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 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:-) Tom Petch ----- Original Message ----- From: "The IESG" <iesg-secretary@xxxxxxxx> 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 > ietf@xxxxxxxx mailing lists by 2018-01-10. Exceptionally, comments may be > sent to iesg@xxxxxxxx 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. > > > >