--- 1/draft-ietf-netmod-module-tags-09.txt 2020-02-29 19:13:14.055990391 -0800 +++ 2/draft-ietf-netmod-module-tags-10.txt 2020-02-29 19:13:14.095991392 -0800 @@ -1,21 +1,21 @@ Network Working Group C. Hopps Internet-Draft LabN Consulting, L.L.C. Updates: 8407 (if approved) L. Berger Intended status: Standards Track LabN Consulting, LLC. -Expires: March 28, 2020 D. Bogdanovic +Expires: September 1, 2020 D. Bogdanovic Volta Networks - September 25, 2019 + February 29, 2020 YANG Module Tags - draft-ietf-netmod-module-tags-09 + draft-ietf-netmod-module-tags-10 Abstract This document provides for the association of tags with YANG modules. The expectation is for such tags to be used to help classify and organize modules. A method for defining, reading and writing a modules tags is provided. Tags may be registered and assigned during module definition; assigned by implementations; or dynamically defined and set by users. This document also provides guidance to future model writers; as such, this document updates RFC8407. @@ -28,25 +28,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on March 28, 2020. + This Internet-Draft will expire on September 1, 2020. Copyright Notice - Copyright (c) 2019 IETF Trust and the persons identified as the + Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -74,21 +74,21 @@ 6.1. Define Standard Tags . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7.1. YANG Module Tag Prefixes Registry . . . . . . . . . . . . 9 7.2. IETF YANG Module Tags Registry . . . . . . . . . . . . . 10 7.3. Updates to the IETF XML Registry . . . . . . . . . . . . 12 7.4. Updates to the YANG Module Names Registry . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . 14 - Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 14 + Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 15 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 15 Appendix C. Non-NMDA State Module. . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction The use of tags for classification and organization is fairly ubiquitous not only within IETF protocols, but in the internet itself (e.g., "#hashtags"). One benefit of using tags for organization over a rigid structure is that it is more flexible and can more easily @@ -243,21 +243,21 @@ +--rw module-tags +--rw module* [name] +--rw name yang:yang-identifier +--rw tag* tag +--rw masked-tag* tag Figure 1: YANG Module Tags Tree Diagram 4.2. YANG Module - file "ietf-module-tags@2019-09-25.yang" + file "ietf-module-tags@2020-02-29.yang" module ietf-module-tags { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-module-tags"; prefix tags; import ietf-yang-types { prefix yang; } organization @@ -298,21 +298,21 @@ The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here."; // RFC Ed.: update the date below with the date of RFC publication // and RFC number and remove this note. - revision 2019-09-25 { + revision 2020-02-29 { description "Initial revision."; reference "RFC XXXX: YANG Module Tags"; } typedef tag { type string { length "1..max"; pattern '[\S ]+'; } @@ -449,21 +449,23 @@ 7.2. IETF YANG Module Tags Registry IANA is asked to create a new registry "IETF YANG Module Tags" grouped under a new "Protocol" category "IETF YANG Module Tags". This registry should be included below "YANG Module Tag Prefixes" when listed on the same page. This registry allocates tags that have the registered prefix "ietf:". New values should be well considered and not achievable through a - combination of already existing IETF tags. + combination of already existing IETF tags. IANA assigned tags must + conform to Net-Unicode as defined in [RFC5198] and they shall not + need normalization. The allocation policy for this registry is IETF Review [RFC8126]. The initial values for this registry are as follows. +----------------------------+--------------------------+-----------+ | Tag | Description | Reference | +----------------------------+--------------------------+-----------+ | ietf:network-element-class | [RFC8199] network | [RFC8199] | | | element. | | @@ -582,26 +584,27 @@ 8. Security Considerations The YANG module defined in this memo is designed to be accessed via the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure transport layer and the mandatory-to-implement secure transport is SSH [RFC6242]. This document adds the ability to associate tag meta-data with YANG modules. This document does not define any actions based on these associations, and none are yet defined, and therefore it does not by - itself introduce any new security considerations. + itself introduce any new security considerations directly. Users of the tag-meta data may define various actions to be taken based on the tag meta-data. These actions and their definitions are outside the scope of this document. Users will need to consider the - security implications of any actions they choose to define. + security implications of any actions they choose to define, including + the potential for a tag to get 'masked' by another user. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . @@ -631,20 +634,24 @@ Documents Containing YANG Data Models", BCP 216, RFC 8407, DOI 10.17487/RFC8407, October 2018, . 9.2. Informative References [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . + [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network + Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, + . + [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . @@ -694,21 +701,21 @@ Special thanks to Robert Wilton for his help improving the introduction and providing the example use cases, as well as generating the non-NMDA module. Appendix C. Non-NMDA State Module. As per [RFC8407] the following is a non-NMDA module to support viewing the operational state for non-NMDA compliant servers. - file "ietf-module-tags-state@2019-09-25.yang" + file "ietf-module-tags-state@2020-02-29.yang" module ietf-module-tags-state { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-module-tags-state"; prefix tags-s; import ietf-yang-types { prefix yang; } import ietf-module-tags { prefix tags; @@ -755,21 +762,21 @@ The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here."; // RFC Ed.: update the date below with the date of RFC publication // and RFC number and remove this note. - revision 2019-09-25 { + revision 2020-02-29 { description "Initial revision."; reference "RFC XXXX: YANG Module Tags"; } container module-tags-state { config false; status deprecated; description