Subject: [netmod] must-stmt in groupings

From: Andy Bierman <[email-masked]>
Date: Sat, 09 Aug 2008 09:16:23 -0700

Hi,

 From 4.2.8:

Here is the example on pg 23:

      augment system/login/user {
          when "class != 'wheel'";
          leaf uid {
              type uint16 {
                  range "1000 .. 30000";
              }
          }
      }

What if this augment were in a grouping (because it's legal)?

module foo {

   ...
   grouping foo {
      augment /system/login/user {
          when "class != 'wheel'";
          leaf uid {
              type uint16 {
                  range "1000 .. 30000";
              }
          }
      }
    }
}

module bar {

   ...
   uses foo:foo;
}

1) The no-prefix == local module rule breaks the augment
    Xpath target, since the local prefix in the grouping module
    is different for a uses-stmt in another module.

2) If the augment had a global target (/nm:system/nm:login/nm:user)
    which is allowed in a top-level grouping, expanded to a top-level
    uses, then even if all the prefixes are entered, they are relative
    to the grouping module (foo), not the uses module (bar).  It's
    broken with or without prefixes.

3) The 'when' target Xpath expression is specified with prefixes
    from the grouping module, but there is no point evaluating this
    expression in the grouping, since the node position that matters
    is relative to the 'uses' statement in a different module.

4) If the 'when' Xpath expression has any QNames in it, then
    they will be evaluated with the wrong prefixes if the 'uses'
    is in a different module.

3 fatal flaws, 1 non-intuitive warning.
Back to the drawing board.

Andy

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

---

From: Andy Bierman <[email-masked]>
Date: Sat, 09 Aug 2008 09:43:28 -0700

Hi,

> Back to the drawing board.

1 solution (for those playing along in the Home Edition ;-)
is to make top-level augments a separate statement,
like augment-external, and make it a body-stmt instead
of a data-def-stmt.  The 'when' clause is still a problem though.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 09 Aug 2008 21:39:31 +0200 (CEST)

>       augment /system/login/user {

No, this is not legal.  7.15 says

   If the
   "augment" statement is on the top-level in a module or submodule, the
   absolute form of a schema node identifier MAY be used.  Otherwise,
   the descendant form MUST be used.

But I agree that it might be a good idea to use two separate
statements.  The current 'uses' substatements have another problem, so
maybe we can solve both problems.  The problem is that the grammar for
e.g. 'leaf' is context-dependant.  When it appears within a 'uses', it
cannot have a type for example.  Here is one idea:

  uses Interface {
      refine interface/mtu {
          default 1500;
      }
      extend interface/unit {
          leaf my-vlan-param { ... }
      }
  }

The substatements to 'uses' clearly signals what is going on -
refinements and extensions to the grouping.

Then the 'augment' statement would be a top-level thing only.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sat, 09 Aug 2008 13:33:31 -0700

>    the descendant form MUST be used.

This seems odd because objects within a top-level grouping
and used at the top-level are visible in other modules
as top level elements.

There is still a problem with prefixes in must/when XPath expressions
that appear within a grouping which is used in a different module.

> refinements and extensions to the grouping.

But this is broken because you cannot refine a local grouping this way.

I like the current augments and uses design just fine because there
cannot be any duplicates and it supports local groupings.
It is an implementation detail to keep track of the
calling context.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 10 Aug 2008 21:36:53 +0200 (CEST)

> and used at the top-level are visible in other modules

But the "augment" statement is not on the top-level, it is within a
grouping.

> that appear within a grouping which is used in a different module.

7.11 says:

   Prefix mappings, type names, grouping names,
   and extension usage are evaluated in the hierarchy where the grouping
   statement appears.

So I don't think this is a problem.

> But this is broken because you cannot refine a local grouping this way.

I don't udnerstand what you mean.  What is broken?

> cannot be any duplicates and it supports local groupings.

The idea is that you can do exacty the same things with the new
'refine' statement.  It is just a different syntax, but the syntax has
a couple of advantages - it gets rid of the context-dependendent
grammar; it uses a target path to modify, just like augemnt (and
possibly extend) instead of the current "overlay" style.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sun, 10 Aug 2008 13:22:49 -0700

> So I don't think this is a problem.

Right -- the prefixes in any must-stmt in some leaf in the grouping
are relative to the module containing the grouping.

When the agent expands the grouping into another module,
it must normalize all the Xpath expressions so they refer
to the correct module, regardless of the set of module
prefixes in use in the module with the uses-stmt.

The draft should explain that a must-stmt within a grouping
cannot be fully evaluated because the uses node is the current
context, and it is unknown.  Also, an implementation must resolve
all differences in module prefix usage when using groupings from
other modules.

> I don't udnerstand what you mean.  What is broken?

Currently, I can refine a local grouping within a uses:

   uses FooContainer {
     container foo {
       grouping foo-local {
         leaf a1 {
           type string { length "min..10"; }
         }
       }
     }
   }

How are you going to do that with Xpath?
IMO, adding meta-data like groupings into the object tree
makes it too complicated.  The current nested approach
also makes it easier to read and force top-down definition.

The Xpath approach can be in any order:

   uses FooContainer {
     refine "foo/tab1/a1" {
      length "min..10";
     }

     // 11 more direct mods of 'a1' leafs...

     refine "foo/tab1/a1" {
      config true;
     }
     refine "foo/tab1" {
      config false;
     }
   }

IMO the current approach is cleaner, but one can construct
examples where XPath is much more terse (at the expense
of the info carried in the object type).

> possibly extend) instead of the current "overlay" style.

But groupings are not objects and grouping names are not
in the same YANG naming scope as objects.

Andy