Subject: [netmod] review of draft-ietf-netmod-schema-mount-08

From: Kent Watsen <[email-masked]>
Date: Thu, 2 Nov 2017 21:04:29 +0000

Hi,

I have read this document and think that is almost ready for 
publication.  I have five discuss items and a bunch of nits.

Kent // contributor

1. From Section 4:

   Routing configuration inside an NI often needs to refer to interfaces (at
   least those that are assigned to the NI), which is impossible unless such
   a reference can point to a node in the parent schema (interface name).

This seems overstated.  Rather it is a result of an earlier design decision.
An alternate solution might have exported the global interfaces into a 
config false list inside the mount jail.   Was such a solution discussed?

2. Also from Section 4:

   For every schema mounted using the "use-schema" method, it is possible 
   to specify a leaf-list named "parent-reference" that contains zero or more
   XPath 1.0 expressions.  Each expression is evaluated with the node in the
   parent data tree where the mount point is defined as the context node.  

If you can nested-mounts, can you also have nested parent-references?

3. Also from Section 4 (same paragraph):

   For the purposes of
   evaluating XPath expressions within the mounted data tree, the union
   of all such nodesets is added to the accessible data tree.

Could this ever result in name collision?

4. Regarding Security Considerations, what about /yangmnt:schema-mounts?
Also, should how NACM interacts with mounted instance data be specified?

5. This document does not say anything about how it relates to NMDA.  Clearly all this is targeted to the conventional datastores, but how is it reflected in e.g., <operational>?  Does anything need to be said here?
What if the mounted schema has deviations in <operational>.

Nits (line-break separated):

Is "other optional choices" being vague on purpose?  Should it just call out features and deviations?

"the YANG library data" seems odd.  Maybe "the instance of the YANG Library module"?

- document, and could be possibly dealt with in a future revision of the YANG data modeling language
+ document, as it needs to be dealt with as an update to the YANG data modeling language

- Schema mount applies to the data model
+ Schema mount regards the data model  

- This document allows mounting of complete data models only.
+ This document allows mounting of complete modules only.

- may extend this model by defining
+ may extend this solution by defining

In S3, replace "YANG 1.1" with "YANG 1.1 and its continuances"?

- A "container" or "list" node
+ A 'container' or 'list' node
	
- of "container" and "list" statements.
+ of the "container" and "list" statements.

- Mounted schemas for all mount points
+ The schema for all mount points

- in the "yangmnt:schema-mounts" container.
+ in the top-level "yangmnt:schema-mounts" container defined in the "ietf-yang-schema-mount" module defined in [Section 8].

 The "refers through its key" part is not clear - are you talking about the mount-point's argument/label?

I don't understand "above those that are defined in the parent schema."  - mostly the word "above" is throwing me…

- If multiple mount points with the same name
+ If multiple mount points with the same label    (wasn't it called a "label" before?)

Regarding "Note, that in this case a mount point", beyond the missing comma, an example would be very helpful.  I don't know if I understand it right.

In the YANG itself, "State data nodes" didn't parse well, "Protocol accessible nodes" instead?

Regarding the first paragraph in Appendix A, I took me some time to realize that the rtgwg-device-model included 
ietf-network-instance and that those modules define mount-points and where.   Please make this easier for first-time readers.

In A1, is ietf-network-instance missing?  - might want to double-check all

In all the examples, but beginning with A2, it might help to show the RESTSCONF protocol operation that illustrates the result, so that it's clear where in the data model the particular instance is located.  Anything that can be done to provide more context would be helpful.

For the 2nd half of A2, what happens if there is an "lne-2", will it also get "eth0"?

- which should include at least
+ which should include at least an instance of ietf-yang-library:modules-state and ietf-interfaces:interfaces-state, as follows: 

Thanks again,
Kent

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 03 Nov 2017 16:53:06 +0100

Hi Kent,

thanks for the thorough review, see my responses inline.

> config false list inside the mount jail.   Was such a solution

Do you mean something like having "symlinks" to interfaces inside the
mount jail? Yes, this was discussed and rejected. According to Martin,
tail-f had made a very bad experience with this approach.

> If you can nested-mounts, can you also have nested parent-references?

Yes, but you can only refer to the level directly above.

> Could this ever result in name collision?

Potentially yes, but sibling nodes with the same name are not an issue
for XPath evaluation. 

> 4. Regarding Security Considerations, what about

You are right, the security considerations should be similar to those in
RFC 7895. It is the same type of risk.

> Also, should how NACM interacts with mounted instance data be

This is a good question because, in principle, top-level NACM rules can
address instances of mounted schemas. On the other hand,
ietf-netconf-acm can also be a part of the mounted schema - and if so,
can its rules also address instances in the parent schema via the
parent-reference mechanism?

But I would say it is up to rfc6536bis to deal with these questions.

>
>
> 5. This document does not say anything about how it relates to NMDA.
> Clearly all this is targeted to the conventional datastores, but how
> is it reflected in e.g., <operational>?  Does anything need to be said
> here?

The "use-schema" case shouldn't pose big problems because it is
essentially an externally specified augment. The "inline" case is
somewhat disturbing though: could the embedded YANG library instances be
different in different datastores?

> What if the mounted schema has deviations in <operational>.

I don't understand why this could be an issue.

> call out features and deviations?

Yes, it should.

> "the YANG library data" seems odd.  Maybe "the instance of the YANG

It is the same but I prefer the former. Note that the term "instance" is not defined in RFC 7950.

> + document, as it needs to be dealt with as an update to the YANG data modeling language

I am not sure that it *needs* to be done, because it could have
far-reaching consequences.

> + Schema mount regards the data model

OK

> + This document allows mounting of complete modules only.

Correct

> + may extend this solution by defining

Or perhaps "approach"? I would leave "solution" to marketing folks.

> In S3, replace "YANG 1.1" with "YANG 1.1 and its continuances"?

Not sure. For example, next version of YANG can/should turn "mount-point" into
a built-in statement.

> + A 'container' or 'list' node

Actually, following RFC 7950 conventions, no quotes should be used here.

> + of the "container" and "list" statements.

OK

> + The schema for all mount points

OK

> + in the top-level "yangmnt:schema-mounts" container defined in the
> "ietf-yang-schema-mount" module defined in [Section 8].

Section 2.2 defines the relationship between the "yangmnt" prefix and
that module.

>  about the mount-point's argument/label?

Yes. Would it be more clear to say this?

   Every entry of this list refers through its key to a mount point
   label and specifies the schema for all mount points with that label.

>
> I don't understand "above those that are defined in the parent
> schema."  - mostly the word "above" is throwing me…

Yes, "apart from" is better.

> + If multiple mount points with the same label    (wasn't it called a

Right

>
> Regarding "Note, that in this case a mount point", beyond the missing
> comma, an example would be very helpful.  I don't know if I understand
> it right.

You don't, because that sentence is completely wrong - it is yet another
example of mixing up the schema and instance. The idea is that if (for
some strange reason) the mounted schema includes the ietf-yang-library
module, then all *instances* of this (mounted) YANG library must be
identical and have the same content as the "use-schema" data.

This is another reason why I would prefer to have only one YANG library
at the top - it is not regular state data.

> accessible nodes" instead?

Do you mean the comment? The same or similar comment is in many existing
modules - for example, ietf-yang-library has "Operational state data
nodes". It is true though that it doesn't make much sense here as long
as there are no configuration data.

> ietf-network-instance and that those modules define mount-points and
> where.   Please make this easier for first-time readers.

OK, we should try.

> In A1, is ietf-network-instance missing?  - might want to double-check

No, because A1 describes only the top (device) level,
ietf-network-instance is a part of the LNE schema in A.2.

>
> In all the examples, but beginning with A2, it might help to show the
> RESTSCONF protocol operation that illustrates the result, so that it's
> clear where in the data model the particular instance is located.
> Anything that can be done to provide more context would be helpful.

It seems to make sense in A.3 - to demonstrate an URI of a resource
inside an NI.

> For the 2nd half of A2, what happens if there is an "lne-2", will it

I think "ietf-logical-network-element:bind-lne-name" leaf should contain
the name of a LNE to to which the interface "eth0" is assigned, so it
looks like a mistake.

> + which should include at least an instance of
> ietf-yang-library:modules-state and ietf-interfaces:interfaces-state,
> as follows:

But the important point is that only interfaces assigned to the LNE need
to be included, so it is not just "an instance of
ietf-interfaces:interfaces-state". Why do you think the existing text
isn't OK?

Lada

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

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

---

From: Kent Watsen <[email-masked]>
Date: Tue, 7 Nov 2017 21:51:53 +0000

> thanks for the thorough review, see my responses inline.

Hi Lada, please see below.

> tail-f had made a very bad experience with this approach.

Yes, a little bit like a symlink inside the mount jail.  Good to hear
that it was discussed.  I still think the above "impossible" word is
overstating things.  Perhaps s/impossible such/possible when/?

> Yes, but you can only refer to the level directly above.

Okay.

> Potentially yes, but sibling nodes with the same name are not an issue

I don't know if I agree that it can't be an issue.  What if the module
has a top-level /widgets container, and there is a parent-reference to
a /widgets container, and there is an Xpath to /widgets - seems like
you could have both false-positives and false-negatives...

> You are right, the security considerations should be similar
> to those in RFC 7895. It is the same type of risk.

ok

> This is a good question because, in principle, top-level NACM rules
> can address instances of mounted schemas. On the other hand,
> ietf-netconf-acm can also be a part of the mounted schema - and if
> so, can its rules also address instances in the parent schema via
> the parent-reference mechanism?
>

I don't know, but it seems that this draft is introducing the concept.
Not to mention, rfc6536bis is already with the IESG.  In either case,
let's work out what it means and then decide which draft it needs to
go into.

> somewhat disturbing though: could the embedded YANG library instances
> be different in different datastores?

YANG Library is only available in <operational> (it's all config false).
I think you mean the embedded YANG Library instances under the mount 
points.  Yes, you may have a problem here.  Still, this isn't my question,
is more about schema-mounting requirements across datastores.  E.g., if
a schema-mount exists in <running>, must it existing in <intended> and
<operational> as well?  Conversely, if a schema-mount exists in
<operational>, must it exist in <running>?  I think this draft should
clarify such things.

> I don't understand why this could be an issue.

I'm not saying it's a problem yet.  I'm just stating that such things
can occur and it's unclear that, if they do, could it cause problems.
For instance, a mounted schema may be looking for a parent reference
that doesn't exist because of a deviation.

> is not defined in RFC 7950.

okay

> far-reaching consequences.

Here I'm using "needs" not to mean that it "has to be done" but more that,
if it is done, it would have to be done in an update to the YANG data 
modeling language.  The current sentence seems too open-ended...

> Or perhaps "approach"? I would leave "solution" to marketing folks.

"approach" is fine.

> Not sure. For example, next version of YANG can/should turn "mount-point"
> into a built-in statement.

So then, when we define yang-next, we'd be forced to either incorporate
schema-mount or simultaneously publish an update to this RFC to allow
it to work with the new version of YANG?  Even if YANG-next defined a
built-in equilvalent, would we not want this mechanism to continue to
be supported, for backwards compatibility?

> Actually, following RFC 7950 conventions, no quotes should be used here.

I'm confused about these conventions - are they written down somewhere.
In Martin's review of zerotouch draft, he dinged me on my mis-use of
single-quotes, for the second time.  Looking at RFC 7950, I don't see
the convention listed anywhere, or are you saying that the convention
is throughout the RFC and folks are expected to implicitly understand
what it is?

> Section 2.2 defines the relationship between the "yangmnt" prefix and

Yes, but this is the first time in the RFC that /schema-mounts is
mentioned.  The prefix is there, but why not guide the user a little
more?

>   label and specifies the schema for all mount points with that label.

Yes!

> Yes, "apart from" is better.

agreed.

> identical and have the same content as the "use-schema" data.

okay

> at the top - it is not regular state data.

Does this need to be discussed some more?

> as there are no configuration data.

Yes, the comment.  Well, this is a nit, so take it for what it's worth,
but it did seem a bit unusual when I read it.

>> Regarding the first paragraph in Appendix A, I took me some time 
>> to realize that the rtgwg-device-model included 
>> ietf-network-instance and that those modules define mount-points 
>> and where.   Please make this easier for first-time readers.
>
> OK, we should try.

thanks.

> ietf-network-instance is a part of the LNE schema in A.2.

okay

> It seems to make sense in A.3 - to demonstrate an URI of a resource

great, anything that helps.

> the name of a LNE to to which the interface "eth0" is assigned, so it

glad to hear there might be a mistake

> But the important point is that only interfaces assigned to the LNE
> need to be included, so it is not just "an instance of

What you have isn't wrong, per se, I'm just trying to make the text
more readable.  How about:

  which should include at least an instance of
  ietf-yang-library:modules-state and ietf-interfaces:interfaces-state,
  containing only the entries relevant to the mount-point, as follows:

- or use your own words?

Kent

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 08 Nov 2017 09:50:19 +0100 (CET)

> >> config false list inside the mount jail.   Was such a solution

Actually, this wouldn't work, since config true leafrefs/xpaths can't
refer to this "config false" list inside the mount jail.

Besides, even a symlink approach would in fact allow for "such a
reference to point to a node in the parent schema tree".

> overstating things.  Perhaps s/impossible such/possible when/?

See above; I think the current text is correct.

The point is that *somehow* the solution needs to allow for these
kinds of references; symlinks could be one solution, the
"parent-reference" that we use is another solution.

> a /widgets container

The nodes exist in a namespace.  So if you have /widgets in two
different modules there is no issue.  However, if you mount a module A
and at the same time provide A's toplevel nodes as parent references
then you might have a problem - or not!  The document defines what
happens in this case (the result is the union).   Also note that
constructing the set of mounted modules and corresponding
parent-references is up to the implementation.

> let's work out what it means and then decide which draft it needs to

I think NACM in the parent node should cover access to the mounted
data.  For example, it should be possible to have a rule for:

 /network-instances/network-instance[name='foo']/vrf-root/rt:routing

> >> Clearly all this is targeted to the conventional datastores

No, or maybe I don't understand what you mean.  Schema mount allows
for mounting config false nodes, or even doing a "read-only" mount.
Such a mount is clearly not available in the conventional datastores.

>, but how

I agree that this needs to be clarified.  This issue partly comes from
the fact that schema mount uses the groupings in the old yang
library.  I think we need to use the new groupings from rfc7895bis.

> is throughout the RFC and folks are expected to implicitly understand

I think you just should be consistent; if you attach some semantic
meaning to single quotes vs double quotes the document needs to
explain that meaning.  If it is just for quotation, be consistent.  I
think the RFC editor prefers double quotes (but I can't find a
reference to this).

As for the term container; this is a term for an interior node,
defined in 7950, so it is used w/o quotes.   Compare with references
to the "container" statement.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 08 Nov 2017 11:17:27 +0100

> "parent-reference" that we use is another solution.

I agree, and also we don't want to make such nodes protocol-accessible in the
mounted tree.

> parent-references is up to the implementation.

This is fine with must expressions but actually leafrefs are defined so that the
leaf instance being referred to has to be unique. This needn't be the case here
- I don't know if it matters.

>  /network-instances/network-instance[name='foo']/vrf-root/rt:routing

Do you mean that NACM can only be used at the top level? What if it is also part
of the mounted schema?

> > YANG Library is only available in <operational> (it's all config false).

OK, so if I have a mount point of the "inline" type in <running> or <intended>,
I have to go to <operational>, find the corresponding instance of the mount
point (if it's there), and read the YANG library data below it to learn the
schema in <intended>? What if the mount point is inactive configuration? Then
the mounted schema probably cannot be determined at all.

> > <operational>, must it exist in <running>?  I think this draft should

I am really confused: what do you mean by saying that "schema-mount exists"? Do
you mean "mount point exists"? If so, as long as the mount point is config=true,
it has to exist in all datastores (I assume). 

> library.  I think we need to use the new groupings from rfc7895bis.

YANG started basically as a document-oriented schema language (and schema mount
adheres to this view). NMDA tries to extrapolate its use to multiple documents
with differents schemas. My gut feeling is that this is not going to work - the
complexity will be overwhelming.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 08 Nov 2017 13:58:08 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> leaf instance being referred to has to be unique.

I'm not sure what you refer to, but in general a leafref can refer to
more than one node:

   The "path" expression evaluates to a node set consisting of zero,
   one, or more nodes.  If the "require-instance" property is "true",
   this node set MUST be non-empty.

> This needn't be the case here

I don't think that we can/should require that a server that mounts
nacm has to enforce the nacm rules in the mount jail.

One reason for mounting nacm would be "peer mount" where you mount all
models some other device supports.  In this case that other device
will of course enfore the nacm rules, but in the parent node these
nacm rules don't mean anything.

> point (if it's there)

It is, per the latest discussions, where we say that the schema for
operational is a superset of the schema for the config.

>, and read the YANG library data below it to learn the
> schema in <intended>?

Sure, and this is how it would work in pre-NMDA as well, to learn the
schema for <candidate> for example.

/martin

> What if the mount point is inactive configuration? Then

---

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

>    this node set MUST be non-empty.

OK, I wasn't aware of this. The text in other places indicates
uniqueness, e.g.

- The "path" substatement (Section 9.9.2) is used to identify the
  referred leaf or leaf-list node ... (sec. 9.9)

- The predicates are only used when more than one key reference is
  needed to uniquely identify a leaf instance. (sec. 9.9.2)

> nacm rules don't mean anything.

OK.

> operational is a superset of the schema for the config.

But this is not about the schema - you have to find the *instance* of the
mount point and grab YANG library data from there. But if that instance
isn't in <operational> (which is IMO possible), you are out of luck.

Again, this mixing of instance data and YANG library (representing the
schema) is problematic.

Lada

---

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

> library.  I think we need to use the new groupings from rfc7895bis.

We previously discussed this point an chose not to use rfc7895bis as we 
wanted to allow current implementations to add support NIs/LNEs with 
minimal additional work, and specifically not require support for 
rfc7895bis and NMDA to support LNEs/NIs (and consequently schema mount).

I do think it would be good to have rfc7895bis supersede 
ietf-yang-schema-mount by incorporating its functionality, but that 
wouldn't be a change to this document.

Lou