Re: [Netconf] YangPush now

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:netconf-bounces@ietf.org] On Behalf Of Henk Birkholz
> Sent: Friday, July 13, 2018 1:54 AM
> To: Robert Wilton <rwilton@cisco.com>; Kent Watsen <kwatsen@juniper.net>;
> Andy Bierman <andy@yumaworks.com>; Netconf <netconf@ietf.org>
> 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
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf