Subject: [netmod] augment target

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 25 Nov 2008 18:15:22 +0100

Hi,

YANG draft says this about the target of "augment": "The target node
MUST be either a container, list, choice, case, input, output, or
notification node." But is the following legal?

module foo {
  namespace "urn:foo";
  prefix foo;
  grouping g {
    container c {
      leaf a { type string; }
    }
  }
  container root {
    uses g;
  }
}

module bar {
  namespace "urn:bar";
  prefix bar;
  import foo { prefix foo; }
  augment foo:root/foo:c {
    leaf b { type int32; }
  }
}

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: Tue, 25 Nov 2008 09:28:09 -0800

> notification node." But is the following legal?

yes

>   import foo { prefix foo; }

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 25 Nov 2008 18:48:17 +0100

> > notification node." But is the following legal?

How about this?

module foo {
  namespace "urn:foo";
  prefix foo;
  include subfoo;
  container root {
    leaf dummy { type empty; }
  }
}

submodule subfoo {
  belongs-to foo;
  augment /foo:root {
    container c {
      leaf a { type string; }
    }
  }

module bar {
  namespace "urn:bar";
  prefix bar;
  import foo { prefix foo; }
  augment /foo:root/foo:c {
    leaf b { type int32; }
  }
}

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Tue, 25 Nov 2008 10:19:50 -0800

>>> notification node." But is the following legal?

no -- nothing to do with augment.
The identifier 'foo:root' cannot be visible in any submodule
because it is in the main module. The belongs-to clause
also changed.

>   augment /foo:root/foo:c {

This would be fine I think:

module foo {
   namespace "urn:foo";
   prefix foo;
   include subroot;
   include subfoo;
}

submodule subroot {
   belongs-to foo;
   container root {

submodule subfoo {
   belongs-to foo { prefix foo; }
   include subroot;
   augment /foo:root {
     container c {
       leaf a { type string; }
     }
   }
}

module bar {
   namespace "urn:bar";
   prefix bar;

Just for fun, let's add a when-stmt to container 'c':

submodule subfoo {
   belongs-to foo { prefix foo; }
   include subroot;
   augment /foo:root {
     container c {
       when "../foo:dummy";
       leaf a { type string; }
     }
   }
}

If the empty leaf /root/dummy is present at runtime,
then the /root/c container will exist in the schema,
allowing leaf 'b' from module bar to also exist.
If /root/dummy gets deleted, then the entire 'c'
container gets magically deleted at the same time.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 25 Nov 2008 20:42:59 +0100

OK, after correcting belongs-to, is this valid?

module foo {
  namespace "urn:foo";
  prefix foo;
  include subfoo;
  container root {

submodule subfoo {

module bar {
  namespace "urn:bar";
  prefix bar;

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Tue, 25 Nov 2008 11:52:45 -0800

> OK, after correcting belongs-to, is this valid?

No, because 'root' is not visible in 'subfoo'.
Only the prefix is available for mapping,
in case you want to use it in places where an optional
prefix is allowed, like XPath expressions.

Stuff in the main module is not visible in submodules at all.
Even with submodules, you have to be careful to avoid loops
(e.g., submodule subroot includes subfoo).  Of course, a
good compiler will detect any definition loops, and there
are a lot of them possible in YANG.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 25 Nov 2008 21:11:20 +0100

> prefix is allowed, like XPath expressions.

How can then be the submodule tree attached to a non-root level in the
main module? I remember an example from the interim where augment in a
submodule was used just for this.

Lada
 
-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 26 Nov 2008 14:04:45 +0100

Hello,
I always found it ugly and surprising that there is no way to make stuff in the module visible 
to submodules. I think this will lead to quite a number of near empty (main) modules.
As Andy has shown there is a workaround, but it is a workaround.
Balazs

-- 
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: Andy Bierman <[email-masked]>
Date: Wed, 26 Nov 2008 06:48:22 -0800

Balazs Lengyel wrote:
> Hello,
> I always found it ugly and surprising that there is no way to make stuff 
> in the module visible to submodules. I think this will lead to quite a 
> number of near empty (main) modules.

It is the way submodules work.

I think the current rules are OK.
If foo includes sub-foo, and sub-foo can include its parent 'foo',
that is no different than module A importing B and B importing A.
It creates an import loop and it is a fatal error in YANG.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 27 Nov 2008 08:19:26 +0100

> that is no different than module A importing B and B importing A.

The relationship between a submodule and its parent module is fixed in
both directions (via include and belongs-to), so I see no reason why the
submodule cannot use the top-level symbols defined in the parent module
right away. The submodule even now cannot override definitions appearing
in the parent module because they would clash when the submodule is
included.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Sun, 30 Nov 2008 08:37:05 -0800

> in the parent module because they would clash when the submodule is

I prefer the current approach, which is that every symbol
external to the file must be imported, included, or a
YANG keyword or builtin type name.

I prefer not to add any more complexity for redundant or rare use cases.
You just have to to define the data structure in a submodule.  You can
move an object from the main module to a submodule as well (revision
sec. should allow this).

The other options:

   1) let main module symbols magically appear in submodules
   2) invent a new 'include-from-main-module' mechanism

are not acceptable, IMO.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 01 Dec 2008 08:01:56 +0100

>    1) let main module symbols magically appear in submodules

I don't think there is any magic in doing so, because of the belongs-to
statement. The isolation between the main module and submodule is weak
anyway in that symbols from a submodule can clash with those in the main
module, so not being able to use definitions from the main module is
just an artificial annoyance without any benefit.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 01 Dec 2008 09:24:16 +0100

Andy Bierman wrote:
>>>> I always found it ugly and surprising that there is no way to make 
>>>> stuff in the module visible to submodules. I think this will lead to 
>>>> quite a number of near empty (main) modules.
IMHO this is not such a rare case. Our designers have been asking for it already.
We can live with the current solution, but it's not nice.
Balazs
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod