YANG Types for DNS Classes and Resource Record Types
draft-ietf-dnsop-iana-class-type-yang-05

Thank you for the work on this document.

Thank you to my fellow ADs for the discussion during the telechat regarding IANA registration procedures.

A couple of minor comments below.

Francesca

1. -----

   models along with standard management protocols such as NETCONF and
   RESTCONF can be effectively used in DNS operations, too.  In fact,

FP: Please expand NETCONF and RESTCONF on first use.

2. -----

FP: I believe it would be good to add a sentence in the terminology section stating that DNS terminology is used throughout the document, and point to RFC 8499 and/or RFC 1035. I think informatively would be enough.

Thank you to Valery Smyslov for the SECDIR review.

I applaud the clever use of XSLT to autogenerate and keep the YANG module up to date.

** Section 5.  Recommend refining the security considerations to defer security issues to the modules that use import the data types defined in this document.  Roughly:

OLD
This documents translates two IANA registries into YANG data types
   and otherwise introduces no technology or protocol.  Consequently,
   there are no security issues to be considered for this document.

NEW

This document translates two IANA registries into YANG data types for use by other YANG modules.  When imported and used, the resultant module schema will have data nodes that can be writable or readable via a network management protocol.  Access or modification to such data nodes may be considered sensitive in some network environments, and this risk should be evaluated by the importing module.

Thanks for the work on this document.

idnits shows (https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-dnsop-iana-class-type-yang-03.txt) following warnings :

  == Missing Reference: 'RFC6895' is mentioned on line 264, but not defined

  == Missing Reference: 'RFC1035' is mentioned on line 264, but not defined

Like Roman, I applaud the use of XSLT to avoid specifying redundant information and allow for reasonably automated updates.
Some other comments below.

Section 3

   The IANA document "Domain Name System (DNS) Parameters"
   [IANA-DNS-PARAMETERS] contains altogether thirteen registries.  The

I suggest "at the time of this writing" just in case we add or remove
some registries.

Section 4

   Upon publication of this document, the initial revision of the "iana-
   dns-class-rr-type" YANG module SHALL be created by applying the XSLT
   stylesheet from Appendix A to the XML version of
   [IANA-DNS-PARAMETERS].

This is just a random observation from a bystander, but my understanding
is that IANA is gradually moving registries to a database backend, so
that the XML version may in some sense not be the "most authoritative"
version (or the "preferred form for modification" to use the open-source
software jargon).  The XML format mand XSLT are both quite well-defined,
and the database backend might not be, though, so it's not clear that
moving to a procedure to generate YANG directly from the database would
be an advantage over taking a detour via XML.

   "status":  Include only if a class or type registration has been
      deprecated or obsoleted.  In both cases, use the value "obsolete"
      as the argument of the "status" statement.

I don't see any logic in the XSLT that looks for "deprecated", just
"OBSOLETE".  (This may be fine, given that there's not currently
anything listed as deprecated in the live registry...)

Section 5

The XSLT is only run over trusted input, so it is safe to ignore the
risk of any issues due to improper escaping or input validation.
Whether or not we need to note this property in the RFC is not entirely
clear, though.

Appendix A

   This appendix contains an XSLT 1.0 stylesheet [W3C.REC-xslt-19991116]
   that is intended to be used for generating the initial revision of
   the "iana-dns-class-rr-type" YANG module.  This is achieved by

Is this only going to be used for the initial revision, or for updates
as well?

     <variable name="lf">&#xA;</variable>

This seems unused (and instead we have a lot of &#xA; literals).

     contact
       "        Internet Assigned Numbers Authority

The leading spaces seem a little out of place in the rendered output, to
me.

     description
       "This YANG module translates IANA registries 'DNS CLASSes' and
        'Resource Record (RR) TYPEs' to YANG derived types.
        [...]
        This initial version of this YANG module was generated from
        the corresponding IANA registries using a XSLT stylesheet

Though I guess this part might not work well for a non-initial revision.

       "IANA 'Domain Name System (DNS) Parameters' registry
        https://www.iana.org/assignments/dns-parameters";</text>
        <text>&#xA;&#xA;</text>

I may be missing something, but why two <text> children of the
<variable>?

       <apply-templates
           select="iana:registry[@id='dns-parameters-2']"/>
       <apply-templates
           select="iana:registry[@id='dns-parameters-4']"/>

Hardcoding the names "dns-parameters-2" and "dns-parameters-4" is in the
class of things that (if I understand correctly) IANA is not always keen
on people doing.  In this case it's probably not a big issue, since the
output of the transformation will be looked at by a human before it's
published, and we can modify the template if needed, but I do wonder if
any identifier more closely aligned to the registry's role is available.

Possible DOWNREF from this Standards Track doc to [IANA-DNS-PARAMETERS].
Possible DOWNREF from this Standards Track doc to [IANA-YANG-PARAMETERS].

Not sure if a normative reference to an IANA registry page is technically OK;
the document should probably normatively cite the RFCs that created these
registries instead, or maybe these can be converted to informative references?

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 1, paragraph 5, nit:
>  can then, for instance, run several different DNS server implementations in
>                              ^^^^^^^^^^^^^^^^^
Consider using "several".

Section 4, paragraph 17, nit:
> FC XXXX 5. Security Considerations This documents translates two IANA registr
>                                    ^^^^
Did you mean "these"?

Section 4, paragraph 17, nit:
> ty Considerations This documents translates two IANA registries into YANG dat
>                                  ^^^^^^^^^^
You should probably use "translate".

"Appendix A.", paragraph 6, nit:
> e corresponding IANA registries using a XSLT stylesheet from Appendix A of RF
>                                       ^
Use "an" instead of 'a' if the following word starts with a vowel sound, e.g.
'an article', 'an hour'.

These URLs point to tools.ietf.org, which is being deprecated:
 * https://tools.ietf.org/html/rfcXXXX

These URLs in the document did not return content:
 * https://tools.ietf.org/html/rfcXXXX

These URLs in the document can probably be converted to HTTPS:
 * http://www.w3.org/1999/XSL/Transform
 * http://www.iana.org/assignments

Updated position.  Thanks for addressing my discuss point.

Hi,

Thanks for this document.  I think that documenting this fields in YANG is a good thing.

One minor nit:

In an couple of places you have used 'analogically' but perhaps meant 'analogously' instead?

Thanks,
Rob