Hi, "Bogaert, Bart (Nokia - BE/Antwerp)" <bart.boga...@nokia.com> wrote: > Hi, > > --- snip --- > > > state.”, so the above sentence only applies for the second case below. > > Ok. > > > 2. The second case is that something is detected but it can’t be read. > > We do not see a reason to use the value configured for the leafs > > ‘serial-num’, ‘mfg-name’ and ‘model-name’ of a matching entry in the > > configuration data. These leafs are defined as optional so why would > > we report something entered by an operator in the operational > > datastore that intends to report on what is detected? Is it not > > better to not report them at all? In an NMDA context it would be > > possible to have a different value (or no value at all) for certain > > leafs while there is something in the running/intended datastore. > > The normal NMDA procedure for a configuration leaf is to repeat it in > operational state. This is then the "applied configuration". > I don't think we should have a special rule for these leafs. > > This also means that a client that just wants to read all the serial > numbers can do so from one place, the operational state, regardless of > how they came into existance. > > [Bogaert, Bart ] > > We do understand that a target of NMDA is to read out the actually > applied data in one request. But the result should not be > confusion. A key word is “applied”. > > Section 5.3 of draft-ietf-netmod-revised-datastores-09 also contains > (I put a part of the section between ***): > The datastore schema for <operational> MUST be a superset of the > combined datastore schema used in all configuration datastores except > that configuration data nodes supported in a configuration datastore > ***MAY be omitted from <operational> if a server is not able to > accurately report them ***.
Note that this text talks about the *schema*. It is intended for servers to migrate to NMDA without having to instrument all config nodes in <operational> immediately. If you apply this to ietf-hardware, it could be a server that implements the node "serial-num" in config, but not in <operational> (which would be weird). > For example, it is expected that the value of multiple leafs need to > be a consistent set, e.g. the mfg-name, the model-name, and the > serial-num. > Suppose we have a use case in which a hardware component is > planned/configured (e.g. a board supporting DSL interfaces) but a > different one is plugged (e.g. a board supporting ethernet > interfaces). > Suppose it is possible to read some fields on the detected component > but due to an issue not to read other fields. > If in that case the operational datastore will be completed with the > data taken from the running datastore, then the presented view might > be inconsistent. This is true for other similar nodes as well - "asset-id" and "uri". > The question is also: what data is applied? Our assumption: if there > is a mismatch between detected versus configured hardware, then the > interface/service related data that is configured consistently with > the planned hardware is not applied on the mismatching > hardware. I.e. the detected hardware is not brought in service so not > ‘applied’, the operational datastore only (accurately) reports on what > is detected. If there is a mismatch and the server doesn't apply the configured values, then obviously the configured 'mfg-name' etc are not copied to <operational>. > We do not see this as a special rule for this data but rather would > apply a general rule: > - if there is a ‘missing resource’, then the data is not reported in the > operational datastore. > - If the server is not able to report accurately, then the data is > omitted from the operational I think that if you want complete separation between the values of 'mfg-name', 'model-name', and 'serial-num' in configuration and operational state, then these should be modelled as separate leafs. We should have a config false leaf 'serial-num' that only contains the detected value (if found), and a config true leaf 'config-serial-num' or something, that contains the configured serial number. But if this is the case, I wonder if it wouldn't be better to leave such additional config objects to vendors, and simply make these three nodes config false in ietf-hardware. /martin > > Regards, Bart > > /martin > > > > > > Best regards, Bart > > > > -----Original Message----- > > From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Robert > > Wilton > > Sent: Thursday, December 21, 2017 4:14 PM > > To: Martin Bjorklund <m...@tail-f.com>; netmod@ietf.org > > Subject: Re: [netmod] AD review of draft-ietf-netmod-entity-06 > > > > Hi Martin, > > > > > > On 21/12/2017 11:37, Martin Bjorklund wrote: > > > Hi, > > > > > > I need WG input on this issue. The question is how to handle > > > 'serial-num', 'mfg-name', and 'model-name'. I think they should all > > > be treated the same. Based on previous WG discussion (see e.g. the > > > mail thread "draft-ietf-netmod-entity issue #13"), I think they > > > should all be configurable, but the configured value is only used in > > > operational state if the system cannot read it from the hardware. > > I think that this approach is probably OK: > > - The client can always see the real value if it is available. > > - If it is not available then they can assign a value via > > configuration. > > > > I was also considering an alternative approach of having a separate > > set of config false leaves for the "burnt in values". And then having > > the configurable leaves always override the default operational > > values. E.g. similar to how an interface MAC address would expect to > > be handled. > > > > But one set of leaves is probably sufficient. > > > > Thanks, > > Rob > > > > > > > > > > So I suggest the following changes: > > > > > > OLD: > > > > > > leaf serial-num { > > > type string; > > > config false; > > > description > > > "The vendor-specific serial number string for the > > > component. The preferred value is the serial number > > > string actually printed on the component itself (if > > > present)."; > > > reference "RFC 6933: entPhysicalSerialNum"; > > > } > > > > > > NEW: > > > > > > leaf serial-num { > > > type string; > > > description > > > "The vendor-specific serial number string for the > > > component. The preferred value is the serial number > > > string actually printed on the component itself (if > > > present). > > > > > > This leaf can be configured. There are two use cases for > > > this; as a 'post-it' note if the server cannot determine > > > this value from the component, or when pre-provisioning a > > > component. > > > > > > If the server can determine the serial number from the > > > component, then that value is always used in operational > > > state, even if another value has been configured."; > > > reference "RFC 6933: entPhysicalSerialNum"; > > > } > > > > > > And corresponding text for 'mfg-name' and 'model-name'. > > > > > > And also: > > > > > > OLD: > > > > > > When the server detects a new hardware component, it > > > initializes a list entry in the operational state. > > > > > > If the server does not support configuration of hardware > > > components, list entries in the operational state are > > > initialized with values for all nodes as detected by the > > > implementation. > > > > > > Otherwise, the following procedure is followed: > > > > > > 1. If there is an entry in the /hardware/component list in > > > the intended configuration with values for the nodes > > > 'class', 'parent', 'parent-rel-pos' that are equal to > > > the detected values, then: > > > > > > 1a. If the configured entry has a value for 'mfg-name' > > > that is equal to the detected value, or if the > > > 'mfg-name' value cannot be detected, then the list > > > entry in the operational state is initialized with the > > > configured values for all configured nodes, including > > > the 'name'. > > > > > > Otherwise, the list entry in the operational state is > > > initialized with values for all nodes as detected by > > > the implementation. The implementation may raise an > > > alarm that informs about the 'mfg-name' mismatch > > > condition. How this is done is outside the scope of > > > this document. > > > > > > 1b. Otherwise (i.e., there is no matching configuration > > > entry), the list entry in the operational state is > > > initialized with values for all nodes as detected by > > > the implementation. > > > > > > If the /hardware/component list in the intended > > > configuration is modified, then the system MUST behave as if > > > it re-initializes itself, and follow the procedure in > > > (1)."; > > > > > > NEW: > > > > > > When the server detects a new hardware component, it > > > initializes a list entry in the operational state. > > > > > > If the server does not support configuration of hardware > > > components, list entries in the operational state are > > > initialized with values for all nodes as detected by the > > > implementation. > > > > > > Otherwise, the following procedure is followed: > > > > > > 1. If there is an entry in the /hardware/component list in > > > the intended configuration with values for the nodes > > > 'class', 'parent', 'parent-rel-pos' that are equal to > > > the detected values, then the list entry in operational > > > state is initialized with the configured values, > > > including the 'name'. The leafs 'serial-num', > > > 'mfg-name', and 'model-name' are treated specially; see > > > their descriptions for details. > > > > > > 2. Otherwise (i.e., there is no matching configuration > > > entry), the list entry in the operational state is > > > initialized with values for all nodes as detected by > > > the implementation. > > > > > > If the /hardware/component list in the intended > > > configuration is modified, then the system MUST behave as if > > > it re-initializes itself, and follow the procedure in > > > (1)."; > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > Benoit Claise <bcla...@cisco.com> wrote: > > >> On 12/20/2017 4:00 PM, Martin Bjorklund wrote: > > >>> Benoit Claise <bcla...@cisco.com> wrote: > > >>>> Hi Martin, > > >>>> > > >>>> Thanks. > > >>>> Only kept the relevant excerpts. > > >>>>>> - Some objects are read-write in RFC6933: > > >>>>>> entPhysicalSerialNum > > >>>>>> entPhysicalAlias > > >>>>>> entPhysicalAssetID > > >>>>>> entPhysicalUris > > >>>>>> > > >>>>>> For example, entPhysicalSerialNum being read-write always bothered > > >>>>>> me. > > >>>>>> serial-num is now "config false", which is a good news IMO. > > >>>>> Actually, this was not the intention. In > > >>>>> draft-ietf-netmod-entity-03 this is configurable. I missed this > > >>>>> in the conversion to NMDA. > > >>>> Ah. So no good news in this case... > > >>>>>> In the reverse direction, entPhysicalMfgName is read-only in > > >>>>>> RFC6933, while it's "config true" in draft-ietf-netmod-entity > > >>>>> Yes, this was added per request from the WG. See e.g. the > > >>>>> thread "draft-ietf-netmod-entity issue #13". > > >>>> Sure. It was mainly an observation. > > >>>>> However, I think that what we have now is probably not correct. > > >>>>> I think that all nodes 'serial-num', 'mfg-name', and 'model-name' > > >>>>> should be config true, and the description of list 'component' > > >>>>> updated to reflect that all these tree leafs are handled the same way. > > >>>>> > > >>>>> I would like to know what the WG thinks about this. > > >>>> Talking as a contributor this time. > > >>>> It seems that inventory management is kind of broken when someone > > >>>> can change 'serial-num', 'mfg-name', and 'model-name. > > >>> They can't really change them. The configured values are only > > >>> used (i.e. visible in the operational state) if the device cannot > > >>> detect them automatically. I.e., they work as "post-it" notes only. > > >> If I look at, for example, the mfg-name, description, this is not > > >> what it says. > > >> > > >> leaf mfg-name { > > >> type string; > > >> description > > >> "The name of the manufacturer of this physical component. > > >> The preferred value is the manufacturer name string > > >> actually printed on the component itself (if present). > > >> > > >> Note that comparisons between instances of the model-name, > > >> firmware-rev, software-rev, and the serial-num nodes are > > >> only meaningful amongst component with the same value of > > >> mfg-name. > > >> > > >> If the manufacturer name string associated with the > > >> physical component is unknown to the server, then this > > >> node is not instantiated."; > > >> reference "RFC 6933 <https://tools.ietf.org/html/rfc6933>: > > >> entPhysicalMfgName"; > > >> > > >> Regards, Benoit > > >> > > >>> > > >>> /martin > > >>> . > > >>> > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > . > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
