Subject: Re: [netmod] Design-Time schema mount

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 01 Aug 2016 15:45:43 +0200

Balazs Lengyel <[email-masked]> 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?

Moreover, clients don't advertise any modules.

> 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.

In contrast, a client that doesn't support schema mount cannot be used
with a server that does.

Lada

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

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

---

From: Andy Bierman <[email-masked]>
Date: Mon, 1 Aug 2016 07:09:08 -0700

> 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

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

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 1 Aug 2016 17:11:05 +0200

> On 01 Aug 2016, at 16:09, Andy Bierman <[email-masked]> wrote:
> 
> 
> 

My point was that "advertise" isn't sufficient.

> 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).

> 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.

> 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

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 2 Aug 2016 10:26:23 +0200

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:

Hello,

why not?

anydata mount-point {
mount:extension1;
mount:extension2;
}

Lada

Lada

Andy

Balazs

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 02 Aug 2016 13:12:34 +0200

Balazs Lengyel <[email-masked]> writes:

> "Yes, but a client that doesn't understand them can still safely work
> with an NACM-aware server." 

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:
>
>     
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 2 Aug 2016 14:42:42 +0200

> is clearly not the case here.

This is apparently where views substantially differ; I do not consider
it an interoperability failure if an old client does not understand a
part of a datamodel of an updated server that the old client is not
dealing with. For me, interoperability means that a server can upgrade
while old clients continue to function as they did before. For me,
interoperability does not mean that server and clients always have to
be updated at the same time and it does not mean that a client needs
to understand and support the entire set of datamodels exposed by a
server.

/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, 04 Aug 2016 08:58:23 +0200

> to understand and support the entire set of datamodels exposed by a

If this was the only aspect of interoperability, then the best data
model would perhaps be just anydata at the top and nothing else.

In my view, it is the information from the data model that reduces
entropy and thus increases interoperability. Of course, it depends on
the purpose of the client but, in general, a client that understands
only a part of the data model is less interoperable with the given
server than a client that understands it fully.

Notwithstanding terminology, I think it is rather important to keep YANG
extensions strictly optional because otherwise we will see vendor
extensions that effectively limit the choice of clients and management
systems.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 26 Aug 2016 10:21:22 +0200 (CEST)

Hi,

[replying to the first post in this (old) thread; the thread got a bit
off-topic]

Balazs Lengyel <[email-masked]> wrote:
> Hello,
> 
> As I understand it, Schema-mount today does not support an important
> use-case which we definitely need, but others also indicated they
> want.
> 
> I want to specify off-line in design time which models will be mounted
> where. Many of my nodes know in design-time what their model structure
> will be, so I want a way to be able to document this in YANG.

I'd like to understand this use case in more detail.  You say that
that a "node knows in design-time" that YANG models it will use.  Thus
it seems natural to be able to specify which other modules to mount in
the YANG module itself.

The problem I see with this is that it is very limited to the use case
where each implementation defines its own YANG modules.  Suppose you
have such a model, for example:

   module A {
     ...
     mount ... {
       mount-module B;
       mount-module C;
     }
  }
      
[pseudo-code for module A that specifies that it mounts B and C]

Now, suppose you take this module A to another implementation, and it
needs to augment something into module C; essentially this means that
it would like to mount B, C and new module D.   This will not be
possible unless it modifies module A.

> In
> today's proposal the only way to find the Yang-Mounts is to read it
> from the live node.
> 
> * OAM integrators or operators want to be able to write CLI scripts
>   and Netconf messages without accessing (expensive) real nodes. For
>   this they need to know the mounts
> * We want to generate some fancy documentation from YANG automatically
>   in design-time.

In a way this is no different from the situation today - in order to
learn what YANG modules a device supports you need to connect and
parse the <hello> message (or ietf-yang-library data in the near
future).  This info could also be made available off-line in a file.

It should certainly be possible to define a file format that a device
somehow could "publish" off-line that contained all the info that is
available at run-time.  This file format could be exactly the same as
you would get if you did a NETCONF <get/> operation with some filter
to only retreive the ietf-yang-library data at the mount points.

/martin

> 
> * Many use cases need the possibility to mount schemas, but do not
>   need the added complexity of schema changes in run-time.
>   Notwithstanding the case of "YANG Features", for me the model schema
>   is a mostly static description of a nodes capabilities. Most of the
>   time I do not want to worry about the node changing its schema on
>   the fly.
> 
> 
> For this I propose 2 YANG extensions
> 
> extension schema-mount {
> description "Indicates that a YANG Module is to be mounted into
> another module.
> The argument specifies the name of the module to be mounted.";
> argument mounted-module;
> }
> 
> extension schema-mount-target {
> description "Specifies the target node under which a YANG module is to
> be mounted.
> The statement can only be used inside a schema-mount statement.
> The argument follows the same rules as an augment statement's target.
> argument target-node;
> }
> 
> The two extension statements can be placed in a separate module or the
> mounted module.
> 
> I don't insist on the solution, but I need the off-line/design-time
> specification of yang-mount to be possible. IMHO the design-time mount
> use-case is more important than the dynamic-mount.
> 
> regards Balazs
> --

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 26 Aug 2016 14:28:22 +0200

> it seems natural to be able to specify which other modules to mount in

Did you have a chance to look into my slides from Berlin? I sketched some
solutions there.

> possible unless it modifies module A.

Not necessarily, D could contain an augment with a target specified by a
schema node identifier that uses nodes from both A and C.

Imagine that instead of "ietf-ip" augmenting "ietf-interfaces" it would
be the other way around: "ietf-interfaces" mounts "ietf-ip". Then the
augment in ietf-ipv6-router-advertisements

  augment "/if:interfaces-state/if:interface/ip:ipv6" { ... }

needn't be changed.

The major problem with this IMO is that it needs a new YANG statement. 

> future).  This info could also be made available off-line in a file.

Yup. So we just need some machine-readable description of the structure
of mounted schemas.

> to only retreive the ietf-yang-library data at the mount points.

Well, if you have multiple levels of mounts, it will get messy: you
wouldn't know which yang-library data belongs to which mount point.

I believe some variation on YSDL could work, and as I wrote in another
thread, we could also incorporate datastores: after defining the
(multilevel) schemas, each datastore will get one assigned - and they
can also share them where needed.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 26 Aug 2016 14:38:30 +0200 (CEST)

> Did you have a chance to look into my slides from Berlin? I sketched some

Well, that's a *solution*.  I'd like to understand the *problem* first ;)

> schema node identifier that uses nodes from both A and C.

Not if B and D are defined as standalone modules, e.g. if B is
ietf-interfaces and D is ietf-ip.

>   augment "/if:interfaces-state/if:interface/ip:ipv6" { ... }

This would be an entirely different kind of mount!  The current mount
doesn't work like that; it doesn't give you visibility into the
combined models - by design.

> wouldn't know which yang-library data belongs to which mount point.

Why not - imagine that you do a full <get/> on such a device, it will
return the nested yang library data just fine.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 26 Aug 2016 15:12:06 +0200

> On 26 Aug 2016, at 14:38, Martin Bjorklund <[email-masked]> wrote:
> 

Right, we cannot have everything.

> combined models - by design.

Of course this is a different kind of mount.

> return the nested yang library data just fine.

Well, yes, if you are prepared to parse and process arbitrary data for which you don't know the schema. I think the schema and instance data (= <get/> reply) are different things and we should treat them so: the complete schema description should IMO have a well-known (meta-)schema, even if we express it with YANG.  

Lada

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 26 Aug 2016 19:25:04 +0200

Hello Martin,

As I see in your answer, you do not question that the design time
mount is an important and possibly frequent use-case, and I
certainly think it is.

I also found this on the Juniper website: What
are the benefits of a Juniper devices publishing Junos YANG
module off box?

See other comments below.

regards Balazs

On 2016-08-26 10:21, Martin Bjorklund wrote:

Hi,

Hello,

module A {
...
mount ... {
mount-module B;
mount-module C;
}
}

BALAZS: No you don't need to modify module A.   You can use a
separate file

to define mounting modD into modA.  Even my proposed
solution allows this.

module mount-list {
import moduleA { prefix moda; }
import moduleD {}

// indicate that moduleD is mounted somewhere
schema-mount moduleD {
// indicate where it is mounted
schema-mount-target /moda:baseContainer ;
}
}

In

BALAZS: actually it is made available in our case, also describing
support for features

BALAZS: That would be an INTERESTING idea for multiple reasons (and
I know some implementations who already do this).

Some potential use-cases:

- Mount descriptors

- defining default security rules for Netconf-acm

- listing available notification streams

- listing supported modules & features from yang-library

/martin

extension schema-mount {

regards Balazs

---

From: Andy Bierman <[email-masked]>
Date: Fri, 26 Aug 2016 10:53:21 -0700

Hi,

I agree with Martin about not specifying which YANG modules
can be mounted under some mount point, in the YANG module.

The mount point needs some basic properties (like "config root", "opstate
root", whatever).
Then data nodes are classified somehow (e.g. config=true/false) and that
determines
what content can be mounted under that mount-point.

The combination of modules on the server needs to be a deployment decision
to
prevent issues like Martin describes below.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 29 Aug 2016 12:51:01 +0200

Hello Andy,

Martin's main problem was that we would need to update the
original modules if the mount changes. I showed that design-time
mount can be defined without modifying the original modules, if
you specify the mount information in a separate file. So what
specific problems are you concerned about?

I do not want to make schema-mount a purely design-time solution.
However I feel that the ability to define the mounts in design
time is an important use-case that does not cause any problems.

regards Balazs

On 2016-08-26 19:53, Andy Bierman
wrote:

Hi,

The mount point needs some basic properties (like "config
root", "opstate root", whatever).

Then data nodes are classified somehow (e.g.
config=true/false) and that determines

The combination of modules on the server needs to be a
deployment decision to

Andy

On Fri, Aug 26, 2016 at 5:38 AM, Martin
Bjorklund <[email-masked]>
wrote:

Ladislav

> solutions there.

Well, that's a *solution*.  I'd like to understand the
*problem* first ;)

> schema node identifier that uses nodes from both A and
C.

Not if B and D are defined as standalone modules, e.g. if B
is

> needn't be changed.

This would be an entirely different kind of mount!  The
current mount

doesn't work like that; it doesn't give you visibility into
the

> wouldn't know which yang-library data belongs to which
mount point.

Why not - imagine that you do a full <get/> on such a
device, it will

/martin

netmod mailing list

[email-masked]