NETCONF B. Zhang Internet-Draft Z. Yang Intended status: Experimental Beijing University of Posts and Expires: September 1, 2009 Telecommunications Y. Li Huawei Technologies February 28, 2009 The Extension of Subtree Filtering of NETCONF draft-zhang-netconf-subtree-00 Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 1, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the Zhang, et al. Expires September 1, 2009 [Page 1] Internet-Draft NETCONF Subtree Filtering Extensions February 2009 document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract The NETCONF protocol defines a subtree filtering mechanism to allow an client to select particular XML subtrees to be included in the for a or operation. In some aspects, subtree filtering has some disadvantages. This document defines an extended subtree filtering to solve these disadvantages. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Disadvantages of Current Subtree Filtering . . . . . . . . . . 3 2.1. Lack of Flexibility in the Way of Match . . . . . . . . . 3 2.2. Inconvenient Path Mechanism . . . . . . . . . . . . . . . 3 2.3. Simplex Logic Relation . . . . . . . . . . . . . . . . . . 3 2.4. Unable to Query the Number of Certain Nodes . . . . . . . 4 3. The Extended Subtree Filtering . . . . . . . . . . . . . . . . 4 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. New Functions . . . . . . . . . . . . . . . . . . . . . . 4 3.2.1. Fuzzy Match . . . . . . . . . . . . . . . . . . . . . 4 3.2.2. Relative Path . . . . . . . . . . . . . . . . . . . . 5 3.2.3. Logic Relation . . . . . . . . . . . . . . . . . . . . 6 3.2.4. Querying the Number of Certain Nodes . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 7. Normative References . . . . . . . . . . . . . . . . . . . . . 11 Zhang, et al. Expires September 1, 2009 [Page 2] Internet-Draft NETCONF Subtree Filtering Extensions February 2009 1. Introduction The NETCONF [RFC4741] protocol defines a subtree filtering mechanism to allow an client to select particular XML [refs.xml] subtrees to be included in the for a or operation. In some aspects, subtree filter has some disadvantages. Such as lack of flexibility in the way of match, inconvenient path mechanism, simplex logic relation between content match nodes and unable to query the number of a kind of nodes and so on. This document defines an extended subtree filtering which provides several new functions to optimize the subtree filtering in the NETCONF protocol. 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. Disadvantages of Current Subtree Filtering 2.1. Lack of Flexibility in the Way of Match According to the NETCONF protocol, the filter must exactly match the server's data model. In other words, the information of every node in the filter including the name, content, namespace and attributes of the node must exactly match that in the server's data model. If a user only knows a part of information of a node, some querying requirements is able not to be done. For example, in the NETCONF protocol the subtree filtering includes a component called "attribute match expressions". In the filter if a node includes an attribute, it must include both the name and value of the attribute. So the subtree filtering can not work if the user want to query the node includes atrribute when he only knows the name or the value of the attribute. 2.2. Inconvenient Path Mechanism For the current subtree filtering, the path in the filter must be "absolute path", which means that the filter must have the same root node as the data model and other elements in the filter must include all the ancestors from the root node of the data model to themselves. If the user wants to query a node information, he must know the absolute path of this node in the data model, which is very inconvenient for him. 2.3. Simplex Logic Relation In the filter, an element node can include more than one attribute, and a containment node can include more than one content match node. For the current subtree filtering, the logic relation of these Zhang, et al. Expires September 1, 2009 [Page 3] Internet-Draft NETCONF Subtree Filtering Extensions February 2009 attributes or these content match nodes only includes "AND". There is no other useful logic relation such as "OR" or "NOT". So the subtree filtering can't work if the user wants to query a node including an attribute or another one, or he wants to query a node not including some attribute. 2.4. Unable to Query the Number of Certain Nodes Sometimes the user maybe want to query the number of a kind of nodes in the data model, but the current subtree filtering can't do that. 3. The Extended Subtree Filtering 3.1. Overview For the shortcomings of the subtree filtering, a new extended subtree filtering is defined in this document. Correspondingly, the node in the subtree filter is replaced by a new node . This new mechanism provides several new functions to optimize the subtree filtering in the NETCONF protocol, such as fuzzy match, relative path, new logic relation, and querying the number of certain nodes. They will be introduced one by one in detail as follows. 3.2. New Functions 3.2.1. Fuzzy Match 3.2.1.1. Description The fuzzy match means that in the process of subtree filtering the server processes the character string match including the name, the content, the attributes and the namespace of the node in a way of wildcard match. That is to say, the filter can include the partial information of a node. 3.2.1.2. New Definition and How to Use Two wildcards are allowed to be used in subtree filtering. o '*' Matches any character string within an element value and an attribute value, including a namespace attribute value. o '_' Matches any character string within an element name and an attribute name, not including a namespace attribute name, i.e. 'xmlns'. Zhang, et al. Expires September 1, 2009 [Page 4] Internet-Draft NETCONF Subtree Filtering Extensions February 2009 3.2.1.3. Examples of Fuzzy Match For example, query an node with an attribute whose value is known but name is unknown. In this example, an attribute match expression contains the wildcard '_', as a result, the node whose any attributes have the value "eth0" will be included in the filter output. In the next example, the filter select nodes whose MAC address starts with "0006G", the wildcard '*' will be used. 0006G* Output: eth0 0006GG93KAG8 ... 3.2.2. Relative Path 3.2.2.1. Description In the NETCONF protocol, the subtree filtering adopts absolute path filtering, which means that the filter must have the same root node as the data model and other elements in the filter must include all the ancestors from the root of the data model to themselves. In Zhang, et al. Expires September 1, 2009 [Page 5] Internet-Draft NETCONF Subtree Filtering Extensions February 2009 order to improve the flexibility of the filtering, this document defines a new mechanism called relative path, by this the filter may not include all the ancestors from the root of the data model to the selected node. But the output will include all the ancestors of the selected node and itself. 3.2.2.2. New Definition and How to Use In the node , a new attribute is defined whose name is "_nodepath", and this attribute has only two values: "absolute" and "relative", which represent absolute path filtering and relative path filtering respectively. In the default situation, the filter without _nodepath attribute, that means absolute path filtering. If the filter has _nodepath attribute and its value is "relative", this means relative path filtering. 3.2.2.3. Examples of Relative Path For example, the user wants to query the node in the data model, but he doesn't know the absolute path. In this case, he can use relative path filtering, the filter is as follows: the output is as follows: ... ... The output includes two nodes and it also includes the ancestors of the two nodes. 3.2.3. Logic Relation 3.2.3.1. Description In the subtree filtering mechanism, more than one attribute can be included in an element node in the filter and more than one content match node can be included in a containment node. The relationship among these attributes or content match nodes is "AND" but not "OR" Zhang, et al. Expires September 1, 2009 [Page 6] Internet-Draft NETCONF Subtree Filtering Extensions February 2009 or "NOT". In order to improve the flexibility of setting the conditions of the filter, two other logic relation: "OR" and "NOT" are imported in this document 3.2.3.2. New Definition and How to Use The attribute of a node and the content match node have different ways to express the logic relation. For the element in the filter which has more than one attribute, this document defines an attribute called "attrLogic" to express the logic relation of the attributes of the element. The value of this attribute is composed of the other names of attributes of the element. And the symbols "^", "||" and "!" are used to express "AND", "OR" and "NOT" logic relation respectively. For the content match node, this document defines an attribute "_matchType" to express the logic relation among the content match nodes. It has three values: "must", "may" and "not" which represent "AND", "OR" and "NOT" logic relation respectively. 3.2.3.3. Examples of Logic Relation This is an example of "OR" relation of attributes. Output: ... ... In this example, the NETCONF client wants to query the node which include attribute ifName="eth0" or ipAddress="192.168.2.1", so the result includes the node which includes an attribute ifName="eth0" and another node which includes an attribute ipAddress="192.168.2.1". If the user wants to query the node which include not only Zhang, et al. Expires September 1, 2009 [Page 7] Internet-Draft NETCONF Subtree Filtering Extensions February 2009 the attribute ifName="eth0" but also the attribute ipAddress="192.168.2.1", he has to change the attribute _attrLogic="ifName||ipAddress" to _attrLogic="ifName^ipAddress". If the node in the filter is set as follows: , this means to select the node without the attribute ifName="eth0". This is an example of "OR" relation of content match nodes. eth0 498 This example shows how to select the node which can include the node eth0 or 498. The output is as follows: eth0 6789 ... eth1 498 ... In the output, there are two nodes. One has a child node eth0 and another one has a child node 498. If the user wants to select the node which has no child node eth1, the filter should be set as follows: Zhang, et al. Expires September 1, 2009 [Page 8] Internet-Draft NETCONF Subtree Filtering Extensions February 2009 eth1 The output is as follows: eth0 6789 ... 3.2.4. Querying the Number of Certain Nodes 3.2.4.1. Description Sometimes the user maybe want to query the number of a kind of nodes in the data model, but the current subtree filtering can't do that. With this function, users can get what they want. 3.2.4.2. New Definition and How to Use In this function a new attribute called "_count" is defined, which has two values "true" and "false". In the output a new element <_countNum> is defined and the number of the queried node is as the content of that. If the user wants to query the number of a kind of nodes, he must set the node with the attribute "_count" whose value is "true", if the value is "false", the output will not include the node <_countNum>. Zhang, et al. Expires September 1, 2009 [Page 9] Internet-Draft NETCONF Subtree Filtering Extensions February 2009 3.2.4.3. Examples of Querying the Number of Certain Nodes Output: <_countNum>2 This example shows how to query the number of the node and in the filter this node is in a path "/top/interfaces/interface". If the user wants to query the number of a node without konwing the path of it, he also can do that by setting the filter to relative path. An example is as follows: Output: <_countNum>1 This example shows how to query the number of the node which has an attribute ifname="eth0" in the data model. In the node , the attribute _nodepath="relative" is set. In the output, the node which has attribute ifname="eth0" is outputed and the number of it is also gained. 4. Security Considerations Zhang, et al. Expires September 1, 2009 [Page 10] Internet-Draft NETCONF Subtree Filtering Extensions February 2009 5. IANA Considerations 6. Acknowledgements 7. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [refs.xml] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0", W3C XML, February 1998, . [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006. Authors' Addresses Bin Zhang Beijing University of Posts and Telecommunications No.10 Xi Tu Cheng RoadGBP[not]Haidian DistrictGBP[not]Beijing Beijing, HaiDian District 100086 P.R.China Phone: 8610 62282934 EMail: bluezb@bupt.edu.cn Zhichao Yang Beijing University of Posts and Telecommunications No.10 Xi Tu Cheng RoadGBP[not]Haidian DistrictGBP[not]Beijing Beijing, HaiDian District 100086 P.R.China Phone: 8610 62282934 EMail: yzc8759@163.com Yan Li Huawei Technologies No.3 Xinxi Road, Shangdi Information Industry Base Beijing, HaiDian District 100085 P.R.China Phone: +86 10 8288 2008 EMail: liyan_77@huawei.com Zhang, et al. Expires September 1, 2009 [Page 11]