On Mon, Aug 24, 2015 at 10:53 AM, Ladislav Lhotka <lho...@nic.cz> wrote:
>
> > On 24 Aug 2015, at 18:42, Andy Bierman <a...@yumaworks.com> wrote:
> >
> >
> >
> > On Mon, Aug 24, 2015 at 9:35 AM, Ladislav Lhotka <lho...@nic.cz> wrote:
> > Ladislav Lhotka <lho...@nic.cz> 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.
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.
> Lada
>
Andy
>
> >
> >
> > Lada
> >
> >
> >
> > Andy
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
