Re: [Netconf] LC on subscribed-notifications-10

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

Hi Rob,

Reducing to the open dialogs...

> From: Robert Wilton, March 13, 2018 6:27 AM
> >> 2. Intro:
> >>    - Should security be somewhere in the intro section?
> > Do you see a particular need to emphasize security here?  Not sure why there
> should be a specific break-out here.
> Only to make it clear that it has been considered, and the draft provides a
> solution for it.

Inserted "and access permissions" in the second sentence to make it:

"Effectively this enables a "subscribe then publish" capability where the customized information needs and access permissions of each target receiver are understood by the publisher before subscribed event records are marshaled and pushed."

> >> - Steam: Is this really a set, or a sequence.  Perhaps ... "A
> >> continuous chronologically ordered sequence of events ..."?  If you
> >> change this, then perhaps grep for usage of "set" in the draft to see
> >> if they should be changed to sequence.
> > I like the addition of "chronologically", put that word in.  Regarding
> "sequence": with "ordered" we likely have that covered sufficiently.  Plus RFC-
> 5277 used  "set", so this is closer match to the original stream definition.
> I still strongly prefer calling it a sequence, because I think that is what it is :-)
>
> I quickly looked up a couple of definitions of stream in computer science
> literature and they all refer to them as sequences not sets.  Is the steam being
> referenced to this draft that same as what a normal software engineer would
> think of as a stream?
> 
> Is a stream ever allowed to contain duplicate values, e.g. on a replay it is
> possible to put the same events into the stream?

Event records are not be repeated on a subscription, even with replay.

>  If events are always unique
> then set is fine, otherwise set just seems like the incorrect term.

I really have no problem with "sequence".  The only issue is that we had requests from the original authors of RFC-5277 to keep the stream definition as close to the original as feasible.   If anyone else wants "sequence" and there are no objections, I am absolutely happy to convert.

> >> 8 2.4. Dynamic subscriptions
> >>
> >> - Would writing "event streams" be better than "targets"?
> > As dynamic subscriptions also apply to datastores (as augmented by yang-
> push), it is better to leave the more general term.
> OK, I think that I'm still struggling to create a good mental picture of how
> everything fits together.
> 
> I assumed that subscriptions only subscribe to event streams (e.g. from first
> sentence in section 1).  Hence, I was assuming that in the case of YANG push,
> that the change notifications to a datastore would effectively be a new event
> stream that could be subscribed to.  Are you saying that it is something
> else?  This might need to be clarified somewhere.

Actually what you were assuming was the original definition of "stream".  I.e., it was how stream was first defined in 2014 in yang-push up until -v04 in 2016.   But with the advent of NMDA, we wanted to adopt the definitions of "datastore" rather than create a mapping that forced the NMDA datastores to be associated 1:1 with stream names.

More is described in yang-push.  Note that In the yang module, target is a 'choice' statement with only a single case explored within subscribed-notifications.  So detailing in this document what is expressed as an actual choice in yang-push seemed confusing. 
 
> >
> >> - Diagram in 2.4.1, I found this diagram a bit tricky to read/interpret.  One
> >> particular question: Can you modify a subscription for a suspended receiver.
> > There is a line from receiver suspended for this, so yes.
> I think that I find it confusing as to what is an external event coming
> from a subscriber or receiver vs internal state changes.
> 
> OK, so I think that I have finally figured out what this diagram is
> meant to be showing :-)
> 
> Hence, I think that it might help to explicitly list the external events
> below the diagram:
> 
> - External events from a subscriber: establish-subscription,
> modify-subscription, ...

As each of these has its own section in the document, I am hesitant to add lots of verbal complexity to the diagram.  If other people think this would be helpful, it certainly could and should be added.

> - Internal states: start, receiver-ACTIVE, receiver-SUSPENDED, end.

In the text above the diagram, I added the sentence "Each state is shown in its own box".  Other text does describe the internal states.

> >> - The text mentions the publisher rejecting a subscription, when can this
> >> happen?
> > Actually it says "any" not "a".  The implication is that no other effects
> anywhere based on a rejected subscription request.  E.g., don't try to guess
> which subscription to delete.
> >
> > But there is still a case for "a".  What if a subscriber (with identical
> credentials) established the referenced subscription on a different transport
> session?  The delete still should not work unless it comes on the original
> transport.
> The first sentence of that paragraph already states that it is on the
> same transport session.  My interpretation of the current text is that a
> publisher can arbitrarily choose not to cancel a subscription.  I think
> that the text would be better if it was more explicit.
> 
> E.g. perhaps replace: " If the publisher rejects the request, the
>     request has no impact whatsoever on any subscription.
> 
> with something like:
> 
> "If the delete request does not match a known subscription id of a
> subscription established on the same transport session, then it MUST be
> rejected with no changes to the system".
 
Ok.  Made it:
If the delete request does not match a known subscription established on the same transport session, then it MUST be rejected with no changes to the publisher.

Thanks,
Eric

> > Appreciated, Thanks Again!
> > Eric
> Thanks,
> Rob