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.
>
> 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
