Re: [netmod] IANA registries and YANG
Maybe this approach can be for the algorithms in the "iana-*algs.yang" modules defined in the crypto-types draft. The '*' expands to symmetric, asymmetric, and hash. The problem is that I'm unsure if there is exists 1-1 registries. But, to the extent there are registries, this approach seems easiest for IANA. Kent // contributor > On Dec 18, 2019, at 2:29 AM, Ladislav Lhotka wrote: > > Ladislav Lhotka writes: > >> 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 > > Followup: template turned out to be the right buzzword! Instead of the > initial revision of a YANG module, it is possible to include an XSLT > stylesheet and instruct IANA to use it for generating the initial revision of > the module directly from the XML version of the registry. I used this > approach in > > https://tools.ietf.org/html/draft-ietf-dnsop-iana-class-type-yang-00 > > Could this be a recommended way for converting other IANA registries? > > Lada > >> >> 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. >> >> 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 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] IANA registries and YANG
Ladislav Lhotka writes: > 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 Followup: template turned out to be the right buzzword! Instead of the initial revision of a YANG module, it is possible to include an XSLT stylesheet and instruct IANA to use it for generating the initial revision of the module directly from the XML version of the registry. I used this approach in https://tools.ietf.org/html/draft-ietf-dnsop-iana-class-type-yang-00 Could this be a recommended way for converting other IANA registries? Lada > > 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. > > 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
Re: [netmod] IANA registries and YANG
On Tue, 2019-11-19 at 11:48 +, tom petch wrote: > - Original Message - > From: "Ladislav Lhotka" > To: "Martin Bjorklund" > Cc: > Sent: Tuesday, November 19, 2019 10:29 AM > > > On Tue, 2019-11-19 at 11:17 +0100, Martin Bjorklund wrote: > > > Ladislav Lhotka 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 RFC; 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
Re: [netmod] IANA registries and YANG
On Tue, 2019-11-19 at 11:17 +0100, Martin Bjorklund wrote: > Ladislav Lhotka 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. 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
Re: [netmod] IANA registries and YANG
Ladislav Lhotka 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? As long as the instructions to the RFC editor are clear, I think this can work. /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 > ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
[netmod] IANA registries and YANG
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. 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
