Re: [netmod] Order of evaluation for when?

Thu, 15 Oct 2015 08:34:50 -0700

Hello,
I had the same interpretation as Martin. The when could be on the config database model. Not just on the when defined in a definition of an rpc or action.
regards Balazs

On 2015-10-15 17:02, Andy Bierman wrote:


On Thu, Oct 15, 2015 at 4:53 AM, Martin Bjorklund <[email protected]> wrote:
Andy Bierman <[email protected]> wrote:
> Hi,
>
> You are incorrect.
>
> Within the PAYLOAD (as this section describes), there is no when-stmt
> for data nodes within the datastore.  Look at the YANG for edit-config.
> There are no when-stmts for "interface" in "edit-config".

Andy, there is some confusion here.  The section talks about:

  For configuration data, there are three windows when constraints
  MUST be enforced:

  - during parsing of RPC payloads
  - during processing of NETCONF operations
  - during validation

So the entire section talks about constraints *on configuration data*.





Here is the YANG for edit-config?
Please point out the when-stmts in this rpc-stmt
specific to the "interface" node.
I just see an "anyxml" that has no when-stmts at all.

So enforcing the when constraint on the RPC PAYLOAD
clearly has nothing to do with "interface" -- just the parameters
specified in the rpc-stmt.


 
If you interpret this section to talk about the nodes in the
definition of edit-config, nothing in the section makes any sense at
all.   For example:

  If all keys of a list entry are not present, the server MUST reply
  with a "missing-element" error-tag in the rpc-error.

you might say that there are no lists in the definition of
edit-config, so this bullet doesn't apply.




edit-config is the next section  -- 8.2.2



/martin



Andy
 


>
> So explain which constraint in the payload is being violated?
>
>
> Andy
>
>
> On Thu, Oct 15, 2015 at 1:00 AM, Balazs Lengyel <[email protected]
> > wrote:
>
> > 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]>
> > [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]>
> >> [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]
> >
> >


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