On 5/22/17 22:57, Brian E Carpenter wrote:
Just cherry-picking a COMMENT point that does need some thinking:
The CBOR definition has constants for IP_PROTO_TCP and IP_PROTO_UDP, but
no way to register additional values with IANA. This does not seem
future-proof.
This is a tricky point. The values are of course already IANA values from
https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
If we wanted to add, say, SCTP that would be straightforward enough, without
bothering IANA.
The document doesn't actually say that the values are taken from that
registry, though, does it? I mean, I noticed the parallel, but without
any explicit mention, I assumed that the values were inspired by the
registry rather than bound to it. For example, SIP has response codes
like "200 OK", "300 Multiple Choices," "301 Moved Permanently," "400 Bad
Request," "401 Unauthorized," and so on. These will all look very
familiar to anyone who has worked with HTTP -- but that doesn't mean
they use the same registry.
It sounds like the extensibility plan you had in mind here was something
like "use the numbers from the protocol numbers registry until we need
something new, at which time, panic." Minimally, I'd like to see that
plan written down in this document. Ideally, I'd like to see a different
plan. But whatever is intended needs to be documented, and the
relationship to existing registries (if any) needs to be crystal clear
rather than implied. The fact that you wrote it to mean one thing and I
read it to mean the other is a pretty compelling example of how doing
this in an implicit fashion goes wrong.
But what if we wanted to specify, say, HTTP or QUIC or anything else that
doesn't run directly over IP?
Well, if you don't have a registry at all, then it's going to be even
harder, isn't it? ;)
In particular, one of the ways I've used registries in the past -- and I
don't think this is uncommon -- is seeing a value in a protocol that I
didn't recognize, going to the governing IANA registry, and looking up
that codepoint to find the corresponding protocol definition. Re-using
the protocol numbers registry won't allow developers to do that (unless
we start adding GRASP RFC numbers to the table, which I suspect would
face some resistance).
My strong recommendation here would be to define a new GRASP protocol
numbers registry, state that any values in the GRASP registry that
correspond to a protocol in the
https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
registry SHOULD use the same number (which you imply by your current
choices to be a Good Thing), and that any values that are appropriate
for GRASP but not general protocol numbers SHOULD be assigned by IANA
starting with 252, with each subsequent such registration using the next
smaller number available.
My concern is that this may turn out to be a much broader problem: how
do we express that some upper layer protocol wants to run over a variety of
"transport" layers, some of which are traditional transport-over-IP
and some of which are transport-over-UDP or whatever. Yes, maybe there
should be a registry for that, but it would definitely not be specific
to GRASP.
That seems like an ocean-boiling exercise with no discernible benefit.
It has the clear anti-benefit of lacking the code-point-to-RFC-mapping
that I describe above. I would strongly desire that this never happen.
/a
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
