Subject: [Netconf] YP#10 Notifiable-on-change for application designers (was RE: review of draft-ietf-netconf-yang-push-11)

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 22 Dec 2017 18:49:34 +0000

Coming back to issue YP#10:
https://github.com/netconf-wg/yang-push/issues/10   
I am hoping we can get to a rough consensus.  Basically the open question for the yang-push draft is: should we provide guidance on how to indicate which schema objects are notifiable-on-change.

There are things we have agreed upon during previous discussions of this issue.

(1) Providing information on which schema nodes might be notifiable-on-change is useful for application designers (i.e., design time).  

(2) Just providing information on which schema nodes are notifiable-on-change is insufficient/incomplete for run-time enforcement (as some instance data based on the schema nodes may go either way.)

(3) The YANG library seems a reasonable place to maintain definitive instance information.  But any such specification will be outside the scope of the yang-push draft.

(4) Whatever mechanism(s) are ultimately selected for identifying whether an instance object or schema node is notifiable-on-change must include support for both explicit marking and inheriting the value of the parent.   The default for unmarked top level nodes is false.

So that seems to be what we have agreed on.   What we haven't closed on is the following: Section 3.10 of yang-push provides a mechanism for marking schema objects as notifiable-on-change.  Section 3.10 will be either removed, or moved to an appendix.

So the open question is do we want 3.10 as an appendix, or do we want it removed?  

Below are the arguments for each...

FOR moving 3.10 into an appendix:
- this provides guidance for today's implementations, without asserting that this would be the long term mechanism
- the previous draft Balazs provided (https://tools.ietf.org/html/draft-lengyel-netmod-schema-annotation-00), didn't get traction when it was proposed.  We would have no timeline for resolution.  
- we need some mechanism, and the deviations construct has many of the required characteristics.

FOR removing 3.10:
- the mechanism proposed (deviations) overloads the meaning of deviations.  
- it is hard to step back from such a meaning expansion of augmentation, even when it is just within an informational appendix
- we don't have majority consensus for any proposal at this point. (e.g., In Alex' latest email below he suggests an alternate to deviation based on "augmentation")
- mechanisms for schema annotation should be in the domain of the NETMOD WG, and it is possible that a generalized solution could emerge from there
- solutions for the instance data (perhaps using the YANG library) might expose a better way of doing this, early guidance might constrain the ultimate solution
- adding this appendix makes the draft and model more complex with content which might provide incorrect guidance should another mechanism emerge as YANG library evolves.

Is there anything else people want to articulate for either side?   Or a new side?

Without getting a majority for the Appendix option, I believe we should *not* include any mechanism to tag notifiable-on-change for schema objects within yang-push.

Thoughts?
Eric

P.S.: The version of yang-push soon to be posted still will still have section 3.10.  It won't be moved/removed until we resolve the issue above.

> -----Original Message-----
> From: Alexander Clemm [mailto:[email-masked]]
> Sent: Thursday, November 30, 2017 1:54 PM
> To: Martin Bjorklund <[email-masked]>; [email-masked]; Mahesh
> Jethanandani <[email-masked]>; [email-masked]
> Cc: Eric Voit (evoit) <[email-masked]>; [email-masked];
> [email-masked]
> Subject: RE: [Netconf] review of draft-ietf-netconf-yang-push-11
> 
> Hi Martin,
> 
> Instead of "deviation", we could also use "augmentation".  The point is that the
> implementation-specifics would be provided in an implementation-specific
> YANG module.  Clearly the possibility to have implementation-specific YANG
> modules is foreseen by the very fact that the deviation statement exists, and
> the genie is out of the bottle here.
> 
> That said, yes, there was an original proposal to use annotations, which Balazs
> proposed.  When it became clear that the general annotations proposal wasn't
> moving forward, we settled for the next-best solution, which is the YANG
> extension (i.e. a very specific annotation to indicate on-change notifiability)
> that we have today.
> 
> As indicated by you and others on this thread, alternatively we can certainly
> also simply defer this issue for now.  In this case, as you state, we would simply
> indicate in the text that clients need to be aware that not every object may
> support on-change notifiability; how do discover which ones do and which
> ones do not would be left outside the scope of the specification.
> 
> However, in that case it would still seem to make sense to propose a way in
> which an implementation could address this in an informational appendix.  This
> informational appendix could then make the suggestions that implementations
> might support a module with such an extension, which we would then include
> in the appendix as an example.  Having a module enumerating the nodes (per
> your earlier suggestion), or suggesting a library augmentation (without
> introducing a dependency on that - can be informational only!) could be
> described there as well.  Perhaps it is a question to our WG chairs, Mahesh and
> Kent, whether putting this as an informational example for a way in which to
> addresss this would be feasible, in the same way as some drafts explain how
> something might be implemented - really this is a process question - or if it
> should simply be omitted entirely.
> 
> We would also make clear that if a subscription contains objects that are not
> on-change notifiable, no updates will be received (rather than rejecting the
> subscription).
> 
> The more I think about this, the more I think that addressing this as part of the
> library will be the technically preferable option.  Having this as an
> augmentation would work.  Is this something that we can include in the YANG
> library -bis draft?  Really this is where this should go.  This could also serve as
> an example there how the library might be used to keep track also of other
> "annotations" in the future.  Perhaps something to discuss on the other thread.
> 
> Thanks
> --- Alex
> 
> 
> > -----Original Message-----
> > From: Martin Bjorklund [mailto:[email-masked]]
> > Sent: Thursday, November 30, 2017 7:25 AM
> > To: Alexander Clemm <[email-masked]>
> > Cc: [email-masked]; [email-masked]; [email-masked];
> > [email-masked]
> > Subject: Re: [Netconf] review of draft-ietf-netconf-yang-push-11
> >
> > Hi,
> >
> > I'll reply to the on-change discussion here.
> >
> > Alexander Clemm <[email-masked]> wrote:
> > > Yes, thank you for the comments!
> > >
> > > As the mail is long, rather than commenting inline, let me make just
> > > a few additional replies in addition to Eric's:
> > >
> > > - On the topic of how to mark on-change notifiable YANG objects:
> > >
> > > Yes, clearly what is on-change notifiable and what is not could
> > > differ by implementation.  We thought that asking implementors to
> > > define implementation-specific modules that would indicate the
> > > on-change notifiability through deviations would make sense, since
> > > this is really one of the function of deviations - indicate what is
> > > implementation-specific.
> >
> > Actually, I think it mis-uses the deviation statement a bit.  From the
> > spec:
> >
> >    Deviations define the way a server or class of servers deviate from a
> >    standard.
> >
> >    [...]
> >
> >    Server deviations are strongly discouraged and MUST only be used as a
> >    last resort.  Telling the application how a server fails to follow a
> >    standard is no substitute for implementing the standard correctly.  A
> >    server that deviates from a module is not fully compliant with the
> >    module.
> >
> >
> > We have discussed an "annotate" statement before, which would be used
> > to add information to schema nodes.  (we actually have such a
> > statement as a vendor-specific extension, and it is used a lot).  But
> > even if we had that, I'm not sure that would be the best solution in this case.
> >
> > > In that sense, the current solution does make sense to me and seems
> > > to be in the spirit of how implementation-specific YANG modules
> > > should be used.
> > >
> > > That said, the other proposal to have a "meta-module" that contains
> > > a list of objects for which on-change notification is supported
> > > could be certainly be an alternative.  However, the notifiability
> > > should be indicated per node at the schema level, not for each
> > > individual instance.  We would not want to have to enumerate
> > > individual list entries, for example. Also, are there additional
> > > considerations to accommodate schema-mount in that case?
> > >
> > > Another thought, perhaps on-change notifiability is something that
> > > could instead also be included in the YANG library.  Each module in
> > > the library would then list the nodes for which on-change is
> > > notifiable on a given server.
> >
> > That's also an option.
> >
> > I think we want somehting that is available on-line in runtime, but
> > that also can be stored in an off-line file (ala AGENT-CAPABILITIES).
> > Augmentation of yang library probably solved both these cases.
> >
> >
> > > Deferring this until later might also an option.
> >
> > I think that's my preferred option.  At least if we want to finish
> > this document sooner rather than later...
> >
> >
> > > I am sure there will
> > > be other annotations/markings for objects that we will come up with
> > > our time.  However, one issue is that by default we did not want to
> > > make assumptions about on-change notifiability being supported.
> > > Rather, when it is supported, it would be specifically indicated;
> > > the default would be that it's not supported.  If we defer the
> > > solution until later, then this won't work.
> >
> > Well, there's alread a feature to indicate *some* support.  If we
> > defer, we'd just write that how an implementation communicates which
> > nodes it supports for on-change is out of scope.
> >
> > > If we wanted to defer, it would
> > > seem what we should do is still propose a solution informally in an
> > > appendix, and indicate that this may be later replaced by another
> > > solution.  We would put the YANG extension into an own separate
> > > module.
> >
> > I don't think that's a good solution.  I don't think we should
> > encourage the extension-statement solution.
> >
> > As one data point, in our implementation, all config nodes in the
> > conventional datastores would be available for on-change.  For
> > operational state, it is up to the instrumentation.
> >
> >
> > > - on the Subscription Policy term (3.6).  Sure, we don't need to
> > > - introduce a new term, but really what the parameters describe is
> > > in
> > > - fact a policy.  We could of course call them "datastore
> > > subscription
> > > - specific configuration parameters", or "datastore subscription
> > > - specific behavior configuration" , but this sounds a bit awkward
> > > to
> > > - me.
> >
> > I would actually prefer more concrete words like the ones you propose.
> >
> >
> > > - on the "no-such-datastore" eror tag: true, invalid-value would
> > > cover
> > > - this, but why be general when we can be specific?
> >
> > I'll reply to this in my reply to Eric.
> >
> >
> > /martin
> >
> >
> >
> > >
> > >
> > > --- Alex
> > >
> > > > -----Original Message-----
> > > > From: Netconf [mailto:[email-masked]] On Behalf Of Eric
> > > > Voit
> > > > (evoit)
> > > > Sent: Wednesday, November 29, 2017 9:37 AM
> > > > To: Martin Bjorklund <[email-masked]>; [email-masked]; Balazs
> > > > Lengyel <[email-masked]>
> > > > ([email-masked]) <[email-masked]>; Andy
> > > > Bierman ([email-masked]) <[email-masked]>
> > > > Subject: Re: [Netconf] review of draft-ietf-netconf-yang-push-11
> > > >
> > > > Hi Martin,
> > > >
> > > > Thanks for the comments.   Many thoughts in-line...
> > > >
> > > > > From: Martin Bjorklund, November 28, 2017 4:38 AM
> > > > >
> > > > > Hi,
> > > > >
> > > > >
> > > > > I have now reviewed draft-ietf-netconf-yang-push-11.  I have one
> > > > > somewhat more important comment, and several others.
> > > > >
> > > > > Important issue:
> > > > >
> > > > > o  3.10
> > > > >
> > > > >   I don't think the proposed YANG extension is the correct solution to
> > > > >   the stated problem, for several reasons:
> > > >
> > > > In general we agree there are several alternatives to solve this
> > > > issue.  And any mechanism supported by the WG would be fine.
> > > >
> > > > My read of your proposal below is that it does reuse elements of 3.10.
> > > > For
> > > > example, I *think* you are proposing hierarchical inheritance of
> > > > on-change property markings of the parent rather than making every
> > > > instance.
> > > > Because
> > > > marking every instance within a routing table would be
> > > > prohibitively expensive.  So based on whatever commonality we can
> > > > establish across the proposed alternatives, perhaps we can come to
> > > > a common way to set this
> > > > information.    If not, we can back out on-change marking as something
> > > > implementation-specific for this current specification.
> > > >
> > > > Stepping back a minute, it is good to think about who would use
> > > > this
> > > > on-
> > > > change support data.  Application developers are going to make
> > > > subscription requests.  And they are far more likely to want to
> > > > design based on the schema level information exposed rather than
> > > > instance data.  Driven by that constraint, the current proposal is
> > > > framed as is -- mostly since there was no interest in Balazs'
> > > > https://tools.ietf.org/html/draft-lengyel-netmod-schema-annotation
> > > > -0
> > > > 0 which was designed to support application developers needing
> > > > this information.  Without this draft, at the time this was
> > > > proposed the next-best thing was an extension which works based on
> > > > the established pattern of deviations.
> > > >
> > > > To cover this issue, I have re-opened YP#10 to track and resolve...
> > > > https://github.com/netconf-wg/yang-push/issues/10
> > > >
> > > > Below are some specific pros/cons I see...
> > > >
> > > > >     1.  In most cases, this is not a property of the data model, but
> > > > >         of the implementation, and possibly even the deployment.  So
> > > > >         having a YANG extension statement is not a good solution.
> > > >
> > > > Fully agree this can be implementation level issue.  But then
> > > > again, so is any deviation.
> > > >
> > > > So to cover "property of the implementation" case, the proposed
> > > > extension would typically be included in deviations file per
> > > > implementation.
> > > > Such an
> > > > approach does mirror existing mechanisms for deviations, and has
> > > > the benefit of not requiring another a new totally separate file
> > > > to document the desired behavior.
> > > >
> > > > As for times this might be deployment specific, we saw potential
> > > > capacity issues determining whether something might not be on-change
> > > > subscribable.   Here it would be up to the implementation to determine
> > > > whether to use the error "on-change-unsupported" from YANG Push,
> > > > or the error "insufficient-resources" from subscribed
> > > > notifications.  A choice between the two can be driven based on
> > > > whether a deployment would
> > > > *ever* have capacity for the requested subscription.
> > > >
> > > > >     2.  With NDMA, the same schema node is present in different
> > > > >         datastores.  It might be the case that an implementation
> > > > >         supports on-change for the node in a configuration datastore,
> > > > >         but not in operational.  Again, marking a node in the schema
> > > > >         is not a good solution.
> > > >
> > > > As the current solution was developed before NMDA, we didn't
> > > > consider differences in on-change support for different datastores.
> > > > So this is a real consideration.
> > > >
> > > > If for a minute we assume we are going to follow the current
> > > > approach in the draft, the extension proposed in 3.10 could have a
> > > > default of the operational datastore.  And we could add the option
> > > > of including a list of datastores in the extension whenever
> > > > on-change for something else is needed/supported..
> > > >
> > > > >     3.  Since the on-change property is implementation dependent, it
> > > > >         means the information will be available to clients only in
> > > > >         deviation modules.  This is quite an expensive and complicated
> > > > >         way to pass the information to the clients.
> > > >
> > > > Visibility to application developers was one reason we went down
> > > > this path.
> > > > Any solution needs to frame this visibility as a key element.
> > > > Considering this,
> > > > I actually see a need both for the schema based solution as
> > > > framed, and the possibility of an instance based mechanism if
> > > > someone wanted the lower level of granularity.  Per above, I don't
> > > > think instance data within all instance objects like routing
> > > > entries is possible anyplace datastore size becomes a factor.
> > > >
> > > > >   An alternative solution could be to have an ordered list of
> > > > >   instance-identifiers that list this property, per datastore, for
> > > > >   example:
> > > > >
> > > > >    <entry>
> > > > >      <path>/sys:system/sys:system-time<path>
> > > > >      <notifiable-on-change>false</notifiable-on-change>
> > > > >    </entry>
> > > > >    <entry>
> > > > >      <path>/sys:system<path>
> > > > >      <notifiable-on-change>true</notifiable-on-change>
> > > > >    </entry>
> > > >
> > > > This could work.  Several questions which would need to be
> > > > addressed with this approach:
> > > >
> > > > (1) how would application developers easily know what objects are
> > > > on- change subscribable?
> > > >
> > > > (2) If this is per-instance, is the property inherited from a parent?
> > > > If no, how
> > > > do we deal with the size of the resulting information?
> > > >
> > > > (3) If this is per-instance, how is this information populated?
> > > > Don't you need schema level guidance recorded somewhere anyway?
> > > >
> > > > (4) Are there any issues with things like Schema mount?
> > > >
> > > > >   Yet another alternative would be to leave this to future work.
> > > >
> > > > If necessary, we can push this out.   I am hoping we can come up with
> > > > something here, especially as the on-chance implementations I have
> > > > seen have all used phased introduction of on-change for different
> > > > schema objects.