> On 01 Aug 2016, at 16:09, Andy Bierman <[email protected]> wrote:
>
>
>
> On Mon, Aug 1, 2016 at 6:45 AM, Ladislav Lhotka <[email protected]> wrote:
> Balazs Lengyel <[email protected]> writes:
>
> > Hello,
> >
> > As I understood Andy, it was already agreed that if you advertise
> > support for a model that defines extensions you MUST support those
> > extensions. So you effectively advertise support for those extensions.
>
> OK, so let's say a server advertises "ietf-system" (that imports
> "ietf-netconf-acm") with conformance-type "implement" and
> "ietf-netconf-acm" with conformance-type "import". Does the server
> support "nacm:default-deny-*" extensions or not?
>
>
> The server is only claiming conformance on the modules that it implements.
> The YANG conformance model has issues. This is not news.
My point was that "advertise" isn't sufficient.
>
>
> Moreover, clients don't advertise any modules.
>
>
> not sure why this matters
If the server can learn what extensions this client supports, it could adjust
its behaviour (probably impossible for something like schema mount though).
>
>
> > As an example if you claim support for nacm, you MUST support its
> > extensions.
>
> NACM is different in that the nacm:default-deny-* extensions just give
> auxiliary information - they help NACM-aware clients avoid sending
> requests that result in access-denied errors.
>
>
> they are quite clear wrt/ how a NACM implementation must treat the extensions.
Yes, but a client that doesn't understand them can still safely work with an
NACM-aware server.
>
>
> In contrast, a client that doesn't support schema mount cannot be used
> with a server that does.
>
>
> why not?
>
> anydata mount-point {
> mount:extension1;
> mount:extension2;
> }
>
> A regular client will see an anydata node with schema-less child nodes.
> A mount-aware client will see a mount-point and know how to determine
> the schema for the child nodes of the mount-point.
The regular client doesn't know the mounted parts of the data model, so no
automation is possible for this data.
Lada
>
>
> Lada
>
> Andy
>
>
> >
> > Balazs
> >
> >
> > On 2016-07-29 15:31, Ladislav Lhotka wrote:
> >> For this approach to work, we would need to change the character of
> >> extensions, in particular:
> >>
> >> - an implementation should be able to signal which extensions are
> >> supported,
> >>
> >> - extensions that change the data model need to be labelled as mandatory
> >> to support.
> >
> > --
> > Balazs Lengyel Ericsson Hungary Ltd.
> > Senior Specialist
> > Mobile: +36-70-330-7909 email: [email protected]
> >
>
> --
> 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
