< draft-ietf-netmod-nmda-diff-01.txt   draft-ietf-netmod-nmda-diff-02.txt >
Network Working Group A. Clemm Network Working Group A. Clemm
Internet-Draft Y. Qu Internet-Draft Y. Qu
Intended status: Standards Track Futurewei Intended status: Standards Track Futurewei
Expires: November 24, 2019 J. Tantsura Expires: January 9, 2020 J. Tantsura
Apstra Apstra
A. Bierman A. Bierman
YumaWorks YumaWorks
May 23, 2019 July 8, 2019
Comparison of NMDA datastores Comparison of NMDA datastores
draft-ietf-netmod-nmda-diff-01 draft-ietf-netmod-nmda-diff-02
Abstract Abstract
This document defines an RPC operation to compare management This document defines an RPC operation to compare management
datastores that comply with the NMDA architecture. datastores that comply with the NMDA architecture.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 November 24, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://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
skipping to change at page 2, line 15 skipping to change at page 2, line 15
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 3 3. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 3
4. Data Model Overview . . . . . . . . . . . . . . . . . . . . . 4 4. Data Model Overview . . . . . . . . . . . . . . . . . . . . . 4
5. YANG Data Model . . . . . . . . . . . . . . . . . . . . . . . 5 5. YANG Data Model . . . . . . . . . . . . . . . . . . . . . . . 5
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Possible Future Extensions . . . . . . . . . . . . . . . . . 11 8. Possible Future Extensions . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9.1. Updates to the IETF XML Registry . . . . . . . . . . . . 12 9.1. Updates to the IETF XML Registry . . . . . . . . . . . . 13
9.2. Updates to the YANG Module Names Registry . . . . . . . . 12 9.2. Updates to the YANG Module Names Registry . . . . . . . . 14
10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
12.1. Normative References . . . . . . . . . . . . . . . . . . 13 12.1. Normative References . . . . . . . . . . . . . . . . . . 15
12.2. Informative References . . . . . . . . . . . . . . . . . 14 12.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
The revised Network Management Datastore Architecture (NMDA) The revised Network Management Datastore Architecture (NMDA)
[RFC8342] introduces a set of new datastores that each hold YANG- [RFC8342] introduces a set of new datastores that each hold YANG-
defined data [RFC7950] and represent a different "viewpoint" on the defined data [RFC7950] and represent a different "viewpoint" on the
data that is maintained by a server. New YANG datastores that are data that is maintained by a server. New YANG datastores that are
introduced include <intended>, which contains validated configuration introduced include <intended>, which contains validated configuration
data that a client application intends to be in effect, and data that a client application intends to be in effect, and
<operational>, which contains at least conceptually operational state <operational>, which contains at least conceptually operational state
skipping to change at page 5, line 7 skipping to change at page 5, line 7
The operation provides the following output parameter: The operation provides the following output parameter:
o differences: This parameter contains the list of differences. o differences: This parameter contains the list of differences.
Those differences are encoded per YANG-Patch data model defined in Those differences are encoded per YANG-Patch data model defined in
RFC8072. The YANG-Patch data model is augmented to indicate the RFC8072. The YANG-Patch data model is augmented to indicate the
value of source datastore nodes in addition to the patch itself value of source datastore nodes in addition to the patch itself
that would need to be applied to the source to produce the target. that would need to be applied to the source to produce the target.
When the target datastore is <operational>, "origin" metadata is When the target datastore is <operational>, "origin" metadata is
included as part of the patch. Including origin metadata can help included as part of the patch. Including origin metadata can help
explain the cause of a difference, for example when a data node is in some cases explain the cause of a difference, for example when
part of <intended> but the origin of the same data node in a data node is part of <intended> but the origin of the same data
<operational> is reported as "system". node in <operational> is reported as "system".
The data model is defined in the ietf-nmda-compare YANG module. Its The data model is defined in the ietf-nmda-compare YANG module. Its
structure is shown in the following figure. The notation syntax structure is shown in the following figure. The notation syntax
follows [RFC8340]. follows [RFC8340].
module: ietf-nmda-compare module: ietf-nmda-compare
rpcs: rpcs:
+---x compare +---x compare
+---w input +---w input
| +---w source identityref | +---w source identityref
skipping to change at page 5, line 49 skipping to change at page 5, line 49
+--ro target target-resource-offset +--ro target target-resource-offset
+--ro point? target-resource-offset +--ro point? target-resource-offset
+--ro where? enumeration +--ro where? enumeration
+--ro value? +--ro value?
+--ro source-value? +--ro source-value?
Structure of ietf-nmda-compare Structure of ietf-nmda-compare
5. YANG Data Model 5. YANG Data Model
<CODE BEGINS> file "ietf-nmda-compare@2019-05-23.yang" <CODE BEGINS> file "ietf-nmda-compare@2019-07-08.yang"
module ietf-nmda-compare { module ietf-nmda-compare {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-nmda-compare"; namespace "urn:ietf:params:xml:ns:yang:ietf-nmda-compare";
prefix cp; prefix cp;
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
} }
import ietf-datastores { import ietf-datastores {
prefix ds; prefix ds;
} }
import ietf-yang-patch { import ietf-yang-patch {
prefix ypatch; prefix ypatch;
} }
import ietf-netconf { import ietf-netconf {
prefix nc; prefix nc;
} }
organization "IETF"; organization "IETF";
contact contact
"WG Web: <http://tools.ietf.org/wg/netconf/> "WG Web: <http://tools.ietf.org/wg/netconf/>
WG List: <mailto:netconf@ietf.org> WG List: <mailto:netconf@ietf.org>
Author: Alexander Clemm Author: Alexander Clemm
<mailto:ludwig@clemm.org> <mailto:ludwig@clemm.org>
Author: Yingzhen Qu Author: Yingzhen Qu
<mailto:yqu@futurewei.com> <mailto:yqu@futurewei.com>
Author: Jeff Tantsura Author: Jeff Tantsura
<mailto:jefftant.ietf@gmail.com> <mailto:jefftant.ietf@gmail.com>
Author: Andy Bierman Author: Andy Bierman
<mailto:andy@yumaworks.com>"; <mailto:andy@yumaworks.com>";
description description
"The YANG data model defines a new operation, <compare>, that "The YANG data model defines a new operation, <compare>, that
can be used to compare NMDA datastores."; can be used to compare NMDA datastores.";
revision 2019-05-23 { revision 2019-07-08 {
description description
"Initial revision"; "Initial revision";
reference reference
"RFC XXXX: Comparison of NMDA datastores"; "RFC XXXX: Comparison of NMDA datastores";
} }
/* RPC */ /* RPC */
rpc compare { rpc compare {
description description
"NMDA compare operation."; "NMDA compare operation.";
input { input {
leaf source { leaf source {
type identityref { type identityref {
base ds:datastore; base ds:datastore;
} }
mandatory true; mandatory true;
description description
"The source datastore to be compared."; "The source datastore to be compared.";
} }
leaf target { leaf target {
type identityref { type identityref {
base ds:datastore; base ds:datastore;
} }
mandatory true; mandatory true;
description description
"The target datastore to be compared."; "The target datastore to be compared.";
} }
leaf all { leaf all {
type empty; type empty;
description description
"When this leaf is provided, all data nodes are compared, "When this leaf is provided, all data nodes are compared,
whether their schema node pertains to both datastores or whether their schema node pertains to both datastores or
not. When this leaf is omitted, a prefiltering step is not. When this leaf is omitted, a prefiltering step is
automatically applied that excludes data nodes from the automatically applied that excludes data nodes from the
comparison that can occur in only one datastore but not comparison that can occur in only one datastore but not
the other. Specifically, if one of the datastores the other. Specifically, if one of the datastores
(source or target) contains only configuration data and (source or target) contains only configuration data and
the other datastore is <operational>, data nodes for the other datastore is <operational>, data nodes for
which config is false are excluded from the comparison."; which config is false are excluded from the comparison.";
} }
choice filter-spec { choice filter-spec {
description description
"Identifies the portions of the datastores to be "Identifies the portions of the datastores to be
compared."; compared.";
anydata subtree-filter { anydata subtree-filter {
description description
"This parameter identifies the portions of the "This parameter identifies the portions of the
target datastore to retrieve."; target datastore to retrieve.";
reference "RFC 6241, Section 6."; reference "RFC 6241, Section 6.";
} }
leaf xpath-filter { leaf xpath-filter {
if-feature nc:xpath; if-feature nc:xpath;
type yang:xpath1.0; type yang:xpath1.0;
description description
"This parameter contains an XPath expression "This parameter contains an XPath expression
identifying the portions of the target identifying the portions of the target
datastore to retrieve."; datastore to retrieve.";
}
}
}
output {
choice compare-response {
description
"Comparison results.";
leaf no-matches {
type empty;
description
"This leaf indicates that the filter did not match
anything and nothing was compared.";
}
container differences {
description
"The list of differences, encoded per RFC8072 with an
augmentation to include source values where
applicable.";
uses ypatch:yang-patch {
augment "yang-patch/edit" {
description
"Provide the value of the source of the patch,
respectively of the comparison, in addition to
the target value, where applicable.";
anydata source-value {
when "../operation = 'delete'"
+ "or ../operation = 'merge'"
+ "or ../operation = 'move'"
+ "or ../operation = 'replace'"
+ "or ../operation = 'remove'";
description
"The anydata 'value' is only used for 'delete',
'move', 'merge', 'replace', and 'remove'
operations.";
}
}
}
}
}
}
}
}
<CODE ENDS>
}
}
}
output {
choice compare-response {
description
"Comparison results.";
leaf no-matches {
type empty;
description
"This leaf indicates that the filter did not match
anything and nothing was compared.";
}
container differences {
description
"The list of differences, encoded per RFC8072 with an
augmentation to include source values where
applicable.";
uses ypatch:yang-patch {
augment "yang-patch/edit" {
description
"Provide the value of the source of the patch,
respectively of the comparison, in addition to
the target value, where applicable.";
anydata source-value {
when "../operation = 'delete'"
+ "or ../operation = 'merge'"
+ "or ../operation = 'move'"
+ "or ../operation = 'replace'"
+ "or ../operation = 'remove'";
description
"The anydata 'value' is only used for 'delete',
'move', 'merge', 'replace', and 'remove'
operations.";
}
}
}
}
}
}
}
}
<CODE ENDS>
6. Example 6. Example
The following example compares the difference between <operational> The following example compares the difference between <operational>
and <intended> for object "explicit-router-id", as defined in data and <intended> for a subtree under "ospf". The subtree contains
module [I-D.ietf-ospf-yang]. objects that are defined in a YANG data model for the management of
OSPF defined in [I-D.ietf-ospf-yang]. The excerpt of the data model
whose instantiation is basis of the comparison is as follows:
RPC request: container ospf {
leaf enable {
type boolean;
}
leaf explicit-router-id {
type rt-types:router-id;
}
leaf preference {
type uint8;
}
}
<rpc message-id="101" The contents of <intended> and <operational> datastores:
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<compare xmlns="urn:ietf:params:xml:ns:yang:ietf-nmda-compare"
xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
<source>ds:operational</source>
<target>ds:intended</target>
<xpath-filter
xmlns:rt="urn:ietf:params:xml:ns:yang:ietf-routing"
xmlns:ospf="urn:ietf:params:xml:ns:yang:ietf-ospf">\
/rt:routing/rt:control-plane-protocols\
/rt:control-plane-protocol/ospf:ospf\
</xpath-filter>
</compare>
</rpc>
RPC reply, when a difference is detected: <ospf xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
or:origin="or:intended">
<enable>true</enable>
<explicit-router-id>2.2.2.2</explicit-router-id>
</ospf>
<rpc-reply <ospf xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" or:origin="or:operational">
message-id="101"> <enable>true</enable>
<differences <explicit-router-id>1.1.1.1</explicit-router-id>
xmlns="urn:ietf:params:xml:ns:yang:ietf-nmda-compare" <preference>200</preference>
xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"> </ospf>
<yang-patch>
<patch-id>ospf router-id</patch-id>
<comment>diff between operational and intended</comment>
<edit>
<edit-id>1</edit-id>
<operation>replace</operation>
<target>/ietf-ospf:explicit-router-id</target>
<value>
<ospf:explicit-router-id
or:origin="or:system">1.1.1.1<explicit-router-id>
</value>
</edit>
</yang-patch>
</differences>
</rpc-reply>
RPC reply when no difference is detected: <operational> contains one object that was not contained in
<intended>, "preference". Another object, "explicit-router-id", has
differences in values. A third object, "enable", is the same in both
cases.
<rpc-reply RPC request to compare <operational< (source of the comparison) with
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" <intended>(target of the comparison):
message-id="101">
<differences <rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:yang:ietf-nmda-compare"/> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
</rpc-reply> <compare xmlns="urn:ietf:params:xml:ns:yang:ietf-nmda-compare"
xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
<source>ds:operational</source>
<target>ds:intended</target>
<xpath-filter
xmlns:rt="urn:ietf:params:xml:ns:yang:ietf-routing"
xmlns:ospf="urn:ietf:params:xml:ns:yang:ietf-ospf">\
/rt:routing/rt:control-plane-protocols\
/rt:control-plane-protocol/ospf:ospf\
</xpath-filter>
</compare>
</rpc>
RPC reply, when a difference is detected:
<rpc-reply
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
message-id="101">
<differences
xmlns="urn:ietf:params:xml:ns:yang:ietf-nmda-compare"
xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">
<yang-patch>
<patch-id>ospf router-id</patch-id>
<comment>diff between operational and intended</comment>
<edit>
<edit-id>1</edit-id>
<operation>replace</operation>
<target>/ietf-ospf:explicit-router-id</target>
<value>
<ospf:explicit-router-id
or:origin="or:system">1.1.1.1<explicit-router-id>
</value>
<source-value>
<ospf:explicit-router-id
or:origin="or:intended">2.2.2.2<explicit-router-id>
</source-value>
<edit-id>2</edit-id>
<operation>create</operation>
<target>/ietf-ospf:preference</target>
<value>
<ospf:preference
or:origin="or:system">200<preference>
</value>
</edit>
</yang-patch>
</differences>
</rpc-reply>
The same request in RESTCONF (using JSON format): The same request in RESTCONF (using JSON format):
POST /restconf/operations/ietf-nmda-compare:compare HTTP/1.1 POST /restconf/operations/ietf-nmda-compare:compare HTTP/1.1
Host: example.com Host: example.com
Content-Type: application/yang-data+json Content-Type: application/yang-data+json
Accept: application/yang-data+json Accept: application/yang-data+json
{ "ietf-nmda-compare:input" { { "ietf-nmda-compare:input" {
"source" : "ietf-datastores:operational", "source" : "ietf-datastores:operational",
"target" : "ietf-datastores:intended". "target" : "ietf-datastores:intended".
"xpath-filter" : \ "xpath-filter" : \
"/ietf-routing:routing/control-plane-protocols\ "/ietf-routing:routing/control-plane-protocols\
/control-plane-protocol/ietf-ospf:ospf" /control-plane-protocol/ietf-ospf:ospf"
}
} }
}
The same response in RESTCONF (using JSON format): The same response in RESTCONF (using JSON format):
HTTP/1.1 200 OK HTTP/1.1 200 OK
Date: Thu, 26 Jan 2017 20:56:30 GMT Date: Thu, 26 Jan 2019 20:56:30 GMT
Server: example-server Server: example-server
Content-Type: application/yang-data+json Content-Type: application/yang-data+json
{ "ietf-nmda-compare:output" : { { "ietf-nmda-compare:output" : {
"differences" : { "differences" : {
"ietf-yang-patch:yang-patch" : { "ietf-yang-patch:yang-patch" : {
"patch-id" : "ospf router-id", "patch-id" : "ospf router-id",
"comment" : "diff between operational and intended", "comment" : "diff between operational and intended",
"edit" : [ "edit" : [
{ {
"edit-id" : "1", "edit-id" : "1",
"operation" : "replace", "operation" : "replace",
"target" : "/ietf-ospf:explicit-router-id", "target" : "/ietf-ospf:explicit-router-id",
"value" : { "value" : {
"ietf-ospf:explicit-router-id" : "1.1.1.1" "ietf-ospf:explicit-router-id" : "1.1.1.1"
"@ietf-ospf:explicit-router-id" : { "@ietf-ospf:explicit-router-id" : {
"ietf-origin:origin" : "ietf-origin:system" "ietf-origin:origin" : "ietf-origin:system"
} }
} "source-value" : {
} "ietf-ospf:explicit-router-id" : "2.2.2.2"
] "@ietf-ospf:explicit-router-id" : {
} "ietf-origin:origin" : "ietf-origin:intended"
} }
} "edit-id" : "2",
} "operation" : "create",
"target" : "/ietf-ospf:preference",
"value" : {
"ietf-ospf:preference" : "200"
"@ietf-ospf:preference" : {
"ietf-origin:origin" : "ietf-origin:system"
}
}
]
}
}
}
}
7. Open Issues 7. Open Issues
Currently, origin metadata is included in RPC output per default in Currently, origin metadata is included in RPC output per default in
comparisons that involve <operational>. It is conceivable to comparisons that involve <operational>. It is conceivable to
introduce an input parameter that controls whether origin metadata introduce an input parameter that controls whether this origin
should in fact be included. metadata should in fact be included.
Currently the comparison filter is defined using subtree and XPath as Currently the comparison filter is defined using subtree and XPath as
in NETCONF[RFC6241]. It is not clear whether there is a requirement in NETCONF[RFC6241]. It is not clear whether there is a requirement
to allow for the definition of filters that relate instead to target to allow for the definition of filters that relate instead to target
resources per RESTCONF [RFC7950]. resources per RESTCONF [RFC7950].
8. Possible Future Extensions 8. Possible Future Extensions
It is conceivable to extend the compare operation with a number of It is conceivable to extend the compare operation with a number of
possible additional features in the future. possible additional features in the future.
skipping to change at page 13, line 7 skipping to change at page 14, line 21
name: ietf-nmda-compare name: ietf-nmda-compare
namespace: urn:ietf:params:xml:ns:yang:ietf-nmda-compare namespace: urn:ietf:params:xml:ns:yang:ietf-nmda-compare
prefix: cp prefix: cp
reference: RFC XXXX reference: RFC XXXX
10. Security Considerations 10. Security Considerations
Comparing discrepancies between datastores requires a certain amount The YANG module specified in this document defines a schema for data
of processing resources at the server. An attacker could attempt to that is designed to be accessed via network management protocols such
as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
is the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
is HTTPS, and the mandatory-to-implement secure transport is TLS
[RFC8446].
The NETCONF access control model [RFC8341] provides the means to
restrict access for particular NETCONF or RESTCONF users to a
preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content.
The RPC operation defined in this YANG module, "compare", may be
considered sensitive or vulnerable in some network environments. It
is thus important to control access to this operation. This is the
sensitivity/vulnerability of RPC operation "compare":
Comparing datastores for differences requires a certain amount of
processing resources at the server. An attacker could attempt to
attack a server by making a high volume of comparison requests. attack a server by making a high volume of comparison requests.
Server implementations can guard against such scenarios in several Server implementations can guard against such scenarios in several
ways. For one, they can implement NACM in order to require proper ways. For one, they can implement the NETCONF access control model
authorization for requests to be made. Second, server in order to require proper authorization for requests to be made.
implementations can limit the number of requests that they serve in Second, server implementations can limit the number of requests that
any one time interval, potentially rejecting requests made at a they serve to a client in any one time interval, rejecting requests
higher frequency than the implementation can reasonably sustain. made at a higher frequency than the implementation can reasonably
sustain.
11. Acknowledgments 11. Acknowledgments
We thank Rob Wilton, Martin Bjorklund, Mahesh Jethanandani, Lou We thank Rob Wilton, Martin Bjorklund, Mahesh Jethanandani, Lou
Berger, Kent Watsen, Phil Shafer, Ladislav Lhotka for valuable Berger, Kent Watsen, Phil Shafer, Ladislav Lhotka for valuable
feedback and suggestions. feedback and suggestions.
12. References 12. References
12.1. Normative References 12.1. Normative References
skipping to change at page 13, line 41 skipping to change at page 15, line 29
[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, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
[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>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>.
[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.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[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>.
[RFC8072] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Patch [RFC8072] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Patch
Media Type", RFC 8072, DOI 10.17487/RFC8072, February Media Type", RFC 8072, DOI 10.17487/RFC8072, February
2017, <https://www.rfc-editor.org/info/rfc8072>. 2017, <https://www.rfc-editor.org/info/rfc8072>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>. <https://www.rfc-editor.org/info/rfc8340>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>. <https://www.rfc-editor.org/info/rfc8342>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
12.2. Informative References 12.2. Informative References
[I-D.ietf-ospf-yang] [I-D.ietf-ospf-yang]
Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem, Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem,
"YANG Data Model for OSPF Protocol", draft-ietf-ospf- "YANG Data Model for OSPF Protocol", draft-ietf-ospf-
yang-21 (work in progress), January 2019. yang-23 (work in progress), July 2019.
Authors' Addresses Authors' Addresses
Alexander Clemm Alexander Clemm
Futurewei Futurewei
2330 Central Expressway 2330 Central Expressway
Santa Clara, CA 95050 Santa Clara, CA 95050
USA USA
Email: ludwig@clemm.org Email: ludwig@clemm.org
 End of changes. 38 change blocks. 
243 lines changed or deleted 325 lines changed or added

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