Andy Bierman <[email protected]> wrote:
> On Wed, Feb 3, 2016 at 9:06 AM, Martin Bjorklund <[email protected]> wrote:
>
> > Hi,
> >
> > William Ivory <[email protected]> wrote:
> > > Hi,
> > >
> > > My colleagues and I are looking for clarification of the last point in
> > > Section 10 of YANG 1.0:
> > >
> > > ' In statements that have any data definition statements as
> > > substatements, those data definition substatements MUST NOT be
> > > reordered.'
> > >
> > > We understand that existing statements must not be reordered in a new
> > > revision of a YANG module, but we're not clear if new statements may
> > > be inserted between existing statements, or must always come at the
> > > 'end' of a list or container definition.
> >
> > They can be inserted anywhere.
> >
> > As Lada pointed out, this should be clarified in 6020bis. I will do:
> >
> > 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, those data definition substatements MUST NOT be
> > reordered. If new data definition statements are added, they can be
> > added anywhere between these substatement.
> >
> >
> >
>
> This is not very good.
> You should explain exactly what interoperability is lost if a data-def-stmt
> changes relative order from 1 release to the next.
Note that this how YANG 1.0 works.
The reason for this rule is that the order does matter for rpc
input/output - they are encoded in XML in the order they are defined.
The rule could be limited to input/output, but groupings might be
used, so it would have to be input/output and groupings.
/martin
> If it is a MUST NOT,
> then this should obvious. Given that list keys MUST be encoded first,
> and XML and JSON allow reordering anyway, it is a completely
> mystery to me why this CLR exists at all.
>
> (BTW, it has no affect at all on default-stmt, bit-stmt, or enum-stmt,
> the only 3 YANG statements where schema-order is actually relevant).
>
>
> Andy
>
>
>
> > > A specific example we're
> > > concerned with is where a grouping is used, and then later that
> > > grouping has an extra element added, but the new node could also be
> > > added directly. Eg:
> > >
> > > Container foo {
> > > Leaf A
> > > Uses grouping B;
> > > Leaf C
> > > Leaf D
> > > }
> > >
> > > Is it valid in a new revision of the module to do the following, or
> > > must the order be A, B, C, D, E? What if grouping B has gained a new
> > > statement?
> > >
> > > Container foo {
> > > Leaf A
> > > Uses grouping B;
> > > Leaf C
> > > Leaf E < ---- ADDED
> > > Leaf D
> > > }
> >
> > This is valid.
> >
> >
> > /martin
> >
> >
> > >
> > > Thanks,
> > >
> > > William
> > >
> > >
> >
> > _______________________________________________
> > netmod mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/netmod
> >
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
