From: netmod <[email protected]> on behalf of Michael Richardson <[email protected]> Sent: 05 July 2021 00:21
Michael Richardson <[email protected]> wrote: > I propose that the WG adopt this as the -00, and then we change the document > to change this into an RFC7224-style IANA-maintained YANG module. > (In DHC WG, when we did RFC3315bis to make RFC8415 we did a -00 which was > whitespace equivalent to RFC3315 first, and then we amended it) > As I understand it, we would be creating a Registry with IANA Considerations, > and when documents extend the Registry, that IANA writes a new YANG module > (with a new date) for us. > I believe that given that the module gets revised, that we don't have to > worry about enumeration vs leaf/choice/empty. But, if there is some > advantage to doing it the non-enumeration way, it would be good to understand > that. But, we might want to do a WG Consensus call on the differences. We might also want to ask a YANG Doctor to come to the ANIMA WG meeting at the end of the Month, to explain the differences. <tp> I would love to know what the problem is (rather than possible solutions to potential problems:-) enum and identity are solutions with different characteristics as others have spelt out. Which is better depends on the problem, how easy it should be to make changes or to prevent people from making changes:-) Likewise involving IANA. They maintain registries which anyone can access. They perform updates, on request, according to the policy of the registry, which is set when the registry is set up and can range from requiring a Standards Track RFC to First Come First Served, depending on how easy you want it to be to make changes. See 'IANA Considerations' RFC for the range of options. And they can turn updates to a registry into an update to a code module (such as an SMI MIB). So the IANA Considerations section in an RFC creates the registry but what it takes to update it varies depending on what they say. What I am missing is how easy or difficult you want it to be to make changes, who will make changes, (IETF only, another SDO, a manufacturer ....), what review you want for changes by whom, how frequent changes will be (usually a guess and usually wrong but it helps to have the assumptions about the requirements spelt out) and such like. As an engineer, I do like to know the requirements before working on the design! Tom Petch -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
