Andy Bierman <a...@yumaworks.com> wrote: > On Wed, Oct 14, 2015 at 12:48 PM, Martin Bjorklund <m...@tail-f.com> wrote: > > > Andy Bierman <a...@yumaworks.com> wrote: > > > On Wed, Oct 14, 2015 at 12:25 PM, Martin Bjorklund <m...@tail-f.com> > > wrote: > > > > > > > Balazs Lengyel <balazs.leng...@ericsson.com> 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. 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? /martin > > > > > > 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 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod