rfc8819xml2.original.xml   rfc8819.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" []> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<?rfc toc="yes"?>
<?rfc compact="no"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no"?>
<?rfc strict="yes"?>
<rfc ipr="trust200902"
category="std"
docName="draft-ietf-netmod-module-tags-10" updates="8407"
submissionType="IETF">
<front>
<title abbrev="YANG Module Tags">YANG Module Tags</title>
<author initials='C.' surname='Hopps' fullname='Christian Hopps'><organization>L
abN Consulting, L.L.C.</organization><address><email>chopps@chopps.org</email></
address></author>
<author initials='L.' surname='Berger' fullname='Lou Berger'><organization>LabN
Consulting, LLC.</organization><address><email>lberger@labn.net</email></address
></author>
<author initials='D.' surname='Bogdanovic' fullname='Dean Bogdanovic'><organizat
ion>Volta Networks</organization><address><email>ivandean@gmail.com</email></add
ress></author> <date/><abstract><t>This document provides for the association o
f tags with YANG modules.
The expectation is for such tags to be used to help classify and
organize modules. A method for defining, reading and writing a
modules tags is provided. Tags may be registered and assigned
during module definition; assigned by implementations; or dynamically
defined and set by users. This document also provides guidance to
future model writers; as such, this document updates RFC8407.</t></abstract> </
front> <middle>
<section title="Introduction">
<t>The use of tags for classification and organization is fairly
ubiquitous not only within IETF protocols, but in the internet itself
(e.g., <spanx style='verb'>#hashtags</spanx>). One benefit of using tags for org
anization 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>This document defines a YANG module <xref target="RFC7950"/> which
provides a list of module entries to allow for adding or removing of
tags as well as viewing the set of tags associated with a module.</t>
<t>This document defines an extension statement to be used to indicate
tags that SHOULD be added by the module implementation automatically
(i.e., outside of configuration).</t>
<t>This document also defines an IANA registry for tag prefixes as well
as a set of globally assigned tags.</t>
<t><xref target="sec-guidelines-to-model-writers"></xref> provides guidelines fo
r authors of YANG
data models.</t>
<t>This document updates <xref target="RFC8407"/>.</t>
<t>The YANG data model in this document conforms to the Network
Management Datastore Architecture defined in <xref target="RFC8342"/>.</t>
<section title="Some possible use cases for YANG module tags">
<t>During this documents's development there 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>One example use of tags would be to help 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>Tags can also be used to help coordination 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>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>Future management protocol extensions could 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 title="Conventions Used in This Document">
<t>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
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appe
ar in all capitals, as
shown here.</t>
</section>
</section>
<section title="Tag Values">
<t>All tags SHOULD begin with a prefix indicating who owns their
definition. An IANA registry (<xref target="sec-yang-module-tag-prefixes-registr
y"></xref>) is
used to support registering tag prefixes. Currently 3 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>Again, except for the conflict-avoiding prefix, this document is not
specifying any structure on (i.e., restricting) the tag values on
purpose. 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 title="IETF Tags" anchor="sec-ietf-tags">
<t>An IETF tag is a tag that has the prefix "ietf:". All IETF tags are
registered with IANA in a registry defined later in this document
(<xref target="sec-ietf-yang-module-tags-registry"></xref>).</t>
</section>
<section title="Vendor Tags">
<t>A vendor tag is a tag that has the prefix "vendor:". These tags are
defined by the vendor that implements the module, and are not
registered; however, it is RECOMMENDED that the vendor include
extra identification in the tag to avoid collisions such as using the
enterpise or organization name following the "vendor:" prefix (e.g.,
vendor:example.com:vendor-defined-classifier).</t>
</section>
<section title="User Tags">
<t>A user tag is any tag that has the prefix "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 RECOMMENDED as it helps avoid collisions.</t>
</section>
<section title="Reserved Tags">
<t>Any tag not starting with the prefix "ietf:", "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 title="Tag Management">
<t>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 title="Module Definition Tagging">
<t>A module definition MAY 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>If the module is defined in an IETF standards track document, the
tags MUST be <xref format="counter" target="sec-ietf-tags">IETF Tags</xref>. Thu
s, new modules can drive the addition of
new IETF tags to the IANA registry defined in <xref target="sec-ietf-yang-module
-tags-registry"></xref>, and the IANA registry can serve as a check against
duplication.</t>
</section>
<section title="Implementation Tagging">
<t>An implementation MAY include additional tags associated with a
module. These tags SHOULD be IETF Tags (i.e., registered) or vendor
specific tags.</t>
</section>
<section title="User Tagging"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"
<t>Tags of any kind, with or without a prefix, can be assigned and submissionType="IETF" category="std" consensus="true"
removed by the user using normal configuration mechanisms. In order number="8819" docName="draft-ietf-netmod-module-tags-10" updates="8407"
to remove a tag from the operational datastore the user adds a obsoletes="" xml:lang="en" tocInclude="true" symRefs="true"
matching <spanx style='verb'>masked-tag</spanx> entry for a given module.</t> sortRefs="true" version="3">
</section> <!-- xml2rfc v2v3 conversion 2.41.0 -->
<front>
<title abbrev="YANG Module Tags">YANG Module Tags</title>
<seriesInfo name="RFC" value="8819" />
<author initials="C." surname="Hopps" fullname="Christian Hopps">
<organization>LabN Consulting, L.L.C.</organization>
<address>
<email>chopps@chopps.org</email>
</address>
</author>
<author initials="L." surname="Berger" fullname="Lou Berger">
<organization>LabN Consulting, LLC.</organization>
<address>
<email>lberger@labn.net</email>
</address>
</author>
<author initials="D." surname="Bogdanovic" fullname="Dean Bogdanovic">
<organization>Volta Networks</organization>
<address>
<email>ivandean@gmail.com</email>
</address>
</author>
<date month="September" year="2020" />
</section> <keyword>YANG</keyword>
<keyword>tags</keyword>
<section title="Tags Module Structure"> <abstract>
<section title="Tags Module Tree"> <t>This document provides for the association of tags with YANG
<t>The tree associated with the "ietf-module-tags" module follows. The modules. The expectation is for such tags to be used to help classify
meaning of the symbols can be found in <xref target="RFC8340"/>.</t> and organize modules. A method for defining, reading, and writing
modules tags is provided. Tags may be registered and assigned during
module definition, assigned by implementations, or dynamically defined
and set by users. This document also provides guidance to future model
writers; as such, this document updates RFC 8407.</t>
</abstract>
</front>
<middle>
<section numbered="true" toc="default">
<name>Introduction</name>
<t>The use of tags for classification and organization is fairly
ubiquitous not only within IETF protocols but in the internet itself
(e.g., <tt>#hashtags</tt>).
<!--[rfced] When we converted this document to v3, xml2rfc converted <spanx
style="verb"> to <tt>. In the html and pdf output, the text enclosed in <tt>
is output in fixed-width font. In the txt output, the text enclosed in <tt>
appears in quotation marks.
<figure title="YANG Module Tags Tree Diagram" anchor="sec-yang-module-tags-tree- Please review carefully and let us know if the output is acceptable or if any
diagram"><artwork><![CDATA[ updates are needed.
-->
One benefit of using tags for organization
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>This document defines a YANG module <xref target="RFC7950"
format="default"/> that 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>This document defines an extension statement to indicate
tags that <bcp14>SHOULD</bcp14> be added by the module implementation
automatically (i.e., outside of configuration).</t>
<t>This document also defines an IANA registry for tag prefixes as well
as a set of globally assigned tags.</t>
<t><xref target="sec-guidelines-to-model-writers" format="default"/>
provides guidelines for authors of YANG data models.</t>
<t>This document updates <xref target="RFC8407" format="default"/>.</t>
<t>The YANG data model in this document conforms to the Network
Management Datastore Architecture (NMDA) defined in <xref target="RFC8342"
format="default"/>.</t>
<section numbered="true" toc="default">
<name>Some Possible Use Cases for YANG Module Tags</name>
<t>During this document's development, there 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>One example use of tags would be to help 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>Tags can also be used to help coordination 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>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>Future management protocol extensions could 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="default">
<name>Conventions Used in This Document</name>
<t>
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&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section>
</section>
<section numbered="true" toc="default">
<name>Tag Values</name>
<t>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"/>) 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>Again, except for the conflict-avoiding prefix, 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="default">
<name>IETF Tags</name>
<t>An IETF tag is a tag that has the prefix "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"/>).</t>
</section>
<section numbered="true" toc="default">
<name>Vendor Tags</name>
<t>A vendor tag is a tag that has the prefix "vendor:". These tags are
defined by the vendor that implements the module and are not
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="default">
<name>User Tags</name>
<t>A user tag is any tag that has the prefix "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="default">
<name>Reserved Tags</name>
<t>Any tag not starting with the prefix "ietf:", "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="default">
<name>Tag Management</name>
<t>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="default">
<name>Module Definition Tagging</name>
<t>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>If the module is defined in an IETF Standards Track document, the
tags <bcp14>MUST</bcp14> be IETF Tags (<xref
target="sec-ietf-tags"/>). Thus, new modules can drive
the addition of new IETF tags to the IANA registry defined in <xref
target="sec-ietf-yang-module-tags-registry" format="default"/>, and
the IANA registry can serve as a check against duplication.</t>
</section>
<section numbered="true" toc="default">
<name>Implementation Tagging</name>
<t>An implementation <bcp14>MAY</bcp14> include 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="default">
<name>User Tagging</name>
<t>Tags of any kind, with or without a prefix, 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="default">
<name>Tags Module Structure</name>
<section numbered="true" toc="default">
<name>Tags Module Tree</name>
<t>The tree associated with the "ietf-module-tags" module follows. The
meaning of the symbols can be found in <xref target="RFC8340"
format="default"/>.</t>
<figure anchor="sec-yang-module-tags-tree-diagram">
<name>YANG Module Tags Tree Diagram</name>
<sourcecode type="yangtree">
<![CDATA[
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>
</section> </figure>
</section>
<section title="YANG Module"> <section numbered="true" toc="default">
<figure title="Module Tags Module" anchor="sec-module-tags-module"><artwork><![C <name>YANG Module</name>
DATA[ <figure anchor="sec-module-tags-module">
<CODE BEGINS> file "ietf-module-tags@2020-02-29.yang" <name>Module Tags Module</name>
<sourcecode name="ietf-module-tags@2020-08-05.yang" type="yang" marker
s="true"><![CDATA[
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: <https://datatracker.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org> WG List: <mailto:netmod@ietf.org>
Author: Christian Hopps Author: Christian Hopps
<mailto:chopps@chopps.org> <mailto:chopps@chopps.org>
Author: Lou Berger Author: Lou Berger
<mailto:lberger@labn.net> <mailto:lberger@labn.net>
Author: Dean Bogdanovic Author: Dean Bogdanovic
<ivandean@gmail.com>"; <mailto:ivandean@gmail.com>";
// 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-08-05 {
// 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> </sourcecode>
</figure>
</section> </section>
</section>
</section> <section numbered="true" toc="default">
<name>Other Classifications</name>
<section title="Other Classifications"> <t>It is worth noting that a different YANG module classification
<t>It is worth noting that a different YANG module classification document exists <xref target="RFC8199" format="default"/>. That document
document exists <xref target="RFC8199"/>. That document only classifies modules only classifies modules in a logical manner and does not define tagging
in a or any other mechanisms. It divides YANG modules into two categories
logical manner and does not define tagging or any other mechanisms. (service or element) and then into one of three origins: standard,
It divides YANG modules into two categories (service or element) and vendor, or user. It does provide a good way to discuss and identify
then into one of three origins: standard, vendor or user. It does modules in general. This document defines IETF tags to support the
provide a good way to discuss and identify modules in general. This classification style described in <xref target="RFC8199" format="default"/
document defines IETF tags to support <xref target="RFC8199"/> style >.</t>
classification.</t> </section>
<section anchor="sec-guidelines-to-model-writers" numbered="true" toc="defau
lt">
<name>Guidelines to Model Writers</name>
<t>This section updates <xref target="RFC8407" format="default"/>.</t>
<section numbered="true" toc="default">
<name>Define Standard Tags</name>
<t>A module <bcp14>MAY</bcp14> indicate, using module-tag extension
statements, a set of tags that are to be automatically associated with
it (i.e., not added through configuration).</t>
<!-- [rfced] Section 6.1: Note that we have marked the following as
<sourcecode> instead of of <artwork>. Please review and let us know if this
is incorrect. If <sourcecode> is correct, should type be set to yang?
</section> Orignal:
module example-module {
//...
import module-tags { prefix tags; }
<section title="Guidelines to Model Writers" anchor="sec-guidelines-to-model-wri tags:module-tag "ietf:some-new-tag";
ters"> tags:module-tag "ietf:some-other-tag";
<t>This section updates <xref target="RFC8407"/>.</t> // ...
}
<section title="Define Standard Tags"> -->
<t>A module MAY indicate, using module-tag extension statements, a set
of tags that are to be automatically associated with it (i.e., not
added through configuration).</t>
<figure><artwork><![CDATA[ <sourcecode name="" type=""><![CDATA[
module example-module { module example-module {
//... //...
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>The module writer can use existing standard tags or use new tags
<t>The module writer can use existing standard tags, or use new tags defined in the model definition, as appropriate. For IETF standardized
defined in the model definition, as appropriate. For IETF modules, new tags <bcp14>MUST</bcp14> be assigned in the IANA registry
standardized modules new tags MUST be assigned in the IANA registry defined below, see <xref target="sec-ietf-yang-module-tags-registry"
defined below, see <xref target="sec-ietf-yang-module-tags-registry"></xref>.</t format="default"/>.</t>
> </section>
</section>
</section> <section numbered="true" toc="default">
<name>IANA Considerations</name>
</section> <section anchor="sec-yang-module-tag-prefixes-registry" numbered="true"
toc="default">
<section title="IANA Considerations"> <name>YANG Module Tag Prefixes Registry</name>
<section title="YANG Module Tag Prefixes Registry" anchor="sec-yang-module-tag-p <t>IANA has created the "YANG Module Tag Prefixes" subregistry
refixes-registry"> in the "YANG Module Tags" registry.</t>
<t>IANA is asked to create a new registry "YANG Module Tag Prefixes" <t>This registry allocates tag prefixes. All YANG module tags
grouped under a new "Protocol" category named "YANG Module Tags".</t> <bcp14>SHOULD</bcp14> begin with one of the prefixes in this registry.</t
>
<t>This registry allocates tag prefixes. All YANG module tags SHOULD <t>Prefix entries in this registry should be short strings consisting
begin with one of the prefixes in this registry.</t> of lowercase ASCII alpha-numeric characters and a final ":" character.</t
>
<t>Prefix entries in this registry should be short strings consisting of <t>The allocation policy for this registry is Specification Required
lowercase ASCII alpha-numeric characters and a final ":" character.</t> <xref target="RFC8126" format="default"/>. The Reference and Assignee
values should be sufficient to identify and contact the organization
<t>The allocation policy for this registry is Specification Required that has been allocated the prefix.</t>
<xref target="RFC8126"/>. The Reference and Assignee values should be sufficient <t>The initial values for this registry are as follows.</t>
to
identify and contact the organization that has been allocated the
prefix.</t>
<t>The initial values for this registry are as follows.</t>
<texttable>
<ttcol>Prefix</ttcol><ttcol>Description</ttcol><ttcol>Reference</ttcol><ttcol>As
signee</ttcol>
<c>ietf:</c><c>IETF Tags allocated in the IANA IETF YANG Module Tags registry.</
c><c>[This document]</c><c>IETF</c>
<c>vendor:</c><c>Non-registered tags allocated by the module implementer.</c><c>
[This document]</c><c>IETF</c>
<c>user:</c><c>Non-registered tags allocated by and for the user.</c><c>[This do
cument]</c><c>IETF</c>
</texttable>
<t>Other standards organizations (SDOs) wishing to allocate their own
set of tags should allocate a prefix from this registry.</t>
</section>
<section title="IETF YANG Module Tags Registry" anchor="sec-ietf-yang-module-tag
s-registry">
<t>IANA is asked to create a new registry "IETF YANG Module Tags" grouped
under a new "Protocol" category "IETF YANG Module Tags". This registry
should be included below "YANG Module Tag Prefixes" when listed on
the same page.</t>
<t>This registry allocates tags that have the registered prefix "ietf:".
New values should be well considered and not achievable through a
combination of already existing IETF tags. IANA assigned tags must
conform to Net-Unicode as defined in <xref target="RFC5198"/> and they shall not
need
normalization.</t>
<t>The allocation policy for this registry is IETF Review <xref target="RFC8126"
/>.</t>
<t>The initial values for this registry are as follows.</t>
<texttable>
<ttcol>Tag</ttcol><ttcol>Description</ttcol><ttcol>Reference</ttcol>
<c>ietf:network-element-class</c><c><xref target="RFC8199"/> network element.</c
><c><xref target="RFC8199"/></c>
<c>ietf:network-service-class</c><c><xref target="RFC8199"/> network service.</c
><c><xref target="RFC8199"/></c>
<c>ietf:sdo-defined-class</c><c>Module is defined by a standards organization.</
c><c><xref target="RFC8199"/></c>
<c>ietf:vendor-defined-class</c><c>Module is defined by a vendor.</c><c><xref ta
rget="RFC8199"/></c>
<c>ietf:user-defined-class</c><c>Module is defined by the user.</c><c><xref targ
et="RFC8199"/></c>
<c>ietf:hardware</c><c>Relates to hardware (e.g., inventory).</c><c>[This docume
nt]</c>
<c>ietf:software</c><c>Relates to software (e.g., installed OS).</c><c>[This doc
ument]</c>
<c>ietf:protocol</c><c>Represents a protocol (often combined with another tag to
refine).</c><c>[This document]</c>
<c>ietf:qos</c><c>Relates to quality of service.</c><c>[This document]</c>
<c>ietf:network-service-app</c><c>Relates to a network service application (e.g.
, an NTP server, DNS server, DHCP server, etc).</c><c>[This document]</c>
<c>ietf:system-management</c><c>Relates to system management (e.g., a system man
agement protocol such as syslog, TACAC+, SNMP, netconf, ...).</c><c>[This docume
nt]</c>
<c>ietf:oam</c><c>Relates to Operations, Administration, and Maintenance (e.g.,
BFD).</c><c>[This document]</c>
<c>ietf:routing</c><c>Relates to routing.</c><c>[This document]</c>
<c>ietf:security</c><c>Related to security.</c><c>[This document]</c>
<c>ietf:signaling</c><c>Relates to control plane signaling.</c><c>[This document
]</c>
<c>ietf:link-management</c><c>Relates to link management.</c><c>[This document]<
/c>
</texttable>
</section>
<section title="Updates to the IETF XML Registry">
<t>This document registers a URI in the "IETF XML Registry" <xref target="RFC368
8"/>.
Following the format in <xref target="RFC3688"/>, the following registrations ha
ve been
made:</t>
<t><list style="hanging">
<t hangText="URI:"><vspace/>urn:ietf:params:xml:ns:yang:ietf-module-tags</t>
<t hangText="Registrant Contact:"><vspace/>The IESG.</t>
<t hangText="XML:"><vspace/>N/A; the requested URI is an XML namespace.</t>
<t hangText="URI:"><vspace/>urn:ietf:params:xml:ns:yang:ietf-module-tags-state</
t>
<t hangText="Registrant Contact:"><vspace/>The IESG.</t>
<t hangText="XML:"><vspace/>N/A; the requested URI is an XML namespace.</t>
</list></t>
</section>
<section title="Updates to the YANG Module Names Registry">
<t>This document registers two YANG modules in the "YANG Module Names"
registry <xref target="RFC6020"/>. Following the format in <xref target="RFC6020
"/>, the following
registration have been made:</t>
<t><list style="hanging">
<t hangText="name:"><vspace/>ietf-module-tags</t>
<t hangText="namespace:"><vspace/>urn:ietf:params:xml:ns:yang:ietf-module-tags</
t>
<t hangText="prefix:"><vspace/>tags</t>
<t hangText="reference:"><vspace/>RFC XXXX (RFC Ed.: replace XXX with actual RFC
number and remove this note.)</t>
<t hangText="name:"><vspace/>ietf-module-tags-state</t>
<t hangText="namespace:"><vspace/>urn:ietf:params:xml:ns:yang:ietf-module-tags-s
tate</t>
<t hangText="prefix:"><vspace/>tags</t>
<t hangText="reference:"><vspace/>RFC XXXX (RFC Ed.: replace XXX with actual RFC
number and remove this note.)</t>
</list></t>
</section>
</section>
<section title="Security Considerations">
<t>The YANG module defined in this memo is designed to be accessed via
the NETCONF protocol <xref target="RFC6241"/>. The lowest NETCONF layer is the
secure transport layer and the mandatory-to-implement secure
transport is SSH <xref target="RFC6242"/>.</t>
<t>This document adds the ability to associate tag meta-data with YANG
modules. This document does not define any actions based on these
associations, and none are yet defined, and therefore it does not
by itself introduce any new security considerations directly.</t>
<t>Users of the tag-meta data may define various actions to be taken
based on the tag meta-data. These actions and their definitions are
outside the scope of this document. Users will need to consider the
security implications of any actions they choose to define,
including the potential for a tag to get 'masked' by another user.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor='RFC2119' target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></
author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify
the requirements in the specification. These words are often capitalized. This
document defines these words as they should be interpreted in IETF documents.
This document specifies an Internet Best Current Practices for the Internet Comm
unity, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>
<reference anchor='RFC7950' target='https://www.rfc-editor.org/info/rfc7950'>
<front>
<title>The YANG 1.1 Data Modeling Language</title>
<author initials='M.' surname='Bjorklund' fullname='M. Bjorklund' role='editor'>
<organization /></author>
<date year='2016' month='August' />
<abstract><t>YANG is a data modeling language used to model configuration data,
state data, Remote Procedure Calls, and notifications for network management pro
tocols. This document describes the syntax and semantics of version 1.1 of the
YANG language. YANG version 1.1 is a maintenance release of the YANG language,
addressing ambiguities and defects in the original specification. There are a s
mall number of backward incompatibilities from YANG version 1. This document al
so specifies the YANG mappings to the Network Configuration Protocol (NETCONF).<
/t></abstract>
</front>
<seriesInfo name='RFC' value='7950'/>
<seriesInfo name='DOI' value='10.17487/RFC7950'/>
</reference>
<reference anchor='RFC8126' target='https://www.rfc-editor.org/info/rfc8126'>
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
<author initials='M.' surname='Cotton' fullname='M. Cotton'><organization /></au
thor>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></auth
or>
<author initials='T.' surname='Narten' fullname='T. Narten'><organization /></au
thor>
<date year='2017' month='June' />
<abstract><t>Many protocols make use of points of extensibility that use constan
ts to identify various protocol parameters. To ensure that the values in these
fields do not have conflicting uses and to promote interoperability, their alloc
ations are often coordinated by a central record keeper. For IETF protocols, th
at role is filled by the Internet Assigned Numbers Authority (IANA).</t><t>To ma
ke assignments in a given registry prudently, guidance describing the conditions
under which new values should be assigned, as well as when and how modification
s to existing values can be made, is needed. This document defines a framework
for the documentation of these guidelines by specification authors, in order to
assure that the provided guidance for the IANA Considerations is clear and addre
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>
</front>
<seriesInfo name='BCP' value='26'/>
<seriesInfo name='RFC' value='8126'/>
<seriesInfo name='DOI' value='10.17487/RFC8126'/>
</reference>
<reference anchor='RFC8174' target='https://www.rfc-editor.org/info/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></auth
or>
<date year='2017' month='May' />
<abstract><t>RFC 2119 specifies common key words that may be used in protocol s
pecifications. This document aims to reduce the ambiguity by clarifying that on
ly UPPERCASE usage of the key words have the defined special meanings.</t></abs
tract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>
<reference anchor='RFC8342' target='https://www.rfc-editor.org/info/rfc8342'>
<front>
<title>Network Management Datastore Architecture (NMDA)</title>
<author initials='M.' surname='Bjorklund' fullname='M. Bjorklund'><organization
/></author>
<author initials='J.' surname='Schoenwaelder' fullname='J. Schoenwaelder'><organ
ization /></author>
<author initials='P.' surname='Shafer' fullname='P. Shafer'><organization /></au
thor>
<author initials='K.' surname='Watsen' fullname='K. Watsen'><organization /></au
thor>
<author initials='R.' surname='Wilton' fullname='R. Wilton'><organization /></au
thor>
<date year='2018' month='March' />
<abstract><t>Datastores are a fundamental concept binding the data models writte
n in the YANG data modeling language to network management protocols such as the
Network Configuration Protocol (NETCONF) and RESTCONF. This document defines an
architectural framework for datastores based on the experience gained with the
initial simpler model, addressing requirements that were not well supported in t
he 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='RFC8199' target='https://www.rfc-editor.org/info/rfc8199'>
<front>
<title>YANG Module Classification</title>
<author initials='D.' surname='Bogdanovic' fullname='D. Bogdanovic'><organizatio
n /></author>
<author initials='B.' surname='Claise' fullname='B. Claise'><organization /></au
thor>
<author initials='C.' surname='Moberg' fullname='C. Moberg'><organization /></au
thor>
<date year='2017' month='July' />
<abstract><t>The YANG data modeling language is currently being considered for a
wide variety of applications throughout the networking industry at large. Many
standards development organizations (SDOs), open-source software projects, vend
ors, and users are using YANG to develop and publish YANG modules for a wide var
iety of applications. At the same time, there is currently no well-known termin
ology to categorize various types of YANG modules.</t><t>A consistent terminolog
y would help with the categorization of YANG modules, assist in the analysis of
the YANG data modeling efforts in the IETF and other organizations, and bring cl
arity to the YANG- related discussions between the different groups.</t><t>This
document describes a set of concepts and associated terms to support consistent
classification of YANG modules.</t></abstract>
</front>
<seriesInfo name='RFC' value='8199'/>
<seriesInfo name='DOI' value='10.17487/RFC8199'/>
</reference>
<reference anchor='RFC8407' target='https://www.rfc-editor.org/info/rfc8407'>
<front>
<title>Guidelines for Authors and Reviewers of Documents Containing YANG Data Mo
dels</title>
<author initials='A.' surname='Bierman' fullname='A. Bierman'><organization /></
author>
<date year='2018' month='October' />
<abstract><t>This memo provides guidelines for authors and reviewers of specific
ations containing YANG modules. Recommendations and procedures are defined, whi
ch are intended to increase interoperability and usability of Network Configurat
ion Protocol (NETCONF) and RESTCONF protocol implementations that utilize YANG m
odules. 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 title="Informative References">
<reference anchor='RFC3688' target='https://www.rfc-editor.org/info/rfc3688'>
<front>
<title>The IETF XML Registry</title>
<author initials='M.' surname='Mealling' fullname='M. Mealling'><organization />
</author>
<date year='2004' month='January' />
<abstract><t>This document describes an IANA maintained registry for IETF standa
rds which use Extensible Markup Language (XML) related items such as Namespaces,
Document Type Declarations (DTDs), Schemas, and Resource Description 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/rfc5198'> <table align="center">
<front> <thead>
<title>Unicode Format for Network Interchange</title> <tr>
<author initials='J.' surname='Klensin' fullname='J. Klensin'><organization /></ <th align="left">Prefix</th>
author> <th align="left">Description</th>
<author initials='M.' surname='Padlipsky' fullname='M. Padlipsky'><organization <th align="left">Reference</th>
/></author> <th align="left">Assignee</th>
<date year='2008' month='March' /> </tr>
<abstract><t>The Internet today is in need of a standardized form for the transm </thead>
ission of internationalized &quot;text&quot; information, paralleling the specif <tbody>
ications for the use of ASCII that date from the early days of the ARPANET. Thi <tr>
s document specifies that format, using UTF-8 with normalization and specific li <td align="left">ietf:</td>
ne-ending sequences. [STANDARDS-TRACK]</t></abstract> <td align="left">IETF Tags allocated in the IANA "IETF YANG
</front> Module Tags" registry.</td>
<seriesInfo name='RFC' value='5198'/> <td align="left">RFC 8819</td>
<seriesInfo name='DOI' value='10.17487/RFC5198'/> <td align="left">IETF</td>
</reference> </tr>
<tr>
<td align="left">vendor:</td>
<td align="left">Non-registered tags allocated by the module
implementer.</td>
<td align="left">RFC 8819</td>
<td align="left">IETF</td>
</tr>
<tr>
<td align="left">user:</td>
<td align="left">Non-registered tags allocated by and for the
user.</td>
<td align="left">RFC 8819</td>
<td align="left">IETF</td>
</tr>
</tbody>
</table>
<t>Other standards development organizations (SDOs) wishing to
allocate their own set of tags should allocate a prefix from this
registry.</t>
</section>
<section anchor="sec-ietf-yang-module-tags-registry" numbered="true"
toc="default">
<name>IETF YANG Module Tags Registry</name>
<t>IANA has created the "IETF YANG Module Tags" subregistry
within the "YANG Module Tags" registry . This
registry appears below the "YANG Module Tag Prefixes" registry.</t>
<t>This registry allocates tags that have the registered prefix
"ietf:". New values should be well considered and not achievable
through a combination of already existing IETF tags. IANA assigned
tags must conform to Net-Unicode as defined in <xref target="RFC5198"
format="default"/>, and they shall not need normalization.</t>
<t>The allocation policy for this registry is IETF Review <xref
target="RFC8126" format="default"/>.</t>
<t>The initial values for this registry are as follows.</t>
<reference anchor='RFC6020' target='https://www.rfc-editor.org/info/rfc6020'> <table align="center">
<front> <thead>
<title>YANG - A Data Modeling Language for the Network Configuration Protocol (N <tr>
ETCONF)</title> <th align="left">Tag</th>
<author initials='M.' surname='Bjorklund' fullname='M. Bjorklund' role='editor'> <th align="left">Description</th>
<organization /></author> <th align="left">Reference</th>
<date year='2010' month='October' /> </tr>
<abstract><t>YANG is a data modeling language used to model configuration and st </thead>
ate data manipulated by the Network Configuration Protocol (NETCONF), NETCONF re <tbody>
mote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</t></abstract <tr>
> <td align="left">ietf:network-element-class</td>
</front> <td align="left">Network element as defined in
<seriesInfo name='RFC' value='6020'/> <xref target="RFC8199" format="default"/>.</td>
<seriesInfo name='DOI' value='10.17487/RFC6020'/> <td align="left">
</reference> <xref target="RFC8199" format="default"/></td>
</tr>
<tr>
<td align="left">ietf:network-service-class</td>
<td align="left">Network service as defined in
<xref target="RFC8199" format="default"/>.</td>
<td align="left">
<xref target="RFC8199" format="default"/></td>
</tr>
<tr>
<td align="left">ietf:sdo-defined-class</td>
<td align="left">Module is defined by a standards organization.</t
d>
<td align="left">
<xref target="RFC8199" format="default"/></td>
</tr>
<tr>
<td align="left">ietf:vendor-defined-class</td>
<td align="left">Module is defined by a vendor.</td>
<td align="left">
<xref target="RFC8199" format="default"/></td>
</tr>
<tr>
<td align="left">ietf:user-defined-class</td>
<td align="left">Module is defined by the user.</td>
<td align="left">
<xref target="RFC8199" format="default"/></td>
</tr>
<tr>
<td align="left">ietf:hardware</td>
<td align="left">Relates to hardware (e.g., inventory).</td>
<td align="left">RFC 8819</td>
</tr>
<tr>
<td align="left">ietf:software</td>
<td align="left">Relates to software (e.g., installed OS).</td>
<td align="left">RFC 8819</td>
</tr>
<tr>
<td align="left">ietf:protocol</td>
<td align="left">Represents a protocol (often combined with
another tag to refine).</td>
<td align="left">RFC 8819</td>
</tr>
<tr>
<td align="left">ietf:qos</td>
<td align="left">Relates to quality of service.</td>
<td align="left">RFC 8819</td>
</tr>
<tr>
<td align="left">ietf:network-service-app</td>
<td align="left">Relates to a network service application (e.g.,
an NTP server, DNS server, DHCP server, etc.).</td>
<td align="left">RFC 8819</td>
</tr>
<tr>
<td align="left">ietf:system-management</td>
<!-- [IANA] ask IANA to update this entry to use "etc" instead of ellipses -
similar to entry for ietf:network-service-app.
-->
<td align="left">Relates to system management (e.g., a system
management protocol such as syslog, TACAC+, SNMP, NETCONF, etc.).</
td>
<td align="left">RFC 8819</td>
</tr>
<tr>
<td align="left">ietf:oam</td>
<td align="left">Relates to Operations, Administration, and
Maintenance (e.g., BFD).</td>
<td align="left">RFC 8819</td>
</tr>
<tr>
<td align="left">ietf:routing</td>
<td align="left">Relates to routing.</td>
<td align="left">RFC 8819</td>
</tr>
<tr>
<td align="left">ietf:security</td>
<td align="left">Related to security.</td>
<td align="left">RFC 8819</td>
</tr>
<!-- [IANA] ask IANA to add the hyphen for "control-plane" -->
<tr>
<td align="left">ietf:signaling</td>
<td align="left">Relates to control-plane signaling.</td>
<td align="left">RFC 8819</td>
</tr>
<tr>
<td align="left">ietf:link-management</td>
<td align="left">Relates to link management.</td>
<td align="left">RFC 8819</td>
</tr>
</tbody>
</table>
</section>
<section numbered="true" toc="default">
<name>Updates to the IETF XML Registry</name>
<t>This document registers a URI in the "IETF XML Registry" <xref
target="RFC3688" format="default"/>. Following the format in <xref
target="RFC3688" format="default"/>, the following registrations have
been made:</t>
<dl newline="false" spacing="compact">
<dt>URI:</dt>
<dd>urn:ietf:params:xml:ns:yang:ietf-module-tags</dd>
<dt>Registrant Contact:</dt>
<dd>The IESG.</dd>
<dt>XML:</dt>
<dd>N/A; the requested URI is an XML namespace.</dd>
</dl>
<dl newline="false" spacing="compact">
<dt>URI:</dt>
<dd>urn:ietf:params:xml:ns:yang:ietf-module-tags-state</dd>
<dt>Registrant Contact:</dt>
<dd>The IESG.</dd>
<dt>XML:</dt>
<dd>N/A; the requested URI is an XML namespace.</dd>
</dl>
</section>
<section numbered="true" toc="default">
<name>Updates to the YANG Module Names Registry</name>
<t>This document registers two YANG modules in the "YANG Module Names"
registry <xref target="RFC6020" format="default"/>. Following the
format in <xref target="RFC6020" format="default"/>, the following
registrations have been made:</t>
<dl newline="false" spacing="compact">
<dt>name:</dt>
<dd>ietf-module-tags</dd>
<dt>namespace:</dt>
<dd>urn:ietf:params:xml:ns:yang:ietf-module-tags</dd>
<dt>prefix:</dt>
<dd>tags</dd>
<dt>reference:</dt>
<dd>RFC 8819</dd>
</dl>
<!-- [rfced] For the ietf-module-tags-state registration, IANA shows the
prefix as "tags-s". In addition, also uses "prefix tags-s;". Should the
IANA entry be updated to match?
<reference anchor='RFC6241' target='https://www.rfc-editor.org/info/rfc6241'> Current:
<front> name: ietf-module-tags-state
<title>Network Configuration Protocol (NETCONF)</title> namespace: urn:ietf:params:xml:ns:yang:ietf-module-tags-state
<author initials='R.' surname='Enns' fullname='R. Enns' role='editor'><organizat prefix: tags
ion /></author> reference: RFC 8819
<author initials='M.' surname='Bjorklund' fullname='M. Bjorklund' role='editor'> -->
<organization /></author>
<author initials='J.' surname='Schoenwaelder' fullname='J. Schoenwaelder' role='
editor'><organization /></author>
<author initials='A.' surname='Bierman' fullname='A. Bierman' role='editor'><org
anization /></author>
<date year='2011' month='June' />
<abstract><t>The Network Configuration Protocol (NETCONF) defined in this docume
nt provides mechanisms to install, manipulate, and delete the configuration of n
etwork devices. It uses an Extensible Markup Language (XML)-based data encoding
for the configuration data as well as the protocol messages. The NETCONF proto
col operations are realized as remote procedure calls (RPCs). This document obs
oletes 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/rfc6242'> <dl newline="false" spacing="compact">
<front> <dt>name:</dt>
<title>Using the NETCONF Protocol over Secure Shell (SSH)</title> <dd>ietf-module-tags-state</dd>
<author initials='M.' surname='Wasserman' fullname='M. Wasserman'><organization <dt>namespace:</dt>
/></author> <dd>urn:ietf:params:xml:ns:yang:ietf-module-tags-state</dd>
<date year='2011' month='June' /> <dt>prefix:</dt>
<abstract><t>This document describes a method for invoking and running the Netwo <dd>tags</dd>
rk Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SS <dt>reference:</dt>
H subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK]</t></abstract <dd>RFC 8819</dd>
> </dl>
</front> </section>
<seriesInfo name='RFC' value='6242'/> </section>
<seriesInfo name='DOI' value='10.17487/RFC6242'/> <section numbered="true" toc="default">
</reference> <name>Security Considerations</name>
<t>The YANG module defined in this memo is designed to be accessed via
the NETCONF protocol <xref target="RFC6241" format="default"/>. The
lowest NETCONF layer is the secure transport layer and the
mandatory-to-implement secure transport is Secure Shell (SSH) <xref
target="RFC6242" format="default"/>.</t>
<t>This document adds the ability to associate tag metadata with YANG
modules. This document does not define any actions based on these
associations, and none are yet defined; therefore, it does not by
itself introduce any new security considerations directly.</t>
<t>Users of the tag metadata may define various actions to be taken
based on the tag metadata. These actions and their definitions are
outside the scope of this document. Users will need to consider the
security implications of any actions they choose to define, including
the potential for a tag to get 'masked' by another user.</t>
</section>
</middle>
<back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7950.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8126.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8342.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8199.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8407.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3688.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5198.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6020.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6241.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6242.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8340.xml"/>
</references>
</references>
<section numbered="true" toc="default">
<name>Examples</name>
<t>The following is a fictional NETCONF 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">
<name>Example NETCONF Query Output</name>
<reference anchor='RFC8340' target='https://www.rfc-editor.org/info/rfc8340'> <!--[rfced] The second line in the figure "Example NETCONF Query Output"
<front> exceeds the 72-character limit. Please review and let us know how this line
<title>YANG Tree Diagrams</title> should be altered.
<author initials='M.' surname='Bjorklund' fullname='M. Bjorklund'><organization
/></author>
<author initials='L.' surname='Berger' fullname='L. Berger' role='editor'><organ
ization /></author>
<date year='2018' month='March' />
<abstract><t>This document captures the current syntax used in YANG module tree
diagrams. The purpose of this document is to provide a single location for this
definition. This syntax may be updated from time to time based on the evolutio
n 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>
<section title="Examples"> 123456789012345678901234567890123456789012345678901234567890123456789012
<t>The following is a fictional NETCONF example result from a query of <t:module-tags xmlns:t="urn:ietf:params:xml:ns:yang:ietf-module-tags">
the module tags list. For the sake of brevity only a few module
results are imagined.</t>
<figure title="Example NETCONF Query Output" anchor="sec-example-netconf-query-o -->
utput"><artwork><![CDATA[ <sourcecode type="xml"><![CDATA[
<ns0:data xmlns:ns0="urn:ietf:params:xml:ns:netconf:base:1.0"> <ns0:data xmlns:ns0="urn:ietf:params:xml:ns:netconf:base:1.0">
<t:module-tags xmlns:t="urn:ietf:params:xml:ns:yang:ietf-module-tags"> <t:module-tags xmlns:t="urn:ietf:params:xml:ns:yang:ietf-module-tags">
<t:module> <t:module>
<t:name>ietf-bfd</t:name> <t:name>ietf-bfd</t:name>
<t:tag>ietf:network-element-class</t:tag> <t:tag>ietf:network-element-class</t:tag>
<t:tag>ietf:oam</t:tag> <t:tag>ietf:oam</t:tag>
<t:tag>ietf:protocol</t:tag> <t:tag>ietf:protocol</t:tag>
<t:tag>ietf:sdo-defined-class</t:tag> <t:tag>ietf:sdo-defined-class</t:tag>
</t:module> </t:module>
<t:module> <t:module>
skipping to change at line 700 skipping to change at line 725
</t:module> </t:module>
<t:module> <t:module>
<t:name>ietf-ssh-server</t:name> <t:name>ietf-ssh-server</t:name>
<t:tag>ietf:network-element-class</t:tag> <t:tag>ietf:network-element-class</t:tag>
<t:tag>ietf:protocol</t:tag> <t:tag>ietf:protocol</t:tag>
<t:tag>ietf:sdo-defined-class</t:tag> <t:tag>ietf:sdo-defined-class</t:tag>
<t:tag>ietf:system-management</t:tag> <t:tag>ietf:system-management</t:tag>
</t:module> </t:module>
</t:module-tags> </t:module-tags>
</ns0:data> </ns0:data>
]]></artwork></figure> ]]></sourcecode>
</section>
<section title="Acknowledgements">
<t>Special thanks to Robert Wilton for his help improving the
introduction and providing the example use cases, as well as
generating the non-NMDA module.</t>
</section>
<section title="Non-NMDA State Module.">
<t>As per <xref target="RFC8407"/> the following is a non-NMDA module to support
viewing the operational state for non-NMDA compliant servers.</t>
<figure title="Non-NMDA Module Tags State Module" anchor="sec-non-nmda-module-ta </figure>
gs-state-module"><artwork><![CDATA[ </section>
<CODE BEGINS> file "ietf-module-tags-state@2020-02-29.yang" <section numbered="true" toc="default">
<name>Non-NMDA State Module.</name>
<t>As per <xref target="RFC8407" format="default"/>, 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">
<name>Non-NMDA Module Tags State Module</name>
<sourcecode name="ietf-module-tags-state@2020-08-05.yang" type="yang"
markers="true"><![CDATA[
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: <https://datatracker.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org> WG List: <mailto:netmod@ietf.org>
Author: Christian Hopps Author: Christian Hopps
<mailto:chopps@chopps.org> <mailto:chopps@chopps.org>
Author: Lou Berger Author: Lou Berger
<mailto:lberger@labn.net> <mailto:lberger@labn.net>
Author: Dean Bogdanovic Author: Dean Bogdanovic
<ivandean@gmail.com>"; <mailto:ivandean@gmail.com>";
// 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-08-05 {
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="default">
<name>Acknowledgements</name>
<t>Special thanks to <contact fullname="Robert Wilton"/> for his help
improving the introduction and providing the example use cases, as well
as generating the non-NMDA module.</t>
</section>
</back> </back>
<!--[rfced] Throughout the text, the following terminology appears to be used
inconsistently. Please review and let us know if/how they may be made
consistent.
IETF Tag vs. IETF tag
-->
</rfc> </rfc>
 End of changes. 58 change blocks. 
777 lines changed or deleted 674 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/