> That's what I meant.
> RPC input MUST be honored by the server or it is not implementing
> 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
>
On Wed, Aug 2, 2017 at 8:20 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> 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
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
Hi Kent,
I objected to this expansion of XPath context when YANG 1.1 was being
developed.
Then I realized the YANG constraints are totally worthless so no reason to
do anything
about it.
The server will NEVER use these constraints. It does not run XPath
validation on its own output.
The client
Hi Alex,
> Why would it not make sense?
Firstly, it seems outside the norm. At least, I'm unaware of any other IDL
that allows for such linkage. Second, I'm trying to understand the value. For
instance, how does it benefit the module designer, the server developer, the
client developer?
pply to
digital radio interfaces.
Alex
From: netmod <netmod-boun...@ietf.org> on behalf of Kent Watsen
<kwat...@juniper.net>
Sent: Wednesday, 2 August 2017 3:37 a.m.
To: netmod@ietf.org
Subject: [netmod] accessible tree for rpcs?
RFC 7950, S6.4.1. (XPath Context) says:
o
