Re: [netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-yang-push-23: (with DISCUSS and COMMENT)

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

> From: Alexander Clemm, May 15, 2019 2:59 PM
>
<snip>
> > Section 3.3 states:
> >
> >             In order for a subscriber to determine whether objects
> >    support on-change subscriptions, objects are marked accordingly on a
> >    publisher.  Accordingly, when subscribing, it is the responsibility
> >    of the subscriber to ensure it is aware of which objects support on-
> >    change and which do not.  For more on how objects are so marked, see
> >    Section 3.10.
> >
> > Chasing the reference, we see that this marking is left for future
> > work or implementation-specific usage.  I'm not very comfortable with
> > the way we are describing this situation, as it seems pretty fragile
> > in the face of different implementations trying to interoperate.
> >
> > <ALEX> The working group decided to pull this item out of this draft.
> > It is being addressed in draft-ietf-netconf-notification-capabilities
> > (https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capa
> > biliti
> > es/) </ALEX>
> 
> I guess I'll see what the -24 looks like, but I'm not sure yet whether "pull this
> item out of the draft" is describing a previous decision that left it in this state or
> a current decision starting from this state.  (The latter would seem to make
> more sense to me, but I can wait and see.)
> 
> <ALEX2> To give a bit of history, in a set of earlier revisions we did describe a
> mechanism for this.  There was quite a bit of discussion around this and various
> options were considered, from introducing a YANG extension (see e.g. rev 12
> section 3.10) to the mechanism that is now described in the separate draft.
> There were also discussions whether such mechanism should be generalized
> further - for example, what if you wanted to express not only whether an item
> supports on-change subscriptions, but wants to give an indication of the "size"
> of the change?  The WG ultimately decided to not overburden the draft and slow
> progress down further and address this item separately.  There was also at some
> point discussion about keeping it simpler and take an all-or-nothing approach
> (require a server to either support on-change for all objects or none), which
> however was deemed to be too restrictive and we did want to allow for the
> possibility of a differentiated approach.
> Bottom line, I would like to ask please accept the previous decision.
> </ALEX2>

To summarize how this played out in the WG
- there was a section dedicated to the solution within YANG push
- several WG members asked extract this solution in order to postpone finalization of the solution
- we extracted the section at the WG request
- a new draft with the solution was adopted by the WG.  See draft-ietf-netconf-notification-capabilities
- implementers would be wise to use this draft

To get a brief glimpse on some of the details in the discussion history, you can look at 
https://github.com/netconf-wg/yang-push/issues/10 
There was also quite a bit on the mailing list.

Thanks,
Eric