draft-ietf-netmod-yang-usage-10.txt   draft-ietf-netmod-yang-usage-11.txt 
Internet Engineering Task Force A. Bierman Internet Engineering Task Force A. Bierman
Internet-Draft Brocade Internet-Draft Brocade
Intended status: Informational August 11, 2010 Intended status: Informational October 2, 2010
Expires: February 12, 2011 Expires: April 5, 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-10 draft-ietf-netmod-yang-usage-11
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 Network intended to increase interoperability and usability of Network
Configuration Protocol (NETCONF) implementations which utilize YANG Configuration Protocol (NETCONF) implementations which utilize YANG
data model modules. data model modules.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 February 12, 2011. This Internet-Draft will expire on April 5, 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 24 skipping to change at page 2, line 24
2.4. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.4. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. General Documentation Guidelines . . . . . . . . . . . . . . . 7 3. General Documentation Guidelines . . . . . . . . . . . . . . . 7
3.1. Module Copyright . . . . . . . . . . . . . . . . . . . . . 7 3.1. Module Copyright . . . . . . . . . . . . . . . . . . . . . 7
3.2. Narrative Sections . . . . . . . . . . . . . . . . . . . . 8 3.2. Narrative Sections . . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . 9 3.5. IANA Considerations Section . . . . . . . . . . . . . . . 9
3.5.1. Documents that Create a New Name Space . . . . . . . . 9 3.5.1. Documents that Create a New Name Space . . . . . . . . 9
3.5.2. Documents that Extend an Existing Name Space . . . . . 9 3.5.2. Documents that Extend an Existing Name Space . . . . . 9
3.6. Reference Sections . . . . . . . . . . . . . . . . . . . . 10 3.6. Reference Sections . . . . . . . . . . . . . . . . . . . . 10
3.7. Intellectual Property Section . . . . . . . . . . . . . . 10
4. YANG Usage Guidelines . . . . . . . . . . . . . . . . . . . . 11 4. YANG Usage Guidelines . . . . . . . . . . . . . . . . . . . . 11
4.1. Module Naming Conventions . . . . . . . . . . . . . . . . 11 4.1. Module Naming Conventions . . . . . . . . . . . . . . . . 11
4.2. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3. Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.4. Conditional Statements . . . . . . . . . . . . . . . . . . 12 4.4. Conditional Statements . . . . . . . . . . . . . . . . . . 12
4.5. XPath Usage . . . . . . . . . . . . . . . . . . . . . . . 12 4.5. XPath Usage . . . . . . . . . . . . . . . . . . . . . . . 12
4.6. Lifecycle Management . . . . . . . . . . . . . . . . . . . 13 4.6. Lifecycle Management . . . . . . . . . . . . . . . . . . . 13
4.7. Module Header, Meta, and Revision Statements . . . . . . . 14 4.7. Module Header, Meta, and Revision Statements . . . . . . . 14
4.8. Namespace Assignments . . . . . . . . . . . . . . . . . . 15 4.8. Namespace Assignments . . . . . . . . . . . . . . . . . . 15
4.9. Top Level Data Definitions . . . . . . . . . . . . . . . . 16 4.9. Top Level Data Definitions . . . . . . . . . . . . . . . . 16
4.10. Data Types . . . . . . . . . . . . . . . . . . . . . . . . 16 4.10. Data Types . . . . . . . . . . . . . . . . . . . . . . . . 16
4.11. Reusable Type Definitions . . . . . . . . . . . . . . . . 17 4.11. Reusable Type Definitions . . . . . . . . . . . . . . . . 17
4.12. Data Definitions . . . . . . . . . . . . . . . . . . . . . 17 4.12. Data Definitions . . . . . . . . . . . . . . . . . . . . . 18
4.13. Operation Definitions . . . . . . . . . . . . . . . . . . 19 4.13. Operation Definitions . . . . . . . . . . . . . . . . . . 19
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
6.1. Security Considerations Section Template . . . . . . . . . 21 6.1. Security Considerations Section Template . . . . . . . . . 21
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.1. Normative References . . . . . . . . . . . . . . . . . . . 25 8.1. Normative References . . . . . . . . . . . . . . . . . . . 25
8.2. Informative References . . . . . . . . . . . . . . . . . . 25 8.2. Informative References . . . . . . . . . . . . . . . . . . 25
Appendix A. Module Review Checklist . . . . . . . . . . . . . . . 27 Appendix A. Module Review Checklist . . . . . . . . . . . . . . . 27
Appendix B. YANG Module Template . . . . . . . . . . . . . . . . 29 Appendix B. YANG Module Template . . . . . . . . . . . . . . . . 29
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 32 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 32
C.1. Changes from 09 to 10 . . . . . . . . . . . . . . . . . . 32 C.1. Changes from 10 to 11 . . . . . . . . . . . . . . . . . . 32
C.2. Changes from 08 to 09 . . . . . . . . . . . . . . . . . . 32 C.2. Changes from 09 to 10 . . . . . . . . . . . . . . . . . . 32
C.3. Changes from 07 to 08 . . . . . . . . . . . . . . . . . . 32 C.3. Changes from 08 to 09 . . . . . . . . . . . . . . . . . . 32
C.4. Changes from 06 to 07 . . . . . . . . . . . . . . . . . . 32 C.4. Changes from 07 to 08 . . . . . . . . . . . . . . . . . . 32
C.5. Changes from 05 to 06 . . . . . . . . . . . . . . . . . . 32 C.5. Changes from 06 to 07 . . . . . . . . . . . . . . . . . . 32
C.6. Changes from 04 to 05 . . . . . . . . . . . . . . . . . . 32 C.6. Changes from 05 to 06 . . . . . . . . . . . . . . . . . . 32
C.7. Changes from 03 to 04 . . . . . . . . . . . . . . . . . . 33 C.7. Changes from 04 to 05 . . . . . . . . . . . . . . . . . . 33
C.8. Changes from 02 to 03 . . . . . . . . . . . . . . . . . . 34 C.8. Changes from 03 to 04 . . . . . . . . . . . . . . . . . . 33
C.9. Changes from 01 to 02 . . . . . . . . . . . . . . . . . . 34 C.9. Changes from 02 to 03 . . . . . . . . . . . . . . . . . . 34
C.10. Changes from 00 to 01 . . . . . . . . . . . . . . . . . . 34 C.10. Changes from 01 to 02 . . . . . . . . . . . . . . . . . . 34
C.11. Changes from 00 to 01 . . . . . . . . . . . . . . . . . . 34
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 36 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
The standardization of network configuration interfaces for use with The standardization of network configuration interfaces for use with
the Network Configuration Protocol (NETCONF) [RFC4741] requires a the Network Configuration Protocol (NETCONF) [RFC4741] requires a
modular set of data models, which can be reused and extended over modular set of data models, which can be reused and extended over
time. time.
This document defines a set of usage guidelines for standards track This document defines a set of usage guidelines for standards track
skipping to change at page 10, line 25 skipping to change at page 11, line 5
For every normative reference statement which appears in a module For every normative reference statement which appears in a module
contained in the specification, which identifies a separate document, contained in the specification, which identifies a separate document,
a corresponding normative reference to that document SHOULD appear in a 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.
If the reference statement identifies an informative reference, which If the reference statement identifies an informative reference, which
identifies a separate document, a corresponding informative reference identifies a separate document, a corresponding informative reference
to that document MAY appear in the Informative References section. to that document MAY appear in the Informative References section.
3.7. Intellectual Property Section
The proper IPR statements MUST be present in the document, according
to the most current Internet-Draft boilerplate. Refer to the IETF
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
based on previous experience, the following sections establish usage based on previous experience, the following sections establish usage
skipping to change at page 13, line 5 skipping to change at page 13, line 5
its ancestors (if any). its ancestors (if any).
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 SHOULD NOT be used. This applies
server is not required to maintain any particular XML document order to implicit use of the 'position' function as well (e.g.,
for system-ordered data nodes. A server is only required to maintain '//chapter[42]'). A server is only required to maintain the relative
the relative XML document order of all instances of a particular XML document order of all instances of a particular user-ordered list
user-ordered list or leaf-list. or leaf-list. The 'position' and 'last' functions MAY be used if
they are evaluated in a context where the context node is a 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., element name or expressions based on static node properties (e.g., element name or
value, 'ancestor' or 'descendant' axes) SHOULD be used instead. value, 'ancestor' or 'descendant' axes) SHOULD be used instead. The
'preceding' and 'following' axes MAY be used if document order is not
The 'preceding-sibling' and 'following-sibling' axes MAY be used, relevant to the outcome of the expression (e.g., check for global
with caution. A server is not required to maintain a persistent or uniqueness of a parameter value.)
deterministic XML document order, which will affect use of these
axes.
Implicit 'position' function calls within predicates MAY be used with The 'preceding-sibling' and 'following-sibling' axes SHOULD NOT used.
caution. (e.g., '//chapter[42]'). Note that a NETCONF server is only A server is only required to maintain the relative XML document order
required to maintain relative document order for related instances of of all instances of a particular user-ordered list or leaf-list. The
a user-ordered list or leaf-list data definition (i.e., 'ordered-by' 'preceding-sibling' and 'following-sibling' axes MAY be used if they
statement set to 'user'). are evaluated in a context where the context node is a user-ordered
'list' or 'leaf-list'.
Data nodes which use the 'int64' and 'uint64' built-in type MAY be Data nodes which use the 'int64' and 'uint64' built-in type SHOULD
used with caution, within 'RelationalExpr' expressions. There are NOT be used within numeric expressions. There are boundary
boundary conditions in which the translation from the YANG 64-bit conditions in which the translation from the YANG 64-bit type to an
type to an XPath number can cause incorrect results. Specifically, XPath number can cause incorrect results. Specifically, an XPath
an XPath 'double' precision floating point number cannot represent 'double' precision floating point number cannot represent very large
very large positive or negative 64-bit numbers because it only positive or negative 64-bit numbers because it only provides a total
provides a total precision of 53 bits. precision of 53 bits. The 'int64' and 'uint64' data types MAY be
used in numeric expressions if the value can be represented with no
more than 53 bits of precision.
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 18, line 37 skipping to change at page 18, line 42
o notification o notification
o rpc o rpc
o typedef o typedef
If the data definition semantics are defined in an external document, If the data definition semantics are defined in an external document,
(other than another YANG module indicated by an import statement), (other than another YANG module indicated by an import statement),
then a reference statement MUST be present. then a reference statement MUST be present.
The 'anyxml' construct MAY be used with caution within configuration The 'anyxml' construct may be useful to represent an HTML banner
data. This may be useful to represent an HTML banner containing containing markup elements, such as '<b>' and '</b>', and MAY be used
markup elements, such as <b> and </b>. However, this construct in such cases . However, this construct SHOULD NOT be used if other
SHOULD NOT be used if other YANG data node types can be used instead YANG data node types can be used instead to represent the desired
to represent the desired syntax and semantics. syntax and semantics.
If there are referential integrity constraints associated with the If there are referential integrity constraints associated with the
desired semantics that can be represented with XPath, then one or desired semantics that can be represented with XPath, then one or
more must statements SHOULD be present. more must statements SHOULD be present.
For list and leaf-list data definitions, if the number of possible For list and leaf-list data definitions, if the number of possible
instances is required to be bounded for all implementations, then the instances is required to be bounded for all implementations, then the
max-elements statements SHOULD be present. max-elements statements SHOULD be present.
If any must or when statements are used within the data definition, If any must or when statements are used within the data definition,
skipping to change at page 25, line 32 skipping to change at page 25, line 32
[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, [RFC5741] Daigle, L., Kolkman, O., and IAB, "RFC Streams, Headers,
and Boilerplates", RFC 5741, December 2009. and Boilerplates", RFC 5741, December 2009.
[W3C.REC-xpath-19991116] [W3C.REC-xpath-19991116]
Clark, J. and S. DeRose, "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.
[I-D.ietf-netmod-yang-types] [I-D.ietf-netmod-yang-types]
skipping to change at page 32, line 7 skipping to change at page 32, 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 3 Figure 3
Appendix C. Change Log Appendix C. Change Log
C.1. Changes from 09 to 10 C.1. Changes from 10 to 11
o Removed Intellectual Property section, since no longer required.
o Reworded XPath guidelines related to XML document order, 'int64'
and 'uint64' data types, and 'anyxml' data nodes.
C.2. Changes from 09 to 10
o Added security considerations section template. o Added security considerations section template.
o Added guideline for documenting conditional requirements for non- o Added guideline for documenting conditional requirements for non-
mandatory non-configuration data nodes. mandatory non-configuration data nodes.
o Clarified that revision date update applies to the module o Clarified that revision date update applies to the module
contents. contents.
C.2. Changes from 08 to 09 C.3. Changes from 08 to 09
o Clarifications and corrections to address Gen-ART review comments. o Clarifications and corrections to address Gen-ART review comments.
C.3. Changes from 07 to 08 C.4. 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.4. Changes from 06 to 07 C.5. 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.5. Changes from 05 to 06 C.6. 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.6. Changes from 04 to 05 C.7. 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.7. Changes from 03 to 04 C.8. 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 34, line 12 skipping to change at page 34, line 18
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.8. Changes from 02 to 03 C.9. 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.9. Changes from 01 to 02 C.10. 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.10. Changes from 00 to 01 C.11. 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. 23 change blocks. 
62 lines changed or deleted 65 lines changed or added

This html diff was produced by rfcdiff 1.39. The latest version is available from http://tools.ietf.org/tools/rfcdiff/