From: netmod <netmod-boun...@ietf.org> on behalf of Michael Richardson 
<mcr+i...@sandelman.ca>
Sent: 05 July 2021 21:40

Randy Presuhn <randy_pres...@alumni.stanford.edu> 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 <mcr+i...@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to