Subject: [netmod] YANG statement order

From: Andy Bierman <[email-masked]>
Date: Thu, 5 Nov 2015 08:51:33 -0800

Hi,

I asked about this text on page 156:

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

I asked why this new rule was added.
I do not see why it is needed, or how it can be enforced.

If I add a new object to grouping A, then every place there
is a "uses A", a new data node will be inserted inline.
If I add a leafs at the end of a nested list, it is before
the data nodes following the list.

Does this text mean one can never reorder the data nodes,
such that the relative order never changes? Or does it mean
new objects must go at the end of a module?
Why do we think it is user-friendly to force statement order
to be a critical one-try-or-else decision?  What happens
if the original statement order was a mistake?  Is this
allowed to be corrected in a future version?

Why is this text required for YANG to be interoperable?
Given that all nodes are QNames, this rule is not needed.
(I don't care about some corner-case XPath functions that
the YANG guidelines already say not to use.)

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 06 Nov 2015 09:50:13 +0900 (JST)

Hi,

> I asked why this new rule was added.

It is not a new rule, it is there in RFC 6020 as well.

In rpc/action input/output the nodes are encoded in XML in the order
they are defined.  So this rule is there to protect clients that might
depend on that order.

> is a "uses A", a new data node will be inserted inline.

Newly inserted nodes does not change the order between the old nodes.

We could relax the rule and say that it only applies to input/output
and groupings (since they might be in input/output.

Or we revisit the original rule that nodes in input/output are encoded
in the order they are defined - however, that rule has huge
implications on performance in some rpc (specifically edit-config).

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 5 Nov 2015 17:02:29 -0800

> It is not a new rule, it is there in RFC 6020 as well.
Then the word "reordered" needs to be clarified

> they are defined.  So this rule is there to protect clients that might

But this just applies to the advertised version of the RPC.
The client should use the schema the server supports,
and the order is dictated by that version.

> Newly inserted nodes does not change the order between the old nodes.

This is one interpretation of the term "reorder".
This interpretation is OK -- the relative order cannot be changed
but overall, any subtree can have nodes added in between
existing objects (via direct edit or uses).

> and groupings (since they might be in input/output.

OK, except the identification of objects does not depend on order.
This is kind of a CLR.

> implications on performance in some rpc (specifically edit-config)
>

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 06 Nov 2015 10:12:37 +0900 (JST)

> and the order is dictated by that version.

In general the update rules are there in order to protect old
clients.  If we say that the client needs to understand the revision
that the server implements, then we can remove all update rules.

> existing objects (via direct edit or uses).

Ok, how about:

OLD:

NEW:

   In statements that have any data definition statements as
   substatements, the relative order between old data definition
   substatements MUST NOT be changed.

> OK, except the identification of objects does not depend on order.

Do you think we should relax the rule?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 5 Nov 2015 17:22:50 -0800

> Do you think we should relax the rule?
yes.

One could argue that it might take operational experience to know
that a certain RPC input order is more advantageous than the current order.
IMO the places YANG is brittle mostly involve the statements where decisions
have to be right the first try because the cost of starting over is too
high,
and YANG does not allow a new version to fix the problem.

We won't change the order of <edit-config> because it is thought to be
correct.
If <target> was after <config> maybe we would want to change it, but YANG
rules
say that is forbidden.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 06 Nov 2015 10:27:53 +0900 (JST)

> If <target> was after <config> maybe we would want to change it, but YANG

Right.  In that case we'd have to use a new name for the operation.
Maybe it's ok.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 6 Nov 2015 09:17:15 -0800

> Right.  In that case we'd have to use a new name for the operation.

So this rule only applied to RPC in RFC 6020?
Then it should only apply to RPC in YANG 1.1.
It does not apply to schema hidden behind anyxml or anydata.
It only applies to the input and output parameters.

Andy