Subject: [netmod] if-feature in default value

From: Martin Bjorklund <[email-masked]>
Date: Mon, 23 May 2016 16:08:45 +0200 (CEST)

Hi,

This comment from the Gen-ART review deserves it's own thread.

gen-art> - section 7.6.4
gen-art> 
gen-art>    The default value MUST NOT be marked with an "if-feature" statement.
gen-art>
[...] 
gen-art> But it's not clear what the whole set of situations is that should be
gen-art> forbidden.  For instance, this should work:
gen-art> 
gen-art>      typedef xyz {
gen-art>        type enumeration {
gen-art> 	 enum blue { if-feature blue; }
gen-art> 	 ...
gen-art>        }
gen-art>      }
gen-art> 
gen-art>      leaf color {
gen-art>        if-feature blue;
gen-art>        type xyz;
gen-art>        default blue;
gen-art>      }
gen-art> 
gen-art> Whereas this won't:
gen-art> 
gen-art>      typedef xyz {
gen-art>        type enumeration {
gen-art> 	 enum blue { if-feature blue; }
gen-art> 	 ...
gen-art>        }
gen-art>      }
gen-art> 
gen-art>      leaf color {
gen-art>        // No if-feature here.
gen-art>        type xyz;
gen-art>        default blue;
gen-art>      }
gen-art> 
gen-art> Is this rule only meant to cover the situation where the leaf's type
gen-art> is an "in-line" enum and the particular enum value has an if-feature?

mbj> Good point.  Yes, the first example should be valid.  Another valid
mbj> example would be:
mbj> 
mbj>     container colors {
mbj>       if-feature blue;
mbj>       leaf color {
mbj>         type xyz;
mbj>         default blue;
mbj>       }
mbj>     }
mbj> 
mbj> Maybe:
mbj> 
mbj> OLD:
mbj> 
mbj>   The definition of the default value MUST NOT be marked with an
mbj>   "if-feature" statement.
mbj> 
mbj> NEW:
mbj> 
mbj>   If the definition of the default value is conditional based on one or
mbj>   more features (see ^if-feature^), then the leaf node MUST
mbj>   also be conditional based on at least the same set of features.
mbj> 
mbj> (modelled after the text in 9.9)

Does anyone have comments on this proposal?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 23 May 2016 07:56:05 -0700

> Does anyone have comments on this proposal?

What problem is this supposed to solve?
If the server does not advertise feature "blue", then the default-stmt
is still invalid.   Are you suggesting that defining defaults that depend on
features is a conformance mechanism for declaring a feature to be mandatory?

> /martin
Andy

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

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 23 May 2016 19:58:54 +0200 (CEST)

> What problem is this supposed to solve?

See the first of the examples above.

> is still invalid.

Correct.

> Are you suggesting that defining defaults that depend on

No.  Just that if the if-feature expression on the leaf matches (or is
more restrictive than) then if-feature on the default value, it should
work.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 23 May 2016 11:06:56 -0700

On Mon, May 23, 2016 at 10:58 AM, Martin Bjorklund <[email-masked]> wrote:

> > > gen-art> Is this rule only meant to cover the situation where the
> leaf's
> > > type
> > > mbj>   If the definition of the default value is conditional based on
> one
> > > or

OK -- conditional values don't matter if the leaf is not enabled.
This is non-trivial to check but I know that doesn't matter.
Most of YANG 1.1 is that way.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 23 May 2016 20:12:00 +0200 (CEST)

> Most of YANG 1.1 is that way.

I was careful to use the same wording as is used in section 9.9 on
leafrefs:

   If the leaf that the leafref refers to is conditional based on one or
   more features (see Section 7.20.2), then the leaf with the leafref
   type MUST also be conditional based on at least the same set of
   features.

So we already have the complexity.

/martin

---

From: Robert Wilton <[email-masked]>
Date: Tue, 24 May 2016 11:24:27 +0100

The proposed new text looks fine to me.

Rob

On 23/05/2016 15:08, Martin Bjorklund wrote:
> .