On 31/10/2017 15:14, Juergen Schoenwaelder wrote:
On Tue, Oct 31, 2017 at 02:14:20PM +0000, Robert Wilton wrote:
Is <operational> always the right datastore to evaluate RPC input/output
data relative to? For most RPCs this seems to be the right choice by
default but it also seems plausible that someone may wish to define an RPC
that wants to validate its input parameters against the contents of another
datastore.
Yes.
An example could be an "is-applied" RPC that takes a path to a subtree in
<running> or <intended> and checks whether the configuration for that
subtree is fully represented in <operational>.
How is this different from say partial locks (RFC 5717)? Note that in
your example, you carry an xpath value as part of the RPC invocation
to the server and the RPC code on the server then is interpreting the
xpath value; this is not the same has having an xpath expression in
the definition of the RPC itself (e.g., as part of a constraint).
OK, thanks for the explanation, I get the distinction.
But what about if the input parameter was an instance-identifier (that
you want to be resolved against the configuration datastore)? Wouldn't
RFC 7950 section 9.13 + NMDA Sec 6.1 force that leaf in the input data
to be resolved against <operational> instead?
I believe we previously concluded that xpath expressions that are part
of the schema definition of an RPC / action are evaluated against
<operational>. I think this is a reasonable interpretation and we
can't affort a vaguely defined xpath context here.
I don't think that it would necessarily be vaguely defined, instead it
would be the description that defines the XPath context to use,
defaulting to operational if not specified otherwise.
However, having said that, I can't think of a realistic example of when
a must/when statement for an RPC against a configuration datastore would
be useful ...
Thanks,
Rob
/js
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
