Benjamin Kaduk has entered the following ballot position for draft-ietf-dnsop-iana-class-type-yang-03: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-iana-class-type-yang/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Like Roman, I applaud the use of XSLT to avoid specifying redundant information and allow for reasonably automated updates. Some other comments below. Section 3 The IANA document "Domain Name System (DNS) Parameters" [IANA-DNS-PARAMETERS] contains altogether thirteen registries. The I suggest "at the time of this writing" just in case we add or remove some registries. Section 4 Upon publication of this document, the initial revision of the "iana- dns-class-rr-type" YANG module SHALL be created by applying the XSLT stylesheet from Appendix A to the XML version of [IANA-DNS-PARAMETERS]. This is just a random observation from a bystander, but my understanding is that IANA is gradually moving registries to a database backend, so that the XML version may in some sense not be the "most authoritative" version (or the "preferred form for modification" to use the open-source software jargon). The XML format mand XSLT are both quite well-defined, and the database backend might not be, though, so it's not clear that moving to a procedure to generate YANG directly from the database would be an advantage over taking a detour via XML. "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...) Section 5 The XSLT is only run over trusted input, so it is safe to ignore the risk of any issues due to improper escaping or input validation. Whether or not we need to note this property in the RFC is not entirely clear, though. Appendix A This appendix contains an XSLT 1.0 stylesheet [W3C.REC-xslt-19991116] that is intended to be used for generating the initial revision of the "iana-dns-class-rr-type" YANG module. This is achieved by Is this only going to be used for the initial revision, or for updates as well? <variable name="lf">
</variable> This seems unused (and instead we have a lot of 
 literals). contact " Internet Assigned Numbers Authority The leading spaces seem a little out of place in the rendered output, to me. description "This YANG module translates IANA registries 'DNS CLASSes' and 'Resource Record (RR) TYPEs' to YANG derived types. [...] This initial version of this YANG module was generated from the corresponding IANA registries using a XSLT stylesheet Though I guess this part might not work well for a non-initial revision. "IANA 'Domain Name System (DNS) Parameters' registry https://www.iana.org/assignments/dns-parameters";</text> <text>

</text> I may be missing something, but why two <text> children of the <variable>? <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. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop