draft-ietf-i2rs-pub-sub-requirements-05.txt   draft-ietf-i2rs-pub-sub-requirements-06.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: August 6, 2016 Cisco Systems Expires: October 17, 2016 Cisco Systems
February 3, 2016 April 15, 2016
Requirements for Subscription to YANG Datastores Requirements for Subscription to YANG Datastores
draft-ietf-i2rs-pub-sub-requirements-05 draft-ietf-i2rs-pub-sub-requirements-06
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 August 6, 2016. This Internet-Draft will expire on October 17, 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
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Business Drivers . . . . . . . . . . . . . . . . . . . . . . 3 2. Business Drivers . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Pub/Sub in I2RS . . . . . . . . . . . . . . . . . . . . . 4 2.1. Pub/Sub in I2RS . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . 6 2.3. Existing Generalized Pub/Sub Implementations . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Assumptions for Subscriber Behavior . . . . . . . . . . . 8 4.1. Assumptions for Subscriber Behavior . . . . . . . . . . . 7
4.2. Subscription Service Requirements . . . . . . . . . . . . 8 4.2. Subscription Service Requirements . . . . . . . . . . . . 7
4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 8 4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 7
4.2.2. Negotiation . . . . . . . . . . . . . . . . . . . . . 10 4.2.2. Negotiation . . . . . . . . . . . . . . . . . . . . . 9
4.2.3. Update Distribution . . . . . . . . . . . . . . . . . 10 4.2.3. Update Distribution . . . . . . . . . . . . . . . . . 9
4.2.4. Transport . . . . . . . . . . . . . . . . . . . . . . 11 4.2.4. Transport . . . . . . . . . . . . . . . . . . . . . . 10
4.2.5. Security Requirements . . . . . . . . . . . . . . . . 11 4.2.5. Security Requirements . . . . . . . . . . . . . . . . 11
4.2.6. Subscription QoS . . . . . . . . . . . . . . . . . . 12 4.2.6. Subscription QoS . . . . . . . . . . . . . . . . . . 11
4.2.7. Filtering . . . . . . . . . . . . . . . . . . . . . . 13 4.2.7. Filtering . . . . . . . . . . . . . . . . . . . . . . 13
4.2.8. Assurance and Monitoring . . . . . . . . . . . . . . 14 4.2.8. Assurance and Monitoring . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
YANG has gained acceptance as the data definition language of choice Applications interacting with YANG datastores require capabilities
for control and management related information. Applications that beyond the traditional client-server configuration of network
interact with YANG datastores are extending beyond traditional elements. One class of such applications are service-assurance
configuration of network elements. In many cases these applications applications which must maintain a continuous view of operational
are aimed at service-assurance, which involves monitoring of data and state. Another class of applications are security
operational data and state. The existing YANG technology ecosystem applications which must continuously track changes made upon network
is proving insufficient for those applications due to: elements to ensure compliance to corporate policy.
o a reliance on RPC-style interactions where data is configured or
fetched on-demand by applications, and
o change notifications which identify a node associated with the
config change, without the actual data updates.
Put simply, 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. Trying to impose a polling-based solution to this problem state. Applying polling-based solutions here imposes load on
imposes load on networks, devices, and applications. Additionally, networks, devices, and applications. Additionally, polling solutions
polling solutions are brittle in the face of communication glitches, are brittle in the face of communication glitches, and have
and they have limitations in their ability to synchronize and limitations in their ability to synchronize and calibrate retrieval
calibrate retrieval intervals across a network. intervals across a network. These limitations can be addressed by
including generic object subscription mechanisms within Network
I2RS WG documents have expressed a need for more robust YANG object Elements, and allowing these mechanisms to be applied in the context
subscriptions. Similar discussions are underway in NETMOD and of data that is conceptually contained in YANG datastores.
NETCONF. With the support of standards bodies such as OMG (DDS),
XMPP.org standard, generic Publication/Subscription (Pub/Sub)
mechanisms to communicate data updates have been defined and proven
themselves in a wide variety of deployments.
It is time to incorporate such generic object subscription mechanisms
as part of Network Elements, and allow these mechanisms to be applied
in the context of data that is conceptually contained in YANG
datastores. With such mechanisms, applications on either a
controller or Network Element have access to a set of consistent
network information driven via push from peer Network Elements which
host authoritative information.
There are some valid IETF starting points and contexts for these
mechanisms. For example NETCONF Event Notifications [RFC5277]
provides a useful tool for an end-to-end solution. However RFC5277
does not follow the Pub/Sub paradigm, does not allow the explicit
deletion of subscriptions, and predates YANG. Predating YANG is an
issue, as monitoring and filtering based on YANG subtrees becomes
problematic. [RFC6470] defines configuration change notifications,
but does not provide the actual configuration change.
Because of this, the authors have put forward this requirement This document aggregates requirements for such subscription from a
document as well as [datastore-push]. We believe these provide a variety of deployment scenarios.
context upon which to create new solutions. It is intended that
these documents include requirements and provide technologies
applicable beyond I2RS.
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 SDN, dedicated, customized networking protocols. With the growth of
imperative policy distribution, and YANG's ascent as a dominant centralized orchestration infrastructures, imperative policy
programmatic interface to network elements, this mixture of fetch distribution, and YANG's ascent as the dominant data modeling
plus custom networking protocols is no longer sufficient. What is language for use in programmatic interfaces to network elements, this
needed is a push mechanism that is able to deliver objects and object mixture of fetch plus custom networking protocols is no longer
changes as they happen. sufficient. What is needed is a push mechanism that is able to
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.
At the same time, SNMP and MIBs are still widely deployed and the Push solutions will not displace all existing operations
defacto choice for many monitoring solutions. Those solutions do not infrastructure needs. And SNMP and MIBs will remain widely deployed
require support for configuration transactions and the need to and the defacto choice for many monitoring solutions. But some
validate and maintain configuration consistency, hence there is less functions could be displaced. Arguably the biggest shortcoming of
pressure to abandon SNMP and MIBs. Arguably the biggest shortcoming SNMP for those applications concerns the need to rely on periodic
of 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 additional load on the network and
devices, is brittle in case polling cycles are missed, and is hard to devices, because it is brittle in case polling cycles are missed, and
synchronize and calibrate across a network, making data obtained from because is hard to synchronize and calibrate across a network. If
multiple devices less comparable. If applications need to apply applications can only use polling type interaction patterns with YANG
those same interaction patterns for YANG datastores, similar issues datastores, similar issues can be expected.
can be expected. Migration to YANG datastores by applications that
do not have to worry about transactional integrity becomes a lot more
compelling if those issues are addressed.
2.1. Pub/Sub in I2RS 2.1. Pub/Sub in I2RS
Various I2RS documents highlight the need to provide Pub/Sub Various I2RS documents highlight the need to provide Pub/Sub
capabilities between network elements. From [i2rs-arch], there are capabilities between network elements. From [i2rs-arch], there are
references throughout the document beginning in section 6.2. Some references throughout the document beginning in section 6.2. Some
specific examples include: specific examples include:
o section 7.6 provides high level pub/sub (notification) guidance o section 7.6 provides high level pub/sub (notification) guidance
o section 6.4.2 identifies "subscribing to an information stream of o section 6.4.2 identifies "subscribing to an information stream of
route changes receiving notifications about peers coming up or route changes receiving notifications about peers coming up or
going down" going down"
o section 6.3 notes that when local config preempts I2RS, external o section 6.3 notes that when local config preempts I2RS, external
notification might be necessary notification might be necessary
In addition [i2rs-usecase] has relevant requirements. A small subset In addition [i2rs-usecase] has relevant requirements. A small subset
includes: includes:
skipping to change at page 5, line 45 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 very small subset of Switches and Routers are being specified now. A small subset of
these includes: current and past subscriptions includes:
o Routing Adjacencies in MPLS VPNs [RFC6513]
o OSPF Route Flooding [RFC2328] o Multicast topology establishment is accomplished before any
content delivery is made to endpoints (IGMP, PIM, etc.)
o Multicast topology establishment protocols (IGMP, PIM, etc.) o Secure Automation and Continuous Monitoring (SACM) allows
o Audio-Video Bridging streams needing guaranteed latency subscription into devices which then may push spontaneous changes
[AVB-latency] (802.1Q-2011 Clause 35) in their configured hardware and software[sacm-requirements]
o Secure Automation and Continuous Monitoring (SACM) o In MPLS VPNs [RFC6513] a Customer Edge router exchanges PIM
[sacm-requirements] control messages before PE Routing Adjacencies are passed.
[RFC6513]
o "Peer Mount" subscriptions for configuration verification between o After OSPF establishes its adjacencies, Link State Advertisement
peers[draft-voit-netmod] will then commence [RFC2328]
Worthy of note in the list above is the wide variety of broadcast, Worthy of note in the examples above is the wide variety of
multicast, and unicast transports used. In addition some transports underlying transports. A generalized Pub/Sub mechanism therefore
are at L3, and some at L2. Therefore if we are going to attempt a should be structured to support alternative transports. Based on
generic Pub/Sub mechanism, it will need to be structured so that it current I2RS requirements, NETCONF should the initially supported
may support alternative transports. Looking at the nearer term based transport based on the need for connection-oriented/unicast
on current I2RS requirements, NETCONF should be our transport communication. Eventual support Multicast and Broadcast subscription
starting point as it supports connection-oriented/unicast update distribution will be needed as well.
communication. But we need to be prepared to decouple where viable
to support Multicast and Broadcast distribution as well.
2.3. Existing Generalized Pub/Sub Implementations 2.3. Existing Generalized Pub/Sub Implementations
TIBCO, RSS, CORBA, and other technologies all show precursor Pub/Sub TIBCO, RSS, CORBA, and other technologies all show precursor Pub/Sub
technologies. However there are new needs described in Section 4 technologies. However there are new needs described in Section 4
below which these technologies do not serve. We need a 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 7, line 18 skipping to change at page 6, line 28
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) made by the Subscriber of a Publisher and targeted to a single leafs) is made by the Subscriber of a Publisher and is
Receiver. A Subscription may include constraints which dictate how targeted to a Receiver. A Subscription may include constraints which
often or under what conditions YANG information updates might be dictate how often or under what conditions YANG information updates
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 YANG datastore is a conceptual datastore that contains hierarchical
data defined in YANG data models. It is what is referred in existing data defined in YANG data models. It is what is referred in existing
RFCs as "NETCONF datastore". However, as the same datastore is no RFCs as "NETCONF datastore". However, as the same datastore is no
longer tied to NETCONF as a specific transport, the term "YANG longer tied to NETCONF as a specific transport, the term "YANG
datastore" is deemed more appropriate. datastore" is deemed more appropriate.
skipping to change at page 10, line 15 skipping to change at page 9, line 22
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 of 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
skipping to change at page 15, line 27 skipping to change at page 14, line 37
suggestions that were received from Ambika Tripathy and Prabhakara suggestions that were received from Ambika Tripathy and Prabhakara
Yellai as well as the helpfulness of related end-to-end system Yellai as well as the helpfulness of related end-to-end system
context info from Nancy Cam Winget, Ken Beck, and David McGrew. context info from Nancy Cam Winget, Ken Beck, and David McGrew.
8. References 8. References
8.1. Normative References 8.1. Normative References
[i2rs-arch] [i2rs-arch]
Atlas, A., "An Architecture for the Interface to the Atlas, A., "An Architecture for the Interface to the
Routing System", December 2015, Routing System", February 2016,
<https://datatracker.ietf.org/doc/draft-ietf-i2rs- <https://datatracker.ietf.org/doc/draft-ietf-i2rs-
architecture/>. architecture/>.
[i2rs-traceability] [i2rs-traceability]
Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to
the Routing System (I2RS) Traceability: Framework and the Routing System (I2RS) Traceability: Framework and
Information Model", December 2015, Information Model", February 2016,
<https://datatracker.ietf.org/doc/draft-ietf-i2rs- <https://datatracker.ietf.org/doc/draft-ietf-i2rs-
traceability/>. 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>.
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event
Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008,
<http://www.rfc-editor.org/info/rfc5277>.
[RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF)
Base Notifications", RFC 6470, DOI 10.17487/RFC6470,
February 2012, <http://www.rfc-editor.org/info/rfc6470>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <http://www.rfc-editor.org/info/rfc6513>. 2012, <http://www.rfc-editor.org/info/rfc6513>.
8.2. Informative References 8.2. Informative References
[AVB-latency]
Jeffree, T., "802.1Qav - Forwarding and Queuing
Enhancements for Time-Sensitive Streams", December 2009,
<http://www.ieee802.org/1/pages/802.1av.html>.
[datastore-push]
Clemm, A., Gonzalez Prieto, A., and E. Voit, "Subscribing
to datastore push updates", October 2015,
<https://tools.ietf.org/html/draft-clemm-netconf-yang-
push-02>.
[draft-voit-netmod]
Voit, E., "Requirements for Peer Mounting of YANG subtrees
from Remote Datastores", September 2015,
<https://tools.ietf.org/html/draft-voit-netmod-peer-mount-
requirements-03>.
[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", November 2015, Requirements", March 2016,
<https://datatracker.ietf.org/doc/draft-ietf-i2rs-usecase- <https://datatracker.ietf.org/doc/draft-ietf-i2rs-usecase-
reqs-summary/>. reqs-summary/>.
[OMG-DDS] "Data Distribution Service for Real-time Systems, version [OMG-DDS] "Data Distribution Service for Real-time Systems, version
1.2", January 2007, <http://www.omg.org/spec/DDS/1.2/>. 1.2", January 2007, <http://www.omg.org/spec/DDS/1.2/>.
[sacm-requirements] [sacm-requirements]
Cam Winget, N., "Secure Automation and Continuous Cam Winget, N., "Secure Automation and Continuous
Monitoring (SACM) Requirements", July 2015, Monitoring (SACM) Requirements", March 2016,
<https://tools.ietf.org/html/draft-ietf-sacm-requirements- <https://tools.ietf.org/html/draft-ietf-sacm-requirements-
09>. 09>.
[XEP-0060] [XEP-0060]
Millard, P., "XEP-0060: Publish-Subscribe", July 2010, Millard, P., "XEP-0060: Publish-Subscribe", July 2010,
<XEP-0060: Publish-Subscribe>. <XEP-0060: Publish-Subscribe>.
Authors' Addresses Authors' Addresses
Eric Voit Eric Voit
 End of changes. 30 change blocks. 
145 lines changed or deleted 84 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/