I'm reading through the latest draft, and I have a few questions/comments.
In section 3, could the Subscription Service be an external broker?
Said another way, it reads like the Subscription Service is/could be an
external entity. Is that the case, or will this always be a component
of the Publisher?
In section 4.2.2 regarding negotiation, it states that when negotiating
QoS, if the Subscription Service is unable to meet the request, it must,
"include in its decline a set of criteria that would have been
acceptable when the Subscription Request was made."
This got me thinking about future state. That is, let's say that as of
now I negotiate that I can do reaction time of T. But in an hour, due
to other things (maybe higher-priority work) I can only do T plus some
factor, X. The requirements in section 4.2.1 state that a Subscription
Service can terminate a Subscription at any time.
And as I read on, Section 4.2.3 describes what happens in the case of a
"breach of contract." Perhaps that paragraph needs to folded in to the
Negotiation section:
"When a Subscription Service is not able to send updates per its
subscription contract, the Subscription must notify subscribers and
put the subscription into a state of indicating the Subscription was
suspended by the service. When able to resume service, subscribers
need to be notified as well. If unable to resume service, the
Subscription Service may terminate the subscription and notify
Subscribers accordingly."
In section 4.2.5, is it needed to say that the mutual authn that exists
between Subscriber and Subscription Service take into account the
Publisher? That is, as a Subscriber I would want to ensure that a given
Subscription Service is actually providing data from a known, trusted
Publisher. I don't see any mention of Publishers in this section, and I
would think there should be some in the case where the Subscription
Service could be a broker.
I like the fact that you have section 4.2.8. It goes to the idea of
built-in serviceability. When you say, "fetch" is it envisioned that
this data is exposed through another Subscription Service, or will there
be other mechanisms to get at this?
Joe
On 10/2/15 15:08, [email protected] wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Interface to the Routing System Working
Group of the IETF.
Title : Requirements for Subscription to YANG Datastores
Authors : Eric Voit
Alexander Clemm
Alberto Gonzalez Prieto
Filename : draft-ietf-i2rs-pub-sub-requirements-03.txt
Pages : 17
Date : 2015-09-28
Abstract:
This document provides requirements for a service that allows client
applications to subscribe to updates of a YANG datastore. Based on
criteria negotiated as part of a subscription, updates will be pushed
to targeted recipients. Such a capability eliminates the need for
periodic polling of YANG datastores by applications and fills a
functional gap in existing YANG transports (i.e. Netconf and
Restconf). Such a service can be summarized as a "pub/sub" service
for YANG datastore updates. Beyond a set of basic requirements for
the service, various refinements are addressed. These refinements
include: periodicity of object updates, filtering out of objects
underneath a requested a subtree, and delivery QoS guarantees.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/
There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-i2rs-pub-sub-requirements-03
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-pub-sub-requirements-03
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
