On 09/13/2016 10:25 AM, Juergen Schoenwaelder wrote:
On Tue, Sep 13, 2016 at 09:34:33AM +0200, Ladislav Lhotka wrote:
On 13 Sep 2016, at 09:01, Yves Beauville <yves.beauvi...@nokia.com> wrote:
Both RFC 6020 and RFC 7950 are providing the same requirement in section
'Payload Parsing':
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.
This section seems confusing. It makes no sense to evaluate "when" or "must" on the
contents of a protocol message such as edit-config because accessible trees for XPath evaluations are defined
in sec. 6.4.1 in terms of datastores and "all state data".
I agree that this bullet in section 8.3.1 looks odd. Perhaps Martin
recalls why this was written in the first place?
/js
IMO it is that bullet that sets apart 'when' from 'must' statements.
With the current text 'when' statements should be evaluated along with
'range',..., 'if-feature' etc. 8.3.1 specified validation statements
upon every <edit-config> while 'must' statements should be evaluated
only upon <commit> along with the rest of "description" statement
validation checks done. The designer should take care to not specify
'when' statements that hinder incremental editing of the 'candidate'
configuration.
I use 'when' statements in models utilizing lists often with 'identity'
leafs in the parent chain of data nodes and only testing for the values
of those 'identity' leafs or the keys. Anything else IMO requires 'must'
statements with proper dedicated error messages. Following this rule
prevents situations where you need to have a single <edit-config>
creating multiple leafs with complicated dependency to satisfy the
'when' statements.
Probably a clarification that the 'when' statement should evaluate to
'true' after the <edit-config> is applied (e.g. to a copy of the edited
configuration for example) and not based only on the data content of the
<edit-config> RPC is what is needed.
Vladimir
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
