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

From: "Bogaert, Bart (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 9 Jan 2018 14:38:57 +0000

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.
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.

Best regards, Bart

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Robert Wilton
Sent: Thursday, December 21, 2017 4:14 PM
To: Martin Bjorklund <[email-masked]>; [email-masked]
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-masked]> wrote:
>> On 12/20/2017 4:00 PM, Martin Bjorklund wrote:
>>> Benoit Claise <[email-masked]> 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-masked]
> https://www.ietf.org/mailman/listinfo/netmod
> .
>

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 09 Jan 2018 16:39:33 +0100 (CET)

Hi,

"Bogaert, Bart (Nokia - BE/Antwerp)" <[email-masked]> wrote:
> Hi Martin,
> 
> We had a discussion on this and we have some concerns about below
> statement (behavior in the description statement):
> 
> 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

> 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.
>

---

From: "Bogaert, Bart (Nokia - BE/Antwerp)" <[email-masked]>
Date: Wed, 10 Jan 2018 13:12:36 +0000

Hi,

--- snip ---

Ok.

> 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 ***.

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.
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.

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

Regards, Bart

/martin

> > mail thread "draft-ietf-netmod-entity issue #13"), I think they 
> > should all be configurable, but the configured value is only used in 
> >>>>> Yes, this was added per request from the WG.  See e.g. the 
> >>>>> thread "draft-ietf-netmod-entity issue #13".
> >>>>> However, I think that what we have now is probably not correct.  
> >>>>> I think that all nodes '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.

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 10 Jan 2018 14:44:53 +0100 (CET)

Hi,

"Bogaert, Bart (Nokia - BE/Antwerp)" <[email-masked]> wrote:
> 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>.

>  	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

---

From: Robert Wilton <[email-masked]>
Date: Wed, 10 Jan 2018 13:51:57 +0000

Hi,

> -	If the server is not able to report accurately, then the data is omitted from the operational
I was thinking that this would be a special case where a "system" 
provided value has precedence over an explicitly configured value:
  - If the hardware has a value, then that is what is reported with 
origin "system".
  - If the hardware has no value, but one is configured, then the 
configured value is reported with origin "intended".
  - If the hardware has no value, and none is configured, then no value 
is reported.

I see the aim of this approach is to provide the "in use" value on a 
single path.

But it may be helpful to have a second sets of 3 leaves here that report 
the "burnt-in" information.  These would always report what values are 
read from hardware, or nothing if no value was available. (this is 
similar to what we are doing for Ethernet MAC address).

An alternative approach would be to split the configured and operational 
values entirely, but then the client has the hassle of having to 
read/combine the two values together to get the useful "in use" value.

Thanks,
Rob

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 11 Jan 2018 14:47:05 +0100 (CET)

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

---

From: Benoit Claise <[email-masked]>
Date: Thu, 11 Jan 2018 14:57:46 +0100

Dear all,

draft-ietf-netmod-entity is the IESG telechat today.
In light of this discussion below, which I consider part of the IETF LC, 
I'll be deferring the document to the next IESG telechat in two weeks.
You have a few days to provide feedback on this propose solution 2.

Regards, Benoit (OPS AD).

---

From: Dan Romascanu <[email-masked]>
Date: Thu, 11 Jan 2018 16:01:51 +0200

Solution 2 seems fine to me at this stage.

Regards,

Dan

On Thu, Jan 11, 2018 at 3:57 PM, Benoit Claise <[email-masked]> wrote:

>>>> -       if there is a ‘missing resource’, then the data is not reported
>>>> in the
>>>>         operational datastore.
>>>>>>>>>>> For example, entPhysicalSerialNum being read-write always
>>>>>>>>>>> bothered
>>>>>>>>>>> me.

---

From: Robert Wilton <[email-masked]>
Date: Thu, 11 Jan 2018 17:56:28 +0000

> 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
Agreed.

Thanks,
Rob

---

From: "Bogaert, Bart (Nokia - BE/Antwerp)" <[email-masked]>
Date: Fri, 12 Jan 2018 09:20:56 +0000

Hi Martin,

We agree with option 2.

Regards, Bart

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: Thursday, January 11, 2018 2:47 PM
To: Bogaert, Bart (Nokia - BE/Antwerp) <[email-masked]>
Cc: [email-masked]
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':

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-masked]> wrote:
> > > ‘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".
> > numbers can do so from one place, the operational state, regardless 
> > of how they came into existance.
> > 
> > [Bogaert, Bart ]
> > 
> > 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 ***.
> 
> > 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.
> 
> > > > '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 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.
> > > 
> > > >>>>>> bothered me.
> > > >>>>>> In the reverse direction, entPhysicalMfgName is read-only 
> > > >>>>>> in RFC6933, while it's "config true" in 
> > > >>>>>> draft-ietf-netmod-entity
> > > >>>> It seems that inventory management is kind of broken when 
> > > >>>> someone can change 'serial-num', 'mfg-name', and 'model-name.
> > > >>> 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

---

From: "Einar Nilsen-Nygaard (einarnn)" <[email-masked]>
Date: Fri, 12 Jan 2018 10:52:29 +0000

Yes, Option 2 seems best.

Cheers,

Einar

> On 11 Jan 2018, at 17:56, Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco) <[email-masked]> wrote:
> 
> 
>

---

From: Joe Clarke <[email-masked]>
Date: Fri, 12 Jan 2018 08:33:04 -0500

> 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).

Joe

---

From: Benoit Claise <[email-masked]>
Date: Fri, 12 Jan 2018 19:55:57 +0100

> that are not field-writeable (certainly that is true from what I've seen
Yep, this is why I wrote in a previous email:

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)

---

From: Benoit Claise <[email-masked]>
Date: Mon, 22 Jan 2018 17:37:44 +0100

Dear all,

Since almost everyone who spoke up in the WG preferred option 2, let's 
go with that one.
Martin, can you please post a new draft version.

This document is on the IESG telechat this Thursday.

Regards, Benoit