On Wed, Feb 3, 2016 at 1:55 AM, William Ivory <[email protected]> wrote:
> Hi Lada, > > I was hoping for more than 'I think' and ' Hmm. The rule is not clear. > In fact, one can argue that it is wrong:'. Is anyone willing / able to > give me a definitive answer? > > Thanks, > > William > > -----Original Message----- > From: Ladislav Lhotka [mailto:[email protected]] > Sent: 03 February 2016 09:19 > To: William Ivory <[email protected]> > Cc: [email protected] > Subject: Re: [netmod] Where can I insert new YANG substatements? > > Hi William, > > > > On 03 Feb 2016, at 09:58, 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.’ > > This was already discussed: > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_netmod_CiVOMEDXfbQKKbgTXTznZh2HQQw&d=CwIFaQ&c=IL_XqQWOjubgfqINi2jTzg&r=GByLeg9jZvOv_AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=IVWnHPIm0qEHmxsw6Hhp_1xhdn2lIC4CSzMCsjh-zLo&s=SqU7w-muS4t_zhH19_1iyPLVl3tD24OUgJijkp4NX4E&e= > > My understanding was that the paragraph you cite would be modified in > 6020bis, but apparently it hasn't been so far. I don't see any reason for > insisting on the order of sibling data node definitions in configuration > and state data since in instance documents the order is arbitrary in both > XML and JSON encoding. > > I have also mentioned in the past that this MUST NOT needs to be changed or at least clarified. According to RFC 2119, "MUST NOT" is supposed to be used when harm to inter-operability needs to be prevented. There are only 2 corner-cases where YANG-stmt order matters - default-stmt for a leaf-list - auto-numbering for enum or bits There are already update rules to prevent these statements from being reordered, so this MUST NOT is not needed at all. > > > 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. 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 > > } > > I think this is allowed in any case. > > This is allowed. It is also allowed to move objects to/from submodules and there is no fixed order to submodules within a module. This is also allowed, which has the same affect: container bar { uses foo; /// <--- add leaf E after D, still reorders X leaf X{} } > Lada > > Andy > > > > Thanks, > > > > William > > > > > > _______________________________________________ > > netmod mailing list > > [email protected] > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=CwIFaQ&c=IL_XqQWOjubgfqINi2jTzg&r=GByLeg9jZvOv_AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=IVWnHPIm0qEHmxsw6Hhp_1xhdn2lIC4CSzMCsjh-zLo&s=0jQV22VeCUg5PDxgGj0fih8or13yFSYEsMqK1ALagu8&e= > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
