Re: [netmod] Comments on schema mount draft

Rohit Ranade <rohitrranade@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-bounces@ietf.org> on behalf of Rohit Ranade <rohitrranade@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