Re: [netmod] Last Call: <draft-ietf-netmod-revised-datastores-09.txt> (Network Management Datastore Architecture) to Proposed Standard two

[Martin Bjorklund <[e-mail]>]

Hi Tom,

"tom p." <[e-mail]> wrote:
> Much of this I-D is about the idea that network management data objects
> can often take two different values.  The I-D always refers to this as
> being two values but is that a limit that this architecture imposes; or
> can it be more?

The I-D talks about two instantiations in the Objectives section, when
the original "config vs oper values" problem is explained, and how
NMDA solves the problem.

But the archtecture allows for any number of instantiations; it all
depends on which datastores a particular server implements.  For
example, a config node might have one value in <candidate>, a
different in <running> and yet a different value in <startup>.  This
is not new to this document.


> The later diagrams show  three datastores, <running>,
> <intended> and <operational>.  Since "<intended> MAY also be updated
> independently of <running> ", can there be three values?  And since the
> architecture says that other conventional configuration datastores may
> be defined in future, can there be any number more values?  I think this
> is a significant issue when set against the objectives, of exposing to
> the user
> what values there are in a server; the I-D is clear that there is one
> schema, but I
> am less certain about its insistence on two values.
> 
> In a sense, there is a datastore, perhaps more than one, missing.  The
> focus has been on configuration-related datastores and is now widening
> to put other object values into datastores.  Yet the values learnt
> from hardware, protocols and such like will only be in a datastore if
> that value is used and so is in <operational>.  If a user-configured
> value is the one put into <operational>, then values learnt by other
> means will not
> appear AFAICT.  For completeness, there should be a datastore for values
> learnt from the hardware, from protocols and so on.  (In fact, doing the
> sort of
> thing that routing protocols, which learn different routes to the same
> destination via different means, have been doing for years:-)

The architecture defined in this I-D defines a set of datastores, but
it also allows for new datastores defined in the future.  If a
datastore with "unused" values is needed, such a datastore can be
defined later.


/martin



> 
> Tom Petch
> 
> ----- Original Message -----
> From: "The IESG" <[e-mail]>
> Sent: Thursday, December 21, 2017 7:23 PM
> 
> > The IESG has received a request from the Network Modeling WG (netmod)
> to
> > consider the following document: - 'Network Management Datastore
> Architecture'
> >   <draft-ietf-netmod-revised-datastores-09.txt> as Proposed Standard
> >
> > The IESG plans to make a decision in the next few weeks, and solicits
> final
> > comments on this action. Please send substantive comments to the
> > [e-mail] mailing lists by 2018-01-10. Exceptionally, comments may
> be
> > sent to [e-mail] instead. In either case, please retain the
> beginning of
> > the Subject line to allow automated sorting.
> >
> > Abstract
> >
> >
> >    Datastores are a fundamental concept binding the data models
> written
> >    in the YANG data modeling language to network management protocols
> >    such as NETCONF and RESTCONF.  This document defines an
> architectural
> >    framework for datastores based on the experience gained with the
> >    initial simpler model, addressing requirements that were not well
> >    supported in the initial model.  This document updates RFC 7950.
> >
> >
> >
> >
> > The file can be obtained via
> > https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/
> >
> > IESG discussion can be tracked via
> >
> https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/ba
> llot/
> >
> >
> > No IPR declarations have been submitted directly on this I-D.
> >
> >
> >
> >
>