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