This draft looks good to me. I have a few comments on the DCCP aspects
of NAT traversal. (Some of these are editorial, a few were also noted
earlier but do not seem to have resulted in new text or discussion).
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 /
^^^^^ ^^^^^^
----
