Benjamin Kaduk <ka...@mit.edu> writes: ...
>> >> > >> > "status": Include only if a class or type registration has been >> > deprecated or obsoleted. In both cases, use the value "obsolete" >> > as the argument of the "status" statement. >> > >> > I don't see any logic in the XSLT that looks for "deprecated", just >> > "OBSOLETE". (This may be fine, given that there's not currently >> > anything listed as deprecated in the live registry...) >> >> Right, the XSLT stylesheet is expected to work on those two registries in >> their current state. The registry XML is loose in some respects and it is >> not clear (to me at least) how a deprecated entry will exactly look like. It >> would be certainly better to indicate the status e.g. with an XML attribute. >> Searching for magic words like "OBSOLETE" in the entry text is brittle, but >> it's currently the only way. > > Understood about the current way being brittle but nothing better being > available (yet). > > My comment here was intended more along the lines of an apparent > inconsistency between the text and the code -- the text says that we will > set "status obsolete" if the registration is deprecated, but the XSLT > doesn't do that. IMO it would be better to either drop the text about > deprecated or add code to look for it (but this is just a non-blocking > comment so my opinion doesn't count for too much). These are instructions for IANA regarding future updates, where registry-deprecated items might come into play. They can choose how to deal with it: - either via manual updates of the YANG module, exactly as it is done for, e.g., iana-if-type [RFC7224] - or by extending the XSLT stylesheet, and possibly also fixing the flaws in the XML ... > >> > >> > <apply-templates >> > select="iana:registry[@id='dns-parameters-2']"/> >> > <apply-templates >> > select="iana:registry[@id='dns-parameters-4']"/> >> > >> > Hardcoding the names "dns-parameters-2" and "dns-parameters-4" is in the >> > class of things that (if I understand correctly) IANA is not always keen >> > on people doing. In this case it's probably not a big issue, since the >> > output of the transformation will be looked at by a human before it's >> > published, and we can modify the template if needed, but I do wonder if >> > any identifier more closely aligned to the registry's role is available. >> >> Again, it is only required to work for the initial revision. I would be >> happy to work with IANA on a more "durable" version of the stylesheet but, >> as you wrote, the XML format may not be maintained for long. > > I feel pretty confident that IANA will continue to publish an XML version > even if it ends up being generated from some other source. Anyway, there's > no urgency for getting a more "durable" version, so we should probably just > wait and react if any issues arise in the future. +1 Thanks, Lada > > Thanks, > > Ben -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
