draft-ietf-netmod-revised-datastores-09.txt   draft-ietf-netmod-revised-datastores-10.txt 
Network Working Group M. Bjorklund Network Working Group M. Bjorklund
Internet-Draft Tail-f Systems Internet-Draft Tail-f Systems
Updates: 7950 (if approved) J. Schoenwaelder Updates: 7950 (if approved) J. Schoenwaelder
Intended status: Standards Track Jacobs University Intended status: Standards Track Jacobs University
Expires: June 23, 2018 P. Shafer Expires: July 17, 2018 P. Shafer
K. Watsen K. Watsen
Juniper Networks Juniper Networks
R. Wilton R. Wilton
Cisco Systems Cisco Systems
December 20, 2017 January 13, 2018
Network Management Datastore Architecture Network Management Datastore Architecture
draft-ietf-netmod-revised-datastores-09 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 NETCONF and RESTCONF. This document defines an architectural
framework for datastores based on the experience gained with the framework for datastores based on the experience gained with the
initial simpler model, addressing requirements that were not well initial simpler model, addressing requirements that were not well
supported in the initial model. This document updates RFC 7950. supported in the initial model. This document updates RFC 7950.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 23, 2018. This Internet-Draft will expire on July 17, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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 (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 39 skipping to change at page 2, line 39
5.3.3. System-controlled Resources . . . . . . . . . . . . . 15 5.3.3. System-controlled Resources . . . . . . . . . . . . . 15
5.3.4. Origin Metadata Annotation . . . . . . . . . . . . . 15 5.3.4. Origin Metadata Annotation . . . . . . . . . . . . . 15
6. Implications on YANG . . . . . . . . . . . . . . . . . . . . 17 6. Implications on YANG . . . . . . . . . . . . . . . . . . . . 17
6.1. XPath Context . . . . . . . . . . . . . . . . . . . . . . 17 6.1. XPath Context . . . . . . . . . . . . . . . . . . . . . . 17
6.2. Invocation of Actions and RPCs . . . . . . . . . . . . . 18 6.2. Invocation of Actions and RPCs . . . . . . . . . . . . . 18
7. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 18 7. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
8.1. Updates to the IETF XML Registry . . . . . . . . . . . . 24 8.1. Updates to the IETF XML Registry . . . . . . . . . . . . 24
8.2. Updates to the YANG Module Names Registry . . . . . . . . 24 8.2. Updates to the YANG Module Names Registry . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . 25 11.1. Normative References . . . . . . . . . . . . . . . . . . 26
11.2. Informative References . . . . . . . . . . . . . . . . . 26 11.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. Guidelines for Defining Datastores . . . . . . . . . 27 Appendix A. Guidelines for Defining Datastores . . . . . . . . . 27
A.1. Define which YANG modules can be used in the datastore . 27 A.1. Define which YANG modules can be used in the datastore . 27
A.2. Define which subset of YANG-modeled data applies . . . . 27 A.2. Define which subset of YANG-modeled data applies . . . . 28
A.3. Define how data is actualized . . . . . . . . . . . . . . 27 A.3. Define how data is actualized . . . . . . . . . . . . . . 28
A.4. Define which protocols can be used . . . . . . . . . . . 28 A.4. Define which protocols can be used . . . . . . . . . . . 28
A.5. Define YANG identities for the datastore . . . . . . . . 28 A.5. Define YANG identities for the datastore . . . . . . . . 28
Appendix B. Ephemeral Dynamic Configuration Datastore Example . 28 Appendix B. Ephemeral Dynamic Configuration Datastore Example . 29
Appendix C. Example Data . . . . . . . . . . . . . . . . . . . . 29 Appendix C. Example Data . . . . . . . . . . . . . . . . . . . . 30
C.1. System Example . . . . . . . . . . . . . . . . . . . . . 30 C.1. System Example . . . . . . . . . . . . . . . . . . . . . 30
C.2. BGP Example . . . . . . . . . . . . . . . . . . . . . . . 32 C.2. BGP Example . . . . . . . . . . . . . . . . . . . . . . . 33
C.2.1. Datastores . . . . . . . . . . . . . . . . . . . . . 34 C.2.1. Datastores . . . . . . . . . . . . . . . . . . . . . 35
C.2.2. Adding a Peer . . . . . . . . . . . . . . . . . . . . 34 C.2.2. Adding a Peer . . . . . . . . . . . . . . . . . . . . 35
C.2.3. Removing a Peer . . . . . . . . . . . . . . . . . . . 35 C.2.3. Removing a Peer . . . . . . . . . . . . . . . . . . . 36
C.3. Interface Example . . . . . . . . . . . . . . . . . . . . 36 C.3. Interface Example . . . . . . . . . . . . . . . . . . . . 37
C.3.1. Pre-provisioned Interfaces . . . . . . . . . . . . . 36 C.3.1. Pre-provisioned Interfaces . . . . . . . . . . . . . 37
C.3.2. System-provided Interface . . . . . . . . . . . . . . 37 C.3.2. System-provided Interface . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
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 NETCONF
[RFC6241], RESTCONF [RFC8040] and the YANG [RFC7950] data modeling [RFC6241], RESTCONF [RFC8040] and the YANG [RFC7950] data modeling
language. Datastores are a fundamental concept binding network language. Datastores are a fundamental concept binding network
management data models to network management protocols. Agreement on management data models to network management protocols. Agreement on
a common architectural model of datastores ensures that data models a common architectural model of datastores ensures that data models
can be written in a network management protocol agnostic way. This can be written in a network management protocol agnostic way. This
architectural framework identifies a set of conceptual datastores but architectural framework identifies a set of conceptual datastores but
it does not mandate that all network management protocols expose all it does not mandate that all network management protocols expose all
these conceptual datastores. This architecture is agnostic with these conceptual datastores. This architecture is agnostic with
regard to the encoding used by network management protocols. regard to the encoding used by network management protocols.
This document updates RFC 7950 by refining the definition of the
accessible tree for some XPath context (see 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 BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 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)
skipping to change at page 4, line 16 skipping to change at page 4, line 20
operational state data from configuration data leads to a number of operational state data from configuration data leads 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 two different but independent instantiations can appear in different datastores,
datastores, one for configured values and one for operational state e.g., one for a configured value and another for an operationally
values. 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 that
are used to expand configuration data via a common template. are used to expand configuration data via a common template.
3. Terminology 3. Terminology
skipping to change at page 7, line 50 skipping to change at page 8, line 4
[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 among
other things mentions the option to consider operational state as other things mentions the option to consider operational state as
being stored in another datastore. Section 4.4 of this document then being stored in another datastore. Section 4.4 of [RFC6244] then
concludes that at the time of the writing, modeling state as distinct concludes that at the time of the writing, modeling state as distinct
leafs and distinct branches is the recommended approach. leafs and distinct branches is the recommended approach.
Implementation experience and requests from operators Implementation experience and requests from operators
[I-D.ietf-netmod-opstate-reqs], [I-D.openconfig-netmod-opstate] [I-D.ietf-netmod-opstate-reqs], [I-D.openconfig-netmod-opstate]
indicate that the datastore model initially designed for NETCONF and indicate that the datastore model initially designed for NETCONF and
refined by YANG needs to be extended. In particular, the notion of refined by YANG needs to be extended. In particular, the notion of
intended configuration and applied configuration has developed. intended configuration and applied configuration has developed.
4.1. Original Model of Datastores 4.1. Original Model of Datastores
skipping to change at page 12, line 10 skipping to change at page 12, line 10
protocols or implementations. protocols or implementations.
<candidate> does not typically persist across reboots, even in the <candidate> does not typically persist across reboots, even in the
presence of non-volatile storage. If <candidate> is stored using presence of non-volatile storage. If <candidate> is stored using
non-volatile storage, it is reset at boot time to the contents of non-volatile storage, it is reset at boot time to the contents of
<running>. <running>.
5.1.3. The Running Configuration Datastore (<running>) 5.1.3. The Running Configuration Datastore (<running>)
The running configuration datastore (<running>) is a configuration The running configuration datastore (<running>) is a configuration
datastore that holds the complete current configuration on the datastore that holds the current configuration of the device. It MAY
device. It MAY include configuration that requires further include configuration that requires further transformation before it
transformation before it can be applied, e.g., inactive can be applied, e.g., inactive configuration, or template-mechanism-
configuration, or template-mechanism-oriented configuration that oriented configuration that needs further expansion. However,
needs further expansion. However, <running> MUST always be a valid <running> MUST always be a valid configuration data tree, as defined
configuration data tree, as defined in Section 8.1 of [RFC7950]. in Section 8.1 of [RFC7950].
<running> MUST be supported if the device can be configured via <running> MUST be supported if the device can be configured via
conventional configuration datastores. conventional configuration datastores.
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>)
skipping to change at page 18, line 19 skipping to change at page 18, line 19
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@2017-12-20.yang" <CODE BEGINS> file "ietf-datastores@2018-01-11.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 19, line 5 skipping to change at page 19, line 5
<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 two sets of identities for datastores.
The first identifies the datastores themselves, the second The first identifies the datastores themselves, the second
identifies datastore properties. identifies datastore properties.
Copyright (c) 2017 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). (http://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 XXXX
(http://www.rfc-editor.org/info/rfcxxxx); see the RFC itself (http://www.rfc-editor.org/info/rfcxxxx); see the RFC itself
for full legal notices."; for full legal notices.";
revision 2017-12-20 { revision 2018-01-11 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: Network Management Datastore Architecture"; "RFC XXXX: Network Management Datastore Architecture";
} }
/* /*
* Identities * Identities
*/ */
skipping to change at page 20, line 44 skipping to change at page 20, line 44
base datastore; base datastore;
} }
description description
"A datastore identity reference."; "A datastore identity reference.";
} }
} }
<CODE ENDS> <CODE ENDS>
<CODE BEGINS> file "ietf-origin@2017-12-20.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 34 skipping to change at page 21, line 34
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) 2017 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). (http://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 XXXX
(http://www.rfc-editor.org/info/rfcxxxx); see the RFC itself (http://www.rfc-editor.org/info/rfcxxxx); see the RFC itself
for full legal notices."; for full legal notices.";
revision 2017-12-20 { revision 2018-01-11 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: Network Management Datastore Architecture"; "RFC XXXX: Network Management Datastore Architecture";
} }
/* /*
* Identities * Identities
*/ */
skipping to change at page 24, line 44 skipping to change at page 24, line 44
prefix: or prefix: or
reference: RFC XXXX reference: RFC XXXX
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 meta-data, hence the "YANG module security only define identities and a metadata annotation, hence the "YANG
guidelines" do not apply. module security guidelines" do not apply.
The origin metadata annotation exposes the origin of values in the
applied configuration. Origin information may provide hints that
certain control plane protocols are active on a device. Since origin
information is tied to applied configuration values, it is only
accessible to clients that have the permissions to read the applied
configuration values. Security administrators should consider the
sensitivity of origin information while defining access control
rules.
10. Acknowledgments 10. Acknowledgments
This document grew out of many discussions that took place since This document grew out of many discussions that took place since
2010. Several Internet-Drafts ([I-D.bjorklund-netmod-operational], 2010. Several Internet-Drafts ([I-D.bjorklund-netmod-operational],
[I-D.wilton-netmod-opstate-yang], [I-D.ietf-netmod-opstate-reqs], [I-D.wilton-netmod-opstate-yang], [I-D.ietf-netmod-opstate-reqs],
[I-D.kwatsen-netmod-opstate], [I-D.openconfig-netmod-opstate]) and [I-D.kwatsen-netmod-opstate], [I-D.openconfig-netmod-opstate]) and
[RFC6244] touched on some of the problems of the original datastore [RFC6244] touched on some of the problems of the original datastore
model. The following people were authors to these Internet-Drafts or model. The following people were authors to these Internet-Drafts or
otherwise actively involved in the discussions that led to this otherwise actively involved in the discussions that led to this
document: document:
o Lou Berger, LabN Consulting, L.L.C., <lberger@labn.net> o Lou Berger, LabN Consulting, L.L.C., <lberger@labn.net>
o Andy Bierman, YumaWorks, <andy@yumaworks.com> o Andy Bierman, YumaWorks, <andy@yumaworks.com>
o Marcus Hines, Google, <hines@google.com> o Marcus Hines, Google, <hines@google.com>
skipping to change at page 26, line 6 skipping to change at page 26, line 17
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997, <https://www.rfc-editor.org/info/ RFC2119, March 1997, <https://www.rfc-editor.org/info/
rfc2119>. 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, RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www
<https://www.rfc-editor.org/info/rfc7950>. .rfc-editor.org/info/rfc7950>.
[RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", RFC [RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", RFC
7952, DOI 10.17487/RFC7952, August 2016, <https://www.rfc- 7952, DOI 10.17487/RFC7952, August 2016, <https://www.rfc-
editor.org/info/rfc7952>. 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 RFC
skipping to change at page 31, line 14 skipping to change at page 32, line 4
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 host name 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</hostname> <hostname>foo.example.com</hostname>
<interface> <interface>
<name>eth0</name> <name>eth0</name>
<auto-negotiation> <auto-negotiation>
<speed>1000</speed> <speed>1000</speed>
</auto-negotiation> </auto-negotiation>
<address> <address>
<ip>2001:db8::10</ip> <ip>2001:db8::10</ip>
<prefix-length>64</prefix-length> <prefix-length>64</prefix-length>
</address> </address>
skipping to change at page 32, line 9 skipping to change at page 33, line 9
to a default value, a loopback interface is automatically added by to a default value, a loopback interface is automatically added by
the system, and the result of the "speed" auto-negotiation. All of the system, and the result of the "speed" auto-negotiation. All of
this is reflected in <operational>. Note how the origin metadata this is reflected in <operational>. Note how the origin metadata
attribute for several "config true" data nodes is inherited from attribute for several "config true" data nodes is inherited from
their parent data nodes. 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</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>
<enabled or:origin="or:default">true</enabled> <enabled or:origin="or:default">true</enabled>
<speed>1000</speed> <speed>1000</speed>
</auto-negotiation> </auto-negotiation>
<speed>100</speed> <speed>100</speed>
<address> <address>
<ip>2001:db8::10</ip> <ip>2001:db8::10</ip>
skipping to change at page 34, line 33 skipping to change at page 35, line 33
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>10.1.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 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
skipping to change at page 35, line 19 skipping to change at page 36, line 19
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 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>10.1.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>
</bgp> </bgp>
C.2.3. Removing a Peer C.2.3. Removing a Peer
skipping to change at page 36, line 9 skipping to change at page 37, line 9
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 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>10.1.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>
</bgp> </bgp>
Once resources are released and the connection is closed, the peer's Once resources are released and the connection is closed, the peer's
data is removed from <operational>. data is removed from <operational>.
 End of changes. 29 change blocks. 
46 lines changed or deleted 57 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/