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

[Martin Bjorklund <[e-mail]>]

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.

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

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


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


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