Re: [Netconf] Draft Charter Proposal for NETCONF WG

["Eric Voit (evoit)" <[e-mail]>]

Hi Juergen,

On your editing question below: all use cases I have been involved with read remote data, and as a result change local data.

If you want more specifics, requirements and some use cases are in Section 4 of the draft:  
https://tools.ietf.org/html/draft-voit-netmod-yang-mount-requirements-00
the particular BNG hosting of multiple VM are not represented in this draft though, but I am happy to rev this draft to add it if WG members are interested in evolving the requirements further.

Eric

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:[e-mail]]
> Sent: Friday, March 3, 2017 5:52 PM
> To: Eric Voit (evoit) <[e-mail]>> Cc: Alexander Clemm <[e-mail]>; ierman
> <[e-mail]>; Netconf <[e-mail]>
> Subject: Re: [Netconf] Draft Charter Proposal for NETCONF WG
> 
> On Fri, Mar 03, 2017 at 06:41:06PM +0000, Eric Voit (evoit) wrote:
> > > From: Juergen Schoenwaelder, March 3, 2017 6:52 AM
> > >
> > > On Fri, Mar 03, 2017 at 11:05:53AM +0000, Eric Voit (evoit) wrote:
> > > >
> > > >
> > > > > From: Juergen Schoenwaelder, March 3, 2017 4:24 AM
> > > > >
> > > > > On Fri, Mar 03, 2017 at 01:01:10AM +0000, Alexander Clemm wrote:
> > > > > >
> > > > > > An operator doesn't want external systems to individually
> > > > > > address every
> > > > > control plane VM.  Rather they want a YANG model for this
> > > > > logical+physical combination.  In this case each VM might use
> > > > > logical+Peer
> > > > > (data) Mount to build a multi-device abstraction.  BTW: doing it
> > > > > this way also allows the same mounted YANG object data to be
> > > > > addressably exposed for each VM without requiring another YANG
> > > > > model to
> > > be made.
> > > > > >
> > > > >
> > > > > My question since the very beginning is: Is the idea to run
> > > > > configuration editing transactions across mount points?
> > > >
> > > > My position is that there is huge value in read only access.  I
> > > > have no desire to
> > > champion edit operations.
> > > >
> > >
> > > Reading data of course has value but then NETCONF has this little
> > > 'CONF' in its name...
> > >
> > > Anyway, if the peer mount is designed as a read-only access
> > > mechanism, how are the VMs then configured? I suppose there then
> > > needs to be a different addressing mechanism to access the VM's
> > > configuration data, e.g., something Andy was hinting at. Or how does this
> work?
> >
> > There are lots of ways to approach this problem, but for this particular use
> case often it is unnecessary.   Configuration attempts from outside the box are
> often supposed to be global or VM agnostic across the box.  So each of the VMs
> then simply Peer Mount the global configuration data.  This eliminates lots of
> error-cases as it becomes very hard to push configuration data out of synch as
> you aren't exposing ways to do this.
> >
> 
> Which particular use case are we providing a solution for?
> 
> I understand edit transactions crossing mount points is not needed for the
> particular use case. Does your particular use case support editing transactions
> within a mount point? Or is your particular use case a completely read-only
> mount and applications have to use an entirely different access mechanism to
> make any changes? Or is the particular use case applications that never change
> anything?
> 
> /js
> 
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>