Re: [i2rs] I-D Action: draft-ietf-i2rs-pub-sub-requirements-03.txt

["Eric Voit (evoit)" <[e-mail]>]

> From: Joe Clarke, October 05, 2015 5:27 PM
> 
> On 10/5/15 17:22, Eric Voit (evoit) wrote:
> 
> >
> > 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.
> 
> Nor do I.  I just asked the question to justify some of my other comments.
> 
> >
> > 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.
> 
> That would be ideal, but at its simplest, I am suggesting some of the wording in
> section 4.2.3 make it into the Negotiation section to be clear what would
> happen if negotiated attributes are no longer able to be maintained.

There will be multiple ways that a Subscription Update could fail to get pushed.  Examples could be based on Bandwidth, CPU, or flow control reasons.  Or it could be that someone put a huge set of data under a subtree which wasn't there during the establishment of the original subscription.   I wouldn't want to prohibit the sending of parameters which might result in a successful reinstatement on the subscription.  But I wouldn't mandate it either.

My suggestion is that there is the option to send suggested parameters.  But that we don't mandate this, nor which parameters may be sent.
 
> >
> > 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.
> 
> Works for me.  I just think that aspect of secure interactions needs to be called
> out.
> >
> > 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.
> 
> So did I.  I didn't think it was clear given the word "fetch."  Perhaps you should
> state that these data must be available via the subscription service.

"It must be possible to fetch a list and status of all Subscription Requests made over a period of time to a Subscription Service.    If a Subscription failed to establish or has been suspended, reasons must be provided.  Example reasons might include: "

Eric
 
> Joe