Subject: Re: [netmod] config lists without keys (Y09) / non-unique leaf-lists (Y57)

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 1 Nov 2015 15:51:15 +0100

On Thu, Oct 29, 2015 at 01:17:56PM +0100, Martin Bjorklund wrote:
> Juergen Schoenwaelder <[email-masked]> wrote:
> > Hi,
> > 
> > the issues Y09 and Y57 were declared dead after intense discussions of
> > various solution proposals. It later appeared to me that there is a
> > solution that we have not considered. The requirement to have a key
> > for every list and unique values in a leaf-list for config nodes is
> > essentially there to allow edits on individual elements using
> > edit-config. The solution not considered so far is simply to give up
> > the ability to edit invidual elements, that is, a config list without
> > a key can only be modified as whole and similarily a leaf-list that
> > allows non-unique values can only be modified as a whole (with
> > edit-config). Comments?
> 
> How would this look in edit-config?  There are quite a few details to
> think through in order to support this.
>

Why would that be complicated for edit-config? This key-less list
would essentially be anyxml with a known structure. You likely do not
allow edit-config specific attributes on all of them.

/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: Andy Bierman <[email-masked]>
Date: Sun, 1 Nov 2015 08:05:29 -0800

Hi,

Why is this WG discussing issues that have been declared DEAD for
various reasons?  Optional keys break old clients, remember?
There was not enough interest in adding these features.

Andy

On Sun, Nov 1, 2015 at 6:51 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

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

---

From: Nabil <[email-masked]>
Date: Sun, 1 Nov 2015 13:43:56 -0800

Hi,

I missed the earlier discussion around this topic prior to calling it DEAD. But here are some comments and ideas.

There is interest in the security product business (access rules configuration for example). Some users don't want to deal with introducing keys that have to carry meaningless values. Not a problem for other cases of course.

The goal is to have a type of configuration lists in which the combination of all of the columns is unique so no need for a key from this perspective. We might think why not just model all leaves as part of the key. The problem with that is edit-config, which can only create or delete records in this case.

Unless the edit-config sends all of the old values (to identify the instance) along with the new values (for a N size list, we would be sending 2*N values), then there is no way to identify a single instance for an edit operation.

This makes edit-config syntax different from the current standard and complicated.

Another option is to keep a key that is system generated at the protocol level. A NETCONF server would have to implement such capability. Just thinking out loud here. There might be other issues with this approach as the key is not decided by the clients.

/Nabil

> On Nov 1, 2015, at 8:05 AM, Andy Bierman <[email-masked]> wrote:
> 
> Hi,
> 
>> On Sun, Nov 1, 2015 at 6:51 AM, Juergen Schoenwaelder <[email-masked]> wrote:

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 02 Nov 2015 09:03:46 +0900 (JST)

> allow edit-config specific attributes on all of them.

For anyxml/anydata, there is a surrounding container that contains the
"blob":

  anydata foo;

  <foo>
    <blah>
      <blaha>goo</blaha>
    </blah>
  </foo>

but with a list, the entries are encoded w/o any surrounding tag:

  list foo { ... }

  <foo>
    // entry 1
  </foo>
  <foo>
    // entry 2
  </foo>

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 02 Nov 2015 09:04:50 +0900 (JST)

> various reasons?  Optional keys break old clients, remember?

Agreed.  But I don't think the issue that Juergen brought up is
related to Y09 (even though the mail subject says so...)

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 2 Nov 2015 14:54:13 +0900

> On 02 Nov 2015, at 06:43, Nabil <[email-masked]> wrote:
> 
> 
> 
> Hi,
> 

Maybe this could work: each config list for which a key is not defined in YANG would get a key by default with a reserved name. A NETCONF client could use this key as usual but it could also create new entries without giving the key, and the server will then generate opaque keys for these entries which can then be used as usual. The client may then need to learn the system-generated key(s) but this can be done using a subsequent get-config (with filters). This approach is used by MongoDB, more or less.

However, this probably still doesn't solve the task of replacing the entire list in one shot (at least in NETCONF) - this seems to require extending <edit-config>.

Lada

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 2 Nov 2015 11:14:45 +0100

> but with a list, the entries are encoded w/o any surrounding tag:

And the consequence of this is?

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 02 Nov 2015 23:26:47 +0900 (JST)

> And the consequence of this is?

I don't know how treating the entire list as one unit would work.  For
example, what would the XML to replace this list with two new entries
look like?

/martin