From nobody Sun Feb 4 05:42:54 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 86E83126FB3 for ; Sun, 4 Feb 2018 05:42:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 wQDgi-qNx3YK for ; Sun, 4 Feb 2018 05:42:52 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 B3886124BE8 for ; Sun, 4 Feb 2018 05:42:51 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id j21-v6so9456429wmh.1 for ; Sun, 04 Feb 2018 05:42:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qwilt-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=HBxpziY/PJ8ZysbSyqKrU4UqhN7DpFoSV28CY++HLqk=; b=MilXcADD8muWlPtZbYxIOWQ1pXquQRNmWOOKU9MShgU/QozS6IacT2IteKlS04fUSt +7JzqXeszCXDW/uKu1GlolEvAV4eS6pRJGWnXpcqOzZ4DCdeUiaV6i9WCd3E3XAGwpi8 9vA09ljglPf9HXxktSY4Yk8PNj3ONKz5HjwujxGn3vPxuoEXZeTpD/Tm2Z5gsoevYRiH 59nn4qHLqIUGxgC4Brsc2+lKFnqdZLN+7g186Q6VwBze0+J5gyB2f0WPppNCQzQI3FL+ pZCxiV2JWYpV5QCnCNcTLDs6EfSg7n+WxT/BlOlc2VnWD94mXzs/VF4dHHTdehCxDwhR dHBw== 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=HBxpziY/PJ8ZysbSyqKrU4UqhN7DpFoSV28CY++HLqk=; b=osrBivzZOiZukll9tYFiPYkFBqg9xOdzlHTMq6Mls/W5l2IQY6xvM5GUSCTNddlYlN NiOnUZCBJZt2c7jx3mUrc0/qa+GOSR5bk0RIHB0ghW+Reen3hp5YsaumB0ODsU0cD+qf RHsyhq73XaVJUQECKi3STiDCTcsaG3LJAHcb77dsQc0rEmH9ryIjV6VmGizAqYIU3vH3 l5MPJ4n8lfMW5lUB3e5i1wFlSVrKYYBeG424gwXWBb6IW6kMU7Ba4N/B/oG38fUznp1A yzY1RhnA2R+O9ry6NEyryi5nIxOqvGKPhQOkclu1q+tz4TwQrkVSf4cOvNVh3Aiy56ZV fJ7A== X-Gm-Message-State: AKwxytc7jnheUiwTKm3GV6FaTCyH9uOy0A8e5o0hLFZ/GI972h+I0Olw eSIcx+NAehH9wvYd5ZImljWzv1JJ5s2h54y4an8wpdYKTUs= X-Google-Smtp-Source: AH8x225UOTJVAzf6NIaEAwexx8WQlhO+9uo89hJwKIbWjN/6jhtKsDPJjkPawQPA6EcaZbNI8yIhxl31WpzR6iyuuIE= X-Received: by 10.28.182.86 with SMTP id g83mr33118383wmf.75.1517751769761; Sun, 04 Feb 2018 05:42:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.127.71 with HTTP; Sun, 4 Feb 2018 05:42:19 -0800 (PST) From: Ori Finkelman Date: Sun, 4 Feb 2018 15:42:19 +0200 Message-ID: To: "" Content-Type: multipart/alternative; boundary="001a1148f4821824ee0564631f3c" Archived-At: Subject: [CDNi] SVA extensions next drafts X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.22 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 Feb 2018 13:42:53 -0000 --001a1148f4821824ee0564631f3c Content-Type: text/plain; charset="UTF-8" Hi, I am planning to split the current SVA open caching draft https://tools.ietf.org/html/draft-finkelman-cdni-sva-extensions-00 into separate functions. + request routing + content management (triggers) + URI signing + CORS delegation + Logging each will have its own draft, shorter and easier to review and edit. Let me know if there are any reservations. Best regards, Ori -- *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com --001a1148f4821824ee0564631f3c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
I am planning to split the current SVA open cachin= g draft=C2=A0https://tools.ietf.org/html/draft-finkelman-cdni-sva-exten= sions-00 into separate functions.
+ request routing
+ content management (triggers)
+ URI signing=C2=A0
+ = CORS delegation
+ Logging
each will have its own draft,= shorter and easier to review and edit.

Let me kno= w if there are any reservations.=C2=A0
Best regards,
Or= i


--
Ori Finkelman
Qwilt | Work: +972-72-2221647= | Mobile: +972-52-3832189 | orif@qwilt.com
--001a1148f4821824ee0564631f3c-- From nobody Mon Feb 5 06:40:26 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 1AA52127058 for ; Mon, 5 Feb 2018 06:40:25 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=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 eV_ae8ygPYf1 for ; Mon, 5 Feb 2018 06:40:22 -0800 (PST) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (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 D0984127023 for ; Mon, 5 Feb 2018 06:40:21 -0800 (PST) Received: by mail-wr0-x233.google.com with SMTP id s5so29855241wra.0 for ; Mon, 05 Feb 2018 06:40:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qwilt-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=iPZxxCilMaCUYTk/u/Bri/oLZBVbIN+vFDvcFEGwaDw=; b=a3XmAwmuUcljvAJw49h+bqLyfEb35/+m3VQ7p3nkkJC37X+5cYpWv/b0Icf6VYvxyw EhXC7q4elmIwR3gzfig4QUPGOeR8ok2IxdzA83omTxrq/1Qrhm4b/FTNrUHes23QpkbZ TGbaAWlkFoOJlUevXZkds03tDjFECYKWQJ6loZgsPRYeSH9zHaC/Q6UznyA+NPnyrdje gMD19J6dQBku4CHJbUh5bFnndOP3FFvHkilCGcMdeG9ofxorbTr1XEwFfL/5EPPjxnFI 7aY4O2Uy8lvp338r/0WumAoQIQBr1b3cuTO3sloRIHmtxlY9MgZg+uYDCKlwbJfyDHXr R9eA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=iPZxxCilMaCUYTk/u/Bri/oLZBVbIN+vFDvcFEGwaDw=; b=a4+goANuAXtTXEUlVXSt6cOLMmb40h8gOJ2wMfddhioLu0j8eWt4fk02WQMM7WLU3C ViYg0aRfO9+H4KudFc55yERUqPSpwzjs91pEdgiVicQKpptAptRSRloWJy3AtuTJ/eqb qX830lxg3tvyUJ0B5dnHNzJvEyJAeDTER03LxUuEH/W3luQBw3TqMLr+i1DLQOtSN9Lg b7g7mc1PzGg+wwv9nO0F2ORsT8omRIVmtFTNWZ+ZFM0PP7F97+WGYofCzyNeBAGQUyDh Z04GlF5jSZ80uAP5VGrQ2VsS0c1B4PR32kFr5L6dOHqAd0JBvMLVvj8jlg/TiT1i5bgD iybg== X-Gm-Message-State: AKwxyteDLl8+awjxs28WlnhN4Rt8w0iUgDEUTLwqv2VYgDwkiiFNYzz9 7KBk0yIJJl14ct+b9jkopHap0jrdOJc95dK9g+/23llG X-Google-Smtp-Source: AH8x227JIMXKMAb88eF5ZI10vZQX2ttgM+uPAqkmPFNZtTQFIfa1Ye2Jr7k3jsZe4+l2lDNVS/pM8MCY9FKbiezHE84= X-Received: by 10.223.148.165 with SMTP id 34mr27527495wrr.52.1517841620162; Mon, 05 Feb 2018 06:40:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.127.71 with HTTP; Mon, 5 Feb 2018 06:39:49 -0800 (PST) In-Reply-To: References: From: Ori Finkelman Date: Mon, 5 Feb 2018 16:39:49 +0200 Message-ID: To: "" Content-Type: multipart/alternative; boundary="94eb2c0d9e1898810a0564780ab2" Archived-At: Subject: Re: [CDNi] SVA extensions next drafts X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.22 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 Feb 2018 14:40:25 -0000 --94eb2c0d9e1898810a0564780ab2 Content-Type: text/plain; charset="UTF-8" Also, I am planning to draft the trigger extensions and the triggers capability objects as a separate draft for extension of RFC8007. Best regards, Ori On Sun, Feb 4, 2018 at 3:42 PM, Ori Finkelman wrote: > Hi, > I am planning to split the current SVA open caching draft > https://tools.ietf.org/html/draft-finkelman-cdni-sva-extensions-00 into > separate functions. > + request routing > + content management (triggers) > + URI signing > + CORS delegation > + Logging > each will have its own draft, shorter and easier to review and edit. > > Let me know if there are any reservations. > Best regards, > Ori > > > -- > > *Ori Finkelman*Qwilt | Work: +972-72-2221647 <072-222-1647> | Mobile: > +972-52-3832189 <052-383-2189> | orif@qwilt.com > -- *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com --94eb2c0d9e1898810a0564780ab2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Also,=C2=A0
I am planning to draft the trigger extensi= ons and the triggers capability objects as a separate draft for extension o= f RFC8007.

Best regards,
Ori
=

On Sun, Feb 4, 20= 18 at 3:42 PM, Ori Finkelman <orif@qwilt.com> wrote:
Hi,
I am planning to split the= current SVA open caching draft=C2=A0https://tools.ie= tf.org/html/draft-finkelman-cdni-sva-extensions-00 into separ= ate functions.
+ request routing
+ content management (= triggers)
+ URI signing=C2=A0
+ CORS delegation
+ Logging
each will have its own draft, shorter and easier to = review and edit.

Let me know if there are any rese= rvations.=C2=A0
Best regards,
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-38321= 89 | o= rif@qwilt.com
--94eb2c0d9e1898810a0564780ab2-- From nobody Mon Feb 5 23:43:33 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 988F41250B8 for ; Mon, 5 Feb 2018 23:43:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 (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 CimSFbjpA0ik for ; Mon, 5 Feb 2018 23:43:29 -0800 (PST) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::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 DDADE120727 for ; Mon, 5 Feb 2018 23:43:28 -0800 (PST) Received: by mail-wr0-x22b.google.com with SMTP id w50so875561wrc.2 for ; Mon, 05 Feb 2018 23:43:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qwilt-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wFXPDShOhhKV0qPPRhigMr7KuVklDCtVWcD4hkAVh/s=; b=dJ5qYDqAXBd5l7y2rUhoAf7hjwr2EYA6ZGzrCJIPdSAwqDCq5Sw1Z3sdlJspK8qO+q Z33+CRCvX/GmI/4Koyc6ht5ZLPX7e2VpUAsW8PI2K32WaRsMEG1vd9qAvctLOKLcqNbK fYapopolihaj6qX0In69YkkGhz0tneYb8f0Qlh9Ux2gZNjxSjwvPPcUM3+Ev339MsJIa WSYSKQljH1lr6KYuLyNibpSrImpkTJhtTkYGhsoD/QRCTvpAdkyUfvo/AhC06tCsgpS9 2EDrE7DxbEMMxyAgXpx+5tao76oC3czki9Aq4jrpD5N1aC7R0w4r/CGNCgQVMsU1ebKB yP1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wFXPDShOhhKV0qPPRhigMr7KuVklDCtVWcD4hkAVh/s=; b=DqQq2HJeo5serRn9mhgvuGKF+9QSgJmuzfFLKALNDs2/sJnUlOiIDdlTzRU3r/mQCg euJSWZCRzyNA2Q562EnbQFYdZQXobc179EmfqInZeQwesKAl5X27jv40d+IsD4/vR/IF iGiQLoK0s/c9yXud9GvJEK1J2xHGOPb6KIgucA+zJQtrdiPP8b9xQPCCPJz6SFi+cWq5 JmnhVePkNi+0KjsdoGeqiyDDFo72Q/oF98D82Douk/tk2VHhWkLSNPUVDd8hypIwQiNJ PPmRfZArRcPHRjsKWGL9jOQW6TVcpyr0mBAH2hX/7j01ch2Kt+fVDgLBhLbzG0nW5vbF OR1A== X-Gm-Message-State: APf1xPCTm7qg0itHSBrYfyCAXGnK+BIjLYLxUGIV530Zkjq01fYY8FnF mk2ilZxHSLye5SkT5FyYj21BXJ/qlRadq8tDvO+jzLtRHXI= X-Google-Smtp-Source: AH8x2251cjg90LspwUZ5h8L54xtsvY2hBbD4rPhwPZeqfJJSU8Bfw7F2F+abhI39Q0RCEgJoXwFLZLGax0YHSCIhQqU= X-Received: by 10.223.148.165 with SMTP id 34mr1250588wrr.52.1517903007360; Mon, 05 Feb 2018 23:43:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.127.71 with HTTP; Mon, 5 Feb 2018 23:42:56 -0800 (PST) In-Reply-To: References: <150937917932.7823.7624674920223255542.idtracker@ietfa.amsl.com> From: Ori Finkelman Date: Tue, 6 Feb 2018 09:42:56 +0200 Message-ID: To: Kevin Ma Cc: Ben Niven-Jenkins , "" Content-Type: multipart/alternative; boundary="94eb2c0d9e188ebdb20564865584" Archived-At: Subject: Re: [CDNi] Triggers playlist: draft-finkelman-cdni-sva-extensions-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.22 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 Feb 2018 07:43:32 -0000 --94eb2c0d9e188ebdb20564865584 Content-Type: text/plain; charset="UTF-8" Kevin, Ben, Colleagues, I am working on the playlist specifications and would like to get your views on the question of playlist types. Should it be implicit from the playlist file extension (or even from the file format) for example *.m3u8 is HLS, *.ismc is MSS, *.mpd is DASH. or, the palylist object should explicitly state that type of playlist, for example: { "playlist": "https://www.example.com/a/b/c/1/index.m3u8", "type": hls } I think that the explicit option is preferable due to the following + it allows to register more types + it allows for private implementations to have their own private types. + it allows the dCDN to advertise which types it supports via the FCI (I am working on extending it to support trigger objects). Thanks, Ori On Thu, Nov 30, 2017 at 7:35 AM, Kevin Ma wrote: > (as an individual) > > > [OF] >> I think the dCDN should return an error for unsupported format > and the uCDN should not delegate that service to the dCDN > > Ideally, the uCDN would not attempt to send a playlist URL if the dCDN has > not advertised the playlist URL trigger capability. > > > Is the uCDN expected to fallback to producing a trigger request with the > URLs from the playlist enumerated as *.urls/*.patterns? > > I would expect so. I think of the playlist URL more as an optional > optimization. Without this optimization, the uCDN would be using > individual urls/patterns anyway -- though for prepositioning, patterns are > trickier and the playlist becomes arguably more useful. > > > On Wed, Nov 29, 2017 at 11:57 AM, Ori Finkelman wrote: > >> Hi Ben, >> Please see some comments and answers below >> >> On Tue, Nov 28, 2017 at 2:28 PM, Ben Niven-Jenkins < >> ben@niven-jenkins.co.uk> wrote: >> >>> Ori, Colleagues, >>> >>> I just read draft-finkelman-cdni-sva-extensions-00 and have some >>> comments I will send in separate emails to keep each conversation to a >>> single topic. >>> >>> >>> > On 16 Nov 2017, at 12:27, Kevin Ma wrote: >>> > >>> > For Triggers playlist, a long time ago we decided to not deal with >>> HTTP adaptive streaming to simplify the initial scope, but I think video >>> and HAS awareness is probably necessary and worthwhile for us to >>> re-address. I think I like content.playlists better than playlist.urls, >>> but that's a detail. >>> >>> Support for multiple optional playlist formats places a burden on the >>> dCDN to support the multiple playlist formats. Multiple optional playlist >>> formats places a burden on the uCDN, e.g. it needs to be able to handle a >>> dCDN that does not support a particular playlist e.g. by transforming the >>> playlist to a dCDN supported format or by falling back to a list of URLs >>> carried in the triggers request. >>> >> [OF] >> Another option would be for the uCDN NOT to delegate traffic of >> un-supported playlist format. That would motivate the dCDN to support all >> of them. >> >>> >>> Support for multiple optional playlist formats therefore (IMO) works >>> against interoperability. What is the use case for requiring multiple >>> optional playlist formats? >>> >> [OF] >> I agree that multiple formats is not in favor of >> interoperability, but this is where the video industry currently stands, so >> we can decide not to standardize it but then we will need to find other >> solutions for the video use cases. ABR protocol awareness is something >> video CDNs have to do anyway. Features like trans-packaging at the edge are >> already being discussed and developed, and for trans-packaging the dCDN >> cache has to be manifest type aware. >> So, basically we could treat it as just a list of files, but I am not >> sure it is in favor of the whole solution. >> >>> >>> What is the envisioned model if a dCDN does not support playlists in >>> trigger requests? Is the uCDN expected to fallback to producing a trigger >>> request with the URLs from the playlist enumerated as *.urls/*.patterns? >>> >> [OF] >> I think the dCDN should return an error for unsupported format >> and the uCDN should not delegate that service to the dCDN. >> >> >>> >>> Thanks >>> Ben >>> >>> >>> >> >> >> -- >> >> *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 | Mobile: +972-52-3832189 | orif@qwilt.com --94eb2c0d9e188ebdb20564865584 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Kevin, Ben,=C2=A0 Colleagues,

I am= working on the playlist specifications and would like to get your views on= the question of playlist types.

Should it be impl= icit from the playlist file extension (or even from the file format) for ex= ample *.m3u8 is HLS, *.ismc is MSS, *.mpd is DASH.=C2=A0
or, = the palylist object should explicitly state that type of playlist, for exam= ple:
=C2=A0 =C2=A0 {=C2=A0
=C2=A0 =C2=A0 =C2=A0 = =C2=A0"playlist": "https://www.example.com/a/b/c/1/index.m3u8",=C2=A0 = =C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0"type": hls
=C2=A0 =C2=A0 }

I think that the expl= icit option is preferable due to the following
+ it allows to reg= ister more types
+ it allows for private implementations to have = their own private types.
+ it allows the dCDN to advertise which = types it supports via the FCI (I am working on extending it to support trig= ger objects).

Thanks,
Ori

=



On Thu, Nov 30, 2017 at 7:35 AM, Kevin Ma <kevin.j.ma.ietf@gmail.com> wrote:
(as an individual)

> [OF] >> I think the dCDN should return an error for = unsupported format and the uCDN should not delegate that service to the dCD= N

Ideally, the uCDN would not attempt to send a p= laylist URL if the dCDN has not advertised the playlist URL trigger capabil= ity.

> Is the uCDN expected to= fallback to producing a trigger request with the URLs from the playlist en= umerated as *.urls/*.patterns?

I would expe= ct so.=C2=A0 I think of the playlist URL more as an optional optimization.= =C2=A0 Without this optimization, the uCDN would be using individual urls/p= atterns anyway -- though for prepositioning, patterns are trickier and the = playlist becomes arguably more useful.


On Wed, Nov 29, 2017 at 11:= 57 AM, Ori Finkelman <orif@qwilt.com> wrote:
Hi Ben,
Please see = some comments and answers below

On Tue, Nov 28, 2017 at 2:28 PM, Ben Niven-Jenkins <ben@niven-jenkins.co.uk> wrote:
Ori, Colleagues,

I just read draft-finkelman-cdni-sva-extensions-00 and have some comme= nts I will send in separate emails to keep each conversation to a single to= pic.


> On 16 Nov 2017, at 12:27, Kevin Ma <kevin.j.ma.ietf@gmail.com> wrote: >
>=C2=A0 =C2=A0For Triggers playlist, a long time ago we decided to not d= eal with HTTP adaptive streaming to simplify the initial scope, but I think= video and HAS awareness is probably necessary and worthwhile for us to re-= address.=C2=A0 I think I like content.playlists better than playlist.urls, = but that's a detail.

Support for multiple optional playlist formats places a burden on the dCDN = to support the multiple playlist formats. Multiple optional playlist format= s places a burden on the uCDN, e.g. it needs to be able to handle a dCDN th= at does not support a particular playlist e.g. by transforming the playlist= to a dCDN supported format or by falling back to a list of URLs carried in= the triggers request.
[OF] >> Another option wo= uld be for the uCDN NOT to delegate traffic of un-supported playlist format= . That would motivate the dCDN to support all of them.=C2=A0=C2=A0

Support for multiple optional playlist formats therefore (IMO) works agains= t interoperability. What is the use case for requiring multiple optional pl= aylist formats?
[OF] >> I agree that multiple fo= rmats is not in favor of interoperability, but this is where the video indu= stry currently stands, so we can decide not to standardize it but then we w= ill need to find other solutions for the video use cases. ABR protocol awar= eness is something video CDNs have to do anyway. Features like trans-packag= ing at the edge are already being discussed and developed, and for trans-pa= ckaging the dCDN cache has to be manifest type aware.=C2=A0
So, b= asically we could treat it as just a list of files, but I am not sure it is= in favor of the whole solution.

What is the envisioned model if a dCDN does not support playlists in trigge= r requests? Is the uCDN expected to fallback to producing a trigger request= with the URLs from the playlist enumerated as *.urls/*.patterns?
[OF] >> I think the dCDN should return an error for unsup= ported format and the uCDN should not delegate that service to the dCDN.=C2= =A0
=C2=A0

Thanks
Ben




--
Ori Finkelman
Qwilt | Work: <= a href=3D"tel:+972%2072-222-1647" value=3D"+972722221647" target=3D"_blank"= >+972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com




--
Ori Finkelman
Qwilt | Work: +972-72-2221647 | Mobile: +972-52-38321= 89 | o= rif@qwilt.com
--94eb2c0d9e188ebdb20564865584-- From nobody Tue Feb 6 03:41:24 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 7A96F1241FC for ; Tue, 6 Feb 2018 03:41:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 (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 SsNUmtjWtu0Z for ; Tue, 6 Feb 2018 03:41:21 -0800 (PST) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (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 97CFA1241F5 for ; Tue, 6 Feb 2018 03:41:20 -0800 (PST) Received: by mail-wr0-x229.google.com with SMTP id 41so1556108wrc.9 for ; Tue, 06 Feb 2018 03:41:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qwilt-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TbXwxhu/fGgsK66i9jVjO36NELZxwmdtRlJXgN+EjxA=; b=pCkBFfYBbtRTJfGMm54ooYucFITEIVQw/EN6U6au0MrvbZSLiMgWcaDObOcXiKAxui 1wsVUga3F++brgdGYw9qKw0fDpWBbS8jCITXq91yddxGFGZCoqvV9aPTmfwV3cdeowr0 vWDDGIemti8sNVybD8cs+RQDwQXZDJbLVseQ2ZALJRtZXbiJdIgQwQvbmNIUXBQedeTp lLhKh3ZbjOnRtW/Gnij4p+BMHWrsvNW2Dc9wCMy2F/jnqMCmgykBhNxK90TbH/5THhKg MHkLmpkajUErCHJOZZ0QW5m3Rxd5hutxbKcJvYxadbcxiS4wuTBtZMUkzYVubRNP+ooc ZUjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TbXwxhu/fGgsK66i9jVjO36NELZxwmdtRlJXgN+EjxA=; b=FDNaNcDepJ2Ueeygg4fkMaD0s3iSI+0gTRKQQMIToPnlbzCWQ4oWGYCEZSZCaum+iZ mR4lt5UaYu+izUw5R9eOvQQKNy6XHXr48AKhI5zNf7pFY1BFjzXWM0c45y7SCAmsTQVW 9DEGed2SW8L55EzgG+rQjv5rOtqGO9N83v5b2A/X4sNN6ak/aHb+k3+1CVeavHS6QiIT LAAdXVqXmzcTBlSPRABQweLjXk68kMhcUZXr9fBaMZvNDi6828gw0UA9Rr0zjjKyRBU3 tjhdbUymOrUey2PlSIB+/AJTNQB+qN0ibF105F3q1YNObOu6PDxkTQb+UTRSqzYGa+A6 uhLQ== X-Gm-Message-State: APf1xPAWiY0yAqXaYSGIfmxq1oBRD3mEck84ItS8LMvNNptJ1+Gtd+Gd 4o8Wpyle0O83biWiZICdxWewjMY5+m2tAm9tbgcrUA== X-Google-Smtp-Source: AH8x227MQ/VT6oQ3nDww4xMZXk0GemW4CQVBqD7qkS5jqTUuaMaZLrjGGV99Fzrwc+UQGAaEa5GQW4CbUYa/lVGvQGg= X-Received: by 10.223.209.3 with SMTP id a3mr1870190wri.27.1517917278951; Tue, 06 Feb 2018 03:41:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.127.71 with HTTP; Tue, 6 Feb 2018 03:40:48 -0800 (PST) In-Reply-To: References: <150937917932.7823.7624674920223255542.idtracker@ietfa.amsl.com> From: Ori Finkelman Date: Tue, 6 Feb 2018 13:40:48 +0200 Message-ID: To: Kevin Ma Cc: Ben Niven-Jenkins , "" Content-Type: multipart/alternative; boundary="f4f5e809f5e035f88c056489a810" Archived-At: Subject: Re: [CDNi] Triggers playlist: draft-finkelman-cdni-sva-extensions-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.22 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 Feb 2018 11:41:23 -0000 --f4f5e809f5e035f88c056489a810 Content-Type: text/plain; charset="UTF-8" And, if we use the explicit option, is the type mandatory, or the implementation may choose to omit it and rely on the dCDN to be able to auto-detect it by file extension or format ? On Tue, Feb 6, 2018 at 9:42 AM, Ori Finkelman wrote: > Kevin, Ben, Colleagues, > > I am working on the playlist specifications and would like to get your > views on the question of playlist types. > > Should it be implicit from the playlist file extension (or even from the > file format) for example *.m3u8 is HLS, *.ismc is MSS, *.mpd is DASH. > or, the palylist object should explicitly state that type of playlist, for > example: > { > "playlist": "https://www.example.com/a/b/c/1/index.m3u8", > "type": hls > } > > I think that the explicit option is preferable due to the following > + it allows to register more types > + it allows for private implementations to have their own private types. > + it allows the dCDN to advertise which types it supports via the FCI (I > am working on extending it to support trigger objects). > > Thanks, > Ori > > > > > On Thu, Nov 30, 2017 at 7:35 AM, Kevin Ma > wrote: > >> (as an individual) >> >> > [OF] >> I think the dCDN should return an error for unsupported format >> and the uCDN should not delegate that service to the dCDN >> >> Ideally, the uCDN would not attempt to send a playlist URL if the dCDN >> has not advertised the playlist URL trigger capability. >> >> > Is the uCDN expected to fallback to producing a trigger request with >> the URLs from the playlist enumerated as *.urls/*.patterns? >> >> I would expect so. I think of the playlist URL more as an optional >> optimization. Without this optimization, the uCDN would be using >> individual urls/patterns anyway -- though for prepositioning, patterns are >> trickier and the playlist becomes arguably more useful. >> >> >> On Wed, Nov 29, 2017 at 11:57 AM, Ori Finkelman wrote: >> >>> Hi Ben, >>> Please see some comments and answers below >>> >>> On Tue, Nov 28, 2017 at 2:28 PM, Ben Niven-Jenkins < >>> ben@niven-jenkins.co.uk> wrote: >>> >>>> Ori, Colleagues, >>>> >>>> I just read draft-finkelman-cdni-sva-extensions-00 and have some >>>> comments I will send in separate emails to keep each conversation to a >>>> single topic. >>>> >>>> >>>> > On 16 Nov 2017, at 12:27, Kevin Ma wrote: >>>> > >>>> > For Triggers playlist, a long time ago we decided to not deal with >>>> HTTP adaptive streaming to simplify the initial scope, but I think video >>>> and HAS awareness is probably necessary and worthwhile for us to >>>> re-address. I think I like content.playlists better than playlist.urls, >>>> but that's a detail. >>>> >>>> Support for multiple optional playlist formats places a burden on the >>>> dCDN to support the multiple playlist formats. Multiple optional playlist >>>> formats places a burden on the uCDN, e.g. it needs to be able to handle a >>>> dCDN that does not support a particular playlist e.g. by transforming the >>>> playlist to a dCDN supported format or by falling back to a list of URLs >>>> carried in the triggers request. >>>> >>> [OF] >> Another option would be for the uCDN NOT to delegate traffic of >>> un-supported playlist format. That would motivate the dCDN to support all >>> of them. >>> >>>> >>>> Support for multiple optional playlist formats therefore (IMO) works >>>> against interoperability. What is the use case for requiring multiple >>>> optional playlist formats? >>>> >>> [OF] >> I agree that multiple formats is not in favor of >>> interoperability, but this is where the video industry currently stands, so >>> we can decide not to standardize it but then we will need to find other >>> solutions for the video use cases. ABR protocol awareness is something >>> video CDNs have to do anyway. Features like trans-packaging at the edge are >>> already being discussed and developed, and for trans-packaging the dCDN >>> cache has to be manifest type aware. >>> So, basically we could treat it as just a list of files, but I am not >>> sure it is in favor of the whole solution. >>> >>>> >>>> What is the envisioned model if a dCDN does not support playlists in >>>> trigger requests? Is the uCDN expected to fallback to producing a trigger >>>> request with the URLs from the playlist enumerated as *.urls/*.patterns? >>>> >>> [OF] >> I think the dCDN should return an error for unsupported format >>> and the uCDN should not delegate that service to the dCDN. >>> >>> >>>> >>>> Thanks >>>> Ben >>>> >>>> >>>> >>> >>> >>> -- >>> >>> *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 <072-222-1647> | Mobile: > +972-52-3832189 <052-383-2189> | orif@qwilt.com > -- *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com --f4f5e809f5e035f88c056489a810 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
And, if we use the explicit option, is the type mandatory,= or the implementation may choose to omit it and rely on the dCDN to be abl= e to auto-detect it by file extension or format ?

On Tue, Feb 6, 2018 at 9:42 AM, Ori F= inkelman <orif@qwilt.com> wrote:
Kevin, Ben,=C2=A0 Colleagues,

I am= working on the playlist specifications and would like to get your views on= the question of playlist types.

Should it be impl= icit from the playlist file extension (or even from the file format) for ex= ample *.m3u8 is HLS, *.ismc is MSS, *.mpd is DASH.=C2=A0
or, = the palylist object should explicitly state that type of playlist, for exam= ple:
=C2=A0 =C2=A0 {=C2=A0
=C2=A0 =C2=A0 =C2=A0 = =C2=A0"playlist": "https://www.example.com/a/b/c/1/index.= m3u8",=C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0&qu= ot;type": hls
=C2=A0 =C2=A0 }

I think that the explicit option is preferable due to the following
<= div>+ it allows to register more types
+ it allows for private im= plementations to have their own private types.
+ it allows the dC= DN to advertise which types it supports via the FCI (I am working on extend= ing it to support trigger objects).

Thanks,
<= div>Ori




On Thu, Nov 30, 2017 at 7:35 AM, Kevin Ma &l= t;kevin.j.ma= .ietf@gmail.com> wrote:
(as an individual)

> [OF] &= gt;> I think the dCDN should return an error for unsupported format and = the uCDN should not delegate that service to the dCDN

=
Ideally, the uCDN would not attempt to send a playlist URL if the dCDN= has not advertised the playlist URL trigger capability.
> Is the uCDN expected to fallback to producing a trigger r= equest with the URLs from the playlist enumerated as *.urls/*.patterns?

I would expect so.=C2=A0 I think of the playli= st URL more as an optional optimization.=C2=A0 Without this optimization, t= he uCDN would be using individual urls/patterns anyway -- though for prepos= itioning, patterns are trickier and the playlist becomes arguably more usef= ul.


On Wed, Nov 29, 2017 at 11:57 AM, Ori Fi= nkelman <orif@qwilt.com> wrote:
Hi Ben,
Please see some comments= and answers below

On Tue, Nov 28, 2017 at 2:28 PM, Ben Niven-Jenkins <ben@niven= -jenkins.co.uk> wrote:
Ori, Colleagues,

I just read draft-finkelman-cdni-sva-extensions-00 and have some comme= nts I will send in separate emails to keep each conversation to a single to= pic.


> On 16 Nov 2017, at 12:27, Kevin Ma <kevin.j.ma.ietf@gmail.com> wrote: >
>=C2=A0 =C2=A0For Triggers playlist, a long time ago we decided to not d= eal with HTTP adaptive streaming to simplify the initial scope, but I think= video and HAS awareness is probably necessary and worthwhile for us to re-= address.=C2=A0 I think I like content.playlists better than playlist.urls, = but that's a detail.

Support for multiple optional playlist formats places a burden on the dCDN = to support the multiple playlist formats. Multiple optional playlist format= s places a burden on the uCDN, e.g. it needs to be able to handle a dCDN th= at does not support a particular playlist e.g. by transforming the playlist= to a dCDN supported format or by falling back to a list of URLs carried in= the triggers request.
[OF] >> Another option wo= uld be for the uCDN NOT to delegate traffic of un-supported playlist format= . That would motivate the dCDN to support all of them.=C2=A0=C2=A0

Support for multiple optional playlist formats therefore (IMO) works agains= t interoperability. What is the use case for requiring multiple optional pl= aylist formats?
[OF] >> I agree that multiple fo= rmats is not in favor of interoperability, but this is where the video indu= stry currently stands, so we can decide not to standardize it but then we w= ill need to find other solutions for the video use cases. ABR protocol awar= eness is something video CDNs have to do anyway. Features like trans-packag= ing at the edge are already being discussed and developed, and for trans-pa= ckaging the dCDN cache has to be manifest type aware.=C2=A0
So, b= asically we could treat it as just a list of files, but I am not sure it is= in favor of the whole solution.

What is the envisioned model if a dCDN does not support playlists in trigge= r requests? Is the uCDN expected to fallback to producing a trigger request= with the URLs from the playlist enumerated as *.urls/*.patterns?
[OF] >> I think the dCDN should return an error for unsup= ported format and the uCDN should not delegate that service to the dCDN.=C2= =A0
=C2=A0

Thanks
Ben




--
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: +9= 72-52-3832189 | orif@qwilt.com
--f4f5e809f5e035f88c056489a810-- From nobody Tue Feb 6 07:51:16 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 BE05C12D833 for ; Tue, 6 Feb 2018 07:51:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.929 X-Spam-Level: X-Spam-Status: No, score=-14.929 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 fzmtgM7WT5VL for ; Tue, 6 Feb 2018 07:51:07 -0800 (PST) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by ietfa.amsl.com (Postfix) with SMTP id 13E69126D73 for ; Tue, 6 Feb 2018 07:51:07 -0800 (PST) Received: (qmail 28477 invoked by uid 99); 6 Feb 2018 15:51:06 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Feb 2018 15:51:06 +0000 Received: from mail-io0-f169.google.com (mail-io0-f169.google.com [209.85.223.169]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id E871F1A0044 for ; Tue, 6 Feb 2018 15:51:05 +0000 (UTC) Received: by mail-io0-f169.google.com with SMTP id f34so2931221ioi.13 for ; Tue, 06 Feb 2018 07:51:05 -0800 (PST) X-Gm-Message-State: APf1xPCQXZVGbKIllWYOegPLc+V2cXISLwjr2G6nviZhPrxllpvOr9Zu zGhetO+isH9G5Jvk2Jhmv/UUN8rt7MCfReoDYGM= X-Google-Smtp-Source: AH8x226Xo40bkSr56OeBi9CC3sbwWrdjhL9ilTAf75j9j7S3jCFMUkjCifrXx+I+dguGARQlEtk1CgofP7ARroCY8c4= X-Received: by 10.107.22.199 with SMTP id 190mr3804616iow.242.1517932265301; Tue, 06 Feb 2018 07:51:05 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Phil Sorber Date: Tue, 06 Feb 2018 15:50:54 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Ori Finkelman Cc: "" Content-Type: multipart/alternative; boundary="001a1148e120776e9d05648d25e8" Archived-At: Subject: Re: [CDNi] SVA extensions next drafts X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.22 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 Feb 2018 15:51:14 -0000 --001a1148e120776e9d05648d25e8 Content-Type: text/plain; charset="UTF-8" As an individual, I like the idea of the split. As long as the overhead of having that many drafts in the air isn't too much. Keeps all the concerns separate. As a chair, that's a lot more to shepherd but I think that's still fine. It means we can make progress on different drafts instead of it being held up in one giant monolithic draft. Thanks. On Mon, Feb 5, 2018 at 7:41 AM Ori Finkelman wrote: > Also, > I am planning to draft the trigger extensions and the triggers capability > objects as a separate draft for extension of RFC8007. > > Best regards, > Ori > > On Sun, Feb 4, 2018 at 3:42 PM, Ori Finkelman wrote: > >> Hi, >> I am planning to split the current SVA open caching draft >> https://tools.ietf.org/html/draft-finkelman-cdni-sva-extensions-00 into >> separate functions. >> + request routing >> + content management (triggers) >> + URI signing >> + CORS delegation >> + Logging >> each will have its own draft, shorter and easier to review and edit. >> >> Let me know if there are any reservations. >> Best regards, >> Ori >> >> >> -- >> >> *Ori Finkelman*Qwilt | Work: +972-72-2221647 <072-222-1647> | Mobile: >> +972-52-3832189 <052-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 > --001a1148e120776e9d05648d25e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As an individual, I like the idea of the split. As lo= ng as the overhead of having that many drafts in the air isn't too much= . Keeps all the concerns separate.

As a chair,= that's a lot more to shepherd but I think that's still fine. It me= ans we can make progress on different drafts instead of it being held up in= one giant monolithic draft.

Thanks.
=
On Mon, Feb 5, 2018 at 7:41= AM Ori Finkelman <orif@qwilt.com&= gt; wrote:
Also,= =C2=A0
I am planning to draft the trigger extensions and the triggers c= apability objects as a separate draft for extension of RFC8007.
<= br>
Best regards,
Ori

On Sun, Feb 4, 2018 at 3:42 PM, Ori Fin= kelman <orif@qwilt.com> wrote:
Hi,
I am planning to split the current SVA open cach= ing draft=C2=A0https://tools.ietf.org/html/draft-fink= elman-cdni-sva-extensions-00 into separate functions.
+ reque= st routing
+ content management (triggers)
+ URI signin= g=C2=A0
+ CORS delegation
+ Logging
each will= have its own draft, shorter and easier to review and edit.

<= /div>
Let me know if there are any reservations.=C2=A0
Best r= egards,
Ori


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



--
_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni
--001a1148e120776e9d05648d25e8-- From nobody Tue Feb 6 20:06:11 2018 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA086120726 for ; Tue, 6 Feb 2018 20:06:09 -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, MIME_QP_LONG_LINE=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 fyioF7KeasRM for ; Tue, 6 Feb 2018 20:06:07 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (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 58D54120227 for ; Tue, 6 Feb 2018 20:06:07 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id r13so5268744qtm.8 for ; Tue, 06 Feb 2018 20:06:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SI+4elqeaUKPoWbKlSjxUnuvrrklUnj6v0hYZjlTfao=; b=LdES06EVLfdPBfHcglEMfdI+/FuASXbpB6IAB8SNKwvSAsL0HU7rsRY9yUgYgo1XJX Ln/ESJfpM+ErAFm4X9XhHTyZCYIlZqwEkFKKoCnqv7eI0dp8Kj9seCUZU6Q0EUNqUUTs ZYk0wh5WWVcAXlHvI6xAjHrdDDEGQ9x00Y2PG9p/NjuC9Cd5PBi3yZsSnYxsgLgnvYpC R63MaCJLoPA0BKcxmBk/XX9/ii19ToYR00qcugliRMe4J+/le6qEpQ126Qlem3W7bxXF uKS64uGl6pFbv8yPug9OELahhhjkQcxv2J/rsDvvmUHY3t8WNKlRSgc+XxtPt15a5HDA HRgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SI+4elqeaUKPoWbKlSjxUnuvrrklUnj6v0hYZjlTfao=; b=TE7M1jDYsfWqCBfFnlSaFHQmc4V4woxw69pIeM+pDApcdcDisAZiEhNcYs4N0ChdVY zTYS3fsA1Dizp7t+TmYSf4nDiAIGehvw1WAPe/NF63Xy3ko1P0Edc9289VvubzRbpo8i 5sPhV0WFCxCbLzWmbxWx80qz4IGn2jNlRRm6OlV9x3e5ryoQn/dIdVlGLrhjZweHcyyX qGm1JEHflRmWzxYKcbm7fAAyEw7Sz62AF4YA26ZPuYIuSXv/K9on3dF5nzVyAS1AWf3G ifSKNSCDc6GlEPLHn2Yd+kKfe2nulOFpzo38lcu0v41DioIvHp7JM2rPuqOk+M7wW3bQ /Qsw== X-Gm-Message-State: APf1xPDItbmvSusT/XafdEgr93AWGBlK9s0my+A8DCKKzwnjLD9GgGZL d7QNTTOgdKKLA5riHnSEmLg= X-Google-Smtp-Source: AH8x225aPZLa2lZv6URgpGOSBdD65sqin7R+VUFZxF5gxEC23ZOfoMhTV/TyC2DU2TqnYKGmRXGwUQ== X-Received: by 10.200.22.88 with SMTP id x24mr4703572qtk.326.1517976366531; Tue, 06 Feb 2018 20:06:06 -0800 (PST) Received: from [192.168.1.100] (c-24-34-41-146.hsd1.nh.comcast.net. [24.34.41.146]) by smtp.gmail.com with ESMTPSA id s39sm433890qth.67.2018.02.06.20.06.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Feb 2018 20:06:05 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-A997E30A-C02A-478E-9395-7102C1BC411E Mime-Version: 1.0 (1.0) From: "Kevin J. Ma" X-Mailer: iPhone Mail (15C202) In-Reply-To: Date: Tue, 6 Feb 2018 23:06:04 -0500 Cc: Ori Finkelman , "" Content-Transfer-Encoding: 7bit Message-Id: <13CEF6ED-94E0-4319-96FB-7EAEA853D941@gmail.com> References: To: Phil Sorber Archived-At: Subject: Re: [CDNi] SVA extensions next drafts X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.22 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, 07 Feb 2018 04:06:10 -0000 --Apple-Mail-A997E30A-C02A-478E-9395-7102C1BC411E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable +1 Sent from my iPhone > On Feb 6, 2018, at 10:50 AM, Phil Sorber wrote: >=20 > As an individual, I like the idea of the split. As long as the overhead of= having that many drafts in the air isn't too much. Keeps all the concerns s= eparate. >=20 > As a chair, that's a lot more to shepherd but I think that's still fine. I= t means we can make progress on different drafts instead of it being held up= in one giant monolithic draft. >=20 > Thanks. >=20 >> On Mon, Feb 5, 2018 at 7:41 AM Ori Finkelman wrote: >> Also,=20 >> I am planning to draft the trigger extensions and the triggers capability= objects as a separate draft for extension of RFC8007. >>=20 >> Best regards, >> Ori >>=20 >>> On Sun, Feb 4, 2018 at 3:42 PM, Ori Finkelman wrote: >>> Hi, >>> I am planning to split the current SVA open caching draft https://tools.= ietf.org/html/draft-finkelman-cdni-sva-extensions-00 into separate functions= . >>> + request routing >>> + content management (triggers) >>> + URI signing=20 >>> + CORS delegation >>> + Logging >>> each will have its own draft, shorter and easier to review and edit. >>>=20 >>> Let me know if there are any reservations.=20 >>> Best regards, >>> Ori >>>=20 >>>=20 >>> --=20 >>> Ori Finkelman >>> Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com= >>=20 >>=20 >>=20 >> --=20 >> 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 --Apple-Mail-A997E30A-C02A-478E-9395-7102C1BC411E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1

Se= nt from my iPhone

On Feb 6, 2018, at 10:50 AM, Phil Sorber <= ;sorber@apache.org> wrote:
As an individua= l, I like the idea of the split. As long as the overhead of having that many= drafts in the air isn't too much. Keeps all the concerns separate.

As a chair, that's a lot more to shepherd but I think t= hat's still fine. It means we can make progress on different drafts instead o= f it being held up in one giant monolithic draft.

Thanks.

On Mon, = Feb 5, 2018 at 7:41 AM Ori Finkelman <o= rif@qwilt.com> wrote:
Also, 
I am planning to draft the trigger extensions and t= he triggers capability objects as a separate draft for extension of RFC8007.=

Best regards,
Ori

On Sun, Feb 4, 2018 at 3:42 PM,= Ori Finkelman <orif@qwilt.com> wrote:
Hi,
I am planning to split the current SVA open c= aching draft https://tools.ietf.org/html/draft-fin= kelman-cdni-sva-extensions-00 into separate functions.
+ reque= st routing
+ content management (triggers)
+ URI signing=  
+ CORS delegation
+ Logging
each will h= ave its own draft, shorter and easier to review and edit.

Let me know if there are any reservations. 
Best regar= ds,
Ori


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



--
Ori Finkelman
Qwilt | Work: +972-72-2221647 | M= obile: +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
= --Apple-Mail-A997E30A-C02A-478E-9395-7102C1BC411E-- From nobody Tue Feb 6 20:38:56 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 72077124D68 for ; Tue, 6 Feb 2018 20:38:54 -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, MIME_QP_LONG_LINE=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 qypaaQPlkvHO for ; Tue, 6 Feb 2018 20:38:51 -0800 (PST) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 4F132124319 for ; Tue, 6 Feb 2018 20:38:51 -0800 (PST) Received: by mail-qt0-x22c.google.com with SMTP id r13so5332274qtm.8 for ; Tue, 06 Feb 2018 20:38:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bZqsHfT/K8+fI9ua1PXSCFAGimhHgvn4KJL+PawFjmo=; b=nEyC9OHFPSVOCY8M9IsbPDUYxb5CpkcjdIZWqaeX+Jkn19WMdtQ0MlWiITsdUQe/BG rBJqZBkDuvoEL+sdILXkLVAjNfeTWzFkHmDFYLys06H77cJymZgtQPqmD+1Gu2vGSuGM daFUIBBgqQF6/ZKGgroqAEtEsI1gCk26YRin3dZKE3k5DSD0LzFYr37Mjv5A4ixQBn1g nJTN2+AOsMypmkeX8n4TAZAGfpF7B7SDjNB8bMBre9qZ+8gwBn4/FIu2FAvx+Udx2pL3 nLzJ5C6QOvJorimRq5/Ey86MbIdU61NavYa4yfHEnlPWa7SssB5bB/cFuglODBVbQVpi vXDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bZqsHfT/K8+fI9ua1PXSCFAGimhHgvn4KJL+PawFjmo=; b=q2qWIt+x1wednuM4q0OSCyT84qjpbQdiqlL4CkkrhvlIZ/OlqIoTl4+USBd49af7n4 k09Ak5v8sZL/1cyjyaDs8w7qkFQPZk/Pf24EBSgvlpgvEK1K/+qe0eyjkc0VROfy36jZ mUzkFEqY6tj4JheyB8RLjyiT76gn5nfpS/dgNMPgTrrKQ6HggoQPUSYqMR6PuaEKsZVC 9YfAD4VSYjAYkCOtD0J2m90NoH9BCJsQqkuWKW1Sna1n6WhYvATz4ZyIrb8GC2hT0i51 vy+qgPaSstrhAyqOrlVltbryI4+B0jsue4CQqMwOg5GfvMmGP3tRHg3ed162zmj/5WU+ tqXg== X-Gm-Message-State: APf1xPDCryX+NEFk3uDBX+MHjUoLupm0fAXgTtmO9wuNdkuQqlxMuyO7 fl6nyyMjLe2QJKl8Lcvyw/wPfbi7 X-Google-Smtp-Source: AH8x226qw0uLPVpmNvBYVVEaVo8ko9BvbusPQedAlNM516rix0Xz7F+hr/7VD1JtGYa55u8p+x3Gag== X-Received: by 10.237.41.164 with SMTP id o33mr4419279qtd.2.1517978330245; Tue, 06 Feb 2018 20:38:50 -0800 (PST) Received: from [192.168.1.100] (c-24-34-41-146.hsd1.nh.comcast.net. [24.34.41.146]) by smtp.gmail.com with ESMTPSA id g64sm441517qtd.17.2018.02.06.20.38.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Feb 2018 20:38:49 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-68FCF00B-3AE9-4F74-B001-60DFFBD0E13B Mime-Version: 1.0 (1.0) From: "Kevin J. Ma" X-Mailer: iPhone Mail (15C202) In-Reply-To: Date: Tue, 6 Feb 2018 23:38:48 -0500 Cc: Ben Niven-Jenkins , "" Content-Transfer-Encoding: 7bit Message-Id: References: <150937917932.7823.7624674920223255542.idtracker@ietfa.amsl.com> To: Ori Finkelman Archived-At: Subject: Re: [CDNi] Triggers playlist: draft-finkelman-cdni-sva-extensions-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.22 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, 07 Feb 2018 04:38:54 -0000 --Apple-Mail-68FCF00B-3AE9-4F74-B001-60DFFBD0E13B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable (as an individual) I think an explicit type is probably better from an inter= operability standpoint; and if you go with one, I would make it mandatory. T= he question I would ask is: Do we need a registry for types? Or are there e= xisting type specifications that we could reference/use (e.g., IANA media ty= pes would be great if they existed...)? Sent from my iPhone > On Feb 6, 2018, at 6:40 AM, Ori Finkelman wrote: >=20 > And, if we use the explicit option, is the type mandatory, or the implemen= tation may choose to omit it and rely on the dCDN to be able to auto-detect i= t by file extension or format ? >=20 >> On Tue, Feb 6, 2018 at 9:42 AM, Ori Finkelman wrote: >> Kevin, Ben, Colleagues, >>=20 >> I am working on the playlist specifications and would like to get your vi= ews on the question of playlist types. >>=20 >> Should it be implicit from the playlist file extension (or even from the f= ile format) for example *.m3u8 is HLS, *.ismc is MSS, *.mpd is DASH.=20 >> or, the palylist object should explicitly state that type of playlist, fo= r example: >> {=20 >> "playlist": "https://www.example.com/a/b/c/1/index.m3u8", =20 >> "type": hls >> } >>=20 >> I think that the explicit option is preferable due to the following >> + it allows to register more types >> + it allows for private implementations to have their own private types. >> + it allows the dCDN to advertise which types it supports via the FCI (I a= m working on extending it to support trigger objects). >>=20 >> Thanks, >> Ori >>=20 >>=20 >>=20 >>=20 >>> On Thu, Nov 30, 2017 at 7:35 AM, Kevin Ma wr= ote: >>> (as an individual) >>>=20 >>> > [OF] >> I think the dCDN should return an error for unsupported format= and the uCDN should not delegate that service to the dCDN >>>=20 >>> Ideally, the uCDN would not attempt to send a playlist URL if the dCDN h= as not advertised the playlist URL trigger capability. >>>=20 >>> > Is the uCDN expected to fallback to producing a trigger request with t= he URLs from the playlist enumerated as *.urls/*.patterns? >>>=20 >>> I would expect so. I think of the playlist URL more as an optional opti= mization. Without this optimization, the uCDN would be using individual url= s/patterns anyway -- though for prepositioning, patterns are trickier and th= e playlist becomes arguably more useful. >>>=20 >>>=20 >>>> On Wed, Nov 29, 2017 at 11:57 AM, Ori Finkelman wrote:= >>>> Hi Ben, >>>> Please see some comments and answers below >>>>=20 >>>>> On Tue, Nov 28, 2017 at 2:28 PM, Ben Niven-Jenkins wrote: >>>>> Ori, Colleagues, >>>>>=20 >>>>> I just read draft-finkelman-cdni-sva-extensions-00 and have some comme= nts I will send in separate emails to keep each conversation to a single top= ic. >>>>>=20 >>>>>=20 >>>>> > On 16 Nov 2017, at 12:27, Kevin Ma wrote= : >>>>> > >>>>> > For Triggers playlist, a long time ago we decided to not deal with= HTTP adaptive streaming to simplify the initial scope, but I think video an= d HAS awareness is probably necessary and worthwhile for us to re-address. I= think I like content.playlists better than playlist.urls, but that's a deta= il. >>>>>=20 >>>>> Support for multiple optional playlist formats places a burden on the d= CDN to support the multiple playlist formats. Multiple optional playlist for= mats places a burden on the uCDN, e.g. it needs to be able to handle a dCDN t= hat does not support a particular playlist e.g. by transforming the playlist= to a dCDN supported format or by falling back to a list of URLs carried in t= he triggers request. >>>> [OF] >> Another option would be for the uCDN NOT to delegate traffic of= un-supported playlist format. That would motivate the dCDN to support all o= f them. =20 >>>>>=20 >>>>> Support for multiple optional playlist formats therefore (IMO) works a= gainst interoperability. What is the use case for requiring multiple optiona= l playlist formats? >>>> [OF] >> I agree that multiple formats is not in favor of interoperabili= ty, but this is where the video industry currently stands, so we can decide n= ot to standardize it but then we will need to find other solutions for the v= ideo use cases. ABR protocol awareness is something video CDNs have to do an= yway. Features like trans-packaging at the edge are already being discussed a= nd developed, and for trans-packaging the dCDN cache has to be manifest type= aware.=20 >>>> So, basically we could treat it as just a list of files, but I am not s= ure it is in favor of the whole solution. >>>>>=20 >>>>> What is the envisioned model if a dCDN does not support playlists in t= rigger requests? Is the uCDN expected to fallback to producing a trigger req= uest with the URLs from the playlist enumerated as *.urls/*.patterns? >>>> [OF] >> I think the dCDN should return an error for unsupported format a= nd the uCDN should not delegate that service to the dCDN.=20 >>>> =20 >>>>>=20 >>>>> Thanks >>>>> Ben >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> --=20 >>>> Ori Finkelman >>>> Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.co= m >>>=20 >>=20 >>=20 >>=20 >> --=20 >> Ori Finkelman >> Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com >=20 >=20 >=20 > --=20 > Ori Finkelman > Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com --Apple-Mail-68FCF00B-3AE9-4F74-B001-60DFFBD0E13B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable (as an individual) I think an explicit type= is probably better from an interoperability standpoint; and if you go with o= ne, I would make it mandatory.  The question I would ask is: Do we need= a registry for types?  Or are there existing type specifications that w= e could reference/use (e.g., IANA media types would be great if they existed= ...)?

Sent from my iPhone
On Feb 6, 2018, at 6:40 AM, Ori Finkelman <orif@qwilt.com> wrote:

<= div>
And, if we use the explicit option, is the type mandato= ry, or the implementation may choose to omit it and rely on the dCDN to be a= ble to auto-detect it by file extension or format ?

On Tue, Feb 6, 2018 at 9:42 AM, Ori Fi= nkelman <orif@qwilt.com> wrote:
=
Kevin, Ben,  Colleagues,

I am worki= ng on the playlist specifications and would like to get your views on the qu= estion of playlist types.

Should it be implicit fro= m the playlist file extension (or even from the file format) for example *.m= 3u8 is HLS, *.ismc is MSS, *.mpd is DASH. 
or, the palyli= st object should explicitly state that type of playlist, for example:
<= div>
    { 
       "playlis= t": "https://www.example.com/a/b/c/1/index.m3u8",    
       "type": hls
    }

I think that the explicit option is preferable d= ue to the following
+ it allows to register more types
+= it allows for private implementations to have their own private types.
+ it allows the dCDN to advertise which types it supports via the FCI (= I am working on extending it to support trigger objects).

Thanks,
Ori



=
On Thu, Nov 30, 2017 at 7:35 AM, Kevin Ma <kevin.j.ma.ietf@gmail.com> wrote:
(as an individual)

> [OF] >> I think the dCDN should return an error for unsupported f= ormat and the uCDN should not delegate that service to the dCDN

Ideally, the uCDN would not attempt to send a playlist URL if t= he dCDN has not advertised the playlist URL trigger capability.
<= div>
> Is the uCDN expected to fallback to producing a trig= ger request with the URLs from the playlist enumerated as *.urls/*.patterns?=

I would expect so.  I think of the pla= ylist URL more as an optional optimization.  Without this optimization,= the uCDN would be using individual urls/patterns anyway -- though for prepo= sitioning, patterns are trickier and the playlist becomes arguably more usef= ul.


On Wed, Nov 29, 2017 at 11:57 AM, Ori Fink= elman <orif@qwilt.com> wrote:
Hi Ben,
Please see some comments and a= nswers below

= On Tue, Nov 28, 2017 at 2:28 PM, Ben Niven-Jenkins <ben@niven-jenkins.c= o.uk> wrote:
Ori, Colleagues,

I just read draft-finkelman-cdni-sva-extensions-00 and have some commen= ts I will send in separate emails to keep each conversation to a single topi= c.


> On 16 Nov 2017, at 12:27, Kevin Ma <kevin.j.ma.ietf@gmail.com> wrote:
>
>   For Triggers playlist, a long time ago we decided to not de= al with HTTP adaptive streaming to simplify the initial scope, but I think v= ideo and HAS awareness is probably necessary and worthwhile for us to re-add= ress.  I think I like content.playlists better than playlist.urls, but t= hat's a detail.

Support for multiple optional playlist formats places a burden on the dCDN t= o support the multiple playlist formats. Multiple optional playlist formats p= laces a burden on the uCDN, e.g. it needs to be able to handle a dCDN that d= oes not support a particular playlist e.g. by transforming the playlist to a= dCDN supported format or by falling back to a list of URLs carried in the t= riggers request.
[OF] >> Another option would be f= or the uCDN NOT to delegate traffic of un-supported playlist format. That wo= uld motivate the dCDN to support all of them.  

Support for multiple optional playlist formats therefore (IMO) works against= interoperability. What is the use case for requiring multiple optional play= list formats?
[OF] >> I agree that multiple forma= ts is not in favor of interoperability, but this is where the video industry= currently stands, so we can decide not to standardize it but then we will n= eed to find other solutions for the video use cases. ABR protocol awareness i= s something video CDNs have to do anyway. Features like trans-packaging at t= he edge are already being discussed and developed, and for trans-packaging t= he dCDN cache has to be manifest type aware. 
So, basically w= e could treat it as just a list of files, but I am not sure it is in favor o= f the whole solution.
=
What is the envisioned model if a dCDN does not support playlists in trigger= requests? Is the uCDN expected to fallback to producing a trigger request w= ith the URLs from the playlist enumerated as *.urls/*.patterns?
[OF] >> I think the dCDN should return an error for unsupport= ed format and the uCDN should not delegate that service to the dCDN. 
 

Thanks
Ben


=



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




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



--
<= div class=3D"gmail_signature" data-smartmail=3D"gmail_signature">
Ori Finkelman
Qwilt | Work: +972-72-2221647 | Mobile: +972-5= 2-3832189 | orif@qwilt.com
= --Apple-Mail-68FCF00B-3AE9-4F74-B001-60DFFBD0E13B-- From nobody Tue Feb 6 21:03: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 783951243F6 for ; Tue, 6 Feb 2018 21:03:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.93 X-Spam-Level: X-Spam-Status: No, score=-14.93 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 9ulNA09CDOvN for ; Tue, 6 Feb 2018 21:03:05 -0800 (PST) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by ietfa.amsl.com (Postfix) with SMTP id 57D171200E5 for ; Tue, 6 Feb 2018 21:03:05 -0800 (PST) Received: (qmail 20057 invoked by uid 99); 7 Feb 2018 05:03:04 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Feb 2018 05:03:04 +0000 Received: from mail-it0-f54.google.com (mail-it0-f54.google.com [209.85.214.54]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id AF30C1A0044 for ; Wed, 7 Feb 2018 05:03:03 +0000 (UTC) Received: by mail-it0-f54.google.com with SMTP id e1so689666ita.0 for ; Tue, 06 Feb 2018 21:03:02 -0800 (PST) X-Gm-Message-State: APf1xPDCcReO9cPikxL5Veyxx7EUBWaFBHMEecf3RudcV05PZq8CKExg FCL3qGMatNAV0VRVBtT08Srn68vItjCcOcwpUqg= X-Google-Smtp-Source: AH8x225LfYa7CiwLg+UX42YFYyJ0YXuHGmxUP9iv9KTt5X5/T+n8v/7EkjM/2dvfURli5Z2/FceWUwCn+gaCE+3OPDs= X-Received: by 10.36.204.67 with SMTP id x64mr6642414itf.153.1517979781238; Tue, 06 Feb 2018 21:03:01 -0800 (PST) MIME-Version: 1.0 From: Phil Sorber Date: Wed, 07 Feb 2018 05:02:50 +0000 X-Gmail-Original-Message-ID: Message-ID: To: "" Content-Type: multipart/alternative; boundary="94eb2c05ea52a3195505649835d8" Archived-At: Subject: [CDNi] Meeting in London X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.22 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, 07 Feb 2018 05:03:06 -0000 --94eb2c05ea52a3195505649835d8 Content-Type: text/plain; charset="UTF-8" Hey All, I just wanted to confirm that no one thought there was a need to have a session in London. I don't think we have any big outstanding issues that require a face to face meeting to resolve. Thanks. --94eb2c05ea52a3195505649835d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey All,

I just wanted to co= nfirm that no one thought there was a need to have a session in London. I d= on't think we have any big outstanding issues that require a face to fa= ce meeting to resolve.

Thanks.
--94eb2c05ea52a3195505649835d8-- From nobody Wed Feb 7 00:40:13 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 D77B5126CC7 for ; Wed, 7 Feb 2018 00:40:11 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=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 AMNccWK_q5kW for ; Wed, 7 Feb 2018 00:40:10 -0800 (PST) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (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 E51561200C1 for ; Wed, 7 Feb 2018 00:40:09 -0800 (PST) Received: by mail-wr0-x236.google.com with SMTP id f6so72468wra.6 for ; Wed, 07 Feb 2018 00:40:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qwilt-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=qDL/dou6uKL9lj1iehvOYkgZvkMhRnAPLAEvfsfgaa0=; b=1AdP0aUywtYVGvo+ZAVNZlykDs3sRJiVjyDSIpbZ0+rmq1S9FmwucUwdYHDCBKvLjP mQzLmtPu01tswrCOUoq197U4d6vyGDUvUS7V84jbMINAz+3T6H/TYiLG5SmmkJ00twfq qXpqU6hDjXowYP+C0Mq/V/UQvat9BB5Z4ZlemTX3SKFMGvk7pjSKfVL29Ef5gbMZi+2S X+lVSaHVw0TCFZFG3kXzX5Zj4giSlC6s8gZkvvqpOicDNE7mJ159G/DlqMoFbGOsx0oQ HBfmumFlznglEYjaoslgZodn4PEutk9y3yR2NFNEy3HSRMsjpVnkRT2NYymeWyiRfbca 2zKw== 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=qDL/dou6uKL9lj1iehvOYkgZvkMhRnAPLAEvfsfgaa0=; b=By001MLZxRQfIU2k+sEXNRZcYRDE5sBNJcypE/8I1Fwu2cCyIVcJ5KL7Ke/eciPhBG 3P7dl3Y08tkvevczctV7X2qXLxxheyW+JAqkmBMVD4hbuy6j8jSyO35PIVuEsHAP2tzx 8631rDK617yACweZ0Em/Ei7ku408l/VzqqAYAbSCcCU6L0ZuWwQDTIScDwpH/jantWYZ EtjSjtIwIQzyk7cK/Fgaav2oh1iN1XcezDQU8m769otPOEQ5GGtIE/CrFn6oJq2KWkqj ZmtuO9NWlhhSMW/Cb03P7Vk4gmHqGP13gkr1P2loKAV0Sv2vDRjSG9oKrzf8mc4Gk8Yo rf5g== X-Gm-Message-State: APf1xPAm2n0FYskWd8vtaFs9/qXbmGnMvexqzEWSoLQVBIN8sfe85mzF MdT//Q1kLG76Odrt+LVdFJ8RsVX6WL+JD4ALKB8i1iM0ync= X-Google-Smtp-Source: AH8x227qqNP8nrvSChJNP69/bo0UtgIUuqw+YZNsYIboAbTcSajxNeTyYqs6sY0Zsqah07InXflbRm2xUWXt0qDC7F4= X-Received: by 10.223.209.3 with SMTP id a3mr4635571wri.27.1517992808184; Wed, 07 Feb 2018 00:40:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.127.71 with HTTP; Wed, 7 Feb 2018 00:39:37 -0800 (PST) From: Ori Finkelman Date: Wed, 7 Feb 2018 10:39:37 +0200 Message-ID: To: "" Content-Type: multipart/alternative; boundary="f4f5e809f5e01a945505649b3e1d" Archived-At: Subject: [CDNi] Triggers regexp: draft-finkelman-cdni-sva-extensions-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.22 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, 07 Feb 2018 08:40:12 -0000 --f4f5e809f5e01a945505649b3e1d Content-Type: text/plain; charset="UTF-8" Dear Colleagues, Regarding the addition of a regular expression match for triggers, mainly for invalidation. What should be the regexp standard we use, PCRE ? POSIX BRE or ERE ? Does the type of regrexp need to be exchanged via the interface (trigger and capability) ? Example 1: assuming we support only one specific type of regrex { "regex": "/^(https:\/\/video\.example\.com)\/([a-z])\/([1-7])\/([\/\w \.-]*)*\/?$", "case-sensitive": true } Example 2: assuming regexp type is variable { "regex": "/^(https:\/\/video\.example\.com)\/([a-z])\/([1-7])\/([\/\w \.-]*)*\/?$", "case-sensitive": true "regrex-type": "pcre" } Thanks, Ori -- *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com --f4f5e809f5e01a945505649b3e1d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Colleagues,
Regarding the addition of a regular e= xpression match for triggers, mainly for invalidation.
What shoul= d be the regexp standard we use,=C2=A0PCRE ? POSIX BRE or ERE ?
D= oes the type of regrexp need to be exchanged via the interface (trigger and= capability) ?

Example 1: assuming we support only= one specific type of regrex

=C2=A0 =C2=A0 {= =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0"regex": "/^(htt= ps:\/\/video\.example\.com)\/([a-z])\/([1-7])\/([\/\w \.-]*)*\/?$",=C2= =A0 =C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0"case-sensitive&= quot;: true
=C2=A0 =C2=A0 }

Exampl= e 2: assuming regexp type is variable

=C2=A0 = =C2=A0 {=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0"regex": &quo= t;/^(https:\/\/video\.example\.com)\/([a-z])\/([1-7])\/([\/\w \.-]*)*\/?$&q= uot;,=C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0"case-se= nsitive": true
=C2=A0 =C2=A0 =C2=A0 =C2=A0"regrex-type&= quot;: "pcre"
=C2=A0 =C2=A0 }

Thanks,
Ori


--
Ori Finkel= man
Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.c= om
--f4f5e809f5e01a945505649b3e1d-- From nobody Wed Feb 7 03:57:54 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 AB032129516 for ; Wed, 7 Feb 2018 03:57:52 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=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 eFfDtK_mAVz7 for ; Wed, 7 Feb 2018 03:57:49 -0800 (PST) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (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 5D3A0124235 for ; Wed, 7 Feb 2018 03:57:49 -0800 (PST) Received: by mail-wr0-x22d.google.com with SMTP id a43so721430wrc.4 for ; Wed, 07 Feb 2018 03:57:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qwilt-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+3PS34FuoLXkzdULWOgiwXXfAlX0yapheo6L3Fxy2Is=; b=iUfooGACHIsSROqSlhp87aHc+qkGSHZglja5Ho3xJbFWf2SQpCkK5ID8/sJqB5lMXB XML4jmF1JkNfPzv/1uTjzLIoqYAopDWbgNbT40Z0AwyYqcTfTRB0w2H4s5y43ZbFN0ga EqR7CPgJiyUbcqAEUA8Fin2+wbR7uT3zZYa/HXcF3mwC3u6EjdywdQQD8JcFYh4gGDtF rVhRzzJSs0R8hz4wgUuR87/Z4HtoWLROHiZdz+0dWH/OsqvOBgTP3z+B6TRAQKcavPjo b/wXFT5CtD/nTY9yUfm/pPDoXLnEi+VedIm0ZoXlBY9MDl7umT7VnOU4dQc4pi6mbS2L vySw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+3PS34FuoLXkzdULWOgiwXXfAlX0yapheo6L3Fxy2Is=; b=YmXFaJCkv3cVxwS7XcEqU97EgyOXHu//H192iTUUdk1DsNmtLqluUqMDs3JYIeBIWW HMPNp+beB8WuGpY8x0dyPh0Y3XQ75y0ppY+4YO9UyFQagk7Os8ecPlBxR6cJhWiBNnGN 7oachbusVICIOGk4uFkkAxv+QfDn9w/d1mynUgKnHaFSboSeeX6H+xTr9qwYkLLDjy98 aLa8WPs2NGHfintag3wov9Nrf0gMJjTM3tBHzXCHUBwrqs0azRlq5La2Sb9H4vIpOPek Xs1NbTizZKHerHwifuJ80DgC47tC7vmKY8bbT7EL9efJ4FJ+Z2PUV3T369od6Ip45jln qg9w== X-Gm-Message-State: APf1xPA/LTzcO2CypnCsDgoN1JeDotlA+bL0OlW0j5p9yE70l5M4Ishx Wpv9uUBAySxj1z4TL9RwldYYMEaApwJ27MgcHDERUg== X-Google-Smtp-Source: AH8x224SGtp5OilKUSPKke6/PTXuaTxAjgM+Wz1Ml1lyYXXf6qJ2lf7aPQmRdHSwqS+bz1a8I0AcCPnUjMQzHASRRUE= X-Received: by 10.223.184.125 with SMTP id u58mr5950337wrf.138.1518004667743; Wed, 07 Feb 2018 03:57:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.127.71 with HTTP; Wed, 7 Feb 2018 03:57:16 -0800 (PST) In-Reply-To: References: <150937917932.7823.7624674920223255542.idtracker@ietfa.amsl.com> From: Ori Finkelman Date: Wed, 7 Feb 2018 13:57:16 +0200 Message-ID: To: "Kevin J. Ma" Cc: Ben Niven-Jenkins , "" Content-Type: multipart/alternative; boundary="f403045f5488fd131405649e0071" Archived-At: Subject: Re: [CDNi] Triggers playlist: draft-finkelman-cdni-sva-extensions-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.22 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, 07 Feb 2018 11:57:53 -0000 --f403045f5488fd131405649e0071 Content-Type: text/plain; charset="UTF-8" There is the CDNI protocol registry in https://tools.ietf.org/html/rfc8006#section-7.3 but since these are used for a different purpose it seems to me they should have a separate registry. I am not sure about IANA media types as these are used for that specific purpose, to serve as media types in HTTP responses, which are not what we need. I am starting with a new registry within the draft, if we find something better I will switch to it. Thanks, Ori On Wed, Feb 7, 2018 at 6:38 AM, Kevin J. Ma wrote: > (as an individual) I think an explicit type is probably better from an > interoperability standpoint; and if you go with one, I would make it > mandatory. The question I would ask is: Do we need a registry for types? > Or are there existing type specifications that we could reference/use > (e.g., IANA media types would be great if they existed...)? > > Sent from my iPhone > > On Feb 6, 2018, at 6:40 AM, Ori Finkelman wrote: > > And, if we use the explicit option, is the type mandatory, or the > implementation may choose to omit it and rely on the dCDN to be able to > auto-detect it by file extension or format ? > > On Tue, Feb 6, 2018 at 9:42 AM, Ori Finkelman wrote: > >> Kevin, Ben, Colleagues, >> >> I am working on the playlist specifications and would like to get your >> views on the question of playlist types. >> >> Should it be implicit from the playlist file extension (or even from the >> file format) for example *.m3u8 is HLS, *.ismc is MSS, *.mpd is DASH. >> or, the palylist object should explicitly state that type of playlist, >> for example: >> { >> "playlist": "https://www.example.com/a/b/c/1/index.m3u8", >> "type": hls >> } >> >> I think that the explicit option is preferable due to the following >> + it allows to register more types >> + it allows for private implementations to have their own private types. >> + it allows the dCDN to advertise which types it supports via the FCI (I >> am working on extending it to support trigger objects). >> >> Thanks, >> Ori >> >> >> >> >> On Thu, Nov 30, 2017 at 7:35 AM, Kevin Ma >> wrote: >> >>> (as an individual) >>> >>> > [OF] >> I think the dCDN should return an error for unsupported format >>> and the uCDN should not delegate that service to the dCDN >>> >>> Ideally, the uCDN would not attempt to send a playlist URL if the dCDN >>> has not advertised the playlist URL trigger capability. >>> >>> > Is the uCDN expected to fallback to producing a trigger request with >>> the URLs from the playlist enumerated as *.urls/*.patterns? >>> >>> I would expect so. I think of the playlist URL more as an optional >>> optimization. Without this optimization, the uCDN would be using >>> individual urls/patterns anyway -- though for prepositioning, patterns are >>> trickier and the playlist becomes arguably more useful. >>> >>> >>> On Wed, Nov 29, 2017 at 11:57 AM, Ori Finkelman wrote: >>> >>>> Hi Ben, >>>> Please see some comments and answers below >>>> >>>> On Tue, Nov 28, 2017 at 2:28 PM, Ben Niven-Jenkins < >>>> ben@niven-jenkins.co.uk> wrote: >>>> >>>>> Ori, Colleagues, >>>>> >>>>> I just read draft-finkelman-cdni-sva-extensions-00 and have some >>>>> comments I will send in separate emails to keep each conversation to a >>>>> single topic. >>>>> >>>>> >>>>> > On 16 Nov 2017, at 12:27, Kevin Ma >>>>> wrote: >>>>> > >>>>> > For Triggers playlist, a long time ago we decided to not deal with >>>>> HTTP adaptive streaming to simplify the initial scope, but I think video >>>>> and HAS awareness is probably necessary and worthwhile for us to >>>>> re-address. I think I like content.playlists better than playlist.urls, >>>>> but that's a detail. >>>>> >>>>> Support for multiple optional playlist formats places a burden on the >>>>> dCDN to support the multiple playlist formats. Multiple optional playlist >>>>> formats places a burden on the uCDN, e.g. it needs to be able to handle a >>>>> dCDN that does not support a particular playlist e.g. by transforming the >>>>> playlist to a dCDN supported format or by falling back to a list of URLs >>>>> carried in the triggers request. >>>>> >>>> [OF] >> Another option would be for the uCDN NOT to delegate traffic of >>>> un-supported playlist format. That would motivate the dCDN to support all >>>> of them. >>>> >>>>> >>>>> Support for multiple optional playlist formats therefore (IMO) works >>>>> against interoperability. What is the use case for requiring multiple >>>>> optional playlist formats? >>>>> >>>> [OF] >> I agree that multiple formats is not in favor of >>>> interoperability, but this is where the video industry currently stands, so >>>> we can decide not to standardize it but then we will need to find other >>>> solutions for the video use cases. ABR protocol awareness is something >>>> video CDNs have to do anyway. Features like trans-packaging at the edge are >>>> already being discussed and developed, and for trans-packaging the dCDN >>>> cache has to be manifest type aware. >>>> So, basically we could treat it as just a list of files, but I am not >>>> sure it is in favor of the whole solution. >>>> >>>>> >>>>> What is the envisioned model if a dCDN does not support playlists in >>>>> trigger requests? Is the uCDN expected to fallback to producing a trigger >>>>> request with the URLs from the playlist enumerated as *.urls/*.patterns? >>>>> >>>> [OF] >> I think the dCDN should return an error for unsupported format >>>> and the uCDN should not delegate that service to the dCDN. >>>> >>>> >>>>> >>>>> Thanks >>>>> Ben >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> *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 <072-222-1647> | Mobile: >> +972-52-3832189 <052-383-2189> | orif@qwilt.com >> > > > > -- > > *Ori Finkelman*Qwilt | Work: +972-72-2221647 <072-222-1647> | Mobile: > +972-52-3832189 <052-383-2189> | orif@qwilt.com > > -- *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com --f403045f5488fd131405649e0071 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There is the CDNI protocol registry in=C2=A0https://tools.ietf.org/html/r= fc8006#section-7.3 but since these are used for a different purpose it = seems to me they should have a separate registry.
I am not sure about I= ANA media types as these are used for that specific purpose, to serve as me= dia types in HTTP responses, which are not what we need.

I am starting with a new registry within the draft, if we find somet= hing better I will switch to it.

Thanks,
Ori



On Wed, Feb 7, 2018 at 6:38 AM, Kevin J. M= a <kevin.j.ma.ietf@gmail.com> wrote:
(as an individual) I think an explicit= type is probably better from an interoperability standpoint; and if you go= with one, I would make it mandatory.=C2=A0 The question I would ask is: Do= we need a registry for types?=C2=A0 Or are there existing type specificati= ons that we could reference/use (e.g., IANA media types would be great if t= hey existed...)?

Sent from my iPhone

On Feb 6, 2018, a= t 6:40 AM, Ori Finkelman <orif@qwilt.com> wrote:

=
And, if we use the explicit option, is the type manda= tory, or the implementation may choose to omit it and rely on the dCDN to b= e able to auto-detect it by file extension or format ?

On Tue, Feb 6, 2018 at 9:42 AM, = Ori Finkelman <orif@qwilt.com> wrote:
Kevin, Ben,=C2=A0 Colleagues,

I am= working on the playlist specifications and would like to get your views on= the question of playlist types.

Should it be impl= icit from the playlist file extension (or even from the file format) for ex= ample *.m3u8 is HLS, *.ismc is MSS, *.mpd is DASH.=C2=A0
or, = the palylist object should explicitly state that type of playlist, for exam= ple:
=C2=A0 =C2=A0 {=C2=A0
=C2=A0 =C2=A0 =C2=A0 = =C2=A0"playlist": "https://www.example.com/a/b/c/1/index.= m3u8",=C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0&qu= ot;type": hls
=C2=A0 =C2=A0 }

I think that the explicit option is preferable due to the following
<= div>+ it allows to register more types
+ it allows for private im= plementations to have their own private types.
+ it allows the dC= DN to advertise which types it supports via the FCI (I am working on extend= ing it to support trigger objects).

Thanks,
<= div>Ori




On Thu, Nov 30, 2017= at 7:35 AM, Kevin Ma <kevin.j.ma.ietf@gmail.com> wr= ote:
(as an individ= ual)

> [OF] >> I think the dCDN should r= eturn an error for unsupported format and the uCDN should not delegate that= service to the dCDN

Ideally, the uCDN would not = attempt to send a playlist URL if the dCDN has not advertised the playlist = URL trigger capability.

> Is the uCDN exp= ected to fallback to producing a trigger request with the URLs from the pla= ylist enumerated as *.urls/*.patterns?

I wo= uld expect so.=C2=A0 I think of the playlist URL more as an optional optimi= zation.=C2=A0 Without this optimization, the uCDN would be using individual= urls/patterns anyway -- though for prepositioning, patterns are trickier a= nd the playlist becomes arguably more useful.


On Wed, Nov 29, 2017 at 11:57 AM, Ori Finkelman <orif@= qwilt.com> wrote:
Hi Ben,
Please see some comments and answer= s below

On T= ue, Nov 28, 2017 at 2:28 PM, Ben Niven-Jenkins <ben@niven-jenkins.co= .uk> wrote:
Ori, Colleagues,

I just read draft-finkelman-cdni-sva-extensions-00 and have some comme= nts I will send in separate emails to keep each conversation to a single to= pic.


> On 16 Nov 2017, at 12:27, Kevin Ma <kevin.j.ma.ietf@gmail.com> wrote: >
>=C2=A0 =C2=A0For Triggers playlist, a long time ago we decided to not d= eal with HTTP adaptive streaming to simplify the initial scope, but I think= video and HAS awareness is probably necessary and worthwhile for us to re-= address.=C2=A0 I think I like content.playlists better than playlist.urls, = but that's a detail.

Support for multiple optional playlist formats places a burden on the dCDN = to support the multiple playlist formats. Multiple optional playlist format= s places a burden on the uCDN, e.g. it needs to be able to handle a dCDN th= at does not support a particular playlist e.g. by transforming the playlist= to a dCDN supported format or by falling back to a list of URLs carried in= the triggers request.
[OF] >> Another option wo= uld be for the uCDN NOT to delegate traffic of un-supported playlist format= . That would motivate the dCDN to support all of them.=C2=A0=C2=A0

Support for multiple optional playlist formats therefore (IMO) works agains= t interoperability. What is the use case for requiring multiple optional pl= aylist formats?
[OF] >> I agree that multiple fo= rmats is not in favor of interoperability, but this is where the video indu= stry currently stands, so we can decide not to standardize it but then we w= ill need to find other solutions for the video use cases. ABR protocol awar= eness is something video CDNs have to do anyway. Features like trans-packag= ing at the edge are already being discussed and developed, and for trans-pa= ckaging the dCDN cache has to be manifest type aware.=C2=A0
So, b= asically we could treat it as just a list of files, but I am not sure it is= in favor of the whole solution.

What is the envisioned model if a dCDN does not support playlists in trigge= r requests? Is the uCDN expected to fallback to producing a trigger request= with the URLs from the playlist enumerated as *.urls/*.patterns?
[OF] >> I think the dCDN should return an error for unsup= ported format and the uCDN should not delegate that service to the dCDN.=C2= =A0
=C2=A0

Thanks
Ben





--
Ori Finkelman
Qwil= t | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.co= m




--
Ori Finkelman
Qwilt | Wo= rk: = +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



--
Ori Finkelman
Qwilt | Work: +972= -72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com
--f403045f5488fd131405649e0071-- From nobody Wed Feb 7 07:01: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 BE378126BF3 for ; Wed, 7 Feb 2018 07:01:49 -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, MIME_QP_LONG_LINE=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 9F-OoEHaa5Dl for ; Wed, 7 Feb 2018 07:01:46 -0800 (PST) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (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 7ECEE120454 for ; Wed, 7 Feb 2018 07:01:46 -0800 (PST) Received: by mail-qt0-x234.google.com with SMTP id d8so2013251qtm.0 for ; Wed, 07 Feb 2018 07:01:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DpYaNKq3KrB14fPi46Hm9OnwrjTF6Ym5r7qGoFkcyCo=; b=mk5o5z1jEBeLZ6dCxBuS2kn7s3vH8Rh1Dq85nB9KaVqMv0nMVn/jL8Lb/n3VuhRKr9 0DvJTtpr8inRwLrWV1Km9OpzT1LmsehKutQ3HTpJFwVacahbhi+TdJnIj0uidw1R0tWh OIDDXdjXjkHB8ViLXmegY8W7snG+lbO7pGKwBySRn56MZPOYWslqte0Ur3qhwBtwt7Tv Lo6sm6aFDqVaMlLY4PBPNky4YBLoy0ctJfwrX5NlSxipWyEVRecPEIkai69BmYNmRzSH HVxb+KCrQ431j+1sLU2r8FEfxrvo6vw24S2coDstQeAgBX47oidnKG+032PyRJAS8nc9 j/uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DpYaNKq3KrB14fPi46Hm9OnwrjTF6Ym5r7qGoFkcyCo=; b=h0lO/f2X/OXbtsINVcY+fp9LG4PXuXQmYWr3NcbAQWa7BIk5fv0hZG1QuLdwAXud0Q JjscIxAI16Y8g/naOXE9iTeny6rcxk3NUUBY4cXXGT5L8NvESJRNNQkGDAG3q/ZDzaVH QBMFU8sB/pBehFf93p+viNQuv0sgbNKMWv8X+y4YioVJhPQl/GAlm+2T+inaLpWKI2T7 LEYcK6SYPd9DIeFPgrwy2Pmz8hdlYrUfq/qX+TK30lV0k3XT7EGIGnOhmdt871PpPrAH Jt/0/eiJ5apFlPm4ZAiK2P5Ug6BYAQ2q7AUkaoV86tEAcaqz8Y+BAs/Gi3ts3N3ab4tx hkrQ== X-Gm-Message-State: APf1xPBe+39UacapM1Ts65cSVZuAc5WnTHhc9RRHoIpaEk03TlK97P0W jLU5UjgHW7D/yBLekSOsWy7O6A47 X-Google-Smtp-Source: AH8x2272QGHu+dXBSSkxsKjnl8vidO0IesoWosPr/ewwYnWgcp9ScKz4qhelNhypOF5E019g6Fl43A== X-Received: by 10.200.81.83 with SMTP id h19mr9320501qtn.63.1518015705378; Wed, 07 Feb 2018 07:01:45 -0800 (PST) Received: from [172.20.20.20] ([73.61.19.35]) by smtp.gmail.com with ESMTPSA id v14sm1210806qtc.56.2018.02.07.07.01.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Feb 2018 07:01:44 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-9FAC7C82-6DA0-46AD-B5CF-BFED49B28738 Mime-Version: 1.0 (1.0) From: "Kevin J. Ma" X-Mailer: iPhone Mail (15C202) In-Reply-To: Date: Wed, 7 Feb 2018 10:01:43 -0500 Cc: "" Content-Transfer-Encoding: 7bit Message-Id: References: To: Ori Finkelman Archived-At: Subject: Re: [CDNi] Triggers regexp: draft-finkelman-cdni-sva-extensions-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.22 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, 07 Feb 2018 15:01:50 -0000 --Apple-Mail-9FAC7C82-6DA0-46AD-B5CF-BFED49B28738 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I would favor triggers matching uri signing, i.e., PCRE only, to simplify in= teroperability requirements; unless there's a really good reason implementer= s should have to support multiple standards? Sent from my iPhone > On Feb 7, 2018, at 3:39 AM, Ori Finkelman wrote: >=20 > Dear Colleagues, > Regarding the addition of a regular expression match for triggers, mainly f= or invalidation. > What should be the regexp standard we use, PCRE ? POSIX BRE or ERE ? > Does the type of regrexp need to be exchanged via the interface (trigger a= nd capability) ? >=20 > Example 1: assuming we support only one specific type of regrex >=20 > {=20 > "regex": "/^(https:\/\/video\.example\.com)\/([a-z])\/([1-7])\/([\/= \w \.-]*)*\/?$", =20 > "case-sensitive": true > } >=20 > Example 2: assuming regexp type is variable >=20 > {=20 > "regex": "/^(https:\/\/video\.example\.com)\/([a-z])\/([1-7])\/([\/= \w \.-]*)*\/?$", =20 > "case-sensitive": true > "regrex-type": "pcre" > } >=20 > Thanks, > Ori >=20 >=20 >=20 > --=20 > 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 --Apple-Mail-9FAC7C82-6DA0-46AD-B5CF-BFED49B28738 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I would favor triggers matching uri signing= , i.e., PCRE only, to simplify interoperability requirements; unless there's= a really good reason implementers should have to support multiple standards= ?

Sent from my iPhone

On= Feb 7, 2018, at 3:39 AM, Ori Finkelman <orif@qwilt.com> wrote:

=
Dear Colleagues,
Regarding the addition of a regular ex= pression match for triggers, mainly for invalidation.
What should b= e the regexp standard we use, PCRE ? POSIX BRE or ERE ?
Does t= he type of regrexp need to be exchanged via the interface (trigger and capab= ility) ?

Example 1: assuming we support only one sp= ecific type of regrex

    { 
       "regex": "/^(https:\/\/video\.example\.co= m)\/([a-z])\/([1-7])\/([\/\w \.-]*)*\/?$",    
&nbs= p;      "case-sensitive": true
    }

Example 2: assuming regexp type is variable
=

    { 
     = ;  "regex": "/^(https:\/\/video\.example\.com)\/([a-z])\/([1-7])\/([\/\= w \.-]*)*\/?$",    
       "cas= e-sensitive": true
       "regrex-type": "pcre= "
    }

Thanks,
Ori



--
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
= --Apple-Mail-9FAC7C82-6DA0-46AD-B5CF-BFED49B28738-- From nobody Wed Feb 7 09:41:51 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 AB05D12D838 for ; Wed, 7 Feb 2018 09:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 eRxdozVxCbMI for ; Wed, 7 Feb 2018 09:41:48 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::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 C4AED12D833 for ; Wed, 7 Feb 2018 09:41:47 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id r71so4718826wmd.1 for ; Wed, 07 Feb 2018 09:41:47 -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=bvuPzNPfJ15rfD9lD7FReqUrnK0yYeAiNvGQRSRQscs=; b=SIU6lj1doP+i5EHQxWhvAgV1CP3filuU2k/d3z9QGDtTKFLbE13mwa+ny8oSPNVAd7 JcfKNZ5sYtC4p/yaJAKsm1aZ7ALz7LqkrzJk8BctgsfBr3BkbIX120/iTKUi8i4yRJZN Oh09Qz9J7EDAhPOt4lPA70g7oERjCvoL+GGazEU0KfZphwPFVxuE+gP6hE8pfi09Kvs1 sA2GYW1+hvazDrqQ1OhmZ3EXO9JK3q1vW/XeU0Rdzw8ldotspk2l1JyZ/XC2PdlT1fOm G0WbpYdZaLPVb1swZP8t2Y7ajDe6csLCc7A+EbnydHzqA46SqgblV158o+DM/hIbsqra F7nQ== 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=bvuPzNPfJ15rfD9lD7FReqUrnK0yYeAiNvGQRSRQscs=; b=SO5NSY3eZnmi2zt6IFTG2EaaZLprCs3Gb3ky+Hglsk6qHPMMCkc2KC+AsvasYvh22Q AyiSEsrTNPGcU73neRucDKEWiECCrl45VqhMiwf3vaFqfV3d7r2r22C1v8SlaZNLduWn 93KBX1MwtnrGSiSX58LwQb4QcSx89IMRbGwrlz4DL8OvWlOXDVAFzeozFoz3EH06rqeP XgbYjTF31IFk43RetnKUxKCPwyWPmPTtEXsEJzV/NyFMJhU8zjgCCIa1qbfzk1Xje8Ru mNFWGy9yATryXjMgQvXr3R1lkL6rB9CCl/ABRSleMVCg3ys5KHPWOdJbq0WPP/9/9AWR 9+UA== X-Gm-Message-State: APf1xPBt2LtVQNxUWwWKhWZsSQGEmPur63pcRkeY4ZcRTc54cf//wJ52 OH83djP8b8+GBOBIbibsZErvHWbo2rXOSSH80rCD0g== X-Google-Smtp-Source: AH8x224qbfDrkf5L3wilDDlD29gH9JFOaULNisXWi4EclONRJAJuzPA5JZr6iGbT89GFYYdnPpDUGGadjXf3v8L5mkU= X-Received: by 10.28.0.212 with SMTP id 203mr4981686wma.128.1518025306191; Wed, 07 Feb 2018 09:41:46 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ori Finkelman Date: Wed, 07 Feb 2018 17:41:35 +0000 Message-ID: To: "Kevin J. Ma" Cc: "" Content-Type: multipart/alternative; boundary="001a113c9bf222e9af0564a2cfb9" Archived-At: Subject: Re: [CDNi] Triggers regexp: draft-finkelman-cdni-sva-extensions-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.22 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, 07 Feb 2018 17:41:50 -0000 --001a113c9bf222e9af0564a2cfb9 Content-Type: text/plain; charset="UTF-8" I also prefer pcre only. On Wed, Feb 7, 2018, 17:01 Kevin J. Ma wrote: > I would favor triggers matching uri signing, i.e., PCRE only, to simplify > interoperability requirements; unless there's a really good reason > implementers should have to support multiple standards? > > Sent from my iPhone > > On Feb 7, 2018, at 3:39 AM, Ori Finkelman wrote: > > Dear Colleagues, > Regarding the addition of a regular expression match for triggers, mainly > for invalidation. > What should be the regexp standard we use, PCRE ? POSIX BRE or ERE ? > Does the type of regrexp need to be exchanged via the interface (trigger > and capability) ? > > Example 1: assuming we support only one specific type of regrex > > { > "regex": > "/^(https:\/\/video\.example\.com)\/([a-z])\/([1-7])\/([\/\w \.-]*)*\/?$", > > "case-sensitive": true > } > > Example 2: assuming regexp type is variable > > { > "regex": > "/^(https:\/\/video\.example\.com)\/([a-z])\/([1-7])\/([\/\w \.-]*)*\/?$", > > "case-sensitive": true > "regrex-type": "pcre" > } > > Thanks, > Ori > > > > -- > > *Ori Finkelman*Qwilt | Work: +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 --001a113c9bf222e9af0564a2cfb9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I also prefer pcre only.


On Wed, Feb 7, 2018, 17:01 = Kevin J. Ma <kevin.j.ma.iet= f@gmail.com> wrote:
I would favor triggers matching uri signing, i.e., PCRE only, to = simplify interoperability requirements; unless there's a really good re= ason implementers should have to support multiple standards?

Sent from my iPhone

On Feb 7, 2018, at 3:39 AM, Ori Finkelman <<= a href=3D"mailto:orif@qwilt.com" target=3D"_blank">orif@qwilt.com> w= rote:

Dear Col= leagues,
Regarding the addition of a regular expression match for trigg= ers, mainly for invalidation.
What should be the regexp standard = we use,=C2=A0PCRE ? POSIX BRE or ERE ?
Does the type of regrexp n= eed to be exchanged via the interface (trigger and capability) ?
=
Example 1: assuming we support only one specific type of reg= rex

=C2=A0 =C2=A0 {=C2=A0
=C2=A0 = =C2=A0 =C2=A0 =C2=A0"regex": "/^(https:\/\/video\.example\.c= om)\/([a-z])\/([1-7])\/([\/\w \.-]*)*\/?$",=C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0"case-sensitive": true
= =C2=A0 =C2=A0 }

Example 2: assuming regexp t= ype is variable

=C2=A0 =C2=A0 {=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0"regex": "/^(https:\/\/video\.= example\.com)\/([a-z])\/([1-7])\/([\/\w \.-]*)*\/?$",=C2=A0 =C2=A0=C2= =A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0"case-sensitive": true
=C2=A0 =C2=A0 =C2=A0 =C2=A0"regrex-type": "pcre&quo= t;
=C2=A0 =C2=A0 }

Thanks,
Ori



--
Ori Finkel= man
Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.c= om
<= span>_______________________________________________
CDNi m= ailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/c= dni


--
Ori Finkelman
Qwilt |= Work: +972-72-2221647 | Mobile: +972-52-3832189 |=C2=A0orif@qwilt.com
--001a113c9bf222e9af0564a2cfb9-- From nobody Thu Feb 8 09:38: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 6DEF712700F for ; Thu, 8 Feb 2018 09:38:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.93 X-Spam-Level: X-Spam-Status: No, score=-14.93 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 B9pzaKK5k8eM for ; Thu, 8 Feb 2018 09:38:27 -0800 (PST) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by ietfa.amsl.com (Postfix) with SMTP id E9FD7126E64 for ; Thu, 8 Feb 2018 09:38:26 -0800 (PST) Received: (qmail 87221 invoked by uid 99); 8 Feb 2018 17:38:25 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 08 Feb 2018 17:38:25 +0000 Received: from mail-it0-f41.google.com (mail-it0-f41.google.com [209.85.214.41]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 8D4511A0054 for ; Thu, 8 Feb 2018 17:38:25 +0000 (UTC) Received: by mail-it0-f41.google.com with SMTP id p139so7531207itb.1 for ; Thu, 08 Feb 2018 09:38:25 -0800 (PST) X-Gm-Message-State: APf1xPC3j0s0ZKV3MqzskOBasn+8oMsIIt8AZ8gjs2ZPsQ4C3PmPd/x1 aCeyOPGYkq0fxlEHLWMQQfivR7nQz8bIheyW8ro= X-Google-Smtp-Source: AH8x2273qcPikTZs+EeuulXy13Ebiz3uQC67fCTFkBKq5eSJx4hYmASNIMcoKX/qThl/YtC7Cewzb1ra0xPDPuNXvtQ= X-Received: by 10.36.142.3 with SMTP id h3mr98608ite.112.1518111504778; Thu, 08 Feb 2018 09:38:24 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Phil Sorber Date: Thu, 08 Feb 2018 17:38:14 +0000 X-Gmail-Original-Message-ID: Message-ID: To: "" Content-Type: multipart/alternative; boundary="94eb2c049e5cf8cbc40564b6e064" Archived-At: Subject: Re: [CDNi] Meeting in London X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.22 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, 08 Feb 2018 17:38:28 -0000 --94eb2c049e5cf8cbc40564b6e064 Content-Type: text/plain; charset="UTF-8" Ok, I'm taking this silence as confirmation. Thanks! On Tue, Feb 6, 2018 at 10:02 PM Phil Sorber wrote: > Hey All, > > I just wanted to confirm that no one thought there was a need to have a > session in London. I don't think we have any big outstanding issues that > require a face to face meeting to resolve. > > Thanks. > --94eb2c049e5cf8cbc40564b6e064 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ok, I'm taking this silence as confirmation.

Thanks!

On Tue, Feb 6, 2018 at 10:02 PM Phil Sorber <sorber@apache.org> wrote:
Hey All,

= I just wanted to confirm that no one thought there was a need to have a ses= sion in London. I don't think we have any big outstanding issues that r= equire a face to face meeting to resolve.

Thanks.<= br>
--94eb2c049e5cf8cbc40564b6e064-- From nobody Thu Feb 8 09:38:48 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 2261C126E64; Thu, 8 Feb 2018 09:38:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: aamelnikov@fastmail.fm, cdni@ietf.org, sorber@apache.org, cdni-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151811151809.17139.9906633915443359241.idtracker@ietfa.amsl.com> Date: Thu, 08 Feb 2018 09:38:38 -0800 Archived-At: Subject: [CDNi] cdni - Not having a session at IETF 101 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.22 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, 08 Feb 2018 17:38:38 -0000 Phil Sorber, a chair of the cdni working group, indicated that the cdni working group does not plan to hold a session at IETF 101. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Mon Feb 12 06:32:43 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 8CAAC127873 for ; Mon, 12 Feb 2018 06:32:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 qf1JEVYXkO-L for ; Mon, 12 Feb 2018 06:32:40 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 410F31270FC for ; Mon, 12 Feb 2018 06:32:40 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id f71so9964905wmf.0 for ; Mon, 12 Feb 2018 06:32:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qwilt-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=jR1uh8mlC4LegqgsM43kiZqYA3/+AxNbEiBZDrtjuAI=; b=U5qkNB+9UlBZAuHkirxYWiXW3e9TCmc3kazQRgTodUNls15x95grkngDTw564ie2iw xM/ArkHkjcnMWVZ7oGZDhHmUEIJxL1zjQc+cS48ex3D5NgWAeSWCJYLZgqVH1xfU0kex fPMZQpMAqDz0Ni7i3BoSQSqsDLkfNxig1vEKvkcdRXybDQ2UoUjmEMt/w0F020LtV7S/ yTuhc/Uyoo4TIjhJYvBqqSR+j78VKRtT7PJeZsmNDFH/p+n5GxZtR3ZE1PZMi3WAEBGM yy1BXk8y0TkvG6OW8NZak+zgXRhYjnCVG9HdIwgwUCNukgCV3NciuvAeyR/QuCX8Y6Bs 9ypw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=jR1uh8mlC4LegqgsM43kiZqYA3/+AxNbEiBZDrtjuAI=; b=cY97awPsBLShUWFlL3H/dZAW4w3vFC8wXx6rSfXEzVFr3Dbw1fKI4HxqDHnMsGQ51q jWZKgSTR6AMSkP5kBhZymZSaySDUWr5zUBCwrItmFfHIT+ioHmdtkSMr0MhQhERhm6TX stYKz/5PpmvxZvMB6GW/L/Gx8bJNU4a4PJwoIXEQpqHSG8tYgIHKySmCeFjf9PDzUyIn 83iLc3h+Tuj5xVZuArCycNX0fDdClKAeeoa9TGwwKErHoJb0fk0cVzimv2tEJu3SkH0e 3ZunSb8bAK7n/Iodg1yDbx9ZnFJkllWT8gYgr/+s3XXOjxx2QMOYGqyJ/SJO0cUh8IH4 1k5A== X-Gm-Message-State: APf1xPD0qmDyGr1/25ER3cqERBnDwsOVFQ0zNtFpO47filfG2IDu8xar h48055PVFSE4d8Tc/smx6+p2pFzeZW9MMW6B2ukXETrV X-Google-Smtp-Source: AH8x226IgCBeWk+pbNJKxxBPVbQRe5GynnASgaekOm/i3Nrfs39nP3nWAUxSTduUzcbxz35Gsgs17JqRmIQ8JLRDC8A= X-Received: by 10.28.0.212 with SMTP id 203mr3428499wma.128.1518445958302; Mon, 12 Feb 2018 06:32:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.127.71 with HTTP; Mon, 12 Feb 2018 06:32:07 -0800 (PST) In-Reply-To: <151844583990.6130.2280764624601101619.idtracker@ietfa.amsl.com> References: <151844583990.6130.2280764624601101619.idtracker@ietfa.amsl.com> From: Ori Finkelman Date: Mon, 12 Feb 2018 16:32:07 +0200 Message-ID: To: "" Content-Type: multipart/alternative; boundary="001a113c9bf2f4c1ae056504bfcf" Archived-At: Subject: [CDNi] Fwd: New Version Notification for draft-finkelman-cdni-rr-sva-extensions-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.22 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 Feb 2018 14:32:42 -0000 --001a113c9bf2f4c1ae056504bfcf Content-Type: text/plain; charset="UTF-8" Dear Colleagues, Please see the new draft for the SVA request routing extensions. Best regards, Ori ---------- Forwarded message ---------- From: Date: Mon, Feb 12, 2018 at 4:30 PM Subject: New Version Notification for draft-finkelman-cdni-rr-sva-extensions-00.txt To: Sanjay Mishra , Ori Finkelman A new version of I-D, draft-finkelman-cdni-rr-sva-extensions-00.txt has been successfully submitted by Ori Finkelman and posted to the IETF repository. Name: draft-finkelman-cdni-rr-sva-extensions Revision: 00 Title: CDNI SVA Request Routing Extensions Document date: 2018-02-12 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-finkelman-cdni- rr-sva-extensions-00.txt Status: https://datatracker.ietf.org/doc/draft-finkelman-cdni-rr- sva-extensions/ Htmlized: https://tools.ietf.org/html/draft-finkelman-cdni-rr-sva- extensions-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-finkelman-cdni- rr-sva-extensions-00 Abstract: The Open Caching working group of the Streaming Video Alliance is focused on the delegation of video delivery requests 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). 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 --001a113c9bf2f4c1ae056504bfcf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Colleagues,
Please see the new draft f= or the SVA request routing extensions.

Best regard= s,
Ori


-------= --- Forwarded message ----------
From: <interne= t-drafts@ietf.org>
Date: Mon, Feb 12, 2018 at 4:30 PM
S= ubject: New Version Notification for draft-finkelman-cdni-rr-sva-extensions= -00.txt
To: Sanjay Mishra <sanjay.mishra@verizon.com>, Ori Finkelman <orif@qwilt.com>



A new version of I-D, draft-finkelman-cdni-rr-sva-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-finkelman-cdni-rr-sva-<= wbr>extensions
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CDNI SVA Request Routing Extension= s
Document date:=C2=A0 2018-02-12
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 9
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft= -finkelman-cdni-rr-sva-extensions-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-finkelman-cdni-rr-= sva-extensions/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-finkelman-cdni-rr-sva-exte= nsions-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-finkelman-c= dni-rr-sva-extensions-00


Abstract:
=C2=A0 =C2=A0The Open Caching working group of the Streaming Video Alliance= is
=C2=A0 =C2=A0focused on the delegation of video delivery requests from comm= ercial
=C2=A0 =C2=A0CDNs to a caching layer at the ISP.=C2=A0 In that aspect, Open= Caching is
=C2=A0 =C2=A0a specific use case of CDNI, where the commercial CDN is the u= pstream
=C2=A0 =C2=A0CDN (uCDN) and the ISP caching layer is the downstream CDN (dC= DN).





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<= br>Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com
--001a113c9bf2f4c1ae056504bfcf-- From nobody Mon Feb 26 04:04:32 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 084EA1242F7 for ; Mon, 26 Feb 2018 04:04:31 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=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 wXiln1GjbHzW for ; Mon, 26 Feb 2018 04:04:29 -0800 (PST) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::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 D7A11124234 for ; Mon, 26 Feb 2018 04:04:28 -0800 (PST) Received: by mail-wr0-x22e.google.com with SMTP id w77so20895954wrc.6 for ; Mon, 26 Feb 2018 04:04:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qwilt-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0EELsMCRXjOD123JF+F8Iiy7dZu3E/yi99v1sb8WP+k=; b=yk4aynW/GBvRnm6cgLiSmUILcOwsrIEmdTLxbH8u6rAulap9IAT4z3xA7AnCPJDMUn 1zWwYFX8OG3lDAmlWfDIobPHhe5E24kqr6ABV1q24gqT8lrKkTZa2Zw4kLkDXZxUZlCV JoDualEL/qXkgKtEdE35uwgayUo0+cYjrb5/xOSbtYxJJvktYZOdXa0NUA3TcMb9qvaS i7M2nShmwrRdxw5pnvVTb1Nbr8augv3gQwK89l+eJfJuHqnHNrujqEVS4nR+sQKQs6cG wA10mmLJh7pZeLh4nUz2lCtcx/AM/+914PFpBW7Ac6uQLeI8aMKuBd74I0/eS8bNPgVX EDig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0EELsMCRXjOD123JF+F8Iiy7dZu3E/yi99v1sb8WP+k=; b=Zlt26Aj+kL4nO7Akd/R9zlEirORx46s9pOn7hLcCNz0SUvjuQWBueyyOvKywSvnF3f stOjTi/evv86sCfCH3wMgEu4rcFwdHCeqVGDTVsmVUtIyALFnsHTTgJ07uDhkUDDjp/k 1DQAANQ6OVNCDROWEgtnANTz5RpUQ+0AqFoUEU0zRoJkejZqASQbPl2Abab/zCLTzroK qzSS1M7lZCJRaA+qadL57sDXOUU4/ncoFBFraHhVTbmVP/38P9EOboiPd5B+eLzD7e5z 3GqGKJrnxswRVvQhNM9AO6dK6mMcGi86zwHaYL7cjr7jBG+PNaS+e1Dab9qCxWO5tE6z P5HQ== X-Gm-Message-State: APf1xPBEtKOOcxE5HXmWBfnQlwPJU1/VfRpDrUfwX1ZjLZ1C26A/N7aY ieEQvOwAH9fdlDaBk30hSZsKMTouvMcoIf4c6IWa4A== X-Google-Smtp-Source: AH8x225IoKW3C28ohabaffGk6temnktstHvvkZR/P4Am5ilRdixlz0gx/p/21j56S6oe/OYdPVb67CnD+HNJUhaudAE= X-Received: by 10.223.161.10 with SMTP id o10mr9809800wro.60.1519646667356; Mon, 26 Feb 2018 04:04:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.208.7 with HTTP; Mon, 26 Feb 2018 04:03:56 -0800 (PST) In-Reply-To: References: From: Ori Finkelman Date: Mon, 26 Feb 2018 14:03:56 +0200 Message-ID: To: "Kevin J. Ma" Cc: "" Content-Type: multipart/alternative; boundary="f403045e2726cad42c05661c4f20" Archived-At: Subject: Re: [CDNi] Triggers regexp: draft-finkelman-cdni-sva-extensions-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.22 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, 26 Feb 2018 12:04:31 -0000 --f403045e2726cad42c05661c4f20 Content-Type: text/plain; charset="UTF-8" Dear all, Another question regarding the trigger extensions. It was suggested that in order to execute a trigger (for example pre-position) in "local time" of each geography, one should combine the geo location extension with the time window extension. For example, if pre-position should occur on 3AM local time, it would be set for 11AM UTC for California , and 8AM UTC on New-York While this works logically, it means that the user needs to state for each relevant geography the UTC time for execution, instead of just stating the required local time and let the dCDN handle it per geography. My question is that given that we add trigger extensions, how would be able to state such multiple cases. Take the above example, I can see two alternatives : 1. Issue two separate trigger commands, one with Geo = CA, and time = 11AM UTC, and a second command with Geo = NY and time = 8AM UTC. while this works, it requires a separate command for each geo. 2. Wrap the extension objects with extension groups, such that each group must be applied together. For example this trigger command will have two extension groups, one with Geo=CA and Time=11AM UTC, and the other with Geo=NY and time=8AM UTC. I would love to get some feedback on this, Thanks, Ori On Wed, Feb 7, 2018 at 7:41 PM, Ori Finkelman wrote: > I also prefer pcre only. > > On Wed, Feb 7, 2018, 17:01 Kevin J. Ma wrote: > >> I would favor triggers matching uri signing, i.e., PCRE only, to simplify >> interoperability requirements; unless there's a really good reason >> implementers should have to support multiple standards? >> >> Sent from my iPhone >> >> On Feb 7, 2018, at 3:39 AM, Ori Finkelman wrote: >> >> Dear Colleagues, >> Regarding the addition of a regular expression match for triggers, mainly >> for invalidation. >> What should be the regexp standard we use, PCRE ? POSIX BRE or ERE ? >> Does the type of regrexp need to be exchanged via the interface (trigger >> and capability) ? >> >> Example 1: assuming we support only one specific type of regrex >> >> { >> "regex": "/^(https:\/\/video\.example\.com)\/([a-z])\/([1-7])\/([\/\w >> \.-]*)*\/?$", >> "case-sensitive": true >> } >> >> Example 2: assuming regexp type is variable >> >> { >> "regex": "/^(https:\/\/video\.example\.com)\/([a-z])\/([1-7])\/([\/\w >> \.-]*)*\/?$", >> "case-sensitive": true >> "regrex-type": "pcre" >> } >> >> Thanks, >> Ori >> >> >> >> -- >> >> *Ori Finkelman*Qwilt | Work: +972-72-2221647 <072-222-1647> | Mobile: >> +972-52-3832189 <052-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 <072-222-1647> | Mobile: > +972-52-3832189 <052-383-2189> | orif@qwilt.com > -- *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com --f403045e2726cad42c05661c4f20 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,
Another question regarding the trigger exten= sions.
It was suggested that in order to execute a trigger (for e= xample pre-position) in "local time" of each geography, one shoul= d combine the geo location extension with the time window extension.
<= div>For example, if pre-position should occur on 3AM local time, it would b= e set for 11AM UTC for California , and 8AM UTC on New-York
While= this works logically, it means that the user needs to state for each relev= ant geography the UTC time for execution, instead of just stating the requi= red local time and let the dCDN handle it per geography.

My question is that given that we add trigger extensions, how would = be able to state such multiple cases.

Take the abo= ve example, I can see two alternatives :
1. Issue two separate tr= igger commands, one with Geo =3D CA, and time =3D 11AM UTC, and a second co= mmand with Geo =3D NY and time =3D 8AM UTC.
=C2=A0 =C2=A0 =C2=A0w= hile this works, it requires a separate command for each geo.
2. Wrap the extension objects with extension groups, such that = each group must be applied together. For example this trigger command will = have two extension groups, one with Geo=3DCA and Time=3D11AM UTC, and the o= ther with Geo=3DNY and time=3D8AM UTC.


<= div>
I would love to get some feedback on this,

Thanks,
Ori

<= br>

On= Wed, Feb 7, 2018 at 7:41 PM, Ori Finkelman <orif@qwilt.com> = wrote:

I also prefer pcre = only.


On Wed, Feb 7, 2018, 17:01 = Kevin J. Ma <kevin.j.ma.ietf@gmail.com> wrote:
I would favor triggers matching uri signing, i.= e., PCRE only, to simplify interoperability requirements; unless there'= s a really good reason implementers should have to support multiple standar= ds?

Sent from my iPhone

On Feb 7= , 2018, at 3:39 AM, Ori Finkelman <orif@qwilt.com> wrote:

Dear Colleagues,
Regarding the addition= of a regular expression match for triggers, mainly for invalidation.
=
What should be the regexp standard we use,=C2=A0PCRE ? POSIX BRE or ER= E ?
Does the type of regrexp need to be exchanged via the interfa= ce (trigger and capability) ?

Example 1: assuming = we support only one specific type of regrex

= =C2=A0 =C2=A0 {=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0"regex"= ;: "/^(https:\/\/video\.example\.com)\/([a-z])\/([1-7])\/([\/\w \= .-]*)*\/?$",=C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0&= quot;case-sensitive": true
=C2=A0 =C2=A0 }
<= br>
Example 2: assuming regexp type is variable

=C2=A0 =C2=A0 {=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0&qu= ot;regex": "/^(https:\/\/video\.example\.com)\/([a-z])\/([1-= 7])\/([\/\w \.-]*)*\/?$",=C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0 = =C2=A0 =C2=A0"case-sensitive": true
=C2=A0 =C2=A0 =C2= =A0 =C2=A0"regrex-type": "pcre"
=C2=A0 =C2=A0= }

Thanks,
Ori



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

--
Ori F= inkelman
Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 |=C2=A0orif@q= wilt.com



--
Ori Finkelman
Qwilt | Work:= +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com
--f403045e2726cad42c05661c4f20-- From nobody Mon Feb 26 21:53:16 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 C15921200B9 for ; Mon, 26 Feb 2018 21:53: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=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 7_ShGqTSl-Bs for ; Mon, 26 Feb 2018 21:53:12 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 3EEAE124207 for ; Mon, 26 Feb 2018 21:53:12 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id o25so16635921qkl.7 for ; Mon, 26 Feb 2018 21:53:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=F3uxDi0a5JUYrnIaN/y5DyYAo7VR+SJA5f6loGIZ24c=; b=MqhR927LESbJnU3RFPPoXmR8zGhYxjvh54x7BwzCSVou27Bi/4exj05ofzYGsav2Nw ezbnF5Som4GPJ0t9IQPXRtDP4OEcH2yRLqGOgB5LrrGSQUHXMSqEKdAlFNbj6OLxecxj OBmQFaXcxYa5GbJWg6AZOYtbL/X5GGiSMvbsaj0CBqgczCyHlu3aF10q1MSdPQg/U3HW bWS6hBLbruKcI8kdwAbKcOe8KI/Oau/jV1bN5w5Dl0XX7DE21rdXoD6ABXXHBFFoynJJ zpQYBGXnShXG45NTktonWvQdyGE26PLKn2aiD5Az2wUwOv/VtDq4mOCzxm1lPvuGamTp EiZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=F3uxDi0a5JUYrnIaN/y5DyYAo7VR+SJA5f6loGIZ24c=; b=FU49Vr14HOKnGeIKsWIkuKeLHeH73xQocFcpyim3lv6l4gKMN8dlb1me22tBOLNLR+ 4CJsKdNJAHvsy6qtVb5ZeYtTUvCsrVNJmNKO5w0HFw9up7KXIQYCLuEW1IvrVFKSopOn 2hFldaskiGsvxVXTvNUdn1tgSqqHPxm7A5lasmUBgEOweuFv6X5Ni5JTExBNDv9b8Ye3 m92KDn3fWxgWSH3IKs/dYjJBZhy0N0lwKq2XG0QBm86l3oj9olUKsRJFc5QtOcuhQhRT vTK+/c+FakWAI6yN9Ix9ohPTe+8ynVaXBFkSzj4qVteZNBqfRqqU+NwyEQNMohe4pbf0 SWug== X-Gm-Message-State: APf1xPCxnzoLSE6PwuzLnLRrGYK1ess+l+ceVZOXKbRG2yr00/Io/+ND ai6xYRi5YA9LJ5gCiuHb+KvnwIOi X-Google-Smtp-Source: AG47ELt+AeAEDjxkvuJh2J1ClBKbe1DaFSTYiWViYGe/+io86spCPacE61WaabZe0GyJ6e/Puw53qQ== X-Received: by 10.55.212.130 with SMTP id s2mr21408130qks.247.1519710791037; Mon, 26 Feb 2018 21:53:11 -0800 (PST) Received: from [192.168.1.100] (c-24-34-41-146.hsd1.nh.comcast.net. [24.34.41.146]) by smtp.gmail.com with ESMTPSA id g15sm5716785qke.34.2018.02.26.21.53.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Feb 2018 21:53:09 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-D84BE065-7993-45CB-92FC-076A6D4959FD Mime-Version: 1.0 (1.0) From: "Kevin J. Ma" X-Mailer: iPhone Mail (15D60) In-Reply-To: Date: Tue, 27 Feb 2018 00:53:08 -0500 Cc: "" Content-Transfer-Encoding: 7bit Message-Id: <816D33C2-C6C0-40C8-8160-8E38B521215E@gmail.com> References: To: Ori Finkelman Archived-At: Subject: Re: [CDNi] Triggers regexp: draft-finkelman-cdni-sva-extensions-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.22 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, 27 Feb 2018 05:53:15 -0000 --Apple-Mail-D84BE065-7993-45CB-92FC-076A6D4959FD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Ori, (as an individual) I personally don't see any reason to combine time and g= eolocation; it over complicates things, imo. I didn't see a problem with pr= oviding a time without timezone to be interpreted as "local time". I didn't= think that being able to send a trigger that said "do this at 1am local tim= e" was a terribly difficult concept - it probably just needs some textual cl= arification and a more precise definition of how the json should be parsed a= nd interpreted, to remove any UTC vs explicit timezone vs "local time" ambig= uity? thanx. -- Kevin J. Ma Sent from my iPhone > On Feb 26, 2018, at 7:03 AM, Ori Finkelman wrote: >=20 > Dear all, > Another question regarding the trigger extensions. > It was suggested that in order to execute a trigger (for example pre-posit= ion) in "local time" of each geography, one should combine the geo location e= xtension with the time window extension. > For example, if pre-position should occur on 3AM local time, it would be s= et for 11AM UTC for California , and 8AM UTC on New-York > While this works logically, it means that the user needs to state for each= relevant geography the UTC time for execution, instead of just stating the r= equired local time and let the dCDN handle it per geography. >=20 > My question is that given that we add trigger extensions, how would be abl= e to state such multiple cases. >=20 > Take the above example, I can see two alternatives : > 1. Issue two separate trigger commands, one with Geo =3D CA, and time =3D 1= 1AM UTC, and a second command with Geo =3D NY and time =3D 8AM UTC. > while this works, it requires a separate command for each geo. >=20 > 2. Wrap the extension objects with extension groups, such that each group m= ust be applied together. For example this trigger command will have two exte= nsion groups, one with Geo=3DCA and Time=3D11AM UTC, and the other with Geo=3D= NY and time=3D8AM UTC. >=20 >=20 >=20 > I would love to get some feedback on this, >=20 >=20 > Thanks, > Ori >=20 >=20 >=20 >> On Wed, Feb 7, 2018 at 7:41 PM, Ori Finkelman wrote: >> I also prefer pcre only. >>=20 >>=20 >>> On Wed, Feb 7, 2018, 17:01 Kevin J. Ma wrote= : >>> I would favor triggers matching uri signing, i.e., PCRE only, to simplif= y interoperability requirements; unless there's a really good reason impleme= nters should have to support multiple standards? >>>=20 >>> Sent from my iPhone >>>=20 >>>> On Feb 7, 2018, at 3:39 AM, Ori Finkelman wrote: >>>>=20 >>>> Dear Colleagues, >>>> Regarding the addition of a regular expression match for triggers, main= ly for invalidation. >>>> What should be the regexp standard we use, PCRE ? POSIX BRE or ERE ? >>>> Does the type of regrexp need to be exchanged via the interface (trigge= r and capability) ? >>>>=20 >>>> Example 1: assuming we support only one specific type of regrex >>>>=20 >>>> {=20 >>>> "regex": "/^(https:\/\/video\.example\.com)\/([a-z])\/([1-7])\/(= [\/\w \.-]*)*\/?$", =20 >>>> "case-sensitive": true >>>> } >>>>=20 >>>> Example 2: assuming regexp type is variable >>>>=20 >>>> {=20 >>>> "regex": "/^(https:\/\/video\.example\.com)\/([a-z])\/([1-7])\/(= [\/\w \.-]*)*\/?$", =20 >>>> "case-sensitive": true >>>> "regrex-type": "pcre" >>>> } >>>>=20 >>>> Thanks, >>>> Ori >>>>=20 >>>>=20 >>>>=20 >>>> --=20 >>>> Ori Finkelman >>>> Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.co= m >>>=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 > --=20 > Ori Finkelman > Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com --Apple-Mail-D84BE065-7993-45CB-92FC-076A6D4959FD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ori,

  (as an in= dividual) I personally don't see any reason to combine time and geolocation;= it over complicates things, imo.  I didn't see a problem with providin= g a time without timezone to be interpreted as "local time".  I didn't t= hink that being able to send a trigger that said "do this at 1am local time"= was a terribly difficult concept - it probably just needs some textual clar= ification and a more precise definition of how the json should be parsed and= interpreted, to remove any UTC vs explicit timezone vs "local time" ambigui= ty?

thanx.

--  Kevin J= . Ma

Sent from my iPhone
On Feb 26, 2018, at 7:03 AM, Ori Finkelman <orif@qwilt.com> wrote:

<= div>
Dear all,
Another question regarding the trigger ex= tensions.
It was suggested that in order to execute a trigger (for= example pre-position) in "local time" of each geography, one should combine= the geo location extension with the time window extension.
For ex= ample, if pre-position should occur on 3AM local time, it would be set for 1= 1AM UTC for California , and 8AM UTC on New-York
While this works l= ogically, it means that the user needs to state for each relevant geography t= he UTC time for execution, instead of just stating the required local time a= nd let the dCDN handle it per geography.

My questio= n is that given that we add trigger extensions, how would be able to state s= uch multiple cases.

Take the above example, I can s= ee two alternatives :
1. Issue two separate trigger commands, one w= ith Geo =3D CA, and time =3D 11AM UTC, and a second command with Geo =3D NY a= nd time =3D 8AM UTC.
     while this works, it requ= ires a separate command for each geo.

2. Wrap the e= xtension objects with extension groups, such that each group must be applied= together. For example this trigger command will have two extension groups, o= ne with Geo=3DCA and Time=3D11AM UTC, and the other with Geo=3DNY and time=3D= 8AM UTC.



I would love= to get some feedback on this,


Thank= s,
Ori



On Wed, Feb 7, 2018 at 7:41 PM, Ori = Finkelman <orif@qwilt.com> wrote:
I also prefer pcre only.


On Wed, Feb 7, 2018, 17:01 K= evin J. Ma <kevin.j.ma.ietf@gmail.com> wrote:
I would favor triggers matching uri signing, i.e., P= CRE only, to simplify interoperability requirements; unless there's a really= good reason implementers should have to support multiple standards?

=
Sen= t from my iPhone

On Feb 7, 2018, at 3:= 39 AM, Ori Finkelman <orif@qwilt.com> wrote:

<= div dir=3D"ltr">Dear Colleagues,
Regarding the addition of a regular exp= ression match for triggers, mainly for invalidation.
What should b= e the regexp standard we use, PCRE ? POSIX BRE or ERE ?
Does t= he type of regrexp need to be exchanged via the interface (trigger and capab= ility) ?

Example 1: assuming we support only one sp= ecific type of regrex

    { 
       "regex": "/^(https:\/\/video\.example\.com)\/([a-z])\/([1-7])\/([\/\w \.-]*)*\/?$",    
       "case-sensitive": true
    }=

Example 2: assuming regexp type is variable<= /div>

    { 
    &= nbsp;  "regex": "/^(https:\/\/video\.example\.com)\/([a-z])\/([1-7= ])\/([\/\w \.-]*)*\/?$",    
      &= nbsp;"case-sensitive": true
       "regrex-typ= e": "pcre"
    }

Thanks,<= /div>
Ori



--
<= div class=3D"m_4594877315751269159m_3543836693084869264gmail_signature">Ori Finkelman
Qwilt | Work: +972-72-2221647 | Mobile: <= a href=3D"tel:052-383-2189" value=3D"+972523832189" target=3D"_blank">+972-5= 2-3832189 | orif@qwilt.com
_______________________________________________
CDN= i mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listi= nfo/cdni


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


--
Ori Finkelman
Qwilt | Work: +972-72-2221647 |= Mobile: +972-52-3832189 | orif@qwilt.com
= --Apple-Mail-D84BE065-7993-45CB-92FC-076A6D4959FD-- From nobody Tue Feb 27 01:23: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 4F857126CD8 for ; Tue, 27 Feb 2018 01:23:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=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 KoMezN7qAfU3 for ; Tue, 27 Feb 2018 01:23:56 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 A48C81201F2 for ; Tue, 27 Feb 2018 01:23:55 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id 139so9228177wmn.2 for ; Tue, 27 Feb 2018 01:23:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qwilt-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YnGQtTnbXtaiSMFzpKeII0JvoEfvDrOWtVQdil4ezCQ=; b=VLdHQiK6V+2KDUjfmbZRMjjw5CLc/bF1CYFVPGkDg4bASZRsYc4bA8qHs2s5OBxwKZ Ns96Bbaw0eHawYMuY8Od4VQNcJ2mS6BZT8F4/tLl6caTN9HEQ8JlC1rCVdFnsQRSF2sh KlaHU5BHjdv8TuNxxcwjGldz15NEkaM8IN8EsW5d+RcumFnD68JK5ajMZX6fE8YSis44 AjhCiMQwABtQhtMXnG/pLXIawOnuUZGwcCO4bIDMqooTLcSHyAAFgNpE9HfBbj5zCiAT qTHZyc2Ab9Ch/c150E7Svi1tz+Oznx1knhuXjIQviOPzpvuDFbZoR4RLOKGOTI+vWtzP 6xkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YnGQtTnbXtaiSMFzpKeII0JvoEfvDrOWtVQdil4ezCQ=; b=VjmvzKYJ/3JqvjY3+MWLVRq5d/u0LF95RVxh4uV8ErtYneP5ioP6cX2SNsGKhB6t3D gJuH4F4AHzP2b38jv8Vina0penBLCTQb5e6S77bfXi7Gyl9UwMzKFeoSHTt9O3wVYmmL IxBRmExX0Dv4zo5WA6WkBF7//jGExxYzCdy6WveGKECq6NnBM3JgjfP6ILx6QpKgduZ2 qM47q4m4ALVgZwbfisKDWSfbZ7LkF5yuHQ5euAf2GWgZArKZJar1KHIla/aJW0GCTjfQ eus18kQoqMSCf8jmzVGkgrHymGr43pD5ka8UqvBwtOhrlzlBkTm8qHb7nVh31VBm+kU3 hNTA== X-Gm-Message-State: APf1xPC5+jKHkdJ6V37mA0yICMJ0gY2xQKC7NE1Kg0p6EINa605uqaD/ IgoRnlbR7j9aX9nVHTKuUuaN6YYCg5xyUOAnaskldQ== X-Google-Smtp-Source: AG47ELuA0urgrNink+MGKF7AHVv5BL0vWIY12Vi+rjDgIlB8C4ZF+LVWhs7VW9w6b9iCZvkpIVEWTmJJytwfiaRLAWw= X-Received: by 10.28.93.3 with SMTP id r3mr5478796wmb.26.1519723434075; Tue, 27 Feb 2018 01:23:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.208.7 with HTTP; Tue, 27 Feb 2018 01:23:23 -0800 (PST) In-Reply-To: <816D33C2-C6C0-40C8-8160-8E38B521215E@gmail.com> References: <816D33C2-C6C0-40C8-8160-8E38B521215E@gmail.com> From: Ori Finkelman Date: Tue, 27 Feb 2018 11:23:23 +0200 Message-ID: To: "Kevin J. Ma" Cc: "" Content-Type: multipart/alternative; boundary="001a1145a70c7203b205662e2fe6" Archived-At: Subject: Re: [CDNi] Triggers regexp: draft-finkelman-cdni-sva-extensions-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.22 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, 27 Feb 2018 09:23:58 -0000 --001a1145a70c7203b205662e2fe6 Content-Type: text/plain; charset="UTF-8" Hi Kevin, I think the difficulty with local time is the interpretation of what to do with it. If it is a generic local time, then whose local time is it ? the uCDN ? the dCDN ? per cache or region ? OTHO if it is local time plus time zone, then you need to provide them for each and every geo, so it comes back the original question in my previous mail. However, after reiteration this internally, I tend to agree it over complicates things, and for now let's stick with a general time scope, stated in UTC. If ever an implementation will really need to have different times for different geos, they will be able to add a new object, for example GeoAndTime object that will state the required time per Geo, but this can be deferred for now. Thanks, Ori On Tue, Feb 27, 2018 at 7:53 AM, Kevin J. Ma wrote: > Hi Ori, > > (as an individual) I personally don't see any reason to combine time and > geolocation; it over complicates things, imo. I didn't see a problem with > providing a time without timezone to be interpreted as "local time". I > didn't think that being able to send a trigger that said "do this at 1am > local time" was a terribly difficult concept - it probably just needs some > textual clarification and a more precise definition of how the json should > be parsed and interpreted, to remove any UTC vs explicit timezone vs "local > time" ambiguity? > > thanx. > > -- Kevin J. Ma > > Sent from my iPhone > > On Feb 26, 2018, at 7:03 AM, Ori Finkelman wrote: > > Dear all, > Another question regarding the trigger extensions. > It was suggested that in order to execute a trigger (for example > pre-position) in "local time" of each geography, one should combine the geo > location extension with the time window extension. > For example, if pre-position should occur on 3AM local time, it would be > set for 11AM UTC for California , and 8AM UTC on New-York > While this works logically, it means that the user needs to state for each > relevant geography the UTC time for execution, instead of just stating the > required local time and let the dCDN handle it per geography. > > My question is that given that we add trigger extensions, how would be > able to state such multiple cases. > > Take the above example, I can see two alternatives : > 1. Issue two separate trigger commands, one with Geo = CA, and time = 11AM > UTC, and a second command with Geo = NY and time = 8AM UTC. > while this works, it requires a separate command for each geo. > > 2. Wrap the extension objects with extension groups, such that each group > must be applied together. For example this trigger command will have two > extension groups, one with Geo=CA and Time=11AM UTC, and the other with > Geo=NY and time=8AM UTC. > > > > I would love to get some feedback on this, > > > Thanks, > Ori > > > > On Wed, Feb 7, 2018 at 7:41 PM, Ori Finkelman wrote: > >> I also prefer pcre only. >> >> On Wed, Feb 7, 2018, 17:01 Kevin J. Ma wrote: >> >>> I would favor triggers matching uri signing, i.e., PCRE only, to >>> simplify interoperability requirements; unless there's a really good reason >>> implementers should have to support multiple standards? >>> >>> Sent from my iPhone >>> >>> On Feb 7, 2018, at 3:39 AM, Ori Finkelman wrote: >>> >>> Dear Colleagues, >>> Regarding the addition of a regular expression match for triggers, >>> mainly for invalidation. >>> What should be the regexp standard we use, PCRE ? POSIX BRE or ERE ? >>> Does the type of regrexp need to be exchanged via the interface (trigger >>> and capability) ? >>> >>> Example 1: assuming we support only one specific type of regrex >>> >>> { >>> "regex": "/^(https:\/\/video\.example\.com)\/([a-z])\/([1-7])\/([\/\w >>> \.-]*)*\/?$", >>> "case-sensitive": true >>> } >>> >>> Example 2: assuming regexp type is variable >>> >>> { >>> "regex": "/^(https:\/\/video\.example\.com)\/([a-z])\/([1-7])\/([\/\w >>> \.-]*)*\/?$", >>> "case-sensitive": true >>> "regrex-type": "pcre" >>> } >>> >>> Thanks, >>> Ori >>> >>> >>> >>> -- >>> >>> *Ori Finkelman*Qwilt | Work: +972-72-2221647 <072-222-1647> | Mobile: >>> +972-52-3832189 <052-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 <072-222-1647> | Mobile: >> +972-52-3832189 <052-383-2189> | orif@qwilt.com >> > > > > -- > > *Ori Finkelman*Qwilt | Work: +972-72-2221647 <072-222-1647> | Mobile: > +972-52-3832189 <052-383-2189> | orif@qwilt.com > > -- *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com --001a1145a70c7203b205662e2fe6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Kevin,
I think the difficulty with local time is th= e interpretation of what to do with it.
If it is a generic local = time, then whose local time is it ? the uCDN ? the dCDN ? per cache or regi= on ?
OTHO if it is local time plus time zone, then you need to pr= ovide them for each and every geo, so it comes back the original question i= n my previous mail.

However, after reiteration thi= s internally, I tend to agree it over complicates things, and for now let&#= 39;s stick with a general time scope, stated in UTC.
If ever an i= mplementation will really need to have different times for different geos, = they will be able to add a new object, for example GeoAndTime object that w= ill state the required time per Geo, but this can be deferred for now.

Thanks,
Ori

On Tue, Feb 27, 2018 at 7:53 AM, Kevin= J. Ma <kevin.j.ma.ietf@gmail.com> wrote:
Hi Ori,

=C2=A0= (as an individual) I personally don't see any reason to combine time a= nd geolocation; it over complicates things, imo.=C2=A0 I didn't see a p= roblem with providing a time without timezone to be interpreted as "lo= cal time".=C2=A0 I didn't think that being able to send a trigger = that said "do this at 1am local time" was a terribly difficult co= ncept - it probably just needs some textual clarification and a more precis= e definition of how the json should be parsed and interpreted, to remove an= y UTC vs explicit timezone vs "local time" ambiguity?
<= br>
thanx.

-- =C2=A0Kevin J. Ma

<= div id=3D"m_3132961322781999934AppleMailSignature">Sent from my iPhone

On Feb 26, 2018, at 7:03 AM, Ori Finkelman= <orif@qwilt.com= > wrote:

De= ar all,
Another question regarding the trigger extensions.
It= was suggested that in order to execute a trigger (for example pre-position= ) in "local time" of each geography, one should combine the geo l= ocation extension with the time window extension.
For example, if= pre-position should occur on 3AM local time, it would be set for 11AM UTC = for California , and 8AM UTC on New-York
While this works logical= ly, it means that the user needs to state for each relevant geography the U= TC time for execution, instead of just stating the required local time and = let the dCDN handle it per geography.

My question = is that given that we add trigger extensions, how would be able to state su= ch multiple cases.

Take the above example, I can s= ee two alternatives :
1. Issue two separate trigger commands, one= with Geo =3D CA, and time =3D 11AM UTC, and a second command with Geo =3D = NY and time =3D 8AM UTC.
=C2=A0 =C2=A0 =C2=A0while this works, it= requires a separate command for each geo.

2. Wrap= the extension objects with extension groups, such that each group must be = applied together. For example this trigger command will have two extension = groups, one with Geo=3DCA and Time=3D11AM UTC, and the other with Geo=3DNY = and time=3D8AM UTC.



= I would love to get some feedback on this,


Thanks,
Ori



On Wed, Feb 7, 2018 a= t 7:41 PM, Ori Finkelman <orif@qwilt.com> wrote:

I also prefer pcre only.


On Wed, Feb 7, 2018, 17:01 = Kevin J. Ma <kevin.j.ma.ietf@gmail.com> wrote:
I would favor triggers matching uri signing, i.= e., PCRE only, to simplify interoperability requirements; unless there'= s a really good reason implementers should have to support multiple standar= ds?

Sent from my iPhone

On Feb 7, 2018, at 3:39 AM, Ori Finkelman <orif@qwilt.com> wrote:

Dear Colleagues,
Re= garding the addition of a regular expression match for triggers, mainly for= invalidation.
What should be the regexp standard we use,=C2=A0PC= RE ? POSIX BRE or ERE ?
Does the type of regrexp need to be excha= nged via the interface (trigger and capability) ?

= Example 1: assuming we support only one specific type of regrex
<= br>
=C2=A0 =C2=A0 {=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2= =A0"regex": "/^(https:\/\/video\.example\.com)\/([a-z])= \/([1-7])\/([\/\w \.-]*)*\/?$",=C2=A0 =C2=A0=C2=A0
=C2=A0 = =C2=A0 =C2=A0 =C2=A0"case-sensitive": true
=C2=A0 =C2= =A0 }

Example 2: assuming regexp type is var= iable

=C2=A0 =C2=A0 {=C2=A0
=C2=A0 = =C2=A0 =C2=A0 =C2=A0"regex": "/^(https:\/\/video\.example\.<= wbr>com)\/([a-z])\/([1-7])\/([\/\w \.-]*)*\/?$",=C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0"case-sensitive": true
=C2=A0 =C2=A0 =C2=A0 =C2=A0"regrex-type": "pcre"
=C2=A0 =C2=A0 }

Thanks,
Ori=

<= span>_______________________________________________
C= DNi 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
<= /div>


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



--
Ori Finkelman
Qwilt | Work= : +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com
--001a1145a70c7203b205662e2fe6-- From nobody Tue Feb 27 14:58: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 D26E412E8C3 for ; Tue, 27 Feb 2018 14:58:33 -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=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 y9KQh4IajRND for ; Tue, 27 Feb 2018 14:58:31 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 48CFA12E88D for ; Tue, 27 Feb 2018 14:58:31 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id s198so700058qke.5 for ; Tue, 27 Feb 2018 14:58:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PaRXejxPkmA2dw7qSMdpG7achO5/mQNqGPgmeR/BI+k=; b=dQpok4mR9raPT/lV7oLHBXdOWhCrYKp1KzemSEKI3QiGDpEHBIFmthxDEQU9y8Yd1l suNvnk490LlOp7q6pSmGficVUTHx4B2Oy4jTu0agyW+GCmvL0KvEp81LiwLsqaD6R4pP 8q9CSoUJHKTmEvdlA4u2KHaQPuSjmwVBo5jqHvEMnC9mbsXAWa+H1atsOk1MF2zWmEue IX2oj+d6wwAhScdwA8sl7gryr1a20lKliM7zkANvuS4s7szQMjc57Ok/lUcuRARNdhXb +CizUHQAyW8biDbp3XcotQCP0RYxJN4w8vO358pfPPXaajFXSBnBlEmmMkHAmwbozyFT y3Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PaRXejxPkmA2dw7qSMdpG7achO5/mQNqGPgmeR/BI+k=; b=Ye+i96aztGQ95fTVWCkqqo0MXJYOibtOu2OuS4D+fN6mrLuz9fSUAR66AcSyKONRYs hWvImYAOgJvEwl0/i7nU2uP+7Bv/LFDZ7WgPtYhVkRuWxa4N7asFQIg+jj+Ud7K0FF3C i8Xqo29HoL//KYBbX7vvKQnudPbWXg1RcFJEdoNP602vN/Xwh8q5sYuzyINqscVrq3ma CGVkdTT28f3nZmQWJ2KnW0UFgdqMwUHp9jQ9RmqbMbXA8japRTmBwxrg7RZga9LfkEqI WwSPGja6aMPJJOhUNDXqzDUqW7jYF4cIl+zrntQj9hAKQFFq70T5ik0EIv5qI9JU1MKN cGmQ== X-Gm-Message-State: APf1xPAV637eA5xA8yO4T0dLmTnh1ux4a2O75/DjCOOD/3iQ6wqIpOMl V/oNFBgAv0JDnvaRNyRqmKqmgu+y X-Google-Smtp-Source: AG47ELsRlFKzV1Gr5K1bWzwRFwMTk6Gf4+6seVWlJIUvHdqaGEfw/XtIXIeGIE8Wm8acEyZ/3KFKxw== X-Received: by 10.55.115.67 with SMTP id o64mr24359846qkc.144.1519772310211; Tue, 27 Feb 2018 14:58:30 -0800 (PST) Received: from [192.168.0.41] (static-72-70-48-42.bstnma.fios.verizon.net. [72.70.48.42]) by smtp.gmail.com with ESMTPSA id h190sm206732qka.10.2018.02.27.14.58.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Feb 2018 14:58:29 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-FD7D2045-B512-4315-885E-FED4147A0CDB Mime-Version: 1.0 (1.0) From: "Kevin J. Ma" X-Mailer: iPhone Mail (15D60) In-Reply-To: Date: Tue, 27 Feb 2018 17:58:28 -0500 Cc: "" Content-Transfer-Encoding: 7bit Message-Id: References: <816D33C2-C6C0-40C8-8160-8E38B521215E@gmail.com> To: Ori Finkelman Archived-At: Subject: Re: [CDNi] Triggers regexp: draft-finkelman-cdni-sva-extensions-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.22 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, 27 Feb 2018 22:58:34 -0000 --Apple-Mail-FD7D2045-B512-4315-885E-FED4147A0CDB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I think it is up to the dCDN to interpret local time. If the uCDN wants to u= se it's local time, it should specify it in UTC. The question that caused confusion, iirc, was about trying to predict when a= cache in a given region is going to be hit, and I don't think that is a tra= ctable problem. The idea of saying "preposition X at time Y" is an assumpti= on that Y is the optimal time to preposition X (in the uCDN's opinion). Tha= t assumption is based off an underlying assumption that the primetime load o= n the dCDN is not at time Y, but there's always going to be exceptions to th= at. A cache in LA may serve users in NY (or vice versa) and may not have hi= t the designated local time yet; it violates the assumption whether we use U= TC or localtime, so I don't see it as something for which we should design. Sent from my iPhone > On Feb 27, 2018, at 4:23 AM, Ori Finkelman wrote: >=20 > Hi Kevin, > I think the difficulty with local time is the interpretation of what to do= with it. > If it is a generic local time, then whose local time is it ? the uCDN ? th= e dCDN ? per cache or region ? > OTHO if it is local time plus time zone, then you need to provide them for= each and every geo, so it comes back the original question in my previous m= ail. >=20 > However, after reiteration this internally, I tend to agree it over compli= cates things, and for now let's stick with a general time scope, stated in U= TC. > If ever an implementation will really need to have different times for dif= ferent geos, they will be able to add a new object, for example GeoAndTime o= bject that will state the required time per Geo, but this can be deferred fo= r now. >=20 > Thanks, > Ori >=20 >> On Tue, Feb 27, 2018 at 7:53 AM, Kevin J. Ma w= rote: >> Hi Ori, >>=20 >> (as an individual) I personally don't see any reason to combine time an= d geolocation; it over complicates things, imo. I didn't see a problem with= providing a time without timezone to be interpreted as "local time". I did= n't think that being able to send a trigger that said "do this at 1am local t= ime" was a terribly difficult concept - it probably just needs some textual c= larification and a more precise definition of how the json should be parsed a= nd interpreted, to remove any UTC vs explicit timezone vs "local time" ambig= uity? >>=20 >> thanx. >>=20 >> -- Kevin J. Ma >>=20 >> Sent from my iPhone >>=20 >>> On Feb 26, 2018, at 7:03 AM, Ori Finkelman wrote: >>>=20 >>> Dear all, >>> Another question regarding the trigger extensions. >>> It was suggested that in order to execute a trigger (for example pre-pos= ition) in "local time" of each geography, one should combine the geo locatio= n extension with the time window extension. >>> For example, if pre-position should occur on 3AM local time, it would be= set for 11AM UTC for California , and 8AM UTC on New-York >>> While this works logically, it means that the user needs to state for ea= ch relevant geography the UTC time for execution, instead of just stating th= e required local time and let the dCDN handle it per geography. >>>=20 >>> My question is that given that we add trigger extensions, how would be a= ble to state such multiple cases. >>>=20 >>> Take the above example, I can see two alternatives : >>> 1. Issue two separate trigger commands, one with Geo =3D CA, and time =3D= 11AM UTC, and a second command with Geo =3D NY and time =3D 8AM UTC. >>> while this works, it requires a separate command for each geo. >>>=20 >>> 2. Wrap the extension objects with extension groups, such that each grou= p must be applied together. For example this trigger command will have two e= xtension groups, one with Geo=3DCA and Time=3D11AM UTC, and the other with G= eo=3DNY and time=3D8AM UTC. >>>=20 >>>=20 >>>=20 >>> I would love to get some feedback on this, >>>=20 >>>=20 >>> Thanks, >>> Ori >>>=20 >>>=20 >>>=20 >>>> On Wed, Feb 7, 2018 at 7:41 PM, Ori Finkelman wrote: >>>> I also prefer pcre only. >>>>=20 >>>>=20 >>>>> On Wed, Feb 7, 2018, 17:01 Kevin J. Ma wro= te: >>>>> I would favor triggers matching uri signing, i.e., PCRE only, to simpl= ify interoperability requirements; unless there's a really good reason imple= menters should have to support multiple standards? >>>>>=20 >>>>> Sent from my iPhone >>>>>=20 >>>>>> On Feb 7, 2018, at 3:39 AM, Ori Finkelman wrote: >>>>>>=20 >>>>>> Dear Colleagues, >>>>>> Regarding the addition of a regular expression match for triggers, ma= inly for invalidation. >>>>>> What should be the regexp standard we use, PCRE ? POSIX BRE or ERE ? >>>>>> Does the type of regrexp need to be exchanged via the interface (trig= ger and capability) ? >>>>>>=20 >>>>>> Example 1: assuming we support only one specific type of regrex >>>>>>=20 >>>>>> {=20 >>>>>> "regex": "/^(https:\/\/video\.example\.com)\/([a-z])\/([1-7])\= /([\/\w \.-]*)*\/?$", =20 >>>>>> "case-sensitive": true >>>>>> } >>>>>>=20 >>>>>> Example 2: assuming regexp type is variable >>>>>>=20 >>>>>> {=20 >>>>>> "regex": "/^(https:\/\/video\.example\.com)\/([a-z])\/([1-7])\= /([\/\w \.-]*)*\/?$", =20 >>>>>> "case-sensitive": true >>>>>> "regrex-type": "pcre" >>>>>> } >>>>>>=20 >>>>>> Thanks, >>>>>> Ori >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> --=20 >>>>>> Ori Finkelman >>>>>> Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.= com >>>>>=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.co= m >>>=20 >>>=20 >>>=20 >>> --=20 >>> Ori Finkelman >>> Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com= >=20 >=20 >=20 > --=20 > Ori Finkelman > Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com --Apple-Mail-FD7D2045-B512-4315-885E-FED4147A0CDB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think it is up to the dCDN to interpret l= ocal time.  If the uCDN wants to use it's local time, it should specify= it in UTC.

The question that caused confusion, iirc, was= about trying to predict when a cache in a given region is going to be hit, a= nd I don't think that is a tractable problem.  The idea of saying "prep= osition X at time Y" is an assumption that Y is the optimal time to preposit= ion X (in the uCDN's opinion).  That assumption is based off an underly= ing assumption that the primetime load on the dCDN is not at time Y, but the= re's always going to be exceptions to that.  A cache in LA may serve us= ers in NY (or vice versa) and may not have hit the designated local time yet= ; it violates the assumption whether we use UTC or localtime, so I don't see= it as something for which we should design.

Sent from my iPhone

On Feb 27, 2018, at 4:23 AM, Ori Fi= nkelman <orif@qwilt.com> wrote:<= br>
Hi Kevin,
I= think the difficulty with local time is the interpretation of what to do wi= th it.
If it is a generic local time, then whose local time is it ?= the uCDN ? the dCDN ? per cache or region ?
OTHO if it is local t= ime plus time zone, then you need to provide them for each and every geo, so= it comes back the original question in my previous mail.

However, after reiteration this internally, I tend to agree it over c= omplicates things, and for now let's stick with a general time scope, stated= in UTC.
If ever an implementation will really need to have differ= ent times for different geos, they will be able to add a new object, for exa= mple GeoAndTime object that will state the required time per Geo, but this c= an be deferred for now.

Thanks,
Ori
=

On Tue, Feb 2= 7, 2018 at 7:53 AM, Kevin J. Ma <kevin.j.ma.ietf@gmail.com> wrote:
Hi Ori,
=
  (as an individual) I personally don't see any reason t= o combine time and geolocation; it over complicates things, imo.  I did= n't see a problem with providing a time without timezone to be interpreted a= s "local time".  I didn't think that being able to send a trigger that s= aid "do this at 1am local time" was a terribly difficult concept - it probab= ly just needs some textual clarification and a more precise definition of ho= w the json should be parsed and interpreted, to remove any UTC vs explicit t= imezone vs "local time" ambiguity?

thanx.

--  Kevin J. Ma

Sent from my iPhone
On Feb 26, 2018, at 7:03 AM, Ori Finkelman <orif@qwilt.com> wrote:

Dear all,
Another question regard= ing the trigger extensions.
It was suggested that in order to exec= ute a trigger (for example pre-position) in "local time" of each geography, o= ne should combine the geo location extension with the time window extension.=
For example, if pre-position should occur on 3AM local time, it w= ould be set for 11AM UTC for California , and 8AM UTC on New-York
= While this works logically, it means that the user needs to state for each r= elevant geography the UTC time for execution, instead of just stating the re= quired local time and let the dCDN handle it per geography.

My question is that given that we add trigger extensions, how would= be able to state such multiple cases.

Take the abo= ve example, I can see two alternatives :
1. Issue two separate tri= gger commands, one with Geo =3D CA, and time =3D 11AM UTC, and a second comm= and with Geo =3D NY and time =3D 8AM UTC.
     whil= e this works, it requires a separate command for each geo.

2. Wrap the extension objects with extension groups, such that each g= roup must be applied together. For example this trigger command will have tw= o extension groups, one with Geo=3DCA and Time=3D11AM UTC, and the other wit= h Geo=3DNY and time=3D8AM UTC.



<= /div>
I would love to get some feedback on this,


Thanks,
Ori



On Wed, Feb 7,= 2018 at 7:41 PM, Ori Finkelman <orif@qwilt.com> wrote:

I also prefer pcre only.


On Wed, Feb 7, 2018, 17:01 K= evin J. Ma <kevin.j.ma.ietf@gmail.com> wrote:
I would favor triggers matching uri signing, i.e., P= CRE only, to simplify interoperability requirements; unless there's a really= good reason implementers should have to support multiple standards?

=
Sent from my iPhone

= On Feb 7, 2018, at 3:39 AM, Ori Finkelman <orif@qwilt.com> wrote:

Dear Colleagues,
Regarding the addi= tion of a regular expression match for triggers, mainly for invalidation.
What should be the regexp standard we use, PCRE ? POSIX BRE or E= RE ?
Does the type of regrexp need to be exchanged via the interfa= ce (trigger and capability) ?

Example 1: assuming w= e support only one specific type of regrex

&nb= sp;   { 
       "regex": "/^(https:\= /\/video\.example\.com)\/([a-z])\/([1-7])\/([\/\w \.-]*)*\/?$",  &= nbsp; 
       "case-sensitive": true
    }

Example 2: assuming reg= exp type is variable

    { 
       "regex": "/^(https:\/\/video\.example\.com)\/([a-z])\/([1-7])\/([\/\w \.-]*)*\/?$",    
=        "case-sensitive": true
    &n= bsp;  "regrex-type": "pcre"
    }
<= br>
Thanks,
Ori


<= div>
--
Ori Finkelman
= Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com
_______________________________________________
CDN= i mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listi= nfo/cdni


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



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



--
= --Apple-Mail-FD7D2045-B512-4315-885E-FED4147A0CDB-- From nobody Wed Feb 28 01:57: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 E747412EAEC for ; Wed, 28 Feb 2018 01:56:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 DsoN-uNjBIYy for ; Wed, 28 Feb 2018 01:56:56 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 EF5781200B9 for ; Wed, 28 Feb 2018 01:56:55 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id i3so2445099wmi.4 for ; Wed, 28 Feb 2018 01:56:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qwilt-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pF3PAOPlTRucKEQ/R94HfE4q1PnQ6WGHhM63MbNTZUo=; b=Ki7W9Y44HZmuZkJFxNPrqTc4JwN2vGFr1qnj+S2swxBFo5ZAx8ZCnQotSbFD+Eupbr 6rNZYn+QGbJ5xVbG8rQf/20g8eqIXhUA6iNlcCi98MhkB/K/JilFW0Xmz93i6q9OCynD OuSskbVyp+V1SukKJIDQR2RGYkUdT4rEmPEjmIR14csKwEFNbNw+oKpFdhhXAR2NyEer PFjyE4eamGszZgCVG1PUiuUaDoXiiAF8ju+X88jQcCxG574C3nPOv6skykgNxT3s81kE KXo53wYHpEXiW1uvqYCQF4LXAPLBcC4EqFAQqeGo2RXRKI5bTn7JSqJe4gMfmf2UH6Bm IWAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pF3PAOPlTRucKEQ/R94HfE4q1PnQ6WGHhM63MbNTZUo=; b=hYYvTZWG275cBByfuxSgHy299EcxT3a9BfB25FM050JP/EL4TaSZzubUCmby2tN+sU 8AGnael95uYXm0vEp7Uq4I4u/WUvitYkcxhohGMC4I+21FvdIbNTAo/iUy6Uousn+5nr E5/FvkX9EymeaHNLqpG0PCHn/ZL6ymT8oVfDryltmfgBzS08khMN2zqZV2gmHz7hFGof pmQgUfDPzKcvfQRW/PblFRqsxvbUw7YL1qYFt/1VZ6/Mlm5F1514cIZdcQ8oUaU+DNbH 8oBMKC/Ra5CK7tGslRJfIRk4KNt5c+wIQSw88Kc9Ul6X6EKQBtZhj8QYQUB/02H0/Qxn TeWQ== X-Gm-Message-State: APf1xPD7C3I4+mISD5UwSPOUNr7A+n4y3ZVqj2RYW+5Z/xaFL5/75NAT ++7tif9soVhk6bduiOlH7dQ8M0x6FPpNi9WyGaMzQw== X-Google-Smtp-Source: AG47ELsvIfql1vMBV6Ip87hFdW8XQpR95sBwSyrU8qEjDDdOma7w8Eozqqjdd/QXzOD2QdsMnkx7+ACDMAMMXzg/v44= X-Received: by 10.28.216.82 with SMTP id p79mr14945437wmg.8.1519811814423; Wed, 28 Feb 2018 01:56:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.208.7 with HTTP; Wed, 28 Feb 2018 01:56:23 -0800 (PST) In-Reply-To: References: <816D33C2-C6C0-40C8-8160-8E38B521215E@gmail.com> From: Ori Finkelman Date: Wed, 28 Feb 2018 11:56:23 +0200 Message-ID: To: "Kevin J. Ma" Cc: "" Content-Type: multipart/alternative; boundary="001a11468e0253173a056642c357" Archived-At: Subject: Re: [CDNi] Triggers regexp: draft-finkelman-cdni-sva-extensions-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.22 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 Feb 2018 09:56:59 -0000 --001a11468e0253173a056642c357 Content-Type: text/plain; charset="UTF-8" Hi Kevin, I agree, it seems that what we were trying initially to solve it a very specific use case and may not be applicable to the general case. Therefore I am putting it aside for now and will only draft to option to set a time window in UTC. Thanks, Ori On Wed, Feb 28, 2018 at 12:58 AM, Kevin J. Ma wrote: > I think it is up to the dCDN to interpret local time. If the uCDN wants > to use it's local time, it should specify it in UTC. > > The question that caused confusion, iirc, was about trying to predict when > a cache in a given region is going to be hit, and I don't think that is a > tractable problem. The idea of saying "preposition X at time Y" is an > assumption that Y is the optimal time to preposition X (in the uCDN's > opinion). That assumption is based off an underlying assumption that the > primetime load on the dCDN is not at time Y, but there's always going to be > exceptions to that. A cache in LA may serve users in NY (or vice versa) > and may not have hit the designated local time yet; it violates the > assumption whether we use UTC or localtime, so I don't see it as something > for which we should design. > > Sent from my iPhone > > On Feb 27, 2018, at 4:23 AM, Ori Finkelman wrote: > > Hi Kevin, > I think the difficulty with local time is the interpretation of what to do > with it. > If it is a generic local time, then whose local time is it ? the uCDN ? > the dCDN ? per cache or region ? > OTHO if it is local time plus time zone, then you need to provide them for > each and every geo, so it comes back the original question in my previous > mail. > > However, after reiteration this internally, I tend to agree it over > complicates things, and for now let's stick with a general time scope, > stated in UTC. > If ever an implementation will really need to have different times for > different geos, they will be able to add a new object, for example > GeoAndTime object that will state the required time per Geo, but this can > be deferred for now. > > Thanks, > Ori > > On Tue, Feb 27, 2018 at 7:53 AM, Kevin J. Ma > wrote: > >> Hi Ori, >> >> (as an individual) I personally don't see any reason to combine time >> and geolocation; it over complicates things, imo. I didn't see a problem >> with providing a time without timezone to be interpreted as "local time". >> I didn't think that being able to send a trigger that said "do this at 1am >> local time" was a terribly difficult concept - it probably just needs some >> textual clarification and a more precise definition of how the json should >> be parsed and interpreted, to remove any UTC vs explicit timezone vs "local >> time" ambiguity? >> >> thanx. >> >> -- Kevin J. Ma >> >> Sent from my iPhone >> >> On Feb 26, 2018, at 7:03 AM, Ori Finkelman wrote: >> >> Dear all, >> Another question regarding the trigger extensions. >> It was suggested that in order to execute a trigger (for example >> pre-position) in "local time" of each geography, one should combine the geo >> location extension with the time window extension. >> For example, if pre-position should occur on 3AM local time, it would be >> set for 11AM UTC for California , and 8AM UTC on New-York >> While this works logically, it means that the user needs to state for >> each relevant geography the UTC time for execution, instead of just stating >> the required local time and let the dCDN handle it per geography. >> >> My question is that given that we add trigger extensions, how would be >> able to state such multiple cases. >> >> Take the above example, I can see two alternatives : >> 1. Issue two separate trigger commands, one with Geo = CA, and time = >> 11AM UTC, and a second command with Geo = NY and time = 8AM UTC. >> while this works, it requires a separate command for each geo. >> >> 2. Wrap the extension objects with extension groups, such that each group >> must be applied together. For example this trigger command will have two >> extension groups, one with Geo=CA and Time=11AM UTC, and the other with >> Geo=NY and time=8AM UTC. >> >> >> >> I would love to get some feedback on this, >> >> >> Thanks, >> Ori >> >> >> >> On Wed, Feb 7, 2018 at 7:41 PM, Ori Finkelman wrote: >> >>> I also prefer pcre only. >>> >>> On Wed, Feb 7, 2018, 17:01 Kevin J. Ma >>> wrote: >>> >>>> I would favor triggers matching uri signing, i.e., PCRE only, to >>>> simplify interoperability requirements; unless there's a really good reason >>>> implementers should have to support multiple standards? >>>> >>>> Sent from my iPhone >>>> >>>> On Feb 7, 2018, at 3:39 AM, Ori Finkelman wrote: >>>> >>>> Dear Colleagues, >>>> Regarding the addition of a regular expression match for triggers, >>>> mainly for invalidation. >>>> What should be the regexp standard we use, PCRE ? POSIX BRE or ERE ? >>>> Does the type of regrexp need to be exchanged via the interface >>>> (trigger and capability) ? >>>> >>>> Example 1: assuming we support only one specific type of regrex >>>> >>>> { >>>> "regex": "/^(https:\/\/video\.example\.com)\/([a-z])\/([1-7])\/([\/\w >>>> \.-]*)*\/?$", >>>> "case-sensitive": true >>>> } >>>> >>>> Example 2: assuming regexp type is variable >>>> >>>> { >>>> "regex": "/^(https:\/\/video\.example\.com)\/([a-z])\/([1-7])\/([\/\w >>>> \.-]*)*\/?$", >>>> "case-sensitive": true >>>> "regrex-type": "pcre" >>>> } >>>> >>>> Thanks, >>>> Ori >>>> >>>> >>>> >>>> -- >>>> >>>> *Ori Finkelman*Qwilt | Work: +972-72-2221647 <072-222-1647> | Mobile: >>>> +972-52-3832189 <052-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 <072-222-1647> | Mobile: >>> +972-52-3832189 <052-383-2189> | orif@qwilt.com >>> >> >> >> >> -- >> >> *Ori Finkelman*Qwilt | Work: +972-72-2221647 <072-222-1647> | Mobile: >> +972-52-3832189 <052-383-2189> | orif@qwilt.com >> >> > > > -- > > *Ori Finkelman*Qwilt | Work: +972-72-2221647 <072-222-1647> | Mobile: > +972-52-3832189 <052-383-2189> | orif@qwilt.com > > -- *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com --001a11468e0253173a056642c357 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Kevin,
I agree, it seems that what we were trying i= nitially to solve it a very specific use case and may not be applicable to = the general case. Therefore I am putting it aside for now and will only dra= ft to option to set a time window in UTC.

Thanks,<= /div>
Ori

On Wed, Feb 28, 2018 at 12:58 AM, Kevin J. Ma <= ;kevin.j.ma.= ietf@gmail.com> wrote:
I think it is up to the dCDN to interpret local time.=C2=A0 I= f the uCDN wants to use it's local time, it should specify it in UTC.
The question that caused confusion, iirc, was about tryin= g to predict when a cache in a given region is going to be hit, and I don&#= 39;t think that is a tractable problem.=C2=A0 The idea of saying "prep= osition X at time Y" is an assumption that Y is the optimal time to pr= eposition X (in the uCDN's opinion).=C2=A0 That assumption is based off= an underlying assumption that the primetime load on the dCDN is not at tim= e Y, but there's always going to be exceptions to that.=C2=A0 A cache i= n LA may serve users in NY (or vice versa) and may not have hit the designa= ted local time yet; it violates the assumption whether we use UTC or localt= ime, so I don't see it as something for which we should design.

=
Sent from my iPhone

On Feb 27, 2018, at 4:23 AM, Ori Finkelm= an <orif@qwilt.com> wrote:


On Tue, Feb 27, 2018 at 7:53 AM, Kevin J. Ma <kevin.j.ma.ietf@gmail.com> wrote:
Hi Ori,

=C2=A0 (as an individu= al) I personally don't see any reason to combine time and geolocation; = it over complicates things, imo.=C2=A0 I didn't see a problem with prov= iding a time without timezone to be interpreted as "local time".= =C2=A0 I didn't think that being able to send a trigger that said "= ;do this at 1am local time" was a terribly difficult concept - it prob= ably just needs some textual clarification and a more precise definition of= how the json should be parsed and interpreted, to remove any UTC vs explic= it timezone vs "local time" ambiguity?

t= hanx.

-- =C2=A0Kevin J. Ma

Sent from my iPho= ne

On Feb 26, 20= 18, at 7:03 AM, Ori Finkelman <orif@qwilt.com> wrote:

Dear all,
Another question regarding the tr= igger extensions.
It was suggested that in order to execute a tri= gger (for example pre-position) in "local time" of each geography= , one should combine the geo location extension with the time window extens= ion.
For example, if pre-position should occur on 3AM local time,= it would be set for 11AM UTC for California , and 8AM UTC on New-York
While this works logically, it means that the user needs to state for= each relevant geography the UTC time for execution, instead of just statin= g the required local time and let the dCDN handle it per geography.

My question is that given that we add trigger extensions,= how would be able to state such multiple cases.

T= ake the above example, I can see two alternatives :
1. Issue two = separate trigger commands, one with Geo =3D CA, and time =3D 11AM UTC, and = a second command with Geo =3D NY and time =3D 8AM UTC.
=C2=A0 =C2= =A0 =C2=A0while this works, it requires a separate command for each geo.

2. Wrap the extension objects with extension groups,= such that each group must be applied together. For example this trigger co= mmand will have two extension groups, one with Geo=3DCA and Time=3D11AM UTC= , and the other with Geo=3DNY and time=3D8AM UTC.

=

I would love to get some feedback on this,


Thanks,
Ori

<= /div>


On Wed, Feb 7, 2018 at 7:41 PM, Ori Finkelman &l= t;orif@qwilt.com>= ; wrote:

I also pre= fer pcre only.


On Wed, Feb 7, 2018, 17:01 = Kevin J. Ma <kevin.j.ma.ietf@gmail.com> wrote:
I would favor triggers matching uri signing, i.= e., PCRE only, to simplify interoperability requirements; unless there'= s a really good reason implementers should have to support multiple standar= ds?

Sent from my iPhone

On Feb 7, 2018, at 3:39 AM, Ori Finkelma= n <orif@qwilt.com> wrote:

D= ear Colleagues,
Regarding the addition of a regular expression match fo= r triggers, mainly for invalidation.
What should be the regexp st= andard we use,=C2=A0PCRE ? POSIX BRE or ERE ?
Does the type of re= grexp need to be exchanged via the interface (trigger and capability) ?

Example 1: assuming we support only one specific type= of regrex

=C2=A0 =C2=A0 {=C2=A0
= =C2=A0 =C2=A0 =C2=A0 =C2=A0"regex": "/^(https:\/\/video\.exa= mple\.com)\/([a-z])\/([1-7])\/([\/\w \.-]*)*\/?$",=C2=A0 =C2=A0= =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0"case-sensitive": tru= e
=C2=A0 =C2=A0 }

Example 2: assum= ing regexp type is variable

=C2=A0 =C2=A0 {= =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0"regex": "/^(htt= ps:\/\/video\.example\.com)\/([a-z])\/([1-7])\/([\/\w \.-]*)*\/?$"= ;,=C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0"case-sensi= tive": true
=C2=A0 =C2=A0 =C2=A0 =C2=A0"regrex-type&quo= t;: "pcre"
=C2=A0 =C2=A0 }

Thanks,
Ori
<= span>_______________________________________________
C= DNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni

--
Ori Finkelman
Qwilt | Wo= rk: = +972-72-2221647 | Mobile: +972-52-3832189 |=C2=A0orif@qwilt.com



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



--
Ori Finkelm= an
Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.co= m



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