Hi -

On 10/26/2017 11:42 AM, Andy Bierman wrote:


On Thu, Oct 26, 2017 at 11:22 AM, Randy Presuhn <[email protected] <mailto:[email protected]>> wrote:

    Hi -

    On 10/26/2017 10:44 AM, Robert Wilton wrote:

        Hi ,

        Separating out the issue regarding which datastore action and
        RPC apply to, we propose the following NEW text to the
        datastores draft:

        6.2 Invocation of Actions and RPC Operations

            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.

            An NMDA compliant server MUST execute all actions in the
        context of
            <operational>.  Likewise, an NMDA compliant server MUST
        invoke all RPC
            operations in the context of <operational>, unless the RPC
        is explicitly
            defined as affecting other datastores (e.g., <edit-config>).

        OK?


    A question - I understand the motivation for the "unless" for RPC
    operations, but wonder why there is no similar "unless" for actions.



The <rpc> is not really in a datastore at all.
It may have input and output parameters with leafref and must/when statements.
These are evaluated in the <operational> context.
The <rpc> may in fact be something like <edit-config>
which has parameters (like <config> to apply to
a specific datastore.

The action node is embedded within some data that has to be parsed
in a specific datastore before the action is processed.
This data is required to be in <operational>.
It also has XPath and leafref that needs to be resolved (same as <rpc>).

The side effects of the <rpc> or <action> can impact other datastores.
This would be defined in the description-stmt and this is not a problem.

Thus my question.  I don't see a substantial difference between
"impact" and "affect" when side effects are permitted.  It seems
that the scope of what is affected (think about the consequences
for someone formulating an access control policy) in both cases
MUST be documented in in the description-stmt.  The fact that the
action is bound to a particular chunk of data is only the tip of
the iceberg, and doesn't seem to make a difference in terms of what
the description-stmt needs to spell out.

Randy

_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to