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. > Moreover, clients don't advertise any modules. > > not sure why this matters > > 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. > 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. 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 >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
