Re: [CDNi] Triggers regexp: draft-finkelman-cdni-sva-extensions-00.txt

["Kevin J. Ma" <[e-mail]>]

I think it is up to the dCDN to interpret local time.  If the uCDN wants to use it's local time, it should specify it in UTC.

The question that caused confusion, iirc, was about trying to predict when a cache in a given region is going to be hit, and I don't think that is a tractable problem.  The idea of saying "preposition X at time Y" is an assumption that Y is the optimal time to preposition X (in the uCDN's opinion).  That assumption is based off an underlying assumption that the primetime load on the dCDN is not at time Y, but there's always going to be exceptions to that.  A cache in LA may serve users in NY (or vice versa) and may not have hit the designated local time yet; it violates the assumption whether we use UTC or localtime, so I don't see it as something for which we should design.

Sent from my iPhone

> On Feb 27, 2018, at 4:23 AM, Ori Finkelman <[e-mail]> wrote:
> 
> Hi Kevin,
> I think the difficulty with local time is the interpretation of what to do with it.
> If it is a generic local time, then whose local time is it ? the uCDN ? the dCDN ? per cache or region ?
> OTHO if it is local time plus time zone, then you need to provide them for each and every geo, so it comes back the original question in my previous mail.
> 
> However, after reiteration this internally, I tend to agree it over complicates things, and for now let's stick with a general time scope, stated in UTC.
> If ever an implementation will really need to have different times for different geos, they will be able to add a new object, for example GeoAndTime object that will state the required time per Geo, but this can be deferred for now.
> 
> Thanks,
> Ori
> 
>> On Tue, Feb 27, 2018 at 7:53 AM, Kevin J. Ma <[e-mail]> wrote:
>> Hi Ori,
>> 
>>   (as an individual) I personally don't see any reason to combine time and geolocation; it over complicates things, imo.  I didn't see a problem with providing a time without timezone to be interpreted as "local time".  I didn't think that being able to send a trigger that said "do this at 1am local time" was a terribly difficult concept - it probably just needs some textual clarification and a more precise definition of how the json should be parsed and interpreted, to remove any UTC vs explicit timezone vs "local time" ambiguity?
>> 
>> thanx.
>> 
>> --  Kevin J. Ma
>> 
>> Sent from my iPhone
>> 
>>> On Feb 26, 2018, at 7:03 AM, Ori Finkelman <[e-mail]> wrote:
>>> 
>>> Dear all,
>>> Another question regarding the trigger extensions.
>>> It was suggested that in order to execute a trigger (for example pre-position) in "local time" of each geography, one should combine the geo location extension with the time window extension.
>>> For example, if pre-position should occur on 3AM local time, it would be set for 11AM UTC for California , and 8AM UTC on New-York
>>> While this works logically, it means that the user needs to state for each relevant geography the UTC time for execution, instead of just stating the required local time and let the dCDN handle it per geography.
>>> 
>>> My question is that given that we add trigger extensions, how would be able to state such multiple cases.
>>> 
>>> Take the above example, I can see two alternatives :
>>> 1. Issue two separate trigger commands, one with Geo = CA, and time = 11AM UTC, and a second command with Geo = NY and time = 8AM UTC.
>>>      while this works, it requires a separate command for each geo.
>>> 
>>> 2. Wrap the extension objects with extension groups, such that each group must be applied together. For example this trigger command will have two extension groups, one with Geo=CA and Time=11AM UTC, and the other with Geo=NY and time=8AM UTC.
>>> 
>>> 
>>> 
>>> I would love to get some feedback on this,
>>> 
>>> 
>>> Thanks,
>>> Ori
>>> 
>>> 
>>> 
>>>> On Wed, Feb 7, 2018 at 7:41 PM, Ori Finkelman <[e-mail]> wrote:
>>>> I also prefer pcre only.
>>>> 
>>>> 
>>>>> On Wed, Feb 7, 2018, 17:01 Kevin J. Ma <[e-mail]> wrote:
>>>>> I would favor triggers matching uri signing, i.e., PCRE only, to simplify interoperability requirements; unless there's a really good reason implementers should have to support multiple standards?
>>>>> 
>>>>> Sent from my iPhone
>>>>> 
>>>>>> On Feb 7, 2018, at 3:39 AM, Ori Finkelman <[e-mail]> wrote:
>>>>>> 
>>>>>> Dear Colleagues,
>>>>>> Regarding the addition of a regular expression match for triggers, mainly for invalidation.
>>>>>> What should be the regexp standard we use, PCRE ? POSIX BRE or ERE ?
>>>>>> Does the type of regrexp need to be exchanged via the interface (trigger and capability) ?
>>>>>> 
>>>>>> Example 1: assuming we support only one specific type of regrex
>>>>>> 
>>>>>>     { 
>>>>>>        "regex": "/^(https:\/\/video\.example\.com)\/([a-z])\/([1-7])\/([\/\w \.-]*)*\/?$",    
>>>>>>        "case-sensitive": true
>>>>>>     }
>>>>>> 
>>>>>> Example 2: assuming regexp type is variable
>>>>>> 
>>>>>>     { 
>>>>>>        "regex": "/^(https:\/\/video\.example\.com)\/([a-z])\/([1-7])\/([\/\w \.-]*)*\/?$",    
>>>>>>        "case-sensitive": true
>>>>>>        "regrex-type": "pcre"
>>>>>>     }
>>>>>> 
>>>>>> Thanks,
>>>>>> Ori
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> -- 
>>>>>> Ori Finkelman
>>>>>> Qwilt | Work: [phone] | Mobile: [phone] | [e-mail]
>>>>> 
>>>>>> _______________________________________________
>>>>>> CDNi mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/cdni
>>>> 
>>>> 
>>>> -- 
>>>> Ori Finkelman
>>>> Qwilt | Work: [phone] | Mobile: [phone] | [e-mail]
>>> 
>>> 
>>> 
>>> -- 
>>> Ori Finkelman
>>> Qwilt | Work: [phone] | Mobile: [phone] | [e-mail]
> 
> 
> 
> -- 
> Ori Finkelman
> Qwilt | Work: [phone] | Mobile: [phone] | [e-mail]