This email describes something I am going to speak about this at the DCCP WG meeting. It is one of the last things that needs to be decided relating to the way in which service codes and server ports work for DCCP. After the last DCCP WG meeting, Mark Handley proposed a change in the way IANA should allocate well-known DCCP ports, so that server ports could be given-out on demand by IANA to anyone who applies (with a service code), without requiring a specification or additional justification. After thinking this through, I can see some merit in allowing this, but also some disadvantages in populating the DCCP port registry with freely assigned entries... Here is a different proposal from me for consideration: * IANA registered DCCP ports are fine, and we have a procedure to register them for people who need them [RFC4340]. * Many applications using DCCP can and will use out-of-band signaling to discover server ports (SDP via SIP, SRV via DNS, etc). * Applications that don't do signaling still need an easy way to find a server port for a Service Code (but do they need to be IANA registered?). I will suggest this last case may be easily solved using a common hash function at the client and server (and any tool or midbox that cares about this) that maps the Service Code value to a server port number. It would not be of consequence if the same server port number were matched to different apps - since they would be UNIQUELY identified by Service Code. This hash-approach could eliminate the need for a port registry entry for most new Service Codes. I suggest this gives trivially easily identification of the server port, without needing to coordinate IANA assignments. Thoughts please, Gorry (as an author, not the Chair)
