Subject: [YANG] sec 7.14.2 -- augment's when statement

From: Andy Bierman <[email-masked]>
Date: Tue, 11 Dec 2007 12:16:21 -0800

Hi,

The YANG draft does not really specify much about the sparse-augments
mechanism.  IMO, it has the same problem as the partial-lock Xpath
expression, wrt/ different result-sets depending on the moment
the Xpath expression is evaluated.

As stupid as this decl is, it is legal:

augment "/interfaces/interface[name='Ethernet0/1']" {

   when "/interfaces/interface/ifInOctets div 7";

   leaf inTemp1 { type int32; }
   leaf inTemp2 { type float64; }

}

1) Xpath does not force the DM writer to keep one Xpath expression
    free of instance information, and another specific to some instances.
    The augment target and when clauses do not treat the interface object
    the same way.  Both are legal Xpath, but only one makes sense
    wrt/ the conceptual data model.

2) The 'when' expression is allowed to be dynamic.
    This definition adds a couple counters to interface 'Ethernet0/1',
    which exist when ifInOctets is divisible by seven.  The counters
    appear and disappear as the counter ticks.

IMO, it is okay to limit partial-lock and when expressions,
such that they support real use cases, and are implementable
and inter-operable.  Full Xpath 1.0 has many more absurd corner-cases
than this one.

Study the spec for awhile to see what I mean:

http://www.w3.org/TR/xpath

Andy

_______________________________________________
YANG mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/yang

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 11 Dec 2007 21:31:57 +0100 (CET)

Andy Bierman <[email-masked]> wrote:
> mechanism. 

[...]

>    when "/interfaces/interface/ifInOctets div 7";

Yes you're right.

We couldn't think of a (yet another) restricted form of XPath that we
could use.  If you (or anybody else) has a suggestion that defines the
when expression

  "such that they support real use cases"

please let us know!

/matin

---

From: Phil Shafer <[email-masked]>
Date: Tue, 11 Dec 2007 15:33:41 -0500

>the Xpath expression is evaluated.

The big difference is that the YANG XPath is known at build time,
so I can construct my model appropriately.  Also key is that
the "when" is defined by the data model, and is not a random
string pitched at the server by an application.

>augment "/interfaces/interface[name='Ethernet0/1']" {

The argument to augment can't have predicates.

>   when "/interfaces/interface/ifInOctets div 7";

If I made a model like this, I could write C code to do this
test, avoiding turning statistics into XML for my XPath code.

>    wrt/ the conceptual data model.

I'm not sure I follow you, but both are conceptual.

>2) The 'when' expression is allowed to be dynamic.

Dynamic, but not fully random.  The "when" clause is not
when the data model is defined, and can be implemented within
the server as needed.  The XPath is a way of expressing the
restriction, but the server is free to code it by hand based
on the model _or_ by XPath expression evaluation.  No one is
required to implement a data model that has silly "when"s.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Tue, 11 Dec 2007 15:43:45 -0500

>  "such that they support real use cases"

It's hard to put "Don't be stupid" in a spec.  But anyone making
useless YANG modules will quickly notice that no one implements
them.  The SMI spec doesn't say "don't put a zillion layers of
'.1.1.1.1.1.1' in your MIBs" but folks seem to get it.

We need to add suitable words about "implementation considerations"
in the "when" section, but I think that will suffice.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 12 Dec 2007 04:32:12 -0800

>   "such that they support real use cases"

Let's start with the requirements.

The syntax is okay -- I figured out where augments-in-augments
could be used (descendant form inside an absolute form).

No WG bothered to separate config data from 'other' data before.
We could separate 'other' into more categories:

   0 - config
   1 - key (naming) component
   2 - read-only static property (e.g, ifType)
   3 - read-only dynamic property (e.g., ifOperStatus)
   4 - read-only statistic (e.g., ifInOctets)
   5 - read-write dynamic property (e.g., ifMtu)

IMO, only (1) and (2) are OK for 'when' clauses, but who knows.

Andy