Re: [Netconf] YangPush now

[Andy Bierman <[e-mail]>]

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
 2) CallHome procedures and server requirements such as
     processing normal NC or RC requests on the session
 3) no MUST or SHOULD implement values for transport

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).
Just declaring everything done gets it out of the WG faster,
but may not mean the RFC will be out faster.



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
>