On Thu, Mar 24, 2022 at 10:44:42AM +0000, [email protected] wrote: > > It seems that later on you are actually changing what RFC 8407 says > > although I am not sure I understand the reasoning. RFC 8407 recommends > > to use enums if there is a single naming authority allocating values and > > thus ensuring uniqness of values. I am not sure in which sense the DOTS > > decision to use enums is not inline with what RFC 8407 says. DOTS may > > have decided to go with enums for space reasons and then this decision > > implies that values have to be centrally allocated. Note that there are > > IANA registries that allow distributed allocation of values and for > > thoses cases the RFC 8407 recommendation to use identities still applies > > I think. > > [Med] I was referring to this part: > > If extensibility of enumerated values is required, then the > "identityref" data type SHOULD be used instead of an enumeration or > other built-in type. >
But why do you think this statement of RFC 8407 needs any changes or different interpretations? An enum implies that allocations can only be done by updating the module defining the enum. If a WG goes for an enum because of efficiency concerns, then the WG accepts that new allocations require an update of the module defining the enum. If you want multiple parties to allocate values, then the price is the overhead of using identities. The good old middle ground are numbers spaces where some of the space is allocated for distributed allocations (and sometimes these allocations than include things like enterprise IDs to reduce the likelyhood for collisions) but then the YANG equivalent for this is not just a plain enum. /js -- Jürgen Schönwälder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
