Subject: [netmod] nested insert operations (yang-08, 7.7.7 and 7.8.6)

From: Andy Bierman <[email-masked]>
Date: Wed, 04 Nov 2009 10:58:12 -0800

Hi,

I am not sure the text in these sections wrt/
nested nc:operation attributes is very clear,
or nested insert operations are explained at all.

The higher level operation (closer to root) has precedence
over the nested operation.  There are lots of implementation
details omitted, but essentially, a 'replace' operation
takes affect the first descendant-or-self node that actually changed.
So any insert operations nested within the 'replace' operation
do not have any existing list or leaf-list, as explained in
the draft:

7.7.7, para 6:
   In a <copy-config>, or an <edit-config> with a "replace" operation
   which covers the entire leaf-list, the leaf-list order is the same as
   the order of the XML elements in the request.

An insert nested within a nc:operation=replace is really ignored,
and should probably be flagged as an error. (The request PDU order
is used instead.)

=================================

7.7.7, para 4:
   If no "insert" attribute is present in the "create" operation, it
   defaults to "last".

Doesn't this default apply to 'merge' as well?

Isn't the order required (key or value attributes)
if the operation is 'replace'?  Or is it just a NO-OP,
and the server leaves the list or leaf-list in the same place?

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 05 Nov 2009 22:07:39 +0100 (CET)

Hi,

> and should probably be flagged as an error. (The request PDU order

Actually, we can simplify the quoted text above a bit into:

    In a <copy-config> the leaf-list order is the same as the order of
    the XML elements in the request.

and since elements are processed in order in an edit-config, if there
are no insert attributes, each element will
be placed at the end of the list, and we will end up with the same
order as in the request.

In this case, we don't need to reject insert within a create or
replace; they will be processed in order as in any other case.

Yes, if the entry does not exists.  Maybe change the quoted text to:

  If no "insert" attribute is present when the entry is created, it
  defaults to "last".

> and the server leaves the list or leaf-list in the same place?

It leaves it in the same place.  This is not useful for a leaf-list,
but it makes sense for a list entry.  How about adding:

  If no "insert" attribute is present in a "replace" operation, the
  list entry does not change its position in the list.

/martin