Subject: [netmod] draft-ietf-netmod-rfc6087bis-05.txt

From: Andy Bierman <[email-masked]>
Date: Mon, 19 Oct 2015 18:41:25 -0700

Hi,

I updated the YANG guidelines draft.
All open issues have been addressed in this version.

https://github.com/netmod-wg/rfc6087bis/issues

Andy

---

From: Robert Wilton <[email-masked]>
Date: Tue, 20 Oct 2015 14:49:17 +0100

Hi,

I have one question related to "5.1.  Module Naming Conventions".

Currently, the YANG modules that I have included as part of my 
individual IDs don't currently use an "ietf-" prefix because the drafts 
haven't been adopted as WG documents yet.

However, this means that the pyang tool throws up a warning for this.  E.g.
[email-masked]:1: warning: RFC 6087: 4.1: no module 
name prefix used, suggest ietf-interfaces-common

So, am I right in not including the ietf prefix for non WG adopted 
drafts?  If so, should the above warning in pyang be made informational 
instead?

Thanks,
Rob

On 20/10/2015 02:41, Andy Bierman wrote:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 20 Oct 2015 16:01:53 +0200 (CEST)

Robert Wilton <[email-masked]> wrote:
> individual IDs don't currently use an "ietf-" prefix because the
> drafts haven't been adopted as WG documents yet.
> 
> drafts?  If so, should the above warning in pyang be made
> informational instead?

I think it wiuld be useful if 6087bis provided guidelines for these
kinds of modules as well.

That said, I think that pyang --ietf should still flag this as an
error.  When checking a non-WG module, use --lint instead of --ietf.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 20 Oct 2015 21:25:42 +0200 (CEST)

> I updated the YANG guidelines draft.

I have a couple of comments.

--------------------------

Section 5.14 says:

    The "choice" statement is allowed to be directly present within a
    "case" statement in YANG 1.1.

It is allowed in YANG 1 as well.

    This needs to be considered
    carefully.  Consider simply including the nested "choice" as
    additional "case" statements within the parent "choice" statement.

Ok, but I don't think people use nested choice by accident.  I have
seen it used a handful of times, and there was always a good reason
for doing it.  If you think some warning text like this is needed, I
suggest something along the lines of:

    If a "case" statement contains a single "choice" statement,
    consider simply including ...

--------------------------

Section 5.1 says:

           Normative modules contained in Standards Track documents
	   MUST be named according to the guidelines in the IANA
	   Considerations section of [I-D.ietf-netmod-rfc6020bis].

Note that since 6020bis doesn't obsolete 6020, the IANA Considerations
text is not copied to 6020bis.  So either reference 6020, or copy the
rule (use "ietf-" prefix).

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 21 Oct 2015 08:57:17 +0200

> I have a couple of comments.

But isn't it that in these legitimate cases the inner choice is always
accompanied by other nodes within the same case? The solution to Y29
enables choice as a short-hand case, and this can always be
flattened. Do I miss something?

Lada

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

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 21 Oct 2015 09:17:46 +0200 (CEST)

> flattened. Do I miss something?

No you're right.  It should also be noted that an implementation can
choose to flatten such nested choices.

/martin

---

From: Jernej Tuljak <[email-masked]>
Date: Wed, 21 Oct 2015 09:21:21 +0200

> https://github.com/netmod-wg/rfc6087bis/issues

You missed this: 
https://www.ietf.org/mail-archive/web/netmod/current/msg13593.html

Applies to both YANG 1.0 and current 1.1 text.

Jernej

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 21 Oct 2015 09:22:50 +0200

> On 21 Oct 2015, at 09:17, Martin Bjorklund <[email-masked]> wrote:
> 

So maybe this was the reason for not allowing choice as a short-hand case. I wonder, is Y29-01 a good idea after all? We are encouraging people to do convoluted things that have a simpler alternative.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 21 Oct 2015 09:50:19 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> So maybe this was the reason for not allowing choice as a short-hand
> case. I wonder, is Y29-01 a good idea after all? We are encouraging
> people to do convoluted things that have a simpler alternative.

IMO Y29 is about having consistent rules in the language.  Allowing
short hand cases for just a subset of the nodes seems like a CLR.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 21 Oct 2015 10:05:50 +0200

> On 21 Oct 2015, at 09:50, Martin Bjorklund <[email-masked]> wrote:
> 

It would be practically useful in cases like this:

grouping foo {
  choice foo {
    ...
  }
}

choice foobar {
  uses foo;
  leaf bar;
}

However, this is not possible because of another CLR that doesn't allow "uses" as a substatment of "choice". So if we want consistency, we should simply remove short-case-stmt from the ABNF and use data-def-stmt instead.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 21 Oct 2015 10:13:39 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> However, this is not possible because of another CLR that doesn't
> allow "uses" as a substatment of "choice". So if we want consistency,
> we should simply remove short-case-stmt from the ABNF and use
> data-def-stmt instead.

The problem with allowing uses as a shorthand is that it is not
directly obvious what it means.  For example:

  grouping foo {
    leaf a { ... }
    leaf b { ... }
  }

  choice x {
    uses foo;
  }

could be equivalent to:

A:

 choice x {
   leaf a { ... }
   leaf b { ... }
 }

or

B:

 choice x {
   case foo {
     leaf a { ... }
     leaf b { ... }
   }
 }

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 21 Oct 2015 10:51:20 +0200

> On 21 Oct 2015, at 10:13, Martin Bjorklund <[email-masked]> wrote:
> 

The text in sec. 7.13 makes it quite clear that it would be A (The effect of a "uses" reference to a grouping is that the nodes defined by the grouping are copied into the current schema tree, … ).

Moreover, you have a similar dilemma if you augment a choice:

augment x {
  leaf a { ... }
  leaf b { ... }
}

But my point is different: choice as a short-hand case is only possible directly, not via "uses":

choice foo {
  choice bar { ... }
  ...
}

However, this really begs the question "Why don't you simply make the cases of 'bar' into cases of 'foo'?" I can't see any reasonable answer.

Balazs wanted to add CLRs to ban "complex" choices. I don't know how to do it in general but here we are removing one obstacle for defining choices that are *needlessly* complex.

Lada