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

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Tue, 5 Nov 2019 18:03:03 +0900

Hi Jan,
I have revised the Consumer-Facing Interface Data Model draft according to
your guideline as follows:
https://tools.ietf.org/html/draft-ietf-i2nsf-consumer-facing-interface-dm-07

I attach a revision letter to explain how I revised this draft according to
your comments.

If you have further comments, please let me know.

Thanks.

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, 6 Nov 2019 11:05:15 +0900

Hi Jan,
I believe that I have addressed your comments on I2NSF Consumer-Facing
Interface Data Model:
https://tools.ietf.org/html/draft-ietf-i2nsf-consumer-facing-interface-dm-07

If you are satisfied with the revision, could you update the Review result
in the following page?
https://datatracker.ietf.org/doc/review-ietf-i2nsf-consumer-facing-interface-dm-05-yangdoctors-lc-lindblad-2019-06-26/

Thanks.

Best Regards,
Paul

On Tue, Nov 5, 2019 at 6:03 PM Mr. Jaehoon Paul Jeong <
[email-masked]> wrote:

> I attach a revision letter to explain how I revised this draft according
> to your comments.
>
>> Thanks for your volunteering to improve our Consumer-Facing Interface
>> YANG Module.
>> 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.
>>