Hi Martin, We agree with option 2.
Regards, Bart -----Original Message----- From: Martin Bjorklund [mailto:[email protected]] Sent: Thursday, January 11, 2018 2:47 PM To: Bogaert, Bart (Nokia - BE/Antwerp) <[email protected]> Cc: [email protected] Subject: Re: [netmod] AD review of draft-ietf-netmod-entity-06 Hi, To summarize this, I think we have three options for the three nodes 'model-name', 'mfg-name', and 'serial-num': 1. Do nothing (keep the nodes as config true). 2. Make these three nodes config false (fairly simple change). (vendors can augment w/ their own config true nodes). 3. Add three new nodes for the configured values. After thinking about this some more, and discussing with Benoit, I think the best path forward is to do 2, i.e., mark the nodes 'model-name', 'mfg-name', and 'serial-num' as "config false". As such they would not be configurable, and thus contain the detected values. If no value is detected, the node is not present. Note that 1 or 3 can be done in a future update to this module (or by a vendor). /martin Martin Bjorklund <[email protected]> wrote: > Hi, > > "Bogaert, Bart (Nokia - BE/Antwerp)" <[email protected]> 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:[email protected]] On Behalf Of Robert > > > Wilton > > > Sent: Thursday, December 21, 2017 4:14 PM > > > To: Martin Bjorklund <[email protected]>; [email protected] > > > 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 <[email protected]> wrote: > > > >> On 12/20/2017 4:00 PM, Martin Bjorklund wrote: > > > >>> Benoit Claise <[email protected]> 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 > > > > [email protected] > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > . > > > > > > > > > > _______________________________________________ > > > netmod mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
