Hi Ted,
Thanks for the comments on the NAPTR-related part. It is very helpful.
To be more concrete, this "rdns-naptr-records" YANG node is to configure DNS for the U-NAPTR lookup suggested by Sec 3.4 of RFC 8686 (https://datatracker.ietf.org/doc/html/rfc8686#name-step-3-perform-dns-u-naptr-). For example, if
- "198.51.100.0/24" is configured in "rdns-naptr-records/static-prefix"
- the "alto-server/base-uri" is set to "https://alto1.example.net"
- there is an ird resource configured in "alto-server/resource" with resource-id named "ird"
then the following U-NAPTR record will be added:
100.51.198.IN-ADDR.ARPA. IN NAPTR 100 10 "u" "ALTO:https" "!.*!https://alto1.example.net/ird!" ""
Where the order value of 100 and the preference of 10 are determined by default. They can be determined by some other advanced configuration and algorithm, but it is out of the scope of this document.
Thanks,
Jensen
On Tue, Oct 24, 2023 at 2:43 AM Ted Lemon via Datatracker <noreply@xxxxxxxx> wrote:
Reviewer: Ted Lemon
Review result: Ready with Nits
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.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
