Re: [netmod] Adam Roach's No Objection on draft-ietf-netmod-entity-07: (with COMMENT)

Martin Bjorklund <mbj@tail-f.com> Thu, 11 January 2018 08:49 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 1732C12EABB; Thu, 11 Jan 2018 00:49:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] 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 DCJBy3uavYIB; Thu, 11 Jan 2018 00:49:26 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC6412EAB8; Thu, 11 Jan 2018 00:49:26 -0800 (PST)
Received: from localhost (unknown [173.38.220.56]) by mail.tail-f.com (Postfix) with ESMTPSA id 1178C1AE00B6; Thu, 11 Jan 2018 09:49:25 +0100 (CET)
Date: Thu, 11 Jan 2018 09:49:24 +0100 (CET)
Message-Id: <20180111.094924.121178859287289476.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
Cc: adam@nostrum.com, iesg@ietf.org, netmod-chairs@ietf.org, draft-ietf-netmod-entity@ietf.org, netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <20180111071317.wvqyyufx4bkyz5pi@elstar.local>
References: <151565374680.30635.814396227713285360.idtracker@ietfa.amsl.com> <20180111071317.wvqyyufx4bkyz5pi@elstar.local>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/0OUg0OvVTZ4PaluYY-g-B1_Gmb8>
Subject: Re: [netmod] Adam Roach's No Objection on draft-ietf-netmod-entity-07: (with COMMENT)
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: Thu, 11 Jan 2018 08:49:28 -0000

Hi,

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> On Wed, Jan 10, 2018 at 10:55:46PM -0800, Adam Roach wrote:
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> > 
> > I have one correction and one question about the ietf-hardware YANG module.
> > 
> >          enum exa {
> >            value 14;
> >            description
> >              "Data scaling factor of 10^15.";
> >          }
> >          enum peta {
> >            value 15;
> >            description
> >              "Data scaling factor of 10^18.";
> >          }
> > 
> > I believe this is backwards -- "peta" should be 10^15, while "exa" should be 10^18.
> 
> I agree this is wrong. This bug was most likely inherited from RFC
> 3433 but luckily there is a confirmed errata for RFC 3433. So Martin
> should fix this in the YANG module

Yes, it was inherited from the MIB.  I will fix this in the YANG module.

(and his copy of the MIB module).

Will do.  As it happens, I always just look into the MIBs distributed
by libsmi, and it seems the MIB is not updated there ;-)  Which leads
to an interesting issue - the errata for the MIB not only changes the
description in the comment, but it also changes the *value*.  I will
thus do the same in the YANG module:

      enum peta {
        value 14;
        description
          "Data scaling factor of 10^15.";
      }
      enum exa {
        value 15;
        description
          "Data scaling factor of 10^18.";
      }

This matches the verified MIB Errata, but since the original MIB is
probably present in most distributions, I wouldn't be surprised if
this object is not correctly implemented in real code...  When I
googled for the MIB I found several instances of NON-updated MIBs, and
zero instances of an updated MIB.

> >      typedef sensor-value-precision {
> >        type int32 {
> >          range "-8 .. 9";
> >        }
> > 
> > Why is this an int32 rather than an int8?
> 
> Likely because they way this was defined in the MIB module:
> 
>    SYNTAX Integer32 (-8..9)
> 
> I assume using int8 would be fine as well. (Note that YANG update
> rules allow to expand the range restriction but they do not allow to
> replace int8 with int32; so the range resulting from the type is a
> hard limit, the range restriction is an expandable limit. I guess in
> this case using int8 would be safe but then this is a slight (but
> likely not important) departure from the MIB module.)

I agree.  I will make the change to int8.


/martin