tp> Likewise involving IANA. They maintain registries which anyone can
tp> access. They perform updates, on request, according to the policy of
tp> the registry, which is set when the registry is set up and can range
tp> from requiring a Standards Track RFC to First Come First Served,
tp> depending on how easy you want it to be to make changes. See 'IANA
tp> Considerations' RFC for the range of options. And they can turn
tp> updates to a registry into an update to a code module (such as an SMI
tp> MIB).
Probably Standards Track RFC to update the voucher types.
tp> What I am missing is how easy or difficult you want it to be to make
tp> changes, who will make changes, (IETF only, another SDO, a manufacturer
tp> ....), what review you want for changes by whom, how frequent changes
tp> will be (usually a guess and usually wrong but it helps to have the
tp> assumptions about the requirements spelt out) and such like.
tp> As an engineer, I do like to know the requirements before working on
the design!
We need to be able to write RFCs that extend the voucher types.
Not that often though.
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
