Re: [alto] Dnsdir telechat review of draft-ietf-alto-oam-yang-15

[Jensen Zhang <[e-mail]>]

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 <[e-mail]>
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.
>
>
>