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

[Ladislav Lhotka <[e-mail]>]

Martin Bjorklund <[e-mail]> writes:

> Ladislav Lhotka <[e-mail]> wrote:
>> 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.
>
> 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.
>

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)

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

OK.

>
>
>> > > >> 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)
>
> It is, per the latest discussions, where we say that the schema for
> 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

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

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