Subject: [netmod] edit-config semantics

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

Hi,

[replying in a new thread to edit-config concerns raised in "delete in
list and leaf-list"]

Ladislav Lhotka <[email-masked]> wrote:
> 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.

Section 5.2 of RFC 4741 excplicitly state:

   Data modeling and content issues are outside the scope of the NETCONF
   protocol.  An assumption is made that the device's data model is
   well-known to the application and that both parties are aware of
   issues such as the layout, containment, keying, lookup, replacement,
   and management of the data, as well as any other constraints imposed
   by the data model.

Since the protocol is data model agnostic, it has to be pretty vague
in talking about keys etc.

It is important though that the YANG specification is very clear how
edit-config works with data models defined in YANG.

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

Can you give an example?

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

---

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

> in talking about keys etc.

Then it should have avoided "defining" the edit-config operations, and
perhaps the subtree filters, too.

> > can interfere with YANG semantics in various ugly ways.

1.

list foo { key "clef schluessel"; ... }

<foo>
    <clef nc:operation:"replace">newkey</clef>
</foo>

Does it replace the 'clef' part of the key in all list items?

2.

leaf-list baz { type string; }

<baz nc:operation="replace">somevalue</baz>

How can this be interpreted?

The general problem is that the selection step is mixed with the action
step. They should be separate.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: David Reid <[email-masked]>
Date: Tue, 23 Sep 2008 10:20:28 -0400

> Does it replace the 'clef' part of the key in all list items?

Does the XML encoding of a list entry have to include all of the keys?
I thought that the above example would be invalid since the key schluessel
is not specified. Am I missing something?

> step. They should be separate.

I would expect this example also to generate an error based on section 7.7.6:

   Leaf-list entries can be created and deleted, but not modified,
   through <edit-config>, by using the "operation" attribute in the
   leaf-list entry's XML element.

When the spec says "created and deleted, but not modified", does that mean I 
can do a netconf create or delete operation but not a netconf merge or replace 
operation on a leaf-list?

-David Reid

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 23 Sep 2008 18:33:12 +0200

> is not specified. Am I missing something?

No, you are right, this is what Sec. 7.8.6 says. The edit-config
operations (including default-operation) probably must not be applied to
keys in any way. But it also means there is no way for changing values
of leafs that happen to be part of the key.

> operation on a leaf-list?

Further in Sec. 7.7.6: 'If the operation is "merge" or "replace" the
leaf-list entry is created if it does not exist.' It is not clear though
whether it is an error or not if the entry exists. For "create" it has
to be an error according to RFC 4741.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 23 Sep 2008 20:33:43 +0200 (CEST)

> operation on a leaf-list?

No.  You can do replace and merge, as specified later in that section.
But remember that a leaf-list entry has just one value, and each entry
is identified by its value.  So if we have a leaf-list:

  <baz>a</baz>
  <baz>c</baz>

what would it mean to modify the entry "c"?  If you change its value
to say "b", the entry is now identified as "b".  There is no way you
can, in one edit-config operation, change the value of "c" to "b".
You would have to delete "c" and create "b".

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 23 Sep 2008 20:36:07 +0200 (CEST)

> to be an error according to RFC 4741.

Right, and "merge" or "replace" on an existing entry in an ordered-by
system leaf-list, but the entry might be moved in an ordered-by user
leaf-list.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 24 Sep 2008 08:59:15 +0200

> system leaf-list, but the entry might be moved in an ordered-by user

So it is a NOOP if "nc:merge" or "nc:replace" is used without
"yang:insert" and "yang:value" attributes for leaf-lists ordered by both
user and system?

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 24 Sep 2008 09:11:00 +0200 (CEST)

> "yang:insert" and "yang:value" attributes for leaf-lists ordered by both

Yes, it is noop if the entry exists.  The spec already says that the
entry is created if it does not exist.

/martin