On Thu, 2019-10-10 at 14:07 +0200, Martin Bjorklund wrote: > Ladislav Lhotka <lho...@nic.cz> wrote: > > Hi, > > > > some of you have probably seen the discussions around > > > > https://tools.ietf.org/html/draft-lhotka-dnsop-iana-class-type-yang-02 > > > > We proposed to adopt it as a work item in the DNSOP WG, but despite > > some support this is probably not going to happen. The substantial > > objections are: > > > > 1. It is not good to publish a YANG snapshot of an IANA registry as an RFC > > because future implementors will use the module from that RFC and implement > > registry entries that may have been deprecated in the mean time. > > > > 2. The meaning of "deprecated" and "obsolete" defined by IANA (RFC > > 8126) differs from the definition in RFC 7950. > > > > I already raised #2 in this mailing list, and I think it should be > > addressed in the next version of YANG. > > > > Regarding #1, I tried to explain that the RFC is only intended to contain an > > initial revision of the corresponding YANG module, but it didn't help. One > > suggestion was to avoid representing the registries as enumerations or sets > of > > identities, and use only integers. > > That's a bit odd. But perhaps it can be solved by actually not > filling in all values in this module, but rather make it a template > and instruct IANA to fill it in with the contents of the registry at > the time of publication.
OK, so the module template in the RFC couldn't be used at all - this might indeed help. My idea was to tag the RFC as historic as soon as IANA takes over the module maintenance. I think part of the problem is that the new revisions are available from a rather obscure place - the YANG Parameters registry page: https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml Lada > > > > /martin > > > > I wonder if we can come up with a reasonable solution. Without > > having the important registries as YANG modules, it is difficult to > > work on other modules - for DNS, in this case, but it could apply to > > other areas, too. > > > > 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
