On 10/5/15 18:16, Eric Voit (evoit) wrote:
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.
Agreed.
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:"
Sure, that sounds better, but my contention here was the make explicit
that "fetch" meant to make these data available via the Subscription
Service itself. That is, define how one would fetch these data.
Joe
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
