Martin Bjorklund <[email protected]> writes:

> Andy Bierman <[email protected]> wrote:
>> On Thu, Apr 21, 2016 at 1:45 AM, Martin Bjorklund <[email protected]> wrote:
>> 
>> > Hi Andy,
>> >
>> > Are you ok with the proposed OLD/NEW changes?
>> >
>> >
>> Yes, except the issue of multiple deviations (that could be in 1 module on
>> N modules).
>> The actual result depends on the order the deviations are applied.
>> This "last one wins" is implementation-dependent. Some text should be added
>> either to fix it or warn people.  (Note that the <hello> and YANG library
>> are not ordered so they cannot be used to inform the client which of
>> the N is actually applied.)  This also affects the order of "deviate add
>> default"
>> for leaf-list.
>
> I prefer some warning text.  In reality, I don't think is an issue.

Hopefully. It could become a problem if, for example, deviations are
bundled with other definitions.

Lada

>
>
> /martin
>
>
>
>
>
>> 
>> 
>> 
>> >
>> > /martin
>> 
>> 
>> 
>> Andy
>> 
>> 
>> >
>> 
>> 
>> >
>> > Martin Bjorklund <[email protected]> wrote:
>> > > Andy Bierman <[email protected]> wrote:
>> > > > Hi,
>> > > >
>> > > > The ABNF for "default" is wrong in the deviate-*-stmt (add, replace,
>> > delete)
>> > > > Is says [default-stmt] but it should be *default-stmt
>> > >
>> > > Thanks, fixed.
>> > >
>> > > But for deviate-replace, it is not clear what the correct answer is.
>> > >
>> > > This is pretty clear:
>> > >
>> > >   leaf foo {
>> > >     type int32;
>> > >     default 42;
>> > >   }
>> > >
>> > >   deviation /foo {
>> > >     deviate replace {
>> > >       default 10;
>> > >     }
>> > >   }
>> > >
>> > > But what about this:
>> > >
>> > >   leaf-list bar {
>> > >     type int32;
>> > >     default 42;
>> > >     default 43;
>> > >   }
>> > >
>> > >   deviation /bar {
>> > >     deviate replace {
>> > >       default 10;
>> > >       default 11;
>> > >     }
>> > >   }
>> > >
>> > > Are all defaults changed?
>> > >
>> > > Compare with must and unique - they can not be replaced currently.
>> > >
>> > > In order to resolve this we probably need more text as well :(
>> > >
>> > >
>> > > OLD:
>> > >
>> > >   The argument "replace" replaces properties of the target node.  The
>> > >   properties to replace are identified by substatements to the
>> > >   "deviate" statement.  The properties to replace MUST exist in the
>> > >   target node.
>> > >
>> > >
>> > > NEW:
>> > >
>> > >   The argument "replace" replaces properties of the target node.  The
>> > >   properties to replace are identified by substatements to the
>> > >   "deviate" statement.  The properties to replace MUST exist in the
>> > >   target node.  If multiple properties exist in the target node, all
>> > >   of them are replaced with the new properties defined in the
>> > >   substatements to the deviate statement.
>> > >
>> > > + add an example to the section "Usage examples":
>> > >
>> > > NEW:
>> > >
>> > >   In this example, the original definition of a leaf list has two
>> > >   default values "42" and "43:
>> > >
>> > >     leaf-list bar {
>> > >       type int32;
>> > >       default 42;
>> > >       default 43;
>> > >     }
>> > >
>> > >   A server can change this to the values "10" and "11" instead:
>> > >
>> > >     deviation /base:bar {
>> > >       deviate replace {
>> > >         default 10;
>> > >         default 11;
>> > >       }
>> > >     }
>> > >
>> > >
>> > > Also, change the grammar:
>> > >
>> > > OLD:
>> > >
>> > > deviate-replace-stmt = deviate-keyword sep replace-keyword-str optsep
>> > >                       (";" /
>> > >                        "{" stmtsep
>> > >                            ;; these stmts can appear in any order
>> > >                            [type-stmt]
>> > >                            [units-stmt]
>> > >                            [default-stmt]
>> > >                            [config-stmt]
>> > >                            [mandatory-stmt]
>> > >                            [min-elements-stmt]
>> > >                            [max-elements-stmt]
>> > >                        "}") stmtsep
>> > >
>> > > NEW:
>> > >
>> > > deviate-replace-stmt = deviate-keyword sep replace-keyword-str optsep
>> > >                       (";" /
>> > >                        "{" stmtsep
>> > >                            ;; these stmts can appear in any order
>> > >                            [type-stmt]
>> > >                            [units-stmt]
>> > >                            *must-stmt
>> > >                            *unique-stmt
>> > >                            *default-stmt
>> > >                            [config-stmt]
>> > >                            [mandatory-stmt]
>> > >                            [min-elements-stmt]
>> > >                            [max-elements-stmt]
>> > >                        "}") stmtsep
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > > Is it intentional that the ABNF for deviate-delete-stmt leaves out
>> > > > config, mandatory, max-elements, and min-elements?
>> > > > I understand why "type" cannot be removed.
>> > >
>> > > I don't really remember, but I can see that if you want to "delete"
>> > > min-elements you can replace it and set it to 0.
>> > >
>> > > > IMO the rest of the statements should be removable.
>> > >
>> > > > Sec. 7.20.3.2 does not mention the restrictions indicated in the ABNF.
>> > > > This section should make it clear a leaf has only 1 default
>> > > > and the 0..n refers to leaf-list only.
>> > >
>> > > In general, the result after applying deviations must be valid - e.g.,
>> > > you cannot deviate "foo" as the default for an int32 leaf.
>> > >
>> > > > It should also be clear that the "deviate add default" for a leaf-list
>> > > > is YANG statement order-dependent.
>> > > >
>> > > > Not as obvious -- a config=false leaf-list can have duplicate default
>> > > > values.
>> > > > The deviate-stmt has no way to specify which 1 to delete or replace
>> > > > if there are duplicates.
>> > >
>> > > Unless replace will replace *all*, as suggested above.
>> > >
>> > >
>> > > /martin
>> > >
>> > > _______________________________________________
>> > > netmod mailing list
>> > > [email protected]
>> > > https://www.ietf.org/mailman/listinfo/netmod
>> > >
>> >
>
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

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

Reply via email to