On Fri, Sep 30, 2016 at 7:29 AM, Martin Bjorklund <[email protected]> wrote:
> Andy Bierman <[email protected]> wrote: > > On Thu, Sep 29, 2016 at 10:44 PM, Martin Bjorklund <[email protected]> > wrote: > > > > > Andy Bierman <[email protected]> wrote: > > > > 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? > > > > > > 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. > > > > > > > OK > > > > But it is not intuitive that the resulting type-stmt is not validated at > > all within the target > > 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! > } > } > } > > 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. > /martin > > Andy > > > , 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 > > > > > > > > > > > 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; > > > > } > > > > } > > > > } > > > > > > > > > > > > /martin > > > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
