Re: [netmod] Design-Time schema mount

[Ladislav Lhotka <[e-mail]>]

> On 28 Jul 2016, at 15:30, Balazs Lengyel <[e-mail]> 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

> 
> Balazs
> 
> 
> On 2016-07-28 15:05, Ladislav Lhotka wrote:
>> 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 <[e-mail]> 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.
>>>   
>>> 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;
>>> }
>> 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
>>> -- 
>>> Balazs Lengyel                       Ericsson Hungary Ltd.
>>> Senior Specialist
>>> Mobile: [phone]              email: [e-mail]
>>> _______________________________________________
>>> netmod mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/netmod
> 
> -- 
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: [phone]              email: [e-mail]

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