Subject: [netmod] Question on the path element of the NACM YANG model

From: "Bogaert, Bart (Nokia - BE/Antwerp)" <[email-masked]>
Date: Thu, 23 Dec 2021 08:40:41 +0000

Hi,

We are having some debate about the contents of the path element of an NACM rule when combined with the module-name element.  Assume the following rule:

            <rule>
                <name>nome-of-rule</name>
                <module-name>some-module</module-name>
                <path>/node-a/node-b/node-c</path>
                <access-operations>read</access-operations>
                <action>permit</action>
            </rule>

When reading the RFC txt, the way I understand this rule is that only /node-a/node-b/node-c as defined in module 'some-module' will match (so the path 'adopts' the namespace of module 'some-module'.  As such it is not necessary the prefix the path.

When having a rule like this:

            <rule>
                <name>some-other-rule</name>
                <path>/node-a/node-b/node-c </path>
                <access-operations>read</access-operations>
                <action>permit</action>
            </rule>

There may be more 'matches' depending on whether there would be more than 1 module defining a path as in the above example (I leave in the middle whether this is good modelling or not but it is for the sake of the context of the question).

The RFC text is not specific on whether prefixes are mandatory in the path content but this is how I understand the text:

  *   If a module-name is part of the rule, the path is within the context of the module and 'adopts' the namespace of that module
  *   If the module-name is not part of the rule, the complete data store applies and then it depends on whether prefixes have been used in the path contents (or not).
  *   The module-name is not inside the rule-type choice, so the presence of module-name in the rule has meaning and brings context to the rule.

Is that a correct understanding?  Is there a section in the RFC that explicitly describes what can be expected as behavior when implemented in a server?

Best regards,
Bart

---

From: Jürgen Schönwälder <[email-masked]>
Date: Thu, 23 Dec 2021 11:36:55 +0100

>   *   The module-name is not inside the rule-type choice, so the presence of module-name in the rule has meaning and brings context to the rule.

I have not implemented this so I am not sure either but I would assume
that the 'data-node' value (of type 'node-instance-identifier')
resolves into a set of nodes, regardless of the existence or value of
the 'module-name' sibling. If a 'module-name' is set, then this set is
further restricted to the set of nodes defined in that module.

Note that in my interpretation, instance identifiers with components
in multiple modules, e.g., "/a:level0/b:level1/c:level3", will match
as long as the prefix 'c' of the node 'level3' is bound to 'c-module'
and 'module-name' is 'c-module'. In other words, I would not assume
that setting 'module-name' to 'c-module' implies that all nodes in the
instance identifier have to belong to 'c-module'.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: "Bogaert, Bart (Nokia - BE/Antwerp)" <[email-masked]>
Date: Thu, 23 Dec 2021 11:57:02 +0000

Hi Juergen,

Thanks for your interpretation.

-----Original Message-----
> From: Jürgen Schönwälder <[email-masked]> 
> Sent: Thursday, December 23, 2021 11:37 AM
> To: Bogaert, Bart (Nokia - BE/Antwerp) <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [netmod] Question on the path element of the NACM YANG model
>
> I have not implemented this so I am not sure either but I would assume that the 'data-node' value (of type 'node-instance-identifier') resolves into a set of nodes, regardless of the existence or value of the 'module-name'
 > sibling. If a 'module-name' is set, then this set is further restricted to the set of nodes defined in that module.
>
>  Note that in my interpretation, instance identifiers with components in multiple modules, e.g., "/a:level0/b:level1/c:level3", will match as long as the prefix 'c' of the node 'level3' is bound to 'c-module'
> and 'module-name' is 'c-module'. In other words, I would not assume that setting 'module-name' to 'c-module' implies that all nodes in the instance identifier have to belong to 'c-module'.

I also did not make that assumption but I'm not sure - when specifying a module-name In the rule - to refer to other nodes having nothing to do with that module.  Maybe there is a use case, however not sure which one (I would omit the module-name in such cases).  
To me it also does not seem to be mandatory to prefix the nodes (so binding it to a namespace).  If it is prefixed, then the match will be restricted to that namespace only, in case there is no prefix you may get multiple matched from different namespaces (if there happens to be an overlapping xpath. 

Best regards,
Bart

---

From: Jernej Tuljak <[email-masked]>
Date: Thu, 23 Dec 2021 14:28:54 +0100

On 23/12/2021 09:40, Bogaert, Bart (Nokia - BE/Antwerp) wrote:
>
> Hi,
>
> We are having some debate about the contents of the path element of an 
> NACM rule when combined with the module-name element.  Assume the 
> following rule:
>
>             <rule>
>
> When reading the RFC txt, the way I understand this rule is that only 
> /node-a/node-b/node-c as defined in module ‘some-module’ will match 
> (so the path ‘adopts’ the namespace of module ‘some-module’.  As such 
> it is not necessary the prefix the path.
>
> There may be more ‘matches’ depending on whether there would be more 
> than 1 module defining a path as in the above example (I leave in the 
> middle whether this is good modelling or not but it is for the sake of 
> the context of the question).
>
> The RFC text is not specific on whether prefixes are mandatory in the 
> path content but this is how I understand the text:
>
>   * If a module-name is part of the rule, the path is within the
>     context of the module and ‘adopts’ the namespace of that module
>   * If the module-name is not part of the rule, the complete data
>     store applies and then it depends on whether prefixes have been
>     used in the path contents (or not).
>   * The module-name is not inside the rule-type choice, so the
>     presence of module-name in the rule has meaning and brings context
>     to the rule.
>
> Is that a correct understanding?  Is there a section in the RFC that 
> explicitly describes what can be expected as behavior when implemented 
> in a server?
>

If this is for RFC8341, from the "description" of 
node-instance-identifier "typedef", which "leaf" path is a type of:

           A node-instance-identifier value is an
           unrestricted YANG instance-identifier expression.
           All the same rules as an instance-identifier apply,
           except that predicates for keys are optional.

And YANG instance-identifier lexical representation rules say this:

    An instance-identifier value is lexically represented as a string.
    All node names in an instance-identifier value MUST be qualified with
    explicit namespace prefixes, and these prefixes MUST be declared in
    the XML namespace scope in the instance-identifier's XML element.

Jernej

> Best regards,
>
> Bart
>
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod