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

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Thu, 1 Aug 2019 17:14:38 +0900

Hi Jan,
I will review your suggestion below and tell you our opinion later.

Thanks a lot.

Best Regards,
Paul

On Wed, Jul 31, 2019 at 5:21 PM Jan Lindblad <[email-masked]> wrote:

> 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 example.com
>  owners [ example.com--eng-it ]
>  tenants tenant dev
>   policies policy team-black
>    owners [ example.com--dev ]
>    rules rule 2
>    !
>    rules rule allow-malware-sites
>     owners [ example.com--dev ]
>
> This is supposed to mean that members of the example.com--eng-it group
> have full ownership of everything in the example.com domain. Within this
> domain, there is a tenant called dev, with a policy called team-black. That
> policy is owned by example.com--dev. This means this policy may be
> updated by members in example.com--dev and example.com--eng-it. Within
> the policy there are two rules ("2" and "allow-malware-sites"). The
> "allow-malware-sites" rule has the example.com--dev 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 example.com org to see the example.com domain and everything
> within it. Next there is a rule to allow members of the example.com 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 example.com 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 example.com
>  group [ example.com--dev example.com--eng-it ]
>  rule read-all
>   path              /i2nsf-cfi/domains/domain[name='example.com']
>   access-operations read
>   action            permit
>  !
> !
> nacm rule-list example.com--dev
>  group [ example.com--dev ]
>  rule 1
>   path   /i2nsf-cfi/domains/domain[name='example.com
> ']/tenants/tenant[name='dev']/policies/policy[name='team-black']
>   action permit
>  !
> !
> nacm rule-list example.com--eng-it
>  group [ example.com--eng-it ]
>  rule 1
>   path   /i2nsf-cfi/domains/domain[name='example.com']
>   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 example.com--dev
>  user-name [ jan vasilij ]
> !
> nacm groups group example.com--eng-it
>  user-name [ chris victor ]
> !
> nacm groups group example.com--finance
>  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,
> /jan
>

-- 
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: [email-masked], [email-masked]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Wed, 7 Aug 2019 22:14:32 +0900

Hi Jan,
Your suggestion looks good to my SKKU team and me.
I agree with your suggestion that our Consumer-Facing Interface YANG data
model leverages the existing NACM.

Could you like me to take any further steps with your sketch?

With your work, my team will be able to continue the revision of
Consumer-Facing Interface YANG data model.

Thanks.

Best Regards,
Paul

---

From: Jan Lindblad <[email-masked]>
Date: Wed, 7 Aug 2019 16:44:43 +0200

Paul, team,

> Your suggestion looks good to my SKKU team and me.

Ok, very good. Glad you liked it. 

I should point out that even if I'm a YANG doctor, this is so far just my own idea. Nobody in the NETMOD WG has given any kind of approval yet, and I believe that will ultimately be necessary. I think the friction should be much less when the module structure is like this, but it's still far from an ordinary, mainstream module.

> I agree with your suggestion that our Consumer-Facing Interface YANG data model leverages the existing NACM.
> 
> With your work, my team will be able to continue the revision of Consumer-Facing Interface YANG data model.

Ok. I think you mean that I should wait for the i2nsf to produce a new revision of the module, then review that module version. If this is not what you mean, please tell me again what you would like me to do.

Best Regards,
/jan

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Fri, 9 Aug 2019 14:12:22 +0900

Hi Jan,
I will revise our Consumer-Facing Interface YANG Data Model according to
your suggested sketch.
Once the revision is done, I will let you know to review our revised YANG
module.

Thanks.

Best Regards,
Paul

On Wed, Aug 7, 2019 at 11:44 PM Jan Lindblad <[email-masked]> wrote:

> I should point out that even if I'm a YANG doctor, this is so far just my
> own idea. Nobody in the NETMOD WG has given any kind of approval yet, and I
> believe that will ultimately be necessary. I think the friction should be
> much less when the module structure is like this, but it's still far from
> an ordinary, mainstream module.
>
> Ok. I think you mean that I should wait for the i2nsf to produce a new
> revision of the module, then review that module version. If this is not
> what you mean, please tell me again what you would like me to do.
>
> Best Regards,
> /jan
>
>