Subject: [netmod] delete on list and leaf-list

From: Martin Bjorklund <[email-masked]>
Date: Mon, 22 Sep 2008 10:39:53 +0200 (CEST)

Hi,

Given this list

  list interface {
      key "name";
      leaf name {
          type string;
      }
      list address {
          key "ip";
          leaf ip {
              type yang:ip-address;
          }
          leaf broadcast {
              type yang:ip-address;
          }
      }
  }

I think it would make sense for a client to replace all addresses on a
paticular interface with an edit-config like this:

  <edit-config>
    <target>
      <running/>
    </target>
    <config>
      <interface xmlns="http://example.com/interface">
        <name>eth0</name>
        <address nc:operation="delete"/>
        <address>
          <ip>10.0.0.1</ip>
        </address>
        <address>
          <ip>172.0.0.1</ip>
        </address>
      </interface>
    </config>
  </edit-config>

I.e. by specifying "delete" on a list node, but not giving any keys,
all list entries are deleted.

But suppose we have this:

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

A client might want to set the same domain-search list (say foo.com,
bar.com) on all devices in the network.  But how does he do that?  He
cannot do:

  <edit-config>
    <target>
      <running/>
    </target>
    <config>
      <system xmlns="http://example.com/system">
        <domain-search>foo.com</domain-search>
        <domain-search>bar.com</domain-search>
      </system>
    </config>
  </edit-config>

since this will just append foo.com and bar.com to the end of the
domain-search list.

We could do as in the list example above:

  <edit-config>
    <target>
      <running/>
    </target>
    <config>
      <system xmlns="http://example.com/system">
        <domain-search nc:operation="delete"/>
        <domain-search>foo.com</domain-search>
        <domain-search>bar.com</domain-search>
      </system>
    </config>
  </edit-config>

but since the delete operation is used to delete a single leaf-list
entry if a value is given, and an empty XML element is the same as
giving an empty value, this means that a leaf-list entry cannot
contain the empty string.  This seems to be an odd CLR.

In YANG we currently specify the semantics of the "delete" operation
from RFC 4741 to say that for lists, all keys MUST be present and are
used to select one entry, and for leaf-list the value is used to
select one entry.

An alternative which solves this problem, could be that when the
operation is "delete", then EITHER the keys/value are present as XML
elements, OR an XML attribute "scope='all'" (or something similar) is
present:

        <domain-search nc:operation="delete" yang:scope="all"/>
        <domain-search>foo.com</domain-search>
        <domain-search>bar.com</domain-search>

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 22 Sep 2008 11:18:50 +0200

Hi,

I think the merge operation in RFC 4741 is seriously underspecified. In
particular, it doesn't say what happens if <edit-config> contains leaf
data that are already present in the target configuration - it can't do
so without introducing the concept of a list key, semantics of default
values (do they exist in the configuration?) etc.

On the other hand, the "operation" attribute that RFC 4741 does define
can interfere with YANG semantics in various ugly ways.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 22 Sep 2008 14:03:42 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> Hi,
> 
> I think the merge operation in RFC 4741 is seriously underspecified.

You're hijacking my thread ;-)  I'll reply to your posting in a
new thread.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 22 Sep 2008 14:39:32 +0200

OK, I hope this is not considered hijacking: :^)

>         <address nc:operation="delete"/>

RFC 4741: "The configuration data identified by the element containing
this attribute is deleted ...". Does it mean here : (i) one/first
"address" element or (ii) all of them? Your example seems to assume (ii)
but the vague formulation in RFC 4741 may be interpreted as  (i), too.

The other edit-config operations are similarly ill-defined, especially
for lists and leaf-lists. I don't think YANG or any other DML can fully
repair such cracks in the RFC 4741 foundation.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 22 Sep 2008 15:05:21 +0200

Hello,

> all list entries are deleted.
BALAZS: IMHO there is no such thing as  a "list" in the data model, there are just a set of 
list entries. So <address nc:operation="delete"/> is just an incorrectly specified list entry, 
which should result in an error response. This is a by-product of YANG not cleanly separating a 
list and a list entry.
For what you want I would rather introduce some kind of wildcard for the key. It would be a 
cleaner structure then adding little attributes to NETCONF.
<address nc:operation="delete">
   <name yang:wildcard="true"/>
</address>

This achieves the same thing, but we still handle a series of entries and do not have to 
introduce operations on the non-existing "list" entity itself.
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 22 Sep 2008 16:04:25 +0200

> list entries. So <address nc:operation="delete"/> is just an incorrectly specified list entry, 

Why is it incorrect? The "address" element is real.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 22 Sep 2008 17:04:38 +0200

Hello Lada,
The original model was
   list interface {
       key "name";
       leaf name {
           type string;
       }
       list address {
           key "ip";
           leaf ip {
               type yang:ip-address;
           }
           leaf broadcast {
               type yang:ip-address;
           }
       }
   }

So to point to an "address" item you have to specify it's key (ip). Without that I would assume 
   the expression is incorrect. We never store an empty address, in the datastore it always has 
a key (ip). AFAIK in Xpath <address/> would select all nodes, but do we want to allow such 
XPath-like addressing of the managed items? We never sad that till now, so I would keep it 
simple. If you want something address it with it's key.
At least that is my view, but this is something that the YANG draft should certainly describe!
Balazs

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 22 Sep 2008 22:28:42 +0200

> simple. If you want something address it with it's key.

The approach of RFC 5261 looks better (though I haven't read it very
carefully yet). I don't understand the fear of XPath, it shouldn't be a
terrible problem for any agent to implement it. These "simple"
approaches seem to lead to inconsistencies.

> At least that is my view, but this is something that the YANG draft should certainly describe!

Yes, such rules should be specified in the YANG draft, but since the
edit-config operations are introduced in RFC 4741, one would assume that
they are independent of YANG. Otherwise it can easily happen that the
operations have different semantics in different DM languages.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 24 Sep 2008 17:32:40 +0200

> approaches seem to lead to inconsistencies.
BALAZS: The point is not the fear of XPath. Netconf as I understand intentionally avoided 
filters for edit-config both subtree and xpath. What you are proposing is introducing XPath 
filters into edit-config, so it must be explicitly stated.
> operations have different semantics in different DM languages.
BALAZS: Then please propose an update to RFC 4741. I think during the YANG effort we must state 
how such an operation works.

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod