draft-ietf-i2rs-pub-sub-requirements-06.txt   draft-ietf-i2rs-pub-sub-requirements-07.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: October 17, 2016 Cisco Systems Expires: November 5, 2016 Cisco Systems
April 15, 2016 May 4, 2016
Requirements for Subscription to YANG Datastores Requirements for Subscription to YANG Datastores
draft-ietf-i2rs-pub-sub-requirements-06 draft-ietf-i2rs-pub-sub-requirements-07
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 October 17, 2016. This Internet-Draft will expire on November 5, 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 2, line 28 skipping to change at page 2, line 28
2.3. Existing Generalized Pub/Sub Implementations . . . . . . 5 2.3. Existing Generalized Pub/Sub Implementations . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Assumptions for Subscriber Behavior . . . . . . . . . . . 7 4.1. Assumptions for Subscriber Behavior . . . . . . . . . . . 7
4.2. Subscription Service Requirements . . . . . . . . . . . . 7 4.2. Subscription Service Requirements . . . . . . . . . . . . 7
4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 7 4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 7
4.2.2. Negotiation . . . . . . . . . . . . . . . . . . . . . 9 4.2.2. Negotiation . . . . . . . . . . . . . . . . . . . . . 9
4.2.3. Update Distribution . . . . . . . . . . . . . . . . . 9 4.2.3. Update Distribution . . . . . . . . . . . . . . . . . 9
4.2.4. Transport . . . . . . . . . . . . . . . . . . . . . . 10 4.2.4. Transport . . . . . . . . . . . . . . . . . . . . . . 10
4.2.5. Security Requirements . . . . . . . . . . . . . . . . 11 4.2.5. Security Requirements . . . . . . . . . . . . . . . . 11
4.2.6. Subscription QoS . . . . . . . . . . . . . . . . . . 11 4.2.6. Subscription QoS . . . . . . . . . . . . . . . . . . 12
4.2.7. Filtering . . . . . . . . . . . . . . . . . . . . . . 13 4.2.7. Filtering . . . . . . . . . . . . . . . . . . . . . . 13
4.2.8. Assurance and Monitoring . . . . . . . . . . . . . . 13 4.2.8. Assurance and Monitoring . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
Applications interacting with YANG datastores require capabilities Applications interacting with YANG datastores require capabilities
beyond the traditional client-server configuration of network beyond the traditional client-server configuration of network
elements. One class of such applications are service-assurance elements. One class of such applications are service-assurance
applications which must maintain a continuous view of operational applications which must maintain a continuous view of operational
data and state. Another class of applications are security data and state. Another class of applications are security
applications which must continuously track changes made upon network applications which must continuously track changes made upon network
elements to ensure compliance to corporate policy. elements to ensure compliance to corporate policy.
skipping to change at page 5, line 11 skipping to change at page 5, line 11
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
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 small subset of switches and routers are being specified now. A small subset of
current and past subscriptions includes: current and past subscription mechanisms includes:
o Multicast topology establishment is accomplished before any o Multicast topology establishment is accomplished before any
content delivery is made to endpoints (IGMP, PIM, etc.) content delivery is made to endpoints (IGMP, PIM, etc.)
o Secure Automation and Continuous Monitoring (SACM) allows o Secure Automation and Continuous Monitoring (SACM) allows
subscription into devices which then may push spontaneous changes subscription into devices which then may push spontaneous changes
in their configured hardware and software[sacm-requirements] in their configured hardware and software[sacm-requirements]
o In MPLS VPNs [RFC6513] a Customer Edge router exchanges PIM o In MPLS VPNs [RFC6513] a Customer Edge router exchanges PIM
control messages before PE Routing Adjacencies are passed. control messages before PE Routing Adjacencies are passed.
[RFC6513] [RFC6513]
o After OSPF establishes its adjacencies, Link State Advertisement o After OSPF establishes its adjacencies, Link State Advertisement
will then commence [RFC2328] will then commence [RFC2328]
Worthy of note in the examples above is the wide variety of Worthy of note in the examples above is the wide variety of
underlying transports. A generalized Pub/Sub mechanism therefore underlying transports. A generalized Pub/Sub mechanism therefore
should be structured to support alternative transports. Based on should be structured to support alternative transports. Based on
current I2RS requirements, NETCONF should the initially supported current I2RS requirements, NETCONF should be the initially supported
transport based on the need for connection-oriented/unicast transport based on the need for connection-oriented/unicast
communication. Eventual support Multicast and Broadcast subscription communication. Eventual support for multicast and broadcast
update distribution will be needed as well. subscription update distribution will be needed 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 new pub-sub below which these technologies do not serve. We need a new pub-sub
technology. 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
skipping to change at page 6, line 11 skipping to change at page 6, line 11
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
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119]. Although
this document is not a protocol specification, the use of this
language clarifies the instructions to protocol designers producing
solutions that satisfy the requirements set out in this document.
A Subscriber makes requests for set(s) of YANG object data. 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 to which a Publisher pushes updates. In A Receiver is the target to which 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
skipping to change at page 6, line 37 skipping to change at page 6, line 40
A Subscription Request for one or more YANG subtrees (including A Subscription Request for one or more YANG subtrees (including
single leafs) is made by the Subscriber of a Publisher and is single leafs) is made by the Subscriber of a Publisher and is
targeted to a Receiver. A Subscription may include constraints which targeted to a Receiver. A Subscription may include constraints which
dictate how often or under what conditions YANG information updates dictate how often or under what conditions YANG information updates
might be sent. might be sent.
A Subscription is a contract between a Subscription Service and a A Subscription is a contract between a Subscription Service and a
Subscriber that stipulates the data to be pushed and the associated Subscriber that stipulates the data to be pushed and the associated
terms. terms.
A YANG datastore is a conceptual datastore that contains hierarchical A datastore is defined in [RFC6241] and is not redefined here.
data defined in YANG data models. It is what is referred in existing
RFCs as "NETCONF datastore". However, as the same datastore is no
longer tied to NETCONF as a specific transport, the term "YANG
datastore" is deemed more appropriate.
An Update provides object changes which have occurred within An Update provides object changes which have occurred within
subscribed YANG subtree(s). An Update must include the current subscribed YANG subtree(s). An Update must include the current
status of (data) node instances which according to any filtering are status of (data) node instances which according to any filtering are
reportably different from the previously provided state. An Update reportably different from the previously provided state. An Update
may include a bundled set of ordered/sequential changes for a given may include a bundled set of ordered/sequential changes for a given
object which have been made since the last update. object that have been made since the last update.
A Filter contains evaluation criteria which are evaluated against A Filter contains evaluation criteria which are evaluated against
YANG object(s) within a Subscription. There are two types of YANG object(s) within a Subscription. There are two types of
Filters: Subtree Filters which identify selected objects/nodes Filters: Subtree Filters which identify selected objects/nodes
published under a target data node, and object Property Filters where published under a target data node, and object element and attribute
an object should only be published if it has propert(ies) meeting Filters where an object should only be published if it has properties
specified Filter criteria. For "on-change" notifications, passing meeting specified Filter criteria.
through the Filter requires that a subscribed object is now different
that from the previous Push, AND at least one of the YANG objects
being evaluated has changed since the last Update.
4. Requirements 4. Requirements
Many of the requirements within this section have been morphed from Many of the requirements within this section have been adapted from
XMPP[XEP-0060] and DDS[OMG-DDS] requirements specifications. XMPP[XEP-0060] and DDS[OMG-DDS] 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; if the Subscription Service is unable to meet Subscription Service; if the Subscription Service is unable to meet
those criteria, the Subscription SHOULD NOT be established. those criteria, the Subscription SHOULD NOT be established.
When a Subscriber needs to restart, the Subscriber MAY have to When a Subscriber and Receiver are the same entity and the transport
resubscribe. There is no requirement for the life span of the session is lost/terminated, the Subscriber MUST reestablish any
Subscription to extend beyond the life span of the Subscriber. subscriptions it previously created via signalling over the transport
session. I.e., There is no requirement for the life span of such
signaled Subscriptions extend beyond the life span of the transport
session.
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 extend the lease A Subscriber MUST be able to periodically lease and extend the lease
a Subscription from a Subscription Service. of a 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 multiple 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 subscriptions to multiple YANG subtrees as part of the same
Request. Subscription 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 filtering 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, therefore the Subscription Service MUST publish only data Request, therefore the Subscription Service MUST publish only data
nodes that meet the filter criteria within a Subscription. 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
parameters, and only establish a Subscription if it is possible to
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.
skipping to change at page 9, line 9 skipping to change at page 9, line 4
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 telling at what point the modified subscribers with an indication telling 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 or periodic o The policy: i.e. whether updates are on-change or periodic
o The interval, for periodic publication policy o The interval, for periodic publication policy
o The dampening period, for on-change update policy (if supported) o The dampening period, for on-change update policy (if supported)
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
skipping to change at page 10, line 34 skipping to change at page 10, line 32
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 replay capability
replay capability. so that a set of updates generated during a previous time internal
can be sent to a Receiver.
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.
skipping to change at page 11, line 14 skipping to change at page 11, line 14
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 so that the capabilities and behaviors
expected of specific technology implementations can be exposed.
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 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
skipping to change at page 11, line 43 skipping to change at page 11, line 44
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
terminate it prematurely later. terminate it prematurely later.
When the Subscriber and Receiver are different, and when the
underlying transport connection passes credentials as part of
transport establishment, then potentially pushed objects MUST be
excluded from a push update if that object doesn't have read access
visibility for that the Receiver.
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, and Bundling. Reliability, Deadline, and Bundling.
A Subscription Service SHOULD be able to interpret Subscription QoS
parameters, and only establish a Subscription if it is possible to
meet the QoS needs of the provided QoS parameters.
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
skipping to change at page 13, line 9 skipping to change at page 13, line 21
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.6.8. Relative Priority
The Subscription Service SHOULD include the relative priority of push
updates so that dequeuing and discarding of case of limited bandwidth
between Publisher and
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 object
Filters to a subscription. Mandatory Property Filter types include: element and attribute Filters to a subscription. Mandatory 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 Filtering criteria to evaluate more than
more than one property of a particular subscribed object as well as one property of a particular subscribed object as well as apply
apply multiple filters against a single property. multiple Filters against a single object.
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 Filtering criteria on a
a subscribed object. (For example: if A has changed AND B=1, then subscribed object. (For example: if A has changed and B=1, then Push
Push A.) Query match capability may be done on objects within the A.) Query match capability may be done on objects within the
datastore even if those objects are not included within 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.
For on-change subscription updates, an object MUST pass a Filter
through a Filter if it has changed since the previous update. This
includes if the object has changed multiple times since the last
update, and ithe value happens to be the exact same value as the last
one sent.
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 is a failure, some failure
reasons MAY include: reasons might 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.
skipping to change at page 15, line 9 skipping to change at page 15, line 38
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998, DOI 10.17487/RFC2328, April 1998,
<http://www.rfc-editor.org/info/rfc2328>. <http://www.rfc-editor.org/info/rfc2328>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<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-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. 40 change blocks. 
61 lines changed or deleted 87 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/