From nobody Sat May 4 21:25:02 2019 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 6DA6D12008D for ; Sat, 4 May 2019 21:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gB7zkZoPigeZ for ; Sat, 4 May 2019 21:24:58 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52849120033 for ; Sat, 4 May 2019 21:24:58 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id d8so6884844lfb.8 for ; Sat, 04 May 2019 21:24:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=FhLOrDY9WlNtFZpYJYrHE/bUtThLIHzlVAPCABYhumk=; b=FHZOWMJny4dJuHAoUPPyAx+vx42eqUx3hRb7laxXwNBcLu+Z+HTE6lRsDyN7ubI87c 1QvIfBkfMEORt2WdBcGdj8n2/seAtNmlW1SqWJ/EMJXQJKBVTuWwDCIKEP+ksPmKnsjN uUxvvKv68bSSX8DZiGHW+/paz0SCMwJZI/AXvuixKYdP37Gb3Vfa9BVyATuQzPec+mVd q6sbQoqMGIL86klSyYPxiyg6s1emdD+dmEFuSqoFVXlUBLM78n6uGbPq7xWWnqAcAb2W SeOLAtDKGjVa/3KBBJF39KzzRVawXca5hs9nxDV1bmQrELZ6dCAZ2Feb1w63c8b5o/pX nuLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=FhLOrDY9WlNtFZpYJYrHE/bUtThLIHzlVAPCABYhumk=; b=DvP16SWgTg19DH08Go/vJCX/qKWQKVCSFBEN0SMpkyMrT4JCyTDkcAMgS7wC6v69C3 54Ht4+xndK7oBfCzuR5WtgE75MsGLGJUHiIL5DQONSEWsxFChYeCljyXsJy0YQ4oO4Wc pp5SeX7AZtbTMPnZwTPhDsvvw74I+RS4NF2X+NLEO3Vvy7gkDC5/JQy9lS4t+KtaF72M M8qzZL4nhK0v2gff3fkvKkasyqWC/pqK1YvPmQ6VPlib0gdoahe+YWAi9yuIEtITLEkJ yVQhYoIcGj4KWqRSQDcDQfZT9dheb2k+JvagjSNNXxTB889iZFgsmJ6w77xSxfSHI5Yr ISag== X-Gm-Message-State: APjAAAU1T+b62DM3ajUDiIBgJyiiqWP6LBY+Q9qJ0zsvdKBJnARdC3ha 8z7USARjNJ1OIeTj4U+O7OyIQ2FfCbvKsayoBcbZt++e X-Google-Smtp-Source: APXvYqyBT1YS5/TXO1WVTm6ikK0WdHqiV16apEolase6Wi5LvkmiVdZ6MqDjs+KYMbtKT5gMeFdnNoBMdSig7nOH2vA= X-Received: by 2002:ac2:55b5:: with SMTP id y21mr3688817lfg.84.1557030296152; Sat, 04 May 2019 21:24:56 -0700 (PDT) MIME-Version: 1.0 References: <155403318275.12273.17586391042919500029@ietfa.amsl.com> In-Reply-To: <155403318275.12273.17586391042919500029@ietfa.amsl.com> From: Kevin Ma Date: Sun, 5 May 2019 00:24:45 -0400 Message-ID: To: "" Content-Type: multipart/alternative; boundary="000000000000b4ee3e05881c5dfb" Archived-At: Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-request-routing-extensions-02.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2019 04:25:02 -0000 --000000000000b4ee3e05881c5dfb Content-Type: text/plain; charset="UTF-8" Hi All, (as chair) I added a milestone after the last IETF to get this draft submitted by June. I believe the contents are uncontroversial (though please speak up if you disagree), and the proposed metadata and capabilities submitted via WG draft are inline with the extensibility model we sought to achieve for the MI and FCI interfaces. To that end, as is our custom, I've done a pre-shepherd review. I encourage everyone to also give it a read and speak up if you have any thoughts or concerns, as we try to move it forward. Ori/Sanjay: Please find my comments below. thanx! -- Kevin J. Ma - section 2: - I would add a sentence before the property definitions (and possibly make it a subsection): "The Redirect Target capability object consists of the following three properties: - I would make the json example its own section, referenced from section 4.1.1 - I would add the http-target json from section 2.2 to this full example. - nits: ", for example" -> ", for example," or ", e.g.," ", for example" -> ", for example," or ", e.g.," ", or due to network problems" -> " or network problems" "Due to this variable" -> "Given the variable" ", and a more dynamic," -> ". A more dynamic" "may be using third party DNS resolver" -> "may be using a third party DNS resolver" "or it can be set" -> "or can be set" "Redirect Target Capability" -> "Redirect Target capability" "When dCDN is" -> "When a dCDN is" "one of these uCDN hosts" -> "one of those uCDN hosts" "DNS routers take routing decisions" -> "DNS routers make routing decisions" "URI to be used as a value of" -> "URI to be used as the value for" "Example of Redirect Target Capability object" -> "The following is an example of a Redirect Target capability object serialization" "Target address for DNS A record" -> "Target address for a DNS A record" "No. but" -> "No, but" "Target URI for HTTP redirect" -> "Target URI for a HTTP redirect" - section 2.1: - nits: "gives the instructions to construct the target address for the DNS response for delegation" -> "gives the target address for the DNS response to delegate" - section 2.2: - nits: "gives the instructions to construct the target Location URI for http redirection" -> "gives the necessary information to construct the target Location URI for HTTP redirection." ", i.e." -> ", i.e.," ", i.e." -> ", i.e.," "In case this flag is true" -> "If set to true" "In case this flag is true" -> "If set to true" - section 3: - I would add a sentence before the property definition (and possibly make it a subsection): "The MI.FallbackTarget Metadata object consists of the following single property: - I would make the json example its own section, referenced from section 4.1.2 - In the case of DNS redirect, would it be acceptable for the uCDN to advertise a host with a port, and say the dCDN must ignore/drop the port? or should there be two properties, one for DNS and one for HTTP, similar to Redirect Target? - nits: "requires that the uCDN should provide" -> "requires that the uCDN provide a" "to the dCDN to be used" -> "to the dCDN, to be used" "differnet than the original address at the uCDN" -> "different from the original uCDN address" "caches, or a client located outside" -> "caches or outside" "DNS redirection mode" -> "DNS redirection" "dCDN path-prefix and the uCDN host name" -> "dCDN path-prefix and/or the uCDN hostname" - section 4.1: "IANA CDNI Payload Type registry" -> "IANA \"CDNI Payload Types\" registry" - section 5: - I think you also need to add a "Privacy" section? On Sun, Mar 31, 2019 at 7:53 AM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Content Delivery Networks Interconnection > WG of the IETF. > > Title : CDNI Request Routing Extensions > Authors : Ori Finkelman > Sanjay Mishra > Filename : draft-ietf-cdni-request-routing-extensions-02.txt > Pages : 11 > Date : 2019-03-31 > > 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). > The extensions specified in this document to the CDNI Metadata and > FCI interfaces are derived from requirements raised by Open Caching > but are applicable to CDNI use cases in general. > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-cdni-request-routing-extensions/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-cdni-request-routing-extensions-02 > > https://datatracker.ietf.org/doc/html/draft-ietf-cdni-request-routing-extensions-02 > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-request-routing-extensions-02 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > --000000000000b4ee3e05881c5dfb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

=C2= =A0 (as chair) I added a milestone after the last IETF to get this draft su= bmitted by June.=C2=A0 I believe the contents are uncontroversial (though p= lease speak up if you disagree), and the proposed metadata and capabilities= submitted via WG draft are inline with the extensibility model we sought t= o achieve for the MI and FCI interfaces.

=C2=A0 To= that end, as is our custom, I've done a pre-shepherd review.=C2=A0 I e= ncourage everyone to also give it a read and speak up if you have any thoug= hts or concerns, as we try to move it forward.

Ori= /Sanjay:

=C2=A0 Please find my comments below.

thanx!

--=C2=A0 Kevin J. Ma<= /div>

- section 2:
=C2=A0 - I would add a= sentence before the property definitions (and possibly make it a subsectio= n): "The Redirect Target capability object consists of the following t= hree properties:
=C2=A0 - I would make the json example its own s= ection, referenced from section 4.1.1
=C2=A0 - I would add the ht= tp-target json from section 2.2 to this full example.
=C2=A0 - ni= ts:
=C2=A0 =C2=A0 ", for example" -> ", for exa= mple," or ", e.g.,"
=C2=A0 =C2=A0 ", for exam= ple" -> ", for example," or ", e.g.,"
=C2=A0 =C2=A0 ", or due to network problems" -> " or net= work problems"
=C2=A0 =C2=A0 "Due to this variable"= ; -> "Given the variable"
=C2=A0 =C2=A0 ", and = a more dynamic," -> ".=C2=A0 A more dynamic"
= =C2=A0 =C2=A0 "may be using third party DNS resolver" -> "= ;may be using a third party DNS resolver"
=C2=A0 =C2=A0 &quo= t;or it can be set" -> "or can be set"
=C2=A0 = =C2=A0 "Redirect Target Capability" -> "Redirect Target c= apability"
=C2=A0 =C2=A0 "When dCDN is" -> &quo= t;When a dCDN is"
=C2=A0 =C2=A0 "one of these uCDN host= s" -> "one of those uCDN hosts"
=C2=A0 =C2=A0 &= quot;DNS routers take routing decisions" -> "DNS routers make = routing decisions"
=C2=A0 =C2=A0 "URI to be used as a v= alue of" -> "URI to be used as the value for"
= =C2=A0 =C2=A0 "Example of Redirect Target Capability object" ->= ; "The following is an example of a Redirect Target capability object = serialization"
=C2=A0 =C2=A0 "Target address for DNS A = record" -> "Target address for a DNS A record"
= =C2=A0 =C2=A0 "No. but" -> "No, but"
=C2= =A0 =C2=A0 "Target URI for HTTP redirect" -> "Target URI = for a HTTP redirect"

- section 2.1:
=C2=A0 - nits:
=C2=A0 =C2=A0 "gives the instructions to con= struct the target address for the DNS response for delegation" -> &= quot;gives the target address for the DNS response to delegate"
<= div>
- section 2.2:
=C2=A0 - nits:
=C2=A0= =C2=A0 "gives the instructions to construct the target Location URI f= or http redirection" -> "gives the necessary information to co= nstruct the target Location URI for HTTP redirection."
=C2= =A0 =C2=A0 ", i.e." -> ", i.e.,"
=C2=A0 = =C2=A0 ", i.e." -> ", i.e.,"
=C2=A0 =C2=A0= "In case this flag is true" -> "If set to true"
=C2=A0 =C2=A0 "In case this flag is true" -> "If s= et to true"

- section 3:
=C2=A0 - I= would add a sentence before the property definition (and possibly make it = a subsection): "The MI.FallbackTarget Metadata object consists of the = following single property:
=C2=A0 - I would make the json example= its own section, referenced from section 4.1.2
=C2=A0 - In the c= ase of DNS redirect, would it be acceptable for the uCDN to advertise a hos= t with a port, and say the dCDN must ignore/drop the port?=C2=A0 or should = there be two properties, one for DNS and one for HTTP, similar to Redirect = Target?
=C2=A0 - nits:
=C2=A0 =C2=A0 "requires tha= t the uCDN should provide" -> "requires that the uCDN provide = a"
=C2=A0 =C2=A0 "to the dCDN to be used" -> &q= uot;to the dCDN, to be used"
=C2=A0 =C2=A0 "differnet t= han the original address at the uCDN" -> "different from the o= riginal uCDN address"
=C2=A0 =C2=A0 "caches, or a clien= t located outside" -> "caches or outside"
=C2= =A0 =C2=A0 "DNS redirection mode" -> "DNS redirection&quo= t;
=C2=A0 =C2=A0 "dCDN path-prefix and the uCDN host name&qu= ot; -> "dCDN path-prefix and/or the uCDN hostname"
<= br>
- section 4.1:
=C2=A0 "IANA CDNI Payload Type = registry" -> "IANA \"CDNI Payload Types\" registry&q= uot;

- section 5:
=C2=A0 - I think you a= lso need to add a "Privacy" section?

On Sun, = Mar 31, 2019 at 7:53 AM <int= ernet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Content Delivery Networks Interconnection = WG of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= CDNI Request Routing Extensions
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Ori = Finkelman
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Sanjay Mishra
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-cdni-request-routing-extensions-02.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 11
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2019-03-31

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).
=C2=A0 =C2=A0The extensions specified in this document to the CDNI Metadata= and
=C2=A0 =C2=A0FCI interfaces are derived from requirements raised by Open Ca= ching
=C2=A0 =C2=A0but are applicable to CDNI use cases in general.



The IETF datatracker status page for this draft is:
https://datatracker.ietf= .org/doc/draft-ietf-cdni-request-routing-extensions/

There are also htmlized versions available at:
https://tools.ietf.org/html= /draft-ietf-cdni-request-routing-extensions-02
https://datatrack= er.ietf.org/doc/html/draft-ietf-cdni-request-routing-extensions-02

A diff from the previous version is available at:
https://www.ietf.or= g/rfcdiff?url2=3Ddraft-ietf-cdni-request-routing-extensions-02


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni
--000000000000b4ee3e05881c5dfb-- From orifinkelman@gmail.com Sun May 5 01:50:17 2019 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 5F95612003F for ; Sun, 5 May 2019 01:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVL77OddVF-r for ; Sun, 5 May 2019 01:50:13 -0700 (PDT) Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 6F5C0120021 for ; Sun, 5 May 2019 01:50:13 -0700 (PDT) Received: by mail-vs1-xe34.google.com with SMTP id g187so6315626vsc.8 for ; Sun, 05 May 2019 01:50:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FSWQaNgdn9oY8HwxYNaiC4xLnnm1Cp0SljmFsNt2Luk=; b=NE3zchApA5l1L7EYybsQ5AcASSBQvfKbi+KLvT3SvvJd6mGmiqLU+IlVaxRmP+5C4x 3wSKrb4pbui2zEkla1rXbGVtWM7VAcYVeGZ51/pVWasg489y2hR5ZH4tIn95vCAxlxmt HPW5D3qkOz/53bapyb18uTNzYhGUGA1T0pPmsdOVONoTgViGMjH7zDiplh4uUG2te2xW 3KCsgeoZBdGK/MU02X2o48YVMsEUZCTC7sM+DaeMhopBc/wSsDYPXfZbqVJcOfvqwwTP YKAIW9Bd5nc/NzNRDD2B6zRLT/nm03GoKNJ46yfQU0MrLudpte4ZrCS0M3DvcZWoXJez Q/Lw== 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=FSWQaNgdn9oY8HwxYNaiC4xLnnm1Cp0SljmFsNt2Luk=; b=BJcawC6b/Fz4/4p8NEM44W2JpnooSqP67mwvdJmD7BIsH5hEj5Koyficg8ZtG48YPc 6bYNRRJv43Ehn//uBY90dKoHpLtkgn5ve4Yrc39jHgiPIRgT9Pe9GXNFVZahhaE2dbrM rf6nrmCOdnzO0H7Zq9QKdSbfrbhS+jyKUHYIGU3zokvFu7ZNSadZqw30DJPBsdBzFBo6 bqQhJZYZmprGKJT8qKwdKhPoxs46RfG32h++ibx5J/OO9yDxLNWMyG7TpvB97o/UjyhH BnuqXPpU/ss2hegomglFdnB7l6ZRrnobkmuceukZ5dQ7IXx8FLJ7LUad7tlVkMrvVeeA cW3A== X-Gm-Message-State: APjAAAUBfftpU6GQ8lbPMWnUZOPF8/usPIRBcN6bgmq8OoHxUPFlHBFu PpkJZuAr7wq16znInO2VJ9N//YZxPXleRjglRGY= X-Google-Smtp-Source: APXvYqype0IqzZSJwSPzVRulehKAPwoDBWUUBg8bo45HLygabbk11ARfs3qlNPkAZhKf/C748dzOuHHD+F1Wn3yEG+8= X-Received: by 2002:a67:c885:: with SMTP id v5mr10250284vsk.49.1557046212026; Sun, 05 May 2019 01:50:12 -0700 (PDT) MIME-Version: 1.0 References: <155403318275.12273.17586391042919500029@ietfa.amsl.com> In-Reply-To: From: "Ori Finkelman (IETF)" Date: Sun, 5 May 2019 11:49:55 +0300 Message-ID: To: Kevin Ma Cc: "" Content-Type: multipart/alternative; boundary="0000000000005def0705882012fe" Archived-At: Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-request-routing-extensions-02.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2019 11:50:42 -0000 --0000000000005def0705882012fe Content-Type: text/plain; charset="UTF-8" Thanks Kevin for the review and comments. I'll fix the draft accordingly and will wait for others to comment before submitting a fixed version. Best regards, Ori On Sun, May 5, 2019 at 7:25 AM Kevin Ma wrote: > Hi All, > > (as chair) I added a milestone after the last IETF to get this draft > submitted by June. I believe the contents are uncontroversial (though > please speak up if you disagree), and the proposed metadata and > capabilities submitted via WG draft are inline with the extensibility model > we sought to achieve for the MI and FCI interfaces. > > To that end, as is our custom, I've done a pre-shepherd review. I > encourage everyone to also give it a read and speak up if you have any > thoughts or concerns, as we try to move it forward. > > Ori/Sanjay: > > Please find my comments below. > > thanx! > > -- Kevin J. Ma > > - section 2: > - I would add a sentence before the property definitions (and possibly > make it a subsection): "The Redirect Target capability object consists of > the following three properties: > - I would make the json example its own section, referenced from section > 4.1.1 > - I would add the http-target json from section 2.2 to this full example. > - nits: > ", for example" -> ", for example," or ", e.g.," > ", for example" -> ", for example," or ", e.g.," > ", or due to network problems" -> " or network problems" > "Due to this variable" -> "Given the variable" > ", and a more dynamic," -> ". A more dynamic" > "may be using third party DNS resolver" -> "may be using a third party > DNS resolver" > "or it can be set" -> "or can be set" > "Redirect Target Capability" -> "Redirect Target capability" > "When dCDN is" -> "When a dCDN is" > "one of these uCDN hosts" -> "one of those uCDN hosts" > "DNS routers take routing decisions" -> "DNS routers make routing > decisions" > "URI to be used as a value of" -> "URI to be used as the value for" > "Example of Redirect Target Capability object" -> "The following is an > example of a Redirect Target capability object serialization" > "Target address for DNS A record" -> "Target address for a DNS A > record" > "No. but" -> "No, but" > "Target URI for HTTP redirect" -> "Target URI for a HTTP redirect" > > - section 2.1: > - nits: > "gives the instructions to construct the target address for the DNS > response for delegation" -> "gives the target address for the DNS response > to delegate" > > - section 2.2: > - nits: > "gives the instructions to construct the target Location URI for http > redirection" -> "gives the necessary information to construct the target > Location URI for HTTP redirection." > ", i.e." -> ", i.e.," > ", i.e." -> ", i.e.," > "In case this flag is true" -> "If set to true" > "In case this flag is true" -> "If set to true" > > - section 3: > - I would add a sentence before the property definition (and possibly > make it a subsection): "The MI.FallbackTarget Metadata object consists of > the following single property: > - I would make the json example its own section, referenced from section > 4.1.2 > - In the case of DNS redirect, would it be acceptable for the uCDN to > advertise a host with a port, and say the dCDN must ignore/drop the port? > or should there be two properties, one for DNS and one for HTTP, similar to > Redirect Target? > - nits: > "requires that the uCDN should provide" -> "requires that the uCDN > provide a" > "to the dCDN to be used" -> "to the dCDN, to be used" > "differnet than the original address at the uCDN" -> "different from > the original uCDN address" > "caches, or a client located outside" -> "caches or outside" > "DNS redirection mode" -> "DNS redirection" > "dCDN path-prefix and the uCDN host name" -> "dCDN path-prefix and/or > the uCDN hostname" > > - section 4.1: > "IANA CDNI Payload Type registry" -> "IANA \"CDNI Payload Types\" > registry" > > - section 5: > - I think you also need to add a "Privacy" section? > > > On Sun, Mar 31, 2019 at 7:53 AM wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Content Delivery Networks >> Interconnection WG of the IETF. >> >> Title : CDNI Request Routing Extensions >> Authors : Ori Finkelman >> Sanjay Mishra >> Filename : >> draft-ietf-cdni-request-routing-extensions-02.txt >> Pages : 11 >> Date : 2019-03-31 >> >> 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). >> The extensions specified in this document to the CDNI Metadata and >> FCI interfaces are derived from requirements raised by Open Caching >> but are applicable to CDNI use cases in general. >> >> >> >> The IETF datatracker status page for this draft is: >> >> https://datatracker.ietf..org/doc/draft-ietf-cdni-request-routing-extensions/ >> >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-cdni-request-routing-extensions-02 >> >> https://datatracker.ietf.org/doc/html/draft-ietf-cdni-request-routing-extensions-02 >> >> A diff from the previous version is available at: >> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-request-routing-extensions-02 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> 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 > --0000000000005def0705882012fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Kevin for the review and comments.=
I'll fix the draft accordingly and will wait for others to comment= before submitting a fixed=C2=A0version.

Best=C2= =A0regards,
Ori

On Sun, May 5, 2019 at 7:25 AM Kevin Ma <= kevin.j.ma.ietf@gmail.com&= gt; wrote:
Hi All,

=C2=A0 (= as chair) I added a milestone after the last IETF to get this draft submitt= ed by June.=C2=A0 I believe the contents are uncontroversial (though please= speak up if you disagree), and the proposed metadata and capabilities subm= itted via WG draft are inline with the extensibility model we sought to ach= ieve for the MI and FCI interfaces.

=C2=A0 To that= end, as is our custom, I've done a pre-shepherd review.=C2=A0 I encour= age everyone to also give it a read and speak up if you have any thoughts o= r concerns, as we try to move it forward.

Ori/Sanj= ay:

=C2=A0 Please find my comments below.

thanx!

--=C2=A0 Kevin J. Ma
=

- section 2:
=C2=A0 - I would add a sent= ence before the property definitions (and possibly make it a subsection): &= quot;The Redirect Target capability object consists of the following three = properties:
=C2=A0 - I would make the json example its own sectio= n, referenced from section 4.1.1
=C2=A0 - I would add the http-ta= rget json from section 2.2 to this full example.
=C2=A0 - nits:
=C2=A0 =C2=A0 ", for example" -> ", for example,= " or ", e.g.,"
=C2=A0 =C2=A0 ", for example&q= uot; -> ", for example," or ", e.g.,"
=C2= =A0 =C2=A0 ", or due to network problems" -> " or network= problems"
=C2=A0 =C2=A0 "Due to this variable" -&= gt; "Given the variable"
=C2=A0 =C2=A0 ", and a mo= re dynamic," -> ".=C2=A0 A more dynamic"
=C2=A0= =C2=A0 "may be using third party DNS resolver" -> "may b= e using a third party DNS resolver"
=C2=A0 =C2=A0 "or i= t can be set" -> "or can be set"
=C2=A0 =C2=A0 = "Redirect Target Capability" -> "Redirect Target capabili= ty"
=C2=A0 =C2=A0 "When dCDN is" -> "When = a dCDN is"
=C2=A0 =C2=A0 "one of these uCDN hosts"= -> "one of those uCDN hosts"
=C2=A0 =C2=A0 "DN= S routers take routing decisions" -> "DNS routers make routing= decisions"
=C2=A0 =C2=A0 "URI to be used as a value of= " -> "URI to be used as the value for"
=C2=A0 = =C2=A0 "Example of Redirect Target Capability object" -> "= ;The following is an example of a Redirect Target capability object seriali= zation"
=C2=A0 =C2=A0 "Target address for DNS A record&= quot; -> "Target address for a DNS A record"
=C2=A0 = =C2=A0 "No. but" -> "No, but"
=C2=A0 =C2= =A0 "Target URI for HTTP redirect" -> "Target URI for a H= TTP redirect"

- section 2.1:
=C2=A0= - nits:
=C2=A0 =C2=A0 "gives the instructions to construct = the target address for the DNS response for delegation" -> "gi= ves the target address for the DNS response to delegate"
- section 2.2:
=C2=A0 - nits:
=C2=A0 =C2=A0= "gives the instructions to construct the target Location URI for http= redirection" -> "gives the necessary information to construct= the target Location URI for HTTP redirection."
=C2=A0 =C2= =A0 ", i.e." -> ", i.e.,"
=C2=A0 =C2=A0 &q= uot;, i.e." -> ", i.e.,"
=C2=A0 =C2=A0 "In= case this flag is true" -> "If set to true"
= =C2=A0 =C2=A0 "In case this flag is true" -> "If set to t= rue"

- section 3:
=C2=A0 - I would = add a sentence before the property definition (and possibly make it a subse= ction): "The MI.FallbackTarget Metadata object consists of the followi= ng single property:
=C2=A0 - I would make the json example its ow= n section, referenced from section 4.1.2
=C2=A0 - In the case of = DNS redirect, would it be acceptable for the uCDN to advertise a host with = a port, and say the dCDN must ignore/drop the port?=C2=A0 or should there b= e two properties, one for DNS and one for HTTP, similar to Redirect Target?=
=C2=A0 - nits:
=C2=A0 =C2=A0 "requires that the u= CDN should provide" -> "requires that the uCDN provide a"=
=C2=A0 =C2=A0 "to the dCDN to be used" -> "to = the dCDN, to be used"
=C2=A0 =C2=A0 "differnet than the= original address at the uCDN" -> "different from the original= uCDN address"
=C2=A0 =C2=A0 "caches, or a client locat= ed outside" -> "caches or outside"
=C2=A0 =C2= =A0 "DNS redirection mode" -> "DNS redirection"
=C2=A0 =C2=A0 "dCDN path-prefix and the uCDN host name" -&g= t; "dCDN path-prefix and/or the uCDN hostname"

- section 4.1:
=C2=A0 "IANA CDNI Payload Type registr= y" -> "IANA \"CDNI Payload Types\" registry"

- section 5:
=C2=A0 - I think you also nee= d to add a "Privacy" section?


On Sun, Mar 31,= 2019 at 7:53 AM <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Content Delivery Networks Interconnection = WG of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= CDNI Request Routing Extensions
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Ori = Finkelman
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Sanjay Mishra
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-cdni-request-routing-extensions-02.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 11
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2019-03-31

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).
=C2=A0 =C2=A0The extensions specified in this document to the CDNI Metadata= and
=C2=A0 =C2=A0FCI interfaces are derived from requirements raised by Open Ca= ching
=C2=A0 =C2=A0but are applicable to CDNI use cases in general.



The IETF datatracker status page for this draft is:
https://datatracker.ietf= ..org/doc/draft-ietf-cdni-request-routing-extensions/

There are also htmlized versions available at:
https://tools.ietf.org/html= /draft-ietf-cdni-request-routing-extensions-02
https://datatrack= er.ietf.org/doc/html/draft-ietf-cdni-request-routing-extensions-02

A diff from the previous version is available at:
https://www.ietf.or= g/rfcdiff?url2=3Ddraft-ietf-cdni-request-routing-extensions-02


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
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
--0000000000005def0705882012fe-- From nobody Sun May 5 13:25:35 2019 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 551EB1200C1 for ; Sun, 5 May 2019 13:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mm4qibaWPG9t for ; Sun, 5 May 2019 13:25:32 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::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 C9993120020 for ; Sun, 5 May 2019 13:25:31 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id k8so9342182lja.8 for ; Sun, 05 May 2019 13:25:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eMfIF9WQ5AACMfrpXDQnyV+2sAqmQ42rqaM1fAygRwI=; b=MmvwCpwmQoH/FWGQpN9bggP5hk4nOsc+eJNYA9wvO9i9TXEXOk36nsTdvBFGjo6lcc 5S87IfSILNyW+lyCSiHH1HAOC+Q1IINJJVz1GfjQTP7x1eblBURQm7Qb+rWfDBZctW/d 9B4dK2qu6bHkHXYCJ3iyR/Z/hWxlJ8NfQmgYBh6mD4q1KOODGCKsoxbott8AmQ3a7+In ZwEeveyolS4gOo18nxc0HYdOu/6qJxWiVcjPOywii5ivya/JIA+tXC0gbbkCmuRtJXRT QLdtHW+nHTkNh4tEq1ATncPDxUE1aUeCWRpZDxZIl3ysDpWpPUJEF831MujrmBzhJHHd 1ykw== 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=eMfIF9WQ5AACMfrpXDQnyV+2sAqmQ42rqaM1fAygRwI=; b=MUakb8S/3/wvWSmt8y/rIYKppCeZc3ib+KpB+5FmPs8b70j8m+atK8VRVIlVpbcQFu WhkkkNciimdEP6+3ZArJEr4+JHlZjXdCtWOu8kU7A7lZvq9Xatgi0RG6JRAfqqjacZxf U/YO9Us0rWWEnju2Hg7rYPSARUbO9S6kYUWCQlqx9yhVySIrXhv1jxlxXeAeGgmWSyd+ FA9JBThXMGGp37UZmYs8+wryZR5Hzsy176ZTBzGqsfCDZPgE/3LojimxSYukQUIEdKpU fGJSnWNEkk89NPhI8yg5GcR8OMR5wmC19BcXLmW5aX2LNLPSknh89JlgwrvMsU5CZtUW dRfw== X-Gm-Message-State: APjAAAUS996tXFWx/7xug1ViX7stydu49KItzMykkVpZwEnpjoV5Tayn VtOOTllbyB3DJvEMZDT4MGtiPOaF3GV27zKop/s= X-Google-Smtp-Source: APXvYqyTqLxIZNShJAZ+7/iyAt3wDNf7ei4C2eanflJYzIZQxOHKnkjaweVljiNxJ2aIK9iedPrwm4UqW2PQyRWjmzY= X-Received: by 2002:a2e:8187:: with SMTP id e7mr11734216ljg.182.1557087930002; Sun, 05 May 2019 13:25:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kevin Ma Date: Sun, 5 May 2019 16:25:18 -0400 Message-ID: To: Phil Sorber Cc: "" Content-Type: multipart/alternative; boundary="000000000000f3b145058829c8eb" Archived-At: Subject: Re: [CDNi] Shepherd Review of URI Signing X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2019 20:25:34 -0000 --000000000000f3b145058829c8eb Content-Type: text/plain; charset="UTF-8" Hi Phil, I had two comments on the updated draft: - section 2.1.3: "It should be appropriately set to an identiy that the validating CDN understands itself to be capable of validating on behalf of. This may be the CSP identity, or any CDN in the chain and can also be modified as needed by any entity in the chain as long as they can generate a valid signature." -> "The claim should contain an identity on behalf of whom the CDN can verify the token (e.g., the CSP or any uCDN in the chain). A dCDN MAY modify claim as long it can generate a valid signature." ? - section 4.5: It would be nice if the 4xx errors matched up with the 2.1.xx section numbers. ;) Do we have any open issues left? or do we think we're close to trying another WGLC? thanx! -- Kevin J. Ma On Mon, Mar 11, 2019 at 7:17 PM Phil Sorber wrote: > Sorry for the delay. I've published version 17 that covers your review as > well as the items you put in this thread and a few other comments on the > list. Here is a link to the diff (not including your changes): > > https://github.com/PSUdaemon/URISigningSpec/pull/61/files > > Thanks. > > On Mon, Nov 12, 2018 at 10:36 PM Kevin Ma > wrote: > >> one additional question: >> >> - section 2.1.3: Is any CDN allowed to add/modify the audience claim? >> Can we add explicit text wrt who can/should modify the audience claim? >> >> On Tue, Nov 13, 2018 at 12:16 AM Kevin Ma >> wrote: >> >>> trying again: https://github.com/PSUdaemon/URISigningSpec/pull/60/files >>> >>> On Sun, Nov 11, 2018 at 11:25 PM Phil Sorber wrote: >>> >>>> Kevin, >>>> >>>> Your PR has been made against your own repo and not mine, thus I cannot >>>> merge it. Can you create a PR with it against my repo instead? >>>> >>>> Thanks. >>>> >>>> On Sat, Nov 10, 2018 at 10:39 PM Kevin Ma >>>> wrote: >>>> >>>>> Hi All, >>>>> >>>>> (As chair) As promised, I have performed a shepherd review of the >>>>> latest URI Signing draft. I have submitted a pull request addressing a >>>>> whole bunch of nits: >>>>> https://github.com/kjmietf/URISigningSpec/pull/2/files . Three >>>>> additional questions for the authors: >>>>> >>>>> - general: should RFC3986, RFC5952, RFC6265, and POSIX.1 be >>>>> normative references? They feel normative to me. >>>>> - section 2.1.10: do you want to add a reference for IPv4 address >>>>> notation? >>>>> - section 6.4: Are there any special instructions to the expert >>>>> reviewer? Need to remove the ed note. >>>>> >>>>> I think that the draft will be ready for WGLC once the above issues >>>>> are addressed. >>>>> >>>>> thanx! >>>>> >>>>> -- Kevin J. Ma >>>>> >>>>> _______________________________________________ >>>>> CDNi mailing list >>>>> CDNi@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>> >>>> --000000000000f3b145058829c8eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Phil,

=C2=A0 I had = two comments on the updated draft:

=C2=A0 - s= ection 2.1.3:
=C2=A0 =C2=A0 "It should be appropriately set = to an identiy that the validating CDN understands itself to be capable of v= alidating on behalf of.=C2=A0 This may be the CSP identity, or any CDN in t= he chain and can also be modified as needed by any entity in the chain as l= ong as they can generate a valid signature." -> "The claim sho= uld contain an identity on behalf of whom the CDN can verify the token (e.g= ., the CSP or any uCDN in the chain).=C2=A0 A dCDN MAY modify claim as long= it can generate a valid signature." ?

=C2=A0= - section 4.5:
=C2=A0 =C2=A0 It would be nice if the 4xx errors = matched up with the 2.1.xx section numbers.=C2=A0 ;)

=C2=A0 Do we have any open issues left?=C2=A0 or do we think we= 9;re close to trying another WGLC?

thanx!

--=C2=A0 Kevin J. Ma



On Mon, Mar 11, 2019 at 7:17 PM Phil Sorber <sorber@apache.org> wrote:
Sor= ry for the delay. I've published version 17 that covers your review as = well as the items you put in this thread and a few other comments on the li= st. Here is a link to the diff (not including your changes):

=

Thanks.

On Mon, Nov 12, = 2018 at 10:36 PM Kevin Ma <kevin.j.ma.ietf@gmail.com> wrote:
one additional = question:

- section 2.1.3: Is any CDN allowed to add/mod= ify the audience claim?=C2=A0 Can we add explicit text wrt who can/should m= odify the audience claim?

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

On Sun, Nov 11, 2018 at 11:25 PM Phil Sor= ber <sorber@apach= e.org> wrote:
Kevin,

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

Thanks= .

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

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

=C2=A0 - general: should RFC3986, RFC5952, RFC6265, and POSIX.1 be normat= ive references?=C2=A0 They feel normative to me.
=C2=A0 - section= 2.1.10: do you want to add a reference for IPv4 address notation?
=C2=A0 - section 6.4: Are there any special instructions to the expert re= viewer?=C2=A0 Need to remove the ed note.

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

thanx!

--=C2= =A0 Kevin J. Ma

_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni
--000000000000f3b145058829c8eb-- From nobody Sun May 5 13:26:37 2019 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 46E2312006E for ; Sun, 5 May 2019 13:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzsoR5Yw-zbC for ; Sun, 5 May 2019 13:26:34 -0700 (PDT) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::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 E2CB1120020 for ; Sun, 5 May 2019 13:26:33 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id f23so9384226ljc.0 for ; Sun, 05 May 2019 13:26:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nU3ZZlRO+WhlmZtvpNmsQNnCPGmRTsAlT7CLe5i+w/c=; b=XfxU3Qd2EzOHJlns5esmEzVkx0FvZe+RhwfQPbqxz9N5e1DPEWp31KgUhk7E6B/pjT qKuH44Sj/ZF5lFXM2xLsNpc5mHVEmB6bB5BxYtIWu/eZ54eOWVZICkzTuMgw+zydqNoC ARiOT3jsquSvPOY58OQttGgOmaGkXPZGuXzlBXosB8yPAGOYfpxAPoEv4yPCu76ykGJA TPsEulvDIidZxqo0Qlm+kHbuqVGfeWrA3wgpmiGygzZMT9yLagn2p+jfx0BhzicLOASE +rGoeaT/GupRNuNkGP9ipI3j6lxPVpotzjcOQtZJl9rPtElRd32GUd3Je12LOqUaN3Uj Bczg== 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=nU3ZZlRO+WhlmZtvpNmsQNnCPGmRTsAlT7CLe5i+w/c=; b=Q+eUqbcd5LK22//sz9mlUTWS/QRqomRM/dGoK8H0nQk721BlBXiol2qPgBXYss41pl QnSDTM2OUZLpPW9RB/dMFJUUrDXvDKEy2S1I+u2DBEuw+oGM7+/rFsThjaE5AS5mvvOc cYV02M13q+HtoHSEtapJdoFFovQ9Iyo8L3hUp1da90pLzR/MLdcvAvgymv7PlrQL648j PsjObRoT/jEQaNKbU3ZuNece3gODxY3o6ePvmSQGdR9v6IuJHBnVQcXZLn9EN8+gKs1g HeS1BvQ/a12OLJrkD4U2fxC8R/+eBiTkXEIRtjJBGGv+eaYhqtG/YoUOjwwETGfRfuTN OwVA== X-Gm-Message-State: APjAAAWwhec5fVPqIP/Vdi/ErB27hFw93eR4DpMRHp6Q3ok28hbHHh5K IBg3aRaI9GiEheegTr/I6gG6Y29lnUG8S2/hrSY= X-Google-Smtp-Source: APXvYqwlfbWsXU5g8U13Qzscm6HpihYWv2Fsy6J6XfVClhAg04X1cetKiIY4xz8yRDyGoM1HqaEGoeUN1Ql+tj72nHE= X-Received: by 2002:a2e:7503:: with SMTP id q3mr11365918ljc.190.1557087992169; Sun, 05 May 2019 13:26:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kevin Ma Date: Sun, 5 May 2019 16:26:20 -0400 Message-ID: To: Phil Sorber Cc: "" Content-Type: multipart/alternative; boundary="000000000000a849e9058829cce8" Archived-At: Subject: Re: [CDNi] Shepherd Review of URI Signing X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2019 20:26:36 -0000 --000000000000a849e9058829cce8 Content-Type: text/plain; charset="UTF-8" "modify claim" -> "modify this claim" On Sun, May 5, 2019 at 4:25 PM Kevin Ma wrote: > Hi Phil, > > I had two comments on the updated draft: > > - section 2.1.3: > "It should be appropriately set to an identiy that the validating CDN > understands itself to be capable of validating on behalf of. This may be > the CSP identity, or any CDN in the chain and can also be modified as > needed by any entity in the chain as long as they can generate a valid > signature." -> "The claim should contain an identity on behalf of whom the > CDN can verify the token (e.g., the CSP or any uCDN in the chain). A dCDN > MAY modify claim as long it can generate a valid signature." ? > > - section 4.5: > It would be nice if the 4xx errors matched up with the 2.1.xx section > numbers. ;) > > Do we have any open issues left? or do we think we're close to trying > another WGLC? > > thanx! > > -- Kevin J. Ma > > > > On Mon, Mar 11, 2019 at 7:17 PM Phil Sorber wrote: > >> Sorry for the delay. I've published version 17 that covers your review as >> well as the items you put in this thread and a few other comments on the >> list. Here is a link to the diff (not including your changes): >> >> https://github.com/PSUdaemon/URISigningSpec/pull/61/files >> >> Thanks. >> >> On Mon, Nov 12, 2018 at 10:36 PM Kevin Ma >> wrote: >> >>> one additional question: >>> >>> - section 2.1.3: Is any CDN allowed to add/modify the audience claim? >>> Can we add explicit text wrt who can/should modify the audience claim? >>> >>> On Tue, Nov 13, 2018 at 12:16 AM Kevin Ma >>> wrote: >>> >>>> trying again: https://github.com/PSUdaemon/URISigningSpec/pull/60/files >>>> >>>> On Sun, Nov 11, 2018 at 11:25 PM Phil Sorber wrote: >>>> >>>>> Kevin, >>>>> >>>>> Your PR has been made against your own repo and not mine, thus I >>>>> cannot merge it. Can you create a PR with it against my repo instead? >>>>> >>>>> Thanks. >>>>> >>>>> On Sat, Nov 10, 2018 at 10:39 PM Kevin Ma >>>>> wrote: >>>>> >>>>>> Hi All, >>>>>> >>>>>> (As chair) As promised, I have performed a shepherd review of the >>>>>> latest URI Signing draft. I have submitted a pull request addressing a >>>>>> whole bunch of nits: >>>>>> https://github.com/kjmietf/URISigningSpec/pull/2/files . Three >>>>>> additional questions for the authors: >>>>>> >>>>>> - general: should RFC3986, RFC5952, RFC6265, and POSIX.1 be >>>>>> normative references? They feel normative to me. >>>>>> - section 2.1.10: do you want to add a reference for IPv4 address >>>>>> notation? >>>>>> - section 6.4: Are there any special instructions to the expert >>>>>> reviewer? Need to remove the ed note. >>>>>> >>>>>> I think that the draft will be ready for WGLC once the above issues >>>>>> are addressed. >>>>>> >>>>>> thanx! >>>>>> >>>>>> -- Kevin J. Ma >>>>>> >>>>>> _______________________________________________ >>>>>> CDNi mailing list >>>>>> CDNi@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>>> >>>>> --000000000000a849e9058829cce8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
"modify claim" -> "modify this claim&quo= t;

On Sun, May 5, 2019 at 4:25 PM Kevin Ma <kevin.j.ma.ietf@gmail.com> wrote:
= Hi Phil,

=C2=A0 I had two comments on the updated draft:=

=C2=A0 - section 2.1.3:
=C2=A0 =C2= =A0 "It should be appropriately set to an identiy that the validating = CDN understands itself to be capable of validating on behalf of.=C2=A0 This= may be the CSP identity, or any CDN in the chain and can also be modified = as needed by any entity in the chain as long as they can generate a valid s= ignature." -> "The claim should contain an identity on behalf = of whom the CDN can verify the token (e.g., the CSP or any uCDN in the chai= n).=C2=A0 A dCDN MAY modify claim as long it can generate a valid signature= ." ?

=C2=A0 - section 4.5:
=C2=A0 = =C2=A0 It would be nice if the 4xx errors matched up with the 2.1.xx sectio= n numbers.=C2=A0 ;)

=C2=A0 Do we have any op= en issues left?=C2=A0 or do we think we're close to trying another WGLC= ?

thanx!

--=C2=A0 Kevin J= . Ma



On Mon, Mar 11, 2019 at 7:17 = PM Phil Sorber <s= orber@apache.org> wrote:
Sorry for the delay.= I've published version 17 that covers your review as well as the items= you put in this thread and a few other comments on the list. Here is a lin= k to the diff (not including your changes):

<= div>
Thanks.

On Mon, Nov 12, 2018 at 10:36 PM = Kevin Ma <kevin.j.ma.ietf@gmail.com> wrote:
one additional question:
- section 2.1.3: Is any CDN allowed to add/modify the audience = claim?=C2=A0 Can we add explicit text wrt who can/should modify the audienc= e claim?

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

=
On Sun, Nov 11, 2018 at 11:25 PM Phil Sorber <sorber@apache.org> w= rote:
Kevin,

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

Thanks.

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

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

=C2=A0 - ge= neral: should RFC3986, RFC5952, RFC6265, and POSIX.1 be normative reference= s?=C2=A0 They feel normative to me.
=C2=A0 - section 2.1.10: do y= ou want to add a reference for IPv4 address notation?
=C2=A0 - se= ction 6.4: Are there any special instructions to the expert reviewer?=C2=A0= Need to remove the ed note.

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

thanx!

--=C2=A0 Kevin J. Ma=

_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni
--000000000000a849e9058829cce8-- From nobody Tue May 7 08:33:48 2019 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 EC3F5120144; Tue, 7 May 2019 08:33:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cdni@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cdni@ietf.org Message-ID: <155724322190.21157.15814043033080782950@ietfa.amsl.com> Date: Tue, 07 May 2019 08:33:41 -0700 Archived-At: Subject: [CDNi] I-D Action: draft-ietf-cdni-uri-signing-18.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 15:33:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Content Delivery Networks Interconnection WG of the IETF. Title : URI Signing for CDN Interconnection (CDNI) Authors : Ray van Brandenburg Kent Leung Phil Sorber Filename : draft-ietf-cdni-uri-signing-18.txt Pages : 40 Date : 2019-05-07 Abstract: This document describes how the concept of URI signing supports the content access control requirements of CDNI and proposes a URI signing method as a JSON Web Token (JWT) profile. The proposed URI signing method specifies the information needed to be included in the URI to transmit the signed JWT, as well as the claims needed by the signed JWT to authorize a UA. The mechanism described can be used both in CDNI and single CDN scenarios. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-uri-signing/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cdni-uri-signing-18 https://datatracker.ietf.org/doc/html/draft-ietf-cdni-uri-signing-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-uri-signing-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 21 01:00:52 2019 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 B1C4E120021; Tue, 21 May 2019 01:00:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cdni@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cdni@ietf.org Message-ID: <155842565063.2604.8106271563190765812@ietfa.amsl.com> Date: Tue, 21 May 2019 01:00:50 -0700 Archived-At: Subject: [CDNi] I-D Action: draft-ietf-cdni-request-routing-extensions-03.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2019 08:00:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Content Delivery Networks Interconnection WG of the IETF. Title : CDNI Request Routing Extensions Authors : Ori Finkelman Sanjay Mishra Filename : draft-ietf-cdni-request-routing-extensions-03.txt Pages : 12 Date : 2019-05-21 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). The extensions specified in this document to the CDNI Metadata and FCI interfaces are derived from requirements raised by Open Caching but are applicable to CDNI use cases in general. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-request-routing-extensions/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cdni-request-routing-extensions-03 https://datatracker.ietf.org/doc/html/draft-ietf-cdni-request-routing-extensions-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-request-routing-extensions-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 29 02:01:48 2019 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 9936E1200F6; Wed, 29 May 2019 02:01:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cdni@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cdni@ietf.org Message-ID: <155912050052.5493.11494878505192985990@ietfa.amsl.com> Date: Wed, 29 May 2019 02:01:40 -0700 Archived-At: Subject: [CDNi] I-D Action: draft-ietf-cdni-interfaces-https-delegation-01.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2019 09:01:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Content Delivery Networks Interconnection WG of the IETF. Title : CDNI extensions for HTTPS delegation Authors : Frederic Fieau Emile Stephan Sanjay Mishra Filename : draft-ietf-cdni-interfaces-https-delegation-01.txt Pages : 9 Date : 2019-05-29 Abstract: The delivery of content over HTTPS involving multiple CDNs raises credential management issues. This document proposes extensions in CDNI Control and Metadata interfaces to setup HTTPS delegation from an Upstream CDN (uCDN) to a Downstream CDN (dCDN). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-interfaces-https-delegation/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cdni-interfaces-https-delegation-01 https://datatracker.ietf.org/doc/html/draft-ietf-cdni-interfaces-https-delegation-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-interfaces-https-delegation-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/