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/