Hi Gorry, Thanks for the comments -- see inline... Tom P. > -----Original Message----- > From: dccp-bounces@xxxxxxxx [mailto:dccp-bounces@xxxxxxxx] On Behalf Of > Gorry Fairhurst > Sent: Thursday, June 24, 2010 8:55 PM > To: dccp@xxxxxxxx > Cc: Gorry > Subject: Comments on :draft-ietf-dccp-udpencap-01.txt > > 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". > [Tom P.] This was originally written when 5597 was just a gleam in Remi's eyes and probably needs more major surgery. How about replacing the two paragraphs starting with "In order for" with this: [RFC5597] specifies how DCCP should be handled by NAT devices, but there is a significant installed base of NAT devices that do not support [RFC5597]. In the short term, it would be useful to have an encapsulation for DCCP that is compatible with the installed base that supports [RFC4787] but does not support [RFC5597]. This document specifies that encapsulation, which is referred to as DCCP-UDP. For convenience, the [RFC4340] encapsulation is referred to as DCCP-STD. > ---- > Section 1. > > Is there merit in the introduction pointing to RFC 5596 when describing > the goals for DCCP NAT traversal? > [Tom P.] I like the idea but I'm having trouble seeing how to include it without making it seem like an arbitrary interjection -- it's one of the many features of DCCP, albeit one that's important to NAT traversal, but any way I think of phrasing it seems like arbitrarily mentioning one supported feature. > ---- > 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)." > [Tom P.] I think this sentence can be removed from section 1. > ---- > 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. > [Tom P.] I think you mean section 3 here, and I agree. Although I think the place to mention that is in section 3.3 DCCP-UDP Checksum Procedures. > ---- > 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)." > [Tom P.] OK > ---- > 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). > [Tom P.] I put this in because I was uncomfortable with false advertising, but I see your point. This section can be eliminated. > ---- > 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: > [Tom P.] Well, Windows and Linux are not the only operating systems out there. Android, for example, doesn't support ECN via (the java equivalent of) sockets. > "(e.g., a user-space implementation that uses a socket interface that > does not support ECN)." > [Tom P.] But I do see your point. I suggest we eliminate talk of practicality and replace the last paragraph with: Implementations that do not support ECN MUST follow the procedures in DCCP-STD section 12.1 for implementations that are not ECN capable. > ----- > 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). > [Tom P.] OK > ----- > 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. > > [Tom P.] OK > -----
