Hi Gorry,
Section 1.1:
When you use the term "Well Known" port, do you mean just "Well Known" or "Well
Known and Registered"? The discussion about rendezvous ports would seem to
apply to both ranges.
Is there such a thing as "Well Known Service Codes"? As opposed to
not-well-known? Aren't all service codes well-known?
Section 2.1:
Why are you suggesting that the ephemeral ports should include 1024-49151? So
going back to above, that seems to be advocating only Well Known ports and
eliminating Registered. That doesn't sound like a good idea to me...
Section 2.7:
I'm not sure that I see the need for this, although as a general concept I
guess it doesn't hurt and could be helpful. However, the given algorithm
produces ports that are in the dynamic port ranges and will conflict with
assignments of ports for requests. If we keep this hashing SCs thing, the
results need to be between 1024 and 49151.
Section 3:
I think the heading "A sending host" is ambiguous. Maybe something like "A
DCCP Client" would be more clear (or "A host initiating a connection").
Section 3.2:
I don't think it's a good idea to open the door to allowing NATs to change
Service Codes. Maybe we could be strong and say NATs MUST NOT change Service
Codes, or we should be totally silent and allow the BEHAVE document to say that.
Should the middlebox requirements be specified in the BEHAVE document, and not
here? I guess BEHAVE is just for NATs, and here we're talking about all
middleboxes. If we decide to keep these requirements here for that reason,
then I think the middle one should be MUST NOT change Service Codes.
Section 3.3:
You list the four cases, but the fourth case includes a requirement and the
others don't. Shouldn't the other cases include requirements too? Case 1 MUST
be supported, cases 2 and 3 SHOULD or MAY?
The following section gives requirements, so probably the best thing is to
eliminate the requirement from case 4 in the list.
It's unclear to me what portion of RFC 4340 is being updated? Are you
replacing the MUST, MAY lines with the update, or adding to them? At any rate,
I think the resulting text should explicitly define actions for each of the
four cases you list above.
Section 3.3.1:
A middlebox may only need to create one pinhole for a connection to SCs on the
same server port? I don't see how this would be possible, unless it does the,
I forget the term, but one of the "cone" connections used by UDP -- any
incoming packet with the destination port gets through regardless of the source
port and address. That's reasonable for connectionless UDP but I don't think
it's a good idea for connection-oriented DCCP. The main point here though is
that you can support more than the usual number of servers with DCCP, and the
middlebox thing doesn't seem to be particularly relevant. So probably the best
thing is to remove the mention of middleboxes.
Section 3.3.2:
Is the requirement here a repetition of an earlier req at a lower strength --
one port MAY be associated with multiple SCs as opposed to SHOULD in a previous
req?
And what does "although only a single port is registered with IANA" mean? Is
there really any relationship between what's registered with IANA here? Do you
mean that only one port can be registered with IANA?
Section 6.2:
"IANA should normally assign a value above 1024" -- shouldn't that be "in the
range 1024-49151"?
"IANA MUST NOT allocate more than one DCCP server port with single Service Code
value" -- by this do you mean that a single Service Code can't be allocated to
more than one port? If so, maybe there's some clearer way to phrase it.
I don't like the idea of making the service name from the hexadecimal value of
the Service Code. It seems to me that service names are meant to human
readable, and the hex value is anything but.
Tom P.
