One more point. How to configure access control rules for the mounted models ? I think in the "Security Considerations" section, we should highlight the need for configuring NACM rules before mounting the nodes. Else all information can be queried. 1 example for rule configuration for notification and data-node will be helpful.
With Regards, Rohit R ________________________________ From: netmod <[email protected]> on behalf of Rohit Ranade <[email protected]> Sent: Sunday, March 25, 2018 12:46:25 PM To: [email protected] Subject: [netmod] Comments on schema mount draft 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.. 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 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. 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 ? 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. 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. 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 ? With Regards, Rohit R
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
