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".
/martin
> >
> > 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
