| < draft-ietf-netmod-node-tags-06.txt | draft-ietf-netmod-node-tags-07.txt > | |||
|---|---|---|---|---|
| NETMOD Working Group Q. Wu | NETMOD Working Group Q. Wu | |||
| Internet-Draft B. Claise | Internet-Draft B. Claise | |||
| Updates: 8407 (if approved) Huawei | Updates: 8407 (if approved) Huawei | |||
| Intended status: Standards Track P. Liu | Intended status: Standards Track P. Liu | |||
| Expires: 25 August 2022 Z. Du | Expires: 31 October 2022 Z. Du | |||
| China Mobile | China Mobile | |||
| M. Boucadair | M. Boucadair | |||
| Orange | Orange | |||
| 21 February 2022 | 29 April 2022 | |||
| Self-Describing Data Object Tags in YANG Data Models | Data Node Tags in YANG Modules | |||
| draft-ietf-netmod-node-tags-06 | draft-ietf-netmod-node-tags-07 | |||
| Abstract | Abstract | |||
| This document defines a method to tag data objects that are | This document defines a method to tag data nodes that are associated | |||
| associated with operation and management data in YANG modules. This | with operation and management data in YANG modules. This method for | |||
| method for tagging YANG data objects is meant to be used for | tagging YANG data nodes is meant to be used for classifying data | |||
| classifying data objects from different YANG modules and identifying | nodes or instance of data nodes from different YANG modules and | |||
| their characteristics data. Tags may be registered as well as | identifying their characteristic data. Tags may be registered as | |||
| assigned during the module definition, assigned by implementations, | well as assigned during the definition of the module, assigned by | |||
| or dynamically defined and set by users. | implementations, or dynamically defined and set by users. | |||
| This document also provides guidance to future YANG data model | This document also provides guidance to future YANG data model | |||
| writers; as such, this document updates RFC 8407. | writers; as such, this document updates RFC 8407. | |||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on 25 August 2022. | This Internet-Draft will expire on 31 October 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2022 IETF Trust and the persons identified as the | Copyright (c) 2022 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| and restrictions with respect to this document. Code Components | and restrictions with respect to this document. Code Components | |||
| extracted from this document must include Revised BSD License text as | extracted from this document must include Revised BSD License text as | |||
| described in Section 4.e of the Trust Legal Provisions and are | described in Section 4.e of the Trust Legal Provisions and are | |||
| provided without warranty as described in the Revised BSD License. | provided without warranty as described in the Revised BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 3. Self-Describing Data Object Tags: Massive Data Object | 3. Data Classification and Fetching using Data Node Tags . . . . 4 | |||
| Collection Use Case . . . . . . . . . . . . . . . . . . . 4 | 4. Data Node Tag Values . . . . . . . . . . . . . . . . . . . . 7 | |||
| 4. Data Object Tag Values . . . . . . . . . . . . . . . . . . . 7 | ||||
| 4.1. IETF Tags . . . . . . . . . . . . . . . . . . . . . . . . 7 | 4.1. IETF Tags . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 4.2. Vendor Tags . . . . . . . . . . . . . . . . . . . . . . . 7 | 4.2. Vendor Tags . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 4.3. User Tags . . . . . . . . . . . . . . . . . . . . . . . . 8 | 4.3. User Tags . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 4.4. Reserved Tags . . . . . . . . . . . . . . . . . . . . . . 8 | 4.4. Reserved Tags . . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 5. Data Object Tag Management . . . . . . . . . . . . . . . . . 8 | 5. Data Node Tag Management . . . . . . . . . . . . . . . . . . 8 | |||
| 5.1. Module Design Tagging . . . . . . . . . . . . . . . . . . 8 | 5.1. Module Design Tagging . . . . . . . . . . . . . . . . . . 8 | |||
| 5.2. Implementation Tagging . . . . . . . . . . . . . . . . . 9 | 5.2. Implementation Tagging . . . . . . . . . . . . . . . . . 10 | |||
| 5.3. User Tagging . . . . . . . . . . . . . . . . . . . . . . 10 | 5.3. User Tagging . . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 6. Data Object Tags Module Structure . . . . . . . . . . . . . . 10 | 6. Data Node Tags Module Structure . . . . . . . . . . . . . . . 10 | |||
| 6.1. Data Object Tags Module Tree . . . . . . . . . . . . . . 10 | 6.1. Data Node Tags Module Tree . . . . . . . . . . . . . . . 10 | |||
| 7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 8. Guidelines to Model Writers . . . . . . . . . . . . . . . . . 14 | 8. Guidelines to Model Writers . . . . . . . . . . . . . . . . . 14 | |||
| 8.1. Define Standard Tags . . . . . . . . . . . . . . . . . . 14 | 8.1. Define Standard Tags . . . . . . . . . . . . . . . . . . 14 | |||
| 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 | |||
| 9.1. YANG Data Object Tag Prefixes Registry . . . . . . . . . 15 | 9.1. YANG Data Object Tag Prefixes Registry . . . . . . . . . 15 | |||
| 9.2. IETF YANG Data Object Tags Registry . . . . . . . . . . . 15 | 9.2. IETF YANG Data Object Tags Registry . . . . . . . . . . . 16 | |||
| 9.3. Updates to the IETF XML Registry . . . . . . . . . . . . 17 | 9.3. Updates to the IETF XML Registry . . . . . . . . . . . . 18 | |||
| 9.4. Updates to the YANG Module Names Registry . . . . . . . . 18 | 9.4. Updates to the YANG Module Names Registry . . . . . . . . 18 | |||
| 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 | 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 | |||
| 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 | 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 | |||
| 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 | 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
| 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 | 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
| 13.1. Normative References . . . . . . . . . . . . . . . . . . 19 | 13.1. Normative References . . . . . . . . . . . . . . . . . . 19 | |||
| 13.2. Informative References . . . . . . . . . . . . . . . . . 20 | 13.2. Informative References . . . . . . . . . . . . . . . . . 20 | |||
| Appendix A. NETCONF Example . . . . . . . . . . . . . . . . . . 21 | Appendix A. Example: Additional Auxiliary Data Property | |||
| Appendix B. Non-NMDA State Module . . . . . . . . . . . . . . . 22 | Information . . . . . . . . . . . . . . . . . . . . . . . 22 | |||
| Appendix C. Targeted data object collection example . . . . . . 26 | Appendix B. Instance Level Tunnel Tagging Example . . . . . . . 22 | |||
| Appendix D. Changes between Revisions . . . . . . . . . . . . . 29 | Appendix C. NETCONF Example . . . . . . . . . . . . . . . . . . 24 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 | Appendix D. Non-NMDA State Module . . . . . . . . . . . . . . . 25 | |||
| Appendix E. Targeted Data Fetching Example . . . . . . . . . . . 28 | ||||
| Appendix F. Changes between Revisions . . . . . . . . . . . . . 30 | ||||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 | ||||
| 1. Introduction | 1. Introduction | |||
| The use of tags for classification and organization purposes is | The use of tags for classification and organization purposes is | |||
| fairly ubiquitous, not only within IETF protocols, but globally in | fairly ubiquitous, not only within IETF protocols, but globally in | |||
| the Internet (e.g., "#hashtags"). For the specific case of YANG data | the Internet (e.g., "#hashtags"). For the specific case of YANG data | |||
| models, a module tag is defined as a string that is associated with a | models, a module tag is defined as a string that is associated with a | |||
| module name at the module level [RFC8819]. | module name at the module level [RFC8819]. | |||
| Many data models have been specified by various Standards Developing | Many data models have been specified by various Standards Developing | |||
| Organizations (SDOs) and the Open Source community, and it is likely | Organizations (SDOs) and the Open Source community, and it is likely | |||
| that many more will be specified. These models cover many of the | that many more will be specified. These models cover many of the | |||
| networking protocols and techniques. However, the data objects | networking protocols and techniques. However, data nodes defined by | |||
| defined by these technology-specific data models might represent a | these technology-specific data models might represent only a portion | |||
| portion of fault, configuration, accounting, performance, and | of fault, configuration, accounting, performance, and security | |||
| security (FCAPS) management information ([FCAPS]) at different levels | (FCAPS) management information ([FCAPS]) at different levels and | |||
| and network locations, but also categorised in various different | network locations, but also categorised in various different ways. | |||
| ways. Furthermore, there is no consistent classification criteria or | Furthermore, there is no consistent classification criteria or | |||
| representation for a specific service, feature, or data source. | representations for a specific service, feature, or data source. | |||
| This document defines self-describing data object tags and associates | This document defines data node tags and shows how they may be | |||
| them with data objects within a YANG module, which: | associated with data nodes within a YANG module, which: | |||
| * Provide dictionary meaning for specific targeted data objects. | * Provide dictionary meaning for specific targeted data nodes. | |||
| * Indicate a relationship between data objects within the same YANG | * Indicate a relationship between data nodes within the same YANG | |||
| module or from different YANG modules. | module or from different YANG modules. | |||
| * Identify key performance metric data objects and the absolute | * Identify key performance metric related data nodes and the | |||
| XPath expression identifying the element path to the node. | absolute XPath expression identifying the element path to the | |||
| nodes. | ||||
| The self-describing data object tags can be used by the NETCONF | The data node tags can be used by a NETCONF [RFC6241] or RESTCONF | |||
| [RFC6241] or RESTCONF [RFC8040] client to classify data objects from | [RFC8040]client to classify data nodes of instance of these data | |||
| different YANG modules and identify characteristic data. In | nodes from different YANG modules and identify characteristic data. | |||
| addition, these tags can provide input, instructions, or indications | In addition, these tags can provide input, instructions, or | |||
| to selection filters and filter queries of configuration or | indications to selection filters and filter queries of configuration | |||
| operational state on a server based on these data object tags (e.g., | or operational state on a server based on these data node tags (e.g., | |||
| return specific objects containing operational state related to | return specific data containing operational state related to | |||
| system-management). NETCONF clients can discover data objects with | performance management). NETCONF clients can discover data nodes or | |||
| self-describing data object tags supported by a NETCONF server by | instances of data nodes with data node tags supported by a NETCONF | |||
| means of the <get-schema> operation (Section 3.1 of [RFC6022]). The | server by means of the <get-schema> operation (Section 3.1 of | |||
| self-describing data object tag capability can also be advertised | [RFC6022]). The data node tag information can also be queried using | |||
| using the capability notification model [RFC9196] by the NETCONF | the model defined in Section 6.1. Similar to YANG module tags | |||
| server or some websites where offline documents are kept. Similar to | defined in [RFC8819], these data node tags may be registered or | |||
| YANG module tags defined in [RFC8819], these data object tags may be | assigned during the module definition, assigned by implementations, | |||
| registered or assigned during the module definition, assigned by | or dynamically defined and set by users. | |||
| implementations, or dynamically defined and set by users. | ||||
| This document defines a YANG module [RFC7950] that augments the | This document defines a YANG module [RFC7950] that augments the | |||
| module tag model [RFC8819] and provides a list of data object entries | module tag model [RFC8819] and provides a list of data node instance | |||
| to add or remove self-describing tags as well as to view the set of | entries to add or remove data node tags as well as to view the set of | |||
| self-describing tags associated with specific data objects within | data node tags associated with specific data nodes or instance of | |||
| YANG modules. | data nodes within YANG modules. | |||
| This document defines three extension statements to indicate self- | This document defines three extension statements to indicate data | |||
| describing tags that should be added by the module implementation | node tags that should be added by the module implementation | |||
| automatically (i.e., outside of configuration). | automatically (i.e., outside of configuration). | |||
| This document also defines an IANA registry for tag prefixes and a | This document also defines an IANA registry for tag prefixes and a | |||
| set of globally assigned tags (Section 9). | set of globally assigned tags (Section 9). | |||
| Section 8 provides guidelines for authors of YANG data models. This | Section 8 provides guidelines for authors of YANG data models. This | |||
| document updates [RFC8407]. | document updates [RFC8407]. | |||
| The YANG data model in this document conforms to the Network | The YANG data model in this document conforms to the Network | |||
| Management Datastore Architecture defined in [RFC8342]. | Management Datastore Architecture defined in [RFC8342]. | |||
| skipping to change at page 4, line 35 ¶ | skipping to change at page 4, line 35 ¶ | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
| 14 [RFC2119][RFC8174] when, and only when, they appear in all | 14 [RFC2119][RFC8174] when, and only when, they appear in all | |||
| capitals, as shown here. | capitals, as shown here. | |||
| The meanings of the symbols in tree diagrams are defined in | The meanings of the symbols in tree diagrams are defined in | |||
| [RFC8340]. | [RFC8340]. | |||
| 3. Self-Describing Data Object Tags: Massive Data Object Collection Use | 3. Data Classification and Fetching using Data Node Tags | |||
| Case | ||||
| Among data object tags, the 'opm' (object, property, metric) tags can | Among data node tags, the 'opm' (object, property, metric) tags can | |||
| be used to tackle massive data object collections, indicate | be used to classify collected data, indicate relationships between | |||
| relationships between data objects, and capture YANG data objects | data nodes, and capture YANG-modelled performance metrics data | |||
| associated with YANG-modelled performance metrics data. An example | associated with data nodes of instances of data nodes. An example is | |||
| is depicted in Figure 1. | depicted in Figure 1. | |||
| .------. | .------. | |||
| |Object| | |Object| | |||
| | Tag | | | Tag | | |||
| '--+--' | '--+--' | |||
| | | | | |||
| +---------V--------+ contain | +---------V--------+ contain | |||
| | YANG Data Node <----------------+ | | YANG Data Node <----------------+ | |||
| | /Data Object 1 | | | | 1 | | | |||
| +--^-------------^-+ | | +--^-------------^-+ | | |||
| |contain |contain | | |contain |contain | | |||
| | | | | | | | | |||
| +-----------+---+ +- -----+-------+ +-----+---------+ | +-----------+---+ +- -----+-------+ +-----+---------+ | |||
| | YANG Data Node| | YANG Data Node| | YANG Data Node| | | YANG Data Node| | YANG Data Node| | YANG Data Node| | |||
| |/Sub Object 2 | | /Sub Object 3 | | /Sub Object 4 | | | 2 | | 3 | | 4 | | |||
| +--^------------+ +^-----^--------+ +^-----^------^-+ | +--^------------+ +^-----^--------+ +^-----^------^-+ | |||
| | | | | | | | | | | | | | | |||
| .---+---. | .--+--. | .--+--. | | .---+---. | .--+--. | .--+--. | | |||
| |Property | | |Metric | | |Metric | | | |Property | | |Metric | | |Metric | | | |||
| | Tag | | | Tag | | | Tag | | | | Tag | | | Tag | | | Tag | | | |||
| '---------' | '-------' | '-------' | | '---------' | '-------' | '-------' | | |||
| | | | | | | | | |||
| .--+--. .--+--. .---+---. | .--+--. .--+--. .---+---. | |||
| |Metric | |Metric | || Multi || | |Metric | |Metric | || Multi || | |||
| | Type | | Type | ||Metric || | | Type | | Type | ||Metric || | |||
| | Tag | | Tag | ||Source || | | Tag | | Tag | ||Source || | |||
| '-------' '-------' \\ Tag // | '-------' '-------' \\ Tag // | |||
| '-----' | '-----' | |||
| Figure 1: The Relation between Object, Property, and Metric | Figure 1: The Relation between Object, Property, and Metric | |||
| In Figure 1, data objects can contain other data objects called | In Figure 1. | |||
| 'subobjects'. Both object and subobjects can be modeled as YANG data | ||||
| nodes [RFC7950]. | ||||
| Data objects that contain other data objects can be one of type | Data nodes that contain other data nodes can be one of type | |||
| 'container', 'leaf-list', or 'list' and are tagged with the object | 'container', 'leaf-list', or 'list' and are tagged with the 'object' | |||
| tag. | tag. | |||
| A subobject tagged with the property tag is a 'leaf' node. | A Data node tagged with the 'property' tag is a 'leaf' node. | |||
| Subobjects tagged with the metric tag can be one of 'container', | Data nodes tagged with the 'metric' tag can be one of 'container', | |||
| 'leaf-list', 'list', or 'leaf' data node. | 'leaf-list', 'list', or 'leaf' data node. | |||
| A data object may contain one single object tag, or one single | A data node may be associated with one single 'object' tag, or one | |||
| property tag, or one single metric tag. The data object tagged with | single 'property' tag, or one single 'metric' tag. The data node | |||
| the metric tag also can have one or multiple Metric Type tags and/or | tagged with the 'metric' tag also can have one or multiple MetricType | |||
| one single multi-source tag. | tags and/or one single multi-source tag. | |||
| The use of 'opm' tags is meant to help filter discrete categories of | The use of 'opm' tags is meant to help filter discrete categories of | |||
| YANG data objects scattered across the same or different YANG modules | YANG data objects scattered across the same or different YANG modules | |||
| that are supported by a device and capture all network performance | that are supported by a device and capture all network performance | |||
| data or all property data in a single view of the data. In the | data or all property data in a single view of the data. In the | |||
| example shown in Figure 2, the 'tunnel-svc' data object is a | example shown in Figure 2, the 'tunnel-svc' data node is a list node | |||
| container node defined in a 'tunnel-pm' module and can be seen as the | defined in a 'example-tunnel-pm' module and can be seen as the root | |||
| root object for property tagged subobjects (e.g., 'tunnel- | object for property tagged data node (e.g., 'tunnel-svc'/'create- | |||
| svc'/'create-time') and metric tagged subobjects (e.g., 'tunnel- | time') and metric tagged data node (e.g., 'tunnel-svc'/'avg- | |||
| svc'/'avg-latency'). The 'name', 'create-time', and 'modified-time' | latency'). The 'name', 'create-time', and 'modified-time' are | |||
| are property tagged subobjects under 'tunnel-svc' container. The | property tagged data node under 'tunnel-svc' list. The 'avg-latency' | |||
| 'avg-latency' and 'packet-loss' metrics are tagged subobjects under | and 'packet-loss' metrics are metric tagged data nodes under 'tunnel- | |||
| 'tunnel-svc' container node. Consider the 'tunnel-svc' data object | svc' list node. Consider the 'tunnel-svc' data node and the 'tunnel- | |||
| and the 'tunnel-svc/name' data object as an example: the 'tunnel-svc' | svc/name' data node as an example: the 'tunnel-svc' data node has one | |||
| data object has one single object tag (i.e., 'ietf:object'), while | single 'object' tag (i.e., 'ietf:object'), while the 'tunnel-svc/ | |||
| the 'tunnel-svc/name' data object has one single property subobject | name' data node has one single 'property' data node tag (i.e., | |||
| tag (i.e., 'ietf:property'). In addition, not all metric subobjects | 'ietf:property'). In addition, not all metric data node need to be | |||
| need to be tagged (e.g., define specific categories, such as loss- | tagged (e.g., define specific categories, such as loss-related metric | |||
| related metric subobjects need to be tagged with a metric-type tag | data nodes need to be tagged with a metric-type tag which can further | |||
| which can further reduce amount data to be fetched). | reduce amount data to be fetched). | |||
| +------------------------+--------------------------------+-----------+ | +------------------------+--------------------------------+-----------+ | |||
| | Data | Object Property Metric | Multi- | | | Data | Object Property Metric | Multi- | | |||
| | Object | Tag Tag Tag |Source Tag | | | Node | Tag Tag Tag |Source Tag | | |||
| +------------------------+--------------------------------+-----------+ | +------------------------+--------------------------------+-----------+ | |||
| | | ietf: | | | | | ietf: | | | |||
| |tunnel-svc | object | | | |tunnel-svc | object | | | |||
| | | ietf: | | | | | ietf: | | | |||
| |tunnel-svc/name | property | | | |tunnel-svc/name | property | | | |||
| | | ietf: | | | | | ietf: | | | |||
| |tunnel-svc/create-time | property | | | |tunnel-svc/create-time | property | | | |||
| | | ietf: | | | | | ietf: | | | |||
| |tunnel-svc/modified-time| property | | | |tunnel-svc/modified-time| property | | | |||
| | | | | | | | | | | |||
| skipping to change at page 7, line 7 ¶ | skipping to change at page 7, line 7 ¶ | |||
| |tunnel-svc/min-latency | ietf: | non-agg | | |tunnel-svc/min-latency | ietf: | non-agg | | |||
| | | metric | | | | | metric | | | |||
| |tunnel-svc/max-latency | ietf: | non-agg | | |tunnel-svc/max-latency | ietf: | non-agg | | |||
| | | metric | | | | | metric | | | |||
| +------------------------+--------------------------------+-----------+ | +------------------------+--------------------------------+-----------+ | |||
| Figure 2: Example of OPM Tags Used in the YANG Module | Figure 2: Example of OPM Tags Used in the YANG Module | |||
| If data objects in YANG modules are adequately tagged and learnt by | If data objects in YANG modules are adequately tagged and learnt by | |||
| the client from a server, the client can retrieve paths to all | the client from a server, the client can retrieve paths to all | |||
| targeted data objects and then use an XPath query defined in | targeted data nodes and then use an XPath query defined in | |||
| [RFC8639][RFC8641] to list all tagged data objects which reflect the | [RFC8639][RFC8641] to list all tagged data nodes which reflect the | |||
| network characteristics. | network characteristics. | |||
| 4. Data Object Tag Values | 4. Data Node Tag Values | |||
| All data object tags SHOULD begin with a prefix indicating who owns | All data node tags (except in some cases of user tags as described in | |||
| their definition. An IANA registry (Section 9.1) is used to register | Section 4.3) begin with a prefix indicating who owns their | |||
| data object tag prefixes. Initially, three prefixes are defined. | definition. An IANA registry (Section 9.1) is used to register data | |||
| node tag prefixes. Initially, three prefixes are defined. | ||||
| No further structure is imposed by this document on the value | No further structure is imposed by this document on the value | |||
| following the registered prefix, and the value can contain any YANG | following the registered prefix, and the value can contain any YANG | |||
| type 'string' characters except carriage returns, newlines, tabs, and | type 'string' characters except carriage returns, newlines, tabs, and | |||
| spaces. | spaces. | |||
| Except for the conflict-avoiding prefix, this document is | Except for the conflict-avoiding prefix, this document is | |||
| purposefully not specifying any structure on (i.e., restricting) the | purposefully not specifying any structure on (i.e., restricting) the | |||
| tag values. The intent is to avoid arbitrarily restricting the | tag values. The intent is to avoid arbitrarily restricting the | |||
| values that designers, implementers, and users can use. As a result | values that designers, implementers, and users can use. As a result | |||
| of this choice, designers, implementers, and users are free to add or | of this choice, designers, implementers, and users are free to add or | |||
| not add any structure they may require to their own tag values. | not add any structure they may require to their own tag values. | |||
| 4.1. IETF Tags | 4.1. IETF Tags | |||
| An IETF tag is a data object tag that has the prefix "ietf:". | An IETF tag is a data node tag that has the prefix "ietf:". | |||
| All IETF data object tags are registered with IANA in the registry | All IETF data node tags are registered with IANA in the registry | |||
| defined in Section 9.2. | defined in Section 9.2. | |||
| 4.2. Vendor Tags | 4.2. Vendor Tags | |||
| A vendor tag is a tag that has the prefix "vendor:". | A vendor tag is a tag that has the prefix "vendor:". | |||
| These tags are defined by the vendor that implements the module, and | These tags are defined by the vendor that implements the module, and | |||
| are not registered with IANA. However, it is RECOMMENDED that the | are not registered with IANA. However, it is RECOMMENDED that the | |||
| vendor includes extra identification in the tag to avoid collisions, | vendor includes extra identification in the tag to avoid collisions, | |||
| such as using the enterprise or organization name following the | such as using the enterprise or organization name following the | |||
| "vendor:" prefix (e.g., vendor:example.com:vendor-defined- | "vendor:" prefix (e.g., vendor:entno:vendor-defined-classifier). | |||
| classifier). | ||||
| 4.3. User Tags | 4.3. User Tags | |||
| A user tag is any tag that has the prefix "user:". For the avoidance | User tags are defined by a user/administrator and are not registered | |||
| of confusion, the colon (":") when it appears for the first time, is | by IANA. | |||
| always assumed to be the separator between a prefix and the rest of | ||||
| the tag. And so, when a user tag does not have a prefix, it MUST NOT | ||||
| contain a colon. | ||||
| These tags are defined by a user/administrator and are not meant to | Any tag with the prefix "user:" is a user tag. Furthermore, any tag | |||
| be registered with IANA. Users are not required to use the "user:" | that does not contain a colon (":", i.e., has no prefix) is also a | |||
| prefix; however, doing so is RECOMMENDED as it helps avoid | user tag. Users are not required to use the "user:" prefix; however, | |||
| collisions. | doing so is RECOMMENDED. | |||
| 4.4. Reserved Tags | 4.4. Reserved Tags | |||
| Any tag not starting with the prefix "ietf:", "vendor:", or "user:" | Section 9.1 describes the IANA registry of tag prefixes. Any prefix | |||
| is reserved for future use (Section 9.1). | not included in that registry is reserved for future use, but tags | |||
| starting with such a prefix are still valid tags. | ||||
| These tag values are not invalid, but simply reserved in the context | ||||
| of specifications (e.g., RFCs). | ||||
| 5. Data Object Tag Management | 5. Data Node Tag Management | |||
| Tags may be associated with a data object within a YANG module in a | Tags may be associated with a data node within a YANG module in a | |||
| number of ways. Typically, tags may be defined and associated at the | number of ways. Typically, tags may be defined and associated at the | |||
| module design time, at implementation time without the need of a live | module design time, at implementation time without the need of a live | |||
| server, or via user administrative control. As the main consumers of | server, or via user administrative control. As the main consumers of | |||
| data object tags are users, users may also remove any tag from a live | data node tags are users, users may also remove any tag from a live | |||
| server, no matter how the tag became associated with a data object | server, no matter how the tag became associated with a data node | |||
| within a YANG module. | within a YANG module. | |||
| 5.1. Module Design Tagging | 5.1. Module Design Tagging | |||
| A data object definition MAY indicate a set of data object tags to be | A data node definition MAY indicate a set of data node tags to be | |||
| added by a module's implementer. These design time tags are | added by a module's implementer. These design time tags are | |||
| indicated using a set of extension statements which include: | indicated using a set of extension statements which include: | |||
| opm-tag extension statement: Classifies management and operation | opm-tag extension statement: Classifies management and operation | |||
| data into object, property subobject, and metric subobject | data into object, property, and metric three categories. Three | |||
| categories. | values (object, property and metric) are assigned to the 'opm-tag' | |||
| tag. | ||||
| Both objects and subobjects can be modeled as YANG data nodes | Data nodes that contain other data nodes can be one of type | |||
| [RFC7950]. Data objects that contain other data objects can be | 'container', 'leaf-list', and 'list' and are tagged with the | |||
| one of type 'container', 'leaf-list', and 'list' and are tagged | 'object' tag value. A data node tagged with the 'property' tag | |||
| with object tag. A subobject tagged with the property tag is a | value is a 'leaf' node. Data node tagged with the 'metric' tag | |||
| 'leaf' node. Subobjects tagged with the metric tag can be one of | value can be one of 'container', 'leaf-list', 'list', or 'leaf' | |||
| 'container', 'leaf-list', 'list', or 'leaf' data node. A data | data node. A data node contains one single 'object' tag, one | |||
| object contains one single object tag, one single property tag, or | single 'property' tag, or one single 'metric' tag. Both 'object' | |||
| one single metric tag. | tag value and 'property' tag value are not inherited down the | |||
| containment hierarchy, e.g., if a container is marked with a | ||||
| 'object ' tag value, all its contained leaves don't inherit the | ||||
| tag value. The 'metric' tag value is inherited down the | ||||
| containment hierarchy if Data nodes tagged with the 'metric' tag | ||||
| is one of 'container', 'leaf-list', 'list'. | ||||
| A data object tagged with metric tag also can have one or multiple | A data node tagged with the 'metric' tag also can have one or | |||
| Metric type tag and/or one single multi-source tag. See the | multiple Metric type tag and/or one single multi-source tag. See | |||
| examples depicted in Figure 2 and Figure 4. | the examples depicted in Figure 2 and Figure 4. | |||
| metric-type extension statement: Provides metric data objects | metric-type extension statement: Provides metric related data nodes | |||
| classifications (e.g., loss, jitter, delay, counter, gauge, | classifications (e.g., loss, jitter, delay, counter, gauge, | |||
| summary, unknown) within the YANG module. | summary, unknown) for data nodes tagged with the 'metric' tag. | |||
| Data nodes tagged with the 'metric-type' tag can be one of | ||||
| 'container', 'leaf-list', 'list', or 'leaf' data node. The | ||||
| 'metric-type' tag is inherited down the containment hierarchy if | ||||
| Data nodes tagged with the 'metric-type' tag is one of | ||||
| 'container', 'leaf-list', 'list'. Figure 6 provides a list of | ||||
| possbile values for the 'metric-type' tag. | ||||
| multi-source-tag extension statement: Identifies multi-source | multi-source-tag extension statement: Identifies multi-source | |||
| aggregation type (e.g., aggregated, non-aggregated) related to a | aggregation type for data nodes tagged with the 'metric' tag. Two | |||
| metric subobject. | values (i.e., aggregated, non-aggregated) are assigned to 'multi- | |||
| source-tag' tag. | ||||
| The 'aggregated' multi-source aggregation type allows a large | The 'aggregated' multi-source aggregation type allows a large | |||
| number of measurements on metric subobjects from different sources | number of measurements on metric subobjects from different sources | |||
| of the same type (e.g., line card, each subinterface of aggregated | of the same type (e.g., line card, each subinterface of aggregated | |||
| Ethernet interface) to be combined into aggregated statistics and | Ethernet interface) to be combined into aggregated statistics and | |||
| report as one metric subobject. | report as one metric subobject. | |||
| The 'non-aggregated' multi-source aggregation type allows | The 'non-aggregated' multi-source aggregation type allows | |||
| measurement from each source of the same type (e.g., line card, | measurement from each source of the same type (e.g., line card, | |||
| each subinterface of aggregated Ethernet interface) to be reported | each subinterface of aggregated Ethernet interface) to be reported | |||
| separately. | separately. | |||
| Data nodes tagged with the 'multi-source-tag' tag can be one of | ||||
| 'container', 'leaf-list', 'list', or 'leaf' data node. The | ||||
| 'multi-source-tag' tag is inherited down the containment hierarchy | ||||
| if Data nodes tagged with the 'multi-source-tag' tag is one of | ||||
| 'container', 'leaf-list', 'list'. | ||||
| Among these extension statements, the 'metric-type' and 'multi- | Among these extension statements, the 'metric-type' and 'multi- | |||
| source' tag extension statements are context information that can be | source-tag' extension statements are context information that can be | |||
| used to correlate data objects from the different modules. | used to correlate data nodes from the different modules. | |||
| If the data node is defined in an IETF Standards Track document, the | If the data node is defined in an IETF Standards Track document, the | |||
| data object tags MUST be IETF Tags (Section 4.1). Thus, new data | data node tags MUST be IETF Tags (Section 4.1). Thus, new data nodes | |||
| objects can drive the addition of new IETF tags to the IANA registry | can drive the addition of new IETF tags to the IANA registry defined | |||
| defined in Section 9.2, and the IANA registry can serve as a check | in Section 9.2, and the IANA registry can serve as a check against | |||
| against duplication. | duplication. | |||
| 5.2. Implementation Tagging | 5.2. Implementation Tagging | |||
| An implementation MAY include additional tags associated with data | An implementation MAY include additional tags associated with data | |||
| objects within a YANG module. These tags SHOULD be IETF | nodes within a YANG module. These tags SHOULD be IETF ((i.e., | |||
| (Section 4.1) or vendor tags (Section 4.2). | registered) ) or vendor tags. | |||
| 5.3. User Tagging | 5.3. User Tagging | |||
| Data object tags of any kind, with or without a prefix, can be | data node tags of any kind, with or without a prefix, can be assigned | |||
| assigned and removed by the user from a server using normal | and removed by the user from a server using normal configuration | |||
| configuration mechanisms. In order to remove a data object tag from | mechanisms. In order to remove a data node tag from the operational | |||
| the operational datastore, the user adds a matching "masked-tag" | datastore, the user adds a matching "masked-tag" entry for a given | |||
| entry for a given data object within the 'ietf-data-object-tags' | data node within the 'ietf-data-node-tags' module. | |||
| module. | ||||
| 6. Data Object Tags Module Structure | 6. Data Node Tags Module Structure | |||
| 6.1. Data Object Tags Module Tree | 6.1. Data Node Tags Module Tree | |||
| The tree associated with the "ietf-data-object-tags" module is as | The tree associated with the "ietf-data-node-tags" module is as | |||
| follows: | follows: | |||
| module: ietf-data-object-tags | module: ietf-data-node-tags | |||
| augment /tags:module-tags/tags:module: | augment /tags:module-tags/tags:module: | |||
| +--rw data-object-tags | +--rw data-node-tags | |||
| +--rw data-object* [name] | +--rw data-node* [ni-id] | |||
| +--rw name nacm:node-instance-identifier | +--rw ni-id nacm:node-instance-identifier | |||
| +--rw tag* tags:tag | +--rw tag* tags:tag | |||
| +--rw masked-tag* tags:tag | +--rw masked-tag* tags:tag | |||
| +--rw extended-tag-type? identityref | ||||
| Figure 3: YANG Module Tags Tree Diagram | Figure 3: YANG Module Data Node Tags Tree Diagram | |||
| 7. YANG Module | 7. YANG Module | |||
| This module imports types from [RFC8819],[RFC8341]. | This module imports types from [RFC8819],[RFC8341]. | |||
| <CODE BEGINS> file "ietf-data-object-tags@2022-02-04.yang" | <CODE BEGINS> file "ietf-data-node-tags@2022-02-04.yang" | |||
| module ietf-data-object-tags { | module ietf-data-node-tags { | |||
| yang-version 1.1; | yang-version 1.1; | |||
| namespace "urn:ietf:params:xml:ns:yang:ietf-data-object-tags"; | namespace "urn:ietf:params:xml:ns:yang:ietf-data-node-tags"; | |||
| prefix ntags; | prefix ntags; | |||
| import ietf-netconf-acm { | import ietf-netconf-acm { | |||
| prefix nacm; | prefix nacm; | |||
| reference | reference | |||
| "RFC 8341: Network Configuration Access Control | "RFC 8341: Network Configuration Access Control | |||
| Model"; | Model"; | |||
| } | } | |||
| import ietf-module-tags { | import ietf-module-tags { | |||
| prefix tags; | prefix tags; | |||
| skipping to change at page 11, line 4 ¶ | skipping to change at page 11, line 9 ¶ | |||
| prefix nacm; | prefix nacm; | |||
| reference | reference | |||
| "RFC 8341: Network Configuration Access Control | "RFC 8341: Network Configuration Access Control | |||
| Model"; | Model"; | |||
| } | } | |||
| import ietf-module-tags { | import ietf-module-tags { | |||
| prefix tags; | prefix tags; | |||
| reference | reference | |||
| "RFC 8819: YANG Module Tags "; | "RFC 8819: YANG Module Tags "; | |||
| } | } | |||
| organization | organization | |||
| "IETF NetMod Working Group (NetMod)"; | "IETF NetMod Working Group (NetMod)"; | |||
| contact | contact | |||
| "WG Web: <https://datatracker.ietf.org/wg/netmod/> | "WG Web: <https://datatracker.ietf.org/wg/netmod/> | |||
| WG List: <mailto:netmod@ietf.org> | WG List: <mailto:netmod@ietf.org> | |||
| Editor: Qin Wu | Editor: Qin Wu | |||
| <mailto:bill.wu@huawei.com> | <mailto:bill.wu@huawei.com> | |||
| Editor: Benoit Claise | Editor: Benoit Claise | |||
| <mailto:benoit.claise@huawei.com> | <mailto:benoit.claise@huawei.com> | |||
| Editor: Peng Liu | Editor: Peng Liu | |||
| <mailto:liupengyjy@chinamobile.com> | <mailto:liupengyjy@chinamobile.com> | |||
| Editor: Zongpeng Du | Editor: Zongpeng Du | |||
| <mailto:duzongpeng@chinamobile.com> | <mailto:duzongpeng@chinamobile.com> | |||
| Editor: Mohamed Boucadair | Editor: Mohamed Boucadair | |||
| <mailto:mohamed.boucadair@orange.com>"; | <mailto:mohamed.boucadair@orange.com>"; | |||
| // RFC Ed.: replace XXXX with actual RFC number and | ||||
| // remove this note. | ||||
| description | description | |||
| "This module describes a mechanism associating self-describing | "This module describes a mechanism associating data node | |||
| tags with YANG data object within YANG modules. Tags may be IANA | tags with YANG data node within YANG modules. Tags may be IANA | |||
| assigned or privately defined. | assigned or privately defined. | |||
| Copyright (c) 2022 IETF Trust and the persons identified as | Copyright (c) 2022 IETF Trust and the persons identified as | |||
| authors of the code. All rights reserved. | authors of the code. All rights reserved. | |||
| Redistribution and use in source and binary forms, with or | Redistribution and use in source and binary forms, with or | |||
| without modification, is permitted pursuant to, and subject to | without modification, is permitted pursuant to, and subject to | |||
| the license terms contained in, the Revised BSD License set | the license terms contained in, the Revised BSD License set | |||
| forth in Section 4.c of the IETF Trust's Legal Provisions | forth in Section 4.c of the IETF Trust's Legal Provisions | |||
| Relating to IETF Documents | Relating to IETF Documents | |||
| (https://trustee.ietf.org/license-info). | (https://trustee.ietf.org/license-info). | |||
| This version of this YANG module is part of RFC XXXX | This version of this YANG module is part of RFC XXXX | |||
| (https://datatracker.ietf.org/html/rfcXXXX); see the RFC itself | (https://datatracker.ietf.org/html/rfcXXXX); see the RFC itself | |||
| for full legal notices."; | for full legal notices."; | |||
| // RFC Ed.: update the date below with the date of RFC publication | ||||
| // and RFC number and remove this note. | ||||
| revision 2022-02-04 { | revision 2022-02-04 { | |||
| description | description | |||
| "Initial revision."; | "Initial revision."; | |||
| reference | reference | |||
| "RFC XXXX: Self-Describing Data Object Tags in YANG Data | "RFC XXXX: data node Tags in YANG Modules"; | |||
| Models"; | } | |||
| identity other-data-property { | ||||
| description | ||||
| "Base identity for data property type."; | ||||
| } | } | |||
| extension opm-tag { | extension opm-tag { | |||
| argument tag; | argument tag; | |||
| description | description | |||
| "The argument 'tag' is of type 'tag'. This extension statement | "The argument 'tag' is of type 'tag'. This extension statement | |||
| is used by module authors to indicate the opm tags that should | is used by module authors to indicate the opm tags that should | |||
| be added automatically by the system. 'opm-tag' is used to | be added automatically by the system. 'opm-tag' is used to | |||
| classify operation and management data objects into the three | classify operation and management data nodes into the three | |||
| categories, object, property, and metric. Data Object can | categories, object, property, and metric. A data node | |||
| contain other data objects called subobjects. Both object and | tagged with 'object' tag can be one of container, leaf-list, or | |||
| subobjects can be modeled as data nodes. A data object | list. A data node tagged is with the 'property' tag is a leaf | |||
| tagged with object tag can be one of container, leaf-list, or | node. The data node tagged with the 'metric' tag can be one of | |||
| list. A data object tagged is with the property tag is a leaf | container, leaf-list, list, or leaf. A data nodes tagged | |||
| node. The data object tagged with the metric tag can be one of | with either property tag or metric tag are child nodes | |||
| container, leaf-list, list, or leaf. A data objects tagged | belonging to a specific root data node. Each data node may | |||
| with either property tag or metric tag are subobjects | contain one single 'object' tag, or one single 'property' tag, | |||
| belonging to a specific root data object. Each data object may | or one single 'metric' tag (these tags are mutually | |||
| contain one single object tag, or one single property tag, | ||||
| or one single metric tag (these tags are mutually | ||||
| exclusive). As such, the origin of the value for the | exclusive). As such, the origin of the value for the | |||
| pre-defined tags should be set to 'system'."; | pre-defined tags should be set to 'system'."; | |||
| } | } | |||
| extension metric-type { | extension metric-type { | |||
| argument tag; | argument tag; | |||
| description | description | |||
| "The argument 'tag' is of type 'tag'. The metric type can be | "The argument 'tag' is of type 'tag'. The metric type can be | |||
| used to provide metric data object classification | used to provide metric data node classification | |||
| (e.g., loss, jitter, packet loss, counter, gauge, | (e.g., loss, jitter, packet loss, counter, gauge, | |||
| summary, unknown) within a YANG module."; | summary, unknown) within a YANG module.The initial values of | |||
| the 'metric-type' tag is defined in section 9.2, additional | ||||
| metric-type tag value can be added in the future."; | ||||
| } | } | |||
| extension multi-source-tag { | extension multi-source-tag { | |||
| argument tag; | argument tag; | |||
| description | description | |||
| "The argument 'tag' is of type 'tag'. The multi-source-tag can | "The argument 'tag' is of type 'tag'. The multi-source-tag can | |||
| be used to identify multi-source aggregation type | be used to identify multi-source aggregation type | |||
| (e.g., aggregated, non-aggregated) related to a metric | (e.g., aggregated, non-aggregated) related to a metric | |||
| subobject. | subobject. | |||
| The 'aggregated' multi-source aggregation type allows a large | The 'aggregated' multi-source aggregation type allows a large | |||
| number of measurements on metric subobjects from different | number of measurements on metric subobjects from different | |||
| sources of the same type (e.g., line card, each subinterface of | sources of the same type (e.g., line card, each subinterface of | |||
| an aggregated Ethernet interface) to be combined into | an aggregated Ethernet interface) to be combined into | |||
| aggregated statistics and reported as one metric subobject | aggregated statistics and reported as one metric subobject | |||
| value. | value. | |||
| The 'non-aggregated' multi-source aggregation type allows | The 'non-aggregated'multi-source aggregation type allows | |||
| measurement from each source of the same type (e.g., line | measurement from each source of the same type (e.g., line | |||
| card, each subinterface of an aggregated Ethernet interface) to | card, each subinterface of an aggregated Ethernet interface) to | |||
| be reported separately."; | be reported separately."; | |||
| } | } | |||
| augment "/tags:module-tags/tags:module" { | augment "/tags:module-tags/tags:module" { | |||
| description | description | |||
| "Augment the Module Tags module with data object tag | "Augment the Module Tags module with data node tag | |||
| attributes."; | attributes."; | |||
| container data-object-tags { | container data-node-tags { | |||
| description | description | |||
| "Contains the list of data objects and their associated data | "Contains the list of data nodes and their associated data | |||
| object tags."; | object tags."; | |||
| list data-object { | list data-node { | |||
| key "name"; | key "ni-id"; | |||
| description | description | |||
| "Includes a list of data objects and their associated data | "Includes a list of data nodes and their associated data | |||
| object tags."; | object tags."; | |||
| leaf name { | leaf ni-id { | |||
| type nacm:node-instance-identifier; | type nacm:node-instance-identifier; | |||
| mandatory true; | mandatory true; | |||
| description | description | |||
| "The YANG data object name."; | "The YANG data node name."; | |||
| } | } | |||
| leaf-list tag { | leaf-list tag { | |||
| type tags:tag; | type tags:tag; | |||
| description | description | |||
| "Lists the tags associated with the data object within | "Lists the tags associated with the data node within | |||
| the YANG module. | the YANG module. | |||
| See the IANA 'YANG Data Object Tag Prefixes' registry | See the IANA 'YANG data node Tag Prefixes' registry | |||
| for reserved prefixes and the IANA 'IETF YANG Data | for reserved prefixes and the IANA 'IETF YANG Data | |||
| Object Tags' registry for IETF tags. | Object Tags' registry for IETF tags. | |||
| The 'operational' state view of this list is | The 'operational' state view of this list is | |||
| constructed using the following steps: | constructed using the following steps: | |||
| 1) System tags (i.e., tags of 'system' origin) are | 1) System tags (i.e., tags of 'system' origin) are | |||
| added. | added. | |||
| 2) User configured tags (i.e., tags of 'intended' | 2) User configured tags (i.e., tags of 'intended' | |||
| origin) are added. | origin) are added. | |||
| 3) Any tag that is equal to a masked-tag is removed."; | 3) Any tag that is equal to a masked-tag is removed."; | |||
| reference | reference | |||
| "RFC XXXX: Self-Describing Data Object Tags in YANG Data | "RFC XXXX: data node Tags in YANG Data | |||
| Models, Section 9"; | Modules, Section 9"; | |||
| } | } | |||
| leaf-list masked-tag { | leaf-list masked-tag { | |||
| type tags:tag; | type tags:tag; | |||
| description | description | |||
| "The list of tags that should not be associated with the | "The list of tags that should not be associated with the | |||
| data object within the YANG module. The user can remove | data node within the YANG module. The user can remove | |||
| (mask) tags from the operational state datastore by | (mask) tags from the operational state datastore by | |||
| adding them to this list. It is not an error to add tags | adding them to this list. It is not an error to add tags | |||
| to this list that are not associated with the data | to this list that are not associated with the data | |||
| object within YANG module, but they have no operational | object within YANG module, but they have no operational | |||
| effect."; | effect."; | |||
| } | } | |||
| leaf extended-tag-type { | ||||
| type identityref { | ||||
| base other-data-property; | ||||
| } | ||||
| description | ||||
| "Type of the extended tag. The extended tag type doesn't include opm tag, | ||||
| metric-type tag and multi-source tag three types defined in | ||||
| this document. The specific extended tag type and associated auxiliary data | ||||
| are defined in the data node tags extension module."; | ||||
| } | ||||
| } | } | |||
| } | } | |||
| } | } | |||
| } | } | |||
| <CODE ENDS> | <CODE ENDS> | |||
| 8. Guidelines to Model Writers | 8. Guidelines to Model Writers | |||
| This section updates [RFC8407]. | This section updates [RFC8407] by providing text that may be regarded | |||
| as a new subsection to Section 4 of that document. It does not | ||||
| change anything already present in [RFC8407]. | ||||
| 8.1. Define Standard Tags | 8.1. Define Standard Tags | |||
| A module MAY indicate, using data object tag extension statements, a | A module MAY indicate, using data node tag extension statements, a | |||
| set of data object tags that are to be automatically associated with | set of data node tags that are to be automatically associated with | |||
| data object within the module (i.e., not added through | data node within the module (i.e., not added through configuration). | |||
| configuration). | ||||
| module example-module-A { | module example-module-A { | |||
| //... | //... | |||
| import ietf-data-node-tags { prefix ntags; } | import ietf-data-node-tags { prefix ntags; } | |||
| container top { | container top { | |||
| ntags:opm-tag "ietf:object"; | ntags:opm-tag "ietf:object"; | |||
| list X { | list X { | |||
| leaf foo { | leaf foo { | |||
| ntags:opm-tag "ietf:property"; | ntags:opm-tag "ietf:property"; | |||
| skipping to change at page 14, line 48 ¶ | skipping to change at page 15, line 25 ¶ | |||
| leaf bar { | leaf bar { | |||
| ntags:opm-tag "ietf:metric"; | ntags:opm-tag "ietf:metric"; | |||
| } | } | |||
| } | } | |||
| } | } | |||
| // ... | // ... | |||
| } | } | |||
| Figure 4: An Example of Data Object Tag | Figure 4: An Example of Data Object Tag | |||
| The module writer can use existing standard data object tags, or use | The module writer can use existing standard data node tags, or use | |||
| new data object tags defined in the data object definition, as | new data node tags defined in the data node definition, as | |||
| appropriate. For IETF standardized modules, new data object tags | appropriate. For IETF standardized modules, new data node tags MUST | |||
| MUST be assigned in the IANA registry defined in Section Section 9.2. | be assigned in the IANA registry defined in Section 9.2. | |||
| 9. IANA Considerations | 9. IANA Considerations | |||
| 9.1. YANG Data Object Tag Prefixes Registry | 9.1. YANG Data Object Tag Prefixes Registry | |||
| This document requests IANA to create "YANG Data Object Tag Prefixes" | This document requests IANA to create "YANG data node Tag Prefixes" | |||
| subregistry in "YANG Data Object Tag" registry. | subregistry in "YANG data node Tag" registry. | |||
| This registry allocates tag prefixes. All YANG Data Object Tags | ||||
| should begin with one of the prefixes in this registry. | ||||
| Prefix entries in this registry should be short strings consisting of | Prefix entries in this registry should be short strings consisting of | |||
| lowercase ASCII alpha-numeric characters and a final ":" character. | lowercase ASCII alpha-numeric characters and a final ":" character. | |||
| The allocation policy for this registry is Specification Required | The allocation policy for this registry is Specification Required | |||
| [RFC8126]. The Reference and Assignee values should be sufficient to | [RFC8126]. The Reference and Assignee values should be sufficient to | |||
| identify and contact the organization that has been allocated the | identify and contact the organization that has been allocated the | |||
| prefix. There is no specific guidance for the Designated Expert and | prefix. There is no specific guidance for the Designated Expert and | |||
| there is a presumption that a code point should be granted unless | there is a presumption that a code point should be granted unless | |||
| there is a compelling reason to the contrary. | there is a compelling reason to the contrary. | |||
| The initial values for this registry are as follows: | The initial values for this registry are as follows: | |||
| +----------+----------------------------------+-----------+----------+ | +----------+----------------------------------+-----------+----------+ | |||
| | Prefix | Description | Reference | Assignee | | | Prefix | Description | Reference | Assignee | | |||
| +----------+----------------------------------+-----------+----------+ | +----------+----------------------------------+-----------+----------+ | |||
| | ietf: | IETF Tags allocated in the IANA | [This | IETF | | | ietf: | IETF Tags allocated in the IANA | [This | IETF | | |||
| | | IETF YANG Data Object Tags | document] | | | | | IETF YANG data node Tags | document] | | | |||
| | | registry | | | | | | registry | | | | |||
| | | | | | | | | | | | | |||
| | vendor: | Non-registered tags allocated by | [This | IETF | | | vendor: | Non-registered tags allocated by | [This | IETF | | |||
| | | the module's implementer. | document] | | | | | the module's implementer. | document] | | | |||
| | | | | | | | | | | | | |||
| | user: | Non-registered tags allocated by | [This | IETF | | | user: | Non-registered tags allocated by | [This | IETF | | |||
| | | and for the user. | document] | | | | | and for the user. | document] | | | |||
| +----------+----------------------------------+-----------+----------+ | +----------+----------------------------------+-----------+----------+ | |||
| Figure 5: Table 1 | Figure 5: Table 1 | |||
| Other standards organizations (SDOs) wishing to allocate their own | Other standards organizations (SDOs) wishing to allocate their own | |||
| set of tags should request the allocation of a prefix from this | set of tags should request the allocation of a prefix from this | |||
| registry. | registry. | |||
| 9.2. IETF YANG Data Object Tags Registry | 9.2. IETF YANG Data Object Tags Registry | |||
| This document requests IANA to create "IETF OPM Tags","IETF Metric | This document requests IANA to create "IETF OPM Tags","IETF Metric | |||
| Type Tags","IETF Multiple Source Tags" three subregistries in "YANG | Type Tags","IETF Multiple Source Tags" three subregistries in "YANG | |||
| Data Object Tag" registry. These 3 subregistries appear below "YANG | data node Tag" registry. These 3 subregistries appear below "YANG | |||
| Data Object Tag Prefixes" registry. | data node Tag Prefixes" registry. | |||
| Three subregistries allocate tags that have the registered prefix | Three subregistries allocate tags that have the registered prefix | |||
| "ietf:". New values should be well considered and not achievable | "ietf:". New values should be well considered and not achievable | |||
| through a combination of already existing IETF tags. | through a combination of already existing IETF tags. | |||
| The allocation policy for these three subregistries is IETF Review | The allocation policy for these three subregistries is IETF Review | |||
| [RFC8126]. The Designated Expert is expected to verify that IANA | [RFC8126]. The Designated Expert is expected to verify that IANA | |||
| assigned tags conform to Net-Unicode as defined in [RFC5198], and | assigned tags conform to Net-Unicode as defined in [RFC5198], and | |||
| shall not need normalization. | shall not need normalization. | |||
| The initial values for these three subregistries are as follows: | The initial values for these three subregistries are as follows: | |||
| +----------------------------+--------------------------+-----------+ | +----------------------------+--------------------------+-----------+ | |||
| | OPM Tag | Description | Reference | | | OPM Tag | Description | Reference | | |||
| +----------------------------+--------------------------+-----------+ | +----------------------------+--------------------------+-----------+ | |||
| | ietf:object |Represents Root object | [This | | | ietf:object |Represents Root object | [This | | |||
| | |containing other data | document] | | | |containing other data | document] | | |||
| | |objects (e.g., interfaces)| | | | |objects (e.g., interfaces)| | | |||
| | | | | | | | | | | |||
| | ietf:property |Represents a property | [This | | | ietf:property |Represents a property | [This | | |||
| | |data object(e.g., ifindex)| document] | | | |data node(e.g., ifindex) | document] | | |||
| | |associated with a specific| | | | |associated with a specific| | | |||
| | |root object (e.g., | | | | |root object (e.g., | | | |||
| | |interfaces) | | | | |interfaces) | | | |||
| | | | | | | | | | | |||
| | ietf:metric |Represent metric data | [This | | | ietf:metric |Represent metric data | [This | | |||
| | |object(e.g., ifstatistics)| document] | | | |object(e.g., ifstatistics)| document] | | |||
| | |associated with specific | | | | |associated with specific | | | |||
| | |root object(e.g., | | | | |root object(e.g., | | | |||
| | |interfaces) | | | | |interfaces) | | | |||
| +----------------------------+--------------------------+-----------+ | +----------------------------+--------------------------+-----------+ | |||
| +----------------------------+--------------------------+-----------+ | +----------------------------+--------------------------+-----------+ | |||
| | Metric Type Tag | Description | Reference | | | Metric Type Tag | Description | Reference | | |||
| +----------------------------+--------------------------+-----------+ | +----------------------------+--------------------------+-----------+ | |||
| | ietf:delay |Represents the delay metric | | | ietf:delay |Represents the delay metric | | |||
| | |group to which the metric | [This | | | |group to which the metric | [This | | |||
| | |data objects belong to. | document] | | | |data nodes belong to. | document] | | |||
| | | | | | | | | | | |||
| | ietf:jitter |Represents the jitter metric [This | | | ietf:jitter |Represents the jitter metric [This | | |||
| | |group to which the metric |document] | | | |group to which the metric |document] | | |||
| | |data objects belong to. | | | | |data nodes belong to. | | | |||
| | | | | | | | | | | |||
| | ietf:loss |Represents the loss metric| [This | | | ietf:loss |Represents the loss metric| [This | | |||
| | |group to which the metric | document] | | | |group to which the metric | document] | | |||
| | |data objects belong to. | | | | |data nodes belong to. | | | |||
| | | | | | | | | | | |||
| | ietf:counter |Represents any metric value | | | ietf:counter |Represents any metric value | | |||
| | |associated with a metric | | | | |associated with a metric | | | |||
| | |data object that monotonically[This | | | |data node that monotonically[This | | |||
| | |increases over time, | document] | | | |increases over time, | document] | | |||
| | |starting from zero. | | | | |starting from zero. | | | |||
| | | | | | | | | | | |||
| | ietf:gauge |Represents current | | | | ietf:gauge |Represents current | | | |||
| | |measurements associated | [This | | | |measurements associated | [This | | |||
| | |with a metric data object |document] | | | |with a metric data node |document] | | |||
| | |that may increase, | | | | |that may increase, | | | |||
| | |decrease or stay constant.| | | | |decrease or stay constant.| | | |||
| | | | | | | | | | | |||
| | ietf:summary |Represents the metric value [This | | | ietf:summary |Represents the metric value [This | | |||
| | |associated with a metric | document | | | |associated with a metric | document] | | |||
| | |data object that measures | | | | |data node that measures | | | |||
| | |distributions of discrete | | | | |distributions of discrete | | | |||
| | |events without knowing | | | | |events without knowing | | | |||
| | |predefined range. | | | | |predefined range. | | | |||
| | | | | | | | | | | |||
| | ietf:unknown |Represents the metric value [This | | | ietf:unknown |Represents the metric value [This | | |||
| | |associated with metric | document | | | |associated with metric | document] | | |||
| | |data object that can not | | | | |data node that can not | | | |||
| | |determine the type of metric. | | | |determine the type of metric. | | |||
| +----------------------------+--------------------------+-----------+ | +----------------------------+--------------------------+-----------+ | |||
| +----------------------------+--------------------------+-----------+ | +----------------------------+--------------------------+-----------+ | |||
| | Multiple Source Tag | Description | Reference | | | Multiple Source Tag | Description | Reference | | |||
| +----------------------------+--------------------------+-----------+ | +----------------------------+--------------------------+-----------+ | |||
| |ietf:agg |Relates to multiple sources [This | | |ietf:agg |Relates to multiple sources [This | | |||
| | |aggregation type (i.e., | document] | | | |aggregation type (i.e., | document] | | |||
| | |aggregated statistics) | | | | |aggregated statistics) | | | |||
| | | | | | | | | | | |||
| |ietf:non-agg |Relates to multiple sources [This | | |ietf:non-agg |Relates to multiple sources [This | | |||
| | |aggregation type (i.e., | document] | | | |aggregation type (i.e., | document] | | |||
| | |non-aggregated statistics)| | | | |non-aggregated statistics)| | | |||
| +----------------------------+--------------------------+-----------+ | +----------------------------+--------------------------+-----------+ | |||
| Figure 6: Table 2 | Figure 6: Table 2 | |||
| 9.3. Updates to the IETF XML Registry | 9.3. Updates to the IETF XML Registry | |||
| This document registers the following namespace URI in the "ns" | This document registers the following namespace URI in the "ns" | |||
| subregistry within the "IETF XML Registry" [RFC3688]: | subregistry within the "IETF XML Registry" [RFC3688]: | |||
| URI: urn:ietf:params:xml:ns:yang:ietf-data-object-tags | URI: urn:ietf:params:xml:ns:yang:ietf-data-node-tags | |||
| Registrant Contact: The IESG. | Registrant Contact: The IESG. | |||
| XML: N/A; the requested URI is an XML namespace. | XML: N/A; the requested URI is an XML namespace. | |||
| 9.4. Updates to the YANG Module Names Registry | 9.4. Updates to the YANG Module Names Registry | |||
| This document registers the following YANG module in the YANG Module | This document registers the following YANG module in the YANG Module | |||
| Names registry [RFC6020] within the "YANG Parameters" registry: | Names registry [RFC6020] within the "YANG Parameters" registry: | |||
| name: ietf-data-object-tags | name: ietf-data-node-tags | |||
| namespace: urn:ietf:params:xml:ns:yang:ietf-data-object-tags | namespace: urn:ietf:params:xml:ns:yang:ietf-data-node-tags | |||
| prefix: ntags | prefix: ntags | |||
| reference: RFC XXXX | reference: RFC XXXX | |||
| maintained by IANA: N | maintained by IANA: N | |||
| 10. Security Considerations | 10. Security Considerations | |||
| The YANG module specified in this document defines schema for data | The YANG module specified in this document defines schema for data | |||
| that is designed to be accessed via network management protocols such | that is designed to be accessed via network management protocols such | |||
| as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer | as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer | |||
| is the secure transport layer, and the mandatory-to-implement secure | is the secure transport layer, and the mandatory-to-implement secure | |||
| transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer | transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer | |||
| is HTTPS, and the mandatory-to-implement secure transport is TLS | is HTTPS, and the mandatory-to-implement secure transport is TLS | |||
| [RFC8446]. | [RFC8446]. | |||
| The Network Configuration Access Control Model (NACM) [RFC8341] | The Network Configuration Access Control Model (NACM) [RFC8341] | |||
| provides the means to restrict access for particular NETCONF or | provides the means to restrict access for particular NETCONF or | |||
| RESTCONF users to a preconfigured subset of all available NETCONF or | RESTCONF users to a preconfigured subset of all available NETCONF or | |||
| RESTCONF protocol operations and content, e.g., the presence of tags | RESTCONF protocol operations and content, e.g., the presence of tags | |||
| may reveal information about the way in which data objects are used | may reveal information about the way in which data nodes are used and | |||
| and therefore providing access to private information or revealing an | therefore providing access to private information or revealing an | |||
| attack vector should be restricted. Note that appropriate privilege | attack vector should be restricted. Note that appropriate privilege | |||
| and security levels need to be applied to the addition and removal of | and security levels need to be applied to the addition and removal of | |||
| user tags to ensure that a user receives the correct data. | user tags to ensure that a user receives the correct data. | |||
| This document adds the ability to associate data object tag meta-data | This document adds the ability to associate data node tag with data | |||
| with data object within the YANG modules. This document does not | nodes or instances of data nodes within the YANG modules. This | |||
| define any actions based on these associations, and none are yet | document does not define any actions based on these associations, and | |||
| defined, and therefore it does not by itself introduce any new | none are yet defined, and therefore it does not by itself introduce | |||
| security considerations. | any new security considerations. | |||
| Users of the data object tag meta-data may define various actions to | Users of the data node tag meta-data may define various actions to be | |||
| be taken based on the data object tag meta-data. These actions and | taken based on the data node tag meta-data. These actions and their | |||
| their definitions are outside the scope of this document. Users will | definitions are outside the scope of this document. Users will need | |||
| need to consider the security implications of any actions they choose | to consider the security implications of any actions they choose to | |||
| to define, including the potential for a tag to get 'masked' by | define, including the potential for a tag to get 'masked' by another | |||
| another user. | user. | |||
| 11. Acknowledgements | 11. Acknowledgements | |||
| The authors would like to thank Ran Tao for his major contributions | The authors would like to thank Ran Tao for his major contributions | |||
| to the initial modeling and use cases. | to the initial modeling and use cases. | |||
| The authors would also like to acknowledge the comments and | The authors would also like to acknowledge the comments and | |||
| suggestions received from Juergen Schoenwaelder, Andy Bierman, Lou | suggestions received from Juergen Schoenwaelder, Andy Bierman, Lou | |||
| Berger,Jaehoon Paul Jeong, Wei Wang, Yuan Zhang, Ander Liu, YingZhen | Berger,Jaehoon Paul Jeong, Wei Wang, Yuan Zhang, Ander Liu, YingZhen | |||
| Qu, Boyuan Yan, Adrian Farrel, and Mahesh Jethanandani. | Qu, Boyuan Yan, Adrian Farrel, and Mahesh Jethanandani. | |||
| 12. Contributors | 12. Contributors | |||
| Liang Geng | Liang Geng | |||
| China Mobile | Individual | |||
| 32 Xuanwumen West St, Xicheng District | 32 Xuanwumen West St, Xicheng District | |||
| Beijing 10053 | Beijing 10053 | |||
| Email: gengliang@chinamobile.com | ||||
| 13. References | 13. References | |||
| 13.1. Normative References | 13.1. Normative References | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
| DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
| <https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
| [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, | [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, | |||
| skipping to change at page 21, line 33 ¶ | skipping to change at page 22, line 5 ¶ | |||
| [RFC9195] Lengyel, B. and B. Claise, "A File Format for YANG | [RFC9195] Lengyel, B. and B. Claise, "A File Format for YANG | |||
| Instance Data", RFC 9195, DOI 10.17487/RFC9195, February | Instance Data", RFC 9195, DOI 10.17487/RFC9195, February | |||
| 2022, <https://www.rfc-editor.org/info/rfc9195>. | 2022, <https://www.rfc-editor.org/info/rfc9195>. | |||
| [RFC9196] Lengyel, B., Clemm, A., and B. Claise, "YANG Modules | [RFC9196] Lengyel, B., Clemm, A., and B. Claise, "YANG Modules | |||
| Describing Capabilities for Systems and Datastore Update | Describing Capabilities for Systems and Datastore Update | |||
| Notifications", RFC 9196, DOI 10.17487/RFC9196, February | Notifications", RFC 9196, DOI 10.17487/RFC9196, February | |||
| 2022, <https://www.rfc-editor.org/info/rfc9196>. | 2022, <https://www.rfc-editor.org/info/rfc9196>. | |||
| Appendix A. NETCONF Example | Appendix A. Example: Additional Auxiliary Data Property Information | |||
| This section gives an example of how Auxiliary Data Property Module | ||||
| could be defined. It demonstrates how auxiliary data property | ||||
| configuration parameters can be conditionally augmented to the | ||||
| generic data node list. The example is not intended as a complete | ||||
| module for Auxiliary Data Property configuration. | ||||
| module ex-auxiliary-data-property { | ||||
| yang-version 1.1; | ||||
| namespace "http://example.com/auxiliary-data-property"; | ||||
| prefix "dp"; | ||||
| import ietf-module-tags { | ||||
| prefix tags; | ||||
| } | ||||
| import ietf-data-node-tags { | ||||
| prefix ntags; | ||||
| } | ||||
| identity critical { | ||||
| base ntags:other-data-property; | ||||
| description | ||||
| "Identity for critical data node tag type."; | ||||
| } | ||||
| augment "/tags:module-tags/tags:module/ntags:data-node-tags/ntags:data-node" { | ||||
| when 'derived-from-or-self(ntags:extended-tag-type, "dp:critical")'; | ||||
| leaf value { | ||||
| type string; | ||||
| description | ||||
| "The auxiliary information corresponding | ||||
| to data node instance tagged with 'critical' | ||||
| extended tag type."; | ||||
| } | ||||
| // other auxiliary data property config params, etc. | ||||
| } | ||||
| } | ||||
| Appendix B. Instance Level Tunnel Tagging Example | ||||
| In the example shown in Figure 2,the 'tunnel-svc' data node is a list | ||||
| node defined in a 'example-tunnel-pm' module and has 7 child nodes: | ||||
| 'name','create-time','modified-time','average-latency','packet- | ||||
| loss','min-latency','max-latency' leaf node. In these child nodes, | ||||
| the 'name' leaf node is the key leaf for the 'tunnel-svc' list. | ||||
| Following is the tree diagram [RFC8340] for the "example-tunnel-pm" | ||||
| module: | ||||
| +--rw tunnel-svc* [name] | ||||
| | +--rw name string | ||||
| | +--ro create-time yang:date-and-time | ||||
| | +--ro modified-time yang:date-and-time | ||||
| | +--ro average-latency yang:gauge64 | ||||
| | +--ro packet-loss yang:counter64 | ||||
| | +--ro min-latency yang:gauge64 | ||||
| | +--ro max-latency yang:gauge64 | ||||
| To help identify specific data for a customer, users tags on specific | ||||
| instances of the data nodes are created as follows: | ||||
| <rpc message-id="103" | ||||
| xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> | ||||
| <edit-data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda" | ||||
| xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores"> | ||||
| <datastore>ds:running</datastore> | ||||
| <config> | ||||
| <module-tag> | ||||
| <module> | ||||
| <name>example-tunnel-pm</name> | ||||
| <data-node-tags xmlns="urn:ietf:params:xml:ns:yang:ietf-data-node-tags"> | ||||
| <data-node> | ||||
| <ni-id> | ||||
| /tp:tunnel-svc[name='foo']/tp:packet-loss | ||||
| </ni-id> | ||||
| <tag>user:customer1_example_com</tag> | ||||
| <tag>ietf:critical</tag> | ||||
| </data-node> | ||||
| <data-node> | ||||
| <ni-id> | ||||
| /tp:tunnel-svc[name='bar']/tp:modified-time | ||||
| </ni-id> | ||||
| <tag>user:customer2_example_com</tag> | ||||
| </data-node> | ||||
| </data-node-tags> | ||||
| </module> | ||||
| </module-tag> | ||||
| </config> | ||||
| </edit-data> | ||||
| </rpc> | ||||
| Note that the 'ietf:critical' tag is addtional new tag value that | ||||
| needs to be allocated from "IETF Metric Type Tags" subregistry in | ||||
| section 9.2. | ||||
| Appendix C. NETCONF Example | ||||
| The following is a NETCONF example result from a query of the data | The following is a NETCONF example result from a query of the data | |||
| object tags list. For the sake of brevity only a few module and | node tags list. For the sake of brevity only a few module and | |||
| associated data object results are provided. The example uses the | associated data node results are provided. The example uses the | |||
| folding defined in [RFC8792]. | folding defined in [RFC8792]. | |||
| =============== NOTE: '\' line wrapping per RFC 8792 ================ | =============== NOTE: '\' line wrapping per RFC 8792 ================ | |||
| <ns0:data xmlns:ns0="urn:ietf:params:xml:ns:netconf:base:1.0"> | <ns0:data xmlns:ns0="urn:ietf:params:xml:ns:netconf:base:1.0"> | |||
| <t:module-tags xmlns:t="urn:ietf:params:xml:ns:yang:ietf-module-tags"> | <t:module-tags xmlns:t="urn:ietf:params:xml:ns:yang:ietf-module-tags"> | |||
| <t:module> | <t:module> | |||
| <t:name>ietf-interfaces</t:name> | <t:name>ietf-interfaces</t:name> | |||
| <s:data-object-tags xmlns:s="urn:ietf:params:xml:ns:yang:ietf-\ | <s:data-node-tags xmlns:s="urn:ietf:params:xml:ns:yang:ietf-\ | |||
| data-object-tags"> | data-node-tags"> | |||
| <s:data-object> | <s:data-node> | |||
| <s:name>/if:interfaces/if:interface</s:name> | <s:ni-id>/if:interfaces/if:interface</s:ni-id> | |||
| <s:tag>ietf:object</s:tag> | <s:tag>ietf:object</s:tag> | |||
| </s:data-object> | </s:data-node> | |||
| <s:data-object> | <s:data-node> | |||
| <s:name>/if:interfaces/if:interface/if:last-change</\ | <s:ni-id>/if:interfaces/if:interface/if:last-change</\ | |||
| s:name> | s:ni-id> | |||
| <s:tag>ietf:property</s:tag> | <s:tag>ietf:property</s:tag> | |||
| </s:data-object> | </s:data-node> | |||
| <s:data-object> | <s:data-node> | |||
| <s:name> | <s:ni-id> | |||
| /if:interfaces/if:interface/if:statistics/if:in-errors | /if:interfaces/if:interface/if:statistics/if:in-errors | |||
| </s:name> | </s:ni-id> | |||
| <s:tag>ietf:metric</s:tag> | <s:tag>ietf:metric</s:tag> | |||
| <s:tag>ietf:loss</s:tag> | <s:tag>ietf:loss</s:tag> | |||
| <s:tag>ietf:non-agg</s:tag> | <s:tag>ietf:non-agg</s:tag> | |||
| </s:data-object> | </s:data-node> | |||
| </s:data-object-tags> | </s:data-node-tags> | |||
| </t:module> | </t:module> | |||
| <t:module> | <t:module> | |||
| <t:name>ietf-ip</t:name> | <t:ni-id>ietf-ip</t:ni-id> | |||
| <s:data-object-tags xmlns:s="urn:ietf:params:xml:ns:yang:ietf\ | <s:data-node-tags xmlns:s="urn:ietf:params:xml:ns:yang:ietf\ | |||
| -data-object-tags"> | -data-node-tags"> | |||
| <s:data-object> | <s:data-node> | |||
| <s:name>/if:interfaces/if:interface/ip:ipv4</s:name> | <s:ni-id>/if:interfaces/if:interface/ip:ipv4</s:ni-id> | |||
| <s:tag>ietf:object</s:tag> | <s:tag>ietf:object</s:tag> | |||
| </s:data-object> | </s:data-node> | |||
| <s:data-object> | <s:data-node> | |||
| <s:name>/if:interfaces/if:interface/ip:ipv4/ip:enable\ | <s:ni-id>/if:interfaces/if:interface/ip:ipv4/ip:enable\ | |||
| </s:name> | </s:ni-id> | |||
| <s:tag>ietf:property</s:tag> | <s:tag>ietf:property</s:tag> | |||
| </s:data-object> | </s:data-node> | |||
| <s:data-object> | <s:data-node> | |||
| <s:name>/if:interfaces/if:interface/ip:ipv4/ip:mtu</s:name> | <s:ni-id>/if:interfaces/if:interface/ip:ipv4/ip:mtu</s:ni-id> | |||
| <s:tag>ietf:metric</s:tag> | <s:tag>ietf:metric</s:tag> | |||
| <s:tag>ietf:non-agg</s:tag> | <s:tag>ietf:non-agg</s:tag> | |||
| </s:data-object> | </s:data-node> | |||
| </s:data-object-tags> | </s:data-node-tags> | |||
| </t:module> | </t:module> | |||
| </t:module-tags> | </t:module-tags> | |||
| </ns0:data> | </ns0:data> | |||
| Figure 7: Example NETCONF Query Output | Figure 7: Example NETCONF Query Output | |||
| Appendix B. Non-NMDA State Module | Appendix D. Non-NMDA State Module | |||
| As per [RFC8407], the following is a non-NMDA module to support | As per [RFC8407], the following is a non-NMDA module to support | |||
| viewing the operational state for non-NMDA compliant servers. | viewing the operational state for non-NMDA compliant servers. | |||
| <CODE BEGINS> file "ietf-data-object-tags-state@2022-02-03.yang" | <CODE BEGINS> file "ietf-data-node-tags-state@2022-02-03.yang" | |||
| module ietf-data-object-tags-state { | module ietf-data-node-tags-state { | |||
| yang-version 1.1; | yang-version 1.1; | |||
| namespace | namespace | |||
| "urn:ietf:params:xml:ns:yang:ietf-data-object-tags-state"; | "urn:ietf:params:xml:ns:yang:ietf-data-node-tags-state"; | |||
| prefix ntags-s; | prefix ntags-s; | |||
| import ietf-netconf-acm { | import ietf-netconf-acm { | |||
| prefix nacm; | prefix nacm; | |||
| reference | reference | |||
| "RFC 8341: Network Configuration Access Control | "RFC 8341: Network Configuration Access Control | |||
| Model"; | Model"; | |||
| } | } | |||
| import ietf-module-tags { | import ietf-module-tags { | |||
| prefix tags; | prefix tags; | |||
| } | ||||
| import ietf-module-tags-state { | ||||
| prefix tags-s; | ||||
| reference | reference | |||
| "RFC 8819: YANG Module Tags "; | "RFC 8819: YANG Module Tags "; | |||
| } | } | |||
| organization | organization | |||
| "IETF NetMod Working Group (NetMod)"; | "IETF NetMod Working Group (NetMod)"; | |||
| contact | contact | |||
| "WG Web: <https://datatracker.ietf.org/wg/netmod/> | "WG Web: <https://datatracker.ietf.org/wg/netmod/> | |||
| WG List:<mailto:netmod@ietf.org> | WG List:<mailto:netmod@ietf.org> | |||
| skipping to change at page 23, line 44 ¶ | skipping to change at page 26, line 14 ¶ | |||
| <mailto:benoit.claise@huawei.com> | <mailto:benoit.claise@huawei.com> | |||
| Editor: Peng Liu | Editor: Peng Liu | |||
| <mailto:liupengyjy@chinamobile.com> | <mailto:liupengyjy@chinamobile.com> | |||
| Editor: Zongpeng Du | Editor: Zongpeng Du | |||
| <mailto:duzongpeng@chinamobile.com> | <mailto:duzongpeng@chinamobile.com> | |||
| Editor: Mohamed Boucadair | Editor: Mohamed Boucadair | |||
| <mailto:mohamed.boucadair@orange.com>"; | <mailto:mohamed.boucadair@orange.com>"; | |||
| // RFC Ed.: replace XXXX with actual RFC number and | ||||
| // remove this note. | ||||
| description | description | |||
| "This module describes a mechanism associating self-describing | "This module describes a mechanism associating data node | |||
| tags with YANG data object within YANG modules. Tags may be | tags with YANG data node within YANG modules. Tags may be | |||
| IANA assigned or privately defined. | IANA assigned or privately defined. | |||
| Copyright (c) 2022 IETF Trust and the persons identified as | Copyright (c) 2022 IETF Trust and the persons identified as | |||
| authors of the code. All rights reserved. | authors of the code. All rights reserved. | |||
| Redistribution and use in source and binary forms, with or | Redistribution and use in source and binary forms, with or | |||
| without modification, is permitted pursuant to, and subject | without modification, is permitted pursuant to, and subject | |||
| to the license terms contained in, the Simplified BSD License | to the license terms contained in, the Simplified BSD License | |||
| set forth in Section 4.c of the IETF Trust's Legal Provisions | set forth in Section 4.c of the IETF Trust's Legal Provisions | |||
| Relating to IETF Documents | Relating to IETF Documents | |||
| (https://trustee.ietf.org/license-info). | (https://trustee.ietf.org/license-info). | |||
| This version of this YANG module is part of RFC XXXX | This version of this YANG module is part of RFC XXXX | |||
| (https://datatracker.ietf.org/html/rfcXXXX); see the RFC | (https://datatracker.ietf.org/html/rfcXXXX); see the RFC | |||
| itself for full legal notices."; | itself for full legal notices."; | |||
| // RFC Ed.: update the date below with the date of RFC publication | ||||
| // and RFC number and remove this note. | ||||
| revision 2022-02-04 { | revision 2022-02-04 { | |||
| description | description | |||
| "Initial revision."; | "Initial revision."; | |||
| reference | reference | |||
| "RFC XXXX: Self-Describing Data Object Tags in YANG Data | "RFC XXXX: Data node Tags in YANG Data | |||
| Models"; | Modules"; | |||
| } | ||||
| extension opm-tag { | ||||
| argument tag; | ||||
| description | ||||
| "The argument 'tag' is of type 'tag'. This extension | ||||
| statement is used by module authors to indicate the opm tags | ||||
| that should be added automatically by the system. 'opm-tag' | ||||
| is used to classify operation and management data objects | ||||
| into the three categories, object, property, and metric. | ||||
| Data Object can contain other data objects called subobjects. | ||||
| Both object and subobjects can be modeled as data nodes. The | ||||
| Data Object tagged with object tag can be one of container, | ||||
| leaf-list and list. The Data Object tagged with the Property | ||||
| tag is a leaf node. The Data Object tagged with the Metric | ||||
| tag can be one of type container, leaf-list, list, leaf. The | ||||
| Data objects tagged with either property tag or metric tag | ||||
| are subobjects belonging to a specific root data object. Each | ||||
| Data Object may contain one single object tag, or one single | ||||
| property tag, or one single metric tag (these tags are | ||||
| mutually exclusive). As such, the origin of the value for the | ||||
| pre-defined tags should be set to 'system'."; | ||||
| } | } | |||
| extension metric-type { | identity other-data-property { | |||
| argument tag; | description | |||
| description | "Base identity for data property type."; | |||
| "The argument 'tag' is of type 'tag'.The metric-type can be | ||||
| used to provide metric subobject classification | ||||
| (e.g., loss, jitter, packet loss, guage, counter, histogram, | ||||
| unknow, etc.) within the YANG module."; | ||||
| } | } | |||
| extension multi-source-tag { | augment "/tags-s:module-tags-state/tags-s:module" { | |||
| argument tag; | ||||
| description | ||||
| "The argument 'tag' is of type 'tag'. The multi-source tag can | ||||
| be used to identify multi-source aggregation type (e.g., | ||||
| aggregated, non-aggregated) related to a metric subobject. | ||||
| The 'aggregated' multi-source aggregation type allows a large | ||||
| number of measurements on metric subobjects from different | ||||
| sources of the same type (e.g., line card, each subinterface | ||||
| of aggregated Ethernet interface) to be combined into | ||||
| aggregated statistics and reported as one metric subobject | ||||
| value. | ||||
| The 'non-aggregated'multi-source aggregation type | ||||
| allows measurement from each source of the same type | ||||
| (e.g., line card, each subinterface of aggregated Ethernet | ||||
| interface) to be reported separately."; | ||||
| } | ||||
| augment "/tags:module-tags/tags:module" { | ||||
| description | description | |||
| "Augments the Module Tags module with data object tag | "Augments the Module Tags module with data node tag | |||
| attributes."; | attributes."; | |||
| container data-object-tags { | ||||
| container data-node-tags { | ||||
| config false; | config false; | |||
| status deprecated; | status deprecated; | |||
| description | description | |||
| "Contains the list of data objects and their | "Contains the list of data nodes and their | |||
| associated self describing tags."; | associated self describing tags."; | |||
| list data-object { | list data-node { | |||
| key "name"; | key "ni-id"; | |||
| status deprecated; | status deprecated; | |||
| description | description | |||
| "Lists the data objects and their associated self | "Lists the data nodes and their associated self | |||
| describing tags."; | describing tags."; | |||
| leaf name { | leaf ni-id { | |||
| type nacm:node-instance-identifier; | type nacm:node-instance-identifier; | |||
| mandatory true; | mandatory true; | |||
| status deprecated; | status deprecated; | |||
| description | description | |||
| "The YANG data object name."; | "The YANG data node name."; | |||
| } | } | |||
| leaf-list tag { | leaf-list tag { | |||
| type tags:tag; | type tags:tag; | |||
| status deprecated; | status deprecated; | |||
| description | description | |||
| "Tags associated with the data object within the | "Tags associated with the data node within the | |||
| YANG module. See the IANA 'YANG Data Object Tag | YANG module. See the IANA 'YANG data node Tag | |||
| Prefixes' registry for reserved prefixes and the | Prefixes' registry for reserved prefixes and the | |||
| IANA 'IETF YANG Data Object Tags'registry for | IANA 'IETF YANG data node Tags'registry for | |||
| IETF tags. | IETF tags. | |||
| The 'operational' state view of this list is | The 'operational' state view of this list is | |||
| constructed using the following steps: | constructed using the following steps: | |||
| 1) System tags (i.e., tags of 'system' origin) are | 1) System tags (i.e., tags of 'system' origin) are | |||
| added. | added. | |||
| 2) User configured tags (i.e., tags of 'intended' | 2) User configured tags (i.e., tags of 'intended' | |||
| origin) are added. | origin) are added. | |||
| 3) Any tag that is equal to a masked-tag is removed."; | 3) Any tag that is equal to a masked-tag is removed."; | |||
| reference | reference | |||
| "RFC XXXX: Self-Describing Data Object Tags in YANG Data | "RFC XXXX: Data node Tags in YANG Data | |||
| Models, Section 9"; | Modules, Section 9"; | |||
| } | } | |||
| leaf-list masked-tag { | leaf-list masked-tag { | |||
| type tags:tag; | type tags:tag; | |||
| status deprecated; | status deprecated; | |||
| description | description | |||
| "The list of tags that should not be associated with the | "The list of tags that should not be associated with the | |||
| data object within the YANG module. The user can remove | data node within the YANG module. The user can remove | |||
| (mask) tags from the operational state datastore by | (mask) tags from the operational state datastore by | |||
| adding them to this list. It is not an error to add | adding them to this list. It is not an error to add | |||
| tags to this list that are not associated with the | tags to this list that are not associated with the | |||
| data object within YANG module, but they have no | data node within YANG module, but they have no | |||
| operational effect."; | operational effect."; | |||
| } | } | |||
| leaf extended-tag-type { | ||||
| type identityref { | ||||
| base other-data-property; | ||||
| } | ||||
| description | ||||
| "Type of the extended tag. The extended tag type doesn't | ||||
| include opm tag, metric-type tag and multi-source tag three | ||||
| types defined in this document. The specific extended tag | ||||
| type and associated auxiliary data are defined in the data | ||||
| node tags extension module."; | ||||
| } | ||||
| } | } | |||
| } | } | |||
| } | } | |||
| } | } | |||
| <CODE ENDS> | <CODE ENDS> | |||
| Appendix C. Targeted data object collection example | Appendix E. Targeted Data Fetching Example | |||
| The following provides targeted data object collection example which | The following provides targeted data node collection example which | |||
| helps reduce amount of data to be fetched. The subscription "id" | helps reduce amount of data to be fetched. The subscription "id" | |||
| values of 22 used below is just an example. In production, the | values of 22 used below is just an example. In production, the | |||
| actual values of "id" might not be small integers. | actual values of "id" might not be small integers. | |||
| +-----------+ +-----------+ | +-----------+ +-----------+ | |||
| | Subscriber| | Publisher | | | Subscriber| | Publisher | | |||
| +-----+-----+ +-----+-----+ | +-----+-----+ +-----+-----+ | |||
| | | | | | | |||
| |Telemery data Tagging Advertisement | | | data Node Tagging Fetching | | |||
| |(data object name, opm-tag = metric)| | | (ni-id, opm-tag = metric) | | |||
| |<-----------------------------------+ | |<-----------------------------------+ | |||
| | | | | | | |||
| | establish-subscription | | | establish-subscription | | |||
| +----------------------------------->| | +----------------------------------->| | |||
| | | | | | | |||
| | RPC Reply: OK, id = 22 | | | RPC Reply: OK, id = 22 | | |||
| |<-----------------------------------+ | |<-----------------------------------+ | |||
| | | | | | | |||
| | Notification Message (for 22) | | | Notification Message (for 22) | | |||
| |<-----------------------------------+ | |<-----------------------------------+ | |||
| | | | | | | |||
| The publisher advertises telemetry data object capability to the | The subscriber fetches data node tag information from the provider | |||
| subscriber to instruct the receiver to subscribe tagged data object | using 'get-schema' operation. The data node tag information instruct | |||
| (e.g., performance metric data object) using standard subscribed | the receiver to subscribe tagged data node (e.g., performance metric | |||
| notification mechanism [RFC8639]. The corresponding telemetry data | data nodes) using standard subscribed notification mechanism | |||
| object capability model is created based on ietf-data-object-tags | [RFC8639]. | |||
| module defined in this document. | ||||
| Figure 8 illustrates the advertisment of the list of available target | Figure 8 illustrates the retrieval of the list of available target | |||
| objects using the YANG instance file format [RFC9195]: | data nodes using the YANG instance file format [RFC9195]: | |||
| =============== NOTE: '\' line wrapping per RFC 8792 ================ | =============== NOTE: '\' line wrapping per RFC 8792 ================ | |||
| <?xml version="1.0" encoding="UTF-8"?> | <?xml version="1.0" encoding="UTF-8"?> | |||
| <instance-data-set xmlns=\ | <instance-data-set xmlns=\ | |||
| "urn:ietf:params:xml:ns:yang:ietf-yang-instance-data"> | "urn:ietf:params:xml:ns:yang:ietf-yang-instance-data"> | |||
| <name>acme-router-notification-capabilities</name> | <name>acme-router-notification-capabilities</name> | |||
| <content-schema> | <content-schema> | |||
| <module>ietf-system-capabilities@2020-03-23</module> | <module>ietf-system-capabilities@2020-03-23</module> | |||
| <module>ietf-notification-capabilities@2020-03-23</module> | <module>ietf-notification-capabilities@2020-03-23</module> | |||
| <module>ietf-data-export-capabilities@2020-03-23</module> | <module>ietf-data-export-capabilities@2020-03-23</module> | |||
| </content-schema> | </content-schema> | |||
| <!-- revision date, contact, etc. --> | <!-- revision date, contact, etc. --> | |||
| <description>Defines the notification capabilities of an | <description>Defines the notification capabilities of an | |||
| acme-router.The router only has running, and operational | acme-router.The router only has running, and operational | |||
| datastores. Every change can be reported on-change from | datastores. Every change can be reported on-change from | |||
| running, but only config=true nodes and some config=false data | running, but only config=true nodes and some config=false data | |||
| from operational. Statistics are not reported based on timer | from operational. Statistics are not reported based on timer | |||
| based trigger and counter threshold based trigger. | based trigger and counter threshold based trigger. | |||
| </description> | </description> | |||
| <content-data> | <content-data> | |||
| <system-capabilities \ | <t:module-tags xmlns:t="urn:ietf:params:xml:ns:yang:ietf-\ | |||
| xmlns="urn:ietf:params:xml:ns:yang:ietf-system-capabilities" \ | module-tags"> | |||
| xmlns:inc=\ | <t:module> | |||
| "urn:ietf:params:xml:ns:yang:ietf-notification-capabilities" \ | <t:name>ietf-interfaces</t:name> | |||
| xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores"> | <s:data-node-tags xmlns:s="urn:ietf:params:xml:ns:yang:ietf-\ | |||
| <datastore-capabilities> | data-node-tags"> | |||
| <datastore>ds:operational</datastore> | <s:data-node> | |||
| <per-node-capabilities> | <s:ni-id>/if:interfaces/if:interface/if:in-errors</s:ni-id> | |||
| <node-selector>\ | <s:opm-tag>ietf:metric</s:opm-tag> | |||
| /if:interfaces/if:interface/if:statistics/if:in-errors\ | <s:metric-type>ietf:loss</s:metric-type> | |||
| </node-selector> | </s:data-node> | |||
| <sec:self-describing-capabilities> | </s:data-node-tags> | |||
| <sec:opm-tag>metric</sec:opm-tag> | </t:module> | |||
| <sec:metric-type>loss</sec:metric-type> | </content-data> | |||
| </sec:self-describing-capabilities> | </instance-data-set> | |||
| </per-node-capabilities> | ||||
| </datastore-capabilities> | ||||
| </system-capabilities> | ||||
| </content-data> | ||||
| </instance-data-set> | ||||
| Figure 8: List of Available Target Objects | Figure 8: List of Available Target Objects | |||
| With telemetry data tagging information carried in the telemetry data | With data node tag information carried in the <get-schema> operation, | |||
| tagging Advertisement, the subscriber identifies targeted data object | the subscriber identifies targeted data node and associated data path | |||
| and associated data path to the datastore node and sends a standard | to the datastore node and sends a standard establish-subscription RPC | |||
| establish-subscription RPC [RFC8639] to subscribe tagged data objects | [RFC8639] to subscribe tagged data nodes that are interests to the | |||
| that are interests to the client application from the publisher. | client application from the publisher. Alternatively, the subscriber | |||
| Alternatively, the subscriber can query data object tag list from | can query data node tag list from somewhere (e.g., the network | |||
| somewhere (e.g., the network device, or offline document) using ietf- | device, or offline document) using ietf-data-node-tags module defined | |||
| data-object-tags module defined in this document and fetch tagged | in this document and fetch tagged data nodes and associated data path | |||
| data objects and associated data path to the datastore node and sends | to the datastore node and sends a standard establish-subscription RPC | |||
| a standard establish-subscription RPC [RFC8639] to subscribe tagged | [RFC8639] to subscribe tagged data nodes that are interests to the | |||
| data objects that are interests to the client application from the | client application from the publisher. | |||
| publisher. | ||||
| =============== NOTE: '\' line wrapping per RFC 8792 ================ | =============== NOTE: '\' line wrapping per RFC 8792 ================ | |||
| <netconf:rpc message-id="101" | <netconf:rpc message-id="101" | |||
| xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"> | xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"> | |||
| <establish-subscription | <establish-subscription | |||
| xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifica\ | xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifica\ | |||
| tions" | tions" | |||
| xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-yang-push"> | xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-yang-push"> | |||
| <yp:datastore | <yp:datastore | |||
| skipping to change at page 29, line 38 ¶ | skipping to change at page 30, line 42 ¶ | |||
| </yp:datastore-xpath-filter> | </yp:datastore-xpath-filter> | |||
| <yp:periodic> | <yp:periodic> | |||
| <yp:period>500</yp:period> | <yp:period>500</yp:period> | |||
| </yp:periodic> | </yp:periodic> | |||
| </establish-subscription> | </establish-subscription> | |||
| </netconf:rpc> | </netconf:rpc> | |||
| The publisher returns specific object types of operational state | The publisher returns specific object types of operational state | |||
| (e.g., in-errors statistics data) subscribed by the client. | (e.g., in-errors statistics data) subscribed by the client. | |||
| Appendix D. Changes between Revisions | Appendix F. Changes between Revisions | |||
| Editorial Note (To be removed by RFC Editor) | Editorial Note (To be removed by RFC Editor) | |||
| v06 - v07 | ||||
| * Update use case in section 3 to remove object and subobject | ||||
| concept and massive related words. | ||||
| * Change the title into Data Node Tags in YANG Modules. | ||||
| * Update Model Tag design in section 5.1 based on Balazs's comments. | ||||
| * Add Instance level tunnel tagging example in the Appendix. | ||||
| * Add 'type' parameter in the base model and add one more model | ||||
| extension example in the Appendix. | ||||
| * Other Appendix Updates. | ||||
| v05 - v06 | v05 - v06 | |||
| * Additional Editorial changes; | * Additional Editorial changes; | |||
| * Use the folding defined in [RFC8792]. | * Use the folding defined in [RFC8792]. | |||
| v04 - v05 | v04 - v05 | |||
| * Add user tag formating clarification; | * Add user tag formating clarification; | |||
| * Provide guidance to the Designated Expert for evaluation of YANG | * Provide guidance to the Designated Expert for evaluation of YANG | |||
| Data Object Tag registry and YANG Data Object Tag prefix registry. | data node Tag registry and YANG data node Tag prefix registry. | |||
| * Update the figure 1 and figure 2 with additional tags. | * Update the figure 1 and figure 2 with additional tags. | |||
| * Security section enhancement for user tag managment. | * Security section enhancement for user tag managment. | |||
| * Change data object name into name in the module. | * Change data node name into name in the module. | |||
| * Other Editorial changes to address Adrian's comments and comments | * Other Editorial changes to address Adrian's comments and comments | |||
| during YANG docotor review. | during YANG docotor review. | |||
| * Open issue: Are there any risks associated with an attacker adding | * Open issue: Are there any risks associated with an attacker adding | |||
| or removing tags so that a requester gets the wrong data? | or removing tags so that a requester gets the wrong data? | |||
| v03 - v04 | v03 - v04 | |||
| * Remove histogram metric type tag from metric type tags. | * Remove histogram metric type tag from metric type tags. | |||
| * Clarify the object tag and property tag,metric tag are mutual | * Clarify the object tag and property tag,metric tag are mutual | |||
| exlusive. | exlusive. | |||
| * Clarify to have two optional node tags (i.e.,object tag and | * Clarify to have two optional node tags (i.e.,object tag and | |||
| property tag) to indicate relationship between data objects. | property tag) to indicate relationship between data nodes. | |||
| * Update targeted data object collection example. | * Update targeted data node collection example. | |||
| v02 - v03 | v02 - v03 | |||
| * Additional Editorial changes. | * Additional Editorial changes. | |||
| * Security section enhancement. | * Security section enhancement. | |||
| * Nits fixed. | * Nits fixed. | |||
| v01 - v02 | v01 - v02 | |||
| * Clarify the relation between data object, object tag, property tag | * Clarify the relation between data node, object tag, property tag | |||
| and metric tag in figure 1 and figure 2 and related description; | and metric tag in figure 1 and figure 2 and related description; | |||
| * Change Metric Group into Metric Type in the YANG model; | * Change Metric Group into Metric Type in the YANG model; | |||
| * Add 5 metric types in section 7.2; | * Add 5 metric types in section 7.2; | |||
| v00 - v01 | v00 - v01 | |||
| * Merge self-describing data object tag use case section into | * Merge data node tag use case section into introduction section as | |||
| introduction section as a subsection; | a subsection; | |||
| * Add one glossary section; | * Add one glossary section; | |||
| * Clarify the relation between data object, object tag, property tag | * Clarify the relation between data node, object tag, property tag | |||
| and metric tag in Self-Describing Data Object Tags Use Case | and metric tag in data node Tags Use Case section; | |||
| section; | ||||
| * Add update to RFC8407 in the front page. | * Add update to RFC8407 in the front page. | |||
| Authors' Addresses | Authors' Addresses | |||
| Qin Wu | Qin Wu | |||
| Huawei | Huawei | |||
| 101 Software Avenue, Yuhua District | 101 Software Avenue, Yuhua District | |||
| Nanjing | Nanjing | |||
| Jiangsu, 210012 | Jiangsu, 210012 | |||
| End of changes. 164 change blocks. | ||||
| 432 lines changed or deleted | 530 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||