Re: [netmod] Design-Time schema mount

[Balazs Lengyel]

Hello Lada, I see 2 statements in your mail: "Yes, but a client that doesn't understand them can still safely work with an NACM-aware server."  IMHO simply ignoring security information is not acceptable in any way. So the nacm extensions are not "optional" either. "The regular client doesn't know the mounted parts of the data model, so no automation is possible for this data." That to me says: a client who doesn't support schema-mount will not really understand schema-mount. True, but that is valid for any schema-mount solution, so if we want schema mount we must live with it. Do you have any better alternative than extensions?  (For me run-time data or plain English text are worse.) Balazs On 2016-08-01 17:11, Ladislav Lhotka wrote: 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 -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist Mobile: +36-70-330-7909 email: balazs.leng...@ericsson.com

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod