On Thu, Nov 5, 2015 at 5:27 PM, Martin Bjorklund <[email protected]> wrote:
> Andy Bierman <[email protected]> wrote: > > On Thu, Nov 5, 2015 at 5:12 PM, Martin Bjorklund <[email protected]> wrote: > > > > > Andy Bierman <[email protected]> wrote: > > > > On Thu, Nov 5, 2015 at 4:50 PM, Martin Bjorklund <[email protected]> > wrote: > > > > > > > > > Hi, > > > > > > > > > > Andy Bierman <[email protected]> wrote: > > > > > > 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. > > > > > > > > > > It is not a new rule, it is there in RFC 6020 as well. > > > > > > > > > > > > > > Then the word "reordered" needs to be clarified > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > 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. > > > > > > 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. > > > > > > > > > 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. > > > > > > > > > > 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). > > > > > > Ok, how about: > > > > > > OLD: > > > > > > In statements that have any data definition statements as > > > substatements, those data definition substatements MUST NOT be > > > reordered. > > > > > > NEW: > > > > > > In statements that have any data definition statements as > > > substatements, the relative order between old data definition > > > substatements MUST NOT be changed. > > > > > > > > We could relax the rule and say that it only applies to > input/output > > > > > 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. > > > > > > 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. > > Right. In that case we'd have to use a new name for the operation. > Maybe it's ok. > > 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. > > /martin > Andy
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
