Ah. 3.9.5.1 currently does not have a “.within” clause giving an expectation as to how the type "transport-proto” is going to grow as the protocol evolves. Foolishly, my brain inserted “uint” as the most obvious envelope type.
Allowing negative values for transport-proto certainly would be possible. As a design pattern, I try to reserve broad ranges like this for the indication of differences that a receiver can act upon without understanding the details, such as the difference between base attributes and other attributes in SenML. So I still would favor sticking with uint for now and carving out a range of that for experimental. Grüße, Carsten > On May 30, 2017, at 22:53, Michael Richardson <[email protected]> wrote: > > > Carsten Bormann <[email protected]> wrote: >> 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.) > > -1 to -32! > > -- > Michael Richardson <[email protected]>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > > _______________________________________________ > Anima mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/anima _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
