Re: [Netconf] Subscription Use Cases

[Andy Bierman <[e-mail]>]

On Fri, Dec 9, 2016 at 5:33 AM, Martin Bjorklund <[e-mail]> wrote:

> "Eric Voit (evoit)" <[e-mail]> wrote:
> > > From: Martin Bjorklund, December 9, 2016 3:27 AM
> > >
> > > "Eric Voit (evoit)" <[e-mail]> wrote:
> > > > Hi Martin,
> > > >
> > > > > From: Martin Bjorklund, December 8, 2016 4:08 AM
> > > > >
> > > > > I think your requirements below are more like driving forces for
> > > > > YANG push, right?  Is there any of these that affects the solution
> > > > > in RFC 5277?
> > > >
> > > > The majority of these cases need yang-push.  But yang push is only
> > > > possible when the information is yang modeled.
> > >
> > > Sure, but that's a completely different thing.
> > >
> > > This discussion is about what needs to be done with RFC 5277.  I'll
> re-iterate
> > > what Andy wrote once more:
> > >
> > >   What are the must-have, should-have, and nice-to-have features that
> are
> > >   missing from RFC 5277?
> >
> > At a high level incremental functionality we have been discussing since
> IETF 94, 95, 96, 97 includes:
> > - configured subscriptions
> > - many subscriptions per transport
> > - modify and delete subscriptions
> > - control plane notifications
> > - Restconf & HTTP support
> > - Data plan notification including subscription-id
> >
> > At a medium level, existing documentation detailing these requirements
> can be seen in places like:
> > https://www.ietf.org/proceedings/95/slides/slides-95-netconf-7.pdf
>  Slide 5
> > https://www.ietf.org/proceedings/96/slides/slides-96-netconf-5.pdf
>  Slides 5, 28
> > https://www.ietf.org/proceedings/97/slides/slides-
> 97-netconf-draft-ietf-netconf-yang-push-01.pdf  Slides 20 & 21
>
> I think the list above summarizes what's in the slides.
>
> So, let me re-order this list a bit:
>
> - configured subscriptions
> - many subscriptions per transport
>   - Data plan notification including subscription-id
>   - modify and delete subscriptions
>
> I don't view "control plane notifications" as a deficiency of 5277; it
> already has a few, and if new functionality requires us to define more
> control plane notifications, that's not a problem.
>
> As for "Restconf & HTTP support", RESTCONF already supports
> notifications, and there need to be a RESTCONF-specific solution in
> place.  I do agree that if we open 5277, we should make sure we have a
> small protocol-dependent part, and a generic, protocol-independent
> part.
>
> So there are really two (major) requirements:
>
>   1.  configured subscriptions
>   2.  many subscriptions per transport session
>
> Do you agree, or did I miss anything?
>
> (1) can be done completely backwards compatible; in fact it might not
> even require an update to 5277.
>
> (2) requires an update to the <notification> element, as discussed
> earlier.
>
> Did you want to make support for (2) mandatory to implement?  If so,
> we need to make :interleave mandatory, or remove it.
>
> Maybe it should be noted that when SSH is used, there really is no
> need for (2), since it is trivial and cheap to open new SSH channels.
> I thus assume that the reason for wanting to do (2) is that sessions
> are expensive when SSH is not used.
>
>

Why are configured subscriptions needed if we have Call-home for both
NETCONF and RESTCONF?
I prefer 1 mandatory-to-implement RPC instead of duplicated optional
solutions.
The new feature is really "server initiates notifications upon a reboot",
not "configured notifications".



>
>
> /martin
>
>

Andy


>
>
> >
> > At a detailed level, I2RS's RFC-7923 has functional requirements for
> yang subscriptions. This is what was requested by the WG to be made
> available for event notifications.
> > as well as various WG meeting minutes.
> >
> > And of course the existing WG minutes, the four draft document
> appendices, and the Dezign team minutes at:
> > https://github.com/netconf-wg/yang-push/wiki/Minutes
> > Attempts to keep a running list of to-be-resolved dialogs.  Of course
> there is a lag between dialogs and embodiment in the drafts.
> >
> > If anyone wants to propose a revision to the requirements, I propose
> they do this as deltas from the existing documentation.
> >
> > Or course we in the WG can and should discuss and tweak any specific
> requirement on this mailer based on ongoing learnings over time.
> >
> > Eric
> >
> > > /martin
> >
>