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. /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
