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

[Ladislav Lhotka <[e-mail]>]

On Wed, 2017-11-08 at 09:50 +0100, Martin Bjorklund wrote:
> Kent Watsen <[e-mail]> wrote:
> > 
> > 
> > > Hi Kent,
> > >
> > > thanks for the thorough review, see my responses inline.
> > 
> > Hi Lada, please see below.
> > 
> > 
> > >> 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?
> 
> 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".
> 
> > > 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.
> > 
> > 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/?
> 
> 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.

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

> 
> > >> 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?
> > >
> > > Potentially yes, but sibling nodes with the same name are not an issue
> > > for XPath evaluation. 
> > 
> > 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
> 
> 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.

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.

> 
> > >> Also, should how NACM interacts with mounted instance data be
> > >> specified?
> > >
> > > 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.
> > 
> > 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.
> 
> 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

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

> 
> 
> > >> 5. This document does not say anything about how it relates to NMDA.
> > >> 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
> > >> 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?
> > 
> > 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.

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

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

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

> 
> 
> > >> What if the mounted schema has deviations in <operational>.
> > >
> > > 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.
> > 
> > 
> > 
> > 
> > >> Nits (line-break separated):
> > >>
> > >> Is "other optional choices" being vague on purpose?  Should it just
> > >> call out features and deviations?
> > >
> > >Yes, it should.
> > >
> > >>
> > >> "the YANG library data" seems odd.  Maybe "the instance of the YANG
> > >> Library module"?
> > >
> > > It is the same but I prefer the former. Note that the term "instance"
> > > is not defined in RFC 7950.
> > 
> > okay
> > 
> > 
> > >> - 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
> > >
> > > I am not sure that it *needs* to be done, because it could have
> > > 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...
> > 
> > 
> > >> - Schema mount applies to the data model
> > >> + Schema mount regards the data model
> > >
> > > OK
> > >
> > >>
> > >> - This document allows mounting of complete data models only.
> > >> + This document allows mounting of complete modules only.
> > >
> > > Correct
> > >
> > >
> > >> - may extend this model by defining
> > >> + may extend this solution by defining
> > >
> > > Or perhaps "approach"? I would leave "solution" to marketing folks.
> > 
> > "approach" is fine.
> > 
> > 
> > >> 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.
> > 
> > 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?
> > 
> > 
> > >> - A "container" or "list" node
> > >> + A 'container' or 'list' node
> > >
> > > 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?
> 
> 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
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67