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

From: Benoit Claise <[email-masked]>
Date: Wed, 20 Dec 2017 12:11:00 +0100

Dear all,

Here is my AD review of draft-ietf-netmod-entity-06.
Note that if you post the new version soon (before the end of this 
week), I could start the IETF last call, and the draft could be on Jan 
11th IESG telechat.

- I don't believe that the RFC 2119 keywords are right on the following 
sentences (SHOULD => should):

    o  The hardware data model SHOULD be suitable for new implementations
       to use as is.

    o  The hardware data model defined in this document can be
       implemented on a system that also implements ENTITY-MIB, thus the
       mapping between the hardware data model and ENTITY-MIB SHOULD be
       clear.

-

      1.2. Tree Diagrams

    Tree diagrams used in this document follow the notation defined in
    [I-D.ietf-netmod-yang-tree-diagrams 
<https://tools.ietf.org/html/draft-ietf-netmod-entity-06#ref-I-D.ietf-netmod-yang-tree-diagrams>].

You could remove the above and add the reference to section 3.

    This document defines the YANG module "ietf-hardware", which has the
    following structure [I-D.ietf-netmod-yang-tree-diagrams 
<https://tools.ietf.org/html/draft-ietf-netmod-entity-06#ref-I-D.ietf-netmod-yang-tree-diagrams>]:

Martin, be consistent with all your YANG modules. So keep your temp 
versions of RFC7223bis and RFC7277bis consistent as well.

- 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.
In the reverse direction, entPhysicalMfgName is read-only in RFC6933, while it's "config true" in draft-ietf-netmod-entity
You should mention these ro/rw differences with RFC6933.
There might be other differences.

-
UUIDorZero

entPhysicalUUID OBJECT-TYPE
     SYNTAX      UUIDorZero
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
             "This object contains identification information
             about the physical entity.  The object contains a
             Universally Unique Identifier, the syntax of this object
             must conform toRFC 4122, Section 4.1 <https://tools.ietf.org/html/rfc4122#section-4.1>.

             A zero-length octet string is returned if no UUID
             information is known."

The YANG module is:

          leaf uuid {
            type yang:uuid;
            config false;
            description
              "A Universally Unique Identifier of the component.";
            reference "RFC 6933 <https://tools.ietf.org/html/rfc6933>: entPhysicalUUID";
          }

Where:

  typedef uuid {
     type string {
       pattern '[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-'
             + '[0-9a-fA-F]{4}-[0-9a-fA-F]{12}';
     }
     description
      "A Universally Unique IDentifier in the string representation
       defined in RFC 4122.  The canonical representation uses
       lowercase characters.

       The following is an example of a UUID in string representation:
       f81d4fae-7dec-11d0-a765-00a0c91e6bf6
       ";
     reference
      "RFC 4122: A Universally Unique IDentifier (UUID) URN
                 Namespace";
   }

Again a difference between the MIB and YANG module to mention in the document?

Regards, Benoit (as OPS AD)

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 20 Dec 2017 14:32:53 +0100 (CET)

Hi,

Benoit Claise <[email-masked]> wrote:
> - sentences (SHOULD => should):
> 

You are right, fixed.

> You could remove the above and add the reference to section 3.

I guess, but having it in the introduction seems consistent with the
other documents.

> 
> Martin, be consistent with all your YANG modules.

Of course, I try to be consistent.

> So keep your temp

It would help if you pointed out the inconsistencies you found.

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

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

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.

> You should mention these ro/rw differences with RFC6933.

Ok.

>             must conform toRFC 4122, Section 4.1
>             <https://tools.ietf.org/html/rfc4122#section-4.1>.
> 

I can add, in the description of leaf "uuid":

  "If no UUID information is known for this component, this leaf is
  not instantiated."

/martin

---

From: Benoit Claise <[email-masked]>
Date: Wed, 20 Dec 2017 15:01:14 +0100

Hi Martin,

Thanks.
Only kept the relevant excerpts.
> this is configurable.  I missed this in the conversion to NMDA.
Ah. So no good news in this case...
> "draft-ietf-netmod-entity issue #13".
Sure. It was mainly an observation.
> 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. Now, an attacker who 
could modify YANG objects can do way more damage that playing with 
inventory management. "forwarding" in 
https://tools.ietf.org/html/draft-ietf-netmod-rfc7277bis-01 comes to mind.
>    "If no UUID information is known for this component, this leaf is
This works.

Thanks, Benoit

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 20 Dec 2017 16:00:20 +0100 (CET)

Benoit Claise <[email-masked]> wrote:
> 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.

/martin

---

From: Benoit Claise <[email-masked]>
Date: Wed, 20 Dec 2017 16:52:46 +0100

> 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

> .

---

From: Benoit Claise <[email-masked]>
Date: Wed, 20 Dec 2017 17:10:41 +0100

Dear all,

One more comment, which I forgot in my AD review.
The -state YANG module in the appendix should actually be "deprecated".

Regards, Benoit
> - I don't believe that the RFC 2119 keywords are right on the 
> following sentences (SHOULD => should):
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 21 Dec 2017 12:37:46 +0100 (CET)

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.

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Dec 2017 12:50:10 +0100

>            string actually printed on the component itself (if

The last sentence is not useful since nobody knows what 'preferred'
value means. So remove it.

>            this value from the component, or when pre-provisioning a

I do not think 'post-it' note helps to clarify things. What about
changing the second sentence to:

  The configured value is used only if the server cannot determine the
  vendor-specific serial number from the component itself.

I do not understand the pre-provisioning part. Something
pre-provisioning won't appear in <operational> and when it appears,
then the normal rules apply, no?

>            state, even if another value has been configured.";

This may not be needed if we use the above formulation.

> And corresponding text for 'mfg-name' and 'model-name'.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 21 Dec 2017 12:58:26 +0100 (CET)

> value means. So remove it.

This text comes from RFC 6933.  Do you really think it is not clear
what the intention is?

>   vendor-specific serial number from the component itself.

Works for me.

> then the normal rules apply, no?

Yes.

> This may not be needed if we use the above formulation.

Agreed.  So we'd have a single paragraph:

   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.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Dec 2017 13:03:36 +0100

> This text comes from RFC 6933.  Do you really think it is not clear

I guess I read too fast. No, the sentence is fine. My comment was wrong.

[...] 
 
>    the server cannot determine the vendor-specific serial number from

Yes, I think this covers it.

/js

---

From: Benoit Claise <[email-masked]>
Date: Thu, 21 Dec 2017 15:53:43 +0100

> Yes, I think this covers it.
That works for me.

Regards, B.

---

From: Robert Wilton <[email-masked]>
Date: Thu, 21 Dec 2017 15:13:35 +0000

Hi Martin,

> 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