idnits 2.17.1 draft-ietf-dnsop-iana-class-type-yang-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (4 June 2021) is 1057 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC6895' is mentioned on line 265, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 265, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-DNS-PARAMETERS' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-YANG-PARAMETERS' -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP Working Group L. Lhotka 3 Internet-Draft CZ.NIC 4 Intended status: Standards Track P. Spacek 5 Expires: 6 December 2021 Internet Systems Consortium 6 4 June 2021 8 YANG Types for DNS Classes and Resource Record Types 9 draft-ietf-dnsop-iana-class-type-yang-04 11 Abstract 13 This document introduces the YANG module "iana-dns-class-rr-type" 14 that contains derived types reflecting two IANA registries: DNS 15 CLASSes and Resource Record (RR) TYPEs. These YANG types are 16 intended as a minimum basis for future data modeling work. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on 6 December 2021. 35 Copyright Notice 37 Copyright (c) 2021 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. Code Components 45 extracted from this document must include Simplified BSD License text 46 as described in Section 4.e of the Trust Legal Provisions and are 47 provided without warranty as described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. YANG Design Considerations . . . . . . . . . . . . . . . . . 3 54 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 55 4.1. URI Registrations . . . . . . . . . . . . . . . . . . . . 6 56 4.2. YANG Module Registrations . . . . . . . . . . . . . . . . 6 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 58 6. Normative References . . . . . . . . . . . . . . . . . . . . 7 59 7. Informative References . . . . . . . . . . . . . . . . . . . 8 60 Appendix A. XSLT Stylesheet . . . . . . . . . . . . . . . . . . 8 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 63 1. Introduction 65 YANG [RFC7950] has become a de facto standard as a language for 66 modeling configuration and state data, as well as specifying 67 management operations and asynchronous notifications. It is 68 reasonable to expect that the approach based on utilizing such data 69 models along with standard management protocols such as 70 NETCONF [RFC6241] and RESTCONF [RFC8040] can be effectively used in 71 DNS operations, too. In fact, several efforts are currently underway 72 that attempt to use NETCONF or RESTCONF for configuring and managing 74 * authoritative servers 76 * resolvers 78 * zone data. 80 While it is possible to use the management protocols mentioned above 81 with ad hoc or proprietary data models, their real potential can be 82 realized only if there is a (completely or partly) unified data model 83 supported by multiple DNS software implementations. Operators can 84 then, for instance, run several DNS server implementations in 85 parallel, and use a common configuration and management interface and 86 data for all of them. Also, it becomes considerably easier to 87 migrate to another implementation. 89 Based on the previous experience from the IETF Routing Area, it is to 90 be expected that the development of unified data models for DNS will 91 be a lengthy and complicated process that will require active 92 cooperation and compromises from the vendors and developers of major 93 DNS server platforms. Nevertheless, it is likely that any DNS- 94 related data modeling effort will need to use various DNS parameters 95 and enumerations that are specified in several IANA registries. For 96 use with YANG, these parameters and enumerations have to be 97 translated into corresponding YANG types or other structures. Such 98 translations should be straightforward and relatively 99 uncontroversial. 101 This document provides a translation of two fundamental DNS-related 102 IANA registries to YANG. It contains the initial revision of the 103 YANG module "iana-dns-class-rr-type" that defines derived types for 104 the common parameters of DNS resource records (RR): class and type. 105 These YANG types, "dns-class" and "rr-type", reflect the IANA 106 registries "DNS CLASSes" and "Resource Record (RR) TYPEs" 107 [IANA-DNS-PARAMETERS]. 109 Appendix A contains an XSLT 1.0 stylesheet that is intended to be 110 used by IANA for generating the initial revision of the "iana-dns- 111 class-rr-type" YANG module. Subsequently, whenever a new class or RR 112 type is added to the above registries, IANA will also update the 113 "iana-dns-class-rr-type" YANG module, following the instructions in 114 Section 4 below. 116 2. Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 120 "OPTIONAL" in this document are to be interpreted as described in 121 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 122 capitals, as shown here. 124 The terminology for describing YANG data models can be found in 125 [RFC7950]. DNS terminology used in this document can be found in 126 [RFC1035] and [RFC8499]. 128 3. YANG Design Considerations 130 At the time of writing, the IANA document "Domain Name System (DNS) 131 Parameters" [IANA-DNS-PARAMETERS] contains altogether thirteen 132 registries. The YANG module "iana-dns-class-rr-type" defines derived 133 types corresponding to only two of the registries that are essential 134 for data models involving zone data, namely "DNS CLASSes" and 135 "Resource Record (RR) TYPEs". It is expected that the remaining 136 registries in [IANA-DNS-PARAMETERS], as well as other DNS-related 137 IANA registries, will be analogously reflected in future YANG modules 138 as necessary. This way, an appropriate combination of YANG modules 139 can be chosen depending on which YANG types are needed for a given 140 data modeling purpose. 142 The registries "DNS CLASSes" and "Resource Record (RR) TYPEs" are 143 transformed into YANG enumeration types "dns-class-name" and "rr- 144 type-name", respectively. This is the initial fragment of the 145 former: 147 typedef dns-class-name { 148 type enumeration { 149 enum IN { 150 value 1; 151 description 152 "Internet (IN)"; 153 reference 154 "RFC 1035"; 155 } 156 ... 157 } 158 ... 159 } 161 The other derived type, "rr-type-name", is defined similarly. 163 [RFC3597] introduced the option of specifying a class or RR type via 164 its assigned decimal number, as an alternative to the mnemonic name. 165 For example, the "IN" class can be equivalently written as "CLASS1", 166 and "AAAA" type can be written as "TYPE28". 168 Accordingly, the derived types "dns-class" and "rr-type" are defined 169 in the YANG module as a union of two member types: 171 * 16-bit decimal integer ("uint16") 173 * mnemonic name belonging to the enumerations "dns-class-name" and 174 "rr-type-name", respectively. 176 For instance, the "rr-type" type is defined as follows: 178 typedef rr-type { 179 type union { 180 type uint16; 181 type rr-type-name; 182 } 183 description 184 "This type allows for referring to a DNS resource record type 185 using either the assigned mnemonic name or numeric value."; 186 } 188 As unassigned and reserved class and RR type values are not included 189 in the mnemonic name enumerations, they can only be specified using 190 their decimal values. 192 4. IANA Considerations 194 RFC Editor: In this section, replace all occurrences of "XXXX" with 195 the actual RFC number (and remove this note). 197 This section deals with actions and processes necessary for IANA to 198 undertake to maintain the "iana-dns-class-rr-type" YANG module. This 199 YANG module is intended to reflect the "DNS CLASSes" and "Resource 200 Record (RR) TYPEs" registries in [IANA-DNS-PARAMETERS]. The most 201 recent revision of the YANG module is available from the "YANG 202 Parameters" registry [IANA-YANG-PARAMETERS]. 204 Upon publication of this document, the initial revision of the "iana- 205 dns-class-rr-type" YANG module SHALL be created by applying the XSLT 206 stylesheet from Appendix A to the XML version of 207 [IANA-DNS-PARAMETERS]. 209 IANA SHALL add this note to the "iana-dns-class-rr-type" item of the 210 "YANG Module Names" registry [IANA-YANG-PARAMETERS]: 212 | Classes and types of DNS resource records must not be directly 213 | added to the "iana-dns-class-rr-type" YANG module. They must 214 | instead be added to the "DNS CLASSes" and "Resource Record (RR) 215 | TYPEs" registries, respectively. 217 When a new DNS class or RR type is added to the "DNS CLASSes" or 218 "Resource Record (RR) TYPEs" registry, a new "enum" statement SHALL 219 be added to the "dns-class-name" or "rr-type-name" type, 220 respectively. The assigned name defined by the "enum" statement 221 SHALL be the same as the mnemonic name of the new class or type. The 222 following substatements to the "enum" statement SHALL be defined: 224 "value": Use the decimal value from the registry. 226 "status": Include only if a class or type registration has been 227 deprecated or obsoleted. In both cases, use the value "obsolete" 228 as the argument of the "status" statement. 230 "description": Replicate the corresponding information from the 231 registry, namely the full name of the new DNS class, or the 232 meaning of the new RR type, if any. 234 "reference": Replicate the reference(s) from the registry. 236 Unassigned or reserved values SHALL NOT be included in the "dns- 237 class-name" and "rr-type-name" enumeration types. 239 Each time the "iana-dns-class-rr-type" YANG module is updated, a new 240 "revision" statement SHALL be added before the existing "revision" 241 statements. 243 IANA SHALL add this new note to the "DNS CLASSes" and "Resource 244 Record (RR) TYPEs" registries: 246 | When this registry is modified, the YANG module "iana-dns-class- 247 | rr-type" must be updated as defined in RFC XXXX. 249 The "Reference" text in the "DNS CLASSes" registry SHALL be updated 250 as follows: 252 | OLD: 253 | [RFC6895] 254 | 255 | NEW: 256 | [RFC6895][RFCXXXX] 258 The "Reference" text in the "Resource Record (RR) TYPEs" registry 259 SHALL be updated as follows: 261 | OLD: 262 | [RFC6895][RFC1035] 263 | 264 | NEW: 265 | [RFC6895][RFC1035][RFCXXXX] 267 4.1. URI Registrations 269 This document registers a URI in the "IETF XML Registry" [RFC3688]. 270 The following registration has been made: 272 | URI: urn:ietf:params:xml:ns:yang:iana-dns-class-rr-type 273 | Registrant Contact: The IESG. 274 | XML: N/A, the requested URI is an XML namespace. 276 4.2. YANG Module Registrations 278 This document registers a YANG module in the "YANG Module Names" 279 registry [RFC6020]. The following registration has been made: 281 | name: iana-dns-class-rr-type 282 | namespace: urn:ietf:params:xml:ns:yang:iana-dns-class-rr-type 283 | prefix: dnsct 284 | reference: RFC XXXX 286 5. Security Considerations 288 This document translates two IANA registries into YANG data types and 289 otherwise introduces no technology or protocol. The definitions 290 themselves have no security impact on the Internet, but their use in 291 concrete YANG modules might have. The security considerations 292 spelled out in the YANG specification [RFC7950] apply for this 293 document as well. 295 6. Normative References 297 [IANA-DNS-PARAMETERS] 298 Internet Assigned Numbers Authority, "Domain Name System 299 (DNS) Parameters", 300 . 302 [IANA-YANG-PARAMETERS] 303 Internet Assigned Numbers Authority, "YANG Parameters", 304 . 306 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 307 Requirement Levels", BCP 14, RFC 2119, 308 DOI 10.17487/RFC2119, March 1997, 309 . 311 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 312 DOI 10.17487/RFC3688, January 2004, 313 . 315 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 316 the Network Configuration Protocol (NETCONF)", RFC 6020, 317 DOI 10.17487/RFC6020, October 2010, 318 . 320 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 321 RFC 7950, DOI 10.17487/RFC7950, August 2016, 322 . 324 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 325 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 326 May 2017, . 328 [W3C.REC-xslt-19991116] 329 Clark, J., "XSL Transformations (XSLT) Version 1.0", World 330 Wide Web Consortium Recommendation REC-xslt-19991116, 16 331 November 1999, 332 . 334 7. Informative References 336 [RFC1035] Mockapetris, P., "Domain names - implementation and 337 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 338 November 1987, . 340 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 341 (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 342 2003, . 344 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 345 and A. Bierman, Ed., "Network Configuration Protocol 346 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 347 . 349 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 350 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 351 . 353 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 354 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 355 January 2019, . 357 Appendix A. XSLT Stylesheet 359 RFC Editor: In this section, replace all occurrences of "XXXX" with 360 the actual RFC number (and remove this note). 362 This appendix contains an XSLT 1.0 stylesheet [W3C.REC-xslt-19991116] 363 that is intended to be used for generating the initial revision of 364 the "iana-dns-class-rr-type" YANG module. This is achieved by 365 applying the stylesheet to the XML version of the IANA registry 366 "Domain Name System (DNS) Parameters" [IANA-DNS-PARAMETERS] that was 367 current at the time when this document was published. 369 Using the ubiquitous xsltproc tool, the YANG module text can be 370 generated with this command: 372 $ xsltproc iana-dns-class-rr-type.xsl dns-parameters.xml 374 file "iana-dns-class-rr-type.xsl" 375 376 379 380 382 " 383 ' 385 386 module iana-dns-class-rr-type { 387 yang-version 1.1; 388 namespace 389 "urn:ietf:params:xml:ns:yang:iana-dns-class-rr-type"; 390 prefix dnsct; 392 organization 393 "Internet Assigned Numbers Authority (IANA)"; 395 contact 396 " Internet Assigned Numbers Authority 398 Postal: ICANN 399 4676 Admiralty Way, Suite 330 400 Marina del Rey, CA 90292 402 Tel: +1 310 823 9358 404 <mailto:iana@iana.org>"; 406 description 407 "This YANG module translates IANA registries 'DNS CLASSes' and 408 'Resource Record (RR) TYPEs' to YANG derived types. 410 Copyright (c) 2020 IETF Trust and the persons identified as 411 authors of the code. All rights reserved. 413 Redistribution and use in source and binary forms, with or 414 without modification, is permitted pursuant to, and subject to 415 the license terms contained in, the Simplified BSD License set 416 forth in Section 4.c of the IETF Trust's Legal Provisions 417 Relating to IETF Documents 418 (https://trustee.ietf.org/license-info). 420 This initial version of this YANG module was generated from 421 the corresponding IANA registries using an XSLT stylesheet 422 from Appendix A of RFC XXXX 423 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 424 for full legal notices."; 426 reference 427 "IANA 'Domain Name System (DNS) Parameters' registry 428 https://www.iana.org/assignments/dns-parameters"; 429 430 432 450 456 464 477 503 532 549 555 560 588 592 593 595 Authors' Addresses 597 Ladislav Lhotka 598 CZ.NIC 599 Czech Republic 601 Email: ladislav.lhotka@nic.cz 603 Petr Spacek 604 Internet Systems Consortium 605 Czech Republic 607 Email: pspacek@isc.org