< draft-ietf-core-sid-15.txt		draft-ietf-core-sid-16.txt >
	Internet Engineering Task Force M. Veillette, Ed.		Internet Engineering Task Force M.V. Veillette, Ed.
	Internet-Draft Trilliant Networks Inc.		Internet-Draft Trilliant Networks Inc.
	Intended status: Standards Track A. Pelov, Ed.		Intended status: Standards Track A.P. Pelov, Ed.
	Expires: July 21, 2021 I. Petrov, Ed.		Expires: 27 December 2021 Acklio
	Acklio		I. Petrov, Ed.
	January 17, 2021		Google Switzerland GmbH
			C. Bormann
			Universität Bremen TZI
			25 June 2021
	YANG Schema Item iDentifier (YANG SID)		YANG Schema Item iDentifier (YANG SID)
	draft-ietf-core-sid-15		draft-ietf-core-sid-16
	Abstract		Abstract
	YANG Schema Item iDentifiers (YANG SID) are globally unique 63-bit		YANG Schema Item iDentifiers (YANG SID) are globally unique 63-bit
	unsigned integers used to identify YANG items. This document defines		unsigned integers used to identify YANG items. This document defines
	the semantics, the registration, and assignment processes of YANG		the semantics, the registration, and assignment processes of YANG
	SIDs. To enable the implementation of these processes, this document		SIDs. To enable the implementation of these processes, this document
	also defines a file format used to persist and publish assigned YANG		also defines a file format used to persist and publish assigned YANG
	SIDs.		SIDs.
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 40 ¶
	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 July 21, 2021.		This Internet-Draft will expire on 27 December 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 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/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		Please review these documents carefully, as they describe your rights
	to this document. Code Components extracted from this document must		and restrictions with respect to this document. Code Components
	include Simplified BSD License text as described in Section 4.e of		extracted from this document must include Simplified BSD License text
	the Trust Legal Provisions and are provided without warranty as		as described in Section 4.e of the Trust Legal Provisions and are
	described in the Simplified BSD License.		provided without warranty as described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology and Notation . . . . . . . . . . . . . . . . . . 4		2. Terminology and Notation . . . . . . . . . . . . . . . . . . 4
	3. ".sid" file lifecycle . . . . . . . . . . . . . . . . . . . . 5		3. ".sid" file lifecycle . . . . . . . . . . . . . . . . . . . . 5
	4. ".sid" file format . . . . . . . . . . . . . . . . . . . . . 6		4. ".sid" file format . . . . . . . . . . . . . . . . . . . . . 6
	5. Content-Types . . . . . . . . . . . . . . . . . . . . . . . . 12		5. Content-Types . . . . . . . . . . . . . . . . . . . . . . . . 12
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 12		6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	7.1. YANG Namespace Registration . . . . . . . . . . . . . . . 13		7.1. YANG Namespace Registration . . . . . . . . . . . . . . . 13
	7.2. Register ".sid" File Format Module . . . . . . . . . . . 13		7.2. Register ".sid" File Format Module . . . . . . . . . . . 13
	7.3. CoAP Content-Formats Registry . . . . . . . . . . . . . . 13		7.3. CoAP Content-Formats Registry . . . . . . . . . . . . . . 14
	7.4. Create new IANA Registry: "YANG SID Mega-Range" registry 14		7.4. Create new IANA Registry: "YANG SID Mega-Range"
			registry . . . . . . . . . . . . . . . . . . . . . . . . 14
	7.4.1. Structure . . . . . . . . . . . . . . . . . . . . . . 14		7.4.1. Structure . . . . . . . . . . . . . . . . . . . . . . 14
	7.4.2. Allocation policy . . . . . . . . . . . . . . . . . . 14		7.4.2. Allocation policy . . . . . . . . . . . . . . . . . . 14
	7.4.2.1. First allocation . . . . . . . . . . . . . . . . 15		7.4.2.1. First allocation . . . . . . . . . . . . . . . . 15
	7.4.2.2. Consecutive allocations . . . . . . . . . . . . . 15		7.4.2.2. Consecutive allocations . . . . . . . . . . . . . 15
	7.4.3. Initial contents of the Registry . . . . . . . . . . 15		7.4.3. Initial contents of the Registry . . . . . . . . . . 15
	7.5. Create a new IANA Registry: IETF YANG SID Range Registry		7.5. Create a new IANA Registry: IETF YANG SID Range Registry
	(managed by IANA) . . . . . . . . . . . . . . . . . . . . 15		(managed by IANA) . . . . . . . . . . . . . . . . . . . . 16
	7.5.1. Structure . . . . . . . . . . . . . . . . . . . . . . 15		7.5.1. Structure . . . . . . . . . . . . . . . . . . . . . . 16
	7.5.2. Allocation policy . . . . . . . . . . . . . . . . . . 16		7.5.2. Allocation policy . . . . . . . . . . . . . . . . . . 16
	7.5.3. Initial contents of the registry . . . . . . . . . . 17		7.5.3. Initial contents of the registry . . . . . . . . . . 18
	7.6. Create new IANA Registry: "IETF YANG SID Registry" . . . 18		7.6. Create new IANA Registry: "IETF YANG SID Registry" . . . 19
	7.6.1. Structure . . . . . . . . . . . . . . . . . . . . . . 18		7.6.1. Structure . . . . . . . . . . . . . . . . . . . . . . 19
	7.6.2. Allocation policy . . . . . . . . . . . . . . . . . . 18		7.6.2. Allocation policy . . . . . . . . . . . . . . . . . . 19
	7.6.3. Recursive Allocation of YANG SID Range at Document		7.6.3. Recursive Allocation of YANG SID Range at Document
	Adoption . . . . . . . . . . . . . . . . . . . . . . 19		Adoption . . . . . . . . . . . . . . . . . . . . . . 20
	7.6.4. Initial contents of the registry . . . . . . . . . . 20		7.6.4. Initial contents of the registry . . . . . . . . . . 21
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21		8.1. Normative References . . . . . . . . . . . . . . . . . . 21
	9.1. Normative References . . . . . . . . . . . . . . . . . . 21		8.2. Informative References . . . . . . . . . . . . . . . . . 22
	9.2. Informative References . . . . . . . . . . . . . . . . . 22		Appendix A. ".sid" file example . . . . . . . . . . . . . . . . 24
	Appendix A. ".sid" file example . . . . . . . . . . . . . . . . 23		Appendix B. SID auto generation . . . . . . . . . . . . . . . . 33
	Appendix B. SID auto generation . . . . . . . . . . . . . . . . 32		Appendix C. ".sid" file lifecycle . . . . . . . . . . . . . . . 34
	Appendix C. ".sid" file lifecycle . . . . . . . . . . . . . . . 33		C.1. ".sid" File Creation . . . . . . . . . . . . . . . . . . 34
	C.1. ".sid" File Creation . . . . . . . . . . . . . . . . . . 33		C.2. ".sid" File Update . . . . . . . . . . . . . . . . . . . 36
	C.2. ".sid" File Update . . . . . . . . . . . . . . . . . . . 35		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 37
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
	1. Introduction		1. Introduction
	Some of the items defined in YANG [RFC7950] require the use of a		Some of the items defined in YANG [RFC7950] require the use of a
	unique identifier. In both NETCONF [RFC6241] and RESTCONF [RFC8040],		unique identifier. In both Network Configuration Protocol(NETCONF)
	these identifiers are implemented using names. To allow the		[RFC6241] and RESTCONF [RFC8040], these identifiers are implemented
	implementation of data models defined in YANG in constrained devices		using names. To allow the implementation of data models defined in
	and constrained networks, a more compact method to identify YANG		YANG in constrained devices and constrained networks, a more compact
	items is required. This compact identifier, called YANG SID or		method to identify YANG items is required. This compact identifier,
	simply SID in this document and when the context is clear, is encoded		called YANG SID or simply SID in this document and when the context
	using a 63-bit unsigned integer. The limitation to 63-bit unsigned		is clear, is encoded using a 63-bit unsigned integer. The limitation
	integers allows SIDs to be manipulated more easily on platforms that		to 63-bit unsigned integers allows SIDs to be manipulated more easily
	might otherwise lack native 64-bit unsigned arithmetic. The loss of		on platforms that might otherwise lack native 64-bit unsigned
	a single bit of range is not significant given the size of the		arithmetic. The loss of a single bit of range is not significant
	remaining space.		given the size of the remaining space.
	The following items are identified using SIDs:		The following items are identified using SIDs:
	o identities		* identities
	o data nodes (Note: including those nodes defined by the 'yang-data'		* data nodes (Note: including those nodes defined by the 'yang-data'
	extension.)		extension.)
	o RPCs and associated input(s) and output(s)		* remote procedure calls (RPCs) and associated input(s) and
			output(s)
	o actions and associated input(s) and output(s)		* actions and associated input(s) and output(s)
	o notifications and associated information		* notifications and associated information
	o YANG modules, submodules and features		* YANG modules, submodules and features
	It is possible that some protocols use only a subset of the assigned		It is possible that some protocols use only a subset of the assigned
	SIDs, for example, for protocols equivalent to NETCONF [RFC6241] like		SIDs, for example, for protocols equivalent to NETCONF [RFC6241] like
	[I-D.ietf-core-comi] the transportation of YANG modules SIDs might be		[I-D.ietf-core-comi] the transportation of YANG module SIDs might be
	unnecessary. Others protocols might need to be able to transport		unnecessary. Other protocols might need to be able to transport this
	this information, for example protocols related to discovery such as		information, for example protocols related to discovery such as
	Constrained YANG Module Library [I-D.ietf-core-yang-library].		Constrained YANG Module Library [I-D.ietf-core-yang-library].
	SIDs are globally unique integers, a registration system is used in		SIDs are globally unique integers. A registration system is used in
	order to guarantee their uniqueness. SIDs are registered in blocks		order to guarantee their uniqueness. SIDs are registered in blocks
	called "SID ranges".		called "SID ranges".
	Assignment of SIDs to YANG items can be automated. For more details		Assignment of SIDs to YANG items can be automated. For more details
	how this could be achieved, please consult Appendix B.		how this can be achieved, please consult Appendix B.
	SIDs are assigned permanently, items introduced by a new revision of		SIDs are assigned permanently, items introduced by a new revision of
	a YANG module are added to the list of SIDs already assigned. If the		a YANG module are added to the list of SIDs already assigned. If the
	meaning of an item changes, for example as a result from a non-		meaning of an item changes, for example as a result from a non-
	backward compatible update of the YANG module, a new SID should be		backward compatible update of the YANG module, a new SID SHOULD be
	assigned to it.		assigned to it. A new SID MUST always be assigned if the new meaning
			of the item is going to be referenced using a SID.
	Section 3 provides more details about the registration process of		Section 3 provides more details about the registration process of
	YANG modules and associated SIDs. To enable the implementation of		YANG modules and associated SIDs. To enable the implementation of
	this registry, Section 4 defines a standard file format used to store		this registry, Section 4 defines a standard file format used to store
	and publish SIDs.		and publish SIDs.
	2. Terminology and Notation		2. Terminology and Notation
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	The following terms are defined in [RFC7950]:		The following terms are defined in [RFC7950]:
	o action		* action
	o feature		* feature
	o module		* module
	o notification		* notification
	o RPC		* RPC
	o schema node		* schema node
	o schema tree		* schema tree
	o submodule		* submodule
	The following term is defined in [RFC8040]:		The following term is defined in [RFC8040]:
	o yang-data extension		* yang-data extension
	This specification also makes use of the following terminology:		This specification also makes use of the following terminology:
	o item: A schema node, an identity, a module, a submodule or a		* item: A schema node, an identity, a module, a submodule or a
	feature defined using the YANG modeling language.		feature defined using the YANG modeling language.
	o schema-node path: A schema-node path is a string that identifies a		* schema-node path: A schema-node path is a string that identifies a
	schema node within the schema tree. A path consists of the list		schema node within the schema tree. A path consists of the list
	of consecutive schema node identifier(s) separated by slashes		of consecutive schema node identifier(s) separated by slashes
	("/"). Schema node identifier(s) are always listed from the top-		("/"). Schema node identifier(s) are always listed from the top-
	level schema node up to the targeted schema node and could contain		level schema node up to the targeted schema node and could contain
	namespace information. (e.g. "/ietf-system:system-state/clock/		namespace information. (e.g. "/ietf-system:system-state/clock/
	current-datetime")		current-datetime")
	o Namespace-qualified form - a schema node identifier is prefixed		* Namespace-qualified form - a schema node identifier is prefixed
	with the name of the module in which the schema node is defined,		with the name of the module in which the schema node is defined,
	separated from the schema node identifier by the colon character		separated from the schema node identifier by the colon character
	(":").		(":").
	o YANG Schema Item iDentifier (YANG SID or simply SID): Unsigned		* YANG Schema Item iDentifier (YANG SID or simply SID): Unsigned
	integer used to identify different YANG items.		integer used to identify different YANG items.
	3. ".sid" file lifecycle		3. ".sid" file lifecycle
	YANG is a language designed to model data accessed using one of the		YANG is a language designed to model data accessed using one of the
	compatible protocols (e.g. NETCONF [RFC6241], RESTCONF [RFC8040] and		compatible protocols (e.g. NETCONF [RFC6241], RESTCONF [RFC8040] and
	CORECONF [I-D.ietf-core-comi]). A YANG module defines hierarchies of		CORECONF [I-D.ietf-core-comi]). A YANG module defines hierarchies of
	data, including configuration, state data, RPCs, actions and		data, including configuration, state data, RPCs, actions and
	notifications.		notifications.
	skipping to change at page 5, line 43 ¶		skipping to change at page 5, line 44 ¶
	Registration of the ".sid" file associated to a YANG module is		Registration of the ".sid" file associated to a YANG module is
	optional but recommended to promote interoperability between devices		optional but recommended to promote interoperability between devices
	and to avoid duplicate allocation of SIDs to a single YANG module.		and to avoid duplicate allocation of SIDs to a single YANG module.
	Different registries might have different requirements for the		Different registries might have different requirements for the
	registration and publication of the ".sid" files. For a diagram of		registration and publication of the ".sid" files. For a diagram of
	one of the possibilities, please refer to the activity diagram on		one of the possibilities, please refer to the activity diagram on
	Figure 1 in Appendix C.		Figure 1 in Appendix C.
	Each time a YANG module or one of its imported module(s) or included		Each time a YANG module or one of its imported module(s) or included
	sub-module(s) is updated, a new ".sid" file MAY need to be created.		sub-module(s) is updated, a new ".sid" file MAY be created if the new
	All the SIDs present in the previous version of the ".sid" file MUST		or updated items will need SIDs. All the SIDs present in the
	be present in the new version as well. The creation of this new		previous version of the ".sid" file MUST be present in the new
	version of the ".sid" file SHOULD be performed using an automated		version as well. The creation of this new version of the ".sid" file
	tool.		SHOULD be performed using an automated tool.
	If a new revision requires more SIDs than initially allocated, a new		If a new revision requires more SIDs than initially allocated, a new
	SID range MUST be added to the 'assignment-ranges' as defined in		SID range MUST be added to the 'assignment-range' as defined in
	Section 4. These extra SIDs are used for subsequent assignments.		Section 4. These extra SIDs are used for subsequent assignments.
	For an example of this update process, see activity diagram Figure 2		For an example of this update process, see activity diagram Figure 2
	in Appendix C.		in Appendix C.
	4. ".sid" file format		4. ".sid" file format
	".sid" files are used to persist and publish SIDs assigned to the		".sid" files are used to persist and publish SIDs assigned to the
	different YANG items of a specific YANG module. It has the following		different YANG items of a specific YANG module. It has the following
	structure.		structure.
	module: ietf-sid-file		module: ietf-sid-file
	+--rw module-name? yang:yang-identifier		+-- sid-file
	+--rw module-revision? revision-identifier		+-- module-name? yang:yang-identifier
	+--rw sid-file-version? sid-file-version-identifier		+-- module-revision? revision-identifier
	+--rw description? string		+-- sid-file-version? sid-file-version-identifier
	+--rw dependency-revision* [module-name]		+-- description? string
	| +--rw module-name yang:yang-identifier		+-- dependency-revision* [module-name]
	| +--rw module-revision revision-identifier		| +-- module-name yang:yang-identifier
	+--rw assigment-ranges* [entry-point]		| +-- module-revision revision-identifier
	| +--rw entry-point sid		+-- assignment-range* [entry-point]
	| +--rw size uint64		| +-- entry-point sid
	+--rw items* [namespace identifier]		| +-- size uint64
	+--rw namespace enumeration		+-- item* [namespace identifier]
	+--rw identifier union		+-- namespace enumeration
	+--rw sid sid		+-- identifier union
			+-- sid sid
	The following YANG module defined the structure of this file,		The following YANG module defined the structure of this file,
	encoding is performed using the rules defined in [RFC7951]. It		encoding is performed using the rules defined in [RFC7951]. It
	references ietf-yang-types defined in [RFC6991] and ietf-restconf		references ietf-yang-types defined in [RFC6991] and ietf-restconf
	defined in [RFC8040].		defined in [RFC8040].
	RFC Ed.: please update the date of the module and Copyright if needed		RFC Ed.: please update the date of the module and Copyright if needed
	and remove this note.		and remove this note.
	<CODE BEGINS> file "ietf-sid-file@2020-02-05.yang"		<CODE BEGINS> file "ietf-sid-file@2020-02-05.yang"
	module ietf-sid-file {		module ietf-sid-file {
	yang-version 1.1;		yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-sid-file";		namespace "urn:ietf:params:xml:ns:yang:ietf-sid-file";
	prefix sid;		prefix sid;
	import ietf-yang-types {		import ietf-yang-types {
	prefix yang;		prefix yang;
	reference "RFC 6991: Common YANG Data Types.";		reference "RFC 6991: Common YANG Data Types.";
	}		}
	import ietf-restconf {		import ietf-restconf {
	prefix rc;		prefix rc;
	reference "RFC 8040: RESTCONF Protocol.";		reference "RFC 8040: RESTCONF Protocol.";
	}		}
	organization
	"IETF Core Working Group";
	contact		organization
	"WG Web: <http://datatracker.ietf.org/wg/core/>		"IETF Core Working Group";
	WG List: <mailto:core@ietf.org>		contact
			"WG Web: <http://datatracker.ietf.org/wg/core/>
	Editor: Michel Veillette		WG List: <mailto:core@ietf.org>
	<mailto:michel.veillette@trilliant.com>
	Editor: Andy Bierman		Editor: Michel Veillette
	<mailto:andy@yumaworks.com>		<mailto:michel.veillette@trilliant.com>
	Editor: Alexander Pelov		Editor: Andy Bierman
	<mailto:a@ackl.io>		<mailto:andy@yumaworks.com>
	Editor: Ivaylo Petrov		Editor: Alexander Pelov
	<mailto:ivaylo@ackl.io>";		<mailto:a@ackl.io>
	description		Editor: Ivaylo Petrov
	"Copyright (c) 2021 IETF Trust and the persons identified as		<mailto:ivaylopetrov@google.com>";
	authors of the code. All rights reserved.
	Redistribution and use in source and binary forms, with or		description
	without modification, is permitted pursuant to, and subject to		"Copyright (c) 2021 IETF Trust and the persons identified as
	the license terms contained in, the Simplified BSD License set		authors of the code. All rights reserved.
	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		Redistribution and use in source and binary forms, with or
	(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself		without modification, is permitted pursuant to, and subject to
	for full legal notices.		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).
	The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL		This version of this YANG module is part of RFC XXXX
	NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',		(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
	'MAY', and 'OPTIONAL' in this document are to be interpreted as		for full legal notices.
	described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
	they appear in all capitals, as shown here.
	This module defines the structure of the .sid files.		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.
	Each .sid file contains the mapping between the different		This module defines the structure of the .sid files.
	string identifiers defined by a YANG module and a
	corresponding numeric value called YANG SID.";
	revision 2020-02-05 {		Each .sid file contains the mapping between the different
	description		string identifiers defined by a YANG module and a
	"Initial revision.";		corresponding numeric value called YANG SID.";
	reference
	"[I-D.ietf-core-sid] YANG Schema Item iDentifier (YANG SID)";
	}
	typedef revision-identifier {		revision 2020-02-05 {
	type string {		description
	pattern '\d{4}-\d{2}-\d{2}';		"Initial revision.";
	}		reference
	description		"[I-D.ietf-core-sid] YANG Schema Item iDentifier (YANG SID)";
	"Represents a date in YYYY-MM-DD format.";		}
	}
	typedef sid-file-version-identifier {		typedef revision-identifier {
	type uint64;		type string {
	description		pattern '\d{4}-\d{2}-\d{2}';
	"Represents the version of a .sid file.";		}
	}		description
			"Represents a date in YYYY-MM-DD format.";
			}
	typedef sid {		typedef sid-file-version-identifier {
	type uint64 {		type uint64;
	range "0..9223372036854775807";		description
	}		"Represents the version of a .sid file.";
	description		}
	"YANG Schema Item iDentifier";
	reference
	"[I-D.ietf-core-sid] YANG Schema Item iDentifier (YANG SID)";
	}
	typedef schema-node-path {		typedef sid {
	type string {		type uint64 {
	pattern		range "0..9223372036854775807";
	'/[a-zA-Z_][a-zA-Z0-9\-_.]*:[a-zA-Z_][a-zA-Z0-9\-_.]*' +		}
	'(/[a-zA-Z_][a-zA-Z0-9\-_.]*(:[a-zA-Z_][a-zA-Z0-9\-_.]*)?)*';		description
	}		"YANG Schema Item iDentifier";
	description		reference
	"A schema-node path is an absolute YANG schema node identifier as		"[I-D.ietf-core-sid] YANG Schema Item iDentifier (YANG SID)";
	defined by the YANG ABNF rule absolute-schema-nodeid, except		}
	that module names are used instead of prefixes.
	This string additionally follows the following rules:		typedef schema-node-path {
			type string {
			pattern
			'/[a-zA-Z_][a-zA-Z0-9\-_.]*:[a-zA-Z_][a-zA-Z0-9\-_.]*' +
			'(/[a-zA-Z_][a-zA-Z0-9\-_.]*(:[a-zA-Z_][a-zA-Z0-9\-_.]*)?)*';
			}
			description
			"A schema-node path is an absolute YANG schema node identifier
			as defined by the YANG ABNF rule absolute-schema-nodeid,
			except that module names are used instead of prefixes.
	o The leftmost (top-level) data node name is always in the		This string additionally follows the following rules:
	namespace-qualified form.
	o Any subsequent schema node name is in the namespace-qualified form
	if the node is defined in a module other than its parent node, and
	the simple form is used otherwise. No predicates are allowed.";
	reference		o The leftmost (top-level) data node name is always in the
	"RFC 7950, The YANG 1.1 Data Modeling Language;		namespace-qualified form.
	Section 6.5: Schema Node Identifier;";		o Any subsequent schema node name is in the
	}		namespace-qualified form if the node is defined in a module
			other than its parent node, and the simple form is used
			otherwise. No predicates are allowed.";
			reference
			"RFC 7950, The YANG 1.1 Data Modeling Language;
			Section 6.5: Schema Node Identifier;";
			}
	rc:yang-data sid-file {		rc:yang-data sid-file {
	uses sid-file;		uses sid-file;
	}		}
	grouping sid-file {		grouping sid-file {
	description "A grouping that contains a YANG container representing the		description "A grouping that contains a YANG container
	file structure of a .sid files.";		representing the file structure of a .sid files.";
	container sid-file {		container sid-file {
	description		description
	"A Wrapper container that together with the rc:yang-data extension		"A Wrapper container that together with the rc:yang-data
	marks the YANG data structures inside as not being intended to be		extension marks the YANG data structures inside as not being
	implemented as part of a configuration datastore or as an operational		intended to be implemented as part of a configuration
	state within the server.";		datastore or as an operational state within the server.";
	leaf module-name {		leaf module-name {
	type yang:yang-identifier;		type yang:yang-identifier;
	description		description
	"Name of the YANG module associated with this .sid file.";		"Name of the YANG module associated with this .sid file.";
	}		}
	leaf module-revision {		leaf module-revision {
	type revision-identifier;		type revision-identifier;
	description		description
	"Revision of the YANG module associated with this .sid file.		"Revision of the YANG module associated with this .sid
	This leaf is not present if no revision statement is		file.
	defined in the YANG module.";		This leaf is not present if no revision statement is
	}		defined in the YANG module.";
			}
	leaf sid-file-version {		leaf sid-file-version {
	type sid-file-version-identifier;		type sid-file-version-identifier;
	description		default 0;
	"Optional leaf that specifies the version number of the .sid file.		description
	.sid files and the version sequence are specific to a given YANG		"Optional leaf that specifies the version number of the
	module revision. This number starts at zero when there is a new YANG		.sid file. .sid files and the version sequence are
	module revision and increases monotonically. This number can		specific to a given YANG module revision. This number
	distinguish updates to the .sid file which are the result of new		starts at zero when there is a new YANG module revision and
	processing, or the result of reported errata.";		increases monotonically. This number can distinguish
	}		updates to the .sid file which are the result of new
			processing, or the result of reported errata.";
			}
	leaf description {		leaf description {
	type string;		type string;
	description		description
	"Free-form meta information about the generated file. It might		"Free-form meta information about the generated file. It
	include .sid file generation tool and time among other things.";		might include .sid file generation tool and time among
	}		other things.";
			}
	list dependency-revision {		list dependency-revision {
	key "module-name";		key "module-name";
	description		description
	"Information about the used revision during the .sid file generation		"Information about the used revision during the .sid file
	of each YANG module that the module in 'module-name' imported.";		generation of each YANG module that the module in
			'module-name' imported.";
	leaf module-name {		leaf module-name {
	type yang:yang-identifier;		type yang:yang-identifier;
	mandatory true;		description
	description		"Name of the YANG module, dependency of 'module-name',
	"Name of the YANG module, dependency of 'module-name', for which		for which revision information is provided.";
	revision information is provided.";		}
	}		leaf module-revision {
	leaf module-revision {		type revision-identifier;
	type revision-identifier;		mandatory true;
	mandatory true;		description
	description		"Revision of the YANG module, dependency of
	"Revision of the YANG module, dependency of 'module-name', for which		'module-name', for which revision information is
	revision information is provided.";		provided.";
	}		}
	}		}
	list assigment-ranges {		list assignment-range {
	key "entry-point";		key "entry-point";
	description		description
	"YANG SID range(s) allocated to the YANG module identified by		"YANG SID range(s) allocated to the YANG module identified
	'module-name' and 'module-revision'.		by 'module-name' and 'module-revision'.
	- The YANG SID range first available value is entry-point and the the		- The YANG SID range first available value is entry-point
	last available value in the range is (entry-point + size - 1).		and the the last available value in the range is
	- The YANG SID ranges specified by all assignment-rages MUST NOT		(entry-point + size - 1).
	overlap.";		- The YANG SID ranges specified by all assignment-rages
			MUST NOT overlap.";
	leaf entry-point {		leaf entry-point {
	type sid;		type sid;
	mandatory true;		description
	description		"Lowest YANG SID available for assignment.";
	"Lowest YANG SID available for assignment.";		}
	}
	leaf size {		leaf size {
	type uint64;		type uint64;
	mandatory true;		mandatory true;
	description		description
	"Number of YANG SIDs available for assignment.";		"Number of YANG SIDs available for assignment.";
	}		}
	}		}
	list items {		list item {
	key "namespace identifier";		key "namespace identifier";
	description		unique "sid";
	"Each entry within this list defined the mapping between
	a YANG item string identifier and a YANG SID. This list MUST
	include a mapping entry for each YANG item defined by
	the YANG module identified by 'module-name' and
	'module-revision'.";
	leaf namespace {		description
	type enumeration {		"Each entry within this list defined the mapping between
	enum module {		a YANG item string identifier and a YANG SID. This list
	value 0;		MUST include a mapping entry for each YANG item defined by
	description		the YANG module identified by 'module-name' and
	"All module and submodule names share the same		'module-revision'.";
	global module identifier namespace.";
	}
	enum identity {
	value 1;
	description
	"All identity names defined in a module and its
	submodules share the same identity identifier
	namespace.";
	}
	enum feature {
	value 2;
	description
	"All feature names defined in a module and its
	submodules share the same feature identifier
	namespace.";
	}
	enum data {
	value 3;
	description
	"The namespace for all data nodes, as defined in YANG.";
	}
	}
	description
	"Namespace of the YANG item for this mapping entry.";
	}
	leaf identifier {		leaf namespace {
	type union {		type enumeration {
	type yang:yang-identifier;		enum module {
	type schema-node-path;		value 0;
	}		description
	description		"All module and submodule names share the same
	"String identifier of the YANG item for this mapping entry.		global module identifier namespace.";
			}
			enum identity {
			value 1;
			description
			"All identity names defined in a module and its
			submodules share the same identity identifier
			namespace.";
			}
			enum feature {
			value 2;
			description
			"All feature names defined in a module and its
			submodules share the same feature identifier
			namespace.";
			}
			enum data {
			value 3;
			description
			"The namespace for all data nodes, as defined in
			YANG.";
			}
			}
			description
			"Namespace of the YANG item for this mapping entry.";
			}
	If the corresponding 'namespace' field is 'module',		leaf identifier {
	'feature', or 'identity', then this field MUST		type union {
	contain a valid YANG identifier string.		type yang:yang-identifier;
			type schema-node-path;
			}
			description
			"String identifier of the YANG item for this mapping
			entry.
	If the corresponding 'namespace' field is 'data',		If the corresponding 'namespace' field is 'module',
	then this field MUST contain a valid schema node		'feature', or 'identity', then this field MUST
	path.";		contain a valid YANG identifier string.
	}
	leaf sid {		If the corresponding 'namespace' field is 'data',
	type sid;		then this field MUST contain a valid schema node
	mandatory true;		path.";
	description		}
	"YANG SID assigned to the YANG item for this mapping entry.";
	}		leaf sid {
	}		type sid;
	}		mandatory true;
	}		description
	}		"YANG SID assigned to the YANG item for this mapping
	<CODE ENDS>		entry.";
			}
			}
			}
			}
			}
			<CODE ENDS>
	5. Content-Types		5. Content-Types
	The following Content-Type is defined:		The following Content-Type has been defined in
			[I-D.ietf-core-yang-cbor]:
	application/yang-data+cbor; id=sid: This Content-Type represents a		application/yang-data+cbor; id=sid: This Content-Type represents a
	CBOR YANG document containing one or multiple data node values.		CBOR YANG document containing one or multiple data node values.
	Each data node is identified by its associated SID.		Each data node is identified by its associated SID.
	FORMAT: CBOR map of SID, instance-value		FORMAT: CBOR map of SID, instance-value
	The message payload of Content-Type 'application/yang-data+cbor'		The message payload of Content-Type 'application/yang-data+cbor'
	is encoded using a CBOR map. Each entry within the CBOR map		is encoded using a CBOR map. Each entry within the CBOR map
	contains the data node identifier (i.e. SID) and the associated		contains the data node identifier (i.e. SID) and the associated
	instance-value. Instance-values are encoded using the rules		instance-value. Instance-values are encoded using the rules
	defined in [I-D.ietf-core-yang-cbor] section 4.		defined in Section 4 of [I-D.ietf-core-yang-cbor].
	6. Security Considerations		6. Security Considerations
	This document defines a new type of identifier used to encode data		This document defines a new type of identifier used to encode data
	models defined in YANG [RFC7950]. As such, this identifier does not		models defined in YANG [RFC7950]. As such, this identifier does not
	contribute to any new security issues in addition of those identified		contribute to any new security issues in addition of those identified
	for the specific protocols or contexts for which it is used.		for the specific protocols or contexts for which it is used.
	7. IANA Considerations		7. IANA Considerations
	skipping to change at page 13, line 27 ¶		skipping to change at page 13, line 44 ¶
	Reference: RFC XXXX		Reference: RFC XXXX
	// RFC Ed.: please replace XXXX with RFC number and remove this note		// RFC Ed.: please replace XXXX with RFC number and remove this note
	7.2. Register ".sid" File Format Module		7.2. Register ".sid" File Format Module
	This document registers one YANG module in the "YANG Module Names"		This document registers one YANG module in the "YANG Module Names"
	registry [RFC6020]:		registry [RFC6020]:
	o name: ietf-sid-file		* name: ietf-sid-file
	o namespace: urn:ietf:params:xml:ns:yang:ietf-sid-file		* namespace: urn:ietf:params:xml:ns:yang:ietf-sid-file
	o prefix: sid		* prefix: sid
	o reference: [[THISRFC]]		* reference: [[RFC XXXX]]
			// RFC Ed.: please replace XXXX with RFC number and remove this note
	7.3. CoAP Content-Formats Registry		7.3. CoAP Content-Formats Registry
	This document adds the following Content-Format to the "CoAP Content-		A Content-Format for "application/yang-data+cbor; id=sid" has been
	Formats", within the "Constrained RESTful Environments (CoRE)		added to the "CoAP Content-Formats" within the "Constrained RESTful
	Parameters" registry.		Environments (CoRE) Parameters" registry, in
			[I-D.ietf-core-yang-cbor].
	+---------------------------------+--------------+------+-----------+
	| Media Type | Content | ID | Reference |
	| | Coding | | |
	+---------------------------------+--------------+------+-----------+
	| application/yang-data+cbor; | | TBD1 | RFC XXXX |
	| id=sid | | | |
	+---------------------------------+--------------+------+-----------+
	// RFC Ed.: replace TBD1 with assigned IDs and remove this note. //
	RFC Ed.: replace RFC XXXX with this RFC number and remove this note.
	7.4. Create new IANA Registry: "YANG SID Mega-Range" registry		7.4. Create new IANA Registry: "YANG SID Mega-Range" registry
	The name of this registry is "YANG SID Mega-Range". This registry is		The name of this registry is "YANG SID Mega-Range". This registry is
	used to record the delegation of the management of a block of SIDs to		used to record the delegation of the management of a block of SIDs to
	third parties (such as SDOs or registrars).		third parties (such as SDOs or registrars).
	7.4.1. Structure		7.4.1. Structure
	Each entry in this registry must include:		Each entry in this registry must include:
	o The entry point (first SID) of the registered SID block.		* The entry point (first SID) of the registered SID block.
	o The size of the registered SID block. The size MUST be one		* The size of the registered SID block. The size MUST be one
	million (1 000 000) SIDs.		million (1 000 000) SIDs.
	o The contact information of the requesting organization including:		* The contact information of the requesting organization including:
	* The policy of SID range allocations: Public, Private or Both.		- The policy of SID range allocations: Public, Private or Both.
	* Organization name		- Organization name
	* URL		- URL
	The information associated to the Organization name should not be		The information associated to the Organization name should not be
	publicly visible in the registry, but should be available. This		publicly visible in the registry, but should be available. This
	information includes contact email and phone number and change		information includes contact email and phone number and change
	controller email and phone number.		controller email and phone number.
	7.4.2. Allocation policy		7.4.2. Allocation policy
	The IANA policy for future additions to this registry is "Expert		The IANA policy for future additions to this registry is "Expert
	Review" [RFC8126].		Review" [RFC8126].
	An organization requesting to manage a YANG SID Range (and thus have		An organization requesting to manage a YANG SID Range (and thus have
	an entry in the YANG SID Mega-Range Registry), must ensure the		an entry in the YANG SID Mega-Range Registry), must ensure the
	following capacities:		following capacities:
	o The capacity to manage and operate a YANG SID Range Registry. A		* The capacity to manage and operate a YANG SID Range Registry. A
	YANG SID Range Registry MUST provide the following information for		YANG SID Range Registry MUST provide the following information for
	all YANG SID Ranges allocated by the Registry:		all YANG SID Ranges allocated by the Registry:
	* Entry Point of allocated YANG SID Range		- Entry Point of allocated YANG SID Range
	* Size of allocated YANG SID Range		- Size of allocated YANG SID Range
	* Type: Public or Private		- Type: Public or Private
	+ Public Ranges MUST include at least a reference to the YANG
			o Public Ranges MUST include at least a reference to the YANG
	module and ".sid" files for that YANG SID Range.		module and ".sid" files for that YANG SID Range.
	+ Private Ranges MUST be marked as "Private"		o Private Ranges MUST be marked as "Private"
	o A Policy of allocation, which clearly identifies if the YANG SID		* A Policy of allocation, which clearly identifies if the YANG SID
	Range allocations would be Private, Public or Both.		Range allocations would be Private, Public or Both.
	o Technical capacity to ensure the sustained operation of the		* Technical capacity to ensure the sustained operation of the
	registry for a period of at least 5 years. If Private		registry for a period of at least 5 years. If Private
	Registrations are allowed, the period must be of at least 10		Registrations are allowed, the period must be of at least 10
	years.		years.
	7.4.2.1. First allocation		7.4.2.1. First allocation
	For a first allocation to be provided, the requesting organization		For a first allocation to be provided, the requesting organization
	must demonstrate a functional registry infrastructure.		must demonstrate a functional registry infrastructure.
	7.4.2.2. Consecutive allocations		7.4.2.2. Consecutive allocations
	skipping to change at page 15, line 37 ¶		skipping to change at page 16, line 5 ¶
	If that extra-allocation is done within 3 years from the last		If that extra-allocation is done within 3 years from the last
	allocation, the experts need to discuss this request on the CORE		allocation, the experts need to discuss this request on the CORE
	working group mailing list and consensus needs to be obtained before		working group mailing list and consensus needs to be obtained before
	allocating a new Mega-Range.		allocating a new Mega-Range.
	7.4.3. Initial contents of the Registry		7.4.3. Initial contents of the Registry
	The initial entry in this registry is allocated to IANA:		The initial entry in this registry is allocated to IANA:
	+-------------+---------+------------+-------------------+----------+		+=============+=========+============+===================+==========+
	| Entry Point | Size | Allocation | Organization name | URL |		| Entry Point | Size | Allocation | Organization | URL |
	+-------------+---------+------------+-------------------+----------+		| | | | name | |
			+=============+=========+============+===================+==========+
	| 0 | 1000000 | Public | IANA | iana.org |		| 0 | 1000000 | Public | IANA | iana.org |
	+-------------+---------+------------+-------------------+----------+		+-------------+---------+------------+-------------------+----------+
			Table 1
	7.5. Create a new IANA Registry: IETF YANG SID Range Registry (managed		7.5. Create a new IANA Registry: IETF YANG SID Range Registry (managed
	by IANA)		by IANA)
	7.5.1. Structure		7.5.1. Structure
	Each entry in this registry must include:		Each entry in this registry must include:
	o The SID range entry point.		* The SID range entry point.
	o The SID range size.		* The SID range size.
	o The YANG module name.		* The YANG module name.
	o Document reference.		* Document reference.
	7.5.2. Allocation policy		7.5.2. Allocation policy
	The first million SIDs assigned to IANA is sub-divided as follows:		The first million SIDs assigned to IANA is sub-divided as follows:
	o The range of 0 to 999 (size 1000) is "Reserved" as defined in		* The range of 0 to 999 (size 1000) is "Reserved" as defined in
	[RFC8126].		[RFC8126].
	o The range of 1000 to 59,999 (size 59,000) is reserved for YANG		* The range of 1000 to 59,999 (size 59,000) is reserved for YANG
	modules defined in RFCs.		modules defined in RFCs.
	* The IANA policy for additions to this registry is either:		- The IANA policy for additions to this registry is either:
	+ "Expert Review" [RFC8126] in case the ".sid" file comes from		o "Expert Review" [RFC8126] in case the ".sid" file comes from
	a YANG module from an existing RFC, or		a YANG module from an existing RFC, or
	+ "RFC Required" [RFC8126] otherwise.		o "RFC Required" [RFC8126] otherwise.
	* The Expert MUST verify that the YANG module for which this		- The Expert MUST verify that the YANG module for which this
	allocation is made has an RFC (existing RFC) OR is on track to		allocation is made has an RFC (existing RFC) OR is on track to
	become RFC (early allocation with a request from the WG chairs		become RFC (early allocation with a request from the WG chairs
	as defined by [RFC7120]).		as defined by [BCP100]).
	o The range of 60,000 to 99,999 (size 40,000) is reserved for		* The range of 60,000 to 99,999 (size 40,000) is reserved for
	experimental YANG modules. This range MUST NOT be used in		experimental YANG modules. This range MUST NOT be used in
	operational deployments since these SIDs are not globally unique		operational deployments since these SIDs are not globally unique
	which limit their interoperability. The IANA policy for this		which limit their interoperability. The IANA policy for this
	range is "Experimental use" [RFC8126].		range is "Experimental use" [RFC8126].
	o The range of 100,000 to 999,999 (size 900,000) is "Reserved" as		* The range of 100,000 to 999,999 (size 900,000) is "Reserved" as
	defined in [RFC8126].		defined in [RFC8126].
	+-------------+---------+-------------------------------+		+=============+=========+===============================+
	| Entry Point | Size | IANA policy |		| Entry Point | Size | IANA policy |
	+-------------+---------+-------------------------------+		+=============+=========+===============================+
	| 0 | 1,000 | Reserved |		| 0 | 1,000 | Reserved |
			+-------------+---------+-------------------------------+
	| 1,000 | 59,000 | Expert Review or RFC Required |		| 1,000 | 59,000 | Expert Review or RFC Required |
			+-------------+---------+-------------------------------+
	| 60,000 | 40,000 | Experimental use |		| 60,000 | 40,000 | Experimental use |
			+-------------+---------+-------------------------------+
	| 100,000 | 900,000 | Reserved |		| 100,000 | 900,000 | Reserved |
	+-------------+---------+-------------------------------+		+-------------+---------+-------------------------------+
			Table 2
	The size of the SID range allocated for a YANG module is recommended		The size of the SID range allocated for a YANG module is recommended
	to be a multiple of 50 and to be at least 33% above the current		to be a multiple of 50 and to be at least 33% above the current
	number of YANG items. This headroom allows assignment within the		number of YANG items. This headroom allows assignment within the
	same range of new YANG items introduced by subsequent revisions. The		same range of new YANG items introduced by subsequent revisions. The
	maximum SID range size is 1000. A larger size may be requested by		maximum SID range size is 1000. A larger size may be requested by
	the authors if this recommendation is considered insufficient. It is		the authors if this recommendation is considered insufficient. It is
	important to note that an additional SID range can be allocated to an		important to note that an additional SID range can be allocated to an
	existing YANG module if the initial range is exhausted.		existing YANG module if the initial range is exhausted.
	In case a SID range is allocated for an existing RFC through the		In case a SID range is allocated for an existing RFC through the
	"Expert Review" policy, the Document reference field for the given		"Expert Review" policy, the Document reference field for the given
	allocation should point to the RFC that the YANG module is defined		allocation should point to the RFC that the YANG module is defined
	in.		in.
	In case a SID range is required before publishing the RFC due to		In case a SID range is required before publishing the RFC due to
	implementations needing stable SID values, early allocation as		implementations needing stable SID values, early allocation as
	defined in [RFC7120] can be employed. As specified in section 4.6 of		defined in [BCP100] can be employed. As specified in Section 4.6 of
	[RFC8126], RFCs and by extension documents that are expected to		[RFC8126], RFCs and by extension documents that are expected to
	become an RFC fulfill the requirement for "Specification Required"		become an RFC fulfill the requirement for "Specification Required"
	stated in section 2 of [RFC7120], which allows for the early		stated in Section 2 of [BCP100], which allows for the early
	allocation process to be employed.		allocation process to be employed.
	7.5.3. Initial contents of the registry		7.5.3. Initial contents of the registry
	Initial entries in this registry are as follows:		Initial entries in this registry are as follows:
	+-------+------+---------------------------+------------------------+		+=======+=====+==============+======================================+
	| Entry | Size | Module name | Document reference |		| Entry | Size|Module name | Document reference |
	| Point | | | |		| Point | | | |
	+-------+------+---------------------------+------------------------+		+=======+=====+==============+======================================+
	| 1000 | 100 | ietf-coreconf | [I-D.ietf-core-comi] |		| 1000 | 100|ietf-coreconf | [I-D.ietf-core-comi] |
	| 1100 | 50 | ietf-yang-types | [RFC6991] |		+-------+-----+--------------+--------------------------------------+
	| 1150 | 50 | ietf-inet-types | [RFC6991] |		| 1100 | 50|ietf-yang- | [RFC6991] |
	| 1200 | 50 | iana-crypt-hash | [RFC7317] |		| | |types | |
	| 1250 | 50 | ietf-netconf-acm | [RFC8341] |		+-------+-----+--------------+--------------------------------------+
	| 1300 | 50 | ietf-sid-file | RFCXXXX |		| 1150 | 50|ietf-inet- | [RFC6991] |
	| 1500 | 100 | ietf-interfaces | [RFC8343] |		| | |types | |
	| 1600 | 100 | ietf-ip | [RFC8344] |		+-------+-----+--------------+--------------------------------------+
	| 1700 | 100 | ietf-system | [RFC7317] |		| 1200 | 50|iana-crypt- | [RFC7317] |
	| 1800 | 400 | iana-if-type | [RFC7224] |		| | |hash | |
	| 2400 | 50 | ietf-voucher | [RFC8366] |		+-------+-----+--------------+--------------------------------------+
	| 2450 | 50 | ietf-constrained-voucher | [I-D.ietf-anima-constr |		| 1250 | 50|ietf-netconf- | [RFC8341] |
	| | | | ained-voucher] |		| | |acm | |
	| 2500 | 50 | ietf-constrained-voucher- | [I-D.ietf-anima-constr |		+-------+-----+--------------+--------------------------------------+
	| | | request | ained-voucher] |		| 1300 | 50|ietf-sid-file | RFCXXXX |
	+-------+------+---------------------------+------------------------+		+-------+-----+--------------+--------------------------------------+
			| 1500 | 100|ietf- | [RFC8343] |
			| | |interfaces | |
			+-------+-----+--------------+--------------------------------------+
			| 1600 | 100|ietf-ip | [RFC8344] |
			+-------+-----+--------------+--------------------------------------+
			| 1700 | 100|ietf-system | [RFC7317] |
			+-------+-----+--------------+--------------------------------------+
			| 1800 | 400|iana-if-type | [RFC7224] |
			+-------+-----+--------------+--------------------------------------+
			| 2400 | 50|ietf-voucher | [RFC8366] |
			+-------+-----+--------------+--------------------------------------+
			| 2450 | 50|ietf- | [I-D.ietf-anima-constrained-voucher] |
			| | |constrained- | |
			| | |voucher | |
			+-------+-----+--------------+--------------------------------------+
			| 2500 | 50|ietf- | [I-D.ietf-anima-constrained-voucher] |
			| | |constrained- | |
			| | |voucher- | |
			| | |request | |
			+-------+-----+--------------+--------------------------------------+
			Table 3
	// RFC Ed.: replace XXXX with RFC number assigned to this draft.		// RFC Ed.: replace XXXX with RFC number assigned to this draft.
	For allocation, RFC publication of the YANG module is required as per		For allocation, RFC publication of the YANG module is required as per
	[RFC8126]. The YANG module must be registered in the "YANG module		[RFC8126]. The YANG module must be registered in the "YANG module
	Name" registry according to the rules specified in section 14 of		Name" registry according to the rules specified in Section 14 of
	[RFC6020].		[RFC6020].
	7.6. Create new IANA Registry: "IETF YANG SID Registry"		7.6. Create new IANA Registry: "IETF YANG SID Registry"
	The name of this registry is "IETF YANG SID Registry". This registry		The name of this registry is "IETF YANG SID Registry". This registry
	is used to record the allocation of SIDs for individual YANG module		is used to record the allocation of SIDs for individual YANG module
	items.		items.
	7.6.1. Structure		7.6.1. Structure
	Each entry in this registry must include:		Each entry in this registry must include:
	o The YANG module name. This module name must be present in the		* The YANG module name. This module name must be present in the
	"Name" column of the "YANG Module Names" registry.		"Name" column of the "YANG Module Names" registry.
	o A link to the associated ".yang" file. This file link must be		* A link to the associated ".yang" file. This file link must be
	present in the "File" column of the "YANG Module Names" registry.		present in the "File" column of the "YANG Module Names" registry.
	o The link to the ".sid" file which defines the allocation. The		* The link to the ".sid" file which defines the allocation. The
	".sid" file is stored by IANA.		".sid" file is stored by IANA.
	o The number of actually allocated SIDs in the ".sid" file.		* The number of actually allocated SIDs in the ".sid" file.
	7.6.2. Allocation policy		7.6.2. Allocation policy
	The allocation policy is Expert review. The Expert MUST ensure that		The allocation policy is Expert review. The Expert MUST ensure that
	the following conditions are met:		the following conditions are met:
	o The ".sid" file has a valid structure:		* The ".sid" file has a valid structure:
	* The ".sid" file MUST be a valid JSON file following the		- The ".sid" file MUST be a valid JSON file following the
	structure of the module defined in RFCXXXX (RFC Ed: replace XXX		structure of the module defined in RFCXXXX (RFC Ed: replace XXX
	with RFC number assigned to this draft).		with RFC number assigned to this draft).
	o The ".sid" file allocates individual SIDs ONLY in the YANG SID		* The ".sid" file allocates individual SIDs ONLY in the YANG SID
	Ranges for this YANG module (as allocated in the IETF YANG SID		Ranges for this YANG module (as allocated in the IETF YANG SID
	Range Registry):		Range Registry):
	* All SIDs in this ".sid" file MUST be within the ranges		- All SIDs in this ".sid" file MUST be within the ranges
	allocated to this YANG module in the "IETF YANG SID Range		allocated to this YANG module in the "IETF YANG SID Range
	Registry".		Registry".
	o If another ".sid" file has already allocated SIDs for this YANG		* If another ".sid" file has already allocated SIDs for this YANG
	module (e.g. for older or newer versions of the YANG module), the		module (e.g. for older or newer versions of the YANG module), the
	YANG items are assigned the same SIDs as in the other ".sid" file.		YANG items are assigned the same SIDs as in the other ".sid" file.
	o If there is an older version of the ".sid" file, all allocated		* If there is an older version of the ".sid" file, all allocated
	SIDs from that version are still present in the current version of		SIDs from that version are still present in the current version of
	the ".sid" file.		the ".sid" file.
	7.6.3. Recursive Allocation of YANG SID Range at Document Adoption		7.6.3. Recursive Allocation of YANG SID Range at Document Adoption
	Due to the difficulty in changing SID values during IETF document		Due to the difficulty in changing SID values during IETF document
	processing, it is expected that most documents will ask for SID		processing, it is expected that most documents will ask for SID
	allocations using Early Allocations [RFC7120]. The details of the		allocations using Early Allocations [BCP100]. The details of the
	Early Allocation should be included in any Working Group Adoption		Early Allocation should be included in any Working Group Adoption
	call. Prior to Working Group Adoption, an internet draft authors can		call. Prior to Working Group Adoption, an internet draft authors can
	use the experimental SID range (as per Section 7.5.2) for their SIDs		use the experimental SID range (as per Section 7.5.2) for their SIDs
	allocations or other values that do not create ambiguity with other		allocations or other values that do not create ambiguity with other
	SID uses (for example they can use a range that comes from a non-IANA		SID uses (for example they can use a range that comes from a non-IANA
	managed "YANG SID Mega-Range" registry).		managed "YANG SID Mega-Range" registry).
	After Working Group Adoption, any modification of a ".sid" file is		After Working Group Adoption, any modification of a ".sid" file is
	expected to be discussed on the mailing list of the appropriate		expected to be discussed on the mailing list of the appropriate
	Working Groups. Specific attention should be paid to implementers'		Working Groups. Specific attention should be paid to implementers'
	skipping to change at page 19, line 38 ¶		skipping to change at page 20, line 38 ¶
	During the early use of SIDs, many existing, previously published		During the early use of SIDs, many existing, previously published
	YANG modules will not have SID allocations. For an allocation to be		YANG modules will not have SID allocations. For an allocation to be
	useful the included YANG modules may also need to have SID		useful the included YANG modules may also need to have SID
	allocations made.		allocations made.
	The Expert Reviewer who performs the (Early) Allocation analysis will		The Expert Reviewer who performs the (Early) Allocation analysis will
	need to go through the list of included YANG modules and perform SID		need to go through the list of included YANG modules and perform SID
	allocations for those modules as well.		allocations for those modules as well.
	o If the document is a published RFC, then the allocation of SIDs		* If the document is a published RFC, then the allocation of SIDs
	for its referenced YANG modules is permanent. The Expert Reviewer		for its referenced YANG modules is permanent. The Expert Reviewer
	provides the generated SID file to IANA for registration. This		provides the generated SID file to IANA for registration. This
	process may be time consuming during a bootstrap period (there are		process may be time consuming during a bootstrap period (there are
	over 100 YANG modules to date, none of which have SID		over 100 YANG modules to date, none of which have SID
	allocations), but should quiet down once needed entries are		allocations), but should quiet down once needed entries are
	allocated.		allocated.
	o If the document is an unprocessed Internet-Draft adopted in a WG,		* If the document is an unprocessed Internet-Draft adopted in a WG,
	then an Early Allocation is performed for this document as well.		then an Early Allocation is performed for this document as well.
	Early Allocations require approval by an IESG Area Director. An		Early Allocations require approval by an IESG Area Director. An
	early allocation which requires additional allocations will list		early allocation which requires additional allocations will list
	the other allocations in it's description, and will be cross-		the other allocations in it's description, and will be cross-
	posted to the any other working group mailing lists.		posted to the any other working group mailing lists.
	o A YANG module which references a module in an document which has		* A YANG module which references a module in an document which has
	not yet been adopted by any working group will be unable to		not yet been adopted by any working group will be unable to
	perform an Early Allocation for that other document until it is		perform an Early Allocation for that other document until it is
	adopted by a working group. As described in [RFC7120], an AD		adopted by a working group. As described in [BCP100], an AD
	Sponsored document acts as if it had a working group. The		Sponsored document acts as if it had a working group. The
	approving AD may also exempt a document from this policy by		approving AD may also exempt a document from this policy by
	agreeing to AD Sponsor the document.		agreeing to AD Sponsor the document.
	At the end of the IETF process all the dependencies of a given module		At the end of the IETF process all the dependencies of a given module
	for which SIDs are assigned, should also have SIDs assigned. Those		for which SIDs are assigned, should also have SIDs assigned. Those
	dependencies' assignments should be permanent (not Early Allocation).		dependencies' assignments should be permanent (not Early Allocation).
	A previously SID-allocated YANG module which changes its references		A previously SID-allocated YANG module which changes its references
	to include a YANG module for which there is no SID allocation needs		to include a YANG module for which there is no SID allocation needs
	to repeat the Early Allocation process.		to repeat the Early Allocation process.
	Early Allocations are made with a one-year period, after which they		Early Allocations are made with a one-year period, after which they
	are expired. [RFC7120] indicates that at most one renewal may be		are expired. [BCP100] indicates that at most one renewal may be
	made. For the SID allocation a far more lenient stance is desired.		made. For the SID allocation a far more lenient stance is desired.
	1. An extension of a referencing documents Early Allocation should		1. An extension of a referencing documents Early Allocation should
	update any referenced Early Allocations to expire no sooner than		update any referenced Early Allocations to expire no sooner than
	the referencing document.		the referencing document.
	2. The [RFC7120] mechanism allows the IESG to provide a second		2. The [BCP100] mechanism allows the IESG to provide a second
	renewal, and such an event may prompt some thought about how the		renewal, and such an event may prompt some thought about how the
	collection of documents are being processed.		collection of documents are being processed.
	This is driven by the very generous size of the SID space and the		This is driven by the very generous size of the SID space and the
	often complex and deep dependencies of YANG modules. Often a core		often complex and deep dependencies of YANG modules. Often a core
	module with many dependencies will undergo extensive review, delaying		module with many dependencies will undergo extensive review, delaying
	the publication of other documents.		the publication of other documents.
	[RFC7120] also says:		[BCP100] also says:
	Note that if a document is submitted for review to the IESG and at		Note that if a document is submitted for review to the IESG and at
	the time of submission some early allocations are valid (not		the time of submission some early allocations are valid (not
	expired), these allocations should not be expired while the document		expired), these allocations should not be expired while the document
	is under IESG consideration or waiting in the RFC Editor's queue		is under IESG consideration or waiting in the RFC Editor's queue
	after approval by the IESG.		after approval by the IESG.
	7.6.4. Initial contents of the registry		7.6.4. Initial contents of the registry
	None.		None.
	8. Acknowledgments		8. References
	The authors would like to thank Andy Bierman, Carsten Bormann,		8.1. Normative References
	Michael Richardson, Abhinav Somaraju, Peter van der Stok, Laurent
	Toutain and Randy Turner for their help during the development of
	this document and their useful comments during the review process.
	9. References		[BCP100] Cotton, M., "Early IANA Allocation of Standards Track Code
			Points", BCP 100, RFC 7120, January 2014.
	9.1. Normative References		<https://www.rfc-editor.org/info/bcp100>
	[I-D.ietf-core-yang-cbor]		[I-D.ietf-core-yang-cbor]
	Veillette, M., Petrov, I., and A. Pelov, "CBOR Encoding of		Veillette, M., Petrov, I., and A. Pelov, "CBOR Encoding of
	Data Modeled with YANG", draft-ietf-core-yang-cbor-13		Data Modeled with YANG", Work in Progress, Internet-Draft,
	(work in progress), July 2020.		draft-ietf-core-yang-cbor-15, 25 January 2021,
			<https://www.ietf.org/archive/id/draft-ietf-core-yang-
			cbor-15.txt>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	DOI 10.17487/RFC3688, January 2004,		DOI 10.17487/RFC3688, January 2004,
	<https://www.rfc-editor.org/info/rfc3688>.		<https://www.rfc-editor.org/info/rfc3688>.
	[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",		[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
	RFC 6991, DOI 10.17487/RFC6991, July 2013,		RFC 6991, DOI 10.17487/RFC6991, July 2013,
	<https://www.rfc-editor.org/info/rfc6991>.		<https://www.rfc-editor.org/info/rfc6991>.
	[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code
	Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January
	2014, <https://www.rfc-editor.org/info/rfc7120>.
	[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",		[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
	RFC 7950, DOI 10.17487/RFC7950, August 2016,		RFC 7950, DOI 10.17487/RFC7950, August 2016,
	<https://www.rfc-editor.org/info/rfc7950>.		<https://www.rfc-editor.org/info/rfc7950>.
	[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",		[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",
	RFC 7951, DOI 10.17487/RFC7951, August 2016,		RFC 7951, DOI 10.17487/RFC7951, August 2016,
	<https://www.rfc-editor.org/info/rfc7951>.		<https://www.rfc-editor.org/info/rfc7951>.
	[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF		[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
	Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,		Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
	<https://www.rfc-editor.org/info/rfc8040>.		<https://www.rfc-editor.org/info/rfc8040>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	9.2. Informative References		8.2. Informative References
	[I-D.ietf-anima-constrained-voucher]		[I-D.ietf-anima-constrained-voucher]
	Richardson, M., Stok, P., and P. Kampanakis, "Constrained		Richardson, M., Stok, P. V. D., Kampanakis, P., and E.
	Voucher Artifacts for Bootstrapping Protocols", draft-		Dijk, "Constrained Voucher Artifacts for Bootstrapping
	ietf-anima-constrained-voucher-09 (work in progress),		Protocols", Work in Progress, Internet-Draft, draft-ietf-
	November 2020.		anima-constrained-voucher-11, 11 June 2021,
			<https://www.ietf.org/archive/id/draft-ietf-anima-
			constrained-voucher-11.txt>.
	[I-D.ietf-core-comi]		[I-D.ietf-core-comi]
	Veillette, M., Stok, P., Pelov, A., Bierman, A., and I.		Veillette, M., Stok, P. V. D., Pelov, A., Bierman, A., and
	Petrov, "CoAP Management Interface (CORECONF)", draft-		I. Petrov, "CoAP Management Interface (CORECONF)", Work in
	ietf-core-comi-10 (work in progress), July 2020.		Progress, Internet-Draft, draft-ietf-core-comi-11, 17
			January 2021, <https://www.ietf.org/archive/id/draft-ietf-
			core-comi-11.txt>.
	[I-D.ietf-core-yang-library]		[I-D.ietf-core-yang-library]
	Veillette, M. and I. Petrov, "Constrained YANG Module		Veillette, M. and I. Petrov, "Constrained YANG Module
	Library", draft-ietf-core-yang-library-03 (work in		Library", Work in Progress, Internet-Draft, draft-ietf-
	progress), January 2021.		core-yang-library-03, 11 January 2021,
			<https://www.ietf.org/archive/id/draft-ietf-core-yang-
			library-03.txt>.
	[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for		[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
	the Network Configuration Protocol (NETCONF)", RFC 6020,		the Network Configuration Protocol (NETCONF)", RFC 6020,
	DOI 10.17487/RFC6020, October 2010,		DOI 10.17487/RFC6020, October 2010,
	<https://www.rfc-editor.org/info/rfc6020>.		<https://www.rfc-editor.org/info/rfc6020>.
	[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,		[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
	and A. Bierman, Ed., "Network Configuration Protocol		and A. Bierman, Ed., "Network Configuration Protocol
	(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,		(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
	<https://www.rfc-editor.org/info/rfc6241>.		<https://www.rfc-editor.org/info/rfc6241>.
	skipping to change at page 23, line 23 ¶		skipping to change at page 24, line 28 ¶
	[RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,		[RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
	"A Voucher Artifact for Bootstrapping Protocols",		"A Voucher Artifact for Bootstrapping Protocols",
	RFC 8366, DOI 10.17487/RFC8366, May 2018,		RFC 8366, DOI 10.17487/RFC8366, May 2018,
	<https://www.rfc-editor.org/info/rfc8366>.		<https://www.rfc-editor.org/info/rfc8366>.
	Appendix A. ".sid" file example		Appendix A. ".sid" file example
	The following ".sid" file (ietf-system@2014-08-06.sid) have been		The following ".sid" file (ietf-system@2014-08-06.sid) have been
	generated using the following yang modules:		generated using the following yang modules:
	o ietf-system@2014-08-06.yang (defined in [RFC7317])		* ietf-system@2014-08-06.yang (defined in [RFC7317])
	o ietf-yang-types@2013-07-15.yang (defined in [RFC6991])		* ietf-yang-types@2013-07-15.yang (defined in [RFC6991])
	o ietf-inet-types@2013-07-15.yang (defined in [RFC6991])		* ietf-inet-types@2013-07-15.yang (defined in [RFC6991])
	o ietf-netconf-acm@2018-02-14.yang (defined in [RFC8341])		* ietf-netconf-acm@2018-02-14.yang (defined in [RFC8341])
	o iana-crypt-hash@2014-04-04.yang (defined in [RFC7317])		* iana-crypt-hash@2014-08-06.yang (defined in [RFC7317])
	{		{
	"ietf-sid-file:sid-file" : {		"ietf-sid-file:sid-file" : {
	"module-name": "ietf-system",		"module-name": "ietf-system",
	"module-revision": "2020-02-05",		"module-revision": "2020-02-05",
	"dependency-revision": [		"dependency-revision": [
	{		{
	"module-name": "ietf-yang-types",		"module-name": "ietf-yang-types",
	"module-revision": "2013-07-15.yang"		"module-revision": "2013-07-15"
	},		},
	{		{
	"module-name": "ietf-inet-types",		"module-name": "ietf-inet-types",
	"module-revision": "2013-07-15.yang"		"module-revision": "2013-07-15"
	},		},
	{		{
	"module-name": "ietf-netconf-acm",		"module-name": "ietf-netconf-acm",
	"module-revision": "2018-02-14.yang"		"module-revision": "2018-02-14"
	},		},
	{		{
	"module-name": "iana-crypt-hash",		"module-name": "iana-crypt-hash",
	"module-revision": "2014-04-04.yang"		"module-revision": "2014-08-06"
	}		}
	],		],
	"description": "Example sid file",		"description": "Example sid file",
	"assignment-ranges": [		"assignment-range": [
	{		{
	"entry-point": 1700,		"entry-point": 1700,
	"size": 100		"size": 100
	}		}
	],		],
	"items": [		"item": [
	{		{
	"namespace": "module",		"namespace": "module",
	"identifier": "ietf-system",		"identifier": "ietf-system",
	"sid": 1700		"sid": 1700
	},		},
	{		{
	"namespace": "identity",		"namespace": "identity",
	"identifier": "authentication-method",		"identifier": "authentication-method",
	"sid": 1701		"sid": 1701
	},		},
	skipping to change at page 33, line 51 ¶		skipping to change at page 35, line 5 ¶
	order to allow better evolution of the YANG module in the future.		order to allow better evolution of the YANG module in the future.
	Generation of ".sid" files should be performed using an automated		Generation of ".sid" files should be performed using an automated
	tool. Note that ".sid" files can only be generated for YANG modules		tool. Note that ".sid" files can only be generated for YANG modules
	and not for submodules.		and not for submodules.
	C.1. ".sid" File Creation		C.1. ".sid" File Creation
	The following activity diagram summarizes the creation of a YANG		The following activity diagram summarizes the creation of a YANG
	module and its associated ".sid" file.		module and its associated ".sid" file.
	+---------------+		+---------------+
	O | Creation of a |		o | Creation of a |
			-+- -->| YANG module |
	-|- ->| YANG module |		/ \ +------+--------+
	/ \ +---------------+
	|		|
	V		v
	/-------------\		.-------------.
	/ Standardized \ yes		/ Standardized \ yes
	\ YANG module ? /-------------+		\ YANG module ? /------------+
	\-------------/ |		'-----+-------' |
	| no |		| no |
	V V		v v
	/-------------\ +---------------+		.-------------. +---------------+
	/ Constrained \ yes | SID range |		+--> / Constrained \ yes | SID range |
	+-->\ application ? /---->| registration |<----------+		| \ application ? /---->| registration |<---------+
	| \-------------/ +---------------+ |		| '-----+-------' +------+--------+ |
	| | no | |		| | no | |
	| V V |		| v v |
	| +---------------+ +---------------+ |		| +---------------+ +---------------+ |
	+---| YANG module | | SID sub-range | |		+----+ YANG module | | SID sub-range | |
	| update | | assignment |<----------+		| update | | assignment |<----------+
	+---------------+ +---------------+ |		+---------------+ +-------+-------+ |
	| |		| |
	V |		v |
	+---------------+ +-------------+		+---------------+ +------+------+
	| ".sid" file | | Rework YANG |		| ".sid" file | | Rework YANG |
	| generation | | model |		| generation | | model |
	+---------------+ +-------------+		+-------+-------+ +-------------+
	| ^		| ^
	V |		v |
	/----------\ yes |		.----------. yes |
	/ Work in \ -----------+		/ Work in \ -----------+
	\ progress /		\ progress /
	\----------/		'----+-----'
	| no		| no
	V		v
	/-------------\ /-------------\		.-------------. .-------------.
	/ RFC \ no / Open \ no		/ RFC \ no / Open \ no
	\ publication? /---->\ specification?/---+		\ publication? /---> \ specification?/---+
	\-------------/ \-------------/ |		'------+------' '------+------' |
	| yes | yes |		yes | | yes |
	| +---------------+ |		| .------------' |
	V V V		| / |
	+---------------+ +---------------+		v v v
	| IANA | | Third party |		+---------------+ +---------------+
	| registration | | registration |		| IANA | | Third party |
	+-------+-------+ +-------+-------+		| registration | | registration |
			+-------+-------+ +---------+-----+
	| |		| |
	+---------------------------------+		+---------------------------------+
	V		v
	[DONE]		[DONE]
	Figure 1: SID Lifecycle		Figure 1: SID Lifecycle
	C.2. ".sid" File Update		C.2. ".sid" File Update
	The following Activity diagram summarizes the update of a YANG module		The following Activity diagram summarizes the update of a YANG module
	and its associated ".sid" file.		and its associated ".sid" file.
	+---------------+		+---------------+
	O | Update of the |		o | Update of the |
	-|- ->| YANG module |		-+- -->| YANG module |
	/ \ | or include(s) |		/ \ | or include(s) |
	| or import(s) |		| or import(s) |
	+---------------+		+------+--------+
	|		|
	V		v
	/-------------\		.-------------.
	/ New items \ yes		/ New items \ yes
	\ created ? /------+		\ created ? /------+
	\-------------/ |		'------+------' |
	| no V		| no v
	| /-------------\ +----------------+		| .-------------. +----------------+
	| / SID range \ yes | Extra sub-range|		| / SID range \ yes | Extra sub-range|
	| \ exhausted ? /---->| assignment |		| \ exhausted ? /---->| assignment |
	| \-------------/ +----------------+		| '------+------' +-------+--------+
	| | no |		| | no |
	| +---------------------+		| +---------------------+
	| |		| |
	| V		| v
	| +---------------+		| +---------------+
	| | ".sid" file |		| | ".sid" file |
	| | update based |		| | update based |
	| | on previous |		| | on previous |
	| | ".sid" file |		| | ".sid" file |
	| +---------------+		| +-------+-------+
	| |		| |
	| V		| v
	| /-------------\ +---------------+		| .-------------. +---------------+
	| / Publicly \ yes | YANG module |		| / Publicly \ yes | YANG module |
	| \ available ? /---->| registration |		| \ available ? /---->| registration |
	| \-------------/ +---------------+		| '------+------' +-------+-------+
	| | no |		| | no |
	+--------------+---------------------+		+--------------+---------------------+
	|		|
	[DONE]		[DONE]
	Figure 2: YANG and ".sid" file update		Figure 2: YANG and ".sid" file update
			Acknowledgments
			The authors would like to thank Andy Bierman, Michael Richardson,
			Abhinav Somaraju, Peter van der Stok, Laurent Toutain and Randy
			Turner for their help during the development of this document and
			their useful comments during the review process.
	Authors' Addresses		Authors' Addresses
	Michel Veillette (editor)		Michel Veillette (editor)
	Trilliant Networks Inc.		Trilliant Networks Inc.
	610 Rue du Luxembourg		610 Rue du Luxembourg
	Granby, Quebec J2J 2V2		Granby Quebec J2J 2V2
	Canada		Canada
	Phone: +14503750556		Phone: +14503750556
	Email: michel.veillette@trilliant.com		Email: michel.veillette@trilliant.com
	Alexander Pelov (editor)		Alexander Pelov (editor)
	Acklio		Acklio
	1137A avenue des Champs Blancs		1137A avenue des Champs Blancs
	Cesson-Sevigne, Bretagne 35510		35510 Cesson-Sevigne
	France		France
	Email: a@ackl.io		Email: a@ackl.io
	Ivaylo Petrov (editor)		Ivaylo Petrov (editor)
	Acklio		Google Switzerland GmbH
	1137A avenue des Champs Blancs		Brandschenkestrasse 110
	Cesson-Sevigne, Bretagne 35510		CH-8002 Zurich
	France		Switzerland
	Email: ivaylo@ackl.io		Email: ivaylopetrov@google.com
			Carsten Bormann
			Universität Bremen TZI
			Postfach 330440
			D-28359 Bremen
			Germany
			Phone: +49-421-218-63921
			Email: cabo@tzi.org
End of changes. 186 change blocks.
	531 lines changed or deleted		580 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/