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

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

> From: Kent Watsen, July 6, 2018 5:05 PM
> 
> <Kent14>
> 
> <Eric13> Per this thread, this is now a configured-replay empty object (rather
> than a start-time).  This empty object simply tells the publisher to push off all
> events retained from a stream since reboot.  And yes, all configured
> subscriptions will restart simultaneously.  But without this feature, receivers
> will not see events from boot to transport establishment.  And without this
> feature, two different configured receivers might get different initial events as
> the transport might not be brought up simultaneously.
> 
> <Kent13> I'm unsure how this addresses my concern that replaying is
> unnecessary for configured subscriptions…I somehow thought that it might be
> related since it's listed here.   Separately, I'm unclear about what this change
> does, I know you provide some explanation above, but you can say it
> differently or provide an example or two to illustrate what you mean?   Does
> this change introduce the problem you mentioned before about duplicates
> events being sent?
> 
> <Eric14>  Here is a link to the slides which I have put together for IETF 102
> which hopefully hits your request above:
> 
> https://github.com/netconf-wg/rfc5277bis/blob/master/draft-configured-
> replay-slides-ietf102.pdf
> 
> 
> <Kent14> not really.  The switch to "configured-replay" seems orthogonal,
> likely due to it being perceived as easier than specifying an exact time.

<Eric15> It is a flag.   It just means that the replay starts with the earliest event after reboot.

> Separately, as a comment on the slides, perhaps list both Pros and Cons?  

I put PRO and CON on slide 2 of:
https://github.com/netconf-wg/rfc5277bis/blob/master/draft-configured-replay-slides-ietf102.pdf 
If you disagree with any bullet, let me know.

> I provided 4 perceived benefits in a recent email…

<Eric15>  Pulling the four items which I believe you are referring to:

Kent #1: it is already a SHOULD for the receiver to do a dynamic fetch for already started subscriptions (see quoted paragraph above), so having another SHOULD for newly started configured subscription doesn't threaten of a-d any more than already, 
Eric response #1: Please reread the provided slide.  I tried to reframe (a)-(d) and provide a summary all the other points from our long thread.  For example, asserting that the two SHOULDs can be safely coupled is incorrect.  Per my Option 2, bullet 4, sub-bullet 2, can be are cases where dynamic subscriptions are not needed on the receiver.  

Kent #2: it seems really weird to have persistent configuration that only gets used once in the lifetime of a configured subscription
Eric response #2: This is not a benefit.   Beyond that, a flag that say when to begin is not a bad thing.  And there is plenty of configuration which is used only once. E.g., stop-time, synch-on-start.

(Kent #3) it is good to remove frivolous features
Eric response #3a:  It is optional to implement.  If someone doesn't want to implement it, they don't have to.  
Eric response #3b:  This is not frivolous.  In fact my personal preference would be to have the start time for a configured subscription be at the known/consistent/anchored boot time.  The default right now is that the start time varies based on the point of first transport establishment -> and this will vary by receiver.  Which means independent receivers of a single subscription may have a different first event.   Sadly this default cannot be change to my preference because replay is an optional feature.   
Eric response #3c: As security people want this behavior, they will be forced to attempt Option 2 should Option 1 not exist.  Which has all the CON drawbacks described on the slide.  

(Kent #4) the current text in draft is confusing about replay-start-time.  
Eric response #4:  This is not a benefit.  And the text has been updated.

> BTW, the description statement on replay-start-time seems incorrect, with the
> node now being config false, how can it be used to "trigger" anything?
> 
> <Eric14>  replay-start-time exists as part of the establish-subscription RPC.   The
> RPC is where the triggering occurs.
> 
> <Kent14> right, and that's fine, but it's not okay for configured subscriptions.
> Subscription-policy uses subscription-policy-dynamic, the description needs to
> be refined, like it was for the subscription-started notification.

<Eric 15> Replay-start-time is config false.  Therefore it will not appear populated for a configured subscription in the data nodes.  (Note: What I did do is delete 'replay-start-time' from the refined definition, as that option no longer exists.)

Eric

> Kent // contributer