From nobody Wed Jun 1 08:50:29 2016 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 913D812B026; Wed, 1 Jun 2016 08:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 jWzF1iD4BTCg; Wed, 1 Jun 2016 08:50:25 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c: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 3B50412D508; Wed, 1 Jun 2016 08:50:25 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id a136so189289141wme.0; Wed, 01 Jun 2016 08:50:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3bN9OpvJ0Q98C8AF2expflFi+GgMBEAuFwuKlZyzeHk=; b=a5xuMVoUILLatPIC9o6VGHXcLS2GrCDiZ+24cyAFmTtAD7CFaw45iNSbNGKlvH/du8 NSPpV0OB9LhcxDrVeHTRl18S9Ay+mZjGuObMar2bYrDBgSN+MK/l1tGBVY5jRQxMzaWK M+uETs4+9kMtIn07mBOa0ASJu0oizNlpTizunPkwgZL2to0znt7wi+cIQ6lW3joUEV/i M9lS/5D6U6h8Jdvo4Zxj56mlJEbSyFyAuwY1NnhNFBEBY1e2LNKpvQSsTb3veYd0rz81 kgIUHtSRbW8pdE924FUFNJP1bN3HUXDOfA9I/ZA3Y5jCmFP+EDlWl5PPcMRlV7NqCmY6 xiaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3bN9OpvJ0Q98C8AF2expflFi+GgMBEAuFwuKlZyzeHk=; b=TU3DRyIg0TwBvITA2dbuCxEggNDhCkkLerRmyoLI3YGONsF+sAlPA1b91ZT7CZbc8M Iwt4eKX2/7zcduRJy4ZxqDL+j08poAIfIEFjWUt3qbQNkp7SQyDBGzvSb17MQHjk3tFY 0bjF56vpP19BRY5RWvHaJWJ8Ugxcof+KqKwRkjq/HkV7omWSg2r62s+OwDOXaPPqztBL zfxnaxPTqWaXv+74Voc15qEP6+kGJF77Z2a3ZIM1zIaduiTE8w4453pTtK9xMalHNWvM YMyrsIVwCmyOcV8O4yTD8qlOH+go9qVcAG5+S8a3a6fQp0Stc5G31W72yA3rAiM/r48x G2zA== X-Gm-Message-State: ALyK8tLqrMmr9KOCEXIUoCAlIlfhuro27IyPEH/kpZluBmMnO7I7NEyblNoo1RVh+8cW6w== X-Received: by 10.28.96.10 with SMTP id u10mr23806900wmb.93.1464796223623; Wed, 01 Jun 2016 08:50:23 -0700 (PDT) Received: from [192.168.1.21] (125.216.113.78.rev.sfr.net. [78.113.216.125]) by smtp.gmail.com with ESMTPSA id y76sm35689575wmd.3.2016.06.01.08.50.21 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 01 Jun 2016 08:50:22 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Francois Le Faucheur In-Reply-To: <20160518223257.14733.37895.idtracker@ietfa.amsl.com> Date: Wed, 1 Jun 2016 17:50:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160518223257.14733.37895.idtracker@ietfa.amsl.com> To: Ben Campbell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: draft-ietf-cdni-logging@ietf.org, cdni-chairs@ietf.org, The IESG , cdni@ietf.org Subject: Re: [CDNi] Ben Campbell's Discuss on draft-ietf-cdni-logging-25: (with DISCUSS and COMMENT) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 01 Jun 2016 15:50:27 -0000 Ben and all, Thanks for the review and comments. Please see proposed resolution = below: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > While the security and privacy bits are much improved from earlier > versions, I think I have found some holes. I assume these are not > intentional, and it's entirely possible I have misread some things. = But I > would like to make sure they are considered prior to progressing. >=20 > - 3.4.1, c-groupid: The privacy-related guidance about c-groupids > indentifying individual clients (in the several bullet list entries = with > "-" bullets) seems contingent on the MAY in the parent (with the "+" > bullet.) The parent says that you MAY structure the field so that = parts > identify the aggregate and one part aggregates the individual, with = the > sub-bullets following an "In this case..." clause. I assume the = guidance > is intended to apply even when an implementation doesn't structure > c-groupid that way (or at all.)=20 Yes. I tweaked the text to make that clearer i.e. s/In that case/In the case where the aggregate is chosen so that it = contains a single client/ >=20 > - 7.1: This section seems to effectively say that various protections = are > required when they are required. But it doesn't give advice on when = they > may be required. (For example, when c-groupid can be mapped to = individual > client addresses.) I am tired of discussing the word smithing around use of TLS. So I = aligned the text to cdni-control-triggers which effectively makes = protection required all the time (i.e. MUST use TLS, unless some other = protection is used). This has passed IESG approval in the context of = cdni-control-triggers, so it should be equally acceptable to all for = cdni-logging, and it will ensure consistency across CDNI I-Ds. So it now reads: =E2=80=9C TLS MUST be used by the server-side and the client-side of the CDNI Logging feed, as well as the server-side and the client-side of the CDNI Logging File pull mechanism, including authentication of the remote end, unless alternate methods are used for ensuring the security of the information exchanged over the LI interface (such as setting up an IPsec tunnel between the two CDNs or using a physically secured internal network between two CDNs that are owned by the same corporate entity). " >=20 > - 7.3: "Making detailed CDNI logging > information known to the uCDN does not represent a particular = privacy > concern because the uCDN is already exposed at request redirection > time to most of the information that shows up as CDNI logging > information (e.g., enduser IP@, URL, HTTP headers - at least when > HTTP redirection is used between uCDN and dCDN)." >=20 > I agree this is mostly true for HTTP redirection. But as you mention, = the > assertion seems to fall down for DNS redirection, where the uCDN may = have > considerably less information. I think some different guidance for = that > case may be needed. I will come back to this one once I have digested the associated thread. >=20 > -- "Transporting > detailed CDNI logging information over the HTTP based CDNI Logging > Interface does not represent a particular privacy concern because it > is protected by usual IETF privacy-protection mechanism (e.g.,TLS)." >=20 > I don't find normative text that says privacy-sensitive information = MUST > be protected. Just that information that needs to be protected MUST be > protected. The reader is left to infer that privacy-sensitive = information > is covered by that. (See previous comment about 7.1). Without = something > explicit there, I think it highly likely that some people will > rationalize that their deployments don't need protection for one = reason > or another. With the new text, the information MUST always be protected. So the = question goes away. >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > - 3.3, 2nd to last paragraph: What does it mean to reject a logging = file? > Does it mean to simply ignore it, or does it imply some notice back = the > source of the file that there's a problem? (I tend to think of = "reject" > as implying the latter in a protocol, in contrast to words like "drop" = or > "ignore=E2=80=9D.) The CDNI Logging File Pull protocol is a simple HTTP transfer of the = CDNI Logging File from dCDN to uCDN, so there is not backwards channel = that can be used for the uCDN to notify the dCDN that a CDNI Logging = File (that was successfully transmitted via HTTP) is actually not a = valid CDNI Logging File.=20 So, the text has been updated to say =E2=80=9Cignore=E2=80=9D instead of = reject. I also replaced =E2=80=9Creject=E2=80=9D by =E2=80=9CIgnore=E2=80=9D in = 3.4: "the implementation MUST ignore those HTTP Request Logging Records" >=20 > - 3.4.1, 3rd "-" bullet: "The algorithmic mapping and variation over = time > MAY allow > the uCDN ... to reconstruct the actual client IPv4 or = IPv6 > address" >=20 > Is that intended to be a 2119 MAY or a statement of fact? If the = former, > it seems to directly contradict the NOT RECOMMENDED in the next "-" > bullet.. It is a statement of fact (and an improper use of the 2119 =E2=80=9CMAY=E2= =80=9D). Text has been updated so it reads: "The algorithmic mapping and variation over time can, in some cases, = allow the uCDN ... to reconstruct the actual client IPv4 or IPv6 = address=E2=80=9D. From nobody Wed Jun 1 09:18:02 2016 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 2F9FE12D0DD; Wed, 1 Jun 2016 09:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 DSviakY52GKG; Wed, 1 Jun 2016 09:17:53 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 41AD612D54F; Wed, 1 Jun 2016 09:17:53 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id a136so190536392wme.0; Wed, 01 Jun 2016 09:17:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vn82tiPBaYD4IYat15aQmddTonKfgAkgHtwnEtRY0vQ=; b=TtrDYi3QXjIzNOj/30FhZ5zDtNrxwPckRc0C5VxtSjDHvVgnfyla0w8ky3GZ3BasBn Un8zdY1u2BmmDK2Cjsu167oYKgjtdqb0hQWbYSE9QRfOCA0idT8veLDa3n4eP4/bvUcp LGRc+JMUANEmtWoYJdTLH4UxF1OQqzADcs88ZNSMkRLNkLss+B6q9k5wiew5UX2+kmO5 rcJyCVu5zkfPYj6QeyRB7vFLI+983+W+eDFr318deyDc5A9aMFjSivaAEysFiuUpUjMQ sVRWkJS3cgqayvNpjZMjcnwQc2a415izPSoj/a2umtkWWQTTRDGO21h7b34p/aVUMrVK +Tfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vn82tiPBaYD4IYat15aQmddTonKfgAkgHtwnEtRY0vQ=; b=ATbaI4kJvK99UvQ8BNWQ8l3CxtXqA04S+2pKMikT9PF5x4wJ0qsvoMYizx6bhuqpmi 6DMzHg0I2ifQZS1MG6c2NNpkbPEIBicO/0pXhM8Pkdo1b9LocGtQ8a8GkuUaRGxONAe3 jlis/Mzi3Qg9qGMPBCmKSIItXDPEk9uPHEE02JPzpDKzIXIwyFXhh/nNphF8BJKli53Z VOaMs4j0hUti7sWpjP5uAwDBBwJyf4yId2Y2goyKe8QEeQzyVcLkDHWxQ6DZ/NSe8g8I rqKXPsuHP2STp78lb1frQRmNnP8ssIC3fgs9GD+4L2PACsyEW1lTe9AzYXHwI4Dziihe VbRA== X-Gm-Message-State: ALyK8tLUvI++pItcfWbGqIDJjh4nhGhrgjtaDs1HHUthC3ZJlDdBDTbl4Bf691rb6DM2Cg== X-Received: by 10.28.54.150 with SMTP id y22mr4350883wmh.70.1464797871695; Wed, 01 Jun 2016 09:17:51 -0700 (PDT) Received: from [192.168.1.21] (125.216.113.78.rev.sfr.net. [78.113.216.125]) by smtp.gmail.com with ESMTPSA id v5sm29649158wjv.36.2016.06.01.09.17.50 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 01 Jun 2016 09:17:50 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Francois Le Faucheur In-Reply-To: <20160529114300.27632.32780.idtracker@ietfa.amsl.com> Date: Wed, 1 Jun 2016 18:17:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160529114300.27632.32780.idtracker@ietfa.amsl.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.3124) Archived-At: Cc: draft-ietf-cdni-logging@ietf.org, cdni-chairs@ietf.org, The IESG , cdni@ietf.org Subject: Re: [CDNi] Alexey Melnikov's No Objection on draft-ietf-cdni-logging-26: (with COMMENT) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 01 Jun 2016 16:17:56 -0000 Hi Alexey, Thanks for following up. See below: >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thank you for addressing my DISCUSS points. >=20 > Ok, you now clarified that version names are case-insensitive. However = I > didn't get this impression while reading 3.3, as there is no version = ABNF > there. So you might want to say that earlier in the document as well. Fair enough. I added a statement about case -insensitive for each of the = directives, version, value, field names where there are respectively = defined (under 3.3 and 3.4) >=20 > In 7.1, last sentence: TLS only provides for protection from tampering > when in transit, not when a log file being stored. I already responded to that point and corrected the sentence so it now = reads: =E2=80=9C Protection against third party tampering, when the CDNI Logging File is = communicated over the CDN Logging Interface, can be achieved as = discussed above through the use of TLS. =E2=80=9C Is it not acceptable ? Cheers Francois= From nobody Wed Jun 1 09:47:10 2016 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 D663B12B00D; Wed, 1 Jun 2016 09:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 aucXQfzXW8rX; Wed, 1 Jun 2016 09:47:06 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::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 5C2A512B00E; Wed, 1 Jun 2016 09:47:06 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id a136so191766214wme.0; Wed, 01 Jun 2016 09:47:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rCOaaCLm0LqLOiB0r8hfeTwNUxQs0vZvGturMnvSu7Y=; b=KuIlMAbYEv25uUC4SVD5wMcMrHzSn38xxz8H5ynxC9VXd0a1yxpHNg9SE8KlaMS/NZ H65lHIF5I/PKznY9zPBd2dadt5JU1+BUQQ8KUGoCF2h4/6iT6rWz+LAbQXOq3a+wUCYr 0bC38VRvCoXb3t8FWD6VdMZ3KJq0URxh3cofZUB+uCOzIC4k0+nyn72P5Wpa0xf7BBj/ WE1pDIWZbyhfful4y0dlLl3RkjMS9yzSIHEzcQ3aOsnJCWsep9eGu86U7Za0v+c65ujg Bx+6g43fj8YftFxvL7pPV5AlCEXYAq9fVUvvrQR3wnxKNlv2xhqggKHl+VjSb7O5L5+w nulg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rCOaaCLm0LqLOiB0r8hfeTwNUxQs0vZvGturMnvSu7Y=; b=c/C1Jb2maKHNdszZGHQNhOcifLGSeu7m8vJycM8OX2PsOpSkJ6izHfPl+8HKbjxHA4 vRUDLxlCRS3yYk6xKMD8tjpJ1rxoBjez7HhssQF6HbuA9SMNibXgdq9M6ThaRGH4u+Xn 8liExwXfa7x3UZ96rO6f3LPUgdcVixJ1V6NZKA1zLUIbAo6VyzIDtjXjp5yaRhqU/yvW JGtxTNx5/d+JC8/Y6KgV/Vpk/n/Tfn7ZKAjKB/eNWmWvkHw/z4FWFocKeuk7+EQDetg5 lI6+/NOWcGbqQZ3VjVvlOnHNo7wXzczVjgPm7FZMV4WlZQ9alM3+rgp7Mh308e/alH0O wJHg== X-Gm-Message-State: ALyK8tLZi8D0SZBTo1w5g0SkuQyUvEKKhAtkvqC4nqOK1vKvSmZf+2RrDPczQvb8nNta2w== X-Received: by 10.195.18.99 with SMTP id gl3mr4510280wjd.162.1464799624531; Wed, 01 Jun 2016 09:47:04 -0700 (PDT) Received: from [192.168.1.21] (125.216.113.78.rev.sfr.net. [78.113.216.125]) by smtp.gmail.com with ESMTPSA id f1sm35182637wmf.22.2016.06.01.09.47.02 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 01 Jun 2016 09:47:03 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Francois Le Faucheur In-Reply-To: Date: Wed, 1 Jun 2016 18:47:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <59AB96A8-B811-443A-8256-54D45141F96E@gmail.com> References: <20160518223257.14733.37895.idtracker@ietfa.amsl.com> <3E2786B2-9204-447C-9A53-A3CB0213E0F5@niven-jenkins.co.uk> <573CFEC8.8010600@cs.tcd.ie> <5DED924E-C407-44E9-8FF1-477B26B69647@niven-jenkins.co.uk> <573D09D5.1020501@cs.tcd.ie> <573D19C3.3050304@cs.tcd.ie> To: Niven-Jenkins Ben , Stephen Farrell , Ben Campbell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: draft-ietf-cdni-logging@ietf.org, The IESG , "" , cdni-chairs@ietf.org Subject: Re: [CDNi] Ben Campbell's Discuss on draft-ietf-cdni-logging-25: (with DISCUSS and COMMENT) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 01 Jun 2016 16:47:09 -0000 Folks, My conclusion from that thread is: * the current argument for why there is no privacy concern in = communicating the CDNI Logging File to the uCDN holds for HTTP=20 * for DNS, the current argument does not hold as currently = written * for DNS, my proposal is to: - capture Ben NJ=E2=80=99s argument (but with a caveat): = because the uCDN is the =E2=80=9Cauthoritative=E2=80=9D CDN (i.e. the = CDN that has control about how the request is delivered and by itself of = by another CDN) and has the responsibility of each and every delivery, = it _may_ not be a privacy concern to communicate detailed logging = information to the uCDN.=20 - in scenarios where there are some privacy concerns = (e.g. because of different regulations applying to uCDN and dCDN), then = this can be taken into account when uCDN and dCDN agree on which fields = to convey inside the CDNI Logging Files and which privacy protection = mechanisms are to be used (such as the c-groupid, and which mapping is = used for the c-groupid). Let me know if that is not acceptable, and can be improved. Cheers Francois > On 19 May 2016, at 17:42, Ben Niven-Jenkins = wrote: >=20 >=20 >> On 19 May 2016, at 02:41, Stephen Farrell = wrote: >>=20 >> Cutting to (I think) the substantive bit... >>=20 >> On 19/05/16 02:11, Ben Niven-Jenkins wrote: >>> My intention was to express my opinion that because the uCDN could >>> have chosen to perform the content delivery itself the dCDN is not >>> exposing any more information to the uCDN than the uCDN could have >>> chosen to gather itself if it so desired and therefore IMO there is >>> no need to provide different guidance for DNS redirection than for >>> HTTP redirection. >>=20 >> Yes, I've seen arguments of that form offered a number of times. >> I don't find it convincing myself, but recognise that other folks >> do. And in every case so far, neither side has convinced the other, >> and sometimes not even understood one another. But let's see if >> we (me really:-) get better with practice... >>=20 >> In this case I'd argue that the "could have chosen" isn't really >> true - presumably the uCDN deals with the dCDN because it's hard(er) >> for the uCDN to do the work directly, so it's not really true that >> the uCDN could have chosen to access the information, at least not >> at the same cost. >=20 > True, but there are lots of possibilities for why the uCDN would;t do = it itself or why it might those to do the content delivery itself if it = was so inclined, e.g. maybe if the uCDN is really interested in invading = user=E2=80=99s privacy, what it gains from that outweighs the additional = cost of performing the delivery itself. Who knows, I don=E2=80=99t think = we can try and account for all that variation. >=20 >> And there may be aspects of meta-data that are just different because >> the access was via the dCDN, e.g. perhaps some other client IP = address >> gets used if somethings multihomed, or some ISP infrastructure = differs, >> e.g. HTTP Forwarded might be present and visible to the dCDN but with >> no similar thing for DNS (or vice versa). I'd not be surprised if = even >> more subtle differences existed over populations of transactions and >> users and CDNs. >=20 > I=E2=80=99m sure there are all sort of things like you suggest above. = What is not at all clear to me is what specifically the logging draft is = meant to do about it. >=20 > Ultimately it=E2=80=99s a tradeoff I think. I=E2=80=99m not sure = we=E2=80=99ll ever agree. >=20 > I have nothing more to say that won=E2=80=99t end up just rehashing = discussions we=E2=80=99ve already had so I don=E2=80=99t intend on = participating in this thread any longer. >=20 > Ben >=20 From nobody Wed Jun 1 11:41:11 2016 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 A6BE112B00A; Wed, 1 Jun 2016 11:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=eRuPZ2qn; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=D6/Xon6B 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 cBdiv-8LFX5z; Wed, 1 Jun 2016 11:41:09 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88E4512B015; Wed, 1 Jun 2016 11:41:07 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id DC63A20A41; Wed, 1 Jun 2016 14:41:06 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Wed, 01 Jun 2016 14:41:06 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=sDRpCrL8MjN+90EEsU6SEw3qUzw=; b=eRuPZ2 qn4WDTvlCY6+syc/YhUQ3Pw4+Kvtw863w4Q1D+bBFEqNw/TN+HE3op3gRzyvHC7U EEZ2fokL7eAA4dVkOYBAST4oIUXBY64IG0zlpJ4DBEpaBHweboJjKr0mpK+JcMPL uwhxj+kz6htr4Kqh5MQPxDp8nANJFQctzShN8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=sDRpCrL8MjN+90E EsU6SEw3qUzw=; b=D6/Xon6BkazO+3q0C2nQQxgFBVMPgCs3QeJSYck8YWHDhFC 9YTKqvmluvN0VSnuNV9vyBi1dp2cqNXC5fMQM2XfGdqhVhfIRt+i4zD73BhbyMqu 17wEDdwPZ4Pkxpb+qxrUZm0H8US7wANHpyamrvvrecxvSYizufQAFoeXqoCE= X-Sasl-enc: 3euyrkii3jpt22vAuHssJUbx4WnO33hyqf1VADccqgaa 1464806466 Received: from [10.234.137.180] (unknown [85.255.237.235]) by mail.messagingengine.com (Postfix) with ESMTPA id 70C88CCD34; Wed, 1 Jun 2016 14:41:06 -0400 (EDT) Content-Type: text/plain; charset=windows-1251 Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPhone Mail (13E238) In-Reply-To: Date: Wed, 1 Jun 2016 19:47:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <56C6B19F-8207-4250-B1D5-055CF67968DB@fastmail.fm> References: <20160529114300.27632.32780.idtracker@ietfa.amsl.com> To: Francois Le Faucheur Archived-At: Cc: cdni@ietf.org, draft-ietf-cdni-logging@ietf.org, The IESG , cdni-chairs@ietf.org Subject: Re: [CDNi] Alexey Melnikov's No Objection on draft-ietf-cdni-logging-26: (with COMMENT) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 01 Jun 2016 18:41:11 -0000 Hi Francois, On 1 Jun 2016, at 17:17, Francois Le Faucheur wrote: >> In 7.1, last sentence: TLS only provides for protection from tampering >> when in transit, not when a log file being stored. >=20 > I already responded to that point and corrected the sentence so it now rea= ds: > =93 > Protection against third party tampering, when the CDNI Logging File is co= mmunicated over the CDN Logging Interface, can be achieved as discussed abov= e through the use of TLS. > =93 >=20 > Is it not acceptable ? Sorry, missed that. Yes, this is an improvement. Can anything be said about data at rest?= From nobody Thu Jun 2 03:02:19 2016 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 1C5F112D6AC for ; Thu, 2 Jun 2016 03:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=Liwq4XFt; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=oiE6SDXX 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 9xVCbja8ZpHY for ; Thu, 2 Jun 2016 03:02:15 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CE1712D6A5 for ; Thu, 2 Jun 2016 03:02:15 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 15438219F9 for ; Thu, 2 Jun 2016 06:02:15 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute5.internal (MEProxy); Thu, 02 Jun 2016 06:02:15 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=Fg8783zm6E2TpmTLjGy51NAhj+o=; b=Liwq4X FtLG4b8Ct6WFUzH82n44Ph6bSY02qRtsifsZCdtPetV98dXkDUh6OYGk4UhUd1q0 aiWumXb3XjFqcj5TSn0q6QmE1VDIQl++oILMwMjckWILR0QyBPO0/g/GkPA67YHT XEweoUGUoi67LLX3ZBt8ZhK0/0l05jtZCYolY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=Fg8783zm6E2TpmT LjGy51NAhj+o=; b=oiE6SDXXKqeVsIHDS9XfldPK7qj6E1ZDoHr4NI+qJG4uiVb G8Kn+HtK86Mxlw3YXh6gljuJH5Vv68Kgm8Ldp82UKrMUh5JQUdlG0+/CBiBC6Fqb jAROyzXQYp110QLPMeCgU/o8q2Izrkm131SjPM0O5Dk2KwjSivpfTEeZTJi0= Received: by mailuser.nyi.internal (Postfix, from userid 99) id DE572A849C; Thu, 2 Jun 2016 06:02:14 -0400 (EDT) Message-Id: <1464861734.1246901.625717065.0912CC9E@webmail.messagingengine.com> X-Sasl-Enc: ZBY56KwrC122DmnNz1dQU7rNLscGwmgs8Wt21m7/IwCs 1464861734 From: Alexey Melnikov To: cdni@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-38f217ef In-Reply-To: References: Date: Thu, 02 Jun 2016 11:02:14 +0100 Archived-At: Subject: [CDNi] Early AD review of draft-ietf-cdni-metadata-17 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 02 Jun 2016 10:02:17 -0000 In order to speed up publication of this draft, I decided to do early AD review. Here are my comments. My apologies if they are a bit cryptic, if you are unsure of what I meant, please ask! In 1.2: content can only be delivered using HTTP/1.1 and not HTTP/1.1 over TLS? Is last para saying that this is an unsolved problem (e.g. LURK BOF solution is needed)? In 4.1.2: hostname and IP addresses need to have defined syntaxes (at least by reference). You also need to say whether IDN domain names are allowed here. In 4.1.5: does "case insensitive" only applies to ASCII range? I.e., encoded UTF-8 sequences in URIs are not affected. In 4.2.6: URI needs a Normative Reference (RFC 3986). In 4.3.7: need a reference to a document/registry defining ASNs. In 6.1: need a reference to HTTP/1.1 spec. Should OPTIONS method be allowed? In 6.2/6.3: Is discovery of the initial URI truly out of scope? You can define a .well-known URI to allow bootstrapping. If it is defined, is it likely to be used? In 7.3: Nit: HTTP/1.1 over TLS needs 2 references, not just one. In 7.4: I think I am sad that you haven't defined any initial authentication mechanism. Has this been discussed in the WG? In 8.1, last para: a requirement to implement mutual authentication is underspecified. Do you mean TLS mutual authentication? If yes, say so. If other mechanisms can be used, say so as well. If you meant to reference 8.5 here, please do so. Why is this only a SHOULD (and not a MUST)? In 8.2: similarly, how can the SHOULD be satisfied? Do you mean TLS or something else? Reference 8.5? In 8.3: similar issue. Also encryption doesn't necessarily provide integrity of data, so the last sentence sounds wrong. In 8.4: similar issue. From nobody Thu Jun 2 06:59:32 2016 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 DF79612D71F for ; Thu, 2 Jun 2016 06:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 aMLleGEys4uM for ; Thu, 2 Jun 2016 06:59:29 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BBAD12D1B1 for ; Thu, 2 Jun 2016 06:49:59 -0700 (PDT) X-AuditID: c618062d-f79886d000002334-39-5750308e2dc5 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 14.FA.09012.E8030575; Thu, 2 Jun 2016 15:11:42 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0294.000; Thu, 2 Jun 2016 09:49:58 -0400 From: Kevin Ma J To: Alexey Melnikov , "cdni@ietf.org" Thread-Topic: [CDNi] Early AD review of draft-ietf-cdni-metadata-17 Thread-Index: AQHRvLXhTYkUPkhZmUmD7E+22fbOBp/WMgJA Date: Thu, 2 Jun 2016 13:49:58 +0000 Message-ID: References: <1464861734.1246901.625717065.0912CC9E@webmail.messagingengine.com> In-Reply-To: <1464861734.1246901.625717065.0912CC9E@webmail.messagingengine.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyuXRPgm6fQUC4wfMVmhb73x9isng6+w+r A5PHzlMH2DyWLPnJFMAUxWWTkpqTWZZapG+XwJXR83chU8FboYpfD/4xNTA28XcxcnJICJhI vHt8iR3CFpO4cG89WxcjF4eQwFFGiX+TFzFCOMsYJW6umM4IUsUmoCXx+OtfJhBbRMBXYvWi f6wgtrCAk8SkZw0sEHFniYP3TwNN4gCyjSTObsoFCbMIqEjcOP0PrIQXqPV6y3oWiPmTGSVu 350GNpNTIEDi+4nJYLsYgS76fmoNWJxZQFzi1pP5TBCXCkgs2XOeGcIWlXj5GOIGCQEliUlL z7FC1OtILNj9iQ3C1pZYtvA1M8RiQYmTM5+wTGAUnYVk7CwkLbOQtMxC0rKAkWUVI0dpcUFO brqRwSZGYDwck2DT3cF4f7rnIUYBDkYlHt4FSv7hQqyJZcWVuYcYJTiYlUR4ec0CwoV4UxIr q1KL8uOLSnNSiw8xSnOwKInzij1SDBcSSE8sSc1OTS1ILYLJMnFwSjUwMv41vHJtSW2WgfqH k40CJZctkwTZKvyurp0rtJO76u/F5J5wUeuHy3a7eNyfGXnIOJfJgc/m48K3LuYLFa4fc/1t PslSkkeK+8neLsVFzHw+677PmvnrIM9u8Qd/pNfnZGmVbfZVXs+xuGX9guP6957NDjjOej2q N2N/erzJ1SXJDg2Tj+9+rsRSnJFoqMVcVJwIAEsKaQuDAgAA Archived-At: Subject: Re: [CDNi] Early AD review of draft-ietf-cdni-metadata-17 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 02 Jun 2016 13:59:31 -0000 HI Alexey,=20 (As and author) Thanks for the review. We will review and respond shortl= y. thanx! -- Kevin J. Ma > -----Original Message----- > From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Alexey Melnikov > Sent: Thursday, June 02, 2016 6:02 AM > To: cdni@ietf.org > Subject: [CDNi] Early AD review of draft-ietf-cdni-metadata-17 >=20 > In order to speed up publication of this draft, I decided to do early AD > review. Here are my comments. My apologies if they are a bit cryptic, if > you are unsure of what I meant, please ask! >=20 > In 1.2: content can only be delivered using HTTP/1.1 and not HTTP/1.1 > over TLS? Is last para saying that this is an unsolved problem (e.g. > LURK BOF solution is needed)? >=20 > In 4.1.2: hostname and IP addresses need to have defined syntaxes (at > least by reference). You also need to say whether IDN domain names are > allowed here. >=20 > In 4.1.5: does "case insensitive" only applies to ASCII range? I.e., > encoded UTF-8 sequences in URIs are not affected. >=20 > In 4.2.6: URI needs a Normative Reference (RFC 3986). >=20 > In 4.3.7: need a reference to a document/registry defining ASNs. >=20 > In 6.1: need a reference to HTTP/1.1 spec. >=20 > Should OPTIONS method be allowed? >=20 > In 6.2/6.3: Is discovery of the initial URI truly out of scope? You can > define a .well-known URI to allow bootstrapping. > If it is defined, is it likely to be used? >=20 > In 7.3: Nit: HTTP/1.1 over TLS needs 2 references, not just one. >=20 > In 7.4: I think I am sad that you haven't defined any initial > authentication mechanism. Has this been discussed in the WG? >=20 > In 8.1, last para: a requirement to implement mutual authentication is > underspecified. Do you mean TLS mutual authentication? If yes, say so. > If other mechanisms can be used, say so as well. > If you meant to reference 8.5 here, please do so. >=20 > Why is this only a SHOULD (and not a MUST)? >=20 > In 8.2: similarly, how can the SHOULD be satisfied? Do you mean TLS or > something else? Reference 8.5? >=20 > In 8.3: similar issue. >=20 > Also encryption doesn't necessarily provide integrity of data, so the > last sentence sounds wrong. >=20 > In 8.4: similar issue. >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From nobody Thu Jun 2 07:15:41 2016 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 E495C12D6FA for ; Thu, 2 Jun 2016 07:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XPJwAwy53eV for ; Thu, 2 Jun 2016 07:15:37 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E59B12D72B for ; Thu, 2 Jun 2016 07:15:37 -0700 (PDT) X-AuditID: c6180641-f796f6d000000e1e-1f-57503f51f9c9 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 1A.DC.03614.15F30575; Thu, 2 Jun 2016 16:14:41 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0294.000; Thu, 2 Jun 2016 10:15:35 -0400 From: Kevin Ma J To: Alexey Melnikov , "cdni@ietf.org" Thread-Topic: [CDNi] Early AD review of draft-ietf-cdni-metadata-17 Thread-Index: AQHRvLXhTYkUPkhZmUmD7E+22fbOBp/WMgJAgAACIfA= Date: Thu, 2 Jun 2016 14:15:35 +0000 Message-ID: References: <1464861734.1246901.625717065.0912CC9E@webmail.messagingengine.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyuXRPgm6gfUC4QeNPeYv97w8xWTyd/YfV gclj56kDbB5LlvxkCmCK4rJJSc3JLEst0rdL4MqYvuEke8Em6Yonl/uYGhjPi3YxcnJICJhI tN9rZ4OwxSQu3FsPZHNxCAkcZZT4eGYllLOMUWL+/FvMIFVsAloSj7/+ZQKxRQR8JVYv+scK YgsLOElMetbAAhF3ljh4/zQbhG0lsertTrAaFgEViQPr5gPFOTh4gXp3TqqHmD+FUeL3/jtg NYxAV3w/tQZsPrOAuMStJ/OZIK4TkFiy5zwzhC0q8fIxxF4JASWJSUvPsULU60gs2P2JDcLW lli28DVYPa+AoMTJmU9YJjCKzEIydhaSlllIWmYhaVnAyLKKkaO0uCAnN93IcBMjMOyPSbA5 7mDc2+t5iFGAg1GJh/dBlH+4EGtiWXFl7iFGCQ5mJRHeHVYB4UK8KYmVValF+fFFpTmpxYcY pTlYlMR59V8qhgsJpCeWpGanphakFsFkmTg4pRoY1RjM2rhNKybpnEwXKJzU9k+pQ/K69Wk5 KxnWaJ7ZbUJ7z0TeWc8+WSH4TOGW33tNrLuDPByOJyZKX3lg+ibtup/xxuZrf4LTYxcu4xWz fOFc/XDi/OVZ0wPqb6vmPb71bc2hjX+33eyKltKYcCT4fO+Cuc9bP/GwMPMve/f/tJT9XXdP BuEpSizFGYmGWsxFxYkALDq2GncCAAA= Archived-At: Subject: Re: [CDNi] Early AD review of draft-ietf-cdni-metadata-17 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 02 Jun 2016 14:15:40 -0000 wrt: > > In 7.4: I think I am sad that you haven't defined any initial > > authentication mechanism. Has this been discussed in the WG? The thought behind this was that URI Signing would be the primary delivery = auth mechanism, and could also be used for acquisition auth; but thank you = for reminding me that I missed the Auth Type registration in https://tools.= ietf.org/html/draft-ietf-cdni-uri-signing-07#section-8. :) We originally considered including an auth object for HTTP basic auth, just= to have something, but it's already inherently supported in the URL [RFC39= 86], and it felt better to just wait for URI Signing (which should follow q= uickly after) [https://mailarchive.ietf.org/arch/msg/cdni/FygOsoddUfcqD2PmV= XpC_XJIasM]. thanx. -- Kevin J. Ma > -----Original Message----- > From: Kevin Ma J > Sent: Thursday, June 02, 2016 9:51 AM > To: 'Alexey Melnikov'; cdni@ietf.org > Subject: RE: [CDNi] Early AD review of draft-ietf-cdni-metadata-17 >=20 > HI Alexey, >=20 > (As and author) Thanks for the review. We will review and respond > shortly. >=20 > thanx! >=20 > -- Kevin J. Ma >=20 > > -----Original Message----- > > From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Alexey Melnikov > > Sent: Thursday, June 02, 2016 6:02 AM > > To: cdni@ietf.org > > Subject: [CDNi] Early AD review of draft-ietf-cdni-metadata-17 > > > > In order to speed up publication of this draft, I decided to do early A= D > > review. Here are my comments. My apologies if they are a bit cryptic, i= f > > you are unsure of what I meant, please ask! > > > > In 1.2: content can only be delivered using HTTP/1.1 and not HTTP/1.1 > > over TLS? Is last para saying that this is an unsolved problem (e.g. > > LURK BOF solution is needed)? > > > > In 4.1.2: hostname and IP addresses need to have defined syntaxes (at > > least by reference). You also need to say whether IDN domain names are > > allowed here. > > > > In 4.1.5: does "case insensitive" only applies to ASCII range? I.e., > > encoded UTF-8 sequences in URIs are not affected. > > > > In 4.2.6: URI needs a Normative Reference (RFC 3986). > > > > In 4.3.7: need a reference to a document/registry defining ASNs. > > > > In 6.1: need a reference to HTTP/1.1 spec. > > > > Should OPTIONS method be allowed? > > > > In 6.2/6.3: Is discovery of the initial URI truly out of scope? You can > > define a .well-known URI to allow bootstrapping. > > If it is defined, is it likely to be used? > > > > In 7.3: Nit: HTTP/1.1 over TLS needs 2 references, not just one. > > > > In 7.4: I think I am sad that you haven't defined any initial > > authentication mechanism. Has this been discussed in the WG? > > > > In 8.1, last para: a requirement to implement mutual authentication is > > underspecified. Do you mean TLS mutual authentication? If yes, say so. > > If other mechanisms can be used, say so as well. > > If you meant to reference 8.5 here, please do so. > > > > Why is this only a SHOULD (and not a MUST)? > > > > In 8.2: similarly, how can the SHOULD be satisfied? Do you mean TLS or > > something else? Reference 8.5? > > > > In 8.3: similar issue. > > > > Also encryption doesn't necessarily provide integrity of data, so the > > last sentence sounds wrong. > > > > In 8.4: similar issue. > > > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni From nobody Thu Jun 2 12:52:00 2016 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 1D1EF12D0A2 for ; Thu, 2 Jun 2016 12:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3st0AJAJcur for ; Thu, 2 Jun 2016 12:51:54 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0848512D0D1 for ; Thu, 2 Jun 2016 12:51:53 -0700 (PDT) X-AuditID: c6180641-f796f6d000000e1e-99-57508e21df1f Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 0F.61.03614.12E80575; Thu, 2 Jun 2016 21:50:57 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0294.000; Thu, 2 Jun 2016 15:51:52 -0400 From: Kevin Ma J To: Alexey Melnikov , "cdni@ietf.org" Thread-Topic: [CDNi] Early AD review of draft-ietf-cdni-metadata-17 Thread-Index: AQHRvLXhTYkUPkhZmUmD7E+22fbOBp/WhWqA Date: Thu, 2 Jun 2016 19:51:52 +0000 Message-ID: References: <1464861734.1246901.625717065.0912CC9E@webmail.messagingengine.com> In-Reply-To: <1464861734.1246901.625717065.0912CC9E@webmail.messagingengine.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyuXRPuK5iX0C4Qf8qG4v97w8xWTyd/YfV gclj56kDbB5LlvxkCmCK4rJJSc3JLEst0rdL4MpY3jSFqWCrfMW6ec/YGhhbJLsYOTgkBEwk Vr527GLkBDLFJC7cW8/WxcjFISRwlFFi+vuHLBDOMkaJiy0vWUCq2AS0JB5//csEYosI+Eqs XvSPFcQWFnCSmPSsgQUi7ixx8P5pNgjbSOLizhlg9SwCKhLLu5sYQWxeoN5rSx9DLZjMKHH7 7jSwIk6BAInvJyaDFTECnfT91BqwOLOAuMStJ/OZIE4VkFiy5zwzhC0q8fIxxBESAkoSk5ae Y4Wo15FYsPsTG4StLbFs4WtmiMWCEidnPmGZwCg6C8nYWUhaZiFpmYWkZQEjyypGjtLigpzc dCPDTYzAeDgmwea4g3Fvr+chRgEORiUe3gdR/uFCrIllxZW5hxglOJiVRHiPdQWEC/GmJFZW pRblxxeV5qQWH2KU5mBREufVf6kYLiSQnliSmp2aWpBaBJNl4uCUamDkjr0b8j0+OucwC9+9 TnvJDkGVaxqfbny8qqm/bDPLma+9V770p5q2H7b+/y+oK9j0ZpP4IdcbW9JNnzEdFzfdHWdd wJmxPO3SUteomJc362w29m/w3MG43LvjuXdkvuKaPS9s5rLeD58hfH32nhvFDe+T1ELPTL9b nrT+xy87uaBP/gfea6cpsRRnJBpqMRcVJwIANO3B64MCAAA= Archived-At: Subject: Re: [CDNi] Early AD review of draft-ietf-cdni-metadata-17 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 02 Jun 2016 19:51:56 -0000 Hi Alexey, inline: > -----Original Message----- > From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Alexey Melnikov > Sent: Thursday, June 02, 2016 6:02 AM > To: cdni@ietf.org > Subject: [CDNi] Early AD review of draft-ietf-cdni-metadata-17 >=20 > In order to speed up publication of this draft, I decided to do early AD > review. Here are my comments. My apologies if they are a bit cryptic, if > you are unsure of what I meant, please ask! >=20 > In 1.2: content can only be delivered using HTTP/1.1 and not HTTP/1.1 > over TLS? Is last para saying that this is an unsolved problem (e.g. > LURK BOF solution is needed)? Essentially, yes. We had considered trying to define a way to pass certs a= nd keys around, but in general it seemed like a bad idea. A LURK-like solu= tion would help. > In 4.1.2: hostname and IP addresses need to have defined syntaxes (at > least by reference). You also need to say whether IDN domain names are > allowed here. I actually just removed the references, since they seemed redundant. The h= ost property is of type "Endpoint" which is defined in 4.3.3. I can add it= back if you feel it's not readable as is. > In 4.1.5: does "case insensitive" only applies to ASCII range? I.e., > encoded UTF-8 sequences in URIs are not affected. I would expect this to apply to the percent encoded values, not the decoded= values, i.e., I would expect "%4A" to be compared as "%4a" and not "j". I= s that what you mean? =20 Ben, do you agree? We can clarify that. > In 4.2.6: URI needs a Normative Reference (RFC 3986). Done. I assume you mean wrt the ignore-query-string property description "= URI query string parameters"? > In 4.3.7: need a reference to a document/registry defining ASNs. Added reference to RFC6793. > In 6.1: need a reference to HTTP/1.1 spec. Added a reference to RFC7230. > Should OPTIONS method be allowed? I'll defer to Ben on this one. > In 6.2/6.3: Is discovery of the initial URI truly out of scope? You can > define a .well-known URI to allow bootstrapping. > If it is defined, is it likely to be used? This is similar to Triggers (https://tools.ietf.org/html/draft-ietf-cdni-co= ntrol-triggers-15#section-4) in that it is assumes the CDNs would exchange = that information out-of-band, or that some other bootstrap API would be def= ined. wrt .well-known, the dCDN (in the case of metadata; the uCDN in the case of= triggers) would still need to have a hostname configured? There was some = discussion a while back (https://mailarchive.ietf.org/arch/msg/cdni/9JUdlQk= 0fD4_0Lhm1lj7_U7QfcM) about using a "well-known" URI for retrieving bootstr= ap information for all interfaces, but it was not followed up. > In 7.3: Nit: HTTP/1.1 over TLS needs 2 references, not just one. The other reference being? What if we just used 7230? More generally, though, do you think we need to adjust the registry structu= re to have a list of Protocol Specs? > In 7.4: I think I am sad that you haven't defined any initial > authentication mechanism. Has this been discussed in the WG? >=20 > In 8.1, last para: a requirement to implement mutual authentication is > underspecified. Do you mean TLS mutual authentication? If yes, say so. > If other mechanisms can be used, say so as well. > If you meant to reference 8.5 here, please do so. >=20 > Why is this only a SHOULD (and not a MUST)? Sections 8.1-8.4 were intended to lead into 8.5 Changed the SHOULDs to MUSTs and added references to 8.5 thanx. -- Kevin J. Ma > In 8.2: similarly, how can the SHOULD be satisfied? Do you mean TLS or > something else? Reference 8.5? >=20 > In 8.3: similar issue. >=20 > Also encryption doesn't necessarily provide integrity of data, so the > last sentence sounds wrong. >=20 > In 8.4: similar issue. >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From nobody Fri Jun 3 04:59:30 2016 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 030DC12D146 for ; Fri, 3 Jun 2016 04:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=dLGrf6Oj; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=F1iRqYuO 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 oVUwVQpVlKCZ for ; Fri, 3 Jun 2016 04:59:26 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF28F12D110 for ; Fri, 3 Jun 2016 04:59:26 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id F3CE121CF2; Fri, 3 Jun 2016 07:59:25 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute3.internal (MEProxy); Fri, 03 Jun 2016 07:59:26 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=DyIscx9OrijtNlhx6/gnDpIcb6k=; b=dLGrf6 Oj/acJIvQtgxNuX3JSoMFCDuTPt4bMcsbf0k904/nvfIGuROV692G4Ff7t0i+XMk FGECP40vlvH7DxWNXlDwDIe+I4hLYo6aS/Icw+zyLtRerbj0yU43TydJdtqiHq77 oa0nTiLoN7wM4DgXjer8XEvlxrkMXLfUDac4Y= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=DyIscx9OrijtNlh x6/gnDpIcb6k=; b=F1iRqYuOR5OzTs8Co9CYRuAP7Mmk1YUrBzPDoUPjscRVltH K2u+fzb2AVoIbv5bOJ/CaF+PvqILUyDUr0GmuLTs1+q6tgmkHFI8fyjm6ueU0Ot8 xCpF7nQ2wNEZoBtHI6CS2lG/5g+RYsmRcpTDBEaxaHzEPYtkgbxMaJ7aG4Zo= Received: by mailuser.nyi.internal (Postfix, from userid 99) id B5939A87E7; Fri, 3 Jun 2016 07:59:25 -0400 (EDT) Message-Id: <1464955165.2560710.626896049.52EA8E0B@webmail.messagingengine.com> X-Sasl-Enc: SCCJfbIDVBRix8R7KU50escwNjQe8/bUrYUZInSU8E4r 1464955165 From: Alexey Melnikov To: Kevin Ma J , cdni@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-38f217ef In-Reply-To: References: <1464861734.1246901.625717065.0912CC9E@webmail.messagingengine.com> Date: Fri, 03 Jun 2016 12:59:25 +0100 Archived-At: Subject: Re: [CDNi] Early AD review of draft-ietf-cdni-metadata-17 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 03 Jun 2016 11:59:29 -0000 Hi Kevin, On Thu, Jun 2, 2016, at 08:51 PM, Kevin Ma J wrote: > Hi Alexey, > > inline: > > > -----Original Message----- > > From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Alexey Melnikov > > Sent: Thursday, June 02, 2016 6:02 AM > > To: cdni@ietf.org > > Subject: [CDNi] Early AD review of draft-ietf-cdni-metadata-17 > > > > In order to speed up publication of this draft, I decided to do early AD > > review. Here are my comments. My apologies if they are a bit cryptic, if > > you are unsure of what I meant, please ask! > > > > In 1.2: content can only be delivered using HTTP/1.1 and not HTTP/1.1 > > over TLS? Is last para saying that this is an unsolved problem (e.g. > > LURK BOF solution is needed)? > > Essentially, yes. We had considered trying to define a way to pass certs > and keys around, but in general it seemed like a bad idea. A LURK-like > solution would help. Ok. > > In 4.1.2: hostname and IP addresses need to have defined syntaxes (at > > least by reference). You also need to say whether IDN domain names are > > allowed here. > > I actually just removed the references, since they seemed redundant. The > host property is of type "Endpoint" which is defined in 4.3.3. I can add > it back if you feel it's not readable as is. I would rather you do. I like references :-). > > In 4.1.5: does "case insensitive" only applies to ASCII range? I.e., > > encoded UTF-8 sequences in URIs are not affected. > > I would expect this to apply to the percent encoded values, not the > decoded values, i.e., I would expect "%4A" to be compared as "%4a" and > not "j". Is that what you mean? > > Ben, do you agree? > > We can clarify that. > > > In 4.2.6: URI needs a Normative Reference (RFC 3986). > > Done. I assume you mean wrt the ignore-query-string property description > "URI query string parameters"? Yes. > > In 4.3.7: need a reference to a document/registry defining ASNs. > > Added reference to RFC6793. > > > In 6.1: need a reference to HTTP/1.1 spec. > > Added a reference to RFC7230. > > > Should OPTIONS method be allowed? > > I'll defer to Ben on this one. > > > In 6.2/6.3: Is discovery of the initial URI truly out of scope? You can > > define a .well-known URI to allow bootstrapping. > > If it is defined, is it likely to be used? > > This is similar to Triggers > (https://tools.ietf.org/html/draft-ietf-cdni-control-triggers-15#section-4) > in that it is assumes the CDNs would exchange that information > out-of-band, or that some other bootstrap API would be defined. > > wrt .well-known, the dCDN (in the case of metadata; the uCDN in the case > of triggers) would still need to have a hostname configured? There was > some discussion a while back > (https://mailarchive.ietf.org/arch/msg/cdni/9JUdlQk0fD4_0Lhm1lj7_U7QfcM) > about using a "well-known" URI for retrieving bootstrap information for > all interfaces, but it was not followed up. Ok, I will read this. > > In 7.3: Nit: HTTP/1.1 over TLS needs 2 references, not just one. > > The other reference being? > What if we just used 7230? + RFC 2818. > More generally, though, do you think we need to adjust the registry > structure to have a list of Protocol Specs? I am not sure what you mean. The current table looks fine to me (other than missing references). > > In 7.4: I think I am sad that you haven't defined any initial > > authentication mechanism. Has this been discussed in the WG? > > > > In 8.1, last para: a requirement to implement mutual authentication is > > underspecified. Do you mean TLS mutual authentication? If yes, say so. > > If other mechanisms can be used, say so as well. > > If you meant to reference 8.5 here, please do so. > > > > Why is this only a SHOULD (and not a MUST)? > > Sections 8.1-8.4 were intended to lead into 8.5 > Changed the SHOULDs to MUSTs and added references to 8.5 > > thanx. Much better! > -- Kevin J. Ma > > > In 8.2: similarly, how can the SHOULD be satisfied? Do you mean TLS or > > something else? Reference 8.5? > > > > In 8.3: similar issue. > > > > Also encryption doesn't necessarily provide integrity of data, so the > > last sentence sounds wrong. > > > > In 8.4: similar issue. From nobody Tue Jun 7 12:15:29 2016 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 8E83612D528 for ; Tue, 7 Jun 2016 12:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEXTEc9j8v71 for ; Tue, 7 Jun 2016 12:15:26 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1634A12D504 for ; Tue, 7 Jun 2016 12:15:26 -0700 (PDT) X-AuditID: c6180641-f796f6d000000e1e-f9-57571d14dc80 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 4C.5F.03614.41D17575; Tue, 7 Jun 2016 21:14:28 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0294.000; Tue, 7 Jun 2016 15:15:24 -0400 From: Kevin Ma J To: "'cdni@ietf.org'" Thread-Topic: Working Group Last Call on draft-ietf-cdni-metadata-17 Thread-Index: AdG1E1bb+DcmCcimThChvHm8GcgjbwLJeRWQ Date: Tue, 7 Jun 2016 19:15:24 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyuXSPt66IbHi4waOlahZPZ/9hdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsxX/5gL9rBXPDh8ja2B8Q1rFyMnh4SAicTVzptMELaYxIV7 69m6GLk4hASOMkq8mjyXCcJZxihx6tlfsA42AS2Jx1//AiU4OEQEVCXOfC0GCQsLOEvc7ZvE AhF2kdiyWw4kLCJgJHGkcx47iM0ioCJxZNc0sCm8Ar4SHY2vweKMQHu/n1oDdgOzgLjErSfz oe4RkFiy5zwzhC0q8fLxP6iblSQ+/p7PDlGvI7Fg9yc2CFtbYtnC18wQ8wUlTs58wjKBUXgW krGzkLTMQtIyC0nLAkaWVYwcpcUFObnpRoabGIFhfEyCzXEH495ez0OMAhyMSjy8C7TCwoVY E8uKK3MPMUpwMCuJ8N6UCg8X4k1JrKxKLcqPLyrNSS0+xCjNwaIkzqv/UjFcSCA9sSQ1OzW1 ILUIJsvEwSnVwBi0SDd0TldNjfLr57mXrsUfuX4v+XKwr82kiRsdjx9ZtFchPcO1+fybCQ+U XhyZIiyz5UOFrcTBXfH/nZU69LWjXjAVXuRdZbRhx/FL6qd79d4unXHIMLl8uu7aiMm+y/05 gg/92HaniJ+hNXpn25ltaxZLzVqb7/vb+NK1fykJJsa76qJqrqUrsRRnJBpqMRcVJwIAnKUm Pl8CAAA= Archived-At: Subject: Re: [CDNi] Working Group Last Call on draft-ietf-cdni-metadata-17 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 07 Jun 2016 19:15:27 -0000 Hi All, (As a chair) The two week WGLC for draft-ietf-cdni-metadata-17 has expire= d. If anyone has any further comments, please send mail to the list. (As an author) Thanks to Alexey for providing early AD comments. We will= post an updated draft shortly which should address the comments received. thanx! -- Kevin J. Ma > -----Original Message----- > From: Kevin Ma J > Sent: Tuesday, May 24, 2016 10:46 AM > To: cdni@ietf.org > Subject: Working Group Last Call on draft-ietf-cdni-metadata-17 >=20 > Hi All, >=20 > As per the discussion in BA, we would like to move the Metadata > Interface draft to WGLC. >=20 > Today will begin the two-week WGLC on: > https://tools.ietf.org/html/draft-ietf-cdni-metadata-17 >=20 > Please send any comments, questions, concerns to the CDNI mailing list: > cdni@ietf.org >=20 > The WGLC will end on Tuesday June 7, 2016. >=20 > thanx! >=20 > -- Kevin and Francois From nobody Wed Jun 8 01:22:33 2016 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 CFF3112D0F0; Wed, 8 Jun 2016 01:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 9isvIzcXkzAS; Wed, 8 Jun 2016 01:22:31 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::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 DC2F912D10B; Wed, 8 Jun 2016 01:22:30 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id v199so52096711wmv.0; Wed, 08 Jun 2016 01:22:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=95PcXJOcNA2czb2JIZ1k7gjnuJIm2l4/v+2O1iyVkzU=; b=GOTc6lzwN+J/nGAApF2vFZwButFu57IGtPZ/C/PkbWvH8e817sIWq9qkhM64tDnRM8 kAO6FHWqBd++mnUQml8aH7Knw3+tspHbAjEsg3rSQIVHcb7lMeXth50OTQUdhL0VFn5F f8nsajCWcwM+D6kc/Zp52RqrVhDHLR9KLFafvGeyEizxT2f/cSbO7OfmrCBGUVb06z5O h+W/5UxL8gCRt49VoHyA5reBSWLTQpIpwmjMXaHBaSeclDDeCBvbXls1WKyYzWumVOUd T1NqBHG0+xQreLum5Up4FKwQDvFrk79VoESxYv1RBERSqTHQBBMe8Axun5NaX9Ra7HNZ JtQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=95PcXJOcNA2czb2JIZ1k7gjnuJIm2l4/v+2O1iyVkzU=; b=RkJUdlKs6I9XdEEBeR/YL9MwflhHy39x4lmSib1uZpRJnZy2et/VuVFhkepi0ycE5K oKMJajFnPgJ6N/Z8q/PJkG6h3OUOv0oHWAp65AVo7fS37L6oBID48GAvd7x6DJgP1tHO hnXaRG8q6vmn5RTGK5rqCYaWNg7XhBG7GJqLUN5a4uRH6vu7UVe6BVMtffHt5PjNcP4p xK00WCO3AksBscL1yZdmRbnf1Gk2d6YXMDFJlrc8esl/kjo2z7BrcLLK9y0kHXqDfRWF DOFc3+WWZMCAoFQx+IFO/4ubwiAuoTBYSx8gtMCEtaeXUpXoG/+tH/BuXWgTTarK30nE xSIA== X-Gm-Message-State: ALyK8tIAECj8CcBBt3cWhIlmmhtTBc201yzFqgWEs59i1y6h7CXcieQ/a2r/NDTaWt0Ytw== X-Received: by 10.195.9.67 with SMTP id dq3mr3521148wjd.140.1465374149105; Wed, 08 Jun 2016 01:22:29 -0700 (PDT) Received: from [192.168.1.21] (125.216.113.78.rev.sfr.net. [78.113.216.125]) by smtp.gmail.com with ESMTPSA id s125sm23328074wms.14.2016.06.08.01.22.27 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 08 Jun 2016 01:22:28 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Francois Le Faucheur In-Reply-To: <56C6B19F-8207-4250-B1D5-055CF67968DB@fastmail.fm> Date: Wed, 8 Jun 2016 10:22:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160529114300.27632.32780.idtracker@ietfa.amsl.com> <56C6B19F-8207-4250-B1D5-055CF67968DB@fastmail.fm> To: Alexey Melnikov X-Mailer: Apple Mail (2.3124) Archived-At: Cc: draft-ietf-cdni-logging@ietf.org, cdni-chairs@ietf.org, The IESG , cdni@ietf.org Subject: Re: [CDNi] Alexey Melnikov's No Objection on draft-ietf-cdni-logging-26: (with COMMENT) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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 Jun 2016 08:22:33 -0000 Hi Alexey, > On 1 Jun 2016, at 20:47, Alexey Melnikov = wrote: >=20 > Hi Francois, >=20 > On 1 Jun 2016, at 17:17, Francois Le Faucheur = wrote: >=20 >>> In 7.1, last sentence: TLS only provides for protection from = tampering >>> when in transit, not when a log file being stored. >>=20 >> I already responded to that point and corrected the sentence so it = now reads: >> =E2=80=9C >> Protection against third party tampering, when the CDNI Logging File = is communicated over the CDN Logging Interface, can be achieved as = discussed above through the use of TLS. >> =E2=80=9C >>=20 >> Is it not acceptable ? >=20 > Sorry, missed that. Yes, this is an improvement. >=20 > Can anything be said about data at rest? The document already has a specific statement wrt data at rest regarding = privacy protection : =E2=80=9C The algorithmic mapping and variation over time MAY allow the uCDN =E2=80=A6= to reconstruct the actual client IPv4 or IPv6 address and/or other = network-level identifying information when required =E2=80=A6 . = However, these enduser addresses SHOULD only be reconstructed on-demand = and the CDNI Logging File SHOULD only be stored with the anonymised = c-groupid value. " The paragraph we were discussing, in the context of your COMMENT, = relates to integrity protection. We clarified that the statement about = integrity protection applies when the data is in flight. When the data = is at rest, I don=E2=80=99t think we need to discuss integrity = protection since the data exchanged via CDNI LI interface can be = processed by the uCDN as it sees fit (e.g. aggregate CDNI Logging Files = with its own local logging records, e.g. filter/sanitise/summarize in = order to export to the Content Service Provider, etc.) so it is = legitimate that the uCDN can modify the data, once properly communicated = via the CDNI LI interface. So to me, we are already covered. Cheers Francois From nobody Wed Jun 8 02:07:22 2016 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 904DF12D86E; Wed, 8 Jun 2016 02:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 IYUU-H3UTvIg; Wed, 8 Jun 2016 02:07:18 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::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 35FCA12D534; Wed, 8 Jun 2016 02:07:18 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id k184so15287759wme.1; Wed, 08 Jun 2016 02:07:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=I04K1S6RcZR+ZiDM+FmZ7e1QCHylh1Zdwd2SriMieL4=; b=v5pIkZX6iLUmTv/d6m2zooH/0TWcmyeSPkLjwcskFCQC9Vx11QGEw8ACKBPqaKdzUc adFRf4yCbdsE07dHWGw3AX4DZSK1xH4CxyT5iJ91n0SzxN/GZjCuF213+DdmcWnGcGzz /ZiT2zdg1oshnU+4RnPH+rYfMHfKJfVkbjinZX020wfhAX+ArzYDxs1z4Rl8tBnmL6T5 X+/mjCE+2jHdymT1cMF9sL63XYqkd8q7i2oGm0OLSwgyNQ9tZVCuGiltUrVkWBRtaJ0A sF6LwDMKbxmBl0Ek3DDv6F8SRBK2byzNt0328bWBcw6UmBjUh6HXHE9hxEDpoJ/cD3L2 5Qww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=I04K1S6RcZR+ZiDM+FmZ7e1QCHylh1Zdwd2SriMieL4=; b=E1cBFCQLop+NE+01Nx3tpNLGUzsGIY0e7PDGodRJ+Zbi/477PEIG8XfVLbLCm7kG48 rLhZMmsHYdg6FmkWD96nCPorC4IjKvstoNr9CgKbZJG1jsnwHE8yD/PqWlcY1D89o/Av ecmPWYKkwCV8g0avlZRa4yJzxBCL2fO+LbDW56qdGwfOSxyWc/RBm+kah9SF691wZhj9 dU7WwHOEDWKmDV3xMhU9yrDi7kTpuaQgbYpHuB6cVqjsoSXJl9LLRDldL+vDyHXgW14N Z3ny6QYRLtTJzZMbfOOtVArpllA7zLGxPsEd1R3TJtiD/W7+tfg6X3FnoPCqbeOWpgGp zzwg== X-Gm-Message-State: ALyK8tLNDZPC70F1MiV2idDFFa/Q5gacojs9b1gbxEulvkgRvk/bSi91+y71sUkmonnOoA== X-Received: by 10.28.12.199 with SMTP id 190mr3607249wmm.15.1465376836574; Wed, 08 Jun 2016 02:07:16 -0700 (PDT) Received: from [192.168.1.21] (125.216.113.78.rev.sfr.net. [78.113.216.125]) by smtp.gmail.com with ESMTPSA id w16sm939436wmw.6.2016.06.08.02.07.14 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 08 Jun 2016 02:07:15 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Francois Le Faucheur In-Reply-To: <59AB96A8-B811-443A-8256-54D45141F96E@gmail.com> Date: Wed, 8 Jun 2016 11:07:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160518223257.14733.37895.idtracker@ietfa.amsl.com> <3E2786B2-9204-447C-9A53-A3CB0213E0F5@niven-jenkins.co.uk> <573CFEC8.8010600@cs.tcd.ie> <5DED924E-C407-44E9-8FF1-477B26B69647@niven-jenkins.co.uk> <573D09D5.1020501@cs.tcd.ie> <573D19C3.3050304@cs.tcd.ie> <59AB96A8-B811-443A-8256-54D45141F96E@gmail.com> To: Niven-Jenkins Ben , Stephen Farrell , Ben Campbell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: draft-ietf-cdni-logging@ietf.org, The IESG , "" , cdni-chairs@ietf.org Subject: Re: [CDNi] Ben Campbell's Discuss on draft-ietf-cdni-logging-25: (with DISCUSS and COMMENT) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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 Jun 2016 09:07:21 -0000 Folks, Here is the rewritten paragraph about the potential privacy concerns = related to communicating details information to the uCDN: " When HTTP redirection is used between the uCDN and the dCDN, making detailed CDNI logging information known to the uCDN does not represent a particular privacy concern because the uCDN is already exposed at request redirection time to most of the information that shows up as CDNI logging information (e.g., enduser IP@, URL, HTTP headers). When DNS redirection is used between the uCDN and the dCDN, there are cases where there is no privacy concern in making detailed CDNI logging information known to the uCDN; this may be the case, for example, where (1) it is considered that because the uCDN has the authority (with respect to the CSP) and control on how the requests are delivered (including whether it is served by the uCDN itself or by a dCDN), the uCDN is entitled to access all detailed information related to the corresponding deliveries, and (2) there is no legal reasons to restrict access by the uCDN to all these detailed information. Conversely, still when DNS redirection is used between the uCDN and the dCDN, there are cases where there may be some privacy concern in making detailed CDNI logging information known to the uCDN; this may be the case, for example, because the uCDN is in a different jurisdiction to the dCDN resulting is some legal reasons to restrict access by the uCDN to all the detailed information related to the deliveries. In this latter case, the privacy concern can be taken into account when the uCDN and dCDN agree about which fields are to be conveyed inside the CDNI Logging Files and which privacy protection mechanism is to be used as discussed in the definition of the c-groupid field specified in Section 3.4.1. =E2=80=9C Cheers Francois > On 1 Jun 2016, at 18:47, Francois Le Faucheur = wrote: >=20 > Folks, >=20 > My conclusion from that thread is: > * the current argument for why there is no privacy concern in = communicating the CDNI Logging File to the uCDN holds for HTTP=20 > * for DNS, the current argument does not hold as currently = written > * for DNS, my proposal is to: > - capture Ben NJ=E2=80=99s argument (but with a caveat): = because the uCDN is the =E2=80=9Cauthoritative=E2=80=9D CDN (i.e. the = CDN that has control about how the request is delivered and by itself of = by another CDN) and has the responsibility of each and every delivery, = it _may_ not be a privacy concern to communicate detailed logging = information to the uCDN.=20 > - in scenarios where there are some privacy concerns = (e.g. because of different regulations applying to uCDN and dCDN), then = this can be taken into account when uCDN and dCDN agree on which fields = to convey inside the CDNI Logging Files and which privacy protection = mechanisms are to be used (such as the c-groupid, and which mapping is = used for the c-groupid). >=20 > Let me know if that is not acceptable, and can be improved. >=20 > Cheers >=20 > Francois >=20 >=20 >> On 19 May 2016, at 17:42, Ben Niven-Jenkins = wrote: >>=20 >>=20 >>> On 19 May 2016, at 02:41, Stephen Farrell = wrote: >>>=20 >>> Cutting to (I think) the substantive bit... >>>=20 >>> On 19/05/16 02:11, Ben Niven-Jenkins wrote: >>>> My intention was to express my opinion that because the uCDN could >>>> have chosen to perform the content delivery itself the dCDN is not >>>> exposing any more information to the uCDN than the uCDN could have >>>> chosen to gather itself if it so desired and therefore IMO there is >>>> no need to provide different guidance for DNS redirection than for >>>> HTTP redirection. >>>=20 >>> Yes, I've seen arguments of that form offered a number of times. >>> I don't find it convincing myself, but recognise that other folks >>> do. And in every case so far, neither side has convinced the other, >>> and sometimes not even understood one another. But let's see if >>> we (me really:-) get better with practice... >>>=20 >>> In this case I'd argue that the "could have chosen" isn't really >>> true - presumably the uCDN deals with the dCDN because it's hard(er) >>> for the uCDN to do the work directly, so it's not really true that >>> the uCDN could have chosen to access the information, at least not >>> at the same cost. >>=20 >> True, but there are lots of possibilities for why the uCDN would;t do = it itself or why it might those to do the content delivery itself if it = was so inclined, e.g. maybe if the uCDN is really interested in invading = user=E2=80=99s privacy, what it gains from that outweighs the additional = cost of performing the delivery itself. Who knows, I don=E2=80=99t think = we can try and account for all that variation. >>=20 >>> And there may be aspects of meta-data that are just different = because >>> the access was via the dCDN, e.g. perhaps some other client IP = address >>> gets used if somethings multihomed, or some ISP infrastructure = differs, >>> e.g. HTTP Forwarded might be present and visible to the dCDN but = with >>> no similar thing for DNS (or vice versa). I'd not be surprised if = even >>> more subtle differences existed over populations of transactions and >>> users and CDNs. >>=20 >> I=E2=80=99m sure there are all sort of things like you suggest above. = What is not at all clear to me is what specifically the logging draft is = meant to do about it. >>=20 >> Ultimately it=E2=80=99s a tradeoff I think. I=E2=80=99m not sure = we=E2=80=99ll ever agree. >>=20 >> I have nothing more to say that won=E2=80=99t end up just rehashing = discussions we=E2=80=99ve already had so I don=E2=80=99t intend on = participating in this thread any longer. >>=20 >> Ben >>=20 >=20 From nobody Wed Jun 8 06:17:19 2016 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 E747312D92A; Wed, 8 Jun 2016 06:17:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160608131715.20067.9182.idtracker@ietfa.amsl.com> Date: Wed, 08 Jun 2016 06:17:15 -0700 Archived-At: Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-logging-27.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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 Jun 2016 13:17:16 -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 of the IETF. Title : CDNI Logging Interface Authors : Francois Le Faucheur Gilles Bertrand Iuniana Oprescu Roy Peterkofsky Filename : draft-ietf-cdni-logging-27.txt Pages : 59 Date : 2016-06-08 Abstract: This memo specifies the Logging interface between a downstream CDN (dCDN) and an upstream CDN (uCDN) that are interconnected as per the CDN Interconnection (CDNI) framework. First, it describes a reference model for CDNI logging. Then, it specifies the CDNI Logging File format and the actual protocol for exchange of CDNI Logging Files. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-logging/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-cdni-logging-27 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-logging-27 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 Jun 8 06:21:58 2016 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 EA55912D0DA for ; Wed, 8 Jun 2016 06:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 fYGTDB-t3CdD for ; Wed, 8 Jun 2016 06:21:49 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 904BE12D92B for ; Wed, 8 Jun 2016 06:21:49 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id n184so181568427wmn.1 for ; Wed, 08 Jun 2016 06:21:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rYVuwgzUa9l3trl3Q8uqhVVUc7uV+3Rpwc7KzBqujuw=; b=PrLo4k2cm7QlXXtFMi6bTORrcmSE3JzQKkTS+MKgjtI4wHh3tgWhdRMbf4CmkTfUxi PhO2lr+B/hLvFkV+dqfk/ImV9ItJ7JyXKJhfPBM58DbLv7GY1rkJhN0OtDrUSLNhGrwT d3w5wxgcDMfa610xFYySNRn5Ojvt8c3BtdCakyUIylgM0EDMdOkStz5k/gKytjvbKp/B n91tpirnUFNPzWd7l2fLI26KybPNNjKUkO61aqNWr1+njuqY1GQNbHR2d/rTcqiEa4Xx d5X2JmOgkdzwq4NYGur1RyH/3qa7grkVciKuvBBY7wFN/wJXshx+eM9w0SKiuco7XP11 y0aA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rYVuwgzUa9l3trl3Q8uqhVVUc7uV+3Rpwc7KzBqujuw=; b=L80beVBqXd+X8R40qL92VcwhQNcCtjr8vJVRjDatpjluVl/VxfVkhi78EMy9dh3gDM WxdeqeElv9BENVBmI4fV2EQLTrAEttN+7RKFkCQnU7uuaBClyaAIEeOoTVda3KbLgj0U WKD6tVcSgHppOGQxWoXSi2Aw3lJtEAKaVCd7ZmQk7FJJB+8roTs1HIFKRfAmTEBsI5a+ vEUwbRTAK+gw8F8rC3WKsa6tytuOsD5TUI1oE/M09pejt4BwEDdKNflCJGdCnkYHodE2 3F6Gv9ZO6Q2z9UYvuNjWSGyO7SOMEAG52Q9LnpPmwwZ6ABY9nIbu61Xc67yb4Kmfig+d 8PTQ== X-Gm-Message-State: ALyK8tLoZKVLWOtfrGHwho+WV+E/Wbri+Idccpc9t2i30u2JvIyF68XUzmkVUXjmdhzX0w== X-Received: by 10.28.148.210 with SMTP id w201mr8286123wmd.63.1465392107615; Wed, 08 Jun 2016 06:21:47 -0700 (PDT) Received: from [192.168.1.21] (125.216.113.78.rev.sfr.net. [78.113.216.125]) by smtp.gmail.com with ESMTPSA id kc2sm1536874wjb.5.2016.06.08.06.21.46 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 08 Jun 2016 06:21:46 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Francois Le Faucheur In-Reply-To: <20160608131715.20067.9182.idtracker@ietfa.amsl.com> Date: Wed, 8 Jun 2016 15:21:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <52E0B3B9-6DB4-46E5-B069-97F60940FA62@gmail.com> References: <20160608131715.20067.9182.idtracker@ietfa.amsl.com> To: Alexey Melnikov , Ben Campbell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "" , Stephen Farrell Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-logging-27.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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 Jun 2016 13:21:54 -0000 Alexey, Ben , Version -27 includes all the proposed resolutions discussed on the list. I hope this will allow Ben to clear his =E2=80=9CDiscuss=E2=80=9D = position. Thanks again for your reviews and comments. Cheers Fran=C3=A7ois (as an editor) > On 8 Jun 2016, at 15:17, internet-drafts@ietf.org wrote: >=20 >=20 > 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 of the IETF. >=20 > Title : CDNI Logging Interface > Authors : Francois Le Faucheur > Gilles Bertrand > Iuniana Oprescu > Roy Peterkofsky > Filename : draft-ietf-cdni-logging-27.txt > Pages : 59 > Date : 2016-06-08 >=20 > Abstract: > This memo specifies the Logging interface between a downstream CDN > (dCDN) and an upstream CDN (uCDN) that are interconnected as per the > CDN Interconnection (CDNI) framework. First, it describes a > reference model for CDNI logging. Then, it specifies the CDNI > Logging File format and the actual protocol for exchange of CDNI > Logging Files. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-cdni-logging/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-cdni-logging-27 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-27 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Wed Jun 8 07:33:56 2016 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 49DE412D559; Wed, 8 Jun 2016 07:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.325 X-Spam-Level: X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426] autolearn=unavailable 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 u6xiVqiDuFOy; Wed, 8 Jun 2016 07:33:52 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 60B8812D594; Wed, 8 Jun 2016 07:33:52 -0700 (PDT) Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u58EXjhX070122 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 8 Jun 2016 09:33:45 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4] From: "Ben Campbell" To: "Francois Le Faucheur" Date: Wed, 08 Jun 2016 09:33:50 -0500 Message-ID: <3850695D-BA08-46E3-9D85-A098C3FB0369@nostrum.com> In-Reply-To: References: <20160518223257.14733.37895.idtracker@ietfa.amsl.com> <3E2786B2-9204-447C-9A53-A3CB0213E0F5@niven-jenkins.co.uk> <573CFEC8.8010600@cs.tcd.ie> <5DED924E-C407-44E9-8FF1-477B26B69647@niven-jenkins.co.uk> <573D09D5.1020501@cs.tcd.ie> <573D19C3.3050304@cs.tcd.ie> <59AB96A8-B811-443A-8256-54D45141F96E@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_99FAA1CE-9221-45A5-9232-ADD613CAA33E_=" Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: cdni@ietf.org, cdni-chairs@ietf.org, The IESG , draft-ietf-cdni-logging@ietf.org, Stephen Farrell Subject: Re: [CDNi] Ben Campbell's Discuss on draft-ietf-cdni-logging-25: (with DISCUSS and COMMENT) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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 Jun 2016 14:33:55 -0000 --=_MailMate_99FAA1CE-9221-45A5-9232-ADD613CAA33E_= Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit That paragraph works for me in general, with one comment: Maybe I missed something in the conversation, but is there a reason to describe (2) as no _legal_ reasons? Could you drop the word "legal"? Thanks! Ben. On 8 Jun 2016, at 4:07, Francois Le Faucheur wrote: > Folks, > > Here is the rewritten paragraph about the potential privacy concerns > related to communicating details information to the uCDN: > > " > When HTTP redirection is used between the uCDN and the dCDN, making > detailed CDNI logging information known to the uCDN does not > represent a particular privacy concern because the uCDN is already > exposed at request redirection time to most of the information that > shows up as CDNI logging information (e.g., enduser IP@, URL, HTTP > headers). When DNS redirection is used between the uCDN and the > dCDN, there are cases where there is no privacy concern in making > detailed CDNI logging information known to the uCDN; this may be > the > case, for example, where (1) it is considered that because the uCDN > has the authority (with respect to the CSP) and control on how the > requests are delivered (including whether it is served by the uCDN > itself or by a dCDN), the uCDN is entitled to access all detailed > information related to the corresponding deliveries, and (2) there > is > no legal reasons to restrict access by the uCDN to all these > detailed > information. Conversely, still when DNS redirection is used > between > the uCDN and the dCDN, there are cases where there may be some > privacy concern in making detailed CDNI logging information known > to > the uCDN; this may be the case, for example, because the uCDN is in > a > different jurisdiction to the dCDN resulting is some legal reasons > to > restrict access by the uCDN to all the detailed information related > to the deliveries. In this latter case, the privacy concern can be > taken into account when the uCDN and dCDN agree about which fields > are to be conveyed inside the CDNI Logging Files and which privacy > protection mechanism is to be used as discussed in the definition > of > the c-groupid field specified in Section 3.4.1. > “ > > Cheers > > Francois > > > > >> On 1 Jun 2016, at 18:47, Francois Le Faucheur >> wrote: >> >> Folks, >> >> My conclusion from that thread is: >> * the current argument for why there is no privacy concern in >> communicating the CDNI Logging File to the uCDN holds for HTTP >> * for DNS, the current argument does not hold as currently written >> * for DNS, my proposal is to: >> - capture Ben NJ’s argument (but with a caveat): because the uCDN >> is the “authoritative” CDN (i.e. the CDN that has control about >> how the request is delivered and by itself of by another CDN) and has >> the responsibility of each and every delivery, it _may_ not be a >> privacy concern to communicate detailed logging information to the >> uCDN. >> - in scenarios where there are some privacy concerns (e.g. because >> of different regulations applying to uCDN and dCDN), then this can be >> taken into account when uCDN and dCDN agree on which fields to convey >> inside the CDNI Logging Files and which privacy protection mechanisms >> are to be used (such as the c-groupid, and which mapping is used for >> the c-groupid). >> >> Let me know if that is not acceptable, and can be improved. >> >> Cheers >> >> Francois >> >> >>> On 19 May 2016, at 17:42, Ben Niven-Jenkins >>> wrote: >>> >>> >>>> On 19 May 2016, at 02:41, Stephen Farrell >>>> wrote: >>>> >>>> Cutting to (I think) the substantive bit... >>>> >>>> On 19/05/16 02:11, Ben Niven-Jenkins wrote: >>>>> My intention was to express my opinion that because the uCDN could >>>>> have chosen to perform the content delivery itself the dCDN is not >>>>> exposing any more information to the uCDN than the uCDN could have >>>>> chosen to gather itself if it so desired and therefore IMO there >>>>> is >>>>> no need to provide different guidance for DNS redirection than for >>>>> HTTP redirection. >>>> >>>> Yes, I've seen arguments of that form offered a number of times. >>>> I don't find it convincing myself, but recognise that other folks >>>> do. And in every case so far, neither side has convinced the other, >>>> and sometimes not even understood one another. But let's see if >>>> we (me really:-) get better with practice... >>>> >>>> In this case I'd argue that the "could have chosen" isn't really >>>> true - presumably the uCDN deals with the dCDN because it's >>>> hard(er) >>>> for the uCDN to do the work directly, so it's not really true that >>>> the uCDN could have chosen to access the information, at least not >>>> at the same cost. >>> >>> True, but there are lots of possibilities for why the uCDN would;t >>> do it itself or why it might those to do the content delivery itself >>> if it was so inclined, e.g. maybe if the uCDN is really interested >>> in invading user’s privacy, what it gains from that outweighs the >>> additional cost of performing the delivery itself. Who knows, I >>> don’t think we can try and account for all that variation. >>> >>>> And there may be aspects of meta-data that are just different >>>> because >>>> the access was via the dCDN, e.g. perhaps some other client IP >>>> address >>>> gets used if somethings multihomed, or some ISP infrastructure >>>> differs, >>>> e.g. HTTP Forwarded might be present and visible to the dCDN but >>>> with >>>> no similar thing for DNS (or vice versa). I'd not be surprised if >>>> even >>>> more subtle differences existed over populations of transactions >>>> and >>>> users and CDNs. >>> >>> I’m sure there are all sort of things like you suggest above. What >>> is not at all clear to me is what specifically the logging draft is >>> meant to do about it. >>> >>> Ultimately it’s a tradeoff I think. I’m not sure we’ll ever >>> agree. >>> >>> I have nothing more to say that won’t end up just rehashing >>> discussions we’ve already had so I don’t intend on participating >>> in this thread any longer. >>> >>> Ben >>> >> --=_MailMate_99FAA1CE-9221-45A5-9232-ADD613CAA33E_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

That paragraph works for me in general, with one comment:= Maybe I missed something in the conversation, but is there a reason to d= escribe (2) as no legal reasons? Could you drop the word "legal"= ?

Thanks!

Ben.

On 8 Jun 2016, at 4:07, Francois Le Faucheur wrote:

Folks,

Here is the rewritten paragraph about the potential priva= cy concerns related to communicating details information to the uCDN:

=

"
When HTTP redirection is used between the uCDN and the dCDN, making detailed CDNI logging information known to the uCDN does not
represent a particular privacy concern because the uCDN is already
= exposed at request redirection time to most of the information that shows up as CDNI logging information (e.g., enduser IP@, URL, HTTP
= headers). When DNS redirection is used between the uCDN and the
dCDN, there are cases where there is no privacy concern in making
detailed CDNI logging information known to the uCDN; this may be the case, for example, where (1) it is considered that because the uCDN has the authority (with respect to the CSP) and control on how the
= requests are delivered (including whether it is served by the uCDN
= itself or by a dCDN), the uCDN is entitled to access all detailed
information related to the corresponding deliveries, and (2) there is<= br> no legal reasons to restrict access by the uCDN to all these detailed<= br> information. Conversely, still when DNS redirection is used between the uCDN and the dCDN, there are cases where there may be some
privacy concern in making detailed CDNI logging information known to the uCDN; this may be the case, for example, because the uCDN is in a<= br> different jurisdiction to the dCDN resulting is some legal reasons to<= br> restrict access by the uCDN to all the detailed information related to the deliveries. In this latter case, the privacy concern can be taken into account when the uCDN and dCDN agree about which fields
= are to be conveyed inside the CDNI Logging Files and which privacy
= protection mechanism is to be used as discussed in the definition of the c-groupid field specified in Section 3.4.1.
=E2=80=9C

Cheers

Francois

On 1 Jun 2016, at 18:47, Francois Le Faucheur flefauch@gmail.com wrote:

Folks,

My conclusion from that thread is:
* the current argument for why there is no privacy concern in communi= cating the CDNI Logging File to the uCDN holds for HTTP
* for DNS, the current argument does not hold as currently written * for DNS, my proposal is to:
- capture Ben NJ=E2=80=99s argument (but with a caveat): because = the uCDN is the =E2=80=9Cauthoritative=E2=80=9D CDN (i.e. the CDN that ha= s control about how the request is delivered and by itself of by another = CDN) and has the responsibility of each and every delivery, it may not be a privacy concern to communicate detailed logging information t= o the uCDN.
- in scenarios where there are some privacy concerns (e.g. becaus= e of different regulations applying to uCDN and dCDN), then this can be t= aken into account when uCDN and dCDN agree on which fields to convey insi= de the CDNI Logging Files and which privacy protection mechanisms are to = be used (such as the c-groupid, and which mapping is used for the c-group= id).

Let me know if that is not acceptable, and can be improve= d.

Cheers

Francois

On 19 May 2016, at 17:42, Ben Niven-Jenkins ben@niven-jenkins.co.uk wrote:

On 19 May 2016, at 02:41, Stephen Farrell stephen.farrell@cs.tcd.ie wrote:

Cutting to (I think) the substantive bit...

On 19/05/16 02:11, Ben Niven-Jenkins wrote:

My intention was to express my opinion that because the u= CDN could
have chosen to perform the content delivery itself the dCDN is not
exposing any more information to the uCDN than the uCDN could have
chosen to gather itself if it so desired and therefore IMO there is
no need to provide different guidance for DNS redirection than for
HTTP redirection.

Yes, I've seen arguments of that form offered a number of= times.
I don't find it convincing myself, but recognise that other folks
do. And in every case so far, neither side has convinced the other,
and sometimes not even understood one another. But let's see if
we (me really:-) get better with practice...

In this case I'd argue that the "could have chosen" isn't= really
true - presumably the uCDN deals with the dCDN because it's hard(er)
for the uCDN to do the work directly, so it's not really true that
the uCDN could have chosen to access the information, at least not
at the same cost.

True, but there are lots of possibilities for why the uCD= N would;t do it itself or why it might those to do the content delivery i= tself if it was so inclined, e.g. maybe if the uCDN is really interested = in invading user=E2=80=99s privacy, what it gains from that outweighs the= additional cost of performing the delivery itself. Who knows, I don=E2=80= =99t think we can try and account for all that variation.

And there may be aspects of meta-data that are just diffe= rent because
the access was via the dCDN, e.g. perhaps some other client IP address gets used if somethings multihomed, or some ISP infrastructure differs, e.g. HTTP Forwarded might be present and visible to the dCDN but with
= no similar thing for DNS (or vice versa). I'd not be surprised if even more subtle differences existed over populations of transactions and
users and CDNs.

I=E2=80=99m sure there are all sort of things like you su= ggest above. What is not at all clear to me is what specifically the logg= ing draft is meant to do about it.

Ultimately it=E2=80=99s a tradeoff I think. I=E2=80=99m n= ot sure we=E2=80=99ll ever agree.

I have nothing more to say that won=E2=80=99t end up just= rehashing discussions we=E2=80=99ve already had so I don=E2=80=99t inten= d on participating in this thread any longer.

Ben

--=_MailMate_99FAA1CE-9221-45A5-9232-ADD613CAA33E_=-- From nobody Wed Jun 8 08:38:20 2016 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 95E7A12D69C; Wed, 8 Jun 2016 08:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 nZp1juDcD_54; Wed, 8 Jun 2016 08:38:12 -0700 (PDT) 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 C3E8312D69B; Wed, 8 Jun 2016 08:38:11 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id m124so22736554wme.1; Wed, 08 Jun 2016 08:38:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=cTm2d4TAXiesZn0DEhEOIaTR9o8Uwd70AhR2d0JbHLg=; b=c2mfA58D7x6Y9LCMO15SmjD/H+cwY0eI6vk5IMsrj+fS8k+Jyb6FqN2JjZO4/xZ45U 1TzMMavOcXHmxzRTRoad9YwITTyNHpnPHgit2npDOGsyrhEL0DwOlOHvzBgh7+kWz6YP hKkpZL+Rhyue5wIJXSSonN6G3xGo7BtxfY9zemm4Pv0Q1m8vdKsqarYeCQXERkfvGfTx EF5zLKTm62akLmGl+ll8w8f6gFendHYAUJaL1czV2eQRg/DvXwbKIAJ/txZyX3kQLdpf 8oq2VCBMGaJx0J23clhpx9Rp8NTgWEPxT8VzBgucG49d5tlK8NUWny+1IWsX8unBotj/ XU4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=cTm2d4TAXiesZn0DEhEOIaTR9o8Uwd70AhR2d0JbHLg=; b=V/gXup1XXU3zQxvbiDLFXS82X+HzYplCLLMEn6cCPW+TcJM+vBYgvT0Xai7nOi2ozP i81klp1Bk7HwGVaYWjHOGWws8AVipuurQU1gIye483vIbtty719NVgtNIq77a93Zk5Nn fSyds06O047jTYUKgvz6Qa/yFy/cOmlQM5UmWGWLHsXBKyl2dbEiSbIV2/oKuR2fepvh oW9+/w8xd8q8pTdnvlBYnkjVJ3DhgzPZrxVNwuqHwk4LRWnPtyeJxlzw4A5zZs0zdjYi r5kdrDKMvGvkUDPLO3PNOH4rnNxuEb5VEK/1sAnB6ATOrqtG65hTGruliVA/GegPWd6A n7UA== X-Gm-Message-State: ALyK8tISYNUT6cH44USmX6Bry5ct4qnYXNzr+WqldiMANL5NrOQ8YAXIT0KaZMfXBQV5rg== X-Received: by 10.28.234.221 with SMTP id g90mr5676035wmi.30.1465400290199; Wed, 08 Jun 2016 08:38:10 -0700 (PDT) Received: from [192.168.1.21] (125.216.113.78.rev.sfr.net. [78.113.216.125]) by smtp.gmail.com with ESMTPSA id p9sm2116682wjv.21.2016.06.08.08.38.08 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 08 Jun 2016 08:38:09 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_AC99D28D-77E0-4ACF-B26A-2158F68CD8CE" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Francois Le Faucheur In-Reply-To: <3850695D-BA08-46E3-9D85-A098C3FB0369@nostrum.com> Date: Wed, 8 Jun 2016 17:38:07 +0200 Message-Id: References: <20160518223257.14733.37895.idtracker@ietfa.amsl.com> <3E2786B2-9204-447C-9A53-A3CB0213E0F5@niven-jenkins.co.uk> <573CFEC8.8010600@cs.tcd.ie> <5DED924E-C407-44E9-8FF1-477B26B69647@niven-jenkins.co.uk> <573D09D5.1020501@cs.tcd.ie> <573D19C3.3050304@cs.tcd.ie> <59AB96A8-B811-443A-8256-54D45141F96E@gmail.com> <3850695D-BA08-46E3-9D85-A098C3FB0369@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: cdni@ietf.org, cdni-chairs@ietf.org, The IESG , draft-ietf-cdni-logging@ietf.org, Stephen Farrell Subject: Re: [CDNi] Ben Campbell's Discuss on draft-ietf-cdni-logging-25: (with DISCUSS and COMMENT) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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 Jun 2016 15:38:14 -0000 --Apple-Mail=_AC99D28D-77E0-4ACF-B26A-2158F68CD8CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Ben, > On 8 Jun 2016, at 16:33, Ben Campbell wrote: >=20 > That paragraph works for me in general, with one comment: Maybe I = missed something in the conversation, but is there a reason to describe = (2) as no legal reasons? Could you drop the word "legal"? >=20 I see. =E2=80=9Clegal=E2=80=9D may be overly restrictive and not = necessarily correct. I am happy to drop the word =E2=80=9Clegal=E2=80=9D (in its two = occurrences). Can you confirm this updated wording works for you: " When HTTP redirection is used between the uCDN and the dCDN, making detailed CDNI logging information known to the uCDN does not represent a particular privacy concern because the uCDN is already exposed at request redirection time to most of the information that shows up as CDNI logging information (e.g., enduser IP@, URL, HTTP headers). When DNS redirection is used between the uCDN and the dCDN, there are cases where there is no privacy concern in making detailed CDNI logging information known to the uCDN; this may be the case, for example, where (1) it is considered that because the uCDN has the authority (with respect to the CSP) and control on how the requests are delivered (including whether it is served by the uCDN itself or by a dCDN), the uCDN is entitled to access all detailed information related to the corresponding deliveries, and (2) there is no reason to restrict access by the uCDN to all these detailed information. Conversely, still when DNS redirection is used between the uCDN and the dCDN, there are cases where there may be some privacy concern in making detailed CDNI logging information known to the uCDN; this may be the case, for example, because the uCDN is in a different jurisdiction to the dCDN resulting is some reasons to restrict access by the uCDN to all the detailed information related to the deliveries. In this latter case, the privacy concern can be taken into account when the uCDN and dCDN agree about which fields are to be conveyed inside the CDNI Logging Files and which privacy protection mechanism is to be used as discussed in the definition of the c-groupid field specified in Section 3.4.1. =E2=80=9C Thanks Fran=C3=A7ois > Thanks! >=20 > Ben. >=20 > On 8 Jun 2016, at 4:07, Francois Le Faucheur wrote: >=20 > Folks, >=20 > Here is the rewritten paragraph about the potential privacy concerns = related to communicating details information to the uCDN: >=20 > " > When HTTP redirection is used between the uCDN and the dCDN, making > detailed CDNI logging information known to the uCDN does not > represent a particular privacy concern because the uCDN is already > exposed at request redirection time to most of the information that > shows up as CDNI logging information (e.g., enduser IP@, URL, HTTP > headers). When DNS redirection is used between the uCDN and the > dCDN, there are cases where there is no privacy concern in making > detailed CDNI logging information known to the uCDN; this may be the > case, for example, where (1) it is considered that because the uCDN > has the authority (with respect to the CSP) and control on how the > requests are delivered (including whether it is served by the uCDN > itself or by a dCDN), the uCDN is entitled to access all detailed > information related to the corresponding deliveries, and (2) there is > no legal reasons to restrict access by the uCDN to all these detailed > information. Conversely, still when DNS redirection is used between > the uCDN and the dCDN, there are cases where there may be some > privacy concern in making detailed CDNI logging information known to > the uCDN; this may be the case, for example, because the uCDN is in a > different jurisdiction to the dCDN resulting is some legal reasons to > restrict access by the uCDN to all the detailed information related > to the deliveries. In this latter case, the privacy concern can be > taken into account when the uCDN and dCDN agree about which fields > are to be conveyed inside the CDNI Logging Files and which privacy > protection mechanism is to be used as discussed in the definition of > the c-groupid field specified in Section 3.4.1. > =E2=80=9C >=20 > Cheers >=20 > Francois >=20 > On 1 Jun 2016, at 18:47, Francois Le Faucheur flefauch@gmail.com = wrote: >=20 > Folks, >=20 > My conclusion from that thread is: > * the current argument for why there is no privacy concern in = communicating the CDNI Logging File to the uCDN holds for HTTP > * for DNS, the current argument does not hold as currently written > * for DNS, my proposal is to: > - capture Ben NJ=E2=80=99s argument (but with a caveat): because the = uCDN is the =E2=80=9Cauthoritative=E2=80=9D CDN (i.e. the CDN that has = control about how the request is delivered and by itself of by another = CDN) and has the responsibility of each and every delivery, it may not = be a privacy concern to communicate detailed logging information to the = uCDN. > - in scenarios where there are some privacy concerns (e.g. because of = different regulations applying to uCDN and dCDN), then this can be taken = into account when uCDN and dCDN agree on which fields to convey inside = the CDNI Logging Files and which privacy protection mechanisms are to be = used (such as the c-groupid, and which mapping is used for the = c-groupid). >=20 > Let me know if that is not acceptable, and can be improved. >=20 > Cheers >=20 > Francois >=20 > On 19 May 2016, at 17:42, Ben Niven-Jenkins ben@niven-jenkins.co.uk = wrote: >=20 > On 19 May 2016, at 02:41, Stephen Farrell stephen.farrell@cs.tcd.ie = wrote: >=20 > Cutting to (I think) the substantive bit... >=20 > On 19/05/16 02:11, Ben Niven-Jenkins wrote: >=20 > My intention was to express my opinion that because the uCDN could > have chosen to perform the content delivery itself the dCDN is not > exposing any more information to the uCDN than the uCDN could have > chosen to gather itself if it so desired and therefore IMO there is > no need to provide different guidance for DNS redirection than for > HTTP redirection. >=20 > Yes, I've seen arguments of that form offered a number of times. > I don't find it convincing myself, but recognise that other folks > do. And in every case so far, neither side has convinced the other, > and sometimes not even understood one another. But let's see if > we (me really:-) get better with practice... >=20 > In this case I'd argue that the "could have chosen" isn't really > true - presumably the uCDN deals with the dCDN because it's hard(er) > for the uCDN to do the work directly, so it's not really true that > the uCDN could have chosen to access the information, at least not > at the same cost. >=20 > True, but there are lots of possibilities for why the uCDN would;t do = it itself or why it might those to do the content delivery itself if it = was so inclined, e.g. maybe if the uCDN is really interested in invading = user=E2=80=99s privacy, what it gains from that outweighs the additional = cost of performing the delivery itself. Who knows, I don=E2=80=99t think = we can try and account for all that variation. >=20 > And there may be aspects of meta-data that are just different because > the access was via the dCDN, e.g. perhaps some other client IP address > gets used if somethings multihomed, or some ISP infrastructure = differs, > e.g. HTTP Forwarded might be present and visible to the dCDN but with > no similar thing for DNS (or vice versa). I'd not be surprised if even > more subtle differences existed over populations of transactions and > users and CDNs. >=20 > I=E2=80=99m sure there are all sort of things like you suggest above. = What is not at all clear to me is what specifically the logging draft is = meant to do about it. >=20 > Ultimately it=E2=80=99s a tradeoff I think. I=E2=80=99m not sure = we=E2=80=99ll ever agree. >=20 > I have nothing more to say that won=E2=80=99t end up just rehashing = discussions we=E2=80=99ve already had so I don=E2=80=99t intend on = participating in this thread any longer. >=20 > Ben >=20 --Apple-Mail=_AC99D28D-77E0-4ACF-B26A-2158F68CD8CE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Ben,

On 8 Jun 2016, at 16:33, Ben Campbell <ben@nostrum.com> = wrote:

That paragraph works for = me in general, with one comment: Maybe I missed something in the = conversation, but is there a reason to describe (2) as no legal reasons? Could you drop the word = "legal"?

I see. =E2=80=9Clegal=E2=80=9D = may be overly restrictive and not necessarily correct.
I am = happy to drop the word =E2=80=9Clegal=E2=80=9D (in its two occurrences). = Can you confirm this updated wording works for you:

"
When HTTP redirection is used = between the uCDN and the dCDN, making
detailed CDNI = logging information known to the uCDN does not
represent a = particular privacy concern because the uCDN is already
exposed at request redirection time to most of the = information that
shows up as CDNI logging information = (e.g., enduser IP@, URL, HTTP
headers). When DNS = redirection is used between the uCDN and the
dCDN, there = are cases where there is no privacy concern in making
detailed CDNI logging information known to the uCDN; this may = be the
case, for example, where (1) it is considered that = because the uCDN
has the authority (with respect to the = CSP) and control on how the
requests are delivered = (including whether it is served by the uCDN
itself or by a = dCDN), the uCDN is entitled to access all detailed
information related to the corresponding deliveries, and (2) = there is
no reason to restrict access by the uCDN to all = these detailed
information. Conversely, still when DNS = redirection is used between
the uCDN and the dCDN, there = are cases where there may be some
privacy concern in = making detailed CDNI logging information known to
the = uCDN; this may be the case, for example, because the uCDN is in a
different jurisdiction to the dCDN resulting is some reasons = to
restrict access by the uCDN to all the detailed = information related
to the deliveries. In this latter = case, the privacy concern can be
taken into account when = the uCDN and dCDN agree about which fields
are to be = conveyed inside the CDNI Logging Files and which privacy
protection mechanism is to be used as discussed in the = definition of
the c-groupid field specified in Section = 3.4.1.
=E2=80=9C

Thanks

Fran=C3=A7ois

Thanks!

Ben.

On 8 Jun 2016, at 4:07, Francois Le Faucheur = wrote:

Folks,

Here is the rewritten paragraph about the = potential privacy concerns related to communicating details information = to the uCDN:

"
When HTTP redirection is used between the uCDN and the dCDN, = making
detailed CDNI logging information known to the uCDN does not
represent a particular privacy concern because the uCDN is already
exposed at request redirection time to most of the information = that
shows up as CDNI logging information (e.g., enduser IP@, URL, HTTP
headers). When DNS redirection is used between the uCDN and the
dCDN, there are cases where there is no privacy concern in making
detailed CDNI logging information known to the uCDN; this may be = the
case, for example, where (1) it is considered that because the = uCDN
has the authority (with respect to the CSP) and control on how the
requests are delivered (including whether it is served by the uCDN
itself or by a dCDN), the uCDN is entitled to access all detailed
information related to the corresponding deliveries, and (2) there = is
no legal reasons to restrict access by the uCDN to all these = detailed
information. Conversely, still when DNS redirection is used = between
the uCDN and the dCDN, there are cases where there may be some
privacy concern in making detailed CDNI logging information known = to
the uCDN; this may be the case, for example, because the uCDN is in = a
different jurisdiction to the dCDN resulting is some legal reasons = to
restrict access by the uCDN to all the detailed information = related
to the deliveries. In this latter case, the privacy concern can = be
taken into account when the uCDN and dCDN agree about which fields
are to be conveyed inside the CDNI Logging Files and which privacy
protection mechanism is to be used as discussed in the definition = of
the c-groupid field specified in Section 3.4.1.
=E2=80=9C

Cheers

Francois

On 1 Jun 2016, at = 18:47, Francois Le Faucheur flefauch@gmail.com wrote:

Folks,

My conclusion from that = thread is:
* the current argument for why there is no privacy concern in = communicating the CDNI Logging File to the uCDN holds for HTTP
* for DNS, the current argument does not hold as currently = written
* for DNS, my proposal is to:
- capture Ben NJ=E2=80=99s argument (but with a caveat): because = the uCDN is the =E2=80=9Cauthoritative=E2=80=9D CDN (i.e. the CDN that = has control about how the request is delivered and by itself of by = another CDN) and has the responsibility of each and every delivery, it = may not be a privacy concern to communicate detailed = logging information to the uCDN.
- in scenarios where there are some privacy concerns (e.g. = because of different regulations applying to uCDN and dCDN), then this = can be taken into account when uCDN and dCDN agree on which fields to = convey inside the CDNI Logging Files and which privacy protection = mechanisms are to be used (such as the c-groupid, and which mapping is = used for the c-groupid).

Let me know if = that is not acceptable, and can be improved.

Cheers

Francois

On 19 May 2016, at = 17:42, Ben Niven-Jenkins ben@niven-jenkins.co.uk wrote:

On 19 May 2016, at = 02:41, Stephen Farrell stephen.farrell@cs.tcd.ie wrote:

Cutting to (I think) the substantive bit...

On 19/05/16 02:11, Ben Niven-Jenkins wrote:

My intention was to = express my opinion that because the uCDN could
have chosen to perform the content delivery itself the dCDN is not
exposing any more information to the uCDN than the uCDN could have
chosen to gather itself if it so desired and therefore IMO there is
no need to provide different guidance for DNS redirection than for
HTTP redirection.

Yes, I've seen arguments of that = form offered a number of times.
I don't find it convincing myself, but recognise that other folks
do. And in every case so far, neither side has convinced the other,
and sometimes not even understood one another. But let's see if
we (me really:-) get better with practice...

In this case I'd argue that the "could have chosen" isn't = really
true - presumably the uCDN deals with the dCDN because it's hard(er)
for the uCDN to do the work directly, so it's not really true that
the uCDN could have chosen to access the information, at least not
at the same cost.

True, but there are lots of = possibilities for why the uCDN would;t do it itself or why it might = those to do the content delivery itself if it was so inclined, e.g. = maybe if the uCDN is really interested in invading user=E2=80=99s = privacy, what it gains from that outweighs the additional cost of = performing the delivery itself. Who knows, I don=E2=80=99t think we can = try and account for all that variation.

And there may be = aspects of meta-data that are just different because
the access was via the dCDN, e.g. perhaps some other client IP = address
gets used if somethings multihomed, or some ISP infrastructure = differs,
e.g. HTTP Forwarded might be present and visible to the dCDN but with
no similar thing for DNS (or vice versa). I'd not be surprised if = even
more subtle differences existed over populations of transactions and
users and CDNs.

I=E2=80=99m sure there are all = sort of things like you suggest above. What is not at all clear to me is = what specifically the logging draft is meant to do about it.

Ultimately it=E2=80=99s a tradeoff I think. = I=E2=80=99m not sure we=E2=80=99ll ever agree.

I have nothing more to say that won=E2=80=99t end up just = rehashing discussions we=E2=80=99ve already had so I don=E2=80=99t = intend on participating in this thread any longer.

Ben


= --Apple-Mail=_AC99D28D-77E0-4ACF-B26A-2158F68CD8CE-- From nobody Wed Jun 8 12:39:20 2016 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 321A912D5A5; Wed, 8 Jun 2016 12:39:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160608193919.20051.57516.idtracker@ietfa.amsl.com> Date: Wed, 08 Jun 2016 12:39:19 -0700 Archived-At: Cc: draft-ietf-cdni-logging@ietf.org, cdni@ietf.org, cdni-chairs@ietf.org Subject: [CDNi] Ben Campbell's No Objection on draft-ietf-cdni-logging-27: (with COMMENT) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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 Jun 2016 19:39:19 -0000 Ben Campbell has entered the following ballot position for draft-ietf-cdni-logging-27: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cdni-logging/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS and COMMENT points. From nobody Wed Jun 8 13:08:47 2016 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 935FA12D790 for ; Wed, 8 Jun 2016 13:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.325 X-Spam-Level: X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426] 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 ztvZI7W20ENT for ; Wed, 8 Jun 2016 13:08:43 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 D6DF512D53A for ; Wed, 8 Jun 2016 13:08:43 -0700 (PDT) Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u58K8Xtb098705 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 8 Jun 2016 15:08:33 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4] From: "Ben Campbell" To: "Francois Le Faucheur" Date: Wed, 08 Jun 2016 15:08:38 -0500 Message-ID: <2A33E99C-BA1C-4F04-A57C-1A84A9A5E4A2@nostrum.com> In-Reply-To: <52E0B3B9-6DB4-46E5-B069-97F60940FA62@gmail.com> References: <20160608131715.20067.9182.idtracker@ietfa.amsl.com> <52E0B3B9-6DB4-46E5-B069-97F60940FA62@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_D12BF33E-3ADD-4867-8148-0F994E905B19_=" Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: Stephen Farrell , cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-logging-27.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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 Jun 2016 20:08:45 -0000 --=_MailMate_D12BF33E-3ADD-4867-8148-0F994E905B19_= Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit I just cleared. Thanks! Ben. On 8 Jun 2016, at 8:21, Francois Le Faucheur wrote: > Alexey, Ben , > > Version -27 includes all the proposed resolutions discussed on the > list. > I hope this will allow Ben to clear his “Discuss” position. > > Thanks again for your reviews and comments. > > Cheers > > François (as an editor) > >> On 8 Jun 2016, at 15:17, internet-drafts@ietf.org 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 of the IETF. >> >> Title : CDNI Logging Interface >> Authors : Francois Le Faucheur >> Gilles Bertrand >> Iuniana Oprescu >> Roy Peterkofsky >> Filename : draft-ietf-cdni-logging-27.txt >> Pages : 59 >> Date : 2016-06-08 >> >> Abstract: >> This memo specifies the Logging interface between a downstream CDN >> (dCDN) and an upstream CDN (uCDN) that are interconnected as per >> the >> CDN Interconnection (CDNI) framework. First, it describes a >> reference model for CDNI logging. Then, it specifies the CDNI >> Logging File format and the actual protocol for exchange of CDNI >> Logging Files. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-cdni-logging/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-cdni-logging-27 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-logging-27 >> >> >> 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/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --=_MailMate_D12BF33E-3ADD-4867-8148-0F994E905B19_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

I just cleared.

Thanks!

Ben.

On 8 Jun 2016, at 8:21, Francois Le Faucheur wrote:

Alexey, Ben ,

Version -27 includes all the proposed resolutions discuss= ed on the list.
I hope this will allow Ben to clear his =E2=80=9CDiscuss=E2=80=9D positio= n.

Thanks again for your reviews and comments.

Cheers

Fran=C3=A7ois (as an editor)

On 8 Jun 2016, at 15:17, internet-drafts@ietf.org wrote:

A New Internet-Draft is available from the on-line Intern= et-Drafts directories.
This draft is a work item of the Content Delivery Networks Interconnectio= n of the IETF.

   Title           : CDNI Logging Interface
   Authors         : Francois Le Faucheur
                     Gilles Bertrand
                     Iuniana Oprescu
                     Roy Peterkofsky
Filename        : draft-ietf-cdni-logging-27.txt
Pages           : 59
Date            : 2016-06-08

Abstract:
This memo specifies the Logging interface between a downstream CDN
(dCDN) and an upstream CDN (uCDN) that are interconnected as per the CDN Interconnection (CDNI) framework. First, it describes a
reference model for CDNI logging. Then, it specifies the CDNI
Logging File format and the actual protocol for exchange of CDNI
Logging Files.

The IETF datatracker status page for this draft is:
htt= ps://datatracker.ietf.org/doc/draft-ietf-cdni-logging/

There's also a htmlized version available at:
https:= //tools.ietf.org/html/draft-ietf-cdni-logging-27

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-27

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/intern= et-drafts/

I-D-Announce mailing list
I-D-Announce@ietf.org
https://ww= w.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: h= ttp://www.ietf.org/shadow.html
or ftp://ftp.ietf.o= rg/ietf/1shadow-sites.txt

--=_MailMate_D12BF33E-3ADD-4867-8148-0F994E905B19_=-- From nobody Thu Jun 9 07:52:41 2016 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 2F63512B060; Thu, 9 Jun 2016 07:52:34 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160609145234.16807.79174.idtracker@ietfa.amsl.com> Date: Thu, 09 Jun 2016 07:52:34 -0700 Archived-At: Cc: draft-ietf-cdni-logging@ietf.org, cdni-chairs@ietf.org, rfc-editor@rfc-editor.org, The IESG , cdni@ietf.org Subject: [CDNi] Protocol Action: 'CDNI Logging Interface' to Proposed Standard (draft-ietf-cdni-logging-27.txt) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 09 Jun 2016 14:52:34 -0000 The IESG has approved the following document: - 'CDNI Logging Interface' (draft-ietf-cdni-logging-27.txt) as Proposed Standard This document is the product of the Content Delivery Networks Interconnection Working Group. The IESG contact persons are Alexey Melnikov, Ben Campbell, Alissa Cooper and Spencer Dawkins. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-logging/ Technical Summary This memo specifies the Logging interface between a downstream CDN (dCDN) and an upstream CDN (uCDN) that are interconnected as per the CDN Interconnection (CDNI) framework. First, it describes a reference model for CDNI logging. Then, it specifies the CDNI Logging File format and the actual protocol for exchange of CDNI Logging Files. Working Group Summary We had a lot of discussion regarding the security of the logging files, specifically as it relates to non-repudiation. Originally, the logging draft had text regarding non-repudiation, but later we determined non-repudiation was not as mature of a solution relative the rest of the logging draft and there was other work regarding non-repudiation occurring in the IETF. We decided to remove all references to non-repudiation for the following reasons: 1) Avoid the potential of defining anything for non-repudiation within CDNi and creating a conflict with other IETF work; 2) the requirement for non-repudiation was not a critical requirement for the logging draft. Recently, we had discussion and debate over which drafts should define the advertisement of capabilities (I.e., what logging fields are required to be supported). This was specifically related to the Footprint and Capabilities Interface (FCI) draft (https://tools.ietf.org/html/draft-ietf-cdni-footprint-capabilities-semantics-04). Ideally, capability advertisement would be defined with the interfaces themselves, but the FCI draft is not as mature as this (and other drafts). As a result of vigorous discussion, we decided to remove a placeholder for the FCI advertisement information from the logging draft. In the future, the FCI draft will define the template for FCI objects and a registry for FCI objects. We will publish a separate RFC for capability advertisement for the logging interface. We determined this approach as the best trade-off between draft publish expediency and necessary functionality. Document Quality CDNI interfaces are still mostly in prototypes with plans for production support. Vendors, such as Cisco and Alcatel-Lucent, continue to progress the development and testing of the CDNI solution space, including the logging draft. Due to the Ops nature of this draft, we requested and received a thorough review from an expert in this area, David Harrington. We discussed and included necessary changes based on this review. Personnel Daryl Malas (co-chair of CDNI) is the document shepherd, and Spencer Dawkins is the responsible Area Director. From nobody Thu Jun 9 10:01:27 2016 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 2CAD012D769; Thu, 9 Jun 2016 10:01:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160609170126.16843.93629.idtracker@ietfa.amsl.com> Date: Thu, 09 Jun 2016 10:01:26 -0700 Archived-At: Cc: cdni@ietf.org, cdni-chairs@ietf.org Subject: [CDNi] cdni - Update to a Meeting Session Request for IETF 96 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 09 Jun 2016 17:01:26 -0000 An update to a meeting session request has just been submitted by Kevin J. Ma, a Chair of the cdni working group. --------------------------------------------------------- Working Group Name: Content Delivery Networks Interconnection Area Name: Applications and Real-Time Area Session Requester: Kevin Ma Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: alto httpbis lurk tls Second Priority: appsawg dispatch Special Requests: --------------------------------------------------------- From nobody Fri Jun 10 08:34:17 2016 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 A28B812D66E for ; Fri, 10 Jun 2016 08:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDOebNjJboMk for ; Fri, 10 Jun 2016 08:34:14 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13B9112D58C for ; Fri, 10 Jun 2016 08:34:13 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.26,450,1459807200"; d="scan'208,217"; a="64744428" Received: from exc-cashub03.tsn.tno.nl (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1a.tno.nl with ESMTP; 10 Jun 2016 17:34:11 +0200 Received: from EXC-MBX03.tsn.tno.nl ([fe80::e969:1300:fb9f:7e12]) by EXC-CASHUB03.tsn.tno.nl ([fe80::6d39:f277:173e:a926%13]) with mapi id 14.03.0294.000; Fri, 10 Jun 2016 17:34:11 +0200 From: "Brandenburg, R. (Ray) van" To: "cdni@ietf.org" Thread-Topic: New version (and IPR statement) of draft-brandenburg-cdni-uri-signing-for-has Thread-Index: AQHRwy2I54wAQQPyYkOQMx8zvzoaIw== Date: Fri, 10 Jun 2016 15:34:10 +0000 Message-ID: <90041886-D253-413F-B006-50BDA558EB12@tno.nl> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.16.0.160506 x-originating-ip: [134.221.225.191] x-esetresult: clean, is OK x-esetid: 37303A29F368486F627066 Content-Type: multipart/alternative; boundary="_000_90041886D253413FB00650BDA558EB12tnonl_" MIME-Version: 1.0 Archived-At: Subject: [CDNi] New version (and IPR statement) of draft-brandenburg-cdni-uri-signing-for-has X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 10 Jun 2016 15:34:16 -0000 --_000_90041886D253413FB00650BDA558EB12tnonl_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpBcyB5b3UgbWlnaHQgaGF2ZSBzZWVuLCBJ4oCZdmUgcmVjZW50bHkgdXBsb2Fk ZWQgYSBuZXcgdmVyc2lvbiBvZiBkcmFmdC1icmFuZGVuYnVyZy1jZG5pLXVyaS1zaWduaW5nLWZv ci1oYXMgKC0wMykuDQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1icmFuZGVu YnVyZy1jZG5pLXVyaS1zaWduaW5nLWZvci1oYXMtMDMNCg0KV2hhdCBpcyBpbXBvcnRhbnQgdG8g bm90ZSBpcyB0aGF0IEtQTiBoYXMgdXBkYXRlZCBpdOKAmXMgSVBSIHN0YXRlbWVudCBvbiB0aGlz IGRvY3VtZW50IHRvIGJlIGluIGxpbmUgd2l0aCB0aGUgSVBSIHN0YXRlbWVudHMgdGhhdCBoYXZl IGJlZW4gZmlsZWQgb24gb3RoZXIgQ0ROSSBkb2N1bWVudHMgKGkuZS4g4oCcUm95YWx0eS1GcmVl LCBSZWFzb25hYmxlIGFuZCBOb24tRGlzY3JpbWluYXRvcnkgTGljZW5zZSB0byBBbGwgSW1wbGVt ZW50ZXJz4oCdKS4gSG9wZWZ1bGx5IHRoaXMgY2xlYXJzIHVwIHRoZSBsZW5ndGh5IElQUiBkaXNj dXNzaW9uIHdl4oCZdmUgYmVlbiBoYXZpbmcgYXJvdW5kIHRoaXMgZG9jdW1lbnQgc28gdGhhdCB3 ZSBjYW4gZm9jdXMgb24gdGhlIHRlY2huaWNhbCBhc3BlY3RzIGFnYWluLg0KDQpMb29raW5nIGZv cndhcmQgdG8geW91ciBmZWVkYmFjaywNClJheQ0KVGhpcyBtZXNzYWdlIG1heSBjb250YWluIGlu Zm9ybWF0aW9uIHRoYXQgaXMgbm90IGludGVuZGVkIGZvciB5b3UuIElmIHlvdSBhcmUgbm90IHRo ZSBhZGRyZXNzZWUgb3IgaWYgdGhpcyBtZXNzYWdlIHdhcyBzZW50IHRvIHlvdSBieSBtaXN0YWtl LCB5b3UgYXJlIHJlcXVlc3RlZCB0byBpbmZvcm0gdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoZSBt ZXNzYWdlLiBUTk8gYWNjZXB0cyBubyBsaWFiaWxpdHkgZm9yIHRoZSBjb250ZW50IG9mIHRoaXMg ZS1tYWlsLCBmb3IgdGhlIG1hbm5lciBpbiB3aGljaCB5b3UgdXNlIGl0IGFuZCBmb3IgZGFtYWdl IG9mIGFueSBraW5kIHJlc3VsdGluZyBmcm9tIHRoZSByaXNrcyBpbmhlcmVudCB0byB0aGUgZWxl Y3Ryb25pYyB0cmFuc21pc3Npb24gb2YgbWVzc2FnZXMuCg== --_000_90041886D253413FB00650BDA558EB12tnonl_ Content-Type: text/html; charset="utf-8" Content-ID: <35CA7E5B9AAE7E4BA0D514D3D447C5AE@tno.nl> MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MCAw IDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo1OTUuMHB0IDg0Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQg NzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMi IGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ SGkgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+QXMgeW91 IG1pZ2h0IGhhdmUgc2VlbiwgSeKAmXZlIHJlY2VudGx5IHVwbG9hZGVkIGEgbmV3IHZlcnNpb24g b2YgZHJhZnQtYnJhbmRlbmJ1cmctY2RuaS11cmktc2lnbmluZy1mb3ItaGFzICgtMDMpLg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48YSBocmVmPSJodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYnJhbmRlbmJ1cmctY2RuaS11cmktc2lnbmluZy1m b3ItaGFzLTAzIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYnJhbmRlbmJ1cmct Y2RuaS11cmktc2lnbmluZy1mb3ItaGFzLTAzPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+V2hhdCBpcyBpbXBvcnRhbnQgdG8gbm90ZSBpcyB0aGF0IEtQTiBo YXMgdXBkYXRlZCBpdOKAmXMgSVBSIHN0YXRlbWVudCBvbiB0aGlzIGRvY3VtZW50IHRvIGJlIGlu IGxpbmUgd2l0aCB0aGUgSVBSIHN0YXRlbWVudHMgdGhhdCBoYXZlIGJlZW4gZmlsZWQgb24gb3Ro ZXIgQ0ROSSBkb2N1bWVudHMgKGkuZS4g4oCcUm95YWx0eS1GcmVlLCBSZWFzb25hYmxlIGFuZA0K IE5vbi1EaXNjcmltaW5hdG9yeSBMaWNlbnNlIHRvIEFsbCBJbXBsZW1lbnRlcnPigJ0pLiBIb3Bl ZnVsbHkgdGhpcyBjbGVhcnMgdXAgdGhlIGxlbmd0aHkgSVBSIGRpc2N1c3Npb24gd2XigJl2ZSBi ZWVuIGhhdmluZyBhcm91bmQgdGhpcyBkb2N1bWVudCBzbyB0aGF0IHdlIGNhbiBmb2N1cyBvbiB0 aGUgdGVjaG5pY2FsIGFzcGVjdHMgYWdhaW4uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPkxvb2tpbmcgZm9yd2FyZCB0byB5b3VyIGZlZWRiYWNrLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5SYXk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIHN0eWxlPSJN QVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1G QU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDhwdDsgbXNvLWJpZGktZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tYmlkaS1mb250LXNpemU6IDExLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxmb250IHN0eWxlPSJGT05ULVNJWkU6IDExcHgi IHNpemU9IjMiPg0KPC9mb250PjxwIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz0i TXNvTm9ybWFsIj48Zm9udCBzdHlsZT0iRk9OVC1TSVpFOiAxMXB4IiBzaXplPSIzIj48c3BhbiBz dHlsZT0iRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDhwdDsg bXNvLWJpZGktZm9udC1zaXplOiA4LjVwdCI+VGhpcyBtZXNzYWdlIG1heSBjb250YWluIGluZm9y bWF0aW9uIHRoYXQgaXMgbm90IGludGVuZGVkIGZvciB5b3UuIElmIHlvdSBhcmUgbm90IHRoZSBh ZGRyZXNzZWUgb3IgaWYgdGhpcyBtZXNzYWdlIHdhcyBzZW50IHRvIHlvdSBieSBtaXN0YWtlLCB5 b3UgYXJlIHJlcXVlc3RlZCB0byBpbmZvcm0gdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoZSBtZXNz YWdlLiBUTk8gYWNjZXB0cyBubyBsaWFiaWxpdHkgZm9yIHRoZSBjb250ZW50IG9mIHRoaXMgZS1t YWlsLCBmb3IgdGhlIG1hbm5lciBpbiB3aGljaCB5b3UgdXNlIGl0IGFuZCBmb3IgZGFtYWdlIG9m IGFueSBraW5kIHJlc3VsdGluZyBmcm9tIHRoZSByaXNrcyBpbmhlcmVudCB0byB0aGUgZWxlY3Ry b25pYyB0cmFuc21pc3Npb24gb2YgbWVzc2FnZXMuPGJyPjxicj48L3NwYW4+PC9mb250PjwvcD48 L2JvZHk+DQo8L2h0bWw+DQo= --_000_90041886D253413FB00650BDA558EB12tnonl_-- From nobody Sat Jun 11 11:57:03 2016 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 5B1F112D79A for ; Sat, 11 Jun 2016 11:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsdzg5vjqqXL for ; Sat, 11 Jun 2016 11:57:00 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32BED12D776 for ; Sat, 11 Jun 2016 11:56:59 -0700 (PDT) X-AuditID: c618062d-f79886d000002334-80-575c558f736c Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id BD.86.09012.F855C575; Sat, 11 Jun 2016 20:16:47 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0294.000; Sat, 11 Jun 2016 14:56:58 -0400 From: Kevin Ma J To: "Brandenburg, R. (Ray) van" , "cdni@ietf.org" Thread-Topic: New version (and IPR statement) of draft-brandenburg-cdni-uri-signing-for-has Thread-Index: AQHRwy2I54wAQQPyYkOQMx8zvzoaI5/kbdJg Date: Sat, 11 Jun 2016 18:56:58 +0000 Message-ID: References: <90041886-D253-413F-B006-50BDA558EB12@tno.nl> In-Reply-To: <90041886-D253-413F-B006-50BDA558EB12@tno.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_A419F67F880AB2468214E154CB8A556206E10D82eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZXLonULc/NCbcYNJHI4uns/+wWnzbfJ3R gcljyZKfTB4H111gDmCK4rJJSc3JLEst0rdL4MqYemw/e8GE9IrOZ5ENjCtSuhg5OSQETCRu nb/LCmGLSVy4t56ti5GLQ0jgKKPE/GVLWSCc5YwSf3Y+ZgOpYhPQknj89S8TiC0iECex49gZ RhBbWCBG4uXUFYwQ8ViJddu3QdlGEnPn/WIGsVkEVCW6d/aC9fIK+Epsun0ObKaQgKXEp03/ 2UFsTgEriQOvXoL1MgJd9P3UGrB6ZgFxiVtP5jNBXCogsWTPeWYIW1Ti5eN/UB8oSXz8PZ8d oj5fYsuuXnaIXYISJ2c+YZnAKDILyahZSMpmISmbxcgBFNeUWL9LH6JEUWJK90N2CFtDonXO XHZk8QWM7KsYOUqLC3Jy040MNjECY+eYBJvuDsb70z0PMQpwMCrx8CZYRIcLsSaWFVfmHmKU 4GBWEuHti44JF+JNSaysSi3Kjy8qzUktPsQozcGiJM4r9kgxXEggPbEkNTs1tSC1CCbLxMEp 1cDYkfa2+41xxrMWznO3fDjCzE/8XsIS5Vom7rZI3suwlCXC4P3bBOk/fwPKjF5vm6WX631y 9UmxKw6Hj8qdvtjz4C/jNqFJh8tOMZjccmg+f1taMX6W9JSO8HrWotvPGVgivv4+XeO6b8eJ h+9+MF3hXfFrg/3Ekyw/z2TUvrErWeHFs9lO/fZ3JZbijERDLeai4kQA8Pvwc5kCAAA= Archived-At: Subject: Re: [CDNi] New version (and IPR statement) of draft-brandenburg-cdni-uri-signing-for-has X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2016 18:57:02 -0000 --_000_A419F67F880AB2468214E154CB8A556206E10D82eusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxsLA0KDQogIChBcyBhIGNoYWlyKSBQZXIgdGhlIGRlY2lzaW9uIGluIEJBIChodHRwczov L3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85NS9taW51dGVzL21pbnV0ZXMtOTUtY2RuaSksIHdl IGRlZmVycmVkIGRpc2N1c3Npb24gb2Ygd2hldGhlciB0byAocmUpYWRvcHQgZHJhZnQtYnJhbmRl bmJ1cmctY2RuaS11cmktc2lnbmluZy1mb3ItaGFzIGFzIGEgV0cgaXRlbS4gIEZvciBoaXN0b3Jp Y2FsIGNvbnRleHQsIGluIFByYWd1ZSwgd2UgZGVjaWRlZCB0byBzZXBhcmF0ZSB0aGUgSVBSIGVu Y3VtYmVyZWQgcG9ydGlvbiBvZiBVUkkgc2lnbmluZyBmcm9tIHRoZSBXRyBkcmFmdCAoaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTMvbWludXRlcy9taW51dGVzLTkzLWNkbmkpLg0K DQogIFRoZXJlIGlzIGEgbmV3IElQUiBkaXNjbG9zdXJlIChodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2lwci8yODA2LykgYXZhaWxhYmxlIHRoYXQgZm9sa3Mgc2hvdWxkIHRha2UgYSBsb29r IGF0LiAgTm90ZTogSSdtIG5vdCBzdXJlIGlmIGl0IHNob3VsZCBoYXZlIGJlZW4gYW4gdXBkYXRl IHRvIHRoZSBwcmV2aW91cyBkaXNjbG9zdXJlIChodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2lwci8yNjUyLykgb3Igd2hldGhlciB0aGF0IG1ha2VzIGEgZGlmZmVyZW5jZT8gIEFsZXhleT8N Cg0KICBJZiBmb2xrcyBoYXZlIHRob3VnaHRzIGFib3V0IHdoZXRoZXIgb3Igbm90IHdlIHNob3Vs ZCAocmUpYWRvcHQgdGhlIEhBUyBVUkkgc2lnbmluZyB3b3JrLCBpbiBsaWdodCBvZiB0aGUgbmV3 IElQUiBkaXNjbG9zdXJlLCBwbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBsaXN0Lg0K DQp0aGFueCENCg0KLS0gIEtldmluIEouIE1hDQoNCkZyb206IENETmkgW21haWx0bzpjZG5pLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCcmFuZGVuYnVyZywgUi4gKFJheSkgdmFuDQpT ZW50OiBGcmlkYXksIEp1bmUgMTAsIDIwMTYgMTE6MzQgQU0NClRvOiBjZG5pQGlldGYub3JnDQpT dWJqZWN0OiBbQ0ROaV0gTmV3IHZlcnNpb24gKGFuZCBJUFIgc3RhdGVtZW50KSBvZiBkcmFmdC1i cmFuZGVuYnVyZy1jZG5pLXVyaS1zaWduaW5nLWZvci1oYXMNCg0KSGkgYWxsLA0KDQpBcyB5b3Ug bWlnaHQgaGF2ZSBzZWVuLCBJ4oCZdmUgcmVjZW50bHkgdXBsb2FkZWQgYSBuZXcgdmVyc2lvbiBv ZiBkcmFmdC1icmFuZGVuYnVyZy1jZG5pLXVyaS1zaWduaW5nLWZvci1oYXMgKC0wMykuDQoNCmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1icmFuZGVuYnVyZy1jZG5pLXVyaS1zaWdu aW5nLWZvci1oYXMtMDMNCg0KV2hhdCBpcyBpbXBvcnRhbnQgdG8gbm90ZSBpcyB0aGF0IEtQTiBo YXMgdXBkYXRlZCBpdOKAmXMgSVBSIHN0YXRlbWVudCBvbiB0aGlzIGRvY3VtZW50IHRvIGJlIGlu IGxpbmUgd2l0aCB0aGUgSVBSIHN0YXRlbWVudHMgdGhhdCBoYXZlIGJlZW4gZmlsZWQgb24gb3Ro ZXIgQ0ROSSBkb2N1bWVudHMgKGkuZS4g4oCcUm95YWx0eS1GcmVlLCBSZWFzb25hYmxlIGFuZCBO b24tRGlzY3JpbWluYXRvcnkgTGljZW5zZSB0byBBbGwgSW1wbGVtZW50ZXJz4oCdKS4gSG9wZWZ1 bGx5IHRoaXMgY2xlYXJzIHVwIHRoZSBsZW5ndGh5IElQUiBkaXNjdXNzaW9uIHdl4oCZdmUgYmVl biBoYXZpbmcgYXJvdW5kIHRoaXMgZG9jdW1lbnQgc28gdGhhdCB3ZSBjYW4gZm9jdXMgb24gdGhl IHRlY2huaWNhbCBhc3BlY3RzIGFnYWluLg0KDQpMb29raW5nIGZvcndhcmQgdG8geW91ciBmZWVk YmFjaywNClJheQ0KDQpUaGlzIG1lc3NhZ2UgbWF5IGNvbnRhaW4gaW5mb3JtYXRpb24gdGhhdCBp cyBub3QgaW50ZW5kZWQgZm9yIHlvdS4gSWYgeW91IGFyZSBub3QgdGhlIGFkZHJlc3NlZSBvciBp ZiB0aGlzIG1lc3NhZ2Ugd2FzIHNlbnQgdG8geW91IGJ5IG1pc3Rha2UsIHlvdSBhcmUgcmVxdWVz dGVkIHRvIGluZm9ybSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UuIFROTyBhY2Nl cHRzIG5vIGxpYWJpbGl0eSBmb3IgdGhlIGNvbnRlbnQgb2YgdGhpcyBlLW1haWwsIGZvciB0aGUg bWFubmVyIGluIHdoaWNoIHlvdSB1c2UgaXQgYW5kIGZvciBkYW1hZ2Ugb2YgYW55IGtpbmQgcmVz dWx0aW5nIGZyb20gdGhlIHJpc2tzIGluaGVyZW50IHRvIHRoZSBlbGVjdHJvbmljIHRyYW5zbWlz c2lvbiBvZiBtZXNzYWdlcy4NCg== --_000_A419F67F880AB2468214E154CB8A556206E10D82eusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1 NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3 MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9y OndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo1OTUu MHB0IDg0Mi4wcHQ7DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xv cj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PkhpIEFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyAoQXMgYSBjaGFpcikgUGVyIHRoZSBkZWNpc2lvbiBpbiBCQSAoPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTUvbWludXRlcy9taW51dGVz LTk1LWNkbmkiPmh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk1L21pbnV0ZXMvbWlu dXRlcy05NS1jZG5pPC9hPiksIHdlIGRlZmVycmVkDQogZGlzY3Vzc2lvbiBvZiB3aGV0aGVyIHRv IChyZSlhZG9wdCBkcmFmdC1icmFuZGVuYnVyZy1jZG5pLXVyaS1zaWduaW5nLWZvci1oYXMgYXMg YSBXRyBpdGVtLiZuYnNwOyBGb3IgaGlzdG9yaWNhbCBjb250ZXh0LCBpbiBQcmFndWUsIHdlIGRl Y2lkZWQgdG8gc2VwYXJhdGUgdGhlIElQUiBlbmN1bWJlcmVkIHBvcnRpb24gb2YgVVJJIHNpZ25p bmcgZnJvbSB0aGUgV0cgZHJhZnQgKDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2Nl ZWRpbmdzLzkzL21pbnV0ZXMvbWludXRlcy05My1jZG5pIj5odHRwczovL3d3dy5pZXRmLm9yZy9w cm9jZWVkaW5ncy85My9taW51dGVzL21pbnV0ZXMtOTMtY2RuaTwvYT4pLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7IFRoZXJl IGlzIGEgbmV3IElQUiBkaXNjbG9zdXJlICg8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2lwci8yODA2LyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9pcHIvMjgwNi88 L2E+KSBhdmFpbGFibGUgdGhhdCBmb2xrcyBzaG91bGQgdGFrZSBhIGxvb2sgYXQuJm5ic3A7IE5v dGU6IEknbQ0KIG5vdCBzdXJlIGlmIGl0IHNob3VsZCBoYXZlIGJlZW4gYW4gdXBkYXRlIHRvIHRo ZSBwcmV2aW91cyBkaXNjbG9zdXJlICg8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2lwci8yNjUyLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9pcHIvMjY1Mi88L2E+ KSBvciB3aGV0aGVyIHRoYXQgbWFrZXMgYSBkaWZmZXJlbmNlPyZuYnNwOyBBbGV4ZXk/PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsgSWYgZm9sa3MgaGF2ZSB0aG91Z2h0cyBhYm91dCB3aGV0aGVyIG9yIG5vdCB3ZSBzaG91bGQg KHJlKWFkb3B0IHRoZSBIQVMgVVJJIHNpZ25pbmcgd29yaywgaW4gbGlnaHQgb2YgdGhlIG5ldyBJ UFIgZGlzY2xvc3VyZSwgcGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgbGlzdC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPnRo YW54ITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+LS0mbmJzcDsgS2V2aW4gSi4gTWE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQ0ROaSBbbWFpbHRvOmNkbmkt Ym91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QnJhbmRlbmJ1cmcsIFIuIChS YXkpIHZhbjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEp1bmUgMTAsIDIwMTYgMTE6MzQgQU08 YnI+DQo8Yj5Ubzo8L2I+IGNkbmlAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW0NETmld IE5ldyB2ZXJzaW9uIChhbmQgSVBSIHN0YXRlbWVudCkgb2YgZHJhZnQtYnJhbmRlbmJ1cmctY2Ru aS11cmktc2lnbmluZy1mb3ItaGFzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkhpIGFsbCw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkFzIHlvdSBtaWdodCBoYXZlIHNl ZW4sIEnigJl2ZSByZWNlbnRseSB1cGxvYWRlZCBhIG5ldyB2ZXJzaW9uIG9mIGRyYWZ0LWJyYW5k ZW5idXJnLWNkbmktdXJpLXNpZ25pbmctZm9yLWhhcyAoLTAzKS4NCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWJyYW5kZW5idXJnLWNkbmktdXJpLXNpZ25pbmctZm9yLWhhcy0wMyI+aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJyYW5kZW5idXJnLWNkbmktdXJpLXNpZ25p bmctZm9yLWhhcy0wMzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPldoYXQgaXMgaW1wb3J0YW50IHRvIG5vdGUgaXMgdGhhdCBLUE4gaGFzIHVwZGF0ZWQgaXTi gJlzIElQUiBzdGF0ZW1lbnQgb24gdGhpcyBkb2N1bWVudCB0byBiZSBpbiBsaW5lIHdpdGggdGhl IElQUiBzdGF0ZW1lbnRzIHRoYXQgaGF2ZSBiZWVuIGZpbGVkIG9uIG90aGVyIENETkkgZG9jdW1l bnRzIChpLmUuIOKAnFJveWFsdHktRnJlZSwgUmVhc29uYWJsZSBhbmQNCiBOb24tRGlzY3JpbWlu YXRvcnkgTGljZW5zZSB0byBBbGwgSW1wbGVtZW50ZXJz4oCdKS4gSG9wZWZ1bGx5IHRoaXMgY2xl YXJzIHVwIHRoZSBsZW5ndGh5IElQUiBkaXNjdXNzaW9uIHdl4oCZdmUgYmVlbiBoYXZpbmcgYXJv dW5kIHRoaXMgZG9jdW1lbnQgc28gdGhhdCB3ZSBjYW4gZm9jdXMgb24gdGhlIHRlY2huaWNhbCBh c3BlY3RzIGFnYWluLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij5Mb29raW5nIGZvcndhcmQgdG8geW91ciBmZWVkYmFjayw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UmF5 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+VGhpcyBtZXNzYWdlIG1heSBjb250YWluIGluZm9ybWF0aW9uIHRoYXQgaXMgbm90IGlu dGVuZGVkIGZvciB5b3UuIElmIHlvdSBhcmUgbm90IHRoZSBhZGRyZXNzZWUgb3IgaWYgdGhpcyBt ZXNzYWdlIHdhcyBzZW50IHRvIHlvdSBieSBtaXN0YWtlLCB5b3UNCiBhcmUgcmVxdWVzdGVkIHRv IGluZm9ybSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UuIFROTyBhY2NlcHRzIG5v IGxpYWJpbGl0eSBmb3IgdGhlIGNvbnRlbnQgb2YgdGhpcyBlLW1haWwsIGZvciB0aGUgbWFubmVy IGluIHdoaWNoIHlvdSB1c2UgaXQgYW5kIGZvciBkYW1hZ2Ugb2YgYW55IGtpbmQgcmVzdWx0aW5n IGZyb20gdGhlIHJpc2tzIGluaGVyZW50IHRvIHRoZSBlbGVjdHJvbmljIHRyYW5zbWlzc2lvbiBv ZiBtZXNzYWdlcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_A419F67F880AB2468214E154CB8A556206E10D82eusaamb103erics_-- From nobody Sat Jun 11 12:13:55 2016 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 88AEF12D5AB; Sat, 11 Jun 2016 12:13:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160611191351.28997.62331.idtracker@ietfa.amsl.com> Date: Sat, 11 Jun 2016 12:13:51 -0700 Archived-At: Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-metadata-18.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2016 19:13: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 of the IETF. Title : CDN Interconnection Metadata Authors : Ben Niven-Jenkins Rob Murray Matt Caulfield Kevin J. Ma Filename : draft-ietf-cdni-metadata-18.txt Pages : 62 Date : 2016-06-11 Abstract: The Content Delivery Networks Interconnection (CDNI) metadata interface enables interconnected Content Delivery Networks (CDNs) to exchange content distribution metadata in order to enable content acquisition and delivery. The CDNI metadata associated with a piece of content provides a downstream CDN with sufficient information for the downstream CDN to service content requests on behalf of an upstream CDN. This document describes both a base set of CDNI metadata and the protocol for exchanging that metadata. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-metadata/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-cdni-metadata-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-metadata-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 Sat Jun 11 12:15:57 2016 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 C0ED512D86F for ; Sat, 11 Jun 2016 12:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDCtf3Qsnv6L for ; Sat, 11 Jun 2016 12:15:53 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A4ED12D86E for ; Sat, 11 Jun 2016 12:15:53 -0700 (PDT) X-AuditID: c618062d-f79886d000002334-28-575c59fd89c6 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 63.D6.09012.DF95C575; Sat, 11 Jun 2016 20:35:41 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0294.000; Sat, 11 Jun 2016 15:15:52 -0400 From: Kevin Ma J To: Alexey Melnikov , "cdni@ietf.org" Thread-Topic: [CDNi] Early AD review of draft-ietf-cdni-metadata-17 Thread-Index: AQHRvLXhTYkUPkhZmUmD7E+22fbOBp/WhWqAgAFi94CADMmxUA== Date: Sat, 11 Jun 2016 19:15:52 +0000 Message-ID: References: <1464861734.1246901.625717065.0912CC9E@webmail.messagingengine.com> <1464955165.2560710.626896049.52EA8E0B@webmail.messagingengine.com> In-Reply-To: <1464955165.2560710.626896049.52EA8E0B@webmail.messagingengine.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyuXRPiO7fyJhwg+N3FCz2vz/EZPF09h9W ByaPnacOsHksWfKTKYApissmJTUnsyy1SN8ugStj7f6D7AUH1St2HZzA0sC4Uq6LkZNDQsBE omvSCXYIW0ziwr31bF2MXBxCAkcZJc5tuM0I4SxnlPgz+SYrSBWbgJbE469/mUBsEQFfidWL /oHFhQWcJCY9a2CBiDtLHLx/GmgSB5DtJHHvdyFImEVAVWLDm9tgJbxArXva/7BAzJ/LJDHn x0awBKdAgMS3Kz/BbEagi76fWgO2i1lAXOLWk/lMEJcKSCzZc54ZwhaVePkY4gYJASWJj7/n s0PU60gs2P2JDcLWlli28DUzxGJBiZMzn7BMYBSdhWTsLCQts5C0zELSsoCRZRUjR2lxQU5u upHBJkZgPByTYNPdwXh/uuchRgEORiUe3gSL6HAh1sSy4srcQ4wSHMxKIryOCTHhQrwpiZVV qUX58UWlOanFhxilOViUxHnFHimGCwmkJ5akZqemFqQWwWSZODilGhgdL9+fPfEF86LC5db+ et3Lrgvny72xCzioU1ZVqak1wSxd+jnzjDbecwe51wj1KfnYzLlgO6FiGm+wwH0F51uyp1eJ 3l3BLc9Zt6Cq9EIXo+bsPoWIJMabLfmxxxdx8pz0+nNwz3XBd1r/Lp0PCFOXbTmSa35NJZcn K2ZL8JxT/xhMDhe/KFBiKc5INNRiLipOBAAoA2ybgwIAAA== Archived-At: Subject: Re: [CDNi] Early AD review of draft-ietf-cdni-metadata-17 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2016 19:15:56 -0000 Hi Alexey, > > Should OPTIONS method be allowed? The authors conferred and decided that only GET and HEAD are allowed; we ha= ve updated the draft accordingly. thanx! -- Kevin J. Ma > -----Original Message----- > From: Alexey Melnikov [mailto:aamelnikov@fastmail.fm] > Sent: Friday, June 03, 2016 7:59 AM > To: Kevin Ma J; cdni@ietf.org > Subject: Re: [CDNi] Early AD review of draft-ietf-cdni-metadata-17 >=20 > Hi Kevin, >=20 > On Thu, Jun 2, 2016, at 08:51 PM, Kevin Ma J wrote: > > Hi Alexey, > > > > inline: > > > > > -----Original Message----- > > > From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Alexey Melniko= v > > > Sent: Thursday, June 02, 2016 6:02 AM > > > To: cdni@ietf.org > > > Subject: [CDNi] Early AD review of draft-ietf-cdni-metadata-17 > > > > > > In order to speed up publication of this draft, I decided to do early > AD > > > review. Here are my comments. My apologies if they are a bit cryptic, > if > > > you are unsure of what I meant, please ask! > > > > > > In 1.2: content can only be delivered using HTTP/1.1 and not HTTP/1.1 > > > over TLS? Is last para saying that this is an unsolved problem (e.g. > > > LURK BOF solution is needed)? > > > > Essentially, yes. We had considered trying to define a way to pass > certs > > and keys around, but in general it seemed like a bad idea. A LURK-like > > solution would help. >=20 > Ok. >=20 > > > In 4.1.2: hostname and IP addresses need to have defined syntaxes (at > > > least by reference). You also need to say whether IDN domain names ar= e > > > allowed here. > > > > I actually just removed the references, since they seemed redundant. > The > > host property is of type "Endpoint" which is defined in 4.3.3. I can > add > > it back if you feel it's not readable as is. >=20 > I would rather you do. I like references :-). >=20 > > > In 4.1.5: does "case insensitive" only applies to ASCII range? I.e., > > > encoded UTF-8 sequences in URIs are not affected. > > > > I would expect this to apply to the percent encoded values, not the > > decoded values, i.e., I would expect "%4A" to be compared as "%4a" and > > not "j". Is that what you mean? > > > > Ben, do you agree? > > > > We can clarify that. > > > > > In 4.2.6: URI needs a Normative Reference (RFC 3986). > > > > Done. I assume you mean wrt the ignore-query-string property > description > > "URI query string parameters"? >=20 > Yes. >=20 > > > In 4.3.7: need a reference to a document/registry defining ASNs. > > > > Added reference to RFC6793. > > > > > In 6.1: need a reference to HTTP/1.1 spec. > > > > Added a reference to RFC7230. > > > > > Should OPTIONS method be allowed? > > > > I'll defer to Ben on this one. > > > > > In 6.2/6.3: Is discovery of the initial URI truly out of scope? You > can > > > define a .well-known URI to allow bootstrapping. > > > If it is defined, is it likely to be used? > > > > This is similar to Triggers > > (https://tools.ietf.org/html/draft-ietf-cdni-control-triggers- > 15#section-4) > > in that it is assumes the CDNs would exchange that information > > out-of-band, or that some other bootstrap API would be defined. > > > > wrt .well-known, the dCDN (in the case of metadata; the uCDN in the cas= e > > of triggers) would still need to have a hostname configured? There was > > some discussion a while back > > (https://mailarchive.ietf.org/arch/msg/cdni/9JUdlQk0fD4_0Lhm1lj7_U7QfcM= ) > > about using a "well-known" URI for retrieving bootstrap information for > > all interfaces, but it was not followed up. >=20 > Ok, I will read this. >=20 > > > In 7.3: Nit: HTTP/1.1 over TLS needs 2 references, not just one. > > > > The other reference being? > > What if we just used 7230? >=20 > + RFC 2818. >=20 > > More generally, though, do you think we need to adjust the registry > > structure to have a list of Protocol Specs? >=20 > I am not sure what you mean. The current table looks fine to me (other > than missing references). >=20 > > > In 7.4: I think I am sad that you haven't defined any initial > > > authentication mechanism. Has this been discussed in the WG? > > > > > > In 8.1, last para: a requirement to implement mutual authentication i= s > > > underspecified. Do you mean TLS mutual authentication? If yes, say so= . > > > If other mechanisms can be used, say so as well. > > > If you meant to reference 8.5 here, please do so. > > > > > > Why is this only a SHOULD (and not a MUST)? > > > > Sections 8.1-8.4 were intended to lead into 8.5 > > Changed the SHOULDs to MUSTs and added references to 8.5 > > > > thanx. >=20 > Much better! >=20 > > -- Kevin J. Ma > > > > > In 8.2: similarly, how can the SHOULD be satisfied? Do you mean TLS o= r > > > something else? Reference 8.5? > > > > > > In 8.3: similar issue. > > > > > > Also encryption doesn't necessarily provide integrity of data, so the > > > last sentence sounds wrong. > > > > > > In 8.4: similar issue. From nobody Sat Jun 11 12:17:46 2016 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 D0B4E12B03F for ; Sat, 11 Jun 2016 12:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2Uv1oi0poRR for ; Sat, 11 Jun 2016 12:17:41 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C780B12D0EF for ; Sat, 11 Jun 2016 12:17:41 -0700 (PDT) X-AuditID: c6180641-f796f6d000000e1e-1d-575c639add11 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 7E.3A.03614.A936C575; Sat, 11 Jun 2016 21:16:43 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0294.000; Sat, 11 Jun 2016 15:17:40 -0400 From: Kevin Ma J To: "cdni@ietf.org" Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-metadata-18.txt Thread-Index: AQHRxBV42AJmqRnmkU+MVj5FABe/wZ/ko6Vg Date: Sat, 11 Jun 2016 19:17:40 +0000 Message-ID: References: <20160611191351.28997.62331.idtracker@ietfa.amsl.com> In-Reply-To: <20160611191351.28997.62331.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyuXRPuO7s5Jhwg4+ruCyezv7D6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujLmXJzEVPBGqeLHtGWsD4za+LkZODgkBE4mH3TOYIGwxiQv3 1rN1MXJxCAkcZZTYOes6K4SznFHi2K4FzCBVbAJaEo+//gXq4OAQEVCW+HnIEcQUFrCX6Ojl B6kQEXCQ+Nc3lwXCNpLYc2sPO4jNIqAqcXLGf1YQm1fAV+LKrBeMILaQgKPElyM/WEDGcAo4 SfTPigcJMwKd8/3UGrDTmAXEJW49mQ91poDEkj3nmSFsUYmXj/+xQthKEh9/z2eHqNeRWLD7 ExuErS2xbOFrZoi1ghInZz5hmcAoOgvJ2FlIWmYhaZmFpGUBI8sqRo7S4oKc3HQjw02MwKA/ JsHmuINxb6/nIUYBDkYlHt4Ei+hwIdbEsuLK3EOMEhzMSiK8jgkx4UK8KYmVValF+fFFpTmp xYcYpTlYlMR59V8qhgsJpCeWpGanphakFsFkmTg4pRoYOy78eb1j4bG3HMkLtrsuVC++/LtB yqjHKNRxSQVrVsq1V9e5XjPbF2w58XxPUtj+gh/T/jy0Zr3e0rzx88GJv2fYpJmHGDM977fp P8tXbfptyv+Q+7tTFuQa6ZlN8azZ/fneKXPN5SlZux/dumsSlHpOROlj+HtFnd61iev0HeuD XBfpeop+VGIpzkg01GIuKk4EAFZcxCl2AgAA Archived-At: Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-metadata-18.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2016 19:17:45 -0000 Hi All, (As an author) This draft addresses the comments we received from Alexey = during the WGLC. The authors believe that this version the draft is ready = to for IESG review. thanx! -- Kevin J. Ma > -----Original Message----- > From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Saturday, June 11, 2016 3:14 PM > To: i-d-announce@ietf.org > Cc: cdni@ietf.org > Subject: [CDNi] I-D Action: draft-ietf-cdni-metadata-18.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Content Delivery Networks Interconnectio= n > of the IETF. >=20 > Title : CDN Interconnection Metadata > Authors : Ben Niven-Jenkins > Rob Murray > Matt Caulfield > Kevin J. Ma > Filename : draft-ietf-cdni-metadata-18.txt > Pages : 62 > Date : 2016-06-11 >=20 > Abstract: > The Content Delivery Networks Interconnection (CDNI) metadata > interface enables interconnected Content Delivery Networks (CDNs) to > exchange content distribution metadata in order to enable content > acquisition and delivery. The CDNI metadata associated with a piece > of content provides a downstream CDN with sufficient information for > the downstream CDN to service content requests on behalf of an > upstream CDN. This document describes both a base set of CDNI > metadata and the protocol for exchanging that metadata. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-cdni-metadata/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-cdni-metadata-18 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-metadata-18 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From nobody Sun Jun 12 13:46:35 2016 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 4417412D0CB for ; Sun, 12 Jun 2016 13:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YR9TTYGdHP8z for ; Sun, 12 Jun 2016 13:46:31 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35DB412B02C for ; Sun, 12 Jun 2016 13:46:31 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.26,463,1459807200"; d="scan'208,217"; a="64814189" Received: from exc-cashub03.tsn.tno.nl (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1a.tno.nl with ESMTP; 12 Jun 2016 22:46:29 +0200 Received: from EXC-MBX03.tsn.tno.nl ([fe80::e969:1300:fb9f:7e12]) by EXC-CASHUB03.tsn.tno.nl ([fe80::6d39:f277:173e:a926%13]) with mapi id 14.03.0294.000; Sun, 12 Jun 2016 22:46:29 +0200 From: "Brandenburg, R. (Ray) van" To: Kevin Ma J Thread-Topic: New version (and IPR statement) of draft-brandenburg-cdni-uri-signing-for-has Thread-Index: AQHRwy2I54wAQQPyYkOQMx8zvzoaI5/kbdJggAHi0LM= Date: Sun, 12 Jun 2016 20:46:28 +0000 Message-ID: <773C358A-078D-477A-A547-DB376B60635E@tno.nl> References: <90041886-D253-413F-B006-50BDA558EB12@tno.nl>, In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-esetresult: clean, is OK x-esetid: 37303A29F368486F627260 Content-Type: multipart/alternative; boundary="_000_773C358A078D477AA547DB376B60635Etnonl_" MIME-Version: 1.0 Archived-At: Cc: "cdni@ietf.org" Subject: Re: [CDNi] New version (and IPR statement) of draft-brandenburg-cdni-uri-signing-for-has X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jun 2016 20:46:34 -0000 --_000_773C358A078D477AA547DB376B60635Etnonl_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Kevin, Fwiw: I checked and the IPR statement should have been filed as an update i= nstead of a new one. A request has been filed to the secretariat to fix thi= s. Ray On 11 Jun 2016, at 20:57, Kevin Ma J > wrote: Hi All, (As a chair) Per the decision in BA (https://www.ietf.org/proceedings/95/= minutes/minutes-95-cdni), we deferred discussion of whether to (re)adopt dr= aft-brandenburg-cdni-uri-signing-for-has as a WG item. For historical cont= ext, in Prague, we decided to separate the IPR encumbered portion of URI si= gning from the WG draft (https://www.ietf.org/proceedings/93/minutes/minute= s-93-cdni). There is a new IPR disclosure (https://datatracker.ietf.org/ipr/2806/) av= ailable that folks should take a look at. Note: I'm not sure if it should = have been an update to the previous disclosure (https://datatracker.ietf.or= g/ipr/2652/) or whether that makes a difference? Alexey? If folks have thoughts about whether or not we should (re)adopt the HAS U= RI signing work, in light of the new IPR disclosure, please send your comme= nts to the list. thanx! -- Kevin J. Ma From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Brandenburg, R. (Ray= ) van Sent: Friday, June 10, 2016 11:34 AM To: cdni@ietf.org Subject: [CDNi] New version (and IPR statement) of draft-brandenburg-cdni-u= ri-signing-for-has Hi all, As you might have seen, I=92ve recently uploaded a new version of draft-bra= ndenburg-cdni-uri-signing-for-has (-03). https://tools.ietf.org/html/draft-brandenburg-cdni-uri-signing-for-has-03 What is important to note is that KPN has updated it=92s IPR statement on t= his document to be in line with the IPR statements that have been filed on = other CDNI documents (i.e. =93Royalty-Free, Reasonable and Non-Discriminato= ry License to All Implementers=94). Hopefully this clears up the lengthy IP= R discussion we=92ve been having around this document so that we can focus = on the technical aspects again. Looking forward to your feedback, Ray This message may contain information that is not intended for you. If you a= re not the addressee or if this message was sent to you by mistake, you are= requested to inform the sender and delete the message. TNO accepts no liab= ility for the content of this e-mail, for the manner in which you use it an= d for damage of any kind resulting from the risks inherent to the electroni= c transmission of messages. --_000_773C358A078D477AA547DB376B60635Etnonl_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Kevin,

Fwiw: I checked and the IPR statement should have been filed as an upd= ate instead of a new one. A request has been filed to the secretariat to fi= x this. 

Ray

On 11 Jun 2016, at 20:57, Kevin Ma J <kevin.j.ma@ericsson.com> wrote:

Hi All,

 

  (As a chair) Per the decision in BA (https://www.ietf.= org/proceedings/95/minutes/minutes-95-cdni), we deferred discussion of whether to (re)adopt draft-brandenburg-cdni-uri-signing-for-= has as a WG item.  For historical context, in Prague, we decided to se= parate the IPR encumbered portion of URI signing from the WG draft (https://ww= w.ietf.org/proceedings/93/minutes/minutes-93-cdni).

 

  There is a new IPR disclosure (https://datatracker.ietf.org/ipr/2806/) = available that folks should take a look at.  Note: I'm not sure if it should have been an update to the previous disclosure (https://datatracker.ietf.org= /ipr/2652/) or whether that makes a difference?  Alexey?

 

  If folks have thoughts about whether or not we shou= ld (re)adopt the HAS URI signing work, in light of the new IPR disclosure, = please send your comments to the list.

 

thanx!

 

--  Kevin J. Ma

 

From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Brandenburg, R. (Ray) van
Sent: Friday, June 10, 2016 11:34 AM
To: cdni@ietf.org
Subject: [CDNi] New version (and IPR statement) of draft-brandenburg= -cdni-uri-signing-for-has

 

Hi all,<= /span>

 

As you might have s= een, I=92ve recently uploaded a new version of draft-brandenburg-cdni-uri-s= igning-for-has (-03).

 

https://= tools.ietf.org/html/draft-brandenburg-cdni-uri-signing-for-has-03<= /o:p>

 

What is important t= o note is that KPN has updated it=92s IPR statement on this document to be = in line with the IPR statements that have been filed on other CDNI document= s (i.e. =93Royalty-Free, Reasonable and Non-Discriminatory License to All Implementers=94). Hopefully this clears = up the lengthy IPR discussion we=92ve been having around this document so t= hat we can focus on the technical aspects again.

 

Looking forward to = your feedback,

Ray

 

This messag= e may contain information that is not intended for you. If you are not the = addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no = liability for the content of this e-mail, for the manner in which you use i= t and for damage of any kind resulting from the risks inherent to the elect= ronic transmission of messages.

--_000_773C358A078D477AA547DB376B60635Etnonl_-- From nobody Sun Jun 12 14:13:20 2016 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 314B712D1D2 for ; Sun, 12 Jun 2016 14:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXd7mXq5eKWA for ; Sun, 12 Jun 2016 14:13:17 -0700 (PDT) Received: from mailex.mailcore.me (smtp.123-reg.co.uk [94.136.40.63]) by ietfa.amsl.com (Postfix) with ESMTP id 1022A12D0F9 for ; Sun, 12 Jun 2016 14:13:16 -0700 (PDT) Received: from [118.201.150.4] (helo=[10.5.1.220]) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1bCCh1-0005Va-1e; Sun, 12 Jun 2016 22:13:15 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ben Niven-Jenkins In-Reply-To: Date: Sun, 12 Jun 2016 22:13:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1464861734.1246901.625717065.0912CC9E@webmail.messagingengine.com> To: Kevin Ma J X-Mailer: Apple Mail (2.2098) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: Cc: "cdni@ietf.org" Subject: Re: [CDNi] Early AD review of draft-ietf-cdni-metadata-17 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jun 2016 21:13:19 -0000 Alexey, Kevin, I=E2=80=99m coming to the party a bit late (unfortunately I have very = little time for IETF work these days). This caught my eye and I wanted = to comment on it. > On 2 Jun 2016, at 15:15, Kevin Ma J wrote: >=20 > wrt: >>> In 7.4: I think I am sad that you haven't defined any initial >>> authentication mechanism. Has this been discussed in the WG? >=20 > The thought behind this was that URI Signing would be the primary = delivery auth mechanism, and could also be used for acquisition auth; = but thank you for reminding me that I missed the Auth Type registration = in https://tools.ietf.org/html/draft-ietf-cdni-uri-signing-07#section-8. = :) URL signing provides authorisation, not authentication. At the time my opinion/thinking (and it hasn=E2=80=99t changed since) = was: - The vast majority of HTTP content is delivered without authentication. - Defining authentication is hard - by which I mean the auth itself is = not hard, specifying a secure way to distribute secrets etc is hard, as = illustrated by the need for a LURK WG for doing something similar for = related but not identical use cases to CDNI. - I was worried trying to define a secure way to distribute auth secrets = etc would delay the work unnecessarily both in terms of time spent in = the WG and time spent getting whatever mechanism we defined past the = IESG. Authenticating the channel over which the CDNI metadata is distributed = (as opposed to authenticating the User Agent/user requesting the content = from the dCDN) is already specified/mandated in the document IIRC. Ben From nobody Sun Jun 12 14:14:25 2016 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 A10B612D0F9 for ; Sun, 12 Jun 2016 14:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.345 X-Spam-Level: X-Spam-Status: No, score=-8.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] 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 IF7pJ-78hs37 for ; Sun, 12 Jun 2016 14:14:22 -0700 (PDT) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by ietfa.amsl.com (Postfix) with SMTP id D277B12D63E for ; Sun, 12 Jun 2016 14:14:22 -0700 (PDT) Received: (qmail 67769 invoked by uid 99); 12 Jun 2016 21:14:21 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 12 Jun 2016 21:14:21 +0000 Received: from mail-io0-f171.google.com (mail-io0-f171.google.com [209.85.223.171]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 0B0FA1A030D for ; Sun, 12 Jun 2016 21:14:20 +0000 (UTC) Received: by mail-io0-f171.google.com with SMTP id o127so59488808iod.2 for ; Sun, 12 Jun 2016 14:14:20 -0700 (PDT) X-Gm-Message-State: ALyK8tJYMgloCJu0GzPGIkYpXb51kRIWl+Lzs3b7rvs9rIvLWL8hI9h0q8oq6FdWiaIOjSmrtBBdAqbGW+h8xw== X-Received: by 10.107.175.227 with SMTP id p96mr17337729ioo.78.1465766060304; Sun, 12 Jun 2016 14:14:20 -0700 (PDT) MIME-Version: 1.0 References: <90041886-D253-413F-B006-50BDA558EB12@tno.nl> In-Reply-To: From: Phil Sorber Date: Sun, 12 Jun 2016 21:14:10 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Kevin Ma J , "Brandenburg, R. (Ray) van" , "cdni@ietf.org" Content-Type: multipart/alternative; boundary=001a11445f5a59321705351b41ca Archived-At: Subject: Re: [CDNi] New version (and IPR statement) of draft-brandenburg-cdni-uri-signing-for-has X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jun 2016 21:14:24 -0000 --001a11445f5a59321705351b41ca Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am in favor of adopting draft-brandenburg-cdni-uri-signing-for-has. On Sat, Jun 11, 2016 at 12:57 PM Kevin Ma J wrote= : > Hi All, > > > > (As a chair) Per the decision in BA ( > https://www.ietf.org/proceedings/95/minutes/minutes-95-cdni), we deferred > discussion of whether to (re)adopt > draft-brandenburg-cdni-uri-signing-for-has as a WG item. For historical > context, in Prague, we decided to separate the IPR encumbered portion of > URI signing from the WG draft ( > https://www.ietf.org/proceedings/93/minutes/minutes-93-cdni). > > > > There is a new IPR disclosure (https://datatracker.ietf.org/ipr/2806/) > available that folks should take a look at. Note: I'm not sure if it > should have been an update to the previous disclosure ( > https://datatracker.ietf.org/ipr/2652/) or whether that makes a > difference? Alexey? > > > > If folks have thoughts about whether or not we should (re)adopt the HAS > URI signing work, in light of the new IPR disclosure, please send your > comments to the list. > > > > thanx! > > > > -- Kevin J. Ma > > > > *From:* CDNi [mailto:cdni-bounces@ietf.org] *On Behalf Of *Brandenburg, > R. (Ray) van > *Sent:* Friday, June 10, 2016 11:34 AM > *To:* cdni@ietf.org > *Subject:* [CDNi] New version (and IPR statement) of > draft-brandenburg-cdni-uri-signing-for-has > > > > Hi all, > > > > As you might have seen, I=E2=80=99ve recently uploaded a new version of > draft-brandenburg-cdni-uri-signing-for-has (-03). > > > > https://tools.ietf.org/html/draft-brandenburg-cdni-uri-signing-for-has-03 > > > > What is important to note is that KPN has updated it=E2=80=99s IPR statem= ent on > this document to be in line with the IPR statements that have been filed = on > other CDNI documents (i.e. =E2=80=9CRoyalty-Free, Reasonable and Non-Disc= riminatory > License to All Implementers=E2=80=9D). Hopefully this clears up the lengt= hy IPR > discussion we=E2=80=99ve been having around this document so that we can = focus on > the technical aspects again. > > > > Looking forward to your feedback, > > Ray > > > > This message may contain information that is not intended for you. If you > are not the addressee or if this message was sent to you by mistake, you > are requested to inform the sender and delete the message. TNO accepts no > liability for the content of this e-mail, for the manner in which you use > it and for damage of any kind resulting from the risks inherent to the > electronic transmission of messages. > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > --001a11445f5a59321705351b41ca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am in favor of adopting draft-brandenburg-cdni-uri-signi= ng-for-has.

On Sat, Jun = 11, 2016 at 12:57 PM Kevin Ma J <kevin.j.ma@ericsson.com> wrote:

Hi All,

=C2=A0

=C2=A0 (As a chair) Per the decision in BA (https://www.ietf.org/proceedings/95/minutes/minutes-95-cdni), we defer= red discussion of whether to (re)adopt draft-brandenburg-cdni-uri-signing-for-= has as a WG item.=C2=A0 For historical context, in Prague, we decided to se= parate the IPR encumbered portion of URI signing from the WG draft (https://www.ietf.org/proceedings/93/minutes/minutes-93-cdni).

=C2=A0

=C2=A0 There is a new IPR disclosure (https://datatracker.ietf.o= rg/ipr/2806/) available that folks should take a look at.=C2=A0 Note: I= 'm not sure if it should have been an update to the previous disclosure (https://da= tatracker.ietf.org/ipr/2652/) or whether that makes a difference?=C2=A0= Alexey?

=C2=A0

=C2=A0 If folks have thoughts about whether or not we shou= ld (re)adopt the HAS URI signing work, in light of the new IPR disclosure, = please send your comments to the list.

=C2=A0

thanx!

=C2=A0

--=C2=A0 Kevin J. Ma

=C2=A0

From: CDNi [ma= ilto:cdni-bounce= s@ietf.org] On Behalf Of Brandenburg, R. (Ray) van
Sent: Friday, June 10, 2016 11:34 AM
To: cdni@ietf.org=
Subject: [CDNi] New version (and IPR statement) of draft-brandenburg= -cdni-uri-signing-for-has

=C2=A0

Hi all,

=C2=A0

As you might have s= een, I=E2=80=99ve recently uploaded a new version of draft-brandenburg-cdni= -uri-signing-for-has (-03).

=C2=A0

https://tools.ietf.org/html/draft-brandenburg-cdni-uri-signing-= for-has-03

=C2=A0

What is important t= o note is that KPN has updated it=E2=80=99s IPR statement on this document = to be in line with the IPR statements that have been filed on other CDNI do= cuments (i.e. =E2=80=9CRoyalty-Free, Reasonable and Non-Discriminatory License to All Implementers=E2=80=9D). Hopefully this c= lears up the lengthy IPR discussion we=E2=80=99ve been having around this d= ocument so that we can focus on the technical aspects again.

=C2=A0

Looking forward to = your feedback,

Ray

=C2=A0

This messag= e may contain information that is not intended for you. If you are not the = addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no = liability for the content of this e-mail, for the manner in which you use i= t and for damage of any kind resulting from the risks inherent to the elect= ronic transmission of messages.

_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni
--001a11445f5a59321705351b41ca-- From nobody Mon Jun 13 05:53:01 2016 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 AAFC812B065 for ; Mon, 13 Jun 2016 05:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=LoBfQo+R; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=MQ4nGIIv 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 uctmUSGd1ohj for ; Mon, 13 Jun 2016 05:52:57 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E678C12B036 for ; Mon, 13 Jun 2016 05:52:56 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 6089720C31 for ; Mon, 13 Jun 2016 08:52:56 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute2.internal (MEProxy); Mon, 13 Jun 2016 08:52:56 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=MG4R56w01h07N19SBHkmjcHmpwk=; b=LoBfQo +RF/Nj153Y/wQij3B5meaoR2fu1QZA2BZJv6kzOwX6EiWuxeWoSdOw/YP9MgjmGx KKXQLxxAk9UNz84hw16eWxyRi72wldaTmkOS0gthVYupV7LOorx2LAaHARE4E5PP 4kzzLQzhvyCoAVyK3h273ckBrBnE7jSrgC/E4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=MG4R56w01h07N19 SBHkmjcHmpwk=; b=MQ4nGIIvBvkg+2z47eLbS6JCX6JbYlKIoubyCjkUYdwIwrJ ltQ16vawNsQDOqQ7QAgX6hAcLOB0pXD4wFrR4XzQrqWvvSZztUus5BftKZnzN1ah Wz9/bC5wB6PvhL3WSSZc13PM1iEppz4Rb+BW68u9KxSC2ay3cF/vbiq5BMRw= Received: by mailuser.nyi.internal (Postfix, from userid 99) id 2E873A906F; Mon, 13 Jun 2016 08:52:56 -0400 (EDT) Message-Id: <1465822376.2345831.636047169.2F7E30C4@webmail.messagingengine.com> X-Sasl-Enc: IofdxJdH94rBM5X5nd115kJLFmZcP2KRbNZQ4o0gPjAL 1465822376 From: Alexey Melnikov To: cdni@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-aff28cd1 Date: Mon, 13 Jun 2016 13:52:56 +0100 In-Reply-To: <1464861734.1246901.625717065.0912CC9E@webmail.messagingengine.com> References: <1464861734.1246901.625717065.0912CC9E@webmail.messagingengine.com> Archived-At: Subject: [CDNi] Early AD review of draft-ietf-cdni-metadata-18 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jun 2016 12:53:00 -0000 Thank you for addressing most of my concerns. Here is the updated list of issues: In 4.1.2: hostname need to have defined syntax (at least by reference). You also need to say whether IDN domain names are allowed here. In 6.1: The CDNI metadata interface specified in this document is a read-only interface. Therefore support for other HTTP methods such as PUT, POST, DELETE, etc. is not specified. A server implementation of the CDNI metadata interface MUST reject all methods other than GET and HEAD. I think the change to the MUST is too strong and is a wrong thing to do, because that means that existing HTTP/1.1 software might have to be modified to support this specification. So I would prefer that you either delete the last sentence or reword to say "doesn't have to support any methods other that ..." In 8.3: An implementation of the CDNI metadata interface MUST use strong encryption and mutual authentication to prevent undetectable Encryption doesn't necessarily provide integrity of data, so I would change "strong encryption" to TLS. modification of metadata (see Section 8.5). On Thu, Jun 2, 2016, at 11:02 AM, Alexey Melnikov wrote: > In order to speed up publication of this draft, I decided to do early AD > review. Here are my comments. My apologies if they are a bit cryptic, if > you are unsure of what I meant, please ask! > > In 1.2: content can only be delivered using HTTP/1.1 and not HTTP/1.1 > over TLS? Is last para saying that this is an unsolved problem (e.g. > LURK BOF solution is needed)? > > In 4.1.2: hostname and IP addresses need to have defined syntaxes (at > least by reference). You also need to say whether IDN domain names are > allowed here. > > In 4.1.5: does "case insensitive" only applies to ASCII range? I.e., > encoded UTF-8 sequences in URIs are not affected. > > In 4.2.6: URI needs a Normative Reference (RFC 3986). > > In 4.3.7: need a reference to a document/registry defining ASNs. > > In 6.1: need a reference to HTTP/1.1 spec. > > Should OPTIONS method be allowed? > > In 6.2/6.3: Is discovery of the initial URI truly out of scope? You can > define a .well-known URI to allow bootstrapping. > If it is defined, is it likely to be used? > > In 7.3: Nit: HTTP/1.1 over TLS needs 2 references, not just one. > > In 7.4: I think I am sad that you haven't defined any initial > authentication mechanism. Has this been discussed in the WG? > > In 8.1, last para: a requirement to implement mutual authentication is > underspecified. Do you mean TLS mutual authentication? If yes, say so. > If other mechanisms can be used, say so as well. > If you meant to reference 8.5 here, please do so. > > Why is this only a SHOULD (and not a MUST)? > > In 8.2: similarly, how can the SHOULD be satisfied? Do you mean TLS or > something else? Reference 8.5? > > In 8.3: similar issue. > > Also encryption doesn't necessarily provide integrity of data, so the > last sentence sounds wrong. > > In 8.4: similar issue. From nobody Mon Jun 13 12:14:18 2016 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 BC87412D944; Mon, 13 Jun 2016 12:14:12 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.22.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160613191412.6888.8117.idtracker@ietfa.amsl.com> Date: Mon, 13 Jun 2016 12:14:12 -0700 Archived-At: Cc: alexey.melnikov@isode.com, flefauch@cisco.com, cdni@ietf.org, draft-ietf-cdni-metadata@ietf.org, cdni-chairs@ietf.org Subject: [CDNi] Last Call: (CDN Interconnection Metadata) to Proposed Standard X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org 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, 13 Jun 2016 19:14:13 -0000 The IESG has received a request from the Content Delivery Networks Interconnection WG (cdni) to consider the following document: - 'CDN Interconnection Metadata' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-06-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Content Delivery Networks Interconnection (CDNI) metadata interface enables interconnected Content Delivery Networks (CDNs) to exchange content distribution metadata in order to enable content acquisition and delivery. The CDNI metadata associated with a piece of content provides a downstream CDN with sufficient information for the downstream CDN to service content requests on behalf of an upstream CDN. This document describes both a base set of CDNI metadata and the protocol for exchanging that metadata. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-cdni-metadata/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-cdni-metadata/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Jun 13 14:01:20 2016 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 1853012DA23 for ; Mon, 13 Jun 2016 14:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7RX1fO4V0_1 for ; Mon, 13 Jun 2016 14:01:09 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 126ED12DA20 for ; Mon, 13 Jun 2016 14:01:09 -0700 (PDT) X-AuditID: c618062d-f79886d000002334-59-575f158ebb4a Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 39.EE.09012.E851F575; Mon, 13 Jun 2016 22:20:31 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0294.000; Mon, 13 Jun 2016 17:01:07 -0400 From: Kevin Ma J To: Alexey Melnikov , "cdni@ietf.org" Thread-Topic: [CDNi] Early AD review of draft-ietf-cdni-metadata-18 Thread-Index: AQHRxXKTDE1Cgkb4nEmGuN8N4i4y4p/n4rTg Date: Mon, 13 Jun 2016 21:01:05 +0000 Message-ID: References: <1464861734.1246901.625717065.0912CC9E@webmail.messagingengine.com> <1465822376.2345831.636047169.2F7E30C4@webmail.messagingengine.com> In-Reply-To: <1465822376.2345831.636047169.2F7E30C4@webmail.messagingengine.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyuXRPuG6/aHy4wcUprBb73x9isng6+w+r A5PHzlMH2DyWLPnJFMAUxWWTkpqTWZZapG+XwJXRc3obW8Ec2Yqdf1ayNDA+Euti5OSQEDCR +Pr/BROELSZx4d56ti5GLg4hgaOMEg0L5jBBOMsZJdb9mc8KUsUmoCXx+OtfsA4RAV+J1Yv+ gcWFBZwkJqyYywwRd5bY2vKGDcI2knj08Q87iM0ioCpxdUovC4jNC9S76fZlqAU3GSWWr1wB NohTIEBi0vzPYAsYgU76fmoNmM0sIC5x68l8qFMFJJbsOc8MYYtKvHwMcYSEgJLEnNfXmCHq dSQW7P7EBmFrSyxb+JoZYrGgxMmZT1gmMIrOQjJ2FpKWWUhaZiFpWcDIsoqRo7S4ICc33chg EyMwIo5JsOnuYLw/3fMQowAHoxIPr8Li2HAh1sSy4srcQ4wSHMxKIrxzZeLDhXhTEiurUovy 44tKc1KLDzFKc7AoifOKPVIMFxJITyxJzU5NLUgtgskycXBKNTA6b969XfNK56MQl/CmiLic nHPWXex6sq/LtXbFme+Y3v9peUj9scjSRNXzr1Knt3t9Yv5xW5PxPPO3JWnBvmffh3mn+Bv/ L3YwUczfe3HeX1HOm0pzUyx+u27zUEm8kKsVayC+sIhla8ansn6nEGvHjZumFYl05S4TW/hI /FHLl+jeg20MD5RYijMSDbWYi4oTARv8FjCEAgAA Archived-At: Subject: Re: [CDNi] Early AD review of draft-ietf-cdni-metadata-18 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jun 2016 21:01:13 -0000 Hi Alexey, We will address and upload a new diff. thanx! -- Kevin J. Ma > -----Original Message----- > From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Alexey Melnikov > Sent: Monday, June 13, 2016 8:53 AM > To: cdni@ietf.org > Subject: [CDNi] Early AD review of draft-ietf-cdni-metadata-18 >=20 > Thank you for addressing most of my concerns. Here is the updated list > of issues: >=20 > In 4.1.2: hostname need to have defined syntax (at least by reference). > You also need to say whether IDN domain names are > allowed here. >=20 > In 6.1: >=20 > The CDNI metadata interface specified in this document is a read-only > interface. Therefore support for other HTTP methods such as PUT, > POST, DELETE, etc. is not specified. A server implementation of the > CDNI metadata interface MUST reject all methods other than GET and > HEAD. >=20 > I think the change to the MUST is too strong and is a wrong thing to do, > because that means that existing HTTP/1.1 software might have to be > modified to > support this specification. >=20 > So I would prefer that you either delete the last sentence or reword to > say > "doesn't have to support any methods other that ..." >=20 > In 8.3: >=20 > An implementation of the CDNI metadata interface MUST use strong > encryption and mutual authentication to prevent undetectable >=20 > Encryption doesn't necessarily provide integrity of data, so I would > change "strong encryption" to TLS. >=20 > modification of metadata (see Section 8.5). >=20 >=20 > On Thu, Jun 2, 2016, at 11:02 AM, Alexey Melnikov wrote: > > In order to speed up publication of this draft, I decided to do early A= D > > review. Here are my comments. My apologies if they are a bit cryptic, i= f > > you are unsure of what I meant, please ask! > > > > In 1.2: content can only be delivered using HTTP/1.1 and not HTTP/1.1 > > over TLS? Is last para saying that this is an unsolved problem (e.g. > > LURK BOF solution is needed)? > > > > In 4.1.2: hostname and IP addresses need to have defined syntaxes (at > > least by reference). You also need to say whether IDN domain names are > > allowed here. > > > > In 4.1.5: does "case insensitive" only applies to ASCII range? I.e., > > encoded UTF-8 sequences in URIs are not affected. > > > > In 4.2.6: URI needs a Normative Reference (RFC 3986). > > > > In 4.3.7: need a reference to a document/registry defining ASNs. > > > > In 6.1: need a reference to HTTP/1.1 spec. > > > > Should OPTIONS method be allowed? > > > > In 6.2/6.3: Is discovery of the initial URI truly out of scope? You can > > define a .well-known URI to allow bootstrapping. > > If it is defined, is it likely to be used? > > > > In 7.3: Nit: HTTP/1.1 over TLS needs 2 references, not just one. > > > > In 7.4: I think I am sad that you haven't defined any initial > > authentication mechanism. Has this been discussed in the WG? > > > > In 8.1, last para: a requirement to implement mutual authentication is > > underspecified. Do you mean TLS mutual authentication? If yes, say so. > > If other mechanisms can be used, say so as well. > > If you meant to reference 8.5 here, please do so. > > > > Why is this only a SHOULD (and not a MUST)? > > > > In 8.2: similarly, how can the SHOULD be satisfied? Do you mean TLS or > > something else? Reference 8.5? > > > > In 8.3: similar issue. > > > > Also encryption doesn't necessarily provide integrity of data, so the > > last sentence sounds wrong. > > > > In 8.4: similar issue. >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From nobody Mon Jun 13 14:02:37 2016 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 A4A9812DA29 for ; Mon, 13 Jun 2016 14:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7n0WYoK_1lho for ; Mon, 13 Jun 2016 14:01:37 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4638E12DA20 for ; Mon, 13 Jun 2016 14:01:36 -0700 (PDT) X-AuditID: c6180641-f796f6d000000e1e-92-575f1ef49d46 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 83.82.03614.4FE1F575; Mon, 13 Jun 2016 23:00:36 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0294.000; Mon, 13 Jun 2016 17:01:35 -0400 From: Kevin Ma J To: Alexey Melnikov , "cdni@ietf.org" Thread-Topic: [CDNi] Early AD review of draft-ietf-cdni-metadata-18 Thread-Index: AQHRxXKTDE1Cgkb4nEmGuN8N4i4y4p/n4rTggAAATHA= Date: Mon, 13 Jun 2016 21:01:34 +0000 Message-ID: References: <1464861734.1246901.625717065.0912CC9E@webmail.messagingengine.com> <1465822376.2345831.636047169.2F7E30C4@webmail.messagingengine.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyuXRPiO4Xufhwg513LCz2vz/EZPF09h9W ByaPnacOsHksWfKTKYApissmJTUnsyy1SN8ugStjW+MFtoK9ChUTJ1xha2B8KdHFyMkhIWAi sfDaXCYIW0ziwr31bF2MXBxCAkcZJRatXc8E4SxnlHjXM4MdpIpNQEvi8de/YB0iAr4Sqxf9 YwWxhQWcJCasmMsMEXeW2Nryhg3CtpI4eusHkM3BwSKgKtH3vxokzAvU+vpLByvE/FuMEmfu bwebzwh0xfdTa8DmMwuIS9x6Mh/qOgGJJXvOM0PYohIvH0PslRBQkpjz+hozRL2OxILdn9gg bG2JZQtfM0MsE5Q4OfMJywRGkVlIxs5C0jILScssJC0LGFlWMXKUFhfk5KYbGW5iBIb9MQk2 xx2Me3s9DzEKcDAq8fAm3I4NF2JNLCuuzD3EKMHBrCTCO1cmPlyINyWxsiq1KD++qDQntfgQ ozQHi5I4r/5LxXAhgfTEktTs1NSC1CKYLBMHp1QDY+U6jfq8a7kXJb/JeG5u7pY4cV8i72fT uurv3xQ3qJ4sq9qYIfo/tdnO+3CiimrkUa5XMslOLFE/+P1i37cpcH6umPHu9PmFVzbEv/Cd Hl4tPidu/bIFJwrL/qmb1NaaB+yrECgTS3H4cDHJ9dTPp9eXWP+KKlrG/X6qPLeR7YXZVzyt 90cvVGIpzkg01GIuKk4EAET0Z0R3AgAA Archived-At: Subject: Re: [CDNi] Early AD review of draft-ietf-cdni-metadata-18 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jun 2016 21:01:41 -0000 s/diff/draft > -----Original Message----- > From: Kevin Ma J > Sent: Monday, June 13, 2016 5:03 PM > To: 'Alexey Melnikov'; cdni@ietf.org > Subject: RE: [CDNi] Early AD review of draft-ietf-cdni-metadata-18 >=20 > Hi Alexey, >=20 > We will address and upload a new diff. >=20 > thanx! >=20 > -- Kevin J. Ma >=20 > > -----Original Message----- > > From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Alexey Melnikov > > Sent: Monday, June 13, 2016 8:53 AM > > To: cdni@ietf.org > > Subject: [CDNi] Early AD review of draft-ietf-cdni-metadata-18 > > > > Thank you for addressing most of my concerns. Here is the updated list > > of issues: > > > > In 4.1.2: hostname need to have defined syntax (at least by reference). > > You also need to say whether IDN domain names are > > allowed here. > > > > In 6.1: > > > > The CDNI metadata interface specified in this document is a read-onl= y > > interface. Therefore support for other HTTP methods such as PUT, > > POST, DELETE, etc. is not specified. A server implementation of the > > CDNI metadata interface MUST reject all methods other than GET and > > HEAD. > > > > I think the change to the MUST is too strong and is a wrong thing to do= , > > because that means that existing HTTP/1.1 software might have to be > > modified to > > support this specification. > > > > So I would prefer that you either delete the last sentence or reword to > > say > > "doesn't have to support any methods other that ..." > > > > In 8.3: > > > > An implementation of the CDNI metadata interface MUST use strong > > encryption and mutual authentication to prevent undetectable > > > > Encryption doesn't necessarily provide integrity of data, so I would > > change "strong encryption" to TLS. > > > > modification of metadata (see Section 8.5). > > > > > > On Thu, Jun 2, 2016, at 11:02 AM, Alexey Melnikov wrote: > > > In order to speed up publication of this draft, I decided to do early > AD > > > review. Here are my comments. My apologies if they are a bit cryptic, > if > > > you are unsure of what I meant, please ask! > > > > > > In 1.2: content can only be delivered using HTTP/1.1 and not HTTP/1.1 > > > over TLS? Is last para saying that this is an unsolved problem (e.g. > > > LURK BOF solution is needed)? > > > > > > In 4.1.2: hostname and IP addresses need to have defined syntaxes (at > > > least by reference). You also need to say whether IDN domain names ar= e > > > allowed here. > > > > > > In 4.1.5: does "case insensitive" only applies to ASCII range? I.e., > > > encoded UTF-8 sequences in URIs are not affected. > > > > > > In 4.2.6: URI needs a Normative Reference (RFC 3986). > > > > > > In 4.3.7: need a reference to a document/registry defining ASNs. > > > > > > In 6.1: need a reference to HTTP/1.1 spec. > > > > > > Should OPTIONS method be allowed? > > > > > > In 6.2/6.3: Is discovery of the initial URI truly out of scope? You > can > > > define a .well-known URI to allow bootstrapping. > > > If it is defined, is it likely to be used? > > > > > > In 7.3: Nit: HTTP/1.1 over TLS needs 2 references, not just one. > > > > > > In 7.4: I think I am sad that you haven't defined any initial > > > authentication mechanism. Has this been discussed in the WG? > > > > > > In 8.1, last para: a requirement to implement mutual authentication i= s > > > underspecified. Do you mean TLS mutual authentication? If yes, say so= . > > > If other mechanisms can be used, say so as well. > > > If you meant to reference 8.5 here, please do so. > > > > > > Why is this only a SHOULD (and not a MUST)? > > > > > > In 8.2: similarly, how can the SHOULD be satisfied? Do you mean TLS o= r > > > something else? Reference 8.5? > > > > > > In 8.3: similar issue. > > > > > > Also encryption doesn't necessarily provide integrity of data, so the > > > last sentence sounds wrong. > > > > > > In 8.4: similar issue. > > > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni From nobody Sun Jun 19 08:36:08 2016 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 82ACE12D51F for ; Sun, 19 Jun 2016 08:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 hWFsO-lloGmG for ; Sun, 19 Jun 2016 08:36:05 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::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 7D49412D50E for ; Sun, 19 Jun 2016 08:36:05 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id r201so30552505wme.1 for ; Sun, 19 Jun 2016 08:36:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:message-id:date:to:mime-version; bh=LP7ow0OJhNd99z6m+mGy0zRT6Vpm6B8gJgJkw/JHxns=; b=dqrNkKOWiJFjpnCcW7OZAgpxqr2ZPXBKqzMM6h2a6EVEwdwVAOXnO+l5mI8GqoywFU ImpAsryHEHJPadkLxnS9CK9aGOyNKRsXE1lcUvjWCka27FiXf1W5FvA7A7tP3xQCRtJz p3PBSvl9cEHrnMFUs7C6e7T83lJh4n9998gCAKKuZb/zJxzmy4Tdo39hrwA8d+3OUZWZ adVX9VNXwhkKKyXpScfOZkS5wq6/K407aGtIn65po8zthemkKL1hutgFWT5hWRNmIGbR f5NM6veLen+ZF4YaAAnuy+pSCPfUJ/fY/bi+mVXFbwYCrJVVumtX/R2j8EeWALvLFm7q 87bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:message-id:date:to:mime-version; bh=LP7ow0OJhNd99z6m+mGy0zRT6Vpm6B8gJgJkw/JHxns=; b=KqCW2cRkasKwoByep42auuFSv3ubjOiENypH/djXJ9l6+D9Gk+EoZuph1rr/4hOYfK J1H/3SwxMRkhXE/UObVBpR9o6zW6ezWfdVlNvDXMJayK4ifuyZPf7Jd9ol8m7HjUp1CI 2X2EA8rpC5As5hV0cVbwu6xBAe0PRmSlRa9ljWh+FpL660b2ucVvYCsdmJMUaIIxm+YA r1EPzvKwSeu9Oh1f58H+6bQ2ITQzh8i1wsBNgI52r/geNTAIwZfEOs3rVBVwt8jmFgMY K7nllObPtyKVWrIe2A6bJVHdALoGjBAC75C93gkwJsUD8RQ8h2qci7eFhheKHfNZBo0A 3ARw== X-Gm-Message-State: ALyK8tLn7NKRp78ajPKAx20JnHEjqSPHnkVRtENhZgYxP37b13X4W0DMcGaWW2D3gHyy9Q== X-Received: by 10.194.85.161 with SMTP id i1mr11526666wjz.95.1466350563909; Sun, 19 Jun 2016 08:36:03 -0700 (PDT) Received: from [192.168.1.21] (125.216.113.78.rev.sfr.net. [78.113.216.125]) by smtp.gmail.com with ESMTPSA id bh4sm29056502wjc.43.2016.06.19.08.36.02 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 19 Jun 2016 08:36:03 -0700 (PDT) From: Francois Le Faucheur Content-Type: multipart/alternative; boundary="Apple-Mail=_76E3DD92-2BC4-4716-BA5D-69D1CB9D9F42" Message-Id: <80669C0F-905B-4E71-B49C-2134C5C9ABDC@gmail.com> Date: Sun, 19 Jun 2016 17:35:58 +0200 To: "" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [CDNi] IETF-96 Berlin, CDNI WG meeting tentatively scheduled on Tuesday 16:20 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 19 Jun 2016 15:36:07 -0000 --Apple-Mail=_76E3DD92-2BC4-4716-BA5D-69D1CB9D9F42 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Folks, See preliminary agenda at: https://datatracker.ietf.org/meeting/96/agenda.html 16:20-18:20 Tuesday Afternoon session II Charlottenburg I = = art cdni Content = Delivery Networks Interconnection See you in Berlin, Francois= --Apple-Mail=_76E3DD92-2BC4-4716-BA5D-69D1CB9D9F42 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Folks,

See preliminary agenda at:
https://datatracker.ietf.org/meeting/96/agenda.html



16:20-18:20Tuesday Afternoon session II
Charlottenburg = IartcdniContent Delivery = Networks Interconnection

See you in Berlin,

Francois
= --Apple-Mail=_76E3DD92-2BC4-4716-BA5D-69D1CB9D9F42-- From nobody Mon Jun 20 04:08:44 2016 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 611FD12B006; Mon, 20 Jun 2016 04:08:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160620110842.30198.11054.idtracker@ietfa.amsl.com> Date: Mon, 20 Jun 2016 04:08:42 -0700 Archived-At: Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-uri-signing-08.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jun 2016 11:08: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 of the IETF. Title : URI Signing for CDN Interconnection (CDNI) Authors : Kent Leung Francois Le Faucheur Ray van Brandenburg Bill Downey Michel Fisher Filename : draft-ietf-cdni-uri-signing-08.txt Pages : 47 Date : 2016-06-20 Abstract: This document describes how the concept of URI signing supports the content access control requirements of CDNI and proposes a URI signing scheme. The proposed URI signing method specifies the information needed to be included in the URI and the algorithm used to authorize and to validate access requests for the content referenced by the URI. 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's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-cdni-uri-signing-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-uri-signing-08 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 Mon Jun 20 04:22:05 2016 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 D32EF12D122 for ; Mon, 20 Jun 2016 04:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSHBVE_N5Aks for ; Mon, 20 Jun 2016 04:22:02 -0700 (PDT) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 800FF12D11E for ; Mon, 20 Jun 2016 04:22:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.26,498,1459807200"; d="scan'208";a="10104714" Received: from exc-cashub02.tsn.tno.nl (HELO mail.tno.nl) ([134.221.225.221]) by mailhost1b.tno.nl with ESMTP; 20 Jun 2016 13:21:59 +0200 Received: from EXC-MBX03.tsn.tno.nl ([fe80::e969:1300:fb9f:7e12]) by EXC-CASHUB02.tsn.tno.nl ([fe80::8c02:de2a:3094:171%14]) with mapi id 14.03.0294.000; Mon, 20 Jun 2016 13:21:59 +0200 From: "Brandenburg, R. (Ray) van" To: "cdni@ietf.org" Thread-Topic: New version of draft-ietf-cdni-uri-signing Thread-Index: AQHRyuX1JZevS2dSNky877Jstjuo8A== Date: Mon, 20 Jun 2016 11:21:58 +0000 Message-ID: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.17.0.160611 x-originating-ip: [134.221.225.191] x-esetresult: clean, is OK x-esetid: 37303A29BC344B6F6D7062 Content-Type: text/plain; charset="utf-8" Content-ID: MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: Subject: [CDNi] New version of draft-ietf-cdni-uri-signing X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jun 2016 11:22:04 -0000 SGkgYWxsLA0KDQpJbiBsaW5lIHdpdGggd2hhdCB3ZSBhZ3JlZWQgaW4gQnVlbm9zIEFpcmVzLCBJ 4oCZdmUgdXBkYXRlZCBhIG5ldyB2ZXJzaW9uICgtMDgpIG9mIGRyYWZ0LWlldGYtY2RuaS11cmkt c2lnbmluZy4NCg0KVGhpcyBuZXcgdmVyc2lvbiBtb3N0bHkgaW5jbHVkZXMgb3B0aW1pemF0aW9u cyByZXN1bHRpbmcgZnJvbSBpbXBsZW1lbnRhdGlvbiBleHBlcmllbmNlIHdpdGggdGhlIC0wNiBh bmQgLTA3IHZlcnNpb24gb2YgdGhlIHNwZWMsIGFuZCBpbmNsdWRlOg0KLSBVcGRhdGVkIGVuY3J5 cHRpb24gYW5kIGhhc2ggYWxnb3JpdGhtIGFjcm9ueW1zIHRvIGJlIGluIGxpbmUgd2l0aCBOSVNU IHN0YW5kYXJkcyAoZS5nLiBFQ0RTQSB2cy4gRUMtRFNBLCBldGMuKSwgYXMgbWVudGlvbmVkIGJ5 IEdhbmNobw0KLSBBZGRlZCBvcHRpb24gdG8gY29tbXVuaWNhdGUgVVJJIFNpZ25pbmcgUGFja2Fn ZSB2aWEgVVJMIFBhdGggUGFyYW1ldGVyIGluc3RlYWQgb2YgcXVlcnkgc3RyaW5nLCBhcyBicm91 Z2h0IHVwIG9uIHRoZSBsaXN0IGJ5IFBoaWwNCi0gQWRkZWQgcGVyY2VudC1lbmNvZGluZyBvZiBV UkkgUGF0dGVybiBDb250YWluZXIgKGFzIG1lbnRpb25lZCBieSBHYW5jaG8pDQotIEFkZGVkIHJl Y29tbWVuZGF0aW9ucyByZWdhcmRpbmcgc3RyaW5nIHBhcnNpbmcgcGVyZm9ybWFuY2Ugb2YgdGhl IFVQQywgYXMgc3VnZ2VzdGVkIGJ5IExlaWYsIEdhbmNobyBhbmQgUGhpbC4gDQoNCmh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNkbmktdXJpLXNpZ25pbmctMDgNCg0KRGlm ZjogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY2RuaS11cmktc2lnbmlu Zy0wOA0KDQpCZXN0IHJlZ2FyZHMsDQoNClJheQ0KDQpUaGlzIG1lc3NhZ2UgbWF5IGNvbnRhaW4g aW5mb3JtYXRpb24gdGhhdCBpcyBub3QgaW50ZW5kZWQgZm9yIHlvdS4gSWYgeW91IGFyZSBub3Qg dGhlIGFkZHJlc3NlZSBvciBpZiB0aGlzIG1lc3NhZ2Ugd2FzIHNlbnQgdG8geW91IGJ5IG1pc3Rh a2UsIHlvdSBhcmUgcmVxdWVzdGVkIHRvIGluZm9ybSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhl IG1lc3NhZ2UuIFROTyBhY2NlcHRzIG5vIGxpYWJpbGl0eSBmb3IgdGhlIGNvbnRlbnQgb2YgdGhp cyBlLW1haWwsIGZvciB0aGUgbWFubmVyIGluIHdoaWNoIHlvdSB1c2UgaXQgYW5kIGZvciBkYW1h Z2Ugb2YgYW55IGtpbmQgcmVzdWx0aW5nIGZyb20gdGhlIHJpc2tzIGluaGVyZW50IHRvIHRoZSBl bGVjdHJvbmljIHRyYW5zbWlzc2lvbiBvZiBtZXNzYWdlcy4K From nobody Fri Jun 24 04:27:11 2016 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 457C812B060 for ; Fri, 24 Jun 2016 04:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=W5DuRjCP; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=MfxJJzx1 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 KbuCLGJmhW1F for ; Fri, 24 Jun 2016 04:27:07 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 990CE12B01E for ; Fri, 24 Jun 2016 04:27:07 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 189E520DB0 for ; Fri, 24 Jun 2016 07:27:06 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute4.internal (MEProxy); Fri, 24 Jun 2016 07:27:06 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=FuU2/JMzxD/1h3yvIwKVCen21es=; b=W5DuRj CPcebnrOMrDWyQ/gJD/eTrzyd5mJpxCH8BZnjX09LV0rhHIA6ui3ChLA+KK/KR63 uF9j9GzF74JHDwkrhiSKTWfVnVVMdZ4cCg/SwFsg7uk5kLGmROcERrLbi3kdVOVD DtAZmJ7UG8lWJcHMrR7oHhgTht+8HTnpkLXps= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=FuU2/JMzxD/1h3y vIwKVCen21es=; b=MfxJJzx1FLDSsaQjaoSGnp7stdXQqO/ke7fRjgyKJyMXeBu +fobOEDSMKG2ZL8gkkJB601ER2U3I1GsGBhUyOYppal5WWFCm1lH4HWkco+6mL6s RS+uqarA+eHwJU7D+uR/uxV7BFAbkekbwNHDU/FSUvTtWk35qWGlUrKdclx8= Received: by mailuser.nyi.internal (Postfix, from userid 99) id D8281A887B; Fri, 24 Jun 2016 07:27:05 -0400 (EDT) Message-Id: <1466767625.3349872.647310425.3952172F@webmail.messagingengine.com> X-Sasl-Enc: Ee7c4L+siPVUq2mVN+p+3CDD7OKHeQrVx28cZQ36fZGe 1466767625 From: Alexey Melnikov To: cdni@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_146676762533498726"; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-1f1d081e Date: Fri, 24 Jun 2016 12:27:05 +0100 In-Reply-To: <80669C0F-905B-4E71-B49C-2134C5C9ABDC@gmail.com> References: <80669C0F-905B-4E71-B49C-2134C5C9ABDC@gmail.com> Archived-At: Subject: Re: [CDNi] IETF-96 Berlin, CDNI WG meeting tentatively scheduled on Tuesday 16:20 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 24 Jun 2016 11:27:09 -0000 This is a multi-part message in MIME format. --_----------=_146676762533498726 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The meeting is likely to move to =C2=A0Weds 1400. =20 On Sun, Jun 19, 2016, at 04:35 PM, Francois Le Faucheur wrote: > Folks, > > See preliminary agenda at: > https://datatracker.ietf.org/meeting/96/agenda.html > > > > 16:20-18:20 Tuesday Afternoon session II > > Charlottenburg I[1] art cdni[2] Content Delivery Networks > Interconnection > > See you in Berlin, > > Francois > _________________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni =20 Links: 1. https://tools.ietf.org/agenda/96/venue/?room=3Dcharlottenburg-i 2. https://datatracker.ietf.org/group/cdni/charter/ --_----------=_146676762533498726 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
The meeting is likely to move to  Weds 1400.
 
On Sun, Jun 19, 2016, at 04:35 PM, Francois Le Faucheur wrote:
Folks,
 
See preliminary agenda at:
 
 
 
16:20-18:20
Tuesday Afternoon session II

Charlottenburg I
art
cdni
Content Delivery Networks Interconnection
<= /td>
 
See you in Berlin,
 
Francois
_______________________________________________
CDNi mailing list
 
--_----------=_146676762533498726-- From nobody Fri Jun 24 09:06:35 2016 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 D25A912DCE2; Fri, 24 Jun 2016 09:00:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160624160052.10933.31165.idtracker@ietfa.amsl.com> Date: Fri, 24 Jun 2016 09:00:52 -0700 Archived-At: Cc: cdni@ietf.org Subject: [CDNi] cdni - Requested session has been scheduled for IETF 96 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 24 Jun 2016 16:00:56 -0000 Dear Kevin Ma, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. cdni Session 1 (1:30:00) Wednesday, Afternoon Session I 1400-1530 Room Name: Lincke size: 80 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Content Delivery Networks Interconnection Area Name: Applications and Real-Time Area Session Requester: Kevin Ma Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: alto httpbis lurk tls Second Priority: appsawg dispatch Special Requests: --------------------------------------------------------- From nobody Sat Jun 25 01:39:35 2016 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 9A38D12D669 for ; Sat, 25 Jun 2016 01:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 PmY9glwXfV6J for ; Sat, 25 Jun 2016 01:39:32 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 68BB912D176 for ; Sat, 25 Jun 2016 01:39:32 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id v199so45603254wmv.0 for ; Sat, 25 Jun 2016 01:39:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=y6A7Z8MNIkqj19dZEHOJs6yVbb6SbFUJ8POT0HS7cTs=; b=bCRwVhemPQrJ7ALQ/Q+U5rkrLnSpuwIB1vrD5tNTfxL3Mz3h5IbU34NSjIpxMy4dz+ 6klYT58yWGlUZtc+0I8DP3mnj9mIJtpop+dwwsSxm61CTD0G84NAtcfjcnzxSMkF9Lf6 S00ELL6TwxaMOl7qEcdWm14my/lgv9127fI/jwNLz+cQepCQl/dPlD0bTm/ADY8sYVZD p9G9wHgFwUbGThNY/MKYPZ7ujXsBeRSefjMi6QF3a9X8m72F1VBu/Xc/XxwQd/LDThBN k4rMAH9fWYTem5kf2uFXLx6YqiUUOVdr1lW5fc92sqs4QAUIten67g1Cz2a34GeNbHtX 8cDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=y6A7Z8MNIkqj19dZEHOJs6yVbb6SbFUJ8POT0HS7cTs=; b=YcBlosqXpH7M8ckuf6FiOppioT9JVizcAolfYba4wi2wgqYSjtarr8SxjChRUj0hxN DXjlqn6QPbigpiTXENiJPUOVTwAq4CuulLz105qacfOcpy4hloSMqgYn7F4shN9WFEFU d9jmdhxegj2858sgOUmpuDm4sryCtiugLxG8eOTTqJMXXhPZULlkLxbEeqY8aeevt2T6 fhA7pcjmdJUDA0Bm5eNbPI6cL/I9FYziaF+isj8pH8aCEsSALdt6gGnZUtBx+YPyvS5K 6WHgZICWE1TCCR6u2YHJo7sbaNeDUk0clGQHFoNUVa58cH9ebGrAbnT/RU6EzqWsT9FT DkeQ== X-Gm-Message-State: ALyK8tLyiGLrPuxprTq/3mfokBP1FoAGrF8c1OmwBDQlfHAtEhFgX6yoanxhxZ2Zy5XgcA== X-Received: by 10.28.31.140 with SMTP id f134mr1813689wmf.69.1466843970923; Sat, 25 Jun 2016 01:39:30 -0700 (PDT) Received: from [192.168.1.21] (125.216.113.78.rev.sfr.net. [78.113.216.125]) by smtp.gmail.com with ESMTPSA id vu10sm2957730wjb.27.2016.06.25.01.39.29 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 25 Jun 2016 01:39:30 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_62A7FC55-4B84-406C-8DCF-B02DADFFD996" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Francois Le Faucheur In-Reply-To: <1730EA59-47AA-48AB-B3CC-DEC0035B77C7@fastmail.fm> Date: Sat, 25 Jun 2016 10:39:28 +0200 Message-Id: <69DEF69D-A682-4FE4-B6D3-330D4776AFE2@gmail.com> References: <80669C0F-905B-4E71-B49C-2134C5C9ABDC@gmail.com> <1730EA59-47AA-48AB-B3CC-DEC0035B77C7@fastmail.fm> To: "" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [CDNi] IETF-96 Berlin, CDNI WG meeting re-scheduled to Wednesday 14:00 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2016 08:39:34 -0000 --Apple-Mail=_62A7FC55-4B84-406C-8DCF-B02DADFFD996 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello everyone, Please note that the CDNI WG session in Berlin has been re-scheduled to = Wed 14:00. This is final: 14:00-15:30 Wednesday Afternoon session I Lincke art = cdni Content Delivery = Networks Interconnection Final agenda at: https://datatracker.ietf.org/meeting/96/agenda.html = Cheers Francois >=20 > On 19 Jun 2016, at 16:35, Francois Le Faucheur > wrote: >=20 >> Folks, >>=20 >> See preliminary agenda at: >> https://datatracker.ietf.org/meeting/96/agenda.html = >>=20 >>=20 >>=20 >> 16:20-18:20 Tuesday Afternoon session II >> Charlottenburg I = = art cdni Content = Delivery Networks Interconnection >>=20 >> See you in Berlin, >>=20 >> Francois >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni = --Apple-Mail=_62A7FC55-4B84-406C-8DCF-B02DADFFD996 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hello everyone,

Please= note that the CDNI WG session in Berlin has been re-scheduled to Wed = 14:00.
This is final:

14:00-15:30Wednesday Afternoon session ILinckeartcdniContent Delivery Networks = Interconnection

Final agenda at:


Cheers

Francois



On 19 = Jun 2016, at 16:35, Francois Le Faucheur <flefauch@gmail.com> = wrote:

Folks,

See preliminary agenda at:
https://datatracker.ietf.org/meeting/96/agenda.html



16:20-18:20Tuesday Afternoon session II
Charlottenburg = IartcdniContent Delivery = Networks Interconnection

See you in Berlin,

Francois
_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni

= --Apple-Mail=_62A7FC55-4B84-406C-8DCF-B02DADFFD996-- From nobody Tue Jun 28 23:58:02 2016 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 5FFAC12D586; Tue, 28 Jun 2016 23:57:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160629065756.22447.95320.idtracker@ietfa.amsl.com> Date: Tue, 28 Jun 2016 23:57:56 -0700 Archived-At: Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-uri-signing-09.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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 Jun 2016 06:57:56 -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 of the IETF. Title : URI Signing for CDN Interconnection (CDNI) Authors : Kent Leung Francois Le Faucheur Ray van Brandenburg Bill Downey Michel Fisher Filename : draft-ietf-cdni-uri-signing-09.txt Pages : 47 Date : 2016-06-28 Abstract: This document describes how the concept of URI signing supports the content access control requirements of CDNI and proposes a URI signing scheme. The proposed URI signing method specifies the information needed to be included in the URI and the algorithm used to authorize and to validate access requests for the content referenced by the URI. 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's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-cdni-uri-signing-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-uri-signing-09 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 Jun 29 06:43:29 2016 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 5590512D767 for ; Wed, 29 Jun 2016 06:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PT5Xx81KPrvm for ; Wed, 29 Jun 2016 06:43:26 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60C9812D169 for ; Wed, 29 Jun 2016 06:43:26 -0700 (PDT) X-AuditID: c618062d-f79886d000002334-6b-5773c6346057 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id C6.D1.09012.436C3775; Wed, 29 Jun 2016 14:59:33 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0294.000; Wed, 29 Jun 2016 09:43:22 -0400 From: Kevin Ma J To: "cdni@ietf.org" Thread-Topic: Working Group Last Call on draft-ietf-cdni-uri-signing Thread-Index: AdHSDAIj8Q+3AOh3Q/WhloflAutMVQ== Date: Wed, 29 Jun 2016 13:43:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyuXSPt67pseJwg7b9bBZPZ/9hdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxrN/cxkL9jBXtC+9ydjAeIupi5GTQ0LARGLd/MeMELaYxIV7 69m6GLk4hASOMkqsW/AMylnOKLHs9Eo2kCo2AS2Jx1//AnVzcIgIKEv8POQIYgoL2EvsnpcM UiEi4CJx9W8jO4StJ3H/534wm0VAVWLK0dmsIOW8Ar4SfSfCQcKMQGu/n1oDdg6zgLjErSfz oU4TkFiy5zwzhC0q8fLxP1YIW0ni4+/57BD1OhILdn9ig7C1JZYtfA1WzysgKHFy5hOWCYzC s5CMnYWkZRaSlllIWhYwsqxi5CgtLsjJTTcy2MQIDOJjEmy6OxjvT/c8xCjAwajEw6uwuyhc iDWxrLgy9xCjBAezkgjv5TPF4UK8KYmVValF+fFFpTmpxYcYpTlYlMR5xR4phgsJpCeWpGan phakFsFkmTg4pRoYrfoMH9QeFc5OPvBK+PafuRsYHploK6ovKI3Lbp7wX/X5EVbOS1l2S2aZ zAy/GZrksPb0xmNRO7P2xV9fuexE0M3dLa8FrVhdPl3meHpU4beK9kPVtquZCXoGp3T0jrXU F3yPLK5mtlsmvejwvgeFgddNF/PY37XXrFq2sL5x9RRnkwhmwayFSizFGYmGWsxFxYkAfIVv p14CAAA= Archived-At: Subject: [CDNi] Working Group Last Call on draft-ietf-cdni-uri-signing X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 29 Jun 2016 13:43:28 -0000 Hi All, As per the discussion in BA, we have received the updated URI Signing dra= ft and would like to move it to WGLC. (Leif and Phil, you're up!) Today will begin the two-week WGLC on: https://tools.ietf.org/html/draft-= ietf-cdni-uri-signing-09 Please send any comments, questions, concerns to the CDNI mailing list: c= dni@ietf.org The WGLC will end on Wednesday July 13, 2016. thanx! -- Kevin and Francois