Leaving the registry for later sounds fine to me, in particular if it isn’t clear yet what the registration policy should be.
If we ever add not-over-IP “transports”, there might be a need for experiments before we go registering. So I would probably identify a range of numbers that are strictly reserved for use in experiments. (This needn’t be very small; say, 65280 to 65535.) Grüße, Carsten > On May 29, 2017, at 04:51, Brian E Carpenter <[email protected]> > wrote: > > On 23/05/2017 10:40, Adam Roach wrote: > ... >> 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. > > Adam is correct. The current values (6 and 17) are of course values from > https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml > and the names are those used in the socket API. If we wanted to add, say, > SCTP it would be easy: IP_PROTO_SCTP = 132. > > The problem comes if we want to add "transport" protocols that aren't > directly over IP: things like HTTP, COAP, QUIC... for example. There's > no registry for them. > > We have considerable flexibility thanks to CBOR; for example, as Michael > Richardson noted, we could define values >255 for transport protocols that > are *not* directly over IP. However, that would need a new IANA registry. > > Proposal: Note in the text that the current values are taken from the > existing Protocol Numbers registry. Also note that if values are required > in future that are not in that registry, a new registry for values >255 > will be created. So IANA doesn't have to do anything now. > > Opinions? Objections? > > Brian > > _______________________________________________ > Anima mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/anima > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
