On 25/05/2017 08:38, Adam Roach wrote: > On 5/24/17 2:47 PM, Brian E Carpenter wrote: >> On 25/05/2017 05:35, Adam Roach wrote: >>> On 5/24/17 12:07 PM, Michael Richardson wrote: >>>> Adam Roach <[email protected]> wrote: >>>> > 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. >>>> >>>> Actually, we aren't limited to 1-octet. >>>> It's a CBOR integer, and grows automatically. >>>> So we could have >=256 for GRASP-only things. >>>> >>> That's even better. >> I'm still puzzled about doing this *specifically* for GRASP. Can this be >> the only upper layer that would like to signal a choice of this kind? > > You do take my point about being able to find the specification for a > codepoint by way of the IANA registry, right? Can you take an explicit > position on whether you think that's something we should ignore? I can't > tell whether you missed the point or just believe it's unimportant.
Sorry, yes I do take the point. I now recall finding myself in a dilemma many months ago when I realised that (a) to specify a foo-over-IP transport layer there is already a well-defined registry and that (b) to specify a foo-over-something-over IP transport layer, there is no registry. In the draft we ducked this, as you noticed. Indeed we can add a registry, or perhaps a note that a registry needs to be created for any transports that are not directly over IP. But then I got to thinking: isn't this a general problem, not a GRASP-specific problem? Which is something to be discussed in the transport and ART areas, I guess. Is it sufficient to state that the currently defined values are from https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml and that the encoding of values for protocols that do not have IP protocol numbers is for further study? Personally I'd rather do that than try to resolve this question on the fly. As Michael pointed out, CBOR gives us a lot of freedom on how to resolve this without any change to the protocol syntax. Brian _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
