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

From: tom petch <[email-masked]>
Date: Mon, 5 Jul 2021 16:13:36 +0000

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

           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Michael Richardson <[email-masked]>
Date: Mon, 05 Jul 2021 12:27:05 -0400

Tom writes:
    > 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).

yes, it's a text string for XML and JSON,
this isn't the case for YANG-CBOR if a value is set.

---

From: Randy Presuhn <[email-masked]>
Date: Mon, 5 Jul 2021 10:29:20 -0700

Hi -

On 2021-07-05 9:13 AM, tom petch wrote:
...
> 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.
...

There are other straightforward ways to deal with this.

In ltru the I-Ds contained both material for publication
in the RFC as well as a *massive* amount of material for
population of the IANA language tag registry.  We needed
it in I-D form for review during development, but wanted to
remove all temptation to use the RFC instead of the IANA
registry.

All it took was a word of instruction to the RFC editor
to delete the many many many pages of registry content
upon publication.  Worked fine.

In this case, just tell the RFC editor to delete the
IANA-maintained module.

Randy

---

From: Michael Richardson <[email-masked]>
Date: Mon, 05 Jul 2021 16:40:38 -0400

> In this case, just tell the RFC editor to delete the

I think you mean, the RFC-maintained module :-)
How do we keep the YANG catalog from latching onto it.

---

From: tom petch <[email-masked]>
Date: Tue, 6 Jul 2021 08:49:38 +0000

From: netmod <[email-masked]> on behalf of Michael Richardson <[email-masked]>
Sent: 05 July 2021 21:40

<tp>
I do not know the answer to YANG Catalog but I do think that Randy has the right words.  I take it to mean delete the initial version of the IANA-maintained module from the published RFC.  MMM, I never thought of that.  On the other hand, it does break the audit trail, of where did the information in IANA come from if the RFC no longer contains it.  On balance, I prefer a separate RFC for just the IANA-maintained module.

More generally, IANA-maintained modules do have consequences.  I see change control as then residing with IANA so all changes have to go through IANA and at present, I only see IANA making changes to enum or identity.  The module in  RFC8366 contains more than that and if other parts of the YANG need changing, I do not know if IANA would be comfortable with making those changes or not.  I have not seen the change control ever reverting from IANA back to the IETF although that is probably possible, in order to make such changes.

One solution is a separate module of just enum maintained by IANA with the rest of the YANG in rfc8366bis importing that module.  But AFAICT such a change would require a change of module name which then ripples through all those using the module unless RFC7950 s.11 allows such a solution based on submodules - I am unsure.  Changing the module name does open up many possibilities but I am do not know if that is acceptable.

Tom Petch