Subject: [netmod] deviation-stmt (7.20.3)

From: Andy Bierman <[email-masked]>
Date: Thu, 29 Sep 2016 15:22:13 -0700

Hi,

The deviation section has a lot of fluff text about how bad deviations are,
but very little text on how to process the "deviate" statement correctly.

The text is not clear if the statements altered in the target module
are semantic patches or syntactic patches.  Are the sub-statements
of the deviate-stmt fully processed in the scope of the deviation module
or in the scope of the target module? In this example, is the type-stmt
resolved in A or dev-A?

Similar issues for deviating a default for an identityref.

  module A {
    namespace "...";
    prefix a;
    // no imports!

    leaf foo {
       type string;
     }

    leaf bar {
       type string;
     }

    leaf baz {
       type string;
     }
  }

  module A-dev {
    ...
    import A { prefix a; }
    import C { prefix c; }
    import ietf-interfaces { prefix if; }

    // variant 1: inline leafref but module A does not import path module
    deviation /a:foo {
       deviate replace {
          type leafref {
               base /c:modules/c:module/c:name;
           }
        }
     }

   // variant 2: imported typedef but module A does not import it
    deviation /a:bar {
       deviate replace {
          type if:interface-ref;
        }
     }

    // variant 3: local typedef but module A cannot import it (circular
imports)
    typedef mystring {
        type string { length "1..10"; }
    }

    deviation /a:baz {
       deviate replace {
          type mystring;
        }
     }
  }

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 30 Sep 2016 07:44:43 +0200 (CEST)

> or in the scope of the target module? In this example, is the type-stmt

Deviations are not special compared to other statements; if you refer
to something in an external module the external module must be
imported and the prefixes are resolved in the module where they are
used.  The type statement is resolved in the same way if it is defined
in a leaf, a typedef or in a deviate.

So in the examples below, all variants are legal.

>         type string { length "1..10"; }

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 30 Sep 2016 07:21:56 -0700

> So in the examples below, all variants are legal.

OK

But it is not intuitive that the resulting type-stmt is not validated at
all within the target
module, compared to some other deviations:

   module A {
      ...
      list foo {
         max-elements 3;
         ...
      }
   }

   module A-dev {
      ...
      deviation /a:foo {
         deviate add {
             min-elements 4;
         }
      }
   }

The "min-elements 4" statement is valid in the A-dev module but when patched
into list /foo it is not valid.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 30 Sep 2016 16:29:57 +0200 (CEST)

Andy Bierman <[email-masked]> wrote:
> module

Syntactically, it is evaluated in A-dev, but the result must be
semantically validated together with A.  For example:

  module A {
    ...
    leaf foo {
      type uint32;
    }
  }

  module A-dev {
    ...
    deviation /a:foo {
      deviate add {
        default -1;  // error!
      }
    }
  }

/martin

> , compared to some other deviations:
> 
> 
>    module A {
>       ...
>       list foo {
>          max-elements 3;
>          ...
>       }
>    }
> 
>    module A-dev {
>       ...
>       deviation /a:foo {
>          deviate add {
>              min-elements 4;
>          }
>       }
>    }
> 
>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 30 Sep 2016 08:51:32 -0700

On Fri, Sep 30, 2016 at 7:29 AM, Martin Bjorklund <[email-masked]> wrote:

> > > > The deviation section has a lot of fluff text about how bad
> deviations
> > > are,

I sort of understand the final result requirement

   After applying all deviations announced by a server, in any order,
   the resulting data model MUST still be valid.

The term "in any order" seems to cover the corner-case where multiple
deviations target the
same statement (e.g., 1 bad, 1 good).

It does not say anything about 2 good deviations

from module dev-A:
   default 10;

from module dev-B:
   default 20;

So "in any order" means the implementation can pick any order and last one
wins?
The YANG library does not have ordered deviations. There is no defined
procedure
in NETCONF for applying deviations in a particular order.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 30 Sep 2016 18:01:22 +0200

My biggest problem with deviations is that a number of things can
not be deviated:

description

reference

Regards Balazs

On 2016-09-30 00:22, Andy Bierman
wrote:

Hi,

deviations are,

but very little text on how to process the "deviate"
statement correctly.

The text is not clear if the statements altered in the
target module

are semantic patches or syntactic patches.  Are the
sub-statements

of the deviate-stmt fully processed in the scope of the
deviation module

or in the scope of the target module? In this example, is
the type-stmt

resolved in A or dev-A?

module A {

namespace "...";

prefix a;

// no imports!

leaf foo {

type string;

}

leaf bar {

type string;

}

leaf baz {

type string;

}

}

module A-dev {

...

import A { prefix a; }

import C { prefix c; }

// variant 1: inline leafref but module A does not
import path module

deviation /a:foo {

deviate replace {

type leafref {

}

}

}

// variant 2: imported typedef but module A does not
import it

deviation /a:bar {

deviate replace {

type if:interface-ref;

}

}

// variant 3: local typedef but module A cannot
import it (circular imports)

typedef mystring {

}

deviation /a:baz {

deviate replace {

type mystring;

}

}

}

Andy

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

--
Balazs Lengyel Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909 email: [email-masked]