draft-ietf-netmod-revised-datastores-10.txt | rfc8342.txt | |||
---|---|---|---|---|
Network Working Group M. Bjorklund | Internet Engineering Task Force (IETF) M. Bjorklund | |||
Internet-Draft Tail-f Systems | Request for Comments: 8342 Tail-f Systems | |||
Updates: 7950 (if approved) J. Schoenwaelder | Updates: 7950 J. Schoenwaelder | |||
Intended status: Standards Track Jacobs University | Category: Standards Track Jacobs University | |||
Expires: July 17, 2018 P. Shafer | ISSN: 2070-1721 P. Shafer | |||
K. Watsen | K. Watsen | |||
Juniper Networks | Juniper Networks | |||
R. Wilton | R. Wilton | |||
Cisco Systems | Cisco Systems | |||
January 13, 2018 | March 2018 | |||
Network Management Datastore Architecture | Network Management Datastore Architecture (NMDA) | |||
draft-ietf-netmod-revised-datastores-10 | ||||
Abstract | Abstract | |||
Datastores are a fundamental concept binding the data models written | Datastores are a fundamental concept binding the data models written | |||
in the YANG data modeling language to network management protocols | in the YANG data modeling language to network management protocols | |||
such as NETCONF and RESTCONF. This document defines an architectural | such as the Network Configuration Protocol (NETCONF) and RESTCONF. | |||
framework for datastores based on the experience gained with the | This document defines an architectural framework for datastores based | |||
initial simpler model, addressing requirements that were not well | on the experience gained with the initial simpler model, addressing | |||
supported in the initial model. This document updates RFC 7950. | requirements that were not well supported in the initial model. This | |||
document updates RFC 7950. | ||||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This is an Internet Standards Track document. | |||
provisions of BCP 78 and BCP 79. | ||||
Internet-Drafts are working documents of the Internet Engineering | ||||
Task Force (IETF). Note that other groups may also distribute | ||||
working documents as Internet-Drafts. The list of current Internet- | ||||
Drafts is at http://datatracker.ietf.org/drafts/current/. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | This document is a product of the Internet Engineering Task Force | |||
and may be updated, replaced, or obsoleted by other documents at any | (IETF). It represents the consensus of the IETF community. It has | |||
time. It is inappropriate to use Internet-Drafts as reference | received public review and has been approved for publication by the | |||
material or to cite them other than as "work in progress." | Internet Engineering Steering Group (IESG). Further information on | |||
Internet Standards is available in Section 2 of RFC 7841. | ||||
This Internet-Draft will expire on July 17, 2018. | Information about the current status of this document, any errata, | |||
and how to provide feedback on it may be obtained at | ||||
https://www.rfc-editor.org/info/rfc8342. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2018 IETF Trust and the persons identified as the | Copyright (c) 2018 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 | (https://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 | |||
2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Objectives ......................................................4 | |||
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 3. Terminology .....................................................5 | |||
4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 4. Background ......................................................8 | |||
4.1. Original Model of Datastores . . . . . . . . . . . . . . 8 | 4.1. Original Model of Datastores ...............................9 | |||
5. Architectural Model of Datastores . . . . . . . . . . . . . . 9 | 5. Architectural Model of Datastores ..............................11 | |||
5.1. Conventional Configuration Datastores . . . . . . . . . . 10 | 5.1. Conventional Configuration Datastores .....................12 | |||
5.1.1. The Startup Configuration Datastore (<startup>) . . . 11 | 5.1.1. The Startup Configuration Datastore (<startup>) ....12 | |||
5.1.2. The Candidate Configuration Datastore (<candidate>) . 11 | 5.1.2. The Candidate Configuration Datastore | |||
5.1.3. The Running Configuration Datastore (<running>) . . . 12 | (<candidate>) ......................................13 | |||
5.1.4. The Intended Configuration Datastore (<intended>) . . 12 | 5.1.3. The Running Configuration Datastore (<running>) ....13 | |||
5.2. Dynamic Configuration Datastores . . . . . . . . . . . . 13 | 5.1.4. The Intended Configuration Datastore (<intended>) ..13 | |||
5.3. The Operational State Datastore (<operational>) . . . . . 13 | 5.2. Dynamic Configuration Datastores ..........................14 | |||
5.3.1. Remnant Configuration . . . . . . . . . . . . . . . . 14 | 5.3. The Operational State Datastore (<operational>) ...........14 | |||
5.3.2. Missing Resources . . . . . . . . . . . . . . . . . . 15 | 5.3.1. Remnant Configuration ..............................16 | |||
5.3.3. System-controlled Resources . . . . . . . . . . . . . 15 | 5.3.2. Missing Resources ..................................16 | |||
5.3.4. Origin Metadata Annotation . . . . . . . . . . . . . 15 | 5.3.3. System-Controlled Resources ........................16 | |||
6. Implications on YANG . . . . . . . . . . . . . . . . . . . . 17 | 5.3.4. Origin Metadata Annotation .........................17 | |||
6.1. XPath Context . . . . . . . . . . . . . . . . . . . . . . 17 | 6. Implications on YANG ...........................................18 | |||
6.2. Invocation of Actions and RPCs . . . . . . . . . . . . . 18 | 6.1. XPath Context .............................................18 | |||
7. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 18 | 6.2. Invocation of Actions and RPCs ............................19 | |||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 | 7. YANG Modules ...................................................20 | |||
8.1. Updates to the IETF XML Registry . . . . . . . . . . . . 24 | 8. IANA Considerations ............................................26 | |||
8.2. Updates to the YANG Module Names Registry . . . . . . . . 24 | 8.1. Updates to the IETF XML Registry ..........................26 | |||
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 | 8.2. Updates to the YANG Module Names Registry .................27 | |||
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 | 9. Security Considerations ........................................27 | |||
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 | 10. References ....................................................28 | |||
11.1. Normative References . . . . . . . . . . . . . . . . . . 26 | 10.1. Normative References .....................................28 | |||
11.2. Informative References . . . . . . . . . . . . . . . . . 26 | 10.2. Informative References ...................................29 | |||
Appendix A. Guidelines for Defining Datastores . . . . . . . . . 27 | ||||
A.1. Define which YANG modules can be used in the datastore . 27 | Appendix A. Guidelines for Defining Datastores ....................31 | |||
A.2. Define which subset of YANG-modeled data applies . . . . 28 | A.1. Define Which YANG Modules Can Be Used in the Datastore .....31 | |||
A.3. Define how data is actualized . . . . . . . . . . . . . . 28 | A.2. Define Which Subset of YANG-Modeled Data Applies ...........31 | |||
A.4. Define which protocols can be used . . . . . . . . . . . 28 | A.3. Define How Data Is Actualized ..............................31 | |||
A.5. Define YANG identities for the datastore . . . . . . . . 28 | A.4. Define Which Protocols Can Be Used .........................31 | |||
Appendix B. Ephemeral Dynamic Configuration Datastore Example . 29 | A.5. Define YANG Identities for the Datastore ...................32 | |||
Appendix C. Example Data . . . . . . . . . . . . . . . . . . . . 30 | Appendix B. Example of an Ephemeral Dynamic Configuration | |||
C.1. System Example . . . . . . . . . . . . . . . . . . . . . 30 | Datastore .............................................32 | |||
C.2. BGP Example . . . . . . . . . . . . . . . . . . . . . . . 33 | Appendix C. Example Data ..........................................33 | |||
C.2.1. Datastores . . . . . . . . . . . . . . . . . . . . . 35 | C.1. System Example .............................................34 | |||
C.2.2. Adding a Peer . . . . . . . . . . . . . . . . . . . . 35 | C.2. BGP Example ................................................37 | |||
C.2.3. Removing a Peer . . . . . . . . . . . . . . . . . . . 36 | C.2.1. Datastores .............................................38 | |||
C.3. Interface Example . . . . . . . . . . . . . . . . . . . . 37 | C.2.2. Adding a Peer ..........................................38 | |||
C.3.1. Pre-provisioned Interfaces . . . . . . . . . . . . . 37 | C.2.3. Removing a Peer ........................................39 | |||
C.3.2. System-provided Interface . . . . . . . . . . . . . . 38 | C.3. Interface Example ..........................................40 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 | C.3.1. Pre-provisioned Interfaces .............................41 | |||
C.3.2. System-Provided Interface ..............................42 | ||||
Acknowledgments ...................................................43 | ||||
Authors' Addresses ................................................44 | ||||
1. Introduction | 1. Introduction | |||
This document provides an architectural framework for datastores as | This document provides an architectural framework for datastores as | |||
they are used by network management protocols such as NETCONF | they are used by network management protocols such as the Network | |||
[RFC6241], RESTCONF [RFC8040] and the YANG [RFC7950] data modeling | Configuration Protocol (NETCONF) [RFC6241], RESTCONF [RFC8040], and | |||
language. Datastores are a fundamental concept binding network | the YANG data modeling language [RFC7950]. Datastores are a | |||
management data models to network management protocols. Agreement on | fundamental concept binding network management data models to network | |||
a common architectural model of datastores ensures that data models | management protocols. Agreement on a common architectural model of | |||
can be written in a network management protocol agnostic way. This | datastores ensures that data models can be written in a way that is | |||
architectural framework identifies a set of conceptual datastores but | network management protocol agnostic. This architectural framework | |||
it does not mandate that all network management protocols expose all | identifies a set of conceptual datastores, but it does not mandate | |||
these conceptual datastores. This architecture is agnostic with | that all network management protocols expose all these conceptual | |||
regard to the encoding used by network management protocols. | datastores. This architecture is agnostic with regard to the | |||
encoding used by network management protocols. | ||||
This document updates RFC 7950 by refining the definition of the | This document updates RFC 7950 by refining the definition of the | |||
accessible tree for some XPath context (see Section 6.1) and the | accessible tree for some XML Path Language (XPath) context (see | |||
invocation context of operations (see Section 6.2). | Section 6.1) and the invocation context of operations (see | |||
Section 6.2). | ||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in | |||
14 [RFC2119] [RFC8174] when, and only when, they appear in all | BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | capitals, as shown here. | |||
2. Objectives | 2. Objectives | |||
Network management data objects can often take two different values, | Network management data objects can often take two different values: | |||
the value configured by the user or an application (configuration) | the value configured by the user or an application (configuration) | |||
and the value that the device is actually using (operational state). | and the value that the device is actually using (operational state). | |||
These two values may be different for a number of reasons, e.g., | These two values may be different for a number of reasons, e.g., | |||
system internal interactions with hardware, interaction with | system internal interactions with hardware, interaction with | |||
protocols or other devices, or simply the time it takes to propagate | protocols or other devices, or simply the time it takes to propagate | |||
a configuration change to the software and hardware components of a | a configuration change to the software and hardware components of a | |||
system. Furthermore, configuration and operational state data | system. Furthermore, configuration and operational state data | |||
objects may have different lifetimes. | objects may have different lifetimes. | |||
The original model of datastores required these data objects to be | The original model of datastores required these data objects to be | |||
modeled twice in the YANG schema, as "config true" objects and as | modeled twice in the YANG schema -- as "config true" objects and as | |||
"config false" objects. The convention adopted by the interfaces | "config false" objects. The convention adopted by the interfaces | |||
data model ([RFC7223]) and the IP data model ([RFC7277]) was using | data model [RFC8343] and the IP data model [RFC8344] was to use two | |||
two separate branches rooted at the root of the data tree, one branch | separate branches rooted at the root of the data tree: one branch for | |||
for configuration data objects and one branch for operational state | configuration data objects and one branch for operational state data | |||
data objects. | objects. | |||
The duplication of definitions and the ad-hoc separation of | The duplication of definitions and the ad hoc separation of | |||
operational state data from configuration data leads to a number of | operational state data from configuration data lead to a number of | |||
problems. Having configuration and operational state data in | problems. Having configuration and operational state data in | |||
separate branches in the data model is operationally complicated and | separate branches in the data model is operationally complicated and | |||
impacts the readability of module definitions. Furthermore, the | impacts the readability of module definitions. Furthermore, the | |||
relationship between the branches is not machine readable and filter | relationship between the branches is not machine readable, and filter | |||
expressions operating on configuration and on related operational | expressions operating on configuration and on related operational | |||
state are different. | state are different. | |||
With the revised architectural model of datastores defined in this | With the revised architectural model of datastores defined in this | |||
document, the data objects are defined only once in the YANG schema | document, the data objects are defined only once in the YANG schema | |||
but independent instantiations can appear in different datastores, | but independent instantiations can appear in different datastores, | |||
e.g., one for a configured value and another for an operationally | e.g., one for a configured value and another for an operationally | |||
used value. This provides a more elegant and simpler solution to the | used value. This provides a more elegant and simpler solution to the | |||
problem. | problem. | |||
The revised architectural model of datastores supports additional | The revised architectural model of datastores supports additional | |||
datastores for systems that support more advanced processing chains | datastores for systems that support more advanced processing chains | |||
converting configuration to operational state. For example, some | converting configuration to operational state. For example, some | |||
systems support configuration that is not currently used (so called | systems support configuration that is not currently used (so-called | |||
inactive configuration) or they support configuration templates that | "inactive configuration") or they support configuration templates | |||
are used to expand configuration data via a common template. | that are used to expand configuration data via a common template. | |||
3. Terminology | 3. Terminology | |||
This document defines the following terminology. Some of the terms | This document defines the following terminology. Some of the terms | |||
are revised definitions of terms originally defined in [RFC6241] and | are revised definitions of terms originally defined in [RFC6241] and | |||
[RFC7950] (see also section Section 4). The revised definitions are | [RFC7950] (see also Section 4). The revised definitions are | |||
semantically equivalent with the definitions found in [RFC6241] and | semantically equivalent to the definitions found in [RFC6241] and | |||
[RFC7950]. It is expected that the revised definitions provided in | [RFC7950]. It is expected that the revised definitions provided in | |||
this section will replace the definitions in [RFC6241] and [RFC7950] | this section will replace the definitions in [RFC6241] and [RFC7950] | |||
when these documents are revised. | when these documents are revised. | |||
o datastore: A conceptual place to store and access information. A | o datastore: A conceptual place to store and access information. A | |||
datastore might be implemented, for example, using files, a | datastore might be implemented, for example, using files, a | |||
database, flash memory locations, or combinations thereof. A | database, flash memory locations, or combinations thereof. A | |||
datastore maps to an instantiated YANG data tree. | datastore maps to an instantiated YANG data tree. | |||
o schema node: A node in the schema tree. The formal definition is | o schema node: A node in the schema tree. The formal definition is | |||
in RFC 7950. | provided in RFC 7950. | |||
o datastore schema: The combined set of schema nodes for all modules | o datastore schema: The combined set of schema nodes for all modules | |||
supported by a particular datastore, taking into consideration any | supported by a particular datastore, taking into consideration any | |||
deviations and enabled features for that datastore. | deviations and enabled features for that datastore. | |||
o configuration: Data that is required to get a device from its | o configuration: Data that is required to get a device from its | |||
initial default state into a desired operational state. This data | initial default state into a desired operational state. This data | |||
is modeled in YANG using "config true" nodes. Configuration can | is modeled in YANG using "config true" nodes. Configuration can | |||
originate from different sources. | originate from different sources. | |||
skipping to change at page 5, line 41 ¶ | skipping to change at page 6, line 14 ¶ | |||
o intended configuration: Configuration that is intended to be used | o intended configuration: Configuration that is intended to be used | |||
by the device. It represents the configuration after all | by the device. It represents the configuration after all | |||
configuration transformations to <running> have been performed and | configuration transformations to <running> have been performed and | |||
is the configuration that the system attempts to apply. | is the configuration that the system attempts to apply. | |||
o intended configuration datastore: A configuration datastore | o intended configuration datastore: A configuration datastore | |||
holding the complete intended configuration of the device. This | holding the complete intended configuration of the device. This | |||
datastore is referred to as "<intended>". | datastore is referred to as "<intended>". | |||
o configuration transformation: The addition, modification or | o configuration transformation: The addition, modification, or | |||
removal of configuration between the <running> and <intended> | removal of configuration between the <running> and <intended> | |||
datastores. Examples of configuration transformations include the | datastores. Examples of configuration transformations include the | |||
removal of inactive configuration and the configuration produced | removal of inactive configuration and the configuration produced | |||
through the expansion of templates. | through the expansion of templates. | |||
o conventional configuration datastore: One of the following set of | o conventional configuration datastore: One of the following set of | |||
configuration datastores: <running>, <startup>, <candidate>, and | configuration datastores: <running>, <startup>, <candidate>, and | |||
<intended>. These datastores share a common datastore schema, and | <intended>. These datastores share a common datastore schema, and | |||
protocol operations allow copying data between these datastores. | protocol operations allow copying data between these datastores. | |||
The term "conventional" is chosen as a generic umbrella term for | The term "conventional" is chosen as a generic umbrella term for | |||
skipping to change at page 6, line 28 ¶ | skipping to change at page 6, line 50 ¶ | |||
conventional nor dynamic configuration. | conventional nor dynamic configuration. | |||
o system configuration: Configuration that is supplied by the device | o system configuration: Configuration that is supplied by the device | |||
itself. | itself. | |||
o default configuration: Configuration that is not explicitly | o default configuration: Configuration that is not explicitly | |||
provided but for which a value defined in the data model is used. | provided but for which a value defined in the data model is used. | |||
o applied configuration: Configuration that is actively in use by a | o applied configuration: Configuration that is actively in use by a | |||
device. Applied configuration originates from conventional, | device. Applied configuration originates from conventional, | |||
dynamic, learned, system and default configuration. | dynamic, learned, system, and default configuration. | |||
o system state: The additional data on a system that is not | o system state: The additional data on a system that is not | |||
configuration, such as read-only status information and collected | configuration, such as read-only status information and collected | |||
statistics. System state is transient and modified by | statistics. System state is transient and modified by | |||
interactions with internal components or other systems. System | interactions with internal components or other systems. System | |||
state is modeled in YANG using "config false" nodes. | state is modeled in YANG using "config false" nodes. | |||
o operational state: The combination of applied configuration and | o operational state: The combination of applied configuration and | |||
system state. | system state. | |||
o operational state datastore: A datastore holding the complete | o operational state datastore: A datastore holding the complete | |||
operational state of the device. This datastore is referred to as | operational state of the device. This datastore is referred to as | |||
"<operational>". | "<operational>". | |||
o origin: A metadata annotation indicating the origin of a data | o origin: A metadata annotation indicating the origin of a | |||
item. | data item. | |||
o remnant configuration: Configuration that remains part of the | o remnant configuration: Configuration that remains part of the | |||
applied configuration for a period of time after it has been | applied configuration for a period of time after it has been | |||
removed from the intended configuration or dynamic configuration. | removed from the intended configuration or dynamic configuration. | |||
The time period may be minimal, or may last until all resources | The time period may be minimal or may last until all resources | |||
used by the newly-deleted configuration (e.g., network | used by the newly deleted configuration (e.g., network | |||
connections, memory allocations, file handles) have been | connections, memory allocations, file handles) have been | |||
deallocated. | deallocated. | |||
The following additional terms are not datastore specific but | The following additional terms are not datastore specific, but they | |||
commonly used and thus defined here as well: | are commonly used and are thus defined here as well: | |||
o client: An entity that can access YANG-defined data on a server, | o client: An entity that can access YANG-defined data on a server, | |||
over some network management protocol. | over some network management protocol. | |||
o server: An entity that provides access to YANG-defined data to a | o server: An entity that provides access to YANG-defined data to a | |||
client, over some network management protocol. | client, over some network management protocol. | |||
o notification: A server-initiated message indicating that a certain | o notification: A server-initiated message indicating that a certain | |||
event has been recognized by the server. | event has been recognized by the server. | |||
skipping to change at page 7, line 33 ¶ | skipping to change at page 8, line 18 ¶ | |||
o datastore: A conceptual place to store and access information. A | o datastore: A conceptual place to store and access information. A | |||
datastore might be implemented, for example, using files, a | datastore might be implemented, for example, using files, a | |||
database, flash memory locations, or combinations thereof. | database, flash memory locations, or combinations thereof. | |||
o configuration datastore: The datastore holding the complete set of | o configuration datastore: The datastore holding the complete set of | |||
configuration that is required to get a device from its initial | configuration that is required to get a device from its initial | |||
default state into a desired operational state. | default state into a desired operational state. | |||
YANG 1.1 [RFC7950] provides the following refinements when NETCONF is | YANG 1.1 [RFC7950] provides the following refinements when NETCONF is | |||
used with YANG (which is the usual case but note that NETCONF was | used with YANG (which is the usual case, but note that NETCONF was | |||
defined before YANG existed): | defined before YANG existed): | |||
o datastore: When modeled with YANG, a datastore is realized as an | o datastore: When modeled with YANG, a datastore is realized as an | |||
instantiated data tree. | instantiated data tree. | |||
o configuration datastore: When modeled with YANG, a configuration | o configuration datastore: When modeled with YANG, a configuration | |||
datastore is realized as an instantiated data tree with | datastore is realized as an instantiated data tree with | |||
configuration. | configuration. | |||
[RFC6244] defined operational state data as follows: | [RFC6244] defined operational state data as follows: | |||
o Operational state data is a set of data that has been obtained by | o Operational state data is a set of data that has been obtained by | |||
the system at runtime and influences the system's behavior similar | the system at runtime and influences the system's behavior similar | |||
to configuration data. In contrast to configuration data, | to configuration data. In contrast to configuration data, | |||
operational state is transient and modified by interactions with | operational state is transient and modified by interactions with | |||
internal components or other systems via specialized protocols. | internal components or other systems via specialized protocols. | |||
Section 4.3.3 of [RFC6244] discusses operational state and among | Section 4.3.3 of [RFC6244] discusses operational state and mentions, | |||
other things mentions the option to consider operational state as | among other things, the option to consider operational state as being | |||
being stored in another datastore. Section 4.4 of [RFC6244] then | stored in another datastore. Section 4.4 of [RFC6244] then concludes | |||
concludes that at the time of the writing, modeling state as distinct | that, at the time of its writing, modeling state as distinct leafs | |||
leafs and distinct branches is the recommended approach. | and distinct branches is the recommended approach. | |||
Implementation experience and requests from operators | Implementation experience and requests from operators [OpState-Reqs] | |||
[I-D.ietf-netmod-opstate-reqs], [I-D.openconfig-netmod-opstate] | [OpState-Modeling] indicate that the datastore model initially | |||
indicate that the datastore model initially designed for NETCONF and | designed for NETCONF and refined by YANG needs to be extended. In | |||
refined by YANG needs to be extended. In particular, the notion of | particular, the notion of intended configuration and applied | |||
intended configuration and applied configuration has developed. | configuration has developed. | |||
4.1. Original Model of Datastores | 4.1. Original Model of Datastores | |||
The following drawing shows the original model of datastores as it is | The following drawing shows the original model of datastores as it is | |||
currently used by NETCONF [RFC6241]: | currently used by NETCONF [RFC6241]: | |||
+-------------+ +-----------+ | +-------------+ +-----------+ | |||
| <candidate> | | <startup> | | | <candidate> | | <startup> | | |||
| (ct, rw) |<---+ +--->| (ct, rw) | | | (ct, rw) |<---+ +--->| (ct, rw) | | |||
+-------------+ | | +-----------+ | +-------------+ | | +-----------+ | |||
| | | | | | | | | | |||
| +-----------+ | | | +-----------+ | | |||
+-------->| <running> |<--------+ | +-------->| <running> |<--------+ | |||
| (ct, rw) | | | (ct, rw) | | |||
+-----------+ | +-----------+ | |||
| | | | |||
v | v | |||
operational state <--- control plane | operational state <--- control plane | |||
(cf, ro) | (cf, ro) | |||
ct = config true; cf = config false | ct = config true; cf = config false | |||
rw = read-write; ro = read-only | rw = read-write; ro = read-only | |||
boxes denote datastores | boxes denote datastores | |||
Figure 1 | Figure 1 | |||
Note that this diagram simplifies the model: read-only (ro) and read- | Note that this diagram simplifies the model: "read-only" (ro) and | |||
write (rw) is to be understood at a conceptual level. In NETCONF, | "read-write" (rw) are to be understood from the client's perspective, | |||
for example, support for <candidate> and <startup> is optional and | at a conceptual level. In NETCONF, for example, support for | |||
<running> does not have to be writable. Furthermore, <startup> can | <candidate> and <startup> is optional, and <running> does not have to | |||
only be modified by copying <running> to <startup> in the | be writable. Furthermore, <startup> can only be modified by copying | |||
standardized NETCONF datastore editing model. The RESTCONF protocol | <running> to <startup> in the standardized NETCONF datastore editing | |||
does not expose these differences and instead provides only a | model. The RESTCONF protocol does not expose these differences and | |||
writable unified datastore, which hides whether edits are done | instead provides only a writable unified datastore, which hides | |||
through <candidate> or by directly modifying <running> or via some | whether edits are done through <candidate>, by directly modifying | |||
other implementation specific mechanism. RESTCONF also hides how | <running>, or via some other implementation-specific mechanism. | |||
configuration is made persistent. Note that implementations may also | RESTCONF also hides how configuration is made persistent. Note that | |||
have additional datastores that can propagate changes to <running>. | implementations may also have additional datastores that can | |||
NETCONF explicitly mentions so called named datastores. | propagate changes to <running>. NETCONF explicitly mentions | |||
so-called "named datastores". | ||||
Some observations: | Some observations: | |||
o Operational state has not been defined as a datastore although | o Operational state has not been defined as a datastore, although | |||
there were proposals in the past to introduce an operational state | there were proposals in the past to introduce an operational state | |||
datastore. | datastore. | |||
o The NETCONF <get> operation returns the contents of <running> | o The NETCONF <get> operation returns the contents of <running> | |||
together with the operational state. It is therefore necessary | together with the operational state. It is therefore necessary | |||
that "config false" data is in a different branch than the "config | that "config false" data be in a different branch than the | |||
true" data if the operational state can have a different lifetime | "config true" data if the operational state can have a different | |||
compared to configuration or if configuration is not immediately | lifetime compared to configuration or if configuration is not | |||
or successfully applied. | immediately or successfully applied. | |||
o Several implementations have proprietary mechanisms that allow | o Several implementations have proprietary mechanisms that allow | |||
clients to store inactive data in <running>. Inactive data is | clients to store inactive data in <running>. Inactive data is | |||
conceptually removed before validation. | conceptually removed before validation. | |||
o Some implementations have proprietary mechanisms that allow | o Some implementations have proprietary mechanisms that allow | |||
clients to define configuration templates in <running>. These | clients to define configuration templates in <running>. These | |||
templates are expanded automatically by the system, and the | templates are expanded automatically by the system, and the | |||
resulting configuration is applied internally. | resulting configuration is applied internally. | |||
o Some operators have reported that it is essential for them to be | o Some operators have reported that it is essential for them to be | |||
able to retrieve the configuration that has actually been | able to retrieve the configuration that has actually been | |||
successfully applied, which may be a subset or a superset of the | successfully applied, which may be a subset or a superset of the | |||
<running> configuration. | <running> configuration. | |||
5. Architectural Model of Datastores | 5. Architectural Model of Datastores | |||
Below is a new conceptual model of datastores extending the original | Below is a new conceptual model of datastores, extending the original | |||
model in order to reflect the experience gained with the original | model in order to reflect the experience gained with the original | |||
model. | model. | |||
+-------------+ +-----------+ | +-------------+ +-----------+ | |||
| <candidate> | | <startup> | | | <candidate> | | <startup> | | |||
| (ct, rw) |<---+ +--->| (ct, rw) | | | (ct, rw) |<---+ +--->| (ct, rw) | | |||
+-------------+ | | +-----------+ | +-------------+ | | +-----------+ | |||
| | | | | | | | | | |||
| +-----------+ | | | +-----------+ | | |||
+-------->| <running> |<--------+ | +-------->| <running> |<--------+ | |||
skipping to change at page 11, line 37 ¶ | skipping to change at page 12, line 46 ¶ | |||
boots. <startup> is only present on devices that separate the | boots. <startup> is only present on devices that separate the | |||
startup configuration from the running configuration datastore. | startup configuration from the running configuration datastore. | |||
The startup configuration datastore may not be supported by all | The startup configuration datastore may not be supported by all | |||
protocols or implementations. | protocols or implementations. | |||
On devices that support non-volatile storage, the contents of | On devices that support non-volatile storage, the contents of | |||
<startup> will typically persist across reboots via that storage. At | <startup> will typically persist across reboots via that storage. At | |||
boot time, the device loads the saved startup configuration into | boot time, the device loads the saved startup configuration into | |||
<running>. To save a new startup configuration, data is copied to | <running>. To save a new startup configuration, data is copied to | |||
<startup>, either via implicit or explicit protocol operations. | <startup> via either implicit or explicit protocol operations. | |||
5.1.2. The Candidate Configuration Datastore (<candidate>) | 5.1.2. The Candidate Configuration Datastore (<candidate>) | |||
The candidate configuration datastore (<candidate>) is a | The candidate configuration datastore (<candidate>) is a | |||
configuration datastore that can be manipulated without impacting the | configuration datastore that can be manipulated without impacting the | |||
device's current configuration and that can be committed to | device's current configuration and that can be committed to | |||
<running>. | <running>. | |||
The candidate configuration datastore may not be supported by all | The candidate configuration datastore may not be supported by all | |||
protocols or implementations. | protocols or implementations. | |||
skipping to change at page 12, line 29 ¶ | skipping to change at page 13, line 42 ¶ | |||
If a device does not have a distinct <startup> and non-volatile | If a device does not have a distinct <startup> and non-volatile | |||
storage is available, the device will typically use that non-volatile | storage is available, the device will typically use that non-volatile | |||
storage to allow <running> to persist across reboots. | storage to allow <running> to persist across reboots. | |||
5.1.4. The Intended Configuration Datastore (<intended>) | 5.1.4. The Intended Configuration Datastore (<intended>) | |||
The intended configuration datastore (<intended>) is a read-only | The intended configuration datastore (<intended>) is a read-only | |||
configuration datastore. It represents the configuration after all | configuration datastore. It represents the configuration after all | |||
configuration transformations to <running> are performed (e.g., | configuration transformations to <running> are performed (e.g., | |||
template expansion, removal of inactive configuration), and is the | template expansion, removal of inactive configuration) and is the | |||
configuration that the system attempts to apply. | configuration that the system attempts to apply. | |||
<intended> is tightly coupled to <running>. Whenever data is written | <intended> is tightly coupled to <running>. Whenever data is written | |||
to <running>, then <intended> MUST also be immediately updated by | to <running>, the server MUST also immediately update and validate | |||
performing all necessary configuration transformations to the | <intended>. | |||
contents of <running> and then <intended> is validated. | ||||
<intended> MAY also be updated independently of <running> if the | <intended> MAY also be updated independently of <running> if the | |||
effect of a configuration transformation changes, but <intended> MUST | effect of a configuration transformation changes, but <intended> MUST | |||
always be a valid configuration data tree, as defined in Section 8.1 | always be a valid configuration data tree, as defined in Section 8.1 | |||
of [RFC7950]. | of [RFC7950]. | |||
For simple implementations, <running> and <intended> are identical. | For simple implementations, <running> and <intended> are identical. | |||
The contents of <intended> are also related to the "config true" | The contents of <intended> are also related to the "config true" | |||
subset of <operational>, and hence a client can determine to what | subset of <operational>; hence, a client can determine to what extent | |||
extent the intended configuration is currently in use by checking | the intended configuration is currently in use by checking to see | |||
whether the contents of <intended> also appear in <operational>. | whether the contents of <intended> also appear in <operational>. | |||
<intended> does not persist across reboots; its relationship with | <intended> does not persist across reboots; its relationship with | |||
<running> makes that unnecessary. | <running> makes that unnecessary. | |||
Currently there are no standard mechanisms defined that affect | Currently, there are no standard mechanisms defined that affect | |||
<intended> so that it would have different content than <running>, | <intended> so that it would have different content than <running>, | |||
but this architecture allows for such mechanisms to be defined. | but this architecture allows for such mechanisms to be defined. | |||
One example of such a mechanism is support for marking nodes as | One example of such a mechanism is support for marking nodes as | |||
inactive in <running>. Inactive nodes are not copied to <intended>. | inactive in <running>. Inactive nodes are not copied to <intended>. | |||
A second example is support for templates, which can perform | A second example is support for templates, which can perform | |||
transformations on the configuration from <running> to the | transformations on the configuration from <running> to the | |||
configuration written to <intended>. | configuration written to <intended>. | |||
5.2. Dynamic Configuration Datastores | 5.2. Dynamic Configuration Datastores | |||
The model recognizes the need for dynamic configuration datastores | The model recognizes the need for dynamic configuration datastores | |||
that are, by definition, not part of the persistent configuration of | that are, by definition, not part of the persistent configuration of | |||
a device. In some contexts, these have been termed ephemeral | a device. In some contexts, these have been termed "ephemeral | |||
datastores since the information is ephemeral, i.e., lost upon | datastores", since the information is ephemeral, i.e., lost upon | |||
reboot. The dynamic configuration datastores interact with the rest | reboot. The dynamic configuration datastores interact with the rest | |||
of the system through <operational>. | of the system through <operational>. | |||
The datastore schema for a dynamic configuration datastore MAY differ | The datastore schema for a dynamic configuration datastore MAY differ | |||
from the datastore schema used for conventional configuration | from the datastore schema used for conventional configuration | |||
datastores. If a module does not contain any configuration data | datastores. If a module does not contain any configuration data | |||
nodes and it is not needed to satisfy any imports, then it MAY be | nodes and it is not needed to satisfy any imports, then it MAY be | |||
omitted from the datastore schema for the dynamic configuration | omitted from the datastore schema for the dynamic configuration | |||
datastore. | datastore. | |||
5.3. The Operational State Datastore (<operational>) | 5.3. The Operational State Datastore (<operational>) | |||
The operational state datastore (<operational>) is a read-only | The operational state datastore (<operational>) is a read-only | |||
datastore that consists of all "config true" and "config false" nodes | datastore that consists of all "config true" and "config false" nodes | |||
defined in the datastore's schema. In the original NETCONF model the | defined in the datastore's schema. In the original NETCONF model, | |||
operational state only had "config false" nodes. The reason for | the operational state only had "config false" nodes. The reason for | |||
incorporating "config true" nodes here is to be able to expose all | incorporating "config true" nodes here is to be able to expose all | |||
operational settings without having to replicate definitions in the | operational settings without having to replicate definitions in the | |||
data models. | data models. | |||
<operational> contains system state and all configuration actually | <operational> contains system state and all configuration actually | |||
used by the system. This includes all applied configuration from | used by the system. This includes all applied configuration from | |||
<intended>, learned configuration, system-provided configuration, and | <intended>, learned configuration, system-provided configuration, and | |||
default values defined by any supported data models. In addition, | default values defined by any supported data models. In addition, | |||
<operational> also contains applied configuration from dynamic | <operational> also contains applied configuration from dynamic | |||
configuration datastores. | configuration datastores. | |||
The datastore schema for <operational> MUST be a superset of the | The datastore schema for <operational> MUST be a superset of the | |||
combined datastore schema used in all configuration datastores except | combined datastore schema used in all configuration datastores, | |||
that configuration data nodes supported in a configuration datastore | except that configuration data nodes supported in a configuration | |||
MAY be omitted from <operational> if a server is not able to | datastore MAY be omitted from <operational> if a server is not able | |||
accurately report them. | to accurately report them. | |||
Requests to retrieve nodes from <operational> always return the value | Requests to retrieve nodes from <operational> always return the value | |||
in use if the node exists, regardless of any default value specified | in use if the node exists, regardless of any default value specified | |||
in the YANG module. If no value is returned for a given node, then | in the YANG module. If no value is returned for a given node, then | |||
this implies that the node is not used by the device. | this implies that the node is not used by the device. | |||
The interpretation of what constitutes as being "in use" by the | The interpretation of what constitutes being "in use" by the system | |||
system is dependent on both the schema definition and the device | is dependent on both the schema definition and the device | |||
implementation. Generally, functionality that is enabled and | implementation. Generally, functionality that is enabled and | |||
operational on the system would be considered as being "in use". | operational on the system would be considered to be "in use". | |||
Conversely, functionality that is neither enabled nor operational on | Conversely, functionality that is neither enabled nor operational on | |||
the system is considered as not being "in use", and hence SHOULD be | the system is considered not to be "in use"; hence, it SHOULD be | |||
omitted from <operational>. | omitted from <operational>. | |||
<operational> SHOULD conform to any constraints specified in the data | <operational> SHOULD conform to any constraints specified in the data | |||
model, but given the principal aim of returning "in use" values, it | model, but given the principal aim of returning "in use" values, it | |||
is possible that constraints MAY be violated under some | is possible that constraints MAY be violated under some circumstances | |||
circumstances, e.g., an abnormal value is "in use", the structure of | (e.g., an abnormal value is "in use", the structure of a list is | |||
a list is being modified, or due to remnant configuration (see | being modified, or remnant configuration (see Section 5.3.1) still | |||
Section 5.3.1). Note, that deviations SHOULD be used when it is | exists). Note that deviations SHOULD be used when it is known in | |||
known in advance that a device does not fully conform to the | advance that a device does not fully conform to the <operational> | |||
<operational> schema. | schema. | |||
Only semantic constraints MAY be violated, these are the YANG "when", | Only semantic constraints MAY be violated. These are the YANG | |||
"must", "mandatory", "unique", "min-elements", and "max-elements" | "when", "must", "mandatory", "unique", "min-elements", and | |||
statements; and the uniqueness of key values. | "max-elements" statements; and the uniqueness of key values. | |||
Syntactic constraints MUST NOT be violated, including hierarchical | Syntactic constraints MUST NOT be violated, including hierarchical | |||
organization, identifiers, and type-based constraints. If a node in | organization, identifiers, and type-based constraints. If a node in | |||
<operational> does not meet the syntactic constraints then it MUST | <operational> does not meet the syntactic constraints, then it | |||
NOT be returned, and some other mechanism should be used to flag the | MUST NOT be returned, and some other mechanism should be used to flag | |||
error. | the error. | |||
<operational> does not persist across reboots. | <operational> does not persist across reboots. | |||
5.3.1. Remnant Configuration | 5.3.1. Remnant Configuration | |||
Changes to configuration may take time to percolate through to | Changes to configuration may take time to percolate through to | |||
<operational>. During this period, <operational> may contain nodes | <operational>. During this period, <operational> may contain nodes | |||
for both the previous and current configuration, as closely as | for both the previous and current configuration, as closely as | |||
possible tracking the current operation of the device. Such remnant | possible tracking the current operation of the device. Such remnant | |||
configuration from the previous configuration persists until the | configuration from the previous configuration persists until the | |||
system has released resources used by the newly-deleted configuration | system has released resources used by the newly deleted configuration | |||
(e.g., network connections, memory allocations, file handles). | (e.g., network connections, memory allocations, file handles). | |||
Remnant configuration is a common example of where the semantic | Remnant configuration is a common example of where the semantic | |||
constraints defined in the data model cannot be relied upon for | constraints defined in the data model cannot be relied upon for | |||
<operational>, since the system may have remnant configuration whose | <operational>, since the system may have remnant configuration whose | |||
constraints were valid with the previous configuration and that are | constraints were valid with the previous configuration and that are | |||
not valid with the current configuration. Since constraints on | not valid with the current configuration. Since constraints on | |||
"config false" nodes may refer to "config true" nodes, remnant | "config false" nodes may refer to "config true" nodes, remnant | |||
configuration may force the violation of those constraints. | configuration may force the violation of those constraints. | |||
skipping to change at page 15, line 24 ¶ | skipping to change at page 16, line 39 ¶ | |||
A typical example is an interface configuration that refers to an | A typical example is an interface configuration that refers to an | |||
interface that is not currently present. In such a situation, the | interface that is not currently present. In such a situation, the | |||
interface configuration remains in <intended> but the interface | interface configuration remains in <intended> but the interface | |||
configuration will not appear in <operational>. | configuration will not appear in <operational>. | |||
Note that configuration validity cannot depend on the current state | Note that configuration validity cannot depend on the current state | |||
of such resources, since that would imply that removing a resource | of such resources, since that would imply that removing a resource | |||
might render the configuration invalid. This is unacceptable, | might render the configuration invalid. This is unacceptable, | |||
especially given that rebooting such a device would cause it to | especially given that rebooting such a device would cause it to | |||
restart with an invalid configuration. Instead we allow | restart with an invalid configuration. Instead, we allow | |||
configuration for missing resources to exist in <running> and | configuration for missing resources to exist in <running> and | |||
<intended>, but it will not appear in <operational>. | <intended>, but it will not appear in <operational>. | |||
5.3.3. System-controlled Resources | 5.3.3. System-Controlled Resources | |||
Sometimes resources are controlled by the device and the | Sometimes, resources are controlled by the device and the | |||
corresponding system controlled data appears in (and disappears from) | corresponding system-controlled data appears in (and disappears from) | |||
<operational> dynamically. If a system controlled resource has | <operational> dynamically. If a system-controlled resource has | |||
matching configuration in <intended> when it appears, the system will | matching configuration in <intended> when it appears, the system will | |||
try to apply the configuration, which causes the configuration to | try to apply the configuration; this causes the configuration to | |||
appear in <operational> eventually (if application of the | appear in <operational> eventually (if application of the | |||
configuration was successful). | configuration was successful). | |||
5.3.4. Origin Metadata Annotation | 5.3.4. Origin Metadata Annotation | |||
As configuration flows into <operational>, it is conceptually marked | As configuration flows into <operational>, it is conceptually marked | |||
with a metadata annotation ([RFC7952]) that indicates its origin. | with a metadata annotation [RFC7952] that indicates its origin. The | |||
The origin applies to all configuration nodes except non-presence | origin applies to all configuration nodes except non-presence | |||
containers. The "origin" metadata annotation is defined in | containers. The "origin" metadata annotation is defined in | |||
Section 7. The values are YANG identities. The following identities | Section 7. The values are YANG identities. The following identities | |||
are defined: | are defined: | |||
o origin: abstract base identity from which the other origin | o origin: abstract base identity from which the other origin | |||
identities are derived. | identities are derived. | |||
o intended: represents configuration provided by <intended>. | o intended: represents configuration provided by <intended>. | |||
o dynamic: represents configuration provided by a dynamic | o dynamic: represents configuration provided by a dynamic | |||
configuration datastore. | configuration datastore. | |||
o system: represents configuration provided by the system itself. | o system: represents configuration provided by the system itself. | |||
Examples of system configuration include applied configuration for | Examples of system configuration include applied configuration for | |||
an always existing loopback interface, or interface configuration | an always-existing loopback interface, or interface configuration | |||
that is auto-created due to the hardware currently present in the | that is auto-created due to the hardware currently present in the | |||
device. | device. | |||
o learned: represents configuration that has been learned via | o learned: represents configuration that has been learned via | |||
protocol interactions with other systems, including protocols such | protocol interactions with other systems, including such protocols | |||
as link-layer negotiations, routing protocols, DHCP, etc. | as link-layer negotiations, routing protocols, and DHCP. | |||
o default: represents configuration using a default value specified | o default: represents configuration using a default value specified | |||
in the data model, using either values in the "default" statement | in the data model, using either values in the "default" statement | |||
or any values described in the "description" statement. The | or any values described in the "description" statement. The | |||
default origin is only used when the configuration has not been | default origin is only used when the configuration has not been | |||
provided by any other source. | provided by any other source. | |||
o unknown: represents configuration for which the system cannot | o unknown: represents configuration for which the system cannot | |||
identify the origin. | identify the origin. | |||
These identities can be further refined, e.g., there could be | These identities can be further refined, e.g., there could be | |||
separate identities for particular types or instances of dynamic | separate identities for particular types or instances of dynamic | |||
configuration datastores derived from "dynamic". | configuration datastores derived from "dynamic". | |||
For all configuration data nodes in <operational>, the device SHOULD | For all configuration data nodes in <operational>, the device SHOULD | |||
report the origin that most accurately reflects the source of the | report the origin that most accurately reflects the source of the | |||
configuration that is in use by the system. | configuration that is in use by the system. | |||
In cases where it could be ambiguous as to which origin should be | In cases where it could be ambiguous as to which origin should be | |||
used, i.e. where the same data node value has originated from | used, i.e., where the same data node value has originated from | |||
multiple sources, then the description statement in the YANG module | multiple sources, the "description" statement in the YANG module | |||
SHOULD be used as guidance for choosing the appropriate origin. For | SHOULD be used as guidance for choosing the appropriate origin. For | |||
example: | example: | |||
If for a particular configuration node, the associated YANG | If, for a particular configuration node, the associated YANG | |||
description statement indicates that a protocol negotiated value | "description" statement indicates that a protocol-negotiated value | |||
overrides any configured value, then the origin would be reported as | overrides any configured value, then the origin would be reported as | |||
"learned", even when a learned value is the same as the configured | "learned", even when a learned value is the same as the configured | |||
value. | value. | |||
Conversely, if for a particular configuration node, the associated | Conversely, if, for a particular configuration node, the associated | |||
YANG description statement indicates that a protocol negotiated value | YANG "description" statement indicates that a protocol-negotiated | |||
does not override an explicitly configured value, then the origin | value does not override an explicitly configured value, then the | |||
would be reported as "intended" even when a learned value is the same | origin would be reported as "intended", even when a learned value is | |||
as the configured value. | the same as the configured value. | |||
In the case that a device cannot provide an accurate origin for a | In the case that a device cannot provide an accurate origin for a | |||
particular configuration data node then it SHOULD use the origin | particular configuration data node, it SHOULD use the origin | |||
"unknown". | "unknown". | |||
6. Implications on YANG | 6. Implications on YANG | |||
6.1. XPath Context | 6.1. XPath Context | |||
This section updates section 6.4.1 of RFC 7950. | This section updates Section 6.4.1 of RFC 7950. | |||
If a server implements the architecture defined in this document, the | If a server implements the architecture defined in this document, the | |||
accessible trees for some XPath contexts are refined as follows: | accessible trees for some XPath contexts are refined as follows: | |||
o If the XPath expression is defined in a substatement to a data | o If the XPath expression is defined in a substatement to a data | |||
node that represents system state, the accessible tree is all | node that represents system state, the accessible tree is all | |||
operational state in the server. The root node has all top-level | operational state in the server. The root node has all top-level | |||
data nodes in all modules as children. | data nodes in all modules as children. | |||
o If the XPath expression is defined in a substatement to a | o If the XPath expression is defined in a substatement to a | |||
skipping to change at page 18, line 7 ¶ | skipping to change at page 19, line 25 ¶ | |||
"output" statement in an "rpc" or "action" statement, the | "output" statement in an "rpc" or "action" statement, the | |||
accessible tree is the RPC or action operation instance and all | accessible tree is the RPC or action operation instance and all | |||
operational state in the server. The root node has top-level data | operational state in the server. The root node has top-level data | |||
nodes in all modules as children. Additionally, for an RPC, the | nodes in all modules as children. Additionally, for an RPC, the | |||
root node also has the node representing the RPC operation being | root node also has the node representing the RPC operation being | |||
defined as a child. The node representing the operation being | defined as a child. The node representing the operation being | |||
defined has the operation's output parameters as children. | defined has the operation's output parameters as children. | |||
6.2. Invocation of Actions and RPCs | 6.2. Invocation of Actions and RPCs | |||
This section updates section 7.15 of RFC 7950. | This section updates Section 7.15 of RFC 7950. | |||
Actions are always invoked in the context of the operational state | Actions are always invoked in the context of the operational state | |||
datastore. The node for which the action is invoked MUST exist in | datastore. The node for which the action is invoked MUST exist in | |||
the operational state datastore. | the operational state datastore. | |||
Note that this document does not constrain the result of invoking an | Note that this document does not constrain the result of invoking an | |||
RPC or action in any way. For example, an RPC might be defined to | RPC or action in any way. For example, an RPC might be defined to | |||
modify the contents of some datastore. | modify the contents of some datastore. | |||
7. YANG Modules | 7. YANG Modules | |||
<CODE BEGINS> file "ietf-datastores@2018-01-11.yang" | <CODE BEGINS> file "ietf-datastores@2018-02-14.yang" | |||
module ietf-datastores { | module ietf-datastores { | |||
yang-version 1.1; | yang-version 1.1; | |||
namespace "urn:ietf:params:xml:ns:yang:ietf-datastores"; | namespace "urn:ietf:params:xml:ns:yang:ietf-datastores"; | |||
prefix ds; | prefix ds; | |||
organization | organization | |||
"IETF Network Modeling (NETMOD) Working Group"; | "IETF Network Modeling (NETMOD) Working Group"; | |||
contact | contact | |||
skipping to change at page 18, line 50 ¶ | skipping to change at page 20, line 38 ¶ | |||
Author: Phil Shafer | Author: Phil Shafer | |||
<mailto:phil@juniper.net> | <mailto:phil@juniper.net> | |||
Author: Kent Watsen | Author: Kent Watsen | |||
<mailto:kwatsen@juniper.net> | <mailto:kwatsen@juniper.net> | |||
Author: Rob Wilton | Author: Rob Wilton | |||
<rwilton@cisco.com>"; | <rwilton@cisco.com>"; | |||
description | description | |||
"This YANG module defines two sets of identities for datastores. | "This YANG module defines a set of identities for identifying | |||
The first identifies the datastores themselves, the second | datastores. | |||
identifies datastore properties. | ||||
Copyright (c) 2018 IETF Trust and the persons identified as | Copyright (c) 2018 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 to | without modification, is permitted pursuant to, and subject to | |||
the license terms contained in, the Simplified BSD License set | the license terms contained in, the Simplified BSD License set | |||
forth in Section 4.c of the IETF Trust's Legal Provisions | 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). | (https://trustee.ietf.org/license-info). | |||
This version of this YANG module is part of RFC XXXX | This version of this YANG module is part of RFC 8342 | |||
(http://www.rfc-editor.org/info/rfcxxxx); see the RFC itself | (https://www.rfc-editor.org/info/rfc8342); see the RFC itself | |||
for full legal notices."; | for full legal notices."; | |||
revision 2018-01-11 { | revision 2018-02-14 { | |||
description | description | |||
"Initial revision."; | "Initial revision."; | |||
reference | reference | |||
"RFC XXXX: Network Management Datastore Architecture"; | "RFC 8342: Network Management Datastore Architecture (NMDA)"; | |||
} | } | |||
/* | /* | |||
* Identities | * Identities | |||
*/ | */ | |||
identity datastore { | identity datastore { | |||
description | description | |||
"Abstract base identity for datastore identities."; | "Abstract base identity for datastore identities."; | |||
} | } | |||
skipping to change at page 20, line 39 ¶ | skipping to change at page 22, line 33 ¶ | |||
* Type definitions | * Type definitions | |||
*/ | */ | |||
typedef datastore-ref { | typedef datastore-ref { | |||
type identityref { | type identityref { | |||
base datastore; | base datastore; | |||
} | } | |||
description | description | |||
"A datastore identity reference."; | "A datastore identity reference."; | |||
} | } | |||
} | } | |||
<CODE ENDS> | <CODE ENDS> | |||
<CODE BEGINS> file "ietf-origin@2018-02-14.yang" | ||||
<CODE BEGINS> file "ietf-origin@2018-01-11.yang" | ||||
module ietf-origin { | module ietf-origin { | |||
yang-version 1.1; | yang-version 1.1; | |||
namespace "urn:ietf:params:xml:ns:yang:ietf-origin"; | namespace "urn:ietf:params:xml:ns:yang:ietf-origin"; | |||
prefix or; | prefix or; | |||
import ietf-yang-metadata { | import ietf-yang-metadata { | |||
prefix md; | prefix md; | |||
} | } | |||
skipping to change at page 21, line 31 ¶ | skipping to change at page 23, line 39 ¶ | |||
Author: Phil Shafer | Author: Phil Shafer | |||
<mailto:phil@juniper.net> | <mailto:phil@juniper.net> | |||
Author: Kent Watsen | Author: Kent Watsen | |||
<mailto:kwatsen@juniper.net> | <mailto:kwatsen@juniper.net> | |||
Author: Rob Wilton | Author: Rob Wilton | |||
<rwilton@cisco.com>"; | <rwilton@cisco.com>"; | |||
description | description | |||
"This YANG module defines an 'origin' metadata annotation, and a | "This YANG module defines an 'origin' metadata annotation and a | |||
set of identities for the origin value. | set of identities for the origin value. | |||
Copyright (c) 2018 IETF Trust and the persons identified as | Copyright (c) 2018 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 to | without modification, is permitted pursuant to, and subject to | |||
the license terms contained in, the Simplified BSD License set | the license terms contained in, the Simplified BSD License set | |||
forth in Section 4.c of the IETF Trust's Legal Provisions | 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). | (https://trustee.ietf.org/license-info). | |||
This version of this YANG module is part of RFC XXXX | This version of this YANG module is part of RFC 8342 | |||
(http://www.rfc-editor.org/info/rfcxxxx); see the RFC itself | (https://www.rfc-editor.org/info/rfc8342); see the RFC itself | |||
for full legal notices."; | for full legal notices."; | |||
revision 2018-01-11 { | revision 2018-02-14 { | |||
description | description | |||
"Initial revision."; | "Initial revision."; | |||
reference | reference | |||
"RFC XXXX: Network Management Datastore Architecture"; | "RFC 8342: Network Management Datastore Architecture (NMDA)"; | |||
} | } | |||
/* | /* | |||
* Identities | * Identities | |||
*/ | */ | |||
identity origin { | identity origin { | |||
description | description | |||
"Abstract base identity for the origin annotation."; | "Abstract base identity for the origin annotation."; | |||
} | } | |||
identity intended { | identity intended { | |||
base origin; | base origin; | |||
description | description | |||
"Denotes configuration from the intended configuration | "Denotes configuration from the intended configuration | |||
datastore"; | datastore."; | |||
} | } | |||
identity dynamic { | identity dynamic { | |||
base origin; | base origin; | |||
description | description | |||
"Denotes configuration from a dynamic configuration | "Denotes configuration from a dynamic configuration | |||
datastore."; | datastore."; | |||
} | } | |||
identity system { | identity system { | |||
base origin; | base origin; | |||
description | description | |||
"Denotes configuration originated by the system itself. | "Denotes configuration originated by the system itself. | |||
Examples of system configuration include applied configuration | Examples of system configuration include applied configuration | |||
for an always existing loopback interface, or interface | for an always-existing loopback interface, or interface | |||
configuration that is auto-created due to the hardware | configuration that is auto-created due to the hardware | |||
currently present in the device."; | currently present in the device."; | |||
} | } | |||
identity learned { | identity learned { | |||
base origin; | base origin; | |||
description | description | |||
"Denotes configuration learned from protocol interactions with | "Denotes configuration learned from protocol interactions with | |||
other devices, instead of via either the intended | other devices, instead of via either the intended | |||
configuration datastore or any dynamic configuration | configuration datastore or any dynamic configuration | |||
datastore. | datastore. | |||
Examples of protocols that provide learned configuration | Examples of protocols that provide learned configuration | |||
include link-layer negotiations, routing protocols, and | include link-layer negotiations, routing protocols, and | |||
skipping to change at page 23, line 4 ¶ | skipping to change at page 25, line 15 ¶ | |||
base origin; | base origin; | |||
description | description | |||
"Denotes configuration learned from protocol interactions with | "Denotes configuration learned from protocol interactions with | |||
other devices, instead of via either the intended | other devices, instead of via either the intended | |||
configuration datastore or any dynamic configuration | configuration datastore or any dynamic configuration | |||
datastore. | datastore. | |||
Examples of protocols that provide learned configuration | Examples of protocols that provide learned configuration | |||
include link-layer negotiations, routing protocols, and | include link-layer negotiations, routing protocols, and | |||
DHCP."; | DHCP."; | |||
} | } | |||
identity default { | identity default { | |||
base origin; | base origin; | |||
description | description | |||
"Denotes configuration that does not have an configured or | "Denotes configuration that does not have a configured or | |||
learned value, but has a default value in use. Covers both | learned value but has a default value in use. Covers both | |||
values defined in a 'default' statement, and values defined | values defined in a 'default' statement and values defined | |||
via an explanation in a 'description' statement."; | via an explanation in a 'description' statement."; | |||
} | } | |||
identity unknown { | identity unknown { | |||
base origin; | base origin; | |||
description | description | |||
"Denotes configuration for which the system cannot identify the | "Denotes configuration for which the system cannot identify the | |||
origin."; | origin."; | |||
} | } | |||
skipping to change at page 23, line 45 ¶ | skipping to change at page 26, line 14 ¶ | |||
/* | /* | |||
* Metadata annotations | * Metadata annotations | |||
*/ | */ | |||
md:annotation origin { | md:annotation origin { | |||
type origin-ref; | type origin-ref; | |||
description | description | |||
"The 'origin' annotation can be present on any configuration | "The 'origin' annotation can be present on any configuration | |||
data node in the operational state datastore. It specifies | data node in the operational state datastore. It specifies | |||
from where the node originated. If not specified for a given | from where the node originated. If not specified for a given | |||
configuration data node then the origin is the same as the | configuration data node, then the origin is the same as the | |||
origin of its parent node in the data tree. The origin for | origin of its parent node in the data tree. The origin for | |||
any top level configuration data nodes must be specified."; | any top-level configuration data nodes must be specified."; | |||
} | } | |||
} | } | |||
<CODE ENDS> | <CODE ENDS> | |||
8. IANA Considerations | 8. IANA Considerations | |||
8.1. Updates to the IETF XML Registry | 8.1. Updates to the IETF XML Registry | |||
This document registers two URIs in the IETF XML registry [RFC3688]. | This document registers two URIs in the "IETF XML Registry" | |||
Following the format in [RFC3688], the following registrations are | [RFC3688]. Following the format in [RFC3688], the following | |||
requested: | registrations have been made: | |||
URI: urn:ietf:params:xml:ns:yang:ietf-datastores | URI: urn:ietf:params:xml:ns:yang:ietf-datastores | |||
Registrant Contact: The IESG. | Registrant Contact: The IESG. | |||
XML: N/A, the requested URI is an XML namespace. | XML: N/A; the requested URI is an XML namespace. | |||
URI: urn:ietf:params:xml:ns:yang:ietf-origin | URI: urn:ietf:params:xml:ns:yang:ietf-origin | |||
Registrant Contact: The IESG. | Registrant Contact: The IESG. | |||
XML: N/A, the requested URI is an XML namespace. | XML: N/A; the requested URI is an XML namespace. | |||
8.2. Updates to the YANG Module Names Registry | 8.2. Updates to the YANG Module Names Registry | |||
This document registers two YANG modules in the YANG Module Names | This document registers two YANG modules in the "YANG Module Names" | |||
registry [RFC6020]. Following the format in [RFC6020], the following | registry [RFC6020]. Following the format in [RFC6020], the following | |||
registrations are requested: | registrations have been made: | |||
name: ietf-datastores | name: ietf-datastores | |||
namespace: urn:ietf:params:xml:ns:yang:ietf-datastores | namespace: urn:ietf:params:xml:ns:yang:ietf-datastores | |||
prefix: ds | prefix: ds | |||
reference: RFC XXXX | reference: RFC 8342 | |||
name: ietf-origin | name: ietf-origin | |||
namespace: urn:ietf:params:xml:ns:yang:ietf-origin | namespace: urn:ietf:params:xml:ns:yang:ietf-origin | |||
prefix: or | prefix: or | |||
reference: RFC XXXX | reference: RFC 8342 | |||
9. Security Considerations | 9. Security Considerations | |||
This document discusses an architectural model of datastores for | This document discusses an architectural model of datastores for | |||
network management using NETCONF/RESTCONF and YANG. It has no | network management using NETCONF/RESTCONF and YANG. It has no | |||
security impact on the Internet. | security impact on the Internet. | |||
Although this document specifies several YANG modules, these modules | Although this document specifies several YANG modules, these modules | |||
only define identities and a metadata annotation, hence the "YANG | only define identities and a metadata annotation; hence, the "YANG | |||
module security guidelines" do not apply. | module security guidelines" [YANG-SEC] do not apply. | |||
The origin metadata annotation exposes the origin of values in the | The origin metadata annotation exposes the origin of values in the | |||
applied configuration. Origin information may provide hints that | applied configuration. Origin information may provide hints that | |||
certain control plane protocols are active on a device. Since origin | certain control-plane protocols are active on a device. Since origin | |||
information is tied to applied configuration values, it is only | information is tied to applied configuration values, it is only | |||
accessible to clients that have the permissions to read the applied | accessible to clients that have the permissions to read the applied | |||
configuration values. Security administrators should consider the | configuration values. Security administrators should consider the | |||
sensitivity of origin information while defining access control | sensitivity of origin information while defining access control | |||
rules. | rules. | |||
10. Acknowledgments | 10. References | |||
This document grew out of many discussions that took place since | ||||
2010. Several Internet-Drafts ([I-D.bjorklund-netmod-operational], | ||||
[I-D.wilton-netmod-opstate-yang], [I-D.ietf-netmod-opstate-reqs], | ||||
[I-D.kwatsen-netmod-opstate], [I-D.openconfig-netmod-opstate]) and | ||||
[RFC6244] touched on some of the problems of the original datastore | ||||
model. The following people were authors to these Internet-Drafts or | ||||
otherwise actively involved in the discussions that led to this | ||||
document: | ||||
o Lou Berger, LabN Consulting, L.L.C., <lberger@labn.net> | ||||
o Andy Bierman, YumaWorks, <andy@yumaworks.com> | ||||
o Marcus Hines, Google, <hines@google.com> | ||||
o Christian Hopps, Deutsche Telekom, <chopps@chopps.org> | ||||
o Balazs Lengyel, Ericsson, <balazs.lengyel@ericsson.com> | ||||
o Acee Lindem, Cisco Systems, <acee@cisco.com> | ||||
o Ladislav Lhotka, CZ.NIC, <lhotka@nic.cz> | ||||
o Thomas Nadeau, Brocade Networks, <tnadeau@lucidvision.com> | ||||
o Tom Petch, Engineering Networks Ltd, <ietfc@btconnect.com> | ||||
o Anees Shaikh, Google, <aashaikh@google.com> | ||||
o Rob Shakir, Google, <robjs@google.com> | ||||
o Jason Sterne, Nokia, <jason.sterne@nokia.co> | ||||
Juergen Schoenwaelder was partly funded by Flamingo, a Network of | ||||
Excellence project (ICT-318488) supported by the European Commission | ||||
under its Seventh Framework Programme. | ||||
11. References | 10.1. Normative References | |||
11.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, DOI 10.17487/ | Requirement Levels", BCP 14, RFC 2119, | |||
RFC2119, March 1997, <https://www.rfc-editor.org/info/ | DOI 10.17487/RFC2119, March 1997, | |||
rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., | [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., | |||
and A. Bierman, Ed., "Network Configuration Protocol | and A. Bierman, Ed., "Network Configuration Protocol | |||
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, | (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, | |||
<https://www.rfc-editor.org/info/rfc6241>. | <https://www.rfc-editor.org/info/rfc6241>. | |||
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", | [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", | |||
RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www | RFC 7950, DOI 10.17487/RFC7950, August 2016, | |||
.rfc-editor.org/info/rfc7950>. | <https://www.rfc-editor.org/info/rfc7950>. | |||
[RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", RFC | [RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", | |||
7952, DOI 10.17487/RFC7952, August 2016, <https://www.rfc- | RFC 7952, DOI 10.17487/RFC7952, August 2016, | |||
editor.org/info/rfc7952>. | <https://www.rfc-editor.org/info/rfc7952>. | |||
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF | [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF | |||
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, | Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, | |||
<https://www.rfc-editor.org/info/rfc8040>. | <https://www.rfc-editor.org/info/rfc8040>. | |||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in | |||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | RFC 2119 Key Words", BCP 14, RFC 8174, | |||
May 2017, <https://www.rfc-editor.org/info/rfc8174>. | DOI 10.17487/RFC8174, May 2017, | |||
<https://www.rfc-editor.org/info/rfc8174>. | ||||
11.2. Informative References | [W3C.REC-xml-20081126] | |||
Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and | ||||
F. Yergeau, "Extensible Markup Language (XML) 1.0 | ||||
(Fifth Edition)", World Wide Web Consortium Recommendation | ||||
REC-xml-20081126, November 2008, | ||||
<https://www.w3.org/TR/2008/REC-xml-20081126>. | ||||
[I-D.bjorklund-netmod-operational] | 10.2. Informative References | |||
Bjorklund, M. and L. Lhotka, "Operational Data in NETCONF | ||||
and YANG", draft-bjorklund-netmod-operational-00 (work in | ||||
progress), October 2012. | ||||
[I-D.ietf-netmod-opstate-reqs] | [NETMOD-Operational] | |||
Watsen, K. and T. Nadeau, "Terminology and Requirements | Bjorklund, M. and L. Lhotka, "Operational Data in NETCONF | |||
for Enhanced Handling of Operational State", draft-ietf- | and YANG", Work in Progress, draft-bjorklund-netmod- | |||
netmod-opstate-reqs-04 (work in progress), January 2016. | operational-00, October 2012. | |||
[I-D.kwatsen-netmod-opstate] | [OpState-Enhance] | |||
Watsen, K., Bierman, A., Bjorklund, M., and J. | Watsen, K., Bierman, A., Bjorklund, M., and J. | |||
Schoenwaelder, "Operational State Enhancements for YANG, | Schoenwaelder, "Operational State Enhancements for YANG, | |||
NETCONF, and RESTCONF", draft-kwatsen-netmod-opstate-02 | NETCONF, and RESTCONF", Work in Progress, draft-kwatsen- | |||
(work in progress), February 2016. | netmod-opstate-02, February 2016. | |||
[I-D.openconfig-netmod-opstate] | [OpState-Modeling] | |||
Shakir, R., Shaikh, A., and M. Hines, "Consistent Modeling | Shakir, R., Shaikh, A., and M. Hines, "Consistent Modeling | |||
of Operational State Data in YANG", draft-openconfig- | of Operational State Data in YANG", Work in Progress, | |||
netmod-opstate-01 (work in progress), July 2015. | draft-openconfig-netmod-opstate-01, July 2015. | |||
[I-D.wilton-netmod-opstate-yang] | [OpState-Reqs] | |||
Wilton, R., ""With-config-state" Capability for NETCONF/ | Watsen, K. and T. Nadeau, "Terminology and Requirements | |||
RESTCONF", draft-wilton-netmod-opstate-yang-02 (work in | for Enhanced Handling of Operational State", Work in | |||
progress), December 2015. | Progress, draft-ietf-netmod-opstate-reqs-04, January 2016. | |||
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, | [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, | |||
DOI 10.17487/RFC3688, January 2004, <https://www.rfc- | DOI 10.17487/RFC3688, January 2004, | |||
editor.org/info/rfc3688>. | <https://www.rfc-editor.org/info/rfc3688>. | |||
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for | [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for | |||
the Network Configuration Protocol (NETCONF)", RFC 6020, | the Network Configuration Protocol (NETCONF)", RFC 6020, | |||
DOI 10.17487/RFC6020, October 2010, <https://www.rfc- | DOI 10.17487/RFC6020, October 2010, | |||
editor.org/info/rfc6020>. | <https://www.rfc-editor.org/info/rfc6020>. | |||
[RFC6244] Shafer, P., "An Architecture for Network Management Using | [RFC6244] Shafer, P., "An Architecture for Network Management Using | |||
NETCONF and YANG", RFC 6244, DOI 10.17487/RFC6244, June | NETCONF and YANG", RFC 6244, DOI 10.17487/RFC6244, | |||
2011, <https://www.rfc-editor.org/info/rfc6244>. | June 2011, <https://www.rfc-editor.org/info/rfc6244>. | |||
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface | [RFC8343] Bjorklund, M., "A YANG Data Model for Interface | |||
Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, | Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, | |||
<https://www.rfc-editor.org/info/rfc7223>. | <https://www.rfc-editor.org/info/rfc8343>. | |||
[RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", RFC | [RFC8344] Bjorklund, M., "A YANG Data Model for IP Management", | |||
7277, DOI 10.17487/RFC7277, June 2014, <https://www.rfc- | RFC 8344, DOI 10.17487/RFC8344, March 2018, | |||
editor.org/info/rfc7277>. | <https://www.rfc-editor.org/info/rfc8344>. | |||
[With-config-state] | ||||
Wilton, R., ""With-config-state" Capability for | ||||
NETCONF/RESTCONF", Work in Progress, draft-wilton-netmod- | ||||
opstate-yang-02, December 2015. | ||||
[YANG-SEC] IETF, "YANG Security Guidelines", <https://trac.ietf.org/ | ||||
trac/ops/wiki/yang-security-guidelines>. | ||||
Appendix A. Guidelines for Defining Datastores | Appendix A. Guidelines for Defining Datastores | |||
The definition of a new datastore in this architecture should be | The definition of a new datastore in this architecture should be | |||
provided in a document (e.g., an RFC) purposed to the definition of | provided in a document (e.g., an RFC) purposed for defining the | |||
the datastore. When it makes sense, more than one datastore may be | datastore. When it makes sense, more than one datastore may be | |||
defined in the same document (e.g., when the datastores are logically | defined in the same document (e.g., when the datastores are logically | |||
connected). Each datastore's definition should address the points | connected). Each datastore's definition should address the points | |||
specified in the sections below. | specified in the subsections below. | |||
A.1. Define which YANG modules can be used in the datastore | A.1. Define Which YANG Modules Can Be Used in the Datastore | |||
Not all YANG modules may be used in all datastores. Some datastores | Not all YANG modules may be used in all datastores. Some datastores | |||
may constrain which data models can be used in them. If it is | may constrain which data models can be used in them. If it is | |||
desirable that a subset of all modules can be targeted to the | desirable that a subset of all modules can be targeted to the | |||
datastore, then the documentation defining the datastore must | datastore, then the documentation defining the datastore must | |||
indicate this. | indicate this. | |||
A.2. Define which subset of YANG-modeled data applies | A.2. Define Which Subset of YANG-Modeled Data Applies | |||
By default, the data in a datastore is modeled by all YANG statements | By default, the data in a datastore is modeled by all YANG statements | |||
in the available YANG modules. However, it is possible to specify | in the available YANG modules. However, it is possible to specify | |||
criteria that YANG statements must satisfy in order to be present in | criteria that YANG statements must satisfy in order to be present in | |||
a datastore. For instance, maybe only "config true" nodes, or | a datastore. For instance, maybe only "config true" nodes, or | |||
"config false" nodes that also have a specific YANG extension, are | "config false" nodes that also have a specific YANG extension, are | |||
present in the datastore. | present in the datastore. | |||
A.3. Define how data is actualized | A.3. Define How Data Is Actualized | |||
The new datastore must specify how it interacts with other | The new datastore must specify how it interacts with other | |||
datastores. | datastores. | |||
For example, the diagram in Section 5 depicts dynamic configuration | For example, the diagram in Section 5 depicts dynamic configuration | |||
datastores feeding into <operational>. How this interaction occurs | datastores feeding into <operational>. How this interaction occurs | |||
has to be defined by the particular dynamic configuration datastores. | has to be defined by the particular dynamic configuration datastores. | |||
In some cases, it may occur implicitly, as soon as the data is put | In some cases, it may occur implicitly, as soon as the data is put | |||
into the dynamic configuration datastore while, in other cases, an | into the dynamic configuration datastore, while in other cases an | |||
explicit action (e.g., an RPC) may be required to trigger the | explicit action (e.g., an RPC) may be required to trigger the | |||
application of the datastore's data. | application of the datastore's data. | |||
A.4. Define which protocols can be used | A.4. Define Which Protocols Can Be Used | |||
By default, it is assumed that both the NETCONF and RESTCONF | By default, it is assumed that both the NETCONF and RESTCONF | |||
protocols can be used to interact with a datastore. However, it may | protocols can be used to interact with a datastore. However, it may | |||
be that only a specific protocol can be used (e.g., ForCES) or that a | be that only a specific protocol can be used (e.g., Forwarding and | |||
subset of all protocol operations or capabilities are available | Control Element Separation (ForCES)) or that a subset of all protocol | |||
(e.g., no locking or no XPath-based filtering). | operations or capabilities are available (e.g., no locking or no | |||
XPath-based filtering). | ||||
A.5. Define YANG identities for the datastore | A.5. Define YANG Identities for the Datastore | |||
The datastore must be defined with a YANG identity that uses the | The datastore must be defined with a YANG identity that uses the | |||
"ds:datastore" identity, or one of its derived identities, as its | "ds:datastore" identity, or one of its derived identities, as its | |||
base. This identity is necessary so that the datastore can be | base. This identity is necessary, so that the datastore can be | |||
referenced in protocol operations (e.g., <get-data>). | referenced in protocol operations (e.g., <get-data>). | |||
The datastore may also be defined with an identity that uses the | The datastore may also be defined with an identity that uses the | |||
"or:origin" identity or one its derived identities as its base. This | "or:origin" identity, or one of its derived identities, as its base. | |||
identity is needed if the datastore interacts with <operational> so | This identity is needed if the datastore interacts with | |||
that data originating from the datastore can be identified as such | <operational>, so that data originating from the datastore can be | |||
via the "origin" metadata attribute defined in Section 7. | identified as such via the "origin" metadata attribute defined in | |||
Section 7. | ||||
An example of these guidelines in use is provided in Appendix B. | An example of these guidelines in use is provided in Appendix B. | |||
Appendix B. Ephemeral Dynamic Configuration Datastore Example | Appendix B. Example of an Ephemeral Dynamic Configuration Datastore | |||
The section defines documentation for an example dynamic | This section defines documentation for an example dynamic | |||
configuration datastore using the guidelines provided in Appendix A. | configuration datastore using the guidelines provided in Appendix A. | |||
While this example is very terse, it is expected to be that a | For brevity, only a terse example is provided; it is expected that a | |||
standalone RFC would be needed when fully expanded. | standalone RFC would be written when this type of scenario is fully | |||
considered. | ||||
This example defines a dynamic configuration datastore called | This example defines a dynamic configuration datastore called | |||
"ephemeral", which is loosely modeled after the work done in the I2RS | "ephemeral", which is loosely modeled after the work done in the I2RS | |||
working group. | Working Group. | |||
+--------------+---------------------------------------------------+ | +--------------------+----------------------------------------------+ | |||
| Name | Value | | | Name | Value | | |||
+--------------+---------------------------------------------------+ | +--------------------+----------------------------------------------+ | |||
| Name | ephemeral | | | Name | ephemeral | | |||
| YANG modules | all (default) | | | | | | |||
| YANG nodes | all "config true" data nodes | | | YANG modules | all (default) | | |||
| How applied | changes automatically propagated to <operational> | | | | | | |||
| Protocols | NC/RC (default) | | | YANG nodes | all "config true" data nodes | | |||
| YANG Module | (see below) | | | | | | |||
+--------------+---------------------------------------------------+ | | How applied | changes automatically propagated to | | |||
| | <operational> | | ||||
| | | | ||||
| Protocols | NETCONF/RESTCONF (default) | | ||||
| | | | ||||
| Defining YANG | "example-ds-ephemeral" | | ||||
| module | | | ||||
+--------------------+----------------------------------------------+ | ||||
The example "ephemeral" datastore properties | Properties of the Example "ephemeral" Datastore | |||
module example-ds-ephemeral { | module example-ds-ephemeral { | |||
yang-version 1.1; | yang-version 1.1; | |||
namespace "urn:example:ds-ephemeral"; | namespace "urn:example:ds-ephemeral"; | |||
prefix eph; | prefix eph; | |||
import ietf-datastores { | import ietf-datastores { | |||
prefix ds; | prefix ds; | |||
} | } | |||
import ietf-origin { | import ietf-origin { | |||
skipping to change at page 30, line 40 ¶ | skipping to change at page 33, line 40 ¶ | |||
} | } | |||
} | } | |||
Appendix C. Example Data | Appendix C. Example Data | |||
The use of datastores is complex, and many of the subtle effects are | The use of datastores is complex, and many of the subtle effects are | |||
more easily presented using examples. This section presents a series | more easily presented using examples. This section presents a series | |||
of example data models with some sample contents of the various | of example data models with some sample contents of the various | |||
datastores. | datastores. | |||
The XML [W3C.REC-xml-20081126] snippets that follow are provided as | ||||
examples only. | ||||
C.1. System Example | C.1. System Example | |||
In this example, the following fictional module is used: | In this example, the following fictional module is used: | |||
module example-system { | module example-system { | |||
yang-version 1.1; | yang-version 1.1; | |||
namespace urn:example:system; | namespace urn:example:system; | |||
prefix sys; | prefix sys; | |||
import ietf-inet-types { | import ietf-inet-types { | |||
skipping to change at page 31, line 25 ¶ | skipping to change at page 34, line 39 ¶ | |||
container auto-negotiation { | container auto-negotiation { | |||
leaf enabled { | leaf enabled { | |||
type boolean; | type boolean; | |||
default true; | default true; | |||
} | } | |||
leaf speed { | leaf speed { | |||
type uint32; | type uint32; | |||
units mbps; | units mbps; | |||
description | description | |||
"The advertised speed, in mbps."; | "The advertised speed, in Mbps."; | |||
} | } | |||
} | } | |||
leaf speed { | leaf speed { | |||
type uint32; | type uint32; | |||
units mbps; | units mbps; | |||
config false; | config false; | |||
description | description | |||
"The speed of the interface, in mbps."; | "The speed of the interface, in Mbps."; | |||
} | } | |||
list address { | list address { | |||
key ip; | key ip; | |||
leaf ip { | leaf ip { | |||
type inet:ip-address; | type inet:ip-address; | |||
} | } | |||
leaf prefix-length { | leaf prefix-length { | |||
type uint8; | type uint8; | |||
} | } | |||
} | } | |||
skipping to change at page 32, line 4 ¶ | skipping to change at page 35, line 17 ¶ | |||
leaf ip { | leaf ip { | |||
type inet:ip-address; | type inet:ip-address; | |||
} | } | |||
leaf prefix-length { | leaf prefix-length { | |||
type uint8; | type uint8; | |||
} | } | |||
} | } | |||
} | } | |||
} | } | |||
} | } | |||
The operator has configured the host name and two interfaces, so the | ||||
The operator has configured the hostname and two interfaces, so the | ||||
contents of <intended> are: | contents of <intended> are: | |||
<system xmlns="urn:example:system"> | <system xmlns="urn:example:system"> | |||
<hostname>foo.example.com</hostname> | <hostname>foo.example.com</hostname> | |||
<interface> | <interface> | |||
<name>eth0</name> | <name>eth0</name> | |||
<auto-negotiation> | <auto-negotiation> | |||
<speed>1000</speed> | <speed>1000</speed> | |||
skipping to change at page 32, line 34 ¶ | skipping to change at page 35, line 48 ¶ | |||
<address> | <address> | |||
<ip>2001:db8::20</ip> | <ip>2001:db8::20</ip> | |||
<prefix-length>64</prefix-length> | <prefix-length>64</prefix-length> | |||
</address> | </address> | |||
</interface> | </interface> | |||
</system> | </system> | |||
The system has detected that the hardware for one of the configured | The system has detected that the hardware for one of the configured | |||
interfaces ("eth1") is not yet present, so the configuration for that | interfaces ("eth1") is not yet present, so the configuration for that | |||
interface is not applied. Further, the system has received a host | interface is not applied. Further, the system has received a | |||
name and an additional IP address for "eth0" over DHCP. In addition | hostname and an additional IP address for "eth0" over DHCP. In | |||
to a default value, a loopback interface is automatically added by | addition to filling in the default value for the auto-negotiation | |||
the system, and the result of the "speed" auto-negotiation. All of | enabled leaf, a loopback interface entry is also automatically | |||
this is reflected in <operational>. Note how the origin metadata | instantiated by the system. All of this is reflected in | |||
attribute for several "config true" data nodes is inherited from | <operational>. Note how the "origin" metadata attribute for several | |||
their parent data nodes. | "config true" data nodes is inherited from their parent data nodes. | |||
<system | <system | |||
xmlns="urn:example:system" | xmlns="urn:example:system" | |||
xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"> | xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"> | |||
<hostname or:origin="or:learned">bar.example.com</hostname> | <hostname or:origin="or:learned">bar.example.com</hostname> | |||
<interface or:origin="or:intended"> | <interface or:origin="or:intended"> | |||
<name>eth0</name> | <name>eth0</name> | |||
<auto-negotiation> | <auto-negotiation> | |||
skipping to change at page 34, line 20 ¶ | skipping to change at page 37, line 24 ¶ | |||
type uint32; | type uint32; | |||
} | } | |||
list peer { | list peer { | |||
key name; | key name; | |||
leaf name { | leaf name { | |||
type inet:ip-address; | type inet:ip-address; | |||
} | } | |||
leaf local-as { | leaf local-as { | |||
type uint32; | type uint32; | |||
description | description | |||
".... Defaults to ../local-as"; | "... Defaults to ../local-as."; | |||
} | } | |||
leaf peer-as { | leaf peer-as { | |||
type uint32; | type uint32; | |||
description | description | |||
"... Defaults to ../peer-as"; | "... Defaults to ../peer-as."; | |||
} | } | |||
leaf local-port { | leaf local-port { | |||
type inet:port; | type inet:port; | |||
} | } | |||
leaf remote-port { | leaf remote-port { | |||
type inet:port; | type inet:port; | |||
default 179; | default 179; | |||
} | } | |||
leaf state { | leaf state { | |||
config false; | config false; | |||
skipping to change at page 35, line 10 ¶ | skipping to change at page 38, line 14 ¶ | |||
The model also follows the pattern of fully integrating state | The model also follows the pattern of fully integrating state | |||
("config false") nodes with configuration ("config true") nodes. | ("config false") nodes with configuration ("config true") nodes. | |||
There is no separate "bgp-state" hierarchy, with the accompanying | There is no separate "bgp-state" hierarchy, with the accompanying | |||
repetition of containment and naming nodes. This makes the model | repetition of containment and naming nodes. This makes the model | |||
simpler and more readable. | simpler and more readable. | |||
C.2.1. Datastores | C.2.1. Datastores | |||
Each datastore represents differing views of these nodes. <running> | Each datastore represents differing views of these nodes. <running> | |||
will hold the configuration provided by the operator, for example a | will hold the configuration provided by the operator -- for example, | |||
single BGP peer. <intended> will conceptually hold the data as | a single BGP peer. <intended> will conceptually hold the data as | |||
validated, after the removal of data not intended for validation and | validated, after the removal of data not intended for validation and | |||
after any local template mechanisms are performed. <operational> | after any local template mechanisms are performed. <operational> | |||
will show data from <intended> as well as any "config false" nodes. | will show data from <intended> as well as any "config false" nodes. | |||
C.2.2. Adding a Peer | C.2.2. Adding a Peer | |||
If the user configures a single BGP peer, then that peer will be | If the user configures a single BGP peer, then that peer will be | |||
visible in both <running> and <intended>. It may also appear in | visible in both <running> and <intended>. It may also appear in | |||
<candidate>, if the server supports the candidate configuration | <candidate> if the server supports the candidate configuration | |||
datastore. Retrieving the peer will return only the user-specified | datastore. Retrieving the peer will return only the user-specified | |||
values. | values. | |||
No time delay should exist between the appearance of the peer in | No time delay should exist between the appearance of the peer in | |||
<running> and <intended>. | <running> and <intended>. | |||
In this scenario, we've added the following to <running>: | In this scenario, we've added the following to <running>: | |||
<bgp> | <bgp> | |||
<local-as>64501</local-as> | <local-as>64501</local-as> | |||
<peer-as>64502</peer-as> | <peer-as>64502</peer-as> | |||
<peer> | <peer> | |||
<name>2001:db8::2:3</name> | <name>2001:db8::2:3</name> | |||
</peer> | </peer> | |||
</bgp> | </bgp> | |||
C.2.2.1. <operational> | C.2.2.1. <operational> | |||
The operational datastore will contain the fully expanded peer data, | The operational datastore will contain the fully expanded peer data, | |||
including "config false" nodes. In our example, this means the | including "config false" nodes. In our example, this means that the | |||
"state" node will appear. | "state" node will appear. | |||
In addition, <operational> will contain the "currently in use" values | In addition, <operational> will contain the "currently in use" values | |||
for all nodes. This means that local-as and peer-as will be | for all nodes. This means that local-as and peer-as will be | |||
populated even if they are not given values in <intended>. The value | populated even if they are not given values in <intended>. The value | |||
of bgp/local-as will be used if bgp/peer/local-as is not provided; | of bgp/local-as will be used if bgp/peer/local-as is not provided; | |||
bgp/peer-as and bgp/peer/peer-as will have the same relationship. In | bgp/peer-as and bgp/peer/peer-as will have the same relationship. In | |||
the operational view, this means that every peer will have values for | the operational view, this means that every peer will have values for | |||
their local-as and peer-as, even if those values are not explicitly | their local-as and peer-as, even if those values are not explicitly | |||
configured but are provided by bgp/local-as and bgp/peer-as. | configured but are provided by bgp/local-as and bgp/peer-as. | |||
skipping to change at page 36, line 15 ¶ | skipping to change at page 39, line 18 ¶ | |||
Each BGP peer has a TCP connection associated with it, using the | Each BGP peer has a TCP connection associated with it, using the | |||
values of local-port and remote-port from <intended>. If those | values of local-port and remote-port from <intended>. If those | |||
values are not supplied, the system will select values. When the | values are not supplied, the system will select values. When the | |||
connection is established, <operational> will contain the current | connection is established, <operational> will contain the current | |||
values for the local-port and remote-port nodes regardless of the | values for the local-port and remote-port nodes regardless of the | |||
origin. If the system has chosen the values, the "origin" attribute | origin. If the system has chosen the values, the "origin" attribute | |||
will be set to "system". Before the connection is established, one | will be set to "system". Before the connection is established, one | |||
or both of the nodes may not appear, since the system may not yet | or both of the nodes may not appear, since the system may not yet | |||
have their values. | have their values. | |||
<bgp or:origin="or:intended"> | <bgp xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin" | |||
or:origin="or:intended"> | ||||
<local-as>64501</local-as> | <local-as>64501</local-as> | |||
<peer-as>64502</peer-as> | <peer-as>64502</peer-as> | |||
<peer> | <peer> | |||
<name>2001:db8::2:3</name> | <name>2001:db8::2:3</name> | |||
<local-as or:origin="or:default">64501</local-as> | <local-as or:origin="or:default">64501</local-as> | |||
<peer-as or:origin="or:default">64502</peer-as> | <peer-as or:origin="or:default">64502</peer-as> | |||
<local-port or:origin="or:system">60794</local-port> | <local-port or:origin="or:system">60794</local-port> | |||
<remote-port or:origin="or:default">179</remote-port> | <remote-port or:origin="or:default">179</remote-port> | |||
<state>established</state> | <state>established</state> | |||
</peer> | </peer> | |||
skipping to change at page 37, line 5 ¶ | skipping to change at page 40, line 5 ¶ | |||
operation of the device. | operation of the device. | |||
Consider the scenario where a client removes a BGP peer. When a peer | Consider the scenario where a client removes a BGP peer. When a peer | |||
is removed, the operational state will continue to reflect the | is removed, the operational state will continue to reflect the | |||
existence of that peer until the peer's resources are released, | existence of that peer until the peer's resources are released, | |||
including closing the peer's connection. During this period, the | including closing the peer's connection. During this period, the | |||
current data values will continue to be visible in <operational>, | current data values will continue to be visible in <operational>, | |||
with the "origin" attribute set to indicate the origin of the | with the "origin" attribute set to indicate the origin of the | |||
original data. | original data. | |||
<bgp or:origin="or:intended"> | <bgp xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin" | |||
or:origin="or:intended"> | ||||
<local-as>64501</local-as> | <local-as>64501</local-as> | |||
<peer-as>64502</peer-as> | <peer-as>64502</peer-as> | |||
<peer> | <peer> | |||
<name>2001:db8::2:3</name> | <name>2001:db8::2:3</name> | |||
<local-as or:origin="or:default">64501</local-as> | <local-as or:origin="or:default">64501</local-as> | |||
<peer-as or:origin="or:default">64502</peer-as> | <peer-as or:origin="or:default">64502</peer-as> | |||
<local-port or:origin="or:system">60794</local-port> | <local-port or:origin="or:system">60794</local-port> | |||
<remote-port or:origin="or:default">179</remote-port> | <remote-port or:origin="or:default">179</remote-port> | |||
<state>closing</state> | <state>closing</state> | |||
</peer> | </peer> | |||
skipping to change at page 38, line 24 ¶ | skipping to change at page 41, line 32 ¶ | |||
</interfaces> | </interfaces> | |||
Since the interface does not exist, this data does not appear in | Since the interface does not exist, this data does not appear in | |||
<operational>. | <operational>. | |||
When a FRU containing this interface is inserted, the system will | When a FRU containing this interface is inserted, the system will | |||
detect it and process the associated configuration. <operational> | detect it and process the associated configuration. <operational> | |||
will contain the data from <intended>, as well as nodes added by the | will contain the data from <intended>, as well as nodes added by the | |||
system, such as the current value of the interface's MTU. | system, such as the current value of the interface's MTU. | |||
<interfaces or:origin="or:intended"> | <interfaces xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin" | |||
or:origin="or:intended"> | ||||
<interface> | <interface> | |||
<name>et-0/0/0</name> | <name>et-0/0/0</name> | |||
<description>Test interface</description> | <description>Test interface</description> | |||
<mtu or:origin="or:system">1500</mtu> | <mtu or:origin="or:system">1500</mtu> | |||
</interface> | </interface> | |||
</interfaces> | </interfaces> | |||
If the FRU is removed, the interface data is removed from | If the FRU is removed, the interface data is removed from | |||
<operational>. | <operational>. | |||
C.3.2. System-provided Interface | C.3.2. System-Provided Interface | |||
Imagine if the system provides a loopback interface (named "lo0") | Imagine that the system provides a loopback interface (named "lo0") | |||
with a default ip-address of "127.0.0.1" and a default ip-address of | with a default IPv4 address of "127.0.0.1" and a default IPv6 address | |||
"::1". The system will only provide configuration for this interface | of "::1". The system will only provide configuration for this | |||
if there is no data for it in <intended>. | interface if there is no data for it in <intended>. | |||
When no configuration for "lo0" appears in <intended>, then | When no configuration for "lo0" appears in <intended>, <operational> | |||
<operational> will show the system-provided data: | will show the system-provided data: | |||
<interfaces or:origin="or:intended"> | <interfaces xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin" | |||
or:origin="or:intended"> | ||||
<interface or:origin="or:system"> | <interface or:origin="or:system"> | |||
<name>lo0</name> | <name>lo0</name> | |||
<ip-address>127.0.0.1</ip-address> | <ip-address>127.0.0.1</ip-address> | |||
<ip-address>::1</ip-address> | <ip-address>::1</ip-address> | |||
</interface> | </interface> | |||
</interfaces> | </interfaces> | |||
When configuration for "lo0" does appear in <intended>, then | When configuration for "lo0" does appear in <intended>, <operational> | |||
<operational> will show that data with the origin set to "intended". | will show that data with the origin set to "intended". If the | |||
If the "ip-address" is not provided, then the system-provided value | "ip-address" is not provided, then the system-provided value will | |||
will appear as follows: | appear as follows: | |||
<interfaces or:origin="or:intended"> | <interfaces xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin" | |||
or:origin="or:intended"> | ||||
<interface> | <interface> | |||
<name>lo0</name> | <name>lo0</name> | |||
<description>loopback</description> | <description>loopback</description> | |||
<ip-address or:origin="or:system">127.0.0.1</ip-address> | <ip-address or:origin="or:system">127.0.0.1</ip-address> | |||
<ip-address>::1</ip-address> | <ip-address>::1</ip-address> | |||
</interface> | </interface> | |||
</interfaces> | </interfaces> | |||
Acknowledgments | ||||
This document grew out of many discussions that took place since | ||||
2010. Several documents ([NETMOD-Operational] [With-config-state] | ||||
[OpState-Reqs] [OpState-Enhance] [OpState-Modeling], as well as | ||||
[RFC6244]), touched on some of the problems of the original datastore | ||||
model. The following people were authors of these works in progress | ||||
or were otherwise actively involved in the discussions that led to | ||||
this document: | ||||
o Lou Berger, LabN Consulting, L.L.C., <lberger@labn.net> | ||||
o Andy Bierman, YumaWorks, <andy@yumaworks.com> | ||||
o Marcus Hines, Google, <hines@google.com> | ||||
o Christian Hopps, Deutsche Telekom, <chopps@chopps.org> | ||||
o Balazs Lengyel, Ericsson, <balazs.lengyel@ericsson.com> | ||||
o Ladislav Lhotka, CZ.NIC, <lhotka@nic.cz> | ||||
o Acee Lindem, Cisco Systems, <acee@cisco.com> | ||||
o Thomas Nadeau, Brocade Networks, <tnadeau@lucidvision.com> | ||||
o Tom Petch, Engineering Networks Ltd, <ietfc@btconnect.com> | ||||
o Anees Shaikh, Google, <aashaikh@google.com> | ||||
o Rob Shakir, Google, <robjs@google.com> | ||||
o Jason Sterne, Nokia, <jason.sterne@nokia.com> | ||||
Juergen Schoenwaelder was partly funded by Flamingo, a Network of | ||||
Excellence project (ICT-318488) supported by the European Commission | ||||
under its Seventh Framework Programme. | ||||
Authors' Addresses | Authors' Addresses | |||
Martin Bjorklund | Martin Bjorklund | |||
Tail-f Systems | Tail-f Systems | |||
Email: mbj@tail-f.com | Email: mbj@tail-f.com | |||
Juergen Schoenwaelder | Juergen Schoenwaelder | |||
Jacobs University | Jacobs University | |||
End of changes. 148 change blocks. | ||||
397 lines changed or deleted | 423 lines changed or added | |||
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |