Andy Bierman <[email protected]> wrote: > On Mon, May 23, 2016 at 10:58 AM, Martin Bjorklund <[email protected]> wrote: > > > Andy Bierman <[email protected]> wrote: > > > On Mon, May 23, 2016 at 7:08 AM, Martin Bjorklund <[email protected]> > > wrote: > > > > > > > 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? > > > > > > > > > > > > > > What problem is this supposed to solve? > > > > See the first of the examples above. > > > > > If the server does not advertise feature "blue", then the default-stmt > > > is still invalid. > > > > Correct. > > > > > Are you suggesting that defining defaults that depend on > > > features is a conformance mechanism for declaring a feature to be > > mandatory? > > > > 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. > > > > > > 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.
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 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
