Thanks Tom for your quick reply. A few comments in-line, you can safely
assume I'd be happy with the changes where there is no comment - this is
starting to look good.
Gorry
On 25/06/2010 16:24, Phelan, Tom wrote:
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
^
- One could even insert "yet" here, if you wish:-)
specifies that encapsulation, which is referred to as DCCP-UDP. For
convenience, the [RFC4340] encapsulation is referred to as DCCP-STD.
I like this text.
----
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.
I wasn't meaning to add a story, I was more thinking of making sure that
readers new all the appropriate pieces...
One possible way could be to change the last sentence above to:
convenience, the [RFC4340] encapsulation (updated by RFC 5596 as
required) is referred to as DCCP-STD.
----
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.
OK, that would fix this for me.
----
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.
Hey, I live in hope :-)
"(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.
That would work for me :-)
-----
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
-----
Thanks,
gorry
