My favorite thing in this new draft is the specific way you have identified
changes to RFC4340. Thanks!
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).
Do not capitalize Middleboxes except at the beginning of a sentence.
"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.
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. Maybe you're thinking of
Mark Handley's original plan?
I also find it unhelpful that this History section says things like "[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). 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.
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.
Thanks for the changes!
Eddie
