> 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 _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
