Tom,
Thanks for your comments. I am working through them, and it looks like
these will improve the I-D. I'll send a detailed response later.
One thing you said is specifically something that I'd like to discuss at
the meeting tomorrow:
"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."
The idea of using the hexadecimal form was the suggestion that came from
the ad-hoc meeting. I'd like to discuss other options. So here is what
I understand - all inputs are welcome... Let me try to unpack this into
a series of statements.
* The "key" for identifying the service is the Service Code (rather than
the port or its ServName).
* Each Server Port entry in the registry MUST have a ServName i.e.
portnames/servernames/keyword. This need to be unique across all registries.
* Anyone can register a ServName with IANA (or reuse a ServName entry),
as per RFC4340. It was not intended to prevent this, where this was
desired it could be used.
* There's a catch. If we wanted "easy" assignment of Server Ports (with
minimal IANA review), we could not expect the IANA to allow easy
arbitrary allocation to the proposed ServName registry, where these
entries need to be unique across all protocols. So, how could we offer
ServNames that would be simple to allocate?
* It would be nice to have a fixed format that could be automatically
generated. We could allow e.g. SCfoob - but this would not support
non-ASCII SC's. The SC is a 32-bit number, so not all have an ASCII
representation. If we relaxed this, we could allow two formats e.g.
SCfoob and SC0x4543484f. Ideas?
* If we can figure out how to easily create entries, DCCP could ask IANA
to reserve the block of names with a specific prefix, e.g. "0x", "SC" or
whatever. Thoughts?
Let's discuss. I would really like to resolve this soon.
Gorry
