< draft-ietf-netmod-module-tags-08.txt		draft-ietf-netmod-module-tags-09.txt >
	Network Working Group C. Hopps		Network Working Group C. Hopps
	Internet-Draft LabN Consulting, L.L.C.		Internet-Draft LabN Consulting, L.L.C.
	Updates: 8407 (if approved) L. Berger		Updates: 8407 (if approved) L. Berger
	Intended status: Standards Track LabN Consulting, LLC.		Intended status: Standards Track LabN Consulting, LLC.
	Expires: November 4, 2019 D. Bogdanovic		Expires: March 28, 2020 D. Bogdanovic
	Volta Networks		Volta Networks
	May 3, 2019		September 25, 2019
	YANG Module Tags		YANG Module Tags
	draft-ietf-netmod-module-tags-08		draft-ietf-netmod-module-tags-09
	Abstract		Abstract
	This document provides for the association of tags with YANG modules.		This document provides for the association of tags with YANG modules.
	The expectation is for such tags to be used to help classify and		The expectation is for such tags to be used to help classify and
	organize modules. A method for defining, reading and writing a		organize modules. A method for defining, reading and writing a
	modules tags is provided. Tags may be registered and assigned during		modules tags is provided. Tags may be registered and assigned during
	module definition; assigned by implementations; or dynamically		module definition; assigned by implementations; or dynamically
	defined and set by users. This document also provides guidance to		defined and set by users. This document also provides guidance to
	future model writers; as such, this document updates RFC8407.		future model writers; as such, this document updates RFC8407.
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on November 4, 2019.		This Internet-Draft will expire on March 28, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 35 ¶		skipping to change at page 2, line 35 ¶
	4.1. Tags Module Tree . . . . . . . . . . . . . . . . . . . . 6		4.1. Tags Module Tree . . . . . . . . . . . . . . . . . . . . 6
	4.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 6		4.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 6
	5. Other Classifications . . . . . . . . . . . . . . . . . . . . 9		5. Other Classifications . . . . . . . . . . . . . . . . . . . . 9
	6. Guidelines to Model Writers . . . . . . . . . . . . . . . . . 9		6. Guidelines to Model Writers . . . . . . . . . . . . . . . . . 9
	6.1. Define Standard Tags . . . . . . . . . . . . . . . . . . 9		6.1. Define Standard Tags . . . . . . . . . . . . . . . . . . 9
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	7.1. YANG Module Tag Prefixes Registry . . . . . . . . . . . . 9		7.1. YANG Module Tag Prefixes Registry . . . . . . . . . . . . 9
	7.2. IETF YANG Module Tags Registry . . . . . . . . . . . . . 10		7.2. IETF YANG Module Tags Registry . . . . . . . . . . . . . 10
	7.3. Updates to the IETF XML Registry . . . . . . . . . . . . 12		7.3. Updates to the IETF XML Registry . . . . . . . . . . . . 12
	7.4. Updates to the YANG Module Names Registry . . . . . . . . 12		7.4. Updates to the YANG Module Names Registry . . . . . . . . 12
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 12		8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
	9.1. Normative References . . . . . . . . . . . . . . . . . . 13		9.1. Normative References . . . . . . . . . . . . . . . . . . 13
	9.2. Informative References . . . . . . . . . . . . . . . . . 13		9.2. Informative References . . . . . . . . . . . . . . . . . 14
	Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 14		Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 14
	Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 15		Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15		Appendix C. Non-NMDA State Module. . . . . . . . . . . . . . . . 15
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
	1. Introduction		1. Introduction
	The use of tags for classification and organization is fairly		The use of tags for classification and organization is fairly
	ubiquitous not only within IETF protocols, but in the internet itself		ubiquitous not only within IETF protocols, but in the internet itself
	(e.g., "#hashtags"). One benefit of using tags for organization over		(e.g., "#hashtags"). One benefit of using tags for organization over
	a rigid structure is that it is more flexible and can more easily		a rigid structure is that it is more flexible and can more easily
	adapt over time as technologies evolve. Tags can be usefully		adapt over time as technologies evolve. Tags can be usefully
	registered, but they can also serve as a non-registered mechanism		registered, but they can also serve as a non-registered mechanism
	available for users to define themselves. This document provides a		available for users to define themselves. This document provides a
	skipping to change at page 6, line 19 ¶		skipping to change at page 6, line 19 ¶
	The tree associated with the "ietf-module-tags" module follows. The		The tree associated with the "ietf-module-tags" module follows. The
	meaning of the symbols can be found in [RFC8340].		meaning of the symbols can be found in [RFC8340].
	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
			Figure 1: YANG Module Tags Tree Diagram
	4.2. YANG Module		4.2. YANG Module
	<CODE BEGINS> file "ietf-module-tags@2019-05-03.yang"		<CODE BEGINS> file "ietf-module-tags@2019-09-25.yang"
	module ietf-module-tags {		module ietf-module-tags {
	yang-version 1.1;		yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-module-tags";		namespace "urn:ietf:params:xml:ns:yang:ietf-module-tags";
	prefix tags;		prefix tags;
	import ietf-yang-types {		import ietf-yang-types {
	prefix yang;		prefix yang;
	}		}
	organization		organization
	skipping to change at page 7, line 5 ¶		skipping to change at page 7, line 6 ¶
	Author: Dean Bogdanovic		Author: Dean Bogdanovic
	<ivandean@gmail.com>";		<ivandean@gmail.com>";
	// RFC Ed.: replace XXXX with actual RFC number and		// RFC Ed.: replace XXXX with actual RFC number and
	// remove this note.		// 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) 2018 IETF Trust and the persons identified as		Copyright (c) 2019 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
			(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
			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 [RFC2119] [RFC8174] 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.";
	This version of this YANG module is part of RFC XXXX
	(https://tools.ietf.org/html/rfcXXXX); see the RFC itself for
	full legal notices.";
	// RFC Ed.: update the date below with the date of RFC publication		// RFC Ed.: update the date below with the date of RFC publication
	// and RFC number and remove this note.		// and RFC number and remove this note.
	revision 2019-05-03 {		revision 2019-09-25 {
	description		description
	"Initial revision.";		"Initial revision.";
	reference "RFC XXXX: YANG Module Tags";		reference "RFC XXXX: YANG Module Tags";
	}		}
	typedef tag {		typedef tag {
	type string {		type string {
	length "1..max";		length "1..max";
	pattern '[\S ]+';		pattern '[\S ]+';
	}		}
	skipping to change at page 8, line 50 ¶		skipping to change at page 9, line 4 ¶
	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>		<CODE ENDS>
			Figure 2: Module Tags Module
	Figure 1: Module Tags Module
	5. Other Classifications		5. Other Classifications
	It is worth noting that a different YANG module classification		It is worth noting that a different YANG module classification
	document exists [RFC8199]. That document only classifies modules in		document exists [RFC8199]. That document only classifies modules in
	a logical manner and does not define tagging or any other mechanisms.		a logical manner and does not define tagging or any other mechanisms.
	It divides YANG modules into two categories (service or element) and		It divides YANG modules into two categories (service or element) and
	then into one of three origins: standard, vendor or user. It does		then into one of three origins: standard, vendor or user. It does
	provide a good way to discuss and identify modules in general. This		provide a good way to discuss and identify modules in general. This
	document defines IETF tags to support [RFC8199] style classification.		document defines IETF tags to support [RFC8199] style classification.
	skipping to change at page 12, line 10 ¶		skipping to change at page 12, line 10 ¶
	| ietf:signaling | Relates to control plane | [This |		| ietf:signaling | Relates to control plane | [This |
	| | signaling. | document] |		| | signaling. | document] |
	| | | |		| | | |
	| ietf:link-management | Relates to link | [This |		| ietf:link-management | Relates to link | [This |
	| | management. | document] |		| | management. | document] |
	+----------------------------+--------------------------+-----------+		+----------------------------+--------------------------+-----------+
	7.3. Updates to the IETF XML Registry		7.3. Updates to the IETF XML Registry
	This document registers a URI in the "IETF XML Registry" [RFC3688].		This document registers a URI in the "IETF XML Registry" [RFC3688].
	Following the format in [RFC3688], the following registration has		Following the format in [RFC3688], the following registrations have
	been made:		been made:
	URI:		URI:
	urn:ietf:params:xml:ns:yang:ietf-module-tags		urn:ietf:params:xml:ns:yang:ietf-module-tags
	Registrant Contact:		Registrant Contact:
	The IESG.		The IESG.
	XML:		XML:
	N/A; the requested URI is an XML namespace.		N/A; the requested URI is an XML namespace.
			URI:
			urn:ietf:params:xml:ns:yang:ietf-module-tags-state
			Registrant Contact:
			The IESG.
			XML:
			N/A; the requested URI is an XML namespace.
	7.4. Updates to the YANG Module Names Registry		7.4. Updates to the YANG Module Names Registry
	This document registers one YANG module in the "YANG Module Names"		This document registers two YANG modules in the "YANG Module Names"
	registry [RFC6020]. Following the format in [RFC6020], the following		registry [RFC6020]. Following the format in [RFC6020], the following
	registration has been made:		registration have been made:
	name:		name:
	ietf-module-tags		ietf-module-tags
	namespace:		namespace:
	urn:ietf:params:xml:ns:yang:ietf-module-tags		urn:ietf:params:xml:ns:yang:ietf-module-tags
	prefix:		prefix:
	tags		tags
	reference:		reference:
	RFC XXXX (RFC Ed.: replace XXX with actual RFC number and remove		RFC XXXX (RFC Ed.: replace XXX with actual RFC number and remove
	this note.)		this note.)
			name:
			ietf-module-tags-state
			namespace:
			urn:ietf:params:xml:ns:yang:ietf-module-tags-state
			prefix:
			tags
			reference:
			RFC XXXX (RFC Ed.: replace XXX with actual RFC number and remove
			this note.)
	8. Security Considerations		8. Security Considerations
	The YANG module defined in this memo is designed to be accessed via		The YANG module defined in this memo is designed to be accessed via
	the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the		the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the
	secure transport layer and the mandatory-to-implement secure		secure transport layer and the mandatory-to-implement secure
	transport is SSH [RFC6242].		transport is SSH [RFC6242].
	This document adds the ability to associate tag meta-data with YANG		This document adds the ability to associate tag meta-data with YANG
	modules. This document does not define any actions based on these		modules. This document does not define any actions based on these
	associations, and none are yet defined, and therefore it does not by		associations, and none are yet defined, and therefore it does not by
	skipping to change at page 15, line 31 ¶		skipping to change at page 15, line 31 ¶
	<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>
			Figure 3: Example NETCONF Query Output
	Appendix B. Acknowledgements		Appendix B. Acknowledgements
	Special thanks to Robert Wilton for his help improving the		Special thanks to Robert Wilton for his help improving the
	introduction and providing the example use cases.		introduction and providing the example use cases, as well as
			generating the non-NMDA module.
			Appendix C. Non-NMDA State Module.
			As per [RFC8407] the following is a non-NMDA module to support
			viewing the operational state for non-NMDA compliant servers.
			<CODE BEGINS> file "ietf-module-tags-state@2019-09-25.yang"
			module ietf-module-tags-state {
			yang-version 1.1;
			namespace "urn:ietf:params:xml:ns:yang:ietf-module-tags-state";
			prefix tags-s;
			import ietf-yang-types {
			prefix yang;
			}
			import ietf-module-tags {
			prefix tags;
			}
			organization
			"IETF NetMod Working Group (NetMod)";
			contact
			"WG Web: <https://tools.ietf.org/wg/netmod/>
			WG List: <mailto:netmod@ietf.org>
			Author: Christian Hopps
			<mailto:chopps@chopps.org>
			Author: Lou Berger
			<mailto:lberger@labn.net>
			Author: Dean Bogdanovic
			<ivandean@gmail.com>";
			// RFC Ed.: replace XXXX with actual RFC number and
			// remove this note.
			description
			"This module describes a mechanism associating tags with YANG
			modules. Tags may be IANA assigned or privately defined.
			This is a temporary non-NMDA module that is for use by
			implementations that don't yet support NMDA.
			Copyright (c) 2019 IETF Trust and the persons identified as
			authors of the code. All rights reserved.
			Redistribution and use in source and binary forms, with or
			without modification, is permitted pursuant to, and subject to
			the license terms contained in, the Simplified BSD License set
			forth in Section 4.c of the IETF Trust's Legal Provisions
			Relating to IETF Documents
			(https://trustee.ietf.org/license-info).
			This version of this YANG module is part of RFC XXXX
			(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
			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 2019-09-25 {
			description
			"Initial revision.";
			reference
			"RFC XXXX: YANG Module Tags";
			}
			container module-tags-state {
			config false;
			status deprecated;
			description
			"Contains the list of modules and their associated tags";
			list module {
			key "name";
			status deprecated;
			description
			"A list of modules and their associated tags";
			leaf name {
			type yang:yang-identifier;
			mandatory true;
			status deprecated;
			description
			"The YANG module name.";
			}
			leaf-list tag {
			type tags:tag;
			status deprecated;
			description
			"Tags associated with the module. See the IANA 'YANG Module
			Tag Prefixes' registry for reserved prefixes and the IANA
			'IETF YANG Module Tags' registry for IETF tags.
			The contents of this list is constructed using the
			following steps:
			1) System tags (i.e., tags of added by the system) are added.
			2) User configured tags (i.e., tags added by configuration)
			are added.
			3) Any tag that is equal to a masked-tag present in the
			corresponding ietf-module-tags:module-tags:module-tag leaf
			list for this module is removed.";
			}
			}
			}
			}
			<CODE ENDS>
			Figure 4: Non-NMDA Module Tags State Module
	Authors' Addresses		Authors' Addresses
	Christian Hopps		Christian Hopps
	LabN Consulting, L.L.C.		LabN Consulting, L.L.C.
	Email: chopps@chopps.org		Email: chopps@chopps.org
	Lou Berger		Lou Berger
	LabN Consulting, LLC.		LabN Consulting, LLC.
End of changes. 21 change blocks.
	23 lines changed or deleted		165 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/