With the current implementation of the Policy model it enforces unique names of the Policy assuming that a policy is identical across a corporation's network. In reality this isn't accurate to how network policies can potentially be deployed, where there is a common set of rules for a policy but additional rules based upon some external factor such as Location, Tenant, Platform, or Role. Based upon these external factors I believe we should remove the uniqueness constraint on Policy name and add connections to these external factor objects and base uniqueness on those combinations.
Use Case
We could have a Management Policy for Datacenter Tenant that contains allow tcp 192.168.10.0/24 while the Management Policy for Backbone Tenant would have an allow tcp 172.16.10.0/24. This would also allow a Management Policy for Palo Alto to include a rule for access from Panorama.
Environment
Proposed Functionality
With the current implementation of the Policy model it enforces unique names of the Policy assuming that a policy is identical across a corporation's network. In reality this isn't accurate to how network policies can potentially be deployed, where there is a common set of rules for a policy but additional rules based upon some external factor such as Location, Tenant, Platform, or Role. Based upon these external factors I believe we should remove the uniqueness constraint on Policy name and add connections to these external factor objects and base uniqueness on those combinations.
Use Case
We could have a Management Policy for Datacenter Tenant that contains
allow tcp 192.168.10.0/24while the Management Policy for Backbone Tenant would have anallow tcp 172.16.10.0/24. This would also allow a Management Policy for Palo Alto to include a rule for access from Panorama.