Re: [netmod] Adam Roach's No Objection on draft-ietf-netmod-entity-07: (with COMMENT)
On 1/11/2018 10:12 AM, Juergen Schoenwaelder wrote:
On Thu, Jan 11, 2018 at 09:49:24AM +0100, Martin Bjorklund wrote:
Will do. As it happens, I always just look into the MIBs distributed
by libsmi, and it seems the MIB is not updated there ;-)
OK. My fault.
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.
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.
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
/js
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Adam Roach's No Objection on draft-ietf-netmod-entity-07: (with COMMENT)
On Thu, Jan 11, 2018 at 09:49:24AM +0100, Martin Bjorklund wrote:
> Will do. As it happens, I always just look into the MIBs distributed
> by libsmi, and it seems the MIB is not updated there ;-)
OK. My fault.
> 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.
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
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103
Re: [netmod] Adam Roach's No Objection on draft-ietf-netmod-entity-07: (with COMMENT)
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 (and his copy of the MIB module).
> 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.)
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103
[netmod] Adam Roach's No Objection on draft-ietf-netmod-entity-07: (with COMMENT)
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?
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
