Subject: Re: [Netconf] [netmod] Is it possible to change a list enty's key/keys?

From: Martin Bjorklund <[email-masked]>
Date: Tue, 10 Mar 2015 12:49:18 +0100 (CET)

Hi,

This is a protocol issue.  I am sending the reply to netconf as well.
New replies should remove netmod from cc.

Balazs Lengyel <[email-masked]> wrote:
> Hello,
> Is it possible to change a list entry's key or keys without deleting
> and re-creating the entry. Can the replace operation be applied
> somehow on key leafs?

No.  This is an side-effect of the way edit-config works, where the
identification of *what* is changed it mixed with *how* to change it.

> I only found this in the mailing list:
> http://www.ietf.org/mail-archive/web/netmod/current/msg01194.html
> "
> 
> 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.

The last sentence says the same.

/martin

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 10 Mar 2015 13:03:04 +0100

Hello,
And is possible to change an existing list entry's key in restconf? As I 
understand yes.

If I am right, I am not happy. IMHO the property whether or not a key of 
an existing list entry can be changed, should be decided by the data 
modeling language (YANG) not the protocol used. So either make it 
changeable on all protocols or none. The node itself or some NMS might 
depend on the keys being unchangeable.
regards Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: [email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Mar 2015 13:21:19 +0100

> depend on the keys being unchangeable.

What does it mean for a key to be 'unchangeable'? I can delete a list
entry and subsequently I create it again with a different name. And
this would not be allowed?

/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: Balazs Lengyel <[email-masked]>
Date: Wed, 11 Mar 2015 09:05:19 +0100

Hello Jurgen,
In a number of (our) systems there is a difference between updating a 
leaf or deleting a list entry and recreating it with mostly the same 
content, but one changed leaf.

E.g. the keys identify an interface. The interface might have alarms, 
log entries, counter values connected to it. If you remove it, many of 
these alarms/log/etc.  are removed as they no longer belong to an 
existing object. When you recreate it, the alarms, logs, the history is 
already lost.

  Also if the object/entry is removed that in some cases results in a 
restart to the object represented by the list entry e.g. an interface, 
which means traffic disturbance.

So while deleting and recreating a list-entry is always allowed, it is 
important whether just changing the key is allowed or not?

And I still believe it should be YANG that decides whether just changing 
a key for an existing list entry is allowed or not. This is a modeling 
question not a protocol question.

regards Balazs

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 11 Mar 2015 09:18:27 +0100 (CET)

Balazs Lengyel <[email-masked]> wrote:
> Hello,
> And is possible to change an existing list entry's key in restconf? As
> I understand yes.
> 
> If I am right, I am not happy. IMHO the property whether or not a key
> of an existing list entry can be changed, should be decided by the
> data modeling language (YANG) not the protocol used.

I disagree.  Different protocols can have different mechanisms to do
things.  A very simple protocol for constrained devices might only
support replacing the entire config.  Should they have to invent their
own modelling language because of this?  I don't think that would be a
good idea.  Maybe NETCONF 2.0 supports renaming of instances.  Should
we then invent a new modelling language as well?

/martin

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 11 Mar 2015 09:54:51 +0100

Hello Martin,
As keys are used to identify things ( objects, leaf entries,  big 
subbranches of the model)  this is a special case.  It is not just any 
other attribute.
A good parallel could be: are you allowed to change the namespace/module 
name for a YANG module? It is part of what identifies that tree branch 
and no one wants to change that, although I could design a protocol 
mechanism to acomplish it.

Yes constrained devices might constrain the protocol, but they should 
never allow changing something that the model says is unchangeable, e.g. 
write to a read-only leaf.
So the question becomes:,  is it allowed to change items like keys that 
are used to address things YES/NO. IMHO this is for YANG to decide. 
(E.g. Netconf or SNMP does not allow it and I am happy with that.)

regards Balazs

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 11 Mar 2015 10:01:33 +0100 (CET)

Balazs Lengyel <[email-masked]> wrote:
> A good parallel could be: are you allowed to change the
> namespace/module name for a YANG module? It is part of what identifies
> that tree branch and no one wants to change that, although I could
> design a protocol mechanism to acomplish it.
> 
> never allow changing something that the model says is unchangeable,
> e.g. write to a read-only leaf.
> are used to address things YES/NO. IMHO this is for YANG to
> decide. (E.g. Netconf or SNMP does not allow it and I am happy with
> that.)

YANG stipulates that the keys are used to identifiy instances.  If you
change the key values of an instance you effectively get a new
instance.  A "rename" operation would do this; and this is the same as
reading the whole instance, delete it, create a new one with new key
values.  There is no explicit operation to do this in NETCONF, but you
can get the same effect with delete/create.  If some other protocol
had this a builtin that would be fine too.

/martin

---

From: Jan Lindblad <[email-masked]>
Date: Wed, 11 Mar 2015 10:06:55 +0100

Balazs,

> had this a builtin that would be fine too.

You can model your own “rename” or “move” RPC that does the move if you need particular semantics.

/jan

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 11 Mar 2015 10:43:34 +0100

> On 11 Mar 2015, at 09:18, Martin Bjorklund <[email-masked]> wrote:
> 

I agree with Martin, in fact I think we should strive for making YANG *less* dependent on management protocols. And I do find the design of ‘edit-config’ in this respect rather peculiar.

Robust management applications should be prepared to deal with e.g. interfaces being renamed at run time because that’s a fact of life.

Lada

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

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C