From nobody Sun Dec 2 01:31:17 2018 Return-Path: X-Original-To: cdni@ietf.org Delivered-To: cdni@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B85C7130DDA; Sun, 2 Dec 2018 01:31:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cdni@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cdni@ietf.org Message-ID: <154374306772.7333.13020676879863958633@ietfa.amsl.com> Date: Sun, 02 Dec 2018 01:31:07 -0800 Archived-At: Subject: [CDNi] I-D Action: draft-ietf-cdni-triggers-extensions-01.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2018 09:31:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Content Delivery Networks Interconnection WG of the IETF. Title : CDNI Control Triggers Interface Extensions Authors : Ori Finkelman Sanjay Mishra Filename : draft-ietf-cdni-triggers-extensions-01.txt Pages : 42 Date : 2018-12-02 Abstract: This document updates RFC 8007 to include generic extensions and more granular content matching options, required by the Open Caching architecture. The Open Caching working group of the Streaming Video Alliance is focused on the delegation of video delivery request from commercial CDNs to a caching layer at the ISP. In that aspect, Open Caching is a specific use case of CDNI, where the commercial CDN is the upstream CDN (uCDN) and the ISP caching layer is the downstream CDN (dCDN). The extensions specified in this document to the CDNI Control Interface / Triggers are derived from requirements of Open Caching but are applicable to CDNI use cases in general. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-triggers-extensions/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cdni-triggers-extensions-01 https://datatracker.ietf.org/doc/html/draft-ietf-cdni-triggers-extensions-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-triggers-extensions-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Dec 9 02:06:11 2018 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3153A130F4F for ; Sun, 9 Dec 2018 02:06:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.348 X-Spam-Level: X-Spam-Status: No, score=-3.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_TEMPERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=qwilt-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKY2g9tCtvjg for ; Sun, 9 Dec 2018 02:06:04 -0800 (PST) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34372127332 for ; Sun, 9 Dec 2018 02:06:04 -0800 (PST) Received: by mail-wr1-x42a.google.com with SMTP id j2so7650610wrw.1 for ; Sun, 09 Dec 2018 02:06:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qwilt-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aD3s70//nqv0jdEditHiLYmKlG2XSAd5DI/47b5r6/0=; b=fGbGOuOGRseyDI8hp4lqot1wBGFZP2N3R4m01J/gwJ/KzRxq4uBox511JbipLdTMyU UW9Y914LwF6Ycofw+zDfdDGQXgXQ2OXA9QqLDWqb5fkgwxU/gJsgVComVMakzbqvL3hN zZWWK5jYNSfzskw3HcxQFZij6wxaxgiD9Aw3XUXzJII547J4BJJ/A3W7OyAlRz+JWaPP 8Zc9jZqS/iuI0O6PO2AoPF1WSiIfUWBdjKRfYE7Hc8ZIu/MIsepC1OEGHbrnuB8RCXHr K8IUhOXo1IlSdt6SixPDYsgThC0TXrngml8zc1+2BYewiaRtxA/m78S1hqa8qjwlalzE LHQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aD3s70//nqv0jdEditHiLYmKlG2XSAd5DI/47b5r6/0=; b=KTKuT88ZBrwcU4e32w70SnnDExaCLhBiK2oGOJ2Qgm2ar2+RYHagydIQDgaENgill+ dW9uc7CvOysh0s33W4Mi9wQqB0S2Ov2x9+TPk68KReqhHCLSUjt7y74ZtnKnQaonU69h J25snOfwBuK9UAgGKauGFDZ8pMw2Gk/IXQMfsEn51fBnn4kPEaN7GJTG2s+j9zZd7VT9 UwpB28UA+23LxnY1lc0yWgQobEI2Sq3Kxp/YdOxu7/pJyEMx3W594/OrzF15Km8KtulB xbu9WE9uUi8+rpXa4zF8OjgvCnxTBpOxCDLyPqTz7k9rgLYh4bGDWgEcK+OoeiRBnkGS uWWg== X-Gm-Message-State: AA+aEWY+rUKlnFvNyC5UNWipidL5aqK1nbr7Iv/89NjLJIsu+8D7FeLN CgXo+DEoGf+0vr8HzTmAcSfqIGG42JpYXcKdCu7gJg== X-Google-Smtp-Source: AFSGD/U6Q51HID+bWW4gXzX5U02B0sAyxQZiwsP4ArllgXqHkYqodSi5KQdAiy6fwCLajlyfjVQl6wYT/qWWesmeCKc= X-Received: by 2002:adf:ae1a:: with SMTP id x26mr6321224wrc.0.1544349962274; Sun, 09 Dec 2018 02:06:02 -0800 (PST) MIME-Version: 1.0 References: <1542120839.3452626.1575386224.226D0485@webmail.messagingengine.com> <8CAB349C-A6E5-4BF2-AC48-008B979A8B5B@fastmail.fm> In-Reply-To: From: Ori Finkelman Date: Sun, 9 Dec 2018 12:05:34 +0200 Message-ID: To: aamelnikov@fastmail.fm Cc: Chris Lemmons , "" Content-Type: multipart/alternative; boundary="000000000000e92396057c93fe1f" Archived-At: Subject: Re: [CDNi] Trigger time policy using local time X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2018 10:06:09 -0000 --000000000000e92396057c93fe1f Content-Type: text/plain; charset="UTF-8" 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 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 wrote: > >> Thanks, I will do that. >> Best regards, >> Ori >> >> On Sun, Nov 18, 2018 at 3:18 PM Alexey Melnikov >> wrote: >> >>> Hi, >>> >>> On 15 Nov 2018, at 12:56, Ori Finkelman 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 wrote: >>> >>>> Thanks Alexey, >>>> I will look into it. >>>> >>>> Ori >>>> >>>> On Tue, Nov 13, 2018 at 4:54 PM Alexey Melnikov >>>> 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 >>>>> 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 >>>>> 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 >>>>> 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 >>>>> 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 >>>>> 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 | >>>>> orif@qwilt.com >>>>> > >>>> >>>>> > >>>> >>>>> > >>>> >>>>> > >>>> -- >>>>> > >>>> Ori Finkelman >>>>> > >>>> Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | >>>>> orif@qwilt.com >>>>> > >>> >>>>> > >>> >>>>> > >>> >>>>> > >>> -- >>>>> > >>> Ori Finkelman >>>>> > >>> Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | >>>>> orif@qwilt.com >>>>> > >>> _______________________________________________ >>>>> > >>> CDNi mailing list >>>>> > >>> CDNi@ietf.org >>>>> > >>> https://www.ietf.org/mailman/listinfo/cdni >>>>> > > >>>>> > > >>>>> > > >>>>> > > -- >>>>> > > Ori Finkelman >>>>> > > Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | >>>>> orif@qwilt.com >>>>> > > _______________________________________________ >>>>> > > CDNi mailing list >>>>> > > CDNi@ietf.org >>>>> > > https://www.ietf.org/mailman/listinfo/cdni >>>>> > >>>>> > _______________________________________________ >>>>> > CDNi mailing list >>>>> > CDNi@ietf.org >>>>> > https://www.ietf.org/mailman/listinfo/cdni >>>>> >>>> >>>> >>>> -- >>>> >>>> *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 >>>> | orif@qwilt.com >>>> >>> >>> >>> -- >>> >>> *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 >>> | orif@qwilt.com >>> >>> >> >> -- >> >> *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | >> orif@qwilt.com >> > > > -- > > *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | > orif@qwilt.com > -- *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com --000000000000e92396057c93fe1f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
The time policy as defined in the= latest drafts now have 3, mutually exclusive properties:
1. <= u>unix-time-window: this is a TimeWindow objects as defined in the = metadata=C2=A0https://tools.ietf.org/html/rfc8006#section-4.2.3.2 using unix epoch= .
2. utc-window: this is a new object type UTCWindo= w, using RFC3339 for start and end times. supports any format defined by RF= C3339.
3. local-time-window:=C2= =A0 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 i= s 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 lo= cal time".
The ABNF format is defined in the draft and is ve= ry much like the one specified by RF3339, without the time-offset and witho= ut the leap-second (which is not necessary for this use case).
Thanks,
Ori


On Sun, Nov 25, 2018 at 10:13 AM Or= i Finkelman <orif@qw= ilt.com> wrote:
Got feedback from Chris Newman, the author of RFC3339. This RFC does n= ot have support for non-coordinated local time intentionally, as the purpos= e of this RFC was to created a timestamp which is interoperable, so that di= fferent 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 e= xactly that.
I will therefore follow Alexey's suggestion and = redefine the format in the triggers extension I-D, so that it suits this pu= rpose.

Ori


On Sun, Nov 18, 2018 at 3:32 PM Ori Fink= elman <orif@qwilt.co= m> wrote:
T= hanks, I will do that.
Best regards,
Ori

On Sun, Nov 18, 2018 at 3:18 PM Alex= ey Melnikov <aamelnikov@fastmail.fm> wrote:
Hi,

On 15 Nov 2018, at 12:56, Ori Finkelm= an <orif@qwilt.com> wrote:


Just include in your document. You can cut &a= mp; paste ABNF from RFC 3339 and modify as needed.

Thanks,
Ori
<= div>




<= div>



Thanks Alexe= y,
I will look=C2=A0into it.

Ori
On Tue, Nov 13, 2018 at 4:54 = PM Alexey Melnikov <aamelnikov@fastmail.fm> 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 muc= h 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 suppo= rt for all other optional things in ISO 8601.

Just my 2p.

> Consider something like "local-offset: true", to indicate th= at 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 <orif@qwilt.com> wrote:
> >
> > Hi Phil,
> > Though it may seem so, this is not our case and using it may crea= te confusion.
> > What we need is something that executes in different absolute tim= es in different locations.
> >
> > using the -0000 offset to signify local time.
> > >> This means that the time is actually in UTC (same as +00= 00) 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" whe= re you just don't include an offset:
> > >> This actually means that time is in the local time of th= e caller, which means that if you translate it to UTC you should get the ca= ller time + the correct offset. This is a specific absolute time, not somet= hing 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 m= ean 4AM in local time in NY (i.e. +0500). Using it to designate 4AM dependi= ng 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 addi= ng a flag that says "use in your own local time" may be do it. Bu= t in this case, I would take Chris proposal and use UNIX epoch as it is eas= ier to parse and is already been used in CDNI.
> >
> > Thanks,
> > Ori
> >
> >
> >
> >
> >
> >
> >
> > On Mon, Nov 12, 2018 at 10:15 PM Phil Sorber <sorber@apache.org> wrote:
> >>
> >> What about section 4.3 of RFC3339?
> >>
> >> https://tools.ietf.org/html/rfc3339#sec= tion-4.3
> >>
> >> using the -0000 offset to signify local time.
> >
> > >> This means that the time is actually in UTC (same as +00= 00) 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 th= e caller, which means that if you translate it to UTC you should get the ca= ller time + the correct offset. This is a specific absolute time, not somet= hing that can be interpreted as different UTC in different time zones.
> >>
> >>
> >> https://en.wikipedia.org/w= iki/ISO_8601#Time_zone_designators
> >>
> >> "If no UTC relation information is given with a time rep= resentation, the time is assumed to be in local time."
> >
> >
> > >> This is the same as the above, We can decide that when w= e say "local time" we actually mean the receivers local time rath= er 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://t= ools.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 tha= t the date-time contains no information about the local time zone." > >>
> >> On Mon, Nov 12, 2018 at 5:53 AM Ori Finkelman <orif@qwilt.com> wrote:
> >>>
> >>> Hi,
> >>> In the CDNI meeting we have discussed how to represent lo= cal time at the trigger destination where there are multiple destination lo= cations in different time zones.
> >>>
> >>> Two options raised:
> >>> 1. Follow RFC 3339, and add a new notion for "your l= ocal time"
> >>> For example: 2018-11-12T02:30:00.00L
> >>> should be interpreted as November 12th, 2018, 2:30AM at y= our 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 72= 00 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 re= quire 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 view= s, but would appreciate any input at the mean time.
> >>>
> >>> Thanks,
> >>> Ori
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Mon, Oct 15, 2018 at 12:23 PM Ori Finkelman <orif@qwilt.com> 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 ru= n the trigger at the given time window in there own local time.
> >>>> For example: "I want you to run this trigger bet= ween 3AM-5AM at your own local time".
> >>>>
> >>>> The reasoning is that network resource availability a= nd 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 regi= on.
> >>>> In the past we have proposed to avoid adding this fla= g 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" f= lag, 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 for= mat 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 tim= e".
> >>>> 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 <orif@qwilt.com> wro= te:
> >>>>>
> >>>>> 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 e= ven 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-3= 832189 | orif@qwilt.com=
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Ori Finkelman
> >>>> Qwilt | Work: +972-72-2221647 | Mobile: +972-52-38321= 89 | orif@qwilt.com=
> >>>
> >>>
> >>>
> >>> --
> >>> Ori Finkelman
> >>> Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 |= orif@qwilt.com
> >>> _______________________________________________
> >>> CDNi mailing list
> >>> CDNi@i= etf.org
> >>> https://www.ietf.org/mailman/listinfo/cd= ni
> >
> >
> >
> > --
> > Ori Finkelman
> > Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com
> > _______________________________________________
> > CDNi mailing list
> > CDNi@ietf.org<= /a>
> > https://www.ietf.org/mailman/listinfo/cdni >
> _______________________________________________
> CDNi mailing list
> CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni


--
Ori Finkelman<= br>Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com


--


--
=
Ori Finkelman
Qwilt | Work: +972-72-2221647 | Mo= bile: +972-52-3832189 | orif@qwilt.com


--
Ori Finkelman
Qwilt= | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com


--
Ori Finkelman
Qwilt | Work: +972-72-2221= 647 | Mobile: +972-52-3832189 | orif@qwilt.com
--000000000000e92396057c93fe1f-- From nobody Tue Dec 11 08:28:38 2018 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 510A7130E3C for ; Tue, 11 Dec 2018 08:28:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=vfdoQEvB; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=tJJH6Pjm Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RW8NYyvCPwZ4 for ; Tue, 11 Dec 2018 08:28:33 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9301D130E3D for ; Tue, 11 Dec 2018 08:28:33 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id A70BE21E8D; Tue, 11 Dec 2018 11:28:32 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Tue, 11 Dec 2018 11:28:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:subject:date:references:in-reply-to; s=fm1; bh=lnB /bf3meZEYjJA+KhAryvet2EFNty3mx4u44EjpTY0=; b=vfdoQEvBVRVWD7gTzKE Uc7oRXoS7IiHMMq4i6h2j1cZHS0oeF+9bdVql6K8U9ia8g8/FuxDAX3tmaJwsbLO KDsSEGnYPkjEYvbZuv1Os9Ye9AlpO31ACG6SkFmwdbxxb9F9fDPdFM5NL2WCVI/S pllhKEqFu60t8dsjsfqlF4+ln+zmudrnvJILBihMovqFG1W2N3LoN4/Hm6KQdxAN m7X4hjJQM3KqxMIiQuecXig/IOAEGiUc/vL2I5SBdQMeW2FvJxX7KrKyX1BDFeCS alPDVCq2MaXHI0Phhi6nBXFBF1KzWE3rdP3SuPoxGwDUV2GKQgQGhhQQseSRJ3H8 njg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=lnB/bf3meZEYjJA+KhAryvet2EFNty3mx4u44EjpT Y0=; b=tJJH6PjmR5ztgXfUbFc5w3w8FKYIk6Al59nnlKCW2FOl0vOerQeljQogs aBdMbbsGk44pymNy+hi/zafWB0rcyjqSEk6CUz4IkGE0FT26GIKXTXcc88F0tCxW sm30HzTvqijSGqIsMBOTR4GuMlFpxuadUJ48dz3XKJdwjuOg/FvSc1VprxzmUkPo dRdpOwAraLXxxxW1KCuktJyF8fIa1/uM1SdQEz4jv1VZNWS8SXUPZm2rvMbmPnAR Ra7s3eWOeN/xoIo1Eo7fh0PHEv+lCXFA0pG/9biWAOE9SjLASB8NfVFcstLnN2Eh H7nqhFjFomFz95PearUuwOXzdZ/Qg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtkedrudegjedgkeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefkhffvggfgtg fouffffhgjsegrjeerreertdejnecuhfhrohhmpeetlhgvgigvhicuofgvlhhnihhkohhv uceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfhhmqeenucffohhmrghinhepfi hikhhiphgvughirgdrohhrghdpihgvthhfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhr ohhmpegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmhenucevlhhushhtvghruf hiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 1B0159E149; Tue, 11 Dec 2018 11:28:32 -0500 (EST) Message-Id: <1544545711.234627.1606013984.26F7D4C1@webmail.messagingengine.com> From: Alexey Melnikov To: Ori Finkelman Cc: Chris Lemmons , "" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15445457122346270" X-Mailer: MessagingEngine.com Webmail Interface - ajax-2f590f9a Date: Tue, 11 Dec 2018 16:28:31 +0000 References: <1542120839.3452626.1575386224.226D0485@webmail.messagingengine.com> <8CAB349C-A6E5-4BF2-AC48-008B979A8B5B@fastmail.fm> In-Reply-To: Archived-At: Subject: Re: [CDNi] Trigger time policy using local time X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 16:28:37 -0000 This is a multi-part message in MIME format. --_----------=_15445457122346270 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Hi Ori, On Sun, Dec 9, 2018, at 10:05 AM, Ori Finkelman wrote: > 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).This looks reasonable to me. Thank you, Alexey > > Thanks, > Ori > > > On Sun, Nov 25, 2018 at 10:13 AM Ori Finkelman 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 wrote:>>> Thanks, I will do that. >>> Best regards, >>> Ori >>> >>> On Sun, Nov 18, 2018 at 3:18 PM Alexey Melnikov >>> wrote:>>>> Hi, >>>> >>>> On 15 Nov 2018, at 12:56, Ori Finkelman 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 >>>>> wrote:>>>>>> Thanks Alexey, >>>>>> I will look into it. >>>>>> >>>>>> Ori >>>>>> >>>>>> On Tue, Nov 13, 2018 at 4:54 PM Alexey Melnikov >>>>>> 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 >>>>>>> > 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 >>>>>>> > > 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 >>>>>>> > >> 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 >>>>>>> > >>> 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 >>>>>>> > >>>> 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 >>>>>>> > >>>>> | orif@qwilt.com>>>>>>> > >>>> >>>>>>> > >>>> >>>>>>> > >>>> >>>>>>> > >>>> -- >>>>>>> > >>>> Ori Finkelman >>>>>>> > >>>> Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 >>>>>>> > >>>> | orif@qwilt.com>>>>>>> > >>> >>>>>>> > >>> >>>>>>> > >>> >>>>>>> > >>> -- >>>>>>> > >>> Ori Finkelman >>>>>>> > >>> Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | >>>>>>> > >>> orif@qwilt.com>>>>>>> > >>> _______________________________________________ >>>>>>> > >>> CDNi mailing list >>>>>>> > >>> CDNi@ietf.org >>>>>>> > >>> https://www.ietf.org/mailman/listinfo/cdni >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > -- >>>>>>> > > Ori Finkelman >>>>>>> > > Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | >>>>>>> > > orif@qwilt.com>>>>>>> > > _______________________________________________ >>>>>>> > > CDNi mailing list >>>>>>> > > CDNi@ietf.org >>>>>>> > > https://www.ietf.org/mailman/listinfo/cdni >>>>>>> > >>>>>>> > _______________________________________________ >>>>>>> > CDNi mailing list >>>>>>> > CDNi@ietf.org >>>>>>> > https://www.ietf.org/mailman/listinfo/cdni >>>>>> >>>>>> >>>>>> -- >>>>>> *Ori Finkelman *Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com>>>>> >>>>> >>>>> -- >>>>> *Ori Finkelman *Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com>>> >>> >>> -- >>> *Ori Finkelman *Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com>> >> >> -- >> *Ori Finkelman *Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com> > > -- > *Ori Finkelman *Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com --_----------=_15445457122346270 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Hi Ori,

On Sun, Dec 9, 2018, at 10:05 AM, Ori Finkelman wrote:
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. local-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).
This looks reasonable to me.

Thank you,
Alexey

Thanks,
Ori


On Sun, Nov 25, 2018 at 10:13 AM Ori Finkelman <orif@qwilt.com> 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 <orif@qwilt.com> wrote:
Thanks, I will do that.
Best regards,
Ori

On Sun, Nov 18, 2018 at 3:18 PM Alexey Melnikov <aamelnikov@fastmail.fm> wrote:
Hi,

On 15 Nov 2018, at 12:56, Ori Finkelman <orif@qwilt.com> 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 <orif@qwilt.com> wrote:
Thanks Alexey,
I will look into it.

Ori

On Tue, Nov 13, 2018 at 4:54 PM Alexey Melnikov <aamelnikov@fastmail.fm> 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 <orif@qwilt.com> 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 <sorber@apache.org> wrote:
> >>
> >> What about section 4.3 of RFC3339?
> >>
> >>
> >> 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.
> >>
> >>
> >>
> >> "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 <orif@qwilt.com> 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 <orif@qwilt.com> 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 <orif@qwilt.com> 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 | orif@qwilt.com
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Ori Finkelman
> >>>> Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com
> >>>
> >>>
> >>>
> >>> --
> >>> Ori Finkelman
> >>> Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com
> >>> _______________________________________________
> >>> CDNi mailing list
> >
> >
> >
> > --
> > Ori Finkelman
> > Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com
> > _______________________________________________
> > CDNi mailing list
>
> _______________________________________________
> CDNi mailing list


--
Ori Finkelman
Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com


--
Ori Finkelman
Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com


--
Ori Finkelman
Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com


--
Ori Finkelman
Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com


--
Ori Finkelman
Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com

--_----------=_15445457122346270--