idnits 2.17.1
draft-netmod-clemm-datastore-push-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
** The document seems to lack a both a reference to RFC 2119 and the
recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
keywords.
RFC 2119 keyword, line 340: '...nses, the server SHOULD include in the...'
RFC 2119 keyword, line 434: '...reason, a server SHALL maintain status...'
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== Line 292 has weird spacing: '...tion-id sub...'
== Line 696 has weird spacing: '...n event to...'
== Line 721 has weird spacing: '...n event to th...'
== The document seems to contain a disclaimer for pre-RFC5378 work, but was
first submitted on or after 10 November 2008. The disclaimer is usually
necessary only for documents that revise or obsolete older RFCs, and that
take significant amounts of text from those RFCs. If you can contact all
authors of the source material and they are willing to grant the BCP78
rights to the IETF Trust, you can and should remove the disclaimer.
Otherwise, the disclaimer is needed and you can ignore this comment.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (October 27, 2014) is 3440 days in the past. Is this
intentional?
Checking references for intended status: Experimental
----------------------------------------------------------------------------
== Missing Reference: 'RFC-5277' is mentioned on line 255, but not defined
** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341)
Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group A. Clemm
3 Internet-Draft A. Gonzalez Prieto
4 Intended status: Experimental E. Voit
5 Expires: April 30, 2015 Cisco Systems
6 October 27, 2014
8 Subscribing to datastore push updates
9 draft-netmod-clemm-datastore-push-00.txt
11 Abstract
13 This document defines a subscription and push mechanism for
14 datastores. This mechanism allows client applications to request
15 updates from a datastore, which are then pushed by the server to the
16 client per a subscription policy, without requiring additional client
17 requests.
19 Status of This Memo
21 This Internet-Draft is submitted in full conformance with the
22 provisions of BCP 78 and BCP 79.
24 Internet-Drafts are working documents of the Internet Engineering
25 Task Force (IETF). Note that other groups may also distribute
26 working documents as Internet-Drafts. The list of current Internet-
27 Drafts is at http://datatracker.ietf.org/drafts/current/.
29 Internet-Drafts are draft documents valid for a maximum of six months
30 and may be updated, replaced, or obsoleted by other documents at any
31 time. It is inappropriate to use Internet-Drafts as reference
32 material or to cite them other than as "work in progress."
34 This Internet-Draft will expire on April 30, 2015.
36 Copyright Notice
38 Copyright (c) 2014 IETF Trust and the persons identified as the
39 document authors. All rights reserved.
41 This document is subject to BCP 78 and the IETF Trust's Legal
42 Provisions Relating to IETF Documents
43 (http://trustee.ietf.org/license-info) in effect on the date of
44 publication of this document. Please review these documents
45 carefully, as they describe your rights and restrictions with respect
46 to this document. Code Components extracted from this document must
47 include Simplified BSD License text as described in Section 4.e of
48 the Trust Legal Provisions and are provided without warranty as
49 described in the Simplified BSD License.
51 This document may contain material from IETF Documents or IETF
52 Contributions published or made publicly available before November
53 10, 2008. The person(s) controlling the copyright in some of this
54 material may not have granted the IETF Trust the right to allow
55 modifications of such material outside the IETF Standards Process.
56 Without obtaining an adequate license from the person(s) controlling
57 the copyright in such materials, this document may not be modified
58 outside the IETF Standards Process, and derivative works of it may
59 not be created outside the IETF Standards Process, except to format
60 it for publication as an RFC or to translate it into languages other
61 than English.
63 Table of Contents
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
66 2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 4
67 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5
68 3.1. Subscription Model . . . . . . . . . . . . . . . . . . . 5
69 3.2. Negotiation of Subscription Policies . . . . . . . . . . 7
70 3.3. Push Data Stream and Transport Mapping . . . . . . . . . 8
71 3.4. Other considerations . . . . . . . . . . . . . . . . . . 9
72 3.4.1. Authorization . . . . . . . . . . . . . . . . . . . . 9
73 3.4.2. Subscription status and subscription monitoring . . . 9
74 3.4.3. Implementation considerations . . . . . . . . . . . . 10
75 4. YANG module . . . . . . . . . . . . . . . . . . . . . . . . . 11
76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
77 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
78 6.1. Normative References . . . . . . . . . . . . . . . . . . 17
79 6.2. Informative References . . . . . . . . . . . . . . . . . 17
81 1. Introduction
83 YANG datastores, i.e. datastores that contain data modeled according
84 using YANG [RFC6020], are not restricted to configuration data, but
85 can also contain operational data. It is therefore reasonable to
86 expect that data in YANG datastores will increasingly be used to
87 support applications that are not focused on managing configurations
88 but that are, for example, related to service assurance.
90 Service assurance applications typically involve monitoring
91 operational state of networks and devices; of particular interest are
92 changes that this data undergoes over time. Likewise, there are
93 applications in which data and objects from one datastore need to be
94 made available to applications in other systems and to remote
95 datastores [peermount-req], requiring mechanisms that allow remote
96 systems to become quickly aware of any updates to allow to validate
97 and maintain cross-network integrity and consistency.
99 Traditional approaches rely heavily on polling, in which data is
100 periodically explicitly retrieved by a client from a server.
102 There are various issues associated with polling-based management:
104 o It introduces additional load on network and devices. Each
105 polling cycle requires a separate yet arguably redundant request
106 that results in an interrupt, requires parsing, consumes
107 bandwidth.
109 o It lacks robustness. Polling cycles may be missed, requests may
110 be delayed or get lost, often particularly in cases when the
111 network is under stress and hence exactly when the need for the
112 data is the greatest.
114 o Data may be difficult to calibrate and compare. Polling cycles
115 may undergo slight fluctuations, resulting in intervals of
116 different lengths which makes data hard to compare. Likewise,
117 pollers may have difficulty issuing requests that reach all
118 devices at the same time, resulting in offset polling intervals
119 which again make data hard to compare.
121 More effective is an alternative in which an application can request
122 to be automatically updated of current content of the datastore (such
123 as a subtree, or data in a subtree that meets a certain filter
124 condition), and in which the server subsequently pushes those
125 updates.
127 The need to perform polling-based management is typically considered
128 an important shortcoming of management applications that rely on MIBs
129 polled using SNMP [RFC1157]. However, without a provision to support
130 a push-based alternative, there is no reason to believe that
131 management applications that operate on YANG datastores using
132 protocols such as NETCONF [RFC6241] or RESTCONF [restconf] will be
133 any more effective, as they would follow the same request/response
134 pattern.
136 While YANG allows to define notifications, such notifications are
137 generally intended to indicate the occurrence of certain well-
138 specified event conditions, such as a the onset of an alarm condition
139 or the occurrence of an error. Likewise, a capability to define
140 configuration change events has been defined in [RFC5277]. However,
141 these change events pertain only to configuration information, not to
142 operational state. RFC 5277 furthermore predates YANG and does not
143 provide tie-in with YANG-defined datastore contents.
145 Service Assurance applications are not the only applications
146 benefiting from a push- and subscription-based alternative to
147 polling. Another example is Peer Mount [peermount]. Peer Mount
148 allows a datastore to incorporate data from remote datastores by
149 reference, resulting in virtual datastores that are federated across
150 a network and offer different local views. Various use cases
151 indicate the usefulness of introducing caching in conjunction with
152 Peer Mount, which benefits greatly if updates can automatically be
153 pushed from a mount server to a mount client.
155 The way in which the updates are to occur can be directed by policy.
156 For example, a client may request to be updated periodically in
157 certain intervals, or whenever data changes occur.
159 Because not every server may support every requested interval for
160 every piece of data, it is furthermore necessary for a server to be
161 able to indicate whether or not it is capable of supporting a
162 requested subscription, and possibly allow to negotiate subscription
163 parameters.
165 Finally, a mechanism is needed to communicate the updates themselves.
166 One option is to use existing NETCONF and RESTCONF mechanisms, by
167 defining special notifications with which to carry those updates.
168 Other alternatives are conceivable, such as use of a dedicated
169 publish/subscribe mechanism that provides an alternative to a NETCONF
170 or RESTCONF transport.
172 This document specifies a YANG data model for the configuration and
173 management of subscriptions to data in YANG datastores. It also
174 defines a notification that can be used to carry data updates and
175 thus serve as push mechanism.
177 2. Definitions and Acronyms
179 Data node: An instance of management information in a YANG datastore.
181 Datastore: A conceptual store of instantiated management information,
182 with individual data items represented by data nodes which are
183 arranged in a hierarchical manner.
185 Data subtree: An instantiated data node and the data nodes that are
186 hierarchically contained within it.
188 Mount client: The system at which a mount point resides, into which
189 the remote subtree is mounted.
191 Mount point: A data node that receives the root node of the remote
192 datastore being mounted.
194 Mount server: The server with which the mount client communicates and
195 which provides the mount client with access to the mounted
196 information. Can be used synonymously with mount target.
198 Mount target: A remote server whose datastore is being mounted.
200 NACM: NETCONF Access Control Model
202 NETCONF: Network Configuration Protocol
204 Peer Mount: An extension to the YANG management framework that allows
205 local YANG datastores to incorporate data from remote (peer) YANG
206 datastores.
208 RPC: Remote Procedure Call
210 Remote datastore: A datastore residing at a remote node
212 SNMP: Simple Network Management Protocol
214 URI: Uniform Resource Identifier
216 YANG: A data definition language for NETCONF
218 3. Solution Overview
220 This document specifies a solution that allows clients to subscribe
221 to information updates in a YANG datastore, which are subsequently
222 pushed from the server to the client. The solution encompasses
223 several components:
225 o The configuration and management of the subscriptions.
227 o An ability to negotiate subscription parameters where a
228 subscription policy desired by a client cannot be supported.
230 o The datastream of the push updates.
232 In addition, there are a number of additional considerations, such as
233 the tie-in of the mechanisms with security mechanisms. Each of those
234 aspects will be discussed in the following subsections.
236 3.1. Subscription Model
238 Yang allows modeling the content of notifications. The contents are
239 a set of explicitly stated data nodes forming a hierarchy. For
240 modeling updates in a datastore, a new generic notification is
241 introduced, the "push-update". This notification has the following
242 semantics. The contents of the notification are not explicitly
243 stated. They are the union of the data nodes in the yang modules
244 supported by the server, excluding the following statements:
245 "mandatory", "must", "min-elements", "max-elements", "when", and
246 "default". Note that the notification contents are dynamic,
247 depending on the modules supported by the server.
249 Subscriptions to the "push-update" are initiated by clients. Servers
250 respond to a subscription request explicitly positively or
251 negatively. Negative responses include information describing the
252 reason for the subscription rejection.
254 Datastore-push subscriptions are defined using a data model. This
255 model is based on the subscriptions defined in [RFC-5277], which is
256 also reused in RESTCONF. The model is extended with a subscription
257 type a set of parameters for each type. The complete set of
258 subscription parameters is:
260 o The name of the stream to subscribe to. The stream is called
261 "push-update".
263 o The identity of the subscriber.
265 o An optional filter. It describes the subset of stream events of
266 interest to the subscriber. The server should only send to the
267 subscriber the events that match the filter, when present. The
268 absence of a filter indicates that all events in the stream are of
269 interest to the subscriber and all events in it must be sent to
270 the subscriber. Two filtering mechanisms are considered: subtree
271 filtering and Xpath filtering, with the semantics described in
272 [RFC5277].
274 o An optional start time. Used to trigger replays starting at the
275 provided time. Its semantics are those in [RFC5277].
277 o An optional stop time. Used to limit temporarily the events of
278 interest. Its semantics are those in [RFC5277].
280 o A notification trigger definition. The trigger can be periodic or
281 based on change. For periodic subscriptions, the trigger is
282 defined by the interval with which to push updates. For on-change
283 subscriptions, the trigger is defined using the dampening interval
284 with which to push repeated changes, an indicator forthe magnitude
285 of changes, etc.
287 The following figure depicts the data model.
289 module: ietf-datastore-push
290 +--rw datastore-push-subscription
291 +--rw stream string
292 +--rw subscription-id subscription-identifier
293 +--rw (filter)?
294 | +--:(substree)
295 | | +--rw subtree-filter
296 | +--:(xpath)
297 | +--rw xpath-filter yang:xpath1.0
298 +--rw (notification-trigger)
299 | +--:(periodic)
300 | | +--rw period yang:timeticks
301 | +--:(on-change)
302 | +--rw (change-policy)
303 | +--:(delta-policy)
304 | +--rw delta uint32
305 +--rw start-time? yang:date-and-time
306 +--rw stop-time? yang:date-and-time
308 Figure 1: Model structure
310 The example below illustrates a subcription for a periodic push of
311 all data under a container called foo.
313
315
317 push-update
318 foo
319
322 500
323
324
325
327 Figure 2: Subscription example
329 3.2. Negotiation of Subscription Policies
331 A subscription rejection can be caused by the inability of the server
332 to provide a stream with the requested semantics. Providing "on-
333 change" updates for operational data can be computationally expensive
334 and an agent may decide not to support them or supporting them for a
335 small number of subscribers or for a limited set of data nodes.
337 Datastore-push supports a simple negotiation between clients and
338 servers for subscription parameters. The negotiation is limited to a
339 single pair of subscription request and response. For negative
340 responses, the server SHOULD include in the returned error what
341 subscription parameters would have been accepted for the request.
342 The returned acceptable parameters are no guarantee for subsequent
343 requests for this client or others.
345 The example below illustrates a subcription response, where an agent
346 does not support frequent periodic updates, and suggests a different
347 sampling rate to the client.
349
351
353 push-update
354 foo
355
358 500
359
360
361
363
364
365 application
366 operation-not-supported
367 error
368
369
370 3000
371
372
373
374
376 Figure 3: Subscription negotiation example
378 3.3. Push Data Stream and Transport Mapping
380 Pushing data based on a subscription could be considered analogous to
381 a response to a data retrieval request, e.g. a "get" request.
382 However, contrary to such a request, multiple responses to the same
383 request may get sent over a longer period of time. Likewise, clients
384 need to be able to distinguish between data updates and state update
385 regarding the subscription itself, for example when a subscription
386 can no longer be serviced.
388 A more suitable mechanism is therefore that of a notification.
389 Contrary to notifications associated with alarms and unexpected event
390 occurrences, push updates are solicited, i.e. tied tied to a
391 particular subscription which triggered the notification. (An
392 alternative conceptual model would consider a subscription an "opt-
393 in" filter on a continuous stream of updates.)
395 The notification contains several parameters:
397 o A subscription correlator, referencing the name of the
398 subscription on whose behalf the notification is sent.
400 o A data node that contains a representation of the datastore
401 subtree containing the updates. The subtree is filtered per
402 access control rules to contain only data that the subscriber is
403 authorized to see. Also, depending on the subscription type,
404 i.e., specifically for on-change subscriptions, the subtree
405 contains only the data nodes that contain actual changes. (This
406 can be simply a node of type string or, for XML-based encoding,
407 anyxml.)
409 Notifications are sent using elements as defined in
410 [RFC5277]. Alternative transports are conceivable but outside the
411 scope of this specification.
413 3.4. Other considerations
415 3.4.1. Authorization
417 A client may only receive updates to data that the client has proper
418 authorization for. Normal authorization rules apply. Data that is
419 being pushed therefore needs to be subjected to a filter that applies
420 the corresponding rules, removing any non-authorized data as
421 applicable.
423 The authorization model for data in YANG datastores is described in
424 the Netconf Access Control Model [RFC6536].
426 3.4.2. Subscription status and subscription monitoring
428 It is possible that a server may no longer be able to serve a
429 subscription that had been previously accepted. For example, a
430 server may have run out of resources, or internal errors may have
431 occurred. When this is the case, a server needs to be able to
432 temporarily suspend the subscription, or even to terminate it.
434 For this reason, a server SHALL maintain status information for each
435 subscription that indicates the current status of the subscription.
437 In addition, a server needs to indicate any changes in status to the
438 subscriber through a notification. Specifically, subscribers need to
439 be informed of the following:
441 o A subscription has been temporarily suspended, including the
442 reason. (See subscription-suspended in the model below.)
444 o A subscription (that had been suspended earlier) is once again
445 operational. (See subscription-resumed in the model below.)
447 o A subscription has been abnormally terminated, including the
448 reason. (See subscription-terminated in the model below.)
450 Finally, a server might provide additional information about
451 subscriptions, such as statistics about the number of data updates
452 that were sent. However, such information is currently outside the
453 scope of this specification.
455 3.4.3. Implementation considerations
457 Implementation specifics are outside the scope of this specification.
458 That said, it should be noted that monitoring of operational state
459 changes inside a system can be associated with significant
460 implementation challenges.
462 Even periodic retrieval of operational state alone, to be able to
463 push it, can consume considerable system resources. Configuration
464 data may in many cases be persisted in an actual database or a
465 configuration file, where retrieval of the database content or the
466 file itself is reasonably straightforward and computationally
467 inexpensive. However, retrieval of operational data may, depending
468 on the implementation, require invocation of APIs, possibly on an
469 object-by-object basis, possibly involving additional internal
470 interrupts, etc.
472 For those reasons, if is important for an implementation to
473 understand what subscriptions it can or cannot support. It is far
474 preferrable to decline a subscription request, than to accept it only
475 to result in subsequent failure later.
477 Whether or not a subscription can be supported will in general be
478 determined by a combination of several factors, including the
479 subscription policy (on-change or periodic, with on-change in general
480 being the more challenging of the two), the period in which to report
481 changes (1 second periods will consume more resources than 1 hour
482 periods), the amount of data in the subtree that is being subscribed
483 to, and the number and combination of other subscriptions that are
484 concurrently being serviced.
486 4. YANG module
488
489 file "ietf-datastore-push@2014-10-27.yang"
491 module ietf-datastore-push {
492 // RFC Ed.: replace XXXX with 'ietf' and remove this note
493 namespace "urn:XXXX:params:xml:ns:yang:ietf-datastore-push";
494 prefix "datastore-push";
496 import ietf-yang-types { prefix yang; }
498 organization
499 "IETF";
501 contact
502 "Editor: Alexander Clemm
503
505 Editor: Alberto Gonzalez Prieto
506
508 Editor: Eric Voit
509 ";
511 description
512 "This module contains conceptual YANG specifications
513 for datastore push.";
515 revision 2014-10-27 {
516 description
517 "Initial revision.";
518 reference
519 "Datastore push.";
520 }
522 // Typedefs
523 typedef datastore-contents {
524 type string;
525 description
526 "The encoding of the contents adheres to the subscription
527 parameters. It corresponds to the filtered datastore
528 subtree.";
529 }
531 typedef subscription-identifier {
532 type string {
533 length "1 .. max";
534 }
535 description
536 "A client-provided identifier for the subscription.";
537 }
539 // Identities
540 // Subscription error
541 identity subscription-errors {
542 description
543 "Base identity for subscription errors.";
544 }
546 typedef subscription-term-reason {
547 type identityref {
548 base "subscription-errors";
549 }
550 description
551 "Reason for a server to terminate a subscription.";
552 }
554 typedef subscription-susp-reason {
555 type identityref {
556 base "subscription-errors";
557 }
558 description
559 "Reason for a server to suspend a subscription.";
560 }
562 identity internal-error {
563 base "subscription-errors";
564 description
565 "Subscription failures caused by server internal error.";
566 }
568 identity no-resources {
569 base "subscription-errors";
570 description
571 "Lack of resources, e.g. CPU, memory, bandwidth";
572 }
573 identity other {
574 base "subscription-errors";
575 description
576 "Fallback reason - any other reason";
577 }
579 // Notifications
580 notification push-update {
581 description
582 "This notification contains an update from a datastore";
584 leaf subscription-id {
585 type subscription-identifier;
586 mandatory true;
587 description
588 "This references the subscription because of which the
589 notification is sent.";
590 }
592 leaf datastore-contents {
593 type datastore-contents;
594 description
595 "This contains datastore contents
596 per the subscription.";
597 }
598 }
600 notification subscription-suspended {
601 description
602 "This notification indicates a suspension of the
603 subscription by the server has occurred. No further
604 datastore updates will be sent until subscription
605 resumes.";
607 leaf subscription-id {
608 type subscription-identifier;
609 mandatory true;
610 description
611 "This references the affected subscription.";
612 }
614 leaf reason {
615 type subscription-susp-reason;
616 description
617 "Provides a reason for why the subscription was
618 suspended.";
619 }
621 }
623 notification subscription-resumed {
624 description
625 "This notification indicates that a subscription that had
626 previously been suspended has resumed. Datastore updates
627 will once again be sent.";
628 leaf subscription-id {
629 type subscription-identifier;
630 mandatory true;
631 description
632 "This references the affected subscription.";
633 }
634 }
636 notification subscription-terminated {
637 description
638 "This notification indicates that a subscription has been
639 terminated.";
641 leaf subscription-id {
642 type subscription-identifier;
643 mandatory true;
644 description
645 "This references the affected subscription.";
647 }
649 leaf reason {
650 type subscription-term-reason;
651 description
652 "Provides a reason for why the subscription was
653 terminated.";
654 }
655 }
657 container datastore-push-subscription {
658 description
659 "Content of a yang-push subscription.";
661 leaf stream {
662 type string;
663 mandatory true;
664 description
665 "The name of the stream to subscribe to.";
666 }
667 leaf subscription-id {
668 type subscription-identifier;
669 mandatory true;
670 description
671 "Identifier to use for this subscription.";
672 }
673 choice filter {
674 description
675 "Subset of stream events of interest.";
676 case substree {
677 container subtree-filter {
678 description
679 "Datastore subtree of interest.";
680 }
681 }
683 case xpath {
684 leaf xpath-filter {
685 type yang:xpath1.0;
686 mandatory true;
687 description
688 "Xpath defining the events of interest.";
689 }
690 }
691 }
693 choice notification-trigger {
694 mandatory true;
695 description
696 "Defines necessary conditions for sending an event to
697 the subscriber.";
698 case periodic {
699 description
700 "The agent is requested to notify periodically the
701 current values of the datastore or the subset
702 defined by the filter.";
703 leaf period {
704 type yang:timeticks;
705 mandatory true;
706 description
707 "Elapsed time between notifications.";
708 }
709 }
711 case on-change {
712 description
713 "The agent is requested to notify changes in
714 values in the datastore or a subset of it defined
715 by a filter.";
717 choice change-policy {
718 mandatory true;
719 description
720 "Policy describing necessary conditions for
721 sending an event to the subscriber.";
722 case delta-policy {
723 leaf delta {
724 type uint32;
725 mandatory true;
726 description
727 "For integer, minimum difference
728 between current and last reports
729 values that can trigger an update.";
730 }
731 }
732 }
733 }
734 }
736 leaf start-time {
737 type yang:date-and-time;
738 description
739 "Starting time for replays.";
740 reference "RFC 5277, Section 2.1.1";
741 }
743 leaf stop-time {
744 type yang:date-and-time;
745 description
746 "Time limit for events of interest.";
747 reference "RFC 5277, Section 2.1.1";
748 }
749 }
750 }
752
754 5. Security Considerations
756 Subscriptions could be used to attempt to overload servers of YANG
757 datastores. For this reason, it is important that the server has the
758 ability to decline a subscription request if it would deplete its
759 resources. In addition, a server needs to be able to suspend an
760 existing subscription when needed. When this occur, the subscription
761 status is updated accordingly and the clients are notified.
762 Likewise, requests for subscriptions need to be properly authorized.
764 A subscription could be used to retrieve data in subtrees that a
765 client has not authorized access to. Therefore it is important that
766 data pushed based on subscriptions is authorized in the same way that
767 regular data retrieval operations are. Data being pushed to a client
768 needs therefore to be filtered accordingly, just like if the data
769 were being retrieved on-demand. The Netconf Authorization Control
770 Model applies.
772 6. References
774 6.1. Normative References
776 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin,
777 "Simple Network Management Protocol (SNMP)", STD 15, RFC
778 1157, May 1990.
780 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event
781 Notifications", RFC 5277, July 2008.
783 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
784 Network Configuration Protocol (NETCONF)", RFC 6020,
785 October 2010.
787 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
788 Bierman, "Network Configuration Protocol (NETCONF)", RFC
789 6241, June 2011.
791 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
792 Protocol (NETCONF) Access Control Model", RFC 6536, March
793 2012.
795 6.2. Informative References
797 [peermount]
798 Clemm, A., Medved, J., and E. Voit, "Mounting YANG-defined
799 information from remote datastores", draft-clemm-netmod-
800 mount-02 (work in progress), October 2014.
802 [peermount-req]
803 Voit, E., Clemm, A., Bansal, S., Tripathy, A., and P.
804 Yellai, "Requirements for Peer Mounting of YANG subtrees
805 from Remote Datastores", draft-voit-netmod-peer-mount-
806 requirements-00 (work in progress), September 2014.
808 [restconf]
809 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
810 Protocol", I-D draft-ietf-netconf-restconf-03, October
811 2014.
813 Authors' Addresses
815 Alexander Clemm
816 Cisco Systems
818 EMail: alex@cisco.com
820 Alberto Gonzalez Prieto
821 Cisco Systems
823 EMail: albertgo@cisco.com
825 Eric Voit
826 Cisco Systems
828 EMail: evoit@cisco.com