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

From: Xiang Li <[email-masked]>
Date: Thu, 30 Apr 2015 08:56:49 -0500

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..."?

--Xiang

> what if the target node depends on a feature? That’s why pyang accepts a hello message in a file where all this can be neatly specified (I plan to add support for yang-library).

> Lada
>
>> /js
>>
>> --
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>

---

From: Xiang Li <[email-masked]>
Date: Thu, 30 Apr 2015 10:08:44 -0500

On 4/30/2015 9:09 AM, Ladislav Lhotka wrote:
>> On 30 Apr 2015, at 15:52, Xiang Li <[email-masked]> wrote:
>>
>>
>>
>> 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.

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.

--Xiang

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 30 Apr 2015 17:54:16 +0200

> On 30 Apr 2015, at 17:08, Xiang Li <[email-masked]> wrote:
> 
> 
> 

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 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

---

From: Xiang Li <[email-masked]>
Date: Thu, 30 Apr 2015 11:38:09 -0500

On 4/30/2015 10:54 AM, Ladislav Lhotka wrote:
> 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
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.
>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 30 Apr 2015 09:50:29 -0700

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.

Andy

> advertised that feature. If the feature is not available then it knows nodes
> in the aug1 will not be
>> 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: Ladislav Lhotka <[email-masked]>
Date: Thu, 30 Apr 2015 19:04:42 +0200

> On 30 Apr 2015, at 18:38, Xiang Li <[email-masked]> wrote:
> 
> 
> 
> 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).

Lada

> available. The contract is not broken because in this case "aug1" is *effectively*a conditional augment.
> 
> 
> --Xiang
> 
> 
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 30 Apr 2015 19:13:06 +0200

> On 30 Apr 2015, at 18:50, Andy Bierman <[email-masked]> wrote:
> 

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.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Thu, 30 Apr 2015 10:22:49 -0700

> 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’…

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
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.

Andy

---

From: Xiang Li <[email-masked]>
Date: Thu, 30 Apr 2015 12:30:35 -0500

> 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 adv…

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".

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.

--Xiang