draft-ietf-i2rs-pub-sub-requirements-08.txt   draft-ietf-i2rs-pub-sub-requirements-09.txt 
Interface to the Routing System (i2rs) E. Voit Interface to the Routing System (i2rs) E. Voit
Internet-Draft A. Clemm Internet-Draft A. Clemm
Intended status: Informational A. Gonzalez Prieto Intended status: Informational A. Gonzalez Prieto
Expires: November 14, 2016 Cisco Systems Expires: November 18, 2016 Cisco Systems
May 13, 2016 May 17, 2016
Requirements for Subscription to YANG Datastores Requirements for Subscription to YANG Datastores
draft-ietf-i2rs-pub-sub-requirements-08 draft-ietf-i2rs-pub-sub-requirements-09
Abstract Abstract
This document provides requirements for a service that allows client This document provides requirements for a service that allows client
applications to subscribe to updates of a YANG datastore. Based on applications to subscribe to updates of a YANG datastore. Based on
criteria negotiated as part of a subscription, updates will be pushed criteria negotiated as part of a subscription, updates will be pushed
to targeted recipients. Such a capability eliminates the need for to targeted recipients. Such a capability eliminates the need for
periodic polling of YANG datastores by applications and fills a periodic polling of YANG datastores by applications and fills a
functional gap in existing YANG transports (i.e., Netconf and functional gap in existing YANG transports (i.e., Netconf and
Restconf). Such a service can be summarized as a "pub/sub" service Restconf). Such a service can be summarized as a "pub/sub" service
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 14, 2016. This Internet-Draft will expire on November 18, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 9, line 34 skipping to change at page 9, line 34
o Any Filters associated with a subtree subscription o Any Filters associated with a subtree subscription
A Subscription Service SHOULD be able to negotiate QoS criteria for a A Subscription Service SHOULD be able to negotiate QoS criteria for a
Subscription. Examples of Subscription QoS criteria may include Subscription. Examples of Subscription QoS criteria may include
reliability of the Subscription Service, reaction time between a reliability of the Subscription Service, reaction time between a
monitored YANG subtree/object change and a corresponding notification monitored YANG subtree/object change and a corresponding notification
push, and the Subscription Service's ability to support certain push, and the Subscription Service's ability to support certain
levels of object liveliness. levels of object liveliness.
In cases where a Subscription Request cannot be fulfilled, the In cases where a Subscription Request cannot be fulfilled due to
Subscription Service MUST include in its decline a set of criteria insufficient platform resources, the Subscription Service SHOULD
that would have been acceptable when the Subscription Request was include within its decline hints on criteria that would have been
made. For example, if periodic updates were requested with too short acceptable when the Subscription Request was made. For example, if
update intervals for the specified data set, an alternative periodic updates were requested with too short update intervals for
acceptable interval period might be returned from the Publisher. If the specified data set, an alternative acceptable interval period
on-change updates were requested with too-aggressive a dampening might be returned from the Publisher. If on-change updates were
period, then an acceptable dampening period may be returned, or requested with too-aggressive a dampening period, then an acceptable
alternatively an indication that only periodic updates are supported dampening period may be returned, or alternatively an indication that
for the requested object(s). only periodic updates are supported for the requested object(s).
4.2.3. Update Distribution 4.2.3. Update Distribution
For "on-change" updates, the Subscription Service MUST only send For "on-change" updates, the Subscription Service MUST only send
deltas to the object data for which a change occurred. [Otherwise deltas to the object data for which a change occurred. [Otherwise
the subscriber might not know what has actually undergone change.] the subscriber might not know what has actually undergone change.]
The updates for each object MUST include an indication whether it was The updates for each object MUST include an indication whether it was
removed, added, or changed. removed, added, or changed.
When a Subscription Service is not able to send updates per its When a Subscription Service is not able to send updates per its
skipping to change at page 11, line 12 skipping to change at page 11, line 12
It MUST be possible for Receivers to associate the update with a It MUST be possible for Receivers to associate the update with a
specific Subscription. specific Subscription.
In the case of connection-oriented transport, when a transport In the case of connection-oriented transport, when a transport
connection drops, the associated Subscription SHOULD be terminated. connection drops, the associated Subscription SHOULD be terminated.
It is up the Subscriber to request a new Subscription. It is up the Subscriber to request a new Subscription.
4.2.5. Security Requirements 4.2.5. Security Requirements
Some uses of this Subscription Service will push privacy-sensitive Some uses of this Subscription Service will push privacy-sensitive
updates and metadata. Good deployment practices will bind this updates and metadata. For privacy-sensitive deployments,
generated information within secure, encrypted transport layer subscription information MUST be bound within secure, encrypted
mechanisms. For example if NETCONF is used as transport, then transport layer mechanisms. For example if NETCONF is used as
[RFC5539] would be a valid option to secure the transported transport, then [RFC5539] would be a valid option to secure the
information. The Subscription Service can also be used with emerging transported information. The Subscription Service can also be used
deployment contexts as well. As an example, deployments based on with emerging privacy-sensitive deployment contexts as well. As an
[i2rs-usecase] can apply these requirements in conjunction with those example, deployments based on [i2rs-usecase] would apply these
documented within [i2rs-protocol-security] to secure ephemeral state requirements in conjunction with those documented within
information being pushed from a Network Element. [i2rs-environment-security] and [i2rs-protocol-security] to secure
ephemeral state information being pushed from a Network Element.
As part of the Subscription establishment, there MUST be mutual As part of the Subscription establishment, mutual authentication MUST
authentication between the Subscriber and the Subscription Service. be used between the Subscriber and the Subscription Service.
When there are multiple Subscribers, it SHOULD be possible to provide Subscribers MUST NOT be able to pose as the original Subscription
cryptographic authentication in such a way that no Subscriber can Service.
pose as the original Subscription Service.
Versioning of any subscription protocols MUST be supported so that Versioning of any subscription protocols MUST be supported so that
the capabilities and behaviors expected of specific technology the capabilities and behaviors expected of specific technology
implementations can be exposed. implementations can be exposed.
A Subscription could be used to attempt to retrieve information to A Subscription could be used to attempt to retrieve information to
which a client has no authorized access. Therefore it is important which a client has no authorized access. Therefore it is important
that data pushed based on Subscriptions is authorized in the same way that data pushed based on Subscriptions is authorized in the same way
that regular data retrieval operations are authorized. Data being that regular data retrieval operations are authorized. Data being
pushed to a client MUST be filtered accordingly, just like if the pushed to a client MUST be filtered accordingly, just like if the
data were being retrieved on-demand. For Unicast transports, the data were being retrieved on-demand. For Unicast transports, the
NETCONF Authorization Control Model applies. NETCONF Authorization Control Model applies.
Additions or changes within a subscribed subtree structure MUST be Additions or changes within a subscribed subtree structure MUST be
validated against authorization methods before Subscription Updates validated against authorization methods before Subscription Updates
including new subtree information are pushed. including new subtree information are pushed.
A loss of authenticated access to subtree or node SHOULD be A loss of authenticated access to target subtree or node SHOULD be
communicated to the Subscriber. communicated to the Subscriber.
For any encrypted information exchanges, commensurate strength
security mechanisms MUST be available and SHOULD be used. This
includes all stages of the Subscription and update push process.
Subscription requests, including requests to create, terminate, Subscription requests, including requests to create, terminate,
suspend, and resume Subscriptions MUST be properly authorized. suspend, and resume Subscriptions MUST be properly authorized.
When the Subscriber and Receiver are different, the Receiver MUST be When the Subscriber and Receiver are different, the Receiver MUST be
able to terminate any Subscription to it where objects are being able to terminate any Subscription to it where objects are being
delivered over a Unicast transport. delivered over a Unicast transport.
A Subscription Service SHOULD decline a Subscription Request if it is A Subscription Service SHOULD decline a Subscription Request if it is
likely to deplete its resources. It is preferable to decline a likely to deplete its resources. It is preferable to decline a
Subscription when originally requested, rather than having to Subscription when originally requested, rather than having to
skipping to change at page 16, line 16 skipping to change at page 16, line 16
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<http://www.rfc-editor.org/info/rfc6241>. <http://www.rfc-editor.org/info/rfc6241>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <http://www.rfc-editor.org/info/rfc6513>. 2012, <http://www.rfc-editor.org/info/rfc6513>.
8.2. Informative References 8.2. Informative References
[i2rs-environment-security]
Migault, D., Halpern, J., and S. Hares, "I2RS Environment
Security Requirements", April 2016,
<https://datatracker.ietf.org/doc/draft-ietf-i2rs-
security-environment-reqs/>.
[i2rs-protocol-security] [i2rs-protocol-security]
Hares, S., Migault, D., and J. Halpern, "I2RS Security Hares, S., Migault, D., and J. Halpern, "I2RS Security
Related Requirements", May 2016, Related Requirements", May 2016,
<https://datatracker.ietf.org/doc/draft-ietf-i2rs- <https://datatracker.ietf.org/doc/draft-ietf-i2rs-
protocol-security-requirements/>. protocol-security-requirements/>.
[i2rs-usecase] [i2rs-usecase]
Hares, S. and M. Chen, "Summary of I2RS Use Case Hares, S. and M. Chen, "Summary of I2RS Use Case
Requirements", March 2016, Requirements", March 2016,
<https://datatracker.ietf.org/doc/draft-ietf-i2rs-usecase- <https://datatracker.ietf.org/doc/draft-ietf-i2rs-usecase-
 End of changes. 10 change blocks. 
29 lines changed or deleted 39 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/