replies inline On Thu, Jul 5, 2018 at 9:36 AM Eric Friedrich (efriedri) <[email protected]> wrote: > > Would the “permissions” field be better titled as “localizationMethods” or > “localizationPolicies"? Permissions typically relates to security and access > control, so it seems a bit out of place here
Yeah, I was kind of thinking along the lines of Android App Permissions and wasn't necessarily proposing that as the field name. Something like you proposed would definitely make more sense. > Also, should we consider adding the fallback list to the allowed localization > methods/policies? > This might allow us to remove the “fallbackToGeo” flag > If a backup list is specified and geo-location is not allowed, that can be > managed through this table rather than the one-off flag "fallbackToGeo" is really "fallbackToClosest" which is to allow TR to go through the entire list of fallbacks before optionally continuing through the rest of the cachegroups ordered by closeness. When False, it prevents going through the rest of the cachegroups and also has the effect of disabling the geo lookup when already localized to that particular cachegroup. However, that would be different than having that cachegroup lack the "geo-enabled" policy. So I think that flag would still be necessary with this "localizationPolicies" feature. > Definitely +1 to keep this extensible, as there will be more localization > types in the future (Anycast, etc,… We at Cisco also have a network hops > localization policy engine too, although its not open-sourced) > > —Eric
