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*. 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. /martin > > 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] > > > > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
