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

From: Ori Finkelman <[email-masked]>
Date: Wed, 7 Feb 2018 10:39:37 +0200

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: +972-72-2221647 | Mobile: +972-52-3832189 |
[email-masked]

---

From: "Kevin J. Ma" <[email-masked]>
Date: Wed, 7 Feb 2018 10:01:43 -0500

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 <[email-masked]> wrote:
> 
> Dear Colleagues,
> Regarding the addition of a regular expression match for triggers, mainly for invalidation.
> Does the type of regrexp need to be exchanged via the interface (trigger and capability) ?
> 
>        "regex": "/^(https:\/\/video\.example\.com)\/([a-z])\/([1-7])\/([\/\w \.-]*)*\/?$",    
>        "case-sensitive": true
>     }
> 
>        "regex": "/^(https:\/\/video\.example\.com)\/([a-z])\/([1-7])\/([\/\w \.-]*)*\/?$",    
>        "case-sensitive": true
>        "regrex-type": "pcre"
>     }
> 
> Thanks,
> Ori
> 
> 
> 
> -- 
> Ori Finkelman
> Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | [email-masked]
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni

---

From: Ori Finkelman <[email-masked]>
Date: Wed, 07 Feb 2018 17:41:35 +0000

I also prefer pcre only.

On Wed, Feb 7, 2018, 17:01 Kevin J. Ma <[email-masked]> 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
>

--

---

From: Ori Finkelman <[email-masked]>
Date: Mon, 26 Feb 2018 14:03:56 +0200

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 <[email-masked]> wrote:

>> *Ori Finkelman*Qwilt | Work: +972-72-2221647 <072-222-1647> | Mobile:
>> +972-52-3832189 <052-383-2189> | [email-masked]
>>
> *Ori Finkelman*Qwilt | Work: +972-72-2221647 <072-222-1647> | Mobile:
> +972-52-3832189 <052-383-2189> | [email-masked]
>

--

---

From: "Kevin J. Ma" <[email-masked]>
Date: Tue, 27 Feb 2018 00:53:08 -0500

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 <[email-masked]> wrote:
> 
> Dear all,
> 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.
> 
> 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.
> 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.
> 
> 
>

---

From: Ori Finkelman <[email-masked]>
Date: Tue, 27 Feb 2018 11:23:23 +0200

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 <[email-masked]>
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
>
>>> I would favor triggers matching uri signing, i.e., PCRE only, to
>>> simplify interoperability requirements; unless there's a really good reason

--

---

From: "Kevin J. Ma" <[email-masked]>
Date: Tue, 27 Feb 2018 17:58:28 -0500

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 <[email-masked]> 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 <[email-masked]> wrote:
>> Hi Ori,
>>

---

From: Ori Finkelman <[email-masked]>
Date: Wed, 28 Feb 2018 11:56:23 +0200

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 <[email-masked]>
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
>
>>   (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
>> 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.
>>
>> 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.

--