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.



>
> /martin
>


Andy
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to