Subject: [netmod] when statement

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 06 Aug 2008 14:24:09 +0200

Hi,

I Dublin I proposed to allow when statement outside augment, as a
general method for adding conditional contents. In my view, 

when condition {
    ...
}

could appear in all places where

augment . {
    when condition {
        ...
   }
}

is currently allowed - it is supposed to do the same thing.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 06 Aug 2008 06:44:33 -0700

> is currently allowed - it is supposed to do the same thing.

I am opposed to this construct.
IMO, YANG is already quite flexible, and it can
already be very difficult to determine by inspection
what a module actually requires.

This is the hack version of the full #ifdef.
I do not see how this offers interoperability.

Would you allow this:

   list some-list {
     when "some-complicated-condition" {
        key "one-version";
     }
     when "some-other-condition" {
         key "another-version";
     }
     when "some-nested-conditions" {
         when "even-more-conditions" {
            key "yet-a-third-version";
         }
     }

     ...
   }

> Lada

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 06 Aug 2008 17:08:34 +0200

> what a module actually requires.

But whenever I want to use it, I can insert the construct with
"augment .", right? And this is even more hacky.
> I do not see how this offers interoperability.

No, since key now cannot be a substatement of augment.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Wed, 06 Aug 2008 08:18:13 -0700

> "augment .", right? And this is even more hacky.

There already is a way to achieve your 'feature', so why add another
one to save a few characters in the YANG file.
I thought it was a big deal to provide 2 ways
of doing the same thing?

IMO, this DM design is awful, and completely subverts
the intent of augment-stmt.   I much prefer to deal
with optionality through module conformance 'packages',
rather then embed it into the module.

That method has proven to work with SMIv2.
What is the proof that this method will work
for IETF standard data models?

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 06 Aug 2008 17:34:59 +0200

> I thought it was a big deal to provide 2 ways

Not really, I also proposed to allow augment-stmt only under uses-stmt -
everybody in Dublin seemed to support this change.

If the consensus is that the "general when" is not needed, I wouldn't
mind if it stays under augment, but also under uses.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Wed, 06 Aug 2008 10:10:22 -0700

> everybody in Dublin seemed to support this change.

Except for top-level augment, right?
You cannot remove the ability for one module to augment
another one.

> mind if it stays under augment, but also under uses.

IMO, this WG needs to start looking at the big picture,
and decide how big problems are solved within YANG.
Tweaking the clauses without any shared understanding
of the 'workings of YANG' is too bottom-up to succeed
in a design-by-committee environment.

I have serious concerns about the standards value of YANG,
especially if it has a nested conditional block, based
on arbitrary values within the running configuration.

The IETF has experience with static module definitions
which are partitioned into groups of objects, and conformance
based on implementation of specific groups within the module.

This simplistic approach is deterministic, static,
and inter-operable.  Combining 'when', 'must', 'augment'
and 'uses' in arbitrary ways is not proven at all.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 06 Aug 2008 19:18:51 +0200

> You cannot remove the ability for one module to augment

Right, although IMO it would be useful to use another keyword for this
type of usage since the mechanism is different - the import statement
has no side effects, so the tree that this augment operates on is not
present.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Wed, 06 Aug 2008 10:32:19 -0700

Ladislav Lhotka wrote:
> type of usage since the mechanism is different 

how about augment-extern?

I don't mind putting augment-stmt inside uses.
I cannot think of any other use case, except your
nested 'when' conceptual containers, which I do not want.

- the import statement
> has no side effects, so the tree that this augment operates on is not

yes it is -- in your implementation, you have to validate
the imported modules along with the 'top' module or sub-module.
You can build an object database and validate all 'definition
context' Xpath expressions against it.  You have to determine
if the augment target can be extended in the requested manner
anyway.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 07 Aug 2008 08:58:42 +0200

> yes it is -- in your implementation, you have to validate

I don't think so. In a NETCONF session, if the agent doesn't separately
advertise the foreign (imported) data model then the main data tree of
this model is not available and the top-level augment cannot have any
effect.

It would be more logical to explicitly associate the modifications with
the data model that is being modified. If I understood correctly the
concept of overlay modules suggested by Martin, this is the way how to
do it.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 07 Aug 2008 09:27:40 +0200

Hello Lada,
I definitely do NOT support this change and don't remember any kind of consensus around it.

It would make mapping of object oriented data models to YANG impossible.

As the Nokia-Siemens guys even proposed to extend the possibilities of augment, I don't believe 
they support your proposal.

Today augmenting choice is the only way to make an extensible enumeration.

We have augmentation of notifications which would be the proper way to extend standard 
notifications e.g. something like the stuff in Sharon's not-content draft.

What happens if a standard module (YAM) is not defined using groupings. Your proposal would 
make that impossible to extend.

Even Phil's examples in the YANG draft use augmenting without uses.

Balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 07 Aug 2008 09:34:34 +0200

Hello Lada,
See some questions below.
Balazs

> this model is not available and the top-level augment cannot have any
Is it not an error to import (use) a data model and not advertise it?

If you are even augmenting that model - extending it - but you do not support it that 
definitely sounds like an error. Extending a non-existing (for my box) model that sounds 
freaky. I could imagine that you only use some types or groupings from an imported module, but 
if we speak of augment we are referring to the data tree.
> the data model that is being modified. 
Could you explian with an example what this would mean in the augmenting and the augmented module?

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 07 Aug 2008 10:24:58 +0200

> Is it not an error to import (use) a data model and not advertise it?

A module may be imported for a number of reasons. If I import e.g.,
inet-types, do I have to advertise inet-types in hello along with my
data model? I don't think so.

> if we speak of augment we are referring to the data tree.

Back to OOP - it you define an instance of a class, you don't specify it
together with all its superclasses. My box just uses a data model that
is derived from another one - and that should be specified in the
derived data model. 

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 07 Aug 2008 10:32:31 +0200

> they support your proposal.

But isn't it more a task for the top-level augment?

If you mention object oriented design - subclass derivation is done so
that you define a new class as a subclass of an existing class and then
specify the changes within that class. But this is not how it works in
YANG. A YANG module that imports another and uses the top-level augment
does these modifications only "by the way" - it may define its own data
tree, rpcs and notifications that have no relation to the foreign
module.

So I would indeed prefer the object-oriented model: if you want to
modify an existing module, you create a new one, declare somehow that
it's derived from the original module and specify the modifications. In
a NETCONF session only this new model would be advertised, not the
original one.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 07 Aug 2008 10:51:40 +0200

> is derived from another one - and that should be specified in the
This example IMHO has nothing to do with OO.

You have a container with a lump of data in module A. The in module B you augment it with a 
second lump of data. If your node does not advertise/implement module A, what are you 
augmenting actually?
So if you augment something in module A, you MUST implement/advertise module A.

Or do you propose, that advertising the augmenting module implicitly means I implement all 
other needed modules as well? I prefer explicit methods.

Balazs

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 07 Aug 2008 11:51:26 +0200

> So if you augment something in module A, you MUST implement/advertise module A.

But I think it is an exact analogy with subclassing: I advertise just
module B, which in turn declares that it is derived from module A. So
naturally the device has to implement everything that is in the
"superclass" module A PLUS the changes from B.

But maybe our Nokia-Siemens friends could speak up and formulate their
OO proposals, it may help clarify this.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 07 Aug 2008 11:38:16 +0200

Hello Lada,

...
> Lada
Could you define more precisely what do you mean by "top-level" augment?

I foresee in my models module B augmenting module A in multiple places. The augmented places 
are typically not on the top level of module A's data tree? The augments are all on the top 
level in module B. Is this top-level augmenting in you definition?

Balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 07 Aug 2008 12:00:21 +0200

Hello Lada,

> "superclass" module A PLUS the changes from B.
module A {
   list foo {
     ...
   }

   list bar {
      list bar-child1 {
        list bar-grandChild1 { ... }
      }

      list bar-child2 { ... }
   }
}

module B {
   import A {
     prefix a;
   }

   augment a:/bar/bar-child1 { ... }
}

Assuming your logic I advertise only module B and not A. Please answer for each, does my 
netconf agent implement
- foo ?
- bar-child2 ?
- bar-grandchild1 ?

For me the answers are not trivial. Using instead an explicit advertising of module A is much 
more simple logic. Anyway the draft MUST chose and describe one of the solutions.
Balazs
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 07 Aug 2008 13:21:40 +0200

> Assuming your logic I advertise only module B and not A. Please answer for each, does my 

What I am talking about is not possible within the current YANG
semantics, which your example seems to imply. So of course the answer
is: none of the three nodes. A possible solution could look like this:

module B {
  include A {
    prefix a;
    augment /a:bar/a:bar-child1 { ... }
  }
}

This include - as opposed to import - would really include the tree from
A in the module B, so all three nodes from your example would be
available if you advertise just B.

Perhaps this could be realized just by extending the include statement
so that it can include "main" modules, too - but that's only one
option. 

In this case augment could be allowed inside uses and include
statements.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 07 Aug 2008 13:40:05 +0200

> Could you define more precisely what do you mean by "top-level" augment?

If you use "augment" inside the module schema hierararchy
(=non-top-level), this augment operates on the local schema tree.

The top-level augment indicates that whenever the schema tree from the
foreign module is used, it should be augmented.

> level in module B. Is this top-level augmenting in you definition?

If the argument of those augments points to the foreign schema tree (its
parts use the foreign namespace prefix), then they are what I mean by
the top-level augments.

Actually the name is a bit misleading since augment-stmt at the top
level of a module can also change the local schema tree. So maybe
"external augment" is better, as Andy suggested.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Thu, 07 Aug 2008 09:18:16 -0700

> It would make mapping of object oriented data models to YANG impossible.

I do not think augmenting a grouping will work
because there is no way to detect which uses-stmts
get augmented, unless your application knows about
the augmenting module.

Nothing in the any of the augmented modules is going to
give any clue that all the 'uses acme:foo;' statements
are really augmented with something else.

The tool which is processing the augmented module really
needs to know that when the 'uses' gets expanded.

> As the Nokia-Siemens guys even proposed to extend the possibilities of 
> augment, I don't believe they support your proposal.
> 

This is not really the same thing.
With an enumeration, the element name remains constant,
and the content string varies.  With a choice,
the element names must all be different, and they
can only appear once (in 1 case-stmt).

BTW, I just found another error-check with augmenting
a choice.  If the choice has a default case, then you cannot
augment the default case with any mandatory nodes.
(Not sure pyang checks for that.)

> We have augmentation of notifications which would be the proper way to 
> extend standard notifications e.g. something like the stuff in Sharon's 
> not-content draft.
> 
> What happens if a standard module (YAM) is not defined using groupings. 
> Your proposal would make that impossible to extend.
> 

Where is that?
The only examples of augment I can find (4.2.8 and 7.15.4)
are showing the 'when' clause and/or augmenting external nodes.

But clearly, the 'when-stmt' can be used outside of a 'uses-stmt',
so making this change would take away that feature.

IMO, YANG lacks the ability for an operator or implementor
to easily and correctly determine which objects must be supported
(for any version of the module.)

A simple 'table row' could have so many holes in it, or
extras added to it, or even objects that pop in
and out of existence depending on the arbitrary 'when-stmt'
Xpath expression, that a human might not be able to
make this determination just by reading the specification.
Since YANG is supposed to be the human-friendly version
of the DML, this is a problem.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 07 Aug 2008 22:22:06 +0200 (CEST)

> data model? I don't think so.

No.  But it isn't specified (yet) in the draft.  This will be done
when we've decided what to do about conformance in general.  For
example, one of the questions is if you advertise module foo, and foo
augments bar, do you have to implement and advertise bar as well?  (I
don't think so).

/martin

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 08 Aug 2008 11:39:38 +0200

Martin Bjorklund wrote:
> For
I would be surprised by this bit.

In my view if you advertise foo you promise to implement all data definition statements of foo. 
Augment is a data definition statement. If you don't implement bar you can not implement the 
augment that means you must implement bar as well.

Balazs

---

From: Phil Shafer <[email-masked]>
Date: Fri, 08 Aug 2008 13:06:54 -0400

>mind if it stays under augment, but also under uses.

One particular use case is making enumeration values conditional,
something augment can't do (currently).

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Fri, 08 Aug 2008 11:10:35 -0700

> something augment can't do (currently).

This could be done with the 'if-feature' mechanism within
the enum as well.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Fri, 08 Aug 2008 15:37:59 -0400

>This could be done with the 'if-feature' mechanism within

feature space is flat and requires specific advertisement on the
feature.  when's argument can supply logic detailing when the
enumeration is valid ('when "../mtu > 1500"').

Thanks,
 Phil

---

From: "tom.petch" <[email-masked]>
Date: Tue, 12 Aug 2008 16:49:12 +0200

----- Original Message -----
From: "Andy Bierman" <[email-masked]>
Sent: Wednesday, August 06, 2008 7:10 PM
Subject: Re: [netmod] when statement

> in a design-by-committee environment.

+1 (and +1 to all the times Andy has raised something similar).

Bottom-up detailed design can and does produce a viable system that can be
implemented and deployed.  But lacking an internal coherence, it will be harder
to understand, harder to learn, harder to get right both for users and
implementers of tools (see XML:-(.

Tom Petch

---

From: Phil Shafer <[email-masked]>
Date: Tue, 12 Aug 2008 14:56:39 -0400

>implementers of tools (see XML:-(.

Are we not doing enough to communicate the "Zen of YANG"?  Or
are you feeling that there's no zen here at all?

Thanks,
 Phil

---

From: "tom.petch" <[email-masked]>
Date: Wed, 13 Aug 2008 11:56:05 +0200

---- Original Message -----
From: "Phil Shafer" <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: "Andy Bierman" <[email-masked]>; "NETMOD Working Group"
<[email-masked]>
Sent: Tuesday, August 12, 2008 8:56 PM
Subject: Re: [netmod] when statement

> are you feeling that there's no zen here at all?
My perception is that the communication is lacking, that the Zen is encoded
across a number of details and so is hard to mine.  (I was going to say Tao of
YANG but think that your Zen of YANG is better).

Tom Petch