On Tue, 2019-11-19 at 11:48 +0000, tom petch wrote: > ----- Original Message ----- > From: "Ladislav Lhotka" <lho...@nic.cz> > To: "Martin Bjorklund" <m...@tail-f.com> > Cc: <netmod@ietf.org> > Sent: Tuesday, November 19, 2019 10:29 AM > > > On Tue, 2019-11-19 at 11:17 +0100, Martin Bjorklund wrote: > > > Ladislav Lhotka <lho...@nic.cz> wrote: > > > > Hi, > > > > > > > > I would like to discuss the issue of developing YANG modules that > > > > mirror IANA registries. The main objection, raised in DNSOP WG in > > > > relation to draft-lhotka-dnsop-iana-class-type-yang-02, was that > the > > > > RFC containing the initial revision of the module doesn't get > updated > > > > along with the IANA registry (IANA is expected to keep the module > in > > > > sync without updating the RFC). As a result implementors can use > the > > > > obsolete snapshot from the RFC. > > > > > > > > I am aware of three solution proposals: > > > > > > > > 1. use some kind of template instead of a YANG module > > > > > > > > 2. include only two or three entries of the registry as examples > so > > > > that it is clear that it is not the complete list > > > > > > > > 3. keep the module in the document during the whole I-D stage but > > > > instruct the RFC Editor to remove it just before it becomes > RFC. > > > Do you mean that the RFC editor removes it and the RFC just points > to > > > the IANA registry? And then the RFC editor hands it over to IANA so > > > that they can use it as an initial version to be published? > > > > Yes. The final RFC would then only describe and explain the design of > the > > module, which is useful in itself (because there are several possible > options > > for translating a registry to YANG). > > > > > As long as the instructions to the RFC editor are clear, I think > this > > > can work. > > > > We have to work out the details and discuss it with IANA, but it > shouldn't IMO > > be too difficult. And the draft in DNSOP can be used as a guinea pig. > > I think that this is a bad idea; we have been handing over modules to > IANA to maintain since 1999 and I have not seen much in the way of > troubles in the intervening decades.
I guess everyone in this mailing list will agree that this issue is largely a red herring, but it seems that our draft in DNSOP cannot move forward without solving it. For those with masochistic inclination, here is a typical ML thread: https://mailarchive.ietf.org/arch/msg/dnsop/0AjdiR8htN_vjglimt1b7z10V_E DNSOP chairs don't want to take a stance and hope that the IESG will resolve this issue somehow - but this is of course not going to happen. > > I want the RFC to contain the initial version of the module - otherwise, > we have no record of the initial version. Why do you need the initial version? After all, it is just a random snapshot of the registry that is used to explain to IANA how the module is supposed to be updated. > > What we should do is make it clear that it is the initial version and > will not be maintained e.g. in the description and revision clauses > > 'The initial version of this module was published in RFCXXXX; the > current version can be found at > https:// ...iana ... > " I suggested something like this repeatedly, without any significant success. What else can we do? Lada > > Tom Petch > > > > > > > > > > > > > Lada > > > > > > > > > > > /martin > > > > > > > > > > I am personally in favour of #3. According to Randy Presuhn, who > > > > proposed it, this procedure was used during the preparation of BCP > > > > 47. It would require some extra coordination with with IANA but, > apart > > > > from that, it should IMO work well and avoid the problem mentioned > > > > above. > > > > > > > > Thanks, Lada > > > > > > > > -- > > > > Ladislav Lhotka > > > > Head, CZ.NIC Labs > > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > > > _______________________________________________ > > > > netmod mailing list > > > > netmod@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > -- > > Ladislav Lhotka > > Head, CZ.NIC Labs > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
