Balazs Lengyel <[email protected]> writes: > 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.
Not really, there are no security implications because access control policies are enforced at the server side. The client can use this information for avoiding requests that result in access-denied error, or perhaps reflect it in the user interface. > > "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. Yes, but if the YANG version is bumped, the client can immediately see that it is not compatible, and disconnect. In contrast, sec. 6.3.1 says that an extension "MAY be ignored in its entirety". According to the RFC 2119 semantics, doing so should not affect interoperability, which is clearly not the case here. > > Do you have any better alternative than extensions? (For me run-time > data or plain English text are worse.) For me too. As I said, I would prefer some kind of meta-schema approach, such as extending YANG library. Lada > > Balazs > > On 2016-08-01 17:11, Ladislav Lhotka wrote: > > > > 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 > > > > > > -- > 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
