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 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.
Andy
On Wed, Aug 2, 2017 at 7:51 AM, Kent Watsen <kwat...@juniper.net> wrote:
> 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? (more on this below)
>
> While not in the subject, my question extends to notifications as well.
> Section 6.4.1 says that the accessible tree is "the notification instance,
> all state data in the server, and the running configuration datastore".
> Notifications are particularly interesting given their one-way
> communication property. In this regard, notifications are a bit like
> <operational> in that the server will/should send truth, regardless what
> the validation might allow.
>
>
> > Is your question about the datastores proposal?
>
> I wasn't thinking about it originally, but you raise a good point. Looking
> at revised-datastores, we see that the XPath context rules are revised in
> S5.1. It seems like that <running> is no longer included (better), but the
> concern raised in this thread persists. Just thinking about <running> no
> longer being included, this seems to break backwards compatibility. For
> RPC's, neither NETCONF nor RESTCONF provide a mechanism to address a
> datastore. And for actions, NETCONF again doesn't address a datastore,
> though RESTCONF does. What this means is that a legacy server also
> supporting NMDA is unable to differentiate between if it should use old or
> new behavior. Maybe it's a mute point, in that <operational> is a subset
> of <running>, but there is a semantic difference between something
> configured versus applied.
>
> BTW, the restconf-nmda draft currently doesn't say anything about action
> statements, but it seems that it should restrict them to just <operational>
> under the {+restconf}/ds/ resource. We wouldn't want to support, for
> instance, {+restconf}/ds/ietf-datastores:candidate/foobar/restart.
>
>
>
> > Usually an action will refer to some object that is defined as
> configuration
> > and/or state, and may depend on the particular properties of that object.
> > Here is a YANG fragment showing one possible application:
> >
> > list ospf-instance {
> > config true;
> > leaf id {type string;}
> > leaf supports-graceful-restart {type boolean;}
> > }
> >
> > rpc ospf-graceful-restart {
> > input {
> > leaf instance-id {type leafref {path "/ospf-instance/id";}}
> > must
> > "/ospf-instance[id=current()/instance-id]/supports-graceful-restart
> = 'true'" {
> > error-message "Instance does not support graceful
> restart";
> > }
> > }
> > }
> >
> > As another application, a "mute transmitter" command might only apply to
> > digital radio interfaces.
>
> About this example, my first thought is that RPC input is probably the
> most defensible example - RPC output or notification examples make even
> less sense. With this example, the YANG is doing two things: 1) asserting
> that the instance exists and 2) asserting that the instance supports
> graceful restarts. So:
>
> From a module designer perspective:
> - it is more exact than a description statement (but just mildly so),
> and
> note that the 'leaf' and 'must' statements should have 'description'
> statements too
>
> From a server developer perspective:
> - it moves a little more of the validation into the input-parsing
> logic,
> but I'm sure that the server would throw an error anyway if the
> instance didn't exist or if it didn't support graceful restart.
>
> From a client developer perspective:
> - again, the leafref/must statements are more exact than description
> statements, but I don't believe that there is any expectation that
> a client would perform validation prior to sending the RPC. Of
> course it could if it had a copy of the server's datastores (e.g.
> peer mount), but that doesn't guarantee anything unless the client
> is also going to use locking (which doesn't exist in RESTCONF)
> around the syncing of the server's data and the execution RPC.
>
>
> We can do similar exercises with RPC output and notifications, but my
> position is that we'll find even less value. Again, these provisions seem
> like a lot of complexity for little gain...
>
> Kent // contributor
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
