Re: [netmod] [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but what's he encoding ?

[tom petch <[e-mail]>]

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 <[e-mail]>   . o O ( IPv6 IøT consulting )

           Sandelman Software Works Inc, Ottawa and Worldwide