< draft-bierman-netconf-get2-02.txt   draft-bierman-netconf-get2-03.txt >
Network Working Group A. Bierman Network Working Group A. Bierman
Internet-Draft YumaWorks Internet-Draft YumaWorks, Inc.
Intended status: Standards Track October 9, 2012 Intended status: Standards Track April 8, 2013
Expires: April 12, 2013 Expires: October 10, 2013
The NETCONF <get2> Operation The NETCONF <get2> Operation
draft-bierman-netconf-get2-02 draft-bierman-netconf-get2-03
Abstract Abstract
This document describes NETCONF protocol enhancements to improve data This document describes NETCONF protocol enhancements to improve data
retrieval capabilities. retrieval capabilities.
Status of this Memo Status of this Memo
This Internet-Draft is submitted 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.
skipping to change at page 1, line 31 skipping to change at page 1, line 31
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 April 12, 2013. This Internet-Draft will expire on October 10, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3
1.1.1. Wrong Data Type Returned . . . . . . . . . . . . . . . 3 1.1.1. Cannot Retrieve Just the Non-Configuration Data . . . 3
1.1.2. No Last-Modified Indication or Time Filtering . . . . 3 1.1.2. No Last-Modified Indication or Time Filtering . . . . 3
1.1.3. No Simple Instance Discovery Mechanism . . . . . . . . 3 1.1.3. No Simple Instance Discovery Mechanism . . . . . . . . 3
1.1.4. No Subtree Depth Control . . . . . . . . . . . . . . . 4 1.1.4. No Subtree Depth Control . . . . . . . . . . . . . . . 4
1.1.5. Content Filter Specification is not Extensible . . . . 4 1.1.5. Content Filter Specification is not Extensible . . . . 4
1.1.6. Source of Operational Data Unknown . . . . . . . . . . 4 1.2. Solution . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Solution . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.3.1. NETCONF . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1. NETCONF . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.2. YANG . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3.2. YANG . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.3. Terms . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3.3. Terms . . . . . . . . . . . . . . . . . . . . . . . . 5
2. <get2> Operation . . . . . . . . . . . . . . . . . . . . . . . 7 2. <get2> Operation . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Depth Filters . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Depth Filters . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Time Filters . . . . . . . . . . . . . . . . . . . . . . . 8 2.2. Time Filters . . . . . . . . . . . . . . . . . . . . . . . 8
3. Operational Data Source Reporting . . . . . . . . . . . . . . 9 3. XSD for the "last-modified" Attribute . . . . . . . . . . . . 9
3.1. Identifying Data Sources . . . . . . . . . . . . . . . . . 9 4. <get2> YANG Module . . . . . . . . . . . . . . . . . . . . . . 10
4. XSD for the "last-modified" Attribute . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
5. XSD for the "data-source" Attribute . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. data-source YANG Module . . . . . . . . . . . . . . . . . . . 12 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7. <get2> YANG Module . . . . . . . . . . . . . . . . . . . . . . 15 7.1. 00-01 . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7.2. 01-02 . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 7.3. 02-03 . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 23 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. 00-01 . . . . . . . . . . . . . . . . . . . . . . . . . . 23 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19
10.2. 01-02 . . . . . . . . . . . . . . . . . . . . . . . . . . 23 8.2. Informative References . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . . 24 A.1. YANG Module Used in Examples . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . . 24 A.2. YANG Data Used in Examples . . . . . . . . . . . . . . . . 21
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 25 A.3. Example: If-Modified-Since Non-Empty Filter Retrieval . . 21
A.1. YANG Module Used in Examples . . . . . . . . . . . . . . . 25 A.4. Example: If-Modified-Since Empty Filter Retrieval . . . . 22
A.2. YANG Data Used in Examples . . . . . . . . . . . . . . . . 26 A.5. Example: Keys Only Filter Retrieval . . . . . . . . . . . 23
A.3. Example: Operational Datastore . . . . . . . . . . . . . . 26 A.6. Example: Testing for Node Existence with Depth=1 . . . . . 24
A.4. Example: If-Modified-Since Non-Empty Filter Retrieval . . 28 A.7. Example: Keys Only Filter Retrieval with Depth=3 . . . . . 25
A.5. Example: If-Modified-Since Empty Filter Retrieval . . . . 29 A.8. Example: Retrieve Only Non-Configuration Data Nodes . . . 26
A.6. Example: Keys Only Filter Retrieval . . . . . . . . . . . 30 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28
A.7. Example: Testing for Node Existence with Depth=1 . . . . . 31
A.8. Example: Keys Only Filter Retrieval with Depth=3 . . . . . 32
A.9. Example: Operational Data Sources (tree height) . . . . . 33
A.10. Example: Operational Data Sources (ietf-system) . . . . . 35
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
There is a need for standard mechanisms to allow NETCONF [RFC6241] There is a need for standard mechanisms to allow NETCONF [RFC6241]
application designers to retrieve data from NETCONF servers more application designers to retrieve data from NETCONF servers more
efficiently. efficiently.
1.1. Problem Statement 1.1. Problem Statement
This document attempts to address the following problems with NETCONF This document attempts to address the following problems with NETCONF
data retrieval mechanisms. data retrieval mechanisms.
1.1.1. Wrong Data Type Returned 1.1.1. Cannot Retrieve Just the Non-Configuration Data
The NETCONF <get> operation allows a client to retrieve data from the The NETCONF <get> operation allows a client to retrieve data from the
server but it returns all data, including configuration datastore server but it returns all data, including configuration datastore
nodes. The <get-config> operation already returns all configuration nodes. The <get-config> operation already returns all configuration
datastore nodes. datastore nodes.
It was originally thought that <get> should return all nodes so the It was originally thought that <get> should return all nodes so the
client would not have to correlate configuration and non- client would not have to correlate configuration and non-
configuration data nodes, since they would be mixed together in the configuration data nodes, since they would be mixed together in the
reply. reply.
skipping to change at page 4, line 34 skipping to change at page 4, line 34
This design does not allow additional content filter specification This design does not allow additional content filter specification
types to be supported by an implementation. It does not allow the types to be supported by an implementation. It does not allow the
standard to be easily extended in a modular fashion. standard to be easily extended in a modular fashion.
In addition, this design does not allow YANG statements to be used to In addition, this design does not allow YANG statements to be used to
properly describe the protocol operation. The special properly describe the protocol operation. The special
"get-filter-element-attributes" YANG extension in the ietf-netconf "get-filter-element-attributes" YANG extension in the ietf-netconf
module is not extensible, and it does not really count as proper module is not extensible, and it does not really count as proper
YANG, since this extension is outside the YANG language definition. YANG, since this extension is outside the YANG language definition.
1.1.6. Source of Operational Data Unknown
The operational data nodes returned by the server can sometimes
represent server state parameters which may be derived from different
sources.
For example, an operational node representing the current date and
time in use on a system might be derived from the Network Time
Protocol (NTP) or from an action operation to set the current time.
A list representing a routing entries in use in a router might
include entries learned from a routing protocol and entries
statically configured in the running datastore.
There is a need for standard mechanisms to:
o identify data-model specific sources of operational data.
o identify which nodes in a datastore that the server should
maintain data source information
o allow the client to retrieve the data source information.
1.2. Solution 1.2. Solution
This document defines a new NETCONF protocol operation called <get2> This document defines a new NETCONF protocol operation called <get2>
to address the deficiencies described in the previous section. It to address the deficiencies described in the previous section. It
can be implemented existing NETCONF servers without requiring a can be implemented existing NETCONF servers without requiring a
change in the protocol version. change in the protocol version.
1.3. Terminology 1.3. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 6, line 4 skipping to change at page 5, line 28
o server o server
o startup configuration datastore o startup configuration datastore
1.3.2. YANG 1.3.2. YANG
The following terms are defined in [RFC6020]: The following terms are defined in [RFC6020]:
o anyxml o anyxml
o container o container
o data node o data node
o key leaf o key leaf
o leaf o leaf
o leaf-list o leaf-list
o list o list
o presence container (or P-container) o presence container (or P-container)
o non-presence container (or NP-container) o non-presence container (or NP-container)
1.3.3. Terms 1.3.3. Terms
The following terms are defined: The following terms are defined:
o non-configuration data node: a data node which is not a
configuration data node, i.e. config=false.
o operational datastore: the collection of all conceptual YANG data
nodes which represent non-configuration data. This conceptual
datastore also includes ancestor container and list nodes for any
nested non-configuration data nodes, as well as list keys for any
list data nodes in this datastore.
o operational data node: A data node which is is contained within
the operational datastore. Ancestor container, list, and key leaf
nodes for any nested non-configuration nodes are only operational
data nodes if they are also non-configuration data nodes.
o depth filter: A mechanism implemented within the NETCONF server to o depth filter: A mechanism implemented within the NETCONF server to
allow a client to retrieve only a limited number of levels within allow a client to retrieve only a limited number of levels within
the a subtree, instead of retrieving the entire subtree. the a subtree, instead of retrieving the entire subtree.
o time filter: A mechanism implemented within the NETCONF server to o time filter: A mechanism implemented within the NETCONF server to
allow a client to retrieve only data that has been modified since allow a client to retrieve only data that has been modified since
a specified data and time. a specified data and time.
2. <get2> Operation 2. <get2> Operation
skipping to change at page 7, line 38 skipping to change at page 7, line 38
Section 2.2. Section 2.2.
o depth: A leaf indicating the subtree depth level for the retrieval o depth: A leaf indicating the subtree depth level for the retrieval
request, according to the procedures in Section 2.1. request, according to the procedures in Section 2.1.
o with-defaults: A leaf indicating the type of defaults handling o with-defaults: A leaf indicating the type of defaults handling
requested, according to procedures in [RFC6243]. requested, according to procedures in [RFC6243].
o with-timestamps: A leaf indicating that "last-modified" XML o with-timestamps: A leaf indicating that "last-modified" XML
attributes are requested, encoded according to the schema in attributes are requested, encoded according to the schema in
Section 4. Section 3.
o with-data-sources: A leaf indicating that "data-source" XML
attributes are requested, encoded according to the schema in
Section 5.
2.1. Depth Filters 2.1. Depth Filters
A depth filter indicates how many subtree levels should be returned A depth filter indicates how many subtree levels should be returned
in the <rpc-reply>. This filter is specified with the "depth" input in the <rpc-reply>. This filter is specified with the "depth" input
parameter for the <get2> protocol operation. The default "0" parameter for the <get2> protocol operation. The default "0"
indicates that all levels from the requested subtrees should be indicates that all levels from the requested subtrees should be
returned. returned.
A new level is started for each YANG data node within the requested A new level is started for each YANG data node within the requested
skipping to change at page 9, line 5 skipping to change at page 9, line 5
the specified value, then an empty <data> element will be returned in the specified value, then an empty <data> element will be returned in
the <rpc-reply>. the <rpc-reply>.
If the server maintains "last-modified" timestamps for any data nodes If the server maintains "last-modified" timestamps for any data nodes
within the source datastore then the same type of comparison will be within the source datastore then the same type of comparison will be
done for the data node to determine if it should be included in the done for the data node to determine if it should be included in the
response. If no "last-modified" timestamp is maintained for a data response. If no "last-modified" timestamp is maintained for a data
node, then the server will use the "last-modified" timestamp for its node, then the server will use the "last-modified" timestamp for its
nearest ancestor, or for the datastore itself if there are none. nearest ancestor, or for the datastore itself if there are none.
3. Operational Data Source Reporting 3. XSD for the "last-modified" Attribute
Operational data source reporting is supported if the server
advertises the "data-source" feature.
If the "with-data-sources" parameter is present in the <get2>
request, and the server supports the "data-source" feature, then data
source reporting will be done for the applicable nodes.
An operational data source applies only to operational data nodes,
and only if the "data-source" YANG extension statement defined in
Section 6 is present in the YANG data definition statement for the
data node.
If the "data-source" extension applies to a data node, then a server
that implements the "data-source" feature is expected to return the
"data-source" XML attribute for that node.
3.1. Identifying Data Sources
Operational data sources are defined with YANG identity statements.
The YANG module in Section 6 contains the base identity
"data-sources", and a few common data sources:
o server: normal case: the server instrumentation is the source of
the operational data value.
o running: the operational data value is derived from a value in the
running configuration datastore.
o operation: the operational data value is derived from a direct or
side effect of a client-initiated protocol operation.
o ntp: the operational data value is derived from NTP information
o dns: the operational data value is derived from DNS information
Other modules can define new data source identities, such as the
"thfp" protocol in the "example-get2" module.
The "data-source" YANG extension is defined in Section 6. It is used
within other YANG modules to identify which operational data nodes
should have data source information maintained by the server.
4. XSD for the "last-modified" Attribute
The following XML Schema document [XSD] defines the "last-modified" The following XML Schema document [XSD] defines the "last-modified"
attribute, described within this document. This XSD is only relevant attribute, described within this document. This XSD is only relevant
if the server supports the "timestamps" YANG feature within the if the server supports the "timestamps" YANG feature within the
"ietf-netconf-get2" YANG module. "ietf-netconf-get2" YANG module.
The "last-modified" attribute uses the XSD data type "dateTime", in The "last-modified" attribute uses the XSD data type "dateTime", in
accordance with Section 3.2.7.1 of XML Schema Part 2: Datatypes. accordance with Section 3.2.7.1 of XML Schema Part 2: Datatypes.
This is equivalent to the YANG data type "date-and-time". This is equivalent to the YANG data type "date-and-time".
skipping to change at page 11, line 5 skipping to change at page 10, line 5
a modification was last detected by the server a modification was last detected by the server
for the datastore or data node corresponding to for the datastore or data node corresponding to
the XML element containing this attribute. the XML element containing this attribute.
</xs:documentation> </xs:documentation>
</xs:annotation> </xs:annotation>
</xs:attribute> </xs:attribute>
</xs:schema> </xs:schema>
<CODE ENDS> <CODE ENDS>
5. XSD for the "data-source" Attribute 4. <get2> YANG Module
The following XML Schema document [XSD] defines the "data-source"
attribute, described within this document. This attribute uses the
XSD data type "QName", in accordance with Section 3.2.18.1 of XML
Schema Part 2: Datatypes.
This is an XML encoding of the YANG "identityref" data type:
o the module namespace statement value for the YANG module
containing the identity statement is represented in
the"namespace-name" part.
o the identity name is represented in the local part.
<CODE BEGINS> file "data-source.xsd"
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns:netconf:default:1.0"
targetNamespace="urn:ietf:params:xml:ns:netconf:data-source:1.0"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
xml:lang="en">
<xs:annotation>
<xs:documentation>
This schema defines the syntax for the "data-source" attribute
described within this document.
</xs:documentation>
</xs:annotation>
<!--
data-source attribute
-->
<xs:attribute name="data-source" type="xs:QName">
<xs:annotation>
<xs:documentation>
This attribute indicates the identity statement
for the configuration source for the data node
corresponding to the XML element containing this
attribute.
</xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:schema>
<CODE ENDS>
6. data-source YANG Module
RFC Ed.: update the date below with the date of RFC publication and
remove this note.
<CODE BEGINS> file "ietf-netconf-data-source@2012-10-09.yang"
module ietf-netconf-data-source {
namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-data-source";
prefix datasrc;
organization
"IETF NETCONF (Network Configuration Protocol) Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/netconf/>
WG List: <mailto:netconf@ietf.org>
WG Chair: Mehmet Ersue
<mailto:mehmet.ersue@nsn.com>
WG Chair: Bert Wijnen
<mailto:bertietf@bwijnen.net>
Editor: Andy Bierman
<mailto:andy@yumaworks.com>";
description
"This module contains a collection of YANG definitions for
identifying the data source of operational data nodes.
Copyright (c) 2012 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.";
// RFC Ed.: replace XXXX with actual RFC number and remove this
// note.
// RFC Ed.: remove this note
// Note: extracted from draft-bierman-netconf-get2-02.txt
// RFC Ed.: update the date below with the date of RFC publication
// and remove this note.
revision "2012-10-09" {
description
"Initial revision.";
reference
"RFC XXXX: The NETCONF <get2> Operation";
}
/* Extensions */
extension data-source {
description
"This extension indicates that the data node containing it
is expected to support the 'data-source' XML attribute
in replies for the <get2> operation.
This extension is ignored if it is not within a YANG
data definition statement for an operational data node.";
}
/* Identities */
identity data-sources {
description
"Base identity for all data sources.";
}
identity server {
base data-sources;
description
"Indicates the server instrumentation as the data source.";
}
identity running {
base data-sources;
description
"Indicates the running datastore as the data source.";
}
identity operation {
base data-sources;
description
"Indicates a client-initiated protocol operation as
the data source.";
}
identity ntp {
base data-sources;
description
"Indicates the NTP protocol as the data source.";
reference
"RFC 5905: Network Time Protocol Version 4:
Protocol and Algorithms Specification";
}
identity dns {
base data-sources;
description
"Indicates the DNS protocol as the data source.";
// reference TBD
}
}
<CODE ENDS>
7. <get2> YANG Module
This module imports the "with-defaults-parameters" grouping from This module imports the "with-defaults-parameters" grouping from
[RFC6243]. [RFC6243].
Several YANG features are imported from [RFC6241]. Several YANG features are imported from [RFC6241].
Some data types are imported from [RFC6021]. Some data types are imported from [RFC6021].
RFC Ed.: update the date below with the date of RFC publication and RFC Ed.: update the date below with the date of RFC publication and
remove this note. remove this note.
<CODE BEGINS> file "ietf-netconf-get2@2012-10-09.yang" <CODE BEGINS> file "ietf-netconf-get2@2013-04-08.yang"
module ietf-netconf-get2 { module ietf-netconf-get2 {
namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-get2"; namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-get2";
prefix get2; prefix get2;
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
} }
skipping to change at page 16, line 12 skipping to change at page 11, line 12
WG Chair: Bert Wijnen WG Chair: Bert Wijnen
<mailto:bertietf@bwijnen.net> <mailto:bertietf@bwijnen.net>
Editor: Andy Bierman Editor: Andy Bierman
<mailto:andy@yumaworks.com>"; <mailto:andy@yumaworks.com>";
description description
"This module contains a collection of YANG definitions for the "This module contains a collection of YANG definitions for the
retrieval of information from a NETCONF server. retrieval of information from a NETCONF server.
Copyright (c) 2012 IETF Trust and the persons identified as Copyright (c) 2013 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
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 // RFC Ed.: replace XXXX with actual RFC number and remove this
// note. // note.
// RFC Ed.: remove this note // RFC Ed.: remove this note
// Note: extracted from draft-bierman-netconf-get2-02.txt // Note: extracted from draft-bierman-netconf-get2-03.txt
// RFC Ed.: update the date below with the date of RFC publication // RFC Ed.: update the date below with the date of RFC publication
// and remove this note. // and remove this note.
revision "2012-10-09" { revision "2013-04-08" {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: The NETCONF <get2> Operation"; "RFC XXXX: The NETCONF <get2> Operation";
} }
/* Features */ /* Features */
feature timestamps { feature timestamps {
description description
skipping to change at page 17, line 22 skipping to change at page 12, line 22
feature with-defaults { feature with-defaults {
description description
"This feature indicates that the server supports the "This feature indicates that the server supports the
'with-defaults' parameter for the <get2> operation. 'with-defaults' parameter for the <get2> operation.
A NETCONF server SHOULD support this feature."; A NETCONF server SHOULD support this feature.";
reference reference
"RFC 6243: With-defaults Capability for NETCONF"; "RFC 6243: With-defaults Capability for NETCONF";
} }
feature data-sources {
description
"This feature indicates that the server supports the
'with-data-sources' parameter for the <get2> operation.
A NETCONF server SHOULD support this feature.";
reference
"RFC XXXX: The NETCONF <get2> Operation";
}
/* Protocol Operations */ /* Protocol Operations */
rpc get2 { rpc get2 {
description description
"Retrieve NETCONF datastore information"; "Retrieve NETCONF datastore information";
input { input {
container source { container source {
choice datastore-source { choice datastore-source {
default running; default running;
description description
skipping to change at page 18, line 8 skipping to change at page 12, line 48
description description
"The candidate configuration datastore is the "The candidate configuration datastore is the
retrieval source."; retrieval source.";
} }
leaf running { leaf running {
type empty; type empty;
description description
"The running configuration datastore is the "The running configuration datastore is the
retrieval source."; retrieval source.";
} }
leaf operational {
type empty;
description
"The collection of non-configuration
data nodes supported by the server is the
retrieval source.";
}
leaf startup { leaf startup {
if-feature nc:startup; if-feature nc:startup;
type empty; type empty;
description description
"The startup configuration datastore is the "The startup configuration datastore is the
retrieval source."; retrieval source.";
} }
leaf url { leaf url {
if-feature nc:url; if-feature nc:url;
type inet:uri; type inet:uri;
description description
"The URL-based configuration is the "The URL-based configuration is the
retrieval source."; retrieval source.";
} }
leaf nonconfig {
type empty;
description
"The retrieval source is the collection of all
non-configuration data nodes supported by the server.
Any ancestor container and/or list and list key nodes
are also returned. No other leafs or leaf-lists will
be included in the reply.
The server MAY return ancestor container, and/or list
and list key nodes that do not contain any
non-configuration nodes. This can occur for several
reasons, e.g., the implementation streams replies
and cannot defer instrumentation or access control
filtering of descendant data nodes.";
}
} }
} }
choice filter-spec { choice filter-spec {
anyxml subtree-filter { anyxml subtree-filter {
description description
"This parameter identifies the portions of the "This parameter identifies the portions of the
target datastore to retrieve."; target datastore to retrieve.";
reference "RFC 6241, Section 6."; reference "RFC 6241, Section 6.";
} }
skipping to change at page 20, line 8 skipping to change at page 15, line 8
type empty; type empty;
description description
"This parameter will cause the server to return "This parameter will cause the server to return
XML attributes identifying the last modification XML attributes identifying the last modification
time within one or more elements within the time within one or more elements within the
<rpc-reply>."; <rpc-reply>.";
reference "RFC XXXX, sections 2.2 and 3."; reference "RFC XXXX, sections 2.2 and 3.";
} }
leaf with-data-sources {
if-feature data-sources;
when "../source/operational";
type empty;
description
"This parameter will cause the server to return
XML attributes identifying the operational
data sources for elements within the
<rpc-reply> that support the 'data-source'
YANG extension statement.";
reference "RFC XXXX, sections 2.2 and 3.";
}
} }
output { output {
anyxml data { anyxml data {
description description
"Copy of the requested datastore subset which "Copy of the requested datastore subset which
matched the filter criteria (if any). matched the filter criteria (if any).
An empty data container indicates that the An empty data container indicates that the
request did not produce any results."; request did not produce any results.";
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
8. IANA Considerations 5. IANA Considerations
This document registers a URI in the IETF XML registry [RFC3688]. This document registers a URI in the IETF XML registry [RFC3688].
Following the format in RFC 3688, the following 2 registrations are Following the format in RFC 3688, the following registration is
requested to be made. requested:
URI: urn:ietf:params:xml:ns:yang:ietf-netconf-data-source
Registrant Contact: The NETCONF WG of the IETF.
XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-netconf-get2 URI: urn:ietf:params:xml:ns:yang:ietf-netconf-get2
Registrant Contact: The NETCONF WG of the IETF. Registrant Contact: The NETCONF WG of the IETF.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
This document registers 2 YANG modules in the YANG Module Names This document registers 1 YANG module in the YANG Module Names
registry [RFC6020]. registry [RFC6020].
name: ietf-netconf-data-source
namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-data-source
prefix: cfgsrc
reference: RFC XXXX
name: ietf-netconf-get2 name: ietf-netconf-get2
namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-get2 namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-get2
prefix: get2 prefix: get2
reference: RFC XXXX reference: RFC XXXX
9. Security Considerations 6. Security Considerations
This document does not introduce any new security concerns in This document does not introduce any new security concerns in
addition to those specified in [RFC6241], section 9. addition to those specified in [RFC6241], section 9.
10. Change Log 7. Change Log
-- RFC Ed.: remove this section before publication. -- RFC Ed.: remove this section before publication.
10.1. 00-01 7.1. 00-01
o removed subtree-filter YANG feature o removed subtree-filter YANG feature
o changed depth filter to exactly match the XML layering o changed depth filter to exactly match the XML layering
o renamed filter to subtree-filter o renamed filter to subtree-filter
o renamed select to xpath-filter o renamed select to xpath-filter
o added some new examples o added some new examples
10.2. 01-02 7.2. 01-02
o added operational data source support o added operational data source support
o added 'ietf-netconf-data-source' module o added 'ietf-netconf-data-source' module
o clarified terminology o clarified terminology
11. References 7.3. 02-03
11.1. Normative References o removed operational data source support since this problem needs
to be solved as part of the operational state work.
o removed 'operational' datastore from datastore-choice and replaced
it with a datastore value called 'nonconfig'
o removed ietf-netconf-data-source YANG module
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020, Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010. October 2010.
[RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021, [RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021,
October 2010. October 2010.
skipping to change at page 24, line 36 skipping to change at page 19, line 36
[XPATH] Clark, J. and S. DeRose, "XML Path Language (XPath) [XPATH] Clark, J. and S. DeRose, "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>.
[XSD] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes [XSD] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes
Second Edition", World Wide Web Consortium Second Edition", World Wide Web Consortium
Recommendation REC-xmlschema-2-20041028, October 2004, Recommendation REC-xmlschema-2-20041028, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>. <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
11.2. Informative References 8.2. Informative References
[I-D.ietf-netmod-system-mgmt]
Bierman, A. and B. Bjorklund, "YANG Data Model for System
Management", draft-ietf-netmod-system-mgmt-03 (work in
progress), September 2012.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
Appendix A. Examples Appendix A. Examples
A.1. YANG Module Used in Examples A.1. YANG Module Used in Examples
module example-get2 { module example-get2 {
namespace "http://example.com/ns/example-get2"; namespace "http://example.com/ns/example-get2";
prefix exget2; prefix exget2;
description "Module used in <get2> examples.";
import ietf-netconf-data-source { prefix datasrc; } revision 2013-04-08;
revision 2012-10-09;
identity thfp {
base datasrc:data-sources;
description
"The Tree Height Finder Protocol is
the source of the operational data.";
}
identity manual {
base datasrc:data-sources;
description
"The height was derived manually by on-site
measurement crews.";
}
container forests { container forests {
list forest { list forest {
key name; key name;
leaf name { leaf name {
type string; type string;
} }
leaf tree-count { leaf tree-count {
skipping to change at page 26, line 7 skipping to change at page 20, line 40
list tree { list tree {
key name; key name;
leaf name { leaf name {
type string; type string;
} }
leaf location { leaf location {
type string; type string;
} }
leaf height { leaf height {
datasrc:data-source;
config false; config false;
type decimal64 { type decimal64 {
fraction-digits 3; fraction-digits 3;
} }
units meters; units meters;
} }
} // list tree } // list tree
} // container trees } // container trees
} // list forest } // list forest
} // container forests } // container forests
skipping to change at page 26, line 37 skipping to change at page 21, line 21
list forest: "south": list forest: "south":
list tree: "banyan", "palm" list tree: "banyan", "palm"
The forests and trees are configured, which represent trees the The forests and trees are configured, which represent trees the
company has planted and growing over time. company has planted and growing over time.
The operational data (tree height) represents the data that the The operational data (tree height) represents the data that the
company monitors for each tree over time. company monitors for each tree over time.
There are 2 operational data sources for tree height data in this A.3. Example: If-Modified-Since Non-Empty Filter Retrieval
example:
o thfp: Tree Height Finder Protocol
o manual: Manual measurement by work crews
The north forest was measured with the mythical Tree Height Finder
protocol and the south forest was measured manually.
A.3. Example: Operational Datastore
This example simply retrieves the "forests" subtree data from the
operational datastore.
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get2 xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-get2">
<source>
<operational />
</source>
<subtree-filter>
<forests xmlns="http://example.com/ns/example-get2" />
</subtree-filter>
</get2>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-get2">
<forests xmlns="http://example.com/ns/example-get2">
<forest>
<name>north</name>
<tree-count>3</tree-count>
<trees>
<tree>
<name>birch</name>
<height>41.013</height>
</tree>
<tree>
<name>ash</name>
<height>16.523</height>
</tree>
<tree>
<name>maple</name>
<height>51.204</height>
</tree>
</trees>
</forest>
<forest>
<name>south</name>
<tree-count>2</tree-count>
<trees>
<tree>
<name>banyan</name>
<height>91.433</height>
</tree>
<tree>
<name>palm</name>
<height>83.439</height>
</tree>
</trees>
</forest>
</forests>
</data>
</rpc-reply>
A.4. Example: If-Modified-Since Non-Empty Filter Retrieval
In this example, the running datastore was last modified at In this example, the running datastore was last modified at
"2012-09-09T01:43:27Z" because the forest named "north" was modified "2012-09-09T01:43:27Z" because the forest named "north" was modified
at this time. at this time.
o The forest named "north" was last modified after the specified o The forest named "north" was last modified after the specified
"if-modified-since" timestamp. "if-modified-since" timestamp.
o The forest named "south" was last modified before the specified o The forest named "south" was last modified before the specified
"if-modified-since" timestamp. "if-modified-since" timestamp.
o The server maintains a last-modified timestamp for the running o The server maintains a last-modified timestamp for the running
datastore and the "forest" list entries. datastore and the "forest" list entries.
o The client is also requesting that timestamps be returned for the o The client is also requesting that timestamps be returned for the
nodes that have been modified. If any part of the "forest" nodes that have been modified. If any part of the "forest"
subtree is modified then this timestamp will be updated. subtree is modified then this timestamp will be updated.
<rpc message-id="102" <rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get2 xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-get2"> <get2 xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-get2">
<subtree-filter> <subtree-filter>
<forests xmlns="http://example.com/ns/example-get2" /> <forests xmlns="http://example.com/ns/example-get2" />
</subtree-filter> </subtree-filter>
<if-modified-since>2012-09-09T01:43:27Z</if-modified-since> <if-modified-since>2012-09-09T01:43:27Z</if-modified-since>
<with-timestamps /> <with-timestamps />
</get2> </get2>
</rpc> </rpc>
<rpc-reply message-id="102" <rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:lm="urn:ietf:params:xml:ns:netconf:last-modified:1.0"> xmlns:lm="urn:ietf:params:xml:ns:netconf:last-modified:1.0">
<data <data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-get2"
xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-get2" lm:last-modified="2012-09-09T02:00:00Z">
lm:last-modified="2012-09-09T02:00:00Z">
<forests xmlns="http://example.com/ns/example-get2"> <forests xmlns="http://example.com/ns/example-get2">
<forest lm:last-modified="2012-09-09T02:00:00Z"> <forest lm:last-modified="2012-09-09T02:00:00Z">
<name>north</name> <name>north</name>
<trees> <trees>
<tree> <tree>
<name>birch</name> <name>birch</name>
<location>hillside</location> <location>hillside</location>
</tree> </tree>
<tree> <tree>
<name>ash</name> <name>ash</name>
skipping to change at page 29, line 45 skipping to change at page 22, line 43
<tree> <tree>
<name>maple</name> <name>maple</name>
<location>east meadow</location> <location>east meadow</location>
</tree> </tree>
</trees> </trees>
</forest> </forest>
</forests> </forests>
</data> </data>
</rpc-reply> </rpc-reply>
A.5. Example: If-Modified-Since Empty Filter Retrieval A.4. Example: If-Modified-Since Empty Filter Retrieval
In this example the client has changed the if-modified-since In this example the client has changed the "if-modified-since"
timestamp to a time in the future. timestamp to a time in the future.
o No "forest" list entry has been modified since this time so an o No "forest" list entry has been modified since this time so an
empty data node is returned. empty data node is returned.
o Note that the last-modified timestamp is returned for the node o Note that the "last-modified" timestamp is returned for the node
representing the datastore, even though no data nodes have been representing the datastore, even though no data nodes have been
modified since the specified time. This allows the client to modified since the specified time. This allows the client to
easily retrieve the last-modified timestamp for the entire easily retrieve the last-modified timestamp for the entire
datastore. datastore.
<rpc message-id="103" <rpc message-id="102"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get2 xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-get2"> <get2 xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-get2">
<subtree-filter> <subtree-filter>
<forests xmlns="http://example.com/ns/example-get2" /> <forests xmlns="http://example.com/ns/example-get2" />
</subtree-filter> </subtree-filter>
<if-modified-since>2012-09-09T03:43:27Z</if-modified-since> <if-modified-since>2012-09-09T03:43:27Z</if-modified-since>
<with-timestamps /> <with-timestamps />
</get2> </get2>
</rpc> </rpc>
<rpc-reply message-id="103" <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"
xmlns:lm="urn:ietf:params:xml:ns:netconf:last-modified:1.0"> xmlns:lm="urn:ietf:params:xml:ns:netconf:last-modified:1.0">
<data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-get2" <data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-get2"
lm:last-modified="2012-09-09T02:00:00Z" /> lm:last-modified="2012-09-09T02:00:00Z" />
</rpc-reply> </rpc-reply>
A.6. Example: Keys Only Filter Retrieval A.5. Example: Keys Only Filter Retrieval
This example retrieves the names-only from the "forests" subtree in This example retrieves only the names from the "forests" subtree in
the running datastore. the running datastore.
o The default source (running) is used. o The default source (running) is used.
o The default depth="0" is used to retrieve all subtree levels. o The default depth="0" is used to retrieve all subtree levels.
o The xpath-filter is used instead of the subtree-filter o The "keys-only" leaf is set
o Whitespace added to xpath-filter element for display purposes only o The "forests" subtree is selected. The xpath-filter is used
<rpc message-id="104" instead of the subtree-filter.
o Whitespace added to xpath-filter element for display purposes
only.
<rpc message-id="103"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get2 xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-get2"> <get2 xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-get2">
<xpath-filter xmlns:ex=http://example.com/ns/example-get2"> <xpath-filter xmlns:ex=http://example.com/ns/example-get2">
/ex:forests /ex:forests
</xpath-filter> </xpath-filter>
<keys-only /> <keys-only />
</get2> </get2>
</rpc> </rpc>
<rpc-reply message-id="104" <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 xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-get2"> <data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-get2">
<forests xmlns="http://example.com/ns/example-get2"> <forests xmlns="http://example.com/ns/example-get2">
<forest> <forest>
<name>north</name> <name>north</name>
<trees> <trees>
<tree> <tree>
<name>birch</name> <name>birch</name>
</tree> </tree>
<tree> <tree>
skipping to change at page 31, line 47 skipping to change at page 24, line 48
</tree> </tree>
<tree> <tree>
<name>palm</name> <name>palm</name>
</tree> </tree>
</trees> </trees>
</forest> </forest>
</forests> </forests>
</data> </data>
</rpc-reply> </rpc-reply>
A.7. Example: Testing for Node Existence with Depth=1 A.6. Example: Testing for Node Existence with Depth=1
This example retrieves the "trees" node to determine which forests This example retrieves the "trees" node to determine which forests
have any trees. have any trees.
o Only 1 subtree level is requested, instead of the default of all o Only 1 subtree level is requested, instead of the default of all
levels. levels.
o The default source (running) is used. o The default source (running) is used.
o The "trees" subtree is selected.
o The depth parameter is set to "1" to only retrieve the requested o The depth parameter is set to "1" to only retrieve the requested
layer (trees) and its ancestor nodes and the configuration leaf layer "trees" and its ancestor nodes and the configuration leaf
nodes from each "forest" entry. nodes from each "forest" entry.
<rpc message-id="105" <rpc message-id="104"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get2 xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-get2"> <get2 xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-get2">
<subtree-filter> <subtree-filter>
<forests xmlns="http://example.com/ns/example-get2"> <forests xmlns="http://example.com/ns/example-get2">
<forest> <forest>
<trees /> <trees />
</forest> </forest>
</forests> </forests>
</subtree-filter> </subtree-filter>
<depth>1</depth> <depth>1</depth>
</get2> </get2>
</rpc> </rpc>
<rpc-reply message-id="105" <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 xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-get2"> <data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-get2">
<forests xmlns="http://example.com/ns/example-get2"> <forests xmlns="http://example.com/ns/example-get2">
<forest> <forest>
<name>north</name> <name>north</name>
<trees /> <trees />
</forest> </forest>
<forest> <forest>
<name>south</name> <name>south</name>
<trees /> <trees />
</forest> </forest>
</forests> </forests>
</data> </data>
</rpc-reply> </rpc-reply>
A.8. Example: Keys Only Filter Retrieval with Depth=3 A.7. Example: Keys Only Filter Retrieval with Depth=3
This example retrieves the names-only from the "forest" list within
the "forests" subtree, in the running datastore.
o Only 3 subtree levels are requested, instead of the default of all This example retrieves only the "name" leafs from the "forest" list
levels. within the "forests" subtree, in the running datastore.
o The default source (running) is used. o The default source (running) is used.
o The "keys-only" leaf is set
o The "forests" subtree is selected
o The depth parameter is set to "3" to only retrieve the requested o The depth parameter is set to "3" to only retrieve the requested
layer (forests), its child nodes (forest), and the key leaf nodes layer (forests), its child nodes (forest), and the key leaf nodes
from each "forest" entry. Without the "keys-only" parameter, from each "forest" entry. Without the "keys-only" parameter,
other leafs from the "forest" list would be returned as well. other leafs from the "forest" list would be returned as well.
<rpc message-id="106" <rpc message-id="105"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get2 xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-get2"> <get2 xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-get2">
<subtree-filter> <subtree-filter>
<forests xmlns="http://example.com/ns/example-get2" /> <forests xmlns="http://example.com/ns/example-get2" />
</subtree-filter> </subtree-filter>
<keys-only /> <keys-only />
<depth>3</depth> <depth>3</depth>
</get2> </get2>
</rpc> </rpc>
<rpc-reply message-id="106" <rpc-reply message-id="105"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-get2"> <data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-get2">
<forests xmlns="http://example.com/ns/example-get2"> <forests xmlns="http://example.com/ns/example-get2">
<forest> <forest>
<name>north</name> <name>north</name>
</forest> </forest>
<forest> <forest>
<name>south</name> <name>south</name>
</forest> </forest>
</forests> </forests>
</data> </data>
</rpc-reply> </rpc-reply>
A.9. Example: Operational Data Sources (tree height) A.8. Example: Retrieve Only Non-Configuration Data Nodes
This example simply retrieves the "forests" subtree data from the This example retrieves only the name leafs from the "forest" list
operational datastore, but requesting that data-source XML attributes within the "forests" subtree, in the running datastore.
be added as required in the reply.
<rpc message-id="107" o The "source" leaf is set to the "nonconfig" data source
o The "forests" subtree is selected
<rpc message-id="106"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get2 xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-get2"> <get2 xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-get2">
<source> <source><nonconfig /></source>
<operational />
</source>
<subtree-filter> <subtree-filter>
<forests xmlns="http://example.com/ns/example-get2" /> <forests xmlns="http://example.com/ns/example-get2" />
</subtree-filter> </subtree-filter>
<with-data-sources />
</get2> </get2>
</rpc> </rpc>
<rpc-reply message-id="107" <rpc-reply message-id="106"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
xmlns:ds="urn:ietf:params:xml:ns:netconf:data-source:1.0">
<data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-get2"> <data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-get2">
<forests xmlns="http://example.com/ns/example-get2" <forests xmlns="http://example.com/ns/example-get2">
xmlns:ex="http://example.com/ns/example-get2">
<forest> <forest>
<name>north</name> <name>north</name>
<tree-count>3</tree-count>
<trees> <trees>
<tree> <tree>
<name>birch</name> <name>birch</name>
<height ds:data-source="ex:thfp">41.013</height> <height>41.013</height>
</tree> </tree>
<tree> <tree>
<name>ash</name> <name>ash</name>
<height ds:data-source="ex:thfp">16.523</height> <height>16.523</height>
</tree> </tree>
<tree> <tree>
<name ds:data-source="ex:thfp">maple</name> <name>maple</name>
<height>51.204</height> <height>51.204</height>
</tree> </tree>
</trees> </trees>
</forest> </forest>
<forest> <forest>
<name>south</name> <name>south</name>
<tree-count>2</tree-count>
<trees> <trees>
<tree> <tree>
<name>banyan</name> <name>banyan</name>
<height ds:data-source="ex:manual">91.433</height> <height>91.433</height>
</tree> </tree>
<tree> <tree>
<name>palm</name> <name>palm</name>
<height ds:data-source="ex:manual">83.439</height> <height>83.439</height>
</tree> </tree>
</trees> </trees>
</forest> </forest>
</forests> </forests>
</data> </data>
</rpc-reply> </rpc-reply>
A.10. Example: Operational Data Sources (ietf-system)
This example shows how the data-source reporting can be used with a
real YANG module. The ietf-system module defined in
[I-D.ietf-netmod-system-mgmt] contains an operational data node
called "current-datetime". The data source for this node can either
be NTP or the "set-current-datetime" operation defined in the module.
To implement data source reporting, the "data-source" extension needs
to added to the "current-datetime" leaf as follows:
leaf current-datetime {
datasrc:data-source;
type yang:date-and-time;
config false;
description
"The current system date and time.";
}
The following example shows the retrieval of the "current-datetime"
leaf if the data source is NTP. The extra whitespace shown for the
"current-datetime" leaf is for display purposes only.
<rpc message-id="108"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get2 xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-get2">
<source>
<operational />
</source>
<subtree-filter>
<system xmlns="urn:ietf:params:xml:ns:yang:ietf-system">
<clock>
<current-datetime />
</clock>
</system>
</subtree-filter>
<with-data-sources />
</get2>
</rpc>
<rpc-reply message-id="108"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:ds="urn:ietf:params:xml:ns:netconf:data-source:1.0">
<data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-get2">
<system xmlns="urn:ietf:params:xml:ns:yang:ietf-system">
<clock>
<current-datetime ds:data-source="ds:ntp">
2012-09-09T01:11:27Z
</current-datetime>
</clock>
</system>
</data>
</rpc-reply>
The following example shows the retrieval of the "current-datetime"
leaf if the data source is the "set-current-datetime" operation. The
extra whitespace shown for the "current-datetime" leaf is for display
purposes only.
<rpc message-id="109"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get2 xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-get2">
<source>
<operational />
</source>
<subtree-filter>
<system xmlns="urn:ietf:params:xml:ns:yang:ietf-system">
<clock>
<current-datetime />
</clock>
</system>
</subtree-filter>
<with-data-sources />
</get2>
</rpc>
<rpc-reply message-id="109"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:ds="urn:ietf:params:xml:ns:netconf:data-source:1.0">
<data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-get2">
<system xmlns="urn:ietf:params:xml:ns:yang:ietf-system">
<clock>
<current-datetime ds:data-source="ds:operation">
2012-09-09T01:11:27Z
</current-datetime>
</clock>
</system>
</data>
</rpc-reply>
Author's Address Author's Address
Andy Bierman Andy Bierman
YumaWorks YumaWorks, Inc.
Email: andy@yumaworks.com Email: andy@yumaworks.com
 End of changes. 76 change blocks. 
583 lines changed or deleted 133 lines changed or added

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