Subject: [netmod] New YANG issues

From: Balazs Lengyel <[email-masked]>
Date: Thu, 3 Jul 2014 15:50:32 +0200

Hello,
Ericsson decided that we would need 3 additions to the list of issues 
for YANG 1.1. I am really sorry for bringing up issues this late, but 
after the internal decision that Ericsson should become more active 
around Netconf (which I hope is a gain for the Netconf community), the 
following issues became really important for us.

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.

2) Recursive containment: Allow groupings to "use" themselves themselves 
directly or indirectly.
It is needed  e.g. for modeling Hierarchical QOS (Que-in-Que), HW 
Equipment information (replaceable-unit in replaceable-unit) or 
representing a file system (directories in directories). All these cases 
are modeled naturally as a containment hierarchy even if they could be 
handled using a reference list.
Besides being more intuitive models with recursive containment have one 
distinct advantage over reference based solutions. If recursive 
containment is used it is easy to point out exactly which Que/ 
Replaceable unit/Directory is addressed. For the exact understanding of 
the item it is needed to know where it is placed in a hierarchy, e.g an 
instance-identifier type address would contain its position in the 
containment hierarchy. If we use a flat list of items and use references 
to indicate how they are related, which item "contains" which, then the 
instance identifier will not tell you the position in the hierarchy.

3) Actions: YANG model defined rpc operations that are connected to a 
specific resource in the data-model.
Actions are something Ericsson and Tail-f has been using for a long time 
and "nearly" got into YANG 1.0 at that time. They are similar, but 
better then the YANG rpc construct, because they are connected to 
managed objects e.g. lists, so you can have the same action (e.g. 
restart) on multiple points in your data model. Also actions are scoped: 
only visible on the managed object where they are actually needed. With 
YANG RPCs it is easy to and up in one huge list of RPCs visible everywhere.

regards Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Mobile: +36-70-330-7909              email: [email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Thu, 3 Jul 2014 07:47:38 -0700

Hi,

IMO we cannot keep adding on new features to YANG 1.1, especially
features that have been discussed and rejected many times already.
Your list might be OK for YANG 2.0 features

On Thu, Jul 3, 2014 at 6:50 AM, Balazs Lengyel <[email-masked]>
wrote:

> Hello,
> Ericsson decided that we would need 3 additions to the list of issues for
> YANG 1.1. I am really sorry for bringing up issues this late, but after the
> internal decision that Ericsson should become more active around Netconf
> (which I hope is a gain for the Netconf community), the following issues
> became really important for us.
>
> 1) Non-Unique leaf-list: YANG shall allow leaf-lists whose members are not
> unique.
YANG insert "before" and "after" attributes and delete/remove operations
would not work correctly.

> distinct advantage over reference based solutions. If recursive containment
> is used it is easy to point out exactly which Que/ Replaceable
> unit/Directory is addressed. For the exact understanding of the item it is
> needed to know where it is placed in a hierarchy, e.g an
> containment hierarchy. If we use a flat list of items and use references to
> indicate how they are related, which item "contains" which, then the

Some mechanism to tell the compiler that the expansion is conceptual is
needed
so the schema tree is not infinitely deep.  A "uses-loop" has no stop
condition.

> and "nearly" got into YANG 1.0 at that time. They are similar, but better
> then the YANG rpc construct, because they are connected to managed objects
> e.g. lists, so you can have the same action (e.g. restart) on multiple
> points in your data model. Also actions are scoped: only visible on the
> managed object where they are actually needed. With YANG RPCs it is easy to
> and up in one huge list of RPCs visible everywhere.
>
>

You could also just add an instance-identifier leaf to the <restart> rpc.
Don't you have to do that anyway?  How does placing an "action" inside
the data tree translate to a NETCONF <rpc> request? You add the i-i
for the data node right?

regards Balazs

Andy

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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 3 Jul 2014 20:07:18 -0700

> 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)

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).

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 08 Jul 2014 16:54:25 +0200

> 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.

> and nc:operation="delete" attributes).

Maybe it's time to move this from YANG to NETCONF spec where it really belongs?

Lada

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