Re: [Netconf] yang-push-17 on-change subscriptions

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

Agree this change should be made.

Eric

From: Andy Bierman <[e-mail]>
Sent: Saturday, August 18, 2018 1:23 PM
To: Martin Bjorklund <[e-mail]>
Cc: Eric Voit (evoit) <[e-mail]>; Netconf <[e-mail]>
Subject: Re: [Netconf] yang-push-17 on-change subscriptions

Hi,

I would like to clarify sec. 3.3. para 5.
The text is confusing wrt/ the dampening period is per-object or per-subscription.


   Once an update record for a given object is generated, no

   other updates for this particular subscription will be created until

   the end of the dampening period.  Values sent at the end of the

   dampening period are the current values of all changed objects which

   are current at the time the dampening period expires.




The first sentence makes me think the dampening period is per-object, but the 2nd sentence
seems the say "the" dampening period (meaning 1 of them) applies to "all changed objects".

Suggest:

OLD:


 Once an update record for a given object is generated,


NEW:


 Once an update record for any object in the subscription is generated,







Andy




On Fri, Aug 17, 2018 at 7:08 AM, Martin Bjorklund <[e-mail]<mailto:[e-mail]>> wrote:
Hi,

"Eric Voit (evoit)" <[e-mail]<mailto:[e-mail]>> wrote:
> > From: Martin Bjorklund, August 17, 2018 3:48 AM
> >
> > Hi,
> >
> > "Eric Voit \(evoit\)" <evoit=[e-mail]<mailto:[e-mail]>> wrote:
> > > A dampening period is optional
> >
> > How do you mean?  There is no if-feature on the "dampening-period",
> > and no
> > text indicating that a server can reject a request with a
> > "dampening-period".
> > AFAICT from the draft, the dampening feature must be implemented by a
> > server.
>
> While the "dampening-period" object must be supported by the RPC, that
> doesn't mean the platform needs to implement subscription dampening.
> This can be accomplished by a dampening period of "0" being returned
> as a hint.  (Per section 3.2: "Such hints include ... acceptable
> dampening periods...". )  Using just the hint for conveying this info
> rather than the hint plus advertisement of an option feature
> "dampening" simplifies the interface.
>
> If you are ok with it, Alex could tweak the following text in the
> draft:
>
> (1) For the definition of leaf 'period-hint' in the YANG model:
>
> OLD: "Returned when the requested time period is too short. This hint
> can assert a viable period for either a periodic push cadence or an
> on-change dampening interval.";
>
> NEW: "Returned when the requested time period cannot be
> supported. This hint can assert a viable period for either a periodic
> push cadence or an on-change dampening interval.  In the case of
> dampening not being supported, a 'period-hint' of '0' must be
> returned. ";

Ok.  The definition of the "period-unsupported" identity should also
be updated accordingly.

BTW, I just realized that the yang-data structures have different
names in the module and the text.  For example, in the module you have
"establish-subscription-datastore-error-info" but the text uses
"establish-subscription-error-datastore" (in some places).


> (2) And in Section 3.1:
>
> OLD: In order to protect against that, a dampening period MAY be used
> to specify the interval which must pass before successive update
> records for the same subscription are generated for a receiver.
>
> NEW: In order to protect against that, on-change dampening MAY be
> supported.  Where supported, a non-zero dampening period will specify
> the interval which must pass before successive update records for the
> same subscription are generated for a receiver.

I suggest you keep the OLD text, but also add a sentence that explains
that the server MAY not support the given dampening period, and that
the period-hint can be used by the server to indicate an acceptable
dampening period (which may be 0).


> If you require more than these tweaks, Alex could also make an
> optional dampening feature.  But this seems to me to be unnecessarily
> heavyweight.

I agree.


/martin


>
> Eric
>
> > /martin
> >
> >
> > (based on your earlier comments).  And
> > > the dampening period is per subscription rather than per object.
> > > Cisco doesn’t have code at this time for dampened changes.
> > >
> > > Eric
> > >
> > > From: Netconf <[e-mail]<mailto:[e-mail]>> On Behalf Of Andy Bierman
> > > Sent: Thursday, August 16, 2018 1:59 PM
> > > To: Netconf <[e-mail]<mailto:[e-mail]>>
> > > Subject: [Netconf] yang-push-17 on-change subscriptions
> > >
> > > Hi,
> > >
> > >
> > > I would like to know if anybody has implemented on-change
> > > subscriptions yet.
> > > The implementation requirements seem very complex when you consider
> > > that every single data node instance in the subscription has its own
> > > dampening timer.
> > >
> > > Edits are not reported sequentially as they occur.
> > > Instead every node is tracked and the change may only reported after
> > > the dampening period expires.  It seems quite possible that nodes can
> > > interact (e.g., leafrefs) so that reporting edit Y can depend on
> > > previous edit X, which cannot be reported until the end of its
> > > dampening period, in the future. So edit Y will be reported before X,
> > > and the patch will fail to validate, because the current state of X is
> > > incorrect on the receiver..
> > >
> > > All the state tracking on the server is expensive to implement, and I
> > > am not really sure it actually helps the client that much.
> > >
> > >
> > > Andy
> > >