Re: [netmod] Y07: do not allow when or if-feature on key

[Ladislav Lhotka <[e-mail]>]

> On 04 Jan 2015, at 11:09, Martin Bjorklund <[e-mail]> wrote:
> 
> Andy Bierman <[e-mail]> wrote:
>> On Fri, Jan 2, 2015 at 8:39 AM, Martin Bjorklund <[e-mail]> wrote:
>>> Andy Bierman <[e-mail]> wrote:
> 
> [...]
> 
>>>> I agree that it is not feasible for a tool to compare XPath statements
>>>> with different context nodes to see if they always produce the
>>>> same results.  But it is easy to check if the feature-stmts are the same
>>>> or less than the parent.
> 
> This is exactly the problem that I tried to describe orginally in this
> email thread.
> 
> The current approach to Y07 is to say that it is ok to have
> if-feature/when on key leafs, as long as they are the same as the
> parent list node.  This sounds simple, but my point is - and it seems
> you agree - that it is not simple.  For boolean expressions in
> if-feature it is doable, but for XPath expressions in when it is not.
> 
> So how do we solve this?
> 
> First of all, this is mostly an issue w/ using leafs defined in a
> groping as a key in a list.  If the key leaf is defined "inline", it
> is not necessary to allow if-feature/when on the key leaf (*).
> 
> 1.  Require the expression to be *exactly* the same string, including
>    whitespaces.

This could possibly work only for a small subset of XPath expressions because of different context nodes. Also, it would be extremely brittle.

> 
>    There are some corner cases where some groupings cannot be used in
>    this case (**).
> 
> 2.  Require the expression to be logically the same - but this is
>    difficult and will probably lead to tools not checking this.

Yes.

> 
>    (Or rather, the expression on the list can be more restrictive
>    than the expression on the key; even more difficult to check.)
> 
> 3.  Ignore the if-feature/when on the key leaf.  This is possibly
>    confusing.

A “default” statement on a key is also ignored.

> 
> 4.  Make if-feature/when on the key leaf illegal.  This means that
>    certain groupings cannot be used.

… and makes some 1.0 modules illegal.

> 
> 5.  Have different rules for if-feature and when.

This is IMO too complicated given that such cases should be quite rare.

> 
> 
> (*) one interesting case is Y07 combined with Y09, for example:
> 
>  list address {
>    key "ip vrf";
>    leaf ip { ... }
>    leaf vrf {
>      if-feature vrf;
>      mandatory false;
>      ...
>    }
>    ...
>  }

This actually makes a good sense and should be allowed if Y09 makes it into 1.1.

Lada

> 
> (**)
> 
>  grouping a {
>    leaf a {
>      when "/properties/a":
>      ...
>    }
>  }
> 
>  grouping b {
>    leaf b {
>      when "/properties/b":
>      ...
>    }
>  }
> 
>  list x {
>    when "/properties/a and /properties/b";
>    key "a b";
>    uses a;
>    uses b;
>  }
> 
> 
>>> I think Lada's suggestion was to ignore if-feature/when b/c of
>>> backwards compatibility reasons.
>>> 
>>> This would be legal in 1.1, if we say that we ignore the if-feature:
>>> 
>>>  list y {
>>>    if-feature "bar";
>>>    key "a b";
>>>    uses x;
>>>    leaf b {
>>>      type string;
>>>    }
>>>  }
>>> 
>>> 
>> 
>> This is legal now -- our tools support it and check for key leafs
>> that are more conditional than their parent.
> 
> But this behavior isn't specified in RFC 6020 - and this is the
> problem that we want to solve.
> 
> 
> /martin
> 
> 
> 

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