Skip to main content

Last Call Review of draft-ietf-dnsop-iana-class-type-yang-02
review-ietf-dnsop-iana-class-type-yang-02-genart-lc-halpern-2021-05-14-00

Request Review of draft-ietf-dnsop-iana-class-type-yang
Requested revision No specific revision (document currently at 05)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2021-05-24
Requested 2021-05-10
Authors Ladislav Lhotka , Petr Špaček
I-D last updated 2021-05-14
Completed reviews Genart Last Call review of -02 by Joel M. Halpern (diff)
Secdir Last Call review of -02 by Valery Smyslov (diff)
Assignment Reviewer Joel M. Halpern
State Completed
Request Last Call review on draft-ietf-dnsop-iana-class-type-yang by General Area Review Team (Gen-ART) Assigned
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/iwUIug9BYj2VBt_UqP-Cr239RlE
Reviewed revision 02 (document currently at 05)
Result Ready w/issues
Completed 2021-05-14
review-ietf-dnsop-iana-class-type-yang-02-genart-lc-halpern-2021-05-14-00
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. 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.

Nits/editorial comments: