Re: [netmod] AD review of draft-ietf-netmod-entity-06

[Benoit Claise <[e-mail]>]

On 1/12/2018 2:33 PM, Joe Clarke wrote:
> On 1/12/18 05:52, Einar Nilsen-Nygaard (einarnn) wrote:
>> Yes, Option 2 seems best.
> Agreed.  I believe most assume these are static values from the vendor
> that are not field-writeable (certainly that is true from what I've seen
> here at Cisco).
Yep, this is why I wrote in a previous email:

    For example, entPhysicalSerialNum being read-write always bothered me.
    serial-num is now "config false", which is a good news IMO.

So option 2 seems about right to me.
Would be nice if the new draft explain that/how people can augment.

Regards, Benoit (as a contributor)
>
> Joe
>
>> Cheers,
>>
>> Einar
>>
>>
>>> On 11 Jan 2018, at 17:56, Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco) <[e-mail]> wrote:
>>>
>>>
>>>
>>> On 11/01/2018 13:47, Martin Bjorklund wrote:
>>>> 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.
>>> Option 2 suits me.  It keeps it simple.
>>>
>>>> Note that 1 or 3 can be done in a future update to this module (or by
>>>> a vendor).
>>> Agreed.
>>>
>>> Thanks,
>>> Rob
>>>
>>>
>>>>
>>>> /martin
>>>>
>>>>
>>>> Martin Bjorklund <[e-mail]> wrote:
>>>>> Hi,
>>>>>
>>>>> "Bogaert, Bart (Nokia - BE/Antwerp)" <[e-mail]> 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:[e-mail]] On Behalf Of Robert
>>>>>>> Wilton
>>>>>>> Sent: Thursday, December 21, 2017 4:14 PM
>>>>>>> To: Martin Bjorklund <[e-mail]>; [e-mail]
>>>>>>> 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 <[e-mail]> wrote:
>>>>>>>>> On 12/20/2017 4:00 PM, Martin Bjorklund wrote:
>>>>>>>>>> Benoit Claise <[e-mail]> 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
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>>>> .
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> netmod mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>> _______________________________________________
>>>> netmod mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>> _______________________________________________
>>> netmod mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/netmod
>> _______________________________________________
>> netmod mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod
>>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod