draft-ietf-netmod-module-tags-01.txt   draft-ietf-netmod-module-tags-02.txt 
Network Working Group C. Hopps Network Working Group C. Hopps
Internet-Draft Deutsche Telekom Internet-Draft Deutsche Telekom
Updates: rfc6087bis (if approved) L. Berger Updates: rfc6087bis (if approved) L. Berger
Intended status: Standards Track LabN Consulting, L.L.C. Intended status: Standards Track LabN Consulting, L.L.C.
Expires: September 7, 2018 D. Bogdanovic Expires: January 1, 2019 D. Bogdanovic
March 6, 2018 June 30, 2018
YANG Module Tags YANG Module Tags
draft-ietf-netmod-module-tags-01 draft-ietf-netmod-module-tags-02
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 standardized and assigned modules tags is provided. Tags may be standardized and assigned
during module definition; assigned by implementations; or dynamically during module definition; assigned by implementations; or dynamically
defined and set by users. This document provides guidance to future defined and set by users. This document provides guidance to future
model writers and, as such, this document updates model writers and, as such, this document updates
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 September 7, 2018. This Internet-Draft will expire on January 1, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
skipping to change at page 2, line 25 skipping to change at page 2, line 25
3.1. IETF Standard Tags . . . . . . . . . . . . . . . . . . . 3 3.1. IETF Standard Tags . . . . . . . . . . . . . . . . . . . 3
3.2. Vendor Tags . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Vendor Tags . . . . . . . . . . . . . . . . . . . . . . . 3
3.3. Local Tags . . . . . . . . . . . . . . . . . . . . . . . 3 3.3. Local Tags . . . . . . . . . . . . . . . . . . . . . . . 3
3.4. Reserved Tags . . . . . . . . . . . . . . . . . . . . . . 3 3.4. Reserved Tags . . . . . . . . . . . . . . . . . . . . . . 3
4. Tag Management . . . . . . . . . . . . . . . . . . . . . . . 4 4. Tag Management . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Module Definition Association . . . . . . . . . . . . . . 4 4.1. Module Definition Association . . . . . . . . . . . . . . 4
4.2. Implementation Association . . . . . . . . . . . . . . . 4 4.2. Implementation Association . . . . . . . . . . . . . . . 4
4.3. Administrative Tagging . . . . . . . . . . . . . . . . . 4 4.3. Administrative Tagging . . . . . . . . . . . . . . . . . 4
5. Tags Module Structure . . . . . . . . . . . . . . . . . . . . 4 5. Tags Module Structure . . . . . . . . . . . . . . . . . . . . 4
5.1. Tags Module Tree . . . . . . . . . . . . . . . . . . . . 4 5.1. Tags Module Tree . . . . . . . . . . . . . . . . . . . . 4
5.2. Tags Module . . . . . . . . . . . . . . . . . . . . . . . 4 5.2. Tags Module . . . . . . . . . . . . . . . . . . . . . . . 5
6. Other Classifications . . . . . . . . . . . . . . . . . . . . 6 6. Other Classifications . . . . . . . . . . . . . . . . . . . . 6
7. Guidelines to Model Writers . . . . . . . . . . . . . . . . . 6 7. Guidelines to Model Writers . . . . . . . . . . . . . . . . . 6
7.1. Define Standard Tags . . . . . . . . . . . . . . . . . . 6 7.1. Define Standard Tags . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8.1. YANG Module Tag Prefix Registry . . . . . . . . . . . . . 7 8.1. YANG Module Tag Prefix Registry . . . . . . . . . . . . . 7
8.2. YANG Module IETF Tag Registry . . . . . . . . . . . . . . 8 8.2. YANG Module IETF Tag Registry . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
skipping to change at page 3, line 36 skipping to change at page 3, line 36
3.1. IETF Standard Tags 3.1. IETF Standard Tags
An IETF standard tag is a tag that has the prefix "ietf:". All IETF An IETF standard tag is a tag that has the prefix "ietf:". All IETF
standard tags are registered with IANA in a registry defined later in standard tags are registered with IANA in a registry defined later in
this document. this document.
3.2. Vendor Tags 3.2. Vendor Tags
A vendor tag is a tag that has the prefix "vendor:". These tags are A vendor tag is a tag that has the prefix "vendor:". These tags are
defined by the vendor that implements the module, and are not defined by the vendor that implements the module, and are not
standardized; however, it is recommended that the vendor consider standardized; however, it is RECOMMENDED that the vendor include
including extra identification in the tag name to avoid collisions extra identification in the tag name to avoid collisions such as
(e.g., vendor:super-duper-company:...). using the enterpise or organization name in the second field (e.g.,
vendor:example.com:system-management:...).
3.3. Local Tags 3.3. Local Tags
A local tag is any tag that has the prefix "local:". These tags are A local tag is any tag that has the prefix "local:". These tags are
defined by the local user/administrator and will never be defined by the local user/administrator and will never be
standardized. standardized.
3.4. Reserved Tags 3.4. Reserved Tags
Any tag not starting with the prefix "ietf:", "vendor:" or "local:" Any tag not starting with the prefix "ietf:", "vendor:" or "local:"
skipping to change at page 4, line 16 skipping to change at page 4, line 16
Tags can become associated with a module in a number of ways. Tags Tags can become associated with a module in a number of ways. Tags
may be defined and associated at model design time, at implementation may be defined and associated at model design time, at implementation
time, or via user administrative control. As the main consumer of time, or via user administrative control. As the main consumer of
tags are users, users may also remove any tag, no matter how the tag tags are users, users may also remove any tag, no matter how the tag
became associated with a module. became associated with a module.
4.1. Module Definition Association 4.1. Module Definition Association
A module definition SHOULD indicate a set of tags to be automatically A module definition SHOULD indicate a set of tags to be automatically
added by the module implementer. These tags MUST be standard tags added by the module implementer. If the module definition will be
(Section 3.1). This does imply that new modules may also drive the standard the tags MUST also be standard tags (Section 3.1). Thus,
addition of new standard tags to the IANA registry. new modules can drive the addition of new standard tags to the IANA
registry, and the IANA registry can serve as a check against
duplication.
4.2. Implementation Association 4.2. Implementation Association
An implementation MAY include additional tags associated with a An implementation MAY include additional tags associated with a
module. These tags may be standard or vendor specific tags. module. These tags may be standard or vendor specific tags.
4.3. Administrative Tagging 4.3. Administrative Tagging
Tags of any kind can be assigned and removed with normal Tags of any kind can be assigned and removed with normal
configuration mechanisms. configuration mechanisms.
skipping to change at page 9, line 40 skipping to change at page 9, line 40
+------------------------+------------------------------+-----------+ +------------------------+------------------------------+-----------+
Table 1: IETF Module Tag Registry Table 1: IETF Module Tag Registry
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-netmod-rfc6087bis] [I-D.ietf-netmod-rfc6087bis]
Bierman, A., "Guidelines for Authors and Reviewers of YANG Bierman, A., "Guidelines for Authors and Reviewers of YANG
Data Model Documents", draft-ietf-netmod-rfc6087bis-18 Data Model Documents", draft-ietf-netmod-rfc6087bis-20
(work in progress), February 2018. (work in progress), March 2018.
[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>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226, IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<https://www.rfc-editor.org/info/rfc5226>. <https://www.rfc-editor.org/info/rfc5226>.
 End of changes. 7 change blocks. 
13 lines changed or deleted 16 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/