draft-ietf-netmod-module-tags-09.txt   draft-ietf-netmod-module-tags-10.txt 
Network Working Group C. Hopps Network Working Group C. Hopps
Internet-Draft LabN Consulting, L.L.C. Internet-Draft LabN Consulting, L.L.C.
Updates: 8407 (if approved) L. Berger Updates: 8407 (if approved) L. Berger
Intended status: Standards Track LabN Consulting, LLC. Intended status: Standards Track LabN Consulting, LLC.
Expires: March 28, 2020 D. Bogdanovic Expires: September 1, 2020 D. Bogdanovic
Volta Networks Volta Networks
September 25, 2019 February 29, 2020
YANG Module Tags YANG Module Tags
draft-ietf-netmod-module-tags-09 draft-ietf-netmod-module-tags-10
Abstract Abstract
This document provides for the association of tags with YANG modules. This document provides for the association of tags with YANG modules.
The expectation is for such tags to be used to help classify and The expectation is for such tags to be used to help classify and
organize modules. A method for defining, reading and writing a organize modules. A method for defining, reading and writing a
modules tags is provided. Tags may be registered and assigned during modules tags is provided. Tags may be registered and assigned during
module definition; assigned by implementations; or dynamically module definition; assigned by implementations; or dynamically
defined and set by users. This document also provides guidance to defined and set by users. This document also provides guidance to
future model writers; as such, this document updates RFC8407. future model writers; as such, this document updates RFC8407.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 March 28, 2020. This Internet-Draft will expire on September 1, 2020.
Copyright Notice 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. 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 39 skipping to change at page 2, line 39
6.1. Define Standard Tags . . . . . . . . . . . . . . . . . . 9 6.1. Define Standard Tags . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7.1. YANG Module Tag Prefixes Registry . . . . . . . . . . . . 9 7.1. YANG Module Tag Prefixes Registry . . . . . . . . . . . . 9
7.2. IETF YANG Module Tags Registry . . . . . . . . . . . . . 10 7.2. IETF YANG Module Tags Registry . . . . . . . . . . . . . 10
7.3. Updates to the IETF XML Registry . . . . . . . . . . . . 12 7.3. Updates to the IETF XML Registry . . . . . . . . . . . . 12
7.4. Updates to the YANG Module Names Registry . . . . . . . . 12 7.4. Updates to the YANG Module Names Registry . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 14 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 15
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 15 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 15
Appendix C. Non-NMDA State Module. . . . . . . . . . . . . . . . 15 Appendix C. Non-NMDA State Module. . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
The use of tags for classification and organization is fairly The use of tags for classification and organization is fairly
ubiquitous not only within IETF protocols, but in the internet itself ubiquitous not only within IETF protocols, but in the internet itself
(e.g., "#hashtags"). One benefit of using tags for organization over (e.g., "#hashtags"). One benefit of using tags for organization over
a rigid structure is that it is more flexible and can more easily a rigid structure is that it is more flexible and can more easily
skipping to change at page 6, line 23 skipping to change at page 6, line 23
+--rw module-tags +--rw module-tags
+--rw module* [name] +--rw module* [name]
+--rw name yang:yang-identifier +--rw name yang:yang-identifier
+--rw tag* tag +--rw tag* tag
+--rw masked-tag* tag +--rw masked-tag* tag
Figure 1: YANG Module Tags Tree Diagram Figure 1: YANG Module Tags Tree Diagram
4.2. YANG Module 4.2. YANG Module
<CODE BEGINS> file "ietf-module-tags@2019-09-25.yang" <CODE BEGINS> file "ietf-module-tags@2020-02-29.yang"
module ietf-module-tags { module ietf-module-tags {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-module-tags"; namespace "urn:ietf:params:xml:ns:yang:ietf-module-tags";
prefix tags; prefix tags;
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
} }
organization organization
skipping to change at page 7, line 29 skipping to change at page 7, line 29
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as 'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here."; they appear in all capitals, as shown here.";
// RFC Ed.: update the date below with the date of RFC publication // RFC Ed.: update the date below with the date of RFC publication
// and RFC number and remove this note. // and RFC number and remove this note.
revision 2019-09-25 { revision 2020-02-29 {
description description
"Initial revision."; "Initial revision.";
reference "RFC XXXX: YANG Module Tags"; reference "RFC XXXX: YANG Module Tags";
} }
typedef tag { typedef tag {
type string { type string {
length "1..max"; length "1..max";
pattern '[\S ]+'; pattern '[\S ]+';
} }
skipping to change at page 10, line 37 skipping to change at page 10, line 37
7.2. IETF YANG Module Tags Registry 7.2. IETF YANG Module Tags Registry
IANA is asked to create a new registry "IETF YANG Module Tags" IANA is asked to create a new registry "IETF YANG Module Tags"
grouped under a new "Protocol" category "IETF YANG Module Tags". grouped under a new "Protocol" category "IETF YANG Module Tags".
This registry should be included below "YANG Module Tag Prefixes" This registry should be included below "YANG Module Tag Prefixes"
when listed on the same page. when listed on the same page.
This registry allocates tags that have the registered prefix "ietf:". This registry allocates tags that have the registered prefix "ietf:".
New values should be well considered and not achievable through a 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 allocation policy for this registry is IETF Review [RFC8126].
The initial values for this registry are as follows. The initial values for this registry are as follows.
+----------------------------+--------------------------+-----------+ +----------------------------+--------------------------+-----------+
| Tag | Description | Reference | | Tag | Description | Reference |
+----------------------------+--------------------------+-----------+ +----------------------------+--------------------------+-----------+
| ietf:network-element-class | [RFC8199] network | [RFC8199] | | ietf:network-element-class | [RFC8199] network | [RFC8199] |
| | element. | | | | element. | |
skipping to change at page 13, line 25 skipping to change at page 13, line 28
8. Security Considerations 8. Security Considerations
The YANG module defined in this memo is designed to be accessed via The YANG module defined in this memo is designed to be accessed via
the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the
secure transport layer and the mandatory-to-implement secure secure transport layer and the mandatory-to-implement secure
transport is SSH [RFC6242]. transport is SSH [RFC6242].
This document adds the ability to associate tag meta-data with YANG This document adds the ability to associate tag meta-data with YANG
modules. This document does not define any actions based on these modules. This document does not define any actions based on these
associations, and none are yet defined, and therefore it does not by 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 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 based on the tag meta-data. These actions and their definitions are
outside the scope of this document. Users will need to consider the 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. References
9.1. Normative References 9.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>.
skipping to change at page 14, line 25 skipping to change at page 14, line 29
Documents Containing YANG Data Models", BCP 216, RFC 8407, Documents Containing YANG Data Models", BCP 216, RFC 8407,
DOI 10.17487/RFC8407, October 2018, DOI 10.17487/RFC8407, October 2018,
<https://www.rfc-editor.org/info/rfc8407>. <https://www.rfc-editor.org/info/rfc8407>.
9.2. Informative References 9.2. Informative References
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008,
<https://www.rfc-editor.org/info/rfc5198>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
skipping to change at page 15, line 44 skipping to change at page 15, line 50
Special thanks to Robert Wilton for his help improving the Special thanks to Robert Wilton for his help improving the
introduction and providing the example use cases, as well as introduction and providing the example use cases, as well as
generating the non-NMDA module. generating the non-NMDA module.
Appendix C. Non-NMDA State Module. Appendix C. 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-module-tags-state@2019-09-25.yang" <CODE BEGINS> file "ietf-module-tags-state@2020-02-29.yang"
module ietf-module-tags-state { module ietf-module-tags-state {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-module-tags-state"; namespace "urn:ietf:params:xml:ns:yang:ietf-module-tags-state";
prefix tags-s; prefix tags-s;
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
} }
import ietf-module-tags { import ietf-module-tags {
prefix tags; prefix tags;
skipping to change at page 17, line 8 skipping to change at page 17, line 14
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as 'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here."; they appear in all capitals, as shown here.";
// RFC Ed.: update the date below with the date of RFC publication // RFC Ed.: update the date below with the date of RFC publication
// and RFC number and remove this note. // and RFC number and remove this note.
revision 2019-09-25 { revision 2020-02-29 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: YANG Module Tags"; "RFC XXXX: YANG Module Tags";
} }
container module-tags-state { container module-tags-state {
config false; config false;
status deprecated; status deprecated;
description description
 End of changes. 14 change blocks. 
13 lines changed or deleted 20 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/