Subject: [netmod] draft-bjorklund-netmod-structural-mount: Namespace issues

From: Anton Tkáčik <[email-masked]>
Date: Mon, 21 Mar 2016 13:13:33 +0000

Hi,

if I understand correctly netmod-structural-mount inlines "mounted" data directly to container / list which is used,

which brings up following issues:

1. It is possible to have identifier conflict between data from model defining mount and mounted data (if mounted schema

contains same model).

e.g.

      module mount-under-mount {

             container mounts {

                   list mount {

                       key name;

                       leaf name;

                              container mounts {

                                    // List of discovered remote mounts

                              }

                              mnt:mount-point data;

                   }

             }?

      }

2. Expanding data directly under container / list may be problematic for clients which do not support netmod-structural-mount.

I believe both can be solved elegantly by requiring mount-point extension to be used inside anydata element, which signifies

to client that this may be any YANG modeled data (and client can omit processing it) and also provides isolation between

data from module defining mount point and mounted data.

E.g:

list mount {

    key name;

    leaf name {...}

    // additional data

    anydata data {

         mnt:mount-point data {

              mnt:mount-yang-library;?

         }

    }

}
AntonTkáčik
Chief Software Architect

Mlynské Nivy 56 / 821 05 Bratislava / Slovakia
+421 911 309 249 / [email-masked]
reception: +421 2 206 65 111 / www.pantheon.sk
[logo]

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 23 Mar 2016 16:26:21 +0100

Hi Anton,

Anton Tkáčik <[email-masked]> writes:

> 1. It is possible to have identifier conflict between data from model
> defining mount and mounted data (if mounted schema

I think we need to eliminate all kinds of recursive mount, so this
should not happen. 

> 2. Expanding data directly under container / list may be problematic
> for clients which do not support netmod-structural-mount.

I don't think it can work if the client doesn't support the mount mechanism.

>
>
> I believe both can be solved elegantly by requiring mount-point
> extension to be used inside anydata element, which signifies

This has been already discussed in the mailing list. IMO, the biggest
problem of anydata (as it is currently defined, at least) is that it
permits really anything, i.e. not only stuff contributed by the mounted
modules.

Lada

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

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 23 Mar 2016 22:01:16 +0100 (CET)

> permits really anything, i.e. not only stuff contributed by the mounted

The fact that anydata can represent "really anything" does not mean
that every server MUST allow the client to create "really anything"
for all anydata config nodes.  It will depend on the semantics of each
particular anydata node.

I think that using mount-point as a substatement to anydata is in fact
the only really safe option to mount.  Both the proposed solutions in
the current structural mount and ysdl drafts are unsafe for clients
that don't understand the mount.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 24 Mar 2016 12:56:40 +0100

> for all anydata config nodes.  It will depend on the semantics of each

Schema validation is effectively disabled for anydata nodes. This may be
a problem especially for implementations that perform validation as a
separate step, perhaps automatically from the data model.

And with schema validation out of the way, it is easier to exploit
potential bugs in the server.

> the only really safe option to mount.  Both the proposed solutions in

Well, if safe means (partial) compatibility of old clients - and I am
not even convinced about this. Otherwise it is IMO less safe because the
schema is loosened.

> that don't understand the mount.

True.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 24 Mar 2016 14:13:00 +0100

> potential bugs in the server.

Lada, as far as I recall you wrote an I-D that proposed to mount data
anywhere. So what did change your mind that you now want strict schema
validation?

> > that don't understand the mount.

What do you mean with 'partial' compatibility? I also do not
understand which schema is 'loosened'? Can you give me an example of
'partial' compatibility and 'loosened' schema? Do you have a counter
proposal that avoids these issues?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 24 Mar 2016 14:47:33 +0100

> On 24 Mar 2016, at 14:13, Juergen Schoenwaelder <[email-masked]> wrote:
> 

With YSDL, the schema validation is absolutely strict: The server provides a list of modules and revisions in yang-library, and a recipe how the modules are combined. Everything is fixed and static, as it is without YSDL, only some of the schema subtrees are attached to non-root locations. As I said in the interim, YSDL is just an externally specified augment.  

> What do you mean with 'partial' compatibility? I also do not

Take the rtgyangdt model, for example. If a mounting mechanism is in place, a client that doesn't understand it will only see a void top-level structure, which is hardly useful.

> understand which schema is 'loosened'? Can you give me an example of

Loosened means exactly that anydata is used. For example, a rogue client may use it to send data that test the robustness of the server's Unicode implementation.

For instance, a server implementor can place a rock-solid off-the-shelf RELAX NG validator in front of the backend and rely on it to catch everything that violates the schema. If anydata is involved, the RELAX NG validator will, well, relax, and pass everything to the backend.

> proposal that avoids these issues?

Sure: avoid anydata, and forget about supporting clients that don't understand mounts.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 24 Mar 2016 14:59:00 +0100

> With YSDL, the schema validation is absolutely strict: The server provides a list of modules and revisions in yang-library, and a recipe how the modules are combined. Everything is fixed and static…

But the same applies here. This discussion is about how to arrange
things such that _old_ clients that do not understand mounts break.
At least that is what I thought.

> Take the rtgyangdt model, for example. If a mounting mechanism is in place, a client that doesn't understand it will only see a void top-level structure, which is hardly useful.

Yes, but it does not _break_ an old client (which likely is not
interested at all in the stuff it does not understand).
 
> Loosened means exactly that anydata is used. For example, a rogue client may use it to send data that test the robustness of the server's Unicode implementation.

We have been there. Since the server understands the model, the server
will reject bad input.
 
> For instance, a server implementor can place a rock-solid off-the-shelf RELAX NG validator in front of the backend and rely on it to catch everything that violates the schema. If anydata is involve…

Again, the server understands the data model, it will not implement
anydata.

> Sure: avoid anydata, and forget about supporting clients that don't understand mounts.

So you propose a flag day from which on all clients must support
mounts? Not very realistic I think.

I believe not breaking existing clients is a key requirement in order
to allow incremental deployment of new features.

/js