Subject: [netmod] multiple deviation-stmts for 1 target

From: Andy Bierman <[email-masked]>
Date: Mon, 02 Mar 2009 15:23:37 -0800

Hi,

The draft does not seem to contain any CLR prohibiting
multiple deviation statements from referencing the
same target.  Good. This is not easy to enforce, since the
statements can be in any module (like an augment).
Also, it is OK (e.g.) for 1 deviations module to add a default-stmt,
and another to change the mandatory-stmt in the same object.

Unlike an augment protected by separate namespaces,
there is just one target object.  So it is clearly an error
if any of the deviate-stmts step on each other (e.g.,
1 removes the default, 1 replaces the default).

All the deviate-stmts need to be gathered from all
the deviation-stmts with the same target and
validated as a group (except the compiler won't
know about deviations from modules not imported).

The draft should mention something about this.
It only contains the requirements for one deviation
statement applied to one object.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 03 Mar 2009 11:52:37 +0100 (CET)

> 1 removes the default, 1 replaces the default).

Is it an error if two deviate-stmts both replace the default?  If not,
which one wins? If this is an error, the implementation has to collect
and analyze all deviation statement as one group (that's probably what
you just wrote...)

If this is what we want, I can add to "The deviation Statement":

  A target node may be deviated by multiple deviation statements,
  possibly defined in multiple modules.

and to "The deviate Statement":

  It is an error if the same property of a particular target node is
  deviated in more than one "deviate" statement in all modules
  supported by a device.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 03 Mar 2009 04:35:14 -0800

>   deviated in more than one "deviate" statement in all modules

I have run into problems when 1 deviate-stmt replaces the type-stmt
and another one (possibly in another deviation-stmt)
replaces the default-stmt.

Do you validate the old default-stmt against the new type?
Do you validate the new default-stmt against the old type?
Or just the new default-stmt against the new type, assuming you can
find both of them at once?

Maybe the 1 deviation-stmt per target rule is a simpler CLR.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 03 Mar 2009 22:38:40 +0100 (CET)

> Maybe the 1 deviation-stmt per target rule is a simpler CLR.

Yes, I think it is.  Is this text ok for the CLR:

  It is an error if a target node is deviated by more than "deviation"
  statement in all modules supported by a device.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 03 Mar 2009 18:32:38 -0800

> Maybe the 1 deviation-stmt per target rule is a simpler CLR.

I don't think this CLR is really needed.
The important factor is that the validation tool
must be aware of all the deviation statements for
a particular object.  That is done in an implementation-specific
manner (similar to constructing the module capability URI).

My only hypothetical use-case is a vendor that has
an existing application for generating deviations, but
only for some things, like changing the default-stmts.
If any platform engineer needs to tweak a different sub-clause
for any object that the 'defaults' app already altered,
then this CLR will prevent them from doing that.
(BTW, this platform engineer does not have ownership
of the defaults app, so changing that code is not an option.)

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 04 Mar 2009 09:39:53 +0100 (CET)

> I don't think this CLR is really needed.

Just to be clear - do you think that the current text is fine, or do
we need to add anything?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 04 Mar 2009 06:50:33 -0800

> Just to be clear - do you think that the current text is fine, or do

I can't think of any normative text for this issue.

Here are some CLRs that fall out of the syntax:

   - a key leaf cannot be changed to 'not-supported'
   - a key leaf cannot be changed from config true to false
   - a leaf within the default case for a choice cannot
     be changed from mandatory false to true
   - the text says an exact match is needed for
     the boolean clauses (e.g., mandatory) but this is useless
     because the property is probably derived from its parent
     instead of with an explicit clause.  You need to ignore that text
     to implementation deviations correctly.
   - exact match on unique and must statements are error-prone
     because they include whitespace (too bad)

It does no good to validate individual deviate-stmts
against the target object since other deviate-stmts may
be required to make the altered object valid YANG.
(e.g, many pairs like type/default, mandatory/default,
min-elements/max-elements).

It is not clear if an implementation is allowed to reject
deviations because (when processed serially) the composite object
is invalid (e.g, add mandatory true and remove default 7;
this is an error in this order, but OK in the reverse order.)

I do not see much upside in checking for all the corner cases.
There are dozens of them to worry about.  I am much more
inclined to force the data modeler to construct the deviation-stmts
in the correct order, and apply the deviate-stmts in the
order they were entered in the YANG file.

Open Issue: Is there a standard processing model for validating
and applying deviations, or should the current approach remain,
which is that implementations can do whatever they want?

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 04 Mar 2009 21:47:28 +0100 (CET)

> I can't think of any normative text for this issue.

How about saying that the data model after applying all deviations
MUST still be valid?  Maybe even say that is MUST be valid after
applying them in *any* order?

>      to implementation deviations correctly.

This only affects 'delete'.  So if you want to "delete" the inherited
"config true" property, you can instead add "config false".

>      because they include whitespace (too bad)

Yes, this might be error prone, but this is a corner case, and at
least the tools will complain if you enter an incorrect string.

/martin