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 protected]> 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 <[email protected]> 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 protected], [email protected] > 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: +82-31-299-4957 Email: [email protected], [email protected] Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php <http://cpslab.skku.edu/people-jaehoon-jeong.php>
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
