Hi, "Bogaert, Bart (Nokia - BE/Antwerp)" <bart.boga...@nokia.com> wrote: > Hi Martin, > > We had a discussion on this and we have some concerns about below > statement (behavior in the description statement): > > > This leaf can be configured. The configured value is used only if > > the server cannot determine the vendor-specific serial number from > > the component itself. > > For the above sentence “server cannot determine” we have 2 cases: > 1. It can’t be determined because there is nothing detected. > According to the NMDA-draft it is clear that in this case there is no > row for the associated component and hence no data. I think this case > is covered by the sentence in the latest draft-ietf-netmod-entity for > the list “component” where it is stated: “When the server detects a > new hardware component, it initializes a list entry in the operational > 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. /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