On Wed, Aug 2, 2017 at 8:20 AM, Juergen Schoenwaelder <
[email protected]> wrote:

> On Wed, Aug 02, 2017 at 08:11:25AM -0700, Andy Bierman wrote:
> >
> > The server will NEVER use these constraints.  It does not run XPath
> > validation on its own output.
> >
> > The client can NEVER reliably use these constraints because they need to
> be
> > evaluated at the instant
> > the RPC or notification output is generated, and the client does not have
> > that snapshot
> > of the running or operational datastores.
> >
> > So just ignore these YANG details.  That's all real tools can do with
> them
> > anyway.
>
> I tend to agree when it comes to the output / notifications.  But
> things are less clear on the input - a server can reject the execution
> of an operation if a must constraint on the input is not satisfied.
>
> But yes, constraints on config false data, operations and
> notifications are likely much less useful than constraints on
> config true data.
>
>
That's what I meant.
RPC input MUST be honored by the server or it is not implementing <rpc>
correctly.

Constraints on RPC output and notification output are for documentation
purposes.
A client could try to evaluate them with its own copies of the server's
running and
operational datastore contents, but I think the YANG definition says the
constraint
is enforced on the server.

Maybe NMDA could clarify this issue.


/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

Reply via email to