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

[Joe Clarke <[e-mail]>]

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.

>
> 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.

Joe