Subject: [Netconf] Clarification of <edit-config> "operation" attribute

From: Alan Luchuk <[email-masked]>
Date: Mon, 14 Dec 2009 11:24:20 -0500

Hello,

I have questions about the specific behavior of the NETCONF <edit-config>
protocol operation with the different values of the "operation" attribute.
RFC 4741 bis does not seem to expand and/or clarify the corresponding sec-
tion(s) of RFC 4741.

In RFC 4741, the "operation" attribute behavior is described on pages 34
and 35.  The meaning of "merge" is not clear.  As an example, for a con-
ceptual table, does merge mean:

-  Add a row in the configuration data to the table ONLY IF the row in the
   configuration data DOES NOT ALREADY EXIST in the table.  Return an
   <rpc-error> if the row in the configuration data ALREADY EXISTS in the
   table.

Or does "merge" mean:

-  Add a row in the configuration data to the table.  If the row in the
   configuration data DOES NOT ALREADY EXIST in the table, then add
   the row.  If the row in the configuration data ALREADY EXISTS in the
   table, then REPLACE the values in the table with the values in the
   configuration data.

Also, from the description of the "data-exists" and "data-missing" error
messages, documented on page 72 of RFC 4741, it appears that the "replace"
and "delete" <edit-config> operations FAIL if the the configuration data
specifies nonexistent rows in a conceptual table.  It would clarify RFC
4741 (bis) if the text on page 34 would include, or at least reference,
the text from page 72.

The text explanation of the "create" operation (RFC 4741, page 35) clearly
explains that the create operation returns an <rpc-error> if the configur-
ation data already exists.  It would be clarify RFC 4741 bis if analogous
text would be added to the sections describing the "replace" and "delete"
operations.

Would someone please point me to the proper sections of RFC 4741 (or bis)
where the correct behavior is clearly explained?

Thanks in advance!

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/
 ------------------------------------------------------------------------------

---

From: Andy Bierman <[email-masked]>
Date: Mon, 14 Dec 2009 09:21:21 -0800

>    table, then REPLACE the values in the table with the values in the

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.

> 4741 (bis) if the text on page 34 would include, or at least reference,

I will look into changing the text in 4741bis.
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>

> text would be added to the sections describing the "replace" and "delete"

OK

> where the correct behavior is clearly explained?

I'll look at the text and send any suggested changes to
the mailing list.

> --Alan

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 14 Dec 2009 20:59:56 +0100 (CET)

Hi,

Alan Luchuk <[email-masked]> wrote:
> and 35.  The meaning of "merge" is not clear.

Yes, and I agree with Andy that we should try to clarify this.

However, note that to some extent this is data model specific.  The
YANG draft specifies what merge means for different types of nodes.

> specifies nonexistent rows in a conceptual table.

I have already fixed this in the sources for 4741bis.

/martin