On Tue, Sep 13, 2016 at 1:25 AM, Juergen Schoenwaelder < [email protected]> wrote:
> On Tue, Sep 13, 2016 at 09:34:33AM +0200, Ladislav Lhotka wrote: > > > > > On 13 Sep 2016, at 09:01, Yves Beauville <[email protected]> > 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? > I recall that I did not agree that this error was clearly defined. The subtle difference this line calls out is the case where the client provides a configuration data node that evaluates to false immediately, vs. an existing node that becomes false after the new edit is applied. (The former is an error and the latter is just a silent delete). One major problem with this text (as I pointed out years ago) is that the when-stmt does not actually exist in the strictest sense. It is hidden in the schema behind an "anyxml" node <config>. The literal YANG says a when-stmt in the RPC input, but there isn't any. The when-stmt is in the implied schema of the node provided in the anyxml subtree. > > /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
