Skip to main content

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)

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
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]/