Subject: Re: [CDNi] Trigger time policy using local time

From: Ori Finkelman <[email-masked]>
Date: Sun, 9 Dec 2018 12:05:34 +0200

Hi,
The time policy as defined in the latest drafts now have 3, mutually
exclusive properties:
1. *unix-time-window:* this is a TimeWindow objects as defined in the
metadata https://tools.ietf.org/html/rfc8006#section-4.2.3.2 using unix
epoch.
2. *utc-window*: this is a new object type UTCWindow, using RFC3339 for
start and end times. supports any format defined by RFC3339.
3. l*ocal-time-window:*  this is a new object type LocalTimeWindow. The
start and end properties are using a new format type called DateLocalTime,
defined in this draft.

*DateLocalTime*
This format is similar to the ISO8601 profile specified by RFC3339,
however, it does not have a time offset and MUST be interpreted by the
reader as "in my local time".
The ABNF format is defined in the draft and is very much like the one
specified by RF3339, without the time-offset and without the leap-second
(which is not necessary for this use case).

Thanks,
Ori

On Sun, Nov 25, 2018 at 10:13 AM Ori Finkelman <[email-masked]> wrote:

> Got feedback from Chris Newman, the author of RFC3339. This RFC does not
> have support for non-coordinated local time intentionally, as the purpose
> of this RFC was to created a timestamp which is interoperable, so that
> different systems will interpret it as the same UTC,
> Therefore, we cannot use RFC3339 timestamp as the base for this use case,
> as we want to allow exactly that.
> I will therefore follow Alexey's suggestion and redefine the format in the
> triggers extension I-D, so that it suits this purpose.
>
> Ori
>
>
> On Sun, Nov 18, 2018 at 3:32 PM Ori Finkelman <[email-masked]> wrote:
>
>> Thanks, I will do that.
>> Best regards,
>> Ori
>>
>> On Sun, Nov 18, 2018 at 3:18 PM Alexey Melnikov <[email-masked]>
>> wrote:
>>
>>> Hi,
>>>
>>> On 15 Nov 2018, at 12:56, Ori Finkelman <[email-masked]> wrote:
>>>
>>> Hi,
>>> Looking at ISO8601, local time is simply defined by not adding the
>>> offset (or Z).
>>> For example: 2018-11-12T02:30:00.00
>>> Is interpreted as 2:30AM at the local time.
>>>
>>> RFC 3339 does not support this option as the RFC is focused on
>>> interoperability, and when what you want is to have a deterministic way to
>>> establish an agreement on a specific absolute time, you can either use UTC
>>> or local time with an offset from UTC.
>>>
>>> We can adopt that option for our use case as it is not trying to agree
>>> on an absolute time but rather on the local.
>>>
>>> Is this an acceptable solution?
>>>
>>> If so, how do we standardize it ? as a CDNI time, or as an extension to
>>> RFC 3339 ?
>>>
>>>
>>> Just include in your document. You can cut & paste ABNF from RFC 3339
>>> and modify as needed.
>>>
>>>
>>> Thanks,
>>> Ori
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Nov 14, 2018 at 11:02 AM Ori Finkelman <[email-masked]> wrote:
>>>
>>>> Thanks Alexey,
>>>> I will look into it.
>>>>
>>>> Ori
>>>>
>>>> On Tue, Nov 13, 2018 at 4:54 PM Alexey Melnikov <[email-masked]>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> On Mon, Nov 12, 2018, at 10:46 PM, Chris Lemmons wrote:
>>>>> > Part of the issue with ISO 8601 is that it is a bit annoying to
>>>>> parse.
>>>>> > It allows you to leave out all sorts of things and really defines a
>>>>> > whole bunch of formats. All these formats are "ISO8601":
>>>>> > 2018-11-12T17:38:41+00:00
>>>>> > 2018-W46
>>>>> > 2018-W46-1
>>>>> > --11-12
>>>>> > 2018-316
>>>>> >
>>>>> > And a whole bunch of others. Obviously, most of those leave out some
>>>>> > information that ought to be required. But actually implementing a
>>>>> > full parser for it is a bit tougher than for some other formats.
>>>>>
>>>>> I agree that generic ISO 8601 format is not what you want, that is why
>>>>> RFC 3339 was defined in the first place. RFC 3339 defines a subset which is
>>>>> much easier to parse.
>>>>>
>>>>> You could have a look at ISO 8601 and see how "local timezone" is
>>>>> defined there and just extend RFC 3339 for this case, without adding
>>>>> support for all other optional things in ISO 8601.
>>>>>
>>>>> Just my 2p.
>>>>>
>>>>> > Consider something like "local-offset: true", to indicate that a
>>>>> local
>>>>> > offset should be added to the UTC time specified. This achieves the
>>>>> > effect of executing it in the local time zone.
>>>>> > On Mon, Nov 12, 2018 at 1:42 PM Ori Finkelman <[email-masked]>
>>>>> wrote:
>>>>> > >
>>>>> > > Hi Phil,
>>>>> > > Though it may seem so, this is not our case and using it may
>>>>> create confusion.
>>>>> > > What we need is something that executes in different absolute
>>>>> times in different locations.
>>>>> > >
>>>>> > > using the -0000 offset to signify local time.
>>>>> > > >> This means that the time is actually in UTC (same as +0000) but
>>>>> the time zone was not supposed to be 0, it is just unknown, and is
>>>>> therefore using 0.
>>>>> > >
>>>>> > > Also, it seems that ISO8601 also has a "local time" where you just
>>>>> don't include an offset:
>>>>> > > >> This actually means that time is in the local time of the
>>>>> caller, which means that if you translate it to UTC you should get the
>>>>> caller time + the correct offset. This is a specific absolute time, not
>>>>> something that can be interpreted as different UTC in different time zones.
>>>>> > > We can decide that when we say "local time" we actually mean the
>>>>> receivers local time rather than the callers local time, but then again, if
>>>>> for example the trigger server is located at NY, then 4AM will mean 4AM in
>>>>> local time in NY (i.e. +0500). Using it to designate 4AM depending on where
>>>>> the cache is found is non-standard.
>>>>> > > I was rather hoping we can have something which designate exactly
>>>>> what we mean, but I guess that passing the time with no time-zone and
>>>>> adding a flag that says "use in your own local time" may be do it. But in
>>>>> this case, I would take Chris proposal and use UNIX epoch as it is easier
>>>>> to parse and is already been used in CDNI.
>>>>> > >
>>>>> > > Thanks,
>>>>> > > Ori
>>>>> > >
>>>>> > >
>>>>> > >
>>>>> > >
>>>>> > >
>>>>> > >
>>>>> > >
>>>>> > > On Mon, Nov 12, 2018 at 10:15 PM Phil Sorber <[email-masked]>
>>>>> wrote:
>>>>> > >>
>>>>> > >> What about section 4.3 of RFC3339?
>>>>> > >>
>>>>> > >> https://tools.ietf.org/html/rfc3339#section-4.3
>>>>> > >>
>>>>> > >> using the -0000 offset to signify local time.
>>>>> > >
>>>>> > > >> This means that the time is actually in UTC (same as +0000) but
>>>>> the time zone was not supposed to be 0, it is just unknown, and is
>>>>> therefore using 0.
>>>>> > >>
>>>>> > >>
>>>>> > >> Also, it seems that ISO8601 also has a "local time" where you
>>>>> just don't include an offset:
>>>>> > >
>>>>> > > >> This actually means that time is in the local time of the
>>>>> caller, which means that if you translate it to UTC you should get the
>>>>> caller time + the correct offset. This is a specific absolute time, not
>>>>> something that can be interpreted as different UTC in different time zones.
>>>>> > >>
>>>>> > >>
>>>>> > >> https://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators
>>>>> > >>
>>>>> > >> "If no UTC relation information is given with a time
>>>>> representation, the time is assumed to be in local time."
>>>>> > >
>>>>> > >
>>>>> > > >> This is the same as the above, We can decide that when we say
>>>>> "local time" we actually mean the receivers local time rather than the
>>>>> callers local time, but then again, if for example the trigger server is
>>>>> located at NY, then the 4AM will mean local time in NY. Using it to
>>>>> designate 4AM depending on where the cache is found is non-standard.
>>>>> > >
>>>>> > >
>>>>> > >
>>>>> > >
>>>>> > >>
>>>>> > >>
>>>>> > >> Also in RFC 2822 section 3.3 (
>>>>> https://tools.ietf.org/html/rfc2822#section-3.3):
>>>>> > >>
>>>>> > >> "Though "-0000" also indicates Universal Time, it is used to
>>>>> indicate that the time was generated on a system that may be in a local
>>>>> time zone other than Universal Time and therefore indicates that the
>>>>> date-time contains no information about the local time zone."
>>>>> > >>
>>>>> > >> On Mon, Nov 12, 2018 at 5:53 AM Ori Finkelman <[email-masked]>
>>>>> wrote:
>>>>> > >>>
>>>>> > >>> Hi,
>>>>> > >>> In the CDNI meeting we have discussed how to represent local
>>>>> time at the trigger destination where there are multiple destination
>>>>> locations in different time zones.
>>>>> > >>>
>>>>> > >>> Two options raised:
>>>>> > >>> 1. Follow RFC 3339, and add a new notion for "your local time"
>>>>> > >>> For example: 2018-11-12T02:30:00.00L
>>>>> > >>> should be interpreted as November 12th, 2018, 2:30AM at your own
>>>>> local time.
>>>>> > >>>
>>>>> > >>> 2. Use UTC / UNIX epoch with a local time flag.
>>>>> > >>> For example: 1541989800 For and {"local-time": true} means
>>>>> 2018-11-12T02:30:00.00 but servers MUST interpret that in their own local
>>>>> time.
>>>>> > >>> I.e. servers MUST reduce their time offset from the UNIX epoch
>>>>> before interpreting the time.
>>>>> > >>> For example, a server located at UTC+02:00 must reduce 7200
>>>>> seconds from this eopch, resulting in 1541982600 which is
>>>>> 2018-11-12T02:30:00.00+02:00
>>>>> > >>> If a sever is located at UTC-04:00 it must reduce -14,400
>>>>> seconds epoch, resulting in 1542004200 which is 2018-11-12T02:30:00.00-04:00
>>>>> > >>>
>>>>> > >>> Personally I am in favor of option 2, as option 1 will require
>>>>> changes in time parser and is probably best done by an updated RFC on top
>>>>> of RFC 3339, not sure this use case justifies it.
>>>>> > >>> I will also ping the authors of RFC3339 to get their views, but
>>>>> would appreciate any input at the mean time.
>>>>> > >>>
>>>>> > >>> Thanks,
>>>>> > >>> Ori
>>>>> > >>>
>>>>> > >>>
>>>>> > >>>
>>>>> > >>>
>>>>> > >>>
>>>>> > >>>
>>>>> > >>>
>>>>> > >>>
>>>>> > >>> On Mon, Oct 15, 2018 at 12:23 PM Ori Finkelman <[email-masked]>
>>>>> wrote:
>>>>> > >>>>
>>>>> > >>>> Hi,
>>>>> > >>>> In the last CDNI meeting we have agreed to add to the time
>>>>> policy the local-time flag (see below).
>>>>> > >>>> The required semantics is the instruct the dCDN to run the
>>>>> trigger at the given time window in there own local time.
>>>>> > >>>> For example: "I want you to run this trigger between 3AM-5AM at
>>>>> your own local time".
>>>>> > >>>>
>>>>> > >>>> The reasoning is that network resource availability and prices
>>>>> may vary across the day, and specifically are more available and less
>>>>> expensive at off-peak hours. however off-peak hours are local per region.
>>>>> > >>>> In the past we have proposed to avoid adding this flag by using
>>>>> a combination of location policy and time policy, but that would require
>>>>> calling a separate trigger for each region.
>>>>> > >>>>
>>>>> > >>>> While working on adding this "local-time" flag, I have realized
>>>>> that TimeWindow as defined in
>>>>> https://tools.ietf.org/html/rfc8006#section-4.2.3.2 in UTC and it is
>>>>> better not be used to represent local time.
>>>>> > >>>> The only option I can think of using textual time format as
>>>>> defined in RFC3339, and the local time flag should be interpreted by the
>>>>> dCDN as "you should interpret this as if it in your own local time".
>>>>> > >>>> Using RFC3339 means we need to add a new time object instead of
>>>>> the TimeWindow.
>>>>> > >>>>
>>>>> > >>>> Thoughts ?
>>>>> > >>>>
>>>>> > >>>> Thanks,
>>>>> > >>>> Ori
>>>>> > >>>>
>>>>> > >>>>
>>>>> > >>>> On Sun, Jul 22, 2018 at 9:19 AM Ori Finkelman <[email-masked]>
>>>>> wrote:
>>>>> > >>>>>
>>>>> > >>>>> Here are the comments we got CDNI meeting.
>>>>> > >>>>>
>>>>> > >>>>> Playlist:
>>>>> > >>>>> change abr-protocol to media-protocol, as it may be used for
>>>>> other media rather than video abr.
>>>>> > >>>>>
>>>>> > >>>>> Trigger TimePolicy:
>>>>> > >>>>> Add local-time flag. When true the trigger should be executed
>>>>> at the local time, per zone.
>>>>> > >>>>>
>>>>> > >>>>> Trigger error and warning propagation:
>>>>> > >>>>> Considering triggers may be propagated to a chain of dCDNs,
>>>>> and considering we allow extensions to be safe-to-redistribute even if not
>>>>> understood, we should add a mechanism for propagating errors and warnings
>>>>> back to the uCDN.
>>>>> > >>>>>
>>>>> > >>>>> Thanks,
>>>>> > >>>>> Ori
>>>>> > >>>>>
>>>>> > >>>>> --
>>>>> > >>>>> Ori Finkelman
>>>>> > >>>>> Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 |
>>>>> [email-masked]
>>>>> > >>>>
>>>>> > >>>>
>>>>> > >>>>
>>>>> > >>>> --
>>>>> > >>>> Ori Finkelman
>>>>> > >>>> Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 |
>>>>> [email-masked]
>>>>> > >>>
>>>>> > >>>
>>>>> > >>>
>>>>> > >>> --
>>>>> > >>> 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
>>>>> > >
>>>>> > >
>>>>> > >
>>>>> > > --
>>>>> > > 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
>>>>> >
>>>>> > _______________________________________________
>>>>> > CDNi mailing list
>>>>> > [email-masked]
>>>>> > https://www.ietf.org/mailman/listinfo/cdni
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189
>>>> | [email-masked]
>>>>
>>>
>>>
>>> --
>>>
>>> *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189
>>> | [email-masked]
>>>
>>>
>>
>> --
>>
>> *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 |
>> [email-masked]
>>
>
>
> --
>
> *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 |
> [email-masked]
>

-- 

*Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 |
[email-masked]

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 11 Dec 2018 16:28:31 +0000

Hi Ori,

On Sun, Dec 9, 2018, at 10:05 AM, Ori Finkelman wrote:
> exclusive properties:> 1. *_unix-time-window:_* this is a TimeWindow objects as defined in
>    the metadata https://tools.ietf.org/html/rfc8006#section-4.2.3.2
>    using unix epoch.> 2. *_utc-window_*: this is a new object type UTCWindow, using RFC3339
>    for start and end times. supports any format defined by RFC3339.> 3. l_ocal-time-window:_  this is a new object type LocalTimeWindow.
>    The start and end properties are using a new format type called
>    DateLocalTime, defined in this draft.> 
> *_DateLocalTime_*
> reader as "in my local time".> The ABNF format is defined in the draft and is very much like the one
> specified by RF3339, without the time-offset and without the leap-
> second (which is not necessary for this use case).This looks reasonable to me.

Thank you,
Alexey
> 
> Thanks,
> Ori
> 
> 
> On Sun, Nov 25, 2018 at 10:13 AM Ori Finkelman <[email-masked]> wrote:>> Got feedback from Chris Newman, the author of RFC3339. This RFC does
>> not have support for non-coordinated local time intentionally, as the
>> purpose of this RFC was to created a timestamp which is
>> interoperable, so that different systems will interpret it as the
>> same UTC,>> Therefore, we cannot use RFC3339 timestamp as the base for this use
>> case, as we want to allow exactly that.>> I will therefore follow Alexey's suggestion and redefine the format
>> in the triggers extension I-D, so that it suits this purpose.>> 
>> Ori
>> 
>> 
>> On Sun, Nov 18, 2018 at 3:32 PM Ori Finkelman <[email-masked]> wrote:>>> Thanks, I will do that.
>>> Best regards,
>>> Ori
>>> 
>>> On Sun, Nov 18, 2018 at 3:18 PM Alexey Melnikov
>>> <[email-masked]> wrote:>>>> Hi,
>>>> 
>>>>> offset (or Z).>>>>> For example: 2018-11-12T02:30:00.00
>>>>> interoperability, and when what you want is to have a
>>>>> deterministic way to establish an agreement on a specific absolute
>>>>> time, you can either use UTC or local time with an offset from
>>>>> UTC.>>>>> 
>>>>> We can adopt that option for our use case as it is not trying to
>>>>> agree on an absolute time but rather on the local.>>>>> 
>>>>> If so, how do we standardize it ? as a CDNI time, or as an
>>>>> extension to RFC 3339 ?>>>> 
>>>> Just include in your document. You can cut & paste ABNF from RFC
>>>> 3339 and modify as needed.>>>>> 
>>>>> Thanks,
>>>>> Ori
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On Wed, Nov 14, 2018 at 11:02 AM Ori Finkelman <[email-masked]>
>>>>> wrote:>>>>>> Thanks Alexey,
>>>>>> I will look into it.
>>>>>> 
>>>>>> Ori
>>>>>> 
>>>>>> On Tue, Nov 13, 2018 at 4:54 PM Alexey Melnikov
>>>>>> <[email-masked]> wrote:>>>>>>> Hi,
>>>>>>> 
>>>>>>>  > Part of the issue with ISO 8601 is that it is a bit annoying
>>>>>>>  > to parse.>>>>>>>  > It allows you to leave out all sorts of things and really
>>>>>>>  > defines a>>>>>>>  > whole bunch of formats. All these formats are "ISO8601":
>>>>>>>  > And a whole bunch of others. Obviously, most of those leave
>>>>>>>  > out some>>>>>>>  > information that ought to be required. But actually
>>>>>>>  > implementing a>>>>>>>  > full parser for it is a bit tougher than for some other
>>>>>>>  > formats.>>>>>>> 
>>>>>>>  I agree that generic ISO 8601 format is not what you want, that
>>>>>>>  is why RFC 3339 was defined in the first place. RFC 3339
>>>>>>>  defines a subset which is much easier to parse.>>>>>>> 
>>>>>>>  You could have a look at ISO 8601 and see how "local timezone"
>>>>>>>  is defined there and just extend RFC 3339 for this case,
>>>>>>>  without adding support for all other optional things in ISO
>>>>>>>  8601.>>>>>>> 
>>>>>>>  Just my 2p.
>>>>>>> 
>>>>>>>  > Consider something like "local-offset: true", to indicate
>>>>>>>  > that a local>>>>>>>  > offset should be added to the UTC time specified. This
>>>>>>>  > achieves the>>>>>>>  > effect of executing it in the local time zone.
>>>>>>>  > On Mon, Nov 12, 2018 at 1:42 PM Ori Finkelman
>>>>>>>  > <[email-masked]> wrote:>>>>>>>  > >
>>>>>>>  > > Hi Phil,
>>>>>>>  > > Though it may seem so, this is not our case and using it
>>>>>>>  > > may create confusion.>>>>>>>  > > What we need is something that executes in different
>>>>>>>  > > absolute times in different locations.>>>>>>>  > >
>>>>>>>  > > >> This means that the time is actually in UTC (same as
>>>>>>>  > > >> +0000) but the time zone was not supposed to be 0, it is
>>>>>>>  > > >> just unknown, and is therefore using 0.>>>>>>>  > >
>>>>>>>  > > Also, it seems that ISO8601 also has a "local time" where
>>>>>>>  > > you just don't include an offset:>>>>>>>  > > >> This actually means that time is in the local time of
>>>>>>>  > > >> the caller, which means that if you translate it to UTC
>>>>>>>  > > >> you should get the caller time + the correct offset.
>>>>>>>  > > >> This is a specific absolute time, not something that can
>>>>>>>  > > >> be interpreted as different UTC in different time zones.>>>>>>>  > > We can decide that when we say "local time" we actually
>>>>>>>  > > mean the receivers local time rather than the callers local
>>>>>>>  > > time, but then again, if for example the trigger server is
>>>>>>>  > > located at NY, then 4AM will mean 4AM in local time in NY
>>>>>>>  > > (i.e. +0500). Using it to designate 4AM depending on where
>>>>>>>  > > the cache is found is non-standard.>>>>>>>  > > I was rather hoping we can have something which designate
>>>>>>>  > > exactly what we mean, but I guess that passing the time
>>>>>>>  > > with no time-zone and adding a flag that says "use in your
>>>>>>>  > > own local time" may be do it. But in this case, I would
>>>>>>>  > > take Chris proposal and use UNIX epoch as it is easier to
>>>>>>>  > > parse and is already been used in CDNI.>>>>>>>  > >
>>>>>>>  > > Thanks,
>>>>>>>  > > Ori
>>>>>>>  > >
>>>>>>>  > >
>>>>>>>  > >
>>>>>>>  > >
>>>>>>>  > >
>>>>>>>  > >
>>>>>>>  > >
>>>>>>>  > > On Mon, Nov 12, 2018 at 10:15 PM Phil Sorber
>>>>>>>  > > <[email-masked]> wrote:>>>>>>>  > >>
>>>>>>>  > > >> This means that the time is actually in UTC (same as
>>>>>>>  > > >> +0000) but the time zone was not supposed to be 0, it is
>>>>>>>  > > >> just unknown, and is therefore using 0.>>>>>>>  > >>
>>>>>>>  > >>
>>>>>>>  > >> Also, it seems that ISO8601 also has a "local time" where
>>>>>>>  > >> you just don't include an offset:>>>>>>>  > >
>>>>>>>  > > >> This actually means that time is in the local time of
>>>>>>>  > > >> the caller, which means that if you translate it to UTC
>>>>>>>  > > >> you should get the caller time + the correct offset.
>>>>>>>  > > >> This is a specific absolute time, not something that can
>>>>>>>  > > >> be interpreted as different UTC in different time zones.>>>>>>>  > >>
>>>>>>>  > >>
>>>>>>>  > >> https://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators>>>>>>>  > >>
>>>>>>>  > >> representation, the time is assumed to be in local time.">>>>>>>  > >
>>>>>>>  > >
>>>>>>>  > > >> This is the same as the above, We can decide that when
>>>>>>>  > > >> we say "local time" we actually mean the receivers local
>>>>>>>  > > >> time rather than the callers local time, but then again,
>>>>>>>  > > >> if for example the trigger server is located at NY, then
>>>>>>>  > > >> the 4AM will mean local time in NY. Using it to
>>>>>>>  > > >> designate 4AM depending on where the cache is found is
>>>>>>>  > > >> non-standard.>>>>>>>  > >
>>>>>>>  > >
>>>>>>>  > >
>>>>>>>  > >
>>>>>>>  > >>
>>>>>>>  > >>
>>>>>>>  > >> Also in RFC 2822 section 3.3
>>>>>>>  > >> (https://tools.ietf.org/html/rfc2822#section-3.3):>>>>>>>  > >>
>>>>>>>  > >> "Though "-0000" also indicates Universal Time, it is used
>>>>>>>  > >> to indicate that the time was generated on a system that
>>>>>>>  > >> may be in a local time zone other than Universal Time and
>>>>>>>  > >> therefore indicates that the date-time contains no
>>>>>>>  > >> information about the local time zone.">>>>>>>  > >>
>>>>>>>  > >> On Mon, Nov 12, 2018 at 5:53 AM Ori Finkelman
>>>>>>>  > >> <[email-masked]> wrote:>>>>>>>  > >>>
>>>>>>>  > >>> Hi,
>>>>>>>  > >>> In the CDNI meeting we have discussed how to represent
>>>>>>>  > >>> local time at the trigger destination where there are
>>>>>>>  > >>> multiple destination locations in different time zones.>>>>>>>  > >>>
>>>>>>>  > >>> Two options raised:
>>>>>>>  > >>> 1. Follow RFC 3339, and add a new notion for "your local
>>>>>>>  > >>>    time">>>>>>>  > >>> For example: 2018-11-12T02:30:00.00L
>>>>>>>  > >>> should be interpreted as November 12th, 2018, 2:30AM at
>>>>>>>  > >>> your own local time.>>>>>>>  > >>>
>>>>>>>  > >>> For example: 1541989800 For and {"local-time": true}
>>>>>>>  > >>> means 2018-11-12T02:30:00.00 but servers MUST interpret
>>>>>>>  > >>> that in their own local time.>>>>>>>  > >>> I.e. servers MUST reduce their time offset from the UNIX
>>>>>>>  > >>>      epoch before interpreting the time.>>>>>>>  > >>> For example, a server located at UTC+02:00 must reduce
>>>>>>>  > >>> 7200 seconds from this eopch, resulting in 1541982600
>>>>>>>  > >>> which is 2018-11-12T02:30:00.00+02:00>>>>>>>  > >>> If a sever is located at UTC-04:00 it must reduce -14,400
>>>>>>>  > >>> seconds epoch, resulting in 1542004200 which is 2018-11-12T02:30:00.00-
>>>>>>>  > >>> 04:00>>>>>>>  > >>>
>>>>>>>  > >>> Personally I am in favor of option 2, as option 1 will
>>>>>>>  > >>> require changes in time parser and is probably best done
>>>>>>>  > >>> by an updated RFC on top of RFC 3339, not sure this use
>>>>>>>  > >>> case justifies it.>>>>>>>  > >>> I will also ping the authors of RFC3339 to get their
>>>>>>>  > >>> views, but would appreciate any input at the mean time.>>>>>>>  > >>>
>>>>>>>  > >>> Thanks,
>>>>>>>  > >>> Ori
>>>>>>>  > >>>
>>>>>>>  > >>>
>>>>>>>  > >>>
>>>>>>>  > >>>
>>>>>>>  > >>>
>>>>>>>  > >>>
>>>>>>>  > >>>
>>>>>>>  > >>>
>>>>>>>  > >>> On Mon, Oct 15, 2018 at 12:23 PM Ori Finkelman
>>>>>>>  > >>> <[email-masked]> wrote:>>>>>>>  > >>>>
>>>>>>>  > >>>> Hi,
>>>>>>>  > >>>> In the last CDNI meeting we have agreed to add to the
>>>>>>>  > >>>> time policy the local-time flag (see below).>>>>>>>  > >>>> The required semantics is the instruct the dCDN to run
>>>>>>>  > >>>> the trigger at the given time window in there own local
>>>>>>>  > >>>> time.>>>>>>>  > >>>> For example: "I want you to run this trigger between 3AM-
>>>>>>>  > >>>> 5AM at your own local time".>>>>>>>  > >>>>
>>>>>>>  > >>>> The reasoning is that network resource availability and
>>>>>>>  > >>>> prices may vary across the day, and specifically are
>>>>>>>  > >>>> more available and less expensive at off-peak hours.
>>>>>>>  > >>>> however off-peak hours are local per region.>>>>>>>  > >>>> In the past we have proposed to avoid adding this flag
>>>>>>>  > >>>> by using a combination of location policy and time
>>>>>>>  > >>>> policy, but that would require calling a separate
>>>>>>>  > >>>> trigger for each region.>>>>>>>  > >>>>
>>>>>>>  > >>>> While working on adding this "local-time" flag, I have
>>>>>>>  > >>>> realized that TimeWindow as defined in
>>>>>>>  > >>>> https://tools.ietf.org/html/rfc8006#section-4.2.3.2 in
>>>>>>>  > >>>> UTC and it is better not be used to represent local
>>>>>>>  > >>>> time.>>>>>>>  > >>>> The only option I can think of using textual time format
>>>>>>>  > >>>> as defined in RFC3339, and the local time flag should be
>>>>>>>  > >>>> interpreted by the dCDN as "you should interpret this as
>>>>>>>  > >>>> if it in your own local time".>>>>>>>  > >>>> Using RFC3339 means we need to add a new time object
>>>>>>>  > >>>> instead of the TimeWindow.>>>>>>>  > >>>>
>>>>>>>  > >>>> Thoughts ?
>>>>>>>  > >>>>
>>>>>>>  > >>>> Thanks,
>>>>>>>  > >>>> Ori
>>>>>>>  > >>>>
>>>>>>>  > >>>>
>>>>>>>  > >>>> On Sun, Jul 22, 2018 at 9:19 AM Ori Finkelman
>>>>>>>  > >>>> <[email-masked]> wrote:>>>>>>>  > >>>>>
>>>>>>>  > >>>>> change abr-protocol to media-protocol, as it may be
>>>>>>>  > >>>>> used for other media rather than video abr.>>>>>>>  > >>>>>
>>>>>>>  > >>>>> Trigger TimePolicy:
>>>>>>>  > >>>>> Add local-time flag. When true the trigger should be
>>>>>>>  > >>>>> executed at the local time, per zone.>>>>>>>  > >>>>>
>>>>>>>  > >>>>> Considering triggers may be propagated to a chain of
>>>>>>>  > >>>>> dCDNs, and considering we allow extensions to be safe-to-
>>>>>>>  > >>>>> redistribute even if not understood, we should add a
>>>>>>>  > >>>>> mechanism for propagating errors and warnings back to
>>>>>>>  > >>>>> the uCDN.>>>>>>>  > >>>>>
>>>>>>>  > >>>>> Thanks,
>>>>>>>  > >>>>> Ori
>>>>>>>  > >>>>>
>>>>>>>  > >>>>> --
>>>>>>>  > >>>>> Ori Finkelman
>>>>>>>  > >>>>> Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189
>>>>>>>  > >>>>> | [email-masked]>>>>>>>  > >>>>
>>>>>>>  > >>>>
>>>>>>>  > >>>>
>>>>>>>  > >>>> --
>>>>>>>  > >>>> Ori Finkelman
>>>>>>>  > >>>> Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189
>>>>>>>  > >>>> | [email-masked]>>>>>>>  > >>>
>>>>>>>  > >>>
>>>>>>>  > >>>
>>>>>>>  > >>> --
>>>>>>>  > >>> Ori Finkelman
>>>>>>>  > >>> [email-masked]>>>>>>>  > >>> _______________________________________________
>>>>>>>  > >>> CDNi mailing list
>>>>>>>  > >>> [email-masked]
>>>>>>>  > > [email-masked]>>>>>>>  > > _______________________________________________
>>>>>>>  > > CDNi mailing list
>>>>>>>  > > [email-masked]
>>>>>> *Ori Finkelman
*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 |
[email-masked]>>>>> 
>>>>> *Ori Finkelman
*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 |
[email-masked]>>> 
>>> *Ori Finkelman
*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 |
[email-masked]>> 
>> *Ori Finkelman
*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 |
[email-masked]> 
> *Ori Finkelman
*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 |
[email-masked]