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

Martin Bjorklund <mbj@tail-f.com> Wed, 20 December 2017 13:32 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF03C120724 for <netmod@ietfa.amsl.com>; Wed, 20 Dec 2017 05:32:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJB-Pka5PJy9 for <netmod@ietfa.amsl.com>; Wed, 20 Dec 2017 05:32:56 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2573B12422F for <netmod@ietf.org>; Wed, 20 Dec 2017 05:32:56 -0800 (PST)
Received: from localhost (h-85-209.A165.priv.bahnhof.se [94.254.85.209]) by mail.tail-f.com (Postfix) with ESMTPSA id 1AC3D1AE0388; Wed, 20 Dec 2017 14:32:54 +0100 (CET)
Date: Wed, 20 Dec 2017 14:32:53 +0100 (CET)
Message-Id: <20171220.143253.1584852195806955458.mbj@tail-f.com>
To: bclaise@cisco.com
Cc: netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <9e66674b-4c6b-94f4-5fb6-4013c390c5db@cisco.com>
References: <ad97d611-b647-e72e-3a20-65dd0b9cb06e@cisco.com> <9e66674b-4c6b-94f4-5fb6-4013c390c5db@cisco.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/3t6bOE25Avv96Sbt-8yoDm-32oA>
Subject: Re: [netmod] AD review of draft-ietf-netmod-entity-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Dec 2017 13:32:58 -0000

Hi,

Benoit Claise <bclaise@cisco.com>; 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