rfc8819xml2.original.xml   rfc8819.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" []> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?> nsus="true" docName="draft-ietf-netmod-module-tags-10" indexInclude="true" ipr="
<?rfc toc="yes"?> trust200902" number="8819" prepTime="2020-12-23T10:04:57" scripts="Common,Latin"
<?rfc compact="no"?> sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="t
<?rfc subcompact="no"?> rue" updates="8407" xml:lang="en">
<?rfc symrefs="yes" ?> <link href="https://datatracker.ietf.org/doc/draft-ietf-netmod-module-tags-10"
<?rfc sortrefs="yes"?> rel="prev"/>
<?rfc iprnotified="no"?> <link href="https://dx.doi.org/10.17487/rfc8819" rel="alternate"/>
<?rfc strict="yes"?> <link href="urn:issn:2070-1721" rel="alternate"/>
<rfc ipr="trust200902"
category="std"
docName="draft-ietf-netmod-module-tags-10" updates="8407"
submissionType="IETF">
<front> <front>
<title abbrev="YANG Module Tags">YANG Module Tags</title> <title abbrev="YANG Module Tags">YANG Module Tags</title>
<author initials='C.' surname='Hopps' fullname='Christian Hopps'><organization>L <seriesInfo name="RFC" value="8819" stream="IETF"/>
abN Consulting, L.L.C.</organization><address><email>chopps@chopps.org</email></ <author initials="C." surname="Hopps" fullname="Christian Hopps">
address></author> <organization showOnFrontPage="true">LabN Consulting, L.L.C.</organization
<author initials='L.' surname='Berger' fullname='Lou Berger'><organization>LabN >
Consulting, LLC.</organization><address><email>lberger@labn.net</email></address <address>
></author> <email>chopps@chopps.org</email>
<author initials='D.' surname='Bogdanovic' fullname='Dean Bogdanovic'><organizat </address>
ion>Volta Networks</organization><address><email>ivandean@gmail.com</email></add </author>
ress></author> <date/><abstract><t>This document provides for the association o <author initials="L." surname="Berger" fullname="Lou Berger">
f tags with YANG modules. <organization showOnFrontPage="true">LabN Consulting, L.L.C.</organization
The expectation is for such tags to be used to help classify and >
organize modules. A method for defining, reading and writing a <address>
modules tags is provided. Tags may be registered and assigned <email>lberger@labn.net</email>
during module definition; assigned by implementations; or dynamically </address>
defined and set by users. This document also provides guidance to </author>
future model writers; as such, this document updates RFC8407.</t></abstract> </ <author initials="D." surname="Bogdanovic" fullname="Dean Bogdanovic">
front> <middle> <organization showOnFrontPage="true">Volta Networks</organization>
<address>
<section title="Introduction"> <email>ivandean@gmail.com</email>
<t>The use of tags for classification and organization is fairly </address>
ubiquitous not only within IETF protocols, but in the internet itself </author>
(e.g., <spanx style='verb'>#hashtags</spanx>). One benefit of using tags for org <date month="12" year="2020"/>
anization over <keyword>YANG</keyword>
a rigid structure is that it is more flexible and can more easily <keyword>tags</keyword>
adapt over time as technologies evolve. Tags can be usefully <abstract pn="section-abstract">
registered, but they can also serve as a non-registered mechanism <t indent="0" pn="section-abstract-1">This document provides for the assoc
available for users to define themselves. This document provides a iation of tags with YANG
mechanism to define tags and associate them with YANG modules in a modules. The expectation is for such tags to be used to help classify
flexible manner. In particular, tags may be registered as well as and organize modules. A method for defining, reading, and writing
assigned during module definition; assigned by implementations; or modules tags is provided. Tags may be registered and assigned during
dynamically defined and set by users.</t> module definition, assigned by implementations, or dynamically defined
and set by users. This document also provides guidance to future model
<t>This document defines a YANG module <xref target="RFC7950"/> which writers; as such, this document updates RFC 8407.</t>
provides a list of module entries to allow for adding or removing of </abstract>
tags as well as viewing the set of tags associated with a module.</t> <boilerplate>
<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
<t>This document defines an extension statement to be used to indicate "exclude" pn="section-boilerplate.1">
tags that SHOULD be added by the module implementation automatically <name slugifiedName="name-status-of-this-memo">Status of This Memo</name
(i.e., outside of configuration).</t> >
<t indent="0" pn="section-boilerplate.1-1">
<t>This document also defines an IANA registry for tag prefixes as well This is an Internet Standards Track document.
as a set of globally assigned tags.</t> </t>
<t indent="0" pn="section-boilerplate.1-2">
<t><xref target="sec-guidelines-to-model-writers"></xref> provides guidelines fo This document is a product of the Internet Engineering Task Force
r authors of YANG (IETF). It represents the consensus of the IETF community. It has
data models.</t> received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
<t>This document updates <xref target="RFC8407"/>.</t> information on Internet Standards is available in Section 2 of
RFC 7841.
<t>The YANG data model in this document conforms to the Network </t>
Management Datastore Architecture defined in <xref target="RFC8342"/>.</t> <t indent="0" pn="section-boilerplate.1-3">
Information about the current status of this document, any
<section title="Some possible use cases for YANG module tags"> errata, and how to provide feedback on it may be obtained at
<t>During this documents's development there were requests for example <eref target="https://www.rfc-editor.org/info/rfc8819" brackets="non
uses of module tags. The following are a few example use cases for e"/>.
tags. This list is certainly not exhaustive.</t> </t>
</section>
<t>One example use of tags would be to help filter different discrete <section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
categories of YANG modules supported by a device. For example, if ude" pn="section-boilerplate.2">
modules are suitably tagged, then an XPath query can be used to list <name slugifiedName="name-copyright-notice">Copyright Notice</name>
all of the vendor modules supported by a device.</t> <t indent="0" pn="section-boilerplate.2-1">
Copyright (c) 2020 IETF Trust and the persons identified as the
<t>Tags can also be used to help coordination when multiple document authors. All rights reserved.
semi-independent clients are interacting with the same devices. For </t>
example, one management client could mark that some modules should <t indent="0" pn="section-boilerplate.2-2">
not be used because they have not been verified to behave correctly, This document is subject to BCP 78 and the IETF Trust's Legal
so that other management clients avoid querying the data associated Provisions Relating to IETF Documents
with those modules.</t> (<eref target="https://trustee.ietf.org/license-info" brackets="none
"/>) in effect on the date of
<t>Tag classification is useful for users searching module repositories publication of this document. Please review these documents
(e.g., YANG catalog). A query restricted to the 'ietf:routing' module carefully, as they describe your rights and restrictions with
tag could be used to return only the IETF YANG modules associated respect to this document. Code Components extracted from this
with routing. Without tags, a user would need to know the name of all document must include Simplified BSD License text as described in
the IETF routing protocol YANG modules.</t> Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
<t>Future management protocol extensions could allow for filtering </t>
queries of configuration or operational state on a server based on </section>
tags. For example, return all operational state related to </boilerplate>
system-management.</t> <toc>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
</section> n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<section title="Conventions Used in This Document"> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", c.1-1">
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <li pn="section-toc.1-1.1">
"OPTIONAL" in this document are to be interpreted as described in <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appe ivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref
ar in all capitals, as derivedContent="" format="title" sectionFormat="of" target="name-introduction">
shown here.</t> Introduction</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
</section> n-toc.1-1.1.2">
<li pn="section-toc.1-1.1.2.1">
</section> <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><
xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.
<section title="Tag Values"> 1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-so
<t>All tags SHOULD begin with a prefix indicating who owns their me-possible-use-cases-for">Some Possible Use Cases for YANG Module Tags</xref></
definition. An IANA registry (<xref target="sec-yang-module-tag-prefixes-registr t>
y"></xref>) is </li>
used to support registering tag prefixes. Currently 3 prefixes <li pn="section-toc.1-1.1.2.2">
are defined. No further structure is imposed by this document on the <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.2.1"><
value following the registered prefix, and the value can contain any xref derivedContent="1.2" format="counter" sectionFormat="of" target="section-1.
YANG type 'string' characters except carriage-returns, newlines and 2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-co
tabs.</t> nventions-used-in-this-do">Conventions Used in This Document</xref></t>
</li>
<t>Again, except for the conflict-avoiding prefix, this document is not </ul>
specifying any structure on (i.e., restricting) the tag values on </li>
purpose. The intent is to avoid arbitrarily restricting the values <li pn="section-toc.1-1.2">
that designers, implementers and users can use. As a result of this <t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" form
choice, designers, implementers, and users are free to add or not at="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" f
add any structure they may require to their own tag values.</t> ormat="title" sectionFormat="of" target="name-tag-values">Tag Values</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
<section title="IETF Tags" anchor="sec-ietf-tags"> n-toc.1-1.2.2">
<t>An IETF tag is a tag that has the prefix "ietf:". All IETF tags are <li pn="section-toc.1-1.2.2.1">
registered with IANA in a registry defined later in this document <t indent="0" pn="section-toc.1-1.2.2.1.1"><xref derivedContent=
(<xref target="sec-ietf-yang-module-tags-registry"></xref>).</t> "2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-ietf-tags">IETF Tags</
</section> xref></t>
</li>
<section title="Vendor Tags"> <li pn="section-toc.1-1.2.2.2">
<t>A vendor tag is a tag that has the prefix "vendor:". These tags are <t indent="0" pn="section-toc.1-1.2.2.2.1"><xref derivedContent=
defined by the vendor that implements the module, and are not "2.2" format="counter" sectionFormat="of" target="section-2.2"/>.  <xref derived
registered; however, it is RECOMMENDED that the vendor include Content="" format="title" sectionFormat="of" target="name-vendor-tags">Vendor Ta
extra identification in the tag to avoid collisions such as using the gs</xref></t>
enterpise or organization name following the "vendor:" prefix (e.g., </li>
vendor:example.com:vendor-defined-classifier).</t> <li pn="section-toc.1-1.2.2.3">
<t indent="0" pn="section-toc.1-1.2.2.3.1"><xref derivedContent=
</section> "2.3" format="counter" sectionFormat="of" target="section-2.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-user-tags">User Tags</
<section title="User Tags"> xref></t>
<t>A user tag is any tag that has the prefix "user:". These tags are </li>
defined by the user/administrator and are not meant to be registered. <li pn="section-toc.1-1.2.2.4">
Users are not required to use the "user:" prefix; however, doing so <t indent="0" pn="section-toc.1-1.2.2.4.1"><xref derivedContent=
is RECOMMENDED as it helps avoid collisions.</t> "2.4" format="counter" sectionFormat="of" target="section-2.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-reserved-tags">Reserve
</section> d Tags</xref></t>
</li>
<section title="Reserved Tags"> </ul>
<t>Any tag not starting with the prefix "ietf:", "vendor:" or "user:" is </li>
reserved for future use. These tag values are not invalid, but simply <li pn="section-toc.1-1.3">
reserved in the context of specifications (e.g., RFCs).</t> <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" form
at="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" f
</section> ormat="title" sectionFormat="of" target="name-tag-management">Tag Management</xr
ef></t>
</section> <ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.3.2">
<section title="Tag Management"> <li pn="section-toc.1-1.3.2.1">
<t>Tags can become associated with a module in a number of ways. Tags <t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent=
may be defined and associated at module design time, at "3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derived
implementation time, or via user administrative control. As the main Content="" format="title" sectionFormat="of" target="name-module-definition-tagg
consumer of tags are users, users may also remove any tag, no matter ing">Module Definition Tagging</xref></t>
how the tag became associated with a module.</t> </li>
<li pn="section-toc.1-1.3.2.2">
<section title="Module Definition Tagging"> <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent=
<t>A module definition MAY indicate a set of tags to be added by the "3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derived
module implementer. These design time tags are indicated using the Content="" format="title" sectionFormat="of" target="name-implementation-tagging
module-tag extension statement.</t> ">Implementation Tagging</xref></t>
</li>
<t>If the module is defined in an IETF standards track document, the <li pn="section-toc.1-1.3.2.3">
tags MUST be <xref format="counter" target="sec-ietf-tags">IETF Tags</xref>. Thu <t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent=
s, new modules can drive the addition of "3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derived
new IETF tags to the IANA registry defined in <xref target="sec-ietf-yang-module Content="" format="title" sectionFormat="of" target="name-user-tagging">User Tag
-tags-registry"></xref>, and the IANA registry can serve as a check against ging</xref></t>
duplication.</t> </li>
</ul>
</section> </li>
<li pn="section-toc.1-1.4">
<section title="Implementation Tagging"> <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" form
<t>An implementation MAY include additional tags associated with a at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
module. These tags SHOULD be IETF Tags (i.e., registered) or vendor ormat="title" sectionFormat="of" target="name-tags-module-structure">Tags Module
specific tags.</t> Structure</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
</section> n-toc.1-1.4.2">
<li pn="section-toc.1-1.4.2.1">
<section title="User Tagging"> <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent=
<t>Tags of any kind, with or without a prefix, can be assigned and "4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derived
removed by the user using normal configuration mechanisms. In order Content="" format="title" sectionFormat="of" target="name-tags-module-tree">Tags
to remove a tag from the operational datastore the user adds a Module Tree</xref></t>
matching <spanx style='verb'>masked-tag</spanx> entry for a given module.</t> </li>
<li pn="section-toc.1-1.4.2.2">
</section> <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent=
"4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derived
</section> Content="" format="title" sectionFormat="of" target="name-yang-module">YANG Modu
le</xref></t>
<section title="Tags Module Structure"> </li>
<section title="Tags Module Tree"> </ul>
<t>The tree associated with the "ietf-module-tags" module follows. The </li>
meaning of the symbols can be found in <xref target="RFC8340"/>.</t> <li pn="section-toc.1-1.5">
<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" form
at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-other-classifications">Other Class
ifications</xref></t>
</li>
<li pn="section-toc.1-1.6">
<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" form
at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-guidelines-to-model-writers">Guide
lines to Model Writers</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.6.2">
<li pn="section-toc.1-1.6.2.1">
<t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent=
"6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-define-standard-tags">
Define Standard Tags</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.7">
<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" form
at="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-iana-considerations">IANA Consider
ations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.7.2">
<li pn="section-toc.1-1.7.2.1">
<t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent=
"7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-yang-module-tag-prefix
es-re">YANG Module Tag Prefixes Registry</xref></t>
</li>
<li pn="section-toc.1-1.7.2.2">
<t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent=
"7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-ietf-yang-module-tags-
regis">IETF YANG Module Tags Registry</xref></t>
</li>
<li pn="section-toc.1-1.7.2.3">
<t indent="0" pn="section-toc.1-1.7.2.3.1"><xref derivedContent=
"7.3" format="counter" sectionFormat="of" target="section-7.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-updates-to-the-ietf-xm
l-reg">Updates to the IETF XML Registry</xref></t>
</li>
<li pn="section-toc.1-1.7.2.4">
<t indent="0" pn="section-toc.1-1.7.2.4.1"><xref derivedContent=
"7.4" format="counter" sectionFormat="of" target="section-7.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-updates-to-the-yang-mo
dule-">Updates to the YANG Module Names Registry</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.8">
<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" form
at="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-security-considerations">Security
Considerations</xref></t>
</li>
<li pn="section-toc.1-1.9">
<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" form
at="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-references">References</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.9.2">
<li pn="section-toc.1-1.9.2.1">
<t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent=
"9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-normative-references">
Normative References</xref></t>
</li>
<li pn="section-toc.1-1.9.2.2">
<t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent=
"9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-informative-references
">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.10">
<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="Append
ix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-examples">Examp
les</xref></t>
</li>
<li pn="section-toc.1-1.11">
<t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="Append
ix B" format="default" sectionFormat="of" target="section-appendix.b"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-non-nmda-state-
module">Non-NMDA State Module</xref></t>
</li>
<li pn="section-toc.1-1.12">
<t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgeme
nts</xref></t>
</li>
<li pn="section-toc.1-1.13">
<t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Add
resses</xref></t>
</li>
</ul>
</section>
</toc>
</front>
<middle>
<section numbered="true" toc="include" removeInRFC="false" pn="section-1">
<name slugifiedName="name-introduction">Introduction</name>
<t indent="0" pn="section-1-1">The use of tags for classification and orga
nization is fairly
ubiquitous not only within IETF protocols but in the internet itself
(e.g., <tt>#hashtags</tt>).
<figure title="YANG Module Tags Tree Diagram" anchor="sec-yang-module-tags-tree- One benefit of using tags for organization
diagram"><artwork><![CDATA[ over a rigid structure is that it is more flexible and can more easily
adapt over time as technologies evolve. Tags can be usefully registered,
but they can also serve as a non-registered mechanism available for
users to define themselves. This document provides a mechanism to define
tags and associate them with YANG modules in a flexible manner. In
particular, tags may be registered as well as assigned during module
definition, assigned by implementations, or dynamically defined and set
by users.</t>
<t indent="0" pn="section-1-2">This document defines a YANG module <xref t
arget="RFC7950" format="default" sectionFormat="of" derivedContent="RFC7950"/> t
hat provides a list of module entries to allow for
adding or removing tags as well as viewing the set of tags associated
with a module.</t>
<t indent="0" pn="section-1-3">This document defines an extension statemen
t to indicate
tags that <bcp14>SHOULD</bcp14> be added by the module implementation
automatically (i.e., outside of configuration).</t>
<t indent="0" pn="section-1-4">This document also defines an IANA registry
for tag prefixes as well
as a set of globally assigned tags.</t>
<t indent="0" pn="section-1-5"><xref target="sec-guidelines-to-model-write
rs" format="default" sectionFormat="of" derivedContent="Section 6"/>
provides guidelines for authors of YANG data models.</t>
<t indent="0" pn="section-1-6">This document updates <xref target="RFC8407
" format="default" sectionFormat="of" derivedContent="RFC8407"/>.</t>
<t indent="0" pn="section-1-7">The YANG data model in this document confor
ms to the Network
Management Datastore Architecture (NMDA) defined in <xref target="RFC8342"
format="default" sectionFormat="of" derivedContent="RFC8342"/>.</t>
<section numbered="true" toc="include" removeInRFC="false" pn="section-1.1
">
<name slugifiedName="name-some-possible-use-cases-for">Some Possible Use
Cases for YANG Module Tags</name>
<t indent="0" pn="section-1.1-1">During this document's development, the
re were requests for example
uses of module tags. The following are a few example use cases for
tags. This list is certainly not exhaustive.</t>
<t indent="0" pn="section-1.1-2">One example use of tags would be to hel
p filter different discrete
categories of YANG modules supported by a device. For example, if
modules are suitably tagged, then an XPath query can be used to list
all of the vendor modules supported by a device.</t>
<t indent="0" pn="section-1.1-3">Tags can also be used to help coordinat
ion when multiple,
semi-independent clients are interacting with the same devices. For
example, one management client could mark that some modules should not
be used because they have not been verified to behave correctly, so
that other management clients avoid querying the data associated with
those modules.</t>
<t indent="0" pn="section-1.1-4">Tag classification is useful for users
searching module
repositories (e.g., YANG catalog). A query restricted to the
'ietf:routing' module tag could be used to return only the IETF YANG
modules associated with routing. Without tags, a user would need to
know the name of all the IETF routing protocol YANG modules.</t>
<t indent="0" pn="section-1.1-5">Future management protocol extensions c
ould allow for filtering
queries of configuration or operational state on a server based on
tags (for example, return all operational state related to
system management).</t>
</section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-1.2
">
<name slugifiedName="name-conventions-used-in-this-do">Conventions Used
in This Document</name>
<t indent="0" pn="section-1.2-1">
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
to be interpreted as
described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="o
f" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFor
mat="of" derivedContent="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section>
</section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-2">
<name slugifiedName="name-tag-values">Tag Values</name>
<t indent="0" pn="section-2-1">All tags <bcp14>SHOULD</bcp14> begin with a
prefix indicating who
owns their definition. An IANA registry (<xref target="sec-yang-module-tag
-prefixes-registry" format="default" sectionFormat="of" derivedContent="Section
7.1"/>) is
used to support registering tag prefixes. Currently, three prefixes are
defined. No further structure is imposed by this document on the value
following the registered prefix, and the value can contain any YANG type
'string' characters except carriage returns, newlines, and tabs.</t>
<t indent="0" pn="section-2-2">Again, except for the conflict-avoiding pre
fix, this document is
purposefully not specifying any structure on (i.e., restricting) the tag v
alues.
The intent is to avoid arbitrarily restricting the values that
designers, implementers, and users can use. As a result of this choice,
designers, implementers, and users are free to add or not add any
structure they may require to their own tag values.</t>
<section anchor="sec-ietf-tags" numbered="true" toc="include" removeInRFC=
"false" pn="section-2.1">
<name slugifiedName="name-ietf-tags">IETF Tags</name>
<t indent="0" pn="section-2.1-1">An IETF tag is a tag that has the prefi
x "ietf:". All IETF tags are
registered with IANA in a registry defined later in this document
(<xref target="sec-ietf-yang-module-tags-registry" format="default" secti
onFormat="of" derivedContent="Section 7.2"/>).</t>
</section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-2.2
">
<name slugifiedName="name-vendor-tags">Vendor Tags</name>
<t indent="0" pn="section-2.2-1">A vendor tag is a tag that has the pref
ix "vendor:". These tags are
defined by the vendor that implements the module and are not
registered; however, it is <bcp14>RECOMMENDED</bcp14> that the vendor
include extra identification in the tag to avoid collisions, such as
using the enterprise or organization name following the "vendor:"
prefix (e.g., vendor:example.com:vendor-defined-classifier).</t>
</section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-2.3
">
<name slugifiedName="name-user-tags">User Tags</name>
<t indent="0" pn="section-2.3-1">A user tag is any tag that has the pref
ix "user:". These tags are
defined by the user/administrator and are not meant to be
registered. Users are not required to use the "user:" prefix; however,
doing so is <bcp14>RECOMMENDED</bcp14> as it helps avoid
collisions.</t>
</section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-2.4
">
<name slugifiedName="name-reserved-tags">Reserved Tags</name>
<t indent="0" pn="section-2.4-1">Any tag not starting with the prefix "i
etf:", "vendor:", or "user:"
is reserved for future use. These tag values are not invalid but
simply reserved in the context of specifications (e.g., RFCs).</t>
</section>
</section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-3">
<name slugifiedName="name-tag-management">Tag Management</name>
<t indent="0" pn="section-3-1">Tags can become associated with a module in
a number of ways. Tags
may be defined and associated at module design time, at implementation
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 became
associated with a module.</t>
<section numbered="true" toc="include" removeInRFC="false" pn="section-3.1
">
<name slugifiedName="name-module-definition-tagging">Module Definition T
agging</name>
<t indent="0" pn="section-3.1-1">A module definition <bcp14>MAY</bcp14>
indicate a set of tags to be
added by the module implementer. These design-time tags are indicated
using the module-tag extension statement.</t>
<t indent="0" pn="section-3.1-2">If the module is defined in an IETF Sta
ndards Track document, the
tags <bcp14>MUST</bcp14> be IETF tags (<xref target="sec-ietf-tags" forma
t="default" sectionFormat="of" derivedContent="Section 2.1"/>). Thus, new module
s can drive
the addition of new IETF tags to the IANA registry defined in <xref targe
t="sec-ietf-yang-module-tags-registry" format="default" sectionFormat="of" deriv
edContent="Section 7.2"/>, and
the IANA registry can serve as a check against duplication.</t>
</section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-3.2
">
<name slugifiedName="name-implementation-tagging">Implementation Tagging
</name>
<t indent="0" pn="section-3.2-1">An implementation <bcp14>MAY</bcp14> in
clude additional tags
associated with a module. These tags <bcp14>SHOULD</bcp14> be IETF
tags (i.e., registered) or vendor-specific tags.</t>
</section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-3.3
">
<name slugifiedName="name-user-tagging">User Tagging</name>
<t indent="0" pn="section-3.3-1">Tags of any kind, with or without a pre
fix, can be assigned and
removed by the user using normal configuration mechanisms. In order to
remove a tag from the operational datastore, the user adds a matching
<tt>masked-tag</tt> entry for a given module.</t>
</section>
</section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-4">
<name slugifiedName="name-tags-module-structure">Tags Module Structure</na
me>
<section numbered="true" toc="include" removeInRFC="false" pn="section-4.1
">
<name slugifiedName="name-tags-module-tree">Tags Module Tree</name>
<t indent="0" pn="section-4.1-1">The tree associated with the "ietf-modu
le-tags" module follows. The
meaning of the symbols can be found in <xref target="RFC8340" format="def
ault" sectionFormat="of" derivedContent="RFC8340"/>.</t>
<figure anchor="sec-yang-module-tags-tree-diagram" align="left" suppress
-title="false" pn="figure-1">
<name slugifiedName="name-yang-module-tags-tree-diagr">YANG Module Tag
s Tree Diagram</name>
<sourcecode type="yangtree" markers="false" pn="section-4.1-2.1">
module: ietf-module-tags module: ietf-module-tags
+--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
]]></artwork></figure> </sourcecode>
</figure>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-4.2
<section title="YANG Module"> ">
<figure title="Module Tags Module" anchor="sec-module-tags-module"><artwork><![C <name slugifiedName="name-yang-module">YANG Module</name>
DATA[ <figure anchor="sec-module-tags-module" align="left" suppress-title="fal
<CODE BEGINS> file "ietf-module-tags@2020-02-29.yang" se" pn="figure-2">
<name slugifiedName="name-module-tags-module">Module Tags Module</name
>
<sourcecode name="ietf-module-tags@2020-12-22.yang" type="yang" marker
s="true" pn="section-4.2-1.1">
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
"IETF NetMod Working Group (NetMod)"; "IETF NetMod Working Group (NetMod)";
contact contact
"WG Web: <https://tools.ietf.org/wg/netmod/> "WG Web: &lt;https://datatracker.ietf.org/wg/netmod/&gt;
WG List: <mailto:netmod@ietf.org> WG List: &lt;mailto:netmod@ietf.org&gt;
Author: Christian Hopps Author: Christian Hopps
<mailto:chopps@chopps.org&gt; &lt;mailto:chopps@chopps.org&gt;
Author: Lou Berger Author: Lou Berger
<mailto:lberger@labn.net&gt; &lt;mailto:lberger@labn.net&gt;
Author: Dean Bogdanovic Author: Dean Bogdanovic
<ivandean@gmail.com>"; &lt;mailto:ivandean@gmail.com&gt;";
// RFC Ed.: replace XXXX with actual RFC number and
// remove this note.
description description
"This module describes a mechanism associating tags with YANG "This module describes a mechanism associating tags with YANG
modules. Tags may be IANA assigned or privately defined. modules. Tags may be IANA assigned or privately defined.
Copyright (c) 2019 IETF Trust and the persons identified as Copyright (c) 2020 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 Simplified BSD License set the license terms contained in, the Simplified 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 8819
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself (https://www.rfc-editor.org/info/rfc8819); see the RFC itself
for full legal notices. for full legal notices.
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 revision 2020-12-22 {
// and RFC number and remove this note.
revision 2020-02-29 {
description description
"Initial revision."; "Initial revision.";
reference "RFC XXXX: YANG Module Tags"; reference
"RFC 8819: YANG Module Tags";
} }
typedef tag { typedef tag {
type string { type string {
length "1..max"; length "1..max";
pattern '[\S ]+'; pattern '[\S ]+';
} }
description description
"A tag is a type 'string' value that does not include carriage "A tag is a type of 'string' value that does not include
return, newline or tab characters. It SHOULD begin with a carriage return, newline, or tab characters. It SHOULD begin
registered prefix; however, tags without a registered prefix with a registered prefix; however, tags without a registered
SHOULD NOT be treated as invalid."; prefix SHOULD NOT be treated as invalid.";
} }
extension module-tag { extension module-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 tags that SHOULD be is used by module authors to indicate the tags that SHOULD be
added automatically by the system. As such the origin of the added automatically by the system. As such, the origin of the
value for the pre-defined tags should be set to 'system' value for the predefined tags should be set to 'system'
[RFC8342]."; [RFC8342].";
} }
container module-tags { container module-tags {
description description
"Contains the list of modules and their associated tags"; "Contains the list of modules and their associated tags.";
list module { list module {
key "name"; key "name";
description description
"A list of modules and their associated tags"; "A list of modules and their associated tags.";
leaf name { leaf name {
type yang:yang-identifier; type yang:yang-identifier;
mandatory true; mandatory true;
description description
"The YANG module name."; "The YANG module name.";
} }
leaf-list tag { leaf-list tag {
type tag; type tag;
description description
"Tags associated with the module. See the IANA 'YANG Module "Tags associated with the module. See the IANA 'YANG
Tag Prefixes' registry for reserved prefixes and the IANA Module Tag Prefixes' registry for reserved prefixes and
'IETF YANG Module Tags' registry for IETF tags. the IANA 'IETF YANG Module Tags' registry for IETF tags.
The 'operational' state [RFC8342] view of this list is The 'operational' state [RFC8342] 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 added. 1) System tags (i.e., tags of 'system' origin) are added.
2) User configured tags (i.e., tags of 'intended' origin) 2) User-configured tags (i.e., tags of 'intended' origin)
are added. 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.";
} }
leaf-list masked-tag { leaf-list masked-tag {
type tag; type tag;
description description
"The list of tags that should not be associated with this "The list of tags that should not be associated with this
module. The user can remove (mask) tags from the module. The user can remove (mask) tags from the
operational state datastore [RFC8342] by adding them to operational state datastore [RFC8342] by adding them to
this list. It is not an error to add tags to this list this list. It is not an error to add tags to this list
that are not associated with the module, but they have no that are not associated with the module, but they have no
operational effect."; operational effect.";
} }
} }
} }
} }
<CODE ENDS>
]]></artwork></figure>
</section>
</section>
<section title="Other Classifications">
<t>It is worth noting that a different YANG module classification
document exists <xref target="RFC8199"/>. That document only classifies modules
in a
logical manner and does not define tagging or any other mechanisms.
It divides YANG modules into two categories (service or element) and
then into one of three origins: standard, vendor or user. It does
provide a good way to discuss and identify modules in general. This
document defines IETF tags to support <xref target="RFC8199"/> style
classification.</t>
</section>
<section title="Guidelines to Model Writers" anchor="sec-guidelines-to-model-wri
ters">
<t>This section updates <xref target="RFC8407"/>.</t>
<section title="Define Standard Tags"> </sourcecode>
<t>A module MAY indicate, using module-tag extension statements, a set </figure>
of tags that are to be automatically associated with it (i.e., not </section>
added through configuration).</t> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-5">
<figure><artwork><![CDATA[ <name slugifiedName="name-other-classifications">Other Classifications</na
me>
<t indent="0" pn="section-5-1">It is worth noting that a different YANG mo
dule classification
document exists <xref target="RFC8199" format="default" sectionFormat="of"
derivedContent="RFC8199"/>. That document
only classifies modules in a logical manner and does not define tagging
or any other mechanisms. It divides YANG modules into two categories
(service or element) and then into one of three origins: standard,
vendor, or user. It does provide a good way to discuss and identify
modules in general. This document defines IETF tags to support the
classification style described in <xref target="RFC8199" format="default"
sectionFormat="of" derivedContent="RFC8199"/>.</t>
</section>
<section anchor="sec-guidelines-to-model-writers" numbered="true" toc="inclu
de" removeInRFC="false" pn="section-6">
<name slugifiedName="name-guidelines-to-model-writers">Guidelines to Model
Writers</name>
<t indent="0" pn="section-6-1">This section updates <xref target="RFC8407"
format="default" sectionFormat="of" derivedContent="RFC8407"/>.</t>
<section numbered="true" toc="include" removeInRFC="false" pn="section-6.1
">
<name slugifiedName="name-define-standard-tags">Define Standard Tags</na
me>
<t indent="0" pn="section-6.1-1">A module <bcp14>MAY</bcp14> indicate, u
sing module-tag extension
statements, a set of tags that are to be automatically associated with
it (i.e., not added through configuration).</t>
<sourcecode name="" type="yang" markers="false" pn="section-6.1-2">
module example-module { module example-module {
namespace "https://example.com/yang/example";
prefix "ex";
//... //...
import module-tags { prefix tags; } import module-tags { prefix tags; }
tags:module-tag "ietf:some-new-tag"; tags:module-tag "ietf:some-new-tag";
tags:module-tag "ietf:some-other-tag"; tags:module-tag "ietf:some-other-tag";
// ... // ...
} }
]]></artwork></figure> </sourcecode>
<t indent="0" pn="section-6.1-3">The module writer can use existing stan
<t>The module writer can use existing standard tags, or use new tags dard tags or use new tags
defined in the model definition, as appropriate. For IETF defined in the model definition, as appropriate. For IETF standardized
standardized modules new tags MUST be assigned in the IANA registry modules, new tags <bcp14>MUST</bcp14> be assigned in the IANA registry
defined below, see <xref target="sec-ietf-yang-module-tags-registry"></xref>.</t defined below, see <xref target="sec-ietf-yang-module-tags-registry" form
> at="default" sectionFormat="of" derivedContent="Section 7.2"/>.</t>
</section>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-7">
</section> <name slugifiedName="name-iana-considerations">IANA Considerations</name>
<section anchor="sec-yang-module-tag-prefixes-registry" numbered="true" to
<section title="IANA Considerations"> c="include" removeInRFC="false" pn="section-7.1">
<section title="YANG Module Tag Prefixes Registry" anchor="sec-yang-module-tag-p <name slugifiedName="name-yang-module-tag-prefixes-re">YANG Module Tag P
refixes-registry"> refixes Registry</name>
<t>IANA is asked to create a new registry "YANG Module Tag Prefixes" <t indent="0" pn="section-7.1-1">IANA has created the "YANG Module Tag P
grouped under a new "Protocol" category named "YANG Module Tags".</t> refixes" subregistry
in the "YANG Module Tags" registry.</t>
<t>This registry allocates tag prefixes. All YANG module tags SHOULD <t indent="0" pn="section-7.1-2">This registry allocates tag prefixes. A
begin with one of the prefixes in this registry.</t> ll YANG module tags
<bcp14>SHOULD</bcp14> begin with one of the prefixes in this registry.</t
<t>Prefix entries in this registry should be short strings consisting of >
lowercase ASCII alpha-numeric characters and a final ":" character.</t> <t indent="0" pn="section-7.1-3">Prefix entries in this registry should
be short strings consisting
<t>The allocation policy for this registry is Specification Required of lowercase ASCII alpha-numeric characters and a final ":" character.</t
<xref target="RFC8126"/>. The Reference and Assignee values should be sufficient >
to <t indent="0" pn="section-7.1-4">The allocation policy for this registry
identify and contact the organization that has been allocated the is Specification Required
prefix.</t> <xref target="RFC8126" format="default" sectionFormat="of" derivedContent
="RFC8126"/>. The Reference and Assignee
<t>The initial values for this registry are as follows.</t> values should be sufficient to identify and contact the organization
that has been allocated the prefix.</t>
<texttable> <t indent="0" pn="section-7.1-5">The initial values for this registry ar
<ttcol>Prefix</ttcol><ttcol>Description</ttcol><ttcol>Reference</ttcol><ttcol>As e as follows.</t>
signee</ttcol> <table align="center" pn="table-1">
<c>ietf:</c><c>IETF Tags allocated in the IANA IETF YANG Module Tags registry.</ <thead>
c><c>[This document]</c><c>IETF</c> <tr>
<c>vendor:</c><c>Non-registered tags allocated by the module implementer.</c><c> <th align="left" colspan="1" rowspan="1">Prefix</th>
[This document]</c><c>IETF</c> <th align="left" colspan="1" rowspan="1">Description</th>
<c>user:</c><c>Non-registered tags allocated by and for the user.</c><c>[This do <th align="left" colspan="1" rowspan="1">Reference</th>
cument]</c><c>IETF</c> <th align="left" colspan="1" rowspan="1">Assignee</th>
</texttable> </tr>
</thead>
<t>Other standards organizations (SDOs) wishing to allocate their own <tbody>
set of tags should allocate a prefix from this registry.</t> <tr>
<td align="left" colspan="1" rowspan="1">ietf:</td>
</section> <td align="left" colspan="1" rowspan="1">IETF tags allocated in th
e IANA "IETF YANG
<section title="IETF YANG Module Tags Registry" anchor="sec-ietf-yang-module-tag Module Tags" registry.</td>
s-registry"> <td align="left" colspan="1" rowspan="1">RFC 8819</td>
<t>IANA is asked to create a new registry "IETF YANG Module Tags" grouped <td align="left" colspan="1" rowspan="1">IETF</td>
under a new "Protocol" category "IETF YANG Module Tags". This registry </tr>
should be included below "YANG Module Tag Prefixes" when listed on <tr>
the same page.</t> <td align="left" colspan="1" rowspan="1">vendor:</td>
<td align="left" colspan="1" rowspan="1">Non-registered tags alloc
<t>This registry allocates tags that have the registered prefix "ietf:". ated by the module
New values should be well considered and not achievable through a implementer.</td>
combination of already existing IETF tags. IANA assigned tags must <td align="left" colspan="1" rowspan="1">RFC 8819</td>
conform to Net-Unicode as defined in <xref target="RFC5198"/> and they shall not <td align="left" colspan="1" rowspan="1">IETF</td>
need </tr>
normalization.</t> <tr>
<td align="left" colspan="1" rowspan="1">user:</td>
<t>The allocation policy for this registry is IETF Review <xref target="RFC8126" <td align="left" colspan="1" rowspan="1">Non-registered tags alloc
/>.</t> ated by and for the
user.</td>
<t>The initial values for this registry are as follows.</t> <td align="left" colspan="1" rowspan="1">RFC 8819</td>
<td align="left" colspan="1" rowspan="1">IETF</td>
<texttable> </tr>
<ttcol>Tag</ttcol><ttcol>Description</ttcol><ttcol>Reference</ttcol> </tbody>
<c>ietf:network-element-class</c><c><xref target="RFC8199"/> network element.</c </table>
><c><xref target="RFC8199"/></c> <t indent="0" pn="section-7.1-7">Other standards development organizatio
<c>ietf:network-service-class</c><c><xref target="RFC8199"/> network service.</c ns (SDOs) wishing to
><c><xref target="RFC8199"/></c> allocate their own set of tags should allocate a prefix from this
<c>ietf:sdo-defined-class</c><c>Module is defined by a standards organization.</ registry.</t>
c><c><xref target="RFC8199"/></c> </section>
<c>ietf:vendor-defined-class</c><c>Module is defined by a vendor.</c><c><xref ta <section anchor="sec-ietf-yang-module-tags-registry" numbered="true" toc="
rget="RFC8199"/></c> include" removeInRFC="false" pn="section-7.2">
<c>ietf:user-defined-class</c><c>Module is defined by the user.</c><c><xref targ <name slugifiedName="name-ietf-yang-module-tags-regis">IETF YANG Module
et="RFC8199"/></c> Tags Registry</name>
<c>ietf:hardware</c><c>Relates to hardware (e.g., inventory).</c><c>[This docume <t indent="0" pn="section-7.2-1">IANA has created the "IETF YANG Module
nt]</c> Tags" subregistry
<c>ietf:software</c><c>Relates to software (e.g., installed OS).</c><c>[This doc within the "YANG Module Tags" registry . This
ument]</c> registry appears below the "YANG Module Tag Prefixes" registry.</t>
<c>ietf:protocol</c><c>Represents a protocol (often combined with another tag to <t indent="0" pn="section-7.2-2">This registry allocates tags that have
refine).</c><c>[This document]</c> the registered prefix
<c>ietf:qos</c><c>Relates to quality of service.</c><c>[This document]</c> "ietf:". New values should be well considered and not achievable
<c>ietf:network-service-app</c><c>Relates to a network service application (e.g. through a combination of already existing IETF tags. IANA assigned
, an NTP server, DNS server, DHCP server, etc).</c><c>[This document]</c> tags must conform to Net-Unicode as defined in <xref target="RFC5198" for
<c>ietf:system-management</c><c>Relates to system management (e.g., a system man mat="default" sectionFormat="of" derivedContent="RFC5198"/>, and they shall not
agement protocol such as syslog, TACAC+, SNMP, netconf, ...).</c><c>[This docume need normalization.</t>
nt]</c> <t indent="0" pn="section-7.2-3">The allocation policy for this registry
<c>ietf:oam</c><c>Relates to Operations, Administration, and Maintenance (e.g., is IETF Review <xref target="RFC8126" format="default" sectionFormat="of" deriv
BFD).</c><c>[This document]</c> edContent="RFC8126"/>.</t>
<c>ietf:routing</c><c>Relates to routing.</c><c>[This document]</c> <t indent="0" pn="section-7.2-4">The initial values for this registry ar
<c>ietf:security</c><c>Related to security.</c><c>[This document]</c> e as follows.</t>
<c>ietf:signaling</c><c>Relates to control plane signaling.</c><c>[This document <table align="center" pn="table-2">
]</c> <thead>
<c>ietf:link-management</c><c>Relates to link management.</c><c>[This document]< <tr>
/c> <th align="left" colspan="1" rowspan="1">Tag</th>
</texttable> <th align="left" colspan="1" rowspan="1">Description</th>
<th align="left" colspan="1" rowspan="1">Reference</th>
</section> </tr>
</thead>
<section title="Updates to the IETF XML Registry"> <tbody>
<t>This document registers a URI in the "IETF XML Registry" <xref target="RFC368 <tr>
8"/>. <td align="left" colspan="1" rowspan="1">ietf:network-element-clas
Following the format in <xref target="RFC3688"/>, the following registrations ha s</td>
ve been <td align="left" colspan="1" rowspan="1">Network element as define
made:</t> d in
<xref target="RFC8199" format="default" sectionFormat="of" deriv
<t><list style="hanging"> edContent="RFC8199"/>.</td>
<t hangText="URI:"><vspace/>urn:ietf:params:xml:ns:yang:ietf-module-tags</t> <td align="left" colspan="1" rowspan="1">
<t hangText="Registrant Contact:"><vspace/>The IESG.</t> <xref target="RFC8199" format="default" sectionFormat="of" deriv
<t hangText="XML:"><vspace/>N/A; the requested URI is an XML namespace.</t> edContent="RFC8199"/></td>
</tr>
<t hangText="URI:"><vspace/>urn:ietf:params:xml:ns:yang:ietf-module-tags-state</ <tr>
t> <td align="left" colspan="1" rowspan="1">ietf:network-service-clas
<t hangText="Registrant Contact:"><vspace/>The IESG.</t> s</td>
<t hangText="XML:"><vspace/>N/A; the requested URI is an XML namespace.</t> <td align="left" colspan="1" rowspan="1">Network service as define
</list></t> d in
<xref target="RFC8199" format="default" sectionFormat="of" deriv
</section> edContent="RFC8199"/>.</td>
<td align="left" colspan="1" rowspan="1">
<section title="Updates to the YANG Module Names Registry"> <xref target="RFC8199" format="default" sectionFormat="of" deriv
<t>This document registers two YANG modules in the "YANG Module Names" edContent="RFC8199"/></td>
registry <xref target="RFC6020"/>. Following the format in <xref target="RFC6020 </tr>
"/>, the following <tr>
registration have been made:</t> <td align="left" colspan="1" rowspan="1">ietf:sdo-defined-class</t
d>
<t><list style="hanging"> <td align="left" colspan="1" rowspan="1">Module is defined by a st
<t hangText="name:"><vspace/>ietf-module-tags</t> andards organization.</td>
<t hangText="namespace:"><vspace/>urn:ietf:params:xml:ns:yang:ietf-module-tags</ <td align="left" colspan="1" rowspan="1">
t> <xref target="RFC8199" format="default" sectionFormat="of" deriv
<t hangText="prefix:"><vspace/>tags</t> edContent="RFC8199"/></td>
<t hangText="reference:"><vspace/>RFC XXXX (RFC Ed.: replace XXX with actual RFC </tr>
number and remove this note.)</t> <tr>
<td align="left" colspan="1" rowspan="1">ietf:vendor-defined-class
<t hangText="name:"><vspace/>ietf-module-tags-state</t> </td>
<t hangText="namespace:"><vspace/>urn:ietf:params:xml:ns:yang:ietf-module-tags-s <td align="left" colspan="1" rowspan="1">Module is defined by a ve
tate</t> ndor.</td>
<t hangText="prefix:"><vspace/>tags</t> <td align="left" colspan="1" rowspan="1">
<t hangText="reference:"><vspace/>RFC XXXX (RFC Ed.: replace XXX with actual RFC <xref target="RFC8199" format="default" sectionFormat="of" deriv
number and remove this note.)</t> edContent="RFC8199"/></td>
</list></t> </tr>
<tr>
</section> <td align="left" colspan="1" rowspan="1">ietf:user-defined-class</
td>
</section> <td align="left" colspan="1" rowspan="1">Module is defined by the
user.</td>
<section title="Security Considerations"> <td align="left" colspan="1" rowspan="1">
<t>The YANG module defined in this memo is designed to be accessed via <xref target="RFC8199" format="default" sectionFormat="of" deriv
the NETCONF protocol <xref target="RFC6241"/>. The lowest NETCONF layer is the edContent="RFC8199"/></td>
secure transport layer and the mandatory-to-implement secure </tr>
transport is SSH <xref target="RFC6242"/>.</t> <tr>
<td align="left" colspan="1" rowspan="1">ietf:hardware</td>
<t>This document adds the ability to associate tag meta-data with YANG <td align="left" colspan="1" rowspan="1">Relates to hardware (e.g.
modules. This document does not define any actions based on these , inventory).</td>
associations, and none are yet defined, and therefore it does not <td align="left" colspan="1" rowspan="1">RFC 8819</td>
by itself introduce any new security considerations directly.</t> </tr>
<tr>
<t>Users of the tag-meta data may define various actions to be taken <td align="left" colspan="1" rowspan="1">ietf:software</td>
based on the tag meta-data. These actions and their definitions are <td align="left" colspan="1" rowspan="1">Relates to software (e.g.
outside the scope of this document. Users will need to consider the , installed OS).</td>
security implications of any actions they choose to define, <td align="left" colspan="1" rowspan="1">RFC 8819</td>
including the potential for a tag to get 'masked' by another user.</t> </tr>
<tr>
</section> <td align="left" colspan="1" rowspan="1">ietf:protocol</td>
<td align="left" colspan="1" rowspan="1">Represents a protocol (of
</middle> ten combined with
<back> another tag to refine).</td>
<references title="Normative References"> <td align="left" colspan="1" rowspan="1">RFC 8819</td>
</tr>
<reference anchor='RFC2119' target='https://www.rfc-editor.org/info/rfc2119'> <tr>
<front> <td align="left" colspan="1" rowspan="1">ietf:qos</td>
<title>Key words for use in RFCs to Indicate Requirement Levels</title> <td align="left" colspan="1" rowspan="1">Relates to quality of ser
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></ vice.</td>
author> <td align="left" colspan="1" rowspan="1">RFC 8819</td>
<date year='1997' month='March' /> </tr>
<abstract><t>In many standards track documents several words are used to signify <tr>
the requirements in the specification. These words are often capitalized. This <td align="left" colspan="1" rowspan="1">ietf:network-service-app<
document defines these words as they should be interpreted in IETF documents. /td>
This document specifies an Internet Best Current Practices for the Internet Comm <td align="left" colspan="1" rowspan="1">Relates to a network serv
unity, and requests discussion and suggestions for improvements.</t></abstract> ice application (e.g.,
</front> an NTP server, DNS server, DHCP server, etc.).</td>
<seriesInfo name='BCP' value='14'/> <td align="left" colspan="1" rowspan="1">RFC 8819</td>
<seriesInfo name='RFC' value='2119'/> </tr>
<seriesInfo name='DOI' value='10.17487/RFC2119'/> <tr>
</reference> <td align="left" colspan="1" rowspan="1">ietf:system-management</t
d>
<reference anchor='RFC7950' target='https://www.rfc-editor.org/info/rfc7950'> <td align="left" colspan="1" rowspan="1">Relates to system managem
<front> ent (e.g., a system
<title>The YANG 1.1 Data Modeling Language</title> management protocol such as syslog, TACAC+, SNMP, NETCONF, etc.).</
<author initials='M.' surname='Bjorklund' fullname='M. Bjorklund' role='editor'> td>
<organization /></author> <td align="left" colspan="1" rowspan="1">RFC 8819</td>
<date year='2016' month='August' /> </tr>
<abstract><t>YANG is a data modeling language used to model configuration data, <tr>
state data, Remote Procedure Calls, and notifications for network management pro <td align="left" colspan="1" rowspan="1">ietf:oam</td>
tocols. This document describes the syntax and semantics of version 1.1 of the <td align="left" colspan="1" rowspan="1">Relates to Operations, Ad
YANG language. YANG version 1.1 is a maintenance release of the YANG language, ministration, and
addressing ambiguities and defects in the original specification. There are a s Maintenance (e.g., BFD).</td>
mall number of backward incompatibilities from YANG version 1. This document al <td align="left" colspan="1" rowspan="1">RFC 8819</td>
so specifies the YANG mappings to the Network Configuration Protocol (NETCONF).< </tr>
/t></abstract> <tr>
</front> <td align="left" colspan="1" rowspan="1">ietf:routing</td>
<seriesInfo name='RFC' value='7950'/> <td align="left" colspan="1" rowspan="1">Relates to routing.</td>
<seriesInfo name='DOI' value='10.17487/RFC7950'/> <td align="left" colspan="1" rowspan="1">RFC 8819</td>
</reference> </tr>
<tr>
<reference anchor='RFC8126' target='https://www.rfc-editor.org/info/rfc8126'> <td align="left" colspan="1" rowspan="1">ietf:security</td>
<front> <td align="left" colspan="1" rowspan="1">Related to security.</td>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title> <td align="left" colspan="1" rowspan="1">RFC 8819</td>
<author initials='M.' surname='Cotton' fullname='M. Cotton'><organization /></au </tr>
thor> <tr>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></auth <td align="left" colspan="1" rowspan="1">ietf:signaling</td>
or> <td align="left" colspan="1" rowspan="1">Relates to control-plane
<author initials='T.' surname='Narten' fullname='T. Narten'><organization /></au signaling.</td>
thor> <td align="left" colspan="1" rowspan="1">RFC 8819</td>
<date year='2017' month='June' /> </tr>
<abstract><t>Many protocols make use of points of extensibility that use constan <tr>
ts to identify various protocol parameters. To ensure that the values in these <td align="left" colspan="1" rowspan="1">ietf:link-management</td>
fields do not have conflicting uses and to promote interoperability, their alloc <td align="left" colspan="1" rowspan="1">Relates to link managemen
ations are often coordinated by a central record keeper. For IETF protocols, th t.</td>
at role is filled by the Internet Assigned Numbers Authority (IANA).</t><t>To ma <td align="left" colspan="1" rowspan="1">RFC 8819</td>
ke assignments in a given registry prudently, guidance describing the conditions </tr>
under which new values should be assigned, as well as when and how modification </tbody>
s to existing values can be made, is needed. This document defines a framework </table>
for the documentation of these guidelines by specification authors, in order to </section>
assure that the provided guidance for the IANA Considerations is clear and addre <section numbered="true" toc="include" removeInRFC="false" pn="section-7.3
sses the various issues that are likely in the operation of a registry.</t><t>Th ">
is is the third edition of this document; it obsoletes RFC 5226.</t></abstract> <name slugifiedName="name-updates-to-the-ietf-xml-reg">Updates to the IE
</front> TF XML Registry</name>
<seriesInfo name='BCP' value='26'/> <t indent="0" pn="section-7.3-1">This document registers a URI in the "I
<seriesInfo name='RFC' value='8126'/> ETF XML Registry" <xref target="RFC3688" format="default" sectionFormat="of" der
<seriesInfo name='DOI' value='10.17487/RFC8126'/> ivedContent="RFC3688"/>. Following the format in <xref target="RFC3688" format="
</reference> default" sectionFormat="of" derivedContent="RFC3688"/>, the following registrati
ons have
<reference anchor='RFC8174' target='https://www.rfc-editor.org/info/rfc8174'> been made:</t>
<front> <dl newline="false" spacing="compact" indent="3" pn="section-7.3-2">
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <dt pn="section-7.3-2.1">URI:</dt>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></auth <dd pn="section-7.3-2.2">urn:ietf:params:xml:ns:yang:ietf-module-tags<
or> /dd>
<date year='2017' month='May' /> <dt pn="section-7.3-2.3">Registrant Contact:</dt>
<abstract><t>RFC 2119 specifies common key words that may be used in protocol s <dd pn="section-7.3-2.4">The IESG.</dd>
pecifications. This document aims to reduce the ambiguity by clarifying that on <dt pn="section-7.3-2.5">XML:</dt>
ly UPPERCASE usage of the key words have the defined special meanings.</t></abs <dd pn="section-7.3-2.6">N/A; the requested URI is an XML namespace.</
tract> dd>
</front> </dl>
<seriesInfo name='BCP' value='14'/> <dl newline="false" spacing="compact" indent="3" pn="section-7.3-3">
<seriesInfo name='RFC' value='8174'/> <dt pn="section-7.3-3.1">URI:</dt>
<seriesInfo name='DOI' value='10.17487/RFC8174'/> <dd pn="section-7.3-3.2">urn:ietf:params:xml:ns:yang:ietf-module-tags-
</reference> state</dd>
<dt pn="section-7.3-3.3">Registrant Contact:</dt>
<reference anchor='RFC8342' target='https://www.rfc-editor.org/info/rfc8342'> <dd pn="section-7.3-3.4">The IESG.</dd>
<front> <dt pn="section-7.3-3.5">XML:</dt>
<title>Network Management Datastore Architecture (NMDA)</title> <dd pn="section-7.3-3.6">N/A; the requested URI is an XML namespace.</
<author initials='M.' surname='Bjorklund' fullname='M. Bjorklund'><organization dd>
/></author> </dl>
<author initials='J.' surname='Schoenwaelder' fullname='J. Schoenwaelder'><organ </section>
ization /></author> <section numbered="true" toc="include" removeInRFC="false" pn="section-7.4
<author initials='P.' surname='Shafer' fullname='P. Shafer'><organization /></au ">
thor> <name slugifiedName="name-updates-to-the-yang-module-">Updates to the YA
<author initials='K.' surname='Watsen' fullname='K. Watsen'><organization /></au NG Module Names Registry</name>
thor> <t indent="0" pn="section-7.4-1">This document registers two YANG module
<author initials='R.' surname='Wilton' fullname='R. Wilton'><organization /></au s in the "YANG Module Names"
thor> registry <xref target="RFC6020" format="default" sectionFormat="of" deriv
<date year='2018' month='March' /> edContent="RFC6020"/>. Following the
<abstract><t>Datastores are a fundamental concept binding the data models writte format in <xref target="RFC6020" format="default" sectionFormat="of" deri
n in the YANG data modeling language to network management protocols such as the vedContent="RFC6020"/>, the following
Network Configuration Protocol (NETCONF) and RESTCONF. This document defines an registrations have been made:</t>
architectural framework for datastores based on the experience gained with the <dl newline="false" spacing="compact" indent="3" pn="section-7.4-2">
initial simpler model, addressing requirements that were not well supported in t <dt pn="section-7.4-2.1">name:</dt>
he initial model. This document updates RFC 7950.</t></abstract> <dd pn="section-7.4-2.2">ietf-module-tags</dd>
</front> <dt pn="section-7.4-2.3">namespace:</dt>
<seriesInfo name='RFC' value='8342'/> <dd pn="section-7.4-2.4">urn:ietf:params:xml:ns:yang:ietf-module-tags<
<seriesInfo name='DOI' value='10.17487/RFC8342'/> /dd>
</reference> <dt pn="section-7.4-2.5">prefix:</dt>
<dd pn="section-7.4-2.6">tags</dd>
<reference anchor='RFC8199' target='https://www.rfc-editor.org/info/rfc8199'> <dt pn="section-7.4-2.7">reference:</dt>
<front> <dd pn="section-7.4-2.8">RFC 8819</dd>
<title>YANG Module Classification</title> </dl>
<author initials='D.' surname='Bogdanovic' fullname='D. Bogdanovic'><organizatio <dl newline="false" spacing="compact" indent="3" pn="section-7.4-3">
n /></author> <dt pn="section-7.4-3.1">name:</dt>
<author initials='B.' surname='Claise' fullname='B. Claise'><organization /></au <dd pn="section-7.4-3.2">ietf-module-tags-state</dd>
thor> <dt pn="section-7.4-3.3">namespace:</dt>
<author initials='C.' surname='Moberg' fullname='C. Moberg'><organization /></au <dd pn="section-7.4-3.4">urn:ietf:params:xml:ns:yang:ietf-module-tags-
thor> state</dd>
<date year='2017' month='July' /> <dt pn="section-7.4-3.5">prefix:</dt>
<abstract><t>The YANG data modeling language is currently being considered for a <dd pn="section-7.4-3.6">tags-s</dd>
wide variety of applications throughout the networking industry at large. Many <dt pn="section-7.4-3.7">reference:</dt>
standards development organizations (SDOs), open-source software projects, vend <dd pn="section-7.4-3.8">RFC 8819</dd>
ors, and users are using YANG to develop and publish YANG modules for a wide var </dl>
iety of applications. At the same time, there is currently no well-known termin </section>
ology to categorize various types of YANG modules.</t><t>A consistent terminolog </section>
y would help with the categorization of YANG modules, assist in the analysis of <section numbered="true" toc="include" removeInRFC="false" pn="section-8">
the YANG data modeling efforts in the IETF and other organizations, and bring cl <name slugifiedName="name-security-considerations">Security Considerations
arity to the YANG- related discussions between the different groups.</t><t>This </name>
document describes a set of concepts and associated terms to support consistent <t indent="0" pn="section-8-1">The YANG module defined in this memo is des
classification of YANG modules.</t></abstract> igned to be accessed via
</front> the NETCONF protocol <xref target="RFC6241" format="default" sectionFormat
<seriesInfo name='RFC' value='8199'/> ="of" derivedContent="RFC6241"/>. The
<seriesInfo name='DOI' value='10.17487/RFC8199'/> lowest NETCONF layer is the secure transport layer and the
</reference> mandatory-to-implement secure transport is Secure Shell (SSH) <xref target
="RFC6242" format="default" sectionFormat="of" derivedContent="RFC6242"/>.</t>
<reference anchor='RFC8407' target='https://www.rfc-editor.org/info/rfc8407'> <t indent="0" pn="section-8-2">This document adds the ability to associate
<front> tag metadata with YANG
<title>Guidelines for Authors and Reviewers of Documents Containing YANG Data Mo modules. This document does not define any actions based on these
dels</title> associations, and none are yet defined; therefore, it does not by
<author initials='A.' surname='Bierman' fullname='A. Bierman'><organization /></ itself introduce any new security considerations directly.</t>
author> <t indent="0" pn="section-8-3">Users of the tag metadata may define variou
<date year='2018' month='October' /> s actions to be taken
<abstract><t>This memo provides guidelines for authors and reviewers of specific based on the tag metadata. These actions and their definitions are
ations containing YANG modules. Recommendations and procedures are defined, whi outside the scope of this document. Users will need to consider the
ch are intended to increase interoperability and usability of Network Configurat security implications of any actions they choose to define, including
ion Protocol (NETCONF) and RESTCONF protocol implementations that utilize YANG m the potential for a tag to get 'masked' by another user.</t>
odules. This document obsoletes RFC 6087.</t></abstract> </section>
</front> </middle>
<seriesInfo name='BCP' value='216'/> <back>
<seriesInfo name='RFC' value='8407'/> <references pn="section-9">
<seriesInfo name='DOI' value='10.17487/RFC8407'/> <name slugifiedName="name-references">References</name>
</reference> <references pn="section-9.1">
</references> <name slugifiedName="name-normative-references">Normative References</na
<references title="Informative References"> me>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
<reference anchor='RFC3688' target='https://www.rfc-editor.org/info/rfc3688'> 119" quoteTitle="true" derivedAnchor="RFC2119">
<front> <front>
<title>The IETF XML Registry</title> <title>Key words for use in RFCs to Indicate Requirement Levels</tit
<author initials='M.' surname='Mealling' fullname='M. Mealling'><organization /> le>
</author> <author initials="S." surname="Bradner" fullname="S. Bradner">
<date year='2004' month='January' /> <organization showOnFrontPage="true"/>
<abstract><t>This document describes an IANA maintained registry for IETF standa </author>
rds which use Extensible Markup Language (XML) related items such as Namespaces, <date year="1997" month="March"/>
Document Type Declarations (DTDs), Schemas, and Resource Description Framework <abstract>
(RDF) Schemas.</t></abstract> <t indent="0">In many standards track documents several words are
</front> used to signify the requirements in the specification. These words are often ca
<seriesInfo name='BCP' value='81'/> pitalized. This document defines these words as they should be interpreted in IE
<seriesInfo name='RFC' value='3688'/> TF documents. This document specifies an Internet Best Current Practices for th
<seriesInfo name='DOI' value='10.17487/RFC3688'/> e Internet Community, and requests discussion and suggestions for improvements.<
</reference> /t>
</abstract>
<reference anchor='RFC5198' target='https://www.rfc-editor.org/info/rfc5198'> </front>
<front> <seriesInfo name="BCP" value="14"/>
<title>Unicode Format for Network Interchange</title> <seriesInfo name="RFC" value="2119"/>
<author initials='J.' surname='Klensin' fullname='J. Klensin'><organization /></ <seriesInfo name="DOI" value="10.17487/RFC2119"/>
author> </reference>
<author initials='M.' surname='Padlipsky' fullname='M. Padlipsky'><organization <reference anchor="RFC7950" target="https://www.rfc-editor.org/info/rfc7
/></author> 950" quoteTitle="true" derivedAnchor="RFC7950">
<date year='2008' month='March' /> <front>
<abstract><t>The Internet today is in need of a standardized form for the transm <title>The YANG 1.1 Data Modeling Language</title>
ission of internationalized &quot;text&quot; information, paralleling the specif <author initials="M." surname="Bjorklund" fullname="M. Bjorklund" ro
ications for the use of ASCII that date from the early days of the ARPANET. Thi le="editor">
s document specifies that format, using UTF-8 with normalization and specific li <organization showOnFrontPage="true"/>
ne-ending sequences. [STANDARDS-TRACK]</t></abstract> </author>
</front> <date year="2016" month="August"/>
<seriesInfo name='RFC' value='5198'/> <abstract>
<seriesInfo name='DOI' value='10.17487/RFC5198'/> <t indent="0">YANG is a data modeling language used to model confi
</reference> guration data, state data, Remote Procedure Calls, and notifications for network
management protocols. This document describes the syntax and semantics of vers
<reference anchor='RFC6020' target='https://www.rfc-editor.org/info/rfc6020'> ion 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the
<front> YANG language, addressing ambiguities and defects in the original specification.
<title>YANG - A Data Modeling Language for the Network Configuration Protocol (N There are a small number of backward incompatibilities from YANG version 1. T
ETCONF)</title> his document also specifies the YANG mappings to the Network Configuration Proto
<author initials='M.' surname='Bjorklund' fullname='M. Bjorklund' role='editor'> col (NETCONF).</t>
<organization /></author> </abstract>
<date year='2010' month='October' /> </front>
<abstract><t>YANG is a data modeling language used to model configuration and st <seriesInfo name="RFC" value="7950"/>
ate data manipulated by the Network Configuration Protocol (NETCONF), NETCONF re <seriesInfo name="DOI" value="10.17487/RFC7950"/>
mote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</t></abstract </reference>
> <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8
</front> 126" quoteTitle="true" derivedAnchor="RFC8126">
<seriesInfo name='RFC' value='6020'/> <front>
<seriesInfo name='DOI' value='10.17487/RFC6020'/> <title>Guidelines for Writing an IANA Considerations Section in RFCs
</reference> </title>
<author initials="M." surname="Cotton" fullname="M. Cotton">
<reference anchor='RFC6241' target='https://www.rfc-editor.org/info/rfc6241'> <organization showOnFrontPage="true"/>
<front> </author>
<title>Network Configuration Protocol (NETCONF)</title> <author initials="B." surname="Leiba" fullname="B. Leiba">
<author initials='R.' surname='Enns' fullname='R. Enns' role='editor'><organizat <organization showOnFrontPage="true"/>
ion /></author> </author>
<author initials='M.' surname='Bjorklund' fullname='M. Bjorklund' role='editor'> <author initials="T." surname="Narten" fullname="T. Narten">
<organization /></author> <organization showOnFrontPage="true"/>
<author initials='J.' surname='Schoenwaelder' fullname='J. Schoenwaelder' role=' </author>
editor'><organization /></author> <date year="2017" month="June"/>
<author initials='A.' surname='Bierman' fullname='A. Bierman' role='editor'><org <abstract>
anization /></author> <t indent="0">Many protocols make use of points of extensibility t
<date year='2011' month='June' /> hat use constants to identify various protocol parameters. To ensure that the v
<abstract><t>The Network Configuration Protocol (NETCONF) defined in this docume alues in these fields do not have conflicting uses and to promote interoperabili
nt provides mechanisms to install, manipulate, and delete the configuration of n ty, their allocations are often coordinated by a central record keeper. For IET
etwork devices. It uses an Extensible Markup Language (XML)-based data encoding F protocols, that role is filled by the Internet Assigned Numbers Authority (IAN
for the configuration data as well as the protocol messages. The NETCONF proto A).</t>
col operations are realized as remote procedure calls (RPCs). This document obs <t indent="0">To make assignments in a given registry prudently, g
oletes RFC 4741. [STANDARDS-TRACK]</t></abstract> uidance describing the conditions under which new values should be assigned, as
</front> well as when and how modifications to existing values can be made, is needed. T
<seriesInfo name='RFC' value='6241'/> his document defines a framework for the documentation of these guidelines by sp
<seriesInfo name='DOI' value='10.17487/RFC6241'/> ecification authors, in order to assure that the provided guidance for the IANA
</reference> Considerations is clear and addresses the various issues that are likely in the
operation of a registry.</t>
<reference anchor='RFC6242' target='https://www.rfc-editor.org/info/rfc6242'> <t indent="0">This is the third edition of this document; it obsol
<front> etes RFC 5226.</t>
<title>Using the NETCONF Protocol over Secure Shell (SSH)</title> </abstract>
<author initials='M.' surname='Wasserman' fullname='M. Wasserman'><organization </front>
/></author> <seriesInfo name="BCP" value="26"/>
<date year='2011' month='June' /> <seriesInfo name="RFC" value="8126"/>
<abstract><t>This document describes a method for invoking and running the Netwo <seriesInfo name="DOI" value="10.17487/RFC8126"/>
rk Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SS </reference>
H subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK]</t></abstract <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
> 174" quoteTitle="true" derivedAnchor="RFC8174">
</front> <front>
<seriesInfo name='RFC' value='6242'/> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
<seriesInfo name='DOI' value='10.17487/RFC6242'/> tle>
</reference> <author initials="B." surname="Leiba" fullname="B. Leiba">
<organization showOnFrontPage="true"/>
<reference anchor='RFC8340' target='https://www.rfc-editor.org/info/rfc8340'> </author>
<front> <date year="2017" month="May"/>
<title>YANG Tree Diagrams</title> <abstract>
<author initials='M.' surname='Bjorklund' fullname='M. Bjorklund'><organization <t indent="0">RFC 2119 specifies common key words that may be used
/></author> in protocol specifications. This document aims to reduce the ambiguity by cla
<author initials='L.' surname='Berger' fullname='L. Berger' role='editor'><organ rifying that only UPPERCASE usage of the key words have the defined special mea
ization /></author> nings.</t>
<date year='2018' month='March' /> </abstract>
<abstract><t>This document captures the current syntax used in YANG module tree </front>
diagrams. The purpose of this document is to provide a single location for this <seriesInfo name="BCP" value="14"/>
definition. This syntax may be updated from time to time based on the evolutio <seriesInfo name="RFC" value="8174"/>
n of the YANG language.</t></abstract> <seriesInfo name="DOI" value="10.17487/RFC8174"/>
</front> </reference>
<seriesInfo name='BCP' value='215'/> <reference anchor="RFC8199" target="https://www.rfc-editor.org/info/rfc8
<seriesInfo name='RFC' value='8340'/> 199" quoteTitle="true" derivedAnchor="RFC8199">
<seriesInfo name='DOI' value='10.17487/RFC8340'/> <front>
</reference> <title>YANG Module Classification</title>
</references> <author initials="D." surname="Bogdanovic" fullname="D. Bogdanovic">
<organization showOnFrontPage="true"/>
<section title="Examples"> </author>
<t>The following is a fictional NETCONF example result from a query of <author initials="B." surname="Claise" fullname="B. Claise">
the module tags list. For the sake of brevity only a few module <organization showOnFrontPage="true"/>
results are imagined.</t> </author>
<author initials="C." surname="Moberg" fullname="C. Moberg">
<figure title="Example NETCONF Query Output" anchor="sec-example-netconf-query-o <organization showOnFrontPage="true"/>
utput"><artwork><![CDATA[ </author>
<ns0:data xmlns:ns0="urn:ietf:params:xml:ns:netconf:base:1.0"> <date year="2017" month="July"/>
<t:module-tags xmlns:t="urn:ietf:params:xml:ns:yang:ietf-module-tags"> <abstract>
<t:module> <t indent="0">The YANG data modeling language is currently being c
<t:name>ietf-bfd</t:name> onsidered for a wide variety of applications throughout the networking industry
<t:tag>ietf:network-element-class</t:tag> at large. Many standards development organizations (SDOs), open-source software
<t:tag>ietf:oam</t:tag> projects, vendors, and users are using YANG to develop and publish YANG modules
<t:tag>ietf:protocol</t:tag> for a wide variety of applications. At the same time, there is currently no we
<t:tag>ietf:sdo-defined-class</t:tag> ll-known terminology to categorize various types of YANG modules.</t>
</t:module> <t indent="0">A consistent terminology would help with the categor
<t:module> ization of YANG modules, assist in the analysis of the YANG data modeling effort
<t:name>ietf-isis</t:name> s in the IETF and other organizations, and bring clarity to the YANG- related di
<t:tag>ietf:network-element-class</t:tag> scussions between the different groups.</t>
<t:tag>ietf:protocol</t:tag> <t indent="0">This document describes a set of concepts and associ
<t:tag>ietf:sdo-defined-class</t:tag> ated terms to support consistent classification of YANG modules.</t>
<t:tag>ietf:routing</t:tag> </abstract>
</t:module> </front>
<t:module> <seriesInfo name="RFC" value="8199"/>
<t:name>ietf-ssh-server</t:name> <seriesInfo name="DOI" value="10.17487/RFC8199"/>
<t:tag>ietf:network-element-class</t:tag> </reference>
<t:tag>ietf:protocol</t:tag> <reference anchor="RFC8342" target="https://www.rfc-editor.org/info/rfc8
<t:tag>ietf:sdo-defined-class</t:tag> 342" quoteTitle="true" derivedAnchor="RFC8342">
<t:tag>ietf:system-management</t:tag> <front>
</t:module> <title>Network Management Datastore Architecture (NMDA)</title>
</t:module-tags> <author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
</ns0:data> <organization showOnFrontPage="true"/>
]]></artwork></figure> </author>
<author initials="J." surname="Schoenwaelder" fullname="J. Schoenwae
</section> lder">
<organization showOnFrontPage="true"/>
<section title="Acknowledgements"> </author>
<t>Special thanks to Robert Wilton for his help improving the <author initials="P." surname="Shafer" fullname="P. Shafer">
introduction and providing the example use cases, as well as <organization showOnFrontPage="true"/>
generating the non-NMDA module.</t> </author>
<author initials="K." surname="Watsen" fullname="K. Watsen">
</section> <organization showOnFrontPage="true"/>
</author>
<section title="Non-NMDA State Module."> <author initials="R." surname="Wilton" fullname="R. Wilton">
<t>As per <xref target="RFC8407"/> the following is a non-NMDA module to support <organization showOnFrontPage="true"/>
viewing the operational state for non-NMDA compliant servers.</t> </author>
<date year="2018" month="March"/>
<figure title="Non-NMDA Module Tags State Module" anchor="sec-non-nmda-module-ta <abstract>
gs-state-module"><artwork><![CDATA[ <t indent="0">Datastores are a fundamental concept binding the dat
<CODE BEGINS> file "ietf-module-tags-state@2020-02-29.yang" a models written in the YANG data modeling language to network management protoc
ols such as the Network Configuration Protocol (NETCONF) and RESTCONF. This docu
ment defines an architectural framework for datastores based on the experience g
ained with the initial simpler model, addressing requirements that were not well
supported in the initial model. This document updates RFC 7950.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8342"/>
<seriesInfo name="DOI" value="10.17487/RFC8342"/>
</reference>
<reference anchor="RFC8407" target="https://www.rfc-editor.org/info/rfc8
407" quoteTitle="true" derivedAnchor="RFC8407">
<front>
<title>Guidelines for Authors and Reviewers of Documents Containing
YANG Data Models</title>
<author initials="A." surname="Bierman" fullname="A. Bierman">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="October"/>
<abstract>
<t indent="0">This memo provides guidelines for authors and review
ers of specifications containing YANG modules. Recommendations and procedures a
re defined, which are intended to increase interoperability and usability of Net
work Configuration Protocol (NETCONF) and RESTCONF protocol implementations that
utilize YANG modules. This document obsoletes RFC 6087.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="216"/>
<seriesInfo name="RFC" value="8407"/>
<seriesInfo name="DOI" value="10.17487/RFC8407"/>
</reference>
</references>
<references pn="section-9.2">
<name slugifiedName="name-informative-references">Informative References
</name>
<reference anchor="RFC3688" target="https://www.rfc-editor.org/info/rfc3
688" quoteTitle="true" derivedAnchor="RFC3688">
<front>
<title>The IETF XML Registry</title>
<author initials="M." surname="Mealling" fullname="M. Mealling">
<organization showOnFrontPage="true"/>
</author>
<date year="2004" month="January"/>
<abstract>
<t indent="0">This document describes an IANA maintained registry
for IETF standards which use Extensible Markup Language (XML) related items such
as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Descrip
tion Framework (RDF) Schemas.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="81"/>
<seriesInfo name="RFC" value="3688"/>
<seriesInfo name="DOI" value="10.17487/RFC3688"/>
</reference>
<reference anchor="RFC5198" target="https://www.rfc-editor.org/info/rfc5
198" quoteTitle="true" derivedAnchor="RFC5198">
<front>
<title>Unicode Format for Network Interchange</title>
<author initials="J." surname="Klensin" fullname="J. Klensin">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Padlipsky" fullname="M. Padlipsky">
<organization showOnFrontPage="true"/>
</author>
<date year="2008" month="March"/>
<abstract>
<t indent="0">The Internet today is in need of a standardized form
for the transmission of internationalized "text" information, paralleling the s
pecifications for the use of ASCII that date from the early days of the ARPANET.
This document specifies that format, using UTF-8 with normalization and specif
ic line-ending sequences. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5198"/>
<seriesInfo name="DOI" value="10.17487/RFC5198"/>
</reference>
<reference anchor="RFC6020" target="https://www.rfc-editor.org/info/rfc6
020" quoteTitle="true" derivedAnchor="RFC6020">
<front>
<title>YANG - A Data Modeling Language for the Network Configuration
Protocol (NETCONF)</title>
<author initials="M." surname="Bjorklund" fullname="M. Bjorklund" ro
le="editor">
<organization showOnFrontPage="true"/>
</author>
<date year="2010" month="October"/>
<abstract>
<t indent="0">YANG is a data modeling language used to model confi
guration and state data manipulated by the Network Configuration Protocol (NETCO
NF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK
]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6020"/>
<seriesInfo name="DOI" value="10.17487/RFC6020"/>
</reference>
<reference anchor="RFC6241" target="https://www.rfc-editor.org/info/rfc6
241" quoteTitle="true" derivedAnchor="RFC6241">
<front>
<title>Network Configuration Protocol (NETCONF)</title>
<author initials="R." surname="Enns" fullname="R. Enns" role="editor
">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Bjorklund" fullname="M. Bjorklund" ro
le="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Schoenwaelder" fullname="J. Schoenwae
lder" role="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Bierman" fullname="A. Bierman" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<date year="2011" month="June"/>
<abstract>
<t indent="0">The Network Configuration Protocol (NETCONF) defined
in this document provides mechanisms to install, manipulate, and delete the con
figuration of network devices. It uses an Extensible Markup Language (XML)-base
d data encoding for the configuration data as well as the protocol messages. Th
e NETCONF protocol operations are realized as remote procedure calls (RPCs). Th
is document obsoletes RFC 4741. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6241"/>
<seriesInfo name="DOI" value="10.17487/RFC6241"/>
</reference>
<reference anchor="RFC6242" target="https://www.rfc-editor.org/info/rfc6
242" quoteTitle="true" derivedAnchor="RFC6242">
<front>
<title>Using the NETCONF Protocol over Secure Shell (SSH)</title>
<author initials="M." surname="Wasserman" fullname="M. Wasserman">
<organization showOnFrontPage="true"/>
</author>
<date year="2011" month="June"/>
<abstract>
<t indent="0">This document describes a method for invoking and ru
nning the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) s
ession as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK
]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6242"/>
<seriesInfo name="DOI" value="10.17487/RFC6242"/>
</reference>
<reference anchor="RFC8340" target="https://www.rfc-editor.org/info/rfc8
340" quoteTitle="true" derivedAnchor="RFC8340">
<front>
<title>YANG Tree Diagrams</title>
<author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
<organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Berger" fullname="L. Berger" role="ed
itor">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="March"/>
<abstract>
<t indent="0">This document captures the current syntax used in YA
NG module tree diagrams. The purpose of this document is to provide a single lo
cation for this definition. This syntax may be updated from time to time based
on the evolution of the YANG language.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="215"/>
<seriesInfo name="RFC" value="8340"/>
<seriesInfo name="DOI" value="10.17487/RFC8340"/>
</reference>
</references>
</references>
<section numbered="true" toc="include" removeInRFC="false" pn="section-appen
dix.a">
<name slugifiedName="name-examples">Examples</name>
<t indent="0" pn="section-appendix.a-1">The following is a fictional NETCO
NF example result from a query of
the module tags list. For the sake of brevity, only a few module results
are shown.</t>
<figure anchor="sec-example-netconf-query-output" align="left" suppress-ti
tle="false" pn="figure-3">
<name slugifiedName="name-example-netconf-query-outpu">Example NETCONF Q
uery Output</name>
<sourcecode type="xml" markers="false" pn="section-appendix.a-2.1">
&lt;ns0:data xmlns:ns0="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
&lt;t:module-tags
xmlns:t="urn:ietf:params:xml:ns:yang:ietf-module-tags"&gt;
&lt;t:module&gt;
&lt;t:name&gt;ietf-bfd&lt;/t:name&gt;
&lt;t:tag&gt;ietf:network-element-class&lt;/t:tag&gt;
&lt;t:tag&gt;ietf:oam&lt;/t:tag&gt;
&lt;t:tag&gt;ietf:protocol&lt;/t:tag&gt;
&lt;t:tag&gt;ietf:sdo-defined-class&lt;/t:tag&gt;
&lt;/t:module&gt;
&lt;t:module&gt;
&lt;t:name&gt;ietf-isis&lt;/t:name&gt;
&lt;t:tag&gt;ietf:network-element-class&lt;/t:tag&gt;
&lt;t:tag&gt;ietf:protocol&lt;/t:tag&gt;
&lt;t:tag&gt;ietf:sdo-defined-class&lt;/t:tag&gt;
&lt;t:tag&gt;ietf:routing&lt;/t:tag&gt;
&lt;/t:module&gt;
&lt;t:module&gt;
&lt;t:name&gt;ietf-ssh-server&lt;/t:name&gt;
&lt;t:tag&gt;ietf:network-element-class&lt;/t:tag&gt;
&lt;t:tag&gt;ietf:protocol&lt;/t:tag&gt;
&lt;t:tag&gt;ietf:sdo-defined-class&lt;/t:tag&gt;
&lt;t:tag&gt;ietf:system-management&lt;/t:tag&gt;
&lt;/t:module&gt;
&lt;/t:module-tags&gt;
&lt;/ns0:data&gt;
</sourcecode>
</figure>
</section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-appen
dix.b">
<name slugifiedName="name-non-nmda-state-module">Non-NMDA State Module</na
me>
<t indent="0" pn="section-appendix.b-1">As per <xref target="RFC8407" form
at="default" sectionFormat="of" derivedContent="RFC8407"/>, the following is a
non-NMDA module to support viewing the operational state for non-NMDA
compliant servers.</t>
<figure anchor="sec-non-nmda-module-tags-state-module" align="left" suppre
ss-title="false" pn="figure-4">
<name slugifiedName="name-non-nmda-module-tags-state-">Non-NMDA Module T
ags State Module</name>
<sourcecode name="ietf-module-tags-state@2020-12-22.yang" type="yang" ma
rkers="true" pn="section-appendix.b-2.1">
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;
} }
organization organization
"IETF NetMod Working Group (NetMod)"; "IETF NetMod Working Group (NetMod)";
contact contact
"WG Web: <https://tools.ietf.org/wg/netmod/> "WG Web: &lt;https://datatracker.ietf.org/wg/netmod/&gt;
WG List: <mailto:netmod@ietf.org> WG List: &lt;mailto:netmod@ietf.org&gt;
Author: Christian Hopps Author: Christian Hopps
<mailto:chopps@chopps.org&gt; &lt;mailto:chopps@chopps.org&gt;
Author: Lou Berger Author: Lou Berger
<mailto:lberger@labn.net&gt; &lt;mailto:lberger@labn.net&gt;
Author: Dean Bogdanovic Author: Dean Bogdanovic
<ivandean@gmail.com>"; &lt;mailto:ivandean@gmail.com&gt;";
// RFC Ed.: replace XXXX with actual RFC number and
// remove this note.
description description
"This module describes a mechanism associating tags with YANG "This module describes a mechanism associating tags with YANG
modules. Tags may be IANA assigned or privately defined. modules. Tags may be IANA assigned or privately defined.
This is a temporary non-NMDA module that is for use by This is a temporary non-NMDA module that is for use by
implementations that don't yet support NMDA. implementations that don't yet support NMDA.
Copyright (c) 2019 IETF Trust and the persons identified as Copyright (c) 2020 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 Simplified BSD License set the license terms contained in, the Simplified 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 8819
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself (https://www.rfc-editor.org/info/rfc8819); see the RFC itself
for full legal notices. for full legal notices.";
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 2020-02-29 { revision 2020-12-22 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: YANG Module Tags"; "RFC 8819: YANG Module Tags";
} }
container module-tags-state { container module-tags-state {
config false; config false;
status deprecated; status deprecated;
description description
"Contains the list of modules and their associated tags"; "Contains the list of modules and their associated tags.";
list module { list module {
key "name"; key "name";
status deprecated; status deprecated;
description description
"A list of modules and their associated tags"; "A list of modules and their associated tags.";
leaf name { leaf name {
type yang:yang-identifier; type yang:yang-identifier;
mandatory true; mandatory true;
status deprecated; status deprecated;
description description
"The YANG module name."; "The YANG module name.";
} }
leaf-list tag { leaf-list tag {
type tags:tag; type tags:tag;
status deprecated; status deprecated;
description description
"Tags associated with the module. See the IANA 'YANG Module "Tags associated with the module. See the IANA 'YANG
Tag Prefixes' registry for reserved prefixes and the IANA Module Tag Prefixes' registry for reserved prefixes and
'IETF YANG Module Tags' registry for IETF tags. the IANA 'IETF YANG Module Tags' registry for IETF tags.
The contents of this list is constructed using the The contents of this list is constructed using the
following steps: following steps:
1) System tags (i.e., tags of added by the system) are added. 1) System tags (i.e., tags of added by the system) are
2) User configured tags (i.e., tags added by configuration) added.
are added. 2) User-configured tags (i.e., tags added by
3) Any tag that is equal to a masked-tag present in the configuration) are added.
corresponding ietf-module-tags:module-tags:module-tag leaf 3) Any tag that is equal to a masked-tag present in the
list for this module is removed."; corresponding ietf-module-tags:module-tags:module-tag leaf
list for this module is removed.";
} }
} }
} }
} }
<CODE ENDS> </sourcecode>
]]></artwork></figure> </figure>
</section>
</section> <section numbered="false" toc="include" removeInRFC="false" pn="section-appe
ndix.c">
<name slugifiedName="name-acknowledgements">Acknowledgements</name>
<t indent="0" pn="section-appendix.c-1">Special thanks to <contact fullnam
e="Robert Wilton"/> for his help
improving the introduction and providing the example use cases, as well
as generating the non-NMDA module.</t>
</section>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
="include" pn="section-appendix.d">
<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
<author initials="C." surname="Hopps" fullname="Christian Hopps">
<organization showOnFrontPage="true">LabN Consulting, L.L.C.</organizati
on>
<address>
<email>chopps@chopps.org</email>
</address>
</author>
<author initials="L." surname="Berger" fullname="Lou Berger">
<organization showOnFrontPage="true">LabN Consulting, L.L.C.</organizati
on>
<address>
<email>lberger@labn.net</email>
</address>
</author>
<author initials="D." surname="Bogdanovic" fullname="Dean Bogdanovic">
<organization showOnFrontPage="true">Volta Networks</organization>
<address>
<email>ivandean@gmail.com</email>
</address>
</author>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 43 change blocks. 
818 lines changed or deleted 1376 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/