Re: [Netconf] YangPush now

[Henk Birkholz <[e-mail]>]

Hello Kent,

while I fully agree with scoping a hum beforehand and with the statement 
that "any preferences posted before won't be counted", I am surprised by 
reading the statement "BTW, I'm unsure if A2 is a viable option." in the 
same message. Maybe I am missing something very obvious here, but is 
that not the exact same thing you were discouraging beforehand?

Again, this is not an attempt to disrupt a constructive and targeted 
process. I am new to this domain and just puzzled by the semantic 
difference of a "preference" and an "option" stated on the list - as it 
seems to me subjectively - they are hard to distinguish for me as a 
non-native speaker.

In consequence, I would like to know what a useful comment before a hum 
looks like and - in contrast - how a comment that does not count looks 
like. The reason for my ("noob") question is that I am unfamiliar with 
the proceedings of this WG & I do not want to infuse disruptive comments 
& I am now unsure how to phrase a productive contribution, I think.

If I voiced a preference that does not count, I am very sorry. I only 
wanted to highlight that not only a set of options, but also their 
implications have to be well understood by the audience before humming. 
That was my only intend :)

Viele Grüße,

Henk

On 07/14/2018 02:40 AM, Kent Watsen wrote:
> Folks,
> 
> While it's okay to post your preferences beforehand, note that the goal
> 
> of the hum is to get the room's collective response at once.  As such, any
> 
> preferences posted before won't be counted.  For the folks that won't
> 
> be present, at the appropriate time, please enter your choice in jabber.
> 
> Note that, regardless the outcome of the hums, the *same* end-result
> 
> will be achieved in time (either all at once or piecemeal).   We're only
> 
> looking at if there is an opportunity of getting a subset to RFC status
> 
> faster (a number of people asked for this).  It will be a snap-decision,
> 
> if there isn't an *obvious* preference from the room, then it will be
> 
> author's choice.
> 
> BTW, I'm unsure if A2 is a viable option.  It seems that it should not be
> 
> possible to configure a receiver without specifying the transport.  In
> 
> YANG terms, SN might need a mandatory "choice" that the notif models
> 
> augment into.  I think that, to support configured subscriptions, there
> 
> should be at least one mandatory to implement "notif" draft.
> 
> Kent
> 
> On 7/13/18, 6:56 PM, "Netconf on behalf of Reshad Rahman (rrahman)" 
> <[e-mail] <mailto:[e-mail]> on behalf of 
> rrahman=[e-mail] 
> <mailto:rrahman=[e-mail]>> wrote:
> 
> I am not an author of SN or YP but I’m a supporter of A1 and B1. I still 
> don’t see the point/intent of doing anything else.
> 
> Regards,
> 
> Reshad.
> 
> *From: *Netconf <[e-mail]> on behalf of "Eric Voit 
> (evoit)" <evoit=[e-mail]>
> *Date: *Friday, July 13, 2018 at 6:17 PM
> *To: *'Andy Bierman' <[e-mail]>, Alexander Clemm 
> <[e-mail]>
> *Cc: *Netconf <[e-mail]>
> *Subject: *Re: [Netconf] YangPush now
> 
> +1.   A1 & B1.
> 
> Eric
> 
> *From:*Netconf <[e-mail]> *On Behalf Of *Andy Bierman
> *Sent:* Friday, July 13, 2018 5:53 PM
> *To:* Alexander Clemm <[e-mail]>
> *Cc:* Netconf <[e-mail]>
> *Subject:* Re: [Netconf] YangPush now
> 
> Hi,
> 
> If the SN draft is only held up for configured subscriptions,
> 
> and the people interested in implementing this YANG feature right away
> 
> are OK with the receiver list as-is, then A1, B1 seems like an easy choice.
> 
> Andy
> 
> On Fri, Jul 13, 2018 at 1:44 PM, Alexander Clemm 
> <[e-mail] <mailto:[e-mail]>> 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]
>     <mailto:[e-mail]>] On Behalf Of Henk Birkholz
>      > Sent: Friday, July 13, 2018 1:54 AM
>      > To: Robert Wilton <[e-mail] <mailto:[e-mail]>>;
>     Kent Watsen <[e-mail] <mailto:[e-mail]>>;
>      > Andy Bierman <[e-mail] <mailto:[e-mail]>>;
>     Netconf <[e-mail] <mailto:[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] <mailto:[e-mail]>
>      > https://www.ietf.org/mailman/listinfo/netconf
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=M407zoQiYHA_i5ojIVIn0hQ22DqGzwH1S4ib8mZNtQs&s=S5YFUlo520sYi5HXAj4BXaOXkItF4q1Rf6YpFGzqDTU&e=>
> 
> 
> 
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>