draft-ietf-i2rs-pub-sub-requirements-03.txt   draft-ietf-i2rs-pub-sub-requirements-04.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: Standards Track A. Gonzalez Prieto
Expires: March 31, 2016 Cisco Systems Expires: July 7, 2016 Cisco Systems
September 28, 2015 January 4, 2016
Requirements for Subscription to YANG Datastores Requirements for Subscription to YANG Datastores
draft-ietf-i2rs-pub-sub-requirements-03 draft-ietf-i2rs-pub-sub-requirements-04
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 March 31, 2016. This Internet-Draft will expire on July 7, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 31 skipping to change at page 2, line 31
4.1. Assumptions for Subscriber Behavior . . . . . . . . . . . 8 4.1. Assumptions for Subscriber Behavior . . . . . . . . . . . 8
4.2. Subscription Service Requirements . . . . . . . . . . . . 8 4.2. Subscription Service Requirements . . . . . . . . . . . . 8
4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 8 4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 8
4.2.2. Negotiation . . . . . . . . . . . . . . . . . . . . . 10 4.2.2. Negotiation . . . . . . . . . . . . . . . . . . . . . 10
4.2.3. Update Distribution . . . . . . . . . . . . . . . . . 10 4.2.3. Update Distribution . . . . . . . . . . . . . . . . . 10
4.2.4. Transport . . . . . . . . . . . . . . . . . . . . . . 11 4.2.4. Transport . . . . . . . . . . . . . . . . . . . . . . 11
4.2.5. Security Requirements . . . . . . . . . . . . . . . . 11 4.2.5. Security Requirements . . . . . . . . . . . . . . . . 11
4.2.6. Subscription QoS . . . . . . . . . . . . . . . . . . 12 4.2.6. Subscription QoS . . . . . . . . . . . . . . . . . . 12
4.2.7. Filtering . . . . . . . . . . . . . . . . . . . . . . 13 4.2.7. Filtering . . . . . . . . . . . . . . . . . . . . . . 13
4.2.8. Assurance and Monitoring . . . . . . . . . . . . . . 14 4.2.8. Assurance and Monitoring . . . . . . . . . . . . . . 14
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6.1. Normative References . . . . . . . . . . . . . . . . . . 15 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
6.2. Informative References . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
YANG has gained acceptance as the data definition language of choice YANG has gained acceptance as the data definition language of choice
for control and management related information. Applications that for control and management related information. Applications that
interact with YANG datastores are extending beyond traditional interact with YANG datastores are extending beyond traditional
configuration of network elements. In many cases these applications configuration of network elements. In many cases these applications
are aimed at service-assurance, which involves monitoring of are aimed at service-assurance, which involves monitoring of
operational data and state. The existing YANG technology ecosystem operational data and state. The existing YANG technology ecosystem
is proving insufficient for those applications due to: is proving insufficient for those applications due to:
o a reliance on RPC-style interactions where data is configured or o a reliance on RPC-style interactions where data is configured or
fetched on-demand by applications. fetched on-demand by applications, and
o change notifications which identify a node associated with the o change notifications which identify a node associated with the
config change, without the actual data updates config change, without the actual data updates.
Put simply, periodic fetching of data is not an adequate solution for Put simply, periodic fetching of data is not an adequate solution for
applications requiring frequent or prompt updates of remote object applications requiring frequent or prompt updates of remote object
state. Trying to impose a polling based solution to this problem state. Trying to impose a polling based solution to this problem
imposes load on networks, devices, and applications. Additionally, imposes load on networks, devices, and applications. Additionally,
polling solutions are brittle in the face of communication glitches, polling solutions are brittle in the face of communication glitches,
and they have limitations in their ability to synchronize and and they have limitations in their ability to synchronize and
calibrate retrieval intervals across a network. calibrate retrieval intervals across a network.
I2RS WG documents have expressed a need for more robust YANG object I2RS WG documents have expressed a need for more robust YANG object
skipping to change at page 3, line 34 skipping to change at page 3, line 37
Element based applications can have access to a set of consistent Element based applications can have access to a set of consistent
network information driven via push from peer Network Elements which network information driven via push from peer Network Elements which
host authoritative information. host authoritative information.
There are some valid IETF starting points and contexts for these There are some valid IETF starting points and contexts for these
mechanisms. For example NETCONF Event Notifications [RFC5277] mechanisms. For example NETCONF Event Notifications [RFC5277]
provides a useful tool for an end-to-end solution. However RFC5277 provides a useful tool for an end-to-end solution. However RFC5277
does not follow the Pub/Sub paradigm, does not allow the explicit does not follow the Pub/Sub paradigm, does not allow the explicit
deletion of subscriptions, and predates YANG. Predating YANG is an deletion of subscriptions, and predates YANG. Predating YANG is an
issue, as monitoring and filtering based on YANG subtrees becomes issue, as monitoring and filtering based on YANG subtrees becomes
problematic . [RFC6470] defines configuration change notifications, problematic. [RFC6470] defines configuration change notifications,
but doesn't provide the actual configuration change. but doesn't provide the actual configuration change.
Because of this, the authors have put forward this requirements Because of this, the authors have put forward this requirements
document as well as [datastore-push]. We believe these provide a document as well as [datastore-push]. We believe these provide a
context upon which to create new solution. It is intended that these context upon which to create new solution. It is intended that these
documents include requirements and provide technologies applicable documents include requirements and provide technologies applicable
beyond I2RS. beyond I2RS.
2. Business Drivers 2. Business Drivers
skipping to change at page 5, line 36 skipping to change at page 5, line 39
And [i2rs-traceability] has Pub/Sub requirements listed in And [i2rs-traceability] has Pub/Sub requirements listed in
Section 7.4.3. Section 7.4.3.
o I2RS Agents should support publishing I2RS trace log information o I2RS Agents should support publishing I2RS trace log information
to that feed as described in [i2rs-arch]. Subscribers would then to that feed as described in [i2rs-arch]. Subscribers would then
receive a live stream of I2RS interactions in trace log format and receive a live stream of I2RS interactions in trace log format and
could flexibly choose to do a number of things with the log could flexibly choose to do a number of things with the log
messages messages
There are additional individual drafts such as [i2rs-pubsub-security]
documenting the Pub/Sub needs for: time delivery sensitivity, support
for multiple transport protocols, secure/authorized communications,
and support for a range specification of subscribed data delivery
content. So the list above should not be considered exhaustive.
2.2. Pub/Sub variants on Network Elements 2.2. Pub/Sub variants on Network Elements
This document is intended to cover requirements beyond I2RS. Looking This document is intended to cover requirements beyond I2RS. Looking
at history, there are many examples of switching and routing at history, there are many examples of switching and routing
protocols which have done explicit or implicit pub/sub in the past. protocols which have done explicit or implicit pub/sub in the past.
In addition, new policy notification mechanisms which operate on In addition, new policy notification mechanisms which operate on
Switches and Routers are being specified now. A very small subset of Switches and Routers are being specified now. A very small subset of
these includes: these includes:
o Routing Adjacencies in MPLS VPNs [RFC6513] o Routing Adjacencies in MPLS VPNs [RFC6513]
skipping to change at page 6, line 31 skipping to change at page 6, line 27
may support alternative transports. Looking at the nearer term based may support alternative transports. Looking at the nearer term based
on current I2RS requirements, NETCONF should be our transport on current I2RS requirements, NETCONF should be our transport
starting point as it supports connection oriented/Unicast starting point as it supports connection oriented/Unicast
communication. But we need to be prepared to decouple where viable communication. But we need to be prepared to decouple where viable
to support Multicast and Broadcast distribution as well. to support Multicast and Broadcast distribution as well.
2.3. Existing Generalized Pub/Sub Implementations 2.3. Existing Generalized Pub/Sub Implementations
TIBCO, RSS, CORBA, and other technologies all show precursor Pub/Sub TIBCO, RSS, CORBA, and other technologies all show precursor Pub/Sub
technologies. However there are new needs described in Section 4 technologies. However there are new needs described in Section 4
below which these technologies do not serve. We need a technology. below which these technologies do not serve. We need a new pub-sub
technology.
There are at least two widely deployed generalized pub/sub There are at least two widely deployed generalized pub/sub
implementations which come close to current needs: XMPP[XEP-0060] and implementations which come close to current needs: XMPP[XEP-0060] and
DDS[OMG-DDS]. Both serve as proof-points that a highly scalable DDS[OMG-DDS]. Both serve as proof-points that a highly scalable
distributed datastore implementation connecting millions of edge distributed datastore implementation connecting millions of edge
devices is possible. devices is possible.
Because of these proof points, we can be comfortable that the Because of these proof points, we can be comfortable that the
underlying technologies can enable reusable generalized YANG object underlying technologies can enable reusable generalized YANG object
distribution. Analysis will need to fully dimension the speed and distribution. Analysis will need to fully dimension the speed and
scale of such object distribution for various subtree sizes and scale of such object distribution for various subtree sizes and
transport types. transport types.
3. Terminology 3. Terminology
A Subscriber makes requests for set(s) of YANG object data. The The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Subscriber is the owner of the Subscription. "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
A Subscriber makes requests for set(s) of YANG object data.
A Publisher is responsible for distributing subscribed YANG object A Publisher is responsible for distributing subscribed YANG object
data per the terms of a Subscription. In general, a Publisher is the data per the terms of a Subscription. In general, a Publisher is the
owner of the YANG datastore that is subjected to the Subscription. owner of the YANG datastore that is subjected to the Subscription.
A Receiver is the target where a Publisher pushes updates. In A Receiver is the target where a Publisher pushes updates. In
general, the Receiver and Subscriber will be the same entity. A general, the Receiver and Subscriber will be the same entity. A
Subscription Service provides Subscriptions to Subscribers of YANG Subscription Service provides Subscriptions to Subscribers of YANG
data. data.
skipping to change at page 8, line 14 skipping to change at page 8, line 14
4. Requirements 4. Requirements
Many of the requirements within this section have been morphed from Many of the requirements within this section have been morphed from
OMG's DDS and XMPP.org's requirements specifications. OMG's DDS and XMPP.org's requirements specifications.
4.1. Assumptions for Subscriber Behavior 4.1. Assumptions for Subscriber Behavior
This document provides requirements for the Subscription Service. It This document provides requirements for the Subscription Service. It
does not define all the requirements for the Subscriber/Receiver. does not define all the requirements for the Subscriber/Receiver.
However In order to frame the desired behavior of the Subscription However in order to frame the desired behavior of the Subscription
Service, it is important to specify key input constraints. Service, it is important to specify key input constraints.
A Subscriber should avoid attempting to establish multiple A Subscriber SHOULD avoid attempting to establish multiple
Subscriptions pertaining to the same information, i.e. referring to Subscriptions pertaining to the same information, i.e. referring to
the same datastore YANG subtrees. the same datastore YANG subtrees.
A Subscriber may provide Subscription QoS criteria to the A Subscriber MAY provide Subscription QoS criteria to the
Subscription Service such that if the Subscription Service is unable Subscription Service such that if the Subscription Service is unable
to meet those criteria, the Subscription should not be established. to meet those criteria, the Subscription SHOULD NOT be established.
When a Subscriber needs to restart, it is acceptable for the When a Subscriber needs to restart, the Subscriber MAY have to
Subscriber to have to resubscribe. There is no requirement for the resubscribe. There is no requirement for the life span of the
life span of the Subscription to extend beyond the life span of the Subscription to extend beyond the life span of the Subscriber.
Subscriber.
A Subscriber must be able to infer when a Subscription Service is no A Subscriber MUST be able to infer when a Subscription Service is no
longer active and when no more updates are being sent. longer active and when no more updates are being sent.
A Subscriber may check with a Subscription Service to validate the A Subscriber MAY check with a Subscription Service to validate the
existence and monitored subtrees of a Subscription. existence and monitored subtrees of a Subscription.
A Subscriber must be able to periodically lease and re-lease a A Subscriber MUST be able to periodically lease and re-lease a
Subscription from a Subscription Service. Subscription from a Subscription Service.
4.2. Subscription Service Requirements 4.2. Subscription Service Requirements
4.2.1. General 4.2.1. General
A Subscription Service must support the ability to create, renew, A Subscription Service MUST support the ability to create, renew,
timeout, and terminate a Subscription. timeout, and terminate a Subscription.
A Subscription Service must be able to support and independently A Subscription Service MUST be able to support and independently
track one or more Subscription Requests by the same Subscriber. track one or more Subscription Requests by the same Subscriber.
A Subscription Service must be able to support an add/change/delete A Subscription Service MUST be able to support an add/change/delete
of one or more YANG subtrees as part of the same Subscription of one or more YANG subtrees as part of the same Subscription
Request. Request.
A Subscription Service must support Subscriptions against operational A Subscription Service MUST support Subscriptions against operational
datastores, configuration datastores, or both. datastores, configuration datastores, or both.
A Subscription Service must be able support a Subtree Filter so that A Subscription Service MUST be able support a Subtree Filter so that
subscribed updates under a target node might publish only operational subscribed updates under a target node might publish only operational
data, only configuration data, or both. data, only configuration data, or both.
A Subscription may include filters as defined within a Subscription A Subscription MAY include filters as defined within a Subscription
Request, the Subscription Service must publish only data nodes that Request, Therefore the Subscription Service MUST publish only data
meet the filter criteria. nodes that meet the filter criteria within a Subscription.
A Subscription Service must support the ability to subscribe to A Subscription Service MUST support the ability to subscribe to
periodic updates. The subscription period must be configurable as periodic updates. The subscription period MUST be configurable as
part of the subscription request. part of the subscription request.
A Subscription Service should support the ability to subscribe to A Subscription Service SHOULD support the ability to subscribe to
updates "on-change", i.e. whenever values of subscribed data objects updates "on-change", i.e. whenever values of subscribed data objects
change. change.
For "on-change" updates, the Subscription Service must support a For "on-change" updates, the Subscription Service MUST support a
dampening period that needs to pass before the first or subsequent dampening period that needs to pass before the first or subsequent
"on-change" updates are sent. The dampening period should be "on-change" updates are sent. The dampening period SHOULD be
configurable as part of the subscription request. configurable as part of the subscription request.
A Subscription Service must allow Subscriptions to be monitored. A Subscription Service MUST allow Subscriptions to be monitored.
Specifically, a Subscription Service must at a minimum maintain Specifically, a Subscription Service MUST at a minimum maintain
information about which Subscriptions are being serviced, the terms information about which Subscriptions are being serviced, the terms
of those subscriptions (e.g. what data is being subscribed, of those subscriptions (e.g. what data is being subscribed,
associated filters, update policy - on change, periodic), and the associated filters, update policy - on change, periodic), and the
overall status of the Subscription - e.g. active or suspended. overall status of the Subscription - e.g. active or suspended.
A Subscription Service should be able to interpret Subscription QoS A Subscription Service SHOULD be able to interpret Subscription QoS
parameters, and only establish a Subscription if it is possible to parameters, and only establish a Subscription if it is possible to
meet the QoS needs of the provided QoS parameters. meet the QoS needs of the provided QoS parameters.
A Subscription Service must support terminating of a Subscription A Subscription Service MUST support terminating of a Subscription
when requested by the Subscriber. when requested by the Subscriber.
A Subscription Service should support the ability to suspend and to A Subscription Service SHOULD support the ability to suspend and to
resume a Subscription on request of a client. resume a Subscription on request of a client.
A Subscription Service may at its discretion revoke or suspend an A Subscription Service MAY at its discretion revoke or suspend an
existing subscription. Reasons may include transitory resource existing subscription. Reasons may include transitory resource
limitation, credential expiry, failure to reconfirm a subscription, limitation, credential expiry, failure to reconfirm a subscription,
loss of connectivity with the Receiver, operator CLI, and/or others. loss of connectivity with the Receiver, operator CLI, and/or others.
When this occurs, the Subscription Service must notify the Subscriber When this occurs, the Subscription Service MUST notify the Subscriber
and update subscription status. and update subscription status.
A Subscription Service may offer the ability to modify a subscription A Subscription Service MAY offer the ability to modify a subscription
filter. If such an ability is offered, the service must provide filter. If such an ability is offered, the service MUST provide
subscribers with an indication at what point the modified subscribers with an indication at what point the modified
subscription goes into effect. subscription goes into effect.
4.2.2. Negotiation 4.2.2. Negotiation
A Subscription Service must be able to negotiate the following terms A Subscription Service MUST be able to negotiate the following terms
of a Subscription: of a Subscription:
o The policy: i.e. whether updates are on-change of periodic o The policy: i.e. whether updates are on-change of periodic
o The interval, for periodic publication policy o The interval, for periodic publication policy
o The dampening period, for on-change update policy o The dampening period, for on-change update policy
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, the
Subscription Service must include in its decline a set of criteria Subscription Service MUST include in its decline a set of criteria
that would have been acceptable when the Subscription Request was that would have been acceptable when the Subscription Request was
made. For example, if periodic updates were requested with too short made. For example, if periodic updates were requested with too short
update intervals for the specified data set, the minimum acceptable update intervals for the specified data set, the minimum acceptable
interval period should be included. If on-change updates were interval period SHOULD be included. If on-change updates were
requested with a dampening period, the minimum acceptable dampening requested with a dampening period, the minimum acceptable dampening
period should be included, or an indication whether only periodic period SHOULD be included, or an indication whether only periodic
updates are supported along with the minimum acceptable interval updates are supported along with the minimum acceptable interval
period for the data set being subscribed to. period for the data set being subscribed to.
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 will not know what has actually undergone change.] the subscriber will not know what has actually undergone change.]
The updates for each object needs to include an indication whether it The updates for each object MUST include an indication whether it was
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
subscription contract, the Subscription must notify subscribers and subscription contract, the Subscription MUST notify subscribers and
put the subscription into a state of indicating the Subscription was put the subscription into a state of indicating the Subscription was
suspended by the service. When able to resume service, subscribers suspended by the service. When able to resume service, subscribers
need to be notified as well. If unable to resume service, the need to be notified as well. If unable to resume service, the
Subscription Service may terminate the subscription and notify Subscription Service MAY terminate the subscription and notify
Subscribers accordingly. Subscribers accordingly.
When a Subscription with "on-change" updates is suspended and then When a Subscription with "on-change" updates is suspended and then
resumed, the first update should include updates of any changes that resumed, the first update SHOULD include updates of any changes that
occurred while the Subscription was suspended, with the current occurred while the Subscription was suspended, with the current
value. The Subscription Service must provide a clear indication when value. The Subscription Service MUST provide a clear indication when
this capability is not supported (because in this case a client this capability is not supported (because in this case a client
application may have to synchronize state separately). application may have to synchronize state separately).
Multiple objects being pushed to a Subscriber, perhaps from different Multiple objects being pushed to a Subscriber, perhaps from different
Subscriptions, should be bundled together into a single Update. Subscriptions, SHOULD be bundled together into a single Update.
The sending of an Update must not be delayed beyond the Push Latency The sending of an Update MUST NOT be delayed beyond the Push Latency
of any enclosed object changes. of any enclosed object changes.
The sending of an Update must not be delayed beyond the dampening The sending of an Update MUST NOT be delayed beyond the dampening
period of any enclosed object changes. period of any enclosed object changes.
The sending of an Update must not occur before the dampening period The sending of an Update MUST NOT occur before the dampening period
expires for any enclosed object changes. expires for any enclosed object changes.
A Subscription Service may, as an option, support a persistence/ A Subscription Service MAY, as an option, support a persistence/
replay capability. replay capability.
4.2.4. Transport 4.2.4. Transport
A Subscription Service should support different transports. A Subscription Service SHOULD support different transports.
A Subscription Service should support different encodings of payload. A Subscription Service SHOULD support different encodings of payload.
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
As part of the Subscription establishment, there must be mutual As part of the Subscription establishment, there MUST be mutual
authentication between the Subscriber and the Subscription Service. authentication between the Subscriber and the Subscription Service.
When there are multiple Subscribers, it should be possible to provide When there are multiple Subscribers, it SHOULD be possible to provide
cryptographic authentication in such a way that no Subscriber can cryptographic authentication in such a way that no Subscriber can
pose as the original Subscription Service. pose as the original Subscription Service.
Versioning must be supported. Versioning MUST be supported.
A Subscription could be used to attempt to retrieve information that A Subscription could be used to attempt to retrieve information that
a client has not authorized access to. Therefore it is important a client has not authorized access to. 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. Data being pushed to a that regular data retrieval operations are authorized. Data being
client must be filtered accordingly, just like if the data were being pushed to a client MUST be filtered accordingly, just like if the
retrieved on-demand. For Unicast transports, the NETCONF data were being retrieved on-demand. For Unicast transports, the
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 subtree or node SHOULD be
communicated to the Subscriber communicated to the Subscriber.
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 A Subscription Service SHOULD decline a Subscription Request if it
would deplete its resources. It is preferable to decline a would 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
terminate it prematurely later. terminate it prematurely later.
4.2.6. Subscription QoS 4.2.6. Subscription QoS
A Subscription Service should be able to negotiate the following A Subscription Service SHOULD be able to negotiate the following
Subscription QoS parameters with a Subscriber: Dampening, Subscription QoS parameters with a Subscriber: Dampening,
Reliability, Deadline, Bundling. Reliability, Deadline, and Bundling.
4.2.6.1. Liveliness 4.2.6.1. Liveliness
A Subscription Service must be able to respond to requests to verify A Subscription Service MUST be able to respond to requests to verify
the Liveliness of a subscription. the Liveliness of a subscription.
A Subscription Service must be able to report the currently monitored A Subscription Service MUST be able to report the currently monitored
Nodes of a Subscription. Nodes of a Subscription.
4.2.6.2. Dampening 4.2.6.2. Dampening
A Subscription Service must be able to negotiate the minimum time A Subscription Service MUST be able to negotiate the minimum time
separation since the previous update before transmitting a subsequent separation since the previous update before transmitting a subsequent
update for Subscription. (Note: this is intended to confine the update for Subscription. (Note: this is intended to confine the
visibility of volatility into something digestible by the receiver.) visibility of volatility into something digestible by the receiver.)
4.2.6.3. Reliability 4.2.6.3. Reliability
A Subscription Service may send Updates over Best Effort and Reliable A Subscription Service MAY send Updates over Best Effort and Reliable
transports. transports.
4.2.6.4. Coherence 4.2.6.4. Coherence
Every update to a subscribed object must be sent to the Receiver in For a particular Subscription, every update to a subscribed object
sequential order. MUST be sent to the Receiver in sequential order.
4.2.6.5. Presentation 4.2.6.5. Presentation
The Subscription Service should have the ability to bundle a set of The Subscription Service SHOULD have the ability to bundle a set of
discrete object notifications into a single publishable update for a discrete object notifications into a single publishable update for a
Subscription. A bundle may include information on different Data Subscription. A bundle MAY include information on different Data
Nodes and/or multiple updates about a single Data Node. Nodes and/or multiple updates about a single Data Node.
For any bundled updates, the Subscription Service must provide For any bundled updates, the Subscription Service MUST provide
information for a Receiver to reconstruct the order and timing of information for a Receiver to reconstruct the order and timing of
updates. updates.
4.2.6.6. Deadline 4.2.6.6. Deadline
The Subscription Service must be able to push updates at a regular The Subscription Service MUST be able to push updates at a regular
cadence that corresponds with Subscriber specified start and end cadence that corresponds with Subscriber specified start and end
timestamps. (Note: the regular cadence can drive one, a discrete timestamps. (Note: the regular cadence can drive one, a discrete
quantity, or an unbounded set of periodic updates.) quantity, or an unbounded set of periodic updates.)
4.2.6.7. Push Latency 4.2.6.7. Push Latency
The Subscription Service should be able to delay Updates on object The Subscription Service SHOULD be able to delay Updates on object
push for a configurable period per Subscriber. push for a configurable period per Subscriber.
It must be possible for an administrative entity to determine the It MUST be possible for an administrative entity to determine the
Push latency between object change in a monitored subtree and the Push latency between object change in a monitored subtree and the
Subscription Service Push of the update transmission. Subscription Service Push of the update transmission.
4.2.7. Filtering 4.2.7. Filtering
If no filtering criteria are provided, or if filtering criteria are If no filtering criteria are provided, or if filtering criteria are
met, updates for a subscribed object must be pushed, subject to the met, updates for a subscribed object MUST be pushed, subject to the
QoS limits established for the subscription. QoS limits established for the subscription.
It must be possible for the Subscription Service to receive Filter(s) It MUST be possible for the Subscription Service to receive Filter(s)
from a Subscriber and apply them to corresponding object(s) within a from a Subscriber and apply them to corresponding object(s) within a
Subscription. Subscription.
It must be possible to attach one or more Subtree and/or Property It MUST be possible to attach one or more Subtree and/or Property
Filters to a subscription. Mandatory Property Filter types include: Filters to a subscription. Mandatory Property Filter types include:
o For character based object properties, filter values which are o For character based object properties, filter values which are
exactly equal to a provided string, not equal to the string, or exactly equal to a provided string, not equal to the string, or
containing a string. containing a string.
o For numeric based object properties, filter values which are =, o For numeric based object properties, filter values which are =,
!=, <, <=, >, >= a provided number. !=, <, <=, >, >= a provided number.
It should be possible for Property Filtering criteria to evaluate It SHOULD be possible for Property Filtering criteria to evaluate
more than one property of a particular subscribed object as well as more than one property of a particular subscribed object as well as
apply multiple filters against a single property. apply multiple filters against a single property.
It should be possible to establish query match criteria on additional It SHOULD be possible to establish query match criteria on additional
objects to be used in conjunction with Property Filtering criteria on objects to be used in conjunction with Property Filtering criteria on
a subscribed object. (For example: if A has changed AND B=1, then a subscribed object. (For example: if A has changed AND B=1, then
Push A.) (Note: Query match capability may be done on objects within Push A.) (Note: Query match capability may be done on objects within
the datastore even if those objects are not included within the the datastore even if those objects are not included within the
subscription. This of course assumes the subscriber has read access subscription. This of course assumes the subscriber has read access
to those objects.) to those objects.)
4.2.8. Assurance and Monitoring 4.2.8. Assurance and Monitoring
It must be possible to fetch the state of a single subscription from It MUST be possible to fetch the state of a single subscription from
a Subscription Service. a Subscription Service.
It must be possible to fetch the state of all subscriptions of a It MUST be possible to fetch the state of all subscriptions of a
particular Subscriber. particular Subscriber.
It must be possible to fetch a list and status of all Subscription It MUST be possible to fetch a list and status of all Subscription
Requests over a period of time. If there us a failure, some failure Requests over a period of time. If there us a failure, some failure
reasons might include: reasons MAY include:
o Improper security credentials provided to access the target node o Improper security credentials provided to access the target node;
o Target node referenced does not exist o Target node referenced does not exist;
o Subscription type requested is not available upon the target node o Subscription type requested is not available upon the target node;
o Out of resources, or resources not available o Out of resources, or resources not available;
o Incomplete negotiations with the Subscriber. o Incomplete negotiations with the Subscriber.
5. Acknowledgements 5. Security Considerations
There are no additional security considerations beyond the
requirements listed in Section 4.2.5.
6. IANA Considerations
This document has no actions for IANA.
7. Acknowledgements
We wish to acknowledge the helpful contributions, comments, and We wish to acknowledge the helpful contributions, comments, and
suggestions that were received from Ambika Tripathy and Prabhakara suggestions that were received from Ambika Tripathy and Prabhakara
Yellai as well as the helpfulness of related end-to-end system Yellai as well as the helpfulness of related end-to-end system
context from [i2rs-pubsub-security] from Nancy Cam Winget, Ken Beck, context info from Nancy Cam Winget, Ken Beck, and David McGrew.
and David McGrew.
6. References 8. References
6.1. Normative References 8.1. Normative References
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/ [i2rs-arch]
RFC2328, April 1998, Atlas, A., "An Architecture for the Interface to the
Routing System", December 2015,
<https://datatracker.ietf.org/doc/draft-ietf-i2rs-
architecture/>.
[i2rs-traceability]
Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to
the Routing System (I2RS) Traceability: Framework and
Information Model", December 2015,
<https://datatracker.ietf.org/doc/draft-ietf-i2rs-
traceability/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998,
<http://www.rfc-editor.org/info/rfc2328>. <http://www.rfc-editor.org/info/rfc2328>.
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event
Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008,
<http://www.rfc-editor.org/info/rfc5277>. <http://www.rfc-editor.org/info/rfc5277>.
[RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF) [RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF)
Base Notifications", RFC 6470, DOI 10.17487/RFC6470, Base Notifications", RFC 6470, DOI 10.17487/RFC6470,
February 2012, <http://www.rfc-editor.org/info/rfc6470>. February 2012, <http://www.rfc-editor.org/info/rfc6470>.
[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>.
6.2. Informative References 8.2. Informative References
[AVB-latency] [AVB-latency]
Jeffree, T., "802.1Qav - Forwarding and Queuing Jeffree, T., "802.1Qav - Forwarding and Queuing
Enhancements for Time-Sensitive Streams", December 2009, Enhancements for Time-Sensitive Streams", December 2009,
<http://www.ieee802.org/1/pages/802.1av.html>. <http://www.ieee802.org/1/pages/802.1av.html>.
[datastore-push] [datastore-push]
Clemm, A., Gonzalez Prieto, A., and E. Voit, "Subscribing Clemm, A., Gonzalez Prieto, A., and E. Voit, "Subscribing
to datastore push updates", July 2015, to datastore push updates", October 2015,
<https://tools.ietf.org/html/draft-clemm-netconf-yang- <https://tools.ietf.org/html/draft-clemm-netconf-yang-
push-01>. push-02>.
[draft-voit-netmod] [draft-voit-netmod]
Voit, E., "Requirements for Peer Mounting of YANG subtrees Voit, E., "Requirements for Peer Mounting of YANG subtrees
from Remote Datastores", September 2015, from Remote Datastores", September 2015,
<https://tools.ietf.org/html/draft-voit-netmod-peer-mount- <https://tools.ietf.org/html/draft-voit-netmod-peer-mount-
requirements-03>. requirements-03>.
[i2rs-arch]
Atlas, A., "An Architecture for the Interface to the
Routing System", March 2015,
<https://datatracker.ietf.org/doc/draft-ietf-i2rs-
architecture/>.
[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, <https://tools.ietf.org/html/draft-
camwinget-i2rs-pubsub-sec-00>.
[i2rs-traceability]
Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to
the Routing System (I2RS) Traceability: Framework and
Information Model", May 2015,
<https://datatracker.ietf.org/doc/draft-ietf-i2rs-
traceability/>.
[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", May 2015, Requirements", November 2015,
<https://datatracker.ietf.org/doc/draft-ietf-i2rs-usecase- <https://datatracker.ietf.org/doc/draft-ietf-i2rs-usecase-
reqs-summary/>. reqs-summary/>.
[OMG-DDS] "Data Distribution Service for Real-time Systems, version [OMG-DDS] "Data Distribution Service for Real-time Systems, version
1.2", January 2007, <http://www.omg.org/spec/DDS/1.2/>. 1.2", January 2007, <http://www.omg.org/spec/DDS/1.2/>.
[sacm-requirements] [sacm-requirements]
Cam Winget, N., "Secure Automation and Continuous Cam Winget, N., "Secure Automation and Continuous
Monitoring (SACM) Requirements", July 2015, Monitoring (SACM) Requirements", July 2015,
<https://tools.ietf.org/html/draft-ietf-sacm-requirements- <https://tools.ietf.org/html/draft-ietf-sacm-requirements-
 End of changes. 101 change blocks. 
146 lines changed or deleted 152 lines changed or added

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