> On 24 Aug 2015, at 18:42, Andy Bierman <[email protected]> wrote: > > > > On Mon, Aug 24, 2015 at 9:35 AM, Ladislav Lhotka <[email protected]> wrote: > Ladislav Lhotka <[email protected]> writes: > Hi, > > > > > 2. The rogue vendor can use a must statement to achieve the same > > effect (or perhaps just state it in a description?). What’s important > > is whether the server that advertises such an extension rejects a > > configuration where the new parameter is missing or not. > > As a follow-up to the discussion during the interim call, here is an > example of a module snippet that augments "ietf-interfaces" with a > mandatory node: > > import ietf-interfaces { > prefix if; > } > > augment "/if:interfaces" { > container top { > must "foo"; > leaf accept { > type boolean; > default true; > } > leaf foo { > type empty; > } > } > } > > If a server advertises this module along with "ietf-interfaces", then, > according to the rules of YANG 1.0, a datastore without the "foo" > instance is invalid. > > > > > When a datastore is validated, all "must" constraints are > conceptually evaluated once for each data node in the data tree, and > for all leafs with default values in use (see Section 7.6.1). If a > data node does not exist in the data tree, and it does not have a > default value, its "must" statements are not evaluated. > > > > According to sec. 7.5.3, para 2, the must statement is not evaluated > for a missing NP container because it has no default-stmt.
OK, so the the must statement can be moved under “accept”: must “../foo”; In YANG 1.1, NP containers exist for validation purposes, see issue Y41. > > > Therefore, I think it really makes no practical sense to insist on > restricting augments to non-mandatory nodes. > > > It does because the current YANG conformance model does not > require the augmenting modules to be present. They are considered > optional so a client can be written to work with the base module > and not break every time a new augments is added. No text in 6020(bis) supports this interpretation. Lada > > > Lada > > > > Andy > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
