draft-ietf-netconf-with-defaults-06.txt   draft-ietf-netconf-with-defaults-07.txt 
NETCONF A. Bierman NETCONF A. Bierman
Internet-Draft InterWorking Labs Internet-Draft InterWorking Labs
Intended status: Standards Track B. Lengyel Intended status: Standards Track B. Lengyel
Expires: September 29, 2010 Ericsson Expires: October 21, 2010 Ericsson
March 28, 2010 April 19, 2010
With-defaults capability for NETCONF With-defaults capability for NETCONF
draft-ietf-netconf-with-defaults-06 draft-ietf-netconf-with-defaults-07
Abstract Abstract
The NETCONF protocol defines ways to read configuration data from a The NETCONF protocol defines ways to read configuration data from a
NETCONF server. Part of this data is not set by the NETCONF client, NETCONF server. Part of this data is not set by the NETCONF client,
but rather a default value is used. In many situations the NETCONF but rather a default value is used. In many situations the NETCONF
client has a priori knowledge about default data, so the NETCONF client has a priori knowledge about default data, so the NETCONF
server does not need to send it to the client. In other situations server does not need to send it to the client. In other situations
the NETCONF client will need this data as part of the NETCONF <rpc- the NETCONF client will need this data as part of the NETCONF <rpc-
reply> messages. This document defines a capability-based extension reply> messages. This document defines a capability-based extension
to the NETCONF protocol that allows the NETCONF client to control to the NETCONF protocol that allows the NETCONF client to control
whether default values are part of NETCONF <rpc-reply> messages or whether default values are part of NETCONF <rpc-reply> messages or
<copy-config> output to the target URL. <copy-config> output to the target URL.
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 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). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on October 21, 2010.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 29, 2010.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
skipping to change at page 2, line 15 skipping to change at page 2, line 9
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
skipping to change at page 3, line 31 skipping to change at page 3, line 31
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
7. Normative References . . . . . . . . . . . . . . . . . . . . . 11 7. Normative References . . . . . . . . . . . . . . . . . . . . . 11
Appendix A. Usage Examples . . . . . . . . . . . . . . . . . . . 12 Appendix A. Usage Examples . . . . . . . . . . . . . . . . . . . 12
A.1. Example YANG Module . . . . . . . . . . . . . . . . . . . 12 A.1. Example YANG Module . . . . . . . . . . . . . . . . . . . 12
A.2. Example Data Set . . . . . . . . . . . . . . . . . . . . . 14 A.2. Example Data Set . . . . . . . . . . . . . . . . . . . . . 14
A.3. Protocol Operation Examples . . . . . . . . . . . . . . . 15 A.3. Protocol Operation Examples . . . . . . . . . . . . . . . 15
A.3.1. <with-defaults> = 'report-all' . . . . . . . . . . . . 15 A.3.1. <with-defaults> = 'report-all' . . . . . . . . . . . . 15
A.3.2. <with-defaults> = 'trim' . . . . . . . . . . . . . . . 16 A.3.2. <with-defaults> = 'trim' . . . . . . . . . . . . . . . 16
A.3.3. <with-defaults> = 'explicit' . . . . . . . . . . . . . 17 A.3.3. <with-defaults> = 'explicit' . . . . . . . . . . . . . 17
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 18 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 18
B.1. 05-06 . . . . . . . . . . . . . . . . . . . . . . . . . . 19 B.1. 06-07 . . . . . . . . . . . . . . . . . . . . . . . . . . 19
B.2. 04-05 . . . . . . . . . . . . . . . . . . . . . . . . . . 19 B.2. 05-06 . . . . . . . . . . . . . . . . . . . . . . . . . . 19
B.3. 03-04 . . . . . . . . . . . . . . . . . . . . . . . . . . 20 B.3. 04-05 . . . . . . . . . . . . . . . . . . . . . . . . . . 19
B.4. 02-03 . . . . . . . . . . . . . . . . . . . . . . . . . . 20 B.4. 03-04 . . . . . . . . . . . . . . . . . . . . . . . . . . 20
B.5. 01-02 . . . . . . . . . . . . . . . . . . . . . . . . . . 20 B.5. 02-03 . . . . . . . . . . . . . . . . . . . . . . . . . . 20
B.6. 00-01 . . . . . . . . . . . . . . . . . . . . . . . . . . 20 B.6. 01-02 . . . . . . . . . . . . . . . . . . . . . . . . . . 20
B.7. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 B.7. 00-01 . . . . . . . . . . . . . . . . . . . . . . . . . . 20
B.8. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
The NETCONF protocol [RFC4741] defines ways to read configuration and The NETCONF protocol [RFC4741] defines ways to read configuration and
state data from a NETCONF server. Part of the configuration data may state data from a NETCONF server. Part of the configuration data may
not be set by the NETCONF client, but rather by a default value from not be set by the NETCONF client, but rather by a default value from
the data model. In many situations the NETCONF client has a priori the data model. In many situations the NETCONF client has a priori
knowledge about default data, so the NETCONF server does not need to knowledge about default data, so the NETCONF server does not need to
send it to the client. A priori knowledge can be e.g., a document send it to the client. A priori knowledge can be e.g., a document
skipping to change at page 5, line 7 skipping to change at page 5, line 7
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Data model schema: A document or set of documents describing the Data model schema: A document or set of documents describing the
data models supported by the NETCONF server. data models supported by the NETCONF server.
Management Application: A computer program running outside the Management Application: A computer program running outside the
NETCONF server that configures or supervises the NETCONF server. NETCONF server that configures or supervises the NETCONF server.
A management application can reach the device e.g. via the A management application can reach the device e.g. via NETCONF,
NETCONF, CLI or SNMP. CLI or SNMP.
Default data: Data specified in the data model schema as default, Default data: Data specified in the data model schema as default,
that is set or used by the device whenever the NETCONF client or that is set or used by the device whenever the NETCONF client or
other management application/user does not provide a specific other management application/user does not provide a specific
value for the relevant data item. Default data MAY or may not be value for the relevant data item. Default data MAY or may not be
stored as part of a configuration datastore. stored as part of a configuration datastore.
Explicitly set data: Data that is set to any value by a NETCONF Explicitly set data: Data that is set to any value by a NETCONF
client or other management application by the way of an actual client or other management application by the way of an actual
management operation, including any data model schema default management operation, including any data model schema default
value. Any value set by the NETCONF server which is not the value. Any value set by the NETCONF server which is not the
schema defined default value is also considered explicitly set schema defined default value is also considered explicitly set
skipping to change at page 6, line 50 skipping to change at page 6, line 50
request. The allowed values of this parameter are report-all, trim, request. The allowed values of this parameter are report-all, trim,
explicit as listed in Section 1.2. explicit as listed in Section 1.2.
The identifier MAY have another parameter: "also-supported". This The identifier MAY have another parameter: "also-supported". This
parameter indicates which additional default handling modes the parameter indicates which additional default handling modes the
server supports. The value of the parameter is a comma separated server supports. The value of the parameter is a comma separated
list of one or two modes that are supported beside the mode indicated list of one or two modes that are supported beside the mode indicated
in the 'basic-mode' parameter. Possible modes are taken from the in the 'basic-mode' parameter. Possible modes are taken from the
list in Section 1.2. list in Section 1.2.
In addition to these parameters, the identifier MUST have the YANG Note that this protocol capability URI is separate from the YANG
'module' and 'revision' parameters if the ietf-with-defaults YANG module capability URI for the YANG module in Section 3. A server
module is supported, as defined in section 5.6.4 of which implements this module will also advertise a YANG module
capability URI according to the rules specified in
[I-D.ietf-netmod-yang]. [I-D.ietf-netmod-yang].
Example: Examples:
urn:ietf:params:netconf:capability:with-defaults?module=ietf-netconf- urn:ietf:params:netconf:capability:with-defaults?basic-mode=report-
with-defaults&revision=2010-03-25&basic-mode=report-all all
urn:ietf:params:netconf:capability:with-defaults?module=ietf-netconf- urn:ietf:params:netconf:capability:with-defaults?basic-mode=report-
with-defaults&revision=2010-03-25&basic-mode=report-all& all&also-supported=trim,explicit
also-supported=trim,explicit
2.5. New Operations 2.5. New Operations
None None
2.6. Modifications to Existing Operations 2.6. Modifications to Existing Operations
A new <with-defaults> XML child element is added to the <get>, <get- A new <with-defaults> XML child element is added to the <get>, <get-
config> and <copy-config> operations. If the <with-defaults> element config> and <copy-config> operations. If the <with-defaults> element
is present, it controls the reporting of default data. The server is present, it controls the reporting of default data. The server
skipping to change at page 8, line 30 skipping to change at page 8, line 30
The following YANG module defines the addition of the with-defaults The following YANG module defines the addition of the with-defaults
element to the <get>, <get-config> and <copy-config> operations. The element to the <get>, <get-config> and <copy-config> operations. The
YANG language is defined in [I-D.ietf-netmod-yang]. The above YANG language is defined in [I-D.ietf-netmod-yang]. The above
operations are defined in YANG in [I-D.ietf-netconf-4741bis]. Every operations are defined in YANG in [I-D.ietf-netconf-4741bis]. Every
NETCONF server SHOULD implement this YANG module. NETCONF server SHOULD implement this YANG module.
<CODE BEGINS> file="ietf-netconf-with-defaults.yang" <CODE BEGINS> file="ietf-netconf-with-defaults.yang"
module ietf-netconf-with-defaults { module ietf-netconf-with-defaults {
namespace "urn:ietf:params:netconf:capability:with-defaults"; namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults";
prefix nwd; prefix nwd;
import ietf-netconf { prefix nc; } import ietf-netconf { prefix nc; }
organization organization
"IETF NETCONF (Network Configuration Protocol) Working Group"; "IETF NETCONF (Network Configuration Protocol) Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/netconf/> "WG Web: <http://tools.ietf.org/wg/netconf/>
skipping to change at page 9, line 34 skipping to change at page 9, line 34
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
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
// RFC Ed.: remove this note // RFC Ed.: remove this note
// Note: extracted from draft-ietf-netmod-with-defaults-06.txt // Note: extracted from draft-ietf-netmod-with-defaults-06.txt
revision 2010-03-25 { revision 2010-04-19 {
description description
"Initial version."; "Initial version.";
reference reference
"RFC XXXX: With-defaults capability for NETCONF"; "RFC XXXX: With-defaults capability for NETCONF";
} }
// RFC Ed.: replace XXXX with actual RFC number and remove this note // RFC Ed.: replace XXXX with actual RFC number and remove this note
typedef with-defaults-mode { typedef with-defaults-mode {
description description
"Possible modes to report default data in "Possible modes to report default data in
skipping to change at page 11, line 15 skipping to change at page 11, line 15
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
| Index | Capability Identifier | | Index | Capability Identifier |
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
| :with-defaults | urn:ietf:params:netconf:capability:with-defaults | | :with-defaults | urn:ietf:params:netconf:capability:with-defaults |
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
This document also registers one module name in the 'YANG Module This document also registers one module name in the 'YANG Module
Names' registry, defined in [I-D.ietf-netmod-yang] . The following Names' registry, defined in [I-D.ietf-netmod-yang] . The following
data should be recorded in this registry: data should be recorded in this registry:
+----------------+--------------------------------------------------+ +----------+--------------------------------------------------------+
| Field | Value | | Field | Value |
+----------------+--------------------------------------------------+ +----------+--------------------------------------------------------+
| Module Name | ietf-netconf-with-defaults | | Module | ietf-netconf-with-defaults |
| Module Prefix | nwd | | Name | |
| XML Namespace | urn:ietf:params:netconf:capability:with-defaults | | Module | nwd |
| Module RFC | XXXX // RFC Ed.: replace XXXX and remove | | Prefix | |
+----------------+--------------------------------------------------+ | XML | urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults |
| Namespac | |
| e | |
| Module | XXXX // RFC Ed.: replace XXXX and remove |
| RFC | |
+----------+--------------------------------------------------------+
5. Security Considerations 5. Security Considerations
This document defines a minor extension to existing NETCONF protocol This document defines a minor extension to existing NETCONF protocol
operations. It does not introduce any new or increased security operations. It does not introduce any new or increased security
risks into the management system. risks into the management system.
The 'with-defaults' capability gives client control over the The 'with-defaults' capability gives client control over the
retrieval of particular types of XML data from a configuration retrieval of particular types of XML data from a configuration
database. They only suppress data that can already be retrieved with database. They only suppress data that can already be retrieved with
skipping to change at page 12, line 16 skipping to change at page 12, line 20
December 2006. December 2006.
[I-D.ietf-netconf-4741bis] [I-D.ietf-netconf-4741bis]
Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)", Bierman, "Network Configuration Protocol (NETCONF)",
draft-ietf-netconf-4741bis-02 (work in progress), draft-ietf-netconf-4741bis-02 (work in progress),
February 2010. February 2010.
[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-11 (work in progress), NETCONF", draft-ietf-netmod-yang-12 (work in progress),
February 2010. April 2010.
[W3C.REC-xml-20081126] [W3C.REC-xml-20081126]
Yergeau, F., Bray, T., Maler, E., Paoli, J., and C. Yergeau, F., Maler, E., Paoli, J., Sperberg-McQueen, C.,
Sperberg-McQueen, "Extensible Markup Language (XML) 1.0 and T. Bray, "Extensible Markup Language (XML) 1.0 (Fifth
(Fifth Edition)", World Wide Web Consortium Edition)", World Wide Web Consortium Recommendation REC-
Recommendation REC-xml-20081126, November 2008, xml-20081126, November 2008,
<http://www.w3.org/TR/2008/REC-xml-20081126>. <http://www.w3.org/TR/2008/REC-xml-20081126>.
Appendix A. Usage Examples Appendix A. Usage Examples
A.1. Example YANG Module A.1. Example YANG Module
The following YANG module defines an example interfaces table to The following YANG module defines an example interfaces table to
demonstrate how the <with-defaults> parameter behaves for a specific demonstrate how the <with-defaults> parameter behaves for a specific
data model. data model.
Note that this is not a real module, and implementation of this Note that this is not a real module, and implementation of this
module is not required for conformance to the :with-defaults protocol module is not required for conformance to the :with-defaults protocol
capability, defined in Section 2. This module is not to be capability, defined in Section 2. This module is not to be
registered with IANA. It is intentionally very terse, and include registered with IANA. It is intentionally very terse, and includes
few descriptive statements. few descriptive statements.
<CODE BEGINS> file="example.yang" <CODE BEGINS> file="example.yang"
module example { module example {
namespace "http://example.com/ns/interfaces"; namespace "http://example.com/ns/interfaces";
prefix exam; prefix exam;
typedef itf-status-type { typedef itf-status-type {
description "Interface status"; description "Interface status";
type enumeration { type enumeration {
enum ok; enum ok;
enum 'waking up'; enum 'waking up';
enum 'not feeling so good'; enum 'not feeling so good';
enum 'better check it out'; enum 'better check it out';
enum 'better call for help'; enum 'better call for help';
skipping to change at page 13, line 47 skipping to change at page 14, line 4
} }
leaf itf-status { leaf itf-status {
description description
"The current status of this interface."; "The current status of this interface.";
type itf-status-type; type itf-status-type;
config false; config false;
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
A.2. Example Data Set A.2. Example Data Set
The following figure shows the conceptual contents of the example The following data element shows the conceptual contents of the
server for the protocol operation examples in the next section. This example server for the protocol operation examples in the next
includes all the configuration data nodes, non-configuration data section. This includes all the configuration data nodes, non-
nodes, and default leafs. configuration data nodes, and default leafs.
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-example"> <interfaces xmlns="http://example.com/ns/interfaces">
<interface> <interface>
<name>eth0</name> <name>eth0</name>
<mtu>8192</mtu> <mtu>8192</mtu>
<itf-status>up</itf-status> <itf-status>up</itf-status>
</interface> </interface>
<interface> <interface>
<name>eth1</name> <name>eth1</name>
<mtu>1500</mtu> <mtu>1500</mtu>
<itf-status>up</itf-status> <itf-status>up</itf-status>
</interface> </interface>
skipping to change at page 15, line 7 skipping to change at page 15, line 16
| name | set by | mtu | | name | set by | mtu |
+--------------+--------------+--------------+ +--------------+--------------+--------------+
| eth0 | client | 8192 | | eth0 | client | 8192 |
| eth1 | server | 1500 | | eth1 | server | 1500 |
| eth2 | client | 9000 | | eth2 | client | 9000 |
| eth3 | client | 1500 | | eth3 | client | 1500 |
+--------------+--------------+--------------+ +--------------+--------------+--------------+
A.3. Protocol Operation Examples A.3. Protocol Operation Examples
The following examples shows some <get> operations which are using The following examples shows some <get> operations using the 'with-
the 'with-defaults' element. The data model used for these examples defaults' element. The data model used for these examples is defined
is defined in Appendix A.1. in Appendix A.1.
The client is retrieving all the data nodes within the 'interfaces' The client is retrieving all the data nodes within the 'interfaces'
object, filtered with the <with-defaults> parameter. object, filtered with the <with-defaults> parameter.
A.3.1. <with-defaults> = 'report-all' A.3.1. <with-defaults> = 'report-all'
The behavior of the <with-defaults > parameter handling for the value The behavior of the <with-defaults> parameter handling for the value
'report-all' is demonstrated in this example. 'report-all' is demonstrated in this example.
<rpc message-id="102" <rpc message-id="102"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get> <get>
<filter type="subtree"> <filter type="subtree">
<interfaces xmlns="http://example.com/ns/interfaces"/> <interfaces xmlns="http://example.com/ns/interfaces"/>
</filter> </filter>
<with-defaults <with-defaults
xmlns="urn:ietf:params:netconf:capability:with-defaults"> xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults">
report-all report-all
</with-defaults> </with-defaults>
</get> </get>
</rpc> </rpc>
<rpc-reply message-id="102" <rpc-reply message-id="102"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data> <data>
<interfaces xmlns="http://example.com/ns/interfaces"> <interfaces xmlns="http://example.com/ns/interfaces">
<interface> <interface>
<name>eth0</name> <name>eth0</name>
<mtu>8192</mtu> <mtu>8192</mtu>
<itf-status>up</itf-status> <itf-status>up</itf-status>
</interface> </interface>
<interface> <interface>
<name>eth1</name> <name>eth1</name>
<mtu>1500</mtu> <mtu>1500</mtu>
<itf-status>up</itf-status> <itf-status>up</itf-status>
</interface> </interface>
<interface> <interface>
<name>eth2</name> <name>eth2</name>
<mtu>9000</mtu> <mtu>9000</mtu>
<itf-status>not feeling so good</itf-status> <itf-status>not feeling so good</itf-status>
</interface> </interface>
<interface> <interface>
<name>eth3</name> <name>eth3</name>
<mtu>1500</mtu> <mtu>1500</mtu>
<itf-status>waking up</itf-status> <itf-status>waking up</itf-status>
</interface> </interface>
</interfaces> </interfaces>
</data> </data>
</rpc-reply> </rpc-reply>
A.3.2. <with-defaults> = 'trim' A.3.2. <with-defaults> = 'trim'
The behavior of the <with-defaults > parameter handling for the value The behavior of the <with-defaults > parameter handling for the value
'trim' is demonstrated in this example. 'trim' is demonstrated in this example.
<rpc message-id="103" <rpc message-id="103"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get> <get>
<filter type="subtree"> <filter type="subtree">
<interfaces xmlns="http://example.com/ns/interfaces"/> <interfaces xmlns="http://example.com/ns/interfaces"/>
</filter> </filter>
<with-defaults <with-defaults
xmlns="urn:ietf:params:netconf:capability:with-defaults"> xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults">
trim trim
</with-defaults> </with-defaults>
</get> </get>
</rpc> </rpc>
<rpc-reply message-id="103" <rpc-reply message-id="103"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data> <data>
<interfaces xmlns="http://example.com/ns/interfaces"> <interfaces xmlns="http://example.com/ns/interfaces">
<interface> <interface>
<name>eth0</name> <name>eth0</name>
<mtu>8192</mtu> <mtu>8192</mtu>
</interface> </interface>
<interface> <interface>
<name>eth1</name> <name>eth1</name>
</interface> </interface>
<interface> <interface>
<name>eth2</name> <name>eth2</name>
<mtu>9000</mtu> <mtu>9000</mtu>
<itf-status>not feeling so good</itf-status> <itf-status>not feeling so good</itf-status>
</interface> </interface>
<interface> <interface>
<name>eth3</name> <name>eth3</name>
<itf-status>waking up</itf-status> <itf-status>waking up</itf-status>
</interface> </interface>
</interfaces> </interfaces>
</data> </data>
</rpc-reply> </rpc-reply>
A.3.3. <with-defaults> = 'explicit' A.3.3. <with-defaults> = 'explicit'
The behavior of the <with-defaults > parameter handling for the value The behavior of the <with-defaults > parameter handling for the value
'explicit' is demonstrated in this example. 'explicit' is demonstrated in this example.
<rpc message-id="104" <rpc message-id="104"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get> <get>
<filter type="subtree"> <filter type="subtree">
<interfaces xmlns="http://example.com/ns/interfaces"/> <interfaces xmlns="http://example.com/ns/interfaces"/>
</filter> </filter>
<with-defaults <with-defaults
xmlns="urn:ietf:params:netconf:capability:with-defaults"> xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults">
explicit explicit
</with-defaults> </with-defaults>
</get> </get>
</rpc> </rpc>
<rpc-reply message-id="104" <rpc-reply message-id="104"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data> <data>
<interfaces xmlns="http://example.com/ns/interfaces"> <interfaces xmlns="http://example.com/ns/interfaces">
<interface> <interface>
<name>eth0</name> <name>eth0</name>
<mtu>8192</mtu> <mtu>8192</mtu>
<itf-status>up</itf-status> <itf-status>up</itf-status>
</interface> </interface>
<interface> <interface>
<name>eth1</name> <name>eth1</name>
<itf-status>up</itf-status> <itf-status>up</itf-status>
</interface> </interface>
<interface> <interface>
<name>eth2</name> <name>eth2</name>
<mtu>9000</mtu> <mtu>9000</mtu>
<itf-status>not feeling so good</itf-status> <itf-status>not feeling so good</itf-status>
</interface> </interface>
<interface> <interface>
<name>eth3</name> <name>eth3</name>
<mtu>1500</mtu> <mtu>1500</mtu>
<itf-status>waking up</itf-status> <itf-status>waking up</itf-status>
</interface> </interface>
</interfaces> </interfaces>
</data> </data>
</rpc-reply> </rpc-reply>
Appendix B. Change Log Appendix B. Change Log
-- RFC Ed.: remove this section before publication. -- RFC Ed.: remove this section before publication.
B.1. 05-06 B.1. 06-07
Removed text in capability identifier section about adding YANG
module capability URI parameters.
Changed YANG module namespace to match YANG format, and updated
examples to use this new namespace.
Fixed some typos.
B.2. 05-06
Removed ':1.0' from capability URI. Removed ':1.0' from capability URI.
Removed open issues section because all known issues are closed. Removed open issues section because all known issues are closed.
Moved examples to a separate appendix, and expanded them. Moved examples to a separate appendix, and expanded them.
Added example.yang as an appendix to properly explain the examples Added example.yang as an appendix to properly explain the examples
used within the document. used within the document.
skipping to change at page 19, line 28 skipping to change at page 19, line 38
Clarified <with-defaults> behavior for non-configuration data nodes. Clarified <with-defaults> behavior for non-configuration data nodes.
Clarified various sections based on WGLC comments on mailing list. Clarified various sections based on WGLC comments on mailing list.
Removed some unused terms. Removed some unused terms.
Reversed the order of the change log sections so the most recent Reversed the order of the change log sections so the most recent
changes are shown first. changes are shown first.
B.2. 04-05 B.3. 04-05
Updated I-D and YANG module boiler-plate. Updated I-D and YANG module boiler-plate.
Removed redundant 'with-defaults' YANG feature. Removed redundant 'with-defaults' YANG feature.
Changed definition of 'explicit' mode to match the YANG definition Changed definition of 'explicit' mode to match the YANG definition
Removed XSD because the YANG is normative and the XSD is Removed XSD because the YANG is normative and the XSD is
unconstrained, and does not properly extend the 3 affected NETCONF unconstrained, and does not properly extend the 3 affected NETCONF
operations. operations.
skipping to change at page 20, line 7 skipping to change at page 20, line 18
the YANG module imports the ietf-netconf module in order to augment the YANG module imports the ietf-netconf module in order to augment
some operations. some operations.
Updated capability requirements to include YANG module capability Updated capability requirements to include YANG module capability
parameters. parameters.
Added a description statement to the with-defaults leaf definition. Added a description statement to the with-defaults leaf definition.
Update open issues section; ready to close all open issues. Update open issues section; ready to close all open issues.
B.3. 03-04 B.4. 03-04
Clarifications Clarifications
Added non-netconf interfaces to the definition of explicitly set Added non-netconf interfaces to the definition of explicitly set
default data default data
B.4. 02-03 B.5. 02-03
Clarifications Clarifications
YAM added YAM added
Use the same URN for the capability and the XML namespace to Use the same URN for the capability and the XML namespace to
accommodate YANG, and avoid two separate URN/URIs being advertised in accommodate YANG, and avoid two separate URN/URIs being advertised in
the HELLO message, for such a small function. the HELLO message, for such a small function.
B.5. 01-02 B.6. 01-02
report-all made mandatory report-all made mandatory
Placeholder for YAM added, XSD will be removed when 4741 provides the Placeholder for YAM added, XSD will be removed when 4741 provides the
NETCONF YAM NETCONF YAM
with-defaults is valid for state data as well (if state data has a with-defaults is valid for state data as well (if state data has a
defined default which might not be so frequent). The definition of defined default which might not be so frequent). The definition of
explicit was modified for state data. explicit was modified for state data.
B.6. 00-01 B.7. 00-01
Changed value set of with-default capability and element Changed value set of with-default capability and element
Added version to URI Added version to URI
B.7. -00 B.8. -00
Created from draft-bierman-netconf-with-defaults-01.txt Created from draft-bierman-netconf-with-defaults-01.txt
It was decided by the NETCONF mailing list, that with-defaults should It was decided by the NETCONF mailing list, that with-defaults should
be a sub-element of each affected operation. While this violates the be a sub-element of each affected operation. While this violates the
XSD of RFC4741 this is acceptable and follows the ideas behind XSD of RFC4741 this is acceptable and follows the ideas behind
NETCONF and YANG. NETCONF and YANG.
Hopefully it will be clarified in the 4741bis RFC whether such Hopefully it will be clarified in the 4741bis RFC whether such
extensions are allowed. extensions are allowed.
Authors' Addresses Authors' Addresses
Andy Bierman Andy Bierman
InterWorking Labs InterWorking Labs
303 Potrero Street, Suite 52 Santa Cruz, CA
Santa Cruz, CA 95060-2760
USA USA
Phone: +1 831 460 7010 Phone: +1 831 460 7010
Email: andyb@iwl.com Email: andyb@iwl.com
Balazs Lengyel Balazs Lengyel
Ericsson Ericsson
Budapest, Budapest,
Hungary Hungary
 End of changes. 39 change blocks. 
182 lines changed or deleted 191 lines changed or added

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