date:20160914

Re: [netmod] 'when' statement in edit-config payload parsing

2016-09-14 Thread Andy Bierman

On Wed, Sep 14, 2016 at 1:42 PM, Martin Bjorklund  wrote:

> Andy Bierman  wrote:
> > On Wed, Sep 14, 2016 at 10:08 AM, Martin Bjorklund 
> wrote:
> >
> > > Andy Bierman  wrote:
> > > > On Wed, Sep 14, 2016 at 5:29 AM, Vladimir Vassilev <
> > > vladi...@transpacket.com
> > > > > 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"  in the .
> >
> > 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.
>
>
Customers have asked for this to be an error.
We have a CLI parameter to turn on/off the error.

It is generally considered a client programming error if the edit payload
contains
any nodes that get immediately deleted because of false when-stmts.
In generally indicates that the client's notion of the existing config is
incorrect.



> /martin
>

Andy


>
>
>
> >
> >
> >
> > > /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  RPC that has started the thread (the 'when'
> > > validation
> > > > > in  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 :
> > > > >
> > > > >   > > > >   xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> > > > >
> > > > >  
> > > >

Re: [netmod] 'when' statement in edit-config payload parsing

2016-09-14 Thread Martin Bjorklund

Andy Bierman  wrote:
> On Wed, Sep 14, 2016 at 10:08 AM, Martin Bjorklund  wrote:
> 
> > Andy Bierman  wrote:
> > > On Wed, Sep 14, 2016 at 5:29 AM, Vladimir Vassilev <
> > vladi...@transpacket.com
> > > > 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"  in the .
> 
> 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  RPC that has started the thread (the 'when'
> > validation
> > > > in  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 :
> > > >
> > > >   > > >   xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> > > >
> > > >  
> > > >
> > > >  
> > > >  
> > > >http://dummy.com; >
> > > >  
> > > >  
> > > >3
> > > >  
> > > >
> > > >  
> > > >
> > > >  
> > > >
> > > > 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  is processed:
> > > >
> > > >   > > >   xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> > > >
> > >

Re: [netmod] 'when' statement in edit-config payload parsing

2016-09-14 Thread Andy Bierman

On Wed, Sep 14, 2016 at 10:08 AM, Martin Bjorklund  wrote:

> Andy Bierman  wrote:
> > On Wed, Sep 14, 2016 at 5:29 AM, Vladimir Vassilev <
> vladi...@transpacket.com
> > > 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"  in the .

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.
Edits to other nodes (e.g., /bar) do not cause an error.

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.
According to the text, if I alter /bar (not /foo) then /foo can be silently
deleted and this is not an error.



> /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  RPC that has started the thread (the 'when'
> validation
> > > in  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 :
> > >
> > >   > >   xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> > >
> > >  
> > >
> > >  
> > >  
> > >http://dummy.com; >
> > >  
> > >  
> > >3
> > >  
> > >
> > >  
> > >
> > >  
> > >
> > > 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  is processed:
> > >
> > >   > >   xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> > >
> > >  
> > >
> > >  
> > >  
> > >http://dummy.com; >
> > >  
> > >3
> > >  
> > >
> > >  
> > >
> > >  
> > >
> > > My interpretation of the relevant text in YANG 1.0 and YANG 1.1 is the
> > > 'when' statement is satisfied since when the  is applied
> to
> > > the 'candidate' configuration the result will be valid

Re: [netmod] 'when' statement in edit-config payload parsing

2016-09-14 Thread Juergen Schoenwaelder

On Wed, Sep 14, 2016 at 07:48:17AM -0700, Andy Bierman wrote:
> On Wed, Sep 14, 2016 at 5:29 AM, Vladimir Vassilev  > 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  RPC that has started the thread (the 'when' validation
> > in  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 :
> >
> >   >   xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> >
> >  
> >
> >  
> >  
> >http://dummy.com; >
> >  
> >  
> >3
> >  
> >
> >  
> >
> >  
> >
> > 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  is processed:
> >
> >   >   xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> >
> >  
> >
> >  
> >  
> >http://dummy.com; >
> >  
> >3
> >  
> >
> >  
> >
> >  
> >
> > My interpretation of the relevant text in YANG 1.0 and YANG 1.1 is the
> > 'when' statement is satisfied since when the  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 .
> 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  anyxml subtree
> are just not careful readers.
> 
> 
> 
> 
> 
> rpc edit-config {
>   description
> 
> 
> "The  operation loads all or part of a specified
>  configuration to the specified target configuration.";
> 
>   reference "RFC 6241, 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 {

Re: [netmod] 'when' statement in edit-config payload parsing

2016-09-14 Thread Andy Bierman

On Wed, Sep 14, 2016 at 5:29 AM, Vladimir Vassilev  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  RPC that has started the thread (the 'when' validation
> in  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 :
>
> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>
>  
>
>  
>  
>http://dummy.com; >
>  
>  
>3
>  
>
>  
>
>  
>
> 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  is processed:
>
> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>
>  
>
>  
>  
>http://dummy.com; >
>  
>3
>  
>
>  
>
>  
>
> My interpretation of the relevant text in YANG 1.0 and YANG 1.1 is the
> 'when' statement is satisfied since when the  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 .
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  anyxml subtree
are just not careful readers.





rpc edit-config {
  description


"The  operation loads all or part of a specified
 configuration to the specified target configuration.";

  reference "RFC 6241, 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.";
}

Re: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 9, 2016)

2016-09-14 Thread Kent Watsen

The last call on this draft has ended!  Thank you everyone who participated.  
There doesn’t seem to be consensus to adopt my proposal to move the -state tree 
to another module, and so we will call it rough consensus in favor of 
publishing the document as it is.   This document will be moved to the ‘WG 
Consensus: Waiting for Write-Up’ working group state shortly; the shepherd will 
take it from there.

Thanks,
Kent (and Lou)

From: netmod  on behalf of Kent Watsen 

Date: Friday, August 26, 2016 at 1:54 PM
To: "netmod@ietf.org" 
Subject: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 
9, 2016)


This is a notice to start a two-week NETMOD WG last call for the document:

A YANG Data Model for Routing Management
https://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-23

Please indicate your support or concerns by Thursday September 9, 2016.

We are not only interested in receiving defect reports, we are equally 
interested in statements of the form:

  * I have reviewed draft-ietf-netmod-routing-cfg-23 and I found no issues
  * I have implemented the data model in draft-ietf-netmod-routing-cfg-23
  * I am implementing the data model in draft-ietf-netmod-routing-cfg-23
  * I am considering to implement the data model in 
draft-ietf-netmod-routing-cfg-23

Of course, these are merely suggestions, folks can provide comments in any form 
that suits them.


Thank you,

NETMOD WG Chairs


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 'when' statement in edit-config payload parsing

2016-09-14 Thread Vladimir Vassilev


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  RPC that has started the thread (the 'when' 
validation in  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 :

 
   
 
   
 
 
   http://dummy.com;>
 
 
   3
 
   
 
   
 

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  is processed:


 
   
 
   
 
 
   http://dummy.com;>
 
   3
 
   
 
   
 

My interpretation of the relevant text in YANG 1.0 and YANG 1.1 is the 
'when' statement is satisfied since when the  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.


Vladimir





Andy


On Tue, Sep 13, 2016 at 4:43 AM, Vladimir Vassilev 
> 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  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
 is
attempted.

I do not see what  completion has to do with the
processing of
edit-config on the server. Are people implementing 
completion by
sending edit-configs to a server? But yes, trying to enforce
constraints while doing  completion may lead to surprises for
people not understanding the constraints being enforced via
incremental  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 ). This is significant reduction
of the entropy and thus can be utilized for automation. In my
example that fact is used for  completion.

Vladimir

___
netmod mailing list
netmod@ietf.org 
https://www.ietf.org/mailman/listinfo/netmod





___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 'when' statement in edit-config payload parsing

Re: [netmod] 'when' statement in edit-config payload parsing

Re: [netmod] 'when' statement in edit-config payload parsing

Re: [netmod] 'when' statement in edit-config payload parsing

Re: [netmod] 'when' statement in edit-config payload parsing

Re: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 9, 2016)

Re: [netmod] 'when' statement in edit-config payload parsing

7 matches

Site Navigation

Mail list logo

Footer information