Hi, Since the session management with Mounted devices, is not known to the client, how will the client know how to configure NACM rules for the inner devices ? Please provide an example use-case. From the client perspective, all rules for a particular mounted device, will the have the xpath of the corresponding mount-point as prefix.
With Regards, Rohit R Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10 From: Ladislav Lhotka<mailto:lho...@nic.cz> Sent: 26 मार्च 2018 20:00 To: Rohit Ranade<mailto:rohitrran...@outlook.com>; netmod@ietf.org<mailto:netmod@ietf.org> Subject: Re: [netmod] Comments on schema mount draft Rohit Ranade <rohitrran...@outlook.com> writes: > One more point. > > How to configure access control rules for the mounted models ? If you mean NACM from the viewpoint of the the parent tree, then I think the consensus was that it has to be specified in the parent tree, including rules for mounted data. This should probably be mentioned in the text. NACM data can also be present in the mounted tree, but it should be used only for the "internal" session in the case of split management, and ignored in the outer session. Lada > 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 <netmod-boun...@ietf.org> on behalf of Rohit Ranade > <rohitrran...@outlook.com> > Sent: Sunday, March 25, 2018 12:46:25 PM > To: netmod@ietf.org > 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 > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
