Unicast UDP Usage Guidelines for Application Designers

Note: This ballot was opened for revision 11 and is now closed.

(Jari Arkko) Yes

Comment (2008-08-14 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I don't quite understand how the tracker brought this document to the
telechat without having Magnus vote "Yes". Presumably Magnus is happy
with the document, no?

(Magnus Westerlund) Yes

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Lisa Dusseault) No Objection

Comment (2008-09-11 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Section 3.4:
   "This results in a relatively weak
   protection from in terms of coding theory"

I think some noun is missing after the word "from"

Same section:

   "This check is not strong from a coding or cryptographic
   perspective, and is not designed to detect physical-layer errors or
   malicious modification of the datagram"

Is it that it can't detect or can't distinguish between?

(Pasi Eronen) No Objection

Comment (2008-08-11 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
There's some repetition of text in Sections 3.1.2 and 3.5, but
presumably RFC editor copyediting will take care of that.

(Russ Housley) No Objection

(Cullen Jennings) (was Discuss) No Objection

Comment (2008-08-13)
No email
send info
I'd really like to talk a little bit about the MSL - the implementation I see code for a MSL much shorter than the 2 minutes recommended here. The result is that it's very hard to predict how long anything will wait. We would be much better off to revise the MSL to some realistic number - then people might implement that and one would count on it. All you can count on today is that if you have a MSL of 2 minutes, lots of equipment will time out long before that.

(Chris Newman) No Objection

(Jon Peterson) No Objection

(Tim Polk) No Objection

(Dan Romascanu) (was Discuss) No Objection

(Mark Townsley) No Objection

(David Ward) (was Discuss) No Objection

Lars Eggert Recuse