Subject: [yang-doctors] order of enums/bits value/position

From: Andy Bierman <[email-masked]>
Date: Sat, 19 Nov 2016 15:18:44 -0800

Hi,

Benoit asked me to make yangdump-pro more consistent with pyang
wrt/ YANG warnings.

yangdump-pro checks for enum values and bit positions to be in ascending
order.
pyang does not check. Lada has a YANG module is values in descending order.

IMO, this is a real warning because auto-numbering is always ascending,
so if it gets used, people may think auto-numbers also goes down, not up,
It is also the convention used in MIB modules forever. It also allows a
simple
canonical order.

I do not want to bias YANG Usage guidelines (this is not mentioned in YANG
or 6087bis),
so I will take out the warning if YANG doctors think there is no value in
a consistent ordering of enum and bit statements within YANG modules.

Should I take out the warning or leave it in?
If yes, does this guideline need to be added to 6087bis?

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 20 Nov 2016 09:49:52 +0100

> On 20 Nov 2016, at 00:18, Andy Bierman <[email-masked]> wrote:
> 
> Hi,
> 
> yangdump-pro checks for enum values and bit positions to be in ascending order.

It's not my module but ietf-isis-sr in this draft:

https://tools.ietf.org/html/draft-ietf-isis-sr-yang-00

The warnings then show up in Benoit's module verification table.

> It is also the convention used in MIB modules forever. It also allows a simple
> canonical order.

It's like deciding which endianness is better. Sometimes the highest bit can really be the most significant, and then it may make sense to start with it. I think the rules are clear so module authors/implementors should be able to figure out what numbers are auto-assigned. In fact, 6087bis should probably warn against combining explicit positions (and enum values) with autonumbering in the same bits (or enumeration) type.

> 
> I do not want to bias YANG Usage guidelines (this is not mentioned in YANG or 6087bis),

At least you should add a command-line flag to switch off warnings that are based neither on 7950 nor on 6087bis.

Lada

> 
> 
> Andy
> 
> _______________________________________________
> yang-doctors mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/yang-doctors

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Sun, 20 Nov 2016 04:38:21 -0800

On Sun, Nov 20, 2016 at 12:49 AM, Ladislav Lhotka <[email-masked]> wrote:

> It's like deciding which endianness is better. Sometimes the highest bit
> can really be the most significant, and then it may make sense to start
> with it. I think the rules are clear so module authors/implementors should
> be able to figure out what numbers are auto-assigned. In fact, 6087bis
> should probably warn against combining explicit positions (and enum values)
> with autonumbering in the same bits (or enumeration) type.
>

I disagree.
They are conceptually the same as in MIB modules
and the convention for 30 years has been ascending numbers.

> At least you should add a command-line flag to switch off warnings that
> are based neither on 7950 nor on 6087bis.
>
> Lada
>
>

Andy

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Sun, 20 Nov 2016 20:32:58 +0100

Inline

> At least you should add a command-line flag to switch off warnings that are based neither on 7950 nor on 6087bis.
I am with Lada here. If the warnings are questionable, then at least allow for
a switch to suppress them.

I do not want to accuse you of "perkenisms". But back in the MIB days, Dave Perkins
had a lot of warnings that he thought made sense but we certainly did not have
consensus on those. So (as AD at the time) I was able to convince Dave to add
command line switches to suppress them.

Bert

---

From: Andy Bierman <[email-masked]>
Date: Sun, 20 Nov 2016 13:29:16 -0800

> command line switches to suppress them.
I am asking YANG doctors for informed opinions, not SNMP stories.

Note that there is no text at all in 7950 or 6087bis that says statements
need to be in
the canonical order in the ABNF.  This is a very severe constraint imposed
by pyang
that is not stated anywhere.

I can make an --extra-warnings flag but the rationale should apply to all
style guidelines not mentioned in 7950 or 6087bis.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sun, 20 Nov 2016 14:31:42 -0800

Hi,

Benoit, use --warn-off=1022 to suppress the out of order warning.
The total warnings will still be incremented
.
The next release will change this behavior to completely ignore the
disabled warning
so the final warning count will not be incremented.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 21 Nov 2016 08:51:57 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> It's like deciding which endianness is better.

Maybe, but even so, it is better to pick one order and stick to it.
It just makes it easier to read and understand if things are consistent.

So I'm with Andy on this one.  I think the warning makes sense.  I'm
also ok with adding it to 6087bis.

/martin

>Sometimes the highest bit can really be the most significant, and then it may make sense to start with it. I think the rules are clear so module authors/implementors should be able to figure out what numbers are auto-assigned. In fact, 6087bis should probably warn against combining explicit positions (and enum values) with autonumbering in the same bits (or enumeration) type.
> 
> >

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 21 Nov 2016 10:20:15 +0100

> On 21 Nov 2016, at 08:51, Martin Bjorklund <[email-masked]> wrote:
> 

I disagree. In fact, I also think that insisting on the order of substatements is questionable. When writing my modules, I often feel, for example, that putting description as the first substatement of "leaf" would make the definition more clear.

I am not sure that referring to MIB conventions is relevant today. 25 years ago, computing resources were incomparable to what we have now, so making MIB module parsing as simple as possible made sense back then.

> also ok with adding it to 6087bis.

OK, but then it has to be discussed in the NETMOD mailing list.

Lada

---

From: Benoit Claise <[email-masked]>
Date: Wed, 23 Nov 2016 16:37:05 +0100

YANG doctors,

[including Radek as I'm in the middle of inserting yanglint]

First of, this discussion is welcome. Comparing the YANG compiler 
results clarified our understanding of the YANG spec. And some bugs have 
been fixed lately in the compilers, both the opensource and commercial 
ones.

IF there is some value in providing indication to YANG module authors 
that their modules pass compilation BASED ON THE OUTCOME OF ALL 
COMPILERS (as opposed to providing only the compiler outcomes), then we 
need to understand what a warning means. Btw, I believe there is some 
value: we always overestimate the knowledge of YANG module authors, the 
time they have to learn all YANG details, and their willingness to 
learn. For example, most YANG module authors do not care about this 
ascending issue: they see a warning, and will correct the YANG module 
according.

For pyang, "error" means that you fail a MUST and "warning" means that 
you fail a SHOULD. I guess this is the same for confdc. Radek, Andy, 
what is your convention?
It would be nice to have a consistent convention.

Finally, the point is not to hide message with " --warn-off=1022" just 
to make nice stats. I don't care about that.
We need a discussion and if the YANG doctors (and the community) agrees, 
then it should be in RFC6087bis.
If the YANG doctors can't agree, then maybe this specific Yumaworks 
warning is at the level of "advice" and should be labeled as such.

Regards, Benoit

---

From: Andy Bierman <[email-masked]>
Date: Wed, 23 Nov 2016 10:41:32 -0800

On Wed, Nov 23, 2016 at 7:37 AM, Benoit Claise <[email-masked]> wrote:

> First of, this discussion is welcome. Comparing the YANG compiler results
> clarified our understanding of the YANG spec. And some bugs have been fixed
> lately in the compilers, both the opensource and commercial ones.
>
> IF there is some value in providing indication to YANG module authors that
> their modules pass compilation BASED ON THE OUTCOME OF ALL COMPILERS (as
> opposed to providing only the compiler outcomes), then we need to
> understand what a warning means. Btw, I believe there is some value: we
> always overestimate the knowledge of YANG module authors, the time they
> have to learn all YANG details, and their willingness to learn. For
> example, most YANG module authors do not care about this ascending issue:
> they see a warning, and will correct the YANG module according.
>
> For pyang, "error" means that you fail a MUST and "warning" means that you
> fail a SHOULD. I guess this is the same for confdc. Radek, Andy, what is
> your convention?

I think yangdump-pro does the same

>
> Finally, the point is not to hide message with " --warn-off=1022" just to
> make nice stats. I don't care about that.
You do not have to use yangdump-pro if you do not want to use it.
A warning means "take a look at this -- are you sure this is what you
meant."
Customers who get that warning change their modules because consistency is
good
and they get that (unlike YD)

Andy

>> I disagree. In fact, I also think that insisting on the order of
>> substatements is questionable. When writing my modules, I often feel, for
>> example, that putting description as the first substatement of "leaf" would
>> make the definition more clear.
>>
>> I am not sure that referring to MIB conventions is relevant today. 25
>> years ago, computing resources were incomparable to what we have now, so
>> making MIB module parsing as simple as possible made sense back then.
>>
>>> Sometimes the highest bit can really be the most significant, and then
>>>> it may make sense to start with it. I think the rules are clear so module
>>>> authors/implementors should be able to figure out what numbers are
>>>> auto-assigned. In fact, 6087bis should probably warn against combining
>>>> explicit positions (and enum values) with autonumbering in the same bits
>>>> (or enumeration) type.
>>>>

---

From: Radek Krejčí <[email-masked]>
Date: Thu, 24 Nov 2016 09:56:27 +0100

Hi,
yanglint implements RFC 6020 and 7950, not 6087 - we plan to improve libyang and yanglint according to 6087, but since it is informational, it seems to us as guidelines how to format output than how to parse input. In libyang/yanglint, failed MUST is definitely an error, but failed SHOULD is not a warning in all cases. For example, invalid filename format (different name of the module in the file) is warning, because we use the filenames when searching for includes and imports, so it is important to have the correct filenames. On the other hand, prefix in the XML data file that differs from the one defined in the module (sec. 7.1.4) is not a warning, because it is not an issue for us.

Regards,
Radek

Dne 23.11.2016 v 16:37 Benoit Claise napsal(a):
> First of, this discussion is welcome. Comparing the YANG compiler results clarified our understanding of the YANG spec. And some bugs have been fixed lately in the compilers, both the opensource and commercial ones.
>
> IF there is some value in providing indication to YANG module authors that their modules pass compilation BASED ON THE OUTCOME OF ALL COMPILERS (as opposed to providing only the compiler outcomes), then we need to understand what a warning means. Btw, I believe there is some value: we always overestimate the knowledge of YANG module authors, the time they have to learn all YANG details, and their willingness to learn. For example, most YANG module authors do not care about this ascending issue: they see a warning, and will correct the YANG module according.
>
> For pyang, "error" means that you fail a MUST and "warning" means that you fail a SHOULD. I guess this is the same for confdc. Radek, Andy, what is your convention?
> Finally, the point is not to hide message with " --warn-off=1022" just to make nice stats. I don't care about that.
> We need a discussion and if the YANG doctors (and the community) agrees, then it should be in RFC6087bis.
> If the YANG doctors can't agree, then maybe this specific Yumaworks warning is at the level of "advice" and should be labeled as such.
>
> Regards, Benoit

---

From: Benoit Claise <[email-masked]>
Date: Fri, 25 Nov 2016 09:11:01 +0100

Andy,
>
>
> On Wed, Nov 23, 2016 at 7:37 AM, Benoit Claise <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     YANG doctors,
>
>     results clarified our understanding of the YANG spec. And some
>     bugs have been fixed lately in the compilers, both the opensource
>     and commercial ones.
>
>     IF there is some value in providing indication to YANG module
>     authors that their modules pass compilation BASED ON THE OUTCOME
>     OF ALL COMPILERS (as opposed to providing only the compiler
>     outcomes), then we need to understand what a warning means. Btw, I
>     believe there is some value: we always overestimate the knowledge
>     of YANG module authors, the time they have to learn all YANG
>     details, and their willingness to learn. For example, most YANG
>     module authors do not care about this ascending issue: they see a
>     warning, and will correct the YANG module according.
>
>     For pyang, "error" means that you fail a MUST and "warning" means
>     that you fail a SHOULD. I guess this is the same for confdc.
>     Radek, Andy, what is your convention?
>     Finally, the point is not to hide message with " --warn-off=1022"
>     just to make nice stats. I don't care about that.
>     If the YANG doctors can't agree, then maybe this specific
>     Yumaworks warning is at the level of "advice" and should be
>     labeled as such.
>
>
I've been sleeping on this negative remark, trying not to overreact.
For the community interest (which is my priority), I will keep the 
yumadump-pro compilation results.
> Customers who get that warning change their modules because 
> consistency is good
Regards, Benoit

---

From: Andy Bierman <[email-masked]>
Date: Fri, 25 Nov 2016 08:08:48 -0800

Hi,

If you do not like a warning, turn it off.
Sorry you think that is negative.

Andy

On Fri, Nov 25, 2016 at 12:11 AM, Benoit Claise <[email-masked]> wrote:

>> that their modules pass compilation BASED ON THE OUTCOME OF ALL COMPILERS
>> (as opposed to providing only the compiler outcomes), then we need to
>> you fail a SHOULD. I guess this is the same for confdc. Radek, Andy, what
>> is your convention?

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Fri, 25 Nov 2016 21:55:32 +0100

In my view, I would do syntax check/compile with strict options, so I see all
warnings. I would then check that the warnings are not mistakes but the way
I intended it to be.

Then I will turn off the warnings, so I get a clean syntax check.

That is just how I worked with the smicng syntax checking and that is
how I would prefer to work with YANG syntax checking.

Makes sense?

Bert

---

From: Benoit Claise <[email-masked]>
Date: Fri, 25 Nov 2016 22:45:34 +0100

Bert,

That's what I did: yangdump-pro --warn-off=1022 --warn-off=1023 ...
But honestly, I've got more important things to focus on that tweaking 
scripts all day long.

Regards, Benoit