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

From: "Xufeng Liu" <[email-masked]>
Date: Wed, 1 Nov 2017 15:49:53 -0400

Yes/support.

Thanks,
- Xufeng

> -----Original Message-----
> From: netmod [mailto:[email-masked]] On Behalf Of Kent Watsen
> Sent: Friday, October 20, 2017 5:38 PM
> To: [email-masked]
> Subject: [netmod] WG Last Call: draft-ietf-netmod-schema-mount-07
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 1 Nov 2017 19:56:52 +0000

Hi Xufeng, 

I support publication of this document.

Thanks,
Acee

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 1 Nov 2017 23:33:52 +0100

Does 'Yes/support' imply "I've reviewed this document and believe it
is ready for publication"?

/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: Dean Bogdanovic <[email-masked]>
Date: Wed, 1 Nov 2017 18:56:15 -0400

Kent,

As other work I have authored depends on it, I have read the document and think it's ready for publication. 

Dean

> On Oct 20, 2017, at 5:37 PM, Kent Watsen <[email-masked]> wrote:
> 
> All,
> 
> draft-ietf-netmod-schema-mount-07.
> 
> Positive comments, e.g., "I've reviewed this document 
> and believe it is ready for publication", are welcome!
> 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
> 
>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 1 Nov 2017 17:12:24 -0700

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.

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

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

Sec. 5: A NETCONF example of an RPC converted to action would help.
Also mention action converted to deeper nested action would help.
Sec. A.4 has a very terse RESTCONF example.

Sec. 8: There are no examples using the mount-point extension-stmt
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 do not understand why the mount-point subtree is needed twice in the YANG
module.
Why is the list duplicated under each schema entry?
An example showing the entire YANG module would help.
Seems like a lot of duplication of the YANG library.

Why is the entire schema-mounts container config=false?
There is no standard way to configure the schema mounts?
All this data is configured via proprietary models, probably
with even more copies of the YANG library?

Andy

---

From: "Xufeng Liu" <[email-masked]>
Date: Thu, 2 Nov 2017 09:28:02 -0400

Yes. I've reviewed this document and believe it is ready for publication.
There are other works that are in progress and depend on this document. It
would be good to see this one published.

Thanks,
- Xufeng

> From: Juergen Schoenwaelder [mailto:[email-masked]]
> Sent: Wednesday, November 1, 2017 6:34 PM
> To: Xufeng Liu <[email-masked]>
> Cc: 'Kent Watsen' <[email-masked]>; [email-masked]
> Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-schema-mount-07
> 
> Does 'Yes/support' imply "I've reviewed this document and believe it is
ready for
> publication"?

---

From: Robert Wilton <[email-masked]>
Date: Thu, 2 Nov 2017 17:06:34 +0000

Hi,

I have read this document and think that is almost ready for publication.

I have one general comment regarding the YANG module library (at the 
end), and a few nits, but otherwise the draft looks good.

1. Sec 1. Introduction paragraph 2, "internal node".  It wasn't 
absolutely clear to me what an internal node is, so I wonder whether 
this would be more clear as  "internal (i.e. non root) node".

2. Sec 1. Introduction, page 4, paragraph starting "2. 
Implementation-time ...".  This section states that it is a stable as 
YANG library, and hence cannot change due to a server reboot. However, 
YANG library doesn't appear to have that restriction, and hence this 
doesn't seem to align with RFC 7895, introduction paragraph 2.

3. Sec 2.1 Glossary of New Terms:  "Schema" isn't actually defined 
anywhere (RFC 7950 doesn't define this).  Should it be defined here?  
The NMDA datastores draft had a similar issue and we choose to define 
"datastore schema" instead.

4. Sec 3.2. paragraph 1.  Same comment as 2 above also applies here.  
The text "same management session" might be more clear as "same client 
management protocol session".

5. Sec 3.2. paragraph 2, last sentence: "are possible and such needs" => 
"are possible, and as such, needs"

6. Sec 3.2 paragraph 5.  Would it useful to state that even though the 
schema is the same, the data is different and not necessarily related.

7. Sec 3.3 last paragraph.  "On the other hand, " => "In addition, "

8.  Sec 6 Implementation Notes.  Would this section be better named 
"Implementation Considerations"?

9. Structure of ietf-yang-schema-mount module:
   - Should "uri" under namespace be marked as "mandatory" so that it 
doesn't appear to be optional in the tree diagram.
   - Should the "module" name be included under the namespace.  It seems 
that lots of other "module bindings" are done via the module name rather 
than the namespace?

10. Example A.3.  This contains some features that are enabled. Possibly 
it would be useful in the description to point this out, and state that 
unless the features are listed they wouldn't be enabled.

My last general comment relates generally to the structure of the 
Iietf-yang-schema-mount.  As Lada has pointed out previously, this 
module and YANG library bis could be more closely aligned (e.g. along 
the lines of reusing module-sets for the "schema" list).  It would have 
been nice if this module could augment YANG library (so that you can 
easily get the modules and schema mount information in a single simple 
request), however that would put an undesired dependency delaying 
publishing this draft until YANG library bis is completed.

Thanks,
Rob

On 20/10/2017 22:37, Kent Watsen wrote:
> .

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 03 Nov 2017 14:37:41 +0100

Hi Andy,

thanks for the comments, see inline.

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

> 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

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

>           version 1 module, neither explicitly nor via a 'uses'

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

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

> 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

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

---

From: Christian Hopps <[email-masked]>
Date: Sat, 04 Nov 2017 15:03:39 -0400

I've reviewed this draft (-08), and I think it's ready for publication.

A nit, the text:

Page 4 item 3: "The mounted schema is defined by instance data that is
part of the mounted data model."

Seems pretty complex if all it's trying to say is "It is what it is".

Thanks,
Chris.

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 06 Nov 2017 10:38:41 +0100

> part of the mounted data model."

So would it be better to say "... is defined by a new instance of YANG library
that is a part of the mounted data model."?

Thanks, Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 08 Nov 2017 14:26:47 +0100

Hi Rob,

thank you for the review, my replies are inline.

> this would be more clear as  "internal (i.e. non root) node".

Agreed, but probably with a hyphen: "non-root"?

> doesn't seem to align with RFC 7895, introduction paragraph 2.

I don't know exactly under what circumstances YANG library can change
after a reboot, but in such a case schema-mounts data might be subject
to a change as well. I definitely think that the "run-time" case is
something else.

> "datastore schema" instead.

I think the right place for defining the term "schema" (and "data model"
as well) is the specification of YANG because it is desirable that all
documents related to YANG use the same meaning.

> management protocol session".

Hmm, I wouldn't say this is more clear - it seems to indicate that we
are managing the client.

But it could also be that such rules are inappropriate in this document and
rather belong to a protocol spec.

> "are possible, and as such, needs"

I actually don't understand neither this sentence nor what the point of
such exceptions could possibly be.

> schema is the same, the data is different and not necessarily related.

I think this goes without saying, as it is also the case for a single mount
point that is a list node - data in each entry is different.

> 7. Sec 3.3 last paragraph.  "On the other hand, " => "In addition, "

Yes.

> "Implementation Considerations"?

Agreed.

> doesn't appear to be optional in the tree diagram.

Yes, this is an omission.

> that lots of other "module bindings" are done via the module name rather 

We need it exclusively for XPath, so it seems natural to stay close to XML
namespaces.

> unless the features are listed they wouldn't be enabled.

Yes, we reuse the groupings from ietf-yang-library, and the idea is to
apply the same semantics. And as you are saying below, it would be more
straightforward to integrate it directly with YANG library. 

> publishing this draft until YANG library bis is completed.

Of course I agree, but I think the priority should be to make things as
simple and easy to understand as possible. They are complex enough
anyway.

Thanks, Lada

---

From: Robert Wilton <[email-masked]>
Date: Wed, 8 Nov 2017 14:51:29 +0000

> Agreed, but probably with a hyphen: "non-root"?
OK.

> to a change as well. I definitely think that the "run-time" case is
A software upgrade could quite reasonably change YANG library without a 
device reboot.  Perhaps saying less is more precise:

E.g.

    2.  Implementation-time: the mounted schema is defined by a server
        implementor and is as stable as YANG library information. Also,
        a client can learn the entire schema together with YANG library data.

Or alternatively, you say that it is at least as stable as the YANG 
library information, and then list when it could change.

> documents related to YANG use the same meaning.
OK, 7950 doesn't define it today.  Is that a problem?

> Hmm, I wouldn't say this is more clear - it seems to indicate that we
My issue is that "same management session" isn't really that clear to 
what it is referring to.  Perhaps drop the "client" and have "same 
management protocol session"?

> rather belong to a protocol spec.
I think that they are OK here if this draft defines the lifetime of the 
schema.  If it is just the same as YANG library, then perhaps this could 
be left to the YANG library spec to specify?

> such exceptions could possibly be.
An example would presumably be where effectively the same data is being 
mounted in a separate place.  E.g. the list of physical interfaces in an 
LNE may represent a subset of all physical interfaces in the device, 
that would also be present in the host model.
> point that is a list node - data in each entry is different.
In Sec 3.2 paragraph 2, it clarifies that the mounted data is generally 
separate from the parent data.  For paragraph 5, I still that it is 
useful to state the equivalent that if a schema is mounted twice it 
doesn't mean the same data is mounted in both places.

> We need it exclusively for XPath, so it seems natural to stay close to XML
I was suggesting that it might be useful to add "module" in addition to 
namespace.

Thanks,
Rob

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 09 Nov 2017 16:37:53 +0100

>         a client can learn the entire schema together with YANG library data.

It seems that neither 7950 nor 7895 defines how stable YANG library data
is. The conclusion might be that it can change any time, which is IMO
hardly acceptable.  

> OK, 7950 doesn't define it today.  Is that a problem?

"Schema tree" and "schema node" are defined and used a lot in 7950, so
it might be good to define "schema" as well - meaning the schema tree
with all associated semantics. 

> management protocol session"?

This probably needs to be coupled somehow with YANG library stability -
if YANG library can change during a session, then schema mounts should
be permitted to change as well.

> that would also be present in the host model.

Then I would say simply "..., its data will generally have no
relationship to the data of the parent, unless the data model explicitly
states otherwise."

OK, "data model" is another term that isn't defined, but to me it is the
collection of YANG modules that define the schema. I think it's not
possible to say where the exception has to be stated, it can be
either in the parent or in the mounted module, or even elsewhere.

> doesn't mean the same data is mounted in both places.

This should be absolutely clear to anybody who understands that we are
only constructing a schema because, e.g., multiple uses of the same
grouping in YANG also don't mean the same instance data. Unfortunately,
with schema mount this confusion arises again and again, maybe the term
"mount" is really misleading.

...

> I was suggesting that it might be useful to add "module" in addition to 

This is possible but redundant, I was thinking about replacing the URIs
with module names. It probably doesn't really matter unless the URIs are
written by hand.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Thu, 9 Nov 2017 08:34:52 -0800

> is. The conclusion might be that it can change any time, which is IMO

Actually, the YANG library is allowed to change at any time.
Clients use the module-set-id and the yang-library-change notification
to keep their cached copy of the server's library up to date.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 09 Nov 2017 18:12:23 +0100

> to keep their cached copy of the server's library up to date.

Notifications are optional, so basically the client needs to check module-set-id 
before every operation, and even this may not be sufficient for avoiding errors.

The YANG data model was touted as a contract between the server and client - and
 it is a strange contract if the server can change it arbitrarily.

Lada

---

From: Robert Wilton <[email-masked]>
Date: Thu, 9 Nov 2017 17:38:40 +0000

> with all associated semantics.
OK, but we can't add definitions to 7950 now.  Would it make sense to 
add the definition to the NMDA draft and reference that?

Agreed.

> either in the parent or in the mounted module, or even elsewhere.
OK, but I would avoid introducing the term "data model".

> "mount" is really misleading.
So, I'm not confused by this (but I am quite familiar with the 
solution), but think that this is an area where a less familiar reader 
could make the wrong assumption, hence the suggestion to clarify it.

> with module names. It probably doesn't really matter unless the URIs are
I'm wondering whether this list is really required at all.  E.g. if you 
see my other email about YANG library structure, then if the structure 
for schema mount and YANG library was converged then would this list 
still be necessary?  Or could there just be a reference to the parent 
schema that xpath references are resolved against?

Thanks,
Rob

---

From: Andy Bierman <[email-masked]>
Date: Thu, 9 Nov 2017 09:44:24 -0800

>  it is a strange contract if the server can change it arbitrarily.

The server can change the library according to the contract.
It updates the module-set-id.

In reality, there are no routers that change the module set at run-time.
They are all mostly-monolithic firmware that need to reboot to change the
YANG modules.
Modular software is more complex to test, so it is not as common in
embedded systems.

Lada

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 9 Nov 2017 19:16:38 +0100

On Thu, Nov 09, 2017 at 05:38:40PM +0000, Robert Wilton wrote:
> OK, but we can't add definitions to 7950 now.  Would it make sense to add
> the definition to the NMDA draft and reference that?

So what is the difference between "schema tree" and "schema"? Or to
put it differently, what is "all associated semantics" that you are
adding to a "schema tree" to obtain a "schema"? RFC 7950 says:

   o  schema tree: The definition hierarchy specified within a module.

If I understand 'definition hierarchy' correctly, than it seems
"schema" is just an abbreviation of "schema tree", i.e., there is no
semantic difference between these two terms. If there is a difference,
we need to be able to spell it out.

/js

---

From: Robert Wilton <[email-masked]>
Date: Fri, 10 Nov 2017 09:39:12 +0000

On 09/11/2017 17:44, Andy Bierman wrote:
>
>
> On Thu, Nov 9, 2017 at 9:12 AM, Ladislav Lhotka <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     > On Thu, Nov 9, 2017 at 7:37 AM, Ladislav Lhotka <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     > > Robert Wilton <[email-masked] <mailto:[email-masked]>>
>     writes:
>     > >
>     > > >>
> They are all mostly-monolithic firmware that need to reboot to change 
> the YANG modules.
I think that it is becoming a lot more common.

Various network OSes allow fixes to be installed on the fly (which could 
include fixes or additions to the manageability interfaces), or the 
software to be upgraded without a formal reboot of the system.  Normally 
this would be achieved via some controlled failover of the route 
processor node to a hot standby route processor.

Linux allows packages to be installed on the fly.   This could include 
new protocols and services with associated YANG modules.  In fact, there 
are even variants of Linux that allow the running kernel to be hot 
patched without a reboot!

If a "hot" upgrade was being controlled by YANG then ideally you don't 
want to even break the management protocol session if possible.

Certainly, I would think that you need to allow LNE's to be 
provisioned/unprovisioned without restarting anything.

Thanks,
Rob

---

From: Robert Wilton <[email-masked]>
Date: Fri, 10 Nov 2017 13:35:38 +0000

>     o  schema tree: The definition hierarchy specified within a module.

When I read this definition of schema tree, it makes me think that it 
applies to only a single module.  E.g. you could have the ietf-ip schema 
tree, or the ietf-interfaces schema tree, etc.

But I think of a"schema" as being the tree structure of all schema nodes 
for a defined set of modules.

> we need to be able to spell it out.

So, if "schema tree" refers to the schema nodes in one module, I think 
"schema" is different from "schema tree".  But perhaps I'm 
misinterpreting the "schema tree" definition.

Thanks,
Rob

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 10 Nov 2017 16:39:36 +0100

>    o  schema tree: The definition hierarchy specified within a module.

As Rob points out, this is probably incorrect, as schema tree should
involve multiple modules. It makes no sense to talk about a schema tree
of an augmenting module unless we also take into account the augmented
module.

Anyway, schema tree is really just the hierarchy, i.e. a tree of schema
nodes, whereas schema is the hierarchy with datatypes, semantic rules
and all that. We can validate instance data against the schema, not
against the schema tree. This is at least how I understand it.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 10 Nov 2017 17:08:36 +0100

> against the schema tree. This is at least how I understand it.

The current definition says "definition hierarchy specified within a
module", perhaps this was intended to mean 'tree of schema nodes', but
perhaps it means "the hierarchy with datatypes, semantic rules and all
that". ;-) Looking at the definition of schema node, I see:

  o schema node: A node in the schema tree.  One of action, container,
  leaf, leaf-list, list, choice, case, rpc, input, output,
  notification, anydata, and anyxml.

With this, your interpretation makes sense and a better way to define
scheme tree would then be:

  o schema tree: The tree formed out of schema nodes of a module.

The schema could be defined as

  o schema: All definitions of a module including the schema tree.

I think it is OK to scope these definitions to the notion of a module.
If people talk about the schema (schema tree, schema nodes) of a
collection of modules, it seems natural to assume that this means the
union of the schemas (schema trees, schema nodes).

/js

---

From: Lou Berger <[email-masked]>
Date: Sat, 11 Nov 2017 00:50:09 +0800

> such exceptions could possibly be.

In the case of the example, LNEs, there is a relationship between 
interfaces in the parent and interfaces in the LNE that is known at the 
parent, but the LNE.  (Think host interface assigned to VM.)

Lou

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 13 Nov 2017 11:20:44 +0800

> union of the schemas (schema trees, schema nodes).

In many cases it is more useful to talk about the multi-module schema as
defined by YANG library and, potentially, schema mount. The
tree-diagrams draft assumes that tree diagrams will capture both the
parent and mounted hierarchy in the same diagram. The thing is that a
collection of modules often defines hierarchies that aren't mere
side-by-side unions of the individual module hierarches. And
specifically, it is somewhat difficult to talk about a hierarchy for a
module that consists only of augments, without having the context of the
module(s) augmented by it.

So I would suggest to define both "module schema/tree" and
"schema/tree", the latter meaning a multi-module schema as defined by
YANG library and schema mount specification.

Actually, we have another candidate for a more precise definition, namely
"data model". So one option could also be to use "schema/tree" for the
single-module, and "data model/tree" for the multi-module stuff.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 13 Nov 2017 11:48:01 +0800

...

> add the definition to the NMDA draft and reference that?

Ultimately, these terms belong to the YANG spec, but some termporary
solution might be useful, and the NMDA draft looks like a good
candidate.

...

> OK, but I would avoid introducing the term "data model".

Any reason for avoiding it? This term is used quite a lot.

> could make the wrong assumption, hence the suggestion to clarify it.

Ideally, everybody should understand that schema mount is just another
means for making modular schemas, as augment is. Unfortunately, it seems
that especially the "inline" method attracts instance-related
considerations.

> schema that xpath references are resolved against?

Some kind of prefix definition (be it URI- or module-based, or both), is
still necessary because potentially we can have modules with conflicting
prefixes.

Lada