Datagram Congestion Control Protocol (DCCP) Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal
RFC 5596

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

(Lars Eggert) Yes

Magnus Westerlund Yes

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Ralph Droms) No Objection

(Lisa Dusseault) No Objection

(Pasi Eronen) No Objection

Comment (2009-05-15)
No email
send info
One editorial nit: there are two instances of "LISTEN'" that
probably should be "LISTEN1" instead.

(Adrian Farrel) No Objection

Comment (2009-05-21)
No email
send info
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".

(Russ Housley) No Objection

(Cullen Jennings) No Objection

Alexey Melnikov No Objection

Comment (2009-05-15)
No email
send info
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.

(Tim Polk) No Objection

Comment (2009-05-21)
No email
send info
Section 2.2.2, Note under the Figure
s/A server that responds a DCCP-Request/A server that receives a DCCP-Request/

s/LISTEN1state/LISTEN1 state/

s/LISTEN1states/LISTEN1 states/

Section 4, Security Considerations, paragraph 4 has unbalanced parentheticals... suggest

s/SDP [RFC4566])/SDP [RFC4566]/

(Dan Romascanu) No Objection