From nobody Sat Nov 3 03:15:06 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 12EFB124BAA for ; Sat, 3 Nov 2018 03:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 t5_X_0vUkX22 for ; Sat, 3 Nov 2018 03:15:02 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 631F112008A for ; Sat, 3 Nov 2018 03:15:02 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id y15-v6so4356918wru.9 for ; Sat, 03 Nov 2018 03:15:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=zmoTeuWl1wpUIK7dSrxHNn+Y131WxGMYvE/rdA1jskM=; b=dGVnFNvYA/8GwCQEkt1X3oUyzM93NiNaCcZdhrnKFM1Xqx3o4slep0je+1aSJjjNMs 5bVfFlOA/TeRgfoCl2I7+c3kUfsvEzvKDtDbj4k1umd5ErIXJ9fvD85IR6QsesAl2OOP HnKdpt5/OE//VqdFHoR8nWZbANGg18bLcus9sPLdQRhKTynmAItzywcjLwgYCm8JsM0Z DAG5A4TxSwawUwBkeYSm4u5EMw4i6d5h5swLgp7Jio7sEi4h2mCEPGhGZigyf4yd5Z5q EnWCP7k77jOZWtxb5BU8SYJchpPCHKF8uOOPJ16HUd0Et3z6GlMrO+xCgssNwDtcGDDH hQ9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=zmoTeuWl1wpUIK7dSrxHNn+Y131WxGMYvE/rdA1jskM=; b=aIFVXBv1vEU6FiTAJuVoRR62o0Gl5SqfxBMHBVSnk6Yqt62UUlGlLc342qdjiCrrMr JN8DYPgY+q8rPa7fuwiWkvBEnRdeBUtbRlNX6r0/fDzZQN3kWGJkFIf/inMgn/y9tLrz STFJ2hL9/f7ixRdCZ2CQp9FbbY0owNqNl8N607g5Dz8Wlffkgr/Du8adrYoEMLW6jzqB BTCKMtex/H9APJwnqY3XtbNt075HtKrqzGcYdusk7Mzz0qTkTjdjA0zJH0gNCdEgCTOr Padixq0fpVbGv9AJhwb5LCJqfLCdOORKizsMrlc3EW2tZUqpcYnvMJZ5AIAcy7+SfW4m 3DFw== X-Gm-Message-State: AGRZ1gILD7nmU/2SX8RLf6dw+DMA2LSoU04pakUVG7mrPLfl/fFZR23+ HJrVHf5Ep19V9njZEdLC5IQyVm/OgAh5ktr/9vgXEGuPuqU= X-Google-Smtp-Source: AJdET5f/ZGnPY/68h3gKpM131IuSX4w4Dt9U+eWkKK8fzEuaL+P4YFS5QCeFAZF3vCELajZLcQvN1XHGorY6Wap5T1Y= X-Received: by 2002:adf:94e2:: with SMTP id 89-v6mr12815556wrr.25.1541240100394; Sat, 03 Nov 2018 03:15:00 -0700 (PDT) MIME-Version: 1.0 From: Chris Lemmons Date: Sat, 3 Nov 2018 17:14:49 +0700 Message-ID: To: cdni@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [CDNi] Error Redirect for URI Signing 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: Sat, 03 Nov 2018 10:15:05 -0000 I've got a draft of some potential language for an error handling claim in URI Signing. This came as a result of another attempt at an implementation. The content originator wants to set a custom redirect for when a token is out of date or otherwise invalid so the user agent can go get a new token. There are a number of use cases for it, so I think this might be the simplest solution. I don't like having a separate claim for the error code, but it is quite simple to implement and understand. Thoughts? Link: https://github.com/PSUdaemon/URISigningSpec/pull/56 From nobody Sun Nov 4 11:54:57 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 32CAE1286E3 for ; Sun, 4 Nov 2018 11:54:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 sQXRzvDJeq9S for ; Sun, 4 Nov 2018 11:54:53 -0800 (PST) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 CAB07123FFD for ; Sun, 4 Nov 2018 11:54:52 -0800 (PST) Received: by mail-lj1-x230.google.com with SMTP id z80-v6so6074522ljb.8 for ; Sun, 04 Nov 2018 11:54:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wFRPNxEutJi6AZ/OZExQhIJXEsKQ2yWj0xZgSq2Xbcg=; b=GooD7uxSrgkYm/AFfUB+WTfjUG+ohgwCT8ryynn45QAT1Az4qatx3LddDja2SvjFnk VEtOac7xZcSXcbhBteOis/U18FIH76r6HaLIdciVP2lIYpvROcSDDJ1qX5GR3TyKQtiO Fx+E8Lsii/Av0erxpnaJXlfvU17ZT/n0jOx+4cSXddN8xbvG+GJb85TxMXNmosXJq1b9 kyr5TjjfVPKksHOzeBed4NYxJ4NakPdYGsi0z+oPWQgl9eLBsd48AglZTCJZK1nTijR+ Q78SvHyqF0zUuPO+YcoMKu5r/Pm/m3gG5MZCPQGOsayTNOxT8iTM91lQbNcsg20ecpOP aUTw== 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=wFRPNxEutJi6AZ/OZExQhIJXEsKQ2yWj0xZgSq2Xbcg=; b=TaqRLBVVAFiJ1mz92ebLTnJCnak0/HUz41Bwp/dk/ej5ynisD4oq9MdlAVwbn4p/KZ 2ZdRPvDjZFPjDhLJkLc837incTj8G7weCgQsNJ9XjdZC4ggbRS6BSTQWceERCTKTrU5D DoSBTfq47gb/l0CZkB5wQTM03GTPTOhY3zg7PLV7srI/FNyWenmZGOG0lBkc6LV589/k TXjFvcjr30Gd8txV2zEuoO0OuUACkCYKfR7VuhzVs0Wrx/xDWMQ+UUw15oin8Ma38Yj2 bkOMwhigbkAJ2uSD7ANOUwB/LLwQxchddFfvjiUIPz6HCU3ZeVLkHcj/It7sGCSwINxJ eGtA== X-Gm-Message-State: AGRZ1gJd+i3pMEeY5VVWgXNIkU+1Wl2rvfqSC2d6pXWd6Gm2tix4Vw1g AAQ07v+LANaBZH9PjNY7Uvpf23yQ0LdPQ/Lmyqs= X-Google-Smtp-Source: AJdET5du4+COxygmWweHoRrrKRf5+BfxBKGs7/gu0nKlOw5ioScBAH8Oyp2QJr8oSdx261//ZqyM/d4XmwLsrxxiXw4= X-Received: by 2002:a2e:c52:: with SMTP id o18-v6mr12372431ljd.94.1541361290960; Sun, 04 Nov 2018 11:54:50 -0800 (PST) MIME-Version: 1.0 References: <153719315394.24705.6491759035539281358.idtracker@ietfa.amsl.com> <1721_1537193244_5B9FB51C_1721_61_1_1BD328329726EF4E91AE924BB1B4CB9E631D3295@OPEXCLILMA1.corporate.adroot.infra.ftgroup> In-Reply-To: <1721_1537193244_5B9FB51C_1721_61_1_1BD328329726EF4E91AE924BB1B4CB9E631D3295@OPEXCLILMA1.corporate.adroot.infra.ftgroup> From: Kevin Ma Date: Sun, 4 Nov 2018 14:54:39 -0500 Message-ID: To: Frederic Fieau Cc: "" Content-Type: multipart/alternative; boundary="00000000000037e2760579dc24be" Archived-At: Subject: Re: [CDNi] TR: New Version Notification for draft-fieau-cdni-interfaces-https-delegation-05.txt 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, 04 Nov 2018 19:54:56 -0000 --00000000000037e2760579dc24be Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Frederic, (As and individual) I think the updated draft looks good. A few minor comments: - I would consider hyphenating your property names to make them more readable, e.g., credentials-delegating-entity vs. credentialsdelegatingentity. - I would add a link to Section 5.1 from the periodicity properties - In the json examples, I would remove "AcmeStarDelegationMethod: " and " SubcertsDelegationMethod:" Finally, do you think the ACME STAR and TLS SubCerts drafts should be normative references? thanx. -- Kevin J. Ma On Mon, Sep 17, 2018 at 10:07 AM wrote: > Dear all, > > I just posted a new version of the draft > "draft-fieau-cdni-interfaces-https-delegation-05" extending the current R= FC > 8006 on MetaData Interface to support delegation schemes in CDNI. > > Feel free to comment, > > Regards, > Frederic > > -----Message d'origine----- > De : internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Envoy=C3=A9 : lundi 17 septembre 2018 16:06 > =C3=80 : Sanjay Mishra; STEPHAN Emile IMT/OLN; STEPHAN Emile IMT/OLN; FIE= AU > Fr=C3=A9d=C3=A9ric IMT/OLN > Objet : New Version Notification for > draft-fieau-cdni-interfaces-https-delegation-05.txt > > > A new version of I-D, draft-fieau-cdni-interfaces-https-delegation-05.txt > has been successfully submitted by Frederic Fieau and posted to the > IETF repository. > > Name: draft-fieau-cdni-interfaces-https-delegation > Revision: 05 > Title: CDNI extensions for HTTPS delegation > Document date: 2018-09-17 > Group: Individual Submission > Pages: 10 > URL: > https://www.ietf.org/internet-drafts/draft-fieau-cdni-interfaces-https-de= legation-05.txt > Status: > https://datatracker.ietf.org/doc/draft-fieau-cdni-interfaces-https-delega= tion/ > Htmlized: > https://tools.ietf.org/html/draft-fieau-cdni-interfaces-https-delegation-= 05 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-fieau-cdni-interfaces-https-d= elegation > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-fieau-cdni-interfaces-https-del= egation-05 > > Abstract: > The delivery of content over HTTPS involving multiple CDNs raises > credential management issues. This document proposes extensions in > CDNI Control and Metadata interfaces to setup HTTPS delegation from > an Upstream CDN (uCDN) to a Downstream CDN (dCDN). > > > > > 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. > > The IETF Secretariat > > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > --00000000000037e2760579dc24be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Frederic,

=C2=A0 (As and individual)= I think the updated draft looks good.=C2=A0 A few minor comments:
=C2=A0 - I would consider hyphenating your property names to make them mo= re readable, e.g.,=C2=A0credentials-delegating-entity vs.=C2=A0credentialsdelegatingentity.
=C2=A0 - I would add a li= nk to Section 5.1 from the periodicity properties
=C2=A0 - In the json examples,= I would remove "AcmeStarDelegationMethod: " and "SubcertsDelegationMethod:"
=C2=A0 Finall= y, do you think the ACME STAR and TLS SubCerts drafts should be normative r= eferences?

thanx.

--=C2=A0 Kevin J. Ma


On Mon, Sep 17, 2018 at 10:07 AM <frederic.fieau@orange.com> wrote:
Dear all,

I just posted a new version of the draft "draft-fieau-cdni-interfaces-= https-delegation-05" extending the current RFC 8006 on MetaData Interf= ace to support delegation schemes in CDNI.

Feel free to comment,

Regards,
Frederic

-----Message d'origine-----
De=C2=A0: int= ernet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Envoy=C3=A9=C2=A0: lundi 17 septembre 2018 16:06
=C3=80=C2=A0: Sanjay Mishra; STEPHAN Emile IMT/OLN; STEPHAN Emile IMT/OLN; = FIEAU Fr=C3=A9d=C3=A9ric IMT/OLN
Objet=C2=A0: New Version Notification for draft-fieau-cdni-interfaces-https= -delegation-05.txt


A new version of I-D, draft-fieau-cdni-interfaces-https-delegation-05.txt has been successfully submitted by Frederic Fieau and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-fieau-cdni-interfaces-h= ttps-delegation
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A005
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CDNI extensions for HTTPS delegati= on
Document date:=C2=A0 2018-09-17
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draf= t-fieau-cdni-interfaces-https-delegation-05.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-fieau-cdni-interf= aces-https-delegation/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-fieau-cdni-interfaces-https-d= elegation-05
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-fieau-cdni-in= terfaces-https-delegation
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-fiea= u-cdni-interfaces-https-delegation-05

Abstract:
=C2=A0 =C2=A0The delivery of content over HTTPS involving multiple CDNs rai= ses
=C2=A0 =C2=A0credential management issues.=C2=A0 This document proposes ext= ensions in
=C2=A0 =C2=A0CDNI Control and Metadata interfaces to setup HTTPS delegation= from
=C2=A0 =C2=A0an Upstream CDN (uCDN) to a Downstream CDN (dCDN).




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


___________________________________________________________________________= ______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci.

This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele= te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified.
Thank you.

_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni
--00000000000037e2760579dc24be-- From nobody Mon Nov 5 01:55:36 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 0964C130DC1 for ; Mon, 5 Nov 2018 01:55:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 v8aBHPdxTPv1 for ; Mon, 5 Nov 2018 01:55:31 -0800 (PST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20123.outbound.protection.outlook.com [40.107.2.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0A561274D0 for ; Mon, 5 Nov 2018 01:55:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=k393AcVVh1D/fEPdPGvqbaQDbX643Wa8eBBhiSKgm1M=; b=G8OfgDynj7XPXbZxEXslufZbZnku8lnCBIEgAwC0OGRFwPovb2cEAbyRE2LRhTZHU0W7bf08cmupPqmyD7mLGA6SffrnSFJ+n+H4/qQWwI4iG7fX79a+Vu+GsmG4u3sBD3+ppuYWgWZVDePcStbgpIiFpJBMceFDIlJU3W7o84Q= Received: from AM6PR07MB4930.eurprd07.prod.outlook.com (20.177.119.75) by AM6PR07MB4867.eurprd07.prod.outlook.com (20.177.118.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.14; Mon, 5 Nov 2018 09:55:26 +0000 Received: from AM6PR07MB4930.eurprd07.prod.outlook.com ([fe80::f95b:cf9a:b466:21d3]) by AM6PR07MB4930.eurprd07.prod.outlook.com ([fe80::f95b:cf9a:b466:21d3%3]) with mapi id 15.20.1294.032; Mon, 5 Nov 2018 09:55:26 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge)" To: "sanjay.mishra=40verizon.com@dmarc.ietf.org" CC: Phil Sorber , "" Thread-Topic: [CDNi] [E] draft-fieau-cdni-interfaces-https-delegation call for adoption Thread-Index: AQHUcn2LPcZeB46Qo0qapAwpaaBSt6VA9lUA Date: Mon, 5 Nov 2018 09:55:26 +0000 Message-ID: <20181105095517.GB9742@nokia.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:67c:370:128:3203:16ce:64f4:5b37] user-agent: Mutt/1.10.1 (2018-07-13) x-clientproxiedby: SG2PR06CA0109.apcprd06.prod.outlook.com (2603:1096:1:1d::11) To AM6PR07MB4930.eurprd07.prod.outlook.com (2603:10a6:20b:5e::11) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM6PR07MB4867; 6:w7iSPV7+/OOE8xKcJWuFFM17DLCOMa2DCxb/Cp9HuqffYA3kw1QgTpoK/5muuPMMt/sW3qvLaKP5w8TSoiUDaBE1eUBJn3xK9clWMk/y07FpkZeNJjr/DhNWMq9KvIYT5wyI6oljZCQcmtvkaHktm/q3wuJOycj8Nls461yVRUiJuVnC9mVHuUGV1awot6SsjB/7VFavB4lhhMsncoHhJi5v5fhvI5fzvbG/PqXjOfRrbPd//p08rPJCCnWIS0FLqEQQ3HzQzTDms1LD/IiLJ95/lqK8UvwHPZzh//nX4CmP5V7dpa77E2LXWDGIGuEjZcWwjJM3QyRvqJW2M3REWbN7dGa4QxHeUdp4Gesqaw3PoRirRBSPgIuopr+hsGCB4UA89b4si550yiY4b6tPEJQM9WJxnEaeZ/znPGmt3uMb4+JToVFdkor62xbYLzFN9LFCP+NzBCG7QrPWiCZ0JA==; 5:vJbWC7YuzSHhmclqxWjUPmh+SzfQTq/ArF3cpX6W0ZTcI1/wM2X0NNecoYV+9tskQBeDY+mklaBHoaYCy028db3lljFHi+okkqG6iKB1/bQUbWH9orsWUo6p1RacWGtm8U9bDwcV/nXeyiCoB+gGiOhjtfzd2otBnYLwTOYem48=; 7:LkKjUWMadmDyb1uqOH9AR8dEJnWkyZCSAjgZ35CakjDrF+UZPVKt+xtubgvcoaK2Gatxr2Vcm8B0BLm3GoX7trKWUnMXXr5K0euHpLnAt1s7IwmQAmkZtVqRH39f40xxXVs1CaptysLMcddJ5n7MTw== x-ms-office365-filtering-correlation-id: 638b41e5-4eb2-4aa7-bb2e-08d64304cfc0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:AM6PR07MB4867; x-ms-traffictypediagnostic: AM6PR07MB4867: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231382)(11241501184)(806099)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:AM6PR07MB4867; BCL:0; PCL:0; RULEID:; SRVR:AM6PR07MB4867; x-forefront-prvs: 08476BC6EF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(136003)(376002)(366004)(346002)(39860400002)(199004)(189003)(558084003)(36756003)(81156014)(478600001)(25786009)(81166006)(8676002)(14454004)(4326008)(8936002)(11346002)(2616005)(476003)(446003)(486006)(53936002)(46003)(6246003)(256004)(71190400001)(71200400001)(2900100001)(186003)(97736004)(68736007)(6512007)(1076002)(6346003)(7736002)(6486002)(86362001)(229853002)(6116002)(52116002)(102836004)(316002)(6506007)(386003)(99286004)(76176011)(33656002)(5660300001)(54906003)(6436002)(58126008)(305945005)(105586002)(106356001)(2906002)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM6PR07MB4867; H:AM6PR07MB4930.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:3; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.fossati@nokia.com; x-microsoft-antispam-message-info: IqrUBk0O8Y30f8sbvQzQGOadnFjwrx8hneCqYFnjrYHREMnek1NroMZNLcKLt0nS1X447m2eG93nykztwyUPMZdnpfUSPPVdffqcrwepbLZC8TV0Cvtj3E7CtRneQoZvuBYdBosTGqK8FsoGeZGA70AOMtCiW54J0z79mgdnrXcZ+z7VLxMl9hk7F+rNjeVwmY+/bWzjUMEd0gyblRvfRqMjs3qNvVZpmj+MUshZBXXMEOzhvcbUp135BhDC1pd08ypPYuin7yo4Pa6J6RD33ZcNOQbBDKyU6UoFAeCZXwcK08ZLhoJ6GMhayDm827omvtQqBuYz9tmLm/lyJ+wi+P/I1LB2mZyt9KnWbhSHowk= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <8E96074E4EAAE743874BFC24F1C1BE79@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 638b41e5-4eb2-4aa7-bb2e-08d64304cfc0 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2018 09:55:26.8323 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB4867 Archived-At: Subject: Re: [CDNi] [E] draft-fieau-cdni-interfaces-https-delegation call for adoption 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: Mon, 05 Nov 2018 09:55:33 -0000 VGhlIDEwLzMxLzIwMTggMTM6NTAsIHNhbmpheS5taXNocmE9NDB2ZXJpem9uLmNvbUBkbWFyYy5p ZXRmLm9yZyB3cm90ZToNCj4gSGkgUGhpbCDigJMgSSBzdXBwb3J0IHRoZSBhZG9wdGlvbiBvZiB0 aGlzIGRvY3VtZW50IGFzIGl0IGZvcm1hbGl6ZXMgQ0ROSSBtZXRhZGF0YSBmb3IgdGVjaG5pcXVl cyBwcm9wb3NlZCBpbiBTVEFSIGFuZCBTdWJjZXJ0cyBkZWxlZ2F0aW9uIG1ldGhvZHMuDQoNCisx DQoNCi0tIA0KVGhvbWFzDQo= From nobody Mon Nov 5 23:20:34 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 16C91128CB7 for ; Mon, 5 Nov 2018 23:20:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 NMMyqqaY9DPr for ; Mon, 5 Nov 2018 23:20:25 -0800 (PST) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 64879128A5C for ; Mon, 5 Nov 2018 23:20:25 -0800 (PST) Received: by mail-lj1-x22b.google.com with SMTP id t22-v6so10452189lji.7 for ; Mon, 05 Nov 2018 23:20:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XccsogEpWfHzZFOQG8m15IP1g9EKKNNqf9tRHAnMz10=; b=h2AB7tM8DmUpoxYD+clKLHZkcAQPWIbfxmi7um6D06Mouf+0nIY5iwcRBusrzMJj9m /nPqrOJYwjciMOAzdCZBDzelRXUECn62qY3/kVQCcpz8v7QDGU5ZkYlMZ/3HTc0G8PpH JutXog/1dRUUwZZL6ncMVOJ9rHEXOoeTlxeTXhDvFaABPF7Rvx9xbgbbjpfbQu1VFyhw mcd2fSH24hbhEQ+qZELn7rx8Rg3HbVqU+pYmOozADH7Zin5I3OqbpgbZ2nrFscvfnsza +Ocaz88yJIZI8F1FNXPJvPWuR2UgCOvweLUzBIg2oJeOeTzMMFt2qZFXVopynti6vnql cDzA== 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=XccsogEpWfHzZFOQG8m15IP1g9EKKNNqf9tRHAnMz10=; b=M6BU4nM9B1+dUBBf+Ws+pZxgxD03mOPhlmUtC3hbe54DqSF99dcCHUeCZD+x24YOEL Q1RyQ2+xmVkhaf97dEMXcpKM5xbuFNcPSZvMo381hQpyJNmaI1VCsMBq5f7rQTOiw3rH QnRUqxBCNRLMMq8abs67p8l03nWkBbXVhJ7erZFwVRS77KzE67iHaB6Tvf7Wejr/YdRT xT1MaejtJuf0S+v5XuEpAoJW0jR7+x1lrrEJROHJlJ8zZOB5vPZAqyqRvRCTw8LJQuZb lBzCMlhg1WcllWmD9RzMdnfZdsRdoQfX4xK+4YIvpkoxbwwKp/CiZdMFEam6NYiHefTA VjEA== X-Gm-Message-State: AGRZ1gIuzBzLqEoCwjnm+9A++OLmRW93bSzzRL8GL340hVvZTh519xG9 rizx9g+npB1QQCW/vpCusUWDdbjRJOA+QvouAgTAhgvM X-Google-Smtp-Source: AJdET5fli4s2ntqRR0H/G6jLi4pcjtPIxSeLADf/HzwgsD7mjSSvfx78BQbb0hiz8AA1H8OZF5bE6Pc+3C3kBbVVBq0= X-Received: by 2002:a2e:59ca:: with SMTP id g71-v6mr16365660ljf.79.1541488823651; Mon, 05 Nov 2018 23:20:23 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Kevin Ma Date: Tue, 6 Nov 2018 02:20:12 -0500 Message-ID: To: alficles@gmail.com Cc: "" Content-Type: multipart/alternative; boundary="000000000000c258470579f9d5ee" Archived-At: Subject: Re: [CDNi] Error Redirect for URI Signing 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, 06 Nov 2018 07:20:29 -0000 --000000000000c258470579f9d5ee Content-Type: text/plain; charset="UTF-8" Hi Chris, (As a chair) My initial thoughts on the PR is that it doesn't really address a CDNI issue. What a CSP might want a UA to do when token validation fails is not really in scope of CDNI, and can be handled other ways by the UA (without bloating the token)? (As an individual) The proposed feature seems to make inter-CDN interoperability for URI signing more complex (and that would need to be fleshed out more and reflected in the sequence diagrams in Section 5). I'm not sure that I see the benefit (over letting the client implement 403 handling), without a more concrete use case. thanx. -- Kevin J. Ma On Sat, Nov 3, 2018 at 6:15 AM Chris Lemmons wrote: > I've got a draft of some potential language for an error handling > claim in URI Signing. This came as a result of another attempt at an > implementation. The content originator wants to set a custom redirect > for when a token is out of date or otherwise invalid so the user agent > can go get a new token. > > There are a number of use cases for it, so I think this might be the > simplest solution. I don't like having a separate claim for the error > code, but it is quite simple to implement and understand. > > Thoughts? > > Link: https://github.com/PSUdaemon/URISigningSpec/pull/56 > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > --000000000000c258470579f9d5ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Chris,

=C2=A0 (As a chair) My initia= l thoughts on the PR is that it doesn't really address a CDNI issue.=C2= =A0 What a CSP might want a UA to do when token validation fails is not rea= lly in scope of CDNI, and can be handled other ways by the UA (without bloa= ting the token)?

=C2=A0 (As an individual) The pro= posed feature seems to make inter-CDN interoperability for URI signing more= complex (and that would need to be fleshed out more and reflected in the s= equence diagrams in Section 5).=C2=A0 I'm not sure that I see the benef= it (over letting the client implement 403 handling), without a more concret= e use case.

thanx.

--=C2= =A0 Kevin J. Ma


On Sat, Nov 3, 2018 at 6:15 AM Chris Lemmons <alficles@gmail.com> wrote:
I've got a draft of some potential language f= or an error handling
claim in URI Signing. This came as a result of another attempt at an
implementation. The content originator wants to set a custom redirect
for when a token is out of date or otherwise invalid so the user agent
can go get a new token.

There are a number of use cases for it, so I think this might be the
simplest solution. I don't like having a separate claim for the error code, but it is quite simple to implement and understand.

Thoughts?

Link: https://github.com/PSUdaemon/URISigningSp= ec/pull/56

_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni
--000000000000c258470579f9d5ee-- From nobody Tue Nov 6 02:05:30 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 C722E1277C8 for ; Tue, 6 Nov 2018 02:05:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 R8Y6CdDngJMe for ; Tue, 6 Nov 2018 02:05:20 -0800 (PST) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37559129AB8 for ; Tue, 6 Nov 2018 02:05:18 -0800 (PST) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 42q4t44CGnzFqhs; Tue, 6 Nov 2018 11:05:16 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.31]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 42q4t43Gqcz1xqd; Tue, 6 Nov 2018 11:05:16 +0100 (CET) Received: from OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf]) by OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1%19]) with mapi id 14.03.0415.000; Tue, 6 Nov 2018 11:05:16 +0100 From: To: Kevin Ma CC: "" Thread-Topic: [CDNi] TR: New Version Notification for draft-fieau-cdni-interfaces-https-delegation-05.txt Thread-Index: AQHUTo+NsS9Y2wnFA0ewVrdQiVW886T0gg2ggEvAgICAAIDAsA== Date: Tue, 6 Nov 2018 10:05:15 +0000 Message-ID: <7885_1541498716_5BE1675C_7885_277_1_1BD328329726EF4E91AE924BB1B4CB9E636E5A47@OPEXCLILMA1.corporate.adroot.infra.ftgroup> References: <153719315394.24705.6491759035539281358.idtracker@ietfa.amsl.com> <1721_1537193244_5B9FB51C_1721_61_1_1BD328329726EF4E91AE924BB1B4CB9E631D3295@OPEXCLILMA1.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: multipart/alternative; boundary="_000_1BD328329726EF4E91AE924BB1B4CB9E636E5A47OPEXCLILMA1corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [CDNi] TR: New Version Notification for draft-fieau-cdni-interfaces-https-delegation-05.txt 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, 06 Nov 2018 10:05:29 -0000 --_000_1BD328329726EF4E91AE924BB1B4CB9E636E5A47OPEXCLILMA1corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS2V2aW4sDQoNCknigJltIE9LIHdpdGggbW9zdCBvZiB5b3VyIHJlbWFya3MuDQoNClJlZ2Fy ZGluZyBleGFtcGxlcywgd2h5IGRvIHlvdSB0aGluayB0aGV5IHNob3VsZCBiZSByZW1vdmVkPw0K DQpBQ01FL1NUQVIgYW5kIFN1YkNlcnRzIHNob3VsZCBiZSwgSU1PLCBjb25zaWRlcmVkIGFzIG5v cm1hdGl2ZSByZWZlcmVuY2Ugc2luY2UgcmVhZGluZyB0aG9zZSBkcmFmdHMgZmlyc3QgaXMgYSBu ZWNlc3Nhcnkgc3RlcCB0byB1bmRlcnN0YW5kIGFuZCBjb25maWd1cmUgQ0ROSSBtZXRhZGF0YS4N Cg0KVGh4LA0KRnJlZGVyaWMNCg0KRGUgOiBLZXZpbiBNYSBbbWFpbHRvOmtldmluLmoubWEuaWV0 ZkBnbWFpbC5jb21dDQpFbnZvecOpIDogZGltYW5jaGUgNCBub3ZlbWJyZSAyMDE4IDIwOjU1DQrD gCA6IEZJRUFVIEZyw6lkw6lyaWMgVEdJL09MTg0KQ2MgOiA8Y2RuaUBpZXRmLm9yZz4NCk9iamV0 IDogUmU6IFtDRE5pXSBUUjogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1maWVh dS1jZG5pLWludGVyZmFjZXMtaHR0cHMtZGVsZWdhdGlvbi0wNS50eHQNCg0KSGkgRnJlZGVyaWMs DQoNCiAgKEFzIGFuZCBpbmRpdmlkdWFsKSBJIHRoaW5rIHRoZSB1cGRhdGVkIGRyYWZ0IGxvb2tz IGdvb2QuICBBIGZldyBtaW5vciBjb21tZW50czoNCiAgLSBJIHdvdWxkIGNvbnNpZGVyIGh5cGhl bmF0aW5nIHlvdXIgcHJvcGVydHkgbmFtZXMgdG8gbWFrZSB0aGVtIG1vcmUgcmVhZGFibGUsIGUu Zy4sIGNyZWRlbnRpYWxzLWRlbGVnYXRpbmctZW50aXR5IHZzLiBjcmVkZW50aWFsc2RlbGVnYXRp bmdlbnRpdHkuDQogIC0gSSB3b3VsZCBhZGQgYSBsaW5rIHRvIFNlY3Rpb24gNS4xIGZyb20gdGhl IHBlcmlvZGljaXR5IHByb3BlcnRpZXMNCiAgLSBJbiB0aGUganNvbiBleGFtcGxlcywgSSB3b3Vs ZCByZW1vdmUgIkFjbWVTdGFyRGVsZWdhdGlvbk1ldGhvZDogIiBhbmQgIlN1YmNlcnRzRGVsZWdh dGlvbk1ldGhvZDoiDQogIEZpbmFsbHksIGRvIHlvdSB0aGluayB0aGUgQUNNRSBTVEFSIGFuZCBU TFMgU3ViQ2VydHMgZHJhZnRzIHNob3VsZCBiZSBub3JtYXRpdmUgcmVmZXJlbmNlcz8NCg0KdGhh bnguDQoNCi0tICBLZXZpbiBKLiBNYQ0KDQoNCk9uIE1vbiwgU2VwIDE3LCAyMDE4IGF0IDEwOjA3 IEFNIDxmcmVkZXJpYy5maWVhdUBvcmFuZ2UuY29tPG1haWx0bzpmcmVkZXJpYy5maWVhdUBvcmFu Z2UuY29tPj4gd3JvdGU6DQpEZWFyIGFsbCwNCg0KSSBqdXN0IHBvc3RlZCBhIG5ldyB2ZXJzaW9u IG9mIHRoZSBkcmFmdCAiZHJhZnQtZmllYXUtY2RuaS1pbnRlcmZhY2VzLWh0dHBzLWRlbGVnYXRp b24tMDUiIGV4dGVuZGluZyB0aGUgY3VycmVudCBSRkMgODAwNiBvbiBNZXRhRGF0YSBJbnRlcmZh Y2UgdG8gc3VwcG9ydCBkZWxlZ2F0aW9uIHNjaGVtZXMgaW4gQ0ROSS4NCg0KRmVlbCBmcmVlIHRv IGNvbW1lbnQsDQoNClJlZ2FyZHMsDQpGcmVkZXJpYw0KDQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5l LS0tLS0NCkRlIDogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmc+IFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmc+XQ0KRW52b3nDqSA6IGx1bmRpIDE3IHNlcHRlbWJyZSAyMDE4 IDE2OjA2DQrDgCA6IFNhbmpheSBNaXNocmE7IFNURVBIQU4gRW1pbGUgSU1UL09MTjsgU1RFUEhB TiBFbWlsZSBJTVQvT0xOOyBGSUVBVSBGcsOpZMOpcmljIElNVC9PTE4NCk9iamV0IDogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1maWVhdS1jZG5pLWludGVyZmFjZXMtaHR0cHMt ZGVsZWdhdGlvbi0wNS50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZmllYXUt Y2RuaS1pbnRlcmZhY2VzLWh0dHBzLWRlbGVnYXRpb24tMDUudHh0DQpoYXMgYmVlbiBzdWNjZXNz ZnVsbHkgc3VibWl0dGVkIGJ5IEZyZWRlcmljIEZpZWF1IGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRG IHJlcG9zaXRvcnkuDQoNCk5hbWU6ICAgICAgICAgICBkcmFmdC1maWVhdS1jZG5pLWludGVyZmFj ZXMtaHR0cHMtZGVsZWdhdGlvbg0KUmV2aXNpb246ICAgICAgIDA1DQpUaXRsZTogICAgICAgICAg Q0ROSSBleHRlbnNpb25zIGZvciBIVFRQUyBkZWxlZ2F0aW9uDQpEb2N1bWVudCBkYXRlOiAgMjAx OC0wOS0xNw0KR3JvdXA6ICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6ICAg ICAgICAgIDEwDQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LWZpZWF1LWNkbmktaW50ZXJmYWNlcy1odHRwcy1kZWxlZ2F0aW9uLTA1LnR4 dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWZpZWF1LWNkbmktaW50ZXJmYWNlcy1odHRwcy1kZWxlZ2F0aW9uLw0KSHRtbGl6ZWQ6ICAgICAg IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1maWVhdS1jZG5pLWludGVyZmFjZXMt aHR0cHMtZGVsZWdhdGlvbi0wNQ0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtZmllYXUtY2RuaS1pbnRlcmZhY2VzLWh0dHBzLWRlbGVn YXRpb24NCkRpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9 ZHJhZnQtZmllYXUtY2RuaS1pbnRlcmZhY2VzLWh0dHBzLWRlbGVnYXRpb24tMDUNCg0KQWJzdHJh Y3Q6DQogICBUaGUgZGVsaXZlcnkgb2YgY29udGVudCBvdmVyIEhUVFBTIGludm9sdmluZyBtdWx0 aXBsZSBDRE5zIHJhaXNlcw0KICAgY3JlZGVudGlhbCBtYW5hZ2VtZW50IGlzc3Vlcy4gIFRoaXMg ZG9jdW1lbnQgcHJvcG9zZXMgZXh0ZW5zaW9ucyBpbg0KICAgQ0ROSSBDb250cm9sIGFuZCBNZXRh ZGF0YSBpbnRlcmZhY2VzIHRvIHNldHVwIEhUVFBTIGRlbGVnYXRpb24gZnJvbQ0KICAgYW4gVXBz dHJlYW0gQ0ROICh1Q0ROKSB0byBhIERvd25zdHJlYW0gQ0ROIChkQ0ROKS4NCg0KDQoNCg0KUGxl YXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRp bWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJl IGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmc+Lg0KDQpU aGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGll Y2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGll bGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQpwYXMgZXRyZSBkaWZmdXNl cywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJl Y3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KYSBsJ2V4cGVk aXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1l c3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCk9y YW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0 ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMg YXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3Jt YXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCnRoZXkgc2hvdWxkIG5vdCBiZSBk aXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KSWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQpBcyBlbWFp bHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0 IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQpUaGFuayB5b3UuDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpDRE5pIG1h aWxpbmcgbGlzdA0KQ0ROaUBpZXRmLm9yZzxtYWlsdG86Q0ROaUBpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2RuaQ0KCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2Ug ZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBj b25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRy ZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91 cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgph IGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVz LiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0 aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEg ZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5k IGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBp bmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3Qg YmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVt YWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRo YXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK --_000_1BD328329726EF4E91AE924BB1B4CB9E636E5A47OPEXCLILMA1corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6 bm9ybWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K CW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRlIiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PkhpIEtldmluLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5J4oCZbSBPSyB3aXRoIG1vc3Qgb2YgeW91ciByZW1h cmtzLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5SZWdhcmRpbmcgZXhhbXBsZXMsIHdo eSBkbyB5b3UgdGhpbmsgdGhleSBzaG91bGQgYmUgcmVtb3ZlZD88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPkFDTUUvU1RBUiBhbmQgU3ViQ2VydHMgc2hvdWxkIGJlLCBJTU8sIGNvbnNpZGVy ZWQgYXMgbm9ybWF0aXZlIHJlZmVyZW5jZSBzaW5jZSByZWFkaW5nIHRob3NlIGRyYWZ0cyBmaXJz dCBpcyBhIG5lY2Vzc2FyeSBzdGVwIHRvIHVuZGVyc3RhbmQgYW5kIGNvbmZpZ3VyZQ0KIENETkkg bWV0YWRhdGEuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGh4LDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5GcmVkZXJpYzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEtldmluIE1hIFttYWlsdG86a2V2aW4u ai5tYS5pZXRmQGdtYWlsLmNvbV0NCjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBkaW1hbmNo ZSA0IG5vdmVtYnJlIDIwMTggMjA6NTU8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IEZJRUFVIEZyw6lk w6lyaWMgVEdJL09MTjxicj4NCjxiPkNjJm5ic3A7OjwvYj4gJmx0O2NkbmlAaWV0Zi5vcmcmZ3Q7 PGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogW0NETmldIFRSOiBOZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yIGRyYWZ0LWZpZWF1LWNkbmktaW50ZXJmYWNlcy1odHRwcy1kZWxlZ2F0aW9u LTA1LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEZyZWRlcmlj LDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IChB cyBhbmQgaW5kaXZpZHVhbCkgSSB0aGluayB0aGUgdXBkYXRlZCBkcmFmdCBsb29rcyBnb29kLiZu YnNwOyBBIGZldyBtaW5vciBjb21tZW50czo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAtIEkgd291bGQgY29uc2lkZXIgaHlwaGVuYXRp bmcgeW91ciBwcm9wZXJ0eSBuYW1lcyB0byBtYWtlIHRoZW0gbW9yZSByZWFkYWJsZSwgZS5nLiwm bmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+Y3JlZGVudGlh bHMtZGVsZWdhdGluZy1lbnRpdHkgdnMuJm5ic3A7Y3JlZGVudGlhbHNkZWxlZ2F0aW5nZW50aXR5 Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsgLSBJ IHdvdWxkIGFkZCBhIGxpbmsgdG8gU2VjdGlvbiA1LjEgZnJvbSB0aGUgcGVyaW9kaWNpdHkgcHJv cGVydGllczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4mbmJz cDsgLSBJbiB0aGUganNvbiBleGFtcGxlcywgSSB3b3VsZCByZW1vdmUgJnF1b3Q7QWNtZVN0YXJE ZWxlZ2F0aW9uTWV0aG9kOiAmcXVvdDsgYW5kICZxdW90O1N1YmNlcnRzRGVsZWdhdGlvbk1ldGhv ZDomcXVvdDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+Jm5i c3A7IEZpbmFsbHksIGRvIHlvdSB0aGluayB0aGUgQUNNRSBTVEFSIGFuZCBUTFMgU3ViQ2VydHMg ZHJhZnRzIHNob3VsZCBiZSBub3JtYXRpdmUgcmVmZXJlbmNlcz88L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj50aGFueC48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4tLSZuYnNwOyBLZXZpbiBKLiBNYTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBN b24sIFNlcCAxNywgMjAxOCBhdCAxMDowNyBBTSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZyZWRlcmlj LmZpZWF1QG9yYW5nZS5jb20iPmZyZWRlcmljLmZpZWF1QG9yYW5nZS5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkRlYXIgYWxsLDxicj4NCjxicj4NCkkganVzdCBwb3N0ZWQgYSBuZXcgdmVyc2lvbiBvZiB0 aGUgZHJhZnQgJnF1b3Q7ZHJhZnQtZmllYXUtY2RuaS1pbnRlcmZhY2VzLWh0dHBzLWRlbGVnYXRp b24tMDUmcXVvdDsgZXh0ZW5kaW5nIHRoZSBjdXJyZW50IFJGQyA4MDA2IG9uIE1ldGFEYXRhIElu dGVyZmFjZSB0byBzdXBwb3J0IGRlbGVnYXRpb24gc2NoZW1lcyBpbiBDRE5JLjxicj4NCjxicj4N CkZlZWwgZnJlZSB0byBjb21tZW50LDxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KRnJlZGVyaWM8 YnI+DQo8YnI+DQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS08YnI+DQpEZSZuYnNwOzogPGEg aHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86aW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnPC9hPl0NCjxicj4NCkVudm95w6kmbmJzcDs6IGx1bmRpIDE3IHNlcHRlbWJyZSAyMDE4IDE2 OjA2PGJyPg0Kw4AmbmJzcDs6IFNhbmpheSBNaXNocmE7IFNURVBIQU4gRW1pbGUgSU1UL09MTjsg U1RFUEhBTiBFbWlsZSBJTVQvT0xOOyBGSUVBVSBGcsOpZMOpcmljIElNVC9PTE48YnI+DQpPYmpl dCZuYnNwOzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1maWVhdS1jZG5pLWlu dGVyZmFjZXMtaHR0cHMtZGVsZWdhdGlvbi0wNS50eHQ8YnI+DQo8YnI+DQo8YnI+DQpBIG5ldyB2 ZXJzaW9uIG9mIEktRCwgZHJhZnQtZmllYXUtY2RuaS1pbnRlcmZhY2VzLWh0dHBzLWRlbGVnYXRp b24tMDUudHh0PGJyPg0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBGcmVkZXJp YyBGaWVhdSBhbmQgcG9zdGVkIHRvIHRoZTxicj4NCklFVEYgcmVwb3NpdG9yeS48YnI+DQo8YnI+ DQpOYW1lOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZHJhZnQtZmll YXUtY2RuaS1pbnRlcmZhY2VzLWh0dHBzLWRlbGVnYXRpb248YnI+DQpSZXZpc2lvbjombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDswNTxicj4NClRpdGxlOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgQ0ROSSBleHRlbnNpb25zIGZvciBIVFRQUyBkZWxlZ2F0aW9uPGJyPg0KRG9j dW1lbnQgZGF0ZTombmJzcDsgMjAxOC0wOS0xNzxicj4NCkdyb3VwOiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgSW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJyPg0KUGFnZXM6Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAxMDxicj4NClVSTDombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtZmllYXUtY2RuaS1pbnRlcmZhY2VzLWh0dHBzLWRlbGVnYXRp b24tMDUudHh0IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtZmllYXUtY2RuaS1pbnRlcmZhY2VzLWh0dHBzLWRlbGVnYXRpb24tMDUu dHh0PC9hPjxicj4NClN0YXR1czombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEg aHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmllYXUtY2RuaS1p bnRlcmZhY2VzLWh0dHBzLWRlbGVnYXRpb24vIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmllYXUtY2RuaS1pbnRlcmZhY2VzLWh0dHBzLWRl bGVnYXRpb24vPC9hPjxicj4NCkh0bWxpemVkOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxh IGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1maWVhdS1jZG5pLWludGVy ZmFjZXMtaHR0cHMtZGVsZWdhdGlvbi0wNSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1maWVhdS1jZG5pLWludGVyZmFjZXMtaHR0cHMtZGVsZWdhdGlv bi0wNTwvYT48YnI+DQpIdG1saXplZDombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVm PSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWZpZWF1LWNkbmkt aW50ZXJmYWNlcy1odHRwcy1kZWxlZ2F0aW9uIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1maWVhdS1jZG5pLWludGVyZmFjZXMtaHR0 cHMtZGVsZWdhdGlvbjwvYT48YnI+DQpEaWZmOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRy YWZ0LWZpZWF1LWNkbmktaW50ZXJmYWNlcy1odHRwcy1kZWxlZ2F0aW9uLTA1IiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWZpZWF1LWNkbmkt aW50ZXJmYWNlcy1odHRwcy1kZWxlZ2F0aW9uLTA1PC9hPjxicj4NCjxicj4NCkFic3RyYWN0Ojxi cj4NCiZuYnNwOyAmbmJzcDtUaGUgZGVsaXZlcnkgb2YgY29udGVudCBvdmVyIEhUVFBTIGludm9s dmluZyBtdWx0aXBsZSBDRE5zIHJhaXNlczxicj4NCiZuYnNwOyAmbmJzcDtjcmVkZW50aWFsIG1h bmFnZW1lbnQgaXNzdWVzLiZuYnNwOyBUaGlzIGRvY3VtZW50IHByb3Bvc2VzIGV4dGVuc2lvbnMg aW48YnI+DQombmJzcDsgJm5ic3A7Q0ROSSBDb250cm9sIGFuZCBNZXRhZGF0YSBpbnRlcmZhY2Vz IHRvIHNldHVwIEhUVFBTIGRlbGVnYXRpb24gZnJvbTxicj4NCiZuYnNwOyAmbmJzcDthbiBVcHN0 cmVhbSBDRE4gKHVDRE4pIHRvIGEgRG93bnN0cmVhbSBDRE4gKGRDRE4pLjxicj4NCjxicj4NCjxi cj4NCjxicj4NCjxicj4NClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb248YnI+DQp1bnRpbCB0aGUgaHRtbGl6 ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9Imh0dHA6Ly90b29s cy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KdG9vbHMuaWV0Zi5vcmc8L2E+Ljxicj4NCjxi cj4NClRoZSBJRVRGIFNlY3JldGFyaWF0PGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCjxi cj4NCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVz IGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZl bnQgZG9uYzxicj4NCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMg YXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZl dWlsbGV6IGxlIHNpZ25hbGVyPGJyPg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWlu c2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRh bnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiw8YnI+DQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSBy ZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxz aWZpZS4gTWVyY2kuPGJyPg0KPGJyPg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMg bWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBt YXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8YnI+DQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0 ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi48YnI+DQpJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg YW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy48YnI+DQpBcyBlbWFp bHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0 IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuPGJyPg0KVGhhbmsgeW91 Ljxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KQ0ROaSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86Q0ROaUBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPkNETmlAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jZG5pIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jZG5pPC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxQUkU+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVz c2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRp b25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBh cyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBT aSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25h bGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpv aW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2Fs dGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3Nh Z2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2Fn ZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxl Z2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxk IG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9u LgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5 IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4K QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2Fn ZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5 b3UuCjwvUFJFPjwvYm9keT4NCjwvaHRtbD4NCg== --_000_1BD328329726EF4E91AE924BB1B4CB9E636E5A47OPEXCLILMA1corp_-- From nobody Tue Nov 6 02:07:09 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 A1179130DFF for ; Tue, 6 Nov 2018 02:07:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=technicolor.onmicrosoft.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 lw1-KZGxfwr5 for ; Tue, 6 Nov 2018 02:07:05 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-eopbgr810110.outbound.protection.outlook.com [40.107.81.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A07A6129AB8 for ; Tue, 6 Nov 2018 02:07:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=technicolor.onmicrosoft.com; s=selector1-technicolor-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=au7dDTCVOI4pAfMgDAKMhqdHXhcj5mgBD8JA3RyLKhE=; b=JjK430xTshGRVsrSmtRjxx45D3uj94L6nKw9906bnnn6jwqEbNQ2v22R+ggd5OybgWfDhk2y68k4sNC8oW57Polhgg/BkLqvyh/hBdF45+dK6T4sVQqRcELeCZwGtMd7o8iLqnLzc1B9WxbiNvvcAkkJIzAS0xVQ0XYmej9TRMI= Received: from BLUPR02MB1122.namprd02.prod.outlook.com (10.163.79.148) by BLUPR02MB193.namprd02.prod.outlook.com (10.242.189.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.1294.30; Tue, 6 Nov 2018 10:06:58 +0000 Received: from BLUPR02MB1122.namprd02.prod.outlook.com ([fe80::3ca9:9f39:52a5:a9b4]) by BLUPR02MB1122.namprd02.prod.outlook.com ([fe80::3ca9:9f39:52a5:a9b4%6]) with mapi id 15.20.1294.032; Tue, 6 Nov 2018 10:06:58 +0000 From: "Taibi Charline (Guguen)" To: "CDNi@ietf.org" Thread-Topic: unsubscribe Thread-Index: AdR1uHK3EMpcum4pR6qOdteTx6W/eQ== Date: Tue, 6 Nov 2018 10:06:57 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Charline.Taibi@technicolor.com; x-originating-ip: [165.225.76.165] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR02MB193; 20:XvZLH9W25W4YtNzEY5uvYQbhk56m0Aazqu7IclZ1DdLvktNdyqSMy4X6tCjeJtUV7MoGFuAnGRKREr/oVWhnG7Xq+5cbWs2ILFMlTL95Rk4sQxgmrJBrefJiTXHmKgtun1A410kpk3TXVSCkzYyVe7PPs5uQEZ4zZxY1y6BQdv4= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: e291fc6b-8ca2-47e9-9668-08d643cf967c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BLUPR02MB193; x-ms-traffictypediagnostic: BLUPR02MB193: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155)(28532068793085)(190501279198761)(227612066756510); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231382)(944501410)(52105095)(93006095)(93001095)(3002001)(10201501046)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123562045)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:BLUPR02MB193; BCL:0; PCL:0; RULEID:; SRVR:BLUPR02MB193; x-forefront-prvs: 0848C1A6AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(376002)(396003)(136003)(346002)(189003)(199004)(221733001)(99286004)(33656002)(8936002)(74316002)(25786009)(14454004)(316002)(7736002)(14444005)(256004)(66066001)(68736007)(2906002)(54896002)(6306002)(55016002)(9686003)(53936002)(7696005)(790700001)(6116002)(3846002)(72206003)(6506007)(3480700004)(5640700003)(6436002)(102836004)(55236004)(86362001)(26005)(476003)(106356001)(105586002)(6916009)(71190400001)(97736004)(71200400001)(81156014)(81166006)(8676002)(2351001)(2501003)(478600001)(2900100001)(486006)(186003)(7116003)(5660300001)(166393002)(220243001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR02MB193; H:BLUPR02MB1122.namprd02.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: technicolor.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: M+N+y9/7/PeJ77+Y8OEpdyNtHF88MBHSEDjNqup863Na08j5V9yc8eSFyTAF+Y0O/Gaqyz+h/IrfXlhFv43USw/DHo6jLvs+GJZ+XZB95FUZH44cg6tZKbC9RzsyqWkBivL7SC5S+uNcHIwoTE5qOwmwvUZW0f9nFNXSrCgx5cr25QappwPzRFnkr3TAnh5Qclo71iRmvXuNVnWFoHMeyo1ubyMFwOsTPLq4ISdySLMfdWtbT5k0okXkqE8QMusCojA3CA7ONvWp+37U1YXfzdrfadvC4/0eV2qdpKb6xIaGbqwTCsb4GpMyXh6yGdf9N8p1Pc8bnwfxllOKGzzYMAZUJhSbUCzAuo5SED7nt/U= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR02MB112237A397B8A5B57A0B49B89ACB0BLUPR02MB1122namp_" MIME-Version: 1.0 X-OriginatorOrg: technicolor.com X-MS-Exchange-CrossTenant-Network-Message-Id: e291fc6b-8ca2-47e9-9668-08d643cf967c X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2018 10:06:57.9511 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 036da35c-ba43-4e4a-9bff-72ec0f508621 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR02MB193 Archived-At: Subject: [CDNi] unsubscribe 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, 06 Nov 2018 10:07:08 -0000 --_000_BLUPR02MB112237A397B8A5B57A0B49B89ACB0BLUPR02MB1122namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This e-mail and any files transmitted with it are confidential and are inte= nded solely for the use of the individual or entity to whom they are addres= sed. Unless you are the intended addressee (or authorized to receive for s= uch intended addressee), you are not allowed to use, copy or disclose to a= nyone the message or any information contained in the message. If you have = received the message in error, please advise the sender by reply e-mail @Te= chnicolor.com and delete the message. Thank you. --_000_BLUPR02MB112237A397B8A5B57A0B49B89ACB0BLUPR02MB1122namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

This e-mail and any files transmitted with it = are confidential and are intended solely for the use of the individual or e= ntity to whom they are addressed.  Unless you are the intended addressee (or authorized to receive for such intended=  addressee), you are not allowed to use, copy or disclose to anyone t= he message or any information contained in the message. If you have receive= d the message in error, please advise the sender by reply e-mail @Technicolor.com and delete the message. Thank = you.  

 

--_000_BLUPR02MB112237A397B8A5B57A0B49B89ACB0BLUPR02MB1122namp_-- From nobody Tue Nov 6 12:11:22 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 5532212785F for ; Tue, 6 Nov 2018 12:11:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 mnnR_2U3xNFC for ; Tue, 6 Nov 2018 12:11:18 -0800 (PST) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 744A5124408 for ; Tue, 6 Nov 2018 12:11:17 -0800 (PST) Received: by mail-lf1-x133.google.com with SMTP id h192so9839375lfg.3 for ; Tue, 06 Nov 2018 12:11:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pyIViBizpiFxOUTBQXnxJLQ8ByHd005+W531HQiiU2k=; b=XvFa9/Y+v/SlZ8FAL+lJzsKZcOV1cOr4ap4RsI5rjyxPgFNIrGWlX7zJ/Yei4xmYzV 0rgrkcoWTr1betCSMXlwsSUPkOuZXNUcq7n4rEke/SPil8I/rHCp3xoima3LAfCkGYPr 84iZIOXxmCRzjONIALRW/6ztyeWqiqnm3UFX3FntPPJVf064LryMxfOnPBpPooU2V4lJ MhE99p3xg7V/+0sMcGnYQUi5L6e75IVSy1aP3AJ5DXgeGipZaaUkBqmV/q5jqW6qFywU T/tzYe82E/5xF2O6kb9dq9YdzTwpX44AvIMCcstRjpogtSjZV5Q+siNjOlqPoQBZwp8K mOrw== 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=pyIViBizpiFxOUTBQXnxJLQ8ByHd005+W531HQiiU2k=; b=gPBdGHlG3+BJQyNIVXKnXtxtCh06rFg8BZ6j0D9DHkirIgQgl9HYnM4of3FpJOo6G5 llauOVmOWmzhxVHAY+CLb+5Mbu9t/QLaCBpsCH8+HgfI0Sq3WYJyl/BxnVOY5eGThaYc iAdoxchXhnMecO24GmojTm/HEs4Kb7/gaF8oz8tcA2SEG0Km3xgCIf0zZFeFcVql9mun tnhC3bdBWp/Id4YpNefgPn96MFAJ0m1ZSxQ8wYa9sk795eSHRAeZM3mZz+ttu0X6bv2/ hmFy0cINBS/hw+Xb837H2fO84IG621w3KvNvenTG++xoEosTPywEZxmAUawtjONJU7FO HBHg== X-Gm-Message-State: AGRZ1gL0gtiVmlZ4YNax0r+O6wPhJOLtNVBsSeYcdkKduaPcMMqiawZz 2xjsAPwuCcsFOxHHy9zGShwKCcf7sz+6Y4j8kME= X-Google-Smtp-Source: AJdET5eKthVY/yLlIWJKWn2QJRnpGW4TpWbPWvV/qVaLK371QK0c88TzcMqfghGqaDb9hPDx9ys/l+EWcv0Witjro7U= X-Received: by 2002:a19:660a:: with SMTP id a10-v6mr12979487lfc.100.1541535075609; Tue, 06 Nov 2018 12:11:15 -0800 (PST) MIME-Version: 1.0 References: <153719315394.24705.6491759035539281358.idtracker@ietfa.amsl.com> <1721_1537193244_5B9FB51C_1721_61_1_1BD328329726EF4E91AE924BB1B4CB9E631D3295@OPEXCLILMA1.corporate.adroot.infra.ftgroup> <7885_1541498716_5BE1675C_7885_277_1_1BD328329726EF4E91AE924BB1B4CB9E636E5A47@OPEXCLILMA1.corporate.adroot.infra.ftgroup> In-Reply-To: <7885_1541498716_5BE1675C_7885_277_1_1BD328329726EF4E91AE924BB1B4CB9E636E5A47@OPEXCLILMA1.corporate.adroot.infra.ftgroup> From: Kevin Ma Date: Tue, 6 Nov 2018 15:11:03 -0500 Message-ID: To: Frederic Fieau Cc: "" Content-Type: multipart/alternative; boundary="000000000000973356057a049ac1" Archived-At: Subject: Re: [CDNi] TR: New Version Notification for draft-fieau-cdni-interfaces-https-delegation-05.txt 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, 06 Nov 2018 20:11:21 -0000 --000000000000973356057a049ac1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Frederic, For the examples, those tags make that block of text invalid json. If those are meant to be titles for the json examples, I don't think they are necessary since the subject and the metadata type cover that; and even if you want them, placing them in front of the curly brace makes it very confusing to read, imo. Looking at the PathMatch and PathMetadata examples, at least those are not on the same line as the curly brace. I agree that those specs should be normative references; but they are currently listed as informative. I would update that. thanx. -- Kevin J. Ma On Tue, Nov 6, 2018 at 5:05 AM wrote: > Hi Kevin, > > > > I=E2=80=99m OK with most of your remarks. > > > > Regarding examples, why do you think they should be removed? > > > > ACME/STAR and SubCerts should be, IMO, considered as normative reference > since reading those drafts first is a necessary step to understand and > configure CDNI metadata. > > > > Thx, > > Frederic > > > > *De :* Kevin Ma [mailto:kevin.j.ma.ietf@gmail.com] > *Envoy=C3=A9 :* dimanche 4 novembre 2018 20:55 > *=C3=80 :* FIEAU Fr=C3=A9d=C3=A9ric TGI/OLN > *Cc :* > *Objet :* Re: [CDNi] TR: New Version Notification for > draft-fieau-cdni-interfaces-https-delegation-05.txt > > > > Hi Frederic, > > > > (As and individual) I think the updated draft looks good. A few minor > comments: > > - I would consider hyphenating your property names to make them more > readable, e.g., credentials-delegating-entity > vs. credentialsdelegatingentity. > > - I would add a link to Section 5.1 from the periodicity properties > > - In the json examples, I would remove "AcmeStarDelegationMethod: " and > "SubcertsDelegationMethod:" > > Finally, do you think the ACME STAR and TLS SubCerts drafts should be > normative references? > > > > thanx. > > > > -- Kevin J. Ma > > > > > > On Mon, Sep 17, 2018 at 10:07 AM wrote: > > Dear all, > > I just posted a new version of the draft > "draft-fieau-cdni-interfaces-https-delegation-05" extending the current R= FC > 8006 on MetaData Interface to support delegation schemes in CDNI. > > Feel free to comment, > > Regards, > Frederic > > -----Message d'origine----- > De : internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Envoy=C3=A9 : lundi 17 septembre 2018 16:06 > =C3=80 : Sanjay Mishra; STEPHAN Emile IMT/OLN; STEPHAN Emile IMT/OLN; FIE= AU > Fr=C3=A9d=C3=A9ric IMT/OLN > Objet : New Version Notification for > draft-fieau-cdni-interfaces-https-delegation-05.txt > > > A new version of I-D, draft-fieau-cdni-interfaces-https-delegation-05.txt > has been successfully submitted by Frederic Fieau and posted to the > IETF repository. > > Name: draft-fieau-cdni-interfaces-https-delegation > Revision: 05 > Title: CDNI extensions for HTTPS delegation > Document date: 2018-09-17 > Group: Individual Submission > Pages: 10 > URL: > https://www.ietf.org/internet-drafts/draft-fieau-cdni-interfaces-https-de= legation-05.txt > Status: > https://datatracker.ietf.org/doc/draft-fieau-cdni-interfaces-https-delega= tion/ > Htmlized: > https://tools.ietf.org/html/draft-fieau-cdni-interfaces-https-delegation-= 05 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-fieau-cdni-interfaces-https-d= elegation > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-fieau-cdni-interfaces-https-del= egation-05 > > Abstract: > The delivery of content over HTTPS involving multiple CDNs raises > credential management issues. This document proposes extensions in > CDNI Control and Metadata interfaces to setup HTTPS delegation from > an Upstream CDN (uCDN) to a Downstream CDN (dCDN). > > > > > 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. > > The IETF Secretariat > > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > --000000000000973356057a049ac1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Frederic,

=C2=A0 For the examples, t= hose tags make that block of text invalid json.=C2=A0 If those are meant to= be titles for the json examples, I don't think they are necessary sinc= e the subject and the metadata type cover that; and even if you want them, = placing them in front of the curly brace makes it very confusing to read, i= mo.=C2=A0 Looking at the PathMatch and PathMetadata examples, at least thos= e are not on the same line as the curly brace.

=C2= =A0 I agree that those specs should be normative references; but they are c= urrently listed as informative.=C2=A0 I would update that.

thanx.

--=C2=A0 Kevin J. Ma
On Tue, Nov 6, 2018 at 5:05 A= M <frederic.fieau@orange.co= m> wrote:

Hi Kevin,

=C2=A0

I=E2=80=99m OK= with most of your remarks.

=C2=A0<= u>

Regarding exam= ples, why do you think they should be removed?

=C2=A0<= u>

ACME/STAR and = SubCerts should be, IMO, considered as normative reference since reading th= ose drafts first is a necessary step to understand and configure CDNI metadata.

=C2=A0<= u>

Thx,=

Frederic

=C2=A0<= u>

De=C2=A0: Kevi= n Ma [mailto:kevin.j.ma.ietf@gmail.com]
Envoy=C3=A9=C2=A0: dimanche 4 novembre 2018 20:55
=C3=80=C2=A0: FIEAU Fr=C3=A9d=C3=A9ric TGI/OLN
Cc=C2=A0: <cdn= i@ietf.org>
Objet=C2=A0: Re: [CDNi] TR: New Version Notification for draft-fieau= -cdni-interfaces-https-delegation-05.txt

=C2=A0

Hi Frederic,

=C2=A0

=C2=A0 (As and individual) I think the updated draft= looks good.=C2=A0 A few minor comments:

=C2=A0 - I would consider hyphenating your property = names to make them more readable, e.g.,=C2=A0credentials-delegating-entity vs.=C2=A0credentialsdelegating= entity.

=C2=A0 = - I would add a link to Section 5.1 from the periodicity properties<= u>

=C2=A0 = - In the json examples, I would remove "AcmeStarDelegationMethod: &quo= t; and "SubcertsDelegationMethod:"

=C2=A0 = Finally, do you think the ACME STAR and TLS SubCerts drafts should be norma= tive references?

=C2=A0

thanx.<= /span>

=C2=A0

--=C2= =A0 Kevin J. Ma

=C2=A0

=C2=A0

On Mon, Sep 17, 2018 at 10:07 AM <frederic.fieau@orange.com> wrote:

Dear all,

I just posted a new version of the draft "draft-fieau-cdni-interfaces-= https-delegation-05" extending the current RFC 8006 on MetaData Interf= ace to support delegation schemes in CDNI.

Feel free to comment,

Regards,
Frederic

-----Message d'origine-----
De=C2=A0: int= ernet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Envoy=C3=A9=C2=A0: lundi 17 septembre 2018 16:06
=C3=80=C2=A0: Sanjay Mishra; STEPHAN Emile IMT/OLN; STEPHAN Emile IMT/OLN; = FIEAU Fr=C3=A9d=C3=A9ric IMT/OLN
Objet=C2=A0: New Version Notification for draft-fieau-cdni-interfaces-https= -delegation-05.txt


A new version of I-D, draft-fieau-cdni-interfaces-https-delegation-05.txt has been successfully submitted by Frederic Fieau and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-fieau-cdni-interfaces-h= ttps-delegation
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A005
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CDNI extensions for HTTPS delegati= on
Document date:=C2=A0 2018-09-17
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-fieau-cdni-interfaces-https-dele= gation-05.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= https://datatracker.ietf.org/doc/draft-fieau-cdni-interfaces-https-delegati= on/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://= tools.ietf.org/html/draft-fieau-cdni-interfaces-https-delegation-05
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0h= ttps://datatracker.ietf.org/doc/html/draft-fieau-cdni-interfaces-https-dele= gation
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-fieau-cdni-interfaces= -https-delegation-05

Abstract:
=C2=A0 =C2=A0The delivery of content over HTTPS involving multiple CDNs rai= ses
=C2=A0 =C2=A0credential management issues.=C2=A0 This document proposes ext= ensions in
=C2=A0 =C2=A0CDNI Control and Metadata interfaces to setup HTTPS delegation= from
=C2=A0 =C2=A0an Upstream CDN (uCDN) to a Downstream CDN (dCDN).




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


___________________________________________________________________________= ______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci.

This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele= te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified.
Thank you.

_______________________________________________
CDNi mailing list
CDNi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/cdni

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message=
s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--000000000000973356057a049ac1-- From nobody Sat Nov 10 21:39:41 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 F35B612D4EA for ; Sat, 10 Nov 2018 21:39:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 T_OIC-EUMd2U for ; Sat, 10 Nov 2018 21:39:38 -0800 (PST) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 29D8F12D4E8 for ; Sat, 10 Nov 2018 21:39:38 -0800 (PST) Received: by mail-lf1-x136.google.com with SMTP id v5so4007537lfe.7 for ; Sat, 10 Nov 2018 21:39:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=JjtV0/qwYnfo8KNJqBwWh/SHNY750yLPclz45PXGsQQ=; b=H/pQjVZOXcEwEHvapoRm03gB2uHkMqf6W8R6TZHw0O4WNiypncAsm51Ekml/w4lieC cagRGwwGtHcEprg+ZEUIX+hEgQ0qcrMA91BPfxvKHi8VNhLGz/m/t9LefP3ma4ex/Szr Qo/ZmDQQmBpjv+ASPK/fe96oY169N+hZoUco4HTz+do4rq1whAE1FSHDXI2SlV3fCNzK OjXj6XGa556LTqIBFpjY9Dcfi60wFQHSb4kL+Jo5ov+UySrOovXOTfao6MnQYuzi7RZ9 wUfB0K6pjm6fe9c+C5wWAPSD/YbkXoPG3rs0RGwHpVbUGZtRX5PlT1gMre0gBq6uphz0 ME+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=JjtV0/qwYnfo8KNJqBwWh/SHNY750yLPclz45PXGsQQ=; b=ncjymcgmXJ/SdMuFNxItEBdd4RdZY2a0I+fliGCauUausiEd/heAPGZbFNTBtr5OZa ac4eWawEIG5KMubPYADrYhzXEXJW0VN2/fTVlKv18119p2sJZPXqKtXOs51rSlAE1zQP dAEOebGN5ij9DOVSV4LpvlP5QGqzu3NmCLbD2E7ZVo6niiENnBQp3CJjlWUDnMMCovO6 cCVdyxgvCEPeZWhbfZdDU96je65hTw/c7PsZtZj+2nzqIxJRd7074DxuwD82DRticlbM r/nJnUMcT2448h0AOXIJ1H2gikILrTO2e4XmxYYwyMPVpLCVTITZSYIKiN9sYNcR9gTM 3lQA== X-Gm-Message-State: AGRZ1gIR0LrtZad8G5U+vumE8YoVSf8+UbikoDZXK9aFcoy+Q/QKzzop guCcqanNhjJ5YO1kw1E3Kik32v6v9XX3Qw+RVKNfdBYa X-Google-Smtp-Source: AJdET5ewM4U6M585gQLsQ2AgPK3ZiAmt9o3DOA8G9kmQmUuKxtsgmw8KaPCdiN8gJIW5tHc28HGUoZemwgD9sADeaV4= X-Received: by 2002:a19:d58e:: with SMTP id m136mr9289986lfg.70.1541914775893; Sat, 10 Nov 2018 21:39:35 -0800 (PST) MIME-Version: 1.0 From: Kevin Ma Date: Sun, 11 Nov 2018 00:39:24 -0500 Message-ID: To: "" Content-Type: multipart/alternative; boundary="0000000000007db94d057a5d02ae" Archived-At: Subject: [CDNi] Shepherd Review of URI Signing 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, 11 Nov 2018 05:39:40 -0000 --0000000000007db94d057a5d02ae Content-Type: text/plain; charset="UTF-8" Hi All, (As chair) As promised, I have performed a shepherd review of the latest URI Signing draft. I have submitted a pull request addressing a whole bunch of nits: https://github.com/kjmietf/URISigningSpec/pull/2/files . Three additional questions for the authors: - general: should RFC3986, RFC5952, RFC6265, and POSIX.1 be normative references? They feel normative to me. - section 2.1.10: do you want to add a reference for IPv4 address notation? - section 6.4: Are there any special instructions to the expert reviewer? Need to remove the ed note. I think that the draft will be ready for WGLC once the above issues are addressed. thanx! -- Kevin J. Ma --0000000000007db94d057a5d02ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

=C2=A0 (As chair) As promised, I have performed a shepherd review of the= latest URI Signing draft.=C2=A0 I have submitted a pull request addressing= a whole bunch of nits:=C2=A0https://github.com/kjmietf/URISigningSpec/pull/2/files= .=C2=A0 Three additional questions for the authors:

=C2=A0 - general: should RFC3986, RFC5952, RFC6265, and POSIX.1 be n= ormative references?=C2=A0 They feel normative to me.
=C2=A0 - se= ction 2.1.10: do you want to add a reference for IPv4 address notation?
=C2=A0 - section 6.4: Are there any special instructions to the expe= rt reviewer?=C2=A0 Need to remove the ed note.

=C2=A0 I think that the draft will be ready for WGLC once the above issues= are addressed.

thanx!

--= =C2=A0 Kevin J. Ma

--0000000000007db94d057a5d02ae-- From nobody Sun Nov 11 19:32:59 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 2789A1276D0 for ; Sun, 11 Nov 2018 19:32:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.899 X-Spam-Level: X-Spam-Status: No, score=-14.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no 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 MXeMruthV6bh for ; Sun, 11 Nov 2018 19:32:55 -0800 (PST) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by ietfa.amsl.com (Postfix) with SMTP id 8F39912008A for ; Sun, 11 Nov 2018 19:32:55 -0800 (PST) Received: (qmail 27205 invoked by uid 99); 12 Nov 2018 03:32:54 -0000 Received: from mail-relay.apache.org (HELO mailrelay1-lw-us.apache.org) (207.244.88.152) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Nov 2018 03:32:54 +0000 Received: from mail-it1-f179.google.com (mail-it1-f179.google.com [209.85.166.179]) by mailrelay1-lw-us.apache.org (ASF Mail Server at mailrelay1-lw-us.apache.org) with ESMTPSA id 08D641728; Mon, 12 Nov 2018 03:32:54 +0000 (UTC) Received: by mail-it1-f179.google.com with SMTP id v11so11326799itj.0; Sun, 11 Nov 2018 19:32:53 -0800 (PST) X-Gm-Message-State: AGRZ1gLiZhZhj1Jhp1TSJT8NhMRMuL0rPa8LB5rC4MJ0STMiX/6zqlId KTVZFAd/P9DRKrIFlWMF+MudYiON3srJgf56+3A= X-Google-Smtp-Source: AJdET5eNmzXNPcXDiSTYf/gRcVLtPo70h3fs/oy+pL5P88y0F7VhNhLZp9YWS6s7P5OaArMnoMDWtC929c3VATcRMHU= X-Received: by 2002:a24:dd8d:: with SMTP id t135-v6mr8552397itf.75.1541993573548; Sun, 11 Nov 2018 19:32:53 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Phil Sorber Date: Sun, 11 Nov 2018 20:32:41 -0700 X-Gmail-Original-Message-ID: Message-ID: To: "" , draft-fieau-cdni-interfaces-https-delegation@ietf.org Content-Type: multipart/alternative; boundary="000000000000328d1a057a6f5b33" Archived-At: Subject: Re: [CDNi] draft-fieau-cdni-interfaces-https-delegation call for adoption 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: Mon, 12 Nov 2018 03:32:57 -0000 --000000000000328d1a057a6f5b33 Content-Type: text/plain; charset="UTF-8" Having seen only positive supportive feedback, and backed up by a positive hum during the WG meeting in Bangkok, I am calling this adoption as successful. Can the draft editors please submit a new draft with the name draft-ietf-cdni-interfaces-https-delegation and I will mark it for adoption. Thanks! On Sun, Oct 28, 2018 at 8:20 PM Phil Sorber wrote: > At the last meeting we discussed the potential to adopt this document. > Frederic posted a new version with the changes we had discussed and so I'd > like to do a formal call for adoption here. > > > https://datatracker.ietf.org/doc/draft-fieau-cdni-interfaces-https-delegation/ > > I'll leave this open until Nov 10th. > > Thanks. > --000000000000328d1a057a6f5b33 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Having seen only positive supportive feedback, and ba= cked up by a positive hum during the WG meeting in Bangkok, I am calling th= is adoption as successful.

Can the dra= ft editors please submit a new draft with the name draft-ietf-cdni-interfac= es-https-delegation and I will mark it for adoption.

Thanks!

On Sun, Oct 28, 2018 at 8:20 PM Phil Sorber <sorber@apache.org> wrote:=
At the last = meeting we discussed the potential to adopt this document. Frederic posted = a new version with the changes we had discussed and so I'd like to do a= formal call for adoption here.


I'll leave this op= en until Nov 10th.

Thanks.
--000000000000328d1a057a6f5b33-- From nobody Sun Nov 11 19:51:52 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 B70C0127133 for ; Sun, 11 Nov 2018 19:51:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.9 X-Spam-Level: X-Spam-Status: No, score=-14.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no 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 bkoms42ObtaY for ; Sun, 11 Nov 2018 19:51:50 -0800 (PST) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by ietfa.amsl.com (Postfix) with SMTP id F2B0A12007C for ; Sun, 11 Nov 2018 19:51:49 -0800 (PST) Received: (qmail 41436 invoked by uid 99); 12 Nov 2018 03:51:47 -0000 Received: from mail-relay.apache.org (HELO mailrelay1-lw-us.apache.org) (207.244.88.152) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Nov 2018 03:51:47 +0000 Received: from mail-it1-f177.google.com (mail-it1-f177.google.com [209.85.166.177]) by mailrelay1-lw-us.apache.org (ASF Mail Server at mailrelay1-lw-us.apache.org) with ESMTPSA id 0052F1728 for ; Mon, 12 Nov 2018 03:51:46 +0000 (UTC) Received: by mail-it1-f177.google.com with SMTP id t189-v6so9663180itf.1 for ; Sun, 11 Nov 2018 19:51:46 -0800 (PST) X-Gm-Message-State: AGRZ1gLr8eYiIqBvM/yo5vTGJdCzC3ZM4jlI5iMZ5Gqjq4AGWhB7yM8D 26W7ZDqwT2btZSpSPFgdFAlQjwLWew/QmMRf4VU= X-Google-Smtp-Source: AJdET5csolzRSE6DJzAhmseYe+BUcMbeDCHQNvHXuXYmYS3R9DwbtkBpqavt3Jo2m1CCgwinApQI2CabAo47wP8u4kU= X-Received: by 2002:a24:b641:: with SMTP id d1-v6mr9289958itj.133.1541994706500; Sun, 11 Nov 2018 19:51:46 -0800 (PST) MIME-Version: 1.0 From: Phil Sorber Date: Sun, 11 Nov 2018 20:51:34 -0700 X-Gmail-Original-Message-ID: Message-ID: To: "" Content-Type: multipart/alternative; boundary="000000000000ba051c057a6f9e8c" Archived-At: Subject: [CDNi] 103 meeting minutes 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: Mon, 12 Nov 2018 03:51:52 -0000 --000000000000ba051c057a6f9e8c Content-Type: text/plain; charset="UTF-8" I've updated the minutes for the meeting. Please review and let me know if there are any corrections. Thanks. --000000000000ba051c057a6f9e8c Content-Type: text/html; charset="UTF-8"
I've updated the minutes for the meeting. Please review and let me know if there are any corrections.

Thanks.
--000000000000ba051c057a6f9e8c-- From nobody Sun Nov 11 19:57:30 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 5C25F1276D0 for ; Sun, 11 Nov 2018 19:57:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.899 X-Spam-Level: X-Spam-Status: No, score=-14.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no 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 48aIiI1HeXM3 for ; Sun, 11 Nov 2018 19:57:27 -0800 (PST) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by ietfa.amsl.com (Postfix) with SMTP id AF82812007C for ; Sun, 11 Nov 2018 19:57:27 -0800 (PST) Received: (qmail 43318 invoked by uid 99); 12 Nov 2018 03:57:27 -0000 Received: from mail-relay.apache.org (HELO mailrelay2-lw-us.apache.org) (207.244.88.137) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Nov 2018 03:57:27 +0000 Received: from mail-io1-f44.google.com (mail-io1-f44.google.com [209.85.166.44]) by mailrelay2-lw-us.apache.org (ASF Mail Server at mailrelay2-lw-us.apache.org) with ESMTPSA id 2FBA12100 for ; Mon, 12 Nov 2018 03:57:26 +0000 (UTC) Received: by mail-io1-f44.google.com with SMTP id f12-v6so5290766iog.0 for ; Sun, 11 Nov 2018 19:57:26 -0800 (PST) X-Gm-Message-State: AGRZ1gIoDiFodtWcUp0dqtEviuPJkPSDbQQPCclERtXk5AG47sn3YOTn Xb7gi2enUY99KEp+ziOUCwaCp0+dDkP1mtt+xyc= X-Google-Smtp-Source: AJdET5esRDxIibKh5sEjRjDN5kvVilcp7wl2tDhLuRv81Jcg7dVgDjEj9p7N319PiZrwTopcRQ8Rqmh1I8kDOuFdSts= X-Received: by 2002:a6b:9141:: with SMTP id t62-v6mr13776729iod.156.1541995045662; Sun, 11 Nov 2018 19:57:25 -0800 (PST) MIME-Version: 1.0 From: Phil Sorber Date: Sun, 11 Nov 2018 20:57:14 -0700 X-Gmail-Original-Message-ID: Message-ID: To: "" Content-Type: multipart/alternative; boundary="000000000000f13898057a6fb286" Archived-At: Subject: [CDNi] Call for Adoption on draft-finkelman-cdni-triggers-sva-extensions 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: Mon, 12 Nov 2018 03:57:29 -0000 --000000000000f13898057a6fb286 Content-Type: text/plain; charset="UTF-8" Hello All, In Bangkok we had an update on the document as well as clarification about the need for a re-charter, or more explicitly, the lack thereof, and a hum for interest in adopting this document. The hum was positive and I would like to open a Call For Adoption on it. If you weren't present at the meeting, or perhaps came up with some new opinions, please voice them here. Link to doc: https://datatracker.ietf.org/doc/draft-finkelman-cdni-triggers-sva-extensions/ This CFA will be open until Nov 25th. Thanks. --000000000000f13898057a6fb286 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello All,

In Bangkok we had an upda= te on the document as well as clarification about the need for a re-charter= , or more explicitly, the lack thereof, and a hum for interest in adopting = this=20 document. The hum was positive and I would like to open a Call For=20 Adoption on it. If you weren't present at the meeting, or perhaps came= =20 up with some new opinions, please voice them here.

Link to doc: https://datatracker.ietf.org/doc/draft-finkel= man-cdni-triggers-sva-extensions/

This CFA wil= l be open until Nov 25th.

Thanks.

--000000000000f13898057a6fb286-- From nobody Sun Nov 11 20:16:00 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 2A9F31276D0 for ; Sun, 11 Nov 2018 20:15:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.899 X-Spam-Level: X-Spam-Status: No, score=-14.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no 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 A1sLgF7X7eJE for ; Sun, 11 Nov 2018 20:15:57 -0800 (PST) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by ietfa.amsl.com (Postfix) with SMTP id 8840A12007C for ; Sun, 11 Nov 2018 20:15:57 -0800 (PST) Received: (qmail 68722 invoked by uid 99); 12 Nov 2018 04:15:57 -0000 Received: from mail-relay.apache.org (HELO mailrelay2-lw-us.apache.org) (207.244.88.137) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Nov 2018 04:15:57 +0000 Received: from mail-it1-f181.google.com (mail-it1-f181.google.com [209.85.166.181]) by mailrelay2-lw-us.apache.org (ASF Mail Server at mailrelay2-lw-us.apache.org) with ESMTPSA id 76ACA2100 for ; Mon, 12 Nov 2018 04:15:56 +0000 (UTC) Received: by mail-it1-f181.google.com with SMTP id m15so11378433itl.4 for ; Sun, 11 Nov 2018 20:15:56 -0800 (PST) X-Gm-Message-State: AGRZ1gI/zQwe32USTNBhxTBiailCfuZyUdRxjatu0cUiba6pmcls4ebb Y82OUB/EL2D8PuQszkEMSDithWzhCtFEHPEsmfo= X-Google-Smtp-Source: AJdET5czdVTnlfNwgZ5oU53tISKLBQiK3u9wqGTIiwaKLPo8OmJnkdsQTG4kAkgjZytWQRj7Wv2kid+jPS/lVBdWiBs= X-Received: by 2002:a02:91c9:: with SMTP id s9-v6mr17459536jag.104.1541996155973; Sun, 11 Nov 2018 20:15:55 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Phil Sorber Date: Sun, 11 Nov 2018 21:15:43 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Chris Lemmons Cc: cdni@ietf.org Content-Type: multipart/alternative; boundary="0000000000001f34cc057a6ff5f9" Archived-At: Subject: Re: [CDNi] Error Redirect for URI Signing 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: Mon, 12 Nov 2018 04:15:59 -0000 --0000000000001f34cc057a6ff5f9 Content-Type: text/plain; charset="UTF-8" (as an individual) I'm not thrilled with the level of complication this adds. Not only will you have to have a full URL to redirect the user to on error, but you will have to capture enough state in the signed token to also redirect them back and presumably to the point in the token sequence that they already were as the intent here is to appear seamless. I can think of a few ways to do this, but none of them seem good. 1. Have the server append the request URL in some fashion to the redirect URL 2. Have the destination of the redirect parse the referrer URL 3. Let the client decide based upon what it may already have stored or in cache. This seems a bit hand wavy and we should provide some guidance to implementers. This also might be incompatible with things like HLS? Is there another solution that you might propose? We should probably include that in the text as a suggested implementation even if there is nothing extra the server or client needs to do. This will also make the token even bigger and I suspect very few will implement it because of that. If we adopt this, I think we should condense this to one claim. The space is already polluted enough. (as document editor) We also need to have a registry entry for this. Thanks. On Sat, Nov 3, 2018 at 4:15 AM Chris Lemmons wrote: > I've got a draft of some potential language for an error handling > claim in URI Signing. This came as a result of another attempt at an > implementation. The content originator wants to set a custom redirect > for when a token is out of date or otherwise invalid so the user agent > can go get a new token. > > There are a number of use cases for it, so I think this might be the > simplest solution. I don't like having a separate claim for the error > code, but it is quite simple to implement and understand. > > Thoughts? > > Link: https://github.com/PSUdaemon/URISigningSpec/pull/56 > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > --0000000000001f34cc057a6ff5f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(as an individual)

I'm n= ot thrilled with the level of complication this adds. Not only will you hav= e to have a full URL to redirect the user to on error, but you will have to= capture enough state in the signed token to also redirect them back and pr= esumably to the point in the token sequence that they already were as the i= ntent here is to appear seamless. I can think of a few ways to do this, but= none of them seem good.
  1. Have the server append the reque= st URL in some fashion to the redirect URL
  2. Have the destination of = the redirect parse the referrer URL
  3. Let the client decide based upo= n what it may already have stored or in cache. This seems a bit hand wavy a= nd we should provide some guidance to implementers. This also might be inco= mpatible with things like HLS?
Is there another sol= ution that you might propose? We should probably include that in the text a= s a suggested implementation even if there is nothing extra the server or c= lient needs to do.

This will also make the tok= en even bigger and I suspect very few will implement it because of that.

If we adopt this, I think we should condense thi= s to one claim. The space is already polluted enough.

<= div>(as document editor)

We also need to have a re= gistry entry for this.

Thanks.
--0000000000001f34cc057a6ff5f9-- From nobody Sun Nov 11 20:25:49 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 0262D1276D0 for ; Sun, 11 Nov 2018 20:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.899 X-Spam-Level: X-Spam-Status: No, score=-14.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no 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 j9Lyo47mO5-3 for ; Sun, 11 Nov 2018 20:25:46 -0800 (PST) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by ietfa.amsl.com (Postfix) with SMTP id 401AD12007C for ; Sun, 11 Nov 2018 20:25:46 -0800 (PST) Received: (qmail 85031 invoked by uid 99); 12 Nov 2018 04:25:46 -0000 Received: from mail-relay.apache.org (HELO mailrelay1-lw-us.apache.org) (207.244.88.152) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Nov 2018 04:25:46 +0000 Received: from mail-io1-f48.google.com (mail-io1-f48.google.com [209.85.166.48]) by mailrelay1-lw-us.apache.org (ASF Mail Server at mailrelay1-lw-us.apache.org) with ESMTPSA id 2E66E1728 for ; Mon, 12 Nov 2018 04:25:45 +0000 (UTC) Received: by mail-io1-f48.google.com with SMTP id o19-v6so5302418iod.3 for ; Sun, 11 Nov 2018 20:25:45 -0800 (PST) X-Gm-Message-State: AGRZ1gIVfwT4wHbGLETGCMp2kV8XaVxJ9DHSFLAZNTtEalqH/xZfbmkG GJ9gqyPjzeLFIDIdTUuiElaTO884heHhl1agqAE= X-Google-Smtp-Source: AJdET5eMR9tuVU3ZfFHo4yPlP1jyGyNEBtSjpd5TINx6taiQE/BGnkoKoE8B5TfJ6WgVi4PsO6Pp2Hj9ar0Pf6XnH9I= X-Received: by 2002:a6b:9141:: with SMTP id t62-v6mr13815383iod.156.1541996744736; Sun, 11 Nov 2018 20:25:44 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Phil Sorber Date: Sun, 11 Nov 2018 21:25:32 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Kevin Ma Cc: "" Content-Type: multipart/alternative; boundary="0000000000003707ed057a701898" Archived-At: Subject: Re: [CDNi] Shepherd Review of URI Signing 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: Mon, 12 Nov 2018 04:25:48 -0000 --0000000000003707ed057a701898 Content-Type: text/plain; charset="UTF-8" Kevin, Your PR has been made against your own repo and not mine, thus I cannot merge it. Can you create a PR with it against my repo instead? Thanks. On Sat, Nov 10, 2018 at 10:39 PM Kevin Ma wrote: > Hi All, > > (As chair) As promised, I have performed a shepherd review of the latest > URI Signing draft. I have submitted a pull request addressing a whole > bunch of nits: https://github.com/kjmietf/URISigningSpec/pull/2/files . > Three additional questions for the authors: > > - general: should RFC3986, RFC5952, RFC6265, and POSIX.1 be normative > references? They feel normative to me. > - section 2.1.10: do you want to add a reference for IPv4 address > notation? > - section 6.4: Are there any special instructions to the expert > reviewer? Need to remove the ed note. > > I think that the draft will be ready for WGLC once the above issues are > addressed. > > thanx! > > -- Kevin J. Ma > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > --0000000000003707ed057a701898 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Kevin,

Your PR has been made= against your own repo and not mine, thus I cannot merge it. Can you create= a PR with it against my repo instead?

Thanks.
=

On Sat, Nov 10, = 2018 at 10:39 PM Kevin Ma <= kevin.j.ma.ietf@gmail.com> wrote:
Hi All,

=C2=A0 (As chair) As promised, I have performed a shepherd review = of the latest URI Signing draft.=C2=A0 I have submitted a pull request addr= essing a whole bunch of nits:=C2=A0https://github.com/kjmietf/URI= SigningSpec/pull/2/files .=C2=A0 Three additional questions for the aut= hors:

=C2=A0 - general: should RFC3986, RFC5952, R= FC6265, and POSIX.1 be normative references?=C2=A0 They feel normative to m= e.
=C2=A0 - section 2.1.10: do you want to add a reference for IP= v4 address notation?
=C2=A0 - section 6.4: Are there any special = instructions to the expert reviewer?=C2=A0 Need to remove the ed note.
<= /div>

=C2=A0 I think that the draft will be ready for WG= LC once the above issues are addressed.

thanx!

--=C2=A0 Kevin J. Ma

=
_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni
--0000000000003707ed057a701898-- From nobody Mon Nov 12 04:52:35 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 2F867129BBF for ; Mon, 12 Nov 2018 04:52:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] 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 0dfZ6Bb6mgjD for ; Mon, 12 Nov 2018 04:52:30 -0800 (PST) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 9F10512F1AC for ; Mon, 12 Nov 2018 04:52:29 -0800 (PST) Received: by mail-wr1-x42c.google.com with SMTP id j17-v6so9183096wrq.11 for ; Mon, 12 Nov 2018 04:52:29 -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; bh=7e9rWYOYAkLfNzBVWUsDIoP3ZBJKIugc4hd8WIZVU0I=; b=zIki8rea698waynBs9yxM6fD/IVC0YFOcv8PJI+A3cpeX7hm2SPvkYEoa9ir8zvSCd BYTJ5mmQsaTY0dhYPm88pjjBaKa4hemi538AfEDI+MZAJPBuC7ypIMSRFqKgRZxcAPkr Ft3TZg2OBsODI6quC2tC85Fhw7loEBAqaqvVKfyJrTrg5v5rnPoqllGJ4DiJPsPTWEmF aSUilpYOa045HbeXyZYCdOGf284CO6pYvwQpe5eU+5vkhDKso5zGTTE0HNuhCTZnVgqG QfrfyBPBzd/w2IZsdPF62iatHWkN2MRKIT2jKvVwMWye/ptibccy8D40hXWEVVz4bA7B 29Sg== 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; bh=7e9rWYOYAkLfNzBVWUsDIoP3ZBJKIugc4hd8WIZVU0I=; b=bfTJfu1LMD9BTlH/N/caTAiPNpdp8wggwf6/ChDd9StHe45wNwy7WpI7kyXSZQNwwN OjhMFjb1+SEQs/hPVt4wLiKYB711XZKWAcZ92st5zKVxvB99/PzRKdx9iefrV8kakYnK WpbKEq8KZJLN8sqkvRhfyq0ygf7+kZ2eCDtey/x8MP4iMNtWM8Eaip7D3/MjNYmCmKQL XRlt3cAHejvGmYD86fcaWQCBgMq46yexZsCiTt4JEw6nWxySUSfq+/02VCAb7kEiYnww WJckIKXW5o5ppMI+ea53tQsP0LYPpCOXrJrqGigU3FyUs6+k+5Wqt5tL8rABpGnlyYSv LkzA== X-Gm-Message-State: AGRZ1gKn5DzNpL20rQW0eSKYWDTcY9WcLSBjNZa2P9s5lUvRts7jPN/F HXxzDteDQEjZpcMD+3xadrUNDO/m9OKNSQsCclcMCsiQxbU= X-Google-Smtp-Source: AJdET5czGULW3UlCU0zg3Khr3E35O9OjPBfvfbZjGL/5RVWmc4pkde0RlXZFboEpwutP0swpEL5nqCXznpPV5WNlwKg= X-Received: by 2002:adf:e3c2:: with SMTP id k2-v6mr943037wrm.156.1542027147454; Mon, 12 Nov 2018 04:52:27 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ori Finkelman Date: Mon, 12 Nov 2018 14:51:58 +0200 Message-ID: To: "" Content-Type: multipart/alternative; boundary="0000000000005bc0ea057a772c36" 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: Mon, 12 Nov 2018 12:52:34 -0000 --0000000000005bc0ea057a772c36 Content-Type: text/plain; charset="UTF-8" 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 --0000000000005bc0ea057a772c36 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
In the CDNI meeting we have discu= ssed how to represent local time at the trigger destination where there are= multiple destination locations in different time=C2=A0zones.
Two options raised:
1. Follow RFC 3339, and add a = new notion for "your local time"=C2=A0
For example:= =C2=A02018-11-12T02:30:00.00L
should be i= nterpreted as November 12th, 2018, 2:30AM at your own local time.
=

2. Use UTC / UNIX epoch with a local time flag.<= /div>
For example:=C2=A0154= 1989800=C2=A0For=C2=A0and {"local-time": true} means=C2=A0= 2018-11-12T02:30:00.00 but servers MUST interpret th= at in their own local time.=C2=A0
I.e. servers MUST reduce their = time offset from the UNIX epoch before interpreting the time.=C2=A0
For example, a server located at UTC+02:00 must reduce 7200 seconds from= this eopch, resulting in=C2=A0= 1541982600 which is=C2=A02018-11-12T02:30:00.00+02:0= 0
If a sever is located at UTC-04:00 it must reduce -1= 4,400 seconds epoch, resulting in 1542004200 which is=C2=A0= 2018-11-12T02:30:00.00-04:00

Personally I am in favor of option 2, as option 1 will require cha= nges in time parser and is probably best done by an updated RFC on top of R= FC 3339, not sure this use case justifies it.
I will also pin= g the authors of RFC3339 to get their views, but would appreciate any input= at the mean time.

Thanks,
Ori



<= /span>



<= /div>


On Mon, Oct 15, 2018 at 12:23 PM Ori Finkelman <orif@qwilt.com> wrote:
Hi,
In the last CDNI meetin= g 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 trigg= er 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 tim= e".

The reasoning is that network resource av= ailability and prices may vary across the day, and specifically are more av= ailable and less expensive at off-peak=C2=A0hours. however off-peak hours a= re 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 t= hat would require calling a separate trigger for each region.
While working on adding this "local-time" flag, I hav= e 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 represe= nt 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 Finke= lman <orif@qwilt.com= > wrote:
=
Here are the comments we got CDNI meeting.

<= div>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. W= hen true the trigger should be executed at the local time, per zone.
<= div>
Trigger error and warning propagation:
Considering triggers may be propagated to a chain of dCDNs, and cons= idering we allow extensions to be safe-to-redistribute even if not understo= od, we should add a mechanism for propagating errors and warnings back to t= he uCDN.

Thanks,
Ori

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


--
Ori Fi= nkelman
Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwi= lt.com


--
Ori Finkelman
Qwilt | Work: +972-72-2221647 | Mobile: +972-52= -3832189 | orif@qwilt.com
--0000000000005bc0ea057a772c36-- From nobody Mon Nov 12 12:15:18 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 2CF0D130F00 for ; Mon, 12 Nov 2018 12:15:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.899 X-Spam-Level: X-Spam-Status: No, score=-14.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no 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 ChIzQyESIcrU for ; Mon, 12 Nov 2018 12:15:08 -0800 (PST) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by ietfa.amsl.com (Postfix) with SMTP id 9E6CF130EDB for ; Mon, 12 Nov 2018 12:15:08 -0800 (PST) Received: (qmail 19076 invoked by uid 99); 12 Nov 2018 20:15:07 -0000 Received: from mail-relay.apache.org (HELO mailrelay2-lw-us.apache.org) (207.244.88.137) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Nov 2018 20:15:07 +0000 Received: from mail-it1-f177.google.com (mail-it1-f177.google.com [209.85.166.177]) by mailrelay2-lw-us.apache.org (ASF Mail Server at mailrelay2-lw-us.apache.org) with ESMTPSA id 4E2AD2125 for ; Mon, 12 Nov 2018 20:15:06 +0000 (UTC) Received: by mail-it1-f177.google.com with SMTP id j79-v6so15094412itb.2 for ; Mon, 12 Nov 2018 12:15:06 -0800 (PST) X-Gm-Message-State: AGRZ1gK4L3zz++8ZSG7puhApVk9ruUfCnYjLFV5Eq9OKcfsc31VUOhNP eIgrKWAsP6o/j2Gmk24E0YFLQ4V4EoD16ptvcL8= X-Google-Smtp-Source: AJdET5c0X/a1YwSr3odGDTw2IRF0qG5ZztUGrFY2AKk5JIuUcqr4RtQc6t7edxS8gCF5Li502Qlq4xNLgsawL7BuzUg= X-Received: by 2002:a24:c445:: with SMTP id v66-v6mr1060724itf.21.1542053705643; Mon, 12 Nov 2018 12:15:05 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Phil Sorber Date: Mon, 12 Nov 2018 13:14:48 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Ori Finkelman Cc: "" Content-Type: multipart/alternative; boundary="000000000000598875057a7d5b40" 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: Mon, 12 Nov 2018 20:15:17 -0000 --000000000000598875057a7d5b40 Content-Type: text/plain; charset="UTF-8" What about section 4.3 of RFC3339? https://tools.ietf.org/html/rfc3339#section-4.3 using the -0000 offset to signify local time. Also, it seems that ISO8601 also has a "local time" where you just don't include an offset: 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." 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 <+972%2072-222-1647> | >>> Mobile: +972-52-3832189 <+972%2052-383-2189> | orif@qwilt.com >>> >> >> >> -- >> >> *Ori Finkelman*Qwilt | Work: +972-72-2221647 <+972%2072-222-1647> | >> Mobile: +972-52-3832189 <+972%2052-383-2189> | orif@qwilt.com >> > > > -- > > *Ori Finkelman*Qwilt | Work: +972-72-2221647 <+972%2072-222-1647> | > Mobile: +972-52-3832189 <+972%2052-383-2189> | orif@qwilt.com > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > --000000000000598875057a7d5b40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What about section 4.3 of RFC3339?


using = the -0000 offset to signify local time.

Also, it s= eems that ISO8601 also has a "local time" where you just don'= t include an offset:


"= ;If no UTC relation information is given with a time representation, the ti= me is assumed to be in local time."

Also in R= FC 2822 section 3.3 (https://tools.ietf.org/html/rfc2822#section-3.3):

<= /div>"Though "-0000" also indicates Universal Time, it is us= ed to indicate that the time was generated on a system that may be in a loc= al time zone other than Universal Time and therefore indicates that the dat= e-time contains no information about the local time zone."

On Mon, Nov 12, 2018 at 5:53 AM Or= i Finkelman <orif@qwilt.com> wr= ote:
Hi,
In the CDNI meeting we have discussed how to represent local ti= me at the trigger destination where there are multiple destination location= s in different time=C2=A0zones.

Two options raised= :
1. Follow RFC 3339, and add a new notion for "your loca= l time"=C2=A0
For example:=C2=A0201= 8-11-12T02:30:00.00L
should be interpreted as November 12= th, 2018, 2:30AM at your own local time.

2.= Use UTC / UNIX epoch with a local time flag.
For example:=C2= =A01541989800=C2=A0For= =C2=A0and {"local-time": true} means=C2=A020= 18-11-12T02:30:00.00 but servers MUST interpret that in their own lo= cal time.=C2=A0
I.e. servers MUST reduce their time offset from t= he UNIX epoch before interpreting the time.=C2=A0
For example, a = server located at UTC+02:00 must reduce 7200 seconds from this eopch, resul= ting in=C2=A01541982600 which i= s=C2=A02018-11-12T02:30:00.00+02:00
<= /div>
If a sever is located at UTC-04:00 it must reduce -14,400 seconds= epoch, resulting in 1542004200 which is=C2=A02018-11-= 12T02:30:00.00-04:00

Personally I am in favor of option 2, as option 1 will require change= s 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 t= he 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:<= br>
H= i,
In the last CDNI meeting we have agreed to add to the time policy th= e local-time flag (see below).
The required semantics is the inst= ruct the dCDN to run the trigger at the given time window in there own loca= l time.
For example: "I want you to run this trigger between= 3AM-5AM at your own local time".

The reasoni= ng is that network resource availability and prices may vary across the day= , and specifically are more available and less expensive at off-peak=C2=A0h= ours. 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 &quo= t;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 ca= n think of using textual time format as defined in RFC3339, and the local t= ime flag should be interpreted by the dCDN as "you should interpret th= is 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 a= br-protocol to media-protocol, as it may be used for other media rather tha= n video abr.

Trigger TimePolicy:
Add local-time flag. When true the trigger should be executed at the= local time, per zone.

Trigger error and war= ning propagation:
Considering triggers may be propagated = to a chain of dCDNs, and considering we allow extensions to be safe-to-redi= stribute even if not understood, we should add a mechanism for propagating = errors and warnings back to the uCDN.

Thanks,


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


--
Ori Finkelman
Qwilt | Work: +972-72-2= 221647 | Mobile: +972-52-3832189 | orif@qwilt.com
_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni
--000000000000598875057a7d5b40-- From nobody Mon Nov 12 12:42:00 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 BCDC0130E68 for ; Mon, 12 Nov 2018 12:41:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] 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 isPEgQLPtTgQ for ; Mon, 12 Nov 2018 12:41:56 -0800 (PST) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (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 E425E130E4B for ; Mon, 12 Nov 2018 12:41:55 -0800 (PST) Received: by mail-wr1-x436.google.com with SMTP id y3-v6so10826760wrh.10 for ; Mon, 12 Nov 2018 12:41:55 -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=bsQ4hD6g1aUyU/En6h5CHAQiKn2Xv0hsJ2brPaGdyF0=; b=mnT/ZBBkwgo2uY0Cqf/vJluIGjRzjl2nN77/RMGVCbnnEJLM6CgqauMO7nIaABr4cu +oPnveItL93rCkUSepfnaBinItDuYn2e/NVGO9NPIRRevlW2p+XgNKFYFZ1d3mCzyhma aHau419/K68VKfjirCJl4p9FFxlwf/MolD8s+DYO7TuNljuCfNCnJtnSs5OwzcpSrk/i ToLeBELG2ejdJuZqe0mEKJly1kcmlOO0rSwfZcRLjDUizLrKXkuCRPQZjrzMCvZRSeg0 4v8zL/JdqakuM/Oy8morbK5lb0xwghyAjbfjcWFqdBCB5zpH6/RXlTpOO0Lwup8e+yXi mnhA== 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=bsQ4hD6g1aUyU/En6h5CHAQiKn2Xv0hsJ2brPaGdyF0=; b=IJUkfnsWBuvytW6JFFnwb/G5QB7ff6InN/s0PByg7Tl9AhThHXB2lcI4AG+gQQ2nkS NYdd1Eg1b9ZvpHP5RTI43xn55dq3h6YsPjp35IGLtrnDYbwB+FoUT1p0YGtxoxkyLdX9 W3I3J28mcMLrcvj1/p3kjmFJItZXv/gfCM1T57TwYZ9gM6KMbXggYKHtaRP5+f0szOw4 b+ntq5sb5vaYcD5d8pp7AVAcWn3NMDXrFvtTpQ5qzbHYKkRASaXhzSfHPZVNkNY6GKXZ Nu6185S3Vm5nE6yMnUEAt+etbI5RTONcONSjj9mwI/ELhjSbTVsUTiSegfUqH0s6yeYN 3DLQ== X-Gm-Message-State: AGRZ1gJwlszV2Lz9kyYORsNk7NaqEO8WVXvN4GaZ73bKZ7bK0cnltjke v4hNBQY1PDqq3zcSZdV24LJDH2awshKjWTeS3gPX2LaDsa4= X-Google-Smtp-Source: AJdET5eHJhxrBMq4/q5Jqi/rTa4ZTNRW2l/ONxhr0VKKX/KkN90orUyrdRw5Vd/8xTir3P/ZjI2Vak90CCSxKs1lq7c= X-Received: by 2002:adf:ee47:: with SMTP id w7-v6mr2186448wro.173.1542055313761; Mon, 12 Nov 2018 12:41:53 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ori Finkelman Date: Mon, 12 Nov 2018 22:41:23 +0200 Message-ID: To: Phil Sorber Cc: "" Content-Type: multipart/alternative; boundary="000000000000337f2f057a7dbbb2" 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: Mon, 12 Nov 2018 20:42:00 -0000 --000000000000337f2f057a7dbbb2 Content-Type: text/plain; charset="UTF-8" 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 <+972%2072-222-1647> | >>>> Mobile: +972-52-3832189 <+972%2052-383-2189> | orif@qwilt.com >>>> >>> >>> >>> -- >>> >>> *Ori Finkelman*Qwilt | Work: +972-72-2221647 <+972%2072-222-1647> | >>> Mobile: +972-52-3832189 <+972%2052-383-2189> | orif@qwilt.com >>> >> >> >> -- >> >> *Ori Finkelman*Qwilt | Work: +972-72-2221647 <+972%2072-222-1647> | >> Mobile: +972-52-3832189 <+972%2052-383-2189> | 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 --000000000000337f2f057a7dbbb2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Phil,
Though it may seem so, this is not our case a= nd 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=C2=A0+0000) but = the time zone was not supposed to be 0, it is just unknown, and is therefor= e 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=C2=A0+ the correct offset. This is a specific absolute time, n= ot something that can be interpreted as different UTC in different time zon= es.=C2=A0
We can decide that when we say "local time&q= uot; we actually mean the receivers local time rather than the callers loca= l 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 desig= nate 4AM depending on where the cache is found is non-standard.=C2=A0=C2=A0= =C2=A0
I was rather hoping we can have something which design= ate exactly what we mean, but I guess that passing the time with no time-zo= ne and adding a flag that says "use in your own local time" may b= e do it. But in this case, I would take Chris proposal and use UNIX epoch a= s it is easier to parse and is already been used in CDNI.

Thanks,
Ori



<= /div>




On Mon, Nov 12, 2018 at 10:15 PM Phil Sorber <sorber@apache.org&g= t; wrote:
Wha= t about section 4.3 of RFC3339?


using the -00= 00 offset to signify local time.
>> This= means that the time is actually in UTC (same as=C2=A0+0000) but the time z= one was not supposed to be 0, it is just unknown, and is therefore using 0.=

A= lso, it seems that ISO8601 also has a "local time" where you just= don't include an offset:
>> This ac= tually 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=C2=A0+ the corre= ct offset. This is a specific absolute time, not something that can be inte= rpreted as different UTC in different time zones.=C2=A0


<= /div>
"If no UTC relation information is given with a t= ime 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, i= f for example the trigger server is located at NY, then the 4AM will mean l= ocal time in NY. Using it to designate 4AM depending on where the cache is = found is non-standard.=C2=A0



=C2=A0
<= br>

"Though "-0000"= ; also indicates Universal Time, it is used to indicate that the time was g= enerated 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 abo= ut 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 trig= ger destination where there are multiple destination locations in different= time=C2=A0zones.

Two options raised:
1. Follow RFC 3339, and add a new notion for "your local time"= =C2=A0
For example:=C2=A02018-11-12T02:3= 0:00.00L
should be interpreted as November 12th, 2018, 2:= 30AM at your own local time.

2. Use UTC / U= NIX epoch with a local time flag.
For example:=C2=A01541989800=C2=A0For=C2=A0and {&qu= ot;local-time": true} means=C2=A02018-11-12T02:30= :00.00 but servers MUST interpret that in their own local time.=C2= =A0
I.e. servers MUST reduce their time offset from the UNIX epoc= h before interpreting the time.=C2=A0
For example, a server locat= ed at UTC+02:00 must reduce 7200 seconds from this eopch, resulting in=C2= =A01541982600 which is=C2=A02018-11-12T02:30:00.00+02:00
= If a sever is located at UTC-04:00 it must reduce -14,400 seconds epoch, re= sulting in 1542004200 which is=C2=A02018-11-12T02:30:0= 0.00-04:00

Pers= onally 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,
I= n 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.<= /div>
For example: "I want you to run this trigger between 3AM-5AM= at your own local time".

The reasoning is th= at network resource availability and prices may vary across the day, and sp= ecifically are more available and less expensive at off-peak=C2=A0hours. ho= wever off-peak hours are local per region.
In the past we have pr= oposed 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.

T= houghts ?

Thanks,
Ori

On Sun, Jul 22, 2018= at 9:19 AM Ori Finkelman <orif@qwilt.com> wrote:
Here are the comments we got CDNI mee= ting.

Playlist:
change abr-proto= col to media-protocol, as it may be used for other media rather than video = abr.

Trigger TimePolicy:
A= dd local-time flag. When true the trigger should be executed at the local t= ime, per zone.

Trigger error and warning pro= pagation:
Considering triggers may be propagated to a cha= in of dCDNs, and considering we allow extensions to be safe-to-redistribute= even if not understood, we should add a mechanism for propagating errors a= nd warnings back to the uCDN.

Thanks,
Or= i

--
Ori Finkelman
= Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | <= a href=3D"mailto:orif@qwilt.com" rel=3D"nofollow" target=3D"_blank">orif@qw= ilt.com


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


--
Or= i 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-222= 1647 | Mobile: +972-52-3832189 | orif@qwilt.com
--000000000000337f2f057a7dbbb2-- From nobody Mon Nov 12 14:16:50 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 5DB30130D7A for ; Mon, 12 Nov 2018 14:16:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 g-6IRjEWufzy for ; Mon, 12 Nov 2018 14:16:46 -0800 (PST) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 BA75A1286D9 for ; Mon, 12 Nov 2018 14:16:45 -0800 (PST) Received: by mail-wr1-x42c.google.com with SMTP id y3-v6so11056007wrh.10 for ; Mon, 12 Nov 2018 14:16:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=d6WEgsS2A1LE/JFudrHlbWVuwAXmS7qj+DsIQe8f5kQ=; b=HIO0smyk+HEYsfMdfAOX5/v+YE4VLcDqfwzFCgZ/YgOREplijeHLB1RAJdDu0gzRbO eBosS+2MqpeEy4lCEfoik1niOBQPIGIRArLV8ShEkBCof8Q2iu4F5sqI9gruMAxEgvsv YmkDNOZ8IlB06S7YCr/EwjA+cqsKbyR9BDf/VUtC6OZOzLwrEwc2y+vzCanJ07FXJgIQ m5H0xPaSbpSRo9Aw7YE5rr1tJ4pR+ekAjK8ll5YuooMW+hveV0d4M0PC1GwGwMAyX1hS msBfKZr2G9vC79rNyzJ2ygSFegrauApeQR6EKB8sjJH2K1I3uY2UKnB3QNhB4s5Nx6JT 4djQ== 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:content-transfer-encoding; bh=d6WEgsS2A1LE/JFudrHlbWVuwAXmS7qj+DsIQe8f5kQ=; b=pHCa/+fJ5GQUBHfxCjL6NY3Rz13pNTTFIr1p1V20ezJFt1kmNFccORX0QY1FVjwd8S I7Rsw4jQsQr8UzZJIfms8hWM8CzspkA86pgqZcsRtv9Y/pFDrEg623MUINzIl/BxZ3rx 6RBrqlwvGdffAWdDcmS4ot09MPpO3Xsx5PLKwNTTZsRpT11KwKWJs/Gi2GIENFEKQDlc mddIKxBphwrSAUVZ0aZm3j+UfFdpszK23U6dYHl5xS4GalZ1+15lwvxw1ECeogbbQVRp L7I/VgYjSZ+/yw+HKBqUf8NMGX5prfHdOv/6JGr5rRMkMUZzhegjh90x54dmx239Bljo KWGQ== X-Gm-Message-State: AGRZ1gIgaNjy01bnyI2vppEuBvNgyu4QpYM8gGnf/sv8tRPmRW/gGt1s EuJbc0CW7h8AI8jOnpxhA6r9FReSyY+C1ZDkw00= X-Google-Smtp-Source: AJdET5eKJ3lBEC3HX7bN24WQQYaB4UxoRDbIZ5dIrMvwp9G07qOr3HdzzuuDD2kKLpB+geWZOiSL2hp4H6s4tN90ZLQ= X-Received: by 2002:a5d:69ce:: with SMTP id s14-v6mr2852376wrw.177.1542061003983; Mon, 12 Nov 2018 14:16:43 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Chris Lemmons Date: Mon, 12 Nov 2018 15:16:32 -0700 Message-ID: To: kevin.j.ma.ietf@gmail.com Cc: cdni@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [CDNi] Error Redirect for URI Signing 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: Mon, 12 Nov 2018 22:16:48 -0000 Certainly, if you control the client entirely, you can easily specify whatever behaviour you want. Likewise, it's possible to negotiate special behaviour (which might or might not perfectly comport with the URI Signing draft) if you only have one CDN to deal with. But if you've got multiple CDNs or CDNs interconnected, it's desirable for a signer to be able to specify the error return in the case of an expired or otherwise invalid token. If you're not in a CDNI environment, this isn't as critical of an issue. You do bring up a potential point, which is "if a uCDN redirects to a dCDN, should an error redirect that points somewhere on the uCDN also be rewritten for the dCDN?" I guess that might be nice, but it significantly complicates things. Instead, I would expect the client to re-traverse the uCDN and be directed the appropriate resource via normal channels. Re: token bloat. There are a few ways to reduce the size of the token, but I think simplicity is more important. If an entity controls both the provider and the user agent, they don't necessarily need this sort of bloat. But if they do need it, there's no real way around it. Inter-CDN interop shouldn't be affected, unless I've missed something. The error redirect target doesn't necessarily even need to be part of the same CDN infrastructure, and if it is, it can use the same process as any other content. In terms of the benefit, it means that if either an origin or uCDN is signing uris to let dCDNs know that the request is authorized, they can also encode enough information to let the dCDN provide fallback addresses for requests that fail. For example, if a uCDN directs all requests from a particular network to a dCDN, it may wish to sign it's redirections so that users that have not been redirected there cannot retrieve content from the dCDN. If a user agent retrieves a 302 redirect to the dCDN, but then experiences a delay before resolving the dCDN's content, the dCDN may reject the token as expired. If the dCDN responds with a 403, the client is done and gets no data. If the dCDN responds with a redirect back to the uCDN, it can re-evaluate the location, sign a new token, and send the client back to obtain success. (Such a uCDN is advised to be careful to avoid loops, in the event of a permanently incorrect token being issued, of course.) In another situation, a content origin may use a separate cookie or another mechanism to keep track of authorizations. They can hand out short-lived tokens and direct generic clients one or more CDNs, but specify a redirect that goes back to the (perhaps comparatively more expensive) origin-verification. The weakest use case is streaming video, since the redirect won't have enough information about the specific URI that was requested in order to actually fulfill the request. Solutions to this scenario are rather significantly more complex and are probably not worth it. Things like trying to add the URI as query strings or similar wind up causing more problems than they solve, I think. Technically, I think you could do it with a template system: "cdnierr": "http://fallback.example.com/r?failed=3D$uri_base64&reason=3D$err_code". That's clearly powerful... but also requires a parsing engine, complete with escapes. But it's hard to beat the simplicity of "Put this value, unmodified, in the Location header and return this status code". As noted, if we like the idea, we also need a registry entry or two for it, and probably an example. On Tue, Nov 6, 2018 at 2:20 PM Kevin Ma wrote: > > Hi Chris, > > (As a chair) My initial thoughts on the PR is that it doesn't really ad= dress a CDNI issue. What a CSP might want a UA to do when token validation= fails is not really in scope of CDNI, and can be handled other ways by the= UA (without bloating the token)? > > (As an individual) The proposed feature seems to make inter-CDN interop= erability for URI signing more complex (and that would need to be fleshed o= ut more and reflected in the sequence diagrams in Section 5). I'm not sure= that I see the benefit (over letting the client implement 403 handling), w= ithout a more concrete use case. > > thanx. > > -- Kevin J. Ma > > > On Sat, Nov 3, 2018 at 6:15 AM Chris Lemmons wrote: >> >> I've got a draft of some potential language for an error handling >> claim in URI Signing. This came as a result of another attempt at an >> implementation. The content originator wants to set a custom redirect >> for when a token is out of date or otherwise invalid so the user agent >> can go get a new token. >> >> There are a number of use cases for it, so I think this might be the >> simplest solution. I don't like having a separate claim for the error >> code, but it is quite simple to implement and understand. >> >> Thoughts? >> >> Link: https://github.com/PSUdaemon/URISigningSpec/pull/56 >> >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni From nobody Mon Nov 12 14:46:45 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 D4BAF12785F for ; Mon, 12 Nov 2018 14:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 EccwRXalwivN for ; Mon, 12 Nov 2018 14:46:42 -0800 (PST) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 2081D123FFD for ; Mon, 12 Nov 2018 14:46:42 -0800 (PST) Received: by mail-wm1-x334.google.com with SMTP id s11so290421wmh.1 for ; Mon, 12 Nov 2018 14:46:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=zm30LN0iK3ysOFaMPvNuLYko1+yePiQMXMx+IsmwT0A=; b=QTVVUEWe7EIC8Kvt9B9GiTCyFycYwzQrX9dLn1p9dI+CLz3H50TD2nkpSdzrNGJU+W pW3uSM5c38nOHGZY5cY6xhjAMffexdnBkGZ5KRvt8Tx8erLzcfFv4F1s47d/nWyrc+B9 ZaT7jKrUqTPwYfwbnmpaKP0Q/a5IdiMpFdaEgKwkS1gsNGtdJ0jvGZ6z3wtkL4lxXGRP WuYFrO0PsPylOJHdadBLedaOMnsR55ySwrLAIM0+U7H544OxaAYY7G2enXzYVC2cl1Np XBMw4QJOJtH49ElSOAOHcVb+/OUL3Yd3cLBW6FUTLSyaDd1QJJJPKLrMa9zVUn5r/yRA bvLw== 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:content-transfer-encoding; bh=zm30LN0iK3ysOFaMPvNuLYko1+yePiQMXMx+IsmwT0A=; b=VgnG+pV8zgkODz6msZiViwAdJuwApEgFwxzsPLlsl+6Oj/XBC7ZfXVFG7vpa8lN7Ao 1jeTs1OQ3ORBrcaFdSVCPmQDbg9f7UgpX0VCv03qDbwbQKPtkIR37mL6Ue7mAcIVf1qU AI8SSFVrGQ0kNTVX61FDRB+f8pU1J3PPDAHbGEnm4gaAjFX4ESGA/UrHWAeuOGzEZf2N jlOghbiYuvJbUXXNDgnWMxUwggszdjcb1P6FK5U2EPALEtNs3ZNZgtoTlAL17oVgiB1U iOpvIgYqtd7fyY55uh/QSyWlIHhhKdrMTelLtn9O1COopPP8Bzm3I3z2nY7+3ryfHhSw Y6zA== X-Gm-Message-State: AGRZ1gLRseLJvGdPykxkPrV1SKB1X58OcgNV6/A8hhocuc3oJJQUHCqW 2K+0M2+1S1fApLcKiWVovc5/XuUTnY5HAeiIIQKGXnWf X-Google-Smtp-Source: AJdET5ddHpRKbG+YFTx77ZpZWcCOSqj0gdMW0nvOSWh/eIg1NBOMhpkDbkHZSSO+q94rdGw3m5CdO4rwHT7Nv4ZyMBo= X-Received: by 2002:a1c:bc82:: with SMTP id m124-v6mr1274743wmf.47.1542062800158; Mon, 12 Nov 2018 14:46:40 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Chris Lemmons Date: Mon, 12 Nov 2018 15:46:28 -0700 Message-ID: To: Ori Finkelman Cc: sorber@apache.org, cdni@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: Mon, 12 Nov 2018 22:46:45 -0000 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. 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 confu= sion. > What we need is something that executes in different absolute times in di= fferent locations. > > using the -0000 offset to signify local time. > >> This means that the time is actually in UTC (same as +0000) but the ti= me zone was not supposed to be 0, it is just unknown, and is therefore usin= g 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, whic= h means that if you translate it to UTC you should get the caller time + th= e 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 receiver= s local time rather than the callers local time, but then again, if for exa= mple the trigger server is located at NY, then 4AM will mean 4AM in local t= ime in NY (i.e. +0500). Using it to designate 4AM depending on where the ca= che 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 fla= g 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 i= s 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 ti= me zone was not supposed to be 0, it is just unknown, and is therefore usin= g 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, whic= h means that if you translate it to UTC you should get the caller time + th= e 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 t= ime" we actually mean the receivers local time rather than the callers loca= l 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 dependi= ng on where the cache is found is non-standard. > > > > >> >> >> Also in RFC 2822 section 3.3 (https://tools.ietf.org/html/rfc2822#sectio= n-3.3): >> >> "Though "-0000" also indicates Universal Time, it is used to indicate th= at the time was generated on a system that may be in a local time zone othe= r than Universal Time and therefore indicates that the date-time contains n= o 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 th= e trigger destination where there are multiple destination locations in dif= ferent 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-12T0= 2: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 i= nterpreting the time. >>> For example, a server located at UTC+02:00 must reduce 7200 seconds fro= m 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 33= 39, not sure this use case justifies it. >>> I will also ping the authors of RFC3339 to get their views, but would a= ppreciate 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 o= wn local time". >>>> >>>> The reasoning is that network resource availability and prices may var= y 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 comb= ination 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 T= imeWindow 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 Ti= meWindow. >>>> >>>> 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 me= dia 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 consi= dering we allow extensions to be safe-to-redistribute even if not understoo= d, we should add a mechanism for propagating errors and warnings back to th= e 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.c= om >>> >>> >>> >>> -- >>> Ori Finkelman >>> Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.co= m >>> _______________________________________________ >>> 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 From nobody Mon Nov 12 15:56:03 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 EB7EA130DFC for ; Mon, 12 Nov 2018 15:56:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outer-planes-net.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 0CFkpUW4bBcF for ; Mon, 12 Nov 2018 15:55:59 -0800 (PST) Received: from mail-it1-x129.google.com (mail-it1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 4598F128CE4 for ; Mon, 12 Nov 2018 15:55:59 -0800 (PST) Received: by mail-it1-x129.google.com with SMTP id e11so15843611itl.5 for ; Mon, 12 Nov 2018 15:55:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=sender:subject:to:cc:references:from:openpgp:autocrypt:message-id :date:user-agent:mime-version:in-reply-to; bh=eNGpyvyerU6pjBuC8MFcUVzzrjkAQq/CtBCSoh8W0M8=; b=EfxhNmPbVtQ9v7uWfPqa1Q37k1NP9g03rkX6QyPFDXbEX7CIMcJy+VrVkNDmOn/juf hOXkOo5tw/zTjmZrtv4bdcoZjVtpn8w799q8Pf0jRIwpY8xJgexlXrTt0xhmZ+gZtouu jTkBxzKIfpZ4EKDg7dFhJcRPui8kCtn+vL0DqGjlbHwQedV/PDX6m9rMfCRFeFNK03C2 IuXdpQ0F5IH4wA5Yo1oVPqxvBIJVY1yLvjtc60j/ongmTncFbDTGXYAmog0LtdvSlry3 J0dx4M01t8W+lhiiQw1yQpk3G1AduiLbPGjPABcvWiEy/JFfS2zEbhgRog2Q8cc+g4et zhVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:openpgp :autocrypt:message-id:date:user-agent:mime-version:in-reply-to; bh=eNGpyvyerU6pjBuC8MFcUVzzrjkAQq/CtBCSoh8W0M8=; b=qvo+jSP0udh/SMCUy4deztvAUQPVlWlGmyZg0IpxXc+6I2oHEoo84iloS7Kz+FQUZL N19KzHGPiG5LfM6Q0xDxPFpIvDHUdtHWGvqe1ZBVeHa7ttOmmtpxESinDDt5rhO5WCC0 9xshDzfY4FokHDCa9Oreu1dNHu87APhrXtvG1MibM4IPxY4mySwT/lRGnV0wWSJYIU9J 6oBPmeFtFX5WOO2mX8SBOBiX/GpLzHAsXDx+JYU2qnZd8LaanHnVIuwrcI0CtVOw4Rn6 MwmQNHOULhGDc9kExgFipSE+Cb+0em1RjiEAaBaOJcPuTUpxgbO+zm/9QvzBjJcm8MGK 3FqA== X-Gm-Message-State: AGRZ1gJPaO9A2fZ6Sd6m1g2OQ0SyuGyAhw7dQHne5B1HzkepL5mV93K0 7FeIvSfsbJmaXbqjSoOHrMFDEFMP3Mw= X-Google-Smtp-Source: AJdET5doIuMBlNClPC/naXPe3ghVxnikkP938bTdRlOtL09xlKAFfNHO2XwsUuiu2XX3E5xcLD4cyg== X-Received: by 2002:a24:33c6:: with SMTP id k189-v6mr1775266itk.46.1542066958173; Mon, 12 Nov 2018 15:55:58 -0800 (PST) Received: from ?IPv6:2601:280:4f80:2b7f:dcb0:de86:bc30:ba2c? ([2601:280:4f80:2b7f:dcb0:de86:bc30:ba2c]) by smtp.gmail.com with ESMTPSA id 201-v6sm5784151itm.2.2018.11.12.15.55.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Nov 2018 15:55:57 -0800 (PST) Sender: Matthew Miller To: Phil Sorber , Chris Lemmons Cc: cdni@ietf.org References: From: "Matthew A. Miller" Openpgp: preference=signencrypt Autocrypt: addr=linuxwolf+ietf@outer-planes.net; prefer-encrypt=mutual; keydata= xsBNBFJoAooBCADQmEtpbpY/4wTeKgZIuyG7HkxIFgiUeqOvtiBKj/pCA73d7Q5hCvQdGcKJ 6uZsYz3Il9oKoKFxVt90iEXspbE39g6ek19e6RsB4j0Q10l4QvH+EqeD760gs0H2yf/eYj9i uk9/VY6axdQlPsmid1zoQgCNjSM7X4/K26WGMs03sbXJpKdoonelzIlJSNfzi0q546iplo72 D2cCm9BriMkQvcGnsm4B9eBIBn3GKmVx1tsmPNeNTyun2DvaLnrYxbA0Ivo1DzZReds9NZ25 uROI/+b+lcg9/kmHzhK+q8NMQCFWmqpS/lZRKxVBSijKGpGr5h8VLVf5iURHtwG+B/QxABEB AAHNLk1hdHRoZXcgQS4gTWlsbGVyIDxsaW51eHdvbGZAb3V0ZXItcGxhbmVzLm5ldD7CwIAE EwEKACoCGwMFCwkIBwMFFQoJCAsFFgIDAQACHgECF4AFCQvHJDEFAlirCeQCGQEACgkQ7PRy ThCeBbt+sAgAzUQokr+f+ArieIrv2JkiQLqiBaZX29Aph9YwG3OPLWSdESEKkFOSJT0LWbsC cAKHLrVfgl2+6iPhf4OOacTdqK7wS6vruPZC1ChdO7NZTgbVa0hP/Q/QKEoaMGNdfc1/lgxY 5kwh+bvGIF1+HyadytgCBBHxdVEhYI7G3ejKqA8iVwri1VW0Wjp8iWdjpF74swIHhid5GcAu 6VJgVNJw3P+WkTkNrkd2tx5yUfNXQuGyFhxwlpiuaOpIk3p74P6e8h/riMpkJ5mIH/ryGTH7 qxpEIuep2bLQZmGwBen8kf3MO/VbiA/NMY6OHdc93EBKr0g7n2BA5uFLdy79FqAA3M7ATQRS aAKKAQgAwP67h8GJUO6XYyWOrcJGXDJnnZEDS+q+bTQXkJMFa74rVIx0yioqY8QdpBJFGaMT 4DCNYe/3pw61ZTDDKqukSCfOh/ssdd8zSGTQZSX5lR4B4+00/LKWugP6iHHHYiETbBVb5bxc aR/LE41Wx3z2HsW3TkeZB6WVk82MTclS1zCuY3p9AeCvr424BSQL7KC38y2eQc95G+nabsVD c6oQ8oZOf1D2giBb2VgbYkSppKj8BKvBtmjCauWeEq/AkZKaDAdua8Qj0vEfgcoh8aavlPJi rqj1YNSyc3AO4R5prPGgTepcUpW8ip8xIPAFoJXfuvsZSV7uVP36gwApU4+ZnwARAQABwsB8 BBgBCgAmAhsMFiEEMddYjeyQaQ1rzJjg7PRyThCeBbsFAlpvpIsFCQvLWoEACgkQ7PRyThCe BbuNHAf/cchJ7kHoIr5i+jgVRuR71AGlxlMbVolnS5tza3bi9Ie63LRdOtMUE3pDUQo25cWd cP7pzwwRBCDD2GxfIuyMCWaES0xtQdTIyNOAFFOtBtCFOrsNEk+iLAu6GBr4QzSQKW1QW4/b vcfpM2pLQn7Zd6naUioEYfTHCMmYHr7hQXaPNEQ7V/J4pLVAN8bHyVgQ9ciQN91DUs6jnueM BUW7DNvuHq0RDzA+ufYdpQAjwl4z1v+rnJ79P3HTxfFdiTTAk9MjyVQklHxS067cmLYkSOku dnCOHhDmSFwkKd9EwOBNuztpjCzmM5SgOT+U/iHH+IM/Hv6bjVCiAQ5WOihe6Q== Message-ID: Date: Mon, 12 Nov 2018 16:55:56 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6yIO4BM3fxTxl6LwZ1kRy82rVyY4MZ6N2" Archived-At: Subject: Re: [CDNi] Error Redirect for URI Signing 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: Mon, 12 Nov 2018 23:56:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6yIO4BM3fxTxl6LwZ1kRy82rVyY4MZ6N2 Content-Type: multipart/mixed; boundary="y5wiF1dNvyZf1a21NaJIGxnZdc5qwRRoz"; protected-headers="v1" From: "Matthew A. Miller" To: Phil Sorber , Chris Lemmons Cc: cdni@ietf.org Message-ID: Subject: Re: [CDNi] Error Redirect for URI Signing References: In-Reply-To: --y5wiF1dNvyZf1a21NaJIGxnZdc5qwRRoz Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable This proposal does not discuss redirect loops at all, which is a serious concern. There is a real potential for a UA to be stuck in a endless loop of redirects. Also, why is this preferred over some form of implementation-specific agreement between the signer and verifier? In order to validate the signature, the verifier must have already established trust with the signer through some means; why is that not appropriate to extend for this type of enhanced behavior? - m&m Matthew A. Miller On 18/11/11 21:15, Phil Sorber wrote: > (as an individual) >=20 > I'm not thrilled with the level of complication this adds. Not only wil= l > you have to have a full URL to redirect the user to on error, but you > will have to capture enough state in the signed token to also redirect > them back and presumably to the point in the token sequence that they > already were as the intent here is to appear seamless. I can think of a= > few ways to do this, but none of them seem good. >=20 > 1. Have the server append the request URL in some fashion to the > redirect URL > 2. Have the destination of the redirect parse the referrer URL > 3. Let the client decide based upon what it may already have stored or= > in cache. This seems a bit hand wavy and we should provide some > guidance to implementers. This also might be incompatible with > things like HLS? >=20 > Is there another solution that you might propose? We should probably > include that in the text as a suggested implementation even if there is= > nothing extra the server or client needs to do. >=20 > This will also make the token even bigger and I suspect very few will > implement it because of that. >=20 > If we adopt this, I think we should condense this to one claim. The > space is already polluted enough. >=20 > (as document editor) >=20 > We also need to have a registry entry for this. >=20 > Thanks. >=20 > On Sat, Nov 3, 2018 at 4:15 AM Chris Lemmons > wrote: >=20 > I've got a draft of some potential language for an error handling > claim in URI Signing. This came as a result of another attempt at a= n > implementation. The content originator wants to set a custom redire= ct > for when a token is out of date or otherwise invalid so the user ag= ent > can go get a new token. >=20 > There are a number of use cases for it, so I think this might be th= e > simplest solution. I don't like having a separate claim for the err= or > code, but it is quite simple to implement and understand. >=20 > Thoughts? >=20 > Link: https://github.com/PSUdaemon/URISigningSpec/pull/56 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni >=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni >=20 --y5wiF1dNvyZf1a21NaJIGxnZdc5qwRRoz-- --6yIO4BM3fxTxl6LwZ1kRy82rVyY4MZ6N2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEMddYjeyQaQ1rzJjg7PRyThCeBbsFAlvqEwwACgkQ7PRyThCe BbtsLAgAz4OVDz2MxHIY0UUS+LVnkITvaCyGVXjZY5L+h10Rx9DPNqG3ah6VHjvk 84fBSR/8/PFjGyjDn4+Am60d1uhZnO2TBy9FYwTbEE+cGL8cZ8kxwZwdgvT5kTkY VAIyxE1glPfkdu6628SvRLN64Qu6MjmfHcBixylAjFjUJr49Hl9yxuvZ0ZG5hkkA 65XtJvnE/iJkAf8ekIXhcdyxfQoZUblRaPlQ1ODD8uTWSVeuvZZ1OMjazrSoReis kgInnduk7QQPucUx4Ng8k6KwGhP6zFo+t/jzcI37vQDCjXy9yLJgRmJm+2uKfFTD bjLAMbCkRMbE6dT6oFeP2deoB3hHZw== =pRbl -----END PGP SIGNATURE----- --6yIO4BM3fxTxl6LwZ1kRy82rVyY4MZ6N2-- From nobody Mon Nov 12 21:16:19 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 199D6126F72 for ; Mon, 12 Nov 2018 21:16:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 spOlQ7lnUkvv for ; Mon, 12 Nov 2018 21:16:16 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 9ABAB128D68 for ; Mon, 12 Nov 2018 21:16:15 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id e5-v6so9685130lja.4 for ; Mon, 12 Nov 2018 21:16:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/vL0D2eaHYZNkj5AmVIUQr4eMaOf9qhnLh4Unc5qVk8=; b=sXSVb7+I941hU23ITbOf2wgq8Eja/xtMu4rQ6CeleaQlb0omWIU5u48dfeoygWYs2s N5v7H6QhamTEv4fs/OqFs9rIggEfSaAcymXWPYCKhj+LQJvYZRYLHmEqf5mAdd5fntjS yKpAwrXcKKzFiJpeXFmChULa5tGT/hAI4smwK4z0zC6ueqCD+jNjALDNJlkqa7MA4E5c /fZ/i6bUBLaJuzQeGhHSRqvGbU6g2P8AHyo3nJ1/NLUNe7/A0DJR9AHqDBFukyNGEPa2 VdAXt3IQQmKaf5ZSSZRDeUS2FtwTY5R/KV7RKuipeT3II/jxa74DEJ4NIddkDHDS/p2C H0Sw== 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=/vL0D2eaHYZNkj5AmVIUQr4eMaOf9qhnLh4Unc5qVk8=; b=JS4Fgc4BFBVRgNjNT3eM9+YUuRv+cZO4++PqntXR5uNM2qt1kOJVzQe8/r3VhK+pXP KPOxikgjSwG9L1w1UGZC9lHVL5mxhyGAyIefPOnjHiboQcJMIiMtAYnPyAohDOYHP1ii LXl4Kry/tACmovEaYHFzHVhUhOHYNxONVE8mnWmUfbNtY0PyM9iShnu3qG+iQsO7JoLO hQFT6dNhHZqJzMiyKJcv/xWNZMUdgUia37gh2cksjvS9v9z307143G/3PQGlMshsvmZL hFX7oeN1pvBfwZWOTxbdh5IYLYew4CLnLdhb3tCJNwChVE0kBNWvlzunUfVqOMZjGutY meBA== X-Gm-Message-State: AGRZ1gL4ZyRMGJtcTv3X89+b52LXT5y8/s3fbDiv6tQYtxLgSgYPUX5n I4hwVAUUrhwxzhsydxcXwLWN/Ux+ACVo0I3+N31fqHrq X-Google-Smtp-Source: AJdET5fHFzGH24mjI8Q92u5A0+Wh92x18pRv0jSu3py6mtu59152LB5gbmnlP755I9ICJFN12ChCHPjnx2KbEjbQmLc= X-Received: by 2002:a2e:59ca:: with SMTP id g71-v6mr2267497ljf.79.1542086173750; Mon, 12 Nov 2018 21:16:13 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Kevin Ma Date: Tue, 13 Nov 2018 00:16:02 -0500 Message-ID: To: Phil Sorber Cc: "" Content-Type: multipart/alternative; boundary="00000000000099781a057a84ea9b" Archived-At: Subject: Re: [CDNi] Shepherd Review of URI Signing 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, 13 Nov 2018 05:16:18 -0000 --00000000000099781a057a84ea9b Content-Type: text/plain; charset="UTF-8" trying again: https://github.com/PSUdaemon/URISigningSpec/pull/60/files On Sun, Nov 11, 2018 at 11:25 PM Phil Sorber wrote: > Kevin, > > Your PR has been made against your own repo and not mine, thus I cannot > merge it. Can you create a PR with it against my repo instead? > > Thanks. > > On Sat, Nov 10, 2018 at 10:39 PM Kevin Ma > wrote: > >> Hi All, >> >> (As chair) As promised, I have performed a shepherd review of the >> latest URI Signing draft. I have submitted a pull request addressing a >> whole bunch of nits: >> https://github.com/kjmietf/URISigningSpec/pull/2/files . Three >> additional questions for the authors: >> >> - general: should RFC3986, RFC5952, RFC6265, and POSIX.1 be normative >> references? They feel normative to me. >> - section 2.1.10: do you want to add a reference for IPv4 address >> notation? >> - section 6.4: Are there any special instructions to the expert >> reviewer? Need to remove the ed note. >> >> I think that the draft will be ready for WGLC once the above issues are >> addressed. >> >> thanx! >> >> -- Kevin J. Ma >> >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >> > --00000000000099781a057a84ea9b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Nov 11, 2018 at 11:25 PM Phil Sorber <sorber@apache.org> wrote:
=
Kevin,

<= /div>
Your PR has been made against your own repo and not mine, thus I = cannot merge it. Can you create a PR with it against my repo instead?
=

Thanks.

On Sat, Nov 10, 2018 at 10:39 PM Kevin Ma <kevin.j.ma.ietf@gmail.com<= /a>> wrote:
_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni
--00000000000099781a057a84ea9b-- From nobody Mon Nov 12 21:36:07 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 BF3ED130DD9 for ; Mon, 12 Nov 2018 21:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 N-6P7HVlt7ma for ; Mon, 12 Nov 2018 21:36:04 -0800 (PST) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 7AF77130DC8 for ; Mon, 12 Nov 2018 21:36:04 -0800 (PST) Received: by mail-lj1-x22e.google.com with SMTP id z80-v6so9701844ljb.8 for ; Mon, 12 Nov 2018 21:36:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HRXniRqRlxfSG7CU8qtfHJ4s+IOcSP+m50wG+adH64w=; b=Ng2RIGjMu45LxgwHnoRC+ALSYL0cBzScIyMTOZgrnhLnCYbr7fNEdr2jGjdB4qz5Qc 0BFVoqEVoC6x4dZK0ykrcFdEegJtt9xRhJ4NDE9WPTDkt4VQazYwsjZBcXPLyxyID/Yf N74KPWQ8z39XH8sG4VgaTRbsoEwFp+KhuWK1NSi+6hqhJFAMCpXF9DDJl2TV1fDY97Jd ukk2iNAGDKLhrkYFVBhfjdzfG/tnZB8aQhNbJ8xzc3GLHF3lo1fggjVB1ytJ0O/0iAx6 9+4wL6/DQzogaLLo3fhkDjgTNidlSOnoDmlPKj1q9BpvK3ce1GF+LwR1dirN9hfmThBw W6SA== 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=HRXniRqRlxfSG7CU8qtfHJ4s+IOcSP+m50wG+adH64w=; b=ASEeUq1epmjE1D5p8w9VnZeJmSrYATqD8Ryd21KsSaUWApZrsTpUygAqki8+cBpxUr BgPFg93zaUsvsVYpgNJaZDqI04aHezJl845fvq4cz+ElRuua5ykMbXMxSWEUWpXGk1bE 6hACZpGvNSMtc55qpvjxxS0mwv2EaNg7MZK0mEOX9hDIoHhPrH0jo94KK359+UANLAYB 3lXuxhMJwpMMgSO9d4q09trHjwADOA3AtU8HmGjt514dUto+DvKaJHwhAuT4vb57pFA0 qN+qmsM9E+dYoIo2PiPh4gAs82SDklw9klympWNIXkkxai52C4mD8mGgUBhPtEHGdYnr TGFg== X-Gm-Message-State: AGRZ1gJskHK3g3zilubosKzkaM6veY++wWH2EHKxCzk58qP+J13jgHp1 gtHFexQYUuk8m1cJP5ZBCjS1lXc1lVZU1tkNtTk= X-Google-Smtp-Source: AJdET5fPkmUOBxKiy58jrHze02XVd34GsWT5XzLVgy+zbokEb5vxXyJUgPny7xQGrZEm50H7r/fqXhsFFa2h3HYjhcc= X-Received: by 2002:a2e:9715:: with SMTP id r21-v6mr5833lji.30.1542087362515; Mon, 12 Nov 2018 21:36:02 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Kevin Ma Date: Tue, 13 Nov 2018 00:35:51 -0500 Message-ID: To: Phil Sorber Cc: "" Content-Type: multipart/alternative; boundary="000000000000749435057a853157" Archived-At: Subject: Re: [CDNi] Shepherd Review of URI Signing 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, 13 Nov 2018 05:36:07 -0000 --000000000000749435057a853157 Content-Type: text/plain; charset="UTF-8" one additional question: - section 2.1.3: Is any CDN allowed to add/modify the audience claim? Can we add explicit text wrt who can/should modify the audience claim? On Tue, Nov 13, 2018 at 12:16 AM Kevin Ma wrote: > trying again: https://github.com/PSUdaemon/URISigningSpec/pull/60/files > > On Sun, Nov 11, 2018 at 11:25 PM Phil Sorber wrote: > >> Kevin, >> >> Your PR has been made against your own repo and not mine, thus I cannot >> merge it. Can you create a PR with it against my repo instead? >> >> Thanks. >> >> On Sat, Nov 10, 2018 at 10:39 PM Kevin Ma >> wrote: >> >>> Hi All, >>> >>> (As chair) As promised, I have performed a shepherd review of the >>> latest URI Signing draft. I have submitted a pull request addressing a >>> whole bunch of nits: >>> https://github.com/kjmietf/URISigningSpec/pull/2/files . Three >>> additional questions for the authors: >>> >>> - general: should RFC3986, RFC5952, RFC6265, and POSIX.1 be normative >>> references? They feel normative to me. >>> - section 2.1.10: do you want to add a reference for IPv4 address >>> notation? >>> - section 6.4: Are there any special instructions to the expert >>> reviewer? Need to remove the ed note. >>> >>> I think that the draft will be ready for WGLC once the above issues >>> are addressed. >>> >>> thanx! >>> >>> -- Kevin J. Ma >>> >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >>> >> --000000000000749435057a853157 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
one additional question:

- section 2.1.= 3: Is any CDN allowed to add/modify the audience claim?=C2=A0 Can we add ex= plicit text wrt who can/should modify the audience claim?

On Tue, Nov 13, 2018 at 12:16 AM = Kevin Ma <kevin.j.ma.ietf@g= mail.com> wrote:

On Sun, Nov 11, 2018 at 11:25 PM Phil Sorber &= lt;sorber@apache.org= > wrote:
Kevin,

Your PR has been made against your own r= epo and not mine, thus I cannot merge it. Can you create a PR with it again= st my repo instead?

Thanks.

On Sat, Nov 10, 2018 at 10:39 PM Ke= vin Ma <k= evin.j.ma.ietf@gmail.com> wrote:
Hi All,

=C2=A0 (As chair) As promised, I have performed a shepherd review o= f the latest URI Signing draft.=C2=A0 I have submitted a pull request addre= ssing a whole bunch of nits:=C2=A0https://github.com/kjmietf/URIS= igningSpec/pull/2/files .=C2=A0 Three additional questions for the auth= ors:

=C2=A0 - general: should RFC3986, RFC5952, RF= C6265, and POSIX.1 be normative references?=C2=A0 They feel normative to me= .
=C2=A0 - section 2.1.10: do you want to add a reference for IPv= 4 address notation?
=C2=A0 - section 6.4: Are there any special i= nstructions to the expert reviewer?=C2=A0 Need to remove the ed note.

=C2=A0 I think that the draft will be ready for WGL= C once the above issues are addressed.

thanx!

--=C2=A0 Kevin J. Ma

<= /div> _______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni
--000000000000749435057a853157-- From nobody Mon Nov 12 21:57: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 25C4D130DD4 for ; Mon, 12 Nov 2018 21:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 HERrLapz6EL6 for ; Mon, 12 Nov 2018 21:57:34 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 C7F43130DC8 for ; Mon, 12 Nov 2018 21:57:33 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id t9-v6so9737339ljh.6 for ; Mon, 12 Nov 2018 21:57:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=95IBZvUgygatSEdEAXRoDKlvub485ldUk+F9YwzKQ8E=; b=TMjIDxWM60lu2TgEAT7ZRRHvHzV8OwPXVKMe2k+q+Nim78y0e+EAAmcxKpeu8d6KLs XK2vhIP9zQyQd4xAXkjC0DwGFS7aMYoMgahptZpOOD+BNKDdJwHitiewgZpXDtb6LKhJ jp1UO9iStfRMh+CgKldmMRB4/opmmn4jMTSdKZuyMNz2MofESWZyPlDaa6ro1VzW5pGp rRpX+Sq+9Qt/wglARx7NzzaO+BORSF0Y6haV73fO94OcoOb+JCqmvsQkvlExPh7UxOL5 tBbMCeG5L98QCfS4E+BCuY06eluQer61V88eP/1MmiPziBC52H+k+2v+cPdviEozYGU4 9Nug== 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=95IBZvUgygatSEdEAXRoDKlvub485ldUk+F9YwzKQ8E=; b=QMbWLG2ot0431DqPptLz3poy+uoCzWDY0NfJ4c/usmO8BnmL6DD/vuuryE21nnigLq RDrhv4iVr15+0pCGmcQ45oBWz+XTC6ctwFNhxf0ukyA0T+ybKdZHm4rzDShFcsuicJzB IUM87+ODCjsBBxQ7kdRB3brPwMoTphoZUOH3mOo8jiGepcJ10W+H9BhsFhJGKXyQIAWT eCqdmr8EauujQgbny9wxLSMl2NhLKewTvxMrW7ZsaQ6Pwx/egs496R3zuZ3G2YwWBJMq HFF8wG97HZ9CLakrPozXfRTEBqwp4Ov6P4wgUOG5UOfDnLWIQLPna3CNTXKyr2N6XwbW bi9Q== X-Gm-Message-State: AGRZ1gKR7ojiUfwvCOYyjVudHbFxEqbe7wmngrWBhJ09X4fh8IFVBVuD gPFKSfMdssJwDhQAtC9zLZvFbt4V0hwdFKgRD86uoVW0 X-Google-Smtp-Source: AJdET5cmMm/JBdjN7uSbIfocS6uywHfJz3xQG2lC9yB1Sy/KTU+/uFGgwHHr8qmEkgSKSs7UTQDWgNEa25ysfShT6OY= X-Received: by 2002:a2e:80d3:: with SMTP id r19-v6mr2292368ljg.151.1542088651810; Mon, 12 Nov 2018 21:57:31 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Kevin Ma Date: Tue, 13 Nov 2018 00:57:20 -0500 Message-ID: To: Chris Lemmons Cc: "" Content-Type: multipart/alternative; boundary="0000000000004daa61057a857e97" Archived-At: Subject: Re: [CDNi] Error Redirect for URI Signing 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, 13 Nov 2018 05:57:37 -0000 --0000000000004daa61057a857e97 Content-Type: text/plain; charset="UTF-8" > Certainly, if you control the client entirely, you can easily specify whatever behaviour you want. [...] it's desirable for a signer to be able to specify the error return in the case of an expired or otherwise invalid token. [...] If the dCDN responds with a redirect back to the uCDN, it can re-evaluate the location, sign a new token, and send the client back to obtain success. I feel like most applications have some level of intelligence on the client side, but for the sake of argument, assuming there is an application that relies on this redirect, automatically doing something about an expired/invalid token, e.g., generating a new valid token, seems to defeat the purpose of having the token, unless there are deeper checks being performed; and if there are deeper checks being performed, it seems to place some (not well defined) responsibility on the CDN to perform those deeper checks? Do you anticipate only the CSP populating the cdnierr and cdnirc claims and all CDNs use the same redirect? Or do you see any/all CDNs along the way being able to change the cdnierr and cdnirc claims? If the latter, do you see the need to be able to limit that in some way and/or set rules on which CDNs can or cannot change the cdnierr and cdnirc claims? If there are no limitations on which CDNs can change the cdnierr and cdnirc claims and/or perform the checks necessary to authorize issuing a new token, it's not clear to me, from an interoperability perspective, how a given CDN in the chain will know what it can/should do with these claims? On Mon, Nov 12, 2018 at 5:16 PM Chris Lemmons wrote: > Certainly, if you control the client entirely, you can easily specify > whatever behaviour you want. Likewise, it's possible to negotiate > special behaviour (which might or might not perfectly comport with the > URI Signing draft) if you only have one CDN to deal with. But if > you've got multiple CDNs or CDNs interconnected, it's desirable for a > signer to be able to specify the error return in the case of an > expired or otherwise invalid token. If you're not in a CDNI > environment, this isn't as critical of an issue. > > You do bring up a potential point, which is "if a uCDN redirects to a > dCDN, should an error redirect that points somewhere on the uCDN also > be rewritten for the dCDN?" I guess that might be nice, but it > significantly complicates things. Instead, I would expect the client > to re-traverse the uCDN and be directed the appropriate resource via > normal channels. > > Re: token bloat. There are a few ways to reduce the size of the token, > but I think simplicity is more important. If an entity controls both > the provider and the user agent, they don't necessarily need this sort > of bloat. But if they do need it, there's no real way around it. > > Inter-CDN interop shouldn't be affected, unless I've missed something. > The error redirect target doesn't necessarily even need to be part of > the same CDN infrastructure, and if it is, it can use the same process > as any other content. > > In terms of the benefit, it means that if either an origin or uCDN is > signing uris to let dCDNs know that the request is authorized, they > can also encode enough information to let the dCDN provide fallback > addresses for requests that fail. > > For example, if a uCDN directs all requests from a particular network > to a dCDN, it may wish to sign it's redirections so that users that > have not been redirected there cannot retrieve content from the dCDN. > If a user agent retrieves a 302 redirect to the dCDN, but then > experiences a delay before resolving the dCDN's content, the dCDN may > reject the token as expired. If the dCDN responds with a 403, the > client is done and gets no data. If the dCDN responds with a redirect > back to the uCDN, it can re-evaluate the location, sign a new token, > and send the client back to obtain success. (Such a uCDN is advised to > be careful to avoid loops, in the event of a permanently incorrect > token being issued, of course.) > > In another situation, a content origin may use a separate cookie or > another mechanism to keep track of authorizations. They can hand out > short-lived tokens and direct generic clients one or more CDNs, but > specify a redirect that goes back to the (perhaps comparatively more > expensive) origin-verification. > > The weakest use case is streaming video, since the redirect won't have > enough information about the specific URI that was requested in order > to actually fulfill the request. Solutions to this scenario are rather > significantly more complex and are probably not worth it. Things like > trying to add the URI as query strings or similar wind up causing more > problems than they solve, I think. Technically, I think you could do > it with a template system: "cdnierr": > "http://fallback.example.com/r?failed=$uri_base64&reason=$err_code". > That's clearly powerful... but also requires a parsing engine, > complete with escapes. But it's hard to beat the simplicity of "Put > this value, unmodified, in the Location header and return this status > code". > > As noted, if we like the idea, we also need a registry entry or two > for it, and probably an example. > On Tue, Nov 6, 2018 at 2:20 PM Kevin Ma wrote: > > > > Hi Chris, > > > > (As a chair) My initial thoughts on the PR is that it doesn't really > address a CDNI issue. What a CSP might want a UA to do when token > validation fails is not really in scope of CDNI, and can be handled other > ways by the UA (without bloating the token)? > > > > (As an individual) The proposed feature seems to make inter-CDN > interoperability for URI signing more complex (and that would need to be > fleshed out more and reflected in the sequence diagrams in Section 5). I'm > not sure that I see the benefit (over letting the client implement 403 > handling), without a more concrete use case. > > > > thanx. > > > > -- Kevin J. Ma > > > > > > On Sat, Nov 3, 2018 at 6:15 AM Chris Lemmons wrote: > >> > >> I've got a draft of some potential language for an error handling > >> claim in URI Signing. This came as a result of another attempt at an > >> implementation. The content originator wants to set a custom redirect > >> for when a token is out of date or otherwise invalid so the user agent > >> can go get a new token. > >> > >> There are a number of use cases for it, so I think this might be the > >> simplest solution. I don't like having a separate claim for the error > >> code, but it is quite simple to implement and understand. > >> > >> Thoughts? > >> > >> Link: https://github.com/PSUdaemon/URISigningSpec/pull/56 > >> > >> _______________________________________________ > >> CDNi mailing list > >> CDNi@ietf.org > >> https://www.ietf.org/mailman/listinfo/cdni > --0000000000004daa61057a857e97 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Certainly, if you control the client entirely, y= ou can easily specify whatever behaviour you want.=C2=A0 [...]=C2=A0 it'= ;s desirable for a
signer to be able to specify the error return i= n the case of an expired or otherwise invalid token.=C2=A0 [...]=C2=A0 If t= he dCDN responds with a redirect back to the uCDN, it can re-evaluate the l= ocation,=C2=A0sign a new token, and send the client back to obtain success.=

I feel like most applications have some level of intell= igence on the client side, but for the sake of argument, assuming there is = an application that relies on this redirect, automatically doing something = about an expired/invalid token, e.g., generating a new valid token, seems t= o defeat the purpose of having the token, unless there are deeper checks be= ing performed; and if there are deeper checks being performed, it seems to = place some (not well defined) responsibility on the CDN to perform those de= eper checks?

Do you anticipate only the CSP popula= ting the cdnierr and cdnirc claims and all CDNs use the same redirect?=C2= =A0 Or do you see any/all CDNs along the way being able to change the cdnie= rr and cdnirc claims?=C2=A0 If the latter, do you see the need to be able t= o limit that in some way and/or set rules on which CDNs can or cannot chang= e the cdnierr and cdnirc claims?=C2=A0 If there are no limitations on which= CDNs can change the cdnierr and cdnirc claims and/or perform the checks ne= cessary to authorize issuing a new token, it's not clear to me, from an= interoperability perspective, how a given CDN in the chain will know what = it can/should do with these claims?



On Mon, Nov 12, 2018 at 5= :16 PM Chris Lemmons <alficles@gma= il.com> wrote:
Certainly, if= you control the client entirely, you can easily specify
whatever behaviour you want. Likewise, it's possible to negotiate
special behaviour (which might or might not perfectly comport with the
URI Signing draft) if you only have one CDN to deal with. But if
you've got multiple CDNs or CDNs interconnected, it's desirable for= a
signer to be able to specify the error return in the case of an
expired or otherwise invalid token. If you're not in a CDNI
environment, this isn't as critical of an issue.

You do bring up a potential point, which is "if a uCDN redirects to a<= br> dCDN, should an error redirect that points somewhere on the uCDN also
be rewritten for the dCDN?" I guess that might be nice, but it
significantly complicates things. Instead, I would expect the client
to re-traverse the uCDN and be directed the appropriate resource via
normal channels.

Re: token bloat. There are a few ways to reduce the size of the token,
but I think simplicity is more important. If an entity controls both
the provider and the user agent, they don't necessarily need this sort<= br> of bloat. But if they do need it, there's no real way around it.

Inter-CDN interop shouldn't be affected, unless I've missed somethi= ng.
The error redirect target doesn't necessarily even need to be part of the same CDN infrastructure, and if it is, it can use the same process
as any other content.

In terms of the benefit, it means that if either an origin or uCDN is
signing uris to let dCDNs know that the request is authorized, they
can also encode enough information to let the dCDN provide fallback
addresses for requests that fail.

For example, if a uCDN directs all requests from a particular network
to a dCDN, it may wish to sign it's redirections so that users that
have not been redirected there cannot retrieve content from the dCDN.
If a user agent retrieves a 302 redirect to the dCDN, but then
experiences a delay before resolving the dCDN's content, the dCDN may reject the token as expired. If the dCDN responds with a 403, the
client is done and gets no data. If the dCDN responds with a redirect
back to the uCDN, it can re-evaluate the location, sign a new token,
and send the client back to obtain success. (Such a uCDN is advised to
be careful to avoid loops, in the event of a permanently incorrect
token being issued, of course.)

In another situation, a content origin may use a separate cookie or
another mechanism to keep track of authorizations. They can hand out
short-lived tokens and direct generic clients one or more CDNs, but
specify a redirect that goes back to the (perhaps comparatively more
expensive) origin-verification.

The weakest use case is streaming video, since the redirect won't have<= br> enough information about the specific URI that was requested in order
to actually fulfill the request. Solutions to this scenario are rather
significantly more complex and are probably not worth it. Things like
trying to add the URI as query strings or similar wind up causing more
problems than they solve, I think. Technically, I think you could do
it with a template system: "cdnierr":
"http://fallback.examp= le.com/r?failed=3D$uri_base64&reason=3D$err_code".
That's clearly powerful... but also requires a parsing engine,
complete with escapes. But it's hard to beat the simplicity of "Pu= t
this value, unmodified, in the Location header and return this status
code".

As noted, if we like the idea, we also need a registry entry or two
for it, and probably an example.
On Tue, Nov 6, 2018 at 2:20 PM Kevin Ma <kevin.j.ma.ietf@gmail.com> wrote: >
> Hi Chris,
>
>=C2=A0 =C2=A0(As a chair) My initial thoughts on the PR is that it does= n't really address a CDNI issue.=C2=A0 What a CSP might want a UA to do= when token validation fails is not really in scope of CDNI, and can be han= dled other ways by the UA (without bloating the token)?
>
>=C2=A0 =C2=A0(As an individual) The proposed feature seems to make inte= r-CDN interoperability for URI signing more complex (and that would need to= be fleshed out more and reflected in the sequence diagrams in Section 5).= =C2=A0 I'm not sure that I see the benefit (over letting the client imp= lement 403 handling), without a more concrete use case.
>
> thanx.
>
> --=C2=A0 Kevin J. Ma
>
>
> On Sat, Nov 3, 2018 at 6:15 AM Chris Lemmons <alficles@gmail.com> wrote:
>>
>> I've got a draft of some potential language for an error handl= ing
>> claim in URI Signing. This came as a result of another attempt at = an
>> implementation. The content originator wants to set a custom redir= ect
>> for when a token is out of date or otherwise invalid so the user a= gent
>> can go get a new token.
>>
>> There are a number of use cases for it, so I think this might be t= he
>> simplest solution. I don't like having a separate claim for th= e error
>> code, but it is quite simple to implement and understand.
>>
>> Thoughts?
>>
>> Link: https://github.com/PSUdaemon/URISi= gningSpec/pull/56
>>
>> _______________________________________________
>> CDNi mailing list
>> CDNi@ietf.org
>> https://www.ietf.org/mailman/listinfo/cdni
--0000000000004daa61057a857e97-- From nobody Mon Nov 12 23:53:46 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 5252F12D4EB for ; Mon, 12 Nov 2018 23:53:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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 Xgb5WHRPQOQe for ; Mon, 12 Nov 2018 23:53:41 -0800 (PST) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 95E9B1252B7 for ; Mon, 12 Nov 2018 23:53:40 -0800 (PST) Received: by mail-wm1-x32c.google.com with SMTP id p2-v6so10378981wmc.2 for ; Mon, 12 Nov 2018 23:53:40 -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=dosP+42SN5Kyv6qWH0C95Oq4F2MLO/9/lmK0vHhfV28=; b=q6RZc2DIzXrE+PAtccWhNXhcsUt8cXxMpudadbrHipFeBn6dhYCnY9RZ+X6HOhr9pq pZoUR4hMar70gqlIVtAAIlx37sTK3kKrGqjyOlv37J5L9TX1tYm9f/aiUCq//FawakLq hukqnD/TzG9Y3cyG0XdZykcmqErm/2vJtTSL2KflV89YjC6mbYsG/oL7sbvUS6f1Poml AhNfMX3wvMUuXE0zLLdko4uoQXzhDjvhkqOU35nrRl2tomv+h3Hmq+6DfTPRSKtaTul5 d01GEnam12vyijFeteso16+6wCq42Hccs62qKEBTY94SwySKShsjfuikuZdq7CRHDzH7 gGrw== 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=dosP+42SN5Kyv6qWH0C95Oq4F2MLO/9/lmK0vHhfV28=; b=N89OCEmEp1QQPYlp82EVPrKd7OVSaj4qLEcmkIYMwH9w07u12nUdr7JipZ/DUcgaru gJH0oBMEcfs7EQibqwOnSLvqAtmEN3YXgRkiZClaxdwyjv/hX9roCUcoYm2cWDoFygzx 7OuSquqOqRTWSSx1KDW7d/A4peoXw3d5TpdRTV1N4Y2Mj42+/8qkLa4jVvGpMz8M/MiQ ZeT/NXS1fj3L5cuOxqTYXvEOLi36WSLhIPIvsAiBeWdyoZEeuMNUqH652R+NGeWkDekI cJMJval+A2ay4+hSat8Ax3JIHHMAFqPKFx4ACOh3D3spg/CUZRV48QwDJEJpy0/py5PL XYOw== X-Gm-Message-State: AGRZ1gKApuIk678TbbORZP6uLRb+IGzkvY5zohborkBJtyz8d6Oi0qhN O30xeToOkl7Ix2sOBoa9HlnHSEyVJKg5XkZdiG8zrg== X-Google-Smtp-Source: AJdET5fOfff+Tz+uqMVaBpNAHi+68jBsImZA97lZttgD3ar2HCkrqGEC1NGBGiUd4jAZP29p9viaL5JLnG02PHHyVKY= X-Received: by 2002:a1c:545e:: with SMTP id p30-v6mr2193322wmi.69.1542095618538; Mon, 12 Nov 2018 23:53:38 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ori Finkelman Date: Tue, 13 Nov 2018 09:53:09 +0200 Message-ID: To: Chris Lemmons Cc: Phil Sorber , "" Content-Type: multipart/alternative; boundary="0000000000008d94de057a871d24" 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, 13 Nov 2018 07:53:45 -0000 --0000000000008d94de057a871d24 Content-Type: text/plain; charset="UTF-8" Hi Chris, I might be missing your exact intention, but I think that the dCDN need to reduce their local offset, in each location, rather than adding it. For example: Suppose you want a trigger to run at 02:30 AM, local time, in each and every location, so you communicate that as 02:30AM in UTC time and set the local-offset to true. Now, if you are located, like me, in Israel and your local offset is +02:00, and you want it to be executed at 02:30AM in Israel, you need to reduce 2 hours from the UTC epoch so that the resulting epoch would be at 02:30AM IL time. OTOH, if you are located in Denver and your offset is -07:00, and you want the trigger to run at 02:30AM Denver time, you need to reduce -07:00 (add 7 hours) to get the correct epoch. Thanks, Ori On Tue, Nov 13, 2018 at 12:46 AM 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. > > 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 > -- *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com --0000000000008d94de057a871d24 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Chris,=C2=A0
I might be missing your exact intentio= n, but I think that the dCDN need to reduce their local offset, in each loc= ation, rather than adding it.
For=C2=A0example:
Suppose= you want a trigger to run at 02:30 AM, local time, in each and every locat= ion, so you communicate that as 02:30AM in UTC time=C2=A0 and set the local= -offset to true.
Now, if you are loc= ated, like me, in Israel and your local offset is=C2=A0+02:00, and you want= it to be executed at 02:30AM in Israel, you need to reduce 2 hours from th= e UTC epoch so that=C2=A0
the= resulting epoch would be at 02:30AM IL time.
OTOH, if you are located in Denver and your offset is -07= :00, and you want the trigger to run at 02:30AM Denver time, you need to re= duce -07:00 (add 7 hours) to get the correct epoch.=C2=A0
=
Thanks,
Ori
=

On Tue, Nov 13, 2018 = at 12:46 AM Chris Lemmons <alficle= s@gmail.com> 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.

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 co= nfusion.
> 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) b= ut the time zone was not supposed to be 0, it is just unknown, and is there= fore using 0.
>
> Also, it seems that ISO8601 also has a "local time" where yo= u just don't include an offset:
> >> This actually means that time is in the local time of the cal= ler, 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 agai= n, if for example the trigger server is located at NY, then 4AM will mean 4= AM 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 t= o 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#section-= 4.3
>>
>> using the -0000 offset to signify local time.
>
> >> This means that the time is actually in UTC (same as +0000) b= ut the time zone was not supposed to be 0, it is just unknown, and is there= fore using 0.
>>
>>
>> Also, it seems that ISO8601 also has a "local time" wher= e you just don't include an offset:
>
> >> This actually means that time is in the local time of the cal= ler, 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/I= SO_8601#Time_zone_designators
>>
>> "If no UTC relation information is given with a time represen= tation, 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 th= an the callers local time, but then again, if for example the trigger serve= r is located at NY, then the 4AM will mean local time in NY. Using it to de= signate 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 i= s 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 t= ime at the trigger destination where there are multiple destination locatio= ns 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 o= wn 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 se= conds 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 seco= nds 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, bu= t 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 pr= ices 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 requ= ire calling a separate trigger for each region.
>>>>
>>>> While working on adding this "local-time" flag, = I have realized that TimeWindow as defined in htt= ps://tools.ietf.org/html/rfc8006#section-4.2.3.2 in UTC and it is bette= r not be used to represent local time.
>>>> The only option I can think of using textual time format a= s 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&quo= t;.
>>>> Using RFC3339 means we need to add a new time object inste= ad of the TimeWindow.
>>>>
>>>> Thoughts ?
>>>>
>>>> Thanks,
>>>> Ori
>>>>
>>>>
>>>> On Sun, Jul 22, 2018 at 9:19 AM Ori Finkelman <orif@qwilt.com> wrote:<= br> >>>>>
>>>>> Here are the comments we got CDNI meeting.
>>>>>
>>>>> Playlist:
>>>>> change abr-protocol to media-protocol, as it may be us= ed for other media rather than video abr.
>>>>>
>>>>> Trigger TimePolicy:
>>>>> Add local-time flag. When true the trigger should be e= xecuted at the local time, per zone.
>>>>>
>>>>> Trigger error and warning propagation:
>>>>> Considering triggers may be propagated to a chain of d= CDNs, and considering we allow extensions to be safe-to-redistribute even i= f not understood, we should add a mechanism for propagating errors and warn= ings back to the uCDN.
>>>>>
>>>>> Thanks,
>>>>> Ori
>>>>>
>>>>> --
>>>>> Ori Finkelman
>>>>> Qwilt | Work: +972-72-2221647 | Mobile: +972-52-383218= 9 | orif@qwilt.com<= br> >>>>
>>>>
>>>>
>>>> --
>>>> 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.o= rg
>>> 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


--
Ori Finkelman
Qwilt | Work: +972-72-2221647 | Mobile: +972-52= -3832189 | orif@qwilt.com
--0000000000008d94de057a871d24-- From nobody Tue Nov 13 06:54:05 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 5C8A4130DE0 for ; Tue, 13 Nov 2018 06:54:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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=Yhq8eQ3m; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BOY2ypJC 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 imb8qEg6mesN for ; Tue, 13 Nov 2018 06:54:01 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55676130DDC for ; Tue, 13 Nov 2018 06:54:01 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 2940E20BA5; Tue, 13 Nov 2018 09:54:00 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Tue, 13 Nov 2018 09:54:00 -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:references:in-reply-to:subject:date; s=fm1; bh=YTb Lezwelw/PAeTPxOs+bqDkYia/1jwkBUFUOLOpjw0=; b=Yhq8eQ3mSag3SldNisq ZoBVBJUnnwy9XePpV6REBUhu5UD2XP20inz15Wle0Lx3k/GRMrAaA1AoZeWSOkNB trasySk6Da2lwvna5G+khRg8aY1hKMjzuOskLheZwOOnWzIcurBHPmyzbNVW2AW+ 3C1FgKx9RiWcXxtnLZoNiOqvp9ojol01BEktga2d1izE3A2y5tbjckcP9fE0gh8O PesYymwV9yrgfgH9NoVv5kBcuNF7DQxdrgwiL31P9BB/H+CdpeaoY9NirxdxxHOF JxWU13My2VIlOgJJoGdlhL7iZycfYi1fnLU/wucsuGTWoyG9OpDSXgjO7rQxubKp TZA== 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=YTbLezwelw/PAeTPxOs+bqDkYia/1jwkBUFUOLOpj w0=; b=BOY2ypJCLumx+OObYp9jL6OvWZIohEIPig28v0gmrllg8F9ILGXwRNJ66 RO7M7bFpbgF+lWLNVcd/l2zTpcPfay5TkoOb2eKTQ4K1K/mut8fQRnStAUj059LS MqAgOGqMp0k9LMSVOQSwIe3T9B34ISSkrw52tbUZoEDjzMe4XsM9QaoDaZo8lWCU 16KbV32X2+qhnJYFlvsL06PxnpQoMw6bdLq7uA2rU8buD10CT9sNY3dh7W34pY6W Qd6my0Jd2VnOuXxl2sHyjRGAdq+LGuarIERUZX1mwofsfx5ocESWWJmEsvux1mD5 QNowi3yHKeC5pyGnB3qsi5O12bKkA== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 85D0E9E1AB; Tue, 13 Nov 2018 09:53:59 -0500 (EST) Message-Id: <1542120839.3452626.1575386224.226D0485@webmail.messagingengine.com> From: Alexey Melnikov To: Chris Lemmons , Ori Finkelman Cc: cdni@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-2d882eb6 References: In-Reply-To: Date: Tue, 13 Nov 2018 14:53:59 +0000 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, 13 Nov 2018 14:54:04 -0000 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 From nobody Tue Nov 13 09:15:01 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 169CF128B14 for ; Tue, 13 Nov 2018 09:15:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 wilGtvevD-Gk for ; Tue, 13 Nov 2018 09:14:51 -0800 (PST) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 59979128CF2 for ; Tue, 13 Nov 2018 09:14:51 -0800 (PST) Received: by mail-wr1-x42b.google.com with SMTP id y3-v6so14170855wrh.10 for ; Tue, 13 Nov 2018 09:14:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=M6gTarMLapUhamUqCR0+Y6fIekKLQd6Vfpxd5aYlRUY=; b=KRpM452yzsQ8bgDXKWOR5GlE4mBO8D2CfcGfFooXtTwi0RbWyMAwgA4fTg7uF7L6Iv Dq4g/Dd5or6XzOyegeoUdmw5YoxbcRYjed2u1m6ToyfraIMj8XUS22lxtXelb8PTyM/a dyu+4UiYFr75SKpeotILdHWJDzLAaT+55I3g2g8z8Rye6/z4t48P4BTJDUbvL+sv+pMk digrcn3+5bXLzU/JB0NIE3Cz9xYP8BNVjwBvMlGaPbpyEdlu2hH63/qXLrGEKT7m1/H1 LokdoG1d7H392yL3oBG/b4yluvgrJdCngtEgdLi7aQhzVMikg3RUoiBRtGqkvTXidu6K an/Q== 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:content-transfer-encoding; bh=M6gTarMLapUhamUqCR0+Y6fIekKLQd6Vfpxd5aYlRUY=; b=tnWO5uAM8oTeF8IzPV3xkPUNwYx6lBTnOmKX68HfzA85pfb7UGYqYNgMZ/8Zw9VpT/ A1aaicsTB4zITp0PJ0OaNnzCY98M4c3PDDRk5J0arc1YQ4kfFrUBJnSp3HhhIMX3OIjX TiaRy1TngrIp7hnfTdRxNzXiBCA9HgrFgXCv/K2LWt/EmzJRbhw/Co+JKKakNLs1rtXE uSvNh79vFgVecoRBRmlK1k2ZVj+6L0i3IkIix9a30xFCexqDOyfyH3vcrhDk7DOXOu9h A9UVIIyMiMtUdfxbrS0/GMEkSwoZ790hc5md8r6H89paSrqZXJVwPBVykDsb7MtSvr07 9Xsw== X-Gm-Message-State: AGRZ1gIJ/gDurEq5NTZcmVqPmH3WxwUE9FyQB3EllODKnXWt3pw+MG6d XHEiY2fxvhFGPes4P5179tWKjzRw2Wg4AoC13YKsv6k0 X-Google-Smtp-Source: AJdET5dq6VFnY1ABX63dU3VS3BBbV3xfwIqLjR6QmqNiwqOpCZS6kEkPfcuGFjbeZdbPMudR/pQ7JwmAIqYA3q+5VdA= X-Received: by 2002:adf:e28c:: with SMTP id v12-v6mr5973949wri.26.1542129289309; Tue, 13 Nov 2018 09:14:49 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Chris Lemmons Date: Tue, 13 Nov 2018 10:14:37 -0700 Message-ID: To: kevin.j.ma.ietf@gmail.com Cc: cdni@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [CDNi] Error Redirect for URI Signing 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, 13 Nov 2018 17:15:00 -0000 > If there are no limitations on which CDNs can change the cdnierr and cdni= rc claims and/or perform the checks necessary to authorize issuing a new to= ken, it's not clear to me, from an interoperability perspective, how a give= n CDN in the chain will know what it can/should do with these claims? Ah, yeah. I didn't put that text in, but I expected that CDNs MUST NOT change the cdnierr claims when redirecting. Everything else goes outside of interoperability, which is fine, but then subject to negotiation between the signer and CDN. > Do you anticipate only the CSP populating the cdnierr and cdnirc claims a= nd all CDNs use the same redirect? Depends on the particular use case. In the simplest use case, where a uCDN is redirecting clients based on geolocation or network information, a client might change IPs, wait too long, or retry a request after a nonce has been used. In such a case, recovery is simple, just go back to the uCDN and let geolocation do it's thing. This use case will mean that the signer (in this case, the uCDN), will put the URL of the unredirected request (plus a tag that allows it to detect loops, which should definitely be clarified in the text), in the cdnierr. In the case where the CSP is using it to authorize a client for CDN resources (potentially on one or more CDNs, possibly stacked) that already has a session on the CSPs server, the CSP may be happy to re-issue tokens to a client that has one that no longer works. It will use the same mechanism it used in the first place, probably a session cookie, to verify that the client is authorized, then send them back to the CDN for the actual content. This back-and-forth isn't necessarily ideal, but could allow a CSP to use a more restrictive token policy, safe in the knowledge that if the the client changes IP or pauses for too long, or otherwise winds up with a bad token, they can just redirect through the CSP's servers to get a new one. In this case, the CSP is likely to use an endpoint locally that redirects to the CDN, probably the same endpoint they used originally to reference the content. In the case where the CSP is using it to provide "fallback" content, they might use a static value. For example, if the content to be distributed is media thumbnails, the CSP might prefer that if a token is invalid, the user be redirected to a generic image instead of getting a blank field. In a custom app, this behaviour can be implemented directly, but using standard status codes and redirections allows the browser to simply take charge. If the CSP has a single CDN, they can reasonably negotiate this behaviour, but in an interconnected context, it's better to put the CSP in the driver's seat, I think. > Also, why is this preferred over some form of implementation-specific > agreement between the signer and verifier? In order to validate the > signature, the verifier must have already established trust with the > signer through some means; why is that not appropriate to extend for > this type of enhanced behavior? You're right that we don't need to specify all possible implementation options here. But we should specify implementation options that will impact interoperability. In this case, a signer cannot use this claim unless it's supported by every CDN it uses. That argues for standardization. ... but doesn't necessarily argue for standardization immediately. I'm starting to be of the mind that the implications this claim are complex enough to really require implementation experience before we really standardize it. We can reasonably easily add claims in future documents, if we so choose. The already extant crit claim gives us the required compatibility as well. Is there a compelling reason we shouldn't table this, ideally get some implementation experience around it, then bring it back if experience warrants? On Mon, Nov 12, 2018 at 10:57 PM Kevin Ma wrote= : > > > Certainly, if you control the client entirely, you can easily specify w= hatever behaviour you want. [...] it's desirable for a > signer to be able to specify the error return in the case of an expired o= r otherwise invalid token. [...] If the dCDN responds with a redirect bac= k to the uCDN, it can re-evaluate the location, sign a new token, and send = the client back to obtain success. > > I feel like most applications have some level of intelligence on the clie= nt side, but for the sake of argument, assuming there is an application tha= t relies on this redirect, automatically doing something about an expired/i= nvalid token, e.g., generating a new valid token, seems to defeat the purpo= se of having the token, unless there are deeper checks being performed; and= if there are deeper checks being performed, it seems to place some (not we= ll defined) responsibility on the CDN to perform those deeper checks? > > Do you anticipate only the CSP populating the cdnierr and cdnirc claims a= nd all CDNs use the same redirect? Or do you see any/all CDNs along the wa= y being able to change the cdnierr and cdnirc claims? If the latter, do yo= u see the need to be able to limit that in some way and/or set rules on whi= ch CDNs can or cannot change the cdnierr and cdnirc claims? If there are n= o limitations on which CDNs can change the cdnierr and cdnirc claims and/or= perform the checks necessary to authorize issuing a new token, it's not cl= ear to me, from an interoperability perspective, how a given CDN in the cha= in will know what it can/should do with these claims? > > > > On Mon, Nov 12, 2018 at 5:16 PM Chris Lemmons wrote: >> >> Certainly, if you control the client entirely, you can easily specify >> whatever behaviour you want. Likewise, it's possible to negotiate >> special behaviour (which might or might not perfectly comport with the >> URI Signing draft) if you only have one CDN to deal with. But if >> you've got multiple CDNs or CDNs interconnected, it's desirable for a >> signer to be able to specify the error return in the case of an >> expired or otherwise invalid token. If you're not in a CDNI >> environment, this isn't as critical of an issue. >> >> You do bring up a potential point, which is "if a uCDN redirects to a >> dCDN, should an error redirect that points somewhere on the uCDN also >> be rewritten for the dCDN?" I guess that might be nice, but it >> significantly complicates things. Instead, I would expect the client >> to re-traverse the uCDN and be directed the appropriate resource via >> normal channels. >> >> Re: token bloat. There are a few ways to reduce the size of the token, >> but I think simplicity is more important. If an entity controls both >> the provider and the user agent, they don't necessarily need this sort >> of bloat. But if they do need it, there's no real way around it. >> >> Inter-CDN interop shouldn't be affected, unless I've missed something. >> The error redirect target doesn't necessarily even need to be part of >> the same CDN infrastructure, and if it is, it can use the same process >> as any other content. >> >> In terms of the benefit, it means that if either an origin or uCDN is >> signing uris to let dCDNs know that the request is authorized, they >> can also encode enough information to let the dCDN provide fallback >> addresses for requests that fail. >> >> For example, if a uCDN directs all requests from a particular network >> to a dCDN, it may wish to sign it's redirections so that users that >> have not been redirected there cannot retrieve content from the dCDN. >> If a user agent retrieves a 302 redirect to the dCDN, but then >> experiences a delay before resolving the dCDN's content, the dCDN may >> reject the token as expired. If the dCDN responds with a 403, the >> client is done and gets no data. If the dCDN responds with a redirect >> back to the uCDN, it can re-evaluate the location, sign a new token, >> and send the client back to obtain success. (Such a uCDN is advised to >> be careful to avoid loops, in the event of a permanently incorrect >> token being issued, of course.) >> >> In another situation, a content origin may use a separate cookie or >> another mechanism to keep track of authorizations. They can hand out >> short-lived tokens and direct generic clients one or more CDNs, but >> specify a redirect that goes back to the (perhaps comparatively more >> expensive) origin-verification. >> >> The weakest use case is streaming video, since the redirect won't have >> enough information about the specific URI that was requested in order >> to actually fulfill the request. Solutions to this scenario are rather >> significantly more complex and are probably not worth it. Things like >> trying to add the URI as query strings or similar wind up causing more >> problems than they solve, I think. Technically, I think you could do >> it with a template system: "cdnierr": >> "http://fallback.example.com/r?failed=3D$uri_base64&reason=3D$err_code". >> That's clearly powerful... but also requires a parsing engine, >> complete with escapes. But it's hard to beat the simplicity of "Put >> this value, unmodified, in the Location header and return this status >> code". >> >> As noted, if we like the idea, we also need a registry entry or two >> for it, and probably an example. >> On Tue, Nov 6, 2018 at 2:20 PM Kevin Ma wrot= e: >> > >> > Hi Chris, >> > >> > (As a chair) My initial thoughts on the PR is that it doesn't really= address a CDNI issue. What a CSP might want a UA to do when token validat= ion fails is not really in scope of CDNI, and can be handled other ways by = the UA (without bloating the token)? >> > >> > (As an individual) The proposed feature seems to make inter-CDN inte= roperability for URI signing more complex (and that would need to be fleshe= d out more and reflected in the sequence diagrams in Section 5). I'm not s= ure that I see the benefit (over letting the client implement 403 handling)= , without a more concrete use case. >> > >> > thanx. >> > >> > -- Kevin J. Ma >> > >> > >> > On Sat, Nov 3, 2018 at 6:15 AM Chris Lemmons wrot= e: >> >> >> >> I've got a draft of some potential language for an error handling >> >> claim in URI Signing. This came as a result of another attempt at an >> >> implementation. The content originator wants to set a custom redirect >> >> for when a token is out of date or otherwise invalid so the user agen= t >> >> can go get a new token. >> >> >> >> There are a number of use cases for it, so I think this might be the >> >> simplest solution. I don't like having a separate claim for the error >> >> code, but it is quite simple to implement and understand. >> >> >> >> Thoughts? >> >> >> >> Link: https://github.com/PSUdaemon/URISigningSpec/pull/56 >> >> >> >> _______________________________________________ >> >> CDNi mailing list >> >> CDNi@ietf.org >> >> https://www.ietf.org/mailman/listinfo/cdni From nobody Wed Nov 14 01:02:59 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 6D1E2130DF3 for ; Wed, 14 Nov 2018 01:02:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] 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 G3PkuVarNbLQ for ; Wed, 14 Nov 2018 01:02:52 -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 6607C12D4EB for ; Wed, 14 Nov 2018 01:02:52 -0800 (PST) Received: by mail-wr1-x42a.google.com with SMTP id z16-v6so16370606wrv.2 for ; Wed, 14 Nov 2018 01:02:52 -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=VOYjyHWGm3ayXwFcIWAmGWkDdfwa0Lr8XRWPsWhch/Y=; b=czFJVpD0b29LKsaR9bNrDmxC/qAS1/tHXt6e+WbuAmmtUQzXVf5B28HHIl+GOVtatC G3qJIeOiT9Fsq2svP0uMSWBz+JquPwVzts9frPYpteuMRcOCP2Su5xXvUmvyphIzerZw iwV5iO2hkG0lymBQnrGXHGpZO3FPNF9RxxqcskEKhRqwthqusM12r9ssh/YtVAH11b+Q A+4PkBrjI4jn3gWRz6GIOND4Fh2WWBW/PY4t6xpFKlUdqpGfFRphtCs14oTnbFgEb+0z jepeXjm7Wd1F44myQqSfqms0yft5jEa2I6DPWvPpiiV45MfbKhY4aBK6YLxDQVECE02E C+AA== 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=VOYjyHWGm3ayXwFcIWAmGWkDdfwa0Lr8XRWPsWhch/Y=; b=P2ob4ytccGvfQTc/fasvns03zIOsaCdqiMwI8pN4T0rP2rzYi5a42kHRLLvRKbe2wA RmtOAkTmTLQKESRmOYDKeqgTvOlODGLSV8iuHx1rz3ujwD/vK9kXq/1hGAGfSddEO885 5yK964v6nYwKORswxrh3xmrvvbQlcA7n+nNx6RqCt52drPIBHtdURdDSRAHUiyo0cH0R 2zy/UnTDenBQOSGTf/7KAjL+Ut+L/PpoLWJ/PL4JRW9x7Pbr3t62oZ6xAdNKkS2v8u1H wjnKHpKwzFUcEdcYoQfvdYb4yyeEBR1MeUJ0H45Jwl14o4/EAF2gStxQ8ke5FgjZKeo2 6eNA== X-Gm-Message-State: AGRZ1gLHOY3hcVCfHf2wShtSRFa7md7VW7vKKdNGp9FukGWrGEVcTYXf Wy6pkGxRdP+1I4DlOKo5wF+FHPXRcHv8Thk81nuXHw== X-Google-Smtp-Source: AJdET5edtHSSJt8Yah3nSyX5vl7ZLmPvnWjqmz/4lhsemRoZk8N8AjP9sQHLbIZlLXo6+zgNbheZtXyC/Bz9UyIaZuM= X-Received: by 2002:a5d:4286:: with SMTP id k6mr963892wrq.225.1542186170411; Wed, 14 Nov 2018 01:02:50 -0800 (PST) MIME-Version: 1.0 References: <1542120839.3452626.1575386224.226D0485@webmail.messagingengine.com> In-Reply-To: <1542120839.3452626.1575386224.226D0485@webmail.messagingengine.com> From: Ori Finkelman Date: Wed, 14 Nov 2018 11:02:20 +0200 Message-ID: To: aamelnikov@fastmail.fm Cc: Chris Lemmons , "" Content-Type: multipart/alternative; boundary="000000000000dd7d19057a9c32ec" 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: Wed, 14 Nov 2018 09:02:58 -0000 --000000000000dd7d19057a9c32ec Content-Type: text/plain; charset="UTF-8" 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 --000000000000dd7d19057a9c32ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Alexey,
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
Qwilt | Work: +972-72-2221647 | Mobile: +972-52= -3832189 | orif@qwilt.com
--000000000000dd7d19057a9c32ec-- From nobody Thu Nov 15 04:56: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 5C50C129385 for ; Thu, 15 Nov 2018 04:56:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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 ujx6WiWzGCWP for ; Thu, 15 Nov 2018 04:56:31 -0800 (PST) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 7CAB0128D0C for ; Thu, 15 Nov 2018 04:56:31 -0800 (PST) Received: by mail-wr1-x431.google.com with SMTP id j26-v6so21119024wre.1 for ; Thu, 15 Nov 2018 04:56:31 -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=Xs36vxCYRTzkNit/U0iWtMhP/Jb7KjJrJ5Tu4A3gG8w=; b=nLTpZtz+96xAQ3MxPNAalKrCANj3InwwvdLiIKd89hL6f5ikOJ1Y6ljb4OSV+N2ajz sfD0NqfQFutYC1OEYIY8tsZK9vLM9koGOG7RZFlSE4SP/tLVhOjL/FYQDbYE2/mxs1Qq RcWR5AtG/LD4D5MBtOURDaM2aM0JFKPtcRc41aYARTzLBB0qN5/OpO6qxcNF7z+o0Db3 LPGlNsJLnmLLzfQMW2Xe4p65LXcbJlNKMy9yaP+c2mVw98gxM1Ij1RVsZaqYvO+7ioVF 69Oy7kDr3RgyGwSkEj8ubKwAr3jL4Anc0KfDu6HhERGcLpFBQy8svhwQJjoCyYPIUv3d 0y3g== 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=Xs36vxCYRTzkNit/U0iWtMhP/Jb7KjJrJ5Tu4A3gG8w=; b=Pp8aYVypEiF/HY9aA/5+6dPHEjzvVrrRaiDN9cSNbujnApeHtkW8ATXPlKNUvKfrer Bw9DO/f5CkcV5v0IUEFJnoJKoTnAuuSUhrCLzjv/jdD+o9t5Y9Q4xdFNQOpT8lwmXWgg SM7Nn4aCwNv7vA0rEGmK0nMqRBTBn/YFQoaPxwrrdHqjMKOqgvIWDt6AKbjn/LrUqmzX 0kd4HlBczdA7v0EEFGLukxaesCVP0mvNnfyCcEz3k5LmZ/27nB9qGBBxGfTkFTAkYE3D v06nBEru3FzeQt2RVdqA56bctJxEYv1DAs3ngPJI9T8vZfEcyh3pePA1ZLky++czAN+7 FZ3w== X-Gm-Message-State: AGRZ1gLpmXIBMLOT2SoLyOffeETvpsP4B8KGjtuYPAcp/zrP+AyY+RCj aYRUruG1wCFArL3XGCnO143OJ93MbhR8bvnN+11BZA== X-Google-Smtp-Source: AJdET5fNEs5weMUYDgWqluD1+iSMEGZYDSHih6jsgAXopy7MnNfY2YYf//ZCUIZVj/CGKp0Ol+Lh5T9kzH7kYPzNg/A= X-Received: by 2002:a5d:4708:: with SMTP id y8-v6mr5790565wrq.16.1542286589639; Thu, 15 Nov 2018 04:56:29 -0800 (PST) MIME-Version: 1.0 References: <1542120839.3452626.1575386224.226D0485@webmail.messagingengine.com> In-Reply-To: From: Ori Finkelman Date: Thu, 15 Nov 2018 14:56:02 +0200 Message-ID: To: aamelnikov@fastmail.fm Cc: Chris Lemmons , "" Content-Type: multipart/alternative; boundary="000000000000515aa2057ab3942f" 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: Thu, 15 Nov 2018 12:56:35 -0000 --000000000000515aa2057ab3942f Content-Type: text/plain; charset="UTF-8" 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 ? 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 --000000000000515aa2057ab3942f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
Looking at ISO8601, local time is simply defined b= y not adding the offset (or Z).
For example:=C2=A02018-11-12T02:30:00.00
Is interpreted as 2:30AM at t= he 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 absolu= te 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 = ?

Thanks,
Ori

<= br>




<= br>


On Wed, Nov 14, 2018 at 11:02 AM Ori Finkelman <orif@qwilt.com> wrote:
Thanks Alexey,
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
Qwi= lt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com


--
Ori Finkelman
Qwilt | Work: +972-72-222= 1647 | Mobile: +972-52-3832189 | orif@qwilt.com
--000000000000515aa2057ab3942f-- From nobody Thu Nov 15 06:29:39 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 D717612D4E7 for ; Thu, 15 Nov 2018 06:29:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 mLEa_Lu9crdJ for ; Thu, 15 Nov 2018 06:29:36 -0800 (PST) Received: from mbox1.develooper.com (mbox1.develooper.com [207.171.7.178]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0D0012785F for ; Thu, 15 Nov 2018 06:29:36 -0800 (PST) Received: from mbox1.develooper.com (mbox1.develooper.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mbox1.develooper.com (Postfix) with ESMTPS id 858ED175D12 for ; Thu, 15 Nov 2018 06:29:29 -0800 (PST) Received: (qmail 25677 invoked from network); 15 Nov 2018 14:29:08 -0000 Received: from unknown (HELO ?100.88.214.137?) (ask@mail.dev@172.56.12.196) by smtp.develooper.com with ESMTPA; 15 Nov 2018 14:29:08 -0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: =?utf-8?Q?Ask_Bj=C3=B8rn_Hansen?= X-Mailer: iPhone Mail (16C5043b) In-Reply-To: Date: Thu, 15 Nov 2018 15:29:07 +0100 Cc: aamelnikov@fastmail.fm, "" Content-Transfer-Encoding: quoted-printable Message-Id: <01DAD7E1-F68E-480F-BFEE-5BCD4BE539F9@develooper.com> References: <1542120839.3452626.1575386224.226D0485@webmail.messagingengine.com> To: Ori Finkelman 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: Thu, 15 Nov 2018 14:29:38 -0000 > On Nov 15, 2018, at 13:56, Ori Finkelman wrote: >=20 > We can adopt that option for our use case as it is not trying to agree on a= n absolute time but rather on the local. For a CDN what does local time mean? What=E2=80=99s the use case for this? (Apologies if it was clarified earlier= , but it doesn=E2=80=99t make sense to me). Ask= From nobody Thu Nov 15 07:35:29 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 498EC130DCF for ; Thu, 15 Nov 2018 07:35:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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 jgFOMQp3d98e for ; Thu, 15 Nov 2018 07:35:25 -0800 (PST) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 BD6F212D4EF for ; Thu, 15 Nov 2018 07:35:24 -0800 (PST) Received: by mail-wr1-x432.google.com with SMTP id e3-v6so21705153wrs.5 for ; Thu, 15 Nov 2018 07:35:24 -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=1U4lEArCY9mYJRoyx42/1Zk9Mx3kpQjk1LxU3djQqE4=; b=T6bcPdhF8twc3KsWaJthvUWlgz6iSrDGQjOTVKPQXrSukA/8DTXv/WDXYoNVbD9GKf DAAIqgBuZjS0rtHtN/p7DKr883sItc+iM4KU7ppj8pn3RYf3PNTyfOZDyLWsSPI4qEz/ aR0hQGV7hOA/dT/ACXtzoi+65N1pCsvKIDWcgH1idivXwRWNeQ0+9DBinGXa6Fzh45iJ 92s4pDK/mhXO4YIbgbd3+k+jISP44dWoR4r46XCk//k7/USF3dqcVaVVQJ+p4vFs34pp y6tavPkuB2+ovpYlfNQoIcV76cegg+MlTtHhJ8hmjuP9pKlAKs/BbctxDj5Msi6VCvOQ sT4g== 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=1U4lEArCY9mYJRoyx42/1Zk9Mx3kpQjk1LxU3djQqE4=; b=AuEPMZBQIOqhi9bpMcyOf7gdquRqWUU3kd+t6d73aYeXOVTaOJw2vBC47IyycZ1W8l QGxdgiLunJRnKIsb469HlyJz96sGznXBKD5KZEK5bYUoXAIzc5miNzxpyxDCrVAk7LZ6 rn6ARxHSgvU72r1ovjbnItCEfL5JfLb52rmqEnrwsGcbBIP8AvmModemxUfmYekS8veK arqQfbKfeKzl0SSjuFG/MuBJkzn/H2YdSKUlnes0SpdDwM0SAKWohx8R1ZkDInD6TwYP N19J98XEBwfGiVVGBIfQNdzdFSdOeo2ZsIoST+4NlJAGab22mIN6iih3/9sKNTxh+K+E Ax5Q== X-Gm-Message-State: AGRZ1gKk1YtE3p/W0Uz41ii4RYiDutRpd69TFB6duP48SkffkJdd0DJ6 KFVCeu0x+WKFH6hcQS8X4qHHAZ4aEu20DV0b4looV77i X-Google-Smtp-Source: AJdET5f9NP3/kGau+WAFJPvYvKJqTvO42V+NIDKrEwwbDc9o4u7n/VsQKtvGyQXGVJm4FOZZDXcVD6Ayi6EW2x7ldBc= X-Received: by 2002:a05:6000:1cb:: with SMTP id t11mr6438631wrx.146.1542296122899; Thu, 15 Nov 2018 07:35:22 -0800 (PST) MIME-Version: 1.0 References: <1542120839.3452626.1575386224.226D0485@webmail.messagingengine.com> <01DAD7E1-F68E-480F-BFEE-5BCD4BE539F9@develooper.com> In-Reply-To: <01DAD7E1-F68E-480F-BFEE-5BCD4BE539F9@develooper.com> From: Ori Finkelman Date: Thu, 15 Nov 2018 17:34:55 +0200 Message-ID: To: ask@develooper.com Cc: aamelnikov@fastmail.fm, "" Content-Type: multipart/alternative; boundary="0000000000008b5622057ab5ccf3" 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: Thu, 15 Nov 2018 15:35:28 -0000 --0000000000008b5622057ab5ccf3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, CDNI Triggers interface is a special case, Let's take CDN-A and CDN-B, both have presence in multiple regions, but they don't share the same coverage, so CDN-A (upstream CDN) uses CDN-B (downstream CDN) in order to extend its coverage. Now CDN-A needs to pre-position some content on its caches, and it wishes CDN-B to pull the content to its caches as well. CDN-A wants CDN-B to pull the content to the caches from CDN-A at off peak hours, for example 2AM-4AM. However, since both are located in multiple regions, the off peak time depends on each specific region. There is no single absolute time which is right for all timezones. What we are looking for is to extend the trigger interface such that one can define the time in which the trigger should be executed, but in this case the time depends on the on the geography. Our proposal is to have an interface to tell the dCDN "I want you to execute the trigger at a specific time in your local times as they are per region". Hope this explains the context. Thanks, Ori On Thu, Nov 15, 2018 at 4:29 PM Ask Bj=C3=B8rn Hansen = wrote: > > > On Nov 15, 2018, at 13:56, Ori Finkelman wrote: > > > > 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. > > For a CDN what does local time mean? > > What=E2=80=99s the use case for this? (Apologies if it was clarified earl= ier, but > it doesn=E2=80=99t make sense to me). > > > Ask > --=20 *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com --0000000000008b5622057ab5ccf3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
CDNI Triggers interface is a special case,
Let's take CDN-A and CDN-B, both have presence in multiple regions, = but they don't share the same coverage, so CDN-A (upstream CDN) uses CD= N-B (downstream CDN) in order to extend its coverage.=C2=A0

<= /div>
Now CDN-A needs to pre-position some content on its caches, and i= t wishes CDN-B to pull the content to its caches as well.
CDN-A w= ants CDN-B to pull the content to the caches from CDN-A at off peak hours, = for example 2AM-4AM.
However, since both are located in multiple = regions, the off peak time depends on each specific region. There is no sin= gle absolute time which is right for all timezones.=C2=A0

What we are looking for is to extend the trigger interface such tha= t one can define the time in which the trigger should be executed, but in t= his case the time depends on the on the geography.

Our proposal is to have an interface to tell the dCDN "I want you to = execute the trigger at a specific time in your local times as they are per = region".

Hope this explains the context.

Thanks,
Ori






On Thu, Nov 15, 2018 at 4:29 PM Ask Bj=C3=B8rn H= ansen <ask@develooper.com> = wrote:

> On Nov 15, 2018, at 13:56, Ori Finkelman <orif@qwilt.com> wrote:
>
> 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.

For a CDN what does local time mean?

What=E2=80=99s the use case for this? (Apologies if it was clarified earlie= r, but it doesn=E2=80=99t make sense to me).


Ask


--
Ori Finkelman
Qwilt | Work: +972-72-2221647 | Mobile: +972-52= -3832189 | orif@qwilt.com
--0000000000008b5622057ab5ccf3-- From nobody Sun Nov 18 01:29:22 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 2308A12D4F2 for ; Sun, 18 Nov 2018 01:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] 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 D5ozQ6-udTlU for ; Sun, 18 Nov 2018 01:29:18 -0800 (PST) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 E6D301274D0 for ; Sun, 18 Nov 2018 01:29:17 -0800 (PST) Received: by mail-wr1-x42b.google.com with SMTP id x10so257174wrs.8 for ; Sun, 18 Nov 2018 01:29:17 -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=Qjhd6m3rG2/XRLZ7QSM86dVTkdsGLSUumuHmV/iDOoc=; b=FT9MS0ut7dcRmvDnAVCAU7p6PoQD0tbe7QvqNcJ2I/OmMLo7VdRK+QWn2ZsSOB+5HN GZRbKqIuV4diGZPwRj5BU+tYTDTR88b9y1Y6hLtb2f0+1HMqYZBjNRecE1yuWpsdny9N 9egzpzFvvzX8mxKmByIUcr+18Us2z41KhGejjF2nPiwVD5nv+sKncpJ3cR1rtvCVo4Sf KR25b1brKtRDw6f8HR4B4dWvkkwIzHkxj16+2+mDzKMsAxHBV1bJUCdV9Tp44uNiJK45 5wnZqrLI1N7dsWrTHMs8Nw/d+ouGrrlNeo2hY7yUVNYc6LTJivOACJ8MEPlj7h8JflPe 37dA== 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=Qjhd6m3rG2/XRLZ7QSM86dVTkdsGLSUumuHmV/iDOoc=; b=Y/hMEI8YwaCj5ywLQ7fMU4h6LVPRCP+Dyv3xubhM+PalJ2NrSME7970TGlc/D1LsHO Q1kqJ2v2sisA00j7w+Qn3JYFnVN8jCPcToegd379lmQsEu8YdoUVJgxruIaEd24oIkeB TRcEeEs9McdpVnMtCY04ue4uCQybViSaRYJ+lcKhBukSo57BYUEnzusuJwABo8ac3TKY tHrRad/kDJ1j6/5AI15EMGNjlghod34Mwo8da1QZIDFghblCGLxvrvrqed7Hb0wb9Q39 0M2KW1m9tGNCyT5CwO6+xRt0X+VAwIM/CEW+qJtv7XJOp/YUDX4vLFbLJsQUXYgArG4C 7Ycg== X-Gm-Message-State: AGRZ1gLSFBQLCqptDLNg8NlrJvLSKKP3WzdwULD7PD85wB5nr92rMz5E uN6IaPDgjeV5X8FeYZfXsTnAzST2MzFis/SpXc3G6A== X-Google-Smtp-Source: AJdET5ero4gm5ZjqrjBW08kgSR6OYcF4NoQevUFjWObt+Ya0Ks3XQsv47lXTIaiVU0Fi9+Dfsia6bnsPY5pbil3oCpg= X-Received: by 2002:adf:9123:: with SMTP id j32-v6mr14170868wrj.0.1542533354899; Sun, 18 Nov 2018 01:29:14 -0800 (PST) MIME-Version: 1.0 References: <1542120839.3452626.1575386224.226D0485@webmail.messagingengine.com> <01DAD7E1-F68E-480F-BFEE-5BCD4BE539F9@develooper.com> In-Reply-To: From: Ori Finkelman Date: Sun, 18 Nov 2018 11:28:47 +0200 Message-ID: To: ask@develooper.com Cc: aamelnikov@fastmail.fm, "" Content-Type: multipart/alternative; boundary="000000000000ac6075057aed0829" 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, 18 Nov 2018 09:29:21 -0000 --000000000000ac6075057aed0829 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ask, Would love to know if my explanation make sense. If there are other alternatives we haven't though about that could satisfy the trigger scheduling requirements, i'd be happy to check them out. All, here is my proposal for the time window object that is using internet timestamp (as RFC3339) instead of UNIX epoch. As proposed by Alexey and others, I have followed ISO8601 that defines a time without an offset to be the local time. I'm currently defining a new object rather than extending and versioning the TimeWindow defined in section 4.2.3.2 of RFC8006 , the reason is that the object is too simple, I think it would be wrong to version it. TimestampWindow A TimestampWindow object describes a time range that can be applied by a TimePolicy, e.g., start 2000-01-01T02:30:00.00Z, end: 2000-01-01T04:30:00.00Z. Property: start Description: The start time of the window. Type: Timestamp (see *Timestamp *below) Mandatory-to-Specify: Yes. Property: end Description: The end time of the window. Type: Timestamp (see *Timestamp *below) Mandatory-to-Specify: Yes. Example TimestampWindow object that describes a time window from 02:30 01/01/2000 UTC to 04:30 01/01/2000 UTC: { "start": 2000-01-01T02:30:00.00Z, "end": 2000-01-01T04:30:00.00Z, } Timestamp A timestamp value expressed as Internet time as defined by section 5.6 of [RFC3339] , with the following extension: A timestamp (date and time string) MAY be used without the time-numoffset or time-offset elements, in which case the reader must interpret it as their own local time. Type: A non-empty JSON string where the string is an Internet timestamp as defined in [RFC3339] with the modification for local time as explained above. Example 1 time representing 09:00:00 01/01/2000 UTC: 2000-01-01T09:00:00.00Z Example 2 time representing 09:00:00 01/01/2000 at the reader's local ti= me: 2000-01-01T09:00:00.00 Example 3 time representing 09:00:00 01/01/2000 local time at offset -05= :00: 2000-01-01T09:00:00.00-05:00 Thanks, Ori On Thu, Nov 15, 2018 at 5:34 PM Ori Finkelman wrote: > Hi, > CDNI Triggers interface is a special case, > Let's take CDN-A and CDN-B, both have presence in multiple regions, but > they don't share the same coverage, so CDN-A (upstream CDN) uses CDN-B > (downstream CDN) in order to extend its coverage. > > Now CDN-A needs to pre-position some content on its caches, and it wishes > CDN-B to pull the content to its caches as well. > CDN-A wants CDN-B to pull the content to the caches from CDN-A at off pea= k > hours, for example 2AM-4AM. > However, since both are located in multiple regions, the off peak time > depends on each specific region. There is no single absolute time which i= s > right for all timezones. > > What we are looking for is to extend the trigger interface such that one > can define the time in which the trigger should be executed, but in this > case the time depends on the on the geography. > > Our proposal is to have an interface to tell the dCDN "I want you to > execute the trigger at a specific time in your local times as they are pe= r > region". > > Hope this explains the context. > > Thanks, > Ori > > > > > > > On Thu, Nov 15, 2018 at 4:29 PM Ask Bj=C3=B8rn Hansen > wrote: > >> >> > On Nov 15, 2018, at 13:56, Ori Finkelman wrote: >> > >> > 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. >> >> For a CDN what does local time mean? >> >> What=E2=80=99s the use case for this? (Apologies if it was clarified ear= lier, but >> it doesn=E2=80=99t make sense to me). >> >> >> Ask >> > > > -- > > *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | > orif@qwilt.com > --=20 *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com --000000000000ac6075057aed0829 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ask,
Would love t= o know if my explanation make sense. If there are other alternatives we hav= en't though about that could satisfy the trigger scheduling requirement= s, i'd be happy to check them out.

All, here i= s my proposal for the time window object that is using internet timestamp (= as RFC3339) instead of UNIX epoch.=C2=A0
As proposed by Alexey an= d others, I have followed ISO8601 that defines a time without an offset to = be the local time.
I'm currently defining a new object ra= ther than extending and versioning the TimeWindow defined in section 4.2.3.2 of RFC800= 6, the reason is that the object is too simple, I think it would be wro= ng to version it.

TimestampWindow


   A TimestampWindow object describes a time range that can be applied by a
   TimePolicy, e.g., start 2000-01-01T02:30:00.00Z, end: 2000-01-01T04:30:0=
0.00Z.

      Property: start

         Description: The start time of the window.

         Type: Timestamp (see Timestamp below)

         Mandatory-to-Specify: Yes.

      Property: end

         Description: The end time of the window.

         Type: Timestamp (see Timestamp below)
         Mandato=
ry-to-Specify: Yes.


   Example Timest=
ampWindow object that describes a time window from 02:30
   01/01/2000 UTC to 04:30 01/01/2000 UTC:

   {
     "start": 2000-01-01T02:30:00.00Z,
     "end": 2000-01-01T04:30:00.00Z,
   }


Timestamp


   A timestamp value expressed as Internet time as defined by section 5.6 of [RFC3339]=
, with the following extension:
   A timestamp (date and time string) MAY be used without the=
 time-numoffset or time-offset elements, in which case the reader
must interpret it as th= eir own local time.=20 Type: A non-empty JSON string where the string is an Internet timestamp = as defined in [RFC3339] with the modification 
   for local time as explained above.

   Example 1 time representing 09:00:00 01/01/2000 UTC:
   2000-01-01T09:00:00.00Z

   Example 2 time representing 09:00:00 01/01/2000 at=
 the reader's local time:
   2000-01-01T09:00:00.00

   Example 3 ti=
me representing 09:00:00 01/01/2000 local time at offset -05:00:
   2000-01-01T09:00:00.00-05:00




Thanks,
Ori
=

On Thu, Nov 15, 2018 = at 5:34 PM Ori Finkelman <orif@qwilt.c= om> wrote:
= Hi,
CDNI Triggers interface is a special case,
Let's take= CDN-A and CDN-B, both have presence in multiple regions, but they don'= t share the same coverage, so CDN-A (upstream CDN) uses CDN-B (downstream C= DN) in order to extend its coverage.=C2=A0

Now CDN= -A needs to pre-position some content on its caches, and it wishes CDN-B to= pull the content to its caches as well.
CDN-A wants CDN-B to pul= l the content to the caches from CDN-A at off peak hours, for example 2AM-4= AM.
However, since both are located in multiple regions, the off = peak time depends on each specific region. There is no single absolute time= which is right for all timezones.=C2=A0

What we a= re looking for is to extend the trigger interface such that one can define = the time in which the trigger should be executed, but in this case the time= depends on the on the geography.

Our proposal is = to have an interface to tell the dCDN "I want you to execute the trigg= er at a specific time in your local times as they are per region".

Hope this explains the context.

<= div>Thanks,
Ori






On Thu, Nov 15, 2018 at 4:29 PM Ask Bj=C3=B8rn Hansen <ask@develooper.com>= wrote:

> On Nov 15, 2018, at 13:56, Ori Finkelman <orif@qwilt.com> wrote:
>
> 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.

For a CDN what does local time mean?

What=E2=80=99s the use case for this? (Apologies if it was clarified earlie= r, but it doesn=E2=80=99t make sense to me).


Ask


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


--
Ori Finkelman
Qwilt | Work: +972-72-2221647 | Mobile: +972-52= -3832189 | orif@qwilt.com
--000000000000ac6075057aed0829-- From nobody Sun Nov 18 05:18:21 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 F09DD130E26 for ; Sun, 18 Nov 2018 05:18:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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=KoCkHgsy; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Ylj166w+ 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 dM4GcNldnWxX for ; Sun, 18 Nov 2018 05:18:12 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7F98130E1D for ; Sun, 18 Nov 2018 05:18:11 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 9B29E20DE0; Sun, 18 Nov 2018 08:18:10 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Sun, 18 Nov 2018 08:18:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=G HKCNmlkcLWTvXR8wjOJSMmOmtZ0Mp2iJHPW9QAVAjg=; b=KoCkHgsygYesr7AQ5 7wxFo1Zv91XKB83naC3tKzOb3TN5H1Yhs/lPuAF6SdZdKTs5aM0mwVbXLVIEmLBC SAKx7qzq+9s5oDkUHXCsDeixCvWinZ/KJ5osAZyGPFw1nEDh3VYw1w42xTI+gQcd szG+bAOYsY/eWpjdY0ACp28dadJWzn0Iyf7TkrkRtvV8/QAnDl/SWRDEGJgF8LEf CN6tw0MHqpOCyGqPiGUCwXDm5OqFlHQbS2FFRgqfD+Y46c17/MJk4ZSMWUux4AYY TsUBVS5wH/TjH+JheMV3zlulT1RUn9m5k0SWomR7wk80Amd4fUnM4SK11FE/PmO3 6rhMg== 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=GHKCNmlkcLWTvXR8wjOJSMmOmtZ0Mp2iJHPW9QAVA jg=; b=Ylj166w+VWeqYIVcUuiZhG/O1x4Wz2iZ6gwmg8UfPDDC7iEBURad1rNcl TdAzvkFLUgmdHkzkL3tN7L3yv2pkNL5PJFtrtyJzAJvbrlXmx+ekqVyEoqPS00lJ RoAdYH/vCqWGTL6lv4m/1kU2bj8VC+7iJpXYxUpID8d1ZRPNs8eaLsBiuVpSpMyj mtKA4EuduZPsVR1n3qqsdXv3ne1FUhEfawRKld7u52MfLzWry6/usxSG4AGZKTgv vpTj7NcrGQt5V4XkwmsA129vc+0cI9ADosga6Cglz9Ovsulwlk0ql9WD7l5Rn75+ O4vIv9cBOXy+LmpXR0v+9zLTS6bRw== X-ME-Sender: X-ME-Proxy: Received: from [10.229.253.132] (unknown [148.252.129.73]) by mail.messagingengine.com (Postfix) with ESMTPA id 8E078102E8; Sun, 18 Nov 2018 08:18:09 -0500 (EST) Content-Type: multipart/alternative; boundary=Apple-Mail-900C37BD-5AD3-4765-A5CE-A8626B949E0A Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPhone Mail (15G77) In-Reply-To: Date: Sun, 18 Nov 2018 13:18:08 +0000 Cc: Chris Lemmons , "" Content-Transfer-Encoding: 7bit Message-Id: <8CAB349C-A6E5-4BF2-AC48-008B979A8B5B@fastmail.fm> References: <1542120839.3452626.1575386224.226D0485@webmail.messagingengine.com> To: Ori Finkelman 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, 18 Nov 2018 13:18:16 -0000 --Apple-Mail-900C37BD-5AD3-4765-A5CE-A8626B949E0A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi, > On 15 Nov 2018, at 12:56, Ori Finkelman wrote: >=20 > 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. >=20 > RFC 3339 does not support this option as the RFC is focused on interoperab= ility, 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. >=20 > We can adopt that option for our use case as it is not trying to agree on a= n absolute time but rather on the local. >=20 > Is this an acceptable solution? >=20 > 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 mo= dify as needed. >=20 > Thanks, > Ori >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >> On Wed, Nov 14, 2018 at 11:02 AM Ori Finkelman wrote: >> Thanks Alexey, >> I will look into it. >>=20 >> Ori >>=20 >>> On Tue, Nov 13, 2018 at 4:54 PM Alexey Melnikov = wrote: >>> Hi, >>>=20 >>> 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 >>> >=20 >>> > 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. >>>=20 >>> I agree that generic ISO 8601 format is not what you want, that is why R= FC 3339 was defined in the first place. RFC 3339 defines a subset which is m= uch easier to parse. >>>=20 >>> You could have a look at ISO 8601 and see how "local timezone" is define= d there and just extend RFC 3339 for this case, without adding support for a= ll other optional things in ISO 8601. >>>=20 >>> Just my 2p. >>>=20 >>> > 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 c= onfusion. >>> > > What we need is something that executes in different absolute times i= n different locations. >>> > > >>> > > using the -0000 offset to signify local time. >>> > > >> This means that the time is actually in UTC (same as +0000) but t= he time zone was not supposed to be 0, it is just unknown, and is therefore u= sing 0. >>> > > >>> > > Also, it seems that ISO8601 also has a "local time" where you just d= on'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 ca= n be interpreted as different UTC in different time zones. >>> > > We can decide that when we say "local time" we actually mean the rec= eivers 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 loca= l time in NY (i.e. +0500). Using it to designate 4AM depending on where the c= ache is found is non-standard. >>> > > I was rather hoping we can have something which designate exactly wh= at 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 wro= te: >>> > >> >>> > >> 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 t= he time zone was not supposed to be 0, it is just unknown, and is therefore u= sing 0. >>> > >> >>> > >> >>> > >> Also, it seems that ISO8601 also has a "local time" where you just d= on'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 ca= n 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 "lo= cal time" we actually mean the receivers local time rather than the callers l= ocal time, but then again, if for example the trigger server is located at N= Y, then the 4AM will mean local time in NY. Using it to designate 4AM depend= ing on where the cache is found is non-standard. >>> > > >>> > > >>> > > >>> > > >>> > >> >>> > >> >>> > >> Also in RFC 2822 section 3.3 (https://tools.ietf.org/html/rfc2822#s= ection-3.3): >>> > >> >>> > >> "Though "-0000" also indicates Universal Time, it is used to indica= te that the time was generated on a system that may be in a local time zone o= ther 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 wrot= e: >>> > >>> >>> > >>> Hi, >>> > >>> In the CDNI meeting we have discussed how to represent local time a= t the trigger destination where there are multiple destination locations in d= ifferent 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 l= ocal 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 bef= ore interpreting the time. >>> > >>> For example, a server located at UTC+02:00 must reduce 7200 second= s from this eopch, resulting in 1541982600 which is 2018-11-12T02:30:00.00+0= 2:00 >>> > >>> If a sever is located at UTC-04:00 it must reduce -14,400 seconds e= poch, 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 cha= nges 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 wo= uld appreciate any input at the mean time. >>> > >>> >>> > >>> Thanks, >>> > >>> Ori >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> On Mon, Oct 15, 2018 at 12:23 PM Ori Finkelman wr= ote: >>> > >>>> >>> > >>>> 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 trigge= r at the given time window in there own local time. >>> > >>>> For example: "I want you to run this trigger between 3AM-5AM at y= our own local time". >>> > >>>> >>> > >>>> The reasoning is that network resource availability and prices ma= y vary across the day, and specifically are more available and less expensiv= e 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 call= ing a separate trigger for each region. >>> > >>>> >>> > >>>> While working on adding this "local-time" flag, I have realized t= hat 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 defin= ed 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 t= he TimeWindow. >>> > >>>> >>> > >>>> Thoughts ? >>> > >>>> >>> > >>>> Thanks, >>> > >>>> Ori >>> > >>>> >>> > >>>> >>> > >>>> On Sun, Jul 22, 2018 at 9:19 AM Ori Finkelman wr= ote: >>> > >>>>> >>> > >>>>> Here are the comments we got CDNI meeting. >>> > >>>>> >>> > >>>>> Playlist: >>> > >>>>> change abr-protocol to media-protocol, as it may be used for oth= er 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 c= onsidering we allow extensions to be safe-to-redistribute even if not unders= tood, we should add a mechanism for propagating errors and warnings back to t= he uCDN. >>> > >>>>> >>> > >>>>> Thanks, >>> > >>>>> Ori >>> > >>>>> >>> > >>>>> -- >>> > >>>>> Ori Finkelman >>> > >>>>> Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@q= wilt.com >>> > >>>> >>> > >>>> >>> > >>>> >>> > >>>> -- >>> > >>>> Ori Finkelman >>> > >>>> Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qw= ilt.com >>> > >>> >>> > >>> >>> > >>> >>> > >>> -- >>> > >>> Ori Finkelman >>> > >>> Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwi= lt.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 >>> >=20 >>> > _______________________________________________ >>> > CDNi mailing list >>> > CDNi@ietf.org >>> > https://www.ietf.org/mailman/listinfo/cdni >>=20 >>=20 >> --=20 >> Ori Finkelman >> Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com >=20 >=20 > --=20 > Ori Finkelman > Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com --Apple-Mail-900C37BD-5AD3-4765-A5CE-A8626B949E0A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi,

On 15 Nov 2018, at 12:56, O= ri Finkelman <orif@qwilt.com> wr= ote:

Hi,
Lo= oking 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 i= nteroperability, and when what you want is to have a deterministic way to es= tablish an agreement on a specific absolute time, you can either use UTC or l= ocal time with an offset from UTC.

We can adopt tha= t option for our use case as it is not trying to agree on an absolute time b= ut rather on the local.

Is this an acceptable solut= ion?

If so, how do we standardize it ? as a CDNI ti= me, or as an extension to RFC 3339 ?

=
Just include in your document. You can cut & paste ABNF from RFC 3= 339 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.<= /div>

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.<= br> > 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 3= 339 was defined in the first place. RFC 3339 defines a subset which is much e= asier to parse.

You could have a look at ISO 8601 and see how "local timezone" is defined th= ere and just extend RFC 3339 for this case, without adding support for all o= ther optional things in ISO 8601.

Just my 2p.

> Consider something like "local-offset: true", to indicate that a local<= br> > 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 creat= e confusion.
> > What we need is something that executes in different absolute time= s in different locations.
> >
> > using the -0000 offset to signify local time.
> > >> This means that the time is actually in UTC (same as +000= 0) but the time zone was not supposed to be 0, it is just unknown, and is th= erefore 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 call= er time + the correct offset. This is a specific absolute time, not somethin= g that can be interpreted as different UTC in different time zones.
> > We can decide that when we say "local time" we actually mean the r= eceivers local time rather than the callers local time, but then again, if f= or example the trigger server is located at NY, then 4AM will mean 4AM in lo= cal time in NY (i.e. +0500). Using it to designate 4AM depending on where th= e cache is found is non-standard.
> > I was rather hoping we can have something which designate exactly w= hat 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?
> >>
> >> https://tools.ietf.org/html/rfc3339#secti= on-4.3
> >>
> >> using the -0000 offset to signify local time.
> >
> > >> This means that the time is actually in UTC (same as +000= 0) but the time zone was not supposed to be 0, it is just unknown, and is th= erefore using 0.
> >>
> >>
> >> Also, it seems that ISO8601 also has a "local time" where you j= ust 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 call= er time + the correct offset. This is a specific absolute time, not somethin= g that can be interpreted as different UTC in different time zones.
> >>
> >>
> >> https://en.wikipedia.org/wik= i/ISO_8601#Time_zone_designators
> >>
> >> "If no UTC relation information is given with a time represent= ation, 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 c= allers local time, but then again, if for example the trigger server is loca= ted at NY, then the 4AM will mean local time in NY. Using it to designate 4A= M depending on where the cache is found is non-standard.
> >
> >
> >
> >
> >>
> >>
> >> Also in RFC 2822 section 3.3 (https://too= ls.ietf.org/html/rfc2822#section-3.3):
> >>
> >> "Though "-0000" also indicates Universal Time, it is used to i= ndicate that the time was generated on a system that may be in a local time z= one other than Universal Time and therefore indicates that the date-time con= tains 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 loc= al time at the trigger destination where there are multiple destination loca= tions in different time zones.
> >>>
> >>> Two options raised:
> >>> 1. Follow RFC 3339, and add a new notion for "your local t= ime"
> >>> For example: 2018-11-12T02:30:00.00L
> >>> should be interpreted as November 12th, 2018, 2:30AM at yo= ur 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 t= ime.
> >>> I.e. servers MUST reduce their time offset from the UNIX e= poch before interpreting the time.
> >>> For example, a server located at UTC+02:00 must reduce 720= 0 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 s= econds epoch, resulting in 1542004200 which is 2018-11-12T02:30:00.00-04:00<= br> > >>>
> >>> Personally I am in favor of option 2, as option 1 will req= uire changes in time parser and is probably best done by an updated RFC on t= op 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 t= ime 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 3= AM-5AM at your own local time".
> >>>>
> >>>> The reasoning is that network resource availability an= d prices may vary across the day, and specifically are more available and le= ss 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 r= equire calling a separate trigger for each region.
> >>>>
> >>>> While working on adding this "local-time" flag, I have= realized that TimeWindow as defined in https://too= ls.ietf.org/html/rfc8006#section-4.2.3.2 in UTC and it is better not be u= sed to represent local time.
> >>>> The only option I can think of using textual time form= at as defined in RFC3339, and the local time flag should be interpreted by t= he 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 i= nstead 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 b= e used for other media rather than video abr.
> >>>>>
> >>>>> Trigger TimePolicy:
> >>>>> Add local-time flag. When true the trigger should b= e executed at the local time, per zone.
> >>>>>
> >>>>> Trigger error and warning propagation:
> >>>>> Considering triggers may be propagated to a chain o= f dCDNs, and considering we allow extensions to be safe-to-redistribute even= if not understood, we should add a mechanism for propagating errors and war= nings back to the uCDN.
> >>>>>
> >>>>> Thanks,
> >>>>> Ori
> >>>>>
> >>>>> --
> >>>>> Ori Finkelman
> >>>>> Qwilt | Work: +972-72-2221647 | Mobile: +972-52-38= 32189 | orif@qwilt.com
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Ori Finkelman
> >>>> Qwilt | Work: +972-72-2221647 | Mobile: +972-52-383218= 9 | orif@qwilt.com > >>>
> >>>
> >>>
> >>> --
> >>> Ori Finkelman
> >>> Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | <= a href=3D"mailto:orif@qwilt.com" target=3D"_blank">orif@qwilt.com
> >>> _______________________________________________
> >>> CDNi mailing list
> >>> CDNi@ie= tf.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
= --Apple-Mail-900C37BD-5AD3-4765-A5CE-A8626B949E0A-- From nobody Sun Nov 18 05:33:10 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 E4CDC130DE4 for ; Sun, 18 Nov 2018 05:33:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] 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 IIg9jdspT4OW for ; Sun, 18 Nov 2018 05:33:03 -0800 (PST) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (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 33CAD130DC9 for ; Sun, 18 Nov 2018 05:33:02 -0800 (PST) Received: by mail-wr1-x436.google.com with SMTP id j17-v6so29220924wrq.11 for ; Sun, 18 Nov 2018 05:33:02 -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=N1miB3eqXmlgEFkG3LtBtnKuQ3c7bikEO398ydQWDXY=; b=Tf6arrItPTN+nKJBPEfY8mEGPiHKE08nsJrx+eq1fWe93mekpJPBibIoUfQuYBOR4T 5jO2/7chEnmXc7W7AqgLoQkv4FDDiXUynEMtrmxxr82WPYR04rR9fZQjVifZReGV6OXU HM9PIrJl/T1C9PgNOUt4sUlqg0Bozh4YlunfwaCydl5TORIYKKbpQtqcpD8qzJmH7KQ0 qGW565CdsLJ9DMJnGbR/4BCbZOZze7h7RQEO0HKK+mOhfvqaflnsYfHUJkL0k/rniwFI VUbuydiM5KvFscMtEih3m49db5BYLk14WnRXygTF/jM9u4vo/6Yd8CLkhuV7lWYybmGT R5gQ== 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=N1miB3eqXmlgEFkG3LtBtnKuQ3c7bikEO398ydQWDXY=; b=ko7mexh4E30mrXx/7TyJO7fQfYlAAy3RtiJGq4VeVlhK2Z7L8PAtZdMjFuvvVr1SIM l93BNkEc6AG/AoISU1Mt0AOLvr9su5O/0B3cUdTiDNthp55/aaThHkwNakwsrnXLYc7u 0QrHkNgz9nA/pjkr309MT9xQHkjkdU1tXMh+/DZwb6fqD+Dm9khM1FV0hssOQ62C4zS/ +VLTM+f5bfDJiXquUw61IRIBJwwA2tIuYkAG2qg9Azhzo/rGkOw3E9qgrZE+9dxbEfjM gApx9hjltCsVqhmrTtvavmqL86ZJophwIc/iBouirQhFdOdLS0n4pLAiqomEL9bRsBdd sCoA== X-Gm-Message-State: AGRZ1gL4r1qubeUSqx88H91KpOdfSykS+5bJlYbB7fd1/4BhoHo9Uzgw DK3DLR6BkbEpxrmeE2XU7pMqmB82wH0YUH+Vb2Jp9Q== X-Google-Smtp-Source: AJdET5fw6hv4JsqAYOn1yKihiYoRilSRDXg9IBwIfCUBkWtDqHEq1YjeMQgNgQQX86LPa+x2ny49VNiXPfZilybal0o= X-Received: by 2002:adf:9123:: with SMTP id j32-v6mr14648745wrj.0.1542547981046; Sun, 18 Nov 2018 05:33:01 -0800 (PST) MIME-Version: 1.0 References: <1542120839.3452626.1575386224.226D0485@webmail.messagingengine.com> <8CAB349C-A6E5-4BF2-AC48-008B979A8B5B@fastmail.fm> In-Reply-To: <8CAB349C-A6E5-4BF2-AC48-008B979A8B5B@fastmail.fm> From: Ori Finkelman Date: Sun, 18 Nov 2018 15:32:34 +0200 Message-ID: To: aamelnikov@fastmail.fm Cc: Chris Lemmons , "" Content-Type: multipart/alternative; boundary="00000000000075ab63057af070f7" 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, 18 Nov 2018 13:33:08 -0000 --00000000000075ab63057af070f7 Content-Type: text/plain; charset="UTF-8" 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 --00000000000075ab63057af070f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks, I will do that.
Best regards,
Ori

On Sun, Nov 18, 20= 18 at 3:18 PM Alexey 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


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


--
Ori Finkelman
Qwi= lt | 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
--00000000000075ab63057af070f7-- From nobody Tue Nov 20 00:20: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 6977A128D68 for ; Tue, 20 Nov 2018 00:20:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Ge4w1oWGGSKM for ; Tue, 20 Nov 2018 00:20:34 -0800 (PST) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8670E128B14 for ; Tue, 20 Nov 2018 00:20:34 -0800 (PST) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 42zdtm3K93zFql2; Tue, 20 Nov 2018 09:20:32 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.58]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 42zdtm2N7GzBrLG; Tue, 20 Nov 2018 09:20:32 +0100 (CET) Received: from OPEXCLILM44.corporate.adroot.infra.ftgroup ([fe80::b08d:5b75:e92c:a45f]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0415.000; Tue, 20 Nov 2018 09:20:30 +0100 From: To: Phil Sorber , "" Thread-Topic: [CDNi] Call for Adoption on draft-finkelman-cdni-triggers-sva-extensions Thread-Index: AQHUejvaW2deFROvlEmlMEhJvJVNsaVYTdXA Date: Tue, 20 Nov 2018 08:20:29 +0000 Message-ID: <21055_1542702032_5BF3C3D0_21055_367_2_457bc3a8-07fc-4659-ad3c-02ad84566b1e@OPEXCLILM33.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/alternative; boundary="_000_457bc3a807fc4659ad3c02ad84566b1eOPEXCLILM33corporateadr_" MIME-Version: 1.0 Archived-At: Subject: Re: [CDNi] Call for Adoption on draft-finkelman-cdni-triggers-sva-extensions 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, 20 Nov 2018 08:20:36 -0000 --_000_457bc3a807fc4659ad3c02ad84566b1eOPEXCLILM33corporateadr_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUGhpbCwNCg0KSSBzdXBwb3J0IHRoZSBhZG9wdGlvbi4gSXQgaW1wcm92ZXMgdGhlIGludGVy b3AgYW5kIHRoZSBtYW5hZ2VtZW50IG9mIGFkYXB0aXZlIHN0cmVhbWluZyBhY3Jvc3MgQ0ROaSBj YWNoZXMuDQoNClJlZ2FyZHMNCkVtaWxlDQoNCkRlIDogQ0ROaSBbbWFpbHRvOmNkbmktYm91bmNl c0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBQaGlsIFNvcmJlcg0KRW52b3nDqSA6IGx1bmRpIDEy IG5vdmVtYnJlIDIwMTggMDQ6NTcNCsOAIDogPGNkbmlAaWV0Zi5vcmc+DQpPYmpldCA6IFtDRE5p XSBDYWxsIGZvciBBZG9wdGlvbiBvbiBkcmFmdC1maW5rZWxtYW4tY2RuaS10cmlnZ2Vycy1zdmEt ZXh0ZW5zaW9ucw0KDQpIZWxsbyBBbGwsDQoNCkluIEJhbmdrb2sgd2UgaGFkIGFuIHVwZGF0ZSBv biB0aGUgZG9jdW1lbnQgYXMgd2VsbCBhcyBjbGFyaWZpY2F0aW9uIGFib3V0IHRoZSBuZWVkIGZv ciBhIHJlLWNoYXJ0ZXIsIG9yIG1vcmUgZXhwbGljaXRseSwgdGhlIGxhY2sgdGhlcmVvZiwgYW5k IGEgaHVtIGZvciBpbnRlcmVzdCBpbiBhZG9wdGluZyB0aGlzIGRvY3VtZW50LiBUaGUgaHVtIHdh cyBwb3NpdGl2ZSBhbmQgSSB3b3VsZCBsaWtlIHRvIG9wZW4gYSBDYWxsIEZvciBBZG9wdGlvbiBv biBpdC4gSWYgeW91IHdlcmVuJ3QgcHJlc2VudCBhdCB0aGUgbWVldGluZywgb3IgcGVyaGFwcyBj YW1lIHVwIHdpdGggc29tZSBuZXcgb3BpbmlvbnMsIHBsZWFzZSB2b2ljZSB0aGVtIGhlcmUuDQoN CkxpbmsgdG8gZG9jOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maW5r ZWxtYW4tY2RuaS10cmlnZ2Vycy1zdmEtZXh0ZW5zaW9ucy8NCg0KVGhpcyBDRkEgd2lsbCBiZSBv cGVuIHVudGlsIE5vdiAyNXRoLg0KDQpUaGFua3MuDQoNCgpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0 IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29u ZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUg ZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMg YXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBs J2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4g TGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlv biwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0 ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBp dHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5m b3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJl IGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFp bHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0 IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== --_000_457bc3a807fc4659ad3c02ad84566b1eOPEXCLILM33corporateadr_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6 bm9ybWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K CW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRlIiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PkhpIFBoaWwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkkgc3VwcG9ydCB0aGUgYWRvcHRpb24uIEl0IGltcHJv dmVzIHRoZSBpbnRlcm9wIGFuZCB0aGUgbWFuYWdlbWVudCBvZiBhZGFwdGl2ZSBzdHJlYW1pbmcg YWNyb3NzIENETmkgY2FjaGVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5SZWdhcmRzPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+RW1pbGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiBDRE5pIFttYWlsdG86Y2RuaS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+ RGUgbGEgcGFydCBkZTwvYj4gUGhpbCBTb3JiZXI8YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4g bHVuZGkgMTIgbm92ZW1icmUgMjAxOCAwNDo1Nzxicj4NCjxiPsOAJm5ic3A7OjwvYj4gJmx0O2Nk bmlAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBbQ0ROaV0gQ2FsbCBmb3Ig QWRvcHRpb24gb24gZHJhZnQtZmlua2VsbWFuLWNkbmktdHJpZ2dlcnMtc3ZhLWV4dGVuc2lvbnM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZWxsbyBBbGwsPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIEJhbmdrb2sgd2UgaGFkIGFuIHVwZGF0 ZSBvbiB0aGUgZG9jdW1lbnQgYXMgd2VsbCBhcyBjbGFyaWZpY2F0aW9uIGFib3V0IHRoZSBuZWVk IGZvciBhIHJlLWNoYXJ0ZXIsIG9yIG1vcmUgZXhwbGljaXRseSwgdGhlIGxhY2sgdGhlcmVvZiwg YW5kIGEgaHVtIGZvciBpbnRlcmVzdCBpbiBhZG9wdGluZyB0aGlzIGRvY3VtZW50LiBUaGUgaHVt IHdhcyBwb3NpdGl2ZSBhbmQgSSB3b3VsZCBsaWtlIHRvIG9wZW4NCiBhIENhbGwgRm9yIEFkb3B0 aW9uIG9uIGl0LiBJZiB5b3Ugd2VyZW4ndCBwcmVzZW50IGF0IHRoZSBtZWV0aW5nLCBvciBwZXJo YXBzIGNhbWUgdXAgd2l0aCBzb21lIG5ldyBvcGluaW9ucywgcGxlYXNlIHZvaWNlIHRoZW0gaGVy ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ TGluayB0byBkb2M6IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWZpbmtlbG1hbi1jZG5pLXRyaWdnZXJzLXN2YS1leHRlbnNpb25zLyI+DQpodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maW5rZWxtYW4tY2RuaS10cmlnZ2Vycy1zdmEt ZXh0ZW5zaW9ucy88L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoaXMgQ0ZBIHdpbGwgYmUgb3BlbiB1bnRpbCBOb3YgMjV0aC48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPFBSRT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBw ZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZp bGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBv dSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2Ug cGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0 cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9u aXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91 dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3Ug ZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNv bnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUg cHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9y IGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg ZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMg bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9y YW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwg Y2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KPC9QUkU+PC9ib2R5Pg0KPC9odG1sPg0K --_000_457bc3a807fc4659ad3c02ad84566b1eOPEXCLILM33corporateadr_-- From nobody Tue Nov 20 01:50:22 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 4EAF712D4EC for ; Tue, 20 Nov 2018 01:50:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 e_Yfk-8IW5-j for ; Tue, 20 Nov 2018 01:50:18 -0800 (PST) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C94A612D4EF for ; Tue, 20 Nov 2018 01:50:17 -0800 (PST) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 42zgtH626Zz2yPg; Tue, 20 Nov 2018 10:50:15 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.72]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 42zgtH44pnzBrLw; Tue, 20 Nov 2018 10:50:15 +0100 (CET) Received: from OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf]) by OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541%19]) with mapi id 14.03.0415.000; Tue, 20 Nov 2018 10:50:15 +0100 From: To: Phil Sorber , "" Thread-Topic: [CDNi] Call for Adoption on draft-finkelman-cdni-triggers-sva-extensions Thread-Index: AQHUejvallf7tAtsZUK1AJYnBVK+uKVYd7Aw Date: Tue, 20 Nov 2018 09:50:14 +0000 Message-ID: <2891_1542707415_5BF3D8D7_2891_162_1_1BD328329726EF4E91AE924BB1B4CB9E637184CB@OPEXCLILMA1.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: multipart/alternative; boundary="_000_1BD328329726EF4E91AE924BB1B4CB9E637184CBOPEXCLILMA1corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [CDNi] Call for Adoption on draft-finkelman-cdni-triggers-sva-extensions 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, 20 Nov 2018 09:50:20 -0000 --_000_1BD328329726EF4E91AE924BB1B4CB9E637184CBOPEXCLILMA1corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUGhpbCwNCg0KSSBmdWxseSBzdXBwb3J0IGFkb3B0aW9uIG9mIHRoZSBkcmFmdC4NCg0KUmVn YXJkcywNCkZyw6lkw6lyaWMNCg0KRGUgOiBDRE5pIFttYWlsdG86Y2RuaS1ib3VuY2VzQGlldGYu b3JnXSBEZSBsYSBwYXJ0IGRlIFBoaWwgU29yYmVyDQpFbnZvecOpIDogbHVuZGkgMTIgbm92ZW1i cmUgMjAxOCAwNDo1Nw0Kw4AgOiA8Y2RuaUBpZXRmLm9yZz4NCk9iamV0IDogW0NETmldIENhbGwg Zm9yIEFkb3B0aW9uIG9uIGRyYWZ0LWZpbmtlbG1hbi1jZG5pLXRyaWdnZXJzLXN2YS1leHRlbnNp b25zDQoNCkhlbGxvIEFsbCwNCg0KSW4gQmFuZ2tvayB3ZSBoYWQgYW4gdXBkYXRlIG9uIHRoZSBk b2N1bWVudCBhcyB3ZWxsIGFzIGNsYXJpZmljYXRpb24gYWJvdXQgdGhlIG5lZWQgZm9yIGEgcmUt Y2hhcnRlciwgb3IgbW9yZSBleHBsaWNpdGx5LCB0aGUgbGFjayB0aGVyZW9mLCBhbmQgYSBodW0g Zm9yIGludGVyZXN0IGluIGFkb3B0aW5nIHRoaXMgZG9jdW1lbnQuIFRoZSBodW0gd2FzIHBvc2l0 aXZlIGFuZCBJIHdvdWxkIGxpa2UgdG8gb3BlbiBhIENhbGwgRm9yIEFkb3B0aW9uIG9uIGl0LiBJ ZiB5b3Ugd2VyZW4ndCBwcmVzZW50IGF0IHRoZSBtZWV0aW5nLCBvciBwZXJoYXBzIGNhbWUgdXAg d2l0aCBzb21lIG5ldyBvcGluaW9ucywgcGxlYXNlIHZvaWNlIHRoZW0gaGVyZS4NCg0KTGluayB0 byBkb2M6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbmtlbG1hbi1j ZG5pLXRyaWdnZXJzLXN2YS1leHRlbnNpb25zLw0KDQpUaGlzIENGQSB3aWxsIGJlIG9wZW4gdW50 aWwgTm92IDI1dGguDQoNClRoYW5rcy4NCg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBp ZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRp ZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNl cywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJl Y3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRp dGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVz c2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFu Z2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVy ZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRh Y2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlv biB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJp YnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFu ZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkg YmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBi ZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK --_000_1BD328329726EF4E91AE924BB1B4CB9E637184CBOPEXCLILMA1corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6 bm9ybWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K CW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRlIiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PkhpIFBoaWwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkkgZnVsbHkgc3VwcG9ydCBhZG9wdGlvbiBvZiB0aGUg ZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5GcsOpZMOpcmljPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EZSZuYnNwOzo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQ0ROaSBbbWFpbHRvOmNkbmktYm91 bmNlc0BpZXRmLm9yZ10NCjxiPkRlIGxhIHBhcnQgZGU8L2I+IFBoaWwgU29yYmVyPGJyPg0KPGI+ RW52b3nDqSZuYnNwOzo8L2I+IGx1bmRpIDEyIG5vdmVtYnJlIDIwMTggMDQ6NTc8YnI+DQo8Yj7D gCZuYnNwOzo8L2I+ICZsdDtjZG5pQGlldGYub3JnJmd0Ozxicj4NCjxiPk9iamV0Jm5ic3A7Ojwv Yj4gW0NETmldIENhbGwgZm9yIEFkb3B0aW9uIG9uIGRyYWZ0LWZpbmtlbG1hbi1jZG5pLXRyaWdn ZXJzLXN2YS1leHRlbnNpb25zPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVsbG8gQWxsLDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBCYW5n a29rIHdlIGhhZCBhbiB1cGRhdGUgb24gdGhlIGRvY3VtZW50IGFzIHdlbGwgYXMgY2xhcmlmaWNh dGlvbiBhYm91dCB0aGUgbmVlZCBmb3IgYSByZS1jaGFydGVyLCBvciBtb3JlIGV4cGxpY2l0bHks IHRoZSBsYWNrIHRoZXJlb2YsIGFuZCBhIGh1bSBmb3IgaW50ZXJlc3QgaW4gYWRvcHRpbmcgdGhp cyBkb2N1bWVudC4gVGhlIGh1bSB3YXMgcG9zaXRpdmUgYW5kIEkgd291bGQgbGlrZSB0byBvcGVu DQogYSBDYWxsIEZvciBBZG9wdGlvbiBvbiBpdC4gSWYgeW91IHdlcmVuJ3QgcHJlc2VudCBhdCB0 aGUgbWVldGluZywgb3IgcGVyaGFwcyBjYW1lIHVwIHdpdGggc29tZSBuZXcgb3BpbmlvbnMsIHBs ZWFzZSB2b2ljZSB0aGVtIGhlcmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkxpbmsgdG8gZG9jOiA8YSBocmVmPSJodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1maW5rZWxtYW4tY2RuaS10cmlnZ2Vycy1zdmEtZXh0ZW5z aW9ucy8iPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlua2VsbWFu LWNkbmktdHJpZ2dlcnMtc3ZhLWV4dGVuc2lvbnMvPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIENGQSB3aWxsIGJlIG9wZW4gdW50 aWwgTm92IDI1dGguPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoYW5rcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxQUkU+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBz ZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZp ZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRp ZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2 ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdl eHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExl cyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24s Ck9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUg YWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRz IGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9y bWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBk aXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxz IG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBo YXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCjwvUFJF PjwvYm9keT4NCjwvaHRtbD4NCg== --_000_1BD328329726EF4E91AE924BB1B4CB9E637184CBOPEXCLILMA1corp_-- From nobody Sun Nov 25 00:13:59 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 008B31276D0 for ; Sun, 25 Nov 2018 00:13:58 -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 mdrWfv_2mTKG for ; Sun, 25 Nov 2018 00:13:54 -0800 (PST) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (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 BC4C1127598 for ; Sun, 25 Nov 2018 00:13:53 -0800 (PST) Received: by mail-wm1-x32f.google.com with SMTP id s11so15348065wmh.1 for ; Sun, 25 Nov 2018 00:13:53 -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=nVuk34A27S8R5Yu8fcPVOSDMLd/F8wl5J9Er0m38eww=; b=v6LqkY4vrG9eOkywaJpfd7nCJ+XAYhDEIrkoD32ppXXGQEef2oyMLbtDzkWB8i5te7 Pl+6lteTyQMJY7DCeUcp6v55M4L2WSK/iDtRW+OikxpHalnZ9nCTFpAoQXGG69ExOZIc gmL+HCFeAMaRmjRfU73kJ5AfXS5hIXg1YDCfb1YQJzmPN9mf+pc/43Eyb3z5f1JZDUk1 lkODojgJP370worS2nTv29YTkYJGzpqlzrYiU+UWcpbt/re40aaJBz21YMuTcvsPGW2v McFJc0iS0tZU1uMoBdfxxfe3dWf2pp75H9bTFckKUvwcPoMRMeT6o9wBrJm4GuFg7HZa q/mA== 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=nVuk34A27S8R5Yu8fcPVOSDMLd/F8wl5J9Er0m38eww=; b=UmcIBtgvKWQZocOOqYS64yfbp3nW7VNIs+0xJx/gyvGkdaazot7eZm7+0AQFwyN4ng 0B/k14wzKZkocOBFIXwQXj/HyLL0oSxCqsYOUH72LKsDnIEZPz3NYxIKd+ZX//HOHFVV 0WY5aMYNGG/EGlksY/F9mDsoI8luo52A4+PS24bDtX7BKVx04C8fb+5EUkrI3jWD6zlR a4ZZIB93HNlrV4Whe+C+Z6Q0GX8HL0BlQ4iESnsanQTnmC3kwBzhZ5xc8QdYnvGosPU5 MitZT3lwJc668jQEDyJ59VHgdz2v6wwlo+EAsPck/SUg9BL7uyz9jRuzd5u85lZLu6tE LQrQ== X-Gm-Message-State: AA+aEWYvBmTHezu8fwyVO33ykLe8Bq2AfQwb63QrnjmWVgVLK8wonAmo oOTXIkFr8FOrEAhHHG9/ourNSsVdhKZN7FYicgG59g== X-Google-Smtp-Source: AFSGD/WGOygs19cmLoZ18Tr9TI0m8XYtOwOg84Tq4p2LUXsFfVraCxDfsC4CCyzClwVAMXxSTirErNURHwVyaVZiyyk= X-Received: by 2002:a7b:ca53:: with SMTP id m19mr17297077wml.102.1543133631907; Sun, 25 Nov 2018 00:13:51 -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, 25 Nov 2018 10:13:19 +0200 Message-ID: To: aamelnikov@fastmail.fm Cc: Chris Lemmons , "" Content-Type: multipart/alternative; boundary="000000000000f8a351057b78cb68" 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, 25 Nov 2018 08:13:58 -0000 --000000000000f8a351057b78cb68 Content-Type: text/plain; charset="UTF-8" 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 --000000000000f8a351057b78cb68 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Got feedback from Chris Newman, the author of RFC3339. Thi= s RFC does not have support for non-coordinated local time intentionally, a= s the purpose of this RFC was to created a timestamp which is interoperable= , so that different systems will interpret it as the same UTC,
Therefor= e, we cannot use RFC3339 timestamp as the base for this use case, as we wan= t to allow exactly that.
I will therefore follow Alexey's sug= gestion and redefine the format in the triggers extension I-D, so that it s= uits this purpose.

Ori

<= br>
On Sun, Nov 18, 2018 at 3:32= PM Ori Finkelman <orif@qwilt.com&= gt; wrote:
Thanks,= I will do that.
Best regards,
Ori

On Sun, Nov 18, 2018 at 3:18 PM Alexey Me= lnikov <aame= lnikov@fastmail.fm> wrote:
<= div dir=3D"auto">Hi,

On 15 Nov 2018, at 12:56, Ori Finkelman &l= t;orif@qwilt.com>= ; wrote:

Hi,Looking at ISO8601, local time is simply defined by not adding the offse= t (or Z).
For example:=C2=A02018-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 f= ocused on interoperability, and when what you want is to have a determinist= ic way to establish an agreement on a specific absolute time, you can eithe= r use UTC or local time with an offset from UTC.

W= e 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 & p= aste ABNF from RFC 3339 and modify as needed.
=

Thanks,
Ori
<= br>




<= br>



On Wed, Nov 14, 2018 at 11:02 AM Ori Finkelman <orif@qwilt.com> wrote:=
Thanks Alexey,I will look=C2=A0into it.

Ori

On Tue, Nov 13, 2018 at 4:54 PM Al= exey 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


--
<= div dir=3D"ltr">Ori Finkelman
Qwilt | Work: +972-72-2221647 | Mob= ile: +972-52-3832189 | orif@qwilt.com


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


--
Ori Finkelman
Q= wilt | 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
--000000000000f8a351057b78cb68-- From nobody Wed Nov 28 02:59:48 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 5ADA9130E25; Wed, 28 Nov 2018 02:59:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 JKZoCIIfytTy; Wed, 28 Nov 2018 02:59:44 -0800 (PST) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2990F130EA2; Wed, 28 Nov 2018 02:59:44 -0800 (PST) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 434d2k5B9kz8tJt; Wed, 28 Nov 2018 11:59:42 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.41]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 434d2k4HsFz3wbH; Wed, 28 Nov 2018 11:59:42 +0100 (CET) Received: from OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0415.000; Wed, 28 Nov 2018 11:59:38 +0100 From: To: Phil Sorber , "" , "draft-fieau-cdni-interfaces-https-delegation@ietf.org" Thread-Topic: draft-fieau-cdni-interfaces-https-delegation call for adoption Thread-Index: AQHUejhrSAT5rNOzbkyKkYIj3ujN9KVlHe9Q Date: Wed, 28 Nov 2018 10:59:37 +0000 Message-ID: <32439_1543402782_5BFE751E_32439_88_1_f9d98bd4-0e52-4732-acd4-37c4e9989b86@OPEXCLILM31.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/alternative; boundary="_000_f9d98bd40e524732acd437c4e9989b86OPEXCLILM31corporateadr_" MIME-Version: 1.0 Archived-At: Subject: Re: [CDNi] draft-fieau-cdni-interfaces-https-delegation call for adoption 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: Wed, 28 Nov 2018 10:59:46 -0000 --_000_f9d98bd40e524732acd437c4e9989b86OPEXCLILM31corporateadr_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUGhpbCBhbmQgS2V2aW4sDQoNCknigJl2ZSBwb3N0ZWQgdGhlIGRyYWZ0IOKAnGRyYWZ0LWll dGYtY2RuaS1pbnRlcmZhY2VzLWh0dHBzLWRlbGVnYXRpb27igJ0sIHRoYXQgYWxzbyByZWZsZWN0 cyB0aGUgbGFzdCBmZXcgY29tbWVudHMuDQpUaGFuayB5b3UgZm9yIGFwcHJvdmFsLg0KDQpSZWdh cmRzLA0KRnJlZGVyaWMNCg0KDQpEZSA6IFBoaWwgU29yYmVyIFttYWlsdG86c29yYmVyQGFwYWNo ZS5vcmddDQpFbnZvecOpIDogbHVuZGkgMTIgbm92ZW1icmUgMjAxOCAwNDozMw0Kw4AgOiA8Y2Ru aUBpZXRmLm9yZz47IGRyYWZ0LWZpZWF1LWNkbmktaW50ZXJmYWNlcy1odHRwcy1kZWxlZ2F0aW9u QGlldGYub3JnDQpPYmpldCA6IFJlOiBkcmFmdC1maWVhdS1jZG5pLWludGVyZmFjZXMtaHR0cHMt ZGVsZWdhdGlvbiBjYWxsIGZvciBhZG9wdGlvbg0KDQpIYXZpbmcgc2VlbiBvbmx5IHBvc2l0aXZl IHN1cHBvcnRpdmUgZmVlZGJhY2ssIGFuZCBiYWNrZWQgdXAgYnkgYSBwb3NpdGl2ZSBodW0gZHVy aW5nIHRoZSBXRyBtZWV0aW5nIGluIEJhbmdrb2ssIEkgYW0gY2FsbGluZyB0aGlzIGFkb3B0aW9u IGFzIHN1Y2Nlc3NmdWwuDQoNCkNhbiB0aGUgZHJhZnQgZWRpdG9ycyBwbGVhc2Ugc3VibWl0IGEg bmV3IGRyYWZ0IHdpdGggdGhlIG5hbWUgZHJhZnQtaWV0Zi1jZG5pLWludGVyZmFjZXMtaHR0cHMt ZGVsZWdhdGlvbiBhbmQgSSB3aWxsIG1hcmsgaXQgZm9yIGFkb3B0aW9uLg0KDQpUaGFua3MhDQoN Ck9uIFN1biwgT2N0IDI4LCAyMDE4IGF0IDg6MjAgUE0gUGhpbCBTb3JiZXIgPHNvcmJlckBhcGFj aGUub3JnPG1haWx0bzpzb3JiZXJAYXBhY2hlLm9yZz4+IHdyb3RlOg0KQXQgdGhlIGxhc3QgbWVl dGluZyB3ZSBkaXNjdXNzZWQgdGhlIHBvdGVudGlhbCB0byBhZG9wdCB0aGlzIGRvY3VtZW50LiBG cmVkZXJpYyBwb3N0ZWQgYSBuZXcgdmVyc2lvbiB3aXRoIHRoZSBjaGFuZ2VzIHdlIGhhZCBkaXNj dXNzZWQgYW5kIHNvIEknZCBsaWtlIHRvIGRvIGEgZm9ybWFsIGNhbGwgZm9yIGFkb3B0aW9uIGhl cmUuDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpZWF1LWNkbmkt aW50ZXJmYWNlcy1odHRwcy1kZWxlZ2F0aW9uLw0KDQpJJ2xsIGxlYXZlIHRoaXMgb3BlbiB1bnRp bCBOb3YgMTB0aC4NCg0KVGhhbmtzLg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNl cyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxs ZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywg ZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3Ug Y2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1 ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2Fn ZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2Ug ZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwg ZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht ZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0 aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0 ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBk ZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUg YWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVu IG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK --_000_f9d98bd40e524732acd437c4e9989b86OPEXCLILM31corporateadr_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6 bm9ybWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K CW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRlIiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj5IaSBQaGlsIGFuZCBLZXZpbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPknigJl2ZSBwb3N0ZWQgdGhlIGRyYWZ0IOKAnDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ ZHJhZnQtaWV0Zi1jZG5pLWludGVyZmFjZXMtaHR0cHMtZGVsZWdhdGlvbuKAnSwgdGhhdCBhbHNv IHJlZmxlY3RzIHRoZSBsYXN0IGZldyBjb21tZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmsgeW91IGZvciBhcHBy b3ZhbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyZWRlcmljPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EZSZuYnNwOzo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUGhpbCBTb3JiZXIgW21haWx0 bzpzb3JiZXJAYXBhY2hlLm9yZ10NCjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBsdW5kaSAx MiBub3ZlbWJyZSAyMDE4IDA0OjMzPGJyPg0KPGI+w4AmbmJzcDs6PC9iPiAmbHQ7Y2RuaUBpZXRm Lm9yZyZndDs7IGRyYWZ0LWZpZWF1LWNkbmktaW50ZXJmYWNlcy1odHRwcy1kZWxlZ2F0aW9uQGll dGYub3JnPGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogZHJhZnQtZmllYXUtY2RuaS1pbnRl cmZhY2VzLWh0dHBzLWRlbGVnYXRpb24gY2FsbCBmb3IgYWRvcHRpb248bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGF2aW5nIHNlZW4gb25seSBwb3NpdGl2ZSBz dXBwb3J0aXZlIGZlZWRiYWNrLCBhbmQgYmFja2VkIHVwIGJ5IGEgcG9zaXRpdmUgaHVtIGR1cmlu ZyB0aGUgV0cgbWVldGluZyBpbiBCYW5na29rLCBJIGFtIGNhbGxpbmcgdGhpcyBhZG9wdGlvbiBh cyBzdWNjZXNzZnVsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5DYW4gdGhlIGRyYWZ0IGVkaXRvcnMgcGxlYXNlIHN1Ym1pdCBhIG5ldyBkcmFm dCB3aXRoIHRoZSBuYW1lIGRyYWZ0LWlldGYtY2RuaS1pbnRlcmZhY2VzLWh0dHBzLWRlbGVnYXRp b24gYW5kIEkgd2lsbCBtYXJrIGl0IGZvciBhZG9wdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzITxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBTdW4sIE9jdCAy OCwgMjAxOCBhdCA4OjIwIFBNIFBoaWwgU29yYmVyICZsdDs8YSBocmVmPSJtYWlsdG86c29yYmVy QGFwYWNoZS5vcmciIHRhcmdldD0iX2JsYW5rIj5zb3JiZXJAYXBhY2hlLm9yZzwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5BdCB0aGUgbGFzdCBtZWV0aW5nIHdlIGRpc2N1c3NlZCB0aGUg cG90ZW50aWFsIHRvIGFkb3B0IHRoaXMgZG9jdW1lbnQuIEZyZWRlcmljIHBvc3RlZCBhIG5ldyB2 ZXJzaW9uIHdpdGggdGhlIGNoYW5nZXMgd2UgaGFkIGRpc2N1c3NlZCBhbmQgc28gSSdkIGxpa2Ug dG8gZG8gYSBmb3JtYWwgY2FsbCBmb3IgYWRvcHRpb24gaGVyZS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmllYXUtY2RuaS1pbnRlcmZhY2VzLWh0dHBzLWRl bGVnYXRpb24vIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtZmllYXUtY2RuaS1pbnRlcmZhY2VzLWh0dHBzLWRlbGVnYXRpb24vPC9hPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ2xsIGxl YXZlIHRoaXMgb3BlbiB1bnRpbCBOb3YgMTB0aC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8UFJFPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBl dXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmls ZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91 IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBw YXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRy dWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25p cXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0 ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBm YWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29u dGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBw cm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3Ig Y29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBl bWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBt ZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3Jh bmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBj aGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91Lgo8L1BSRT48L2JvZHk+DQo8L2h0bWw+DQo= --_000_f9d98bd40e524732acd437c4e9989b86OPEXCLILM31corporateadr_-- From nobody Wed Nov 28 09:15:39 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 54DE913101B; Wed, 28 Nov 2018 09:15:27 -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: <154342532722.13517.6273905790092556010@ietfa.amsl.com> Date: Wed, 28 Nov 2018 09:15:27 -0800 Archived-At: Subject: [CDNi] I-D Action: draft-ietf-cdni-interfaces-https-delegation-00.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: Wed, 28 Nov 2018 17:15:31 -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 extensions for HTTPS delegation Authors : Frederic Fieau Emile Stephan Sanjay Mishra Filename : draft-ietf-cdni-interfaces-https-delegation-00.txt Pages : 9 Date : 2018-11-28 Abstract: The delivery of content over HTTPS involving multiple CDNs raises credential management issues. This document proposes extensions in CDNI Control and Metadata interfaces to setup HTTPS delegation from an Upstream CDN (uCDN) to a Downstream CDN (dCDN). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-interfaces-https-delegation/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cdni-interfaces-https-delegation-00 https://datatracker.ietf.org/doc/html/draft-ietf-cdni-interfaces-https-delegation-00 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 Wed Nov 28 09:23:06 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 3FD01130FA9 for ; Wed, 28 Nov 2018 09:23:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.899 X-Spam-Level: X-Spam-Status: No, score=-14.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no 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 syqXLZbaB8MJ for ; Wed, 28 Nov 2018 09:23:02 -0800 (PST) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by ietfa.amsl.com (Postfix) with SMTP id 9E9F7130F63 for ; Wed, 28 Nov 2018 09:23:02 -0800 (PST) Received: (qmail 64876 invoked by uid 99); 28 Nov 2018 17:23:01 -0000 Received: from mail-relay.apache.org (HELO mailrelay2-lw-us.apache.org) (207.244.88.137) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 Nov 2018 17:23:01 +0000 Received: from mail-it1-f182.google.com (mail-it1-f182.google.com [209.85.166.182]) by mailrelay2-lw-us.apache.org (ASF Mail Server at mailrelay2-lw-us.apache.org) with ESMTPSA id E93CD2677 for ; Wed, 28 Nov 2018 17:23:00 +0000 (UTC) Received: by mail-it1-f182.google.com with SMTP id z7so5645635iti.0 for ; Wed, 28 Nov 2018 09:23:00 -0800 (PST) X-Gm-Message-State: AA+aEWbtNRzfSuzLHVjd5U6YNDilNMD9/wWNrfoqg9M6sZveSBcSXwil +3MS3u2DysH2Vqel+M3mLy8JjnlzsSyIcMWresg= X-Google-Smtp-Source: AFSGD/W5/9I90R65PNNnlCxqq5a/YoFerb7aMdp430pPSlVqlKCOCBRC5/lZSHD1D+ZUBB7Qg5OMkepqRw/wuDBxZkU= X-Received: by 2002:a24:b641:: with SMTP id d1-v6mr3347081itj.133.1543425780424; Wed, 28 Nov 2018 09:23:00 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Phil Sorber Date: Wed, 28 Nov 2018 10:22:48 -0700 X-Gmail-Original-Message-ID: Message-ID: To: "" Content-Type: multipart/alternative; boundary="00000000000061286f057bbcd126" Archived-At: Subject: Re: [CDNi] Call for Adoption on draft-finkelman-cdni-triggers-sva-extensions 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: Wed, 28 Nov 2018 17:23:04 -0000 --00000000000061286f057bbcd126 Content-Type: text/plain; charset="UTF-8" Having seen only positive supportive feedback, and backed up by a positive hum during the WG meeting in Bangkok, I am calling this adoption as successful. Can the draft editors please submit a new draft with the name draft-ietf-cdni-triggers-extensions and I will mark it for adoption. Thanks! On Sun, Nov 11, 2018 at 8:57 PM Phil Sorber wrote: > Hello All, > > In Bangkok we had an update on the document as well as clarification about > the need for a re-charter, or more explicitly, the lack thereof, and a hum > for interest in adopting this document. The hum was positive and I would > like to open a Call For Adoption on it. If you weren't present at the > meeting, or perhaps came up with some new opinions, please voice them here. > > Link to doc: > https://datatracker.ietf.org/doc/draft-finkelman-cdni-triggers-sva-extensions/ > > This CFA will be open until Nov 25th. > > Thanks. > > --00000000000061286f057bbcd126 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Having seen only positive supportive feedback, and ba= cked up by a=20 positive hum during the WG meeting in Bangkok, I am calling this=20 adoption as successful.

Can the draft = editors please submit a new draft with the name draft-ietf-cdni-triggers-ex= tensions and I will mark it for adoption.

Thanks!<= /div>

On Sun, Nov 11, = 2018 at 8:57 PM Phil Sorber <sorber= @apache.org> wrote:
Hello All,

In Bangkok we had an= update on the document as well as clarification about the need for a re-ch= arter, or more explicitly, the lack thereof, and a hum for interest in adop= ting this=20 document. The hum was positive and I would like to open a Call For=20 Adoption on it. If you weren't present at the meeting, or perhaps came= =20 up with some new opinions, please voice them here.

Link to doc: https://datatracker.ietf.or= g/doc/draft-finkelman-cdni-triggers-sva-extensions/

This CFA will be open until Nov 25th.

Thanks= .

--00000000000061286f057bbcd126-- From nobody Wed Nov 28 13:50:06 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 D46F0128A6E for ; Wed, 28 Nov 2018 13:50:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.347 X-Spam-Level: X-Spam-Status: No, score=-3.347 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, URIBL_BLOCKED=0.001] 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 uHLE5uoQkokK for ; Wed, 28 Nov 2018 13:50:02 -0800 (PST) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 2B2F113104D for ; Wed, 28 Nov 2018 13:50:02 -0800 (PST) Received: by mail-wm1-x329.google.com with SMTP id y185so4948455wmd.1 for ; Wed, 28 Nov 2018 13:50:02 -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=NHlbyh3u4iSH9TBkOYPXrDKcFWzSvv+K0CIHbrxtxxQ=; b=ao2qwA8/BJMCsso6shFIstOnKDuukmxbdWPLj/VBy7leaWTF1H4Whi0v/Mfdm5AG8M 2LI1kHLck51yHpNFyMxNfxuaHI9SHsw/sLQuopwgeqR/r8ay066ElEbROEvwaSl7fyYv acnaqQdwSBUzk9ZAf7QR55c7KE7Urq+ZaYzfePyAVudJ4gLS1EN9A57xdA85ib/OnVpa w7TToRfR2r5iLGhzDs87mnCDTNerwugfngZ2u33NHWsu1lZ1rdOoW7U2M83b3MPZKzbd biz30+2kBGsZIK7QEY6LeA7PsrwvMLCv7Zd1byNxVepju/E4lvk54A0dIkQD4OFpkrdi 7jOQ== 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=NHlbyh3u4iSH9TBkOYPXrDKcFWzSvv+K0CIHbrxtxxQ=; b=MObp+5aEnTBb4FSeqSqsz8X054Vki/IqFWdUOCsOASeBWXBILHs2Fg1g+9YbPTN/5n Jd9w0Ly1MuJBrhQUXLmxu3faC2mZC90xlae37EIloY2iMQltNDsdXVxt7sCiKdNyu5AV H0by2vieBDIlHzhcyvFTMD9RVYGsCvJA0MtZSPOQzm882RZxh84+FvAaKWmI7f8V75ER mCu9Ec5RUDo2uD28OFWK+lDK9uPJevPwI5uxEj80khQcYjSiOmvu+AcnI6zG66GmZcFw oZuGhDr2BCnD6W2+IWIpF4rkSUxV8vkGVj0XcX2ba6xylOcDJdEp1qJP6bpSt7ChsKSo 0PXg== X-Gm-Message-State: AA+aEWZzO/8306R2wUAd4uFTU/XS9UD5mkAHq8gn32zp3POwxxMKohdq NSVp2O6ag3rWKeroD9MJpcTfgihq/1J2h57uJYT08g== X-Google-Smtp-Source: AFSGD/X+5vAupHwUXKINQ+zbeRF5SBQcy0E+mvDa3D4VkuVDYrDg582wwkGoIJWVJDqTs+8OU10U7MLEaepDPwvkk6I= X-Received: by 2002:a7b:c142:: with SMTP id z2mr2242wmi.102.1543441800187; Wed, 28 Nov 2018 13:50:00 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ori Finkelman Date: Wed, 28 Nov 2018 23:49:49 +0200 Message-ID: To: Phil Sorber Cc: "" Content-Type: multipart/alternative; boundary="0000000000003b68ca057bc08c44" Archived-At: Subject: Re: [CDNi] Call for Adoption on draft-finkelman-cdni-triggers-sva-extensions 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: Wed, 28 Nov 2018 21:50:05 -0000 --0000000000003b68ca057bc08c44 Content-Type: text/plain; charset="UTF-8" I'll do that. Thanks, Ori On Wed, Nov 28, 2018, 19:23 Phil Sorber wrote: > Having seen only positive supportive feedback, and backed up by a positive > hum during the WG meeting in Bangkok, I am calling this adoption as > successful. > > Can the draft editors please submit a new draft with the name > draft-ietf-cdni-triggers-extensions and I will mark it for adoption. > > Thanks! > > On Sun, Nov 11, 2018 at 8:57 PM Phil Sorber wrote: > >> Hello All, >> >> In Bangkok we had an update on the document as well as clarification >> about the need for a re-charter, or more explicitly, the lack thereof, and >> a hum for interest in adopting this document. The hum was positive and I >> would like to open a Call For Adoption on it. If you weren't present at the >> meeting, or perhaps came up with some new opinions, please voice them here. >> >> Link to doc: >> https://datatracker.ietf.org/doc/draft-finkelman-cdni-triggers-sva-extensions/ >> >> This CFA will be open until Nov 25th. >> >> Thanks.. >> >> _______________________________________________ > 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 --0000000000003b68ca057bc08c44 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'll do that.=C2=A0
Thanks,
Ori

On Wed, Nov 28, 2018, 19:23 Phil Sorber <sorber@apache.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
Having seen only positi= ve supportive feedback, and backed up by a=20 positive hum during the WG meeting in Bangkok, I am calling this=20 adoption as successful.

Can the draft = editors please submit a new draft with the name draft-ietf-cdni-triggers-ex= tensions and I will mark it for adoption.

Thanks!<= /div>

On Sun, Nov 11, = 2018 at 8:57 PM Phil Sorber <sorber@apache.org> wrote:
Hello All,

In Bangkok we had an update on the document as well as clarification= about the need for a re-charter, or more explicitly, the lack thereof, and= a hum for interest in adopting this=20 document. The hum was positive and I would like to open a Call For=20 Adoption on it. If you weren't present at the meeting, or perhaps came= =20 up with some new opinions, please voice them here.

Link to doc: https://datatracker.ietf.or= g/doc/draft-finkelman-cdni-triggers-sva-extensions/

This CFA will be open until Nov 25th.

Thanks= ..

_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni
--
Ori Finkelman
Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 |=C2=A0orif@qwilt.com
--0000000000003b68ca057bc08c44-- From nobody Thu Nov 29 12:24:52 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 39D2C130ED1; Thu, 29 Nov 2018 12:24:50 -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: <154352309019.25974.3480016030894624867@ietfa.amsl.com> Date: Thu, 29 Nov 2018 12:24:50 -0800 Archived-At: Subject: [CDNi] I-D Action: draft-ietf-cdni-triggers-extensions-00.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: Thu, 29 Nov 2018 20:24:50 -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-00.txt Pages : 42 Date : 2018-11-29 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-00 https://datatracker.ietf.org/doc/html/draft-ietf-cdni-triggers-extensions-00 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 Thu Nov 29 14:04:31 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 9073E1293FB for ; Thu, 29 Nov 2018 14:04:30 -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 KTZ1YHj1ks4A for ; Thu, 29 Nov 2018 14:04:27 -0800 (PST) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 2EF6B126DBF for ; Thu, 29 Nov 2018 14:04:27 -0800 (PST) Received: by mail-wm1-x332.google.com with SMTP id y139so3817448wmc.5 for ; Thu, 29 Nov 2018 14:04:27 -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; bh=ZSiCL2jSmQIiQvNvDuw4uTL/oixw7JLz0Gnln+IFKN4=; b=n/LYThQtrps0oE7bvkUYF7RArrCbRUyRf9n/ij2aONA5KpauPFIIoriOV07oHfziGB vw/taG87ZCtWsovAYqquSx+P94HTot/4MhV4slSNmPRTAw8ebGd68PeD6eIM3nQsDLj3 pyyu4QXlSS/MjlIVMQjXN+In0NIgUydBp7hiKZdZQAX49peMCNQV3Jk+tt1RhUPNpuyw LViKp1OVfQRTbXOeocAUeKGoabhNPAi7LP5SWo0Ri56hWVywT4l/U3LhUeGyjkDofkWA l9BupdRT/gm5BH1f1+4z9Prt0C52t5NdkO8a8w4glnFE+waFz2NIdku98cq0053kajGQ /iww== 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; bh=ZSiCL2jSmQIiQvNvDuw4uTL/oixw7JLz0Gnln+IFKN4=; b=Cm0l4nuWvY748QWpehMp/4e45/hna3p723UshY13OwRUpqD8izYTOmUxwR2reaWFDq TPMuwMPiF3FVOpCPl6OUR85YQj61jzP6VQULc0afovEOmvkYPagrIFcf8UFCNfNqBgQl +LfDbpqEweIwal15b5niKjMcgCTv0aZHYC5quU8lxiIRURc9EFut8M8MBKasVlCNSX6q /J+mbrR0/8zasz+676bIMtoOylQH0E9d+Pc9V3xprCE719tG21Oa2HQBZvkgMJVDEe7d 7V0OJpk+zgDbOiAAEw+A3aSrVTp8/04KkoS4FiUp+D2Q+7DRbPapiPFH0HGdHm+UEaex XNVw== X-Gm-Message-State: AA+aEWawWnNg6MYVuWRi6MxTetxpsGDt2sehzySXaf+1HiIlmrf9CxPI WZNJqBhv4kCzJqDzRcsFpp8K3J8QpOWVYa/0PYM5ncs/duQ= X-Google-Smtp-Source: AFSGD/XguHAlf5t+ywmuL10HYmZoluNJ2IE1JusShJWjCJSFUsMyva0nSBgK6wuGZiZUb3mOBbDqSzIBxxF6z2BBokA= X-Received: by 2002:a1c:2e0c:: with SMTP id u12mr2658052wmu.81.1543529065091; Thu, 29 Nov 2018 14:04:25 -0800 (PST) MIME-Version: 1.0 References: <154352309033.25974.1895614830656451372.idtracker@ietfa.amsl.com> In-Reply-To: <154352309033.25974.1895614830656451372.idtracker@ietfa.amsl.com> From: Ori Finkelman Date: Fri, 30 Nov 2018 00:03:57 +0200 Message-ID: To: "" Content-Type: multipart/alternative; boundary="000000000000a02ab2057bd4dd77" Archived-At: Subject: [CDNi] Fwd: New Version Notification for draft-ietf-cdni-triggers-extensions-00.txt 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: Thu, 29 Nov 2018 22:04:30 -0000 --000000000000a02ab2057bd4dd77 Content-Type: text/plain; charset="UTF-8" Hi, The triggers extension is now a working group draft. The github is in https://github.com/orifinkelman/cdni-extensions Comments are most welcome on this thread or as github issues (better). Thanks, Ori ---------- Forwarded message --------- From: Date: Thu, Nov 29, 2018 at 10:24 PM Subject: New Version Notification for draft-ietf-cdni-triggers-extensions-00.txt To: Sanjay Mishra , Ori Finkelman A new version of I-D, draft-ietf-cdni-triggers-extensions-00.txt has been successfully submitted by Ori Finkelman and posted to the IETF repository. Name: draft-ietf-cdni-triggers-extensions Revision: 00 Title: CDNI Control Triggers Interface Extensions Document date: 2018-11-29 Group: cdni Pages: 42 URL: https://www.ietf.org/internet-drafts/draft-ietf-cdni-triggers-extensions-00.txt Status: https://datatracker.ietf.org/doc/draft-ietf-cdni-triggers-extensions/ Htmlized: https://tools.ietf.org/html/draft-ietf-cdni-triggers-extensions-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-cdni-triggers-extensions 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. 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. The IETF Secretariat -- *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com --000000000000a02ab2057bd4dd77 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
The triggers extension is now a w= orking group draft.
Comments are most welcome on this thread or as gith= ub issues (better).

Thanks,
Ori


---------- Forwarded = message ---------
From: <internet-drafts@ietf.org>
Date: Thu, Nov= 29, 2018 at 10:24 PM
Subject: New Version Notification for draft-ietf-c= dni-triggers-extensions-00.txt
To: Sanjay Mishra <sanjay.mishra@verizon.com>, Ori Finkelman = <orif@qwilt.com>

<= br>
A new version of I-D, draft-ietf-cdni-triggers-extensions-00.txt
has been successfully submitted by Ori Finkelman and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-cdni-triggers-exte= nsions
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CDNI Control Triggers Interface Ex= tensions
Document date:=C2=A0 2018-11-29
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 cdni
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 42
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-cd= ni-triggers-extensions-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-cdni-triggers-exten= sions/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-ietf-cdni-triggers-extensions-00 Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-cdni-triggers-ext= ensions


Abstract:
=C2=A0 =C2=A0This document updates RFC 8007 to include generic extensions a= nd more
=C2=A0 =C2=A0granular content matching options, required by the Open Cachin= g
=C2=A0 =C2=A0architecture.=C2=A0 The Open Caching working group of the Stre= aming Video
=C2=A0 =C2=A0Alliance is focused on the delegation of video delivery reques= t from
=C2=A0 =C2=A0commercial CDNs to a caching layer at the ISP.=C2=A0 In that a= spect, Open
=C2=A0 =C2=A0Caching is a specific use case of CDNI, where the commercial C= DN is
=C2=A0 =C2=A0the upstream CDN (uCDN) and the ISP caching layer is the downs= tream
=C2=A0 =C2=A0CDN (dCDN).=C2=A0 The extensions specified in this document to= the CDNI
=C2=A0 =C2=A0Control Interface / Triggers are derived from requirements of = Open
=C2=A0 =C2=A0Caching but are applicable to CDNI use cases in general.





Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



--
Ori Finkelman
Qwilt | Work: +972-7= 2-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com
<= /div> --000000000000a02ab2057bd4dd77--