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

[Ori Finkelman <[e-mail]>]

Hi Kevin,
I agree, it seems that what we were trying initially to solve it a very
specific use case and may not be applicable to the general case. Therefore
I am putting it aside for now and will only draft to option to set a time
window in UTC.

Thanks,
Ori

On Wed, Feb 28, 2018 at 12:58 AM, Kevin J. Ma <[e-mail]>
wrote:

> 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] <072-222-1647> | Mobile:
>>>> [phone] <052-383-2189> | [e-mail]
>>>>
>>>> _______________________________________________
>>>> CDNi mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/cdni
>>>>
>>>>
>>>
>>> --
>>>
>>> *Ori Finkelman*Qwilt | Work: [phone] <072-222-1647> | Mobile:
>>> [phone] <052-383-2189> | [e-mail]
>>>
>>
>>
>>
>> --
>>
>> *Ori Finkelman*Qwilt | Work: [phone] <072-222-1647> | Mobile:
>> [phone] <052-383-2189> | [e-mail]
>>
>>
>
>
> --
>
> *Ori Finkelman*Qwilt | Work: [phone] <072-222-1647> | Mobile:
> [phone] <052-383-2189> | [e-mail]
>
>


-- 

*Ori Finkelman*Qwilt | Work: [phone] | Mobile: [phone] |
[e-mail]