Martin Bjorklund <[email protected]> writes: > Ladislav Lhotka <[email protected]> wrote: >> On Wed, 2017-11-08 at 09:50 +0100, Martin Bjorklund wrote: >> > Kent Watsen <[email protected]> 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 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
