Re: [netmod] Last Call: <draft-ietf-netmod-entity-07.txt> (A YANG Data Model for Hardware Management) to Proposed Standard

["tom p." <[e-mail]>]

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.

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" <[e-mail]>
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
> [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
>
>    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.