From nobody Sun Jan 5 11:42:15 2020 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 D674F120088; Sun, 5 Jan 2020 11:42:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.755 X-Spam-Level: X-Spam-Status: No, score=-0.755 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, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, SPF_HELO_NONE=0.001, 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 glPJfEE9d33a; Sun, 5 Jan 2020 11:42:06 -0800 (PST) Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (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 4713B120033; Sun, 5 Jan 2020 11:42:06 -0800 (PST) Received: by mail-qv1-xf2f.google.com with SMTP id p2so18225425qvo.10; Sun, 05 Jan 2020 11:42:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XWBD0KESXsXeqTCCURntZKBQLMzv3rXJB2pc583ekUs=; b=XNMUF/y9HquK27jUPFaG/tvRG5srULUFbKBP6a5HHxb/TiyawUeP41C6lbB8Hg1wIe DkM13h/5JyETRrrHfwcN+A65lvycMZ96iWEzn+zYCwGKw0NE8vwnGQGcXi8/KnSzej2E LWsLsCDhxokfcQH/C3YomymDpZFhEE1JnuPJzSh9wjSrJci3/ggpGx6+IHKF+fhMHG6Z p5Bk23ZIrJLmRuHfXCm3TdNk+NL/ZOVolW7LrQ3ArbgGHe50Bz0Bk3RNQtINhxc2bjTF 09IrAboeawZAy2Jf0Z1iwZS34fQdwtPTDHeSwRUNT0z/GdnRCgnwCdgfZdalC03RWoiB v4gA== 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=XWBD0KESXsXeqTCCURntZKBQLMzv3rXJB2pc583ekUs=; b=ILsc9Xg+1v+a/i+JHULwx/Lgx774Ny2K8rdy5TNZD8X3bCr4dZOvVpcvOvF1yzOLqz G/pPzHtZCMY/2dHO1juU3eBrjrKQVtnq3z9ckh1qii5+/ta8VIkIIxvcmzANW0ZGS0So xeJ2GNmWs6htY/TC2hTQltB6ooo+ZMIPeONhbl2MtWklFPKtXDu01yU1XTWR5DFqL2Fx JW5SFDO++3MMUEgIEhpQdpFs2S+4JqqZraRd4Luyq99nXaNS4h5oa1f8+wxPfXtBS+mh wEeGYu4BMCqO1gXejIVpdDIz3wgLKKWY5CmPaf2t78ACd7VCPeMkZ2CjfLUSszmD3iTl PQ5Q== X-Gm-Message-State: APjAAAXx1qthgKe7ceMGHfsuRzZD8mIA/J8qMNtAuC+KbjvYv1xXnlV8 Scbi+Z62z4fiLUXzEX3G/cU7pGR4tSAdrUZKRVo= X-Google-Smtp-Source: APXvYqxGUlzz1g/0K20ylY7xjQQIXKfF59WWHl/51XbIbcpJtzWhQp6q9L7EY64Z1uJIAmNay0BTdrCBGmGuTAtqWZg= X-Received: by 2002:a05:6214:1348:: with SMTP id b8mr76537644qvw.137.1578253325255; Sun, 05 Jan 2020 11:42:05 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Kevin Ma Date: Sun, 5 Jan 2020 14:41:54 -0500 Message-ID: To: Jan Seedorf Cc: "cdni@ietf.org" , IETF ALTO , Vijay Gurbani , Francois Le Faucheur , Phil Sorber Content-Type: multipart/alternative; boundary="000000000000d14972059b69bccf" Archived-At: Subject: Re: [CDNi] Finalizing draft-ietf-alto-cdni-request-routing-alto 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 Jan 2020 19:42:09 -0000 --000000000000d14972059b69bccf Content-Type: text/plain; charset="UTF-8" Hi Jan, Sorry for the delayed response. My comments as a co-author and CDNI reviewer are below. Sanjay Mishra has also volunteered to provide an independent CDNI review. thanx! -- Kevin J. Ma - section 3.7.1: "one CDNI FCI resource depending on a network map, one filtered CDNI FCI resource to be defined in Section 5," -> "one filtered CDNI FCI resource to be defined in Section 5, one CDNI FCI resource depending on a network map," or change the order in the json example why do the filtered-cdnifci-property-map countrycode and asn capabilities not have my-default-network-map.pid properties? in update-my-cdni-fci, for the my-filtered-cdnifci capability, ""application/merge-patch+jso" should be ""application/merge-patch+json" - section 3.7.3: is this intended to be a continuation of the example in 3.7.2? if so, should "http/2" be in the 3.7.2 example, if it's being removed in 3.7.3? specifically, should "http/2" be "https/1.1" in 3.7.3? in the footprint example, should the "value": "ipv4:192.0.2.0/24" be a footprint object, i.e., "{ "footprint-type": "ipv4", "footprint-value": [" 192.0.2.0/24"] } ? (same comment applies to the example in 5.7.3) when adding a new ipv4 footprint, does this assume that there was not previously an ipv4 footprint defined? if there was a previously defined ipv4 footprint, the update should change the footprint-value array in the ipv4 footprint structure? - section 6.2.4: the update of "ipv4:192.0.2.0/24" delivery protocol from "http/1.1" to "http/1.1" doesn't actually change anything? - section 7.1: should probably add some text asking IANA to add the entry to the "CDNI Metadata Footprint Types" registry, and add a link to its definition in section 4.1. - authors: probably should change my email to: kevin.j.ma.ietf@gmail.com and remove my Ericsson affiliation? nits: - section 1: "On a high level" -> "At a high level" "; (2) redirecting" -> "; and (2) redirecting" "; (2) CDNI" -> "; and (2) CDNI" "are already in [RFC8008]" -> "are already defined in [RFC8008]" - section 2.1: "look like" -> "look" "asn and countrycode" -> "asn, and countrycode" "a /32 for IPv4 and a /128 for IPv6" -> "a /32 for IPv4 or a /128 for IPv6" "; (5) Capabilities" -> "; and (5) Capabilities" - section 2.2: "have difficulty to measure" -> "have difficulty measuring" "downstream CDN" -> "dCDN" "QoS" -> "quality of service" ? "cost map from dCDN" -> "cost map from the dCDN" "therefore redirect requests to dCDN" -> "redirect requests to a dCDN" "an upstream CDN" -> "a uCDN" "e.g. " -> "e.g., " - section 3.5: "The future documents" -> "Future documents" - section 3.7.2: "delivery protocol and https/1.1" -> "delivery protocol, and https/1.1" - section 5: "constrains" -> "constraints" "only if the entry contains at least one of the client given capabilities will it be returned to the client" -> "an entry will only be returned to the client if it contains at least one of the client given capabilities" - section 5.7.2: "only http/1.1 delivery protocol" -> "only the http/1.1 delivery protocol" - section 7.2/7.3: remove "Besides, " - section 8: "to run out of" -> "to unnecessarily consume" "above well. However," -> " above, however," "should not have to served by" -> "should not have to be served by" "dCDN and it may not disclose" -> "dCDN; and it SHOULD not disclose" "a dCDN may consider" -> "a dCDN could consider" "And it needs to avoid expoing" -> "A dCDN SHOULD avoid exposing" On Thu, Dec 5, 2019 at 11:29 AM Jan Seedorf wrote: > Dear CDNI chairs and CDNI WG, > > the ALTO WG is finalizing "Content Delivery Network Interconnection > (CDNI) Request Routing: CDNI Footprint and Capabilities Advertisement > using ALTO" (draft-ietf-alto-cdni-request-routing-alto-08). For the WGLC > we are about to issue, we would like to have one individual review from > a CDNI expert (the other one coming from the ALTO WG). Can you please > name/choose/recommend a CDNI expert that can provide an individual > review for the draft? We (ALTO chairs) would then start the WGLC ... > > Thanks, > > Kind regards, > > Jan > > > --000000000000d14972059b69bccf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jan,

=C2=A0 Sorry for the delayed re= sponse.=C2=A0 My comments as a co-author and CDNI reviewer are below.=C2=A0= Sanjay Mishra has also volunteered to provide an independent CDNI review.<= /div>

thanx!

--=C2=A0 Kevin J. = Ma

- section 3.7.1:
=C2=A0 "one CDNI = FCI resource depending on a network map, one filtered CDNI FCI resource to = be defined in Section 5," -> "one filtered CDNI FCI resource t= o be defined in Section 5, one CDNI FCI resource depending on a network map= ," =C2=A0or change the order in the json example

=C2=A0 why do = the filtered-cdnifci-property-map countrycode and asn capabilities not have= my-default-network-map.pid properties?

=C2=A0 in update-my-cdni-fci= , for the my-filtered-cdnifci capability, ""application/merge-pat= ch+jso" should be ""application/merge-patch+json"
- section 3.7.3:
=C2=A0 is this intended to be a continuation of the e= xample in 3.7.2? =C2=A0if so, should "http/2" be in the 3.7.2 exa= mple, if it's being removed in 3.7.3? =C2=A0specifically, should "= http/2" be "https/1.1" in 3.7.3?

=C2=A0 in the footpr= int example, should the "value": "ipv4:192.0.2.0/24" be a footprint object, = i.e., "{ "footprint-type": "ipv4", "footprint= -value": ["192.= 0.2.0/24"] } ? =C2=A0(same comment applies to the example in 5.7.3= )

=C2=A0 when adding a new ipv4 footprint, does this assume that the= re was not previously an ipv4 footprint defined? =C2=A0if there was a previ= ously defined ipv4 footprint, the update should change the footprint-value = array in the ipv4 footprint structure?

- section 6.2.4:
=C2=A0 th= e update of "ipv4:19= 2.0.2.0/24" delivery protocol from "http/1.1" to "h= ttp/1.1" doesn't actually change anything?

- section 7.1:=C2=A0 should probably add some text asking IANA to add the entry to the = "CDNI Metadata Footprint Types" registry, and add a link to its d= efinition in section 4.1.

- authors:
=C2=A0 probably should chang= e my email to:=C2=A0kevin.j.ma.ietf@gmail.com=C2=A0and remove my Ericsson affiliati= on?

nits:

- section 1:
=C2=A0 "On a high level" = -> "At a high level"
=C2=A0 "; (2) redirecting" -= > "; and (2) redirecting"
=C2=A0 "; (2) CDNI" -&g= t; "; and (2) CDNI"
=C2=A0 "are already in [RFC8008]"= ; -> "are already defined in [RFC8008]"

- section 2.1:<= br>=C2=A0 "look like" -> "look"
=C2=A0 "asn = and countrycode" -> "asn, and countrycode"
=C2=A0 &quo= t;a /32 for IPv4 and a /128 for IPv6" -> "a /32 for IPv4 or a = /128 for IPv6"
=C2=A0 "; (5) Capabilities" -> "; = and (5) Capabilities"

- section 2.2:
=C2=A0 "have diffi= culty to measure" -> "have difficulty measuring"
=C2= =A0 "downstream CDN" -> "dCDN"
=C2=A0 "QoS&q= uot; -> "quality of service" ?
=C2=A0 "cost map from d= CDN" -> "cost map from the dCDN"
=C2=A0 "therefor= e redirect requests to dCDN" -> "redirect requests to a dCDN&q= uot;
=C2=A0 "an upstream CDN" -> "a uCDN"
=C2= =A0 "e.g. " -> "e.g., "

- section 3.5:
=C2= =A0 "The future documents" -> "Future documents"
=
- section 3.7.2:
=C2=A0 "delivery protocol and https/1.1" = -> "delivery protocol, and https/1.1"

- section 5:
= =C2=A0 "constrains" -> "constraints"
=C2=A0 "= ;only if the entry contains at least one of the client given capabilities w= ill it be returned to the client" -> "an entry will only be re= turned to the client if it contains at least one of the client given capabi= lities"

- section 5.7.2:
=C2=A0 "only http/1.1 delivery= protocol" -> "only the http/1.1 delivery protocol"
- section 7.2/7.3:
=C2=A0 remove "Besides, "

- sectio= n 8:
=C2=A0 "to run out of" -> "to unnecessarily consu= me"
=C2=A0 "above well.=C2=A0 However," -> " abov= e, however,"
=C2=A0 "should not have to served by" -> = "should not have to be served by"
=C2=A0 "dCDN and it may= not disclose" -> "dCDN; and it SHOULD not disclose"
= =C2=A0 "a dCDN may consider" -> "a dCDN could consider&qu= ot;
=C2=A0 "And it needs to avoid expoing" -> "A dCDN = SHOULD avoid exposing"

On Thu, Dec 5, 2019 at 11= :29 AM Jan Seedorf <ietf@j-f-s.de&g= t; wrote:
Dear C= DNI chairs and CDNI WG,

the ALTO WG is finalizing "Content Delivery Network Interconnection (CDNI) Request Routing: CDNI Footprint and Capabilities Advertisement
using ALTO" (draft-ietf-alto-cdni-request-routing-alto-08). For the WG= LC
we are about to issue, we would like to have one individual review from a CDNI expert (the other one coming from the ALTO WG). Can you please
name/choose/recommend a CDNI expert that can provide an individual
review for the draft? We (ALTO chairs) would then start the WGLC ...

Thanks,

Kind regards,

Jan


--000000000000d14972059b69bccf-- From nobody Wed Jan 8 06:10:15 2020 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 BDC2A120821; Wed, 8 Jan 2020 06:10:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.246 X-Spam-Level: X-Spam-Status: No, score=0.246 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 9Yh2lF-Itlma; Wed, 8 Jan 2020 06:10:00 -0800 (PST) Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) (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 2CF5C120127; Wed, 8 Jan 2020 06:10:00 -0800 (PST) Received: by mail-yb1-xb2e.google.com with SMTP id f136so1480459ybg.11; Wed, 08 Jan 2020 06:10:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zmnVjQWMR0uQbkPkzZwevMGxfSiXUfPtWlq9Vp9QnAY=; b=fCRReh3GBNhksIXEj5oRWkJ5N4gCpWwlGR31YRv8jMFn9Wb4+EU/bTqbykuVBHyg4Y +UlHA0QHK1OZaU+kejj86sw6vbXzzM3mebiEpyW656508Rm98Q0qERTgnUVHhP7aBxZe 6N1tOXGSLaHocFNuscnxMYSpb9iPYhgnvzgbXF3KxcGD/lCk5EzdTnP5NQ96Qc9J2MIp q8nP07rLVN8n/xwt1wadMidAOGU7hzI10oX5EVy+7tvyYBFU6DhaS7ErOayJ7kBf+34U 7wO3UAJXxYyb7hxUkVB2LvuqPIPYvs3xpdLaZIDCEly8v8pjrKV7hGPNRAgGaSXPQc6C 27IA== 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=zmnVjQWMR0uQbkPkzZwevMGxfSiXUfPtWlq9Vp9QnAY=; b=pjVXO6aci9z/CGlYlPanHAT507Xx32SKhQ4U3JRDCEp911fBve9jLgF2gUjEx3l0yP ZfTEsGhmUaDejrzsdzkqftHx3aTrIr4mBgCl6AGEZO3bHH6RqpLeSVf7a3P6mGagpR8/ v/d9Ix5ZjerPTHTXlsGb2O+PezFZMODL+43JoU+gdC8dtctLlErN1SGD7mVa0LVXYfoC 9XN0BqO/qZ+NGXwdOehsrvdXNMidHoMOPTDuw2hKHWGi12y/v2weBU6vjZdRq17OutNW mYehWnAhc0N7gg9LbLpELRWKWGp+Dr1YMDEdfI/K2fU423jIslC9jo17zQkdb1UFG++e jOpg== X-Gm-Message-State: APjAAAWwmllmt4GFVbDALd4BLfUd+J+kVHtMhW9Kvij8cnCq72jft+9G NFXddYhCTA0ccfcplIbfySNePhQXo8plZsaXWzf7T4U9 X-Google-Smtp-Source: APXvYqw+dQ1vkidNGz5GmSc9mW2Pj09cdcCXFQ0JedBnFtAMAXbYmb1NJyrtQ9w2raqSvNhyyE2N1GWNPguN+MsRpVw= X-Received: by 2002:a25:d109:: with SMTP id i9mr3410607ybg.46.1578492599203; Wed, 08 Jan 2020 06:09:59 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jensen Zhang Date: Wed, 8 Jan 2020 09:09:49 -0500 Message-ID: To: Kevin Ma Cc: Jan Seedorf , "cdni@ietf.org" , IETF ALTO , Phil Sorber , Francois Le Faucheur Content-Type: multipart/alternative; boundary="000000000000a7fb42059ba17298" Archived-At: Subject: Re: [CDNi] [alto] Finalizing draft-ietf-alto-cdni-request-routing-alto X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 14:10:09 -0000 --000000000000a7fb42059ba17298 Content-Type: text/plain; charset="UTF-8" Hi Kevin and Sanjay, Thank you so much for the reviews. Please see my comments inline. On Sun, Jan 5, 2020 at 2:42 PM Kevin Ma wrote: > Hi Jan, > > Sorry for the delayed response. My comments as a co-author and CDNI > reviewer are below. Sanjay Mishra has also volunteered to provide an > independent CDNI review. > > thanx! > > -- Kevin J. Ma > > - section 3.7.1: > "one CDNI FCI resource depending on a network map, one filtered CDNI FCI > resource to be defined in Section 5," -> "one filtered CDNI FCI resource to > be defined in Section 5, one CDNI FCI resource depending on a network map," > or change the order in the json example > Thanks for catching it! Fixed. > > why do the filtered-cdnifci-property-map countrycode and asn > capabilities not have my-default-network-map.pid properties? > It is not reasonable to define my-default-network-map.pid properties of countrycode or asn entities. In the base ALTO protocol (RFC7285), a PID is defined as an aggregation of endpoint addresses. So in this example, this ALTO server does not allow any client to request such mappings from the filtered-cdnifci-property-map resource. > > in update-my-cdni-fci, for the my-filtered-cdnifci capability, > ""application/merge-patch+jso" should be ""application/merge-patch+json" > Fixed. Thanks! > > - section 3.7.3: > is this intended to be a continuation of the example in 3.7.2? if so, > should "http/2" be in the 3.7.2 example, if it's being removed in 3.7.3? > specifically, should "http/2" be "https/1.1" in 3.7.3? > Good point! The examples should be revised. > > in the footprint example, should the "value": "ipv4:192.0.2.0/24 > " be a footprint object, i.e., "{ "footprint-type": > "ipv4", "footprint-value": ["192.0.2.0/24"] } ? (same comment applies to > the example in 5.7.3) > Yes, it should. Fixed. > > when adding a new ipv4 footprint, does this assume that there was not > previously an ipv4 footprint defined? if there was a previously defined > ipv4 footprint, the update should change the footprint-value array in the > ipv4 footprint structure? > Yes, it will change the footprint-value array. Assuming the "ipv4" footprint-type is the first footprint object, we should use the following JSON patch to do the update { "op": "add", "path": "/cdni-fci/capabilities/0/footprints/0/footprint-value/-", "value": "192.0.2.0/24" } The authors will fix it. > > - section 6.2.4: > the update of "ipv4:192.0.2.0/24" delivery protocol from "http/1.1" to > "http/1.1" doesn't actually change anything? > Good catch. The values in Sec 6.2.3 and Sec 6.2.4 should be different. Fixed. > > - section 7.1: > should probably add some text asking IANA to add the entry to the "CDNI > Metadata Footprint Types" registry, and add a link to its definition in > section 4.1. > I agree. WIll do it. > > - authors: > probably should change my email to: kevin.j.ma.ietf@gmail.com and > remove my Ericsson affiliation? > No problem. Will update. > > nits: > > - section 1: > "On a high level" -> "At a high level" > "; (2) redirecting" -> "; and (2) redirecting" > "; (2) CDNI" -> "; and (2) CDNI" > "are already in [RFC8008]" -> "are already defined in [RFC8008]" > > - section 2.1: > "look like" -> "look" > "asn and countrycode" -> "asn, and countrycode" > "a /32 for IPv4 and a /128 for IPv6" -> "a /32 for IPv4 or a /128 for > IPv6" > "; (5) Capabilities" -> "; and (5) Capabilities" > > - section 2.2: > "have difficulty to measure" -> "have difficulty measuring" > "downstream CDN" -> "dCDN" > "QoS" -> "quality of service" ? > "cost map from dCDN" -> "cost map from the dCDN" > "therefore redirect requests to dCDN" -> "redirect requests to a dCDN" > "an upstream CDN" -> "a uCDN" > "e.g. " -> "e.g., " > > - section 3.5: > "The future documents" -> "Future documents" > > - section 3.7.2: > "delivery protocol and https/1.1" -> "delivery protocol, and https/1.1" > > - section 5: > "constrains" -> "constraints" > "only if the entry contains at least one of the client given > capabilities will it be returned to the client" -> "an entry will only be > returned to the client if it contains at least one of the client given > capabilities" > > - section 5.7.2: > "only http/1.1 delivery protocol" -> "only the http/1.1 delivery > protocol" > > - section 7.2/7.3: > remove "Besides, " > > - section 8: > "to run out of" -> "to unnecessarily consume" > "above well. However," -> " above, however," > "should not have to served by" -> "should not have to be served by" > "dCDN and it may not disclose" -> "dCDN; and it SHOULD not disclose" > "a dCDN may consider" -> "a dCDN could consider" > "And it needs to avoid expoing" -> "A dCDN SHOULD avoid exposing" > Fixed. Thanks for all the grammar check. Thanks again for the reviews. I did not see any major issues attacking the current design. The authors will fix all the issues above and submit a new version. Thanks, Jensen > > On Thu, Dec 5, 2019 at 11:29 AM Jan Seedorf wrote: > >> Dear CDNI chairs and CDNI WG, >> >> the ALTO WG is finalizing "Content Delivery Network Interconnection >> (CDNI) Request Routing: CDNI Footprint and Capabilities Advertisement >> using ALTO" (draft-ietf-alto-cdni-request-routing-alto-08). For the WGLC >> we are about to issue, we would like to have one individual review from >> a CDNI expert (the other one coming from the ALTO WG). Can you please >> name/choose/recommend a CDNI expert that can provide an individual >> review for the draft? We (ALTO chairs) would then start the WGLC ... >> >> Thanks, >> >> Kind regards, >> >> Jan >> > --000000000000a7fb42059ba17298 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Kevin and Sanjay,

Thank you so much for the reviews. Please see my comments = inline.

On Sun, Jan 5, 2020 at 2:42 PM Kevin Ma <kevin.j.ma.ietf@gmail.com> wrote:
Hi Jan,
=
=C2=A0 Sorry for the delayed response.=C2=A0 My comments as = a co-author and CDNI reviewer are below.=C2=A0 Sanjay Mishra has also volun= teered to provide an independent CDNI review.

than= x!

--=C2=A0 Kevin J. Ma

<= div>- section 3.7.1:
=C2=A0 "one CDNI FCI resource depending on a n= etwork map, one filtered CDNI FCI resource to be defined in Section 5,"= ; -> "one filtered CDNI FCI resource to be defined in Section 5, on= e CDNI FCI resource depending on a network map," =C2=A0or change the o= rder in the json example

<= div>Thanks for catching it! Fixed.
=C2=A0

=C2=A0 why = do the filtered-cdnifci-property-map countrycode and asn capabilities not h= ave my-default-network-map.pid properties?

It is not reasonable to define my-default-network-map= .pid properties of countrycode or asn entities. In the base ALTO protocol (= RFC7285), a PID is defined as an aggregation of endpoint addresses. So in t= his example, this ALTO server does not allow any client to request such map= pings from the filtered-cdnifci-property-map resource.
=C2=A0
<= div>
=C2=A0 in update-my-cdni-fci, for the my-filtered-cdnifci capabilit= y, ""application/merge-patch+jso" should be ""appl= ication/merge-patch+json"=C2=A0
Fixed. Thanks!
=C2=A0

- section 3.7.3:
= =C2=A0 is this intended to be a continuation of the example in 3.7.2? =C2= =A0if so, should "http/2" be in the 3.7.2 example, if it's be= ing removed in 3.7.3? =C2=A0specifically, should "http/2" be &quo= t;https/1.1" in 3.7.3?

Good point! The examples should be revised.
=C2=A0
=
=C2=A0 in the footprint example, should the "value": "ip= v4:192.0.2.0/24"= ; be a footprint object, i.e., "{ "footprint-type": "ip= v4", "footprint-value": ["192.0.2.0/24"] } ? =C2=A0(same comment applie= s to the example in 5.7.3)

Yes, it should. Fixed.
=C2=A0

=C2=A0 when adding= a new ipv4 footprint, does this assume that there was not previously an ip= v4 footprint defined? =C2=A0if there was a previously defined ipv4 footprin= t, the update should change the footprint-value array in the ipv4 footprint= structure?

Yes, it w= ill change the footprint-value array. Assuming the "ipv4" footpri= nt-type is the first footprint object, we should use the following JSON pat= ch to do the update

{ "op": "add",
=C2=A0 &qu= ot;path": "/= cdni-fci/capabilities/0/footprints/0/footprint-value/-",
=C2=A0 &qu= ot;value": "192.0.2.0/24"= ; }
<= br>
T= he authors will fix it.
=C2=A0

- section 6.2.4:=
=C2=A0 the update of "ipv4:192.0.2.0/24" delivery protocol from "http/1.1&qu= ot; to "http/1.1" doesn't actually change anything?
=

Good catch. The values in Sec = 6.2.3 and Sec 6.2.4 should be different. Fixed.
=C2=A0
- section 7.1:
=C2=A0 should probably add some text asking IANA to add = the entry to the "CDNI Metadata Footprint Types" registry, and ad= d a link to its definition in section 4.1.

I agree. WIll do it.
=C2=A0

- au= thors:
=C2=A0 probably should change my email to:=C2=A0kevin.j.ma.ietf@gmail.com= =C2=A0and remove my Ericsson affiliation?

No problem. Will update.
=C2=A0

n= its:

- section 1:
=C2=A0 "On a high level" -> "= At a high level"
=C2=A0 "; (2) redirecting" -> ";= and (2) redirecting"
=C2=A0 "; (2) CDNI" -> "; a= nd (2) CDNI"
=C2=A0 "are already in [RFC8008]" -> &quo= t;are already defined in [RFC8008]"

- section 2.1:
=C2=A0 &q= uot;look like" -> "look"
=C2=A0 "asn and countryc= ode" -> "asn, and countrycode"
=C2=A0 "a /32 for = IPv4 and a /128 for IPv6" -> "a /32 for IPv4 or a /128 for IPv= 6"
=C2=A0 "; (5) Capabilities" -> "; and (5) Capa= bilities"

- section 2.2:
=C2=A0 "have difficulty to mea= sure" -> "have difficulty measuring"
=C2=A0 "down= stream CDN" -> "dCDN"
=C2=A0 "QoS" -> &qu= ot;quality of service" ?
=C2=A0 "cost map from dCDN" ->= ; "cost map from the dCDN"
=C2=A0 "therefore redirect req= uests to dCDN" -> "redirect requests to a dCDN"
=C2=A0= "an upstream CDN" -> "a uCDN"
=C2=A0 "e.g. = " -> "e.g., "

- section 3.5:
=C2=A0 "The f= uture documents" -> "Future documents"

- section 3= .7.2:
=C2=A0 "delivery protocol and https/1.1" -> "del= ivery protocol, and https/1.1"

- section 5:
=C2=A0 "con= strains" -> "constraints"
=C2=A0 "only if the ent= ry contains at least one of the client given capabilities will it be return= ed to the client" -> "an entry will only be returned to the cl= ient if it contains at least one of the client given capabilities"
=
- section 5.7.2:
=C2=A0 "only http/1.1 delivery protocol" = -> "only the http/1.1 delivery protocol"

- section 7.2/= 7.3:
=C2=A0 remove "Besides, "

- section 8:
=C2=A0 &= quot;to run out of" -> "to unnecessarily consume"
=C2= =A0 "above well.=C2=A0 However," -> " above, however,&quo= t;
=C2=A0 "should not have to served by" -> "should no= t have to be served by"
=C2=A0 "dCDN and it may not disclose&q= uot; -> "dCDN; and it SHOULD not disclose"
=C2=A0 "a d= CDN may consider" -> "a dCDN could consider"
=C2=A0 &q= uot;And it needs to avoid expoing" -> "A dCDN SHOULD avoid exp= osing"

Fixed. Thanks= for all the grammar check.

Thanks again for the r= eviews. I did not see any major issues attacking the current design. The au= thors will fix all the issues above and submit a new version.
Thanks,
Jensen
=C2=A0

On= Thu, Dec 5, 2019 at 11:29 AM Jan Seedorf <ietf@j-f-s.de> wrote:
Dear CDNI chairs and CDNI WG,

the ALTO WG is finalizing "Content Delivery Network Interconnection (CDNI) Request Routing: CDNI Footprint and Capabilities Advertisement
using ALTO" (draft-ietf-alto-cdni-request-routing-alto-08). For the WG= LC
we are about to issue, we would like to have one individual review from a CDNI expert (the other one coming from the ALTO WG). Can you please
name/choose/recommend a CDNI expert that can provide an individual
review for the draft? We (ALTO chairs) would then start the WGLC ...

Thanks,

Kind regards,

Jan
--000000000000a7fb42059ba17298--