Subject: Re: [netmod] A question about updating model

From: David Reid <[email-masked]>
Date: Wed, 03 Jun 2015 15:38:08 -0400

> > Hi all,
> >    If I want to add a new child data node to a container node or list 
> > node, in order to keep backward compatiable,
> > should this child node be added to the end of son nodes of parent node?
> >  For example, 
> >  container a {
> >      leaf b;
> >      leaf c;
> >      leaf d;
> >  }
> >  If I want to add leaf e as a's child node, leaf e must be the last 
> >child of container a?
> 
> No it doesn't have to be added in order.  See section 10 of RFC 6020.

The last part of section 10 says:

   In statements that have any data definition statements as
   substatements, those data definition substatements MUST NOT be
   reordered.

If e were added between b and c, would that be considered a reorder since
c and d would be moved down.

In general, I think adding nodes in the middle is a bad idea.

-David Reid

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 04 Jun 2015 10:24:50 +0200 (CEST)

> In general, I think adding nodes in the middle is a bad idea.

Hmm.  The rule is not clear.  In fact, one can argue that it is
wrong:

For rpc and notifications, where the order matters, this rule makes
sense.  But for config or state it really doesn't matter, and you
should be free to add the new nodes wherever you like.

But the rule refer to "data definition statements".  If you follow the
terminology, a "data definition statement" "defines new data nodes".

And a "data node" is "A node [...] that can be instantiated in a data
tree".

And a "data tree" is "The instantiated tree of configuration and state data
on a device".

So the rule applies to config and state (which it shouldn't), but not
to rpc and notifications (which it should).

---

The terminology needs some work. A "data definition statement" is
really supposed to mean: One of container, leaf, leaf-list, list,
choice, case, augment, uses, and anyxml.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 4 Jun 2015 10:48:53 +0200

> On 04 Jun 2015, at 10:24, Martin Bjorklund <[email-masked]> wrote:
> 

But in fact one can also augment an rpc or notification, and according to sec. 7.5.12 the new nodes “are encoded as
subelements to the augmented node, in any order”. So the element order in such an rpc/notification is not fixed anymore and the receiving side must be prepared to receive that data in any order.

So I wonder whether the rules about fixed element order in rpcs and notifications really make sense. What’s quite clear though is that they cause serious complications to YANG processing software because rpcs/notifications often need special handling.

Lada

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

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