Re: [netmod] Order of evaluation for when?

Thu, 15 Oct 2015 01:01:20 -0700

See below, Balazs

On 2015-10-14 23:06, Andy Bierman wrote:


On Wed, Oct 14, 2015 at 1:26 PM, Martin Bjorklund <[email protected]> wrote:
Andy Bierman <[email protected]> wrote:
> On Wed, Oct 14, 2015 at 12:48 PM, Martin Bjorklund <[email protected]> wrote:
>
> > Andy Bierman <[email protected]> wrote:
> > > On Wed, Oct 14, 2015 at 12:25 PM, Martin Bjorklund <[email protected]>
> > wrote:
> > >
> > > > Balazs Lengyel <[email protected]> wrote:
> > > > > Hello Martin,
> > > > > I agree that A1 is what follows the spirit of YANG, but then IMHO you
> > > > > should change/correct 8.2.1 in YANG because that implies A2 and
> > error.
> > > >
> > > > Ok, I agree.  I suggest we remove from 8.2.1:
> > > >
> > > >    o  If data for a node tagged with "when" is present, and the "when"
> > > >       condition evaluates to "false", the server MUST reply with an
> > > >       "unknown-element" error-tag in the rpc-error.
> > > >
> > > > and add to 8.2.2:
> > > >
> > > >   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.
> > > >
> > > >
> > > >
> > >
> > > This seems like a BIG protocol change to <edit-config> behavior.
> > > IMO this not an error at all.  In our server the false-when data is just
> > > pruned, and no error is ever sent for a pruned when=false data node.
> >
> > So you are not following the current RFC 6020 spec?
> >
>
>
> Yes we are following it.

Ok.

> The schema for the edit-config RPC operation contains
> an 'anyxml' for <config> node.  It does not contain any
> when-stmts for the data nodes that get passed in the <config> node.
> The correct behavior is to just enforce the error on the when-stmts
> that appear in the rpc-stmt.

I don't understand what you are trying to say.


I know about the text that says a false-when in an RPC is an error.
Show me the when-stmts  "interface" in the "edit-config" rpc-stmt.


 

Here's an example:

  augment /if:interfaces/if:interface {
    when "if:type = 'ianaift:ethernetCsmacd'";

    container ethernet {
      leaf duplex {
        type enumeration {
          enum "half";
          enum "full";
        }
      }
    }
  }

Suppose the db is empty.

What if the edit-confif contains

  <interfaces>
    <interface>
      <name>eth0</name>
      <eth:duplex>full</eth:duplex>
      <type>ianaift:ethernetCsmacd</type>
    </interface>
  </interfaces>

will that work or not?  I.e., will the eth0 interface be created with
duplex full?

Yes -- because these are data nodes and the rules for when-stmt
on data nodes are different than for rpc-stmt.  Then the when-stmt
is a test on whether the node should exist in the candidate or running
datastore.

Our server applies all the edits first, when checks all the when-stmts
that might have changed value.  Nodes that have already existed in the
datastore may get pruned, not just the new nodes.






/martin




Andy
 

>
>
>
>
> > I don't think this is a BIG protocol change, since the spec already
> > says that requests for nodes w/ false when expressions MUST send
> > error.  The change is to say that this behavior is true regardless of
> > evaluation order.
> >
> > > It may be a client programming error for the client to provide
> > > false when nodes or not.  What if the client is reusing some
> > > code that sends 5 parameters, it it's OK if 1 of them gets
> > > pruned sometimes because of a false when (e.g, product
> > > feature-specific knob and that feature is not installed)
> >
> > Well, it might be simpler to send if-featured nodes that the specific
> > server doesn't support - this is also an error in 6020.
> >
> > > BTW, this is a really good example of what not to do, if one
> > > wants to make the YANG specification protocol independent.
> >
> > That statement is true for the entire section 8.2, it is not
> > specifically true for this change.
> >
> >
> > /martin
> >
>
>
> Andy

And this contradicts the current rfc6020bis-07#section-8.2.1 which states that already during parsing you must check 
If data for a node tagged with "when" is present, and the "when"
      condition evaluates to "false", the server MUST reply with an
      "unknown-element" error-tag in the rpc-error.
 

So already during parsing <eth:duplex>full</eth:duplex> you MUST send back an error;
before processing <type>ianaift:ethernetCsmacd</type>. 
(I also assume this is independent from the document order of the edit-config request.)
So this MUST be corrected in the draft!
regards Balazs


 

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320                        
Mobile: +36-70-330-7909              email: [email protected] 




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

Reply via email to