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

[Martin Bjorklund <[e-mail]>]

Hi,

Benoit Claise <[e-mail]> wrote:
> 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.

You are right, fixed.

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

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


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

Of course, I try to be consistent.

> So keep your temp
> versions of RFC7223bis and RFC7277bis consistent as well.

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


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

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

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

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

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


/martin