|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
I look forward to seeing new text or feedback on these topics, Best wishes, Gorry P.S. draft-ietf-dccp-simul-open has now been rev'ed to -05. ---- * Abstract: /(DCCP). Those allow DCCP/ - Should this be /(DCCP). Those allow DCCP/ ? - I suggest replacing this with... /(DCCP) that allow DCCP/ ^^^^^^ ---- * Introduction - It could be helpful to add some explanatory text to a NAT implementor to explain what DCCP actually is. Here is a suggestion, based on the introductions from various DCCP-related documents: "The Datagram Congestion Control Protocol (DCCP) [RFC4340] is an IETF standards-track transport protocol that allows the transmission of congestion-controlled, unreliable datagrams. DCCP can be viewed equally as either UDP-plus-congestion-control or TCP-minus-reliability (although, unlike TCP, DCCP offers a choice from multiple congestion control algorithms). It is intended for applications such as streaming media, Internet telephony, and on-line games. Since it is both datagram-based and connection-oriented, it faces similar problems to TCP NAT traversal." ---- * Introduction:The first use of "NAT" is not defined, I'd normally expect this to be expanded in the introduction.
---- * Applicability, para 1- I didn't see any feedback or new text concerning the following earlier comment:
/This document applies to NAT devices that want to handle DCCP datagrams. / - Suggest we extend this to say: /This document is an adjunct to [i-d.BEHAVE-UDP] and [i-d.BEHAVE-TCP] which define many terms relating to NATs, lay out general requirements for all NATs, and sets requirements for NATs that handle IP and unicast UDP traffic. The purpose of this document is to set requirements for NATs that handle DCCP traffic. The requirements of this specification apply to Traditional NATs as described in [RFC2663]./ ---- * Applicability - I am concerned that the text at the end of the first paragraph can be read either way. If this is going forward as a BCP, then it should provide clear guidance, on how this *should* be deployed if you wish your NAT to support DCCP, not be seen to make a judgment call on the state of current deployment, which I think is not helpful. Currently it says: /It is not the intent of this document to deprecate the overwhelming majority of deployed NAT devices. These NATs are/ ^^^^^^^^^^^^^^^^^^^^^ /It is not the intent of this document to deprecate already ^^^^^^^ deployed NAT devices. These NATs are/ ---- * Section 4.2 - Remove extra "The" /The A DCCP-Listen packet/ ^^^ --- * Section 4.3. Externally Initiated Connections /RECOMMENDED that a NAT have an "Endpoint-independent/ ^^^^^ /RECOMMENDED that a NAT has an "Endpoint-independent/ ^^^ ---- * Section 4.3 /RECOMMENDED that a NAT have an "Endpoint/ ^^^^^ /RECOMMENDED that a NAT has an "Endpoint/ ^^^ ---- * Section 4.3 /RECOMMENDED that a NAT have an "Address/ ^^^^ /RECOMMENDED that a NAT has an "Address/ ^^^ ---- * Security Considerations /inbound Listen and Sync packets/ ^ ^ /inbound DCCP-Listen and DCCP-Sync packets/ ^^^^^ ^^^^^ ---- * Security Considerations /Listen makes it harder / ^ ^ /DCCP-Listen packet makes it harder / ^^^^^ ^^^^^^ ----