Hi Joel, thanks for the review, please see my responses below. Joel Halpern via Datatracker <noreply@xxxxxxxx> writes: > Reviewer: Joel Halpern > Review result: Ready with Issues > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-dnsop-iana-class-type-yang-02 > Reviewer: Joel Halpern > Review Date: 2021-05-14 > IETF LC End Date: 2021-05-24 > IESG Telechat date: Not scheduled for a telechat > > Summary: This document is ready for publication as a proposed standard. > > I do have two questions that I hope has already been considered by the WG and > is a non-issue. See minor issues. > > Major issues: > > Minor issues: 1) I presume IANA has been involved in the development > of this document, and is willing to undertake the maintenance? I > looked for but did not see where that was noted. Yes, Michelle Cotton of IANA did an early review last year. One issue that remains to be decided has to do with the XSLT stylesheet that is intended to be used for generating the initial revision of the YANG module: is it to be removed before publication or not? > 2) I question the use of enumerations for the content. I understand > that since IANA will generate new YANG modules when there is a > change, the new models can have new values. I am concerned that if > an implementation using the older schema reads data from a DNS > repository with updated entries (and the corresponding updated > version) the version skew will cause processing errors instead of > simply handing over the numeric value in a fashion that is > acceptable but not understood. This is partly alleviated by the YANG union types "dns-class" and "rr-type" that should be used for configuration data: old clients can always use corresponding numeric values in place of unsupported enums. If the module update rules of sec. 11 in RFC 7950 are observed, then the risk of interoperability issues is IMO reasonably low. Lada > > Nits/editorial comments: > > > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
