> On 24 Aug 2015, at 20:17, Andy Bierman <[email protected]> wrote: > > > > On Mon, Aug 24, 2015 at 10:53 AM, Ladislav Lhotka <[email protected]> wrote: > > > 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. > > > > YANG does not provide any mechanism to REQUIRE modules A and B > to both be implemented on a server. You may think it should, but > currently the YANG conformance is for an individual module.
There are sections on conformance and conformance announcement, and they say nothing like this. In my view, the data model comprises *all* modules advertised by the server. I think your interpretation of conformance might be an extrapolation from SNMP/SMI times, but, for better or worse, it really has no support in the YANG spec. > > As long as there is no server requirement to implement 2 modules together, > then YANG must allow for the possibility that the augmenting module > in not present. Therefore a client which only > supports the base module is valid. > > IMO this issue is closed. > The WG decided the only problem to solve with YANG conformance > is import-by-revision. This is a conformance issue. You want to > force the old client to support every augmenting module a server > may add to this base module. > > Current YANG conformance rules do not work this way for good reason. > > > > > > > > > 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. > > > Show me the text that says if a server implements a module > it must also implement other modules that augment this module. > There is none. Well, if the server *advertises* such a module, then I guess it has to implement it. I think it comes down to the definition of the “data model”, which is the substance of the client-server contract. It looks like it needs to be clarified, if we can disagree on such a fundamental thing. Lada > > > > Lada > > > Andy > > > > > > > > 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
