On Sat, Nov 04, 2017 at 10:38:45AM -0700, Sonal Agarwal wrote: > Kristian, > > In response to one of your previous comments: > > "I'm really bothered by the compound key consisting of acl-type > and the acl-name since attachment points then need to reference > both. It's also weird because I don't think choosing the > acl-type is really a choice of the user but more of a limitation > of the platform. > > One approach would be to change the key to only be the acl-name > but let the acl-type leaf remain, perhaps make it mandatory or > default to some unified acl-type. I think it's still possible to > implement a constraint on this, right? Like if a platform only > supports a specific type at some attachment point it can add a > constraint on the acl-type by doing deref() on the leafref." > > The key for an ACL needs to remain as the name and type. They > both uniquely define the presence of the ACL in config.
You can't argue for a design choice by saying "this is how it is". If we change the key to be acl-name only then it is the name that "uniquely define the presence of the ACL in config". What do you perceive as the benefit of having acl-type in the key? Why can't it be an attribute? We can still check, from the attachment point, what the acl-type is. kll -- Kristian Larsson KLL-RIPE +46 72 5479985 k...@spritelink.net _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
