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*. > > 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] > > > 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
