Subject: Re: [netmod] closing Y45 - would an inofficial online meeting help?

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 1 May 2015 11:44:13 +0200

> On 30 Apr 2015, at 19:30, Xiang Li <[email-masked]> wrote:
> 
> 
> 
> On 4/30/2015 12:04 PM, Ladislav Lhotka wrote:
>>> On 30 Apr 2015, at 18:38, Xiang Li <[email-masked]> wrote:
>>> 
>>> 
>>> 
>>> On 4/30/2015 10:54 AM, Ladislav Lhotka wrote:
>>>>> On 30 Apr 2015, at 17:08, Xiang Li <[email-masked]> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> On 4/30/2015 9:09 AM, Ladislav Lhotka wrote:
>>>>>>> On 30 Apr 2015, at 15:52, Xiang Li <[email-masked]> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On 4/30/2015 8:16 AM, Ladislav Lhotka wrote:
>>>>>>>>> On 30 Apr 2015, at 14:57, Juergen Schoenwaelder <[email-masked]> wrote:
>>>>>>>>> 
>>>>>>>>> On Thu, Apr 30, 2015 at 02:09:55PM +0200, Ladislav Lhotka wrote:
>>>>>>>>>>> On 30 Apr 2015, at 14:00, Juergen Schoenwaelder <[email-masked]> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> On Thu, Apr 30, 2015 at 01:15:22PM +0200, Martin Bjorklund wrote:
>>>>>>>>>>>> Ladislav Lhotka <[email-masked]> wrote:
>>>>>>>>>>>>>> On 30 Apr 2015, at 12:29, Juergen Schoenwaelder
>>>>>>>>>>>>>> <[email-masked]> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I like to close Y45. It seems most people are fine with Y45-04. Andy
>>>>>>>>>>>>>> may not be fully convinced or he wants a slight change of Y54-04 that
>>>>>>>>>>>>>> turns import-by-revision semantically into import-by-min-revision.
>>>>>>>>>>>>>> Xiang Li seems to support a motion to make import-by-revision mean
>>>>>>>>>>>>>> import-by-min-revision. So perhaps a possible solution is to settle on
>>>>>>>>>>>>>> Y45-04 with a slight change that import-by-revision mean indeed
>>>>>>>>>>>>>> import-by-min-revision. (We would have to write this variation down
>>>>>>>>>>>>>> and give it a new number - any volunteers?)
>>>>>>>>>>>>> Two questions:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 1. Is import-by-revision supposed to mean import-by-min-revision only
>>>>>>>>>>>>> for augments? For groupings and typedefs it should IMO mean an exact
>>>>>>>>>>>>> revision.
>>>>>>>>>>>> Yes.
>>>>>>>>>>>> 
>>>>>>>>>>> I guess this would be more than just augments. Essentially any
>>>>>>>>>>> reference to an 'object' defined in an external module, irrespective
>>>>>>>>>>> whether the reference is via augments or a must/when statement or
>>>>>>>>>>> anything else.
>>>>>>>>>> For must/when a revision makes even less sense because XPath expressions refer to an instance document rather than a module.
>>>>>>>>>> 
>>>>>>>>> But isn't the same is true for an augment that refers to a target that
>>>>>>>>> is a list of a container? The target instance must not only be
>>>>>>>>> defined, it must also exist for the augment to have an effect.
>>>>>>>> No, the target node is by definition a schema node, an augment manipulates the schema - no instance is involved.
>>>>>>>> 
>>>>>>>>> Anyway, the main idea behind Y45-04 is to use imports to handle schema
>>>>>>>>> tree dependencies that need to be unambiguous at module compile time
>>>>>>>>> and to leave instance tree dependencies to future work (e.g. a package
>>>>>>>>> definition system like Andy once proposed).
>>>>>>>> For augments the package is in fact given by the hello message or other form of data model specification, because an augment makes sense only if its target node is part of the schema. In fact, not only revision of the imported module is important here:
>>>>>>> "not only revision of the imported module is important..."?
>>>>>>> 
>>>>>>> I thought you have been arguing for the contrary? Did you mean "not only revision of the advertised module is important…"?
>>>>>> Let’s go back to Andy’s example
>>>>>> 
>>>>>> http://www.ietf.org/mail-archive/web/netmod/current/msg12486.html
>>>>>> 
>>>>>> Andy wrote: “The 'aug1' developer clearly intends for the server to support base@2015-01-01.”
>>>>>> 
>>>>>> But let’s say the new enum in module “base” is defined like so:
>>>>>> 
>>>>>>     enum fastest {
>>>>>>         if-feature foo;
>>>>>>     }
>>>>>> 
>>>>>> Then I could argue that ‘aug1’ developer clearly intends for the server to support not only base@2015-01-01 but also feature foo. However, the latter requirement is not expressed in import-by-revision.
>>>>> Current YANG "enum"  does not allow "if-feature" as its substatement.
>>>> Th one in YANG 1.1 proposal does.
>>>>  
>>>>> But in general if things depend on some 'features' implemented in an augmented
>>>>> base module then they are IMO by definition optional. In other words, 'aug1' developer can't
>>>>> demand a server to support feature 'foo', if it is not advertised. I don't see that's relevant here.
>>>> It is relevant - for the sake of this example, base@2015-01-01 without feature foo is essentially the same as base@2014-01-01. In both cases the augment from the aug1 module cannot be applied.
>>> I think the two scenarios are different.
>>> 
>>> When a client processes anything that involves "if-feature", it knows it must check if the server
>>> advertised that feature. If the feature is not available then it knows nodes in the aug1 will not be
>> Still the same: When a client processes anything that involves data defined in a new revision of a module, it knows it must check if the server advertises that new revision (and the server must advertise it in any case).
> 
> Scenario 1:
> * we have  enum fastest { if-feature foo; }
> * a server  advertises "aug1" and base@2015-01-01"  (without feature foo)
> 
> My point is that in this case  the server's advertisement is "consistent". A client
> can not assume it can set the leaf to 'fastest' because that involves a checking
> to see feature "foo" is advertised.
> 
> Scenario 2:
> * we have  enum fastest  (i.e. NOT based on  feature foo)
> * a server  advertises "aug1" and base@2014-01-01"
> 
> In this case the advertisement is "inconsistent" because aug1 requires at least
> base@2015-01-01 and should be considered as an "error”.

In fact, it is not an error, it is just that the “when” expression can never be true, so the augment will never be applied.

> 
> When a client sees the server supports "aug1",  it should be able to assume
> "base@2015-01-01"  must also be supported without having to check the
> base version in server's advertisement.

How do the two situations differ with respect to applicability of “aug1”?

1. Server doesn’t support base@2015-01-01.
2. Server supports base@2015-01-01 but doesn’t support feature foo.

Lada

> --Xiang

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 1 May 2015 12:25:00 +0200

> On 30 Apr 2015, at 19:22, Andy Bierman <[email-masked]> wrote:
> 
> On Thu, Apr 30, 2015 at 10:13 AM, Ladislav Lhotka <[email-masked]> wrote:
>> 
>>> On 30 Apr 2015, at 18:50, Andy Bierman <[email-masked]> wrote:
>>> 
>>> On Thu, Apr 30, 2015 at 9:38 AM, Xiang Li <[email-masked]> wrote:
>>>> 
>>>> 
>>>>>>>>>> On 30 Apr 2015, at 14:57, Juergen Schoenwaelder
>>>>>>>>>>>> On 30 Apr 2015, at 14:00, Juergen Schoenwaelder
>>>>>>>>>>> For must/when a revision makes even less sense because XPath
>>>>>>>>>>> expressions refer to an instance document rather than a module.
>>>>>>>>>>> 
>>>>>>>>> No, the target node is by definition a schema node, an augment
>>>>>>>>> manipulates the schema - no instance is involved.
>>>>>>>>> 
>>>>>>>>> For augments the package is in fact given by the hello message or
>>>>>>>>> other form of data model specification, because an augment makes sense only
>>>>>>>>> if its target node is part of the schema. In fact, not only revision of the
>>>>>>>>> imported module is important here:
>>>>>>>> 
>>>>>>>> I thought you have been arguing for the contrary? Did you mean "not
>>>>>>>> only revision of the advertised module is important…"?
>>>>>>> 
>>>>>>> Then I could argue that ‘aug1’ developer clearly intends for the server
>>>>>>> to support not only base@2015-01-01 but also feature foo. However, the
>>>>>>> latter requirement is not expressed in import-by-revision.
>>>>>> 
>>>>> It is relevant - for the sake of this example, base@2015-01-01 without
>>>>> feature foo is essentially the same as base@2014-01-01. In both cases the
>>>>> augment from the aug1 module cannot be applied.
>>>> 
>>>> 
>>> quite different.
>>> The original point is that the designer of "aug1" is using
>>> definitions from the new "base" module.  There is no way
>>> that the server can implement this "aug1" module using the
>>> old "base" module.
>>> 
>>> The server does not support the new "fastest" enum.  It is a lie to
>>> advertise that the leaf using this typedef is supported.
>> 
>> The server advertises the old revision of “base, thus making clear that is does *not* support the new “fastest” enum. Therefore, it doesn’t lie. Note that the fact that the augment in ‘aug1’ doesn’t happen isn’t an error from the YANG point of view - it just may or may not be what the server implementer intended.
>> 
> 
> If it advertises the old version of "base" then it cannot advertise "aug1".
> The client sees that advertisement and believes that the new revision
> of the typedef is supported.  It has no reason to suspect that setting

If Y45-04 is accepted, the client can never believe the new revision is supported because it is clearly stated that the revision of the import is ignored for augments. That is:

- if a module is imported only for referring to its nodes (augments, leafrefs, must/when), then the    
  import should be without revision because revision-date would be ignored anyway.

- if groupings or typedefs from the imported module are used, then the exact revision of each is always  
  known either from revision-date, if present, or from server’s advertisement.

I don’t think it it that complicated.

> the leaf to 'fastest' is going to fail.
> 
> This is not typedef drift.
> The requirements for "base" are quite clear for both revisions.
> The server can advertise either one.
> The server does not meet the requirements for "aug1" if
> it only supports the old base module.

If the client has such a requirement, it can immediately see from the server’s advertisement that it is  not fulfilled, and close the session or whatever. It would be nice to have the ability to formally state conformance, e.g.

- module ‘aug1’ needs ‘base’ at the minimum revision 2015-01-01, or

- module ‘aug1’ needs ‘base’ at the minimum revision 2015-01-01 && support for feature foo.

Imports cannot really do this and, moreover, similar statements might IMO be necessary even if neither module imports the other. 

A big benefit of Y45-04 there it removes all ambiguity in the imported revisions of typedefs and groupings.

After reading Y45-05, I still prefer -04 with Juergen’s commentary about future work on conformance - and I am willing to take part in such a work after YANG 1.1 is done.

Lada

> Andy
>>> Andy
>>>> available. The contract is not broken because in this case "aug1" is
>>>> *effectively*a conditional augment.
>>>> 
>>>> 
>>>> --Xiang
>>>> 
>>>> 
>>>> 
>>>>> I am not saying it is a problem but the two situations are effectively
>>>>> identical.
>>>>> 
>>>>> My point is that for processing augments and leafrefs, a more complete
>>>>> conformance information has to be supplied anyway, so taking into account
>>>>> revisions in import statements is not really needed.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> Lada
>>>>> 
>>>>>> --Xiang
>>>>> 
>>>>> --
>>>> _______________________________________________
>>>> netmod mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/netmod
>> 
>> --

---

From: Xiang Li <[email-masked]>
Date: Fri, 01 May 2015 10:25:03 -0500

On 5/1/2015 4:44 AM, Ladislav Lhotka wrote:
> In fact, it is not an error,

When the server advertises it supports "aug1", *currently, at them time, 
it is stating that it
also supports  base@2015-01-01.  Bu then the server is advertising 
base@2014-01-01.
So you see the server's advertisement is contradicting itself.

In other words,  the conformance requirement set by the module designer 
of "aug1" is
not honored by the server at runtime.  Because of that the server's 
implementation is
not compliant to "aug1".

?it is just that the “when” expression can never be true, so the augment will never be >applied.

The problem is the designer of "aug1" assumes that "when" must be able 
to be evaluated to "True".

Thanks
-Xiang

---

From: Andy Bierman <[email-masked]>
Date: Fri, 1 May 2015 09:04:49 -0700

On Fri, May 1, 2015 at 8:25 AM, Xiang Li <[email-masked]> wrote:
>>>>>>>> Then I could argue that ‘aug1’ developer clearly intends for the
>>>>>>>> server to support not only base@2015-01-01 but also feature foo. However,
>>>>>>>> the latter requirement is not expressed in import-by-revision.
>>>>>>>
>>>> Still the same: When a client processes anything that involves data
>>>> defined in a new revision of a module, it knows it must check if the server
>>>> advertises that new revision (and the server must advertise it in any case).
>>>
>>> Scenario 1:
> When the server advertises it supports "aug1", *currently, at them time, it
> is stating that it
> In other words,  the conformance requirement set by the module designer of
> "aug1" is
> The problem is the designer of "aug1" assumes that "when" must be able to be
> evaluated to "True".
>

The problem is also the other leaf:

    augment b:/port-knob {
          when "b:knob-type = 'faster'";
           leaf alt-knob-type {
                type b:port-knob-type;
           }
      }

According to the solution proposal, b:port-knob-type is
the new typedef (that includes the new enum).
Even though the server can implement 'faster', so the
when-stmt might be true, it cannot augment the base object
with a leaf using the new typedef.  A client will assume
that 'alt-knob-type' can be set to 'fastest', but it will fail.

In other words, there isn't 1 single thing from "aug1" that the
server can honor, so it cannot advertise this module
unless it also advertises 'base@2015-01-01'.

Andy

---

From: Xiang Li <[email-masked]>
Date: Fri, 01 May 2015 11:26:01 -0500

On 5/1/2015 5:25 AM, Ladislav Lhotka wrote:
> If Y45-04 is accepted, the client can never believe the new revision is supported because it is clearly stated that the revision of the import is ignored for augments.

That is what I still have doubt whether it is a good thing to do.

> That is:

Why "revision-date" in this case must be ignored completely?

If we do this, the author of "aug1" can not decide the version where 
he/she wants to start.
I think it makes sense for the author of "aug1" to be able to do that 
and set up some basic
requirements for the implementer of "aug1", and that's why I said I 
prefer for "augment"
to use "min-revision-rule", unless it's the intention of the working 
group to prevent the author
of "agu1" from doing that for other legitimate reasons that I missed.

>    known either from revision-date, if present, or from server’s advertisement.

We already agreed on this. We are not ignoring "revision-date" in this 
case either.

-Xiang

> I don’t think it it that complicated.

No... Indeed it's not...

-Xiang

---

From: Andy Bierman <[email-masked]>
Date: Fri, 1 May 2015 09:43:34 -0700

On Fri, May 1, 2015 at 9:26 AM, Xiang Li <[email-masked]> wrote:
>>>>>>>>>>>>>>>>> I like to close Y45. It seems most people are fine with
>>>>>>>>>>>>>>>>> Y45-04.
>>>>>>>>>>>>>>>>> Andy
>>>>>>>>>>>>>>>>> may not be fully convinced or he wants a slight change of
>>>>>>>>>>>>>>>>> Y54-04
>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>> Xiang Li seems to support a motion to make
>>>>>>>>>>>>>>>>> import-by-revision
>>>>>>>>>>>>>>>>> mean
>>>>>>>>>>>>>>>>> import-by-min-revision. So perhaps a possible solution is
>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> settle on
>>>>>>>>>>>>>>>>> import-by-min-revision. (We would have to write this
>>>>>>>>>>>>>>>>> variation
>>>>>>>>>>>>>>>>> down
>>>>>>>>>>>>>>>> 1. Is import-by-revision supposed to mean
>>>>>>>>>>>>>>>> import-by-min-revision
>>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>>> for augments? For groupings and typedefs it should IMO mean
>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>> exact
>>>>>>>>>>>>>>>> revision.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Yes.
>>>>>>>>>>>>>>>
>>>>>>>>>>>> But isn't the same is true for an augment that refers to a
>>>>>>>>>>>> target
>>>>>>>>>>>> that
>>>>>>>>> server
>>>>>>>> base module then they are IMO by definition optional. In other
>>>>>>>> words,
>>>>>>>> 'aug1' developer can't
>>>> The server advertises the old revision of “base, thus making clear that
>>>> is does *not* support the new “fastest” enum. Therefore, it doesn’t lie.
>>>> Note that the fact that the augment in ‘aug1’ doesn’t happen isn’t an error
>>>> from the YANG point of view - it just may or may not be what the server
>>>> implementer intended.
>>>>
>> If Y45-04 is accepted, the client can never believe the new revision is
>> supported because it is clearly stated that the revision of the import is
>> ignored for augments.
>
>
> If we do this, the author of "aug1" can not decide the version where he/she
> wants to start.
> I think it makes sense for the author of "aug1" to be able to do that and
> set up some basic
> requirements for the implementer of "aug1", and that's why I said I prefer
> for "augment"
> to use "min-revision-rule", unless it's the intention of the working group
> to prevent the author
> We already agreed on this. We are not ignoring "revision-date" in this case
> either.
>
> -Xiang
>

I think it is clearly broken.
Using a fixed revision date for typedefs and groupings
but a variable revision-date for everything else can be easily
broken by mixing types/objects in must/when or
augment statements.

I noticed that the example given in Y45-04 for why we need
multiple imports of each module is somewhat flawed:

import ietf-inet-types {
  revision-date 2013-07-17;
  prefix inet;
}
import ietf-inet-types {
  revision-date 2010-09-24;
  prefix inet6021;
}
leaf foo {
  type inet:ip-address-no-zone;
}
leaf bar {
  type inet6021:ip-address;
}

This example shows that author wants to use the new ip-address-no-zone
typedef that was added to RFC 6991, but is going to keep using the
old version of ip-address.

   1) ip-address did not change at all from RFC 6021, so there is no
        point in importing 2 revisions

   2) even if the ip-address did change, is it really up the the author
    of the importing module to decide the standard ip-address type?
    Since the augmenting module is being updated anyway, it is OK
    to update the typedef.  If it is the first version, then even worse
    to pick the out-of-date typedef.

If a typedef gets corrected (e.g., the pattern-stmt is wrong in the old
revision), then why do we want to let other modules keep using
the broken version?  Why make YANG complicated so the user can
do the wrong thing?

What if IPv7 gets added someday?  Is it up to each WG, each module
to decide "We have no interest in supporting the new IP version.
We will stick with the current typedef forever".  Is this OK, or
should the set of IETF modules use consistent data types?

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 04 May 2015 14:48:25 +0200

> broken by mixing types/objects in must/when or

I don't see how it can be broken - if multiple prefixes corresponding to
the same module appear in must/when of in the target node specification,
then it doesn't matter because the revision is ignored for all of
them. And typedefs/groupings apprearing inside an augment are resolved
in the context of the module defining the augment, so there is no
ambiguity either.

>         point in importing 2 revisions

Right, there is no such need in this case.

>     Since the augmenting module is being updated anyway, it is OK

I don't think the augmenting module has to be updated - but maybe I
don't get what you mean.

> the broken version?  Why make YANG complicated so the user can

If the module author thinks it is safe to allow for automatic updates,
he can use import without revision.

On the other hand, typedefs and groupings can be updated in a way that
require an update in the server implementation (new enums, extended
range of an integer leaf, new nodes in a grouping), and then a fixed
revision may be appropriate.

Lada