INTERNET-DRAFT Frank Feng Intended Status: Proposed Standard ZTE Xu Ye ZTE Expires: January 15, 2015 September 16, 2014 The mechanism to advertise schema conformance of NETCONF draft-frank-netconf-conformance-00 Abstract This document describes the unified mechanism to advertise schema conformance of the Network Configuration Protocol (NETCONF). Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2014 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 frank Expires December 1, 2014 [Page 1] INTERNET DRAFT conformance advertisement mechanism August 1, 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 3 Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4.1 Conformance Information of Schema . . . . . . . . . . . . . 3 4.2 Protocol Operation . . . . . . . . 4 4.2.1 input . . . . . . . . . . . . . 4 4.2.2 output . . . . . . . . . . . . 4 4.2.3 YANG Tree Diagram . . . . . . . 4 4.2.4 Examples . . . . . . . . . . . 5 4.3 "conformance-id" Capability . . . . . . . . . . . . . . . . 6 4.3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 4.3.1.1 conformance-id Capability Example . . . . . . . . . 7 4.3.2 Dependencies . . . . . . . . . . . . . . . . . . . . . . 7 4.3.3 Capability Identifier . . . . . . . . . . . . . . . . . 7 4.3.4 New Operations . . . . . . . . . . . . . . . . . . . . . 8 4.3.5 Modifications to Existing Operations . . . . . . . . . . 8 4.3.6. Interactions with Other Capabilities . . . . . . . . . 8 4.4 NETCONF-CONFORMANCE YANG Module . . . . . . . . . . . . . . 8 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 12 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1 Normative References . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 frank Expires December 1, 2014 [Page 2] INTERNET DRAFT conformance advertisement mechanism August 1, 2014 1 Introduction There is a need for standard mechanism to advertise schema conformance to allow NETCONF[RFC6241] client to know the conformance information of schemas supported by server. YANG[RFC6020] has already defined its conformance advertisement mechanism, but NETCONF is lack of a unified way to advertise the schema's conformance. 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2 Problem Statement YANG[RFC6020] has already define its conformance advertisement mechanism in section 5.6.4, RFC6020. But it have several problems listed below: 1. YANG is a data model language, it SHOULD NOT define how to advertise conformance information in protocol(e.g. NETCONF). 2. If a server supports over hundreds of YANG modules, the hello message will be very large. 3. client does not need always receive all modules' advertisement in hello message, when it connects to NETCONF server. e.g., the TCP connection is closed and client reconnects to NETCONF server, the information of schema conformance has no any change. 4. schemas not based YANG have no any standard mechanism to advertise their conformance information. So, NETCONF SHOULD provide a standard way to advertise the conformance information of schemas, include YANG and not YANG. 3 Solution o remove the specification about advertisement of model conformance from YANG. This is the Y54 in YANG1.1 issues list. o use conformance-id instead of conformance information of all schemas in NETCONF hello message. o provide a standard RPC called get-schema-conformance for client to get the conformance information when the client wants to know it. 4 Definitions 4.1 Conformance Information of Schema Conformance is a measure of how accurately a device follows the schema. Generally speaking, devices are responsible for implementing the model faithfully, allowing applications to treat devices which implement the model identically. But in real world, devices are often not able or designed to realize all functions defined by frank Expires December 1, 2014 [Page 3] INTERNET DRAFT conformance advertisement mechanism August 1, 2014 schema. In order to avoid conflict, NETCONF server MUST have capability to advertise conformance information. Conformance information can be considered by three parts listed below: o schemas supported by server schemas supported by NETCONF server MUST be advertised when client requests it. The information includes schema's name, revision and namespace. o optional functions supported by server If a schema defined servral optional functions, the server MUST define whether these functions are supported. When client requests it, server MUST advertised all identifiers of functions what server supported. o deviations declared by server In an ideal world, all devices would be required to implement the schema exactly as defined, and deviations from the schema woucld not be allowed. But in the real world, devices are often not able or designed to implement the schema as written. So, In order to keep consistent schemas between client and server, server MUST have capability to declare the deviations from the schema when client request it. The information of deviation SHOULD include the deviated node's path and the detail information of how implementation deviated from schema. 4.2 Protocol Operation This operation allows the client to get server Schemas information. The operation can have filter parameters to get the schemas information which the client concerned. If the operation hasn't any parameter , it indicates that the server SHOULD reply all supported schemas information. 4.2.1 input o filter: A choice indicating the content filter specification for the retrieval request. 4.2.2 output Positive Response: A element is returned which contains the data corresponding to the input parameters specified in the request. The child nodes of the container correspond to Schemas information module. The Schemas information are conformance information of schema which introduced in section 4.1. Negative Response: An response is sent if the request cannot be completed for any reason. 4.2.3 YANG Tree Diagram +--x get-schema-conformance +--ro input | +--ro filter? | +--ro modules | +--ro module* string +--ro output +--ro data frank Expires December 1, 2014 [Page 4] INTERNET DRAFT conformance advertisement mechanism August 1, 2014 +--ro modules +--ro module*[name] +--ro name string +--ro namespace inet:uri +--ro revision string +--ro functions? | +--ro function* string +--ro deviations? +--ro deviation*[target] +--ro target string +--ro deviates +--ro deviate* +--ro type enumeration +--ro information? string 4.2.4 Examples If the client want to get all Schemas information, can send the rpc request below: The positive response by the server like: module1 http://test.com/ns/test1 2014-08-01 function1 function2 module2 http://test.com/ns/test2 2014-08-03 /configuration/ribs/rib not-supported frank Expires December 1, 2014 [Page 5] INTERNET DRAFT conformance advertisement mechanism August 1, 2014 /configuration/ribs/rib-info replace config false If the client want to get the schema information for only concerned module, it can send request with filter parameters, such as: ietf-netconf The response for the request is only the concerned module schema information. 4.3 "conformance-id" Capability 4.3.1 Overview The conformance-id capability indicates that the server maintains a conformance ID for the schemas supported by the server.This identifier value is selected by the server and it will be changed when the conformance information of schemas changes. When the session is created, server MUST send current conformance ID via hello message if server support conformance-id capability. The client SHOULD treat the conformance ID as an opaque string. 1) Client keeps a cache of server schemas information. 2) Server always sends its current conformance-id value in the "conformance-id" URI. frank Expires December 1, 2014 [Page 6] INTERNET DRAFT conformance advertisement mechanism August 1, 2014 Client Server X message +------------------+ +-----------------------------+ | | | conformance-id =1234 | | Server Schemas | <---- | | | Cache | | ... | +------------------+ +------------------------------+ 3) Client checks cache for server X, conformance-id =1234. If found, then OK to use the cached Schemas information copy. If not found, then send a < get-schema-conformance > for the current Schemas information to create or update the cached copy. The server SHOULD save the conformance ID for Schemas information in non-volatile storage. When the server boots or restarts, the initial conformance ID SHOULD be the same as the last instantiation. 4.3.1.1 conformance-id Capability Example # Server starts session 2 with an abbreviated urn:ietf:params:netconf:capability:conformance- id1.0?id=1234 // ... rest of elements 2 4.3.2 Dependencies The conformance-id capability is not dependent on any other capabilities. 4.3.3 Capability Identifier The conformance-id capability is identified by the following capability string: urn:ietf:params:netconf:capability:conformance-id:1.0 This capability MUST be advertised in every server message, if server support this capability. The conformance-id capability URI MUST contain an "id" argument assigned an opaque string value indicating the current conformance ID value for server schemas information. For example: urn:ietf:params:netconf:capability:conformance-id:1.0?id=6882391 The current conformance ID value MUST be updated any time when the server schemas information change. frank Expires December 1, 2014 [Page 7] INTERNET DRAFT conformance advertisement mechanism August 1, 2014 4.3.4 New Operations The conformance-id capability does not introduce any new protocol operations. 4.3.5 Modifications to Existing Operations The conformance-id capability does not modify any existing protocol operations. 4.3.6. Interactions with Other Capabilities The conformance-id capability does not interact with any other capabilities. 4.4 NETCONF-CONFORMANCE YANG Module This module imports the "uri" typedef from module "ietf-inet-types" [RFC 6991]. file "ietf-netconf-conformance@2014-09-16.yang module ietf-netconf-conformance { namespace "urn:ietf:params:xms:ns:yang:ietf-netconf-conformance"; prefix nccon; import ietf-inet-types { prefix "inet"; } organization "IETF NETCONF (Network Configuration Protocol) Working Group"; contact "WG Web: WG List: WG Chair: Bert Wijnen WG Chair: Mehmet Ersue Editor: Frank Feng Editor: Xu Ye "; description "This module contains a collection of YANG definitions for the schema conformance advertisement of a NETCONF server. Copyright (c) 2014 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 frank Expires December 1, 2014 [Page 8] INTERNET DRAFT conformance advertisement mechanism August 1, 2014 Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision 2014-09-16 { description "Initial revision."; } /*Features*/ feature conformance-id { description "The conformance-id capability indicates that the server. maintains a conformance ID for the schemas supported by the server. This identifier value is selected by the server and it will be changed when the conformance information of schemas changes. When the session is created, server MUST send current conformance ID via hello message if server support conformance-id capability. The client SHOULD treat the conformance ID as an opaque string."; } /*RPCs*/ rpc get-schema-conformance { description "This operation allows the client to get server Schemas information. The operation can have filter parameters to get the schemas information which the client concerned. If the operation hasn't any parameter s indicates that the server SHOULD reply all supported schemas information."; input { container filter { description "A choice indicating the content filter specification for the retrieval request."; container modules { leaf-list module { description "The concerned module name list"; type string; } } } } output { container data { description "The schemas conformance information."; container modules { frank Expires December 1, 2014 [Page 9] INTERNET DRAFT conformance advertisement mechanism August 1, 2014 description "The schemas conformance information of all supported modules."; list module { key name; leaf name { description "The supported module name."; type string; } leaf namespace { description "the module's namespace."; type inet:uri; } leaf revision { description "the module's revision date."; type string; } container functions { description "Functions what the module supported."; leaf-list function { description "The functions' name."; type string; } } container deviations { description "All deviation information about this module."; list deviation { description "a deviation declared by module."; key target; leaf target { description "The target node's absolute schema node identifier."; type string; } container deviates { description "All detail information about a deviation." list deviate { description "A detail information about a deviation."; leaf type { description frank Expires December 1, 2014 [Page 10] INTERNET DRAFT conformance advertisement mechanism August 1, 2014 "The deviate type of this deviate. e.g. add"; type enumeration { enum not-supported; enum add; enum replace; enum delete; } } leaf information { description "The detail information of this deviate.e.g. 'default 100;' or 'config true;'"; type string; } } } } } } } } } } } frank Expires December 1, 2014 [Page 11] INTERNET DRAFT conformance advertisement mechanism August 1, 2014 5 Security Considerations TBD. 4 IANA Considerations TBD. 5 References 5.1 Normative References [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, July 2013. Authors' Addresses Frank Feng Nanjing Institute of ZTE Corporation No.68 Zijinghua Rd. Yuhuatai District, Nanjing, China EMail: feng.chong33@zte.com.cn Xu Ye Nanjing Institute of ZTE Corporation No.68 Zijinghua Rd. Yuhuatai District, Nanjing, China EMail: ye.xu1@zte.com.cn frank Expires December 1, 2014 [Page 12]