Subject: [netmod] Design-Time schema mount

From: Balazs Lengyel <[email-masked]>
Date: Thu, 28 Jul 2016 13:42:27 +0200

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

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

--
Balazs Lengyel Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909 email: [email-masked]

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 28 Jul 2016 15:05:04 +0200

Hi Balazs,

I agree with you, we need a machine-readable offline specification of
the entire schema. After Martin returns from his vacation, I plan to
discuss this with him.

Some comments are inline.

Balazs Lengyel <[email-masked]> writes:

> 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. 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 fact, I met several people in Berlin that expect to be able to
standardise data models utilising schema-mount.

>   
> * 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.
>   
>
> 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;
> }
>
> 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;
> }

This looks similar to the RELAX NG "external" pattern that I briefly
described in slide 9 of my presentation in Berlin:

https://www.ietf.org/proceedings/96/slides/slides-96-netmod-7.pdf

However, I am not in favour of introducing extesions for such
fundamental data modelling functions because doing so undermines the
value of YANG as a standard.

That's why I would prefer to use a solution based on a meta-schema
language (see my slide 10). After all, YANG library in fact already is a
meta-schema language, so we could just extend it to support schema
mount.

Lada

>
> 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
> -- 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

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

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 28 Jul 2016 15:30:40 +0200

Hello,

Yes this is similar to your proposal, so we should be able to hammer out 
something.

I am happy to see you agree that this is an important use-case, YANG 
needs to support.

Solution: My problem is that the specific data in the yang-library or in 
ietf-yang-schema-mount is only defined and available in run-time, so I 
don't understand how it could solve the design-time schema-mount 
requirement. IMHO whatever the solution, it needs to be in a file.

Procedure: I assume we will not update the YANG language in the next 
year or more, so I don't see what else can we do beside yang-extensions.
In one other modeling environment it is common practice, that new 
modeling concepts are first introduced as extensions, then at every 
release of the model language the important extensions are incorporated 
as proper language statements. This gives a fast path to implement new 
things, provides a method to "experiment" with new things and to do a 
shake-down on new things before they are incorporated into the modeling 
language. Again I don't insist on extensions, but what is the alternative?

Balazs

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 28 Jul 2016 16:14:42 +0200

> On 28 Jul 2016, at 15:30, Balazs Lengyel <[email-masked]> wrote:
> 
> Hello,
> 
> Yes this is similar to your proposal, so we should be able to hammer out something.
> 
> I am happy to see you agree that this is an important use-case, YANG needs to support.
> 
> Solution: My problem is that the specific data in the yang-library or in ietf-yang-schema-mount is only defined and available in run-time, so I don't understand how it could solve the design-time schema-mount requirement. IMHO whatever the solution, it needs to be in a file.

YANG library data can appear in the RFC text, in a file, or elsewhere off line.

We could do the same with "mount-points" data as defined in draft-ietf-netmod-schema-mount-02 but only with one level of mounts. 

> 
> Procedure: I assume we will not update the YANG language in the next year or more, so I don't see what else can we do beside yang-extensions.

We could define it using built-in statements, and bump YANG version number. I don't get why this is worse that introducing "standard extensions", except at Layer 8 (Political) - we can claim that YANG is stable even though it isn't.

> In one other modeling environment it is common practice, that new modeling concepts are first introduced as extensions, then at every release of the model language the important extensions are incorporated as proper language statements. This gives a fast path to implement new things, provides a method to "experiment" with new things and to do a shake-down on new things before they are incorporated into the modeling language. Again I don't insist on extensions, but what is the alternative?

We could do that, but it would require to change the character of extensions as something that implementations can ignore. Some upfront signalling that an implementation isn't using standard YANG would also be useful.

Lada

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 28 Jul 2016 16:37:24 +0200

Hello Lada,

I want a formal way to define mount data. I want tools to
understand it, so RFC text or an unspecified file  is a not a good
solution.

We could have described any data model in plain English. The
whole point of YANG is to have a formal definition. If containing
one container in another is described in a formal way why is
containing a full module in a container less important?

My solution would only use standard YANG files with a well
specified content. I need the same level of precision from any
alternative.

Balazs

On 2016-07-28 16:14, Ladislav Lhotka
wrote:

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 28 Jul 2016 16:51:53 +0200

> We could define it using built-in statements, and bump YANG version number. I don't get why this is worse that introducing "standard extensions", except at Layer 8 (Political) - we can claim that Y…

- Running a document of the size and complexity of the YANG
  specification through the IETF and publication process is expensive.

- It is not clear at this point in time that YANG mounts are required
  to be supported everywhere.

- It is up to this WG to keep YANG 1.1 stable. Claiming YANG isn't
  stable as a justification to make it not stable is a somewhat
  circular logic.

I strongly believe that it is feature to work with extensions wherever
possible. Gain experience with language extensions first and if they
are widely deployed and used, consider to move them into the core at
some point in time. I believe it is desirable to keep the complexity
of the core YANG language somewhat under control.

You likely won't agree with any of this and this is fine. But I also
do not agree with your statement that working with extensions is just
a layer 8 (political) issue.

/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: Robert Wilton <[email-masked]>
Date: Thu, 28 Jul 2016 16:13:58 +0100

> of the core YANG language somewhat under control.
I agree with this point (and also the similar one that Balazs made).

One issue I see is that extensions are effectively required to be 
optional, allowing tooling to ignore them if they wish.  This seems to 
hamper their usefulness in some scenarios.

For the example given here, I feel that something stronger would be 
useful, i.e. an extension that must be implemented by the tooling for 
the particular YANG module to make sense.

Perhaps when a module includes an extension it could indicate whether 
support for that extension is regarded as required for the module to be 
useful, or conversely if the module is still sane even if support for 
the extension isn't implemented.

Thanks,
Rob

---

From: Andy Bierman <[email-masked]>
Date: Thu, 28 Jul 2016 08:14:33 -0700

Hi,

+1 to concerns about stability.

Andy

On Thu, Jul 28, 2016 at 7:51 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> > We could define it using built-in statements, and bump YANG version
> number. I don't get why this is worse that introducing "standard
> extensions", except at Layer 8 (Political) - we can claim that YANG is
> stable even though it isn't.
> >
>

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 28 Jul 2016 18:00:34 +0200

> hamper their usefulness in some scenarios.
BALAZS: Any better ideas? IMHO if you want to support yang-mount you 
will support the needed extensions.
> support for that extension is regarded as required for the module to 
> be useful, or conversely if the module is still sane even if support 
> for the extension isn't implemented.
BALAZS: Agree, in the RFC text or in the extension's description we 
could indicate whether it is mandatory to support the extension in order 
to support the module.
Or we could add a formal statement, but no updates to YANG, so add an 
extension to indicate this, and we are back in to step one.
By the way we already have IETF-defined extensions in nacm. Is it 
mandatory to support those? IMHO no.

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 28 Jul 2016 18:01:06 +0200

Hello,

I agree that revising the RFC6020bis) now is not the way to go.
But if we want schema-mount we need a solution. Both for the
current provisional proposal and for design-time mount yang
extensions are used.  IMHO this is a viable solution and a much
better one then putting all information about mounting into plain
English or run-time data.

regards Balazs

On 2016-07-28 17:14, Andy Bierman
wrote:

Hi,

Andy

On Thu, Jul 28, 2016 at 7:51 AM,
Juergen Schoenwaelder <[email-masked]>
wrote:

On
Thu, Jul 28, 2016 at 04:14:42PM +0200, Ladislav Lhotka
wrote:

> We could define it using built-in statements, and
bump YANG version number. I don't get why this is worse
that introducing "standard extensions", except at Layer
8 (Political) - we can claim that YANG is stable even
though it isn't.

- Running a document of the size and complexity of the
YANG

specification through the IETF and publication process
is expensive.

- It is not clear at this point in time that YANG mounts
are required

- It is up to this WG to keep YANG 1.1 stable. Claiming
YANG isn't

stable as a justification to make it not stable is a
somewhat

circular logic.

I strongly believe that it is feature to work with
extensions wherever

possible. Gain experience with language extensions first
and if they

are widely deployed and used, consider to move them into
the core at

some point in time. I believe it is desirable to keep
the complexity

You likely won't agree with any of this and this is
fine. But I also

do not agree with your statement that working with
extensions is just

/js

--

Juergen Schoenwaelder           Jacobs University
Bremen gGmbH

Phone: +49 421 200 3587         Campus Ring 1 |
28759 Bremen | Germany

netmod mailing list

[email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Thu, 28 Jul 2016 12:16:54 -0700

On Thu, Jul 28, 2016 at 9:00 AM, Balazs Lengyel <[email-masked]

> BALAZS: Any better ideas? IMHO if you want to support yang-mount you will
> support the needed extensions.
>
>>
>> useful, i.e. an extension that must be implemented by the tooling for the
>> particular YANG module to make sense.
>>
>> useful, or conversely if the module is still sane even if support for the
>> extension isn't implemented.
>>
> BALAZS: Agree, in the RFC text or in the extension's description we could
> indicate whether it is mandatory to support the extension in order to
> support the module.
Actually we have been over this issue many times already with YANG 1.1.

An implementation that claims conformance to NACM MUST implement the
extensions defined for NACM (default-deny-write, default-deny-all).
A generic tool that claims to support YANG does not need to claim
conformance to NACM and therefore does not need to implement the NACM
extensions.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 29 Jul 2016 15:31:35 +0200

>   specification through the IETF and publication process is expensive.

This is just a procedural issue. Updates to some protocols (e.g. OSPFv3)
were specified as a diff.

>   to be supported everywhere.

Well, we already have things in base YANG that arguably aren't required
to be supported everywhere, for example notifications or actions.

But either way - if an implementation doesn't support a fundamental data
modelling function that's used in a module, then this implementation
cannot use this module, no matter whether the function is implemented as
built-in or extension.

>   stable as a justification to make it not stable is a somewhat

I don't see anything circular here. If any implementor can randomly
choose from a host of extensions, there will be no standard YANG at
all. We all remember browser wars, right? They were caused by extensions
to web standards. I am concerned that this can easily happen here, too. 

> of the core YANG language somewhat under control.

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. 

Lada

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 29 Jul 2016 16:43:47 +0200

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. 
As an example if you claim support for nacm, you MUST support its 
extensions.

Balazs