Skip to main content

Telechat Review of draft-ietf-alto-oam-yang-15
review-ietf-alto-oam-yang-15-dnsdir-telechat-lemon-2023-10-23-00

Request Review of draft-ietf-alto-oam-yang
Requested revision No specific revision (document currently at 17)
Type Telechat Review
Team DNS Directorate (dnsdir)
Deadline 2023-10-24
Requested 2023-10-19
Authors Jingxuan Zhang , Dhruv Dhody , Kai Gao , Roland Schott , Qiufang Ma
I-D last updated 2023-10-23
Completed reviews Dnsdir Last Call review of -12 by Scott Rose (diff)
Secdir Last Call review of -12 by Rich Salz (diff)
Genart Last Call review of -12 by Dan Romascanu (diff)
Dnsdir Telechat review of -14 by Scott Rose (diff)
Dnsdir Telechat review of -15 by Ted Lemon (diff)
Yangdoctors Early review of -06 by Andy Bierman (diff)
Opsdir Early review of -06 by Dan Romascanu (diff)
Tsvart Early review of -06 by Spencer Dawkins (diff)
Assignment Reviewer Ted Lemon
State Completed
Request Telechat review on draft-ietf-alto-oam-yang by DNS Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/dnsdir/lPhCoi0_CWnVEOaM90WZpWgNQls
Reviewed revision 15 (document currently at 17)
Result Ready w/nits
Completed 2023-10-23
review-ietf-alto-oam-yang-15-dnsdir-telechat-lemon-2023-10-23-00
This is the third dnsdir review of this document. Previous reviews, done by a
different reviewer, marked it as ready or ready with nits, on the basis that
this document doesn't make any changes to how NAPTR is used, and that's the
only DNS-related content in the document.

I agree with this assessment. My one issue is that when I tried to actually
understand, by reading this document and the two RFCs to which it referred, how
the YANG model represents the NAPTR record, I failed. This may be because I'm
not smart enough, or lack experience in ALTO and/or YANG (both of which are
true).

However, if the authors intend that I be able to understand from this document
what part of the NAPTR record is represented by the data model, it might be
worth revisiting whether the model in fact accomplishes this. In particular,
NAPTR records contain quite a few fields, e.g. order and preference, and these
fields are not mentioned in the YANG data model. No fields at all are, which
makes me think that the data model is only representing one field, or perhaps
represents the owner name of the NAPTR record and doesn't represent the NAPTR
record's content at all.

If the authors intended that this be understood from what is written there, I
would encourage them to clarify the text. I'm calling this a nit rather than
raising it as an issue because I'm assuming that the problem is on my end—I
certainly didn't read the aforementioned RFCs closely. So perhaps someone who
understands those RFCs better than I do would not be confused by the text in
the data model document.