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

From: Adam Roach <[email-masked]>
Date: Wed, 10 Jan 2018 22:55:46 -0800

Adam Roach has entered the following ballot position for
draft-ietf-netmod-entity-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/

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

----

     typedef sensor-value-precision {
       type int32 {
         range "-8 .. 9";
       }

Why is this an int32 rather than an int8?

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 11 Jan 2018 08:13:17 +0100

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 (and his copy of the MIB module).

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

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 11 Jan 2018 09:49:24 +0100 (CET)

Hi,

Juergen Schoenwaelder <[email-masked]> wrote:
> 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

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.

> likely not important) departure from the MIB module.)

I agree.  I will make the change to int8.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 11 Jan 2018 10:12:59 +0100

On Thu, Jan 11, 2018 at 09:49:24AM +0100, Martin Bjorklund wrote:

> by libsmi, and it seems the MIB is not updated there ;-)

OK. My fault.

> Which leads

Yes. This is very subtle. Not changing the value would also have been
somewhat odd since tera and exa are then 'out of natural order'. But
it might have been more robust. Anyway, the errata says what it says
and all we can do now is likely to hope that people running into this
at the end find the errata linked to the RFC. Hence, I will commit the
errata fix to the libsmi repository now.

/js

---

From: Benoit Claise <[email-masked]>
Date: Thu, 11 Jan 2018 12:04:00 +0100

> errata fix to the libsmi repository now.
Exactly the discussion we've been having on the YANG doctor list.
"- errata on the YANG module inside a RFC: this is looking for troubles 
IMO."
Obviously the same applies for MIB modules.

Regards, Benoit