Thanks Tom for your comments! I have prepared a new revision based on the feedback of this rev. 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. GF> In this section I really mean published GF> - meaning both ends know the value. I've tried to reword. Is there such a thing as "Well Known Service Codes"? As opposed to not-well-known? Aren't all service codes well-known? GF> They are. This was changed. 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. GF> My understanding was that these are valid for source ports. That doesn't sound like a good idea to me... GF> Why, this seems common in TCP. 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. GF> Not sure why you regard dynamic clashes as problematic. GF> My understanding was that if an APP really wishes to avoid a clash GF> it should request a port from IANA, but I do not yet know GF> cases where this would be important. 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"). GF> Thanks, my mistake: I suggest a "client 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. GF> Good. I think I suggested this once. I'd strongly support: GF> "a NAT MUST NOT translate/modify the Service Code GF> of packets it forwards" - changed. 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. GF> I also think there could be middleboxes that redirect or GF> reformat content, and such boxes SHOULD NOT change the SC. 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? GF> I see, replaced MUST with "must", you are correct the GF> next requirement repeated this - changed. The following section gives requirements, so probably the best thing is to eliminate the requirement from case 4 in the list. GF> see above, no longer a requirement. 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? GF> Section 8.1.2 At any rate, I think the resulting text should explicitly define actions for each of the four cases you list above. GF> Could do, but Mark provided this example to help explain things, GF> and it follows RFC 4340, so that would need duplicating some text, GF> I'll reword. 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. GF> Removed the following: GF> "This approach can simplify middlebox processing, e.g. it should not be necessary to create more than one hole in a firewall for this case; for example DTLS connections and unencrypted connections for the same application will normally use different Service Codes to distinguish them, but because this is the same application, it makes sense to use the same server port." 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? GF> Not sure which previous requirement? 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? GF> It was to identify that one SC may be associated with GF> several ports. GF> Is this better: "A specific Service Code value MAY be associated with one server port registered with IANA, and/or MAY be associated with one or more server ports in the dynamic range." Section 6.2: "IANA should normally assign a value above 1024" -- shouldn't that be "in the range 1024-49151"? GF> Changed as requested. "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. GF> I suggest: "IANA MUST NOT allocate a single Service Code GF> value to more than one DCCP server port." GF> I also propose to move the IANA Registry instructions to an appendix GF> and suggest this will probably be published as a part of a GF> different RFC (and therefor deleted before publication of this I-D). 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. GF> See separate email. Tom P. GF> Thanks, I'll try to complete the new revision by the end of this week. Gorry
