draft-ietf-netmod-yang-usage-08.txt		draft-ietf-netmod-yang-usage-09.txt
	Internet Engineering Task Force A. Bierman		Internet Engineering Task Force A. Bierman
	Internet-Draft InterWorking Labs		Internet-Draft InterWorking Labs
	Intended status: Informational July 8, 2010		Intended status: Informational July 12, 2010
	Expires: January 9, 2011		Expires: January 13, 2011
	Guidelines for Authors and Reviewers of YANG Data Model Documents		Guidelines for Authors and Reviewers of YANG Data Model Documents
	draft-ietf-netmod-yang-usage-08		draft-ietf-netmod-yang-usage-09
	Abstract		Abstract
	This memo provides guidelines for authors and reviewers of standards		This memo provides guidelines for authors and reviewers of standards
	track specifications containing YANG data model modules. Applicable		track specifications containing YANG data model modules. Applicable
	portions may be used as a basis for reviews of other YANG data model		portions may be used as a basis for reviews of other YANG data model
	documents. Recommendations and procedures are defined, which are		documents. Recommendations and procedures are defined, which are
	intended to increase interoperability and usability of NETCONF		intended to increase interoperability and usability of Network
	implementations which utilize YANG data model modules.		Configuration Protocol (NETCONF) implementations which utilize YANG
			data model modules.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 January 9, 2011.		This Internet-Draft will expire on January 13, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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 45		skipping to change at page 2, line 46
	4.11. Reusable Type Definitions . . . . . . . . . . . . . . . . 17		4.11. Reusable Type Definitions . . . . . . . . . . . . . . . . 17
	4.12. Data Definitions . . . . . . . . . . . . . . . . . . . . . 17		4.12. Data Definitions . . . . . . . . . . . . . . . . . . . . . 17
	4.13. Operation Definitions . . . . . . . . . . . . . . . . . . 18		4.13. Operation Definitions . . . . . . . . . . . . . . . . . . 18
	4.14. Notification Definitions . . . . . . . . . . . . . . . . . 19		4.14. Notification Definitions . . . . . . . . . . . . . . . . . 19
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 21		6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 23		8.1. Normative References . . . . . . . . . . . . . . . . . . . 23
	8.2. Informative References . . . . . . . . . . . . . . . . . . 23		8.2. Informative References . . . . . . . . . . . . . . . . . . 23
	Appendix A. Module Review Checklist . . . . . . . . . . . . . . . 24		Appendix A. Module Review Checklist . . . . . . . . . . . . . . . 25
	Appendix B. YANG Module Template . . . . . . . . . . . . . . . . 26		Appendix B. YANG Module Template . . . . . . . . . . . . . . . . 27
	Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 29		Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 30
	C.1. Changes from 07 to 08 . . . . . . . . . . . . . . . . . . 29		C.1. Changes from 08 to 09 . . . . . . . . . . . . . . . . . . 30
	C.2. Changes from 06 to 07 . . . . . . . . . . . . . . . . . . 29		C.2. Changes from 07 to 08 . . . . . . . . . . . . . . . . . . 30
	C.3. Changes from 05 to 06 . . . . . . . . . . . . . . . . . . 29		C.3. Changes from 06 to 07 . . . . . . . . . . . . . . . . . . 30
	C.4. Changes from 04 to 05 . . . . . . . . . . . . . . . . . . 29		C.4. Changes from 05 to 06 . . . . . . . . . . . . . . . . . . 30
	C.5. Changes from 03 to 04 . . . . . . . . . . . . . . . . . . 30		C.5. Changes from 04 to 05 . . . . . . . . . . . . . . . . . . 30
	C.6. Changes from 02 to 03 . . . . . . . . . . . . . . . . . . 30		C.6. Changes from 03 to 04 . . . . . . . . . . . . . . . . . . 31
	C.7. Changes from 01 to 02 . . . . . . . . . . . . . . . . . . 31		C.7. Changes from 02 to 03 . . . . . . . . . . . . . . . . . . 32
	C.8. Changes from 00 to 01 . . . . . . . . . . . . . . . . . . 31		C.8. Changes from 01 to 02 . . . . . . . . . . . . . . . . . . 32
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32		C.9. Changes from 00 to 01 . . . . . . . . . . . . . . . . . . 32
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 33
	1. Introduction		1. Introduction
	The standardization of network configuration interfaces for use with		The standardization of network configuration interfaces for use with
	the NETCONF [RFC4741] protocol requires a modular set of data models,		the Network Configuration Protocol (NETCONF) [RFC4741] requires a
	which can be reused and extended over time.		modular set of data models, which can be reused and extended over
			time.
	This document defines a set of usage guidelines for standards track		This document defines a set of usage guidelines for standards track
	documents containing YANG [I-D.ietf-netmod-yang] data models. It is		documents containing YANG [I-D.ietf-netmod-yang] data models. YANG
	similar to the SMIv2 usage guidelines specification [RFC4181] in		is used to define the data structures, protocol operations, and
	intent and structure. However, since that document was written a		notification content used within a NETCONF server. A server which
	decade after SMIv2 modules had been in use, it was published as a		supports a particular YANG module will support client NETCONF
	'best current practice' (BCP). This document is not a BCP, but		operation requests, as indicated by the specific content defined in
	rather an informational reference, intended to promote consistency in		the YANG module.
	documents containing YANG modules.
			This document is similar to the SMIv2 usage guidelines specification
			[RFC4181] in intent and structure. However, since that document was
			written a decade after SMIv2 modules had been in use, it was
			published as a 'best current practice' (BCP). This document is not a
			BCP, but rather an informational reference, intended to promote
			consistency in documents containing YANG modules.
	Many YANG constructs are defined as optional to use, such as the		Many YANG constructs are defined as optional to use, such as the
	description statement. However, in order to maximize		description statement. However, in order to maximize
	interoperability of NETCONF implementations utilizing YANG data		interoperability of NETCONF implementations utilizing YANG data
	models, it is desirable to define a set of usage guidelines which may		models, it is desirable to define a set of usage guidelines which may
	require a higher level of compliance than the minimum level defined		require a higher level of compliance than the minimum level defined
	in the YANG specification.		in the YANG specification.
	In addition, YANG allows constructs such as infinite length		In addition, YANG allows constructs such as infinite length
	identifiers and string values, or top-level mandatory nodes, that a		identifiers and string values, or top-level mandatory nodes, that a
	skipping to change at page 5, line 46		skipping to change at page 5, line 46
	o data node		o data node
	o module		o module
	o namespace		o namespace
	o submodule		o submodule
	o version		o version
			o YANG
			o YIN
	Note that the term 'module' may be used as a generic term for a YANG		Note that the term 'module' may be used as a generic term for a YANG
	module or submodule. When describing properties which are specific		module or submodule. When describing properties which are specific
	to submodules, the term 'submodule' is used instead.		to submodules, the term 'submodule' is used instead.
	2.4. Terms		2.4. Terms
	The following terms are used throughout this document:		The following terms are used throughout this document:
	published: A stable release of a module or submodule, usually		published: A stable release of a module or submodule, usually
	contained in an RFC.		contained in an RFC.
	unpublished: An unstable release of a module or submodule, usually		unpublished: An unstable release of a module or submodule, usually
	contained in an Internet-Draft.		contained in an Internet-Draft.
	3. General Documentation Guidelines		3. General Documentation Guidelines
	YANG data model modules under review are likely to be contained in		YANG data model modules under review are likely to be contained in
	Internet-Drafts. All guidelines for Internet-Draft authors MUST be		Internet-Drafts. All guidelines for Internet-Draft authors MUST be
	followed. These guidelines are available online at:		followed. These guidelines are defined in [RFC2223] and updated in
			[RFC5741]. Additional information is also available online at:
	http://www.rfc-editor.org/rfc-editor/instructions2authors.txt		http://www.rfc-editor.org/rfc-editor/instructions2authors.txt
	The following sections MUST be present in an Internet-Draft		The following sections MUST be present in an Internet-Draft
	containing a module:		containing a module:
	o Narrative sections		o Narrative sections
	o Definitions section		o Definitions section
	skipping to change at page 9, line 19		skipping to change at page 9, line 19
	o Writable data nodes that could be especially disruptive if abused		o Writable data nodes that could be especially disruptive if abused
	MUST be explicitly listed by name and the associated security		MUST be explicitly listed by name and the associated security
	risks MUST be explained.		risks MUST be explained.
	o Readable data nodes that contain especially sensitive information		o Readable data nodes that contain especially sensitive information
	or that raise significant privacy concerns MUST be explicitly		or that raise significant privacy concerns MUST be explicitly
	listed by name and the reasons for the sensitivity/privacy		listed by name and the reasons for the sensitivity/privacy
	concerns MUST be explained.		concerns MUST be explained.
	o Operations (i.e., 'rpc' statements) which are potentially harmful		o Operations (i.e., YANG 'rpc' statements) which are potentially
	to system behavior or that raise significant privacy concerns MUST		harmful to system behavior or that raise significant privacy
	be explicitly listed by name and the reasons for the sensitivity/		concerns MUST be explicitly listed by name and the reasons for the
	privacy concerns MUST be explained.		sensitivity/privacy concerns MUST be explained.
	3.5. IANA Considerations Section		3.5. IANA Considerations Section
	In order to comply with IESG policy as set forth in		In order to comply with IESG policy as set forth in
	http://www.ietf.org/ID-Checklist.html, every Internet-Draft that is		http://www.ietf.org/ID-Checklist.html, every Internet-Draft that is
	submitted to the IESG for publication which has action items for IANA		submitted to the IESG for publication which has action items for IANA
	MUST contain an IANA Considerations section. The requirements for		MUST contain an IANA Considerations section. The requirements for
	this section vary depending what actions are required of the IANA.		this section vary depending what actions are required of the IANA.
	If there are no IANA considerations applicable to the document, then		If there are no IANA considerations applicable to the document, then
	the IANA Considerations section is not required. Refer to the		the IANA Considerations section is not required. Refer to the
	skipping to change at page 9, line 45		skipping to change at page 9, line 45
	3.5.1. Documents that Create a New Name Space		3.5.1. Documents that Create a New Name Space
	If an Internet-Draft defines a new name space that is to be		If an Internet-Draft defines a new name space that is to be
	administered by the IANA, then the document MUST include an IANA		administered by the IANA, then the document MUST include an IANA
	Considerations section, that specifies how the name space is to be		Considerations section, that specifies how the name space is to be
	administered.		administered.
	Specifically, if any YANG module namespace statement value contained		Specifically, if any YANG module namespace statement value contained
	in the document is not already registered with IANA, then a new YANG		in the document is not already registered with IANA, then a new YANG
	Namespace registry entry MUST be requested from the IANA. The YANG		Namespace registry entry MUST be requested from the IANA. The YANG
	specification includes the procedure for this purpose in its IANA		[I-D.ietf-netmod-yang] specification includes the procedure for this
	Considerations section.		purpose in its IANA Considerations section.
	3.5.2. Documents that Extend an Existing Name Space		3.5.2. Documents that Extend an Existing Name Space
	It is possible to extend an existing namespace using a YANG submodule		It is possible to extend an existing namespace using a YANG submodule
	which belongs to an existing module already administered by IANA. In		which belongs to an existing module already administered by IANA. In
	this case, the document containing the main module MUST be updated to		this case, the document containing the main module MUST be updated to
	use the latest revision of the submodule.		use the latest revision of the submodule.
	3.6. Reference Sections		3.6. Reference Sections
	skipping to change at page 11, line 31		skipping to change at page 11, line 31
	Modules contained in standards track documents SHOULD be named		Modules contained in standards track documents SHOULD be named
	according to the guidelines in the IANA considerations section of		according to the guidelines in the IANA considerations section of
	[I-D.ietf-netmod-yang].		[I-D.ietf-netmod-yang].
	A distinctive word or acronym (e.g., protocol name or working group		A distinctive word or acronym (e.g., protocol name or working group
	acronym) SHOULD be used in the module name. If new definitions are		acronym) SHOULD be used in the module name. If new definitions are
	being defined to extend one or more existing modules, then the same		being defined to extend one or more existing modules, then the same
	word or acronym should be reused, instead of creating a new one.		word or acronym should be reused, instead of creating a new one.
	All published module names MUST be unique.		All published module names MUST be unique. For a YANG module
			published in an RFC, this uniqueness is guaranteed by IANA. For
			unpublished modules, the authors need to check that no other work in
			progress is using the same module name.
	Once a module name is published, it MUST NOT be reused, even if the		Once a module name is published, it MUST NOT be reused, even if the
	RFC containing the module is reclassified to 'Historic' status.		RFC containing the module is reclassified to 'Historic' status.
	4.2. Identifiers		4.2. Identifiers
	Identifiers for all YANG identifiers in published modules MUST be		Identifiers for all YANG identifiers in published modules MUST be
	between 1 and 64 characters in length. These include any construct		between 1 and 64 characters in length. These include any construct
	specified as an 'identifier-arg-str' token in the ABNF in section 12		specified as an 'identifier-arg-str' token in the ABNF in section 12
	of [I-D.ietf-netmod-yang].		of [I-D.ietf-netmod-yang].
	skipping to change at page 12, line 33		skipping to change at page 12, line 33
	4.4. Conditional Statements		4.4. Conditional Statements
	A module may be conceptually partitioned in several ways, using the		A module may be conceptually partitioned in several ways, using the
	'if-feature' and/or 'when' statements.		'if-feature' and/or 'when' statements.
	Data model designers need to carefully consider all modularity		Data model designers need to carefully consider all modularity
	aspects, including the use of YANG conditional statements.		aspects, including the use of YANG conditional statements.
	If a data definition is optional, depending on server support for a		If a data definition is optional, depending on server support for a
	NETCONF protocol capability, then a YANG 'feature' statement SHOULD		NETCONF protocol capability, then a YANG 'feature' statement SHOULD
	be defined to indicate the NETCONF capability is supported within the		be defined to indicate that the NETCONF capability is supported
	data model.		within the data model.
	4.5. XPath Usage		4.5. XPath Usage
	This section describes guidelines for using the XML Path Language		This section describes guidelines for using the XML Path Language
	[W3C.REC-xpath-19991116] (XPath) within YANG modules.		[W3C.REC-xpath-19991116] (XPath) within YANG modules.
	The 'attribute' and 'namespace' axes are not supported in YANG, and		The 'attribute' and 'namespace' axes are not supported in YANG, and
	MAY be empty in a NETCONF server implementation.		MAY be empty in a NETCONF server implementation.
	The 'position' and 'last' functions MAY be used with caution. A		The 'position' and 'last' functions MAY be used with caution. A
	server is not required to maintain any particular XML document order		server is not required to maintain any particular XML document order
	for system-ordered data nodes. A server is only required to maintain		for system-ordered data nodes. A server is only required to maintain
	the relative XML document order of all instances of a particular		the relative XML document order of all instances of a particular
	user-ordered list or leaf-list.		user-ordered list or leaf-list.
	The 'preceding', and 'following' axes SHOULD NOT be used. These		The 'preceding', and 'following' axes SHOULD NOT be used. These
	constructs rely on XML document order within a NETCONF server		constructs rely on XML document order within a NETCONF server
	configuration database, which may not be supported consistently or		configuration database, which may not be supported consistently or
	produce reliable results across implementations. Predicate		produce reliable results across implementations. Predicate
	expressions based on static node properties (e.g., name, value,		expressions based on static node properties (e.g., element name or
	ancestors, descendants) SHOULD be used instead.		value, 'ancestor' or 'descendant' axes) SHOULD be used instead.
	The 'preceding-sibling' and 'following-sibling' axes MAY be used,		The 'preceding-sibling' and 'following-sibling' axes MAY be used,
	with caution. A server is not required to maintain a persistent or		with caution. A server is not required to maintain a persistent or
	deterministic XML document order, which will affect use of these		deterministic XML document order, which will affect use of these
	axes.		axes.
	Implicit 'position' function calls within predicates MAY be used with		Implicit 'position' function calls within predicates MAY be used with
	caution. (e.g., //chapter[42]). Note that a NETCONF server is only		caution. (e.g., '//chapter[42]'). Note that a NETCONF server is only
	required to maintain relative document order for related instances of		required to maintain relative document order for related instances of
	a user-ordered list or leaf-list data definition (i.e., 'ordered-by'		a user-ordered list or leaf-list data definition (i.e., 'ordered-by'
	statement set to 'user').		statement set to 'user').
	Data nodes which use the 'int64' and 'uint64' built-in type MAY be		Data nodes which use the 'int64' and 'uint64' built-in type MAY be
	used with caution, within relational expressions. There are boundary		used with caution, within 'RelationalExpr' expressions. There are
	conditions in which the translation from the YANG 64-bit type to an		boundary conditions in which the translation from the YANG 64-bit
	XPath number can cause incorrect results. Specifically, an XPath		type to an XPath number can cause incorrect results. Specifically,
	double precision floating point number cannot represent very large		an XPath 'double' precision floating point number cannot represent
	positive or negative 64-bit numbers because it only provides a total		very large positive or negative 64-bit numbers because it only
	precision of 53 bits.		provides a total precision of 53 bits.
	Data modelers need to be careful not to confuse the YANG value space		Data modelers need to be careful not to confuse the YANG value space
	and the XPath value space. The data types are not the same in both,		and the XPath value space. The data types are not the same in both,
	and conversion between YANG and XPath data types SHOULD be considered		and conversion between YANG and XPath data types SHOULD be considered
	carefully.		carefully.
	Explicit XPath data type conversions MAY be used (e.g., 'string',		Explicit XPath data type conversions MAY be used (e.g., 'string',
	'boolean', or 'number' functions), instead of implicit XPath data		'boolean', or 'number' functions), instead of implicit XPath data
	type conversions.		type conversions.
	skipping to change at page 14, line 16		skipping to change at page 14, line 16
	MUST be updated so that the main module revision date is equal or		MUST be updated so that the main module revision date is equal or
	more recent than the revision date of any submodule which is		more recent than the revision date of any submodule which is
	(directly or indirectly) included by the main module.		(directly or indirectly) included by the main module.
	4.7. Module Header, Meta, and Revision Statements		4.7. Module Header, Meta, and Revision Statements
	For published modules, the namespace MUST be a globally unique URI,		For published modules, the namespace MUST be a globally unique URI,
	as defined in [RFC3986]. This value is usually assigned by the IANA.		as defined in [RFC3986]. This value is usually assigned by the IANA.
	The organization statement MUST be present. If the module is		The organization statement MUST be present. If the module is
	contained in a documented intended for standards-track status, then		contained in a document intended for standards-track status, then the
	the organization SHOULD be the IETF working group chartered to write		organization SHOULD be the IETF working group chartered to write the
	the document.		document.
	The contact statement MUST be present. If the module is contained in		The contact statement MUST be present. If the module is contained in
	a document intended for standards-track status, then the working		a document intended for standards-track status, then the working
	group WEB and mailing information MUST be present, and the main		group WEB and mailing information MUST be present, and the main
	document author or editor contact information SHOULD be present. If		document author or editor contact information SHOULD be present. If
	additional authors or editors exist, their contact information MAY be		additional authors or editors exist, their contact information MAY be
	present. In addition, the Area Director and other contact		present. In addition, the Area Director and other contact
	information MAY be present.		information MAY be present.
	The description statement MUST be present. The appropriate IETF		The description statement MUST be present. The appropriate IETF
	skipping to change at page 16, line 38		skipping to change at page 16, line 38
	4.10. Data Types		4.10. Data Types
	Selection of an appropriate data type (i.e., built-in type, existing		Selection of an appropriate data type (i.e., built-in type, existing
	derived type, or new derived type) is very subjective and therefore		derived type, or new derived type) is very subjective and therefore
	few requirements can be specified on that subject.		few requirements can be specified on that subject.
	Data model designers SHOULD use the most appropriate built-in data		Data model designers SHOULD use the most appropriate built-in data
	type for the particular application.		type for the particular application.
	If extensibility of enumerated values is required, then the		If extensibility of enumerated values is required, then the
	identityref data type SHOULD be used instead of an enumeration or		'identityref' data type SHOULD be used instead of an enumeration or
	other built-in type.		other built-in type.
	For string data types, if a machine-readable pattern can be defined		For string data types, if a machine-readable pattern can be defined
	for the desired semantics, then one or more pattern statements SHOULD		for the desired semantics, then one or more pattern statements SHOULD
	be present.		be present.
	For string data types, if the length of the string is required to be		For string data types, if the length of the string is required to be
	bounded in all implementations, then a length statement MUST be		bounded in all implementations, then a length statement MUST be
	present.		present.
	For numeric data types, if the values allowed by the intended		For numeric data types, if the values allowed by the intended
	semantics are different than those allowed by the unbounded intrinsic		semantics are different than those allowed by the unbounded intrinsic
	data type (e.g., int32), then a range statement SHOULD be present.		data type (e.g., 'int32'), then a range statement SHOULD be present.
	The signed numeric data types (i.e., 'int8', 'int16', 'int32', and		The signed numeric data types (i.e., 'int8', 'int16', 'int32', and
	'int64') SHOULD NOT be used unless negative values are allowed for		'int64') SHOULD NOT be used unless negative values are allowed for
	the desired semantics.		the desired semantics.
	For enumeration or bits data types, the semantics for each enum or		For 'enumeration' or 'bits' data types, the semantics for each 'enum'
	bit SHOULD be documented. A separate description statement (within		or 'bit' SHOULD be documented. A separate description statement
	each enum or bit statement) SHOULD be present.		(within each 'enum' or 'bit' statement) SHOULD be present.
	4.11. Reusable Type Definitions		4.11. Reusable Type Definitions
	If an appropriate derived type exists in any standard module, such as		If an appropriate derived type exists in any standard module, such as
	[I-D.ietf-netmod-yang-types], then it SHOULD be used instead of		[I-D.ietf-netmod-yang-types], then it SHOULD be used instead of
	defining a new derived type.		defining a new derived type.
	If an appropriate units identifier can be associated with the desired		If an appropriate units identifier can be associated with the desired
	semantics, then a units statement SHOULD be present.		semantics, then a units statement SHOULD be present.
	skipping to change at page 23, line 12		skipping to change at page 23, line 12
	The working group thanks Martin Bjorklund and Juergen Schoenwaelder		The working group thanks Martin Bjorklund and Juergen Schoenwaelder
	for their extensive reviews and contributions to this document.		for their extensive reviews and contributions to this document.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[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, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
			[RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors",
			RFC 2223, October 1997.
	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	January 2004.		January 2004.
	[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifier (URI): Generic Syntax", STD 66,		Resource Identifier (URI): Generic Syntax", STD 66,
	RFC 3986, January 2005.		RFC 3986, January 2005.
	[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741,		[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
	December 2006.		December 2006.
	[RFC5378] Bradner, S. and J. Contreras, "Rights Contributors Provide		[RFC5378] Bradner, S. and J. Contreras, "Rights Contributors Provide
	to the IETF Trust", BCP 78, RFC 5378, November 2008.		to the IETF Trust", BCP 78, RFC 5378, November 2008.
			[RFC5741] Daigle, L., Kolkman, O., and IAB, "RFC Streams, Headers,
			and Boilerplates", RFC 5741, December 2009.
	[W3C.REC-xpath-19991116]		[W3C.REC-xpath-19991116]
	DeRose, S. and J. Clark, "XML Path Language (XPath)		DeRose, S. and J. Clark, "XML Path Language (XPath)
	Version 1.0", World Wide Web Consortium		Version 1.0", World Wide Web Consortium
	Recommendation REC-xpath-19991116, November 1999,		Recommendation REC-xpath-19991116, November 1999,
	<http://www.w3.org/TR/1999/REC-xpath-19991116>.		<http://www.w3.org/TR/1999/REC-xpath-19991116>.
	[I-D.ietf-netmod-yang]		[I-D.ietf-netmod-yang]
	Bjorklund, M., "YANG - A data modeling language for the		Bjorklund, M., "YANG - A data modeling language for the
	Network Configuration Protocol (NETCONF)",		Network Configuration Protocol (NETCONF)",
	draft-ietf-netmod-yang-13 (work in progress), June 2010.		draft-ietf-netmod-yang-13 (work in progress), June 2010.
	skipping to change at page 29, line 7		skipping to change at page 30, line 7
	// DO NOT put deviation statements in a published module		// DO NOT put deviation statements in a published module
	}		}
	<CODE ENDS>		<CODE ENDS>
	Figure 2		Figure 2
	Appendix C. Change Log		Appendix C. Change Log
	C.1. Changes from 07 to 08		C.1. Changes from 08 to 09
			o Clarifications and corrections to address Gen-ART review comments.
			C.2. Changes from 07 to 08
	o Corrected YANG security considerations URL.		o Corrected YANG security considerations URL.
	o Expanded 'CODE BEGINS' example.		o Expanded 'CODE BEGINS' example.
	o Added RPC operations to the security considerations guidelines		o Added RPC operations to the security considerations guidelines
	section.		section.
	o Removed guideline about leading and trailing whitespace.		o Removed guideline about leading and trailing whitespace.
	C.2. Changes from 06 to 07		C.3. Changes from 06 to 07
	o Corrected title change bug; supposed to be page header instead.		o Corrected title change bug; supposed to be page header instead.
	o Fixed typos added to last revision.		o Fixed typos added to last revision.
	o Added sentence to checklist to make sure text outside module		o Added sentence to checklist to make sure text outside module
	contains citations for imports.		contains citations for imports.
	C.3. Changes from 05 to 06		C.4. Changes from 05 to 06
	o Several clarifications and corrections, based on the AD review by		o Several clarifications and corrections, based on the AD review by
	Dan Romascanu.		Dan Romascanu.
	C.4. Changes from 04 to 05		C.5. Changes from 04 to 05
	o Changed 'object' terminology to 'data definition'.		o Changed 'object' terminology to 'data definition'.
	o Put XPath guidelines in separate section.		o Put XPath guidelines in separate section.
	o Clarified XPath usage for XML document order dependencies.		o Clarified XPath usage for XML document order dependencies.
	o Updated <CODE BEGINS> guidelines to current conventions.		o Updated <CODE BEGINS> guidelines to current conventions.
	o Added informative reference for IANA considerations guidelines and		o Added informative reference for IANA considerations guidelines and
	XML registry.		XML registry.
	o Updated IANA Considerations section to reserve the ietf-template		o Updated IANA Considerations section to reserve the ietf-template
	module in the YANG Module Name Registry so it cannot be reused		module in the YANG Module Name Registry so it cannot be reused
	accidently.		accidently.
	o Many other clarifications and fixed typos found in WGLC reviews.		o Many other clarifications and fixed typos found in WGLC reviews.
	C.5. Changes from 03 to 04		C.6. Changes from 03 to 04
	o Removed figure 1 to reduce duplication, just refer to 4741bis		o Removed figure 1 to reduce duplication, just refer to 4741bis
	draft.		draft.
	o Fixed bugs and typos found in WGLC reviews.		o Fixed bugs and typos found in WGLC reviews.
	o Removed some guidelines and referring to YANG draft instead of		o Removed some guidelines and referring to YANG draft instead of
	duplicating YANG rules here.		duplicating YANG rules here.
	o Changed security guidelines so they refer to the IETF Trust TLP		o Changed security guidelines so they refer to the IETF Trust TLP
	skipping to change at page 30, line 48		skipping to change at page 32, line 5
	o Added guideline that strings should not rely on preservation of		o Added guideline that strings should not rely on preservation of
	leading and trailing whitespace characters.		leading and trailing whitespace characters.
	o Relaxed some XPath and anyxml guidelines from SHOULD NOT or MUST		o Relaxed some XPath and anyxml guidelines from SHOULD NOT or MUST
	NOT to MAY use with caution.		NOT to MAY use with caution.
	o Updated the TLP text within the example module again.		o Updated the TLP text within the example module again.
	o Reversed order of change log so most recent entries are first.		o Reversed order of change log so most recent entries are first.
	C.6. Changes from 02 to 03		C.7. Changes from 02 to 03
	o Updated figure 1 to align with 4741bis draft.		o Updated figure 1 to align with 4741bis draft.
	o Updated guidelines for import-by-revision and include-by-revision.		o Updated guidelines for import-by-revision and include-by-revision.
	o Added file name to code begins convention in ietf-template module.		o Added file name to code begins convention in ietf-template module.
	C.7. Changes from 01 to 02		C.8. Changes from 01 to 02
	o Updated figure 1 per mailing list comments.		o Updated figure 1 per mailing list comments.
	o Updated suggested organization to include the working group name.		o Updated suggested organization to include the working group name.
	o Updated ietf-template.yang to use new organization statement		o Updated ietf-template.yang to use new organization statement
	value.		value.
	o Updated Code Component requirements as per new TLP.		o Updated Code Component requirements as per new TLP.
	o Updated ietf-template.yang to use new Code Component begin and end		o Updated ietf-template.yang to use new Code Component begin and end
	markers.		markers.
	o Updated references to the TLP in a couple sections.		o Updated references to the TLP in a couple sections.
	o Change manager/agent terminology to client/server.		o Change manager/agent terminology to client/server.
	C.8. Changes from 00 to 01		C.9. Changes from 00 to 01
	o Added transport 'TLS' to figure 1.		o Added transport 'TLS' to figure 1.
	o Added note about RFC 2119 terminology.		o Added note about RFC 2119 terminology.
	o Corrected URL for instructions to authors.		o Corrected URL for instructions to authors.
	o Updated namespace procedures section.		o Updated namespace procedures section.
	o Updated guidelines on module contact, reference, and organization		o Updated guidelines on module contact, reference, and organization
End of changes. 30 change blocks.
	62 lines changed or deleted		89 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/