Hi, Show me the text that says an anyxml passes the constraints of the hidden data models through to the RPC processing. The error for false-when only applies to parameters specified in the RPC.
The processing of the rpc-stmt does not have any when-stmts that need to be checked. The config data is validated as part of a datastore, not as part of the RPC payload. Andy On Thu, Oct 15, 2015 at 8:33 AM, Balazs Lengyel <[email protected] > wrote: > 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]> > [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*. >> >> > > > http://www.netconfcentral.org/modules/ietf-netconf/2011-06-01#edit-config.421 > > > 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]>[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]>[email protected]> wrote: >> > >> > > > On Wed, Oct 14, 2015 at 12:25 PM, Martin Bjorklund < >> [email protected]> >> > >> > > wrote: >> > >> > > > >> > >> > > > > Balazs Lengyel < < <[email protected]> >> [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]>[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
