Thank you Lada.
I had missed the union, reading the introductory material with more
attention.
Glad to hear IANA did an early review.
Yours,
Joel
On 5/17/2021 8:25 AM, Ladislav Lhotka wrote:
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:
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
