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

["Mr. Jaehoon Paul Jeong" <[e-mail]>]

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 <
[e-mail]> wrote:

> 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 <[e-mail]> 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: [phone]
> Email: [e-mail], [e-mail]
> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
> <http://cpslab.skku.edu/people-jaehoon-jeong.php>
>


-- 
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: [phone]
Email: [e-mail], [e-mail]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>