draft-ietf-i2rs-pub-sub-requirements-09.txt   rfc7923.txt 
Interface to the Routing System (i2rs) E. Voit Internet Engineering Task Force (IETF) E. Voit
Internet-Draft A. Clemm Request for Comments: 7923 A. Clemm
Intended status: Informational A. Gonzalez Prieto Category: Informational A. Gonzalez Prieto
Expires: November 18, 2016 Cisco Systems ISSN: 2070-1721 Cisco Systems
May 17, 2016 June 2016
Requirements for Subscription to YANG Datastores Requirements for Subscription to YANG Datastores
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., Network
Restconf). Such a service can be summarized as a "pub/sub" service Configuration Protocol (NETCONF) and RESTCONF). Such a service can
for YANG datastore updates. Beyond a set of basic requirements for be summarized as a "pub/sub" service for YANG datastore updates.
the service, various refinements are addressed. These refinements Beyond a set of basic requirements for the service, various
include: periodicity of object updates, filtering out of objects refinements are addressed. These refinements include: periodicity of
underneath a requested a subtree, and delivery QoS guarantees. object updates, filtering out of objects underneath a requested a
subtree, and delivery QoS guarantees.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on November 18, 2016. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7923.
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
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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction ....................................................3
2. Business Drivers . . . . . . . . . . . . . . . . . . . . . . 3 2. Business Drivers ................................................3
2.1. Pub/Sub in I2RS . . . . . . . . . . . . . . . . . . . . . 3 2.1. Pub/Sub in the Interface to the Routing System (I2RS) ......4
2.2. Pub/Sub Variants on Network Elements . . . . . . . . . . 5 2.2. Pub/Sub Variants on Network Elements .......................5
2.3. Existing Generalized Pub/Sub Implementations . . . . . . 5 2.3. Existing Generalized Pub/Sub Implementations ...............6
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 ..........................8
4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 7 4.2.1. General .............................................8
4.2.2. Negotiation . . . . . . . . . . . . . . . . . . . . . 9 4.2.2. Negotiation .........................................9
4.2.3. Update Distribution . . . . . . . . . . . . . . . . . 9 4.2.3. Update Distribution ................................10
4.2.4. Transport . . . . . . . . . . . . . . . . . . . . . . 10 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 ...................................13
4.2.7. Filtering . . . . . . . . . . . . . . . . . . . . . . 13 4.2.7. Filtering ..........................................14
4.2.8. Assurance and Monitoring . . . . . . . . . . . . . . 14 4.2.8. Assurance and Monitoring ...........................15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5. Security Considerations ........................................15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. References .....................................................16
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 6.1. Normative References ......................................16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.2. Informative References ....................................16
8.1. Normative References . . . . . . . . . . . . . . . . . . 15 Acknowledgments ...................................................17
8.2. Informative References . . . . . . . . . . . . . . . . . 16 Authors' Addresses ................................................18
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 with corporate policy.
Periodic fetching of data is not an adequate solution for 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. Applying polling-based solutions here imposes load on state. Applying polling-based solutions here imposes a load on
networks, devices, and applications. Additionally, polling solutions networks, devices, and applications. Additionally, polling solutions
are brittle in the face of communication glitches, and have are brittle in the face of communication glitches, and have
limitations in their ability to synchronize and calibrate retrieval limitations in their ability to synchronize and calibrate retrieval
intervals across a network. These limitations can be addressed by intervals across a network. These limitations can be addressed by
including generic object subscription mechanisms within Network including generic object subscription mechanisms within network
Elements, and allowing these mechanisms to be applied in the context elements, and allowing these mechanisms to be applied in the context
of data that is conceptually contained in YANG datastores. of data that is conceptually contained in YANG datastores.
This document aggregates requirements for such subscription from a This document aggregates requirements for such subscription from a
variety of deployment scenarios. variety of deployment scenarios.
2. Business Drivers 2. Business Drivers
For decades, information delivery of current network state has been For decades, information delivery of current network state has been
accomplished either by fetching from operations interfaces, or via accomplished either by fetching from operations interfaces, or via
dedicated, customized networking protocols. With the growth of dedicated, customized networking protocols. With the growth of
skipping to change at page 3, line 34 skipping to change at page 3, line 48
sufficient. What is needed is a push mechanism that is able to sufficient. What is needed is a push mechanism that is able to
deliver object changes as they happen. deliver object changes as they happen.
These push distribution mechanisms will not replace existing These push distribution mechanisms will not replace existing
networking protocols. Instead they will supplement these protocols, networking protocols. Instead they will supplement these protocols,
providing different response time, peering, scale, and security providing different response time, peering, scale, and security
characteristics. characteristics.
Push solutions will not displace all existing operations Push solutions will not displace all existing operations
infrastructure needs. And SNMP and MIBs will remain widely deployed infrastructure needs. And SNMP and MIBs will remain widely deployed
and the defacto choice for many monitoring solutions. But some and the de facto choice for many monitoring solutions. But some
functions could be displaced. Arguably the biggest shortcoming of functions could be displaced. Arguably the biggest shortcoming of
SNMP for those applications concerns the need to rely on periodic SNMP for those applications concerns the need to rely on periodic
polling, because it introduces additional load on the network and polling, because it introduces an additional load on the network and
devices, because it is brittle in case polling cycles are missed, and devices, because it is brittle if polling cycles are missed, and
because is hard to synchronize and calibrate across a network. If because it is hard to synchronize and calibrate across a network. If
applications can only use polling type interaction patterns with YANG applications can only use polling type interaction patterns with YANG
datastores, similar issues can be expected. datastores, similar issues can be expected.
2.1. Pub/Sub in I2RS 2.1. Pub/Sub in the Interface to the Routing System (I2RS)
Various I2RS documents highlight the need to provide Pub/Sub Various documents about the Interface to the Routing System (I2RS)
capabilities between network elements. From [i2rs-arch], there are highlight the need to provide pub/sub capabilities between network
references throughout the document beginning in section 6.2. Some elements. From [RFC7921], there are references throughout the
specific examples include: document beginning in Section 6.2. Some specific examples include:
o section 7.6 provides high level pub/sub (notification) guidance o Section 7.6 of [RFC7921] provides high-level pub/sub
o section 6.4.2 identifies "subscribing to an information stream of (notification) guidance.
route changes receiving notifications about peers coming up or
going down"
o section 6.3 notes that when local config preempts I2RS, external o Section 6.4.2 of [RFC7921] identifies "subscribing to an
notification might be necessary information stream of route changes" and "receiving notifications
about peers coming up or going down".
In addition [i2rs-usecase] has relevant requirements. A small subset o Section 6.3 of [RFC7921] notes that when Local Configuration
preempts I2RS, external notification might be necessary.
In addition, [USECASE] has relevant requirements. A small subset
includes: includes:
o L-Data-REQ-12: The I2RS interface should support user o L-Data-REQ-12: The I2RS interface should support user
subscriptions to data with the following parameters: push of data subscriptions to data with the following parameters: push of data
synchronously or asynchronously via registered subscriptions... synchronously or asynchronously via registered subscriptions...
o L-DATA-REQ-07: The I2RS interface (protocol and IMs) should allow o L-DATA-REQ-07: The I2RS interface (protocol and instant messages
a subscriber to select portions of the data model. (IMs)) should allow a subscriber to select portions of the data
model.
o PI-REQ01: monitor the available routes installed in the RIB of o PI-REQ01: Monitor the available routes installed in the Routing
each forwarding device, including near real time notification of Information Base (RIB) of each forwarding device, including near
route installation and removal. real-time notification of route installation and removal.
o BGP-REQ10: I2RS client should be able to instruct the I2RS o BGP-REQ10: The I2RS client SHOULD be able to instruct the I2RS
agent(s) to notify the I2RS client when the BGP processes on an agent(s) to notify the I2RS client when the BGP processes on an
associated routing system observe a route change to a specific set associated routing system observe a route change to a specific set
of IP Prefixes and associated prefixes....The I2RS agent should be of IP Prefixes and associated prefixes.... The I2RS agent should
able to notify the client via publish or subscribe mechanism. be able to notify the client via the publish or subscribe
mechanism.
o IGP-REQ-07: The I2RS interface (protocol and IMs) should support a o IGP-REQ-07: The I2RS interface (protocol and IMs) should support a
mechanism where the I2RS Clients can subscribe to the I2RS Agent's mechanism where the I2RS Clients can subscribe to the I2RS Agent's
notification of critical node IGP events. notification of critical node IGP events.
o MPLS-LDP-REQ-03: The I2RS Agent notifications should allow an I2RS o MPLS-LDP-REQ-03: The I2RS Agent notifications should allow an I2RS
client to subscribe to a stream of state changes regarding the LDP client to subscribe to a stream of state changes regarding the LDP
sessions or LDP LSPs from the I2RS Agent. sessions or LDP Label Switched Paths (LSPs) from the I2RS Agent.
o L-Data-REQ-01: I2rs must be able to collect large data set from o L-Data-REQ-01: I2RS must be able to collect large data sets from
the network with high frequency and resolution with minimal impact the network with high frequency and resolution, and with minimal
to the device's CPU and memory. impact to the device's CPU and memory.
And [i2rs-traceability] has Pub/Sub requirements listed in Also, Section 7.4.3 of [RFC7922] includes this pub/sub requirement:
Section 7.4.3.
o I2RS Agents should support publishing I2RS trace log information o I2RS agents MUST support publishing I2RS trace log information to
to that feed as described in [i2rs-arch]. Subscribers would then that feed as described in [this document]. 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.
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 that 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 that 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 subscription mechanisms 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 may then push spontaneous changes
in their configured hardware and software[sacm-requirements] in their configured hardware and software [SACMREQ].
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 Provider Edge (PE) Routing Adjacencies are
[RFC6513] passed [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 be the initially supported current I2RS requirements, NETCONF should be the initially supported
transport based on the need for connection-oriented/unicast transport due to the need for connection-oriented/unicast
communication. Eventual support for multicast and broadcast communication. Eventual support for multicast and broadcast
subscription 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, Common Object Request Broker Architecture (CORBA), and
technologies. However there are new needs described in Section 4 other technologies all show precursor pub/sub technologies. However,
below which these technologies do not serve. We need a new pub-sub there are new needs (described in Section 4 below) that these
technology. 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 that come close to current needs: Extensible
DDS[OMG-DDS]. Both serve as proof-points that a highly scalable Messaging and Presence Protocol (XMPP) [XEP-0060] and Data
distributed datastore implementation connecting millions of edge Distribution Service (DDS) [OMG-DDS]. Both serve as proof-points
devices is possible. that a highly scalable distributed datastore implementation
connecting millions of edge 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
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]. Although document are to be interpreted as described in [RFC2119]. Although
this document is not a protocol specification, the use of this this document is not a protocol specification, the use of this
language clarifies the instructions to protocol designers producing language clarifies the instructions to protocol designers producing
solutions that satisfy the requirements set out in this document. 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
data. data.
A Subscription Service interacts with the Publisher of the YANG data A Subscription Service interacts with the Publisher of the YANG data
as needed to provide the data per the terms of the Subscription. as needed to provide the data per the terms of the subscription.
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 that
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 datastore is defined in [RFC6241]. A datastore is defined in [RFC6241].
An Update provides object changes which have occurred within An Update provides object changes that 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 for which filtering has indicated
reportably different from the previously provided state. An Update they have different status than previously provided. An Update may
may include a bundled set of ordered/sequential changes for a given include a bundled set of ordered/sequential changes for a given
object that 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 element and attribute published under a target data node, and object element and attribute
Filters where an object should only be published if it has properties Filters where an object should only be published if it has properties
meeting specified Filter criteria. meeting specified Filter criteria.
4. Requirements 4. Requirements
Many of the requirements within this section have been adapted from Many of the requirements within this section have been adapted from
XMPP[XEP-0060] and DDS[OMG-DDS] requirements specifications. the 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 and Receiver are the same entity and the transport When a Subscriber and Receiver are the same entity and the transport
session is lost/terminated, the Subscriber MUST reestablish any session is lost/terminated, the Subscriber MUST re-establish any
subscriptions it previously created via signalling over the transport subscriptions it previously created via signaling over the transport
session. I.e., There is no requirement for the life span of such session. That is, there is no requirement for the life span of such
signaled Subscriptions extend beyond the life span of the transport signaled subscriptions to extend beyond the life span of the
session. 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
of 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. time out, 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 multiple 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 subscriptions to multiple YANG subtrees as part of the same of subscriptions to multiple YANG subtrees as part of the same
Subscription 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 filtering so that A Subscription Service MUST be able support filtering so that the
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 be passed before the first or
"on-change" updates are sent. The dampening period SHOULD be subsequent on-change updates are sent. The dampening period SHOULD
configurable as part of the subscription request. be 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 MUST support terminating of a Subscription A Subscription Service MUST support the termination 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 command-line
interface (CLI), and/or others. When this occurs, the Subscription
When this occurs, the Subscription Service MUST notify the Subscriber Service MUST notify the Subscriber and update the subscription
and update subscription status. 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 on-change policy dampening period (if the on-change policy is o The on-change policy dampening period (if the on-change policy is
supported) 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 due to In cases where a subscription request cannot be fulfilled due to
insufficient platform resources, the Subscription Service SHOULD insufficient platform resources, the Subscription Service SHOULD
include within its decline hints on criteria that would have been include within its decline hints on criteria that would have been
acceptable when the Subscription Request was made. For example, if acceptable when the subscription request was made. For example, if
periodic updates were requested with too short update intervals for periodic updates were requested with update intervals that were too
the specified data set, an alternative acceptable interval period short for the specified data set, an alternative acceptable interval
might be returned from the Publisher. If on-change updates were period might be returned from the Publisher. If on-change updates
requested with too-aggressive a dampening period, then an acceptable were requested with too aggressive a dampening period, then an
dampening period may be returned, or alternatively an indication that acceptable dampening period may be returned, or alternatively an
only periodic updates are supported for the requested object(s). indication that 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
deltas to the object data for which a change occurred. [Otherwise to the object data for which a change occurred. (Otherwise the
the subscriber might not know what has actually undergone change.] subscriber might not know what has actually undergone change.) The
The updates for each object MUST include an indication whether it was updates for each object MUST include an indication of 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
subscription contract, the Subscription MUST notify subscribers and subscription contract, the subscription MUST notify subscribers and
put the subscription into a state indicating the Subscription was put the subscription into a state indicating that the subscription
suspended by the service. When able to resume service, subscribers was suspended by the service. When able to resume service,
need to be notified as well. If unable to resume service, the subscribers need to be notified as well. If unable to resume
Subscription Service MAY terminate the subscription and notify service, the Subscription Service MAY terminate the subscription and
Subscribers accordingly. notify 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 replay capability A Subscription Service MAY, as an option, support a replay capability
so that a set of updates generated during a previous time internal so that a set of updates generated during a previous time internal
can be sent to a Receiver. can be sent to a Receiver.
4.2.4. Transport 4.2.4. Transport
It is possible for updates coming from a Subscription Service to be It is possible for updates coming from a Subscription Service to be
pushed over different types of transports such as NETCONF, RESTCONF, pushed over different types of transports such as NETCONF, RESTCONF,
and HTTP. Beyond existing transports, this Subsription Service will and HTTP. Beyond existing transports, this Subscription Service will
applicable for emerging protocols such as those being defined in be applicable for emerging protocols such as those being defined in
[i2rs-usecase]. The need for such transport flexibility drives the [USECASE]. The need for such transport flexibility drives the
following requirements. following requirements:
A Subscription Service SHOULD support different transports. o A Subscription Service SHOULD support different transports.
A Subscription Service SHOULD support different encodings of payload. o A Subscription Service SHOULD support different encodings of a
payload.
It MUST be possible for Receivers to associate the update with a o 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 o 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
It is up the Subscriber to request a new Subscription. terminated. 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. For privacy-sensitive deployments, updates and metadata. For privacy-sensitive deployments,
subscription information MUST be bound within secure, encrypted subscription information MUST be bound within secure, encrypted
transport layer mechanisms. For example if NETCONF is used as transport-layer mechanisms. For example, if NETCONF is used as
transport, then [RFC5539] would be a valid option to secure the transport, then [RFC7589] would be a valid option to secure the
transported information. The Subscription Service can also be used transported information. The Subscription Service can also be used
with emerging privacy-sensitive deployment contexts as well. As an with emerging privacy-sensitive deployment contexts as well. As an
example, deployments based on [i2rs-usecase] would apply these example, deployments based on [USECASE] would apply these
requirements in conjunction with those documented within requirements in conjunction with those documented within
[i2rs-environment-security] and [i2rs-protocol-security] to secure [I2RS-ENV-SEC] and [I2RS-PROT-SEC] to secure ephemeral state
ephemeral state information being pushed from a Network Element. information being pushed from a network element.
As part of the Subscription establishment, mutual authentication MUST As part of the subscription establishment, mutual authentication MUST
be used between the Subscriber and the Subscription Service. be used between the Subscriber and the Subscription Service.
Subscribers MUST NOT be able to pose as the original Subscription Subscribers MUST NOT be able to pose as the original Subscription
Service. 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 being pushed based on subscriptions is authorized in the
that regular data retrieval operations are authorized. Data being same way that regular data retrieval operations are authorized. Data
pushed to a client MUST be filtered accordingly, just like if the being pushed to a client MUST be filtered accordingly, just like if
data were being retrieved on-demand. For Unicast transports, the 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 target subtree or node SHOULD be A loss of authenticated access to the target subtree or node SHOULD
communicated to the Subscriber. be communicated to the Subscriber.
For any encrypted information exchanges, commensurate strength For any encrypted information exchanges, commensurate strength
security mechanisms MUST be available and SHOULD be used. This security mechanisms MUST be available and SHOULD be used. This
includes all stages of the Subscription and update push process. 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
terminate it prematurely later. terminate it prematurely later.
When the Subscriber and Receiver are different, and when the When the Subscriber and Receiver are different, and when the
underlying transport connection passes credentials as part of underlying transport connection passes credentials as part of
transport establishment, then potentially pushed objects MUST be transport establishment, then potentially pushed objects MUST be
excluded from a push update if that object doesn't have read access excluded from a push update if that object doesn't have read access
visibility for that the Receiver. visibility for that 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 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.
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
For a particular Subscription, every update to a subscribed object For a particular subscription, every update to a subscribed object
MUST be sent to the Receiver in sequential order. MUST be sent to the Receiver in sequential order.
4.2.6.5. Presentation 4.2.6.5. Presentation
The Subscription Service MAY have the ability to bundle a set of The Subscription Service MAY 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 the Subscriber's specified start and
timestamps. (Note: the regular cadence can drive one, a discrete end timestamps. (Note: the regular cadence can drive one update, a
quantity, or an unbounded set of periodic updates.) discrete quantity of updates, 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.6.8. Relative Priority 4.2.6.8. Relative Priority
The Subscription Service SHOULD support the relative prioritization The Subscription Service SHOULD support the relative prioritization
of Subscriptions so that dequeuing and discarding of push updates can of subscriptions so that the dequeuing and discarding of push updates
consider this if there is insufficient bandwidth between Publisher can consider this if there is insufficient bandwidth between the
and Receiver. Publisher and the Receiver.
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 the corresponding object(s)
Subscription. within a subscription.
It MUST be possible to attach one or more Subtree and/or object It MUST be possible to attach one or more Subtree and/or object
element and attribute Filters to a subscription. Mandatory Filter element and attribute Filters to a subscription. Mandatory Filter
types include: types include:
o For character-based object properties, Filter values which are o For character-based object properties, Filter values that 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 object properties, Filter values that are =, !=, <,
!=, <, <=, >, >= a provided number. <=, >, or >= a provided number.
It SHOULD be possible for Filtering criteria to evaluate more than It SHOULD be possible for Filtering criteria to evaluate more than
one property of a particular subscribed object as well as apply one property of a particular subscribed object as well as apply
multiple Filters against a single object. 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 Filtering criteria on a objects to be used in conjunction with Filtering criteria on a
subscribed object. (For example: if A has changed and B=1, then Push subscribed object. (For example, if A has changed and B=1, then 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 that the subscriber has read
to those objects. access to those objects.
For on-change subscription updates, an object MUST pass a Filter For on-change subscription updates, an object MUST pass a Filter
through a Filter if it has changed since the previous update. This through a Filter if it has changed since the previous update. This
includes if the object has changed multiple times since the last 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 update, and if the value happens to be the exact same value as the
one sent. 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 is a failure, some failure requests over a period of time. If there is a failure, some failure
reasons might 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.
5. Security Considerations 5. Security Considerations
There are no additional security considerations beyond the There are no additional security considerations beyond the
requirements listed in Section 4.2.5. requirements listed in Section 4.2.5.
6. IANA Considerations 6. References
This document has no actions for IANA.
7. Acknowledgments
We wish to acknowledge the helpful contributions, comments, and
suggestions that were received from Ambika Tripathy and Prabhakara
Yellai as well as the helpfulness of related end-to-end system
context info from Nancy Cam Winget, Ken Beck, and David McGrew.
8. References
8.1. Normative References
[i2rs-arch]
Atlas, A., "An Architecture for the Interface to the
Routing System", February 2016,
<https://datatracker.ietf.org/doc/draft-ietf-i2rs-
architecture/>.
[i2rs-traceability] 6.1. Normative References
Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to
the Routing System (I2RS) Traceability: Framework and
Information Model", February 2016,
<https://datatracker.ietf.org/doc/draft-ietf-i2rs-
traceability/>.
[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>.
[RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)",
RFC 5539, DOI 10.17487/RFC5539, May 2009,
<http://www.rfc-editor.org/info/rfc5539>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
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 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the
NETCONF Protocol over Transport Layer Security (TLS) with
Mutual X.509 Authentication", RFC 7589,
DOI 10.17487/RFC7589, June 2015,
<http://www.rfc-editor.org/info/rfc7589>.
[i2rs-environment-security] [RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
Migault, D., Halpern, J., and S. Hares, "I2RS Environment Nadeau, "An Architecture for the Interface to the Routing
Security Requirements", April 2016, System", RFC 7921, DOI 10.17487/RFC7921, June 2016,
<https://datatracker.ietf.org/doc/draft-ietf-i2rs- <http://www.rfc-editor.org/info/rfc7921>.
security-environment-reqs/>.
[i2rs-protocol-security] [RFC7922] Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to
the Routing System (I2RS) Traceability: Framework and
Information Model", RFC 7922, DOI 10.17487/RFC7922, June
2016, <http://www.rfc-editor.org/info/rfc7922>.
6.2. Informative References
[I2RS-ENV-SEC]
Migault, D., Ed., Halpern, J., and S. Hares, "I2RS
Environment Security Requirements", Work in Progress,
draft-ietf-i2rs-security-environment-reqs-01, April 2016.
[I2RS-PROT-SEC]
Hares, S., Migault, D., and J. Halpern, "I2RS Security Hares, S., Migault, D., and J. Halpern, "I2RS Security
Related Requirements", May 2016, Related Requirements", Work in Progress, draft-ietf-i2rs-
<https://datatracker.ietf.org/doc/draft-ietf-i2rs- protocol-security-requirements-06, May 2016.
protocol-security-requirements/>.
[i2rs-usecase] [OMG-DDS] Object Management Group (OMG), "Data Distribution Service
Hares, S. and M. Chen, "Summary of I2RS Use Case for Real-time Systems, Version 1.2", January 2007,
Requirements", March 2016, <http://www.omg.org/spec/DDS/1.2/>.
<https://datatracker.ietf.org/doc/draft-ietf-i2rs-usecase-
reqs-summary/>.
[OMG-DDS] "Data Distribution Service for Real-time Systems, version [SACMREQ] Nancy, N. and L. Lorenzin, "Security Automation and
1.2", January 2007, <http://www.omg.org/spec/DDS/1.2/>. Continuous Monitoring (SACM) Requirements", Work in
Progress, draft-ietf-sacm-requirements-13, March 2016.
[sacm-requirements] [USECASE] Hares, S. and M. Chen, "Summary of I2RS Use Case
Cam Winget, N., "Secure Automation and Continuous Requirements", Work in Progress, draft-ietf-i2rs-usecase-
Monitoring (SACM) Requirements", March 2016, reqs-summary-02, March 2016.
<https://tools.ietf.org/html/draft-ietf-sacm-requirements-
09>.
[XEP-0060] [XEP-0060] Millard, P., Saint-Andre, P., and R. Meijer, "Publish-
Millard, P., "XEP-0060: Publish-Subscribe", July 2010, Subscribe", XSF XEP-0060, July 2010,
<XEP-0060: Publish-Subscribe>. <http://xmpp.org/extensions/xep-0060.html>.
Acknowledgments
We wish to acknowledge the helpful contributions, comments, and
suggestions that were received from Ambika Tripathy and Prabhakara
Yellai as well as the helpfulness of related end-to-end system
context info from Nancy Cam Winget, Ken Beck, and David McGrew.
Authors' Addresses Authors' Addresses
Eric Voit Eric Voit
Cisco Systems Cisco Systems
Email: evoit@cisco.com Email: evoit@cisco.com
Alexander Clemm Alexander Clemm
Cisco Systems Cisco Systems
Email: alex@cisco.com Email: alex@cisco.com
Alberto Gonzalez Prieto Alberto Gonzalez Prieto
Cisco Systems Cisco Systems
Email: albertgo@cisco.com Email: albertgo@cisco.com
 End of changes. 124 change blocks. 
293 lines changed or deleted 291 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/