Re: [Netconf] YangPush now

[Andy Bierman <[e-mail]>]

On Thu, Jul 19, 2018 at 6:43 AM, Tim Jenkins (timjenki) <[e-mail]>
wrote:

> Please see [Tim] below.
> --
> Cisco Systems Canada Co.
> 2000 Innovation Drive
> Kanata, ON, Canada, K2K 3E8
> Preferences <http://www.cisco.com/offer/subscribe/?sid=000478326>
> Unsubscribe <http://www.cisco.com/offer/unsubscribe/?sid=000478327>
> Privacy <http://www.cisco.com/web/siteassets/legal/privacy.html>
>
> From: Andy Bierman <[e-mail]>
> Date: Wednesday, July 18, 2018 at 2:52 AM
> To: "Eric Voit (evoit)" <[e-mail]>
> Cc: Juergen Schoenwaelder <[e-mail]>, "Tim
> Jenkins (timjenki)" <[e-mail]>, "[e-mail]" <
> [e-mail]>
> Subject: Re: [Netconf] YangPush now
>
> Hi,
>
> I do not see much standards value in the configured subscriptions, from a
> client developer's POV.
> They are optional to implement and require vendor-specific details to be
> usable.
> [Tim] I agree that for configured subscriptions, we will need to match to
> vendor-specific implementation specifics for the foreseeable future.
>
>

This makes the module look like a just another proprietary YANG module to
clients.



> I can't think of any use-cases where the receiver has perfect knowledge of
> the
> configured subscriptions (and is therefore ready to start receiving
> notifications
> on those subscriptions without any operations) yet cannot invoke
> <establish-subscription>
> once the CallHome session is established.  This seems to be a subjective
> design choice.
> [Tim] From the beginning of the specifications, configured subscriptions
> didn’t require the use of YANG RPCs.   Cisco’s DNAC controller operates
> without invoking YANG RPCs, and uses configured subscriptions today.
>
>

Standards are much more useful on the client-side if there is at least one
known
value that can be used for each object.  This module standardizes what to
push,
not really how to push.  In theory that can be defined elsewhere and this
module
just reflects which method is in use.



Andy


I am OK with the configured subscriptions only because I have no intention
> of
> implementing it at this time.  I can see how other reviewers within the
> IETF may not be willing
> to give such a free pass.
>
> There is no rule that says  standard has to be complete and cannot depend
> on other pieces
> still under development.  Seems to me YANG Push will be stuck in MISREF
> state for awhile anyway,
> but all these external dependencies are by design choice, so the WG must
> be OK with the
> delays that this will cause.
> [Tim] In the current drafts, there are no external dependencies to non-RFC
> call home specifications.  I believe the authors’ intents for this is to
> avoid such a MISREF.
>
>
> Andy
>
>
>
>
> On Tue, Jul 17, 2018 at 8:41 PM, Eric Voit (evoit) <[e-mail]>
> wrote:
> From: Andy Bierman, July 17, 2018 5:06 PM
>
> Hi,
>
> I agree with Juergen that there are TBD features in SN.
>
> I also agree with the co-authors that it would be too much work to
> refactor now.
> It should be faster to complete SN then split it and start over.
>
> The main issues here seem to be:
>  1) no end-point for the configured receiver
>
> <Eric> There should not be any endpoint in SN.   Endpoint specifics would
> need to be exposed in the transport document.
>
> Note that we tried for years to have something transport independent for
> receivers in SN.   I.e., there was an endpoint “address” in the SN from
> 00-v13.   Kent and Martin argued it out of the SN draft.  For more on this,
> there is plenty extensive email alias archive on this subject.   As a
> result, with v14, “address” is gone.
>
> To summarize Kent & Martin’s argument which led to the v14 change: current
> endpoint “address” might be confused with call home.  We won’t agree with
> anything that might conflict with call home.  It is better to do nothing if
> we can’t agree on something.  By doing nothing, vendors can augment in what
> is needed.
>
> For v14 we didn’t just ignore the hole removing “address” made of course.
> Many email iterations over the last several months have proposed YANG
> augmentation code for those people who *do* want a leafref to
> netconf-server.yang now.  So if it makes this “endpoint completeness” issue
> go away, I would happily put an informational appendix into NETCONF-notif.
> This appendix would include the necessary augmentations to the leafref
> which Kent and I worked through.
>
> But we should go no farther than an informational appendix on this.  The
> current solution of doing nothing is actually a far more compelling answer
> than the inserting a mandatory (but then deviated away) leafref to an
> unimplemented ietf call home model.   This would allow the “solution is
> complete” answer to match to what dominates the industry: vendors who have
> their own key and call home infrastructure.
>
>
>  2) CallHome procedures and server requirements such as
>      processing normal NC or RC requests on the session
>
> This is described in draft-ietf-netconf-netconf-event-notifications,
> section 5.2.
>
>  3) no MUST or SHOULD implement values for transport
>
> This is on purpose.  IoT is not going to want a NETCONF transport default.
>   The current draft allows identities to be added for transports supported
> by a platform.  It is not possible to configure a transport the platform
> doesn’t have.
>
> I would like to get YANG Push done but not at the expense of the review
> cycles.
> There is nothing stopping the WG from working faster (e.g. virtual
> interim).
>
> If the WG chairs agreed to a final set of issues as input to the meeting.
> And agreed to abide by what came out of this interim as binding, final
> consensus, it might be a possibility.
>
> Just declaring everything done gets it out of the WG faster,
> but may not mean the RFC will be out faster.
>
> Topics #1 & #2 above are transport specific.  It would seem getting SN &
> YP to review beyond the WG should speed the final process.
>
> Eric
>
>
> Andy
>
>
>
>
> Andy
>
>
> On Tue, Jul 17, 2018 at 10:20 AM, Juergen Schoenwaelder <
> [e-mail]> wrote:
> I see several pieces but I do not see how the pieces give me a
> workable solution nor do I see how such a solution gives me
> interoperability.
>
> If I configure a subscription, how does the flow of notifications work
> over NC and RC? How do I configure where the connection goes?  What is
> the RC resource that provides me the notification stream?  How will
> all of this work if the endpoints in the future want to negotiate
> different encodings?
>
> Since you said you implemented this: What exactly did you implement,
> what did not leave out, what did have to add to make it work?
>
> /js
>
> On Tue, Jul 17, 2018 at 01:20:55PM +0000, Tim Jenkins (timjenki) wrote:
> > Juergen,
> >
> > To flip this around, I don’t understand where the difficulties are.
> >
> > But here’s what I see:
> >
> >   1.  The format of the update notifications should be the same whether
> the subscription is dynamic or configured for a given transport and
> encoding. I believe we have that.
> >   2.  There are some differences in out of band notifications when I
> last read the drafts in details; these were explained by the different
> connection setup contexts. But this is otherwise unrelated to configured
> subscriptions.
> >   3.  Since the transport specific details are now separate from the
> base line drafts, it allows transport specific behaviour to decide how the
> connections (for configured subscriptions) are to be setup. We have usable
> variations of “call home” or “dial out” or whatever you want to call it for
> the cases we need. Admittedly, we do have to provide augmentations for some
> of the protocols, but then, that’s the intent of the design.
> >
> > BTW, my comment below was sent last week. I have no idea how/why it
> arrived on the list after the IETF meeting yesterday.
> >
> > Tim
> >
> > --
> > Cisco Systems Canada Co.
> > 2000 Innovation Drive
> > Kanata, ON, Canada, K2K 3E8
> > Preferences <http://www.cisco.com/offer/subscribe/?sid=000478326>
> > Unsubscribe <http://www.cisco.com/offer/unsubscribe/?sid=000478327>
> > Privacy <http://www.cisco.com/web/siteassets/legal/privacy.html>
> >
> > From: Juergen Schoenwaelder <[e-mail]>
> > Reply-To: Juergen Schoenwaelder <[e-mail]>
> > Date: Tuesday, July 17, 2018 at 1:50 AM
> > To: "Tim Jenkins (timjenki)" <[e-mail]>
> > Cc: "[e-mail]" <[e-mail]>
> > Subject: Re: [Netconf] YangPush now
> >
> > I do not think that configured subscriptions have been fully worked
> > out. Nor do I see how I configure something that actually works.
> > Since you have implemented this, perhaps you can help me to understand
> > how all this actually works with the text in the current IDs.
> >
> > /js
> >
> > On Mon, Jul 16, 2018 at 11:10:52PM +0000, Tim Jenkins (timjenki) wrote:
> > Hi,
> > As an implementor of the drafts, I suggest enough already: we've been
> going down this path for quite some time.
> > Please publish both sets (dynamic and configured, and SN and YP)
> together.
> > Thanks,
> > Tim
> > > 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
> > mailto:[e-mail]
> > https://www.ietf.org/mailman/listinfo/netconf
> > --
> > Cisco Systems Canada Co.
> > 2000 Innovation Drive
> > Kanata, ON, Canada, K2K 3E8
> > Preferences <http://www.cisco.com/offer/subscribe/?sid=000478326>
> > Unsubscribe <http://www.cisco.com/offer/unsubscribe/?sid=000478327>
> > Privacy <http://www.cisco.com/web/siteassets/legal/privacy.html>
> > _______________________________________________
> > Netconf mailing list
> > [e-mail]<mailto:[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/>
> >
>
> --
> 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
>
>
>
>