idnits 2.17.1 draft-ietf-i2rs-pub-sub-requirements-01.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 a Security Considerations section. ** 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 193: '...Q10: I2RS client SHOULD be able instru...' RFC 2119 keyword, line 214: '... o I2RS Agents SHOULD support publis...' RFC 2119 keyword, line 295: '... MAY include constraints which dicta...' RFC 2119 keyword, line 309: '...e(s). An Update MUST include the curr...' RFC 2119 keyword, line 312: '... MAY include a bundled set of ordere...' (70 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 9, 2015) is 3308 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Interface to the Routing System (i2rs) E. Voit 2 Internet-Draft A. Clemm 3 Intended status: Informational A. Gonzalez Prieto 4 Expires: September 10, 2015 Cisco Systems 5 March 9, 2015 7 Requirements for Subscription to YANG Datastores 8 draft-ietf-i2rs-pub-sub-requirements-01 10 Abstract 12 This document provides requirements for a service that allows client 13 applications to subscribe to updates of a YANG datastore. Based on 14 criteria negotiated as part of a subscription, updates will be pushed 15 to targeted recipients. Such a capability eliminates the need for 16 periodic polling of YANG datastores by applications and fills a 17 functional gap in existing YANG transports (i.e. Netconf and 18 Restconf). Such a service can be summarized as a "pub/sub" service 19 for YANG datastore updates. Beyond a set of basic requirements for 20 the service, various refinements are addressed. These refinements 21 include: periodicity of object updates, filtering out of objects 22 underneath a requested a subtree, and delivery QoS guarantees. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 10, 2015. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Business Drivers . . . . . . . . . . . . . . . . . . . . . . 3 60 2.1. Pub/Sub in I2RS . . . . . . . . . . . . . . . . . . . . . 4 61 2.2. Pub/Sub variants on Network Elements . . . . . . . . . . 5 62 2.3. Existing Generalized Pub/Sub Implementations . . . . . . 6 63 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 65 4.1. Assumptions for Subscriber Behavior . . . . . . . . . . . 7 66 4.2. Subscription Service Requirements . . . . . . . . . . . . 8 67 4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 8 68 4.2.2. Negotiation . . . . . . . . . . . . . . . . . . . . . 10 69 4.2.3. Update Distribution . . . . . . . . . . . . . . . . . 10 70 4.2.4. Transport . . . . . . . . . . . . . . . . . . . . . . 11 71 4.2.5. Security Requirements . . . . . . . . . . . . . . . . 11 72 4.2.6. QoS Requirements . . . . . . . . . . . . . . . . . . 12 73 4.2.7. Filtering . . . . . . . . . . . . . . . . . . . . . . 13 74 4.2.8. Assurance and Monitoring . . . . . . . . . . . . . . 14 75 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 76 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 6.1. Normative References . . . . . . . . . . . . . . . . . . 14 78 6.2. Informative References . . . . . . . . . . . . . . . . . 15 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 81 1. Introduction 83 YANG has gained acceptance as the data definition language of choice 84 for control and management related information. Applications that 85 interact with YANG datastores are extending beyond traditional 86 configuration of network elements. In many cases these applications 87 are aimed at service-assurance, which involves monitoring of 88 operational data and state. The existing YANG technology ecosystem 89 is proving insufficient for those applications due to: 91 o a reliance on RPC-style interactions where data is configured or 92 fetched on-demand by applications. 94 o change notifications which identify a node associated with the 95 config change, without the actual data updates 97 Put simply, periodic fetching of data is not an adequate solution for 98 applications requiring frequent or prompt updates of remote object 99 state. Trying to impose a polling based solution to this problem 100 imposes load on networks, devices, and applications. Additionally, 101 polling solutions are brittle in the face of communication glitches, 102 and they have limitations in their ability to synchronize and 103 calibrate retrieval intervals across a network. 105 I2RS WG documents have expressed a need for more robust YANG object 106 subscriptions. Similar discussions are underway in NETMOD and 107 NETCONF. With the support of standards bodies such as OMG (DDS), 108 XMPP.org standard, generic Pub/Sub mechanisms to communicate data 109 updates have been defined and proven themselves in a wide variety of 110 deployments. 112 It is time to incorporate such generic object subscription mechanisms 113 as part of Network Elements, and allow these mechanisms to be applied 114 in the context of data that is conceptually contained in YANG 115 datastores. With such mechanisms, both controller and local Network 116 Element based applications can have access to a set of consistent 117 network information driven via push from peer Network Elements which 118 host authoritative information. 120 There are some valid IETF starting points and contexts for these 121 mechanisms. For example Netconf Event Notifications [RFC5277] 122 provides a useful tool for an end-to-end solution. However RFC5277 123 does not follow the Pub/Sub paradigm, does not allow the explicit 124 deletion of subscriptions, and predates YANG. [RFC6470] defines 125 configuration change notifications, but doesn't provide the actual 126 configuration change. 128 Because of this, the authors have put forward this requirements 129 document as well as [datastore-push]. We are hoping these could 130 provide a context upon which to create new solution. 132 2. Business Drivers 134 For decades, information delivery of current network state has been 135 accomplished either by fetching from operations interfaces, or via 136 dedicated, customized networking protocols. With the growth of SDN, 137 imperative policy distribution, and YANG's ascent as a dominant 138 programmatic interface to network elements, this mixture of fetch 139 plus custom networking protocols is no longer sufficient. What is 140 needed is a push mechanism that is able to deliver objects and object 141 changes as they happen. 143 These push distribution mechanisms will not replace existing 144 networking protocols. Instead they will supplement these protocols, 145 providing different response time, peering, scale, and security 146 characteristics. 148 At the same time, SNMP and MIBs are still widely deployed and the de- 149 facto choice for many monitoring solutions. Those solutions do not 150 require support for configuration transactions and the need to 151 validate and maintain configuration consistency, hence there is less 152 pressure to abandon SNMP and MIBs. Arguably the biggest shortcoming 153 of SNMP for those applications concerns the need to rely on periodic 154 polling, because it introduces additional load on the network and 155 devices, is brittle in case polling cycles are missed, and is hard to 156 synchronize and calibrate across a network, making data obtained from 157 multiple devices less comparable. If applications need to apply 158 those same interaction patterns for YANG datastores, similar issues 159 can be expected. Migration to YANG datastores by applications that 160 do not have to worry about transactional integrity becomes a lot more 161 compelling if those issues are addressed. 163 2.1. Pub/Sub in I2RS 165 Various I2RS documents highlight the need to provide Pub/Sub 166 capabilities between network elements. From [i2rs-arch], there are 167 references throughout the document beginning in section 6.2. Some 168 specific examples include: 170 o section 7.6 provides high level pub/sub (notification) guidance 172 o section 6.4.2 identifies "subscribing to an information stream of 173 route changes receiving notifications about peers coming up or 174 going down" 176 o section 6.3 notes that when local config preempts I2RS, external 177 notification might be necessary 179 In addition [i2rs-usecase]has relevant requirements. A small subset 180 includes: 182 o L-Data-REQ-12: The I2RS interface should support user 183 subscriptions to data with the following parameters: push of data 184 synchronously or asynchronously via registered subscriptions... 186 o L-DATA-REQ-07: The I2RS interface (protocol and IMs) should allow 187 a subscribe to select portions of the data model. 189 o PI-REQ01: monitor the available routes installed in the RIB of 190 each forwarding device, including near real time notification of 191 route installation and removal. 193 o BGP-REQ10: I2RS client SHOULD be able instruct the I2RS agent(s) 194 to notify the I2RS client when the BGP processes on an associated 195 routing system observe a route change to a specific set of IP 196 Prefixes and associated prefixes....The I2RS agent should be able 197 to notify the client via publish or subscribe mechanism. 199 o IGP-REQ-07: The I2RS interface (protocol and IMs) should support a 200 mechanism where the I2RS Clients can subscribe to the I2RS Agent's 201 notification of critical node IGP events. 203 o MPLS-LDP-REQ-03: The I2RS Agent notifications should allow an I2RS 204 client to subscribe to a stream of state changes regarding the LDP 205 sessions or LDP LSPs from the I2RS Agent. 207 o L-Data-REQ-01: I2rs must be able to collect large data set from 208 the network with high frequency and resolution with minimal impact 209 to the device's CPU and memory. 211 And [i2rs-traceability] has Pub/Sub requirements listed in 212 Section 7.4.3. 214 o I2RS Agents SHOULD support publishing I2RS trace log information 215 to that feed as described in [i2rs-arch]. Subscribers would then 216 receive a live stream of I2RS interactions in trace log format and 217 could flexibly choose to do a number of things with the log 218 messages 220 There are additional individual drafts such as [i2rs-pubsub-security] 221 documenting the Pub/Sub needs for: time delivery sensitivity, support 222 for multiple transport protocols, secure/authorized communications, 223 and support for a range specification of subscribed data delivery 224 content. So the list above should not be considered exhaustive. 226 2.2. Pub/Sub variants on Network Elements 228 Looking at history, there are many examples of switching and routing 229 protocols which have done explicit or implicit pub/sub in the past. 230 In addition, new policy notification mechanisms which operate on 231 Switches and Routers are being specified now. A very small subset of 232 these includes: 234 o Routing Adjacencies in MPLS VPNs [RFC6513] 236 o OSPF Route Flooding [RFC2328] 238 o Multicast topology establishment protocols (IGMP, PIM, etc.) 239 o Audio-Video Bridging streams needing guaranteed latency 240 [AVB-latency] (802.1Q-2011 Clause 35) 242 o Secure Automation and Continuous Monitoring (SACM) 243 [sacm-requirements] 245 o "Peer Mount" subscriptions for configuration verification between 246 peers[draft-voit-netmod] 248 Worthy of note in the list above is the wide variety of broadcast, 249 multicast, and unicast transports used. In addition some transports 250 are at L3, and some at L2. Therefore if we are going to attempt a 251 generic Pub/Sub mechanism, it will need to be structured so that it 252 may support alternative transports. Looking at the nearer term based 253 on current I2RS requirements, NETCONF should be our transport 254 starting point as it supports connection oriented/Unicast 255 communication. But we need to be prepared to decouple where viable 256 to support Multicast and Broadcast distribution as well. 258 2.3. Existing Generalized Pub/Sub Implementations 260 TIBCO, RSS, CORBA, and other technologies all show precursor Pub/Sub 261 technologies. However there are new needs described in Section 4 262 below which these technologies do not serve. We need a technology. 264 There are at least two widely deployed generalized pub/sub 265 implementations which come close to current needs: XMPP[XEP-0060] and 266 DDS[OMG-DDS]. Both serve as proof-points that a highly scalable 267 distributed datastore implementation connecting millions of edge 268 devices is possible. 270 Because of these proof points, we can be comfortable that the 271 underlying technologies can enable reusable generalized YANG object 272 distribution. Analysis will need to fully dimension the speed and 273 scale of such object distribution for various subtree sizes and 274 transport types. 276 3. Terminology 278 A Subscriber makes requests for set(s) of YANG object data. The 279 Subscriber is the owner of the Subscription. 281 A Publisher is responsible for distributing subscribed YANG object 282 data per the terms of a Subscription. In general, a Publisher is the 283 owner of the YANG datastore that is subjected to the Subscription. 285 A Receiver is the target where a Publisher pushes updates. In 286 general, the Receiver and Subscriber will be the same entity. A 287 Subscription Service provides Subscriptions to Subscribers of YANG 288 data. 290 A Subscription Service interacts with the Publisher of the YANG data 291 as needed to provide the data per the terms of the Subscription. 293 A Subscription Request for one or more YANG subtrees made by the 294 Subscriber of a Publisher and targeted to a Receiver. A Subscription 295 MAY include constraints which dictates how often or under what 296 conditions YANG subtree updates might be sent. 298 A Subscription is a contract between a Subscription Service and a 299 Subscriber that stipulates the data to be pushed and the associated 300 terms. 302 A YANG datastore is a conceptual datastore that contains hierarchical 303 data defined in YANG data models. It is what is referred in existing 304 RFCs as "Netconf datastore". However, as the same datastore is no 305 longer tied to Netconf as a specific transport, the term "YANG 306 datastore" is deemed more appropriate. 308 An Update provides object changes which have occurred within 309 subscribed YANG subtree(s). An Update MUST include the current 310 status of (data) node instances which according to any filtering are 311 reportably different from the previously provided state. An Update 312 MAY include a bundled set of ordered/sequential changes for a given 313 object which have been made since the last update. 315 A Filter contains evaluation criteria which are evaluated against 316 YANG object(s) within a Subscription. There are two types of 317 Filters: Subtree Filters which identify selected objects/nodes 318 published under a target data node, and object Property Filters where 319 an object should only be published if it has propert(ies) meeting 320 specified Filter criteria. For "on-change" notifications, passing 321 through the Filter requires that a subscribed object is now different 322 that from the previous Push, AND at least one of the YANG objects 323 being evaluated has changed since the last Update. 325 4. Requirements 327 Many of the requirements within this section have been morphed from 328 OMG's DDS and XMPP.org's requirements specifications. 330 4.1. Assumptions for Subscriber Behavior 332 This document provides requirements for the Subscription Service. It 333 does not define all the requirements for the Subscriber/Receiver. 335 However In order to frame the desired behavior of the Subscription 336 Service, it is important to specify key input constraints. 338 4.2. Subscription Service Requirements 340 This document provides requirements for the Subscription Service. It 341 does not define all the requirements for the Subscriber/Receiver. 342 However In order to frame the desired behavior of the Subscription 343 Service, it is important to specify key input constraints. 345 A Subscriber SHOULD avoid attempting to establish multiple 346 Subscriptions pertaining to the same information, i.e. referring to 347 the same datastore YANG subtrees. 349 A Subscriber MAY provide QoS criteria to the Subscription Service 350 such that if the Subscription Service is unable to meet those 351 criteria, the Subscription should not be established. 353 When a Subscriber needs to restart, it is acceptable for the 354 Subscriber to have to resubscribe. There is no requirement for the 355 life span of the Subscription to extend beyond the life span of the 356 Subscriber. 358 A Subscriber MUST be able to infer when a Subscription Service is no 359 longer active and when no more updates are being sent. 361 A Subscriber MAY check with a Subscription Service to validate the 362 existence and monitored subtrees of a Subscription. 364 A Subscriber MUST be able to periodically lease and re-lease a 365 Subscription from a Subscription Service. 367 4.2.1. General 369 A Subscription Service MUST support the ability to create, renew, 370 timeout, and terminate a Subscription. 372 A Subscription Service MUST be able to support and independently 373 track one or more Subscription Requests by the same Subscriber. 375 A Subscription Service MUST be able to support an add/change/delete 376 of one or more YANG subtrees as part of the same Subscription 377 Request. 379 A Subscription Service MUST support Subscriptions against operational 380 datastores, configuration datastores, or both. 382 A Subscription Service MUST be able support a Subtree Filter so that 383 subscribed updates under a target node might publish only operational 384 data, only configuration data, or both. 386 A Subscription MAY include filters as defined within a Subscription 387 Request, the Subscription Service MUST publish only data nodes that 388 meet the filter criteria. 390 A Subscription Service MUST support the ability to subscribe to 391 periodic updates. The subscription period MUST be configurable as 392 part of the subscription request. 394 A Subscription Service SHOULD support the ability to subscribe to 395 updates "on-change", i.e. whenever values of subscribed data objects 396 change. 398 For "on-change" updates, the Subscription Service MUST support a 399 dampening period that needs to pass before the first or subsequent 400 "on-change" updates are sent. The dampening period SHOULD be 401 configurable as part of the subscription request. 403 A Subscription Service MUST allow Subscriptions to be monitored. 404 Specifically, a Subscription Service MUST at a minimum maintain 405 information about which Subscriptions are being serviced, the terms 406 of those subscriptions (e.g. what data is being subscribed, 407 associated filters, update policy - on change, periodic), and the 408 overall status of the Subscription - e.g. active or suspended. 410 A Subscription Service SHOULD be able to interpret Subscription 411 Requests QoS Policy requests, and only establish a Subscription if it 412 is possible to meet the QoS those QoS Policy requests. 414 A Subscription Service MUST support terminating of a Subscription 415 when requested by the Subscriber. 417 A Subscription Service SHOULD support the ability to suspend and to 418 resume a Subscription on request of a client. 420 A Subscription Service MAY at its discretion revoke or suspend an 421 existing subscription. Reasons MAY include transitory resource 422 limitation, credential expiry, failure to reconfirm a subscription, 423 loss of connectivity with the Receiver, operator CLI, and/or others. 424 When this occurs, the Subscription Service MUST notify the Subscriber 425 and update subscription status. 427 A Subscription Service MAY offer the ability to modify a subscription 428 filter. If such an ability is offered, the service MUST provide 429 subscribers with an indication at what point the modified 430 subscription goes into effect. 432 4.2.2. Negotiation 434 A Subscription Service MUST be able to negotiate the following terms 435 of a Subscription: 437 o The policy: i.e. whether updates are on-change of periodic 439 o The interval, for periodic publication policy 441 o The dampening period, for on-change update policy 443 o Any filters associated with a subtree subscription 445 A Subscription Service SHOULD be able to negotiate QoS criteria for a 446 Subscription. Examples of QoS criteria MAY include reliability of 447 the Subscription Service, reaction time between a monitored YANG 448 subtree/object change and a corresponding notification push, and the 449 Subscription Service's ability to support certain levels of object 450 liveliness. 452 In cases where a Subscription Request cannot be fulfilled, the 453 Subscription Service MUST include in its decline a set of criteria 454 that would have been acceptable when the Subscription Request was 455 made. For example, if periodic updates were requested with too short 456 update intervals for the specified data set, the minimum acceptable 457 interval period SHOULD be included. If on-change updates were 458 requested with a dampening period, the minimum acceptable dampening 459 period SHOULD be included, or an indication whether only periodic 460 updates are supported along with the minimum acceptable interval 461 period for the data set being subscribed to. 463 4.2.3. Update Distribution 465 For "on-change" updates, the Subscription Service MUST only send 466 deltas to the object data for which a change occurred. [Otherwise 467 the subscriber will not know what has actually undergone change.] 468 The updates for each object needs to include an indication whether it 469 was removed, added, or changed. 471 When a Subscription Service is not able to send updates per its 472 subscription contract, the Subscription MUST notify subscribers and 473 put the subscription into a state of indicating the Subscription was 474 suspended by the service. When able to resume service, subscribers 475 need to be notified as well. If unable to resume service, the 476 Subscription Service MAY terminate the subscription and notify 477 Subscribers accordingly. 479 When a Subscription with "on-change" updates is suspended and then 480 resumed, the first update SHOULD include updates of any changes that 481 occurred while the Subscription was suspended, with the current 482 value. The Subscription Service MUST provide a clear indication when 483 this capability is not supported (because in this case a client 484 application may have to synchronize state separately). 486 A Subscription Service MAY, as an option, support a persistence/ 487 replay capability. 489 4.2.4. Transport 491 A Subscription Service SHOULD support different transports. 493 A Subscription Service SHOULD support different encodings of payload. 495 It MUST be possible for Receivers to associate the update with a 496 specific Subscription. 498 In the case of connection-oriented transport, when a transport 499 connection drops, the associated Subscription SHOULD be terminated. 500 It is up the Subscriber to request a new Subscription. 502 4.2.5. Security Requirements 504 As part of the Subscription establishment, there MUST be mutual 505 authentication between the Subscriber and the Subscription Service. 507 When there are multiple Subscribers, it SHOULD be possible to provide 508 cryptographic authentication in such a way that no Subscriber can 509 pose as the original Subscription Service. 511 Versioning MUST be supported. 513 A Subscription could be used to attempt to retrieve information that 514 a client has not authorized access to. Therefore it is important 515 that data pushed based on Subscriptions is authorized in the same way 516 that regular data retrieval operations are. Data being pushed to a 517 client MUST be filtered accordingly, just like if the data were being 518 retrieved on-demand. For Unicast transports, the Netconf 519 Authorization Control Model applies. 521 Subscription requests, including requests to create, terminate, 522 suspend, and resume Subscriptions MUST be properly authorized. 524 When the Subscriber and Receiver are different, the Receiver MUST be 525 able to terminate any Subscription to it where objects are being 526 delivered over a Unicast transport. 528 A Subscription Service SHOULD decline a Subscription Request if it 529 would deplete its resources. It is preferable to decline a 530 Subscription when originally requested, rather than having to 531 terminate it prematurely later. 533 4.2.6. QoS Requirements 535 A Subscription Service SHOULD be able to negotiate the following QoS 536 parameters with a Subscriber: Dampening, Reliability, Deadline, 537 Bundling. 539 4.2.6.1. Liveliness 541 A Subscription Service MUST be able to respond to requests to verify 542 the Liveliness of a subscription. 544 A Subscription Service MUST be able to report the currently monitored 545 Nodes of a Subscription. 547 4.2.6.2. Dampening 549 A Subscription Service MUST be able to negotiate the minimum time 550 separation since the previous update before transmitting a subsequent 551 update for Subscription. (Note: this is intended to confine the 552 visibility of volatility into something digestible by the receiver.) 554 4.2.6.3. Reliability 556 A Subscription Service MAY send Updates over Best Effort and Reliable 557 transports. 559 4.2.6.4. Coherence 561 Every update to a subscribed object MUST be sent to the Receiver in 562 sequential order. 564 4.2.6.5. Presentation 566 The Subscription Service SHOULD have the ability to bundle a set of 567 discrete object notifications into a single publishable update for a 568 Subscription. A bundle MAY include information on different Data 569 Nodes and/or multiple updates about a single Data Node. 571 For any bundled updates, the Subscription Service MUST provide 572 information for a Receiver to reconstruct the order and timing of 573 updates. 575 4.2.6.6. Deadline 577 The Subscription Service MUST be able to push updates at a regular 578 cadence that corresponds with Subscriber specified start and end 579 timestamps. (Note: the regular cadence can drive one, a discrete 580 quantity, or an unbounded set of periodic updates.) 582 4.2.6.7. Push Latency 584 It MUST be possible for an administrative entity to determine the 585 Push latency between object change in a monitored subtree and the 586 Subscription Service Push of the update transmission. 588 4.2.7. Filtering 590 If no filtering criteria are provided, or if filtering criteria are 591 met, updates for a subscribed object MUST be pushed, subject to the 592 QoS limits established for the subscription. 594 It MUST be possible for the Subscription Service to receive Filter(s) 595 from a Subscriber and apply them to corresponding object(s) within a 596 Subscription. 598 It MUST be possible to attach one or more Subtree and/or Property 599 Filters to a subscription. Mandatory Property Filter 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 Property Filtering criteria to evaluate 609 more than one property of a particular subscribed object as well as 610 apply multiple filters against a single property. 612 It SHOULD be possible to establish query match criteria on additional 613 objects to be used in conjunction with Property Filtering criteria on 614 a subscribed object. (For example: if A has changed AND B=1, then 615 Push A.) (Note: Query match capability MAY be done on objects within 616 the 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 4.2.8. Assurance and Monitoring 622 It MUST be possible to fetch the state of a single subscription from 623 a Subscription Service. 625 It MUST be possible to fetch the state of all subscriptions of a 626 particular Subsciber. 628 It MUST be possible to fetch a list and status of all Subscription 629 Requests over a period of time. If there us a failure, some failure 630 reasons might include: 632 o Improper security credentials provided to access the target node 634 o Target node referenced does not exist 636 o Subscription type requested is not available upon the target node 638 o Out of resources, or resources not available 640 o Incomplete negotiations with the Subscriber. 642 5. Acknowledgements 644 We wish to acknowledge the helpful contributions, comments, and 645 suggestions that were received from Ambika Tripathy and Prabhakara 646 Yellai as well as the helpfulness of related end-to-end system 647 context from [i2rs-pubsub-security] from Nancy Cam Winget, Ken Beck, 648 and David McGrew. 650 6. References 652 6.1. Normative References 654 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 656 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 657 Notifications", RFC 5277, July 2008. 659 [RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF) 660 Base Notifications", RFC 6470, February 2012. 662 [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP 663 VPNs", RFC 6513, February 2012. 665 6.2. Informative References 667 [AVB-latency] 668 Jeffree, T., "802.1Qav - Forwarding and Queuing 669 Enhancements for Time-Sensitive Streams", December 2009, 670 . 672 [OMG-DDS] "Data Distribution Service for Real-time Systems, version 673 1.2", January 2007, . 675 [XEP-0060] 676 Millard, P., "XEP-0060: Publish-Subscribe", July 2010, 677 . 679 [datastore-push] 680 Clemm, A., Gonzalez Prieto, A., and E. Voit, "Subscribing 681 to datastore push updates", October 2014, 682 . 685 [draft-voit-netmod] 686 Voit, E., "Requirements for Peer Mounting of YANG subtrees 687 from Remote Datastores", October 2014, 688 . 691 [i2rs-arch] 692 Atlas, A., "An Architecture for the Interface to the 693 Routing System", December 2014, 694 . 697 [i2rs-pubsub-security] 698 Beck, K., Cam Winget, N., and D. McGrew, "Using the 699 Publish-Subscribe Model in the Interface to the Routing 700 System", July 2013, . 703 [i2rs-traceability] 704 Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to 705 the Routing System (I2RS) Traceability: Framework and 706 Information Model", December 2014, 707 . 710 [i2rs-usecase] 711 Hares, S. and M. Chen, "Summary of I2RS Use Case 712 Requirements", October 2014, 713 . 716 [sacm-requirements] 717 Cam Winget, N., "Secure Automation and Continuous 718 Monitoring (SACM) Requirements", October 2014, 719 . 722 Authors' Addresses 724 Eric Voit 725 Cisco Systems 727 Email: evoit@cisco.com 729 Alex Clemm 730 Cisco Systems 732 Email: alex@cisco.com 734 Alberto Gonzalez Prieto 735 Cisco Systems 737 Email: albertgo@cisco.com