> On 01 Aug 2016, at 16:09, Andy Bierman <a...@yumaworks.com> wrote: > > > > On Mon, Aug 1, 2016 at 6:45 AM, Ladislav Lhotka <lho...@nic.cz> wrote: > Balazs Lengyel <balazs.leng...@ericsson.com> 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: balazs.leng...@ericsson.com > > > > -- > 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