Re: [Netconf] YangPush now

[Andy Bierman <[e-mail]>]

On Thu, Jul 12, 2018 at 4:26 PM, Alexander Clemm <[e-mail]
> wrote:

> Hi Kent,
>
> good - so we agree that we are too far down the road to change things and
> revert back to where we started a few years ago.  I thought that therefore
> we can just close on these things without opening everything up again.
> This is why I was irritated at calling for a hum.  IMHO we should pass the
> whole package, including YP and SN, and including configured and dynamic
> (another decision we had made a long time ago).  I agree with Balazs'
> sentiment that we needed this yesterday.  We should be looking for ways to
> bring this to swift conclusion (and refactoring documents and rearranging
> major concepts all take their time) - much more important than trying to
> perfect it at this point in time IMHO.
>
>

What if SN did not wait for client-server?
What would that look like?

Perhaps:

      choice receiver-address {
        case standalone-tcp {
           leaf address {}
           leaf port {}
        }
      }

What if the address/port leafs were part of a choice, so different cases
can be augmented from new modules or proprietary modules?

But SN depends on ietf-network-instance which is not done,
which depends on schema-mount which is not done...



> --- Alex
>
>
Andy


> > -----Original Message-----
> > From: Kent Watsen [mailto:[e-mail]]
> > Sent: Thursday, July 12, 2018 2:38 PM
> > To: Alexander Clemm <[e-mail]>; Henk Birkholz
> > <[e-mail]>; Andy Bierman <[e-mail]>;
> > Robert Wilton <rwilton=[e-mail]>
> > Cc: Netconf <[e-mail]>
> > Subject: Re: [Netconf] YangPush now
> >
> > Hi Alex,
> >
> > Addressing your second point first, as you say, we're too far down the
> road to
> > consider YP w/o SN.  I think Andy was just reflecting how things
> could've been
> > different if we turned back time.
> >
> > Regarding your first point, I agree that the delta may not be much, but
> YP is also
> > a large document (56 pages) and, if only to help better focus the WG,
> the chairs
> > will probably run the LCs on these two drafts sequentially anyway.  Just
> speaking
> > for myself, I haven't reviewed YP seriously yet, as I've been waiting
> for the dust
> > to settle on the SN layer first.  In theory, my review should go easy,
> since YP
> > builds on top of SN (the harder to define layer) and also because YP has
> been
> > improved by others already, but that's all part of the unknown behind
> hum #2.
> > Makes sense?
> >
> > Kent
> >
> >
> > ===== original message =====
> >
> > On 2): not sure I understand that particular hum; I don't see what would
> be
> > gained by separating them.  YP builds on SN but it is ready.    If the
> WG decides
> > to refactor SN to move configured subscriptions out, sure, YP needs to be
> > updated to make sure this is reflected, but this should be
> straightforward.  If
> > separating YP and SN would accelerate them (or at least one of them),
> sure, but
> > I am not clear why this would be the case.
> >
> > To the question on putting YP out without SN: this is a well-intended
> suggestion
> > even if it seems a bit ironic given SN was originally created by taking
> it out as a
> > generalizable piece from YP that would be useful for notifications other
> than
> > push updates per decision of the WG.  Changing YP now to become a self-
> > contained piece would mean reverting on this; I am not convinced it is a
> good
> > idea to do so this late in the game and would rather have us see this
> through as
> > we had planned.
> >
> > --- Alex
> >
> > > -----Original Message-----
> > > From: Netconf [mailto:[e-mail]] On Behalf Of Kent
> > > Watsen
> > > Sent: Thursday, July 12, 2018 11:48 AM
> > > To: Henk Birkholz <[e-mail]>; Andy Bierman
> > > <[e-mail]>; Robert Wilton
> > > <rwilton=[e-mail]>
> > > Cc: Netconf <[e-mail]>
> > > Subject: Re: [Netconf] YangPush now
> > >
> > >
> > > > 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
> > >
> >
>
>