Subject: Re: [Netconf] rename operation for YANG Patch

From: Randy Presuhn <[email-masked]>
Date: Thu, 2 Apr 2015 10:00:13 -0700 (GMT-07:00)

Hi -

So bundled up for *simultaneous* execution with the rename request
would also have to be the edits for all the relevant leafrefs??

Randy

-----Original Message-----
>From: Juergen Schoenwaelder <[email-masked]>
>Sent: Apr 2, 2015 9:55 AM
>To: Randy Presuhn <[email-masked]>
>Cc: Netconf <[email-masked]>
>Subject: Re: [Netconf] rename operation for YANG Patch
>
>I expect that the configuration datastore must validate as usual and
>this implies that all leafrefs etc. are valid. There is no difference
>between 'delete foo; create bar' and 'rename foo to bar' in this
>respect.
>
>/js
>
>On Thu, Apr 02, 2015 at 09:20:14AM -0700, Randy Presuhn wrote:
>> Hi -
>> 
>> Care to be more specific about referential integrity,
>> both within the managed system and external references
>> to the entry in question?
>> 
>> Randy
>> 
>> -----Original Message-----
>> >From: Andy Bierman <[email-masked]>
>> >Sent: Apr 2, 2015 8:00 AM
>> >To: Netconf <[email-masked]>
>> >Subject: [Netconf] rename operation for YANG Patch
>> >
>> >Hi,
>> >
>> >It would be very easy to add a "rename" operation to the YANG Patch
>> >draft.  This would allow an operator to efficiently change the value
>> >of list keys without deleting and re-creating entries.
>> >
>> >Since deletion and re-creation will cause a disruption in network
>> >services, IMO it is important that this is fixed in RESTCONF.
>> >Unlike NETCONF (which has a multi-step procedure with
>> >locking and candidate config) there is no way to efficiently
>> >rename an entry in RESTCONF.
>> >
>> >The 'move' operation almost does a 'rename', but it is not expected
>> >to have a payload.  A 'rename' operation would be similar to 'move'
>> >except the keys that are changing would be specified.
>> >
>> >
>> >Is there support to add this operation to YANG Patch?
>> >
>> >
>> >Andy
>> >
>> >_______________________________________________
>> >Netconf mailing list
>> >[email-masked]
>> >https://www.ietf.org/mailman/listinfo/netconf
>> 
>> _______________________________________________
>> Netconf mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/netconf
>
>-- 
>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/>
>
>_______________________________________________
>Netconf mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netconf

---

From: Andy Bierman <[email-masked]>
Date: Thu, 2 Apr 2015 10:04:25 -0700

> would also have to be the edits for all the relevant leafrefs??

Only if the leafref pointed at a key leaf.
As Juergen pointed out, it is no different than deleting the key leaf
so the leafref is now invalid.  Either way the leafref has to get set
to the new value.

Andy