draft-ietf-netconf-with-defaults-00.txt   draft-ietf-netconf-with-defaults-01.txt 
NETCONF A. Bierman NETCONF A. Bierman
Internet-Draft Netconf Central Internet-Draft Netconf Central
Intended status: Standards Track B. Lengyel Intended status: Standards Track B. Lengyel
Expires: August 21, 2009 Ericsson Expires: October 8, 2009 Ericsson
February 17, 2009 April 06, 2009
With-defaults capability for NETCONF With-defaults capability for NETCONF
draft-ietf-netconf-with-defaults-00 draft-ietf-netconf-with-defaults-01
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 33 skipping to change at page 1, line 33
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 August 21, 2009. This Internet-Draft will expire on October 8, 2009.
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 Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
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 agent. Part of this data is not set by the NETCONF manager, NETCONF agent. Part of this data is not set by the NETCONF manager,
but rather a default value is used. In many situations the NETCONF but rather a default value is used. In many situations the NETCONF
manager has a priori knowledge about default data, so the NETCONF manager has a priori knowledge about default data, so the NETCONF
agent does not need to send it to the manager. In other situations agent does not need to send it to the manager. In other situations
the NETCONF manger will need this data as part of the NETCONF <rpc- the NETCONF manger 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
skipping to change at page 2, line 28 skipping to change at page 2, line 27
1.1.2. NETCONF Terms . . . . . . . . . . . . . . . . . . . . 3 1.1.2. NETCONF Terms . . . . . . . . . . . . . . . . . . . . 3
2. With-defaults Capability . . . . . . . . . . . . . . . . . . . 4 2. With-defaults Capability . . . . . . . . . . . . . . . . . . . 4
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Basic handling of default data . . . . . . . . . . . . 4 2.1.1. Basic handling of default data . . . . . . . . . . . . 4
2.2. Dependencies . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Dependencies . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Capability Identifier . . . . . . . . . . . . . . . . . . 5 2.3. Capability Identifier . . . . . . . . . . . . . . . . . . 5
2.4. New Operations . . . . . . . . . . . . . . . . . . . . . . 5 2.4. New Operations . . . . . . . . . . . . . . . . . . . . . . 5
2.5. Modifications to Existing Operations . . . . . . . . . . . 5 2.5. Modifications to Existing Operations . . . . . . . . . . . 5
3. Interactions with Other Capabilities . . . . . . . . . . . . . 7 3. Interactions with Other Capabilities . . . . . . . . . . . . . 7
4. Data Model XSD . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Data Model XSD . . . . . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Other default handling methods in the real world? . . . . 10 7.1. Other default handling methods in the real world? . . . . 10
7.2. XSD needed? . . . . . . . . . . . . . . . . . . . . . . . 10 7.2. XSD needed? . . . . . . . . . . . . . . . . . . . . . . . 10
7.3. Use the NETCONF namespace? . . . . . . . . . . . . . . . . 10
8. Appendix A - Change Log . . . . . . . . . . . . . . . . . . 11 8. Appendix A - Change Log . . . . . . . . . . . . . . . . . . 11
8.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. 00-01 . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.2. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
10. Normative References . . . . . . . . . . . . . . . . . . . . . 13 10. Normative References . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
The NETCONF protocol defines ways to read configuration data from a The NETCONF protocol defines ways to read configuration data from a
NETCONF agent. Part of this data is not set by the NETCONF manager, NETCONF agent. Part of this data is not set by the NETCONF manager,
but rather a default value is used. In many situations the NETCONF but rather a default value is used. In many situations the NETCONF
manager has a priori knowledge about default data, so the NETCONF manager has a priori knowledge about default data, so the NETCONF
skipping to change at page 5, line 15 skipping to change at page 5, line 15
o Report all: All default data is always reported. o Report all: All default data is always reported.
o Trim: Values are not reported if they match the default. o Trim: Values are not reported if they match the default.
o Explicit: Report values if they are explicitly set. o Explicit: Report values if they are explicitly set.
2.2. Dependencies 2.2. Dependencies
None None
2.3. Capability Identifier 2.3. Capability Identifier
urn:ietf:params:netconf:capability:with-defaults urn:ietf:params:netconf:capability:with-defaults:1.0
The identifier MUST have an additional parameter: "basic". This The identifier MUST have a parameter: "basic". This indicates how
indicates how the agent reports default data in <rpc-reply> messages, the agent reports default data in <rpc-reply> messages, in the case
in the case the manager does not specify the required behavior in the the manager does not specify the required behavior in the <rpc>
<rpc> request. The allowed values of this parameter are report-all, request. The allowed values of this parameter are report-all, trim,
trim, explicit as defined in Section 2.1.1. E.g.: explicit as listed in Section 2.1.1.
urn:ietf:params:netconf:capability:with-defaults?basic=report-all The identifier MAY have another parameter: "supported". This
indicates what other default handling methods does the agent support.
The value of the parameter is a colon separated list of one or two
supported methods. Possible methods are taken from the list in
Section 2.1.1.
Example:
urn:ietf:params:netconf:capability:with-defaults:1.0?basic=report-all
urn:ietf:params:netconf:capability:with-defaults:1.0?basic=report-
all&supported=trim:explicit
2.4. New Operations 2.4. New Operations
None None
2.5. Modifications to Existing Operations 2.5. Modifications to Existing Operations
A new <with-defaults> XML element is added to the 'method-name' A new <with-defaults> XML child element is added to the 'method-name'
element. This is the element that indicates the type of the element. This is the element that indicates the type of the
operation e.g. <get>, <get-config> or <copy-config>. If the <with- operation e.g. <get>, <get-config> or <copy-config>. If the <with-
defaults> element is present, it controls the reporting of default defaults> element is present, it controls the reporting of default
data. The agent MUST return default data in the NETCONF <rpc-reply> data. The agent MUST return default data in the NETCONF <rpc-reply>
messages according to the value of the element. messages according to the value of the element.
Allowed values of the with-defaults element are: Allowed values of the with-defaults element are taken from the list
in Section 2.1.1. The allowed values are restricted to the values
o false: default data SHOULD NOT be returned. that the device indicates support for in the with-defaults
o true: all default data MUST be returned. capability.
If the <with-defaults> element is not present, the agent follows its If the <with-defaults> element is not present, the agent follows its
basic behavior as indicated by the capability identifier's parameter basic behavior as indicated by the capability identifier's parameter
see Section 2.3. see Section 2.3.
The 'with-defaults' element is defined in the namespace specified as
the 'targetNamespace' in Section 4. However, an agent MUST accept it
even if no namespace is used.
Affected operations: Affected operations:
o <get> o <get>
o <get-config> o <get-config>
o <copy-config> o <copy-config>
Other operations that return configuration data SHOULD also handle Other operations that return configuration data SHOULD also handle
default data according to the rules set in this document, and default data according to the rules set in this document, and
explicitly state this in their documentation. If this is not explicitly state this in their documentation. If this is not
specified in the document defining the respective operation, the specified in the document defining the respective operation, the
default handling rules described herein do not affect these default handling rules described herein do not affect these
operations. operations.
skipping to change at page 6, line 22 skipping to change at page 6, line 27
specified in the document defining the respective operation, the specified in the document defining the respective operation, the
default handling rules described herein do not affect these default handling rules described herein do not affect these
operations. operations.
The following example shows a <get> operation which is using the The following example shows a <get> operation which is using the
'with-defaults' element. The manager is retrieving the 'interfaces' 'with-defaults' element. The manager is retrieving the 'interfaces'
object, defined in the example.com data model. (In this simple object, defined in the example.com data model. (In this simple
example, the 'name' field is defined as the key, and the 'mtu' field example, the 'name' field is defined as the key, and the 'mtu' field
is the only other data in the <interface> element). The default is the only other data in the <interface> element). The default
value of mtu is '1500'. The basic default handling for the agent is value of mtu is '1500'. The basic default handling for the agent is
"trim". As the 'with-defaults' element has the value 'true', the mtu "trim". As the 'with-defaults' element has the value 'report-all',
is returned not just for eth0 but also for eth1. the mtu is returned not just for eth0 but also for eth1.
<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>
<with-defaults>true</with-defaults> <with-defaults>report-all</with-defaults>
<filter type="subtree"> <filter type="subtree">
<interfaces xmlns="http://example.com/interfaces/1.2"/> <interfaces xmlns="http://example.com/interfaces/1.2"/>
</filter> </filter>
</get> </get>
</rpc> </rpc>
<rpc-reply message-id="102" with-defaults="true" <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/interfaces/1.2"> <interfaces xmlns="http://example.com/interfaces/1.2">
<interface> <interface>
<name>eth0</name> <name>eth0</name>
<mtu>8192</mtu> <mtu>8192</mtu>
</interface> </interface>
<interface> <interface>
<name>eth1</name> <name>eth1</name>
<mtu>1500</mtu> <mtu>1500</mtu>
skipping to change at page 7, line 32 skipping to change at page 8, line 21
<xs:annotation> <xs:annotation>
<xs:documentation> <xs:documentation>
Schema defining the with-defaults element. Schema defining the with-defaults element.
Organization: "IETF NETCONF Working Group" Organization: "IETF NETCONF Working Group"
Contact Info: balazs.lengyel@ericsson.com Contact Info: balazs.lengyel@ericsson.com
</xs:documentation> </xs:documentation>
</xs:annotation> </xs:annotation>
<xs:element name="with-defaults" <xs:attribute name="with-defaults" >
type="xs:boolean"/> <xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="report-all"/>
<xs:enumeration value="trim"/>
<xs:enumeration value="explicit"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:schema> </xs:schema>
5. IANA Considerations 5. IANA Considerations
This document registers two URIs for the NETCONF XML namespace in the This document registers two URIs for the NETCONF XML namespace in the
IETF XML registry [RFC3688]. Note that the capability URN is IETF XML registry [RFC3688]. Note that the capability URN is
compliant to [RFC4741] section 10.3. compliant to [RFC4741] section 10.3.
+---------------+---------------------------------------------------+ +---------------+---------------------------------------------------+
skipping to change at page 10, line 17 skipping to change at page 11, line 5
7.1. Other default handling methods in the real world? 7.1. Other default handling methods in the real world?
Are there any other basic default handling methods out there we need Are there any other basic default handling methods out there we need
to include? to include?
7.2. XSD needed? 7.2. XSD needed?
Is the XSD needed? Does it add any value, any clarity to the Is the XSD needed? Does it add any value, any clarity to the
document? document?
7.3. Use the NETCONF namespace? 8. Appendix A - Change Log
Would it be possible to put the with-defaults element into the 8.1. 00-01
NETCONF namespace? Is the current statement: "However, an agent MUST
accept it even if no namespace is used." acceptable?
8. Appendix A - Change Log Changed value set of with-default capability and element
8.1. -00 Added version to URI
8.2. -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.
 End of changes. 22 change blocks. 
41 lines changed or deleted 53 lines changed or added

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