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

[Ballot comment]
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

[Ballot comment]
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.

[Ballot discuss]
Hi,

One issue that I think we should should discuss and resolve (sorry for the late discuss ballot):

In section 4, it states:

  "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 know that we have had some previous discussion on this on Netmod, but, if draft-ietf-netmod-yang-module-versioning-02 gets standardized then it will effectively evolve YANG's "status deprecated" into "must implement or explicitly deviate" and YANG's "status obsolete" into "must not implement".  It wasn't clear to me that marking one of these fields as being deprecated in an IANA registry would mean that existing implementations must stop using it if they migrate to a new version of the generated YANG module.  Hence, I think that at this stage, it may be safer to map IANA "deprecated" into YANG's "status deprecated"?

[Ballot comment]
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

[Ballot comment]
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?

   

This seems unused (and instead we have a lot of 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";
       

I may be missing something, but why two  children of the
?

     
     

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.

[Ballot comment]
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.

[Ballot comment]
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

[Ballot discuss]
Thank you for the work on this document.

(This is a "let's talk" DISCUSS, which I don't expect to hold after the telechat)
I wonder if it wouldn't make sense to add a step where IANA gets the help of the designated experts from each respective registry when elements are added to the DNS class or RR type registries, either by the experts creating the substatements to be added, or at least checking and confirming those created by IANA.

A couple of minor comments below.

Francesca

[Ballot comment]
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.

[Ballot comment]
Thank you for the work put into this document.  I like the idea of having the IANA to update a 'living' YANG module upon modification of IANA registries.

Thank you to Benno Overeinder for his shepherd's write-up (including the WG consensus) even if I regret that no motivation is given about the intended RFC status.

Regards,

-éric

[Ballot comment]
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

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-dnsop-iana-class-type-yang-02. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are seven actions which we must complete.

First, IANA understands that the initial version of the

iana-dns-class-rr-type YANG module is to be created by applying the XSLT stylesheet from Appendix A of [ RFC-to-be ] to the XML version of the Domain Name System (DNS) Parameters registry page located at:

https://www.iana.org/assignments/dns-parameters/dns-parameters.xml

Second, once the iana-dns-class-rr-type YANG module is created and added to the YANG Module Names registry on the YANG Parameters registry page located at:

https://www.iana.org/assignments/yang-parameters/

the following note will be added to the registration:

Classes and types of DNS resource records must not be directly added to the "iana-dns-class-rr-type" YANG module. They must instead be added to the "DNS CLASSes" and "Resource Record (RR) TYPEs" registries, respectively.

Third, in the DNS CLASSes and Resource Record (RR) TYPEs registries on the Domain Name System (DNS) Parameters registry page located at:

https://www.iana.org/assignments/dns-parameters/

the following note will be added to the registries:

When this registry is modified, the YANG module "iana-dns-class-rr-type" must be updated as defined in [ RFC-to-be ].

Fourth, in the DNS CLASSes registry on the Domain Name System (DNS) Parameters registry page located at:

https://www.iana.org/assignments/dns-parameters/

the reference for the registry will be changed by adding [ RFC-to-be ] to the existing reference.

Fifth, in the Resource Record (RR) TYPEs registry on the Domain Name System (DNS) Parameters registry page located at:

https://www.iana.org/assignments/dns-parameters/

the reference for the registry will be changed by adding [ RFC-to-be ] to the existing reference.

Sixth, in the ns registry on the IETF XML Registry page located at:

https://www.iana.org/assignments/xml-registry/

a single new namespace will be registered as follows:

ID: yang:iana-dns-class-rr-type
URI: urn:ietf:params:xml:ns:yang:iana-dns-class-rr-type
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Seventh, in the YANG Module Names registry on the YANG Parameters registry page located at:

https://www.iana.org/assignments/yang-parameters/

a single new YANG module will be registered as follows:

Name: iana-dns-class-rr-type
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:iana-dns-class-rr-type
Prefix: dnsct
Module:
Reference: [ RFC-to-be ]

While the YANG module name will be registered after the IESG approves the document, the YANG module file will be posted after the RFC Editor notifies us that the document has been published.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-05-24):

From: The IESG
To: IETF-Announce
CC: benno@NLnetLabs.nl, dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-iana-class-type-yang@ietf.org, warren@kumari.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (YANG Types for DNS Classes and Resource Record Types) to Proposed Standard


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'YANG Types for DNS Classes and
Resource Record Types'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-05-24. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document introduces the YANG module "iana-dns-class-rr-type"
  that contains derived types reflecting two IANA registries: DNS
  CLASSes and Resource Record (RR) TYPEs.  These YANG types are
  intended as a minimum basis for future data modeling work.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-iana-class-type-yang/



No IPR declarations have been submitted directly on this I-D.

1) RFC type is Proposed Standard, and this is the correct RFC type.


2)

Technical Summary:

  This document introduces the YANG module "iana-dns-class-rr-type"
  that contains derived types reflecting two IANA registries: DNS
  CLASSes and Resource Record (RR) TYPEs.  These YANG types are
  intended as a minimum basis for future data modeling work.


Working Group Summary:

There were several discussions during the working group process,
but they were all resolved.

Special attention is addressed to the IANA registration process, see
also the IANA Considerations section.  Instead of giving examples in
the document, it is more procedural in its description.  This has been
chosen to ensure that, if there are changes in the IANA registration,
the RFC does not give any obsolete examples and be misleading for
software implementers who do not ultimately look at the IANA registry.


Document Quality:

This document is seen as a fundamental building block for future RFCs
in the DNSOP WG that intend to use YANG and NETCONF for DNS
provisioning.

The authors and the WG participants involved were well knowledgable
with regard to YANG and NETCONF.  The reviewers who have done a
thorough review are Paul Wouters, Normen Kowalewski and Bob Harold, in
addition to other DNSOP participants who have given the document
during different phases feedback.

There was also an early review by IANA.  All seemed to be in order,
but there were some comments about the XSLT stylesheet in Annex A,
namely (not) remove it at the publication of the RFC.  The
authors/reviewers prefer to keep the XSLT-style sheet because they do
not expect changes to the style sheet (and if so, it is appropriate to
go through the IETF process again).  It has been agreed to revisit
this during the Last Call to see what others think.


Document Shepherd:  Benno Overeinder
Responsible Area Director: Warren Kumari


(3)  The Document Shepherd did a detailed review of the document
for content as well as simple editorial checks (spelling/grammar).
The shepherd feels the document is ready for publication.

(4) The Document Shepherd has no concerns on the depth or breadth
of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR

(9) The WG Consensus on this document is very solid.

(10) There has been no appeals.

(11) All nits found have been addressed by the authors.

(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) All normative references are in a clear state.

(15) There are no downward normative references

(16) This RFC will not change any existing RFCs.

(17) The document shepherd confirmed the consistency and references of the
IANA Considerations section are accurate.

(18) new IANA registeries will not require expert review

(19) This document creates the YANG modules

(20) This document creates the YANG module. 

1) RFC type is Proposed Standard, and this is the correct RFC type.


2)

Technical Summary:

  This document introduces the YANG module "iana-dns-class-rr-type"
  that contains derived types reflecting two IANA registries: DNS
  CLASSes and Resource Record (RR) TYPEs.  These YANG types are
  intended as a minimum basis for future data modeling work.


Working Group Summary:

There were several discussions during the working group process,
but they were all resolved.

Special attention is addressed to the IANA registration process, see
also the IANA Considerations section.  Instead of giving examples in
the document, it is more procedural in its description.  This has been
chosen to ensure that, if there are changes in the IANA registration,
the RFC does not give any obsolete examples and be misleading for
software implementers who do not ultimately look at the IANA registry.


Document Quality:

This document is seen as a fundamental building block for future RFCs
in the DNSOP WG that intend to use YANG and NETCONF for DNS
provisioning.

The authors and the WG participants involved were well knowledgable
with regard to YANG and NETCONF.  The reviewers who have done a
thorough review are Paul Wouters, Normen Kowalewski and Bob Harold, in
addition to other DNSOP participants who have given the document
during different phases feedback.

There was also an early review by IANA.  All seemed to be in order,
but there were some comments about the XSLT stylesheet in Annex A,
namely (not) remove it at the publication of the RFC.  The
authors/reviewers prefer to keep the XSLT-style sheet because they do
not expect changes to the style sheet (and if so, it is appropriate to
go through the IETF process again).  It has been agreed to revisit
this during the Last Call to see what others think.


Document Shepherd:  Benno Overeinder
Responsible Area Director: Warren Kumari


(3)  The Document Shepherd did a detailed review of the document
for content as well as simple editorial checks (spelling/grammar).
The shepherd feels the document is ready for publication.

(4) The Document Shepherd has no concerns on the depth or breadth
of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR

(9) The WG Consensus on this document is very solid.

(10) There has been no appeals.

(11) All nits found have been addressed by the authors.

(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) All normative references are in a clear state.

(15) There are no downward normative references

(16) This RFC will not change any existing RFCs.

(17) The document shepherd confirmed the consistency and references of the
IANA Considerations section are accurate.

(18) new IANA registeries will not require expert review

(19) This document creates the YANG modules

(20) This document creates the YANG module.