[apps-discuss] APPSDIR review of draft-ietf-dccp-udpencap-10

[Carsten Bormann <[e-mail]>]

I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate
).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Grüße, Carsten

---------------------------------

Document: draft-ietf-dccp-udpencap-10
Title: Datagram Congestion Control Protocol (DCCP) Encapsulation for NAT
                                  Traversal (DCCP-UDP)
Reviewer: Carsten Bormann
Review Date: 2012-05-26
IETF Last Call Date: 2012-05-12, for 2012-05-25

** Summary:

This draft is ready for publication as a Proposed Standard after minor
revisions.

** Major Issues:

This document does not have any blocking issues.

One observation is that there was no attempt to exploit any economies
in header sizes that might be available for this encapsulation.  E.g.,
the DCCP checksum header field (made redundant by the UDP checksum
field) is always included as two zero bytes.  This can be rectified
using e.g. a flow-based header compressions scheme (such as ROHC),
which fits well with the flow-based, not-so-constrained-node/network
orientation of DCCP.  Still, this should maybe be noted as a conscious
design decision.

The error "Encapsulated Port Reuse" seems to be used for both
permanent (server does not support more than one 6-tuple per 4-tuple)
and temporary (server is overloaded in some way) errors.  While the
latter ones may be less likely, that mingling may make it harder for
an application to properly react to the error.

** Minor Issues:

In English usage, there is a wide-spread error in calling old things
"standard".  Here, calling the old encapsulation of DCCP "DCCP-STD" is
an unfortunate choice of words, as DCCP-UDP also aims to be a
standard.  Maybe use different terminology, such as "classic" or
"DCCP-IP".

The text at the end of the introduction to 3.3, referring to the
interpretation of UDP header fields, is a bit confusing: It might
appear this recommends reimplementing UDP in a slightly different way.
Only later does it become clear that this is not the intention.
(There is also no mention of UDP-lite, which may be another conscious
design decision worth mentioning.)

The second paragraph of 3.8 only says what should not be done, not
what should be done.  Probably, using the same port number that was
used for the source of the original request is intended.  This text
would benefit from making it very clear that the initiator of the DCCP
connection gets to choose the 4-tuple.

The term "UDP connection" is not defined, but seems to be needed in a
normative way.  (RFC 768 does not define that term.)

The text needs to be very careful when talking about port numbers:
Which level is meant?  DCCP or UDP?  One remaining place is the last
paragraph of 3.9.

7.2 has normative text (specifying the protocol) in the IANA
considerations.  Is this text really intended to be recorded in the
registry?

** Nits:

Fix "suport".

Add a period at the end of the introduction of section 5.

The formatting of the ABNF in 5.1 is unfortunate.

Fix the runt sentence "Following [RFC5762].".

Fix "[RFC4585]running".

Fix "open[RFC5596]".

Fix "DCCPx".

If it is necessary to explain the significance of using DCCP port 9 in
the example, is this missing an informative reference to RFC 4145 ("in
the usual manner")?

Fix "encapsualted".

Make one more pass through the references, please, after doing these:

-- Reference RFC5234 throughout, not RFC4234.

-- [ICMP] seems to be the same as [RFC5927].  Replace the former with the latter.

-- [ICE-TCP] appears to be RFC6544.  Replace the former with the latter.

-- This one appears to be spurious (probably was meant to be 5762):
   [RFC4762]  Lasserre, M. and V. Kompella, "Virtual Private LAN Service
              (VPLS) Using Label Distribution Protocol (LDP) Signaling",

-- This one is not "the RTP Profile for Audio and Video Conferences with
   Minimal Control" (RFC 3551):
   [RFC3511]  Hickman, B., Newman, D., Tadjudin, S., and T. Martin,
              "Benchmarking Methodology for Firewall Performance",
              RFC 3511, April 2003.