draft-ietf-netmod-nmda-diff-02.txt   draft-ietf-netmod-nmda-diff-03.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: January 9, 2020 J. Tantsura Expires: May 7, 2020 J. Tantsura
Apstra Apstra
A. Bierman A. Bierman
YumaWorks YumaWorks
July 8, 2019 November 4, 2019
Comparison of NMDA datastores Comparison of NMDA datastores
draft-ietf-netmod-nmda-diff-02 draft-ietf-netmod-nmda-diff-03
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 January 9, 2020. This Internet-Draft will expire on May 7, 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 13 skipping to change at page 2, line 13
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 . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . 6
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Performance Considerations . . . . . . . . . . . . . . . . . 12
8. Possible Future Extensions . . . . . . . . . . . . . . . . . 13 8. Possible Future Extensions . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9.1. Updates to the IETF XML Registry . . . . . . . . . . . . 13 9.1. Updates to the IETF XML Registry . . . . . . . . . . . . 13
9.2. Updates to the YANG Module Names Registry . . . . . . . . 14 9.2. Updates to the YANG Module Names Registry . . . . . . . . 14
10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
12.1. Normative References . . . . . . . . . . . . . . . . . . 15 12.1. Normative References . . . . . . . . . . . . . . . . . . 15
12.2. Informative References . . . . . . . . . . . . . . . . . 16 12.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
skipping to change at page 4, line 46 skipping to change at page 4, line 46
nodes that exist in only one of the datastores. When this nodes that exist in only one of the datastores. When this
parameter is not included, a prefiltering step is automatically parameter is not included, a prefiltering step is automatically
applied to exclude data from the comparison that does not pertain applied to exclude data from the comparison that does not pertain
to both datastores: if the same schema node is not present in both to both datastores: if the same schema node is not present in both
datastores, then all instances of that schema node and all its datastores, then all instances of that schema node and all its
descendants are excluded from the comparison. This allows client descendants are excluded from the comparison. This allows client
applications to focus on the differences that constitute true applications to focus on the differences that constitute true
mismatches of instance data without needing to specify more mismatches of instance data without needing to specify more
complex filter constructs. complex filter constructs.
o exclude-origin: When set, this parameter indicates that origin
metadata should not not be included as part of RPC output. When
this parameter is omitted, origin metadata in comparisons that
involve <operational> is by default included.
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
in some cases explain the cause of a difference, for example when in some cases explain the cause of a difference, for example when
a data node is part of <intended> but the origin of the same data a data node is part of <intended> but the origin of the same data
node in <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].
skipping to change at page 5, line 22 skipping to change at page 5, line 27
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
| +---w target identityref | +---w target identityref
| +---w all? empty | +---w all? empty
| +---w exclude-origin? empty
| +---w (filter-spec)? | +---w (filter-spec)?
| +--:(subtree-filter) | +--:(subtree-filter)
| | +---w subtree-filter? | | +---w subtree-filter?
| +--:(xpath-filter) | +--:(xpath-filter)
| +---w xpath-filter? yang:xpath1.0 {nc:xpath}? | +---w xpath-filter? yang:xpath1.0 {nc:xpath}?
+--ro output +--ro output
+--ro (compare-response)? +--ro (compare-response)?
+--:(no-matches) +--:(no-matches)
| +--ro no-matches? empty | +--ro no-matches? empty
+--:(differences) +--:(differences)
skipping to change at page 5, line 49 skipping to change at page 6, line 7
+--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-07-08.yang" <CODE BEGINS> file "ietf-nmda-compare@2019-11-04.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;
} }
skipping to change at page 6, line 40 skipping to change at page 6, line 47
<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-07-08 { The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.
Copyright (c) 2019 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see the
RFC itself for full legal notices.";
revision 2019-11-04 {
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.";
skipping to change at page 7, line 35 skipping to change at page 8, line 12
"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.";
} }
leaf exclude-origin {
type empty;
description
"When this leaf is provided, origin metadata is not
included as part of RPC output. When this leaf is
omitted, origin metadata in comparisons that involve
<operational> is by default included.";
}
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.";
} }
skipping to change at page 12, line 47 skipping to change at page 12, line 47
"@ietf-ospf:preference" : { "@ietf-ospf:preference" : {
"ietf-origin:origin" : "ietf-origin:system" "ietf-origin:origin" : "ietf-origin:system"
} }
} }
] ]
} }
} }
} }
} }
7. Open Issues 7. Performance Considerations
Currently, origin metadata is included in RPC output per default in
comparisons that involve <operational>. It is conceivable to
introduce an input parameter that controls whether this origin
metadata should in fact be included.
Currently the comparison filter is defined using subtree and XPath as The compare operation can be computationally expensive. While
in NETCONF[RFC6241]. It is not clear whether there is a requirement responsible client applications are expected to use the operation
to allow for the definition of filters that relate instead to target responsibly and sparingly only when warranted, implementations need
resources per RESTCONF [RFC7950]. to be aware of the fact that excessive invocation of this operation
will burden system resources and need to ensure that system
performance will not be adversely impacted. One possibility for an
implementation to mitigate against such a possibility is to limit the
number of requests that is served to a client in any one time
interval, rejecting requests made at a higher frequency than the
implementation can reasonably sustain.
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.
Specifically, it is possible to define an extension with an optional Specifically, it is possible to define an extension with an optional
feature for dampening. This will allow clients to specify a minimum feature for dampening. This will allow clients to specify a minimum
time period for which a difference must persist for it to be time period for which a difference must persist for it to be
reported. This will enable clients to distinguish between reported. This will enable clients to distinguish between
skipping to change at page 15, line 8 skipping to change at page 15, line 8
ways. For one, they can implement the NETCONF access control model ways. For one, they can implement the NETCONF access control model
in order to require proper authorization for requests to be made. in order to require proper authorization for requests to be made.
Second, server implementations can limit the number of requests that Second, server implementations can limit the number of requests that
they serve to a client in any one time interval, rejecting requests they serve to a client in any one time interval, rejecting requests
made at a higher frequency than the implementation can reasonably made at a higher frequency than the implementation can reasonably
sustain. 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, and Tim Carey for
feedback and suggestions. valuable feedback and suggestions.
12. References 12. References
12.1. Normative References 12.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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 16, line 24 skipping to change at page 16, line 24
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <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-23 (work in progress), July 2019. yang-29 (work in progress), October 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. 17 change blocks. 
23 lines changed or deleted 56 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/