Kent Watsen <kwat...@juniper.net> 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 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
