Andy Bierman <[email protected]> wrote:
> On Wed, Sep 14, 2016 at 10:08 AM, Martin Bjorklund <[email protected]> wrote:
>
> > Andy Bierman <[email protected]> wrote:
> > > On Wed, Sep 14, 2016 at 5:29 AM, Vladimir Vassilev <
> > [email protected]
> > > > wrote:
> > >
> > > > On 09/13/2016 06:48 PM, Andy Bierman wrote:
> > > >
> > > > Hi,
> > > >
> > > > I am not in favor of changing when-stmt so it works like must-stmt.
> > > > I prefer it work as designed. It is like choice-stmt, where a new case
> > > > will cause objects from the previously selected case to be
> > automatically
> > > > deleted.
> > > >
> > > > There is no text in RFC 7950 that actually says an error is returned
> > > > if a when-stmt is false because an anyxml or anydata input parameter
> > > > was converted to top-level YANG nodes and reprocessed.
> >
> > Hmm, I agree that the text could be more precise. But note that
> > section 8.3 says:
> >
> > For configuration data, there are three windows when constraints MUST
> > be enforced:
> >
> > So the entire section 8.3 is all about configuration data, which is
> > manipulated by various RPCs.
> >
> > Section 8.3.2 specifically talks about "applying the data to the
> > configuration
> > datastore", and that "unknown-element" is returned for a request that
> > modifies a node tagged with "when".
> >
> >
>
> You mean this sentence:
>
> o Modification requests for nodes tagged with "when", and the "when"
> condition evaluates to "false". In this case, the server MUST
> reply with an "unknown-element" <error-tag> in the <rpc-error>.
>
> Consider this example:
>
> leaf foo {
> type int32;
> when "../bar=20";
> }
>
>
> So the text only applies to modifications to the /foo leaf, right?
> Create and delete operations do not cause an error.
The intention was that also create/delete would cause this error.
> Edits to other nodes (e.g., /bar) do not cause an error.
Yes.
> This does not seem to do anything because the objects specified in the
> when-stmt
> are not allowed to be part of the object affected by the when-stmt.
>
> o If the "when" statement is a child of any other data definition
> statement, the accessible tree is tentatively altered during the
> processing of the XPath expression by replacing all instances of
> the data node for which the "when" statement is defined with a
> single dummy node with the same name, but with no value and no
> children. If no such instance exists, the dummy node is
> tentatively created. The context node is this dummy node.
>
>
> So I do not see how I can edit /foo and cause /foo to be deleted.
Agreed.
> According to the text, if I alter /bar (not /foo) then /foo can be silently
> deleted and this is not an error.
Yes.
/martin
>
>
>
> > /martin
> >
> >
> >
> Andy
>
>
> >
> >
> >
> > > >
> > > > The text only covers direct when-stmts like below:
> > > >
> > > > rpc plot-point {
> > > > input {
> > > > leaf point-type {
> > > > type enumeration {
> > > > enum 2d;
> > > > enum 3d;
> > > > }
> > > > mandatory true;
> > > > }
> > > > leaf X { type int32; mandatory true; }
> > > > leaf Y { type int32; mandatory true; }
> > > > leaf Z {
> > > > when "../point-type = '3d';
> > > > mandatory true;
> > > > type int32;
> > > > }
> > > > }
> > > > }
> > > >
> > > >
> > > > If the client sets point-type to '2d' and provides a Z leaf, then an
> > error
> > > > is returned.
> > > > This is the only type of usage the text in question actually covers.
> > > >
> > > > It is <edit-config> RPC that has started the thread (the 'when'
> > validation
> > > > in <plot-point> is much clearer and I agree with all you say above).
> > There
> > > > was the original example by Yves (changed when "A" to when "../A"):
> > > >
> > > > container root {
> > > > leaf A {
> > > > type empty:
> > > > }
> > > > leaf B {
> > > > when "../A";
> > > > type uint32;
> > > > }
> > > > }
> > > > ... and the netconf <edit-config>:
> > > >
> > > > <rpc message-id="101"
> > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> > > > <edit-config>
> > > > <target>
> > > > <running/>
> > > > </target>
> > > > <config>
> > > > <root xmlns="http://dummy.com"; <http://dummy.com>>
> > > > <A/>
> > > > <B>
> > > > 3
> > > > </B>
> > > > </dummy>
> > > > </config>
> > > > </edit-config>
> > > > </rpc>
> > > >
> > > > There is consensus the 'when' statement is satisfied in this case which
> > > > answers his original question.
> > > >
> > > > However if we make change to the original example by assuming the
> > target
> > > > is not 'running' but 'candidate' and /root/A is already present before
> > the
> > > > following <edit-config> is processed:
> > > >
> > > > <rpc message-id="101"
> > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> > > > <edit-config>
> > > > <target>
> > > > <candidate/>
> > > > </target>
> > > > <config>
> > > > <root xmlns="http://dummy.com"; <http://dummy.com>>
> > > > <B>
> > > > 3
> > > > </B>
> > > > </dummy>
> > > > </config>
> > > > </edit-config>
> > > > </rpc>
> > > >
> > > > My interpretation of the relevant text in YANG 1.0 and YANG 1.1 is the
> > > > 'when' statement is satisfied since when the <edit-config> is applied
> > to
> > > > the 'candidate' configuration the result will be valid 'candidate'
> > > > configuration state and this is what matters. If there is consensus on
> > that
> > > > I have nothing to add.
> > > >
> > > >
> > >
> > >
> > >
> > > Here is the YANG for <edit-config>.
> > > Note that there is no when-stmt at all in the entire definition.
> > > The claims that RFC 7950 actually says enforce the when-stmts that
> > > are implied by the objects represented in the <config> anyxml subtree
> > > are just not careful readers.
> > >
> > >
> > >
> > >
> > >
> > > rpc edit-config {
> > > description
> > >
> > >
> > > "The <edit-config> operation loads all or part of a specified
> > > configuration to the specified target configuration.";
> > >
> > > reference "RFC 6241, Section 7.2
> > > <https://tools.ietf.org/html/rfc6241#section-7.2>";
> > >
> > > input {
> > > container target {
> > > description
> > > "Particular configuration to edit.";
> > >
> > > choice config-target {
> > > mandatory true;
> > > description
> > > "The configuration target.";
> > >
> > > leaf candidate {
> > > if-feature candidate;
> > > type empty;
> > > description
> > > "The candidate configuration is the config target.";
> > > }
> > > leaf running {
> > > if-feature writable-running;
> > > type empty;
> > > description
> > > "The running configuration is the config source.";
> > > }
> > > }
> > > }
> > >
> > > leaf default-operation {
> > > type enumeration {
> > > enum merge {
> > > description
> > > "The default operation is merge.";
> > > }
> > > enum replace {
> > > description
> > > "The default operation is replace.";
> > > }
> > > enum none {
> > > description
> > > "There is no default operation.";
> > > }
> > > }
> > > default "merge";
> > > description
> > > "The default operation to use.";
> > >
> > > leaf test-option {
> > > if-feature validate;
> > > type enumeration {
> > > enum test-then-set {
> > > description
> > > "The server will test and then set if no errors.";
> > > }
> > > enum set {
> > > description
> > > "The server will set without a test first.";
> > > }
> > >
> > > enum test-only {
> > > description
> > > "The server will only test and not set, even
> > > if there are no errors.";
> > > }
> > > }
> > > default "test-then-set";
> > > description
> > > "The test option to use.";
> > > }
> > >
> > > leaf error-option {
> > > type enumeration {
> > > enum stop-on-error {
> > > description
> > > "The server will stop on errors.";
> > > }
> > > enum continue-on-error {
> > > description
> > > "The server may continue on errors.";
> > > }
> > > enum rollback-on-error {
> > > description
> > > "The server will roll back on errors.
> > > This value can only be used if the 'rollback-on-error'
> > > feature is supported.";
> > > }
> > > }
> > > default "stop-on-error";
> > > description
> > > "The error option to use.";
> > > }
> > >
> > > choice edit-content {
> > >
> > > mandatory true;
> > > description
> > > "The content for the edit operation.";
> > >
> > > anyxml config {
> > > description
> > > "Inline Config content.";
> > > }
> > > leaf url {
> > > if-feature url;
> > > type inet:uri;
> > > description
> > > "URL-based config content.";
> > > }
> > > }
> > > }
> > > }
> > >
> > >
> > >
> > > > Vladimir
> > > >
> > > >
> > > >
> > > >
> > > > Andy
> > > >
> > > >
> > > > On Tue, Sep 13, 2016 at 4:43 AM, Vladimir Vassilev <
> > > > [email protected]> wrote:
> > > >
> > > >> On 09/13/2016 01:26 PM, Juergen Schoenwaelder wrote:
> > > >>
> > > >>> On Tue, Sep 13, 2016 at 01:19:02PM +0200, Vladimir Vassilev wrote:
> > > >>>
> > > >>>> I am wondering in which cases this is useful. Consider a candidate
> > > >>>>> datastore - why would a 'when' expression have to true after each
> > > >>>>> edit? Why do we force clients to send edits in such a way that
> > 'when'
> > > >>>>> expressions are true after each edit?
> > > >>>>>
> > > >>>> For example command line <TAB> completion in /interfaces/interface
> > can
> > > >>>> evaluate all 'when' statements in child data nodes and
> > augmentations and
> > > >>>> come up with relevant list of container and leaf child completions
> > > >>>> based on
> > > >>>> the already created /interfaces/interface/type (same applies for the
> > > >>>> options
> > > >>>> a user is presented with in a GUI after specifying the 'name' and
> > > >>>> 'type' of
> > > >>>> the interface). It is the same with 'if-feature' evaluations. The
> > 'must'
> > > >>>> statements however can be more complicated since they are only
> > checked
> > > >>>> when
> > > >>>> the interactive incremental edit process is complete and <commit> is
> > > >>>> attempted.
> > > >>>>
> > > >>>> I do not see what <TAB> completion has to do with the processing of
> > > >>> edit-config on the server. Are people implementing <TAB> completion
> > by
> > > >>> sending edit-configs to a server? But yes, trying to enforce
> > > >>> constraints while doing <TAB> completion may lead to surprises for
> > > >>> people not understanding the constraints being enforced via
> > > >>> incremental <TAB> completion.
> > > >>>
> > > >> Well it means that the 'candidate' configuration can not be in a state
> > > >> where any of the 'when' statements fail (since it is modified only
> > with
> > > >> <edit-config>). This is significant reduction of the entropy and thus
> > can
> > > >> be utilized for automation. In my example that fact is used for <TAB>
> > > >> completion.
> > > >>
> > > >> Vladimir
> > > >>
> > > >> _______________________________________________
> > > >> netmod mailing list
> > > >> [email protected]
> > > >> https://www.ietf.org/mailman/listinfo/netmod
> > > >>
> > > >
> > > >
> > > >
> >
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
