NACM Improvement Requests

[abierman]

There is no repo for nacm-next so adding it to netconf-next

Customers keep complaining about NACM when they try to use it to partition list entries within another subtree,

Use case:

• Need to provide each client with access to one nested interface entry.
• Want to use read-default=deny and use 'permit' rules to a few top-level subtrees

Problem: NACM data-rules always apply to the entire subtree

• Access to the /interfaces container must be given in a data-rule.
• A 'deny' rule for every interface EXCEPT the allowed one is needed /interfaces/interface[name='foo']
• A separate rule-list for each group is needed

e.g. 3 interfaces: allow access to if3

rule1: deny /interfaces/interface[name='if1'] rule2: deny /interfaces/interface[name='if2'] rule3: permit /interfaces

Solution: (Has not been implemented yet!)

• create a special data-rule access parameter than indicates if it applies to the entire subtree or just that node

• this will allow very simple data-rules

  rule1: permit-node /interfaces rule 2: permit-subtree /interfaces/interface[name='if3']

[mjethanandani]

As Andy mentions, this is not a NETCONF-next issue.

[avtobiff]

Skip here, create a nacm-next project.

[BalazsLengyel]

Alternatively specify, that if you are allowed to read/write the /interfaces/interface[name='if9'] that implies read/write(?) access on all parent lists/containers and their keys: in this case /interfaces.