Re: [Netconf] YangPush now

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

Hi Juergen,

The options only apply to three drafts which have been under WGLC:
- draft-ietf-netconf-subscribed-notifications
- draft-ietf-netconf-yang-push
- draft-ietf-netconf-netconf-event-notifications

For more context, see the PPT slides for the NETCONF session:
https://github.com/netconf-wg/rfc5277bis/blob/master/Subscriptions-NETCONF-IETF102.pdf 

Agree that draft-ietf-netconf-restconf-notif isn't ready.  And that there are technical issues open there.  This is what was being discussed on the thread earlier this week.

Eric

> -----Original Message-----
> From: Netconf <[e-mail]> On Behalf Of Juergen
> Schoenwaelder
> Sent: Saturday, July 14, 2018 2:02 AM
> To: Alexander Clemm <[e-mail]>
> Cc: Netconf <[e-mail]>
> Subject: Re: [Netconf] YangPush now
> 
> I am confused to which drafts this analysis applies exactly. The work seems
> to be covered by the following drafts:
> 
> - draft-ietf-netconf-yang-push [56 pages]
> - draft-ietf-netconf-subscribed-notifications [74 pages]
> - draft-ietf-netconf-restconf-notif [33 pages]
> - draft-ietf-netconf-notification-messages [23 pages]
> - draft-ietf-netconf-netconf-event-notifications [26 pages]
> - draft-ietf-netconf-udp-pub-channel [19 pages]
> 
> I do not think all the 231 pages are 'done', there were technical issues
> raised on the list related to configured subscriptions recently, more
> specifically draft-ietf-netconf-restconf-notif. Note that the goal is not to
> minimize edits but to avoid getting stuck on issues during WG last call (or
> the publication queue) on features that may not seem that relevant. It may
> also be useful to have a fair assessment of the dependencies of these drafts
> (or the relevant drafts for the questions) wrt configuration data models and
> their progress.
> 
> /js
> 
> On Fri, Jul 13, 2018 at 08:44:41PM +0000, Alexander Clemm wrote:
> > Hi,
> >
> > I will unfortunately not be able to attend Monday's meeting (still in
> transit),  so let me briefly summarize what the options are and their
> implications, and which we therefore prefer as authors.
> >
> > Regarding progressing Dynamic and Configured Together (hum A):
> >
> > Option A1: Keep them together, as currently defined in the draft.  This
> option is done & currently defined in the drafts.  This will be the fastest and
> is thus preferred.
> >
> > Option A2: Keep them together, but leave the Netconf transport option
> for configured open for now.  This requires updates to the Netconf
> Notification draft (draft-ietf-netconf-netconf-event-notifications), but the
> updates should be straightforward and the time delta should still be small.
> Once ietf-netconf-server.yang completes, a -bis version of the Netconf
> Notification draft can be issued to accommodate configured subscriptions
> with call home using netconf server.  This option is not preferred but
> acceptable.
> >
> > Option A3: Take out configured subscriptions altogether for now, to
> revisit at a later point.  Keep only dynamic subscriptions.  This option
> implies having to refactor the drafts.  It will imply further delay and
> significant effort to make the updates.  The concern is that this will miss the
> market window, therefore IMHO this a terrible option.  Frankly, given this, I
> am not sure that the authors will be willing to invest all that effort into
> something that will de-facto only diminish value.
> >
> > Regarding progressing subscribed notification (SN) and YANG-Push (YP)
> together (hum B):
> >
> > Option B1: Keep them together as one cluster.  This has been the WG
> direction since this stuff was adopted; SN was actually created by breaking
> out the generalizable portions from YP at the time.  They really belong
> together and the business value we are targeting is provided by them
> jointly, even if SN can be used on its own.  Hence, author preference is to
> keep them together.
> >
> > Option B2: Separate them out.  The concern is that while in theory it
> > might not result in further delays, in practice it still breeds the
> > risk of doing so.  (And we know that the difference between theory and
> > practice is that while in theory both are the same, in practice often
> > they are not.)
> >
> > Summary: Authors clearly prefer A1 and B1, although they will accept A2
> and B2 if the WG decides to go there.  A3 is a terrible option and a very
> clear no go.
> > --- Alex
> >
> >
> > > -----Original Message-----
> > > From: Netconf [mailto:[e-mail]] On Behalf Of Henk
> > > Birkholz
> > > Sent: Friday, July 13, 2018 1:54 AM
> > > To: Robert Wilton <[e-mail]>; Kent Watsen
> > > <[e-mail]>; Andy Bierman <[e-mail]>;
> Netconf
> > > <[e-mail]>
> > > Subject: Re: [Netconf] YangPush now
> > >
> > > Hi all,
> > >
> > > I would also like to see the implications and consequences of a
> > > specific hum option to be highlighted very clearly and explicitly.
> > > Every option that is available to hum on should highlight an
> > > expected amount of delay of WGLC created by the decision.
> > >
> > > This thread's subject is "YangPush now" and that is exactly the point.
> > > Remodeling takes time. Wrt to number of changes, I would like to
> > > encourage the minimal viable solution at this point of time (yes, I
> > > a can barely believe it myself... but it is actually me, who is
> > > writing this statement... maybe to some this is an indicator).
> > >
> > > Viele Grüße,
> > >
> > > Henk
> > >
> > >
> > > On 07/13/2018 10:50 AM, Robert Wilton wrote:
> > > > Hi,
> > > >
> > > > It might be useful (at least to me), if the draft authors could
> > > > explicitly indicate what their preference is, and also which of
> > > > the choices below they think would lead to the work completing most
> quickly.
> > > >
> > > > Thanks,
> > > > Rob
> > > >
> > > >
> > > > On 12/07/2018 19:48, Kent Watsen wrote:
> > > >>> I would like to strongly +1 retaining the configured
> > > >>> subscriptions (not necessarily in the Push draft itself for the
> > > >>> sake of expediting WGLC or
> > > >>> modularity)
> > > >> Ah, so here's another hum question: with or without yang push.
> > > >>
> > > >> hums now are:
> > > >>
> > > >>   1. dynamic subscriptions ~ configured subscriptions
> > > >>     a. dynamic first, then configured (published sequentially)
> > > >>     b. dynamic and configure together (published in parallel)
> > > >>
> > > >>   2. subscribed-notifications ~ yang-push
> > > >>     a. SN first, then YP  (published sequentially)
> > > >>     b. SN and YP together (published in parallel)
> > > >>
> > > >> Eric/Alex: please include a slide with this somewhere in your preso.
> > > >>
> > > >> Thanks,
> > > >> Kent // chair
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > >
> > > _______________________________________________
> > > Netconf mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/netconf
> > _______________________________________________
> > Netconf mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netconf
> 
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>
> 
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf