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

From: [email-masked]
Date: Fri, 02 Oct 2015 12:08:56 -0700

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/

---

From: Joe Clarke <[email-masked]>
Date: Mon, 5 Oct 2015 12:59:15 -0400

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?

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

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.

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?

Joe

On 10/2/15 15:08, [email-masked] wrote:
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 5 Oct 2015 21:22:18 +0000

Hi Joe,

-----Original Message-----
From: i2rs, October 05, 2015 12:59 PM

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:

<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-masked] wrote:
> 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.
>

---

From: Joe Clarke <[email-masked]>
Date: Mon, 5 Oct 2015 17:27:29 -0400

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

> <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 wo…

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.

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

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 5 Oct 2015 17:39:42 -0400

I think I am missing something in the discussion of this first point 
about separation.
While lots of implementation strategies are possible, the communication 
pattern I would anticipate for I2RS is that an I2RS client is 
communicating with an I2RS Agent who handles some piece(s) of 
information.  The client would send its subscription to that agent.  The 
client would expect the information resulting from its subscription to 
come back on a communications channel from the same entity.

So unless we add a lot of extra mechanisms to the protocol, I don't see 
how the effective manager of the subscription service for I2RS can be 
separate from the effective producer as seen by I2RS.

You can have brokers who accept subscriptions from multiple parties, 
subscribe on their own behalf to the I2RS agent, and then fan the 
results out to other parties.  But that would seem to represent a 
(legitimate) reuse of the subscription mechanism in a different context.

Yours,
Joel

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 5 Oct 2015 21:52:09 +0000

> From: Joel M. Halpern, October 05, 2015 5:40 PM
> 
> I think I am missing something in the discussion of this first point about
> separation.
> pattern I would anticipate for I2RS is that an I2RS client is communicating with
> an I2RS Agent who handles some piece(s) of information.  The client would send
> its subscription to that agent.  The client would expect the information resulting
> from its subscription to come back on a communications channel from the same
> entity.
> 
> So unless we add a lot of extra mechanisms to the protocol, I don't see how the
> effective manager of the subscription service for I2RS can be separate from the
> effective producer as seen by I2RS.

I agree with you.   I was trying to convey that I see no reason that the Requirements for the Subscription Service cannot be augmented (not changed) to allow for additional internal interface specifications.   

In this case, both incremental requirements and protocols would be needed.  There certainly wouldn't be one protocol.  I have no desire to pursue this myself.  Others might.

> You can have brokers who accept subscriptions from multiple parties, subscribe
> on their own behalf to the I2RS agent, and then fan the results out to other
> parties.  But that would seem to represent a

Yes.

Eric

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

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 5 Oct 2015 22:16:11 +0000

> From: Joe Clarke, October 05, 2015 5:27 PM
> 
> > 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:
> >
> > <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?
> 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

---

From: Joe Clarke <[email-masked]>
Date: Tue, 6 Oct 2015 09:04:35 -0400

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

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