|
|
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: [dccp] 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
> -----
|
|