--- 1/draft-ietf-i2rs-pub-sub-requirements-02.txt 2015-10-02 12:14:55.416770559 -0700 +++ 2/draft-ietf-i2rs-pub-sub-requirements-03.txt 2015-10-02 12:14:55.448771337 -0700 @@ -1,18 +1,19 @@ + Interface to the Routing System (i2rs) E. Voit Internet-Draft A. Clemm Intended status: Informational A. Gonzalez Prieto -Expires: September 27, 2015 Cisco Systems - March 26, 2015 +Expires: March 31, 2016 Cisco Systems + September 28, 2015 Requirements for Subscription to YANG Datastores - draft-ietf-i2rs-pub-sub-requirements-02 + draft-ietf-i2rs-pub-sub-requirements-03 Abstract This document provides requirements for a service that allows client applications to subscribe to updates of a YANG datastore. Based on criteria negotiated as part of a subscription, updates will be pushed to targeted recipients. Such a capability eliminates the need for periodic polling of YANG datastores by applications and fills a functional gap in existing YANG transports (i.e. Netconf and Restconf). Such a service can be summarized as a "pub/sub" service @@ -29,21 +30,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 27, 2015. + This Internet-Draft will expire on March 31, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -63,21 +64,21 @@ 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Assumptions for Subscriber Behavior . . . . . . . . . . . 8 4.2. Subscription Service Requirements . . . . . . . . . . . . 8 4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 8 4.2.2. Negotiation . . . . . . . . . . . . . . . . . . . . . 10 4.2.3. Update Distribution . . . . . . . . . . . . . . . . . 10 4.2.4. Transport . . . . . . . . . . . . . . . . . . . . . . 11 4.2.5. Security Requirements . . . . . . . . . . . . . . . . 11 4.2.6. Subscription QoS . . . . . . . . . . . . . . . . . . 12 - 4.2.7. Filtering . . . . . . . . . . . . . . . . . . . . . . 14 + 4.2.7. Filtering . . . . . . . . . . . . . . . . . . . . . . 13 4.2.8. Assurance and Monitoring . . . . . . . . . . . . . . 14 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.1. Normative References . . . . . . . . . . . . . . . . . . 15 6.2. Informative References . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction YANG has gained acceptance as the data definition language of choice @@ -332,27 +333,20 @@ Many of the requirements within this section have been morphed from OMG's DDS and XMPP.org's requirements specifications. 4.1. Assumptions for Subscriber Behavior This document provides requirements for the Subscription Service. It does not define all the requirements for the Subscriber/Receiver. However In order to frame the desired behavior of the Subscription Service, it is important to specify key input constraints. -4.2. Subscription Service Requirements - - This document provides requirements for the Subscription Service. It - does not define all the requirements for the Subscriber/Receiver. - However In order to frame the desired behavior of the Subscription - Service, it is important to specify key input constraints. - A Subscriber should avoid attempting to establish multiple Subscriptions pertaining to the same information, i.e. referring to the same datastore YANG subtrees. A Subscriber may provide Subscription QoS criteria to the Subscription Service such that if the Subscription Service is unable to meet those criteria, the Subscription should not be established. When a Subscriber needs to restart, it is acceptable for the Subscriber to have to resubscribe. There is no requirement for the @@ -361,20 +355,22 @@ A Subscriber must be able to infer when a Subscription Service is no longer active and when no more updates are being sent. A Subscriber may check with a Subscription Service to validate the existence and monitored subtrees of a Subscription. A Subscriber must be able to periodically lease and re-lease a Subscription from a Subscription Service. +4.2. Subscription Service Requirements + 4.2.1. General A Subscription Service must support the ability to create, renew, timeout, and terminate a Subscription. A Subscription Service must be able to support and independently track one or more Subscription Requests by the same Subscriber. A Subscription Service must be able to support an add/change/delete of one or more YANG subtrees as part of the same Subscription @@ -669,87 +666,92 @@ We wish to acknowledge the helpful contributions, comments, and suggestions that were received from Ambika Tripathy and Prabhakara Yellai as well as the helpfulness of related end-to-end system context from [i2rs-pubsub-security] from Nancy Cam Winget, Ken Beck, and David McGrew. 6. References 6.1. Normative References - [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. + [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/ + RFC2328, April 1998, + . [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event - Notifications", RFC 5277, July 2008. + Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, + . [RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF) - Base Notifications", RFC 6470, February 2012. + Base Notifications", RFC 6470, DOI 10.17487/RFC6470, + February 2012, . - [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP - VPNs", RFC 6513, February 2012. + [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ + BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February + 2012, . 6.2. Informative References [AVB-latency] Jeffree, T., "802.1Qav - Forwarding and Queuing Enhancements for Time-Sensitive Streams", December 2009, . - [OMG-DDS] "Data Distribution Service for Real-time Systems, version - 1.2", January 2007, . - - [XEP-0060] - Millard, P., "XEP-0060: Publish-Subscribe", July 2010, - . - [datastore-push] Clemm, A., Gonzalez Prieto, A., and E. Voit, "Subscribing - to datastore push updates", October 2014, - . + to datastore push updates", July 2015, + . [draft-voit-netmod] Voit, E., "Requirements for Peer Mounting of YANG subtrees - from Remote Datastores", October 2014, + from Remote Datastores", September 2015, . + requirements-03>. [i2rs-arch] Atlas, A., "An Architecture for the Interface to the - Routing System", December 2014, - . + Routing System", March 2015, + . [i2rs-pubsub-security] Beck, K., Cam Winget, N., and D. McGrew, "Using the Publish-Subscribe Model in the Interface to the Routing System", July 2013, . [i2rs-traceability] Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to the Routing System (I2RS) Traceability: Framework and - Information Model", December 2014, + Information Model", May 2015, . [i2rs-usecase] Hares, S. and M. Chen, "Summary of I2RS Use Case - Requirements", October 2014, + Requirements", May 2015, . + [OMG-DDS] "Data Distribution Service for Real-time Systems, version + 1.2", January 2007, . + [sacm-requirements] Cam Winget, N., "Secure Automation and Continuous - Monitoring (SACM) Requirements", October 2014, + Monitoring (SACM) Requirements", July 2015, . + 09>. + + [XEP-0060] + Millard, P., "XEP-0060: Publish-Subscribe", July 2010, + . Authors' Addresses Eric Voit Cisco Systems Email: evoit@cisco.com Alexander Clemm Cisco Systems