Re: [yang-doctors] [I2nsf] Yangdoctors last call review of draft-ietf-i2nsf-consumer-facing-interface-dm-05

Jan Lindblad <> Wed, 31 July 2019 08:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 38CA912004A; Wed, 31 Jul 2019 01:22:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id liJqfWqLJ8li; Wed, 31 Jul 2019 01:21:58 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0C94B120098; Wed, 31 Jul 2019 01:21:57 -0700 (PDT)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 74B731AE02BB; Wed, 31 Jul 2019 10:21:54 +0200 (CEST)
From: Jan Lindblad <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_AF26CFE3-729D-4F92-83B0-F05AB1D4ACA5"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 31 Jul 2019 10:21:52 +0200
In-Reply-To: <>
Cc: YANG Doctors <>,, IETF Discussion <>,, Brian Kim <>
To: "Mr. Jaehoon Paul Jeong" <>, "" <>
References: <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <>
Subject: Re: [yang-doctors] [I2nsf] Yangdoctors last call review of draft-ietf-i2nsf-consumer-facing-interface-dm-05
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email list of the yang-doctors directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 31 Jul 2019 08:22:02 -0000

Paul, I2NSF team,

> Thanks for your volunteering to improve our Consumer-Facing Interface YANG Module.
> Could you propose a way to redesign ietf-i2nsf-cfi-policy.yang to befit NACM?

Certainly. Find my proposed sketch for the module structure attached.

I think it is important for the adoption of this module that it is reasonably easy to implement it on top of existing NETCONF/RESTCONF/YANG servers. They all implement the NACM management access control mechanism today, so the ietf-i2nsf-cfi-policy module should build on that. It's therefore important to leverage the existing NACM mechanisms and concepts for groups, users, permissions. 

It would be technically possible to set up all the management access control rules needed to implement the I2NSF ideas by only creating rules in NACM. The NACM rules are massively more complex than the simple owner leaf proposed in your YANG module, however. From a usability perspective I think it makes good sense to keep the abstraction in ietf-i2nsf-cfi-policy and let the module implementor make sure this high level authorization view is translated into NACM specifics.

In order to make this feasible, I changed the owner string leaf into a leafref pointer to NACM groups, and removed the module's separate identities for permissions. Let's adopt the NACM counterparts instead. The structure of the rules was very flat, i.e. the domains, tenants, policies and rules were mostly side by side, not reflecting their logical hierarchy in the YANG. This would make the number of NACM rules to control access to each individual item very high. By arranging them in a tree structure, I believe the number of NACM rules can be kept to a minimum. NACM rules may have a high impact on server performance, so it's important to not have excessive amounts of them.

I created a hierarchy with domains on top, each domain containing zero or more tenants, each with zero or more policies that in turn consist of zero or more rules. At each level it is possible to list owners in the form of NACM groups. The module implementor would then have to translate these owner references to actual NACM rules.

Here is an example sketch configuration and the resulting NACM rules (in CLI style syntax for readability):

i2nsf-cfi domains domain
 owners [ ]
 tenants tenant dev
  policies policy team-black
   owners [ ]
   rules rule 2
   rules rule allow-malware-sites
    owners [ ]

This is supposed to mean that members of the group have full ownership of everything in the domain. Within this domain, there is a tenant called dev, with a policy called team-black. That policy is owned by This means this policy may be updated by members in and Within the policy there are two rules ("2" and "allow-malware-sites"). The "allow-malware-sites" rule has the group listed as owner; this is superfluous. In this example, the rules are otherwise empty.

In order for existing NC/RC/YANG servers to enforce the above, the ietf-i2nsf-cfi-policy module implementation would need to translate the intent above to NACM rules like the ones below. In this example, the implementation created a rule to allow members of the dev and eng-it groups within the org to see the domain and everything within it. Next there is a rule to allow members of the dev group to update the policy named team-black within the dev tenant. Finally, there is a rule to allow the eng-it group members to update anything within the domain. The default nacm policy per statement in the YANG is to deny anyone else to see anything within the i2nsf domain.

nacm rule-list
 group [ ]
 rule read-all
  path              /i2nsf-cfi/domains/domain[name='']
  access-operations read
  action            permit
nacm rule-list
 group [ ]
 rule 1
  path   /i2nsf-cfi/domains/domain[name='']/tenants/tenant[name='dev']/policies/policy[name='team-black']
  action permit
nacm rule-list
 group [ ]
 rule 1
  path   /i2nsf-cfi/domains/domain[name='']
  action permit

NACM also contains a mapping from user names to groups. Is this in line with your expectations? Do we need additional infrastructure to control this mapping?

nacm groups group
 user-name [ jan vasilij ]
nacm groups group
 user-name [ chris victor ]
nacm groups group
 user-name [ clara sakura ]

What do you think about this approach to the management access control? I'm not sure I got the relations between domains, tenants, policies and rules as you want them. Are all these levels needed? Do you believe this is this is a workable approach to your vision?

Please let me know if you would like me to take any further steps with this sketch. I should mention that I also have plenty of other comments on your updated module, but I want to get the access control approach resolved before looking at anything else.

> I am not aware of any particular party interested to implement our data model.

Then it is all the more important that the solution can be implemented on top of the existing servers out there without modifying them.

Best Regards,