YANG Schema Mount
draft-ietf-netmod-schema-mount-01
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 8528.
|
|
---|---|---|---|
Authors | Martin Björklund , Ladislav Lhotka | ||
Last updated | 2016-06-27 (Latest revision 2016-04-05) | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Reviews |
GENART Telechat review
(of
-11)
by Joel Halpern
Ready w/issues
GENART Last Call review
(of
-10)
by Joel Halpern
Almost ready
|
||
Additional resources | Mailing list discussion | ||
Stream | WG state | WG Document | |
Document shepherd | Lou Berger | ||
IESG | IESG state | Became RFC 8528 (Proposed Standard) | |
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | "Lou Berger" <lberger@labn.net> |
draft-ietf-netmod-schema-mount-01
Network Working Group M. Bjorklund Internet-Draft Tail-f Systems Intended status: Standards Track L. Lhotka Expires: October 8, 2016 CZ.NIC April 6, 2016 YANG Schema Mount draft-ietf-netmod-schema-mount-01 Abstract This document defines a mechanism to combine YANG modules into the schema defined in other YANG modules. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on October 8, 2016. Copyright Notice Copyright (c) 2016 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 (http://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. Bjorklund & Lhotka Expires October 8, 2016 [Page 1] Internet-Draft YANG Schema Mount April 2016 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 1.1.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . 2 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Schema Mount . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Augment and Validation in Mounted Data . . . . . . . . . 4 3.2. Top-level RPCs . . . . . . . . . . . . . . . . . . . . . 4 3.3. Top-level Notifications . . . . . . . . . . . . . . . . . 5 4. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Schema Mount YANG Module . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 10 Appendix A. Example: Logical Devices . . . . . . . . . . . . . . 11 Appendix B. Example: Network Manager . . . . . . . . . . . . . . 13 B.1. Invoking an RPC . . . . . . . . . . . . . . . . . . . . . 16 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 16 Appendix D. Alternative solutions . . . . . . . . . . . . . . . 16 D.1. Static Mount Points with YANG Library Only . . . . . . . 16 D.2. Dynamic Mount Points with YANG Library Only . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction 1.1. Terminology The keywords "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]. 1.1.1. Tree Diagrams A simplified graphical representation of the data model is used in this document. The meaning of the symbols in these diagrams is as follows: o Brackets "[" and "]" enclose list keys. o Abbreviations before data node names: "rw" means configuration data (read-write) and "ro" state data (read-only). Bjorklund & Lhotka Expires October 8, 2016 [Page 2] Internet-Draft YANG Schema Mount April 2016 o Symbols after data node names: "?" means an optional node, "!" means a presence container, and "*" denotes a list and leaf-list. o Parentheses enclose choice and case nodes, and case nodes are also marked with a colon (":"). o Ellipsis ("...") stands for contents of subtrees that are not shown. 2. Background YANG has two mechanisms for extending a data model with additional nodes; "uses" and "augment". The "uses" statement explicitly incorporates the contents of a "grouping" defined in some other module. The "augment" statement explicitly adds contents to a target node defined in some other module. In both these cases, the source and/or target model explicitly defines the relationship between the models. In some cases these mechanisms are not sufficient. For example, suppose we have a model like ietf-interfaces [RFC7223] that is defined to be implemented in a device. Now suppose we want to model a device that supports multiple logical devices [I-D.rtgyangdt-rtgwg-device-model], where each such logical device has its own instantiation of ietf-interfaces (and other models), but at the same time, we'd like to be able to manage all these logical devices from the main device. We would like something like this: +--rw interfaces | +--rw interface* [name] | ... +--rw logical-device* [name] +--rw name string | ... +--rw interfaces +--rw interface* [name] ... With the "uses" approach, ietf-interfaces would have to define a grouping with all its nodes, and the new model for logical devices would have to use this grouping. This is a not a scalable solution, since every time there is a new model defined, we would have to update our model for logical devices to use a grouping from the new model. Another problem is that this approach cannot handle vendor- specific modules. With the "augment" approach, ietf-interfaces would have to augment the logical-device list with all its nodes, and at the same time Bjorklund & Lhotka Expires October 8, 2016 [Page 3] Internet-Draft YANG Schema Mount April 2016 define all its nodes on the top-level. This approach is also not scalable, since there may be other models to which we would like to add the interface list. 3. Schema Mount The schema mount mechanism defined in this document takes a different approach to the extensibility problem described in the previous section. It decouples the definition of the relation between the source and target models from the definitions of the models themselves. This is accomplished with a YANG extension statement that is used to specify a mount point in a data model. The purpose of a mount point is to define a place in the node hierarchy where other YANG data models may be attached, without any special notation in the other YANG data models. For each mount point supported by a server, the server populates an operational state node hierarchy with information about which models it has mounted. This node hierarchy can be read by a client in order to learn what is implemented on a server. Schema mount applies to the data model, and specifically does not assume anything about how the mounted data is implemented. It may be implemented using the same instrumentation as the rest of the system, or it may be implemented by querying some other system. Future specifications may define mechanisms to control or monitor the implementation of specific mount points. This document allows mounting of complete data models only. Other specifications may extend this model by defining additional mechanisms, for example mounting of sub-hierarchies of a module. 3.1. Augment and Validation in Mounted Data All paths (in leafrefs, instance-identifiers, XPath expressions, and target nodes of augments) in the data models mounted at a mount point are interpreted with the mount point as the root node, and the mounted data nodes as its children. This means that data within a mounted subtree can never refer to data outside of this subtree. 3.2. Top-level RPCs If any mounted data model defines RPCs, these RPCs can be invoked by clients by treating them as actions defined where the mount point is specified. An example of this is given in Appendix B.1. Bjorklund & Lhotka Expires October 8, 2016 [Page 4] Internet-Draft YANG Schema Mount April 2016 quot; maxOccurs="unbounded"/> </sequence> </extension> </complexContent> </complexType> <element name="findOrganizations" type="areg:findOrganizationsType" substitutionGroup="iris:query" /> <!-- --> <!-- Find Networks by Name Server --> <!-- --> <complexType name="findNetworksByNameServerType"> <complexContent> <extension base="iris:queryType"> <sequence> <element name="nameServer" type="normalizedString" /> <element name="returnedResultType" minOccurs="0" maxOccurs="1" > <simpleType> <restriction base="string" > <enumeration value="returnIPv4Networks" /> <enumeration value="returnIPv6Networks" /> </restriction> </simpleType> </element> </sequence> </extension> </complexContent> </complexType> Gunduz, et al. Standards Track [Page 23] RFC 4698 IRIS Address Registry Type October 2006 <element name="findNetworksByNameServer" type="areg:findNetworksByNameServerType" substitutionGroup="iris:query" /> <!-- --> <!-- Contact Search Group --> <!-- --> <group name="contactSearchGroup"> <choice> <element name="commonName" type="areg:exactOrPartialMatchParameter" /> <group ref="areg:commonSearchGroup" /> </choice> </group> <!-- --> <!-- Common Search Group --> <!-- --> <group name="commonSearchGroup"> <choice> <element name="eMail" type="areg:domainResourceParameter" /> <element name="city" type="areg:exactMatchParameter" /> <element name="region" type="areg:exactMatchParameter" /> <element name="country" type="areg:exactMatchParameter" /> <element name="postalCode" type="areg:exactMatchParameter" /> </choice> </group> <!-- --> <!-- Parameters for Search Groups --> <!-- --> <complexType name="exactOrPartialMatchParameter"> <choice> <group ref="areg:partialMatchGroup" /> <group ref="areg:exactMatchGroup" /> </choice> </complexType> <complexType name="exactMatchParameter"> <group ref="areg:exactMatchGroup" /> </complexType> <complexType name="partialMatchParameter"> <sequence> <group ref="areg:partialMatchGroup" /> Gunduz, et al. Standards Track [Page 24] RFC 4698 IRIS Address Registry Type October 2006 </sequence> </complexType> <complexType name="domainResourceParameter" > <choice> <group ref="areg:exactMatchGroup" /> <element name="inDomain" type="token" /> </choice> </complexType> <group name="partialMatchGroup"> <choice> <sequence> <element name="beginsWith"> <simpleType> <restriction base="token"> <minLength value="1"/> </restriction> </simpleType> </element> <element minOccurs="0" ref="areg:endsWith"/> </sequence> <element ref="areg:endsWith" /> </choice> </group> <element name="endsWith"> <simpleType> <restriction base="token"> <minLength value="1"/> </restriction> </simpleType> </element> <group name="exactMatchGroup"> <sequence> <element name="exactMatch" type="normalizedString" /> </sequence> </group> <!-- ========================================= --> <!-- --> <!-- Result Types --> <!-- --> <!-- ========================================= --> <!-- --> <!-- IPv4 and IPv6 Network Results --> Gunduz, et al. Standards Track [Page 25] RFC 4698 IRIS Address Registry Type October 2006 <!-- --> <complexType name="ipNetworkType"> <complexContent> <extension base="iris:resultType"> <sequence> <element name="networkHandle" type="token" minOccurs="0" maxOccurs="1" /> <element name="name" minOccurs="0" maxOccurs="1" type="normalizedString" /> <element name="startAddress" type="token" /> <element name="endAddress" type="token" /> <sequence minOccurs="0" maxOccurs="1"> <element name="networkType" type="normalizedString" minOccurs="1" maxOccurs="1" /> <element name="networkTypeInfo" type="iris:entityType" minOccurs="0" maxOccurs="1" /> 3.3. Top-level Notifications If the server emits a notification defined at the top-level in any mounted data model, it is treated as if the notification was attached to the data node where the mount point is specified. 4. Data Model This document defines the YANG 1.1 module [I-D.ietf-netmod-rfc6020bis] "ietf-yang-schema-mount", which has the following structure: module: ietf-yang-schema-mount +--ro mount-points +--ro mount-point* [module name] +--ro module yang:yang-identifier +--ro name yang:yang-identifier +--ro (data-model) +--:(inline-yang-library) | +--ro inline-yang-library? empty +--:(modules) +--ro modules +--ro module* [name revision] +--ro name yang:yang-identifier +--ro revision union +--ro schema? inet:uri +--ro namespace inet:uri +--ro feature* yang:yang-identifier +--ro deviation* [name revision] | +--ro name yang:yang-identifier | +--ro revision union +--ro conformance-type enumeration +--ro submodules +--ro submodule* [name revision] +--ro name yang:yang-identifier +--ro revision union +--ro schema? inet:uri 5. Schema Mount YANG Module <CODE BEGINS> file "ietf-yang-schema-mount@2016-04-05.yang" module ietf-yang-schema-mount { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount"; prefix yangmnt; import ietf-yang-types { Bjorklund & Lhotka Expires October 8, 2016 [Page 5] Internet-Draft YANG Schema Mount April 2016 prefix yang; } import ietf-yang-library { prefix yanglib; } organization "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; contact "WG Web: <http://tools.ietf.org/wg/netmod/> WG List: <mailto:netmod@ietf.org> WG Chair: Thomas Nadeau <mailto:tnadeau@lucidvision.com> WG Chair: Juergen Schoenwaelder <mailto:j.schoenwaelder@jacobs-university.de> WG Chair: Kent Watsen <mailto:kwatsen@juniper.net> Editor: Martin Bjorklund <mailto:mbj@tail-f.com>"; // RFC Ed.: replace XXXX with actual RFC number and remove this // note. description "This module defines a YANG extension statement that can be used to incorporate data models defined in other YANG modules in a module. It also defines a operational state data so that clients can learn which data models a server implements for the mount points. Copyright (c) 2016 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 (http://trustee.ietf.org/license-info). The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in the module text are to be interpreted as described Bjorklund & Lhotka Expires October 8, 2016 [Page 6] Internet-Draft YANG Schema Mount April 2016 in RFC 2119 (http://tools.ietf.org/html/rfc2119). This version of this YANG module is part of RFC XXXX (http://tools.ietf.org/html/rfcXXXX); see the RFC itself for full legal notices."; // RFC Ed.: update the date below with the date of RFC publication // and remove this note. revision 2016-04-05 { description "Initial revision."; reference "RFC XXXX: YANG Schema Mount"; } /* * Extension statements */ extension mount-point { argument name; description "The argument 'name' is a yang-identifier. The name of the mount point MUST be unique within the module where it is defined. The 'mount-point' statement can be present in 'container' and 'list'. If a mount point is defined in a grouping, its name is bound to the module where the grouping is used. Note that this implies that such a grouping can be used at most once in a module. A mount point defines a place in the node hierarchy where other data models may be attached. A server that implements a module with a mount point, populates the /mount-points/mount-point list with detailed information on which data models are mounted at each mount point. The 'mount-yang-library' extension may be used as a substatement to 'mount-point'."; } extension mount-yang-library { description "The presence of this statement as a substatement to 'mount-point' indicates that the data model defined in the Bjorklund & Lhotka Expires October 8, 2016 [Page 7] Internet-Draft YANG Schema Mount April 2016 module 'ietf-yang-library' is mounted. When this statement is present, a client can discover the mounted YANG modules by reading from the mounted 'ietf-yang-library' data. This statement is useful if the mount point is defined in a list and different list entries may mount a different set of modules."; } /* * Operational state data nodes */ container mount-points { config false; description "Contains information about which mount points are implemented in the server, and their data models."; list mount-point { key "module name"; description "Contains information about which data models are implemented for the mountpoint 'name' defined in 'module'."; leaf module { type yang:yang-identifier; description "The name of the module where the mount point is defined."; } leaf name { type yang:yang-identifier; description "The name of the mount point."; } choice data-model { mandatory true; description "Indicates which data models the server implements for this mount point. It is expected that this choice may be augmented with other data model discovery mechansisms."; leaf inline-yang-library { type empty; description "This leaf indicates that the server has mounted Bjorklund & Lhotka Expires October 8, 2016 [Page 8] Internet-Draft YANG Schema Mount April 2016 'ietf-yang-library' at the mount point, and that the instantiation of 'ietf-yang-library' contains the information about which modules are mounted. This is useful if the mount point is defined in a list and different list entries may mount a different set of modules."; } container modules { description "The 'module' list contains the set of modules that are mounted at the mount point."; uses yanglib:module-list; } } } } } <CODE ENDS> 6. IANA Considerations This document registers a URI in the IETF XML registry [RFC3688]. Following the format in RFC 3688, the following registration is requested to be made. URI: urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. This document registers a YANG module in the YANG Module Names registry [RFC6020]. name: ietf-yang-schema-mount namespace: urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount prefix: yangmnt reference: RFC XXXX 7. Security Considerations TBD Bjorklund & Lhotka Expires October 8, 2016 [Page 9] Internet-Draft YANG Schema Mount April 2016 8. Contributors The idea of having some way to combine schemas from different YANG modules into one has been proposed independently by several groups of people: Alexander Clemm, Jan Medved, and Eric Voit ([I-D.clemm-netmod-mount]); Ladislav Lhotka ([I-D.lhotka-netmod-ysdl]); and Lou Berger and Christian Hopps. 9. References 9.1. Normative References [I-D.ietf-netmod-rfc6020bis] Bjorklund, M., "The YANG 1.1 Data Modeling Language", draft-ietf-netmod-rfc6020bis-11 (work in progress), February 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <http://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, <http://www.rfc-editor.org/info/rfc6020>. 9.2. Informative References [I-D.clemm-netmod-mount] Clemm, A., Medved, J., and E. Voit, "Mounting YANG-Defined Information from Remote Datastores", draft-clemm-netmod- mount-04 (work in progress), March 2016. [I-D.lhotka-netmod-ysdl] Lhotka, L., "YANG Schema Dispatching Language", draft- lhotka-netmod-ysdl-00 (work in progress), November 2015. [I-D.rtgyangdt-rtgwg-device-model] Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps, "Network Device YANG Organizational Models", draft- rtgyangdt-rtgwg-device-model-03 (work in progress), February 2016. Bjorklund & Lhotka Expires October 8, 2016 [Page 10] Internet-Draft YANG Schema Mount April 2016 [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, <http://www.rfc-editor.org/info/rfc6241>. [RFC7223] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, <http://www.rfc-editor.org/info/rfc7223>. [RFC7277] Bjorklund, M., </sequence> <element name="nameServer" type="normalizedString" minOccurs="0" maxOccurs="unbounded" /> <element name="organization" type="iris:entityType" minOccurs="0" maxOccurs="1" /> <choice minOccurs="0" maxOccurs="1" > <element name="parent" type="iris:entityType" /> <element name="noParent"> </element> </choice> <group ref="areg:contactGroup" /> <group ref="areg:commonGroup" /> </sequence> </extension> </complexContent> </complexType> <element name="ipv4Network" type="areg:ipNetworkType" substitutionGroup="iris:result" /> <element name="ipv6Network" type="areg:ipNetworkType" substitutionGroup="iris:result" /> <!-- --> <!-- Autonomous System --> <!-- --> <complexType name="autonomousSystemType"> <complexContent> <extension base="iris:resultType"> <sequence> Gunduz, et al. Standards Track [Page 26] RFC 4698 IRIS Address Registry Type October 2006 <element name="asHandle" type="token" minOccurs="0" maxOccurs="1" /> <element name="asNumberStart" type="integer" minOccurs="0" maxOccurs="1" /> <element name="asNumberEnd" type="integer" minOccurs="0" maxOccurs="1" /> <element name="name" type="normalizedString" minOccurs="0" maxOccurs="1" /> <element name="organization" type="iris:entityType" minOccurs="0" maxOccurs="1" /> <choice minOccurs="0" maxOccurs="1"> <element name="parent" type="iris:entityType" /> <element name="noParent" /> </choice> <group ref="areg:contactGroup" /> <group ref="areg:commonGroup" /> </sequence&"A YANG Data Model for IP Management", RFC 7277, DOI 10.17487/RFC7277, June 2014, <http://www.rfc-editor.org/info/rfc7277>. [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for System Management", RFC 7317, DOI 10.17487/RFC7317, August 2014, <http://www.rfc-editor.org/info/rfc7317>. Appendix A. Example: Logical Devices Logical devices within a device typically use the same set of data models in each instance. This can be modelled with a mount point: module example-logical-devices { namespace "urn:example:logical-devices"; prefix exld; import ietf-yang-schema-mount { prefix yangmnt; } container logical-devices { list logical-device { key name; leaf name { type string; } yangmnt:mount-point logical-device; } } } A server with two logical devices that both implement "ietf-interfaces" [RFC7223], "ietf-ip" [RFC7277], and "ietf-system" [RFC7317] YANG modules might populate the "mount-points" container with: Bjorklund & Lhotka Expires October 8, 2016 [Page 11] Internet-Draft YANG Schema Mount April 2016 <mount-points xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount"> <mount-point> <module>example-logical-devices</module> <name>logical-device</name> <modules> <module> <name>ietf-interface</name> <revision>2014-05-08</revision> <namespace> urn:ietf:params:xml:ns:yang:ietf-interfaces </namespace> <conformance-type>implement</conformance-type> </module> <module> <name>ietf-ip</name> <revision>2014-06-16</revision> <namespace> urn:ietf:params:xml:ns:yang:ietf-ip </namespace> <conformance-type>implement</conformance-type> </module> <module> <name>ietf-system</name> <revision>2014-08-06</revision> <namespace> urn:ietf:params:xml:ns:yang:ietf-system </namespace> <conformance-type>implement</conformance-type> </module> <module> <name>ietf-yang-types</name> <revision>2013-07-15</revision> <namespace> urn:ietf:params:xml:ns:yang:ietf-yang-types </namespace> <conformance-type>import</conformance-type> </module> </modules> </mount-point> </mount-points> and the "logical-devices" container might have: Bjorklund & Lhotka Expires October 8, 2016 [Page 12] Internet-Draft YANG Schema Mount April 2016 <logical-devices xmlns="urn:example:logical-devices"> <logical-device> <name>vrtrA</name> <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"> <interface> <name>eth0</name> <ipv6 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip"> <enabled>true</enabled> ... </ipv6> ... </interface> </interfaces> <system xmlns="urn:ietf:params:xml:ns:yang:ietf-system"> ... </system> </logical-device> <logical-deviceGunduz, et al. Standards Track [Page 27] RFC 4698 IRIS Address Registry Type October 2006 <element name="city" type="string" minOccurs="0" maxOccurs="1" /> <element name="region" type="string" minOccurs="0" maxOccurs="1" /> <element name="postalCode" type="normalizedString" minOccurs="0" maxOccurs="1" /> <element name="country" type="token" minOccurs="0" maxOccurs="1" /> </sequence> </complexType> </element> <element name="phone" minOccurs="0" maxOccurs="unbounded" > <complexType> <sequence> <element name="number" type="normalizedString" /> <element name="extension" type="normalizedString" minOccurs="0" maxOccurs="unbounded" /> <element name="type" type="normalizedString" minOccurs="0" maxOccurs="1" /> </sequence> </complexType> </element> <group ref="areg:commonGroup" /> </sequence> </extension> </complexContent> </complexType> <element name="contact" type="areg:contactType" substitutionGroup="iris:result" /> <!-- --> <!-- Organization --> <!-- --> <complexType name="organizationType"> <complexContent> <extension base="iris:resultType"> <sequence> <element name="name" type="normalizedString" minOccurs="0" maxOccurs="1" /> <element name="eMail" type="normalizedString" minOccurs="0" maxOccurs="unbounded" /> <element name="id" type="token" /> <element name="postalAddress" minOccurs="0" maxOccurs="unbounded"> <complexType> <sequence> Gunduz, et al. Standards Track [Page 28] RFC 4698 IRIS Address Registry Type October 2006 <element name="address" type="string" minOccurs="0" maxOccurs="1" /> <element name="city" type="string" minOccurs="0" maxOccurs="1" /> <element name="region" type="string" minOccurs="0" maxOccurs="1" /> <element name="postalCode" type="normalizedString" minOccurs="0" maxOccurs="1" /> <element name="country" type="token" minOccurs="0" maxOccurs="1" /> </sequence> </complexType> </element> <element name="phone" minOccurs="0" maxOccurs="unbounded" > <complexType> <sequence> <element name="number" type="normalizedString" /> <element name="extension" type="normalizedString" minOccurs="0" maxOccurs="unbounded" /> <element name="type" type="normalizedString" minOccurs="0" maxOccurs="1" /> </sequence> </complexType> </element> <group ref="areg:contactGroup" /> <group ref="areg:commonGroup" /> </sequence> </extension> </complexContent> </complexType> <element name="organization" type="areg:organizationType" substitutionGroup="iris:result" /> <!-- --> <!-- Contact Group --> <!-- --> <group name="contactGroup"> <sequence> <element name="adminContact" type="iris:entityType" minOccurs="0" maxOccurs="unbounded" /> <element name="techContact" type="iris:entityType" minOccurs="0" maxOccurs="unbounded" /> <element name="nocContact" type="iris:entityType" minOccurs="0" maxOccurs="unbounded" /> <element name="abuseContact" type="iris:entityType" minOccurs="0" maxOccurs="unbounded" /> Gunduz, et al. Standards Track [Page 29] RFC 4698 IRIS Address Registry Type October 2006 <element name="otherContact" type="iris:entityType" minOccurs="0" maxOccurs="unbounded" /> </sequence> </group> <!-- --> <!-- Common Group --> <!-- --> <group name="commonGroup"> <sequence> <element name="numberResourceRegistry" type="iris:entityType" minOccurs="0" maxOccurs="1" /> <element name="registrationDate" type="dateTime" minOccurs="0" maxOccurs="1" /> <element name="lastUpdatedDate" type="dateTime" minOccurs="0" maxOccurs="1" /> <element ref="iris:seeAlso" minOccurs="0" maxOccurs="unbounded" /> </sequence> </group> </schema> Figure 9 Gunduz, et al. Standards Track [Page 30] RFC 4698 IRIS Address Registry Type October 2006 6. BEEP Transport Compliance IRIS allows several extensions of the core capabilities. This section outlines those extensions allowable by IRIS-BEEP [3]. 6.1. Message Pattern This registry type uses the default message pattern as described in IRIS-BEEP [3]. 6.2. Server Authentication This registry type uses the default server authentication method as described in IRIS-BEEP [3]. 7. URI Resolution 7.1. Application Service Label See Section 9 for the application service label registration. 7.2. Operational Considerations Address registries do not have natural links to DNS. Using reverse DNS tree presents problems for IP address delegation (for example, delegations do not fall into byte boundaries, unlike reverse DNS), and DNS does not currently contain any information regarding autonomous system delegation. Therefore, in order for the top-down resolution to operate properly, it is requested that the IAB instruct IANA to insert and maintain a NAPTR DNS resource record for areg.iris.arpa, as described in Section 9. 7.3. Top-Down Resolution The top-down alternative resolution method MUST be identified as 'top' in IRIS URIs. The process for this condition is as follows: 1. The IRIS [2] direct-resolution process is tried against areg.iris.arpa. 2. If the direct-resolution process yields no server for which a connection can be made, then a negative response is returned, and no further action is taken. Gunduz, et al. Standards Track [Page 31] RFC 4698 IRIS Address Registry Type October 2006 It is RECOMMENDED that IRIS clients issuing AREG1 requests use the 'top' resolution method when no resolution method has been explicitly given by a user. IRIS servers accepting AREG1 requests that seek information for which they are not authoritative SHOULD refer clients using the 'top' resolution method. 8. Internationalization Considerations This document lays out no new considerations for internationalization beyond those specified in IRIS [2]. 9. IANA Considerations The following URN has been registered with IANA according to the IANA considerations defined in IRIS [2]: urn:ietf:params:xml:ns:areg1 The following S-NAPTR application service label has been registered with IANA according to the IANA considerations defined in IRIS [2]: AREG1 Under instructions from the IAB, the IANA will create a new second level domain under .arpa called iris (i.e., iris.arpa.). The contents of this new domain are to be under the control of the IAB. Under instructions from the IAB, the IANA will insert and maintain a NAPTR DNS resource record in the iris.arpa. domain for the name areg.iris.arpa. The initial contents for that record is: areg.iris.arpa. ;; order pref flags service re replacement IN NAPTR 100 10 "" "AREG1:iris.xpc:iris.lwz" "" areg.nro.net 10. Security Considerations This document lays out no new considerations for security precautions beyond those specified in IRIS [2]. Gunduz, et al. Standards Track [Page 32] RFC 4698 IRIS Address Registry Type October 2006 11. References 11.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Newton, A. and M. Sanz, "IRIS: The Internet Registry Information Service (IRIS) Core Protocol", RFC 3981, January 2005. [3] Newton, A. and M. Sanz, "Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP)", RFC 3983, January 2005. [4] Newton, A., "Cross Registry Internet Service Protocol (CRISP) Requirements", RFC 3707, February 2004. 11.2. Informative References [5] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0", W3C XML, February 1998, <http://www.w3.org/TR/1998/REC-xml-19980210>. [6] World Wide Web Consortium, "Namespaces in XML", W3C XML Namespaces, January 1999, <http://www.w3.org/TR/1999/REC-xml-names-19990114>. [7] World Wide Web Consortium, "XML Schema Part 2: Datatypes", W3C XML Schema, October 2000, <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/>. [8] World Wide Web Consortium, "XML Schema Part 1: Structures", W3C XML Schema, October 2000, <http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/>. [9] International Organization for Standardization, "Codes for the representation of names of countries, 3rd edition", ISO Standard 3166, August 1988. Gunduz, et al. Standards Track [Page 33] RFC 4698 IRIS Address Registry Type October 2006 Appendix A. Privacy Considerations Internet address registries store contact details and other information that may be abused. The XML Schema defined in this document purposefully makes the inclusion of any data in a response an option that is dependent on the needs and policies of the Internet address registry serving the data. Combined with the authentication mechanisms of an IRIS transfer protocol, Internet address registries may derive authorization policies to meet their needs without compromising general privacy policies. As an example, the constituents of an Internet address registry may create a policy whereby NOC contact email addresses are only to be available to members of the Internet address registry. To institute this policy, the XML elements for NOC contacts will never appear in a response to a user that has not been authenticated to be a member of the Internet address registry. Appendix B. Example Requests and Responses The examples in this section use the string "C:" to denote data sent by a client to a server and the string "S:" to denote data sent by a server to a client. B.1. Example 1 The following is an example of entity lookup for the contact-handle of 'JN560-RIR1'. C: <?xml version="1.0"?> C: <request xmlns="urn:ietf:params:xml:ns:iris1" C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" C: xsi:schemaLocation="urn:ietf:params:xml:ns:iris1 iris.xsd" > C: C: <searchSet> C: C: <lookupEntity C: registryType="urn:ietf:params:xml:ns:areg1" C: entityClass="contact-handle" C: entityName="JN560-RIR1" /> C: C: </searchSet> C: C: </request> S: <?xml version="1.0"?> S: <iris:response S: xmlns:iris="urn:ietf:params:xml:ns:iris1" Gunduz, et al. Standards Track [Page 34] RFC 4698 IRIS Address Registry Type October 2006 S: xmlns="urn:ietf:params:xml:ns:areg1" S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> S: S: <iris:resultSet> S: <iris:answer> S: S: <contact S: authority="rir.example.net" S: registryType="areg1" S: entityClass="contact-handle&> <name>vrtrB</name> <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"> <interface> <name>eth0</name> <ipv6 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip"> <enabled>true</enabled> ... </ipv6> ... </interface> </interfaces> <system xmlns="urn:ietf:params:xml:ns:yang:ietf-system"> ... </system> </logical-device> </logical-devices> Appendix B. Example: Network Manager This example shows how a Network Manager application can use schema mount to define a data model with all its managed devices. Schema mount is used to mount the data models each device supports, and these data models can be discovered by a client via the "ietf-yang-library" module that is mounted for each device. module example-network-manager { namespace "urn:example:network-manager"; prefix exnm; Bjorklund & Lhotka Expires October 8, 2016 [Page 13] Internet-Draft YANG Schema Mount April 2016 import ietf-inet-types { prefix inet; } import ietf-yang-schema-mount { prefix yangmnt; } container managed-devices { description "The managed devices and device communication settings."; list device { key name; leaf name { type string; } container transport { choice protocol { mandatory true; container netconf { leaf address { type inet:ip-address; mandatory true; } container authentication { // ... } } container restconf { leaf address { type inet:ip-address; mandatory true; } // ... } } } container root { yangmnt:mount-point managed-device { yangmnt:mount-yang-library; } } } } } The "devices" container might have: Bjorklund & Lhotka Expires October 8, 2016 [Page 14] Internet-Draft YANG Schema Mount April 2016 <devices xmlns="urn:example:network-manager"> <device> <name>rtrA</name> <transport> <netconf> <address>192.0.2.2</address> <authentication> ... </authentication> ... </netconf> </transport> <root> <modules-state xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library"> <module> <name>ietf-system</name> ... </module> </modules-state> <system xmlns="urn:ietf:params:xml:ns:yang:ietf-system"> ... </system> </root> </device> <device> <name>rtrB</name> <transport> <restconf> <address>192.0.2.3</address> <authentication> ... </authentication> ... </restconf> </transport> <root> <modules-state xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library"> <module> <name>ietf-interfaces</name> ... </module> </modules-state> <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"> ... </interfaces> Bjorklund & Lhotka Expires October 8, 2016 [Page 15] Internet-Draft YANG Schema Mount April 2016 </root> </device> " S: entityName="JN560-RIR1"> S: S: <contactHandle>JN560-RIR1</contactHandle> S: S: <commonName>Bob Smurd</commonName> S: S: <organization S: iris:referentType="organization" S: authority="rir.example.net" S: registryType="areg1" S: entityClass="organization-id" S: entityName="ORGX"> S: <iris:displayName S: language="en"> S: Organization X, Inc. S: </iris:displayName> S: </organization> S: S: <phone> S: <number>+1-703-555-5555</number> S: <type>office</type> S: </phone> S: S: </contact> S: S: </iris:answer> S: </iris:resultSet> S: S: </iris:response> Figure 11: Example 1 Gunduz, et al. Standards Track [Page 35] RFC 4698 IRIS Address Registry Type October 2006 B.2. Example 2 The following example shows a query to find the IP networks containing a given address. C: <?xml version="1.0"?> C: <request xmlns="urn:ietf:params:xml:ns:iris1" C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> C: C: <searchSet> C: <findNetworksByAddress C: xmlns="urn:ietf:params:xml:ns:areg1"> C: C: <ipv4Address> C: <start>192.0.2.134</start> C: </ipv4Address> C: C: <specificity C: allowEquivalences="true" C: >one-level-less-specific</specificity> C: C: </findNetworksByAddress> C: </searchSet> C: C: </request> S: <?xml version="1.0"?> S: <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1" S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> S: S: <iris:resultSet> S: <iris:answer> S: <areg:ipv4Network S: xmlns="urn:ietf:params:xml:ns:areg1" S: xmlns:areg="urn:ietf:params:xml:ns:areg1" S: xsi:schemaLocation="urn:ietf:params:xml:ns:areg1 areg.xsd" S: authority="rir.example.net" registryType="areg1" S: entityClass="ipv4-handle" entityName="NET-192-0-2-128-1" > S: <networkHandle> S: NET-192-0-2-128-1 S: </networkHandle> S: <name> S: UU-192-0-2-D6 S: </name> S: <startAddress> S: 192.0.2.128 S: </startAddress> S: <endAddress> Gunduz, et al. Standards Track [Page 36] RFC 4698 IRIS Address Registry Type October 2006 S: 192.0.2.255 S: </endAddress> S: <networkType>reassigned</networkType> S: <organization S: iris:referentType="areg:organization" S: authority="rir.example.net" registryType="areg1" S: entityClass="organization-id" entityName="ORGX"> S: <iris:displayName language="en"> S: Organization X, Inc. S: </iris:displayName> S: </organization> S: <parent S: iris:referentType="areg:ipv4Network" S: authority="rir.example.net" registryType="areg1" S: entityClass="ipv4-handle" entityName="NET-192-0-2-0-1"/> S: <techContact S: iris:referentType="areg:contact" S: authority="rir.example.net" registryType="areg1" S: entityClass="contact-handle" entityName="JN560-RIR1"> S: <iris:displayName language="en"> S: Smurd, Bob S: </iris:displayName> S: </techContact> S: <registrationDate> S: 2002-11-18T00:00:00-00:00 S: </registrationDate> S: <lastUpdatedDate> S: 2002-11-18T00:00:00-00:00 S: </lastUpdatedDate> S: <iris:seeAlso S: iris:referentType="ANY" S: authority="rir.example.net" registryType="areg1" S: entityClass="local" entityName="portability-notice"/</devices> B.1. Invoking an RPC A client that wants to invoke the "restart" operation [RFC7317] on the managed device "rtrA" over NETCONF [RFC6241] can send: <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <action xmlns="urn:ietf:params:xml:ns:yang:1"> <managed-devices xmlns="urn:example:network-manager"> <device> <name>rtrA</name> <system xmlns="urn:ietf:params:xml:ns:yang:ietf-system"> <restart/> </system> </device> </managed-devices> </action> </rpc> Appendix C. Open Issues o Is there a use case for specifying modules that are required to be mounted under a mount point? o Do we really need the case where ietf-yang-library is not mounted? The solution would be simpler if we always use ietf-yang-library at every mount point. See Appendix D.1. o Support non-named mount points? (ysdl case) See Appendix D.2. Appendix D. Alternative solutions This section discusses some alternative solution ideas. D.1. Static Mount Points with YANG Library Only This solution supports named mount points, and always use ietf-yang- library. There would be just one single extension statement, and no additional operational state data: Bjorklund & Lhotka Expires October 8, 2016 [Page 16] Internet-Draft YANG Schema Mount April 2016 extension mount-point { argument name; } Data models need to be prepared with this extension: container logical-devices { list logical-device { key name; ... yangmnt:mount-point logical-device; } } The tree on the server from Appendix A would look like this: "example-logical-devices:logical-devices": { "logical-device": [ { "name": "vrtrA", "ietf-yang-library:modules-state": { "module-set-id": "ef50fe1", "module": [ { "name": "ietf-interfaces", ... }, { "name": "ietf-system", ... } ] }, "ietf-interfaces:interfaces": { ... }, "ietf-system:system": { ... } }, { "name": "vrtrB", "ietf-yang-library:modules-state": { ... } } ] } Bjorklund & Lhotka Expires October 8, 2016 [Page 17] Internet-Draft YANG Schema Mount April 2016 D.2. Dynamic Mount Points with YANG Library Only This solution supports only non-named mount points, and always use ietf-yang-library. There would be no extension statement. Instead, the server would populate a list of dynamic mount points. Each such mount point MUST mount ietf-yang-library. container mount-points { config false; list mount-point { key path; leaf path { type schema-node-path; } } } The tree on the server from Appendix A would look like this: Bjorklund & Lhotka Expires October 8, 2016 [Page 18] Internet-Draft YANG Schema Mount April 2016 "ietf-yang-schema-mount:mount-points": { "mount-point": [ { "path": "/exld:logical-devices/exld:logical-device" } ] }, "example-logical-devices:logical-devices": { "logical-device": [ { "name": "vrtrA", "ietf-yang-library:modules-state": { "module-set-id": "ef50fe1", "module": [ { "name": "ietf-interfaces", ... }, { "name": "ietf-system", ... } ] }, "ietf-interfaces:interfaces": { ... }, "ietf-system:system": { ... } }, { "name": "vrtrB", "ietf-yang-library:modules-state": { ... } } ] } A client needs to read the "/mount-points/mount-point" list in order to learn where the server has mounted data models. Next, it needs to read the "modules-state" subtree for each instantiated mount point in order to learn which modules are mounted at that instance. Authors' Addresses Bjorklund & Lhotka Expires October 8, 2016 [Page 19] Internet-Draft YANG Schema Mount April 2016 Martin Bjorklund Tail-f Systems Email: mbj@tail-f.com Ladislav Lhotka CZ.NIC Email: mbj@lhotka@nic.cz Bjorklund & Lhotka Expires October 8, 2016 [Page 20]