On Wed, Oct 14, 2015 at 1:26 PM, Martin Bjorklund <m...@tail-f.com> wrote:
> 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.
>
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
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
