DCCP-UDP: A Datagram Congestion Control Protocol UDP Encapsulation for NAT Traversal
draft-ietf-dccp-udpencap-11

Martin already found everything I found

Substantive comments; these are non-blocking, but please consider them
seriously, and feel free to chat with me about them:

Ditto on "Update 5762",  and on Stephen's DANE comment.  Also...

-- 3.8 --
In list item 2:
   A DCCP endpoint MUST implement one of the two
   methods:

Does that mean *exactly one*, or might it implement both, using each in different circumstances?  Regardless of the answer to that question, the 2119 MAYs in the two methods are wrong.  If at least one of these MUST be implemented, then they are *not* both entirely optional (which is what MAY means). I suggest changing "MAY accept" and "MAY support" to "accept" and "supports", respectively, and changing "A DCCP server" to "The DCCP server" in both cases.

========
Other comments; no need to respond to these. Take them or modify them
as you please:

-- Introduction --
There's no need for the [RFC4340] citation *twice* in the first paragraph, and then once again in the second.  The first citation will do for all three.  I would also change that first citation to be this way: "The Datagram Congestion Control Protocol (DCCP) [RFC4340] is a transport-layer protocol that..."

The same is true for the three [RFC5597] citations in the second paragraph, though the reference style (of which I'm not terribly fond, but nevermind) makes it matter less.  Still, I might change the second and third instances to just say "RFC 5597", without making them citations.

-- 3 --
   A DCCP implementation MAY allow services to be simultaneously offered
   over any or all combinations

Does this really need to be a 2119 MAY?  Why on Earth?

-- 5 --
   This is considered a
   scenario that has the potential to be an important use-case.

That's double-talk.  Please find a different way to say what you really mean.

-- 5.1 --
The second sentence is missing a closing paren.  It also should probably have a citation for [RFC5234].

-- 5.2 --
Do you really want to cite RFC 4234?

-- 6 --
OLD
   A firewall than interprets
NEW
   A firewall that interprets

All my comments have been addressed by the new revision of the draft. So, I am clearing my discuss. Thanks!

Good document with some nits:

- ID-Nits complains a bit about unused references and one obsoloted reference
  ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234)

- the  document header should mention that this memo updates RFC 5762.

- Section 3., paragraph 7:

>    Section 3.8 describes usage of UDP ports.  This includes
>    implementation of a DCCP-UDP encapsulation service as a daemon that
>    listens on a well-known port, allowing multiplexing of different DCCP
>    applications over the port.

  s/over the port/over the same port/

- Section 5.4., paragraph 2:

>    An approach to doing this might be to include candidates for the
>    DCCP-UDP encapsulation and native DCCP into an Interactive
>    Connectivity Establishment (ICE) [RFC5245] exchange.  Since DCCP is
>    connection-oriented, these candidates would need to be encoded into
>    ICE in a manner analogous to TCP candidates defined in [ICE-TCP].
>    Both active and passive candidates could be supported for native
>    DCCPx and DCCP-UDP encapsulation, as may DCCP simultaneous
>    open[RFC5596].  In choosing local preference values, it may make
>    sense to to prefer DCCP-UDP over native DCCP in cases where low
>    connection setup time is important, and to prioritise native DCCP in
>    cases where low overhead is preferred (on the assumption that DCCP-
>    UDP is more likely to work through legacy NAT, but has higher
>    overhead).

  s/DCCPx/DCCP-STD/

Please consider the comments from Carsten Bormann's review:

http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06038.html

My only comment is really a question: do we want to define a mechanism for working around IPv6 NAT, thereby perhaps passively encouraging the deployment of IPv6 NAT.  I realize the mechanism in this document is completely protocol independent and the definition of its use on IPv6 costs essentially nothing.

Consider pointing out in the description of the first method in section 3.8 that peers that implement
this method will not work with peers that do not use rtcp-mux.

Please clarify this sentence:
" (The active state of a DCCP connection is defined in Section 3.8: A DCCP connection becomes active following transmission of a DCCP- Request, and become inactive after sending a DCCP-Close.)"
Did you mean RFC 4340 instead of Section 3.8 here?

  Please consider the editorial comments in the Gen-ART Review by
  Kathleen Moriarty on 25-May-2012.  Please find the review here:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg07453.html

- Isn't this really pretending that the need for a UDP
encapsulation is "short-term"? Why is such pretense useful? 

- Along the same lines, is a "SHOULD prefer DCCP-STD" not going
to lead to another happy-eyeballs problem to be solved later?
(The 1st para of section 5 says the above, but 5.4 says that its
ok to prefer DCCP-UDP where low connection setup time is
important, which appears to be the exception that makes
preferring DCCP-STD a SHOULD and not a MUST?)

- So a portmapper-like thing like this is going to have a
problem with DANE perhaps - has anyone thought that out? that
is, what port should I use when I name the DANE TLSA record?  I
assume it ought be the DCCP destination port, and that any
resulting DTLS session is with the process listening there and
not the portmapper. But am I right? This could well be a topic
for future study rather than someting to decide here. (Not
sure.) But in any case, saying something might be useful.

- I think section 6 could usefully say that a client
MUST establish DTLS sessions with the listener on the
DCCP port and not the UDP port. 

- typo: 3.4, s/A DCCP-UDP implementations MAY/ DCCP-UDP
implementations MAY/

"These fields identify the UDP ports on which the source and
  destination (respectively) of the packet are listening for
  incoming DCCP-UDP packets.  The UDP port values do not identify
  the DCCP source and destination ports."

I don't know if there is enough DCCP in the wild that any of the 
router vendors have implemented ECMP support for it, so the 
following comment may be moot. 

This encapsulation is going to trigger the use of UDP ECMP in
place of DCCP ECMP, but without enough entropy in the 
packet header for ECMP to occur. Thus a service using
this encapsulation will probably see worse performance from
the routing layer than a service running a native transport.

This probably deserves discussion in the document.