Re: [netmod] Design-Time schema mount

Balazs Lengyel Tue, 02 Aug 2016 01:27:00 -0700

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 <[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]

_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Design-Time schema mount

Reply via email to