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

[tom petch <[e-mail]>]

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

Randy Presuhn <[e-mail]> wrote:
    > 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.

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

<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

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide