< draft-ietf-netconf-yang-push-23.txt   draft-ietf-netconf-yang-push-24.txt >
NETCONF A. Clemm NETCONF A. Clemm
Internet-Draft Huawei USA Internet-Draft Huawei USA
Intended status: Standards Track E. Voit Intended status: Standards Track E. Voit
Expires: November 1, 2019 Cisco Systems Expires: November 16, 2019 Cisco Systems
A. Gonzalez Prieto May 15, 2019
Microsoft
A. Tripathy
E. Nilsen-Nygaard
Cisco Systems
A. Bierman
YumaWorks
B. Lengyel
Ericsson
April 30, 2019
Subscription to YANG Datastores Subscription to YANG Datastores
draft-ietf-netconf-yang-push-23 draft-ietf-netconf-yang-push-24
Abstract Abstract
Via the mechanism described in this document, subscriber applications This document describes a mechanism that allows subscriber
may request a continuous, customized stream of updates from a YANG applications to request a continuous and customized stream of updates
datastore. Providing such visibility into updates enables new from a YANG datastore. Providing such visibility into updates
capabilities based on the remote mirroring and monitoring of enables new capabilities based on the remote mirroring and monitoring
configuration and operational state. of configuration and operational state.
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.
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 1, 2019. This Internet-Draft will expire on November 16, 2019.
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 35 skipping to change at page 2, line 22
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 4 2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 3
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Subscription Model . . . . . . . . . . . . . . . . . . . 5 3.1. Subscription Model . . . . . . . . . . . . . . . . . . . 5
3.2. Negotiation of Subscription Policies . . . . . . . . . . 6 3.2. Negotiation of Subscription Policies . . . . . . . . . . 6
3.3. On-Change Considerations . . . . . . . . . . . . . . . . 7 3.3. On-Change Considerations . . . . . . . . . . . . . . . . 7
3.4. Reliability Considerations . . . . . . . . . . . . . . . 8 3.4. Reliability Considerations . . . . . . . . . . . . . . . 8
3.5. Data Encodings . . . . . . . . . . . . . . . . . . . . . 9 3.5. Data Encodings . . . . . . . . . . . . . . . . . . . . . 9
3.6. Defining the Selection with a Datastore . . . . . . . . . 10 3.6. Defining the Selection with a Datastore . . . . . . . . . 10
3.7. Streaming Updates . . . . . . . . . . . . . . . . . . . . 11 3.7. Streaming Updates . . . . . . . . . . . . . . . . . . . . 11
3.8. Subscription Management . . . . . . . . . . . . . . . . . 13 3.8. Subscription Management . . . . . . . . . . . . . . . . . 13
3.9. Receiver Authorization . . . . . . . . . . . . . . . . . 15 3.9. Receiver Authorization . . . . . . . . . . . . . . . . . 15
skipping to change at page 3, line 9 skipping to change at page 2, line 45
4. A YANG Data Model for Management of Datastore Push 4. A YANG Data Model for Management of Datastore Push
Subscriptions . . . . . . . . . . . . . . . . . . . . . . . . 18 Subscriptions . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 18 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2. Subscription Configuration . . . . . . . . . . . . . . . 24 4.2. Subscription Configuration . . . . . . . . . . . . . . . 24
4.3. YANG Notifications . . . . . . . . . . . . . . . . . . . 25 4.3. YANG Notifications . . . . . . . . . . . . . . . . . . . 25
4.4. YANG RPCs . . . . . . . . . . . . . . . . . . . . . . . . 26 4.4. YANG RPCs . . . . . . . . . . . . . . . . . . . . . . . . 26
5. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 31 5. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 31
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
7. Security Considerations . . . . . . . . . . . . . . . . . . . 48 7. Security Considerations . . . . . . . . . . . . . . . . . . . 48
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 50
9.1. Normative References . . . . . . . . . . . . . . . . . . 50 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 50
9.2. Informative References . . . . . . . . . . . . . . . . . 51 10.1. Normative References . . . . . . . . . . . . . . . . . . 50
10.2. Informative References . . . . . . . . . . . . . . . . . 51
Appendix A. Appendix A: Subscription Errors . . . . . . . . . . 52 Appendix A. Appendix A: Subscription Errors . . . . . . . . . . 52
A.1. RPC Failures . . . . . . . . . . . . . . . . . . . . . . 52 A.1. RPC Failures . . . . . . . . . . . . . . . . . . . . . . 52
A.2. Notifications of Failure . . . . . . . . . . . . . . . . 53 A.2. Notifications of Failure . . . . . . . . . . . . . . . . 53
Appendix B. Changes Between Revisions . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 Appendix B. Changes Between Revisions . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58
1. Introduction 1. Introduction
Traditional approaches to providing visibility into managed entities Traditional approaches to provide visibility into managed entities
from a remote system have been built on polling. With polling, data from a remote system have been built on polling. With polling, data
is periodically requested and retrieved by a client from a server to is periodically requested and retrieved by a client from a server to
stay up-to-date. However, there are issues associated with polling- stay up-to-date. However, there are issues associated with polling-
based management: based management:
o Polling incurs significant latency. This latency prohibits many o Polling incurs significant latency. This latency prohibits many
application types. types of application.
o Polling cycles may be missed, requests may be delayed or get lost, o Polling cycles may be missed and requests may be delayed or get
often when the network is under stress and the need for the data lost, often when the network is under stress and the need for the
is the greatest. data is the greatest.
o Polling requests may undergo slight fluctuations, resulting in o Polling requests may undergo slight fluctuations, resulting in
intervals of different lengths. The resulting data is difficult intervals of different lengths. The resulting data is difficult
to calibrate and compare. to calibrate and compare.
o For applications that monitor for changes, many remote polling o For applications that monitor for changes, many remote polling
cycles place unwanted and ultimately wasteful load on the network, cycles place unwanted and ultimately wasteful load on the network,
devices, and applications, particularly when changes occur only devices, and applications, particularly when changes occur only
infrequently. infrequently.
skipping to change at page 25, line 21 skipping to change at page 25, line 21
* a "period" which defines the duration between push updates. * a "period" which defines the duration between push updates.
* an "anchor-time"; update intervals fall on the points in time * an "anchor-time"; update intervals fall on the points in time
that are a multiple of a "period" from an "anchor-time". If that are a multiple of a "period" from an "anchor-time". If
"anchor-time" is not provided, then the "anchor-time" MUST be "anchor-time" is not provided, then the "anchor-time" MUST be
set with the creation time of the initial update record. set with the creation time of the initial update record.
o For on-change subscriptions, assuming any dampening period has o For on-change subscriptions, assuming any dampening period has
completed, triggering occurs whenever a change in the subscribed completed, triggering occurs whenever a change in the subscribed
information is detected. On-change subscriptions have more information is detected. On-change subscriptions have more
complex semantics that is guided by its own set of parameters: complex semantics that are guided by their own set of parameters:
* a "dampening-period" specifies the interval that must pass * a "dampening-period" specifies the interval that must pass
before a successive update for the subscription is sent. If no before a successive update for the subscription is sent. If no
dampening period is in effect, the update is sent immediately. dampening period is in effect, the update is sent immediately.
If a subsequent change is detected, another update is only sent If a subsequent change is detected, another update is only sent
once the dampening period has passed for this subscription. once the dampening period has passed for this subscription.
* an "excluded-change" parameter which allows restriction of the * an "excluded-change" parameter which allows restriction of the
types of changes for which updates should be sent (e.g., only types of changes for which updates should be sent (e.g., only
add to an update record on object creation). add to an update record on object creation).
skipping to change at page 26, line 12 skipping to change at page 26, line 12
might be part of a "push-update" or "push-change-update" might be part of a "push-update" or "push-change-update"
notification. notification.
An "id" (that identifies the subscription) MUST be transported along An "id" (that identifies the subscription) MUST be transported along
with the subscribed contents. This allows a receiver to with the subscribed contents. This allows a receiver to
differentiate which subscription resulted in a particular update differentiate which subscription resulted in a particular update
record. record.
A "time-of-update" which represents the time an update record A "time-of-update" which represents the time an update record
snapshot was generated. A receiver MAY assume that at this point in snapshot was generated. A receiver MAY assume that at this point in
time a publisher's objects have the values that were pushed. time a publisher's objects had the values that were pushed.
An "incomplete-update" leaf. This leaf indicates that not all An "incomplete-update" leaf. This leaf indicates that not all
changes which have occurred since the last update are actually changes which have occurred since the last update are actually
included with this update. In other words, the publisher has failed included with this update. In other words, the publisher has failed
to fulfill its full subscription obligations. (For example a to fulfill its full subscription obligations. (For example a
datastore was unable to provide the full set of datastore nodes to a datastore was unable to provide the full set of datastore nodes to a
publisher process.) To facilitate re-synchronization of on-change publisher process.) To facilitate re-synchronization of on-change
subscriptions, a publisher MAY subsequently send a "push-update" subscriptions, a publisher MAY subsequently send a "push-update"
containing a full selection snapshot of subscribed data. containing a full selection snapshot of subscribed data.
skipping to change at page 28, line 33 skipping to change at page 28, line 33
/ex:foo /ex:foo
</yp:datastore-xpath-filter> </yp:datastore-xpath-filter>
<yp:on-change> <yp:on-change>
<yp:dampening-period>100</yp:dampening-period> <yp:dampening-period>100</yp:dampening-period>
</yp:on-change> </yp:on-change>
</establish-subscription> </establish-subscription>
</rpc> </rpc>
Figure 12: Establish-subscription request example 2 Figure 12: Establish-subscription request example 2
a publisher that cannot serve on-change updates but periodic updates a publisher that cannot serve on-change updates but that can serve
might return the following NETCONF response: periodic updates might return the following NETCONF response:
<rpc-reply message-id="101" <rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"> xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">
<rpc-error> <rpc-error>
<error-type>application</error-type> <error-type>application</error-type>
<error-tag>operation-failed</error-tag> <error-tag>operation-failed</error-tag>
<error-severity>error</error-severity> <error-severity>error</error-severity>
<error-path>/yp:periodic/yp:period</error-path> <error-path>/yp:periodic/yp:period</error-path>
<error-info> <error-info>
skipping to change at page 29, line 44 skipping to change at page 29, line 44
Figure 14: Modify subscription request Figure 14: Modify subscription request
The publisher MUST respond to the subscription modification request. The publisher MUST respond to the subscription modification request.
If the request is rejected, the existing subscription is left If the request is rejected, the existing subscription is left
unchanged, and the publisher MUST send an RPC error response. This unchanged, and the publisher MUST send an RPC error response. This
response might have hints encapsulated within the YANG-data structure response might have hints encapsulated within the YANG-data structure
"modify-subscription-error-datastore". A subscription MAY be "modify-subscription-error-datastore". A subscription MAY be
modified multiple times. modified multiple times.
The specific parameters to be returned in as part of the RPC error The specific parameters to be returned as part of the RPC error
response depend on the specific transport that is used to manage the response depend on the specific transport that is used to manage the
subscription. For NETCONF, those parameters are specified in subscription. For NETCONF, those parameters are specified in
[I-D.draft-ietf-netconf-netconf-event-notifications]. [I-D.draft-ietf-netconf-netconf-event-notifications].
A configured subscription cannot be modified using "modify- A configured subscription cannot be modified using "modify-
subscription" RPC. Instead, the configuration needs to be edited as subscription" RPC. Instead, the configuration needs to be edited as
needed. needed.
4.4.3. Delete-subscription RPC 4.4.3. Delete-subscription RPC
skipping to change at page 31, line 12 skipping to change at page 31, line 12
of module changes in order to process updates regarding datastore of module changes in order to process updates regarding datastore
nodes from changed modules correctly. nodes from changed modules correctly.
5. YANG Module 5. YANG Module
This YANG module imports typedefs from [RFC6991], identities from This YANG module imports typedefs from [RFC6991], identities from
[RFC8342], the YANG-data extension from [RFC8040], and the yang-patch [RFC8342], the YANG-data extension from [RFC8040], and the yang-patch
grouping from [RFC8072]. In addition, it imports and augments many grouping from [RFC8072]. In addition, it imports and augments many
definitions from [I-D.draft-ietf-netconf-subscribed-notifications]. definitions from [I-D.draft-ietf-netconf-subscribed-notifications].
<CODE BEGINS> file "ietf-yang-push@2019-04-30.yang" <CODE BEGINS> file "ietf-yang-push@2019-05-15.yang"
module ietf-yang-push { module ietf-yang-push {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-yang-push"; namespace "urn:ietf:params:xml:ns:yang:ietf-yang-push";
prefix yp; prefix yp;
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
reference reference
"RFC 6991: Common YANG Data Types"; "RFC 6991: Common YANG Data Types";
} }
skipping to change at page 32, line 45 skipping to change at page 32, line 45
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
(https://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 XXXX;
see the RFC itself for full legal notices."; see the RFC itself for full legal notices.";
// RFC Ed.: replace XXXX with actual RFC number and remove this // RFC Ed.: replace XXXX with actual RFC number and remove this
// note. // note.
revision 2019-04-30 { revision 2019-05-15 {
description description
"Initial revision. "Initial revision.
NOTE TO RFC EDITOR: NOTE TO RFC EDITOR:
(1)Please replace the above revision date to (1)Please replace the above revision date to
the date of RFC publication when published. the date of RFC publication when published.
(2) Please replace the date in the file name (2) Please replace the date in the file name
(ietf-yang-push@2019-04-30.yang) to the date of RFC (ietf-yang-push@2019-05-15.yang) to the date of RFC
publication. publication.
(3) Please replace the following reference to (3) Please replace the following reference to
draft-ietf-netconf-yang-push-23 with RFC number when draft-ietf-netconf-yang-push-24 with RFC number when
published (i.e. RFC xxxx)."; published (i.e. RFC xxxx).";
reference reference
"draft-ietf-netconf-yang-push-23"; "draft-ietf-netconf-yang-push-24";
} }
/* /*
* FEATURES * FEATURES
*/ */
feature on-change { feature on-change {
description description
"This feature indicates that on-change triggered subscriptions "This feature indicates that on-change triggered subscriptions
are supported."; are supported.";
skipping to change at page 45, line 33 skipping to change at page 45, line 33
subscription obligations, and despite its best efforts is subscription obligations, and despite its best efforts is
providing an incomplete set of objects."; providing an incomplete set of objects.";
} }
} }
notification push-change-update { notification push-change-update {
if-feature "on-change"; if-feature "on-change";
description description
"This notification contains an on-change push update. This "This notification contains an on-change push update. This
notification shall only be sent to the receivers of a notification shall only be sent to the receivers of a
subscription; it does not constitute a general-purpose subscription. It does not constitute ageneral-purpose
notification."; notification that would be subscribable as part of the
NETCONF event stream by any receiver.";
leaf id { leaf id {
type sn:subscription-id; type sn:subscription-id;
description description
"This references the subscription which drove the "This references the subscription which drove the
notification to be sent."; notification to be sent.";
} }
container datastore-changes { container datastore-changes {
description description
"This contains the set of datastore changes of the target "This contains the set of datastore changes of the target
datastore starting at the time of the previous update, per datastore starting at the time of the previous update, per
skipping to change at page 47, line 5 skipping to change at page 47, line 6
augment "/sn:subscription-modified/sn:target" { augment "/sn:subscription-modified/sn:target" {
description description
"This augmentation allows the datastore to be included as "This augmentation allows the datastore to be included as
part of the notification that a subscription has been part of the notification that a subscription has been
modified."; modified.";
case datastore { case datastore {
uses datastore-criteria { uses datastore-criteria {
refine "selection-filter/within-subscription" { refine "selection-filter/within-subscription" {
description description
"Specifies where the selection filter, and where it came "Specifies the selection filter and where it originated
from within the subscription and then populated within from. If the 'selection-filter-ref' is populated, the
this notification. If the 'selection-filter-ref' is filter within the subscription came from the 'filters'
populated, the filter within the subscription came from container. Otherwise it is populated in-line as part of
the 'filters' container. Otherwise it is populated the subscription itself.";
in-line as part of the subscription itself.";
} }
} }
} }
} }
/* /*
* DATA NODES * DATA NODES
*/ */
augment "/sn:filters" { augment "/sn:filters" {
skipping to change at page 50, line 12 skipping to change at page 50, line 12
occasional polling to guard against a compromised subscription occasional polling to guard against a compromised subscription
against subscription configuration updates itself. against subscription configuration updates itself.
8. Acknowledgments 8. Acknowledgments
For their valuable comments, discussions, and feedback, we wish to For their valuable comments, discussions, and feedback, we wish to
acknowledge Tim Jenkins, Martin Bjorklund, Kent Watsen, Susan Hares, acknowledge Tim Jenkins, Martin Bjorklund, Kent Watsen, Susan Hares,
Yang Geng, Peipei Guo, Michael Scharf, Guangying Zheng, Tom Petch, Yang Geng, Peipei Guo, Michael Scharf, Guangying Zheng, Tom Petch,
Henk Birkholz, Reshad Rahman, Qin Wu, Rohit Ranade, and Rob Wilton. Henk Birkholz, Reshad Rahman, Qin Wu, Rohit Ranade, and Rob Wilton.
9. References 9. Contributors
9.1. Normative References Alberto Gonzalez Prieto
Microsoft
albgonz@microsoft.com
Ambika Prasad Tripathy
Cisco Systems
ambtripa@cisco.com
Einar Nilsen-Nygaard
Cisco Systems
einarnn@cisco.com
Andy Bierman
YumaWorks
andy@yumaworks.com
Balazs Lengyel
Ericsson
balazs.lengyel@ericsson.com
10. References
10.1. Normative References
[I-D.draft-ietf-netconf-subscribed-notifications] [I-D.draft-ietf-netconf-subscribed-notifications]
Voit, E., Clemm, A., Gonzalez Prieto, A., Tripathy, A., Voit, E., Clemm, A., Gonzalez Prieto, A., Tripathy, A.,
and E. Nilsen-Nygaard, "Subscription to YANG Event and E. Nilsen-Nygaard, "Subscription to YANG Event
Notifications", draft-ietf-netconf-subscribed- Notifications", draft-ietf-netconf-subscribed-
notifications-24 (work in progress), April 2019. notifications-24 (work in progress), April 2019.
[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,
skipping to change at page 51, line 24 skipping to change at page 51, line 45
[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>.
[RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K.,
and R. Wilton, "YANG Library", RFC 8525, and R. Wilton, "YANG Library", RFC 8525,
DOI 10.17487/RFC8525, March 2019, DOI 10.17487/RFC8525, March 2019,
<https://www.rfc-editor.org/info/rfc8525>. <https://www.rfc-editor.org/info/rfc8525>.
9.2. Informative References 10.2. Informative References
[I-D.draft-ietf-netconf-netconf-event-notifications] [I-D.draft-ietf-netconf-netconf-event-notifications]
Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard,
E., and A. Tripathy, "Dynamic subscription to YANG Events E., and A. Tripathy, "Dynamic subscription to YANG Events
and DAtastores over NETCONF", April 2019. and DAtastores over NETCONF", April 2019.
[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>.
skipping to change at page 53, line 49 skipping to change at page 54, line 17
subscription-terminated subscription-suspended subscription-terminated subscription-suspended
----------------------- ---------------------- ----------------------- ----------------------
datastore-not-subscribable period-unsupported datastore-not-subscribable period-unsupported
unchanging-selection update-too-big unchanging-selection update-too-big
synchronization-size synchronization-size
Appendix B. Changes Between Revisions Appendix B. Changes Between Revisions
(To be removed by RFC editor prior to publication) (To be removed by RFC editor prior to publication)
v23 - v24
o Minor updates to address IESG review comments. Moving five of the
coauthors to contributors as requested.
v22 - v23
o Minor updates to address IESG review comments.
v21 - v22 v21 - v22
o Minor updates per Martin Bjorklund's YANG doctor review. o Minor updates per Martin Bjorklund's YANG doctor review.
v20 - v21 v20 - v21
o Minor updates, simplifying RPC input conditions. o Minor updates, simplifying RPC input conditions.
v19 - v20 v19 - v20
o Minor updates per WGLC comments. o Minor updates per WGLC comments.
skipping to change at page 58, line 4 skipping to change at line 2699
Alexander Clemm Alexander Clemm
Huawei USA Huawei USA
Email: ludwig@clemm.org Email: ludwig@clemm.org
Eric Voit Eric Voit
Cisco Systems Cisco Systems
Email: evoit@cisco.com Email: evoit@cisco.com
Alberto Gonzalez Prieto
Microsoft
Email: albgonz@microsoft.com
Ambika Prasad Tripathy
Cisco Systems
Email: ambtripa@cisco.com
Einar Nilsen-Nygaard
Cisco Systems
Email: einarnn@cisco.com
Andy Bierman
YumaWorks
Email: andy@yumaworks.com
Balazs Lengyel
Ericsson
Email: balazs.lengyel@ericsson.com
 End of changes. 27 change blocks. 
50 lines changed or deleted 75 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/