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
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
