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.
