Subject: [netmod] Y09: introduce optional keys Y09

From: Balázs Lengyel <[email-masked]>
Date: Tue, 5 Aug 2014 23:58:33 +0000

Hello,
So before we go into the interim, I think we should consider this issue as well. As Lada and Andy wrote in some cases there is no need for a key. We already allow this for config false lists.

I support what Andy wrote:
"YANG 1.1 should allow user-ordered lists and leaf-lists to be keyed by the sibling order, and not require any keys."

Naturally this would mean that the rules for the <edit-config> operation and especially the insert before/after have to be defined for the keyless case, but IMHO that's business as usual.
regards Balazs

On 2014-07-08 16:54, Ladislav Lhotka wrote:
> Andy Bierman <[email-masked]> writes:
>
>> On Thu, Jul 3, 2014 at 6:50 AM, Balazs Lengyel <[email-masked]>
>> wrote:
>>
>>> 1) Non-Unique leaf-list: YANG shall allow leaf-lists whose members are not
>>> unique.
>>> They are needed in a number of cases especially for user-ordered lists,
>>> where the position is stable and  carries a meaning.
>>>
>> I actually like this one, but I think this is a more general problem
>> which has been raised before, but should be reconsidered.
>>
>> Perhaps YANG 1.1 should allow user-ordered lists and leaf-lists to be keyed
>> by
>> the sibling order, and not require any keys.  That would solve your problem.
>> It actually shows up in the example-jukebox "playlist" in RESTCONF.
>> This is a list instead of a leaf-list just so a dummy key can be defined,
>> just so duplicates can be allowed in the playlist.
>>
>>
>> YANG 1.0:
>>
>>         list song {
>>           key index;
>>           ordered-by user;
>>
>>           description
>>             "Example nested configuration data resource";
>>
>>           leaf index {    // not really needed
>>             type uint32;
>>             description
>>               "An arbitrary integer index for this playlist song.";   //
>>   <<<<< Yuch!!!
>>           }
>>           leaf id {
>>             type rc:data-resource-identifier;
>>             mandatory true;
>>             description
>>               "Song identifier. Must identify an instance of
>>                /jukebox/library/artist/album/song/name.";
>>           }
>>         }
>>
>>
>> Maybe YANG 1.1:
>>
>>
>>         leaf-list song {
>>            ordered-by user;
>>            type rc:data-resource-identifier;
>>            description
>>               "Song identifier. Must identify an instance of
>>                /jukebox/library/artist/album/song/name.";
>>         }
>>
>> IMO this is a lot cleaner (You are right Balazs)
> Yes, I'd support this. There are other use cases such as AS-Path that
> may contain the same AS number repeatedly.
>
>> There would need to be a way in NETCONF to insert and delete by position
>> instead of keys
>> or leaf-list value. (e.g add position="N" attribute in YANG 1.1 to go with
>> the "insert"
>> and nc:operation="delete" attributes).
> Maybe it's time to move this from YANG to NETCONF spec where it really belongs?
>
> Lada
>
>>
>>
>>
>>
>>> regards Balazs
>>
>>
>>
>> Andy
>> _______________________________________________
>> netmod mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/netmod

--
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: Thu, 7 Aug 2014 10:34:19 +0200

Hi,

this was discussed during the 2014-07-02 virtual interim meeting and
Martin took an action item to write up a solution proposal (see the
virtual interim meeting minutes). If you want to help Martin with
this, please go ahead and coordinate with him.

/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: Martin Bjorklund <[email-masked]>
Date: Thu, 07 Aug 2014 18:34:50 +0200 (CEST)

> this, please go ahead and coordinate with him.

I took an action to do a proposal for optional keys.  I do not agree
with the new issue of having key-less ordered-by user lists, so I
won't cover that part in my proposal.

/martin

> > So before we go into the interim, I think we should consider this
> > issue as well. As Lada and Andy wrote in some cases there is no need
> > for a key. We already allow this for config false lists.
> > 
> > "YANG 1.1 should allow user-ordered lists and leaf-lists to be keyed
> > by the sibling order, and not require any keys."
> > 
> > Naturally this would mean that the rules for the <edit-config>
> > operation and especially the insert before/after have to be defined
> > for the keyless case, but IMHO that's business as usual.
> > regards Balazs
> >