Hi, Thank you for these comments, replies inline.
Rohit Ranade <[email protected]> wrote: > Hi All, > > Please find some comments for the schema mount draft. If I find any > other will send in another mail. > > Editorial: > ============ > 1. Section 3.1 > "The "mount-point" statement MUST NOT be used in a YANG version 1 > module." > ==> It is unclear why such a restriction is placed. The reason is that YANG 1 doesn't support inline actions and notification, which means that top-level rpcs and notifs in the mounted module cannot be invoked using the mechanism described in section 5. I will try to clarify this. > 2. Section 3.2 > "state data in the "yangmnt:schema-mounts"" > ==> Here the yang tree diagram is not yet introduced. I feel better to > introduce > this diagram as it makes it easier to understand the data-nodes Ok. I moved section 8 to a new section 3.2. > 3. Section 3.2 > "Data in this container is intended to be as stable as data in the > top-level YANG library" > ==> What is the meaning of "as stable" as ? As a developer , I am > unclear what needs > to be done here. Please clarify. Kent also had a comment around this, and the text about stable is now removed. > 4. Section 3.2 > "i.e., instances of that mount point MUST NOT contain any data above > those that are defined in the parent schema." > ==> Here "any data above", means "above" in the hieararchy ? No, this was just wrong; it should be "except". > Not > clear, this is similar > to having a USB slot, but no device mounted on it as yet in UNIX > terms. Right ? > The query output on parent-schema should give empty data. > > 5. Section 3.2 > "If multiple mount points with the same name are defined in the same > module - either directly or because the mount point is defined in a > grouping and the grouping is used multiple times - then the > corresponding "mount-point" entry applies equally to all such mount > points." > ==> As per tree diagram, "mount-point" has two keys. So each module > can have multiple > mount points. So how to apply it "equally" ? Not clear. Note that the sentence starts with "If multiple mount points with the same name are defined in the same module" -- so this clearly doesn't apply to mount points with different names, right? For example, you can have: container foo { yangmnt:mount-point my-mnt-point; } container bar { yangmnt:mount-point my-mnt-point; } There is just one entry in the "mount-point" list, so that entry applies to both these mount points. Both are either "inline" or "shared-schema". > 6. Section 3.2 > Instead of "inline" and "shared-schema", I suggest to use > "variable-schema" and > "same-schema" > Reason: The key difference between the two is that in one case, the > schema MAY be different > while in the other the schema is same. The name can be similar to the > reason. At this point, we have to live with these terms. This was part of the compromise leading to this solution; there are other documents in the RFC editor's queue that depend on these terms. > Logical Point: > 1. Consider the topology where 1 main device is present with N logical > devices behind it. > When the mounting is done, it is quite possible that some of N devices > are having different > versions of modules. > This can lead to each instance of mount point, having different > schema. > How can the client understand the schema of each mount-point instance > ? Preferably get-schema of these devices and then know the model ? This draft says that each instance will have its own YANG library instance. So there the client can detect which versions of the different modules each instance supports. Then <get-schema> can be invoked to get the modules, if it is supported. /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
