RFC 9108 PROPOSED STANDARD DNS · YANG · IANA

YANG DNS Types: YANG Types for DNS Classes and Resource Record Types

Two DNS registries, DNS CLASSes and RR TYPEs, translated into reusable YANG types.

On rfc-editor.org ↗
PUBLISHED
September 2021
AUTHORS
L. Lhotka, P. Špaček
STREAM
IETF
YANG MODULE
iana-dns-class-rr-type
MODULE PREFIX
dnsct
REGISTRIES COVERED
2 of 13 DNS Parameters registries
NUMERIC FORM
16-bit unsigned integer (uint16)
STYLESHEET LANGUAGE
XSLT 1.0
DOI
10.17487/RFC9108

RFC text

Contents
Original text · RFC Editor View on rfc-editor.org ↗
Internet Engineering Task Force (IETF)                         L. Lhotka
Request for Comments: 9108                                        CZ.NIC
Category: Standards Track                                      P. Špaček
ISSN: 2070-1721                              Internet Systems Consortium
                                                          September 2021


          YANG Types for DNS Classes and Resource Record Types

Abstract

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

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc9108.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction
   2.  Terminology
   3.  YANG Design Considerations
   4.  IANA Considerations
     4.1.  URI Registrations
     4.2.  YANG Module Registrations
   5.  Security Considerations
   6.  References
     6.1.  Normative References
     6.2.  Informative References
   Appendix A.  XSLT Stylesheet
   Authors' Addresses

1.  Introduction

   YANG [RFC7950] has become a de facto standard as a language for
   modeling configuration and state data, as well as specifying
   management operations and asynchronous notifications.  It is
   reasonable to expect that the approach based on utilizing such data
   models along with standard management protocols such as
   NETCONF [RFC6241] and RESTCONF [RFC8040] can be effectively used in
   DNS operations, too.  In fact, several efforts are currently underway
   that attempt to use NETCONF or RESTCONF for configuring and managing

   *  authoritative servers,

   *  resolvers, and

   *  zone data.

   While it is possible to use the management protocols mentioned above
   with ad hoc or proprietary data models, their real potential can be
   realized only if there is a (completely or partly) unified data model
   supported by multiple DNS software implementations.  Operators can
   then, for instance, run several DNS server implementations in
   parallel, and use a common configuration and management interface and
   data for all of them.  Also, it becomes considerably easier to
   migrate to another implementation.

   Based on the previous experience from the IETF Routing Area, it is to
   be expected that the development of unified data models for DNS will
   be a lengthy and complicated process that will require active
   cooperation and compromise from the vendors and developers of major
   DNS server platforms.  Nevertheless, it is likely that any DNS-
   related data modeling effort will need to use various DNS parameters
   and enumerations that are specified in several IANA registries.  For
   use with YANG, these parameters and enumerations have to be
   translated into corresponding YANG types or other structures.  Such
   translations should be straightforward and relatively
   uncontroversial.

   This document provides a translation of two fundamental DNS-related
   IANA registries to YANG.  It contains the initial version of the YANG
   module "iana-dns-class-rr-type", which defines derived types for the
   common parameters of DNS resource records (RR): class and type.
   These YANG types, "dns-class" and "rr-type", reflect the IANA
   registries "DNS CLASSes" and "Resource Record (RR) TYPEs"
   [IANA-DNS-PARAMETERS].

   Appendix A contains an XSLT 1.0 stylesheet that is intended to be
   used by IANA for generating the initial version of the "iana-dns-
   class-rr-type" YANG module.  Subsequently, whenever a new class or RR
   type is added to the above registries, IANA will also update the
   "iana-dns-class-rr-type" YANG module, following the instructions in
   Section 4 below.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   The terminology for describing YANG data models can be found in
   [RFC7950].  DNS terminology used in this document can be found in
   [RFC1035] and [RFC8499].

3.  YANG Design Considerations

   At the time of writing, the "Domain Name System (DNS) Parameters"
   [IANA-DNS-PARAMETERS] contains altogether thirteen registries.  The
   YANG module "iana-dns-class-rr-type" defines derived types
   corresponding to only two of the registries that are essential for
   data models involving zone data, namely "DNS CLASSes" and "Resource
   Record (RR) TYPEs".  It is expected that the remaining registries in
   [IANA-DNS-PARAMETERS], as well as other DNS-related IANA registries,
   will be analogously reflected in future YANG modules as necessary.
   This way, an appropriate combination of YANG modules can be chosen
   depending on which YANG types are needed for a given data modeling
   purpose.

   The registries "DNS CLASSes" and "Resource Record (RR) TYPEs" are
   transformed into YANG enumeration types "dns-class-name" and "rr-
   type-name", respectively.  This is the initial fragment of the
   former:

     typedef dns-class-name {
       type enumeration {
         enum IN {
           value 1;
           description
             "Internet (IN)";
           reference
             "RFC 1035";
         }
         ...
       }
       ...
     }

   The other derived type, "rr-type-name", is defined similarly.

   [RFC3597] introduced the option of specifying a class or RR type via
   its assigned decimal number as an alternative to the mnemonic name.
   For example, the "IN" class can be equivalently written as "CLASS1",
   and "AAAA" type can be written as "TYPE28".

   Accordingly, the derived types "dns-class" and "rr-type" are defined
   in the YANG module as a union of two member types:

   *  16-bit decimal integer ("uint16")

   *  mnemonic name belonging to the enumerations "dns-class-name" and
      "rr-type-name", respectively.

   For instance, the "rr-type" type is defined as follows:

     typedef rr-type {
       type union {
         type uint16;
         type rr-type-name;
       }
       description
         "This type allows reference to a DNS resource record type
          using either the assigned mnemonic name or numeric value.";
     }

   As unassigned and reserved class and RR type values are not included
   in the mnemonic name enumerations, they can only be specified using
   their decimal values.

4.  IANA Considerations

   This section deals with actions and processes necessary for IANA to
   undertake to maintain the "iana-dns-class-rr-type" YANG module.  This
   YANG module is intended to reflect the "DNS CLASSes" and "Resource
   Record (RR) TYPEs" registries in [IANA-DNS-PARAMETERS].  The most
   recent version of the YANG module is available from the "YANG
   Parameters" registry [IANA-YANG-PARAMETERS].

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

   IANA has added this note to the "iana-dns-class-rr-type" item of the
   "YANG Module Names" registry [IANA-YANG-PARAMETERS]:

   |  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.

   When a new DNS class or RR type is added to the "DNS CLASSes" or
   "Resource Record (RR) TYPEs" registry, a new "enum" statement SHALL
   be added to the "dns-class-name" or "rr-type-name" type,
   respectively.  The assigned name defined by the "enum" statement
   SHALL be the same as the mnemonic name of the new class or type.  The
   following substatements to the "enum" statement SHALL be defined:

   "value":        Use the decimal value from the registry.

   "status":       Include only if a class or type registration has been
                   deprecated or obsoleted.  IANA "deprecated" maps to
                   YANG status "deprecated", and IANA "obsolete" maps to
                   YANG status "obsolete".

   "description":  Replicate the corresponding information from the
                   registry, namely the full name of the new DNS class,
                   or the meaning of the new RR type, if any.

   "reference":    Replicate the reference(s) from the registry.

   Unassigned or reserved values SHALL NOT be included in the "dns-
   class-name" and "rr-type-name" enumeration types.

   Each time the "iana-dns-class-rr-type" YANG module is updated, a new
   "revision" statement SHALL be added before the existing "revision"
   statements.

   IANA has added this note to the "DNS CLASSes" and "Resource Record
   (RR) TYPEs" registries:

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

   The "Reference" text in the "DNS CLASSes" registry has been updated
   as follows:

   OLD:

   |  [RFC6895]

   NEW:

   |  [RFC6895][RFC9108]

   The "Reference" text in the "Resource Record (RR) TYPEs" registry has
   been updated as follows:

   OLD:

   |  [RFC6895][RFC1035]

   NEW:

   |  [RFC6895][RFC1035][RFC9108]

4.1.  URI Registrations

   This document registers a URI in the "IETF XML Registry" [RFC3688].
   The following registration has been made:

   URI:  urn:ietf:params:xml:ns:yang:iana-dns-class-rr-type
   Registrant Contact:  The IESG.
   XML:  N/A; the requested URI is an XML namespace.

4.2.  YANG Module Registrations

   This document registers a YANG module in the "YANG Module Names"
   registry [RFC6020].  The following registration has been made:

   Name:  iana-dns-class-rr-type
   Namespace:  urn:ietf:params:xml:ns:yang:iana-dns-class-rr-type
   Prefix:  dnsct
   Reference:  RFC 9108

5.  Security Considerations

   This document translates two IANA registries into YANG data types and
   otherwise introduces no technology or protocol.  The definitions
   themselves have no security impact on the Internet, but their use in
   concrete YANG modules might have.  The security considerations
   spelled out in the YANG specification [RFC7950] apply to this
   document as well.

6.  References

6.1.  Normative References

   [IANA-DNS-PARAMETERS]
              IANA, "Domain Name System (DNS) Parameters",
              <https://www.iana.org/assignments/dns-parameters>.

   [IANA-YANG-PARAMETERS]
              IANA, "YANG Parameters",
              <https://www.iana.org/assignments/yang-parameters>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              DOI 10.17487/RFC3688, January 2004,
              <https://www.rfc-editor.org/info/rfc3688>.

   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
              the Network Configuration Protocol (NETCONF)", RFC 6020,
              DOI 10.17487/RFC6020, October 2010,
              <https://www.rfc-editor.org/info/rfc6020>.

   [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
              RFC 7950, DOI 10.17487/RFC7950, August 2016,
              <https://www.rfc-editor.org/info/rfc7950>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [W3C.REC-xslt-19991116]
              Clark, J., "XSL Transformations (XSLT) Version 1.0", W3C
              Recommendation REC-xslt-19991116, November 1999,
              <https://www.w3.org/TR/1999/REC-xslt-19991116>.

6.2.  Informative References

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/info/rfc1035>.

   [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
              (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September
              2003, <https://www.rfc-editor.org/info/rfc3597>.

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <https://www.rfc-editor.org/info/rfc6241>.

   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
              <https://www.rfc-editor.org/info/rfc8040>.

   [RFC8499]  Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
              Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
              January 2019, <https://www.rfc-editor.org/info/rfc8499>.

Appendix A.  XSLT Stylesheet

   This appendix contains an XSLT 1.0 stylesheet [W3C.REC-xslt-19991116]
   that is to be used to generate the initial revision of the "iana-dns-
   class-rr-type" YANG module.  This is achieved by applying the
   stylesheet to the XML version of the IANA registry "Domain Name
   System (DNS) Parameters" [IANA-DNS-PARAMETERS] that was current at
   the time this document was published.

   Using the ubiquitous xsltproc tool, the YANG module text can be
   generated with this command:

       $ xsltproc iana-dns-class-rr-type.xsl dns-parameters.xml

   <CODE BEGINS> file "iana-dns-class-rr-type.xsl"
   <?xml version="1.0" standalone="yes"?>
   <stylesheet xmlns="http://www.w3.org/1999/XSL/Transform"
               xmlns:iana="http://www.iana.org/assignments"
               version="1.0">
     <output method="text"/>
     <strip-space elements="*"/>

     <variable name="dq">"</variable>
     <variable name="sq">'</variable>

     <variable name="module-intro">
       <text>module iana-dns-class-rr-type {
     yang-version 1.1;
     namespace
       "urn:ietf:params:xml:ns:yang:iana-dns-class-rr-type";
     prefix dnsct;

     organization
       "Internet Assigned Numbers Authority (IANA)";

     contact
       "        Internet Assigned Numbers Authority

        Postal: ICANN
                12025 Waterfront Drive, Suite 300
                Los Angeles, CA 90094

        Tel:    +1 424 254 5300

        &lt;mailto:iana@iana.org&gt;";

     description
       "This YANG module translates IANA registries 'DNS CLASSes' and
        'Resource Record (RR) TYPEs' to YANG-derived types.

        Copyright (c) 2021 IETF Trust and the persons identified as
        authors of the code.  All rights reserved.

        Redistribution and use in source and binary forms, with or
        without modification, is permitted pursuant to, and subject to
        the license terms contained in, the Simplified BSD License set
        forth in Section 4.c of the IETF Trust's Legal Provisions
        Relating to IETF Documents
        (https://trustee.ietf.org/license-info).

        This version of this YANG module was generated from
        the corresponding IANA registries using an XSLT stylesheet
        from Appendix A of RFC 9108
        (https://www.rfc-editor.org/info/rfc9108); see the RFC itself
        for full legal notices.";

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

     <template name="enum">
       <param name="id"/>
       <value-of select="concat('      enum ', $id)"/>
       <text> {&#xA;        value </text>
       <value-of select="concat(iana:value, ';&#xA;')"/>
       <if test="contains(iana:description, 'OBSOLETE')">
         <text>        status obsolete;&#xA;</text>
       </if>
       <apply-templates select="iana:description"/>
       <variable name="xrefs" select="iana:xref[@type!='note']"/>
       <if test="$xrefs">
         <text>        reference&#xA;          "</text>
         <if test="count($xrefs)&gt;1">- </if>
         <apply-templates select="iana:xref[@type!='note']"/>
       </if>
       <text>      }&#xA;</text>
     </template>

     <template match="/">
       <value-of select="$module-intro"/>
       <apply-templates select="iana:registry[@id='dns-parameters']"/>
       <text>}&#xA;</text>
     </template>

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

     <template match="iana:updated">
       <value-of select="concat('  revision ', ., ' {')"/>
       <text>
       description
         "Initial revision.";
       reference
         "RFC 9108: YANG Types for DNS Classes and Resource Record
          Types";
     }

     /* Typedefs */&#xA;&#xA;</text>
     </template>

     <template match="iana:registry[@id='dns-parameters-2']">
       <text>  typedef dns-class-name {&#xA;</text>
       <text>    type enumeration {&#xA;</text>
       <apply-templates
           select="iana:record[not(iana:description='Unassigned' or
                   starts-with(iana:description,'Reserved'))]"
           mode="class"/>
       <text>    }
       description
         "This enumeration type defines mnemonic names and corresponding
          numeric values of DNS classes.";
       reference
         "RFC 6895: Domain Name System (DNS) IANA Considerations";
     }

     typedef dns-class {
       type union {
         type uint16;
         type dns-class-name;
       }
       description
         "This type allows reference to a DNS class using either the
          assigned mnemonic name or numeric value.";
     }&#xA;&#xA;</text>
     </template>

     <template match="iana:registry[@id='dns-parameters-4']">
       <text>  typedef rr-type-name {&#xA;</text>
       <text>    type enumeration {&#xA;</text>
       <apply-templates
           select="iana:record[iana:type!='Unassigned' and
                   iana:type!='Private use' and iana:type!='Reserved']"
           mode="rr-type"/>
       <text>    }
       description
         "This enumeration type defines mnemonic names and corresponding
          numeric values of DNS resource record types.";
       reference
         "- RFC 6895: Domain Name System (DNS) IANA Considerations

          - RFC 1035: Domain names - implementation and specification";
     }

     typedef rr-type {
       type union {
         type uint16;
         type rr-type-name;
       }
       description
         "This type allows reference to a DNS resource record type
          using either the assigned mnemonic name or numeric value.";
     }&#xA;</text>
     </template>

     <template match="iana:record" mode="class">
       <call-template name="enum">
         <with-param name="id">
           <choose>
             <when test="contains(iana:description,'(')">
               <value-of select="substring-before(substring-after(
                                 iana:description, '('), ')')"/>
             </when>
             <otherwise>
               <value-of
                   select="substring-after(iana:description, ' ')"/>
             </otherwise>
           </choose>
         </with-param>
       </call-template>
     </template>

     <template match="iana:record" mode="rr-type">
       <call-template name="enum">
         <with-param name="id" select="iana:type"/>
       </call-template>
     </template>

     <template match="iana:description">
       <text>        description&#xA;          </text>
       <value-of select="concat($dq, ., $dq, ';&#xA;')"/>
     </template>

     <template match="iana:xref">
       <choose>
         <when test="@type='rfc'">
           <value-of
               select="concat('RFC ', substring-after(@data, 'rfc'))"/>
         </when>
         <when test="@type='person'">
           <apply-templates
               select="/iana:registry/iana:people/iana:person[
                       @id=current()/@data]"/>
         </when>
         <when test="@type='text'">
           <value-of select="translate(., $dq, $sq)"/>
         </when>
         <otherwise>
           <value-of select="@data"/>
         </otherwise>
       </choose>
       <choose>
         <when test="position()=last()">
           <text>";&#xA;</text>
         </when>
         <otherwise>
           <text>&#xA;           - </text>
         </otherwise>
       </choose>
     </template>

     <template match="iana:person">
       <value-of select="concat(iana:name, ' &lt;', iana:uri, '&gt;')"/>
     </template>

   </stylesheet>
   <CODE ENDS>

Authors' Addresses

   Ladislav Lhotka
   CZ.NIC
   Czech Republic

   Email: ladislav.lhotka@nic.cz


   Petr Špaček
   Internet Systems Consortium
   Czech Republic

   Email: pspacek@isc.org

AI ELI5

On this page
PROBLEMManagement tools that use YANG with NETCONF or RESTCONF need a shared way to name DNS classes and resource record types, or every DNS data model must invent its own.
MECHANISMThe YANG module iana-dns-class-rr-type defines the types dns-class and rr-type. Each accepts either a 16-bit number or a mnemonic name taken from the matching IANA registry, and IANA keeps the module in step with those registries.
WHY IT MATTERSFuture DNS data models can import these two types as a common starting point. The document introduces no new protocol, and its security impact is nil on its own.

§1Why DNS Needs YANG Types

YANG is a language for modeling configuration and state data, management operations and notifications. Together with management protocols such as NETCONF and RESTCONF it could be used for DNS operations: configuring authoritative servers, resolvers and zone data.

The RFC argues that the real benefit comes only from a unified data model supported by several DNS implementations. Operators could then run several server implementations in parallel with one management interface, and moving to another implementation would become easier. The authors expect building such models to be lengthy and to need cooperation from the major DNS vendors.

Any such model will need the parameters and enumerations in IANA registries. This RFC translates two fundamental ones into YANG, a step it calls straightforward and relatively uncontroversial.

If every toy company labelled its toy boxes differently, sorting them would be a mess. This document gives everyone the same labels for DNS record kinds.

§2The Module and Its Types

The module is named iana-dns-class-rr-type. At the time of writing, the IANA Domain Name System (DNS) Parameters page held thirteen registries, and the module covers only two: DNS CLASSes and Resource Record (RR) TYPEs. The RFC expects the other registries to be reflected in future modules as needed.

Each registry becomes a YANG enumeration, dns-class-name and rr-type-name. An entry such as IN carries its value (1), a description and a reference (RFC 1035).

The types people actually use are dns-class and rr-type. Each is a union of a uint16 and the matching enumeration. This follows RFC 3597, which allows a class or type to be written by its decimal number, for example CLASS1 for IN or TYPE28 for AAAA.

Unassigned and reserved values are left out of the enumerations, so they can only be given as decimal numbers.

A type can be written as a name or as a number, like calling a friend by name or by their locker number. Values nobody has been given yet only have numbers.

THE RR-TYPE UNION (RFC 9108)
rr-type typedef
typedef rr-type {
  type union {
    type uint16;
    type rr-type-name;
  }
  description
    "This type allows reference to a DNS resource record type
     using either the assigned mnemonic name or numeric value.";
}

§3How IANA Keeps the Module Current

IANA created the initial module by running the XSLT stylesheet in the RFC's appendix against the XML version of the DNS Parameters registry. The latest module is available from the YANG Parameters registry.

When a class or RR type is added to its registry, a new enum statement SHALL be added to the module. Its name is the mnemonic name, and its substatements are set as follows.

  • value: the decimal value from the registry.
  • status: included only if the registration is deprecated or obsoleted, mapping to the YANG statuses deprecated and obsolete.
  • description: the full class name or the meaning of the type, if any.
  • reference: the references from the registry.

Unassigned or reserved values SHALL NOT be included, and each update adds a new revision statement before the existing ones. Changes must be made in the registries, never directly in the module, and IANA added notes saying so to the registries and to the module's entry.

The module has the namespace urn:ietf:params:xml:ns:yang:iana-dns-class-rr-type and the prefix dnsct.

When a new kind of DNS record is added to the official list, IANA must add it to the YANG copy too. Nobody may edit the copy by hand.

§4The XSLT Stylesheet

Appendix A holds an XSLT 1.0 stylesheet that is meant for IANA to generate the first version of the module. It is applied to the XML version of the DNS Parameters registry, for example with xsltproc iana-dns-class-rr-type.xsl dns-parameters.xml.

The stylesheet writes the module header, then an enum for each record of the two registries. It skips unassigned and reserved entries, and marks an entry status obsolete when its description contains the word OBSOLETE. For classes, the name comes from the text in parentheses in the description, when there is any.

The stylesheet is a recipe that turns the official list into the YANG version automatically, so no one has to copy it by hand.

§5Security Considerations

The RFC translates two IANA registries into YANG data types and introduces no technology or protocol. The definitions themselves have no security impact on the Internet, but their use in concrete YANG modules might.

The security considerations in the YANG specification, RFC 7950, apply to this document as well.

This is only a list of names, so it cannot cause harm by itself. Care is needed only when the list is used in real tools.

§6References