On Thu, Jan 04, 2018 at 12:37:02PM -0000, tom p. wrote: > This I-D illlustrates a problem that the netmod WG has been wrestling > with for a decade or more and (IMHO) has yet fully to solve. This I-D > is in Last Call at the same time as netmod-revised-datastores, which > proposes the most recent solution. > > The problem is that an 'object' can take more than one value and the > question is how to represent that. Previously it was by having twin > trees in the schema; now it is by having one common schema and multiple > datastores, <running> for the user-supplied values, <operational> for > those actually in use, the latter including values learnt from the > hardware or protocols or some other means. > > In this model the situation arises with 'serial-num' which may take a > value from the hardware or may be written as part of configuration (the > idea of configuring serial numbers may seem unusual but has been > inherited from the Entity MIB [RFC6933] with the endorsement of the > netmod WG). > > So if there is an accessible hardware value and the user writes a value, > who wins? There is no way of specifying this, neither in YANG nor in > 'revised-datastores'; in this case, the 'description' specifies that the > value determined from the component should be used so a user can > configure a value, see it in the <running> datastore but not in the > <operational> datastore and cannot tell why, unless they are familiar > with the minutiae of description clauses.
The origin attribute will at least tell you where the operationally used value is originating from. > In this case, the model is clear as to which value, configured or > learnt, wins; here, it is learnt. In other cases, it may be that > configured wins or that may be something a user wants to influence as > part of policy. > > Is that still one schema or is it now two slightly different schemas > based on the description clause coupled with the datastore that the > schema is being applied to? > > Is the description clause an adequate way of expressing policy? > > In passing, routing protocols addressed this dilemma a long time ago, > with concepts such as 'Admin Distance'. > > (Whether or not this particular value should be configurable is a > different and irrelevant discussion; the MIB WG decided it should be, > the YANG WG likewise - and there are plenty of other objects which > illustrate this dilemma, how to specify who wins). > > Tom Petch > > ----- Original Message ----- > From: "The IESG" <[email protected]> > Sent: Thursday, December 21, 2017 10:22 PM > > > The IESG has received a request from the Network Modeling WG (netmod) > to > > consider the following document: - 'A YANG Data Model for Hardware > Management' > > <draft-ietf-netmod-entity-07.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 > > [email protected] mailing lists by 2018-01-10. Exceptionally, comments may > be > > sent to [email protected] instead. In either case, please retain the > beginning of > > the Subject line to allow automated sorting. > > > > Abstract > > > > This document defines a YANG data model for the management of > > hardware on a single server. > > > > The file can be obtained via > > https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/ > > > > IESG discussion can be tracked via > > https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/ballot/ > > > > No IPR declarations have been submitted directly on this I-D. > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
