On 31/10/2017 15:35, Kent Watsen wrote:
Hi Robert,
6.2 Invocation of RPC Operations
This section updates section 7.14 of RFC 7950.
RPCs MAY be defined as affecting the contents of a specific datastore,
any configuration datastore (e.g., <edit-config>), or any datastore
(e.g., <get-data>). The RPC definition specifies how the RPC input
data is interpreted by the server.
s/MAY/may/? - is this draft providing for this, or should it come from
e.g., RFC 7950?
I think that I prefer MAY because we are stating what RPCs are allowed
to do, but don't feel strongly on this ...
RPCs definitions that do not explicitly state an affected
datastore(s) modify the general operational state of the server.
Hence, if any RPC input data relates to data node instances then
those would generally resolve to data node instances in the
<operational> data tree.
I reordered first sentence, and added a comma to the second:
RPCs modify the general operational state of the server, unless
explicitly defined to affect other datastores. Hence, if any RPC
input data relates to data node instances, then those would
generally resolve to data node instances in the <operational>
data tree.
Also OK with me.
6.3 Invocation of Actions
This section updates section 7.15 of RFC 7950.
In YANG data models, the "action" statement may appear under "config
true" and "config false" schema nodes. While instances of both
schema nodes may appear in <operational>, instances of "config true"
schema nodes may also appear in other datastores.
okay
Actions are always invoked on a data node instance that exist in the
<operational> data tree. The behavior defined by an action statement
is generally expected to affect the operational state of the server
rather than directly modifying the contents of any configuration
datastore.
fixed plurality issue in first sentence, and removed wishy-washy
language from the rest:
Actions are always invoked on a data node instance that exists in the
<operational> data tree. Action statements affect the operational
state of the server.
This wishy-washy language is the tricky bit:
i) Actions are allowed to have any operational impact on the device
(just as RPCs are), their behavior is not constrained in any way.
ii) However, as far as I can see, it doesn't make sense for an action to
directly affect the contents of any configuration datastore, that should
be done via a purpose built rpc (like edit-config).
My text was aimed to allow (i) but not encourage (ii) ... If your text
is sufficient for this then it is fine with me - I agree that it is
simpler, and simpler is preferable.
Thanks,
Rob
What do you think?
Kent // contributor
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
