Subject: [netmod] leaf-list problem

From: Martin Bjorklund <[email-masked]>
Date: Wed, 19 Aug 2009 10:24:57 +0200 (CEST)

Hi,

Consider this data model from the draft:

  leaf-list domain-search {
      type string;
      description "List of domain names to search";
  }

Suppose that a client wants to set this to the same list on many
servers.  It can build an edit-config request with:

  <domain-search>high.example.com</domain-search>
  <domain-search>low.example.com</domain-search>

But since the default operation is 'merge', this will just append the
two domains to the end of the current leaf-list on each device.  It
really wants to replace the contents of this leaf-list, regardless of
what was there, so it might try:

  <domain-search nc:operation="replace">high.example.com</domain-search>
  <domain-search>low.example.com</domain-search>

where the first line supposedly replaces the entire list with one
entry 'high.example.com', and the second line appends the second
entry.

But this doesn't work, b/c the current text says:

      If the operation is "merge" or "replace" the leaf-list entry is
      created if it does not exist.

So the first line would just append high.example.com, just as merge
would have done.

I suggest we change this text to:

      If the operation is "merge" the leaf-list entry is
      created if it does not exist.

      If the operation is "replace" the complete leaf-list contents is
      replaced with the new leaf-list entry.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 19 Aug 2009 10:39:48 +0200

>       replaced with the new leaf-list entry.

I agree that this is an issue to resolve; I did run into this myself
recently. But given the new wording, what is the effect of doing this:

Do we state anywhere that things are processed in sequential order?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 19 Aug 2009 10:53:10 +0200 (CEST)

>From 7.7.7:

   If several entries in an "ordered-by user" leaf-list are modified in
   the same <edit-config> request, the entires are modified one at the
   time, in the order of the XML elements in the request.

We can change this: s/"ordered-by user"//

Oh, there's a typo: s/entires/entries/.   Now fixed (in two places).

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 19 Aug 2009 03:05:20 -0700

>       replaced with the new leaf-list entry.

This is a new feature request.
I do not want to change the meaning of nc:replace now.
The nc:operation attribute applies only to
the subtree it appears in -- not its siblings.
This is a massive change to the NETCONF protocol.

Delete the whole leaf-list, then add it back.
Problem solved.

> /martin

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 19 Aug 2009 12:40:39 +0200 (CEST)

> the subtree it appears in -- not its siblings.

Absolutely!

This subtree:

replaces the domain-search leaf-list.

And this subtree:

merges a new entry with the existing list.

> Delete the whole leaf-list, then add it back.

That would be perfectly fine, but how do you delete a leaf-list?  The
draft says:

  o  If the operation is "delete" the entry is deleted from
     the leaf-list if it exists.

So this won't work:

  <domain-search nc:operation="delete"/>

b/c it will delete the leaf-list entry "".

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 19 Aug 2009 07:56:35 -0700

> replaces the domain-search leaf-list.

no -- it replaces the 1 leaf-list node with
the value 'high.example.com'.  It does not affect
any siblings of the 'high.example.com' instance.

each leaf-list value is unique and separate

<config>
  <a>1</a>
  <a>2</a>
  <a>3</a>
</config>

This is 3 leaf-list nodes, not 1 leaf-list.

>      the leaf-list if it exists.

<config>
  <a nc:operation="delete">1</a>
</config>

result:

<config>
  <a>2</a>
  <a>3</a>
</config>

> b/c it will delete the leaf-list entry "".

correct -- you have to specify the value of the leaf-list getting deleted

Andy

---

From: WashamFan <[email-masked]>
Date: Thu, 20 Aug 2009 12:09:50 +0800

Hi,

----- Original Message -----
From: Martin Bjorklund <[email-masked]>
Date: Wednesday, August 19, 2009 6:41 pm
Subject: Re: [netmod] leaf-list problem
To: [email-masked]
Cc: [email-masked]

>  b/c it will delete the leaf-list entry "".

If I understand correctly, the behavior of 'replace' you'd like can be divided
into 2 steps: 1) delete all existing leaf-list entries 2) merge the new entry.

As I know, you could not achieve step 1) at once especially there exists
many entries. So, I prefer add a feature to clean up a leaf-list at once 
instead of integrating this feature into 'replace' semantics if it is neccessary.

washam

---

From: Andy Bierman <[email-masked]>
Date: Wed, 19 Aug 2009 22:47:44 -0700

> instead of integrating this feature into 'replace' semantics if it is neccessary.

I agree.
I do not want to change the way nc:operation works
by overloading one of the existing values.
That is very confusing, and kind of a hack.

Right now, the application has to retrieve the current
leaf-list from each device and provide delete operations
for them.  Just like list entries.  I prefer this
consistent behavior, and also keeping the nc:operation
attribute to process only the current sub-tree.

   <config>
       <domain-search>high.example.com</domain-search>
       <domain-search>low.example.com</domain-search>
       <domain-search nc:operation="delete">ftp.example.com</domain-search>
       <domain-search nc:operation="delete">www.example.com</domain-search>
   </config>

The current proposal is broken just by including 2
replace operations for the same leaf-list:

   <config>
       <domain-search nc:operation="replace">high.example.com</domain-search>
       <domain-search nc:operation="replace">low.example.com</domain-search>
   </config>

This is perfectly valid according to RFC 4741 because each replace
applies only to the domain-search leaf-list instance.  Not all instances
of the leaf-list.

This is an issue for RFC4741-bis -- whether or not to
change the meaning of the nc:operation attribute.

Andy