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

[Ori Finkelman <[e-mail]>]

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] | Mobile: [phone] |
[e-mail]