idnits 2.17.1 draft-ietf-i2rs-pub-sub-requirements-07.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 4, 2016) is 2914 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Interface to the Routing System (i2rs) E. Voit 3 Internet-Draft A. Clemm 4 Intended status: Informational A. Gonzalez Prieto 5 Expires: November 5, 2016 Cisco Systems 6 May 4, 2016 8 Requirements for Subscription to YANG Datastores 9 draft-ietf-i2rs-pub-sub-requirements-07 11 Abstract 13 This document provides requirements for a service that allows client 14 applications to subscribe to updates of a YANG datastore. Based on 15 criteria negotiated as part of a subscription, updates will be pushed 16 to targeted recipients. Such a capability eliminates the need for 17 periodic polling of YANG datastores by applications and fills a 18 functional gap in existing YANG transports (i.e. Netconf and 19 Restconf). Such a service can be summarized as a "pub/sub" service 20 for YANG datastore updates. Beyond a set of basic requirements for 21 the service, various refinements are addressed. These refinements 22 include: periodicity of object updates, filtering out of objects 23 underneath a requested a subtree, and delivery QoS guarantees. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on November 5, 2016. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Business Drivers . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. Pub/Sub in I2RS . . . . . . . . . . . . . . . . . . . . . 3 62 2.2. Pub/Sub variants on Network Elements . . . . . . . . . . 5 63 2.3. Existing Generalized Pub/Sub Implementations . . . . . . 5 64 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 66 4.1. Assumptions for Subscriber Behavior . . . . . . . . . . . 7 67 4.2. Subscription Service Requirements . . . . . . . . . . . . 7 68 4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 7 69 4.2.2. Negotiation . . . . . . . . . . . . . . . . . . . . . 9 70 4.2.3. Update Distribution . . . . . . . . . . . . . . . . . 9 71 4.2.4. Transport . . . . . . . . . . . . . . . . . . . . . . 10 72 4.2.5. Security Requirements . . . . . . . . . . . . . . . . 11 73 4.2.6. Subscription QoS . . . . . . . . . . . . . . . . . . 12 74 4.2.7. Filtering . . . . . . . . . . . . . . . . . . . . . . 13 75 4.2.8. Assurance and Monitoring . . . . . . . . . . . . . . 14 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 78 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 81 8.2. Informative References . . . . . . . . . . . . . . . . . 15 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 84 1. Introduction 86 Applications interacting with YANG datastores require capabilities 87 beyond the traditional client-server configuration of network 88 elements. One class of such applications are service-assurance 89 applications which must maintain a continuous view of operational 90 data and state. Another class of applications are security 91 applications which must continuously track changes made upon network 92 elements to ensure compliance to corporate policy. 94 Periodic fetching of data is not an adequate solution for 95 applications requiring frequent or prompt updates of remote object 96 state. Applying polling-based solutions here imposes load on 97 networks, devices, and applications. Additionally, polling solutions 98 are brittle in the face of communication glitches, and have 99 limitations in their ability to synchronize and calibrate retrieval 100 intervals across a network. These limitations can be addressed by 101 including generic object subscription mechanisms within Network 102 Elements, and allowing these mechanisms to be applied in the context 103 of data that is conceptually contained in YANG datastores. 105 This document aggregates requirements for such subscription from a 106 variety of deployment scenarios. 108 2. Business Drivers 110 For decades, information delivery of current network state has been 111 accomplished either by fetching from operations interfaces, or via 112 dedicated, customized networking protocols. With the growth of 113 centralized orchestration infrastructures, imperative policy 114 distribution, and YANG's ascent as the dominant data modeling 115 language for use in programmatic interfaces to network elements, this 116 mixture of fetch plus custom networking protocols is no longer 117 sufficient. What is needed is a push mechanism that is able to 118 deliver object changes as they happen. 120 These push distribution mechanisms will not replace existing 121 networking protocols. Instead they will supplement these protocols, 122 providing different response time, peering, scale, and security 123 characteristics. 125 Push solutions will not displace all existing operations 126 infrastructure needs. And SNMP and MIBs will remain widely deployed 127 and the defacto choice for many monitoring solutions. But some 128 functions could be displaced. Arguably the biggest shortcoming of 129 SNMP for those applications concerns the need to rely on periodic 130 polling, because it introduces additional load on the network and 131 devices, because it is brittle in case polling cycles are missed, and 132 because is hard to synchronize and calibrate across a network. If 133 applications can only use polling type interaction patterns with YANG 134 datastores, similar issues can be expected. 136 2.1. Pub/Sub in I2RS 138 Various I2RS documents highlight the need to provide Pub/Sub 139 capabilities between network elements. From [i2rs-arch], there are 140 references throughout the document beginning in section 6.2. Some 141 specific examples include: 143 o section 7.6 provides high level pub/sub (notification) guidance 144 o section 6.4.2 identifies "subscribing to an information stream of 145 route changes receiving notifications about peers coming up or 146 going down" 148 o section 6.3 notes that when local config preempts I2RS, external 149 notification might be necessary 151 In addition [i2rs-usecase] has relevant requirements. A small subset 152 includes: 154 o L-Data-REQ-12: The I2RS interface should support user 155 subscriptions to data with the following parameters: push of data 156 synchronously or asynchronously via registered subscriptions... 158 o L-DATA-REQ-07: The I2RS interface (protocol and IMs) should allow 159 a subscriber to select portions of the data model. 161 o PI-REQ01: monitor the available routes installed in the RIB of 162 each forwarding device, including near real time notification of 163 route installation and removal. 165 o BGP-REQ10: I2RS client should be able to instruct the I2RS 166 agent(s) to notify the I2RS client when the BGP processes on an 167 associated routing system observe a route change to a specific set 168 of IP Prefixes and associated prefixes....The I2RS agent should be 169 able to notify the client via publish or subscribe mechanism. 171 o IGP-REQ-07: The I2RS interface (protocol and IMs) should support a 172 mechanism where the I2RS Clients can subscribe to the I2RS Agent's 173 notification of critical node IGP events. 175 o MPLS-LDP-REQ-03: The I2RS Agent notifications should allow an I2RS 176 client to subscribe to a stream of state changes regarding the LDP 177 sessions or LDP LSPs from the I2RS Agent. 179 o L-Data-REQ-01: I2rs must be able to collect large data set from 180 the network with high frequency and resolution with minimal impact 181 to the device's CPU and memory. 183 And [i2rs-traceability] has Pub/Sub requirements listed in 184 Section 7.4.3. 186 o I2RS Agents should support publishing I2RS trace log information 187 to that feed as described in [i2rs-arch]. Subscribers would then 188 receive a live stream of I2RS interactions in trace log format and 189 could flexibly choose to do a number of things with the log 190 messages 192 2.2. Pub/Sub variants on Network Elements 194 This document is intended to cover requirements beyond I2RS. Looking 195 at history, there are many examples of switching and routing 196 protocols which have done explicit or implicit pub/sub in the past. 197 In addition, new policy notification mechanisms which operate on 198 switches and routers are being specified now. A small subset of 199 current and past subscription mechanisms includes: 201 o Multicast topology establishment is accomplished before any 202 content delivery is made to endpoints (IGMP, PIM, etc.) 204 o Secure Automation and Continuous Monitoring (SACM) allows 205 subscription into devices which then may push spontaneous changes 206 in their configured hardware and software[sacm-requirements] 208 o In MPLS VPNs [RFC6513] a Customer Edge router exchanges PIM 209 control messages before PE Routing Adjacencies are passed. 210 [RFC6513] 212 o After OSPF establishes its adjacencies, Link State Advertisement 213 will then commence [RFC2328] 215 Worthy of note in the examples above is the wide variety of 216 underlying transports. A generalized Pub/Sub mechanism therefore 217 should be structured to support alternative transports. Based on 218 current I2RS requirements, NETCONF should be the initially supported 219 transport based on the need for connection-oriented/unicast 220 communication. Eventual support for multicast and broadcast 221 subscription update distribution will be needed as well. 223 2.3. Existing Generalized Pub/Sub Implementations 225 TIBCO, RSS, CORBA, and other technologies all show precursor Pub/Sub 226 technologies. However there are new needs described in Section 4 227 below which these technologies do not serve. We need a new pub-sub 228 technology. 230 There are at least two widely deployed generalized pub/sub 231 implementations which come close to current needs: XMPP[XEP-0060] and 232 DDS[OMG-DDS]. Both serve as proof-points that a highly scalable 233 distributed datastore implementation connecting millions of edge 234 devices is possible. 236 Because of these proof points, we can be comfortable that the 237 underlying technologies can enable reusable generalized YANG object 238 distribution. Analysis will need to fully dimension the speed and 239 scale of such object distribution for various subtree sizes and 240 transport types. 242 3. Terminology 244 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 245 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 246 document are to be interpreted as described in [RFC2119]. Although 247 this document is not a protocol specification, the use of this 248 language clarifies the instructions to protocol designers producing 249 solutions that satisfy the requirements set out in this document. 251 A Subscriber makes requests for set(s) of YANG object data. 253 A Publisher is responsible for distributing subscribed YANG object 254 data per the terms of a Subscription. In general, a Publisher is the 255 owner of the YANG datastore that is subjected to the Subscription. 257 A Receiver is the target to which a Publisher pushes updates. In 258 general, the Receiver and Subscriber will be the same entity. A 259 Subscription Service provides Subscriptions to Subscribers of YANG 260 data. 262 A Subscription Service interacts with the Publisher of the YANG data 263 as needed to provide the data per the terms of the Subscription. 265 A Subscription Request for one or more YANG subtrees (including 266 single leafs) is made by the Subscriber of a Publisher and is 267 targeted to a Receiver. A Subscription may include constraints which 268 dictate how often or under what conditions YANG information updates 269 might be sent. 271 A Subscription is a contract between a Subscription Service and a 272 Subscriber that stipulates the data to be pushed and the associated 273 terms. 275 A datastore is defined in [RFC6241] and is not redefined here. 277 An Update provides object changes which have occurred within 278 subscribed YANG subtree(s). An Update must include the current 279 status of (data) node instances which according to any filtering are 280 reportably different from the previously provided state. An Update 281 may include a bundled set of ordered/sequential changes for a given 282 object that have been made since the last update. 284 A Filter contains evaluation criteria which are evaluated against 285 YANG object(s) within a Subscription. There are two types of 286 Filters: Subtree Filters which identify selected objects/nodes 287 published under a target data node, and object element and attribute 288 Filters where an object should only be published if it has properties 289 meeting specified Filter criteria. 291 4. Requirements 293 Many of the requirements within this section have been adapted from 294 XMPP[XEP-0060] and DDS[OMG-DDS] requirements specifications. 296 4.1. Assumptions for Subscriber Behavior 298 This document provides requirements for the Subscription Service. It 299 does not define all the requirements for the Subscriber/Receiver. 300 However in order to frame the desired behavior of the Subscription 301 Service, it is important to specify key input constraints. 303 A Subscriber SHOULD avoid attempting to establish multiple 304 Subscriptions pertaining to the same information, i.e. referring to 305 the same datastore YANG subtrees. 307 A Subscriber MAY provide Subscription QoS criteria to the 308 Subscription Service; if the Subscription Service is unable to meet 309 those criteria, the Subscription SHOULD NOT be established. 311 When a Subscriber and Receiver are the same entity and the transport 312 session is lost/terminated, the Subscriber MUST reestablish any 313 subscriptions it previously created via signalling over the transport 314 session. I.e., There is no requirement for the life span of such 315 signaled Subscriptions extend beyond the life span of the transport 316 session. 318 A Subscriber MUST be able to infer when a Subscription Service is no 319 longer active and when no more updates are being sent. 321 A Subscriber MAY check with a Subscription Service to validate the 322 existence and monitored subtrees of a Subscription. 324 A Subscriber MUST be able to periodically lease and extend the lease 325 of a Subscription from a Subscription Service. 327 4.2. Subscription Service Requirements 329 4.2.1. General 331 A Subscription Service MUST support the ability to create, renew, 332 timeout, and terminate a Subscription. 334 A Subscription Service MUST be able to support and independently 335 track multiple Subscription Requests by the same Subscriber. 337 A Subscription Service MUST be able to support an add/change/delete 338 of subscriptions to multiple YANG subtrees as part of the same 339 Subscription Request. 341 A Subscription Service MUST support Subscriptions against operational 342 datastores, configuration datastores, or both. 344 A Subscription Service MUST be able support filtering so that 345 subscribed updates under a target node might publish only operational 346 data, only configuration data, or both. 348 A Subscription MAY include Filters as defined within a Subscription 349 Request, therefore the Subscription Service MUST publish only data 350 nodes that meet the Filter criteria within a Subscription. 352 A Subscription Service MUST support the ability to subscribe to 353 periodic updates. The subscription period MUST be configurable as 354 part of the subscription request. 356 A Subscription Service SHOULD support the ability to subscribe to 357 updates "on-change", i.e., whenever values of subscribed data objects 358 change. 360 For "on-change" updates, the Subscription Service MUST support a 361 dampening period that needs to pass before the first or subsequent 362 "on-change" updates are sent. The dampening period SHOULD be 363 configurable as part of the subscription request. 365 A Subscription Service MUST allow Subscriptions to be monitored. 366 Specifically, a Subscription Service MUST at a minimum maintain 367 information about which Subscriptions are being serviced, the terms 368 of those subscriptions (e.g., what data is being subscribed, 369 associated Filters, update policy - on change, periodic), and the 370 overall status of the Subscription - e.g., active or suspended. 372 A Subscription Service MUST support terminating of a Subscription 373 when requested by the Subscriber. 375 A Subscription Service SHOULD support the ability to suspend and to 376 resume a Subscription on request of a client. 378 A Subscription Service MAY at its discretion revoke or suspend an 379 existing subscription. Reasons may include transitory resource 380 limitation, credential expiry, failure to reconfirm a subscription, 381 loss of connectivity with the Receiver, operator CLI, and/or others. 383 When this occurs, the Subscription Service MUST notify the Subscriber 384 and update subscription status. 386 A Subscription Service MAY offer the ability to modify a subscription 387 Filter. If such an ability is offered, the service MUST provide 388 subscribers with an indication telling at what point the modified 389 subscription goes into effect. 391 4.2.2. Negotiation 393 A Subscription Service MUST be able to negotiate the following terms 394 of a Subscription: 396 o The policy: i.e. whether updates are on-change or periodic 398 o The interval, for periodic publication policy 400 o The dampening period, for on-change update policy (if supported) 402 o Any Filters associated with a subtree subscription 404 A Subscription Service SHOULD be able to negotiate QoS criteria for a 405 Subscription. Examples of Subscription QoS criteria may include 406 reliability of the Subscription Service, reaction time between a 407 monitored YANG subtree/object change and a corresponding notification 408 push, and the Subscription Service's ability to support certain 409 levels of object liveliness. 411 In cases where a Subscription Request cannot be fulfilled, the 412 Subscription Service MUST include in its decline a set of criteria 413 that would have been acceptable when the Subscription Request was 414 made. For example, if periodic updates were requested with too short 415 update intervals for the specified data set, an alternative 416 acceptable interval period might be returned from the Publisher. If 417 on-change updates were requested with too-aggressive a dampening 418 period, then an acceptable dampening period may be returned, or 419 alternatively an indication that only periodic updates are supported 420 for the requested object(s). 422 4.2.3. Update Distribution 424 For "on-change" updates, the Subscription Service MUST only send 425 deltas to the object data for which a change occurred. [Otherwise 426 the subscriber might not know what has actually undergone change.] 427 The updates for each object MUST include an indication whether it was 428 removed, added, or changed. 430 When a Subscription Service is not able to send updates per its 431 subscription contract, the Subscription MUST notify subscribers and 432 put the subscription into a state indicating the Subscription was 433 suspended by the service. When able to resume service, subscribers 434 need to be notified as well. If unable to resume service, the 435 Subscription Service MAY terminate the subscription and notify 436 Subscribers accordingly. 438 When a Subscription with "on-change" updates is suspended and then 439 resumed, the first update SHOULD include updates of any changes that 440 occurred while the Subscription was suspended, with the current 441 value. The Subscription Service MUST provide a clear indication when 442 this capability is not supported (because in this case a client 443 application may have to synchronize state separately). 445 Multiple objects being pushed to a Subscriber, perhaps from different 446 Subscriptions, SHOULD be bundled together into a single Update. 448 The sending of an Update MUST NOT be delayed beyond the Push Latency 449 of any enclosed object changes. 451 The sending of an Update MUST NOT be delayed beyond the dampening 452 period of any enclosed object changes. 454 The sending of an Update MUST NOT occur before the dampening period 455 expires for any enclosed object changes. 457 A Subscription Service MAY, as an option, support a replay capability 458 so that a set of updates generated during a previous time internal 459 can be sent to a Receiver. 461 4.2.4. Transport 463 A Subscription Service SHOULD support different transports. 465 A Subscription Service SHOULD support different encodings of payload. 467 It MUST be possible for Receivers to associate the update with a 468 specific Subscription. 470 In the case of connection-oriented transport, when a transport 471 connection drops, the associated Subscription SHOULD be terminated. 472 It is up the Subscriber to request a new Subscription. 474 4.2.5. Security Requirements 476 As part of the Subscription establishment, there MUST be mutual 477 authentication between the Subscriber and the Subscription Service. 479 When there are multiple Subscribers, it SHOULD be possible to provide 480 cryptographic authentication in such a way that no Subscriber can 481 pose as the original Subscription Service. 483 Versioning MUST be supported so that the capabilities and behaviors 484 expected of specific technology implementations can be exposed. 486 A Subscription could be used to attempt to retrieve information that 487 a client has not authorized access to. Therefore it is important 488 that data pushed based on Subscriptions is authorized in the same way 489 that regular data retrieval operations are authorized. Data being 490 pushed to a client MUST be filtered accordingly, just like if the 491 data were being retrieved on-demand. For Unicast transports, the 492 NETCONF Authorization Control Model applies. 494 Additions or changes within a subscribed subtree structure MUST be 495 validated against authorization methods before Subscription Updates 496 including new subtree information are pushed. 498 A loss of authenticated access to subtree or node SHOULD be 499 communicated to the Subscriber. 501 Subscription requests, including requests to create, terminate, 502 suspend, and resume Subscriptions MUST be properly authorized. 504 When the Subscriber and Receiver are different, the Receiver MUST be 505 able to terminate any Subscription to it where objects are being 506 delivered over a Unicast transport. 508 A Subscription Service SHOULD decline a Subscription Request if it is 509 likely to deplete its resources. It is preferable to decline a 510 Subscription when originally requested, rather than having to 511 terminate it prematurely later. 513 When the Subscriber and Receiver are different, and when the 514 underlying transport connection passes credentials as part of 515 transport establishment, then potentially pushed objects MUST be 516 excluded from a push update if that object doesn't have read access 517 visibility for that the Receiver. 519 4.2.6. Subscription QoS 521 A Subscription Service SHOULD be able to negotiate the following 522 Subscription QoS parameters with a Subscriber: Dampening, 523 Reliability, Deadline, and Bundling. 525 A Subscription Service SHOULD be able to interpret Subscription QoS 526 parameters, and only establish a Subscription if it is possible to 527 meet the QoS needs of the provided QoS parameters. 529 4.2.6.1. Liveliness 531 A Subscription Service MUST be able to respond to requests to verify 532 the Liveliness of a subscription. 534 A Subscription Service MUST be able to report the currently monitored 535 Nodes of a Subscription. 537 4.2.6.2. Dampening 539 A Subscription Service MUST be able to negotiate the minimum time 540 separation since the previous update before transmitting a subsequent 541 update for Subscription. (Note: this is intended to confine the 542 visibility of volatility into something digestible by the receiver.) 544 4.2.6.3. Reliability 546 A Subscription Service MAY send Updates over Best Effort and Reliable 547 transports. 549 4.2.6.4. Coherence 551 For a particular Subscription, every update to a subscribed object 552 MUST be sent to the Receiver in sequential order. 554 4.2.6.5. Presentation 556 The Subscription Service MAY have the ability to bundle a set of 557 discrete object notifications into a single publishable update for a 558 Subscription. A bundle MAY include information on different Data 559 Nodes and/or multiple updates about a single Data Node. 561 For any bundled updates, the Subscription Service MUST provide 562 information for a Receiver to reconstruct the order and timing of 563 updates. 565 4.2.6.6. Deadline 567 The Subscription Service MUST be able to push updates at a regular 568 cadence that corresponds with Subscriber specified start and end 569 timestamps. (Note: the regular cadence can drive one, a discrete 570 quantity, or an unbounded set of periodic updates.) 572 4.2.6.7. Push Latency 574 The Subscription Service SHOULD be able to delay Updates on object 575 push for a configurable period per Subscriber. 577 It MUST be possible for an administrative entity to determine the 578 Push latency between object change in a monitored subtree and the 579 Subscription Service Push of the update transmission. 581 4.2.6.8. Relative Priority 583 The Subscription Service SHOULD include the relative priority of push 584 updates so that dequeuing and discarding of case of limited bandwidth 585 between Publisher and 587 4.2.7. Filtering 589 If no filtering criteria are provided, or if filtering criteria are 590 met, updates for a subscribed object MUST be pushed, subject to the 591 QoS limits established for the subscription. 593 It MUST be possible for the Subscription Service to receive Filter(s) 594 from a Subscriber and apply them to corresponding object(s) within a 595 Subscription. 597 It MUST be possible to attach one or more Subtree and/or object 598 element and attribute Filters to a subscription. Mandatory Filter 599 types include: 601 o For character-based object properties, Filter values which are 602 exactly equal to a provided string, not equal to the string, or 603 containing a string. 605 o For numeric based object properties, Filter values which are =, 606 !=, <, <=, >, >= a provided number. 608 It SHOULD be possible for Filtering criteria to evaluate more than 609 one property of a particular subscribed object as well as apply 610 multiple Filters against a single object. 612 It SHOULD be possible to establish query match criteria on additional 613 objects to be used in conjunction with Filtering criteria on a 614 subscribed object. (For example: if A has changed and B=1, then Push 615 A.) Query match capability may be done on objects within the 616 datastore even if those objects are not included within the 617 subscription. This of course assumes the subscriber has read access 618 to those objects. 620 For on-change subscription updates, an object MUST pass a Filter 621 through a Filter if it has changed since the previous update. This 622 includes if the object has changed multiple times since the last 623 update, and ithe value happens to be the exact same value as the last 624 one sent. 626 4.2.8. Assurance and Monitoring 628 It MUST be possible to fetch the state of a single subscription from 629 a Subscription Service. 631 It MUST be possible to fetch the state of all subscriptions of a 632 particular Subscriber. 634 It MUST be possible to fetch a list and status of all Subscription 635 Requests over a period of time. If there is a failure, some failure 636 reasons might include: 638 o Improper security credentials provided to access the target node; 640 o Target node referenced does not exist; 642 o Subscription type requested is not available upon the target node; 644 o Out of resources, or resources not available; 646 o Incomplete negotiations with the Subscriber. 648 5. Security Considerations 650 There are no additional security considerations beyond the 651 requirements listed in Section 4.2.5. 653 6. IANA Considerations 655 This document has no actions for IANA. 657 7. Acknowledgements 659 We wish to acknowledge the helpful contributions, comments, and 660 suggestions that were received from Ambika Tripathy and Prabhakara 661 Yellai as well as the helpfulness of related end-to-end system 662 context info from Nancy Cam Winget, Ken Beck, and David McGrew. 664 8. References 666 8.1. Normative References 668 [i2rs-arch] 669 Atlas, A., "An Architecture for the Interface to the 670 Routing System", February 2016, 671 . 674 [i2rs-traceability] 675 Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to 676 the Routing System (I2RS) Traceability: Framework and 677 Information Model", February 2016, 678 . 681 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 682 Requirement Levels", BCP 14, RFC 2119, 683 DOI 10.17487/RFC2119, March 1997, 684 . 686 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 687 DOI 10.17487/RFC2328, April 1998, 688 . 690 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 691 and A. Bierman, Ed., "Network Configuration Protocol 692 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 693 . 695 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 696 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 697 2012, . 699 8.2. Informative References 701 [i2rs-usecase] 702 Hares, S. and M. Chen, "Summary of I2RS Use Case 703 Requirements", March 2016, 704 . 707 [OMG-DDS] "Data Distribution Service for Real-time Systems, version 708 1.2", January 2007, . 710 [sacm-requirements] 711 Cam Winget, N., "Secure Automation and Continuous 712 Monitoring (SACM) Requirements", March 2016, 713 . 716 [XEP-0060] 717 Millard, P., "XEP-0060: Publish-Subscribe", July 2010, 718 . 720 Authors' Addresses 722 Eric Voit 723 Cisco Systems 725 Email: evoit@cisco.com 727 Alexander Clemm 728 Cisco Systems 730 Email: alex@cisco.com 732 Alberto Gonzalez Prieto 733 Cisco Systems 735 Email: albertgo@cisco.com