idnits 2.17.1 draft-zhang-dns-resolver-yang-00.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 == Line 146 has weird spacing: '...address ine...' == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (September 30, 2016) is 2758 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: 'RFC6241' is mentioned on line 82, but not defined == Unused Reference: 'RFC1034' is defined on line 230, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 234, but no explicit reference was found in the text == Unused Reference: 'RFC6021' is defined on line 243, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6021 (Obsoleted by RFC 6991) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force QF. Zhang 2 Internet Draft Ericsson 3 Intended status: Standards Track September 30, 2016 4 Expires: April 2017 6 Yang Data Model for DNS Resolver Protocol 7 draft-zhang-dns-resolver-yang-00.txt 9 Abstract 11 This document defines a YANG data model that can be used to 12 configure and manage DNS Resolver. 14 Status of this Memo 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft will expire on February 30, 2009. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction...................................................2 55 1.1. Terminology...............................................2 56 1.2. Tree Diagrams.............................................3 57 2. Design of Data Model...........................................3 58 2.1. Overview..................................................3 59 2.2. Resource Record...........................................4 60 3. DNS Resolver YANG Module.......................................4 61 4. Security Considerations........................................6 62 5. IANA Considerations............................................6 63 6. Normative References...........................................6 65 1. Introduction 67 This document defines a YANG [RFC6020] data model for the management 68 of DNS protocol. 70 This data model includes configuration data and state data (status 71 information and counters for the collection of statistics). 73 1.1. Terminology 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 77 "OPTIONAL" in this document are to be interpreted as described in BCP 78 14 [RFC2119]. 80 The following terms are used within this document: 82 The following terms are defined in [RFC6241] and are not redefined 83 here: 85 o client 87 o configuration data 88 o server 90 o state data 92 The following terms are defined in [RFC6020] and are not redefined 93 here: 95 o augment 97 o data model 99 o data node 101 o presence container 103 1.2. Tree Diagrams 105 A simplified graphical representation of the data model is used in 106 this document. The meaning of the symbols in these diagrams is as 107 follows: 109 o Brackets "[" and "]" enclose list keys. 111 o Abbreviations before data node names: "rw" means configuration 112 (read-write), and "ro" means state data (read-only). 114 o Symbols after data node names: "?" means an optional node, "!" 115 means a presence container, and "*" denotes a list and leaf-list. 117 o Parentheses enclose choice and case nodes, and case nodes are also 118 marked with a colon (":"). 120 o Ellipsis ("...") stands for contents of subtrees that are not 121 shown. 123 2. Design of Data Model 125 The goal of this document is to define a data model that provides a 126 common user interface to the DNS Resolver protocol. There is very 127 information that is designated as "mandatory", providing freedom for 128 vendors to adapt this data model to their respective product 129 implementations. 131 2.1. Overview 133 The DNS Resolver YANG module defined in this document is augmented to 134 the DNS resolver, which is defined in RFC7317. 136 2.2. Resource Record 138 In general, we expect a resolver to cache all static hostname-to- 139 IpAddress mapping data. Each static mapping data is one resource 140 record, it contains the hostname and the corresponding IP address. 142 module: ietf-system-dns-resolver 143 augment /sys:system/sys:dns-resolver: 144 +--rw resource-record* [name] 145 +--rw name string 146 +--rw address inet:ip-address 148 3. DNS Resolver YANG Module 150 file "ietf-dns-resolver@2016-09-23.yang" 152 module ietf-system-dns-resolver { 153 yang-version "1"; 155 namespace "urn:ietf:params:xml:ns:yang:ietf-system:dns-resolver"; 156 prefix "dnsres"; 158 import ietf-inet-types { 159 prefix inet; 160 } 162 import ietf-system { 163 prefix sys; 164 } 166 organization 167 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 169 contact 170 "Qifeng Zhang 171 Ericsson (China) Communication Co.,Ltd 172 ET2, No.5 Lize East street, Chaoyang District 173 100102 174 China 175 Phone: +86 13911502387 176 EMail: qifeng.zhang@ericsson.com"; 178 description 179 "This YANG module defines a data model for the configuration of 180 DNS Resolver defined in RFC1035"; 182 revision 2016-09-23 { 183 description 184 "Initial revision."; 185 reference 186 "RFC 1035: DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"; 187 } 189 /* Configuration data */ 191 augment "/sys:system/sys:dns-resolver" { 192 description 193 "Augment dns-resolver to include resource record."; 195 list resource-record { 196 key "name"; 197 description 198 "List of Resource Record entry."; 200 leaf name { 201 type string; 202 description 203 "An arbitrary name for the host."; 204 } 206 leaf address { 207 type inet:ip-address; 208 mandatory true; 209 description 210 "The address of the host."; 211 } 212 } 213 } 214 } 215 217 4. Security Considerations 219 The data model defined does not create any security implications. 221 5. IANA Considerations 223 This draft does not request any IANA action. 225 6. Normative References 227 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 228 Requirement Levels", BCP 14, RFC 2119, March 1997. 230 [RFC1034] P. Mockapetris, "DOMAIN NAMES - CONCEPTS AND FACILITIES", 231 DOI 10.17487/RFC1034, RFC 1034, November 1987, 232 . 234 [RFC1035] P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND 235 SPECIFICATION", DOI 10.17487/RFC1035, RFC 1035, November 236 1987, . 238 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 239 the Network Configuration Protocol (NETCONF)", RFC 6020, 240 DOI 10.17487/RFC6020, October 2010, . 243 [RFC6021] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6021, 244 DOI 10.17487/RFC6021, October 2010, . 247 Authors' Addresses 249 Qifeng Zhang 250 Ericsson (China) Communications Company Ltd. 251 Ericsson Tower, No. 5 Lize East Street, 252 Chaoyang District Beijing 100102, P.R. China 254 Email: qifeng.zhang@ericsson.com