I have a few comments on rev -01 of the above draft,
Best wishes,
Gorry
----
Section 1.
I hesitate to use the words "This is the long-term objective for DCCP",
since this can be seen as a euphemism for "never". I'd suggest we don't
actually need to promote this view by using the words "long-term".
----
Section 1.
Is there merit in the introduction pointing to RFC 5596 when describing
the goals for DCCP NAT traversal?
----
Section 1.
I'm not sure I understand the standards language here:
"Also,
support for ECN might be impractical for some implementations. Those
implementations MAY choose to not support ECN."
- If this is "impractical" whatever that means, then they can choose not
to? This seems odd, and seems to contradict later
- I would much prefer "Implementations SHOULD support ECN (see section
3.4)."
----
Section 2.
Checksum: 16 bits
- I think the checksum field MUST be non-zero, if you over-riding the
DCCP checksum function, as per RFC 5405.
----
Section 3.2
" For DCCP-UDP, all generic header fields except for Checksum function
as specified in [RFC4340]."
I think this could be better reworded:
"All generic header fields, except for the Checksum field have the same
meaning as specified in [RFC4340]"
It could also be useful to say: "(including the update specified in RFC
5596)."
----
3.3.1. Minimum Checksum Coverage Feature
- I agree with not including special support for DCCP partial checksum
support. If you wanted to do this, you should have encapsulated in
UDP-Lite. It would be nice to think NATs will support UDP-Lite, but my
guess is that NATs are just as likely to natively support DCCP, If this
does happen to prove wrong we can redefine UDP-Lite encaps for DCCP!
That said, I do not see why we need to also mandate this:
"A DCCP-UDP
implementation MUST NOT send a "Change R(Minimum Checksum Coverage,
value)" with any "value" other than 0, and MUST answer all "Change
R(Minimum Checksum Coverage, value)" with "Confirm L(Minimum Checksum
Coverage, 0)"."
It is allowable for apps to call the API and say they are willing to set
less checksum coverage, even if the links on the way do not support this
as a special treatment. I'd argue that it's equally OK to negotiate to
use this, even though they happen to routed over a tunnel that will
discard all types of corruption. To me, this seems better to encourage
use of the function, so that when we go Native it can still be used (I
dislike the idea of different features for different transports).
----
3.4 Explicit Congestion Notification
"(e.g., user-space implementations using the
socket interface)."
- I guess this is a comment on Windows? - I'd rather not go there, we
have Linux stacks we have "used" where we set ECN on sockets. I'd
suggest we don't imply it has to be so, and say:
"(e.g., a user-space implementation that uses a socket interface that
does not support ECN)."
-----
Section 3.7
" There is one Service Code registry and one DCCP port registry and
they apply to all combinations of encapsulation and IP version. "
- I think was OK when the work started, but the proposed changes to
ports and services registry (about to be WGLC'ed in TSVWG) would make
this out of date.
I suggest:
" There is one Service Code registry and one DCCP port registration
that applies to all combinations of encapsulation and IP version. "
- It may be helpful to cite RFC 5595 (since service codes are sometimes
:-) alien to non-DCCP people).
-----
Section 3.7
I agree with the IANA instruction not to register variegates per encaps.
I'd however much prefer that we were to omit this last phrase:
"Since
the port registry supports multiple applications registering the same
port (as long as the Service Codes are different), other applications
MAY register on the same port, but those registrations are also
applicable to all combinations of encapsulation and IP version."
- this would avoid ambiguity for the updated IANA procedure, since the
new procedure calls out how IANA should handle this in the TSVWG draft.
-----
