Re: [Netconf] Subscription Use Cases

[Martin Bjorklund <[e-mail]>]

"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.



/martin



> 
> 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
>