From: Michael Richardson
Sent: Monday, July 05, 2021 16:17
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.
<tp>
Michael,
That is nice and clear.
To quote an earlier e-mail in this thread,
> Where I'm a bit blurry is how stuff like the YANG in RFC8995, which uses
> RFC8366 gets updated when IANA revises the module. I think, it mostly doesn't
> matter because none of are generating code from YANG... AT THIS TIME.
Well my answer would be that confusion reigns. An IANA Registry is
authoritative so the minute the RFC is published asking IANA to maintain a
module, then the module in RFC8366(-bis) is obsolete. Trouble is, that the rest
of the RFC - if any - is not. (You may have seen this on the DHCP list with
I-D referencing an RFC when they should have been referencing the IANA website)
RFC7224 gets it right because the contents are only the initial version of
the IANA module so that (almost) any reference to RFC7224 is an error, the
reference should be to the IANA website. That says that having long-lived text
in an RFC with the initial version of an IANA-maintained module can only cause
confusion (IMHO); they are clearer as separate RFC.
Again a quote that caught my eye,
"I also think that in our enumeration/Registry, that we should include the
"value" parameter, so that constrained-voucher can consistently set values
even if the enumeration changes order."
If by 'value' that means the value substatement of the 'enum' YANG statement,
then that may not give you what you expect. What goes on the wire is the text
name string. If a number is displayed to a user, then it is because the local
software had deduced one, perhaps from a YANG module. The text string is the
authoritative definition, the value conveys nothing. If you want a value, then
you need a different type of leaf like an integer. (In other languages, the
binding of text string to value is part of the specification of an enumeration
- not in YANG).
The usual alternative to a YANG enum is identity which can also be in an
IANA-maintained module but which can be augmented. It is just an identifier
(which to me is more honest than an enum with its 'value' substatement:-). It
is referenced by identityref. (It can also form a tree structure). AFAICT
'leaf assertion' in RFC8366 could equally well be an identityref. and then
later RFC could augment the identity.
So I have reservations about enum and about IANA-maintained modules (at least
as part of a larger RFC:-) but I did note when I looked at
draft-ietf-anima-voucher
that one of the authors was a YANG doctor so assumed that the choice of 'enum
was made knowingly.
Tom Petch
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
