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

[Benoit Claise <[e-mail]>]

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
> 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)
>
>
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod