draft-ietf-netmod-yang-usage-01.txt		draft-ietf-netmod-yang-usage-02.txt
	Internet Engineering Task Force A. Bierman		Internet Engineering Task Force A. Bierman
	Internet-Draft Netconf Central		Internet-Draft Netconf Central, Inc.
	Intended status: Informational August 12, 2009		Intended status: Informational October 26, 2009
	Expires: February 13, 2010		Expires: April 29, 2010
	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-01		draft-ietf-netmod-yang-usage-02
	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), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 32		skipping to change at page 1, line 32
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on February 13, 2010.		This Internet-Draft will expire on April 29, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 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 in effect on the date of		Provisions Relating to IETF Documents in effect on the date of
	publication of this document (http://trustee.ietf.org/license-info).		publication of this document (http://trustee.ietf.org/license-info).
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 3, line 20		skipping to change at page 3, line 20
	2.2. NETCONF Terms . . . . . . . . . . . . . . . . . . . . . . 5		2.2. NETCONF Terms . . . . . . . . . . . . . . . . . . . . . . 5
	2.3. YANG Terms . . . . . . . . . . . . . . . . . . . . . . . . 5		2.3. YANG Terms . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.4. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 6		2.4. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3. General Documentation Guidelines . . . . . . . . . . . . . . . 7		3. General Documentation Guidelines . . . . . . . . . . . . . . . 7
	3.1. YANG Data Model Boilerplate Section . . . . . . . . . . . 7		3.1. YANG Data Model Boilerplate Section . . . . . . . . . . . 7
	3.2. Narrative Sections . . . . . . . . . . . . . . . . . . . . 7		3.2. Narrative Sections . . . . . . . . . . . . . . . . . . . . 7
	3.3. Definitions Section . . . . . . . . . . . . . . . . . . . 8		3.3. Definitions Section . . . . . . . . . . . . . . . . . . . 8
	3.4. Security Considerations Section . . . . . . . . . . . . . 8		3.4. Security Considerations Section . . . . . . . . . . . . . 8
	3.5. IANA Considerations Section . . . . . . . . . . . . . . . 8		3.5. IANA Considerations Section . . . . . . . . . . . . . . . 8
	3.5.1. Documents that Create a New Name Space . . . . . . . . 8		3.5.1. Documents that Create a New Name Space . . . . . . . . 8
	3.5.2. Documents that Extend an Existing Name Space . . . . . 8		3.5.2. Documents that Extend an Existing Name Space . . . . . 9
	3.6. Reference Sections . . . . . . . . . . . . . . . . . . . . 9		3.6. Reference Sections . . . . . . . . . . . . . . . . . . . . 9
	3.7. Copyright Notices . . . . . . . . . . . . . . . . . . . . 9		3.7. Copyright Notices . . . . . . . . . . . . . . . . . . . . 9
	3.8. Intellectual Property Section . . . . . . . . . . . . . . 9		3.8. Intellectual Property Section . . . . . . . . . . . . . . 9
	4. YANG Usage Guidelines . . . . . . . . . . . . . . . . . . . . 10		4. YANG Usage Guidelines . . . . . . . . . . . . . . . . . . . . 10
	4.1. Module Naming Conventions . . . . . . . . . . . . . . . . 10		4.1. Module Naming Conventions . . . . . . . . . . . . . . . . 10
	4.2. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 10		4.2. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 10
	4.3. Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 10		4.3. Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 10
	4.4. Conditional Statements . . . . . . . . . . . . . . . . . . 11		4.4. Conditional Statements . . . . . . . . . . . . . . . . . . 11
	4.5. Lifecycle Management . . . . . . . . . . . . . . . . . . . 12		4.5. Lifecycle Management . . . . . . . . . . . . . . . . . . . 12
	4.6. Header Contents . . . . . . . . . . . . . . . . . . . . . 12		4.6. Header Contents . . . . . . . . . . . . . . . . . . . . . 12
	skipping to change at page 3, line 48		skipping to change at page 3, line 48
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 19		6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 21		8.1. Normative References . . . . . . . . . . . . . . . . . . . 21
	8.2. Informative References . . . . . . . . . . . . . . . . . . 21		8.2. Informative References . . . . . . . . . . . . . . . . . . 21
	Appendix A. Module Review Checklist . . . . . . . . . . . . . . . 22		Appendix A. Module Review Checklist . . . . . . . . . . . . . . . 22
	Appendix B. YANG Module Template . . . . . . . . . . . . . . . . 24		Appendix B. YANG Module Template . . . . . . . . . . . . . . . . 24
	Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 27		Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 27
	C.1. Changes from 00 to 01 . . . . . . . . . . . . . . . . . . 27		C.1. Changes from 00 to 01 . . . . . . . . . . . . . . . . . . 27
			C.2. Changes from 01 to 02 . . . . . . . . . . . . . . . . . . 27
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28
	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 NETCONF [RFC4741] protocol requires a modular set of data models,
	which can be reused and extended over time.		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. It is
	similar to the MIB usage guidelines specification [RFC4181] in intent		similar to the MIB usage guidelines specification [RFC4181] in intent
	and structure.		and structure.
	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 clause. However, in order to maximize interoperability		description clause. However, in order to maximize interoperability
	of NETCONF implementations utilizing YANG data models, it is		of NETCONF implementations utilizing YANG data models, it is
	desirable to define a set of usage guidelines which may require a		desirable to define a set of usage guidelines which may require a
	higher level of compliance than the minimum level defined in the YANG		higher level of compliance than the minimum level defined in the YANG
	specification.		specification.
	The NETCONF stack can be conceptually partitioned into four layers.		The NETCONF stack can be conceptually partitioned into four layers.
	Layer Example		Layer Example
	+-------------+ +--------------------+ +-------------------+		+-------------+ +--------------------+ +-------------------+
	(4) | Content | | Configuration data | | Notification data |		(4) | Content | | Configuration data | | Notification data |
	+-------------+ +--------------------+ +-------------------+		+-------------+ +--------------------+ +-------------------+
	| | |		| | |
	+-------------+ +-----------------+ +---------------+		+-------------+ +-----------------+ +---------------+
	(3) | Operations | | <edit-config> | | <eventType> |		(3) | Operations | | <edit-config> | | <eventType> |
	+-------------+ +-----------------+ +---------------+		+-------------+ +-----------------+ +---------------+
	| | |		| | |
	+-------------+ +--------------------+ +----------------+		+-------------+ +--------------------+ +----------------+
	(2) | RPC | | <rpc>, <rpc-reply> | | <notification> |		(2) | Messages | | <rpc>, <rpc-reply> | | <notification> |
	+-------------+ +--------------------+ +----------------+		+-------------+ +--------------------+ +----------------+
	| | |		| | |
	+-------------+ +--------------------------------+		+-------------+ +-----------------------------------------------+
	(1) | Transport | | BEEP, SSH, SSL, TLS, console |		(1) | Secure | | SSH, TLS, BEEP/TLS, SOAP/BEEP, SOAP/HTTPS ... |
	| Protocol | | |		| Transports | | |
	+-------------+ +--------------------------------+		+-------------+ +-----------------------------------------------+
	Figure 1		Figure 1
	This document defines usage guidelines related to the NETCONF		This document defines usage guidelines related to the NETCONF
	operations layer (3), and NETCONF content layer (4).		operations layer (3), and NETCONF content layer (4).
	2. Terminology		2. Terminology
	2.1. Requirements Notation		2.1. Requirements Notation
	skipping to change at page 5, line 23		skipping to change at page 5, line 23
	RFC 2119 language is used here to express the views of the NETMOD		RFC 2119 language is used here to express the views of the NETMOD
	working group regarding YANG module content. Yang modules complying		working group regarding YANG module content. Yang modules complying
	with this document will treat the RFC 2119 terminology as if it were		with this document will treat the RFC 2119 terminology as if it were
	describing best current practices.		describing best current practices.
	2.2. NETCONF Terms		2.2. NETCONF Terms
	The following terms are defined in [RFC4741] and are not redefined		The following terms are defined in [RFC4741] and are not redefined
	here:		here:
	o agent
	o application		o application
	o capabilities		o capabilities
	o manager		o client
	o operation		o operation
	o RPC		o RPC
			o server
	2.3. YANG Terms		2.3. YANG Terms
	The following terms are defined in [I-D.ietf-netmod-yang] and are not		The following terms are defined in [I-D.ietf-netmod-yang] and are not
	redefined here:		redefined here:
	o data node		o data node
	o module		o module
	o submodule		o submodule
	skipping to change at page 7, line 32		skipping to change at page 7, line 31
	o Security Considerations section		o Security Considerations section
	o IANA Considerations section		o IANA Considerations section
	o References section		o References section
	3.1. YANG Data Model Boilerplate Section		3.1. YANG Data Model Boilerplate Section
	This section MUST contain a verbatim copy of the latest approved		This section MUST contain a verbatim copy of the latest approved
	Internet-Standard Management Framework boilerplate, which is		Internet-Standard Management Framework boilerplate, which is
	available on-line at [ed: URL TBD].		available on-line, in section 4 of the Trust Legal Provisions (TLP)
			document, at: http://trustee.ietf.org/license-info/
			Each YANG module contained within an Internet Draft or RPC MUST be
			identified as a 'Code Component'. The strings '<CODE BEGINS>' and
			'<CODE ENDS>' SHOULD be used to identify each Code Component.
	3.2. Narrative Sections		3.2. Narrative Sections
	The narrative part MUST include an overview section that describes		The narrative part MUST include an overview section that describes
	the scope and field of application of the module(s) defined by the		the scope and field of application of the module(s) defined by the
	specification and that specifies the relationship (if any) of these		specification and that specifies the relationship (if any) of these
	modules to other standards, particularly to standards containing		modules to other standards, particularly to standards containing
	other module modules. The narrative part SHOULD include one or more		other module modules. The narrative part SHOULD include one or more
	sections to briefly describe the structure of the modules defined in		sections to briefly describe the structure of the modules defined in
	the specification.		the specification.
	skipping to change at page 9, line 14		skipping to change at page 9, line 20
	is to be administered.		is to be administered.
	Specifically, if any YANG submodule belongs-to value contained in the		Specifically, if any YANG submodule belongs-to value contained in the
	document is associated with a module that contains a namespace		document is associated with a module that contains a namespace
	statement value equal to a YANG Namespace already administered by the		statement value equal to a YANG Namespace already administered by the
	IANA, then the existing YANG Namespace must be updated to include the		IANA, then the existing YANG Namespace must be updated to include the
	new submodule.		new submodule.
	3.6. Reference Sections		3.6. Reference Sections
	[ed: 2223bis text TBD]
	For every import or include statement which appears in a module		For every import or include statement which appears in a module
	contained in the specification, which identifies a module in a		contained in the specification, which identifies a module in a
	separate document, a corresponding normative reference to that		separate document, a corresponding normative reference to that
	document MUST appear in the Normative References section. The		document MUST appear in the Normative References section. The
	reference MUST correspond to the specific module version actually		reference MUST correspond to the specific module version actually
	used within the specification.		used within the specification.
	For every reference statement which appears in a module contained in		For every reference statement which appears in a module contained in
	the specification, which identifies a separate document, a		the specification, which identifies a separate document, a
	corresponding normative reference to that document SHOULD appear in		corresponding normative reference to that document SHOULD appear in
	the Normative References section. The reference SHOULD correspond to		the Normative References section. The reference SHOULD correspond to
	the specific document version actually used within the specification.		the specific document version actually used within the specification.
	3.7. Copyright Notices		3.7. Copyright Notices
	The proper copyright notices MUST be present in the module		The proper copyright notices MUST be present in the module
	description statement. [ed.: See RFC 4181, 3.7. Exact text for		description statement. Refer to the IETF Trust Legal Provision for
	insertion is TBD.]		the exact legal text that needs to be included.
	3.8. Intellectual Property Section		3.8. Intellectual Property Section
	The proper IPR statements MUST be present in the document, according		The proper IPR statements MUST be present in the document, according
	to the most current Internet Draft boilerplate. [ed.: actual IETF IPR		to the most current Internet Draft boilerplate. Refer to the IETF
	text reference TBD]		Trust Legal Provision for the exact legal text that needs to be
			included.
	4. YANG Usage Guidelines		4. YANG Usage Guidelines
	In general, modules in IETF standards-track specifications MUST		In general, modules in IETF standards-track specifications MUST
	comply with all syntactic and semantic requirements of YANG.		comply with all syntactic and semantic requirements of YANG.
	[I-D.ietf-netmod-yang]. The guidelines in this section are intended		[I-D.ietf-netmod-yang]. The guidelines in this section are intended
	to supplement the YANG specification, which is intended to define a		to supplement the YANG specification, which is intended to define a
	minimum set of conformance requirements.		minimum set of conformance requirements.
	In order to promote interoperability and establish a set of practices		In order to promote interoperability and establish a set of practices
	skipping to change at page 11, line 31		skipping to change at page 11, line 31
	an 'if-feature' statement SHOULD be used instead of a 'when'		an 'if-feature' statement SHOULD be used instead of a 'when'
	statement.		statement.
	All 'must' and 'when' statements MUST contain valid XPath. If any		All 'must' and 'when' statements MUST contain valid XPath. If any
	name tests are present, they MUST contain valid module prefixes and		name tests are present, they MUST contain valid module prefixes and
	data node names. References to non-existent nodes are considered		data node names. References to non-existent nodes are considered
	invalid in YANG, even though they are permitted in XPath.		invalid in YANG, even though they are permitted in XPath.
	The 'attribute' and 'namespace' axis SHOULD NOT be used because the		The 'attribute' and 'namespace' axis SHOULD NOT be used because the
	associated XML node types are not supported in YANG, and may not be		associated XML node types are not supported in YANG, and may not be
	supported consistently across NETCONF agent implementations.		supported consistently across NETCONF server implementations.
	The 'position' and 'last' functions SHOULD NOT be used. Also, the		The 'position' and 'last' functions SHOULD NOT be used. Also, the
	'preceding', and 'following' axes SHOULD NOT be used. These		'preceding', and 'following' axes SHOULD NOT be used. These
	constructs rely on XML document order within a NETCONF agent		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., name, value,
	ancestors, descendants) SHOULD be used instead.		ancestors, descendants) 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. An agent 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 SHOULD NOT be		Implicit 'position' function calls within predicates SHOULD NOT be
	used. (e.g., //chapter[42]).		used. (e.g., //chapter[42]).
	Data nodes which use the 'int64' and 'uint64' built-in type SHOULD		Data nodes which use the 'int64' and 'uint64' built-in type SHOULD
	NOT be used within relational expressions. There are boundary		NOT be used within relational expressions. There are boundary
	conditions in which the translation from the YANG 64-bit type to an		conditions in which the translation from the YANG 64-bit type to an
	XPath number can cause incorrect results.		XPath number can cause incorrect results.
	skipping to change at page 12, line 40		skipping to change at page 12, line 40
	present. It SHOULD be present (in all published modules) if any		present. It SHOULD be present (in all published modules) if any
	groupings are used from the external sub-module.		groupings are used from the external sub-module.
	4.6. Header Contents		4.6. Header Contents
	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 documented intended for standards-track status, then
	the organization SHOULD be the IETF.		the organization SHOULD be the IETF working group chartered to write
			the 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 documented intended for standards-track status, then the working		a documented intended for standards-track status, then the working
	group WEB and mailing information MUST be present, and the document		group WEB and mailing information MUST be present, and the document
	author contact information SHOULD be present. In addition, the Area		author contact information SHOULD be present. In addition, the Area
	Director and other contact information MAY be present.		Director and other contact information MAY be present.
	The description statement MUST be present. If the module is		The description statement MUST be present. If the module is
	contained in an unpublished document, then the file name of this		contained in an unpublished document, then the file name of this
	document SHOULD be identified in the description statement. This		document SHOULD be identified in the description statement. This
	skipping to change at page 14, line 36		skipping to change at page 14, line 36
	module. However, there MAY be more than one if needed.		module. However, there MAY be more than one if needed.
	The top-level data organization SHOULD be considered carefully, in		The top-level data organization SHOULD be considered carefully, in
	advance. Data model designers need to consider how the functionality		advance. Data model designers need to consider how the functionality
	for a given protocol or protocol family will grow over time.		for a given protocol or protocol family will grow over time.
	The names and data organization SHOULD reflect persistent		The names and data organization SHOULD reflect persistent
	information, such as the name of a protocol. The name of the working		information, such as the name of a protocol. The name of the working
	group SHOULD NOT be used because this may change over time.		group SHOULD NOT be used because this may change over time.
	A mandatory database object is defined as a node that a manager must		A mandatory database object is defined as a node that a client must
	provide for the database to be valid. The agent will not provide a		provide for the database to be valid. The server will not provide a
	value under any conditions.		value under any conditions.
	Top-level database objects MUST NOT be mandatory.		Top-level database objects MUST NOT be mandatory.
	If a mandatory node appears at the top-level, it will immediately		If a mandatory node appears at the top-level, it will immediately
	cause the database to be invalid. This can occur when the agent		cause the database to be invalid. This can occur when the server
	boots or when a module is loaded dynamically at runtime.		boots or when a module is loaded dynamically at runtime.
	Top level objects are declared in YANG as mandatory with the		Top level objects are declared in YANG as mandatory with the
	mandatory statement or the min-elements statement. All nested non-		mandatory statement or the min-elements statement. All nested non-
	presence containers are transparent, so a mandatory node nested		presence containers are transparent, so a mandatory node nested
	within one or more non-presence containers causes the top-level		within one or more non-presence containers causes the top-level
	container to be considered mandatory.		container to be considered mandatory.
	4.9. Data Types		4.9. Data Types
	skipping to change at page 15, line 24		skipping to change at page 15, line 24
	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 not required to		For string data types, if the length of the string is not required to
	be unbounded in all implementations, then a length statement SHOULD		be unbounded in all implementations, then a length statement SHOULD
	be present. [ed: should the 'resource-denied' error be mentioned		be present.
	here?]
	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 or
	skipping to change at page 19, line 9		skipping to change at page 19, line 9
	then a reference statement SHOULD be present.		then a reference statement SHOULD be present.
	5. IANA Considerations		5. IANA Considerations
	There are no actions requested of IANA at this time.		There are no actions requested of IANA at this time.
	6. Security Considerations		6. Security Considerations
	This document defines documentation guidelines for NETCONF content		This document defines documentation guidelines for NETCONF content
	defined with the YANG data modeling language. It does not introduce		defined with the YANG data modeling language. It does not introduce
	any new or increased security risks into the management system. [ed:		any new or increased security risks into the management system.
	RFC 4181 style security section TBD]
	7. Acknowledgments		7. Acknowledgments
	The structure and contents of this document are adapted from		The structure and contents of this document are adapted from
	Guidelines for MIB Documents [RFC4181], by C. M. Heard.		Guidelines for MIB Documents [RFC4181], by C. M. Heard.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	skipping to change at page 21, line 21		skipping to change at page 21, line 21
	[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.
	[I-D.ietf-netmod-yang]		[I-D.ietf-netmod-yang]
	Bjorklund, M., "YANG - A data modeling language for		Bjorklund, M., "YANG - A data modeling language for
	NETCONF", draft-ietf-netmod-yang-07 (work in progress),		NETCONF", draft-ietf-netmod-yang-08 (work in progress),
	July 2009.		October 2009.
	[I-D.ietf-netmod-yang-types]		[I-D.ietf-netmod-yang-types]
	Schoenwaelder, J., "Common YANG Data Types",		Schoenwaelder, J., "Common YANG Data Types",
	draft-ietf-netmod-yang-types-03 (work in progress),		draft-ietf-netmod-yang-types-04 (work in progress),
	May 2009.		October 2009.
	8.2. Informative References		8.2. Informative References
	[RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB		[RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB
	Documents", BCP 111, RFC 4181, September 2005.		Documents", BCP 111, RFC 4181, September 2005.
	Appendix A. Module Review Checklist		Appendix A. Module Review Checklist
	This section is adapted from RFC 4181.		This section is adapted from RFC 4181.
	skipping to change at page 24, line 7		skipping to change at page 24, line 7
	errors; see [YANG tool URL TBD] for more information. Checking		errors; see [YANG tool URL TBD] for more information. Checking
	for correct syntax, however, is only part of the job. It is		for correct syntax, however, is only part of the job. It is
	just as important to actually read the YANG module document from		just as important to actually read the YANG module document from
	the point of view of a potential implementor. It is		the point of view of a potential implementor. It is
	particularly important to check that description statements are		particularly important to check that description statements are
	sufficiently clear and unambiguous to allow interoperable		sufficiently clear and unambiguous to allow interoperable
	implementations to be created.		implementations to be created.
	Appendix B. YANG Module Template		Appendix B. YANG Module Template
	== begin "ietf-template.yang"		<CODE BEGINS>
	module ietf-template {		module ietf-template {
	// replace this string with a unique namespace URN value		// replace this string with a unique namespace URN value
	namespace		namespace
	"urn:ietf:params:xml:ns:yang:ietf-template:DRAFT-01";		"urn:ietf:params:xml:ns:yang:ietf-template:DRAFT-02";
	// replace this string, and try to pick a unique prefix		// replace this string, and try to pick a unique prefix
	prefix "temp";		prefix "temp";
	// import statements here: e.g.,		// import statements here: e.g.,
	// import ietf-yang-types { prefix yang; }		// import ietf-yang-types { prefix yang; }
	// import ietf-inet-types { prefix inet; }		// import ietf-inet-types { prefix inet; }
			// identify the IETF working group if applicable
	organization		organization
	"Internet Engineering Task Force";		"IETF NETMOD (NETCONF Data Modeling Language) Working Group";
	// update this contact statement with your info		// update this contact statement with your info
	contact		contact
	"WG Web: <http://tools.ietf.org/wg/your-wg-name/>		"WG Web: <http://tools.ietf.org/wg/your-wg-name/>
	WG List: <mailto:your-wg-name@ietf.org>		WG List: <mailto:your-wg-name@ietf.org>
	WG Chair: your-WG-chair		WG Chair: your-WG-chair
	<mailto:your-WG-chair@example.com>		<mailto:your-WG-chair@example.com>
	Editor: your-name		Editor: your-name
	skipping to change at page 25, line 46		skipping to change at page 25, line 44
	POSSIBILITY OF SUCH DAMAGE.		POSSIBILITY OF SUCH DAMAGE.
	This version of this YANG module is part of RFC XXXX; see		This version of this YANG module is part of RFC XXXX; see
	the RFC itself for full legal notices.";		the RFC itself for full legal notices.";
	// RFC Ed.: replace XXXX with actual RFC number and remove this note		// RFC Ed.: replace XXXX with actual RFC number and remove this note
	reference "RFC XXXX";		reference "RFC XXXX";
	// RFC Ed.: remove this note		// RFC Ed.: remove this note
	// Note: extracted from draft-ietf-netmod-yang-usage-01.txt		// Note: extracted from draft-ietf-netmod-yang-usage-02.txt
	// replace YYYY-MM-DD with a real date (year-month-day)		// replace YYYY-MM-DD with a real date (year-month-day)
	// here is an example revision date: 2009-08-12		// here is an example revision date: 2009-08-12
	revision YYYY-MM-DD {		revision YYYY-MM-DD {
	description		description
	"Initial version";		"Initial version";
	}		}
	// extension statements		// extension statements
	// feature statements		// feature statements
	// identity statements		// identity statements
	// typedef statements		// typedef statements
	skipping to change at page 26, line 29		skipping to change at page 26, line 29
	// augment statements		// augment statements
	// rpc statements		// rpc statements
	// notification statements		// notification statements
	// DO NOT put deviation statements in a published module		// DO NOT put deviation statements in a published module
	}		}
	== end "ietf-template.yang"		<CODE ENDS>
	Figure 2		Figure 2
	Appendix C. Change Log		Appendix C. Change Log
	C.1. Changes from 00 to 01		C.1. 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.
	skipping to change at page 28, line 5		skipping to change at page 27, line 29
	o Added note on use of preceding-sibling and following-sibling axes		o Added note on use of preceding-sibling and following-sibling axes
	in XPath expressions.		in XPath expressions.
	o Added section on temporary namespace statement values.		o Added section on temporary namespace statement values.
	o Added section on top level database objects.		o Added section on top level database objects.
	o Added ietf-template.yang appendix.		o Added ietf-template.yang appendix.
			C.2. Changes from 01 to 02
			o Updated figure 1 per mailing list comments.
			o Updated suggested organization to include the working group name.
			o Updated ietf-template.yang to use new organization statement
			value.
			o Updated Code Component requirements as per new TLP.
			o Updated ietf-template.yang to use new Code Component begin and end
			markers.
			o Updated references to the TLP in a couple sections.
			o Change manager/agent terminology to client/server.
	Author's Address		Author's Address
	Andy Bierman		Andy Bierman
	Netconf Central		Netconf Central, Inc.
	Simi Valley, CA		Simi Valley, CA
	USA		USA
	Email: andy@netconfcentral.com		Email: andy@netconfcentral.com
End of changes. 33 change blocks.
	55 lines changed or deleted		79 lines changed or added
This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/