Datagram Congestion Control Protocol (DCCP) Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal
draft-ietf-dccp-simul-open-08
Yes
(Lars Eggert)
(Magnus Westerlund)
No Objection
(Cullen Jennings)
(Dan Romascanu)
(Lisa Dusseault)
(Ralph Droms)
(Ron Bonica)
(Ross Callon)
(Russ Housley)
(Tim Polk)
Note: This ballot was opened for revision 08 and is now closed.
Lars Eggert Former IESG member
Yes
Yes
()
Unknown
Magnus Westerlund Former IESG member
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(2009-05-21)
Unknown
Section 2.2.1 I believe that the final paragraph ("The remaining fields, including...") should include a full list of the fields. Further, the note should be placed before the text that states the specific values to be assigned to those fields. It might be nice to discuss the X field just once. It would be helpful to place the RFC Editor note immediately adjacent to the paragraph that deines the setting of the Type field. === Figure 2 The figure does not make it clear whether the DCCP-Listen should be sent a third time on time-out from Invited state. The text says "at most 2 retransmissions" so the figure appears to be wrong. It should say "3rd timeout".
Alexey Melnikov Former IESG member
No Objection
No Objection
(2009-05-15)
Unknown
2.2.2. Protocol Method for DCCP Server Endpoints [...] A fully specified server endpoint performs a passive-open from the CLOSED state by inviting the remote client to connect. This is performed by sending a single DCCP-Listen packet to the specified remote IP-address:port, using the format specified in Section 2.2.1. The figure below provides pseudocode describing the packet processing in the INVITED state. This processing step follows Step 2 in section 8,5 of [RFC4340]). I think "8,5" should be "8.5". 2.2.3.1. Optional generation of Triggered Requests [...] A client implementing this optmisation MAY immediately perform a typo: optimisation retransmission of a DCCP-Request following the reception of the first DCCP-Listen packet. The retransmission is performed in the same manner as a timeout in the REQUEST state [RFC4340]. A triggered retransmission SHOULD result in the client increasing the exponential-backoff timer interval.
Cullen Jennings Former IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
Lisa Dusseault Former IESG member
No Objection
No Objection
()
Unknown
Pasi Eronen Former IESG member
No Objection
No Objection
(2009-05-15)
Unknown
One editorial nit: there are two instances of "LISTEN'" that probably should be "LISTEN1" instead.
Ralph Droms Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Tim Polk Former IESG member
No Objection
No Objection
(2009-05-21)
Unknown