Hi Joe,
-----Original Message-----
From: i2rs, October 05, 2015 12:59 PM
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?
<Eric> I don't know of any reason why the Subscription Service must 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."
<Eric> Yes, this is paragraph 3 of Section 4.2.3. I think you are suggesting
we make more robust error/informational codes for a Suspended subscription,
including giving parameters which might work to un-suspend. The Subscriber
could then attempt a "Modify Subscription" which would then have a chance to
bring things back to "Active". The hard part is knowing when to send these
parameters when a suspension is very temporary due to short during overload
conditions. This will be especially difficult as many subscriptions could be
suspended (and modifications synchronized) at the same time due to an transient
overload event.
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.
<Eric> This could be as simple as " Publisher and Subscription Service must
maintain a secure relationship". I have no problem adding that.
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?
<Eric> Why would this need to be a different Subscription Service? I
envisioned the same one.
Eric
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
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
