Re: [netmod] WG Last Call: draft-ietf-netmod-schema-mount-07

[Ladislav Lhotka <[e-mail]>]

Hi Andy,

thanks for the comments, see inline.

Andy Bierman <[e-mail]> writes:

> Hi,
>
> I have read this draft a few times.
> I have not implemented the draft but it seems reasonably constrained.
>
> here are some comments.
>
> Sec 1: seems like a lot of background on YANG and then some explanation
> of the solution.  The problem statement is never really explained.
> Some discussion of building blocks for virtual servers might help.

The third paragraph starts with:

   In some cases these mechanisms are not sufficient; it is often
   necessary that an existing module (or a set of modules) is added to
   the data model starting at a non-root location.

I think this and the subsequent text explains the problem
sufficiently. Do you have any suggestions as to what needs to be said?


>
> Sec. 3.3: there are no examples of multiple level schema -mounts.
> What is the use-case for this complexity?

One use case are the LNE and NI levels combined. Details are in appendix A.

>
> Sec. 4: an instance document showing the config for the example would
> help

Such an example is in appendix A.3. Sec. 4 should refer to it though.

>
> Sec. 5: A NETCONF example of an RPC converted to action would help.

This is a good idea. We can expand appendix A.4 by showing the action to
which the ietf-isis:clear-adjacency RPC is conceptually converted

> Also mention action converted to deeper nested action would help.

An action is attached to a node, and it is actually that node that
becomes nested. It is pretty much the same as actions defined inside a
grouping, so I don't think it needs extra explanation.

> Sec. A.4 has a very terse RESTCONF example.
>
> Sec. 8: There are no examples using the mount-point extension-stmt

We are referring to the LNE and NI modules that use this extension
statement.

> Why is this restriction in the text? It is not explained.
>
>           The 'mount-point' statement MUST NOT be used in a YANG
>           version 1 module, neither explicitly nor via a 'uses'
>           statement.

I don't know the reason for this CLR. Martin?

>
>
> I do not understand why the mount-point subtree is needed twice in the YANG
> module.
> Why is the list duplicated under each schema entry?

Because the structure is recursive, thus allowing any number of mount
levels. We need to refer to mount points at the top level, but then there
can be mount points inside each subschema.

> An example showing the entire YANG module would help.

What do you mean by the entire YANG module? Section 8 shows it in its
entirety.

> Seems like a lot of duplication of the YANG library.

Well, yes, we could simplify it by integrating YANG library with
"schema-mounts" data. This is what I proposed earlier:

https://www.ietf.org/mail-archive/web/netmod/current/msg18045.html

>
> Why is the entire schema-mounts container config=false?

For the same reason why YANG library is config=false. The schema is an
implementation-time thing and the client shouldn't be allowed to tinker
with it at run time.

> There is no standard way to configure the schema mounts?

To some extent you can do it using the "inline" method, which I
personally don't like. I am seriously concerned that we keep mixing up
schema and instance data, see also the recent discussions about tree
diagrams.

Likewise, I could ask: There is no standard way to configure YANG
library?

> All this data is configured via proprietary models, probably
> with even more copies of the YANG library?

I would prefer to treat YANG library, schema mount data and the
specification of available datastores not as normal data but rather as
special metadata that is known beforehand and cannot be changed.

Lada

>
>
>
> Andy
>
>
>
>
> On Fri, Oct 20, 2017 at 2:37 PM, Kent Watsen <[e-mail]> wrote:
>
>> All,
>>
>> This starts a two-week working group last call on
>> draft-ietf-netmod-schema-mount-07.
>>
>> The working group last call ends on November 3.
>> Please send your comments to the netmod mailing list.
>>
>> Positive comments, e.g., "I've reviewed this document
>> and believe it is ready for publication", are welcome!
>> This is useful and important, even from authors.
>>
>> Could the authors, explicitly CC-ed on this email,
>> please also confirm one more time that they are
>> unaware of any IPR related to this draft.
>>
>> Thank you,
>> Netmod Chairs
>>
>>
>> _______________________________________________
>> netmod mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod
>>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67