Eddie Kohler wrote:
My favorite thing in this new draft is the specific way you have
identified changes to RFC4340. Thanks!
>
Good to see I finally addressed that issue. Thanks for your feedback.
Detailed comments.
Service Codes allow a flexible correspondence between application-
layer services and server port numbers, which affects how
applications interact with DCCP. This decouples the use of ports for
connection demultiplexing and state management from their use to
indicate a desired service. An application identifies the requested
service by the Service Code value in a DCCP-Request packet. Each
application may listen on one or more ports associated with one or
more Service Codes ([RFC4340], section 8.1.2).
=> This goes too far and may confuse readers. Remember that ports are
still primary. Prefer:
Service Codes allow applications to declare exactly which services
are associated with server port numbers. This can affects how
applications interact with DCCP. ... Each application specifies
one or more Service Codes for each listening port ([RFC4340], section
8.1.2).
This text did not originate with me, although I'd be happy to adapt it a
little (the original contributor may have more to add).
Suggested NEW:
Service Codes allow an application to declare the set of services
that are associated with server port numbers. This can affect how
applications interact with DCCP. It allows decoupling of the role of
port numbers to indicate a desired service from the connection
demultiplexing and state management. A DCCP application identifies the
requested service by the Service Code value in a DCCP-Request packet.
Each application therefore associates one or more Service Codes with
each listening port ([RFC4340], section 8.1.2).
Do not capitalize Middleboxes except at the beginning of a sentence.
Corrected.
"Middleboxes that desire to identify the type of data being transported
by a flow," => prefer "the type of data a flow claims to transport."
Since middleboxes can't, of course, trust the service code. But you do
make this clearer later on.
I agree, corrected.
Section 1.1.
" The original draft of the DCCP specification did not use traditional
ports; instead the client allocated a 32-bit identifier to uniquely
identify the connection." => I don't know what you mean by the
"original draft," but the 13 July 2001 draft "draft-kohler-dcp-00" has
source and destination ports:
http://www.read.cs.ucla.edu/dccp/draft-kohler-dcp-00.txt
So I consider this false and anyway not helpful.
>
I see. I recall the debate, but not what was included in the drafts of
the spec. I suggest we rephrase this, to say that the Spec considered
alternatives to the traditional way...
NEW:
Early discussion of the DCCP protocol considered an alternative to the
use of traditional ports; instead allocating the client a 32-bit
identifier to uniquely identify each connection.
Maybe you're thinking of Mark Handley's original plan?
>
I think the text was contributed by Mark - he may have further comments?
I also find it unhelpful that this History section says things like
>
I'd prefer this section to reflect a broad consensus - if there are
further comments from you or others who were involved, do let me know
before the end of next week. I'd like to record this right in the RFC.
"[The Service Code] was intended to perform the primary role of a
Published server port, in that it would be trivially simply to obtain a
unique value for each application."
>
The "primary role" of a published
service port is to provide a known rendezvous point, not necessarily to
UNIQUELY identify an application (as the handful of existing collisions
proves).
>
I agree.
Suggest NEW:
The solution in DCCP to this problem was to use a 32-bit Service
Code [RFC4340] that is included only in the DCCP-Request packet. The
use of a 32-bit value was intended to make it trivially simply to
obtain a unique value for each application.
Service Code is not, and has never been, useful for port
rendezvous.
Section 3.2.
I don't really think it's appropriate to put MUST and SHOULD official
requirements on middleboxes, which is a poorly defined term. The three
added requirements at the end could be dropped with no bad effects.
Noted. I'd like to seek some AD Guidance on this (I see
draft-ietf-behave-dccp-01.txt refers back to this draft for NAT traversal).
We should also include the behave draft (which also just completed WGLC)
as an Informational Ref to this draft:
http://www.ietf.org/internet-drafts/draft-ietf-behave-dccp-01.txt
Section 3.3.0.
I like this wording. But watch "Server," which is a normal noun and
shouldn't be capitalized except at the beginning of a sentence.
I have fixed.
/ Service Code is used by a Server/ Service Code is used by a server/
^
/the Server. In this/the server. In this/
^
Thanks for the changes!
Eddie
Gorry
P.S. Have you checked if the port allocation requests for DCCP in
Section 6, seem right?
