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
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
- [netmod] Adam Roach's No Objection on draft-ietf-… Adam Roach
- Re: [netmod] Adam Roach's No Objection on draft-i… Juergen Schoenwaelder
- Re: [netmod] Adam Roach's No Objection on draft-i… Juergen Schoenwaelder
- Re: [netmod] Adam Roach's No Objection on draft-i… Martin Bjorklund
- Re: [netmod] Adam Roach's No Objection on draft-i… Benoit Claise