Subject: [Netconf] Clarification of <edit-config> "operation" and other attributes

From: Alan Luchuk <[email-masked]>
Date: Tue, 19 Jan 2010 14:32:03 -0500

Hello,

Thanks for helping to clarify my undestanding with the responses to my prev-
ious questions about the NETCONF <edit-config> RPC.  I have additional ques-
tions, and would appreciate further clarification.  If these questions are
answered in an RFC, draft, or WG mail archives, references would be fine
instead of having to answer the questions again.

In response to my previous question, Andy Bierman wrote:

>Yes, where REPLACE applies only to the values explicitly
>contained in the PDU.  Any nodes already in the config
>(or whatever subtree) remain in the config.
>
>The replace operation does not fail if the data is not
>in the target config (unlike delete).
>
>PDU:
>
>   <config>
>      <a>fred</a>
>      <b>barney</b>
>   </config>
>
>target config:
>
>   <config>
>      <a>wilma</a>
>      <c>betty</c>
>   </config>
>
>
>Result of default-operation='merge' (order may be different
>on every server for top-level elements)
>
>   <config>
>      <a>fred</a>
>      <b>barney</b>
>      <c>betty</c>
>   </config>
>
>
>Result of default-operation=replace:
>
>   <config>
>      <a>fred</a>
>      <b>barney</b>
>   </config>
>
>Result of default-operation=none:
>
>   <config>
>      <a>wilma</a>
>      <c>betty</c>
>   </config>

Two things about this example:

First, was the <config> element in this example intended to represent a
generic container node in the data model, or was it intended to represent
the <config> element of the <edit-config> RPC?  A colleague and I inter-
preted Andy's reply differently, and it affected our understanding of the
<edit-config> behavior.

Second, because there was no contradicting E-mails on the working group, I
assume the behavior in the example above is a WG consensus.

I suggest the following wording for the description of the behavior of
the "merge" operation:

    merge:  The configuration data identified by the element containing
            this attribute is merged with the configuration at the cor-
            responding level in the configuration datastore identified
            by the target parameter.

            That is, nodes in the configuration data that DO NOT EXIST in
            the configuration datastore are added; nodes in the configuration
            data replace corresponding nodes that EXIST in the configuration
            datastore.

            This is the default behavior.

Regarding the "delete" operation, does it behave differently for nodes that
DO or DO NOT exist in the configuration datastore?  That is, does the "delete"
operation SUCCEED if the node specified in the configuration data EXISTS in
the configuration datastore, and FAIL if the node specified in the configur-
ation data DOES NOT EXIST in the configuration datastore?   Or does "delete"
always quietly succeed (for configuration nodes), such that after a "delete"
operation has completed, one can be sure the specified node does NOT EXIST
in the configuration datastore?

The description of the "create" operation describes its behavior in the two
cases where the configuration data specified DOES and DOES NOT exist in the
in the configuration datastore.  It would be helpful if there was similar
text for all four operation attributes:  merge, replace, create, and delete.

RFC 4741 and bis-01 specifies:

    Elements in the <config> subtree may contain an "operation"
    attribute.  The attribute identifies the point in the
    configuration to perform the operation and MAY appear on
    multiple elements throughout the <config> subtree.

What are the rules for handling the "operation" attribute if different
operations are specified at different levels in the configuration subtree.
For example, what happens in the case of:

  <rpc message-id="101"
       xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <edit-config>
      <target>
        <running/>
      </target>
      <config>
        <top xmlns="http://example.com/schema/1.2/config" operation="delete">
          <interface operation="merge">
            <name>Ethernet0/0</name>
            <mtu>1500</mtu>
          </interface>
        </top>
      </config>
    </edit-config>
  </rpc>

Which happens:

1)  Is everything in the <top> subtree deleted, then the <interface> subtree
    merged;

2)  Is the <interface> subtree merged, then the <top> subtree deleted;

3)  Is an error returned;

4)  Is there a precedence order for the operation attributes;

5)  Some other behavior; or

6)  Is this implementation dependent?

What happens if a "delete" (or other) operation is specified on a container
element in the configuration data, but one or more of the contained nodes
in the configuration datastore are state data, and therefore are not config-
urable?

Regarding the "continue-on-error" error option, if multiple errors occur
during an <edit-config> RPC, does it return a single error, multiple errors,
or is this implementation dependent?

Thanks in advance for any/all clarification.

Regards,
--Alan

 ------------------------------------------------------------------------------
 Alan Luchuk               SNMP Research, Inc.          Voice:  +1 865 573 1434
 Senior Software Engineer  3001 Kimberlin Heights Road  FAX:    +1 865 573 9197
 [email-masked]           Knoxville, TN  37920-9716    http://www.snmp.com/
 ------------------------------------------------------------------------------