From kleung@cisco.com Wed Oct 2 14:40:54 2013 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 3F48521F9EC8 for ; Wed, 2 Oct 2013 14:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WV13Cpwnx6v8 for ; Wed, 2 Oct 2013 14:40:34 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id DF51A21F9A70 for ; Wed, 2 Oct 2013 14:40:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9257; q=dns/txt; s=iport; t=1380750034; x=1381959634; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=uY3gjGdBby7pEnKvWukHr/siGU7rxMxk9FdPrusNZiA=; b=MBJAHZwhBpuTg5Tb9Z2IC/OnoVAJR0QoT7XijldTBLWOMa1Hdb0/wFnN c/BwBqZuKwAGBxWPi0zuXgaldNRGVDwwWS3NVxEF2IKcrr3QIcxl6nOE+ rTVPypdNUgzO5wCx5Rxo6JSRO8nl+DMekRn0iQLnH+nDScpZs6EumnWUw 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkFAAiSTFKtJV2d/2dsb2JhbABPCoMHOFLBN4EaFnSCJQEBAQQBAQE3LQcLDAQCAQgRBAEBAQoUCQcnCxQJCAIEAQ0FCBOHawy9aASODgULgQIxBwaDGYEEA6oAgV+BRYFpQQ X-IronPort-AV: E=Sophos;i="4.90,1021,1371081600"; d="scan'208";a="267352663" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 02 Oct 2013 21:40:33 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r92LeWPq032575 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Oct 2013 21:40:32 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.219]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Wed, 2 Oct 2013 16:40:32 -0500 From: "Kent Leung (kleung)" To: Spencer Dawkins , "Francois Le Faucheur (flefauch)" Thread-Topic: [CDNi] Publication has been requested for draft-ietf-cdni-requirements-10 Thread-Index: AQHOuIWHCsUH0xJlZ0qbcb8cd9Wy2Jnh1UsA Date: Wed, 2 Oct 2013 21:40:31 +0000 Message-ID: References: <523DA6BB.1010409@gmail.com> <52407F8A.4020606@gmail.com> In-Reply-To: <52407F8A.4020606@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.101.31] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Martin Stiemerling , "" , Daryl Malas Subject: Re: [CDNi] Publication has been requested for draft-ietf-cdni-requirements-10 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 02 Oct 2013 21:40:54 -0000 Hi Spencer. Thanks for your thorough review. Also, I appreciate the discuss= ion on the comments. I've tried to capture all the topics so please inform = me if anything is incorrect or missing. 1. Comment: "... need any additional requirements specifically for manageme= nt ..."=20 This hasn't come up in the past, AFAIK. I've assumed that management is out= of scope from requirements' perspective. Obviously, anyone can write a dra= ft for management such as MIBs, etc. So "great question, but not now" :) 2. Comment: "... of two different line types with the same description odd = in Figure 1..."=20 I agree. Having different line types in the figure is more readable, so wil= l change to "**** and .... interfaces outside the scope of CDNI" 3. Comment: "GEN-3 ..." Requirement is updated: GEN-3 [HIGH] The CDNI solution shall not require a change, or an upgrade, to the Content Service Provider delivering content thro= ugh a single CDN, to benefit from content delivery through interconn= ected CDNs. 4. Comment: "GEN-10..." I've changed the requirement from: GEN-10 [MED] The CDNI solution should support an arbitrary topology of interconnected CDNs (i.e. the CDN topology cannot be restricted to a tree, a loop-free topology, etc.). To: GEN-10 [MED] The CDNI solution should support an arbitrary topology of interconnected CDNs (i.e. the topology of interconnected CDNs= cannot be restricted to a tree, ring, star, etc.). 5. Comment: "GEN-11..." No change to requirement. GEN-11 [HIGH] The CDNI solution shall prevent looping of any CDNI information exchange. 6. Comment: "CI-4..." Requirement is updated. CI-4 [HIGH] The CDNI Control interface shall allow the Downstream CDN to report on the completion of these actions (by itself, and including downstream cascaded CDNs, in a manner appropriate for the action (e.g. synchronously or asynchronously). The confirmation receipt should include a success or failure indication. The failure indication along with the reason are included if the Downstream CDN cannot delete the content in its storage. 7. Comment: "CI-11..." Requirement is updated. CI-11 [LOW] The CDNI Control interface may allow bootstrapping of the Content Acquisition interface. This could, for example, include exchange and negotiation of the Content Acquisition methods to be used across the CDNs (e.g. HTTP, HTTPS, FTP, ATIS C2). Informative reference is added for: [ATIS-0800042] ATIS IPTV Content on Demand Service, December 8, 2010 8. Comment: "RI-1 and RI-2 ... efficient request-routing" No change to requirements. 9. Comment: "RI-5..." Requirement is updated. RI-5 [MED] In case of detection of a request redirection loop, the CDNI R= equest Routing Redirection Interface's loop prevention mechanism should= allow redirection of the request on an alternate CDN path (as opposed to t= he request not being redirected at all). 10. Comment: "RI-6..." Typo fixed. RI-6 [MED] The CDNI Request Routing Redirection interface should support a mechanism allowing enforcement of a limit on the number of successive CDN redirections for a given request. 11. Comment: "MI-19..." Requirement is updated. MI-19 [MED] The CDNI Metadata interface should support an optional mechanism allowing the Upstream CDN to indicate to the Downstream CDN which CDNI Log fields are to be provided for all, for specific sets of, or for specific content items delivered using HTTP. A CDNI implementation that does not support this optional CDNI Metadata Distribution Interface mechanism shall ignore this log format indication and generate CDNI logging format for HTTP Adaptive Streaming using the default set of CDNI Logging fields. (Note: This function may be = part of=20 the CDNI Metadata interface or the CDNI Control interface.) 12. Comment: "SEC-1... protect privacy" I'm not quite sure how to capture privacy protection in the general securit= y requirements section. It seems to be a broad statement in the context of = IP and HTTP communications. So I'm open to suggested text. :) The CDNI inte= rface that seems most relevant is the CDNI Logging interface. I've tried to= capture this requirement below. Add a new requirement: LI-18 [MED] The CDNI Logging interface should provide privacy protection by not disclosing information that can be used to identify the us= er (e.g. method that anonymize the IP address carried in the logging = field ). If these changes are agreeable, let me know and I'll publish the next versi= on of the draft. Kent -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Spe= ncer Dawkins Sent: Monday, September 23, 2013 10:51 AM To: Francois Le Faucheur (flefauch) Cc: Martin Stiemerling; ; Daryl Malas Subject: Re: [CDNi] Publication has been requested for draft-ietf-cdni-requ= irements-10 On 9/23/2013 3:29 AM, Francois Le Faucheur (flefauch) wrote: > >>>>>> In the same section, >>>>>> >>>>>> RI-5 [MED] In case of detection of a request redirection loop,= the >>>>>> CDNI Request Routing Redirection interface's loop prevent= ion >>>>>> mechanism should allow routing of the request by avoiding= the >>>>>> loop (as opposed to the request loop being simply interru= pted >>>>>> without routing the request). >>>>>> >>>>>> I'm not understanding what "by avoiding the loop" means. I can=20 >>>>>> guess, but I'm guessing. >>>>> How about: >>>>> " >>>>> RI-5 [MED] In case of detection of a potential request redirect= ion >>>>> loop, the >>>>> CDNI Request Routing Redirection interface's loop preventi= on >>>>> mechanism should prevent or interrupt the loop and=20 >>>>> allow routing of the request (as opposed to the request loop being=20 >>>>> simply interrupted >>>>> without routing the request). >>>>> " >>>> I'm not clearly explaining what's not clear to me. Let me guess again = ... >>>> >>>> I'm pretty sure I'm choking because I'm reading "allow routing of=20 >>>> the request" as "you sent me a request that loops when I route it,=20 >>>> so I either prevent or interrupt the loop *and continue to route=20 >>>> the request*, like I suddenly know how to route the request that=20 >>>> was looping, without looping". >>>> >>>> Is RI-5 saying that if you send a request that loops, you get a=20 >>>> response that tells you that the request looped, as opposed to=20 >>>> having the loop prevention mechanism drop the request to protect=20 >>>> the CDN, but you get nothing back? Or am I missing this completely? >>> [DM] I think I understand your concern; and, after reviewing the=20 >>> requirement again, I agree with you. If the CDN knew how to avoid=20 >>> the loop in the first place, why would it send a request purposely=20 >>> in a direction that causes a loop. Perhaps the requirement should=20 >>> state something more like: >>> >>> [MED] In case of detection of a request redirection loop, the >>> CDNI Request Routing Redirection interface's loop preventio= n >>> mechanism should notify the requesting CDNs of the loop,=20 >>> so the requesting CDN could attempt a difference dCDN. >> After looking at the original requirement again, what I was struggling w= ith is that the text sounds like the interface is avoiding the loop that th= e request caused, but the same interface is still routing the same request = with no changes. >> >> Your suggestion would work for me (if it works for others, of course), b= ecause it doesn't use the same word for what happens before and after a req= uest redirection loops. > The text suggested by Daryl could work for me too. Although I would prefe= r: > " > [MED] In case of detection of a request redirection loop, the > CDNI Request Routing Redirection interface's loop prevention > mechanism should allow the uCDN to attempt a different dCDN. > " > > This is because the loop detection might actually be done by the uCDN its= elf based on information received in the RI request, so the uCDN never real= ly receive a "notification" of loop (ie the uCDN may look at the informatio= n in the received RI request, and realises that the "initially selected dCD= N" would result in a loop - because it already appears in the received RI r= equest). This text makes sense to me, and would also work for me if it works for oth= ers. I'm not sure how it's equivalent to the original RI-5, but since I said I c= ouldn't understand the original RI-5, that's probably a good thing :-) Spencer _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From spencerdawkins.ietf@gmail.com Wed Oct 2 20:51:40 2013 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 652C721F8E21 for ; Wed, 2 Oct 2013 20:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMTeZE+1hXXK for ; Wed, 2 Oct 2013 20:51:30 -0700 (PDT) Received: from mail-pb0-x231.google.com (mail-pb0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 7199C21F9FE5 for ; Wed, 2 Oct 2013 20:51:17 -0700 (PDT) Received: by mail-pb0-f49.google.com with SMTP id xb4so1836678pbc.36 for ; Wed, 02 Oct 2013 20:51:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=p7fHgd0iUfPfqL8rDHnNJ2GBXEyCyIKGZKA1Ed2AIjg=; b=R+viFQFLmpFhkJEhWsEvpbMR+/ZL0Uri+dWCkGFS3MxjabhJtm71m8q716nXv8RQu8 SAfqCPJ/xLKbESpDyMI2ykabcB9XJm/lYxEQY//MqN5hpYF54fdqCEal9hHEggYU45yU 3dXRgejc9N5PacDI8G/c2FzNbaO1hyhh+lVZiGY2CFwNOcFn1MQdwi2eZJ5KIJiMpLft UiESzLh4AUjGKf+vwyp6MZTE78IS/6sJJSR04cViDceQiPinPKK/Zo4ETpFIhnUDMG+M q6+yN/jFsI66Win2XureaSHNLyxTLAfXR5jFXv9Jm/DuDyTMA3+wKCrzF1rmrIpeKdQo YfOQ== X-Received: by 10.67.21.226 with SMTP id hn2mr6881202pad.69.1380772277294; Wed, 02 Oct 2013 20:51:17 -0700 (PDT) Received: from [192.168.0.30] (99-200-157-60.pools.spcsdns.net. [99.200.157.60]) by mx.google.com with ESMTPSA id go4sm5197536pbb.15.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Oct 2013 20:51:16 -0700 (PDT) Message-ID: <524CE9AC.9030000@gmail.com> Date: Wed, 02 Oct 2013 22:51:08 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Kent Leung (kleung)" References: <523DA6BB.1010409@gmail.com> <52407F8A.4020606@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Martin Stiemerling , "" , Daryl Malas Subject: Re: [CDNi] Publication has been requested for draft-ietf-cdni-requirements-10 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 03 Oct 2013 03:51:40 -0000 On 10/2/2013 4:40 PM, Kent Leung (kleung) wrote: > Hi Spencer. Thanks for your thorough review. Also, I appreciate the discussion on the comments. I've tried to capture all the topics so please inform me if anything is incorrect or missing. Just to cut to the chase, "yes, please submit an updated draft" :-) I have a couple of things I'd like for you to look at, but you're ready for me to forward the draft after you do that. > 1. Comment: "... need any additional requirements specifically for management ..." > > This hasn't come up in the past, AFAIK. I've assumed that management is out of scope from requirements' perspective. Obviously, anyone can write a draft for management such as MIBs, etc. So "great question, but not now" :) That's fair, especially if the answer is that CDNI doesn't require anything special that we don't already know how to manage. > 2. Comment: "... of two different line types with the same description odd in Figure 1..." > > I agree. Having different line types in the figure is more readable, so will change to "**** and .... interfaces outside the scope of CDNI" Thanks! > 3. Comment: "GEN-3 ..." > > Requirement is updated: > > GEN-3 [HIGH] The CDNI solution shall not require a change, or an > upgrade, to the Content Service Provider delivering content through > a single CDN, to benefit from content delivery through interconnected CDNs. Thanks! > 4. Comment: "GEN-10..." > > I've changed the requirement from: > > GEN-10 [MED] The CDNI solution should support an arbitrary topology > of interconnected CDNs (i.e. the CDN topology cannot be > restricted to a tree, a loop-free topology, etc.). > > To: > > GEN-10 [MED] The CDNI solution should support an arbitrary topology > of interconnected CDNs (i.e. the topology of interconnected CDNs cannot be > restricted to a tree, ring, star, etc.). Thanks! > 5. Comment: "GEN-11..." > > No change to requirement. > > GEN-11 [HIGH] The CDNI solution shall prevent looping of any CDNI > information exchange. That's fine, and I want to emphasize that the discussion on this requirement was helpful to me. I'm still learning how to review requirement drafts :-) > 6. Comment: "CI-4..." > > Requirement is updated. > > CI-4 [HIGH] The CDNI Control interface shall allow the Downstream > CDN to report on the completion of these actions (by itself, > and including downstream cascaded CDNs, in a manner > appropriate for the action (e.g. synchronously or > asynchronously). The confirmation receipt should include a > success or failure indication. The failure indication along > with the reason are included if the Downstream CDN cannot delete > the content in its storage. This is a little rough. I'm counting two left parens and one right paren, and I think it would be The failure indication and the reason are included if ... but with minor fixes, this will be fine. > 7. Comment: "CI-11..." > > Requirement is updated. > > CI-11 [LOW] The CDNI Control interface may allow bootstrapping of > the Content Acquisition interface. This could, for example, > include exchange and negotiation of the Content Acquisition > methods to be used across the CDNs (e.g. HTTP, HTTPS, FTP, > ATIS C2). > > Informative reference is added for: > > [ATIS-0800042] ATIS IPTV Content on Demand Service, December 8, 2010 So, this is the reference for ATIS C2? That linkage wasn't clear to me. > 8. Comment: "RI-1 and RI-2 ... efficient request-routing" > > No change to requirements. That's fine, and again, the discussion on this requirement was helpful to me. > 9. Comment: "RI-5..." > > Requirement is updated. > > RI-5 [MED] In case of detection of a request redirection loop, the CDNI Request Routing Redirection Interface's loop prevention mechanism should allow redirection of the request on an alternate CDN path (as opposed to the request not being redirected at all). This is OK, I think. Early in the discussion, the distinction I was making was "as opposed to the request being dropped, so you get an error indication instead of a timeout". If that's clearly the same as "not being redirected at all", that's fine, and it could be clearly the same ;-) > 10. Comment: "RI-6..." > > Typo fixed. > > RI-6 [MED] The CDNI Request Routing Redirection interface should > support a mechanism allowing enforcement of a limit on the > number of successive CDN redirections for a given request. Thank you. > 11. Comment: "MI-19..." > > Requirement is updated. > > MI-19 [MED] The CDNI Metadata interface should support an optional > mechanism allowing the Upstream CDN to indicate to the > Downstream CDN which CDNI Log fields are to be provided for > all, for specific sets of, or for specific content items > delivered using HTTP. A CDNI implementation that does not > support this optional CDNI Metadata Distribution Interface > mechanism shall ignore this log format indication and generate > CDNI logging format for HTTP Adaptive Streaming using the > default set of CDNI Logging fields. (Note: This function may be part of > the CDNI Metadata interface or the CDNI Control interface.) I THINK which CDNI Log fields are to be provided for all, for specific sets of, or for specific content items delivered using HTTP is correct, but I wonder if which CDNI Log fields are to be provided for all content items, for specific sets of content items, or for specific content items delivered using HTTP would be easier for readers. Your call. > 12. Comment: "SEC-1... protect privacy" > > I'm not quite sure how to capture privacy protection in the general security requirements section. It seems to be a broad statement in the context of IP and HTTP communications. So I'm open to suggested text. :) The CDNI interface that seems most relevant is the CDNI Logging interface. I've tried to capture this requirement below. > > Add a new requirement: > > LI-18 [MED] The CDNI Logging interface should provide privacy protection > by not disclosing information that can be used to identify the user > (e.g. method that anonymize the IP address carried in the logging field ). The IAB plenary in Vancouver will include discussion of pervasive passive monitoring, which is your signal that we are still figuring privacy out. For that reason alone, I don't think this is the time to work really hard figuring out requirements for privacy. I suspect your new requirement is appropriate. We may get more guidance as we go through the publication cycle. Thank you for working on this. From spencerdawkins.ietf@gmail.com Wed Oct 2 20:53:29 2013 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 9508121F9FBC for ; Wed, 2 Oct 2013 20:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMk-EY-9bp5S for ; Wed, 2 Oct 2013 20:53:23 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 09B5921F8E21 for ; Wed, 2 Oct 2013 20:53:19 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id kp14so1991063pab.10 for ; Wed, 02 Oct 2013 20:53:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=HnqabEz4YBu29uUvYfZ0t3qOOdYxG2b/scYCCiHWpRA=; b=Z+dmUR+hScOetuRV45/pb/c2uhweJ2MT2BqDg0VqDPt1pnEzjeIaYbXPYUepcnG/c3 bOVsBLLUbZJIZQmXzOlI1RYO0PfugkTvFinPkrwIOyP5qcD6FAAT76wSt2pvCefd00i4 jgtchM79+VdzGcLEmctX/tY6VUO1jlJ2lh6ylUn4T+0+s4tL+LSd+632CCXFz4Za0rC6 L61wb1nVLSzoupyOD1Az3gGcwo8e8uiKf0fAS/SVaZ6jjlmoQLyo6j1edeP3OXNLVoBn uYPKsFOiqVM7hH4+TD9FlYZfn6GMyDvgF13JrnRIsV1spKU+P624w70mchgmGeWf9V1h NIWA== X-Received: by 10.68.197.104 with SMTP id it8mr6141643pbc.17.1380772399721; Wed, 02 Oct 2013 20:53:19 -0700 (PDT) Received: from [192.168.0.30] (99-200-157-60.pools.spcsdns.net. [99.200.157.60]) by mx.google.com with ESMTPSA id q4sm5214558pba.12.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Oct 2013 20:53:18 -0700 (PDT) Message-ID: <524CEA27.2030001@gmail.com> Date: Wed, 02 Oct 2013 22:53:11 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Kent Leung (kleung)" References: <523DA6BB.1010409@gmail.com> <52407F8A.4020606@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Martin Stiemerling , "" , Daryl Malas Subject: Re: [CDNi] Publication has been requested for draft-ietf-cdni-requirements-10 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 03 Oct 2013 03:53:29 -0000 On 10/2/2013 4:40 PM, Kent Leung (kleung) wrote: > Hi Spencer. Thanks for your thorough review. Also, I appreciate the discussion on the comments. I've tried to capture all the topics so please inform me if anything is incorrect or missing. Sorry for sending two notes back to back. It's appropriate for me to say that this review cycle was really easy for me to follow. Thank you for that, too! Spencer From flefauch@cisco.com Thu Oct 3 13:28:56 2013 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 3A1CE21E80E7 for ; Thu, 3 Oct 2013 13:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXg2oEiFnl-S for ; Thu, 3 Oct 2013 13:28:45 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id E8F5021F9B6A for ; Thu, 3 Oct 2013 13:12:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5791; q=dns/txt; s=iport; t=1380831176; x=1382040776; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=5I75kHhz2SwFp7skPpdVLTw+5tSDbJzY7oK7n4h2Y64=; b=evNXdKNUTo7gJmqbflk++WHii+FiKdNSvRrTmHVf3x28en/tTpIn3G5L iJI/THW2zl7G5JFOyYibXPAcsu/AlCeeffSAATDuP5vHfw7PZgfogxXac vKsUMW4vhgm2R9Hdoaf570F42ZTt3oMOrklZqD/uEkWv0MrqUNzr5yp3H U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAJvPTVKtJXG8/2dsb2JhbABPCoMHOEYMwUeBHBZ0giUBAQEDAQEBATctBwsFBwQCAQgRBAEBAQoUCQcnCxQJCAIEDgUIh3gGDLxOBI4OgRACMQcGgxmBBAOqAIMkgio X-IronPort-AV: E=Sophos;i="4.90,1028,1371081600"; d="scan'208";a="264811312" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 03 Oct 2013 20:12:43 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r93KCh4O006169 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Oct 2013 20:12:43 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.33]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Thu, 3 Oct 2013 15:12:43 -0500 From: "Francois Le Faucheur (flefauch)" To: "Kent Leung (kleung)" Thread-Topic: [CDNi] Publication has been requested for draft-ietf-cdni-requirements-10 Thread-Index: AQHOwHTqBKC6uef8TkWsOD40D66lBA== Date: Thu, 3 Oct 2013 20:12:42 +0000 Message-ID: References: <523DA6BB.1010409@gmail.com> <52407F8A.4020606@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.107.127] Content-Type: text/plain; charset="us-ascii" Content-ID: <95DF01E956BBA644B45BB7A0B513CEC3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Martin Stiemerling , "" , Daryl Malas Subject: Re: [CDNi] Publication has been requested for draft-ietf-cdni-requirements-10 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 03 Oct 2013 20:28:56 -0000 Hi Kent, One small thing: > 12. Comment: "SEC-1... protect privacy" >=20 > I'm not quite sure how to capture privacy protection in the general secur= ity requirements section. It seems to be a broad statement in the context o= f IP and HTTP communications. So I'm open to suggested text. :) The CDNI in= terface that seems most relevant is the CDNI Logging interface. I've tried = to capture this requirement below. >=20 > Add a new requirement: >=20 > LI-18 [MED] The CDNI Logging interface should provide privacy protection > by not disclosing information that can be used to identify the u= ser > (e.g. method that anonymize the IP address carried in the logging= field ). I suggest you tweak the text to make it clear that it will be up to a given= deployment to decide whether the privacy protection mechanism is actually = used or not. In other word, the pricavy protection mechanism woudl be "Opti= onal to Use". The text above might be understood as saying that the CDNI Logging interfac= e needs to _never_ disclose information that can be used to identify the us= er. I don't think we want to say that. We just want the interface to allow = to not disclose that information when and where that is required. Thanks Francois >=20 >=20 > If these changes are agreeable, let me know and I'll publish the next ver= sion of the draft. >=20 > Kent >=20 > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of S= pencer Dawkins > Sent: Monday, September 23, 2013 10:51 AM > To: Francois Le Faucheur (flefauch) > Cc: Martin Stiemerling; ; Daryl Malas > Subject: Re: [CDNi] Publication has been requested for draft-ietf-cdni-re= quirements-10 >=20 > On 9/23/2013 3:29 AM, Francois Le Faucheur (flefauch) wrote: >>=20 >>>>>>> In the same section, >>>>>>>=20 >>>>>>> RI-5 [MED] In case of detection of a request redirection loop,= the >>>>>>> CDNI Request Routing Redirection interface's loop prevent= ion >>>>>>> mechanism should allow routing of the request by avoiding= the >>>>>>> loop (as opposed to the request loop being simply interru= pted >>>>>>> without routing the request). >>>>>>>=20 >>>>>>> I'm not understanding what "by avoiding the loop" means. I can=20 >>>>>>> guess, but I'm guessing. >>>>>> How about: >>>>>> " >>>>>> RI-5 [MED] In case of detection of a potential request redirect= ion >>>>>> loop, the >>>>>> CDNI Request Routing Redirection interface's loop preventi= on >>>>>> mechanism should prevent or interrupt the loop and=20 >>>>>> allow routing of the request (as opposed to the request loop being=20 >>>>>> simply interrupted >>>>>> without routing the request). >>>>>> " >>>>> I'm not clearly explaining what's not clear to me. Let me guess again= ... >>>>>=20 >>>>> I'm pretty sure I'm choking because I'm reading "allow routing of=20 >>>>> the request" as "you sent me a request that loops when I route it,=20 >>>>> so I either prevent or interrupt the loop *and continue to route=20 >>>>> the request*, like I suddenly know how to route the request that=20 >>>>> was looping, without looping". >>>>>=20 >>>>> Is RI-5 saying that if you send a request that loops, you get a=20 >>>>> response that tells you that the request looped, as opposed to=20 >>>>> having the loop prevention mechanism drop the request to protect=20 >>>>> the CDN, but you get nothing back? Or am I missing this completely? >>>> [DM] I think I understand your concern; and, after reviewing the=20 >>>> requirement again, I agree with you. If the CDN knew how to avoid=20 >>>> the loop in the first place, why would it send a request purposely=20 >>>> in a direction that causes a loop. Perhaps the requirement should=20 >>>> state something more like: >>>>=20 >>>> [MED] In case of detection of a request redirection loop, the >>>> CDNI Request Routing Redirection interface's loop preventio= n >>>> mechanism should notify the requesting CDNs of the loop,=20 >>>> so the requesting CDN could attempt a difference dCDN. >>> After looking at the original requirement again, what I was struggling = with is that the text sounds like the interface is avoiding the loop that t= he request caused, but the same interface is still routing the same request= with no changes. >>>=20 >>> Your suggestion would work for me (if it works for others, of course), = because it doesn't use the same word for what happens before and after a re= quest redirection loops. >> The text suggested by Daryl could work for me too. Although I would pref= er: >> " >> [MED] In case of detection of a request redirection loop, the >> CDNI Request Routing Redirection interface's loop prevention >> mechanism should allow the uCDN to attempt a different dCDN. >> " >>=20 >> This is because the loop detection might actually be done by the uCDN it= self based on information received in the RI request, so the uCDN never rea= lly receive a "notification" of loop (ie the uCDN may look at the informati= on in the received RI request, and realises that the "initially selected dC= DN" would result in a loop - because it already appears in the received RI = request). >=20 > This text makes sense to me, and would also work for me if it works for o= thers. >=20 > I'm not sure how it's equivalent to the original RI-5, but since I said I= couldn't understand the original RI-5, that's probably a good thing :-) >=20 > Spencer > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From spencerdawkins.ietf@gmail.com Thu Oct 3 17:29:49 2013 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 13A7A21F8F4A for ; Thu, 3 Oct 2013 17:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5p9WEFpm4nf for ; Thu, 3 Oct 2013 17:29:41 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 45EE421F90A7 for ; Thu, 3 Oct 2013 17:29:30 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id u16so7280949iet.5 for ; Thu, 03 Oct 2013 17:29:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ehkI7d8II2JIHqmedt2Lq288RpFOTOWDq8S7oYBooV0=; b=Q/x7ttpi2T2SRP+a+lFKz83IKudoma4Y9uNdpo5TcOlTy1i73kpVnqhhHqpByH82Sj JakZc95T2viaaA4BymdXDv2bHtvb9n2PkJ1IKvwPd59hswDA1hwnL4ehRZJtzP9xkcQg +8TnCCRHw73rdc77jckY/Q6WLAxT+1fasg8XT7wv1cFTAzeUeBvEDYScVpgN2kIAVnMI UoR7a9VXUcKBtcKSQoI2JlemDdQV3Ai4GtDrO4sThR4rODyQcG+tE5bSJyCkLNTr0ydi FNKqz9B19tAE6M0ZyHo8Rr4T9229Vp8CwVk+2VfYpiMPFqPwziR9yYlNNp09DiWryavp 0LoA== X-Received: by 10.50.130.106 with SMTP id od10mr4356996igb.1.1380846565667; Thu, 03 Oct 2013 17:29:25 -0700 (PDT) Received: from [192.168.0.30] (173-139-211-97.pools.spcsdns.net. [173.139.211.97]) by mx.google.com with ESMTPSA id p5sm3486938igj.10.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Oct 2013 17:29:23 -0700 (PDT) Message-ID: <524E0BDB.2030508@gmail.com> Date: Thu, 03 Oct 2013 19:29:15 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Francois Le Faucheur (flefauch)" References: <523DA6BB.1010409@gmail.com> <52407F8A.4020606@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Martin Stiemerling , "" , Daryl Malas Subject: Re: [CDNi] Publication has been requested for draft-ietf-cdni-requirements-10 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 04 Oct 2013 00:29:49 -0000 On 10/3/2013 3:12 PM, Francois Le Faucheur (flefauch) wrote: > Hi Kent, > > One small thing: > >> 12. Comment: "SEC-1... protect privacy" >> >> I'm not quite sure how to capture privacy protection in the general security requirements section. It seems to be a broad statement in the context of IP and HTTP communications. So I'm open to suggested text. :) The CDNI interface that seems most relevant is the CDNI Logging interface. I've tried to capture this requirement below. >> >> Add a new requirement: >> >> LI-18 [MED] The CDNI Logging interface should provide privacy protection >> by not disclosing information that can be used to identify the user >> (e.g. method that anonymize the IP address carried in the logging field ). > I suggest you tweak the text to make it clear that it will be up to a given deployment to decide whether the privacy protection mechanism is actually used or not. In other word, the pricavy protection mechanism woudl be "Optional to Use". > The text above might be understood as saying that the CDNI Logging interface needs to _never_ disclose information that can be used to identify the user. I don't think we want to say that. We just want the interface to allow to not disclose that information when and where that is required. Ordinarily I wouldn't poke my nose in while you folks are chatting, but since I asked Kent to do a revision before Francois sent this note, perhaps I should say that I'd be OK with words that said something like that, if the working group goes for it. Spencer From flefauch@cisco.com Thu Oct 3 22:52:48 2013 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 DFE6321F9AB4 for ; Thu, 3 Oct 2013 22:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Moq5EMOwWTBq for ; Thu, 3 Oct 2013 22:52:37 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id BAF8621F9A5F for ; Thu, 3 Oct 2013 22:52:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5773; q=dns/txt; s=iport; t=1380865953; x=1382075553; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4BunJwsU64bK1jWsmrTwbBx0g4tjdQ2KRpin8J07oVc=; b=V66aUTNIxG3n6ToCY3wURz0PIvJRuHSeqWI4jmiu5rnUgtEc04nh2ZBV m5SeEHhqs9qJX0bddb9rkPSPv3Yzy6JX+8xwomq14l9r0lZl+rXShmMUO iWYphOKSyiP2/2GXeE0bD4ZgLmBHgASbGlWPnoWmgH1gf4llMF8zGLEA3 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAGZWTlKtJV2a/2dsb2JhbABQCoMHOEYMwUiBGhZ0giUBAQEDAQEBATctBwsFBwQCAQgRBAEBAQoUCQcnCxQJCAIEDgUIh3gGDLw7BI4OgRACMQcGgxmBBAOqAIMkgio X-IronPort-AV: E=Sophos;i="4.90,1030,1371081600"; d="scan'208";a="267942866" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 04 Oct 2013 05:52:30 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r945qUg4011913 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Oct 2013 05:52:30 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.33]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Fri, 4 Oct 2013 00:52:29 -0500 From: "Francois Le Faucheur (flefauch)" To: "Kent Leung (kleung)" Thread-Topic: [CDNi] Publication has been requested for draft-ietf-cdni-requirements-10 Thread-Index: AQHOwMXokl7vF4z+cECQPLVSl740yQ== Date: Fri, 4 Oct 2013 05:52:28 +0000 Message-ID: References: <523DA6BB.1010409@gmail.com> <52407F8A.4020606@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.106.9] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Martin Stiemerling , "" , Daryl Malas Subject: Re: [CDNi] Publication has been requested for draft-ietf-cdni-requirements-10 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 04 Oct 2013 05:52:49 -0000 Hi Kent, One small thing: > 12. Comment: "SEC-1... protect privacy" >=20 > I'm not quite sure how to capture privacy protection in the general secur= ity requirements section. It seems to be a broad statement in the context o= f IP and HTTP communications. So I'm open to suggested text. :) The CDNI in= terface that seems most relevant is the CDNI Logging interface. I've tried = to capture this requirement below. >=20 > Add a new requirement: >=20 > LI-18 [MED] The CDNI Logging interface should provide privacy protection > by not disclosing information that can be used to identify the us= er > (e.g. method that anonymize the IP address carried in the logging = field ). I suggest you tweak the text to make it clear that it will be up to a given= deployment to decide whether the privacy protection mechanism is actually = used or not. In other word, the pricavy protection mechanism woudl be "Opti= onal to Use". The text above might be understood as saying that the CDNI Logging interfac= e needs to _never_ disclose information that can be used to identify the us= er. I don't think we want to say that. We just want the interface to allow = to not disclose that information when and where that is required. Thanks Francois >=20 >=20 > If these changes are agreeable, let me know and I'll publish the next ver= sion of the draft. >=20 > Kent >=20 > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of S= pencer Dawkins > Sent: Monday, September 23, 2013 10:51 AM > To: Francois Le Faucheur (flefauch) > Cc: Martin Stiemerling; ; Daryl Malas > Subject: Re: [CDNi] Publication has been requested for draft-ietf-cdni-re= quirements-10 >=20 > On 9/23/2013 3:29 AM, Francois Le Faucheur (flefauch) wrote: >>=20 >>>>>>> In the same section, >>>>>>>=20 >>>>>>> RI-5 [MED] In case of detection of a request redirection loop, = the >>>>>>> CDNI Request Routing Redirection interface's loop preventi= on >>>>>>> mechanism should allow routing of the request by avoiding = the >>>>>>> loop (as opposed to the request loop being simply interrup= ted >>>>>>> without routing the request). >>>>>>>=20 >>>>>>> I'm not understanding what "by avoiding the loop" means. I can=20 >>>>>>> guess, but I'm guessing. >>>>>> How about: >>>>>> " >>>>>> RI-5 [MED] In case of detection of a potential request redirecti= on >>>>>> loop, the >>>>>> CDNI Request Routing Redirection interface's loop preventio= n >>>>>> mechanism should prevent or interrupt the loop and=20 >>>>>> allow routing of the request (as opposed to the request loop being=20 >>>>>> simply interrupted >>>>>> without routing the request). >>>>>> " >>>>> I'm not clearly explaining what's not clear to me. Let me guess again= ... >>>>>=20 >>>>> I'm pretty sure I'm choking because I'm reading "allow routing of=20 >>>>> the request" as "you sent me a request that loops when I route it,=20 >>>>> so I either prevent or interrupt the loop *and continue to route=20 >>>>> the request*, like I suddenly know how to route the request that=20 >>>>> was looping, without looping". >>>>>=20 >>>>> Is RI-5 saying that if you send a request that loops, you get a=20 >>>>> response that tells you that the request looped, as opposed to=20 >>>>> having the loop prevention mechanism drop the request to protect=20 >>>>> the CDN, but you get nothing back? Or am I missing this completely? >>>> [DM] I think I understand your concern; and, after reviewing the=20 >>>> requirement again, I agree with you. If the CDN knew how to avoid=20 >>>> the loop in the first place, why would it send a request purposely=20 >>>> in a direction that causes a loop. Perhaps the requirement should=20 >>>> state something more like: >>>>=20 >>>> [MED] In case of detection of a request redirection loop, the >>>> CDNI Request Routing Redirection interface's loop prevention >>>> mechanism should notify the requesting CDNs of the loop,=20 >>>> so the requesting CDN could attempt a difference dCDN. >>> After looking at the original requirement again, what I was struggling = with is that the text sounds like the interface is avoiding the loop that t= he request caused, but the same interface is still routing the same request= with no changes. >>>=20 >>> Your suggestion would work for me (if it works for others, of course), = because it doesn't use the same word for what happens before and after a re= quest redirection loops. >> The text suggested by Daryl could work for me too. Although I would pref= er: >> " >> [MED] In case of detection of a request redirection loop, the >> CDNI Request Routing Redirection interface's loop prevention >> mechanism should allow the uCDN to attempt a different dCDN. >> " >>=20 >> This is because the loop detection might actually be done by the uCDN it= self based on information received in the RI request, so the uCDN never rea= lly receive a "notification" of loop (ie the uCDN may look at the informati= on in the received RI request, and realises that the "initially selected dC= DN" would result in a loop - because it already appears in the received RI = request). >=20 > This text makes sense to me, and would also work for me if it works for o= thers. >=20 > I'm not sure how it's equivalent to the original RI-5, but since I said I= couldn't understand the original RI-5, that's probably a good thing :-) >=20 > Spencer > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From D.Malas@cablelabs.com Tue Oct 8 12:41:41 2013 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 E477E21F9C83 for ; Tue, 8 Oct 2013 12:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.462 X-Spam-Level: X-Spam-Status: No, score=-102.462 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 750pvJKfCGSh for ; Tue, 8 Oct 2013 12:41:36 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 76BDF21F9C28 for ; Tue, 8 Oct 2013 12:41:36 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id r98JfZ1H025349 for ; Tue, 8 Oct 2013 13:41:35 -0600 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Tue, 08 Oct 2013 13:41:35 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.03.0146.000; Tue, 8 Oct 2013 13:41:35 -0600 From: Daryl Malas To: "cdni@ietf.org" Thread-Topic: [CDNi] CDNI Framework WG Chair Review - Part 1 Thread-Index: AQHOxF5lF3rcjZN9PkaZrjfSCHNATA== Date: Tue, 8 Oct 2013 19:41:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [10.5.0.27] Content-Type: multipart/alternative; boundary="_000_CE748B5111F52dmalascablelabscom_" MIME-Version: 1.0 X-Approved: ondar Subject: [CDNi] CDNI Framework WG Chair Review - Part 1 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 08 Oct 2013 19:41:42 -0000 --_000_CE748B5111F52dmalascablelabscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable All, This is a fairly large draft, and I've been struggling to get time to revie= w it in detail. With this in mind, I'm going to break up my review in a co= uple of parts, so the authors and others can respond, argue or comment on m= y comments. --Daryl ------Part 1-------- Abstract (minor change): "CDN Interconnection requires the specification of several interfaces and mechanisms to address issues such as request routing, distribution metadata exchange, and logging information exchange across CDNs." Suggest we remove "several," since do not know exactly how many interfaces = end up being defined. Section 1 =96 Introduction: Change [I-D.ietf-cdni-use-cases] to reference RFC 6770. Change throughout = as necessary. Abstract and Introduction have a lot of redundancy. "CDN Interconnection requires the specification of several interfaces and mechanisms to address issues such as request routing, distribution metadata exchange, and logging information exchange across CDNs. The intent of this document is to outline what each interface needs to accomplish, and to describe how these interfaces and mechanisms fit together, while leaving their detailed specification to other documents." "CDN Interconnection requires the specification of several interfaces and mechanisms to address issues such as request routing, metadata exchange, and the acquisition of content by one CDN from another. The intent of this document is to describe how these interfaces and mechanisms fit together, leaving their detailed specification to other documents." Can you tell which one is the abstract and which is the introduction? I su= ggest we either remove the duplication or change the wording to better desc= ribe our intent with the draft. "The purpose of this document is to provide an overview of the various components necessary to interconnect CDNs." I think it would be more accurate to say, "The purpose of this document is to describe the functions of the interfaces and related compone= nts necessary to interconnect CDNs. Section 1.1: Change, "This document draws freely on the core terminology defined in RFC 6707." to "This document uses the core terminology defined in RFC 6707." (minor) "It also introduce the following terms:" to "It also introduces the= following terms:" Recursive CDI Request Redirection - "Note that the Downstream CDN may elect to have the request redirected directly to a Surrogate inside the Downstream CDN, to the Request Routing System of the Downstream CDN, to another CDN, or to any other system that the Downstream CDN sees as fit for handling the redirected request." I have concerns with the last part of this, "the Downstream CDN sees as fi= t for handling the redirected request." This implies the Upstream CDN (or, specifically, the = CDN domain) has no say in how the request is ultimately delivered to the su= bscriber. I think we are implying a business implication here. I suggest = we change this to, "=85or as necessary in order to handle the redirected re= quest appropriately." (minor) Suggest we capitalize the first letter of "Synchronous, Asynchronou= s and Trigger" for consistency. Section 1.2: In Figure 1, create consistency in the lines considered outside the scope o= f CDNI. Having both **** and =85.creates confusion. We ran into this duri= ng the AD review of the "requirements" draft. I suggest you talk with Kent= Leung to ensure consistency across the two. In the 2nd paragraph after "Figure 1: CDNI Expanded=85" the term uCDN start= s being used without being defined previously as a shortened form of upstre= am CDN. Afterwards, the text returns to spelling it out. I suggest we def= ine this early on and try to create some level of consistency of use throug= hout the document. The first time I see these defined is in Section 3. CDNI Metadata interface (MI) - change "May include a combination of:" to "I= t may include a combination of:" Page 7 =96 We have a reference to a new "caller" and "callee". Whom do the= se reference? I can surmise from the text, but they should be defined for = clarity to readers who have never participated in the CDNI WG. From what I= can tell these are never used again in the document. Can we leverage exis= ting terms that are more consistent through the document? Page 7 =96 Update reference to "I-D.brandenburg-cdni-has" to "RFC 6983". Section 2.1.1 =96 What is the purpose of stating, "...although the user is free to choose other DNS servers (e.g., OpenDNS, Google Public DNS)." I suggest we remove that. I don't think it adds any value to the explanati= on. Also, there is some editorial error in the 2nd paragraph, "=85to the end us= er-\u002Dthe user=85" Page 9, 2nd paragraph, "(1) there is a limit to the number alternate=85" to= "(1) there is a limit to the number of alternate=85" Last paragraph of this section, there is another editorial error "=85to the= client-\u002Dthe LDNS server=85" Page 12 =96 The example on step 7 seems redundant with step 4. I understan= d the step, but I think the example seems redundant. I suggest changing th= e example. Page 15 =96 Editorial issues in Step 2. Page 15 =96 Does it provide better clarity in step 4 to change "replacing t= he hostname by a subdomain" to "replacing the hostname with a subdomain"? >end =96Part 1 --_000_CE748B5111F52dmalascablelabscom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
All,

This is a fairly large draft, and I've been struggling to get time to = review it in detail.  With this in mind, I'm going to break up my revi= ew in a couple of parts, so the authors and others can respond, argue or co= mment on my comments.

--Daryl

------Part 1--------
Abstract (minor change):

"CDN Interconnection requires the specification of several
interfaces and mechanisms to address issues such as request routing,
distribution metadata exchange, and logging information exchange
across CDNs."

Suggest we remove "several," since do not know exactly how m= any interfaces end up being defined.

Section 1 =96 Introduction:
Change [I-D.ietf-cdni-use-cases] to reference RFC 6770.  Change t= hroughout as necessary.

Abstract and Introduction have a lot of redundancy.

"CDN Interconnection requires the specification of several
interfaces and mechanisms to address issues such as request routing,
distribution metadata exchange, and logging information exchange
across CDNs. The intent of this document is to outline what each
interface needs to accomplish, and to describe how these interfaces
and mechanisms fit together, while leaving their detailed
specification to other documents."

"CDN Interconnection requires the
specification of several interfaces and mechanisms to address issues
such as request routing, metadata exchange, and the acquisition of
content by one CDN from another. The intent of this document is to
describe how these interfaces and mechanisms fit together, leaving
their detailed specification to other documents."

Can you tell which one is the abstract and which is the introduction? =  I suggest we either remove the duplication or change the wording to b= etter describe our intent with the draft.  

"The purpose of this
document is to provide an overview of the various components
necessary to interconnect CDNs."

I think it would be more accurate to say, "The purpose of this
document is to describe the functions of the interfaces and related co= mponents
necessary to interconnect CDNs.

Section 1.1:

Change, "This document draws freely on the core terminology defin= ed in RFC
6707." to "This document uses the core terminology defined i= n RFC 6707."

(minor) "It also introduce the following terms:" to "It= also introduces the following terms:"

Recursive CDI Request Redirection -
"Note that the Downstream CDN may elect to have the request redir= ected
directly to a Surrogate inside the Downstream CDN, to the Request
Routing System of the Downstream CDN, to another CDN, or to any other<= /div>
system that the Downstream CDN sees as fit for handling the
redirected request."

I  have concerns with the last part of this, "the Downstream= CDN sees as fit for handling the
redirected request."  This implies the Upstream CDN (or, spe= cifically, the CDN domain) has no say in how the request is ultimately deli= vered to the subscriber.  I think we are implying a business implicati= on here.  I suggest we change this to, "=85or as necessary in order to handle the redirected request appropriately."

(minor) Suggest we capitalize the first letter of "Synchronous, A= synchronous and Trigger" for consistency.

Section 1.2:

In Figure 1, create consistency in the lines considered outside the sc= ope of CDNI.  Having both **** and =85.creates confusion.  We ran= into this during the AD review of the "requirements" draft. &nbs= p;I suggest you talk with Kent Leung to ensure consistency across the two.

In the 2nd paragraph after "Figure 1: CDNI Expanded=85" the = term uCDN starts being used without being defined previously as a shortened= form of upstream CDN.  Afterwards, the text returns to spelling it ou= t.  I suggest we define this early on and try to create some level of consistency of use throughout the document.  The= first time I see these defined is in Section 3.

CDNI Metadata interface (MI) - change "May include a combination = of:" to "It may include a combination of:"

Page 7 =96 We have a reference to a new "caller" and "c= allee".  Whom do these reference?  I can surmise from the te= xt, but they should be defined for clarity to readers who have never partic= ipated in the CDNI WG.  From what I can tell these are never used again in the document.  Can we leverage existing terms that are more = consistent through the document?

Page 7 =96 Update reference to "I-D.brandenburg-cdni-has" to= "RFC 6983".

Section 2.1.1 =96 What is the purpose of stating, "...although th= e user is
free to choose other DNS servers (e.g., OpenDNS, Google Public DNS).&q= uot;

I suggest we remove that.  I don't think it adds any value to the= explanation.

Also, there is some editorial error in the 2nd paragraph, "=85to = the end user-\u002Dthe user=85"

Page 9, 2nd paragraph, "(1) there is a limit to the number altern= ate=85" to "(1) there is a limit to the number of alternate=85&qu= ot;

Last paragraph of this section, there is another editorial error "= ;=85to the client-\u002Dthe LDNS server=85"

Page 12 =96 The example on step 7 seems redundant with step 4.  I= understand the step, but I think the example seems redundant.  I sugg= est changing the example.

Page 15 =96 Editorial issues in Step 2.

Page 15 =96 Does it provide better clarity in step 4 to change "r= eplacing the hostname by a subdomain" to "replacing the hostname = with a subdomain"?

>end =96Part 1



--_000_CE748B5111F52dmalascablelabscom_-- From flefauch@cisco.com Thu Oct 10 06:35:36 2013 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 C99B921E8104 for ; Thu, 10 Oct 2013 06:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuqeBzCmmCzq for ; Thu, 10 Oct 2013 06:35:31 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 325FE21F9CC2 for ; Thu, 10 Oct 2013 06:35:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=919; q=dns/txt; s=iport; t=1381412131; x=1382621731; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=ka0URN4wq40wDG5Mx3sKSl+WvEpnWJL7DvOYjD5niIg=; b=XYXX4lt9/s7suNNsvKZDrtEXP9RYjkK8aBX6/ax+jicyZ/dcNqs+f4Is +4e0pabYNeaSmcNy9LtrF6TrmIzlhrOF96bKTrWlwd9vQaw9iSzju7QGE /NOLJ15iD35xE4Bu+uuiCYzMuuq0t1M0bbOcu/wyRI5fk+1oNwjjPvc1Q 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAFusVlKtJV2c/2dsb2JhbABZgweBCsEdgSIWdIInAQQ6LRISASoUQicEAQ0Nh365P48WMYMmgQQDqgeDJIIq X-IronPort-AV: E=Sophos;i="4.90,1072,1371081600"; d="scan'208";a="270441685" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 10 Oct 2013 13:35:29 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9ADZT0j017400 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 10 Oct 2013 13:35:29 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.33]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Thu, 10 Oct 2013 08:35:29 -0500 From: "Francois Le Faucheur (flefauch)" To: "Kent Leung (kleung)" , Yiu Lee Thread-Topic: LI-14 and LI-15 in draft-ietf-cdni-requirements Thread-Index: AQHOxb2Vps75A4VDGkKG/wZ5SpSAdw== Date: Thu, 10 Oct 2013 13:35:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.206] Content-Type: text/plain; charset="us-ascii" Content-ID: <6F08849912FE2B4AA20FDF11701DE636@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: [CDNi] LI-14 and LI-15 in draft-ietf-cdni-requirements X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 10 Oct 2013 13:35:36 -0000 Kent, Yiu, As we are working on a statement of compliance for cdni-logging, we are goi= ng through all relevant requirements and I noticed:=20 " LI-14 [HIGH] The CDNI Logging interface shall support extensibility to allow proprietary information fields to be carried. These information fields shall be agreed upon ahead of time between the corresponding CDNs. LI-15 [HIGH] The CDNI Logging interface shall support the exchange of extensible log file formats to support proprietary information fields. These information fields shall be agreed upon ahead of time between the corresponding CDNs. " Do we really need two separate requirements to indicate that the cdni-loggi= ng interafce needs to be extensible to support proprietray fields? If yes, can you expand on the subttle difference between the two? Thanks Francois= From flefauch@cisco.com Thu Oct 10 07:08:27 2013 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 424D221F9D30 for ; Thu, 10 Oct 2013 07:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3l0dZ18yohto for ; Thu, 10 Oct 2013 07:08:09 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 167CB21F93B9 for ; Thu, 10 Oct 2013 07:08:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1325; q=dns/txt; s=iport; t=1381414085; x=1382623685; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=MwrKCMrVCvEjvoJeHgw/az0iZvDuEIO6OLhFGk/GtTA=; b=gvNsQ3M1CUE3z+ZwGBfPQtOV6CXD+ohD4nwMkSLR4jTnmqgNuqcwNAlN CsUT1dbIaxN8GkiBjC1fATTi83jRF6pqkaNJDWnU2YRNdkFLPDZUgSdoh 7EUdB480CO3Sjb02XwzT9JM3kHfiH6Nqn0upOHhy1L+8WnBIDeZTch7gJ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4FAN+zVlKtJXHB/2dsb2JhbABZgweBCsEngSEWdIInAQQ6PxIBKhRCJwQBDQ0Th2u5So8WMYMmgQQDqgeDJIIq X-IronPort-AV: E=Sophos;i="4.90,1072,1371081600"; d="scan'208";a="267492230" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 10 Oct 2013 14:08:03 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9AE83w2008581 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 10 Oct 2013 14:08:03 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.33]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Thu, 10 Oct 2013 09:08:03 -0500 From: "Francois Le Faucheur (flefauch)" To: "Kent Leung (kleung)" , Yiu Lee Thread-Topic: SEC-4 in in draft-ietf-cdni-requirements Thread-Index: AQHOxcIi0D1l2Tya00O4QpS5GM3Byg== Date: Thu, 10 Oct 2013 14:08:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.206] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: [CDNi] SEC-4 in in draft-ietf-cdni-requirements X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 10 Oct 2013 14:08:27 -0000 Kent, Liu, " SEC-4 [MED] The CDNI solution should be able to ensure that the Downstream CDN cannot spoof a transaction log attempting to appear as if it corresponds to a request redirected by a given Upstream CDN when that request has not been redirected by this Upstream CDN. This ensures non-repudiation by the Upstream CDN of transaction logs generated by the Downstream CDN for deliveries performed by the Downstream CDN on behalf of the Upstream CDN. " I think this requirement does not reflect correctly how non-repudiation cou= ld play in teh context of CDNI Logging. For example, since the logging info= rmation is sent by dCDN to uCDN, it only makes sense to talk about non-repu= diation by dCDN, not by uCDN. I suggest a rewording along the lines of:=20 " SEC-4 [MED] The CDNI solution should be able to ensure non-repudiation by = the Downstream CDN of transaction logs generated by the Downstream CDN and commu= nicated to an Upstream CDN. This reduces the incentives for the Downstream = CDN to spoof a transaction log attempting to appear as if it corresponds to= a request redirected by the Upstream CDN when that request has not been re= directed by this Upstream CDN. " Cheers Francois= From internet-drafts@ietf.org Thu Oct 10 07:22:22 2013 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 EFC2F21E808E; Thu, 10 Oct 2013 07:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ml8SI+88do1d; Thu, 10 Oct 2013 07:22:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D3D21E805D; Thu, 10 Oct 2013 07:22:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131010142221.30339.69093.idtracker@ietfa.amsl.com> Date: Thu, 10 Oct 2013 07:22:21 -0700 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-logging-07.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 10 Oct 2013 14:22:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Content Delivery Networks Interconnection= Working Group of the IETF. Title : CDNI Logging Interface Author(s) : Francois Le Faucheur Gilles Bertrand Iuniana Oprescu Roy Peterkofsky Filename : draft-ietf-cdni-logging-07.txt Pages : 45 Date : 2013-10-10 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: http://tools.ietf.org/html/draft-ietf-cdni-logging-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-07 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 flefauch@cisco.com Thu Oct 10 10:12:05 2013 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 2FA2D21F9B8A for ; Thu, 10 Oct 2013 10:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYH7hA42Fk9X for ; Thu, 10 Oct 2013 10:12:00 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 359CE21F9BCE for ; Thu, 10 Oct 2013 10:11:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7399; q=dns/txt; s=iport; t=1381425115; x=1382634715; h=from:to:subject:date:message-id:mime-version; bh=FyQ8AfCfZ43XDINoczdaxu2eRYbPiH0E5MM2eUgUG6c=; b=FLDwQU+HvI03PToIROk1t8AtO9rhgUPqSX/DBVlBwoxKi06xCB/Om+OG wtdw46lFG3YBuRItASLITgUK0Z+lgBYc+GJ7SNZGhJ+b4vbxwv+ElIvu/ rbNXeyCqPMfhOgJHxCQ6edfnHv40ohZQ1M+cwmOhc7/oyvRd6biNNENgh w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4FAHjfVlKtJXG//2dsb2JhbABZgwc4TAbBKoEjFnSCJwEEgQsBKgNTJwQKEQGHfQcFmGqhOo8Wg1eBBAOqB4Mkgio X-IronPort-AV: E=Sophos;i="4.90,1073,1371081600"; d="scan'208,217";a="270673264" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 10 Oct 2013 17:11:51 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9AHBpKx000592 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 10 Oct 2013 17:11:51 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.33]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Thu, 10 Oct 2013 12:11:51 -0500 From: "Francois Le Faucheur (flefauch)" To: "" Thread-Topic: Updates to cdni-logging since Berlin Thread-Index: AQHOxdvPvqpoq4Dd+UyEwZf4y/0w+Q== Date: Thu, 10 Oct 2013 17:11:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.206] Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D0BB5EBBExmbrcdx10ciscoc_" MIME-Version: 1.0 Subject: [CDNi] Updates to cdni-logging since Berlin X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 10 Oct 2013 17:12:05 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D0BB5EBBExmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, (speaking as one of the document editors) This is to report on the progress on cdni-logging since Berlin. We have issued two updates (-06 and -07) since Berlin (-05). I think we are= getting very close to a version that will be ready from the editors viewpo= int. The main changes are : * added/tweaked text reflecting decision to not support real-time logging e= xchange and not support logging of operational events * added granularity of occurence (eg per CDNI Logging File) of CDNI directi= ves (as per Kevin's comment) * clarifications in usage of a few directives and fields (as per Kevin's co= mment) * removed s-uri-signing field (since this is going to cdni-signing document= as announced by Kent on teh list) * cleaned-up/added text on what is mandatory/optional to implement by a giv= en CDNI Logging implementation, which is a distinct notion from what is man= datory/optional to actually use in a given deployment. For example, the "s-cached" field may or may not be used in a given deploym= ent (i.e it is "optional to use"), however a "dCDN-side implementation of t= he CDNI Logging interface MUST support the ability to include valid values= " for the "s-cached" field (i.e it is "mandatory to implement") . As discussed in Berlin, the general approach is to select a set of "Mandato= ry to implement" that will ensure easy and functional practical interoperab= ility, and therefore facilitate deployment (this is as opposed to an altern= ative approach of selecting the absolute minimum set that will only guarant= ee the bare minimum interoperability). * updated the text on use of compression (content encoding) for HTTP transf= er of CDNI Logging files (to reflect the corresponding discussion on the li= st). * removed the Open Issues section since they are now all addressed * removed everything related to non-repudiation since this is going to be d= iscussed outside of this document * added text to clarify that a dCDN needs to be able to serve any logging f= ile that is currently advertised in the subscription feed (as per my note t= o the list) * removed former Appendix "A.2. Considerations on CDNI Logging Applicabili= ty" and moved the subset of text that was still relevant into the appropria= te part of the document (eg benefits of using W3C like format, benefits of = gzip to mitigate scaling issue with ABR logs). * reworded former Appendix "A.1. Compliance with cdni-requirements" and pr= esented in Table format to facilitate reading of level of compliance to eac= h and every requirement. * editorial fixes Please review and provide comments. Francois A diff from 06 to 07 is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-07 Diff from 05 to 06 is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-06 --_000_FC236DA6F2DA77449EF2D02DF4471A8D0BB5EBBExmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Folks,

(speaking as one of the document editors)

This is to report on the progress on cdni-logging since Berlin.

We have issued two updates (-06 and -07) since Berlin (-05). I think w= e are getting very close to a version that will be ready from the editors v= iewpoint. The main changes are :

* added/tweaked text reflecting decision to not support real-time logg= ing exchange and not support logging of operational events

* added granularity of occurence (eg per CDNI Logging File) = of CDNI directives (as per Kevin's comment)

* clarifications in usage of a few directives and fields (as per = Kevin's comment)

* removed s-uri-signing field (since this is going to cdni-signing doc= ument as announced by Kent on teh list)

* cleaned-up/added text on what is mandatory/optional to implement by = a given CDNI Logging implementation, which is a distinct notion from what i= s mandatory/optional to actually use in a given deployment.
For example, the "s-cached" field may or may not be used in = a given deployment (i.e it is "optional to use"), however a "= ;dCDN-side implementation of the CDNI Logging interface MUST support  the ability to include valid values" for the "s-cach= ed" field (i.e it is "mandatory to implement") .
As discussed in Berlin, the general approach is to select a set of &qu= ot;Mandatory to implement" that will ensure easy and functional practi= cal interoperability, and therefore facilitate deployment (this is as oppos= ed to an alternative approach of selecting the absolute minimum set that will only guarantee the bare minimum interop= erability).

* updated the text on use of compression (content encoding) for HTTP t= ransfer of CDNI Logging files (to reflect the corresponding discussion on t= he list).

* removed the Open Issues section since they are now all addressed

* removed everything related to non-repudiation since this is going to= be discussed outside of this document

* added text to clarify that a dCDN needs to be able to serve any logg= ing file that is currently advertised in the subscription feed (as per my n= ote to the list)

* removed former Appendix "A.2.  Considerations on CDNI Logg= ing Applicability" and moved the subset of text that was still relevan= t into the appropriate part of the document (eg benefits of using W3C like = format, benefits of gzip to mitigate scaling issue with ABR logs).

* reworded former Appendix "A.1.  Compliance with cdni-= requirements" and presented in Table format to facilitate reading of l= evel of compliance to each and every requirement.

* editorial fixes

Please review and provide comments.

Francois


--_000_FC236DA6F2DA77449EF2D02DF4471A8D0BB5EBBExmbrcdx10ciscoc_-- From ben@niven-jenkins.co.uk Sun Oct 13 00:28:14 2013 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 D3BA921E80BB for ; Sun, 13 Oct 2013 00:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGgaaL7Sv7Ye for ; Sun, 13 Oct 2013 00:28:01 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 267DE21E80B4 for ; Sun, 13 Oct 2013 00:28:01 -0700 (PDT) Received: from cpc4-cmbg17-2-0-cust814.5-4.cable.virginmedia.com ([86.14.227.47] helo=[192.168.0.4]) by mail6.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1VVG5n-0004f4-ET; Sun, 13 Oct 2013 08:27:59 +0100 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: Date: Sun, 13 Oct 2013 08:27:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <82E8974B-BD12-4B4B-871B-8CA57820FCA4@niven-jenkins.co.uk> References: To: "Francois Le Faucheur (flefauch)" X-Mailer: Apple Mail (2.1085) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "cdni@ietf.org" Subject: Re: [CDNi] CDNI Logging : access to CDNI Logging File once it is moved from Subscription to Archive in the Logging Feed X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 13 Oct 2013 07:28:15 -0000 Francois, Colleagues, My opinion is that if logs are advertised in the subscription or archive = feeds then they should be made available for download. I.e. we don't = introduce new semantics that mean that if it is a CDN Logging feed then = only entries in the subscription feed should be made available and the = archive feed is "known" to probably point to dead links for log files. Forcing a linkage between time covered by the subscription feed and tie = and the retention time a uCDN would like a dCDN to provide is not a good = idea IMO as it limits the flexibility we give to implementations for no = advantage. If a CDN wishes to remove old logs they should also remove the archive = pages that reference those logs (or never generate/advertise them in the = first place). Ben On 27 Sep 2013, at 14:15, Francois Le Faucheur (flefauch) wrote: > Folks, >=20 > [as a co-author] >=20 > I'd like input on one of the very remaining open items in = cdni-logging. >=20 > For memory, the CDNI Logging Feed allows a dCDN to advertise to the = uCDN which CDNI Logging Files can be retrieved by the uCDN from the = dCDN. > It is structured as an Archived ATOM feed, meaning that a sliding = window of currently available CDNI Logging files is advertised in a = "Subscription" document, and then, over time, the older Logging Files = are moved to an "Archive" document and new Logging Files appear in the = Subscription document. >=20 > There is currently an editor's note asking a question about what = should happen once a Logging File has been moved to an "archive": > " > [Editor's note: if a given Logging file is moved away from > subscription document to an archive document, do we agree it may no > longer be accessible to uCDN?] > " > I personally agree that the Logging File need not be made available = for download once it has moved away from the Subscripton document to the = Archive document. My rationale is that: > * this is precisely the point of the Subscription document i.e. = to indicate which files are currently downloadable and the server-side = is then responsible for ensuring it can serve these files (ie it has to = retain them and be ready to serve them).=20 > * it is not reasonable to expect that the server-side will make = old Logging Files accessible forever > * if the client-side wants to have a large window of time to = pull Logging Files, then it needs to agree with the server-side and this = period will be used as the retention period in the subscripton file.=20 >=20 > Please let us know if you disagree/agree with that, so we can address = that in the next rev (this has not been addressed in -06 posted today). >=20 > For memory, I think the current text already implies the above: > " > The server-side implementation MUST respond to any valid pull request > by a client-side implementation for a CDNI Logging File published by > the server-side in the subscription document of the CDNI Logging > Feed.=20 > " > If we agree with the position above, we could also tweak the text to = say that the server-side MUST respond _and_ actually provide the Logging = File (ie responding 404 is not good). >=20 > Cheers >=20 > Francois >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From ben@niven-jenkins.co.uk Sun Oct 13 18:13:56 2013 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 6EB3321F9C68 for ; Sun, 13 Oct 2013 18:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eyrx9rlFPh49 for ; Sun, 13 Oct 2013 18:13:50 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5222B11E816F for ; Sun, 13 Oct 2013 18:13:47 -0700 (PDT) Received: from cpc4-cmbg17-2-0-cust814.5-4.cable.virginmedia.com ([86.14.227.47] helo=[192.168.0.4]) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1VVWjC-0004Qc-OF; Mon, 14 Oct 2013 02:13:47 +0100 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: Date: Mon, 14 Oct 2013 02:13:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <48474D18-F627-4FE2-B098-41B9E93C6E73@niven-jenkins.co.uk> References: To: "Francois Le Faucheur (flefauch)" X-Mailer: Apple Mail (2.1085) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "" , Yiu Lee Subject: Re: [CDNi] SEC-4 in in draft-ietf-cdni-requirements X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 14 Oct 2013 01:13:56 -0000 Francois, Colleagues, On 10 Oct 2013, at 15:08, Francois Le Faucheur (flefauch) wrote: > Kent, Liu, >=20 > " > SEC-4 [MED] The CDNI solution should be able to ensure that the > Downstream CDN cannot spoof a transaction log attempting to > appear as if it corresponds to a request redirected by a = given > Upstream CDN when that request has not been redirected by = this > Upstream CDN. This ensures non-repudiation by the Upstream > CDN of transaction logs generated by the Downstream CDN for > deliveries performed by the Downstream CDN on behalf of the > Upstream CDN. > " > I think this requirement does not reflect correctly how = non-repudiation could play in teh context of CDNI Logging. For example, = since the logging information is sent by dCDN to uCDN, it only makes = sense to talk about non-repudiation by dCDN, not by uCDN. >=20 > I suggest a rewording along the lines of:=20 >=20 > " > SEC-4 [MED] The CDNI solution should be able to ensure = non-repudiation by the Downstream > CDN of transaction logs generated by the Downstream CDN and = communicated to an Upstream CDN. This reduces the incentives for the = Downstream CDN to spoof a transaction log attempting to appear as if it = corresponds to a request redirected by the Upstream CDN when that = request has not been redirected by this Upstream CDN. > " I don't see how the second sentence leads from the first. I.e. I don't = see how a dCDN having the ability to ensure logs that it has generated = are not modified reduces the dCDN's incentive to spoof (or not to spoof) = log entries. Maybe just drop the second sentence entirely? Ben From ben@niven-jenkins.co.uk Sun Oct 13 20:09:44 2013 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 20E1E11E81DA for ; Sun, 13 Oct 2013 20:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckiuWsP8q6X3 for ; Sun, 13 Oct 2013 20:09:39 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 6750F11E80E2 for ; Sun, 13 Oct 2013 20:09:39 -0700 (PDT) Received: from cpc4-cmbg17-2-0-cust814.5-4.cable.virginmedia.com ([86.14.227.47] helo=[192.168.0.4]) by mail4.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1VVYXK-0000Bh-9U; Mon, 14 Oct 2013 04:09:38 +0100 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: Date: Mon, 14 Oct 2013 04:09:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Brandenburg, R. (Ray) van" X-Mailer: Apple Mail (2.1085) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "cdni@ietf.org" Subject: Re: [CDNi] CDNI and byte-range requests X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 14 Oct 2013 03:09:44 -0000 Ray, On 30 Jul 2013, at 12:27, Brandenburg, R. (Ray) van wrote: > Hi all, >=20 > As I'm not sure whether this should be part of the Redirection = Interface document or the Framework document, let me just post this as a = general question to the list: >=20 > To my knowledge, the current CDNI documents do not explicitly address = the case of HTTP Byte-range requests. Although in most cases byte-range = requests will function just as any other requests, I think there are = some cases where byte-range requests warrant further attention. An = example is the Redirection interface. If a uCDN asks a dCDN to deliver a = particular user request (containing a byte range), and the dCDN answers = positively, can the uCDN assume that the dCDN accepts any future = requests for the same file with a different byte range? And if that is = the case, is this default behavior or do we need an explicit flag in the = inter-CDN redirection request to indicate the uCDN/dCDN's preference?=20 >=20 > To be clear: I don't think we need any new functionality to handle = byte-range requests, but a few sentences in either the Framework or the = RI document might clear up any future uncertainty.=20 I don't see how this is any different to a sequence of non byte-range = requests. It will likely depend on the behaviour of the client (and possibly = whether the server closes the connection after each request if that = drives a different client behaviour) as to where the client ends up = going (uCDN or dCDN) when it makes a subsequent request.=20 Trying to say anything here may take us down the rat hole of trying to = describe client behaviour which we don't control. Ben >=20 > Best regards, >=20 > Ray > This e-mail and its contents are subject to the DISCLAIMER at = http://www.tno.nl/emaildisclaimer >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Mon Oct 14 05:37:44 2013 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 162A821E8165 for ; Mon, 14 Oct 2013 05:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klubBAN0532f for ; Mon, 14 Oct 2013 05:37:38 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id AA4D521E8163 for ; Mon, 14 Oct 2013 05:37:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3726; q=dns/txt; s=iport; t=1381754254; x=1382963854; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4o6WMvbgAky2dDXj6tXJL9lLzgchnNp9qSpzUffXqpE=; b=fJlD8q3bwpzdWnOlVganCdbn5/4fZgh6VnAeEi8t2UwS7u6Wam+/0MAv 21pj9usPJjbNmZGL3M//wFLNxqwM3VS1dv1Pu2N4I10OoWHAqmmcBbBhA wpHHZ3Q3rUQCfdWBAUeuzAQgbIx3mdqFlienYsVQ4mTyl7aUg/muCrnQq 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAMnkW1KtJXG//2dsb2JhbABZgweBCsFugSAWdIIlAQEBAwE6PwULAgEIGAoUEDIlAgQOBQgTh2UGvViPHwIxB4MfgQQDqgeDJIIp X-IronPort-AV: E=Sophos;i="4.93,492,1378857600"; d="scan'208";a="271609063" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 14 Oct 2013 12:37:34 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9ECbY9O030947 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Oct 2013 12:37:34 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.33]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Mon, 14 Oct 2013 07:37:33 -0500 From: "Francois Le Faucheur (flefauch)" To: Ben Niven-Jenkins Thread-Topic: [CDNi] SEC-4 in in draft-ietf-cdni-requirements Thread-Index: AQHOxcIi0D1l2Tya00O4QpS5GM3BypnzvYyAgAC/DwA= Date: Mon, 14 Oct 2013 12:37:33 +0000 Message-ID: References: <48474D18-F627-4FE2-B098-41B9E93C6E73@niven-jenkins.co.uk> In-Reply-To: <48474D18-F627-4FE2-B098-41B9E93C6E73@niven-jenkins.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.206] Content-Type: text/plain; charset="us-ascii" Content-ID: <2559E2A67B04C341B88A2EBB291F56C3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Yiu Lee Subject: Re: [CDNi] SEC-4 in in draft-ietf-cdni-requirements X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 14 Oct 2013 12:37:44 -0000 On 14 Oct 2013, at 03:13, Ben Niven-Jenkins wrote: > Francois, Colleagues, >=20 > On 10 Oct 2013, at 15:08, Francois Le Faucheur (flefauch) wrote: >=20 >> Kent, Liu, >>=20 >> " >> SEC-4 [MED] The CDNI solution should be able to ensure that the >> Downstream CDN cannot spoof a transaction log attempting to >> appear as if it corresponds to a request redirected by a given >> Upstream CDN when that request has not been redirected by this >> Upstream CDN. This ensures non-repudiation by the Upstream >> CDN of transaction logs generated by the Downstream CDN for >> deliveries performed by the Downstream CDN on behalf of the >> Upstream CDN. >> " >> I think this requirement does not reflect correctly how non-repudiation = could play in teh context of CDNI Logging. For example, since the logging i= nformation is sent by dCDN to uCDN, it only makes sense to talk about non-r= epudiation by dCDN, not by uCDN. >>=20 >> I suggest a rewording along the lines of:=20 >>=20 >> " >> SEC-4 [MED] The CDNI solution should be able to ensure non-repudiation = by the Downstream >> CDN of transaction logs generated by the Downstream CDN and comm= unicated to an Upstream CDN. This reduces the incentives for the Downstream= CDN to spoof a transaction log attempting to appear as if it corresponds t= o a request redirected by the Upstream CDN when that request has not been r= edirected by this Upstream CDN. >> " >=20 > I don't see how the second sentence leads from the first. I.e. I don't se= e how a dCDN having the ability to ensure logs that it has generated are no= t modified reduces the dCDN's incentive to spoof (or not to spoof) log entr= ies. What non-repudiation brings is the fact that the dCDN can not dispute havin= g sent a particular Log Record (and have it sent exactly as recieved by the= uCDN). So a dCDN that is caught sending a CDNI Logging file with invalid records (= and the proof for that would have to be established via some other mechanis= m, such as for example contrasting it to CSP logs generated from end-device= s) can not just say "oh, I never sent that file, you must have done somethi= ng wrong yourself and generated/corrupted that logging record/file yourself= ". Basically, it brings traceability which generally helps keeping people h= onest. It is an open question as to whether such a non-repudiation mechanis= m brings sufficient value or not. Some argued "yes", which is why we have a= requirement for it. But that is a separate question.=20 Perhaps we should not say that "it reduces the incentive", but rather that = it creates a disincentive to cheat.=20 Perhaps this wording may help make things a little clearer: " SEC-4 [MED] The CDNI solution should be able to ensure non-repudiation by = the Downstream CDN of transaction logs generated by the Downstream CDN and = communicated to an Upstream CDN. This would ensure that the Downstream CDN = can not repudiate transmitted Log records, and therefore act as a disincent= ive for the dCDN to spoof a transaction log (attempting to appear as if it = corresponds to a request redirected by the Upstream CDN when that request h= as not been redirected by this Upstream CDN). " >=20 > Maybe just drop the second sentence entirely? >=20 That woudl be an easy way out, but it is clearly far from trivial to articu= late the rationale for including a requirement about non-repudiatin, I thin= k we need to record teh rationale. Otherwise, the question will most likely= come up come up at review time down the pipe. Cheers Francois > Ben >=20 From flefauch@cisco.com Mon Oct 14 21:41:45 2013 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 865D421E81A2 for ; Mon, 14 Oct 2013 21:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSvJQRDkc0+U for ; Mon, 14 Oct 2013 21:41:40 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD0321E80C5 for ; Mon, 14 Oct 2013 21:41:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10751; q=dns/txt; s=iport; t=1381812100; x=1383021700; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=KpKrxvtP3QgT/uiY6iG0JtqJ5yyBT8+2q0CtWkbVifM=; b=iyz7cYbiT2/9hg4Yv/yUlnAgK4d4ceTkzuiTDjlaU+o9erZRSOZUUUXv Tt8vMdVOsHuT1wNhEJSWoEOcZhdraDNwrMGxleK1JAda5IYm/A1FocbRA YF7QZXTkWEjzjiGesGV29irUhSon1ZyEuVBYQBUctVjSC9ktKnddI7usl o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AssFAPXGXFKtJV2Z/2dsb2JhbAA/FwODBzhSwiCBGhZtB4ImAQECAmYCIQIBHA4KBAwKMiQBAgEDG4d+DDavC44ejHWBDBt9IAEMCxEHgweBBgOqBoJSUoFwOQ X-IronPort-AV: E=Sophos;i="4.93,496,1378857600"; d="scan'208,217";a="272129426" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 15 Oct 2013 04:41:39 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9F4fdHZ020791 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 15 Oct 2013 04:41:39 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.33]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Mon, 14 Oct 2013 23:41:39 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: Informal Meetings on CDNI Logging - 16 Oct Thread-Index: AQHOyWDWntoQppkrr0yqebpjMWBLrQ== Date: Tue, 15 Oct 2013 04:41:39 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.105.199] Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D0BB714F8xmbrcdx10ciscoc_" MIME-Version: 1.0 Subject: [CDNi] Informal Meetings on CDNI Logging - 16 Oct X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 15 Oct 2013 04:41:45 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D0BB714F8xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Just a friendly reminder about tommorow's Informal Meetings on CDNI Logging= : * Wed 16 Oct, at 9:15am California Time (ie 18:15pm Paris Time) Attendance is via Webex: Topic: Informal Meetings on CDNI Logging Date: Wednesday, October 16, 2013 Time: 6:15 pm, Europe Summer Time (Paris, GMT+02:00) Meeting Number: 304 625 039 Password: cdni ------------------------------------------------------- To join the meeting online(Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D206137858&UID=3D4843= 18167&PW=3DNY2IzMDA2NTQ0&RT=3DMiMyMw%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: cdni 4. Click "Join". 5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. Call-in toll-free number (US/Canada): +1-866-432-9903 Call-in toll number (US/Canada): +1-408-525-6800 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restricti= ons.pdf Access code:304 625 039 CCP:+14085256800x304625039# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. --_000_FC236DA6F2DA77449EF2D02DF4471A8D0BB714F8xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <0119391E39EAB54C81594CBA76DD5F32@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Hi,

Just a friendly reminder about tommorow's Informal Meetings on CD= NI Logging:
* Wed = 16 Oct, at 9:15am California Time (ie 18:15pm Paris Time)


Attendance is via Webex:

Topic: Informal Meetings on CDNI Logging 
Date: Wednesday, October 16, 2013 
Time: 6:15 pm, Europe Summer Time (Paris, GMT+02:00)=  
Meeting Number: 304 625 039 
Password: cdni 

-------------------------------------------------------&= nbsp;
To join the meeting online(Now from mobile devices!)&nbs= p;
-------------------------------------------------------&= nbsp;
1. Go to https://cisco.webex.c= om/ciscosales/j.php?ED=3D206137858&UID=3D484318167&PW=3DNY2IzMDA2NT= Q0&RT=3DMiMyMw%3D%3D 
2. If requested, enter your name and email address. = ;
3. If a password is required, enter the meeting password= : cdni 
4. Click "Join". 
5. If the meeting includes a teleconference, follow the = instructions that appear on your screen. 

-------------------------------------------------------&= nbsp;
To join the audio conference only 
-------------------------------------------------------&= nbsp;
To receive a call back, provide your phone number when y= ou join the meeting, or call the number below and enter the access code.&nb= sp;
Call-in toll-free number (US/Canada): +1-866-432-990= 3 
Call-in toll number (US/Canada): +1-408-525-6800&nbs= p;
Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf 

Access code:304 625 039 

CCP:+14085256800x304625039# 

IMPORTANT NOTICE: This WebEx service includes a feature = that allows audio and any documents and other materials exchanged or viewed= during the session to be recorded. By joining this session, you automatically consent to such recordings. If = you do not consent to the recording, discuss your concerns with the meeting= host prior to the start of the recording or do not join the session. Pleas= e note that any such recordings may be subject to discovery in the event of litigation. 

--_000_FC236DA6F2DA77449EF2D02DF4471A8D0BB714F8xmbrcdx10ciscoc_-- From flefauch@cisco.com Tue Oct 15 01:52:59 2013 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 9DC1E21E809A for ; Tue, 15 Oct 2013 01:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bwhl7KO5opfZ for ; Tue, 15 Oct 2013 01:52:52 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 06D4311E817C for ; Tue, 15 Oct 2013 01:52:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4619; q=dns/txt; s=iport; t=1381827159; x=1383036759; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=7f4+Oz5hR5iWCO2q8MumPgSyDbuZWYaLeJIjDeAQ3uw=; b=biBxc4xbWuYio9ryP1J51QTK5LGWNxP3KaTs825nu4slK7jSBV0u4TP2 2LEHiG6sE5fRqJBcf5FHW7pTmsZp/vstzLXBw2/oL4J8ifYlvjAD4Wo1Z 9liuA6cx9rF/YsYkJvu6MNIbnOKMFSF92WZq+KMpnvLL/cOgzUXTwDb7q 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAFoBXVKtJV2b/2dsb2JhbABZgwc4UsIdgR8WdIIlAQEBAwEBAQFrCwULAgEIGAoDFgsnCyUCBA4FCId4Bgy8dgSPFwIxB4MfgQYDqgaBZoE+gik X-IronPort-AV: E=Sophos;i="4.93,497,1378857600"; d="scan'208";a="272199185" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 15 Oct 2013 08:52:38 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9F8qcmW024937 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Oct 2013 08:52:38 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.33]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Tue, 15 Oct 2013 03:52:37 -0500 From: "Francois Le Faucheur (flefauch)" To: Ben Niven-Jenkins Thread-Topic: [CDNi] CDNI Logging : access to CDNI Logging File once it is moved from Subscription to Archive in the Logging Feed Thread-Index: AQHOu4ObUoHE8wHJKkqQcuD6pGxU7JnyqESAgAM8TgA= Date: Tue, 15 Oct 2013 08:52:37 +0000 Message-ID: References: <82E8974B-BD12-4B4B-871B-8CA57820FCA4@niven-jenkins.co.uk> In-Reply-To: <82E8974B-BD12-4B4B-871B-8CA57820FCA4@niven-jenkins.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.206] Content-Type: text/plain; charset="Windows-1252" Content-ID: <61C3FD143F43644FA43206D9357CFB33@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] CDNI Logging : access to CDNI Logging File once it is moved from Subscription to Archive in the Logging Feed X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 15 Oct 2013 08:52:59 -0000 Hi Ben, On 13 Oct 2013, at 09:27, Ben Niven-Jenkins wrote: > Francois, Colleagues, >=20 > My opinion is that if logs are advertised in the subscription or archive = feeds then they should be made available for download. I.e. we don't introd= uce new semantics that mean that if it is a CDN Logging feed then only entr= ies in the subscription feed should be made available and the archive feed = is "known" to probably point to dead links for log files. >=20 > Forcing a linkage between time covered by the subscription feed and tie a= nd the retention time a uCDN would like a dCDN to provide is not a good ide= a IMO as it limits the flexibility we give to implementations for no advant= age. >=20 > If a CDN wishes to remove old logs they should also remove the archive pa= ges that reference those logs (or never generate/advertise them in the firs= t place). Please help me understand your proposal: Say dCDN: * produced 24 Log files on 1 Oct , that were listed in an archive feed (ar= chive-1-oct) * produced 24 Log files on 2 Oct, that were listed in an archive feed (arc= hive-2-oct) * =85 * produced 24 Log files on 14 Oct, that were listed in an archive feed (a= rchive-14-oct) Say today is 15 October and the dCDN has agreed with uCDN to retain log fil= es for a period of one week. So the Subscription feed has a prev-archive link to archive-14-oct, that ha= s a prev-archive link to archive-13-oct, etc=85.. . But what happens in archive-7-oct? does it need to be modified so that it n= o longer has a prev-archive link? Or do you keep the prev-archive chaning forever and simply accept that some= files advertised in an archive feed are no longer accessible (ie if uCDN t= ries pull a file advertised in archive-3-oct it will received a 404).? I don't have a strong view on this topic but woudl like to document the cho= sen approach properly.=20 Cheers Francois > Ben >=20 >=20 > On 27 Sep 2013, at 14:15, Francois Le Faucheur (flefauch) wrote: >=20 >> Folks, >>=20 >> [as a co-author] >>=20 >> I'd like input on one of the very remaining open items in cdni-logging. >>=20 >> For memory, the CDNI Logging Feed allows a dCDN to advertise to the uCDN= which CDNI Logging Files can be retrieved by the uCDN from the dCDN. >> It is structured as an Archived ATOM feed, meaning that a sliding window= of currently available CDNI Logging files is advertised in a "Subscription= " document, and then, over time, the older Logging Files are moved to an "A= rchive" document and new Logging Files appear in the Subscription document. >>=20 >> There is currently an editor's note asking a question about what should = happen once a Logging File has been moved to an "archive": >> " >> [Editor's note: if a given Logging file is moved away from >> subscription document to an archive document, do we agree it may no >> longer be accessible to uCDN?] >> " >> I personally agree that the Logging File need not be made available for = download once it has moved away from the Subscripton document to the Archiv= e document. My rationale is that: >> * this is precisely the point of the Subscription document i.e. to indi= cate which files are currently downloadable and the server-side is then res= ponsible for ensuring it can serve these files (ie it has to retain them an= d be ready to serve them).=20 >> * it is not reasonable to expect that the server-side will make old Log= ging Files accessible forever >> * if the client-side wants to have a large window of time to pull Loggi= ng Files, then it needs to agree with the server-side and this period will = be used as the retention period in the subscripton file.=20 >>=20 >> Please let us know if you disagree/agree with that, so we can address th= at in the next rev (this has not been addressed in -06 posted today). >>=20 >> For memory, I think the current text already implies the above: >> " >> The server-side implementation MUST respond to any valid pull request >> by a client-side implementation for a CDNI Logging File published by >> the server-side in the subscription document of the CDNI Logging >> Feed.=20 >> " >> If we agree with the position above, we could also tweak the text to say= that the server-side MUST respond _and_ actually provide the Logging File = (ie responding 404 is not good). >>=20 >> Cheers >>=20 >> Francois >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 From ray.vanbrandenburg@tno.nl Tue Oct 15 02:24:16 2013 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 CF36D11E81BE for ; Tue, 15 Oct 2013 02:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oySDuSKn5i+9 for ; Tue, 15 Oct 2013 02:24:12 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id B947011E8120 for ; Tue, 15 Oct 2013 02:24:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.93,498,1378850400"; d="scan'208";a="15317295" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1a.tno.nl with ESMTP; 15 Oct 2013 11:24:04 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.91]) by EXC-CASHUB03.tsn.tno.nl ([134.221.225.222]) with mapi id 14.03.0123.003; Tue, 15 Oct 2013 11:23:34 +0200 From: "Brandenburg, R. (Ray) van" To: Ben Niven-Jenkins Thread-Topic: [CDNi] CDNI and byte-range requests Thread-Index: Ac6NF7WBCrwwUsXoTkKL13I1urBVJw7Yld+AAEMoc8A= Date: Tue, 15 Oct 2013 09:23:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] CDNI and byte-range requests X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 15 Oct 2013 09:24:17 -0000 Hi Ben, > -----Original Message----- > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > Sent: maandag 14 oktober 2013 5:10 > To: Brandenburg, R. (Ray) van > Cc: cdni@ietf.org > Subject: Re: [CDNi] CDNI and byte-range requests >=20 > Ray, >=20 > On 30 Jul 2013, at 12:27, Brandenburg, R. (Ray) van wrote: >=20 > > Hi all, > > > > As I'm not sure whether this should be part of the Redirection Interfac= e > document or the Framework document, let me just post this as a general > question to the list: > > > > To my knowledge, the current CDNI documents do not explicitly address > the case of HTTP Byte-range requests. Although in most cases byte-range > requests will function just as any other requests, I think there are some= cases > where byte-range requests warrant further attention. An example is the > Redirection interface. If a uCDN asks a dCDN to deliver a particular user > request (containing a byte range), and the dCDN answers positively, can t= he > uCDN assume that the dCDN accepts any future requests for the same file > with a different byte range? And if that is the case, is this default beh= avior or > do we need an explicit flag in the inter-CDN redirection request to indic= ate > the uCDN/dCDN's preference? > > > > To be clear: I don't think we need any new functionality to handle byte= - > range requests, but a few sentences in either the Framework or the RI > document might clear up any future uncertainty. >=20 > I don't see how this is any different to a sequence of non byte-range > requests. >=20 > It will likely depend on the behaviour of the client (and possibly whethe= r the > server closes the connection after each request if that drives a differen= t > client behaviour) as to where the client ends up going (uCDN or dCDN) whe= n > it makes a subsequent request. >=20 > Trying to say anything here may take us down the rat hole of trying to > describe client behaviour which we don't control. >=20 Let me give a practical example: Let's say the uCDN is hosting a 2gb TS fil= e. At some point it receives an incoming request for a particular byte rang= e within that file, let's say the first 10mb. For some reason the uCDN deci= des that it wants to redirect the request to a dCDN. The dCDN receives the = request. At that point it has to decide what to do: does it download the fu= ll 2gb file from the uCDN, or does it download just the first 10mb? Of cour= se it's fully up to internal logic in the dCDN to decide what it should do = here, however it does have an impact on the uCDN as well (potentially unnec= essary traffic reducing the effectiveness of the inter-CDN redirect). My qu= estion is, do we need to say anything about this case to help both the dCDN= and uCDN in making this decision?=20 Ray > Ben >=20 > > > > Best regards, > > > > Ray > > This e-mail and its contents are subject to the DISCLAIMER at > http://www.tno.nl/emaildisclaimer > > > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni From sleibrand@llnw.com Tue Oct 15 02:31:05 2013 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 5D45811E8175 for ; Tue, 15 Oct 2013 02:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvyv4UbMC6Jm for ; Tue, 15 Oct 2013 02:31:00 -0700 (PDT) Received: from exprod5og105.obsmtp.com (exprod5og105.obsmtp.com [64.18.0.180]) by ietfa.amsl.com (Postfix) with ESMTP id 1656E21E80BD for ; Tue, 15 Oct 2013 02:30:55 -0700 (PDT) Received: from mail-pa0-f53.google.com ([209.85.220.53]) (using TLSv1) by exprod5ob105.postini.com ([64.18.4.12]) with SMTP ID DSNKUl0LT8BcpvIqi/lxKLo9o3tvaZWEPXBW@postini.com; Tue, 15 Oct 2013 02:30:56 PDT Received: by mail-pa0-f53.google.com with SMTP id kq14so8696752pab.40 for ; Tue, 15 Oct 2013 02:30:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=c3A4lLrhoxuBibb0mQhw9Ju7gbPUhh/rhEZLCNOzRyM=; b=hrV43IjGSwlxrmen+DSlG8eqN9DPsZHWBzK2M7hUEIfqf7bdSQoo+e2/vbFQyPMfeT 7zQ/8d5NnXcvLgXTXSM2cyvg4fAysyhNW1Luw4eVrSezFhUTFJSrlM0y0JKDgc4JH4x+ 9YsITUrNQhM5HTXODqV1lp8nojgV9beFFrvGLaRvRU+LMsL3O/yZRnz+podCb/2yNMX6 11EUuYWUR/6TWsxc02zQwRDajHOnOpOi5MCl8hvKT/e7+4a6Fp3aaMoJfe84OMEc8AEZ DXsRF9NBd9MMwDEhsrFnc+LGTul++AAVA/FcnakNrS9csaIFJhF1jY9RvPMnEuHlSq23 y8MQ== X-Gm-Message-State: ALoCoQnGmj0y83P09idWlf6jT4pIEef6Hycet9JnN0M70fbPJ+QAfvzIprJzE1Dn04bIw4iLuCc+VXPJnFspA2UJ4IU4ThU2vbtZEAEIrEHvGHHjvZdkql+dteYQazZ/x2cjP2NFwlc7vurOvjjk9tFTADU6YRGBJQ== X-Received: by 10.66.158.72 with SMTP id ws8mr42676531pab.39.1381829455213; Tue, 15 Oct 2013 02:30:55 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.66.158.72 with SMTP id ws8mr42676526pab.39.1381829455098; Tue, 15 Oct 2013 02:30:55 -0700 (PDT) Received: by 10.68.30.41 with HTTP; Tue, 15 Oct 2013 02:30:55 -0700 (PDT) In-Reply-To: References: Date: Tue, 15 Oct 2013 02:30:55 -0700 Message-ID: From: Scott Leibrand To: "Brandenburg, R. (Ray) van" Content-Type: multipart/alternative; boundary=047d7bacc796cfcd0704e8c43da7 Cc: "cdni@ietf.org" Subject: Re: [CDNi] CDNI and byte-range requests X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 15 Oct 2013 09:31:05 -0000 --047d7bacc796cfcd0704e8c43da7 Content-Type: text/plain; charset=ISO-8859-1 This feature (partial object caching) is absolutely a requirement before we could think about offloading on-demand video traffic to a dCDN. If the dCDN downloads the entire file, that completely ruins the uCDN's efforts to do partial caching, and the resulting increase in cache use makes things worse than not using a dCDN at all. -Scott On Tue, Oct 15, 2013 at 2:23 AM, Brandenburg, R. (Ray) van < ray.vanbrandenburg@tno.nl> wrote: > Hi Ben, > > > -----Original Message----- > > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > > Sent: maandag 14 oktober 2013 5:10 > > To: Brandenburg, R. (Ray) van > > Cc: cdni@ietf.org > > Subject: Re: [CDNi] CDNI and byte-range requests > > > > Ray, > > > > On 30 Jul 2013, at 12:27, Brandenburg, R. (Ray) van wrote: > > > > > Hi all, > > > > > > As I'm not sure whether this should be part of the Redirection > Interface > > document or the Framework document, let me just post this as a general > > question to the list: > > > > > > To my knowledge, the current CDNI documents do not explicitly address > > the case of HTTP Byte-range requests. Although in most cases byte-range > > requests will function just as any other requests, I think there are > some cases > > where byte-range requests warrant further attention. An example is the > > Redirection interface. If a uCDN asks a dCDN to deliver a particular user > > request (containing a byte range), and the dCDN answers positively, can > the > > uCDN assume that the dCDN accepts any future requests for the same file > > with a different byte range? And if that is the case, is this default > behavior or > > do we need an explicit flag in the inter-CDN redirection request to > indicate > > the uCDN/dCDN's preference? > > > > > > To be clear: I don't think we need any new functionality to handle > byte- > > range requests, but a few sentences in either the Framework or the RI > > document might clear up any future uncertainty. > > > > I don't see how this is any different to a sequence of non byte-range > > requests. > > > > It will likely depend on the behaviour of the client (and possibly > whether the > > server closes the connection after each request if that drives a > different > > client behaviour) as to where the client ends up going (uCDN or dCDN) > when > > it makes a subsequent request. > > > > Trying to say anything here may take us down the rat hole of trying to > > describe client behaviour which we don't control. > > > > Let me give a practical example: Let's say the uCDN is hosting a 2gb TS > file. At some point it receives an incoming request for a particular byte > range within that file, let's say the first 10mb. For some reason the uCDN > decides that it wants to redirect the request to a dCDN. The dCDN receives > the request. At that point it has to decide what to do: does it download > the full 2gb file from the uCDN, or does it download just the first 10mb? > Of course it's fully up to internal logic in the dCDN to decide what it > should do here, however it does have an impact on the uCDN as well > (potentially unnecessary traffic reducing the effectiveness of the > inter-CDN redirect). My question is, do we need to say anything about this > case to help both the dCDN and uCDN in making this decision? > > Ray > > > Ben > > > > > > > > Best regards, > > > > > > Ray > > > This e-mail and its contents are subject to the DISCLAIMER at > > http://www.tno.nl/emaildisclaimer > > > > > > _______________________________________________ > > > CDNi mailing list > > > CDNi@ietf.org > > > https://www.ietf.org/mailman/listinfo/cdni > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > --047d7bacc796cfcd0704e8c43da7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This feature (partial object caching) is absolutely a requ= irement before we could think about offloading on-demand video traffic to a= dCDN. =A0If the dCDN downloads the entire file, that completely ruins the = uCDN's efforts to do partial caching, and the resulting increase in cac= he use makes things worse than not using a dCDN at all.

-Scott


On Tue, Oct 15, 2013 at 2:23 AM, Brandenburg, R. (Ray) = van <ray.vanbrandenburg@tno.nl> wrote:
Hi Ben,

> -----Original Message-----
> From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]
> Sent: maandag 14 oktober 2013 5:10
> To: Brandenburg, R. (Ray) van
> Cc: cdni@ietf.org
> Subject: Re: [CDNi] CDNI and byte-range requests
>
> Ray,
>
> On 30 Jul 2013, at 12:27, Brandenburg, R. (Ray) van wrote:
>
> > Hi all,
> >
> > As I'm not sure whether this should be part of the Redirectio= n Interface
> document or the Framework document, let me just post this as a general=
> question to the list:
> >
> > To my knowledge, the current CDNI documents do not explicitly add= ress
> the case of HTTP Byte-range requests. Although in most cases byte-rang= e
> requests will function just as any other requests, I think there are s= ome cases
> where byte-range requests warrant further attention. An example is the=
> Redirection interface. If a uCDN asks a dCDN to deliver a particular u= ser
> request (containing a byte range), and the dCDN answers positively, ca= n the
> uCDN assume that the dCDN accepts any future requests for the same fil= e
> with a different byte range? And if that is the case, is this default = behavior or
> do we need an explicit flag in the inter-CDN redirection request to in= dicate
> the uCDN/dCDN's preference?
> >
> > To be clear: I don't think we need any new functionality to h= andle byte-
> range requests, but a few sentences in either the Framework or the RI<= br> > document might clear up any future uncertainty.
>
> I don't see how this is any different to a sequence of non byte-ra= nge
> requests.
>
> It will likely depend on the behaviour of the client (and possibly whe= ther the
> server closes the connection after each request if that drives a diffe= rent
> client behaviour) as to where the client ends up going (uCDN or dCDN) = when
> it makes a subsequent request.
>
> Trying to say anything here may take us down the rat hole of trying to=
> describe client behaviour which we don't control.
>

Let me give a practical example: Let's say the uCDN is host= ing a 2gb TS file. At some point it receives an incoming request for a part= icular byte range within that file, let's say the first 10mb. For some = reason the uCDN decides that it wants to redirect the request to a dCDN. Th= e dCDN receives the request. At that point it has to decide what to do: doe= s it download the full 2gb file from the uCDN, or does it download just the= first 10mb? Of course it's fully up to internal logic in the dCDN to d= ecide what it should do here, however it does have an impact on the uCDN as= well (potentially unnecessary traffic reducing the effectiveness of the in= ter-CDN redirect). My question is, do we need to say anything about this ca= se to help both the dCDN and uCDN in making this decision?

Ray

> Ben
>
> >
> > Best regards,
> >
> > Ray
> > This e-mail and its contents are subject to the DISCLAIMER at
> http:/= /www.tno.nl/emaildisclaimer
> >
> > _______________________________________________
> > CDNi mailing list
> > CDNi@ietf.org
> > https://www.ietf.org/mailman/listinfo/cdni

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

--047d7bacc796cfcd0704e8c43da7-- From ben@niven-jenkins.co.uk Tue Oct 15 03:18:20 2013 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 0845A11E81C0 for ; Tue, 15 Oct 2013 03:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pri5ob13iheM for ; Tue, 15 Oct 2013 03:18:15 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 19AB021F9D31 for ; Tue, 15 Oct 2013 03:18:14 -0700 (PDT) Received: from dab-rcn1-h-28-3.dab.02.net ([82.132.245.82] helo=[10.31.198.16]) by mail4.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1VW1hc-00086u-UW; Tue, 15 Oct 2013 11:18:13 +0100 References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <8B41CEB7-0D10-47F2-90A7-2D5AEE11CF7F@niven-jenkins.co.uk> X-Mailer: iPhone Mail (11A501) From: Ben Niven-Jenkins Date: Tue, 15 Oct 2013 11:17:11 +0100 To: "Brandenburg, R. (Ray) van" X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "cdni@ietf.org" Subject: Re: [CDNi] CDNI and byte-range requests X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 15 Oct 2013 10:18:20 -0000 Ray, I'm not sure it warrants special mention, for example why is it any differen= t to a client doing a GET for the complete resource and terminating the conn= ection early.=20 There are many situations that may lead to some form of caching inefficiency= depending on the circumstances, client behaviour and the feature set of eac= h CDN.=20 I don't think it is feasible to document them all and I don't see byte range= requests as being a particularly special case worthy of specific mention.=20= Ben > On 15 Oct 2013, at 10:23, "Brandenburg, R. (Ray) van" wrote: >=20 > Hi Ben, >=20 >> -----Original Message----- >> From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] >> Sent: maandag 14 oktober 2013 5:10 >> To: Brandenburg, R. (Ray) van >> Cc: cdni@ietf.org >> Subject: Re: [CDNi] CDNI and byte-range requests >>=20 >> Ray, >>=20 >>> On 30 Jul 2013, at 12:27, Brandenburg, R. (Ray) van wrote: >>>=20 >>> Hi all, >>>=20 >>> As I'm not sure whether this should be part of the Redirection Interface= >> document or the Framework document, let me just post this as a general >> question to the list: >>>=20 >>> To my knowledge, the current CDNI documents do not explicitly address >> the case of HTTP Byte-range requests. Although in most cases byte-range >> requests will function just as any other requests, I think there are some= cases >> where byte-range requests warrant further attention. An example is the >> Redirection interface. If a uCDN asks a dCDN to deliver a particular user= >> request (containing a byte range), and the dCDN answers positively, can t= he >> uCDN assume that the dCDN accepts any future requests for the same file >> with a different byte range? And if that is the case, is this default beh= avior or >> do we need an explicit flag in the inter-CDN redirection request to indic= ate >> the uCDN/dCDN's preference? >>>=20 >>> To be clear: I don't think we need any new functionality to handle byte-= >> range requests, but a few sentences in either the Framework or the RI >> document might clear up any future uncertainty. >>=20 >> I don't see how this is any different to a sequence of non byte-range >> requests. >>=20 >> It will likely depend on the behaviour of the client (and possibly whethe= r the >> server closes the connection after each request if that drives a differen= t >> client behaviour) as to where the client ends up going (uCDN or dCDN) whe= n >> it makes a subsequent request. >>=20 >> Trying to say anything here may take us down the rat hole of trying to >> describe client behaviour which we don't control. >=20 > Let me give a practical example: Let's say the uCDN is hosting a 2gb TS fi= le. At some point it receives an incoming request for a particular byte rang= e within that file, let's say the first 10mb. For some reason the uCDN decid= es that it wants to redirect the request to a dCDN. The dCDN receives the re= quest. At that point it has to decide what to do: does it download the full 2= gb file from the uCDN, or does it download just the first 10mb? Of course it= 's fully up to internal logic in the dCDN to decide what it should do here, h= owever it does have an impact on the uCDN as well (potentially unnecessary t= raffic reducing the effectiveness of the inter-CDN redirect). My question is= , do we need to say anything about this case to help both the dCDN and uCDN i= n making this decision?=20 >=20 > Ray >=20 >> Ben >>=20 >>>=20 >>> Best regards, >>>=20 >>> Ray >>> This e-mail and its contents are subject to the DISCLAIMER at >> http://www.tno.nl/emaildisclaimer >>>=20 >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >=20 From ben@niven-jenkins.co.uk Tue Oct 15 03:22:39 2013 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 8DA7E11E81C4 for ; Tue, 15 Oct 2013 03:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTh30NGAHjtw for ; Tue, 15 Oct 2013 03:22:24 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 60A5011E81C1 for ; Tue, 15 Oct 2013 03:22:19 -0700 (PDT) Received: from dab-rcn1-h-28-10.dab.02.net ([82.132.247.193] helo=[10.31.198.16]) by smtp02.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1VW1lY-0003mR-GK; Tue, 15 Oct 2013 11:22:18 +0100 References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-EB05F8B4-2FDF-4BBC-BA1B-FD70190BB173 Content-Transfer-Encoding: 7bit Message-Id: <7B33FC92-AEB5-46E2-9DB4-AE5D976D07B9@niven-jenkins.co.uk> X-Mailer: iPhone Mail (11A501) From: Ben Niven-Jenkins Date: Tue, 15 Oct 2013 11:21:16 +0100 To: Scott Leibrand X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "cdni@ietf.org" Subject: Re: [CDNi] CDNI and byte-range requests X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 15 Oct 2013 10:22:39 -0000 --Apple-Mail-EB05F8B4-2FDF-4BBC-BA1B-FD70190BB173 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Scott, What two CDNs may agree is a minimum feature set and what we need to specify= in the RFCs are separate things IMO.=20 Partial caching may be considered a required feature for dCDNs but I don't s= ee it as within scope for the Framework or Redirection Interface documents t= o mandate that as it is not related to either IMO.=20 Ben > On 15 Oct 2013, at 10:30, Scott Leibrand wrote: >=20 > This feature (partial object caching) is absolutely a requirement before w= e could think about offloading on-demand video traffic to a dCDN. If the dC= DN downloads the entire file, that completely ruins the uCDN's efforts to do= partial caching, and the resulting increase in cache use makes things worse= than not using a dCDN at all. >=20 > -Scott >=20 >=20 >> On Tue, Oct 15, 2013 at 2:23 AM, Brandenburg, R. (Ray) van wrote: >> Hi Ben, >>=20 >> > -----Original Message----- >> > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] >> > Sent: maandag 14 oktober 2013 5:10 >> > To: Brandenburg, R. (Ray) van >> > Cc: cdni@ietf.org >> > Subject: Re: [CDNi] CDNI and byte-range requests >> > >> > Ray, >> > >> > On 30 Jul 2013, at 12:27, Brandenburg, R. (Ray) van wrote: >> > >> > > Hi all, >> > > >> > > As I'm not sure whether this should be part of the Redirection Interf= ace >> > document or the Framework document, let me just post this as a general >> > question to the list: >> > > >> > > To my knowledge, the current CDNI documents do not explicitly address= >> > the case of HTTP Byte-range requests. Although in most cases byte-range= >> > requests will function just as any other requests, I think there are so= me cases >> > where byte-range requests warrant further attention. An example is the >> > Redirection interface. If a uCDN asks a dCDN to deliver a particular us= er >> > request (containing a byte range), and the dCDN answers positively, can= the >> > uCDN assume that the dCDN accepts any future requests for the same file= >> > with a different byte range? And if that is the case, is this default b= ehavior or >> > do we need an explicit flag in the inter-CDN redirection request to ind= icate >> > the uCDN/dCDN's preference? >> > > >> > > To be clear: I don't think we need any new functionality to handle by= te- >> > range requests, but a few sentences in either the Framework or the RI >> > document might clear up any future uncertainty. >> > >> > I don't see how this is any different to a sequence of non byte-range >> > requests. >> > >> > It will likely depend on the behaviour of the client (and possibly whet= her the >> > server closes the connection after each request if that drives a differ= ent >> > client behaviour) as to where the client ends up going (uCDN or dCDN) w= hen >> > it makes a subsequent request. >> > >> > Trying to say anything here may take us down the rat hole of trying to >> > describe client behaviour which we don't control. >> > >>=20 >> Let me give a practical example: Let's say the uCDN is hosting a 2gb TS f= ile. At some point it receives an incoming request for a particular byte ran= ge within that file, let's say the first 10mb. For some reason the uCDN deci= des that it wants to redirect the request to a dCDN. The dCDN receives the r= equest. At that point it has to decide what to do: does it download the full= 2gb file from the uCDN, or does it download just the first 10mb? Of course i= t's fully up to internal logic in the dCDN to decide what it should do here,= however it does have an impact on the uCDN as well (potentially unnecessary= traffic reducing the effectiveness of the inter-CDN redirect). My question i= s, do we need to say anything about this case to help both the dCDN and uCDN= in making this decision? >>=20 >> Ray >>=20 >> > Ben >> > >> > > >> > > Best regards, >> > > >> > > Ray >> > > This e-mail and its contents are subject to the DISCLAIMER at >> > http://www.tno.nl/emaildisclaimer >> > > >> > > _______________________________________________ >> > > CDNi mailing list >> > > CDNi@ietf.org >> > > https://www.ietf.org/mailman/listinfo/cdni >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 --Apple-Mail-EB05F8B4-2FDF-4BBC-BA1B-FD70190BB173 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Scott,

What t= wo CDNs may agree is a minimum feature set and what we need to specify in th= e RFCs are separate things IMO. 

Partial cachi= ng may be considered a required feature for dCDNs but I don't see it as with= in scope for the Framework or Redirection Interface documents to mandate tha= t as it is not related to either IMO. 

Ben

On 15 Oct 2013, at 10:30, Scott Leibrand <sleibrand@llnw.com> wrote:

This feature (partial object caching) i= s absolutely a requirement before we could think about offloading on-demand v= ideo traffic to a dCDN.  If the dCDN downloads the entire file, that co= mpletely ruins the uCDN's efforts to do partial caching, and the resulting i= ncrease in cache use makes things worse than not using a dCDN at all.

-Scott


On Tue, Oct 15, 2013 at 2:23 AM, Brandenburg, R. (Ray) va= n <ray.vanbrandenburg@tno.nl> wrote:
Hi Ben,

> -----Original Message-----
> From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]
> Sent: maandag 14 oktober 2013 5:10
> To: Brandenburg, R. (Ray) van
> Cc: cdni@ietf.org
> Subject: Re: [CDNi] CDNI and byte-range requests
>
> Ray,
>
> On 30 Jul 2013, at 12:27, Brandenburg, R. (Ray) van wrote:
>
> > Hi all,
> >
> > As I'm not sure whether this should be part of the Redirection Int= erface
> document or the Framework document, let me just post this as a general<= br> > question to the list:
> >
> > To my knowledge, the current CDNI documents do not explicitly addr= ess
> the case of HTTP Byte-range requests. Although in most cases byte-range=
> requests will function just as any other requests, I think there are so= me cases
> where byte-range requests warrant further attention. An example is the<= br> > Redirection interface. If a uCDN asks a dCDN to deliver a particular us= er
> request (containing a byte range), and the dCDN answers positively, can= the
> uCDN assume that the dCDN accepts any future requests for the same file=
> with a different byte range? And if that is the case, is this default b= ehavior or
> do we need an explicit flag in the inter-CDN redirection request to ind= icate
> the uCDN/dCDN's preference?
> >
> > To be clear: I don't think we need any new functionality to handle= byte-
> range requests, but a few sentences in either the Framework or the RI > document might clear up any future uncertainty.
>
> I don't see how this is any different to a sequence of non byte-range > requests.
>
> It will likely depend on the behaviour of the client (and possibly whet= her the
> server closes the connection after each request if that drives a differ= ent
> client behaviour) as to where the client ends up going (uCDN or dCDN) w= hen
> it makes a subsequent request.
>
> Trying to say anything here may take us down the rat hole of trying to<= br> > describe client behaviour which we don't control.
>

Let me give a practical example: Let's say the uCDN is hosting a= 2gb TS file. At some point it receives an incoming request for a particular= byte range within that file, let's say the first 10mb. For some reason the u= CDN decides that it wants to redirect the request to a dCDN. The dCDN receiv= es the request. At that point it has to decide what to do: does it download t= he full 2gb file from the uCDN, or does it download just the first 10mb? Of c= ourse it's fully up to internal logic in the dCDN to decide what it should d= o here, however it does have an impact on the uCDN as well (potentially unne= cessary traffic reducing the effectiveness of the inter-CDN redirect). My qu= estion is, do we need to say anything about this case to help both the dCDN a= nd uCDN in making this decision?

Ray

> Ben
>
> >
> > Best regards,
> >
> > Ray
> > This e-mail and its contents are subject to the DISCLAIMER at
> http://= www.tno.nl/emaildisclaimer
> >
> > _______________________________________________
> > CDNi mailing list
> > CDNi@ietf.org
> > https://www.ietf.org/mailman/listinfo/cdni

_______________________________________________
CDNi mailing list
CDNi@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/cdni

= --Apple-Mail-EB05F8B4-2FDF-4BBC-BA1B-FD70190BB173-- From ben@niven-jenkins.co.uk Tue Oct 15 03:23:40 2013 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 ED50721F9BB1 for ; Tue, 15 Oct 2013 03:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOx4tnAxr9GF for ; Tue, 15 Oct 2013 03:23:36 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id B4CB311E81C0 for ; Tue, 15 Oct 2013 03:23:34 -0700 (PDT) Received: from dab-rcn1-h-28-10.dab.02.net ([82.132.247.193] helo=[10.31.198.16]) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1VW1mk-0006V9-Kf; Tue, 15 Oct 2013 11:23:33 +0100 References: <82E8974B-BD12-4B4B-871B-8CA57820FCA4@niven-jenkins.co.uk> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11A501) From: Ben Niven-Jenkins Date: Tue, 15 Oct 2013 11:23:19 +0100 To: "Francois Le Faucheur (flefauch)" X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "cdni@ietf.org" Subject: Re: [CDNi] CDNI Logging : access to CDNI Logging File once it is moved from Subscription to Archive in the Logging Feed X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 15 Oct 2013 10:23:41 -0000 Francois, I believe the practice is to remove the prev-archive link in the (now) last a= rchive feed page when previously last archive feed page is no longer availab= le.=20 Ben > On 15 Oct 2013, at 09:52, "Francois Le Faucheur (flefauch)" wrote: >=20 > Hi Ben, >=20 > On 13 Oct 2013, at 09:27, Ben Niven-Jenkins > wrote: >=20 >> Francois, Colleagues, >>=20 >> My opinion is that if logs are advertised in the subscription or archive f= eeds then they should be made available for download. I.e. we don't introduc= e new semantics that mean that if it is a CDN Logging feed then only entries= in the subscription feed should be made available and the archive feed is "= known" to probably point to dead links for log files. >>=20 >> Forcing a linkage between time covered by the subscription feed and tie a= nd the retention time a uCDN would like a dCDN to provide is not a good idea= IMO as it limits the flexibility we give to implementations for no advantag= e. >>=20 >> If a CDN wishes to remove old logs they should also remove the archive pa= ges that reference those logs (or never generate/advertise them in the first= place). >=20 > Please help me understand your proposal: >=20 > Say dCDN: > * produced 24 Log files on 1 Oct , that were listed in an archive feed (= archive-1-oct) > * produced 24 Log files on 2 Oct, that were listed in an archive feed (= archive-2-oct) > * =E2=80=A6 > * produced 24 Log files on 14 Oct, that were listed in an archive feed= (archive-14-oct) >=20 > Say today is 15 October and the dCDN has agreed with uCDN to retain log fi= les for a period of one week. >=20 > So the Subscription feed has a prev-archive link to archive-14-oct, that h= as a prev-archive link to archive-13-oct, etc=E2=80=A6.. . > But what happens in archive-7-oct? does it need to be modified so that it n= o longer has a prev-archive link? > Or do you keep the prev-archive chaning forever and simply accept that som= e files advertised in an archive feed are no longer accessible (ie if uCDN t= ries pull a file advertised in archive-3-oct it will received a 404).? >=20 > I don't have a strong view on this topic but woudl like to document the ch= osen approach properly.=20 >=20 > Cheers >=20 > Francois >=20 >> Ben >>=20 >>=20 >>> On 27 Sep 2013, at 14:15, Francois Le Faucheur (flefauch) wrote: >>>=20 >>> Folks, >>>=20 >>> [as a co-author] >>>=20 >>> I'd like input on one of the very remaining open items in cdni-logging. >>>=20 >>> For memory, the CDNI Logging Feed allows a dCDN to advertise to the uCDN= which CDNI Logging Files can be retrieved by the uCDN from the dCDN. >>> It is structured as an Archived ATOM feed, meaning that a sliding window= of currently available CDNI Logging files is advertised in a "Subscription"= document, and then, over time, the older Logging Files are moved to an "Arc= hive" document and new Logging Files appear in the Subscription document. >>>=20 >>> There is currently an editor's note asking a question about what should h= appen once a Logging File has been moved to an "archive": >>> " >>> [Editor's note: if a given Logging file is moved away from >>> subscription document to an archive document, do we agree it may no >>> longer be accessible to uCDN?] >>> " >>> I personally agree that the Logging File need not be made available for d= ownload once it has moved away from the Subscripton document to the Archive d= ocument. My rationale is that: >>> * this is precisely the point of the Subscription document i.e. to in= dicate which files are currently downloadable and the server-side is then re= sponsible for ensuring it can serve these files (ie it has to retain them an= d be ready to serve them).=20 >>> * it is not reasonable to expect that the server-side will make old L= ogging Files accessible forever >>> * if the client-side wants to have a large window of time to pull Log= ging Files, then it needs to agree with the server-side and this period will= be used as the retention period in the subscripton file.=20 >>>=20 >>> Please let us know if you disagree/agree with that, so we can address th= at in the next rev (this has not been addressed in -06 posted today). >>>=20 >>> For memory, I think the current text already implies the above: >>> " >>> The server-side implementation MUST respond to any valid pull request >>> by a client-side implementation for a CDNI Logging File published by >>> the server-side in the subscription document of the CDNI Logging >>> Feed.=20 >>> " >>> If we agree with the position above, we could also tweak the text to say= that the server-side MUST respond _and_ actually provide the Logging File (= ie responding 404 is not good). >>>=20 >>> Cheers >>>=20 >>> Francois >>>=20 >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >=20 From sleibrand@llnw.com Tue Oct 15 04:15:39 2013 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 14C5821E80BB for ; Tue, 15 Oct 2013 04:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7vgNvlNlUY4 for ; Tue, 15 Oct 2013 04:15:27 -0700 (PDT) Received: from exprod5og106.obsmtp.com (exprod5og106.obsmtp.com [64.18.0.182]) by ietfa.amsl.com (Postfix) with ESMTP id EE07911E81D9 for ; Tue, 15 Oct 2013 04:15:26 -0700 (PDT) Received: from mail-pb0-f43.google.com ([209.85.160.43]) (using TLSv1) by exprod5ob106.postini.com ([64.18.4.12]) with SMTP ID DSNKUl0jztWdqqkIfuCoa1GDl2JNMrY0cCYh@postini.com; Tue, 15 Oct 2013 04:15:26 PDT Received: by mail-pb0-f43.google.com with SMTP id md4so8548450pbc.30 for ; Tue, 15 Oct 2013 04:15:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bQdmkekPQrYOLnBW3UmhW7ni3pJvNhpLCWniFeBAPic=; b=ZOE7wJU8gfB6pVuu10bSrKP4skoW5OzmGhtsU76QIe7r1sKeWloVQZcw+E511iRVJF plEFwdjmtQlzRx4uMWqTb+kyX4alSVyaG86oANIk9Z7sxalNqISyGF8jKOD61K+ZPHEF yuew1AM+lIoDNG8joZHCyRQa8oGxi8eZ628nzfe8x/vdxl5k6+Zt4bYF3n5UwwQvHNHa APD8i4TA2MG+rJ2s45/pXjOhz+R/gj5bk7SBBLmdoglzMm4Ahut7BdmyutnKx9OBlMTs 6CN/dhzGycdwhVPMQaGV/OOIb1UkbIpIIWrMHkA4FtGSa2+IcE0Gnk1a2kIuG2LpAdsM F55A== X-Gm-Message-State: ALoCoQnnAyvlsMHzP9HHN4ROK0C/gOI8o+ifXTzmU5r8vXr8OHctXnY726nCA20+3t0lKxMvPDWPaFMumwYYh46EGF0YFMTIcp9ZaMGx/mezXK72l18n2qwnRiez6rnqEmoBiv3/5KR5LOvZvbbIv1UMiQYJhhF/dQ== X-Received: by 10.67.1.101 with SMTP id bf5mr42053696pad.50.1381835725754; Tue, 15 Oct 2013 04:15:25 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.67.1.101 with SMTP id bf5mr42053674pad.50.1381835725524; Tue, 15 Oct 2013 04:15:25 -0700 (PDT) Received: by 10.68.30.41 with HTTP; Tue, 15 Oct 2013 04:15:25 -0700 (PDT) In-Reply-To: <8B41CEB7-0D10-47F2-90A7-2D5AEE11CF7F@niven-jenkins.co.uk> References: <8B41CEB7-0D10-47F2-90A7-2D5AEE11CF7F@niven-jenkins.co.uk> Date: Tue, 15 Oct 2013 04:15:25 -0700 Message-ID: From: Scott Leibrand To: Ben Niven-Jenkins Content-Type: multipart/alternative; boundary=047d7b15ac238ef03604e8c5b373 Cc: "cdni@ietf.org" Subject: Re: [CDNi] CDNI and byte-range requests X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 15 Oct 2013 11:15:39 -0000 --047d7b15ac238ef03604e8c5b373 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 15, 2013 at 3:17 AM, Ben Niven-Jenkins wrote: > Ray, > > I'm not sure it warrants special mention, I'm not sure it does, but... > for example why is it any different to a client doing a GET for the > complete resource and terminating the connection early. > Because clients only request content they actually want. In particular, if part of a video is unpopular, clients will tend not to request it. But a dCDN that requests the full file will ask for it anyway, wrecking the upstream's ability to cache just the popular bits. > > There are many situations that may lead to some form of caching > inefficiency depending on the circumstances, client behaviour and the > feature set of each CDN. > > I don't think it is feasible to document them all and I don't see byte > range requests as being a particularly special case worthy of specific > mention. > I don't disagree there. In my experience most CDN equipment vendors support some form of partial caching, and there is no particular reason they have to do it the same way, as long as some sort of sensible behavior is configurable. -Scott > > Ben > > > On 15 Oct 2013, at 10:23, "Brandenburg, R. (Ray) van" < > ray.vanbrandenburg@tno.nl> wrote: > > > > Hi Ben, > > > >> -----Original Message----- > >> From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > >> Sent: maandag 14 oktober 2013 5:10 > >> To: Brandenburg, R. (Ray) van > >> Cc: cdni@ietf.org > >> Subject: Re: [CDNi] CDNI and byte-range requests > >> > >> Ray, > >> > >>> On 30 Jul 2013, at 12:27, Brandenburg, R. (Ray) van wrote: > >>> > >>> Hi all, > >>> > >>> As I'm not sure whether this should be part of the Redirection > Interface > >> document or the Framework document, let me just post this as a general > >> question to the list: > >>> > >>> To my knowledge, the current CDNI documents do not explicitly address > >> the case of HTTP Byte-range requests. Although in most cases byte-range > >> requests will function just as any other requests, I think there are > some cases > >> where byte-range requests warrant further attention. An example is the > >> Redirection interface. If a uCDN asks a dCDN to deliver a particular > user > >> request (containing a byte range), and the dCDN answers positively, can > the > >> uCDN assume that the dCDN accepts any future requests for the same file > >> with a different byte range? And if that is the case, is this default > behavior or > >> do we need an explicit flag in the inter-CDN redirection request to > indicate > >> the uCDN/dCDN's preference? > >>> > >>> To be clear: I don't think we need any new functionality to handle > byte- > >> range requests, but a few sentences in either the Framework or the RI > >> document might clear up any future uncertainty. > >> > >> I don't see how this is any different to a sequence of non byte-range > >> requests. > >> > >> It will likely depend on the behaviour of the client (and possibly > whether the > >> server closes the connection after each request if that drives a > different > >> client behaviour) as to where the client ends up going (uCDN or dCDN) > when > >> it makes a subsequent request. > >> > >> Trying to say anything here may take us down the rat hole of trying to > >> describe client behaviour which we don't control. > > > > Let me give a practical example: Let's say the uCDN is hosting a 2gb TS > file. At some point it receives an incoming request for a particular byte > range within that file, let's say the first 10mb. For some reason the uCDN > decides that it wants to redirect the request to a dCDN. The dCDN receives > the request. At that point it has to decide what to do: does it download > the full 2gb file from the uCDN, or does it download just the first 10mb? > Of course it's fully up to internal logic in the dCDN to decide what it > should do here, however it does have an impact on the uCDN as well > (potentially unnecessary traffic reducing the effectiveness of the > inter-CDN redirect). My question is, do we need to say anything about this > case to help both the dCDN and uCDN in making this decision? > > > > Ray > > > >> Ben > >> > >>> > >>> Best regards, > >>> > >>> Ray > >>> This e-mail and its contents are subject to the DISCLAIMER at > >> http://www.tno.nl/emaildisclaimer > >>> > >>> _______________________________________________ > >>> CDNi mailing list > >>> CDNi@ietf.org > >>> https://www.ietf.org/mailman/listinfo/cdni > > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > --047d7b15ac238ef03604e8c5b373 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Oct 15, 2013 at 3:17 AM, Ben Niven-Jenkins <ben@niven-jenkins.co.uk> wrote:
Ray,

I'm not sure it warrants special mention,

I'm not sure it does, but...
=A0
for example why is it any different to a client doing a GET for the comple= te resource and terminating the connection early.

=
Because clients only request content they actually want. =A0In p= articular, if part of a video is unpopular, clients will tend not to reques= t it. =A0But a dCDN that requests the full file will ask for it anyway, wre= cking the upstream's ability to cache just the popular bits.
=A0

There are many situations that may lead to some form of caching inefficienc= y depending on the circumstances, client behaviour and the feature set of e= ach CDN.

I don't think it is feasible to document them all and I don't see b= yte range requests as being a particularly special case worthy of specific = mention.

I don't disagree there. = =A0In my experience most CDN equipment vendors support some form of partial= caching, and there is no particular reason they have to do it the same way= , as long as some sort of sensible behavior is configurable.

-Scott
=A0

Ben

> On 15 Oct 2013, at 10:23, "Brandenburg, R. (Ray) van" <ray.vanbrandenburg@tno.nl>= ; wrote:
>
> Hi Ben,
>
>> -----Original Message-----
>> From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]
>> Sent: maandag 14 oktober 2013 5:10
>> To: Brandenburg, R. (Ray) van
>> Cc: cdni@ietf.org
>> Subject: Re: [CDNi] CDNI and byte-range requests
>>
>> Ray,
>>
>>> On 30 Jul 2013, at 12:27, Brandenburg, R. (Ray) van wrote:
>>>
>>> Hi all,
>>>
>>> As I'm not sure whether this should be part of the Redirec= tion Interface
>> document or the Framework document, let me just post this as a gen= eral
>> question to the list:
>>>
>>> To my knowledge, the current CDNI documents do not explicitly = address
>> the case of HTTP Byte-range requests. Although in most cases byte-= range
>> requests will function just as any other requests, I think there a= re some cases
>> where byte-range requests warrant further attention. An example is= the
>> Redirection interface. If a uCDN asks a dCDN to deliver a particul= ar user
>> request (containing a byte range), and the dCDN answers positively= , can the
>> uCDN assume that the dCDN accepts any future requests for the same= file
>> with a different byte range? And if that is the case, is this defa= ult behavior or
>> do we need an explicit flag in the inter-CDN redirection request t= o indicate
>> the uCDN/dCDN's preference?
>>>
>>> To be clear: I don't think we need any new functionality t= o handle byte-
>> range requests, but a few sentences in either the Framework or the= RI
>> document might clear up any future uncertainty.
>>
>> I don't see how this is any different to a sequence of non byt= e-range
>> requests.
>>
>> It will likely depend on the behaviour of the client (and possibly= whether the
>> server closes the connection after each request if that drives a d= ifferent
>> client behaviour) as to where the client ends up going (uCDN or dC= DN) when
>> it makes a subsequent request.
>>
>> Trying to say anything here may take us down the rat hole of tryin= g to
>> describe client behaviour which we don't control.
>
> Let me give a practical example: Let's say the uCDN is hosting a 2= gb TS file. At some point it receives an incoming request for a particular = byte range within that file, let's say the first 10mb. For some reason = the uCDN decides that it wants to redirect the request to a dCDN. The dCDN = receives the request. At that point it has to decide what to do: does it do= wnload the full 2gb file from the uCDN, or does it download just the first = 10mb? Of course it's fully up to internal logic in the dCDN to decide w= hat it should do here, however it does have an impact on the uCDN as well (= potentially unnecessary traffic reducing the effectiveness of the inter-CDN= redirect). My question is, do we need to say anything about this case to h= elp both the dCDN and uCDN in making this decision?
>
> Ray
>
>> Ben
>>
>>>
>>> Best regards,
>>>
>>> Ray
>>> This e-mail and its contents are subject to the DISCLAIMER at<= br> >> ht= tp://www.tno.nl/emaildisclaimer
>>>
>>> _______________________________________________
>>> CDNi mailing list
>>> CDNi@ietf.org
>>> https://www.ietf.org/mailman/listinfo/cdni
>
_______________________________________________
CDNi mailing list
CDNi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/cdni

--047d7b15ac238ef03604e8c5b373-- From flefauch@cisco.com Tue Oct 15 05:41:11 2013 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 8C11C11E81DD for ; Tue, 15 Oct 2013 05:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.538 X-Spam-Level: X-Spam-Status: No, score=-10.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zyALBo1Ec-I2 for ; Tue, 15 Oct 2013 05:41:05 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5B44811E81E4 for ; Tue, 15 Oct 2013 05:40:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11662; q=dns/txt; s=iport; t=1381840859; x=1383050459; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=eh3+gG81A5cB/FgEchdtCBVKwyilnGI/0SyhEjsj8b4=; b=O55QkxElvNNysMRui3YLPErnRKAmZeMJRteBe3nweKfwqvdqNyQQL9uH 4F/vHzhD9//jucz7gFHziOH3CToeKM/YeT356euD3ZUV/C+7ay7xDOpjH hZ6qG8ab2teqWxMpTv7N9EMXQXKBmvexgf8sprl9s5o5GUICbh++idt3z U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAH82XVKtJXG9/2dsb2JhbABagwc4UsIhgSIWdIIlAQEBAwEBAQFrCwUHBAIBCA4DBAEBAQodBycLFAkIAgQBDQUIh3gGDL1HjhGBCC0EBwaDGYEGA4kEoQKDJIFwOQ X-IronPort-AV: E=Sophos;i="4.93,498,1378857600"; d="scan'208,217";a="272070419" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 15 Oct 2013 12:40:58 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9FCewWP022202 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Oct 2013 12:40:58 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.33]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Tue, 15 Oct 2013 07:40:58 -0500 From: "Francois Le Faucheur (flefauch)" To: Scott Leibrand , Jan Seedorf Thread-Topic: [CDNi] CDNI and byte-range requests Thread-Index: AQHOyaPLPvZrSd8NIUuiMUsJdkIDMQ== Date: Tue, 15 Oct 2013 12:40:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.206] Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D0BB731AFxmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] CDNI and byte-range requests X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 15 Oct 2013 12:41:11 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D0BB731AFxmbrcdx10ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Scott, Jan, and all, On 15 Oct 2013, at 11:30, Scott Leibrand > wrote: This feature (partial object caching) is absolutely a requirement before we= could think about offloading on-demand video traffic to a dCDN. If the dC= DN downloads the entire file, that completely ruins the uCDN's efforts to d= o partial caching, and the resulting increase in cache use makes things wor= se than not using a dCDN at all. Then perhaps it would make sense to include something like "Partial Object = Caching" in the set of capabilities that can be advertised in the CDNI Foot= print and Capabilities Advertisement interface (FCI). This would allow the = uCDN to select a dCDN that supports partial object caching when required (o= r possibly elect to serve itself). Jan, Would you mind including this as a candidate in your list so we rememebr to= make a concious decision about it? Thanks Francois -Scott On Tue, Oct 15, 2013 at 2:23 AM, Brandenburg, R. (Ray) van > wrote: Hi Ben, > -----Original Message----- > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > Sent: maandag 14 oktober 2013 5:10 > To: Brandenburg, R. (Ray) van > Cc: cdni@ietf.org > Subject: Re: [CDNi] CDNI and byte-range requests > > Ray, > > On 30 Jul 2013, at 12:27, Brandenburg, R. (Ray) van wrote: > > > Hi all, > > > > As I'm not sure whether this should be part of the Redirection Interfac= e > document or the Framework document, let me just post this as a general > question to the list: > > > > To my knowledge, the current CDNI documents do not explicitly address > the case of HTTP Byte-range requests. Although in most cases byte-range > requests will function just as any other requests, I think there are some= cases > where byte-range requests warrant further attention. An example is the > Redirection interface. If a uCDN asks a dCDN to deliver a particular user > request (containing a byte range), and the dCDN answers positively, can t= he > uCDN assume that the dCDN accepts any future requests for the same file > with a different byte range? And if that is the case, is this default beh= avior or > do we need an explicit flag in the inter-CDN redirection request to indic= ate > the uCDN/dCDN's preference? > > > > To be clear: I don't think we need any new functionality to handle byte= - > range requests, but a few sentences in either the Framework or the RI > document might clear up any future uncertainty. > > I don't see how this is any different to a sequence of non byte-range > requests. > > It will likely depend on the behaviour of the client (and possibly whethe= r the > server closes the connection after each request if that drives a differen= t > client behaviour) as to where the client ends up going (uCDN or dCDN) whe= n > it makes a subsequent request. > > Trying to say anything here may take us down the rat hole of trying to > describe client behaviour which we don't control. > Let me give a practical example: Let's say the uCDN is hosting a 2gb TS fil= e. At some point it receives an incoming request for a particular byte rang= e within that file, let's say the first 10mb. For some reason the uCDN deci= des that it wants to redirect the request to a dCDN. The dCDN receives the = request. At that point it has to decide what to do: does it download the fu= ll 2gb file from the uCDN, or does it download just the first 10mb? Of cour= se it's fully up to internal logic in the dCDN to decide what it should do = here, however it does have an impact on the uCDN as well (potentially unnec= essary traffic reducing the effectiveness of the inter-CDN redirect). My qu= estion is, do we need to say anything about this case to help both the dCDN= and uCDN in making this decision? Ray > Ben > > > > > Best regards, > > > > Ray > > This e-mail and its contents are subject to the DISCLAIMER at > http://www.tno.nl/emaildisclaimer > > > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_FC236DA6F2DA77449EF2D02DF4471A8D0BB731AFxmbrcdx10ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <05408D7E71A66845AECA8F0B2D524A26@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Scott, Jan, and all,

On 15 Oct 2013, at 11:30, Scott Leibrand <sleibrand@llnw.com> wrote:

This feature (partial object caching) is absolutely a requ= irement before we could think about offloading on-demand video traffic to a= dCDN.  If the dCDN downloads the entire file, that completely ruins t= he uCDN's efforts to do partial caching, and the resulting increase in cache use makes things worse than not using = a dCDN at all.

Then perhaps it would make sense to include something like "Parti= al Object Caching" in the set of capabilities that can be advertised i= n the CDNI Footprint and Capabilities Advertisement interface (FCI). This w= ould allow the uCDN to select a dCDN that supports partial object caching when required (or possibly elect to serve = itself).

Jan,
Would you mind including this as a candidate in your list so we rememe= br to make a concious decision about it?

Thanks

Francois




-Scott


On Tue, Oct 15, 2013 at 2:23 AM, Brandenburg, R.= (Ray) van <ray.vanbrandenburg@tno.nl> wrote:
Hi Ben,

> -----Original Message-----
> From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]
> Sent: maandag 14 oktober 2013 5:10
> To: Brandenburg, R. (Ray) van
> Cc: cdni@ietf.org
> Subject: Re: [CDNi] CDNI and byte-range requests
>
> Ray,
>
> On 30 Jul 2013, at 12:27, Brandenburg, R. (Ray) van wrote:
>
> > Hi all,
> >
> > As I'm not sure whether this should be part of the Redirection In= terface
> document or the Framework document, let me just post this as a general=
> question to the list:
> >
> > To my knowledge, the current CDNI documents do not explicitly add= ress
> the case of HTTP Byte-range requests. Although in most cases byte-rang= e
> requests will function just as any other requests, I think there are s= ome cases
> where byte-range requests warrant further attention. An example is the=
> Redirection interface. If a uCDN asks a dCDN to deliver a particular u= ser
> request (containing a byte range), and the dCDN answers positively, ca= n the
> uCDN assume that the dCDN accepts any future requests for the same fil= e
> with a different byte range? And if that is the case, is this default = behavior or
> do we need an explicit flag in the inter-CDN redirection request to in= dicate
> the uCDN/dCDN's preference?
> >
> > To be clear: I don't think we need any new functionality to handl= e byte-
> range requests, but a few sentences in either the Framework or the RI<= br> > document might clear up any future uncertainty.
>
> I don't see how this is any different to a sequence of non byte-range<= br> > requests.
>
> It will likely depend on the behaviour of the client (and possibly whe= ther the
> server closes the connection after each request if that drives a diffe= rent
> client behaviour) as to where the client ends up going (uCDN or dCDN) = when
> it makes a subsequent request.
>
> Trying to say anything here may take us down the rat hole of trying to=
> describe client behaviour which we don't control.
>

Let me give a practical example: Let's say the uCDN is hosting a 2gb TS fil= e. At some point it receives an incoming request for a particular byte rang= e within that file, let's say the first 10mb. For some reason the uCDN deci= des that it wants to redirect the request to a dCDN. The dCDN receives the request. At that point it has to = decide what to do: does it download the full 2gb file from the uCDN, or doe= s it download just the first 10mb? Of course it's fully up to internal logi= c in the dCDN to decide what it should do here, however it does have an impact on the uCDN as well (potent= ially unnecessary traffic reducing the effectiveness of the inter-CDN redir= ect). My question is, do we need to say anything about this case to help bo= th the dCDN and uCDN in making this decision?

Ray

> Ben
>
> >
> > Best regards,
> >
> > Ray
> > This e-mail and its contents are subject to the DISCLAIMER at
> http:/= /www.tno.nl/emaildisclaimer
> >
> > _______________________________________________
> > CDNi mailing list
> > CDNi@ietf.org
> > https://www.ietf.org/mailman/listinfo/cdni

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

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

--_000_FC236DA6F2DA77449EF2D02DF4471A8D0BB731AFxmbrcdx10ciscoc_-- From flefauch@cisco.com Tue Oct 15 06:32:27 2013 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 9463F11E81E2 for ; Tue, 15 Oct 2013 06:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9XiTv5S-Ijd for ; Tue, 15 Oct 2013 06:32:22 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7534911E81E3 for ; Tue, 15 Oct 2013 06:32:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6699; q=dns/txt; s=iport; t=1381843942; x=1383053542; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ciFzR1w6GHePAl7xNa/rsBiIfdDXzKbL4GoRAe6OdeI=; b=b/+mZDYp4Mi7/wGxvW4wqI2WXE7MxD2AxpuDVMlAf8VtlN46XQXmNZPD j6UvDQJwB0hc0YneAZJ727JDiJsjTcZo03kpao4JiO8r7zkLoiY2uT/17 GdFyN7CMZzK9b8c/lSmpIlFqZntVEJAsMH9FgjyqVpFkD+wC0fBTP7efY c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAKRDXVKtJV2Z/2dsb2JhbABagwc4UsIjgSMWdIIlAQEBAwEBAQFrCwULAgEIGAoDFgsnCyUCBA4FCId4Bgy9NASPFwIxB4MfgQYDqgaBZoE+gik X-IronPort-AV: E=Sophos;i="4.93,499,1378857600"; d="scan'208";a="272095155" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 15 Oct 2013 13:32:03 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9FDW35i008012 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Oct 2013 13:32:03 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.33]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Tue, 15 Oct 2013 08:32:03 -0500 From: "Francois Le Faucheur (flefauch)" To: Ben Niven-Jenkins Thread-Topic: [CDNi] CDNI Logging : access to CDNI Logging File once it is moved from Subscription to Archive in the Logging Feed Thread-Index: AQHOu4ObUoHE8wHJKkqQcuD6pGxU7JnyqESAgAM8TgCAABlagIAANLmA Date: Tue, 15 Oct 2013 13:32:02 +0000 Message-ID: References: <82E8974B-BD12-4B4B-871B-8CA57820FCA4@niven-jenkins.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.206] Content-Type: text/plain; charset="Windows-1252" Content-ID: <8CC726710FB3A6429EE31D81647D2F8A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] CDNI Logging : access to CDNI Logging File once it is moved from Subscription to Archive in the Logging Feed X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 15 Oct 2013 13:32:27 -0000 On 15 Oct 2013, at 12:23, Ben Niven-Jenkins wrote= : > Francois, >=20 > I believe the practice is to remove the prev-archive link in the (now) la= st archive feed page when previously last archive feed page is no longer av= ailable.=20 I just had a quick look at RFC5005. It suggests that documents in an archive feed are permanent , which I under= stand to mean that they shoudl not be modified after having been sent, and = that client will probably never pull them again. For example, it says: * "Archived feeds split the entries among multiple permanent documents" * " The requirement that archive documents be stable allows clients to saf= ely assume that if they have retrieved one in the past, it will not meaning= fully change in the future." It also says that a publisher is not expected to serve all archives for-eve= r: * "Publishers are not required to make all archive documents available; they may refuse to serve (e.g., with HTTP status code 403 or 410) or be unable to serve (e.g., with HTTP status code 404) an archive document." So, to me the behavior expected by RFC5005 would probably be to : 1) just leave old archive feeds unmodified 2) simply have the right to no longer serve old archive feeds when they ar= e outside the time window agreed by uCDN and dCDN 3) simply have the right to no longer server old CDNI logging files when t= hey are outside the time window agreed by uCDN and dCDN This seems in line with RFC5005 and its expectation that a client will not = re-pull an old archive to see if it has been updated. It also seems very si= mple (ie nothing needs to ever get modified in the feed). Could that work for you? Francois > Ben >=20 >> On 15 Oct 2013, at 09:52, "Francois Le Faucheur (flefauch)" wrote: >>=20 >> Hi Ben, >>=20 >> On 13 Oct 2013, at 09:27, Ben Niven-Jenkins >> wrote: >>=20 >>> Francois, Colleagues, >>>=20 >>> My opinion is that if logs are advertised in the subscription or archiv= e feeds then they should be made available for download. I.e. we don't intr= oduce new semantics that mean that if it is a CDN Logging feed then only en= tries in the subscription feed should be made available and the archive fee= d is "known" to probably point to dead links for log files. >>>=20 >>> Forcing a linkage between time covered by the subscription feed and tie= and the retention time a uCDN would like a dCDN to provide is not a good i= dea IMO as it limits the flexibility we give to implementations for no adva= ntage. >>>=20 >>> If a CDN wishes to remove old logs they should also remove the archive = pages that reference those logs (or never generate/advertise them in the fi= rst place). >>=20 >> Please help me understand your proposal: >>=20 >> Say dCDN: >> * produced 24 Log files on 1 Oct , that were listed in an archive feed= (archive-1-oct) >> * produced 24 Log files on 2 Oct, that were listed in an archive feed = (archive-2-oct) >> * =85 >> * produced 24 Log files on 14 Oct, that were listed in an archive fee= d (archive-14-oct) >>=20 >> Say today is 15 October and the dCDN has agreed with uCDN to retain log = files for a period of one week. >>=20 >> So the Subscription feed has a prev-archive link to archive-14-oct, that= has a prev-archive link to archive-13-oct, etc=85.. . >> But what happens in archive-7-oct? does it need to be modified so that i= t no longer has a prev-archive link? >> Or do you keep the prev-archive chaning forever and simply accept that s= ome files advertised in an archive feed are no longer accessible (ie if uCD= N tries pull a file advertised in archive-3-oct it will received a 404).? >>=20 >> I don't have a strong view on this topic but woudl like to document the = chosen approach properly.=20 >>=20 >> Cheers >>=20 >> Francois >>=20 >>> Ben >>>=20 >>>=20 >>>> On 27 Sep 2013, at 14:15, Francois Le Faucheur (flefauch) wrote: >>>>=20 >>>> Folks, >>>>=20 >>>> [as a co-author] >>>>=20 >>>> I'd like input on one of the very remaining open items in cdni-logging= . >>>>=20 >>>> For memory, the CDNI Logging Feed allows a dCDN to advertise to the uC= DN which CDNI Logging Files can be retrieved by the uCDN from the dCDN. >>>> It is structured as an Archived ATOM feed, meaning that a sliding wind= ow of currently available CDNI Logging files is advertised in a "Subscripti= on" document, and then, over time, the older Logging Files are moved to an = "Archive" document and new Logging Files appear in the Subscription documen= t. >>>>=20 >>>> There is currently an editor's note asking a question about what shoul= d happen once a Logging File has been moved to an "archive": >>>> " >>>> [Editor's note: if a given Logging file is moved away from >>>> subscription document to an archive document, do we agree it may no >>>> longer be accessible to uCDN?] >>>> " >>>> I personally agree that the Logging File need not be made available fo= r download once it has moved away from the Subscripton document to the Arch= ive document. My rationale is that: >>>> * this is precisely the point of the Subscription document i.e. to i= ndicate which files are currently downloadable and the server-side is then = responsible for ensuring it can serve these files (ie it has to retain them= and be ready to serve them).=20 >>>> * it is not reasonable to expect that the server-side will make old = Logging Files accessible forever >>>> * if the client-side wants to have a large window of time to pull Lo= gging Files, then it needs to agree with the server-side and this period wi= ll be used as the retention period in the subscripton file.=20 >>>>=20 >>>> Please let us know if you disagree/agree with that, so we can address = that in the next rev (this has not been addressed in -06 posted today). >>>>=20 >>>> For memory, I think the current text already implies the above: >>>> " >>>> The server-side implementation MUST respond to any valid pull request >>>> by a client-side implementation for a CDNI Logging File published by >>>> the server-side in the subscription document of the CDNI Logging >>>> Feed.=20 >>>> " >>>> If we agree with the position above, we could also tweak the text to s= ay that the server-side MUST respond _and_ actually provide the Logging Fil= e (ie responding 404 is not good). >>>>=20 >>>> Cheers >>>>=20 >>>> Francois >>>>=20 >>>> _______________________________________________ >>>> CDNi mailing list >>>> CDNi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cdni >>=20 From ben@niven-jenkins.co.uk Tue Oct 15 08:43:08 2013 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 2A9AF21E817B for ; Tue, 15 Oct 2013 08:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UugQd4ZGMTP4 for ; Tue, 15 Oct 2013 08:43:02 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5587321E8102 for ; Tue, 15 Oct 2013 08:43:01 -0700 (PDT) Received: from host4.velocix.com ([81.134.152.4] helo=xxx.corp.velocix.com) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1VW6lw-0003IW-PG; Tue, 15 Oct 2013 16:43:01 +0100 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Ben Niven-Jenkins In-Reply-To: Date: Tue, 15 Oct 2013 16:42:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <42284C59-D8B3-4CED-B84D-C723F5FED925@niven-jenkins.co.uk> References: <82E8974B-BD12-4B4B-871B-8CA57820FCA4@niven-jenkins.co.uk> To: "Francois Le Faucheur (flefauch)" X-Mailer: Apple Mail (2.1085) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "cdni@ietf.org" Subject: Re: [CDNi] CDNI Logging : access to CDNI Logging File once it is moved from Subscription to Archive in the Logging Feed X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 15 Oct 2013 15:43:09 -0000 Francois, On 15 Oct 2013, at 14:32, Francois Le Faucheur (flefauch) wrote: >=20 > On 15 Oct 2013, at 12:23, Ben Niven-Jenkins = wrote: >=20 >> Francois, >>=20 >> I believe the practice is to remove the prev-archive link in the = (now) last archive feed page when previously last archive feed page is = no longer available.=20 >=20 > I just had a quick look at RFC5005. >=20 >=20 > So, to me the behavior expected by RFC5005 would probably be to : > 1) just leave old archive feeds unmodified > 2) simply have the right to no longer serve old archive feeds = when they are outside the time window agreed by uCDN and dCDN > 3) simply have the right to no longer server old CDNI logging = files when they are outside the time window agreed by uCDN and dCDN >=20 > This seems in line with RFC5005 and its expectation that a client will = not re-pull an old archive to see if it has been updated. It also seems = very simple (ie nothing needs to ever get modified in the feed). >=20 > Could that work for you? Yes, that works for me. Ben >=20 > Francois >=20 >=20 >> Ben >>=20 >>> On 15 Oct 2013, at 09:52, "Francois Le Faucheur (flefauch)" = wrote: >>>=20 >>> Hi Ben, >>>=20 >>> On 13 Oct 2013, at 09:27, Ben Niven-Jenkins = >>> wrote: >>>=20 >>>> Francois, Colleagues, >>>>=20 >>>> My opinion is that if logs are advertised in the subscription or = archive feeds then they should be made available for download. I.e. we = don't introduce new semantics that mean that if it is a CDN Logging feed = then only entries in the subscription feed should be made available and = the archive feed is "known" to probably point to dead links for log = files. >>>>=20 >>>> Forcing a linkage between time covered by the subscription feed and = tie and the retention time a uCDN would like a dCDN to provide is not a = good idea IMO as it limits the flexibility we give to implementations = for no advantage. >>>>=20 >>>> If a CDN wishes to remove old logs they should also remove the = archive pages that reference those logs (or never generate/advertise = them in the first place). >>>=20 >>> Please help me understand your proposal: >>>=20 >>> Say dCDN: >>> * produced 24 Log files on 1 Oct , that were listed in an archive = feed (archive-1-oct) >>> * produced 24 Log files on 2 Oct, that were listed in an archive = feed (archive-2-oct) >>> * =85 >>> * produced 24 Log files on 14 Oct, that were listed in an archive = feed (archive-14-oct) >>>=20 >>> Say today is 15 October and the dCDN has agreed with uCDN to retain = log files for a period of one week. >>>=20 >>> So the Subscription feed has a prev-archive link to archive-14-oct, = that has a prev-archive link to archive-13-oct, etc=85.. . >>> But what happens in archive-7-oct? does it need to be modified so = that it no longer has a prev-archive link? >>> Or do you keep the prev-archive chaning forever and simply accept = that some files advertised in an archive feed are no longer accessible = (ie if uCDN tries pull a file advertised in archive-3-oct it will = received a 404).? >>>=20 >>> I don't have a strong view on this topic but woudl like to document = the chosen approach properly.=20 >>>=20 >>> Cheers >>>=20 >>> Francois >>>=20 >>>> Ben >>>>=20 >>>>=20 >>>>> On 27 Sep 2013, at 14:15, Francois Le Faucheur (flefauch) wrote: >>>>>=20 >>>>> Folks, >>>>>=20 >>>>> [as a co-author] >>>>>=20 >>>>> I'd like input on one of the very remaining open items in = cdni-logging. >>>>>=20 >>>>> For memory, the CDNI Logging Feed allows a dCDN to advertise to = the uCDN which CDNI Logging Files can be retrieved by the uCDN from the = dCDN. >>>>> It is structured as an Archived ATOM feed, meaning that a sliding = window of currently available CDNI Logging files is advertised in a = "Subscription" document, and then, over time, the older Logging Files = are moved to an "Archive" document and new Logging Files appear in the = Subscription document. >>>>>=20 >>>>> There is currently an editor's note asking a question about what = should happen once a Logging File has been moved to an "archive": >>>>> " >>>>> [Editor's note: if a given Logging file is moved away from >>>>> subscription document to an archive document, do we agree it may = no >>>>> longer be accessible to uCDN?] >>>>> " >>>>> I personally agree that the Logging File need not be made = available for download once it has moved away from the Subscripton = document to the Archive document. My rationale is that: >>>>> * this is precisely the point of the Subscription document i.e. = to indicate which files are currently downloadable and the server-side = is then responsible for ensuring it can serve these files (ie it has to = retain them and be ready to serve them).=20 >>>>> * it is not reasonable to expect that the server-side will make = old Logging Files accessible forever >>>>> * if the client-side wants to have a large window of time to pull = Logging Files, then it needs to agree with the server-side and this = period will be used as the retention period in the subscripton file.=20 >>>>>=20 >>>>> Please let us know if you disagree/agree with that, so we can = address that in the next rev (this has not been addressed in -06 posted = today). >>>>>=20 >>>>> For memory, I think the current text already implies the above: >>>>> " >>>>> The server-side implementation MUST respond to any valid pull = request >>>>> by a client-side implementation for a CDNI Logging File published = by >>>>> the server-side in the subscription document of the CDNI Logging >>>>> Feed.=20 >>>>> " >>>>> If we agree with the position above, we could also tweak the text = to say that the server-side MUST respond _and_ actually provide the = Logging File (ie responding 404 is not good). >>>>>=20 >>>>> Cheers >>>>>=20 >>>>> Francois >>>>>=20 >>>>> _______________________________________________ >>>>> CDNi mailing list >>>>> CDNi@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/cdni >>>=20 >=20 From kleung@cisco.com Tue Oct 15 12:14:23 2013 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 07C6411E8153 for ; Tue, 15 Oct 2013 12:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-I5twxmt9au for ; Tue, 15 Oct 2013 12:14:17 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 14F6B21F958A for ; Tue, 15 Oct 2013 12:14:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4630; q=dns/txt; s=iport; t=1381864457; x=1383074057; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=p/4v6P/F++EXZR4tU7UVlLqKeanCaeJ1in4n1O4ygw8=; b=f/HbXUU13kbtnbE1bLaLusg48v3po2JPSdq+5MrVwd70rsU7NBkRIUBK Y4pgUajNmXy71Op/rdtDn9WZXEqZ7n89RB60lwY6S9XpcRjoKy91grQm+ g9FsyRIanfsTAt3N85UFYotZYqTmUEpA1xIGV01RFpKgLueEjf8vA/2Vz Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAN2SXVKtJXHA/2dsb2JhbABagweBCsIqgSMWdIIlAQEBAwE6PwUHBAIBCBEEAQEBChQQMh0IAgQBDQUIE4dlBr15jxkxBwaDGYEGA6oGgySCKQ X-IronPort-AV: E=Sophos;i="4.93,501,1378857600"; d="scan'208";a="272472154" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 15 Oct 2013 19:14:16 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9FJEGiq010325 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Oct 2013 19:14:16 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.219]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Tue, 15 Oct 2013 14:14:15 -0500 From: "Kent Leung (kleung)" To: "Francois Le Faucheur (flefauch)" , Ben Niven-Jenkins Thread-Topic: [CDNi] SEC-4 in in draft-ietf-cdni-requirements Thread-Index: AQHOxcIi0D1l2Tya00O4QpS5GM3BypnzvYyAgAC/DwCAAaqrQA== Date: Tue, 15 Oct 2013 19:14:15 +0000 Message-ID: References: <48474D18-F627-4FE2-B098-41B9E93C6E73@niven-jenkins.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.84.32] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Yiu Lee Subject: Re: [CDNi] SEC-4 in in draft-ietf-cdni-requirements X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 15 Oct 2013 19:14:23 -0000 Good discussion. So, do we have agreement to update the requirement with th= e following? "SEC-4 [MED] The CDNI solution should be able to ensure non-repudiation by= the Downstream CDN of transaction logs generated by the Downstream CDN and= communicated to an Upstream CDN. This would ensure that the Downstream CDN= cannot repudiate transmitted Log records, and therefore reduces the incent= ive for the dCDN to spoof a transaction log (attempting to appear as if it = corresponds to a request redirected by the Upstream CDN when that request h= as not been redirected by this Upstream CDN)." Kent -----Original Message----- From: Francois Le Faucheur (flefauch)=20 Sent: Monday, October 14, 2013 5:38 AM To: Ben Niven-Jenkins Cc: Francois Le Faucheur (flefauch); Kent Leung (kleung); Yiu Lee; Subject: Re: [CDNi] SEC-4 in in draft-ietf-cdni-requirements On 14 Oct 2013, at 03:13, Ben Niven-Jenkins wrote: > Francois, Colleagues, >=20 > On 10 Oct 2013, at 15:08, Francois Le Faucheur (flefauch) wrote: >=20 >> Kent, Liu, >>=20 >> " >> SEC-4 [MED] The CDNI solution should be able to ensure that the >> Downstream CDN cannot spoof a transaction log attempting to >> appear as if it corresponds to a request redirected by a given >> Upstream CDN when that request has not been redirected by this >> Upstream CDN. This ensures non-repudiation by the Upstream >> CDN of transaction logs generated by the Downstream CDN for >> deliveries performed by the Downstream CDN on behalf of the >> Upstream CDN. >> " >> I think this requirement does not reflect correctly how non-repudiation = could play in teh context of CDNI Logging. For example, since the logging i= nformation is sent by dCDN to uCDN, it only makes sense to talk about non-r= epudiation by dCDN, not by uCDN. >>=20 >> I suggest a rewording along the lines of:=20 >>=20 >> " >> SEC-4 [MED] The CDNI solution should be able to ensure non-repudiation = by the Downstream >> CDN of transaction logs generated by the Downstream CDN and comm= unicated to an Upstream CDN. This reduces the incentives for the Downstream= CDN to spoof a transaction log attempting to appear as if it corresponds t= o a request redirected by the Upstream CDN when that request has not been r= edirected by this Upstream CDN. >> " >=20 > I don't see how the second sentence leads from the first. I.e. I don't se= e how a dCDN having the ability to ensure logs that it has generated are no= t modified reduces the dCDN's incentive to spoof (or not to spoof) log entr= ies. What non-repudiation brings is the fact that the dCDN can not dispute havin= g sent a particular Log Record (and have it sent exactly as recieved by the= uCDN). So a dCDN that is caught sending a CDNI Logging file with invalid records (= and the proof for that would have to be established via some other mechanis= m, such as for example contrasting it to CSP logs generated from end-device= s) can not just say "oh, I never sent that file, you must have done somethi= ng wrong yourself and generated/corrupted that logging record/file yourself= ". Basically, it brings traceability which generally helps keeping people h= onest. It is an open question as to whether such a non-repudiation mechanis= m brings sufficient value or not. Some argued "yes", which is why we have a= requirement for it. But that is a separate question.=20 Perhaps we should not say that "it reduces the incentive", but rather that = it creates a disincentive to cheat.=20 Perhaps this wording may help make things a little clearer: " SEC-4 [MED] The CDNI solution should be able to ensure non-repudiation by = the Downstream CDN of transaction logs generated by the Downstream CDN and = communicated to an Upstream CDN. This would ensure that the Downstream CDN = can not repudiate transmitted Log records, and therefore act as a disincent= ive for the dCDN to spoof a transaction log (attempting to appear as if it = corresponds to a request redirected by the Upstream CDN when that request h= as not been redirected by this Upstream CDN). " >=20 > Maybe just drop the second sentence entirely? >=20 That woudl be an easy way out, but it is clearly far from trivial to articu= late the rationale for including a requirement about non-repudiatin, I thin= k we need to record teh rationale. Otherwise, the question will most likely= come up come up at review time down the pipe. Cheers Francois > Ben >=20 From kleung@cisco.com Tue Oct 15 12:18:03 2013 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 1DFDA11E8152 for ; Tue, 15 Oct 2013 12:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7N+4iNsxU+N for ; Tue, 15 Oct 2013 12:17:57 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id A775A11E8149 for ; Tue, 15 Oct 2013 12:17:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5460; q=dns/txt; s=iport; t=1381864676; x=1383074276; h=from:to:cc:subject:date:message-id:references: content-transfer-encoding:mime-version; bh=tCEr3BoR+fqCvQ9s7b/ciHKHoroCoB7zigHZshewB1k=; b=HmzhqCK1yW4S1+4gSQ60oezkwTHF1IbDgywWKs7czC1LM9CUduUvja3F okXUlnSxA98FuvOf1J+fOClg+uQdtDIWz0Vkayh4taYfEIssMP9DZqZN8 zOrIyvR/ApueXsNpQdfd4PhnOt74Xk157x9kfN0WG+95qWU62OqZeEeHb U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAAuUXVKtJXHB/2dsb2JhbABagweBCsIqgSMWdIIlAQEBAwE6PwUHBAIBCBEEAQEBChQQMh0IAgQBDQUIE4dlBr13jxkxDYMZgQYDqgaDJIIp X-IronPort-AV: E=Sophos;i="4.93,501,1378857600"; d="scan'208";a="272473830" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-5.cisco.com with ESMTP; 15 Oct 2013 19:17:56 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9FJHqLt004128 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Oct 2013 19:17:54 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.219]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Tue, 15 Oct 2013 14:17:52 -0500 From: "Kent Leung (kleung)" To: "Francois Le Faucheur (flefauch)" , Ben Niven-Jenkins Thread-Topic: [CDNi] SEC-4 in in draft-ietf-cdni-requirements Thread-Index: AQHOxcIi0D1l2Tya00O4QpS5GM3BypnzvYyAgAC/DwCAAaqrQIAAA2nA Date: Tue, 15 Oct 2013 19:17:52 +0000 Message-ID: References: <48474D18-F627-4FE2-B098-41B9E93C6E73@niven-jenkins.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.84.32] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Yiu Lee Subject: Re: [CDNi] SEC-4 in in draft-ietf-cdni-requirements X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 15 Oct 2013 19:18:03 -0000 Oops. This is the requirement text to confirm: " SEC-4 [MED] The CDNI solution should be able to ensure non-repudiation by = the Downstream CDN of transaction logs generated by the Downstream CDN and = communicated to an Upstream CDN. This would ensure that the Downstream CDN = cannot repudiate transmitted Log records, and therefore act as a disincenti= ve for the dCDN to spoof a transaction log (attempting to appear as if it c= orresponds to a request redirected by the Upstream CDN when that request ha= s not been redirected by this Upstream CDN). " Kent -----Original Message----- From: Kent Leung (kleung)=20 Sent: Tuesday, October 15, 2013 12:12 PM To: Francois Le Faucheur (flefauch); Ben Niven-Jenkins Cc: Yiu Lee; Subject: RE: [CDNi] SEC-4 in in draft-ietf-cdni-requirements Good discussion. So, do we have agreement to update the requirement with th= e following? "SEC-4 [MED] The CDNI solution should be able to ensure non-repudiation by= the Downstream CDN of transaction logs generated by the Downstream CDN and= communicated to an Upstream CDN. This would ensure that the Downstream CDN= cannot repudiate transmitted Log records, and therefore reduces the incent= ive for the dCDN to spoof a transaction log (attempting to appear as if it = corresponds to a request redirected by the Upstream CDN when that request h= as not been redirected by this Upstream CDN)." Kent -----Original Message----- From: Francois Le Faucheur (flefauch)=20 Sent: Monday, October 14, 2013 5:38 AM To: Ben Niven-Jenkins Cc: Francois Le Faucheur (flefauch); Kent Leung (kleung); Yiu Lee; Subject: Re: [CDNi] SEC-4 in in draft-ietf-cdni-requirements On 14 Oct 2013, at 03:13, Ben Niven-Jenkins wrote: > Francois, Colleagues, >=20 > On 10 Oct 2013, at 15:08, Francois Le Faucheur (flefauch) wrote: >=20 >> Kent, Liu, >>=20 >> " >> SEC-4 [MED] The CDNI solution should be able to ensure that the >> Downstream CDN cannot spoof a transaction log attempting to >> appear as if it corresponds to a request redirected by a given >> Upstream CDN when that request has not been redirected by this >> Upstream CDN. This ensures non-repudiation by the Upstream >> CDN of transaction logs generated by the Downstream CDN for >> deliveries performed by the Downstream CDN on behalf of the >> Upstream CDN. >> " >> I think this requirement does not reflect correctly how non-repudiation = could play in teh context of CDNI Logging. For example, since the logging i= nformation is sent by dCDN to uCDN, it only makes sense to talk about non-r= epudiation by dCDN, not by uCDN. >>=20 >> I suggest a rewording along the lines of:=20 >>=20 >> " >> SEC-4 [MED] The CDNI solution should be able to ensure non-repudiation = by the Downstream >> CDN of transaction logs generated by the Downstream CDN and comm= unicated to an Upstream CDN. This reduces the incentives for the Downstream= CDN to spoof a transaction log attempting to appear as if it corresponds t= o a request redirected by the Upstream CDN when that request has not been r= edirected by this Upstream CDN. >> " >=20 > I don't see how the second sentence leads from the first. I.e. I don't se= e how a dCDN having the ability to ensure logs that it has generated are no= t modified reduces the dCDN's incentive to spoof (or not to spoof) log entr= ies. What non-repudiation brings is the fact that the dCDN can not dispute havin= g sent a particular Log Record (and have it sent exactly as recieved by the= uCDN). So a dCDN that is caught sending a CDNI Logging file with invalid records (= and the proof for that would have to be established via some other mechanis= m, such as for example contrasting it to CSP logs generated from end-device= s) can not just say "oh, I never sent that file, you must have done somethi= ng wrong yourself and generated/corrupted that logging record/file yourself= ". Basically, it brings traceability which generally helps keeping people h= onest. It is an open question as to whether such a non-repudiation mechanis= m brings sufficient value or not. Some argued "yes", which is why we have a= requirement for it. But that is a separate question.=20 Perhaps we should not say that "it reduces the incentive", but rather that = it creates a disincentive to cheat.=20 Perhaps this wording may help make things a little clearer: " SEC-4 [MED] The CDNI solution should be able to ensure non-repudiation by = the Downstream CDN of transaction logs generated by the Downstream CDN and = communicated to an Upstream CDN. This would ensure that the Downstream CDN = can not repudiate transmitted Log records, and therefore act as a disincent= ive for the dCDN to spoof a transaction log (attempting to appear as if it = corresponds to a request redirected by the Upstream CDN when that request h= as not been redirected by this Upstream CDN). " >=20 > Maybe just drop the second sentence entirely? >=20 That woudl be an easy way out, but it is clearly far from trivial to articu= late the rationale for including a requirement about non-repudiatin, I thin= k we need to record teh rationale. Otherwise, the question will most likely= come up come up at review time down the pipe. Cheers Francois > Ben >=20 From flefauch@cisco.com Wed Oct 16 01:53:38 2013 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 93E7111E825F for ; Wed, 16 Oct 2013 01:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlPE-rbhjIp5 for ; Wed, 16 Oct 2013 01:53:33 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7F211E811B for ; Wed, 16 Oct 2013 01:53:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=140; q=dns/txt; s=iport; t=1381913613; x=1383123213; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=48u5vI+iIxFvbNiVevajjjnaaraSykBuDY+8qMbuyj4=; b=TwvsA/Xlf2tackGWKfkgGlXShV05K8z13way8yrpZkDSfL6eTtSPfw2R YLkVaTeVJxiewwV4XDd/jN1CwLrooPvVEVZmwSglw8kHBhpMXJVCYh6C9 d1y2oDF/P8kgqelnduBqJieojtTYvuY9rRe6IhyzaNbJZ51kAj9blo9nY Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIGAEBTXlKtJXG+/2dsb2JhbABagweBCsINgSAWbQeCJwEEOlEBKhRCJwQbh36caKFijyCDV4EGA6oGgySCKQ X-IronPort-AV: E=Sophos;i="4.93,506,1378857600"; d="scan'208";a="272691319" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 16 Oct 2013 08:53:32 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9G8rWDn015488 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 16 Oct 2013 08:53:32 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.33]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Wed, 16 Oct 2013 03:53:32 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: Reminder: I-D Cut-off date is 2013-10-21 Thread-Index: AQHOyk0wlEc2ru14YEqTQORmQMNTjQ== Date: Wed, 16 Oct 2013 08:53:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.206] Content-Type: text/plain; charset="us-ascii" Content-ID: <8F96354AB218FE4A9DABE75D0C0BB0AA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] Reminder: I-D Cut-off date is 2013-10-21 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 16 Oct 2013 08:53:38 -0000 Hi, " 2013-10-21 (Monday): Internet Draft submission cut-off (for all drafts, inc= luding -00) by UTC 24:00 " Cheers Francois= From flefauch@cisco.com Wed Oct 16 02:10:31 2013 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 1268121F9C55 for ; Wed, 16 Oct 2013 02:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JctGRB1mc6S for ; Wed, 16 Oct 2013 02:10:25 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id EE7F211E8158 for ; Wed, 16 Oct 2013 02:10:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1030; q=dns/txt; s=iport; t=1381914624; x=1383124224; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=QLhBMzFIrjjIjQcz19xr/OtfY3tvvs8fC3DjiFTz6v0=; b=CM+Ra8FkU00pTXhUf4nciuWveRhMc0Ud/ZI9SeiFSHbK86AiRxYh4z0E baQFa4V6972YfBwCpQ5GYMeCVdRTvANcoyTKGriKjt9G9uz6yOoqBp28E pU+FMAXmKD2h3CZJ4/tAujgn0vGeRyNrv0x6eHNGr4mxFkuEdnVB9ayk9 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQGABlXXlKtJV2Z/2dsb2JhbABagwc4UsINgSEWbQeCJwEEOj8SASoUQicEDg2Hfr5GjgiBGDGDJoEGA6oGgySBcDk X-IronPort-AV: E=Sophos;i="4.93,506,1378857600"; d="scan'208";a="272715762" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 16 Oct 2013 09:10:23 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9G9AN58030675 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Oct 2013 09:10:23 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.33]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Wed, 16 Oct 2013 04:10:23 -0500 From: "Francois Le Faucheur (flefauch)" To: "draft-ietf-cdni-metadata@tools.ietf.org" Thread-Topic: Next rev of cdni-metadata for Vancouver Thread-Index: AQHOyk+LoLpovSpvWEy1johhSkxHqA== Date: Wed, 16 Oct 2013 09:10:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.206] Content-Type: text/plain; charset="us-ascii" Content-ID: <0127631BA4F6F34A89A096A9323E2A01@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: [CDNi] Next rev of cdni-metadata for Vancouver X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 16 Oct 2013 09:10:31 -0000 Dear authors of cdni-metadata, We are fast approaching the I-D dealine (next Monday). Can you please confi= rm that you plan to post an updated rev reflecting the discussions/agreemen= ts from Berlin? For memory, the updated target date for submission of cdni-metadata to IESG= is Dec 2013, which means we want to target WG Last Call on the version for= Vancouver or on an update shortly after. Thanks Francois & Daryl PS: For convenience below is an excerpt from Berlin minutes, discussing one= of the most important open items ie ensure enough coverage of HTTP deliver= y: " - Kevin, Ben, Matt - agreed to make sure there's enough in the draft to all= ow base HTTP delivery before going to WG last call - Francois - use the cdni email list if there is disagreement about what ex= actly is needed to allow base HTTP delivery - Francois - we will need confirmation from authors that the MI spec does c= over what is needed for HTTP delivery before we can consider moving to WG L= ast Call "= From flefauch@cisco.com Wed Oct 16 02:26:33 2013 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 E622E11E815B for ; Wed, 16 Oct 2013 02:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VrPxhgnCga7 for ; Wed, 16 Oct 2013 02:26:20 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 2477F21F8FD2 for ; Wed, 16 Oct 2013 02:26:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=295; q=dns/txt; s=iport; t=1381915573; x=1383125173; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=fNqyI6N/+mdwD7FxA7hBegspuFI5D896YFYdnkIdmVA=; b=kcVrDgMROte4C44cQSC+0BXlA01jlE+12tK2zUXbr6h+Vpr9QIiAgd0G 0asodDaZkm3SxYY8M7tjsBxbxu0mame0sc3MlT60pi2EOr2ZdBoz2Ltjo XFb6w7EGI115aOMXuPFPEa2hSYUPdwNABiaALL6uTm0577DDjVvJEPW6a M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQGAEJbXlKtJV2Z/2dsb2JhbABagwc4UsINgSEWbQeCJwEEOj8SASoUQicEDg2Hfgy+QASPIDECgySBBgOqBoMkgik X-IronPort-AV: E=Sophos;i="4.93,506,1378857600"; d="scan'208";a="272776973" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 16 Oct 2013 09:26:11 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9G9QBOV013488 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Oct 2013 09:26:11 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.33]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Wed, 16 Oct 2013 04:26:11 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: Vancouver CDNI WG Slot requests Thread-Index: AQHOylHAdjxGwSDWYkuSiq1jxBcHgw== Date: Wed, 16 Oct 2013 09:26:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.206] Content-Type: text/plain; charset="us-ascii" Content-ID: <46590F360C646E418428C2D8CE7A4E57@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] Vancouver CDNI WG Slot requests X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 16 Oct 2013 09:26:34 -0000 All, Please unicast your slot request to Daryl and I by Monday 21 October (earli= er is better). Thanks Francois & Daryl PS: As per final agenda (https://datatracker.ietf.org/meeting/88/agenda.htm= l), the CDNI WG will hold a single session: * Thursday Nov 7, 1520-1720 PST.= From flefauch@cisco.com Wed Oct 16 03:43:58 2013 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 6FBFF11E81BE for ; Wed, 16 Oct 2013 03:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPFqalzBy5W8 for ; Wed, 16 Oct 2013 03:43:53 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id BFEA411E81B7 for ; Wed, 16 Oct 2013 03:43:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5635; q=dns/txt; s=iport; t=1381920233; x=1383129833; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Hkjr1ak+80r+GG4erbt0TAJi6kcDErblVuaPwbjWtJE=; b=COPKUPuGkbUJL93ybS9e9Af6cN6Oi0at1m47jZRTfdJP2+2ODAzUQOHi /XFnbZG+lWwIyHJITPZAGYuhRFW0FHEcGxhDbU15l0d8xTRvMJK3/AL5e GMn76SO4ad7zSyUkClwhLN2q61nNaW3lm+wNghWvDqer/i0sLUku/1z6c U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioFANVsXlKtJXHA/2dsb2JhbABagkNEgQrCDoEiFnSCJgEBBHkQAgEIDhQkMiUCBA4Nh36+bo4HC4EOMQeDH4EGA6oGgySBZ0I X-IronPort-AV: E=Sophos;i="4.93,506,1378857600"; d="scan'208,217";a="272798745" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 16 Oct 2013 10:43:51 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9GAhpqo022894 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Oct 2013 10:43:51 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.33]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Wed, 16 Oct 2013 05:43:51 -0500 From: "Francois Le Faucheur (flefauch)" To: Daryl Malas Thread-Topic: [CDNi] CDNI Framework WG Chair Review - Part 1 Thread-Index: AQHOxF5lF3rcjZN9PkaZrjfSCHNATJn3hEaA Date: Wed, 16 Oct 2013 10:43:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.206] Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D0BB762DAxmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] CDNI Framework WG Chair Review - Part 1 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 16 Oct 2013 10:43:58 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D0BB762DAxmbrcdx10ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Daryl, Larry and all, Thoughts embedded below about two comments. I personally agree with all other comments/suggestions from Daryl. Section 2.1.1 =96 What is the purpose of stating, "...although the user is free to choose other DNS servers (e.g., OpenDNS, Google Public DNS)." I suggest we remove that. I don't think it adds any value to the explanati= on. I think it is useful to convey the idea that the user may be using a "DNS" = that is fairly local (ie whose location provides some hint about where the = enduser itself is located) or a non-local DNS (ie whose location is complet= ly un-correlated with the enduser location). This helps understanding the s= ubsequent paragraph bringing up the inaccucary drawback of the DNS method. However, the text in the subsequent paragraph is currently inconsistent bec= ause it only mentions the case of the LDNS: "On the other hand, DNS redirection is problematic because the DNS request comes from the LDNS server, not the end-user. " This may have to do with an ambiguous use of the term "LDNS". My suggestion is that the edited text: * indicates that the user can use different DNS servers * with some DNS servers (eg DNS server run by network operator), the locati= on of the DNS server may provide some indication of the enduser location. W= ith some DNS servers (eg global DNS server), it does not. * DNS redirection only sees the IP address of teh DNS server and not enduse= r and therefore has limited or no information on enduser location which aff= ects redirection accuracy. Page 12 =96 The example on step 7 seems redundant with step 4. I understan= d the step, but I think the example seems redundant. I suggest changing th= e example. I don't see why step 4 and 7 are redundant. Step 4 is using Redirection Int= erface while Step 7 is over Metadata Interface. Francois --_000_FC236DA6F2DA77449EF2D02DF4471A8D0BB762DAxmbrcdx10ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Daryl, Larry and all,

Thoughts embedded below about two comments. 
I personally agree with all other comments/suggestions from Daryl.


Section 2.1.1 =96 What is the purpose of stating, "...although th= e user is
free to choose other DNS servers (e.g., OpenDNS, Google Public DNS).&q= uot;

I suggest we remove that.  I don't think it adds any value to the= explanation.

I think it is useful to convey the idea that the user may be using a &= quot;DNS" that is fairly local (ie whose location provides some hint a= bout where the enduser itself is located) or a non-local DNS (ie whose= location is completly un-correlated with the enduser location). This helps understanding the subsequent paragraph bringing up t= he inaccucary drawback of the DNS method.

However, the text in the subsequent paragraph is currently inconsisten= t because it only mentions the case of the LDNS:
"On the other hand, DNS redirection is
   problematic because the DNS request comes from the LDNS server= , not
   the end-user. 
"
This may have to do with an ambiguous use of the term "LDNS"= .

My suggestion is that the edited text:
* indi= cates that the user can use different DNS servers
* with= some DNS servers (eg DNS server run by network operator), the location of = the DNS server may provide some indication of the enduser location. With so= me DNS servers (eg global DNS server), it does not.
* DNS = redirection only sees the IP address of teh DNS server and not enduser and = therefore has limited or no information on enduser location which affects r= edirection accuracy.


Page 12 =96 The example on step 7 seems redundant with step 4.  I= understand the step, but I think the example seems redundant.  I sugg= est changing the example.

I don't see why step 4 and 7 are redundant. Step 4 is using Redirectio= n Interface while Step 7 is over Metadata Interface.

Francois
--_000_FC236DA6F2DA77449EF2D02DF4471A8D0BB762DAxmbrcdx10ciscoc_-- From D.Malas@cablelabs.com Wed Oct 16 08:48:15 2013 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 B8FC311E82E9 for ; Wed, 16 Oct 2013 08:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.462 X-Spam-Level: X-Spam-Status: No, score=-101.462 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5LgEa4f4KRz for ; Wed, 16 Oct 2013 08:48:10 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1B211E82DF for ; Wed, 16 Oct 2013 08:48:10 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id r9GFm5HG007183; Wed, 16 Oct 2013 09:48:06 -0600 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Wed, 16 Oct 2013 09:48:05 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.03.0146.000; Wed, 16 Oct 2013 09:48:05 -0600 From: Daryl Malas To: "Francois Le Faucheur (flefauch)" Thread-Topic: [CDNi] CDNI Framework WG Chair Review - Part 1 Thread-Index: AQHOylybZtFTk3rhOkSYOYXGDyv3dJn3eXcA Date: Wed, 16 Oct 2013 15:48:04 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.5.0.27] Content-Type: multipart/alternative; boundary="_000_CE8410C5129C9dmalascablelabscom_" MIME-Version: 1.0 X-Approved: ondar Cc: "cdni@ietf.org" Subject: Re: [CDNi] CDNI Framework WG Chair Review - Part 1 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 16 Oct 2013 15:48:15 -0000 --_000_CE8410C5129C9dmalascablelabscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable In line... From: "Francois Le Faucheur (flefauch)" > Date: Wednesday, October 16, 2013 4:43 AM To: Daryl Malas > Cc: "Francois Le Faucheur (flefauch)" >, "cdni@ietf.org" > Subject: Re: [CDNi] CDNI Framework WG Chair Review - Part 1 Daryl, Larry and all, Thoughts embedded below about two comments. I personally agree with all other comments/suggestions from Daryl. Section 2.1.1 =96 What is the purpose of stating, "...although the user is free to choose other DNS servers (e.g., OpenDNS, Google Public DNS)." I suggest we remove that. I don't think it adds any value to the explanati= on. I think it is useful to convey the idea that the user may be using a "DNS" = that is fairly local (ie whose location provides some hint about where the = enduser itself is located) or a non-local DNS (ie whose location is complet= ly un-correlated with the enduser location). This helps understanding the s= ubsequent paragraph bringing up the inaccucary drawback of the DNS method. However, the text in the subsequent paragraph is currently inconsistent bec= ause it only mentions the case of the LDNS: "On the other hand, DNS redirection is problematic because the DNS request comes from the LDNS server, not the end-user. " This may have to do with an ambiguous use of the term "LDNS". My suggestion is that the edited text: * indicates that the user can use different DNS servers * with some DNS servers (eg DNS server run by network operator), the locati= on of the DNS server may provide some indication of the enduser location. W= ith some DNS servers (eg global DNS server), it does not. * DNS redirection only sees the IP address of teh DNS server and not enduse= r and therefore has limited or no information on enduser location which aff= ects redirection accuracy. [DM] OK. Page 12 =96 The example on step 7 seems redundant with step 4. I understan= d the step, but I think the example seems redundant. I suggest changing th= e example. I don't see why step 4 and 7 are redundant. Step 4 is using Redirection Int= erface while Step 7 is over Metadata Interface. [DM] The example use of the interfaces is what I'm contending is redundant.= There are other uses of the Metadata Interface, so I suggest expanding th= e example rather than repeating the purpose with a different interface. Ye= s, it works. I'm just suggesting we avoid redundancy across interfaces in = order to make the example more "interesting." Francois --_000_CE8410C5129C9dmalascablelabscom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
In line...

From: "Francois Le Faucheur (f= lefauch)" <flefauch@cisco.com= >
Date: Wednesday, October 16, 2013 4= :43 AM
To: Daryl Malas <d.malas@cablelabs.com>
Cc: "Francois Le Faucheur (fle= fauch)" <flefauch@cisco.com>, "cdni@ietf.org" <= cdni@ietf.org>
Subject: Re: [CDNi] CDNI Framework = WG Chair Review - Part 1

Daryl, Larry and all,

Thoughts embedded below about two comments. 
I personally agree with all other comments/suggestions from Daryl.


Section 2.1.1 =96 What is the purpose of stating, "...although th= e user is
free to choose other DNS servers (e.g., OpenDNS, Google Public DNS).&q= uot;

I suggest we remove that.  I don't think it adds any value to the= explanation.

I think it is useful to convey the idea that the user may be using a &= quot;DNS" that is fairly local (ie whose location provides some hint a= bout where the enduser itself is located) or a non-local DNS (ie whose= location is completly un-correlated with the enduser location). This helps understanding the subsequent paragraph bringing up t= he inaccucary drawback of the DNS method.

However, the text in the subsequent paragraph is currently inconsisten= t because it only mentions the case of the LDNS:
"On the other hand, DNS redirection is
   problematic because the DNS request comes from the LDNS server= , not
   the end-user. 
"
This may have to do with an ambiguous use of the term "LDNS"= .

My suggestion is that the edited text:
* indi= cates that the user can use different DNS servers
* with= some DNS servers (eg DNS server run by network operator), the location of = the DNS server may provide some indication of the enduser location. With so= me DNS servers (eg global DNS server), it does not.
* DNS = redirection only sees the IP address of teh DNS server and not enduser and = therefore has limited or no information on enduser location which affects r= edirection accuracy.

[DM] OK.


Page 12 =96 The example on step 7 seems redundant with step 4.  I= understand the step, but I think the example seems redundant.  I sugg= est changing the example.

I don't see why step 4 and 7 are redundant. Step 4 is using Redirectio= n Interface while Step 7 is over Metadata Interface.

[DM] The example use of the interfaces is what I'm contending is redun= dant.  There are other uses of the Metadata Interface, so I suggest ex= panding the example rather than repeating the purpose with a different inte= rface.  Yes, it works.  I'm just suggesting we avoid redundancy across interfaces in order to make the example more &q= uot;interesting."

Francois
 --_000_CE8410C5129C9dmalascablelabscom_-- From iuniana.oprescu@orange.com Thu Oct 17 01:06:51 2013 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 8C77D11E810F for ; Thu, 17 Oct 2013 01:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UARSbZfGjCqI for ; Thu, 17 Oct 2013 01:06:47 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 0701A11E8107 for ; Thu, 17 Oct 2013 01:06:30 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 485D219023D; Thu, 17 Oct 2013 10:06:29 +0200 (CEST) Received: from pmexch31.intranet-paris.francetelecom.fr (unknown [10.100.76.21]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 17C77384061; Thu, 17 Oct 2013 10:06:29 +0200 (CEST) Received: from PMEXCB1D.intranet-paris.francetelecom.fr ([10.100.76.13]) by pmexch31.intranet-paris.francetelecom.fr ([10.100.76.21]) with mapi; Thu, 17 Oct 2013 10:06:28 +0200 From: To: "Kent Leung (kleung)" , "Francois Le Faucheur (flefauch)" , Ben Niven-Jenkins Date: Thu, 17 Oct 2013 10:06:29 +0200 Thread-Topic: [CDNi] SEC-4 in in draft-ietf-cdni-requirements Thread-Index: AQHOxcIi0D1l2Tya00O4QpS5GM3BypnzvYyAgAC/DwCAAaqrQIAAA2nAgAJpRsA= Message-ID: <2183_1381997189_525F9A85_2183_19123_1_8F0D2F5E4AAB7249BC7339A3E944DEDD2267C49AF1@PMEXCB1D.intranet-paris.francetelecom.fr> References: <48474D18-F627-4FE2-B098-41B9E93C6E73@niven-jenkins.co.uk> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.10.17.3915 Cc: "" , Yiu Lee Subject: Re: [CDNi] SEC-4 in in draft-ietf-cdni-requirements X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 17 Oct 2013 08:06:52 -0000 I think it's a bit complicated, maybe replace the second phrase with someth= ing like: This would ensure that the Downstream CDN cannot repudiate transmitted Log = records, therefore discouraging the dCDN from spoofing a transaction log (a= ttempting to appear as if it corresponds to a request redirected by the Ups= tream CDN when that request has not been redirected by this Upstream CDN).= =20 -----Message d'origine----- De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de Ken= t Leung (kleung) Envoy=E9 : mardi 15 octobre 2013 21:18 =C0 : Francois Le Faucheur (flefauch); Ben Niven-Jenkins Cc : ; Yiu Lee Objet : Re: [CDNi] SEC-4 in in draft-ietf-cdni-requirements Oops. This is the requirement text to confirm: " SEC-4 [MED] The CDNI solution should be able to ensure non-repudiation by = the Downstream CDN of transaction logs generated by the Downstream CDN and = communicated to an Upstream CDN. This would ensure that the Downstream CDN = cannot repudiate transmitted Log records, and therefore act as a disincenti= ve for the dCDN to spoof a transaction log (attempting to appear as if it c= orresponds to a request redirected by the Upstream CDN when that request ha= s not been redirected by this Upstream CDN). " Kent -----Original Message----- From: Kent Leung (kleung) Sent: Tuesday, October 15, 2013 12:12 PM To: Francois Le Faucheur (flefauch); Ben Niven-Jenkins Cc: Yiu Lee; Subject: RE: [CDNi] SEC-4 in in draft-ietf-cdni-requirements Good discussion. So, do we have agreement to update the requirement with th= e following? "SEC-4 [MED] The CDNI solution should be able to ensure non-repudiation by= the Downstream CDN of transaction logs generated by the Downstream CDN and= communicated to an Upstream CDN. This would ensure that the Downstream CDN= cannot repudiate transmitted Log records, and therefore reduces the incent= ive for the dCDN to spoof a transaction log (attempting to appear as if it = corresponds to a request redirected by the Upstream CDN when that request h= as not been redirected by this Upstream CDN)." Kent -----Original Message----- From: Francois Le Faucheur (flefauch) Sent: Monday, October 14, 2013 5:38 AM To: Ben Niven-Jenkins Cc: Francois Le Faucheur (flefauch); Kent Leung (kleung); Yiu Lee; Subject: Re: [CDNi] SEC-4 in in draft-ietf-cdni-requirements On 14 Oct 2013, at 03:13, Ben Niven-Jenkins wrote: > Francois, Colleagues, >=20 > On 10 Oct 2013, at 15:08, Francois Le Faucheur (flefauch) wrote: >=20 >> Kent, Liu, >>=20 >> " >> SEC-4 [MED] The CDNI solution should be able to ensure that the >> Downstream CDN cannot spoof a transaction log attempting to >> appear as if it corresponds to a request redirected by a given >> Upstream CDN when that request has not been redirected by this >> Upstream CDN. This ensures non-repudiation by the Upstream >> CDN of transaction logs generated by the Downstream CDN for >> deliveries performed by the Downstream CDN on behalf of the >> Upstream CDN. >> " >> I think this requirement does not reflect correctly how non-repudiation = could play in teh context of CDNI Logging. For example, since the logging i= nformation is sent by dCDN to uCDN, it only makes sense to talk about non-r= epudiation by dCDN, not by uCDN. >>=20 >> I suggest a rewording along the lines of:=20 >>=20 >> " >> SEC-4 [MED] The CDNI solution should be able to ensure non-repudiation = by the Downstream >> CDN of transaction logs generated by the Downstream CDN and comm= unicated to an Upstream CDN. This reduces the incentives for the Downstream= CDN to spoof a transaction log attempting to appear as if it corresponds t= o a request redirected by the Upstream CDN when that request has not been r= edirected by this Upstream CDN. >> " >=20 > I don't see how the second sentence leads from the first. I.e. I don't se= e how a dCDN having the ability to ensure logs that it has generated are no= t modified reduces the dCDN's incentive to spoof (or not to spoof) log entr= ies. What non-repudiation brings is the fact that the dCDN can not dispute havin= g sent a particular Log Record (and have it sent exactly as recieved by the= uCDN). So a dCDN that is caught sending a CDNI Logging file with invalid records (= and the proof for that would have to be established via some other mechanis= m, such as for example contrasting it to CSP logs generated from end-device= s) can not just say "oh, I never sent that file, you must have done somethi= ng wrong yourself and generated/corrupted that logging record/file yourself= ". Basically, it brings traceability which generally helps keeping people h= onest. It is an open question as to whether such a non-repudiation mechanis= m brings sufficient value or not. Some argued "yes", which is why we have a= requirement for it. But that is a separate question.=20 Perhaps we should not say that "it reduces the incentive", but rather that = it creates a disincentive to cheat.=20 Perhaps this wording may help make things a little clearer: " SEC-4 [MED] The CDNI solution should be able to ensure non-repudiation by = the Downstream CDN of transaction logs generated by the Downstream CDN and = communicated to an Upstream CDN. This would ensure that the Downstream CDN = can not repudiate transmitted Log records, and therefore act as a disincent= ive for the dCDN to spoof a transaction log (attempting to appear as if it = corresponds to a request redirected by the Upstream CDN when that request h= as not been redirected by this Upstream CDN). " >=20 > Maybe just drop the second sentence entirely? >=20 That woudl be an easy way out, but it is clearly far from trivial to articu= late the rationale for including a requirement about non-repudiatin, I thin= k we need to record teh rationale. Otherwise, the question will most likely= come up come up at review time down the pipe. Cheers Francois > Ben >=20 _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From flefauch@cisco.com Thu Oct 17 02:51:41 2013 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 3DD2811E8262 for ; Thu, 17 Oct 2013 02:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.566 X-Spam-Level: X-Spam-Status: No, score=-10.566 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWdEYx-tOR0A for ; Thu, 17 Oct 2013 02:51:36 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 31ECA11E8250 for ; Thu, 17 Oct 2013 02:51:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7690; q=dns/txt; s=iport; t=1382003493; x=1383213093; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=TrGjo4FQT/SBqGJHDPPMD6lTXXVmx6gcTHjOkCM2gy4=; b=T8eOKOy5rx3fMHo0M9qkl0877pJbCRRzCx30bUYRK324ZAFBCMf7ihyq zSw+jHqmoS/i0ZIXu9ly0dhYBy6y5YJ7D+y8XyN7E/bOLtDpB1DV4WBZW MqlcY7N2uiJ7hg29Vt+xFdnBI43Yf6Xcckg9kfwhOP4tWgDOIddN6Qizg M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8GAMyyX1KtJXG8/2dsb2JhbABagwc4Ur4AgSAWbQeCJQEBAQMBAQEBawsFBwQCAQgRBAEBAQodBycLFAkIAgQOBQgTh2UGDL91BI4IgRYCMQcGgxmBBwOJBKEGgySBcDk X-IronPort-AV: E=Sophos;i="4.93,513,1378857600"; d="scan'208";a="87463016" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by ams-iport-2.cisco.com with ESMTP; 17 Oct 2013 09:51:30 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9H9pUZ0026616 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Oct 2013 09:51:30 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.33]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Thu, 17 Oct 2013 04:51:29 -0500 From: "Francois Le Faucheur (flefauch)" To: "iuniana.oprescu@orange.com" Thread-Topic: [CDNi] SEC-4 in in draft-ietf-cdni-requirements Thread-Index: AQHOxcIi0D1l2Tya00O4QpS5GM3Byg== Date: Thu, 17 Oct 2013 09:51:28 +0000 Message-ID: References: <48474D18-F627-4FE2-B098-41B9E93C6E73@niven-jenkins.co.uk> <2183_1381997189_525F9A85_2183_19123_1_8F0D2F5E4AAB7249BC7339A3E944DEDD2267C49AF1@PMEXCB1D.intranet-paris.francetelecom.fr> In-Reply-To: <2183_1381997189_525F9A85_2183_19123_1_8F0D2F5E4AAB7249BC7339A3E944DEDD2267C49AF1@PMEXCB1D.intranet-paris.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.206] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1AF39E585F4B3A4081492463D6F28ACB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Yiu Lee Subject: Re: [CDNi] SEC-4 in in draft-ietf-cdni-requirements X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 17 Oct 2013 09:51:41 -0000 On 17 Oct 2013, at 10:06, iuniana.oprescu@orange.com wrote: > I think it's a bit complicated, maybe replace the second phrase with some= thing like: >=20 > This would ensure that the Downstream CDN cannot repudiate transmitted Lo= g records, therefore discouraging the dCDN from spoofing a transaction log = (attempting to appear as if it corresponds to a request redirected by the U= pstream CDN when that request has not been redirected by this Upstream CDN)= .=20 I also like this wording better. Francois >=20 > -----Message d'origine----- > De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de K= ent Leung (kleung) > Envoy=E9 : mardi 15 octobre 2013 21:18 > =C0 : Francois Le Faucheur (flefauch); Ben Niven-Jenkins > Cc : ; Yiu Lee > Objet : Re: [CDNi] SEC-4 in in draft-ietf-cdni-requirements >=20 > Oops. This is the requirement text to confirm: >=20 > " > SEC-4 [MED] The CDNI solution should be able to ensure non-repudiation b= y the Downstream CDN of transaction logs generated by the Downstream CDN an= d communicated to an Upstream CDN. This would ensure that the Downstream CD= N cannot repudiate transmitted Log records, and therefore act as a disincen= tive for the dCDN to spoof a transaction log (attempting to appear as if it= corresponds to a request redirected by the Upstream CDN when that request = has not been redirected by this Upstream CDN). > " >=20 > Kent >=20 > -----Original Message----- > From: Kent Leung (kleung) > Sent: Tuesday, October 15, 2013 12:12 PM > To: Francois Le Faucheur (flefauch); Ben Niven-Jenkins > Cc: Yiu Lee; > Subject: RE: [CDNi] SEC-4 in in draft-ietf-cdni-requirements >=20 > Good discussion. So, do we have agreement to update the requirement with = the following? >=20 > "SEC-4 [MED] The CDNI solution should be able to ensure non-repudiation = by the Downstream CDN of transaction logs generated by the Downstream CDN a= nd communicated to an Upstream CDN. This would ensure that the Downstream C= DN cannot repudiate transmitted Log records, and therefore reduces the ince= ntive for the dCDN to spoof a transaction log (attempting to appear as if i= t corresponds to a request redirected by the Upstream CDN when that request= has not been redirected by this Upstream CDN)." >=20 > Kent >=20 > -----Original Message----- > From: Francois Le Faucheur (flefauch) > Sent: Monday, October 14, 2013 5:38 AM > To: Ben Niven-Jenkins > Cc: Francois Le Faucheur (flefauch); Kent Leung (kleung); Yiu Lee; > Subject: Re: [CDNi] SEC-4 in in draft-ietf-cdni-requirements >=20 >=20 > On 14 Oct 2013, at 03:13, Ben Niven-Jenkins > wrote: >=20 >> Francois, Colleagues, >>=20 >> On 10 Oct 2013, at 15:08, Francois Le Faucheur (flefauch) wrote: >>=20 >>> Kent, Liu, >>>=20 >>> " >>> SEC-4 [MED] The CDNI solution should be able to ensure that the >>> Downstream CDN cannot spoof a transaction log attempting to >>> appear as if it corresponds to a request redirected by a given >>> Upstream CDN when that request has not been redirected by this >>> Upstream CDN. This ensures non-repudiation by the Upstream >>> CDN of transaction logs generated by the Downstream CDN for >>> deliveries performed by the Downstream CDN on behalf of the >>> Upstream CDN. >>> " >>> I think this requirement does not reflect correctly how non-repudiation= could play in teh context of CDNI Logging. For example, since the logging = information is sent by dCDN to uCDN, it only makes sense to talk about non-= repudiation by dCDN, not by uCDN. >>>=20 >>> I suggest a rewording along the lines of:=20 >>>=20 >>> " >>> SEC-4 [MED] The CDNI solution should be able to ensure non-repudiation= by the Downstream >>> CDN of transaction logs generated by the Downstream CDN and comm= unicated to an Upstream CDN. This reduces the incentives for the Downstream= CDN to spoof a transaction log attempting to appear as if it corresponds t= o a request redirected by the Upstream CDN when that request has not been r= edirected by this Upstream CDN. >>> " >>=20 >> I don't see how the second sentence leads from the first. I.e. I don't s= ee how a dCDN having the ability to ensure logs that it has generated are n= ot modified reduces the dCDN's incentive to spoof (or not to spoof) log ent= ries. >=20 > What non-repudiation brings is the fact that the dCDN can not dispute hav= ing sent a particular Log Record (and have it sent exactly as recieved by t= he uCDN). >=20 > So a dCDN that is caught sending a CDNI Logging file with invalid records= (and the proof for that would have to be established via some other mechan= ism, such as for example contrasting it to CSP logs generated from end-devi= ces) can not just say "oh, I never sent that file, you must have done somet= hing wrong yourself and generated/corrupted that logging record/file yourse= lf". Basically, it brings traceability which generally helps keeping people= honest. It is an open question as to whether such a non-repudiation mechan= ism brings sufficient value or not. Some argued "yes", which is why we have= a requirement for it. But that is a separate question.=20 >=20 > Perhaps we should not say that "it reduces the incentive", but rather tha= t it creates a disincentive to cheat.=20 >=20 > Perhaps this wording may help make things a little clearer: > " > SEC-4 [MED] The CDNI solution should be able to ensure non-repudiation b= y the Downstream CDN of transaction logs generated by the Downstream CDN an= d communicated to an Upstream CDN. This would ensure that the Downstream CD= N can not repudiate transmitted Log records, and therefore act as a disince= ntive for the dCDN to spoof a transaction log (attempting to appear as if i= t corresponds to a request redirected by the Upstream CDN when that request= has not been redirected by this Upstream CDN). > " >=20 >>=20 >> Maybe just drop the second sentence entirely? >>=20 >=20 > That woudl be an easy way out, but it is clearly far from trivial to arti= culate the rationale for including a requirement about non-repudiatin, I th= ink we need to record teh rationale. Otherwise, the question will most like= ly come up come up at review time down the pipe. >=20 > Cheers >=20 > Francois >=20 >> Ben >>=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 From mcaulfie@cisco.com Thu Oct 17 11:11:00 2013 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 1BB2211E8191 for ; Thu, 17 Oct 2013 11:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KpBEz+mi9R5 for ; Thu, 17 Oct 2013 11:10:55 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id DA6A811E82C5 for ; Thu, 17 Oct 2013 11:10:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1575; q=dns/txt; s=iport; t=1382033422; x=1383243022; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Hoq1WdEN/QL+PiUYuuwwEHySS+EenVkl/cM4HsSio5s=; b=SOOvrsECDqqeVvcSmQ9HpfJRsYQBfzkTjBEQpcCAQsl9q+YU4RHK9rws 6GOmMLCswF9JLAS2xwr0PQAIgvkzeaW+K3bMHd7MAGccJ00q80tV/nXCc xh83Clg18hwcWbI6x3N8bEFFl3+9WPkxLMQfIZS6jj5svROVSeE9Il6X6 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AksFANMmYFKtJXG8/2dsb2JhbABagwc4Ur4HgSgWdIIlAQEBBAEBATc0CwwEAgEIEQQBAQsUCQcnCxQJCAIEAQ0FCId+DMBtBI4IgRgxBwaDGYEHA6oKgySBcDk X-IronPort-AV: E=Sophos;i="4.93,515,1378857600"; d="scan'208";a="273440941" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 17 Oct 2013 18:10:21 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9HIALgA004273 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Oct 2013 18:10:21 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.192]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Thu, 17 Oct 2013 13:10:21 -0500 From: "Matt Caulfield (mcaulfie)" To: "Francois Le Faucheur (flefauch)" , "draft-ietf-cdni-metadata@tools.ietf.org" Thread-Topic: Next rev of cdni-metadata for Vancouver Thread-Index: AQHOyk+LoLpovSpvWEy1johhSkxHqJn5M1zA Date: Thu, 17 Oct 2013 18:10:20 +0000 Message-ID: <166EBB70C264A9479E459B01B1BA6C921DDA39A9@xmb-aln-x03.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.131.76.237] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Next rev of cdni-metadata for Vancouver X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 17 Oct 2013 18:11:00 -0000 Yes, a new revision of the Metadata Interface will be posted by Monday refl= ecting the action items from Berlin. -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Fra= ncois Le Faucheur (flefauch) Sent: Wednesday, October 16, 2013 5:10 AM To: draft-ietf-cdni-metadata@tools.ietf.org Cc: cdni@ietf.org Subject: [CDNi] Next rev of cdni-metadata for Vancouver Dear authors of cdni-metadata, We are fast approaching the I-D dealine (next Monday). Can you please confi= rm that you plan to post an updated rev reflecting the discussions/agreemen= ts from Berlin? For memory, the updated target date for submission of cdni-metadata to IESG= is Dec 2013, which means we want to target WG Last Call on the version for= Vancouver or on an update shortly after. Thanks Francois & Daryl PS: For convenience below is an excerpt from Berlin minutes, discussing one= of the most important open items ie ensure enough coverage of HTTP deliver= y: " - Kevin, Ben, Matt - agreed to make sure there's enough in the draft to all= ow base HTTP delivery before going to WG last call - Francois - use the cdni email list if there is disagreement about what ex= actly is needed to allow base HTTP delivery - Francois - we will need confirmation from authors that the MI spec does c= over what is needed for HTTP delivery before we can consider moving to WG L= ast Call " _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From ietf-secretariat-reply@ietf.org Thu Oct 17 13:28:59 2013 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 B5D1111E8244 for ; Thu, 17 Oct 2013 13:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.458 X-Spam-Level: X-Spam-Status: No, score=-102.458 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvoWvG+asIIA for ; Thu, 17 Oct 2013 13:28:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C394211E825E for ; Thu, 17 Oct 2013 13:28:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: cdni@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131017202852.32613.71527.idtracker@ietfa.amsl.com> Date: Thu, 17 Oct 2013 13:28:52 -0700 From: IETF Secretariat X-Mailman-Approved-At: Thu, 17 Oct 2013 13:49:03 -0700 Subject: [CDNi] Milestones changed for cdni WG X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 17 Oct 2013 20:28:59 -0000 Changed milestone "Submit specification of URI Signing for CDNI to IESG as Proposed Standard", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/cdni/charter/ From ietf-secretariat-reply@ietf.org Thu Oct 17 13:34:36 2013 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 232E411E8235 for ; Thu, 17 Oct 2013 13:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.458 X-Spam-Level: X-Spam-Status: No, score=-102.458 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mG5DhApm5-U4 for ; Thu, 17 Oct 2013 13:34:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A383111E8121 for ; Thu, 17 Oct 2013 13:34:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: cdni@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131017203435.32595.46032.idtracker@ietfa.amsl.com> Date: Thu, 17 Oct 2013 13:34:35 -0700 From: IETF Secretariat X-Mailman-Approved-At: Thu, 17 Oct 2013 13:49:03 -0700 Subject: [CDNi] Milestones changed for cdni WG X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 17 Oct 2013 20:34:36 -0000 Changed milestone "Submit specification of the CDNI Metadata Distribution interface to IESG as Proposed Standard", set description to "Submit specification of the CDNI Metadata interface to IESG as Proposed Standard". Changed milestone "Submit specification of the CDNI Request Routing/Redirection interface to IESG as Proposed Standard", set description to "Submit specification of the CDNI Request Routing Redirection interface to IESG as Proposed Standard". Changed milestone "Submit specification of the CDNI Request Routing/Footprint & Capabilities Advertisement interface to IESG as Proposed Standard", set description to "Submit specification of the CDNI Footprint & Capabilities Advertisement interface to IESG as Proposed Standard". URL: http://datatracker.ietf.org/wg/cdni/charter/ From internet-drafts@ietf.org Fri Oct 18 01:51:40 2013 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 EC95E21F9FE9; Fri, 18 Oct 2013 01:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhsAeItLlu6j; Fri, 18 Oct 2013 01:51:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D99BE21F9C46; Fri, 18 Oct 2013 01:51:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131018085137.2277.50053.idtracker@ietfa.amsl.com> Date: Fri, 18 Oct 2013 01:51:37 -0700 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-logging-08.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 18 Oct 2013 08:51:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Content Delivery Networks Interconnection= Working Group of the IETF. Title : CDNI Logging Interface Author(s) : Francois Le Faucheur Gilles Bertrand Iuniana Oprescu Roy Peterkofsky Filename : draft-ietf-cdni-logging-08.txt Pages : 46 Date : 2013-10-18 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: http://tools.ietf.org/html/draft-ietf-cdni-logging-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-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 flefauch@cisco.com Fri Oct 18 02:08:56 2013 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 08F1411E816B for ; Fri, 18 Oct 2013 02:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKlG+5VnIX6w for ; Fri, 18 Oct 2013 02:08:51 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id C16BA11E8108 for ; Fri, 18 Oct 2013 02:08:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3066; q=dns/txt; s=iport; t=1382087327; x=1383296927; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=dxoBZ6dF1q56+NME6bQqQ/cWyFoBe1uFoMmYY4cPA3I=; b=J6SNq91AXFzpbCnAZkOlvYCTAtNDxfkM/uKdD+DEcxQlglQOacLQuli2 UZp1mZhvEpfu6/WRHfplk/qxcycocsw2LPIDtUQYMO1Rd17L+ARq6BNQo ss/XjnVX/42QOLlAeP82f60JN3CrpdexXnRIEjB11CU4tCTmErSAQ0oGo U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AncGAIP5YFKtJXG//2dsb2JhbABagwc4TAa+F4EjFm0HgiUBAQEDAQEBATc0GwIBCCIUECcLJQIEEwgBh3cGBwXAT48eAjiDH4EKA5k4kFiDJIIp X-IronPort-AV: E=Sophos;i="4.93,521,1378857600"; d="scan'208";a="273677518" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 18 Oct 2013 09:08:47 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9I98lkW010556 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 18 Oct 2013 09:08:47 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.33]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Fri, 18 Oct 2013 04:08:46 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-logging-08.txt Thread-Index: AQHOy99FrWtFMN9znk6xt6jJGGMi8Jn6f16A Date: Fri, 18 Oct 2013 09:08:45 +0000 Message-ID: References: <20131018085137.2277.50053.idtracker@ietfa.amsl.com> In-Reply-To: <20131018085137.2277.50053.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.206] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-logging-08.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 18 Oct 2013 09:08:56 -0000 Folks, (as a co-author) The key changes from -07 to -08 are: * replaced the integrity-hash value in CDNI Logging File example with the = correct value computed on the actual Logging file content * reflected discussion/agreement on the list about situation where the dCD= N no longer wants to make old CDNI Logging file available * tweaked the example times in the CDNI Logging Feed example * changed "MUST" into "MAY" in "A client-side implementation of the CDNI L= ogging interface MAY pull, at its convenience, a CDNI Logging File". This i= s because it is up to a client to decide if/when they want t o pull logging= files. * added a sub-section on DoS in Security Considerations, as a result of re= viewing compliance against the Security related requirements of cdni-requir= ements. * corrected compliance to SEC-2 from "Full" to "partial" since no specific= mechanisms are defined in spec against DOS * added editor's note clarifying that the Appendix reviewing compliance to= cdni-requirements is expecte dto be removed before publication. * editos/typos * updated Ack section >From the authors viewpoint, the document is now ready to move to WG Last Ca= ll and we plan to poll the WG in Vancouver about doing so. Cheers Francois & co-authors On 18 Oct 2013, at 10:51, wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Content Delivery Networks Interconnectio= n Working Group of the IETF. >=20 > Title : CDNI Logging Interface > Author(s) : Francois Le Faucheur > Gilles Bertrand > Iuniana Oprescu > Roy Peterkofsky > Filename : draft-ietf-cdni-logging-08.txt > Pages : 46 > Date : 2013-10-18 >=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: > http://tools.ietf.org/html/draft-ietf-cdni-logging-08 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-08 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > 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 D.Malas@cablelabs.com Fri Oct 18 18:51:44 2013 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 E1AF411E8115 for ; Fri, 18 Oct 2013 18:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.963 X-Spam-Level: X-Spam-Status: No, score=-100.963 tagged_above=-999 required=5 tests=[AWL=-0.499, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zbbscmrjl2lz for ; Fri, 18 Oct 2013 18:51:40 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3B021F9D9A for ; Fri, 18 Oct 2013 18:51:37 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id r9J1pVJa016741; Fri, 18 Oct 2013 19:51:31 -0600 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Fri, 18 Oct 2013 19:51:31 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.03.0146.000; Fri, 18 Oct 2013 19:51:31 -0600 From: Daryl Malas To: "Francois Le Faucheur (flefauch)" , "cdni@ietf.org" Thread-Topic: [CDNi] RE: Vancouver CDNI WG Slot requests Thread-Index: AQHOzG27wIEREQ0nVEu64ya6NpUwwQ== Date: Sat, 19 Oct 2013 01:51:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.5.0.27] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: [CDNi] RE: Vancouver CDNI WG Slot requests X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 19 Oct 2013 01:51:45 -0000 As a reminder, please send your agenda slot requests as soon as possible. Thanks, Daryl & Francois ________________________________________ From: Francois Le Faucheur (flefauch) [flefauch@cisco.com] Sent: Wednesday, October 16, 2013 3:26 AM To: cdni@ietf.org Cc: Francois Le Faucheur (flefauch); Daryl Malas Subject: Vancouver CDNI WG Slot requests All, Please unicast your slot request to Daryl and I by Monday 21 October (earli= er is better). Thanks Francois & Daryl PS: As per final agenda (https://datatracker.ietf.org/meeting/88/agenda.htm= l), the CDNI WG will hold a single session: * Thursday Nov 7, 1520-1720 PST.= From internet-drafts@ietf.org Mon Oct 21 02:10:01 2013 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 3933911E8192; Mon, 21 Oct 2013 02:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l874Pz3kdisb; Mon, 21 Oct 2013 02:09:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 244A021F9FD5; Mon, 21 Oct 2013 02:09:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021090951.8729.10067.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 02:09:51 -0700 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-control-triggers-01.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 09:10:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Content Delivery Networks Interconnection= Working Group of the IETF. Title : CDNI Control Interface / Triggers Author(s) : Rob Murray Ben Niven-Jenkins Filename : draft-ietf-cdni-control-triggers-01.txt Pages : 35 Date : 2013-10-21 Abstract: This document describes the part of the CDN Interconnect Control Interface that allows a CDN to trigger activity in an interconnected CDN that is configured to deliver content on its behalf. The upstream CDN can use this mechanism to request that the downstream CDN pre-positions metadata or content, or that it re-validate or purge metadata or content. The upstream CDN can monitor the status of activity that it has triggered in the downstream CDN. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-control-triggers There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-control-triggers-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-control-triggers-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Oct 21 02:32:24 2013 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 5252C11E84EE; Mon, 21 Oct 2013 02:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aR3J+QWT+3a2; Mon, 21 Oct 2013 02:32:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 619B121F9F0A; Mon, 21 Oct 2013 02:30:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021093041.29508.98885.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 02:30:41 -0700 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-redirection-01.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 09:32:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Content Delivery Networks Interconnection= Working Group of the IETF. Title : Request Routing Redirection Interface for CDN Interconne= ction Author(s) : Wang Danhua Ben Niven-Jenkins He Xiaoyan Ge Chen Ni Wei Filename : draft-ietf-cdni-redirection-01.txt Pages : 24 Date : 2013-10-21 Abstract: The Request Routing Interface comprises of (1) the asynchronous advertisement of footprint and capabilities by a downstream CDN that allows a upstream CDN to decide whether to redirect particular user requests to that downstream CDN; and (2) the synchronous operation of an upstream CDN requesting whether a downstream CDN is prepared to accept a user request and of a downstream CDN responding with how to actually redirect the user request. This document describes an interface for the latter part, i.e. the CDNI request routing/ Redirection Interface. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-redirection There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-redirection-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-redirection-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ben@niven-jenkins.co.uk Mon Oct 21 03:30:48 2013 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 A7F7911E84D0 for ; Mon, 21 Oct 2013 03:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ac7hU7nNywjt for ; Mon, 21 Oct 2013 03:30:42 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4FB11E839A for ; Mon, 21 Oct 2013 03:28:21 -0700 (PDT) Received: from cpc4-cmbg17-2-0-cust814.5-4.cable.virginmedia.com ([86.14.227.47] helo=[192.168.0.4]) by mail10.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1VYCht-0005Bk-71 for cdni@ietf.org; Mon, 21 Oct 2013 11:27:29 +0100 From: Ben Niven-Jenkins Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Oct 2013 11:27:28 +0100 References: <20131021093041.29508.98885.idtracker@ietfa.amsl.com> To: cdni@ietf.org Message-Id: <0936B164-79A1-48D7-B702-3B98E8486861@niven-jenkins.co.uk> Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Subject: [CDNi] Fwd: I-D Action: draft-ietf-cdni-redirection-01.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 10:30:49 -0000 Colleagues, This is an update to the redirection interface specification to add = additional editorial text around data plane loop detection, media types = to use, the JSON encoding and the security considerations. There are still some things outstanding within the document but any = review or suggestions for additional text would be most welcome :-) Ben Begin forwarded message: > From: internet-drafts@ietf.org > Date: 21 October 2013 10:30:41 GMT+01:00 > To: i-d-announce@ietf.org > Cc: cdni@ietf.org > Subject: [CDNi] I-D Action: draft-ietf-cdni-redirection-01.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 = Interconnection Working Group of the IETF. >=20 > Title : Request Routing Redirection Interface for CDN = Interconnection > Author(s) : Wang Danhua > Ben Niven-Jenkins > He Xiaoyan > Ge Chen > Ni Wei > Filename : draft-ietf-cdni-redirection-01.txt > Pages : 24 > Date : 2013-10-21 >=20 > Abstract: > The Request Routing Interface comprises of (1) the asynchronous > advertisement of footprint and capabilities by a downstream CDN that > allows a upstream CDN to decide whether to redirect particular user > requests to that downstream CDN; and (2) the synchronous operation = of > an upstream CDN requesting whether a downstream CDN is prepared to > accept a user request and of a downstream CDN responding with how to > actually redirect the user request. This document describes an > interface for the latter part, i.e. the CDNI request routing/ > Redirection Interface. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-cdni-redirection >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-cdni-redirection-01 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-redirection-01 >=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 internet-drafts@ietf.org Mon Oct 21 08:02:00 2013 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 4C99611E85EA; Mon, 21 Oct 2013 08:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOVEs5liPMeJ; Mon, 21 Oct 2013 08:01:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 01B3D11E85ED; Mon, 21 Oct 2013 08:01:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021150154.29521.77690.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 08:01:54 -0700 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-framework-06.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 15:02:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Content Delivery Networks Interconnection= Working Group of the IETF. Title : Framework for CDN Interconnection Author(s) : Larry Peterson Bruce Davie Filename : draft-ietf-cdni-framework-06.txt Pages : 52 Date : 2013-10-21 Abstract: This document presents a framework for Content Distribution Network Interconnection (CDNI). The purpose of the framework is to provide an overall picture of the problem space of CDNI and to describe the relationships among the various components necessary to interconnect CDNs. CDN Interconnection requires the specification of interfaces and mechanisms to address issues such as request routing, distribution metadata exchange, and logging information exchange across CDNs. The intent of this document is to outline what each interface needs to accomplish, and to describe how these interfaces and mechanisms fit together, while leaving their detailed specification to other documents. It obsoletes RFC 3466. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-framework There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-framework-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-framework-06 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 kleung@cisco.com Mon Oct 21 09:19:43 2013 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 0972111E83B4 for ; Mon, 21 Oct 2013 09:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Phnaf7BqJFtS for ; Mon, 21 Oct 2013 09:19:37 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8B86B11E81E0 for ; Mon, 21 Oct 2013 09:19:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8629; q=dns/txt; s=iport; t=1382372376; x=1383581976; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=r95Zg4Rt8HQDZ/FEsG20kYVf7xcC5BwLMMa9jgGs+nE=; b=UgWyIEz/qN4QyuIiBZ9joe3GbAVnZWt0bJ4qxkT7vRyPmr8PQP5335o6 fO4q3HRPqwZ7tiZF8AUIRkWAi3LHqOTKZvQ5yCfG5Kv1E039hoABTh6Un 2rAUA6Bwldwqd2Ib29nMyevG0bj3Mk9vPozdy6MVAo1D5F4ezEnxuvv/y I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFABNTZVKtJXG9/2dsb2JhbABZgwc4VL4vgS4WdIIlAQEBAwEBAQFrCwUHBAIBCBEEAQEBCh0HJwsUCQgCBAENBQgTh2UFAQ25cwSOE4EYMQcGgxmBCgOJB6EJgySBcTk X-IronPort-AV: E=Sophos;i="4.93,539,1378857600"; d="scan'208";a="271677373" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 21 Oct 2013 16:19:35 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9LGJZj0006624 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Oct 2013 16:19:35 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.192]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Mon, 21 Oct 2013 11:19:35 -0500 From: "Kent Leung (kleung)" To: "Francois Le Faucheur (flefauch)" , "iuniana.oprescu@orange.com" Thread-Topic: [CDNi] SEC-4 in in draft-ietf-cdni-requirements Thread-Index: AQHOxcIi0D1l2Tya00O4QpS5GM3BypnzvYyAgAC/DwCAAaqrQIAAA2nAgAJpRsCAAHE+AIAGYRoQ Date: Mon, 21 Oct 2013 16:19:35 +0000 Message-ID: References: <48474D18-F627-4FE2-B098-41B9E93C6E73@niven-jenkins.co.uk> <2183_1381997189_525F9A85_2183_19123_1_8F0D2F5E4AAB7249BC7339A3E944DEDD2267C49AF1@PMEXCB1D.intranet-paris.francetelecom.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.71.231.132] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Yiu Lee Subject: Re: [CDNi] SEC-4 in in draft-ietf-cdni-requirements X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 16:19:43 -0000 OK. Looks like there are no disagreements. I'll update the draft with the f= ollowing: SEC-4 [MED] The CDNI solution should be able to ensure non-repudiation by = the Downstream CDN of transaction logs generated by the Downstream CDN and = communicated to an Upstream CDN. This would ensure that the Downstream CDN = cannot repudiate transmitted Log records, therefore discouraging the dCDN f= rom spoofing a transaction log (attempting to appear as if it corresponds t= o a request redirected by the Upstream CDN when that request has not been r= edirected by this Upstream CDN). Kent -----Original Message----- From: Francois Le Faucheur (flefauch)=20 Sent: Thursday, October 17, 2013 2:51 AM To: iuniana.oprescu@orange.com Cc: Francois Le Faucheur (flefauch); Kent Leung (kleung); Ben Niven-Jenkins= ; ; Yiu Lee Subject: Re: [CDNi] SEC-4 in in draft-ietf-cdni-requirements On 17 Oct 2013, at 10:06, iuniana.oprescu@orange.com wrote: > I think it's a bit complicated, maybe replace the second phrase with some= thing like: >=20 > This would ensure that the Downstream CDN cannot repudiate transmitted Lo= g records, therefore discouraging the dCDN from spoofing a transaction log = (attempting to appear as if it corresponds to a request redirected by the U= pstream CDN when that request has not been redirected by this Upstream CDN)= .=20 I also like this wording better. Francois >=20 > -----Message d'origine----- > De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part=20 > de Kent Leung (kleung) Envoy=E9 : mardi 15 octobre 2013 21:18 =C0 :=20 > Francois Le Faucheur (flefauch); Ben Niven-Jenkins Cc :=20 > ; Yiu Lee Objet : Re: [CDNi] SEC-4 in in=20 > draft-ietf-cdni-requirements >=20 > Oops. This is the requirement text to confirm: >=20 > " > SEC-4 [MED] The CDNI solution should be able to ensure non-repudiation b= y the Downstream CDN of transaction logs generated by the Downstream CDN an= d communicated to an Upstream CDN. This would ensure that the Downstream CD= N cannot repudiate transmitted Log records, and therefore act as a disincen= tive for the dCDN to spoof a transaction log (attempting to appear as if it= corresponds to a request redirected by the Upstream CDN when that request = has not been redirected by this Upstream CDN). > " >=20 > Kent >=20 > -----Original Message----- > From: Kent Leung (kleung) > Sent: Tuesday, October 15, 2013 12:12 PM > To: Francois Le Faucheur (flefauch); Ben Niven-Jenkins > Cc: Yiu Lee; > Subject: RE: [CDNi] SEC-4 in in draft-ietf-cdni-requirements >=20 > Good discussion. So, do we have agreement to update the requirement with = the following? >=20 > "SEC-4 [MED] The CDNI solution should be able to ensure non-repudiation = by the Downstream CDN of transaction logs generated by the Downstream CDN a= nd communicated to an Upstream CDN. This would ensure that the Downstream C= DN cannot repudiate transmitted Log records, and therefore reduces the ince= ntive for the dCDN to spoof a transaction log (attempting to appear as if i= t corresponds to a request redirected by the Upstream CDN when that request= has not been redirected by this Upstream CDN)." >=20 > Kent >=20 > -----Original Message----- > From: Francois Le Faucheur (flefauch) > Sent: Monday, October 14, 2013 5:38 AM > To: Ben Niven-Jenkins > Cc: Francois Le Faucheur (flefauch); Kent Leung (kleung); Yiu Lee;=20 > > Subject: Re: [CDNi] SEC-4 in in draft-ietf-cdni-requirements >=20 >=20 > On 14 Oct 2013, at 03:13, Ben Niven-Jenkins > wrote: >=20 >> Francois, Colleagues, >>=20 >> On 10 Oct 2013, at 15:08, Francois Le Faucheur (flefauch) wrote: >>=20 >>> Kent, Liu, >>>=20 >>> " >>> SEC-4 [MED] The CDNI solution should be able to ensure that the >>> Downstream CDN cannot spoof a transaction log attempting to >>> appear as if it corresponds to a request redirected by a given >>> Upstream CDN when that request has not been redirected by this >>> Upstream CDN. This ensures non-repudiation by the Upstream >>> CDN of transaction logs generated by the Downstream CDN for >>> deliveries performed by the Downstream CDN on behalf of the >>> Upstream CDN. >>> " >>> I think this requirement does not reflect correctly how non-repudiation= could play in teh context of CDNI Logging. For example, since the logging = information is sent by dCDN to uCDN, it only makes sense to talk about non-= repudiation by dCDN, not by uCDN. >>>=20 >>> I suggest a rewording along the lines of:=20 >>>=20 >>> " >>> SEC-4 [MED] The CDNI solution should be able to ensure non-repudiation= by the Downstream >>> CDN of transaction logs generated by the Downstream CDN and comm= unicated to an Upstream CDN. This reduces the incentives for the Downstream= CDN to spoof a transaction log attempting to appear as if it corresponds t= o a request redirected by the Upstream CDN when that request has not been r= edirected by this Upstream CDN. >>> " >>=20 >> I don't see how the second sentence leads from the first. I.e. I don't s= ee how a dCDN having the ability to ensure logs that it has generated are n= ot modified reduces the dCDN's incentive to spoof (or not to spoof) log ent= ries. >=20 > What non-repudiation brings is the fact that the dCDN can not dispute hav= ing sent a particular Log Record (and have it sent exactly as recieved by t= he uCDN). >=20 > So a dCDN that is caught sending a CDNI Logging file with invalid records= (and the proof for that would have to be established via some other mechan= ism, such as for example contrasting it to CSP logs generated from end-devi= ces) can not just say "oh, I never sent that file, you must have done somet= hing wrong yourself and generated/corrupted that logging record/file yourse= lf". Basically, it brings traceability which generally helps keeping people= honest. It is an open question as to whether such a non-repudiation mechan= ism brings sufficient value or not. Some argued "yes", which is why we have= a requirement for it. But that is a separate question.=20 >=20 > Perhaps we should not say that "it reduces the incentive", but rather tha= t it creates a disincentive to cheat.=20 >=20 > Perhaps this wording may help make things a little clearer: > " > SEC-4 [MED] The CDNI solution should be able to ensure non-repudiation b= y the Downstream CDN of transaction logs generated by the Downstream CDN an= d communicated to an Upstream CDN. This would ensure that the Downstream CD= N can not repudiate transmitted Log records, and therefore act as a disince= ntive for the dCDN to spoof a transaction log (attempting to appear as if i= t corresponds to a request redirected by the Upstream CDN when that request= has not been redirected by this Upstream CDN). > " >=20 >>=20 >> Maybe just drop the second sentence entirely? >>=20 >=20 > That woudl be an easy way out, but it is clearly far from trivial to arti= culate the rationale for including a requirement about non-repudiatin, I th= ink we need to record teh rationale. Otherwise, the question will most like= ly come up come up at review time down the pipe. >=20 > Cheers >=20 > Francois >=20 >> Ben >>=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 From internet-drafts@ietf.org Mon Oct 21 09:53:35 2013 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 51A0211E8685; Mon, 21 Oct 2013 09:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdsl0ciGpCuT; Mon, 21 Oct 2013 09:53:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B2A2911E835E; Mon, 21 Oct 2013 09:53:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021165326.32469.57312.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 09:53:26 -0700 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-requirements-11.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 16:53:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Content Delivery Networks Interconnection= Working Group of the IETF. Title : Content Distribution Network Interconnection (CDNI) Requ= irements Author(s) : Kent Leung Yiu Lee Filename : draft-ietf-cdni-requirements-11.txt Pages : 24 Date : 2013-10-21 Abstract: Content Delivery Networks (CDNs) are frequently used for content delivery. As a result of significant growth in content delivered over IP networks, existing CDN providers are scaling up their infrastructure. Many Network Service Providers and Enterprise Service Providers are also deploying their own CDNs. To deliver contents from the Content Service Provider (CSP) to end users, the contents may traverse across multiple CDNs. This creates a need for interconnecting (previously) standalone CDNs so that they can collectively act as a single delivery platform from the CSP to the end users. The goal of the present document is to outline the requirements for the solution and interfaces to be specified by the CDNI working group. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-requirements There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-requirements-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-requirements-11 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 RMurray@velocix.com Mon Oct 21 09:53:51 2013 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 4EC9711E867D for ; Mon, 21 Oct 2013 09:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9fvHWkSy3Mm for ; Mon, 21 Oct 2013 09:53:47 -0700 (PDT) Received: from owa.velocix.com (mail-out1.velocix.com [81.134.152.10]) by ietfa.amsl.com (Postfix) with ESMTP id D2C8311E81CC for ; Mon, 21 Oct 2013 09:53:34 -0700 (PDT) Received: from EXC01-MLT.corp.velocix.com (172.18.4.41) by EXC00CAM.corp.velocix.com (172.18.4.40) with Microsoft SMTP Server (TLS) id 14.2.347.0; Mon, 21 Oct 2013 17:53:32 +0100 Received: from EXB04CAM.corp.velocix.com ([169.254.1.225]) by exc01-mlt.corp.velocix.com ([172.18.4.41]) with mapi id 14.02.0318.001; Mon, 21 Oct 2013 17:53:32 +0100 From: Rob Murray To: "cdni@ietf.org" Thread-Topic: New Version Notification for draft-ietf-cdni-control-triggers-01.txt Thread-Index: AQHOzj1Y9dIENqIcU0ilJ3NST7JVJZn/X6gA Date: Mon, 21 Oct 2013 16:53:32 +0000 Message-ID: In-Reply-To: <20131021090952.8729.96421.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [172.18.14.173] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] New Version Notification for draft-ietf-cdni-control-triggers-01.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 16:53:51 -0000 Hi all, Some minor updates to the CI/T draft ... - updated references and interface names - MIME type names changed to match the metadata draft As far as I know, that leaves the CI/T draft about done: - there's one to-do left in it, to say we need to align the HTTP/HTTPS-ness with other interfaces when that's decided. - We'd like to make a change to the structure of the self describing links used in this interface, and potentially metadata and others. Described below... The current relationship format is based on "atom:link". An example relationship given in the current triggers draft is the JSON dictionary: { "href": "http://triggers.cdni.example.com/trigger/12345", "rel": "Trigger", "type": "application/cdni.ci.TriggerStatus+json" } The location, purpose of the link (the relationship), and the type of the document referred to are all given. Our new thinking is to represent the same information in the format described at: http://stateless.co/hal_specification.html http://tools.ietf.org/html/draft-kelly-json-hal-06 So, in the proposed structure: - the containing dictionary has the well-known name "_links" - dictionary keys are the relationship type (which matches better the way it is likely to be used in an implementation) - lists of links sharing the same relationship type are allowed - a "self" link is included (where possible, it's a "SHOULD" in "draft-kelly-json-hal") The example relationship above (with an extra TriggerStatus record in the collection) would look like: "_links": { "self": { "href": "/all-triggers" }, "Trigger": [ { "href": "http://triggers.cdni.example.com/trigger/12345", "type": "application/cdni.ci.TriggerStatus+json" }, { "href": "http://triggers.cdni.example.com/trigger/12346", "type": "application/cdni.ci.TriggerStatus+json" } ] } The "type" field is optional in draft-kelly. It may not be needed here, but I've left it in for comparison with the previous example. Any thoughts, or objections to this change? Many thanks, Rob. -----Original Message----- From: "internet-drafts@ietf.org" Date: Monday, 21 October 2013 10:09 To: Rob Murray , Ben Niven-Jenkins Subject: New Version Notification for draft-ietf-cdni-control-triggers-01.txt > >A new version of I-D, draft-ietf-cdni-control-triggers-01.txt >has been successfully submitted by Rob Murray and posted to the >IETF repository. > >Filename: draft-ietf-cdni-control-triggers >Revision: 01 >Title: CDNI Control Interface / Triggers >Creation date: 2013-10-21 >Group: cdni >Number of pages: 35 >URL: =20 >http://www.ietf.org/internet-drafts/draft-ietf-cdni-control-triggers-01.tx >t >Status: =20 >http://datatracker.ietf.org/doc/draft-ietf-cdni-control-triggers >Htmlized: =20 >http://tools.ietf.org/html/draft-ietf-cdni-control-triggers-01 >Diff: =20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-control-triggers-01 > >Abstract: > This document describes the part of the CDN Interconnect Control > Interface that allows a CDN to trigger activity in an interconnected > CDN that is configured to deliver content on its behalf. The > upstream CDN can use this mechanism to request that the downstream > CDN pre-positions metadata or content, or that it re-validate or > purge metadata or content. The upstream CDN can monitor the status > of activity that it has triggered in the downstream CDN. > > > =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. > >The IETF Secretariat > From internet-drafts@ietf.org Mon Oct 21 12:26:05 2013 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 7777611E8247; Mon, 21 Oct 2013 12:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vo2KQjHNbv7V; Mon, 21 Oct 2013 12:26:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD2911E8557; Mon, 21 Oct 2013 12:26:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021192602.32574.76200.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 12:26:02 -0700 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-metadata-03.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 19:26:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Content Delivery Networks Interconnection= Working Group of the IETF. Title : CDN Interconnect Metadata Author(s) : Ben Niven-Jenkins Rob Murray Grant Watson Matt Caulfield Kent Leung Kevin J. Ma Filename : draft-ietf-cdni-metadata-03.txt Pages : 41 Date : 2013-10-21 Abstract: The CDNI Metadata Interface enables interconnected 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 the core 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: http://tools.ietf.org/html/draft-ietf-cdni-metadata-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-metadata-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mcaulfie@cisco.com Mon Oct 21 12:28:05 2013 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 DDA8A11E8600 for ; Mon, 21 Oct 2013 12:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOncrdJIeqpI for ; Mon, 21 Oct 2013 12:28:01 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 62D4611E8452 for ; Mon, 21 Oct 2013 12:27:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2476; q=dns/txt; s=iport; t=1382383678; x=1383593278; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=dIqLxdIlfd+XYuKulBWfxHGf6TYbAmnV0di6cEipYjc=; b=FLnGIB352h2Vu0qoQxNdeeRcmJ5qOA5ocKdCYspvYonXOsSPHbrPrt5e FVjAgS9EjUkDK4Ui/JvYZycVwL3VSWDdlB6g9HcVbVCpW72XJfUo0sKIl ifGSXF1++tiIa5mCv/0bb5gfJOg3XOd0+plsXV/6VT7fSGkR1BjkxCKIk E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsGAAuAZVKtJV2Y/2dsb2JhbABZgwc4TgaDKrsBGIEWFm0HgiUBAQEEIxFDDgQCAQgRBAEBAwIGHQMCAgIwFAEGAQEFAwIEEwgBh30IBadokkqBKY4BOAaCZDWBCgOUKoUOkFiDJIIq X-IronPort-AV: E=Sophos;i="4.93,541,1378857600"; d="scan'208";a="274584758" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 21 Oct 2013 19:27:58 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9LJRvwB024675 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 21 Oct 2013 19:27:57 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.192]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Mon, 21 Oct 2013 14:27:57 -0500 From: "Matt Caulfield (mcaulfie)" To: "cdni@ietf.org" Thread-Topic: New Version Notification for draft-ietf-cdni-metadata-03.txt Thread-Index: AQHOzpNlTH8KphvndE+GOp7v+4TOnZn/ibNQ Date: Mon, 21 Oct 2013 19:27:57 +0000 Message-ID: <166EBB70C264A9479E459B01B1BA6C921DDAA6FC@xmb-aln-x03.cisco.com> References: <20131021192603.32574.46672.idtracker@ietfa.amsl.com> In-Reply-To: <20131021192603.32574.46672.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.131.76.242] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [CDNi] FW: New Version Notification for draft-ietf-cdni-metadata-03.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 19:28:06 -0000 VXBkYXRlZCB0aGUgQ0ROSSBtZXRhZGF0YSBkcmFmdCBiYXNlZCBvbiBwcmV2aW91cyBmZWVkYmFj ay4NCg0KQ29tbWVudHMgYW5kIHF1ZXN0aW9uIHdlbGNvbWUuDQoNClRoYW5rcywNCk1hdHQgDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogTW9uZGF5LCBPY3Rv YmVyIDIxLCAyMDEzIDM6MjYgUE0NClRvOiBLZW50IExldW5nIChrbGV1bmcpOyBNYXR0IENhdWxm aWVsZCAobWNhdWxmaWUpOyBSb2IgTXVycmF5OyBCZW4gTml2ZW4tSmVua2luczsgS2V2aW4gTWE7 IEtldmluIEouIE1hOyBHcmFudCBXYXRzb24NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtaWV0Zi1jZG5pLW1ldGFkYXRhLTAzLnR4dA0KDQoNCkEgbmV3IHZlcnNp b24gb2YgSS1ELCBkcmFmdC1pZXRmLWNkbmktbWV0YWRhdGEtMDMudHh0IGhhcyBiZWVuIHN1Y2Nl c3NmdWxseSBzdWJtaXR0ZWQgYnkgQmVuIE5pdmVuLUplbmtpbnMgYW5kIHBvc3RlZCB0byB0aGUg SUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LWlldGYtY2RuaS1tZXRhZGF0YQ0K UmV2aXNpb246CSAwMw0KVGl0bGU6CQkgQ0ROIEludGVyY29ubmVjdCBNZXRhZGF0YQ0KQ3JlYXRp b24gZGF0ZToJIDIwMTMtMTAtMjENCkdyb3VwOgkJIGNkbmkNCk51bWJlciBvZiBwYWdlczogNDEN ClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtaWV0Zi1jZG5pLW1ldGFkYXRhLTAzLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY2RuaS1tZXRhZGF0YQ0KSHRtbGl6ZWQ6 ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNkbmktbWV0YWRh dGEtMDMNCkRpZmY6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9 ZHJhZnQtaWV0Zi1jZG5pLW1ldGFkYXRhLTAzDQoNCkFic3RyYWN0Og0KICAgVGhlIENETkkgTWV0 YWRhdGEgSW50ZXJmYWNlIGVuYWJsZXMgaW50ZXJjb25uZWN0ZWQgQ0ROcyB0byBleGNoYW5nZQ0K ICAgY29udGVudCBkaXN0cmlidXRpb24gbWV0YWRhdGEgaW4gb3JkZXIgdG8gZW5hYmxlIGNvbnRl bnQgYWNxdWlzaXRpb24NCiAgIGFuZCBkZWxpdmVyeS4gIFRoZSBDRE5JIG1ldGFkYXRhIGFzc29j aWF0ZWQgd2l0aCBhIHBpZWNlIG9mIGNvbnRlbnQNCiAgIHByb3ZpZGVzIGEgZG93bnN0cmVhbSBD RE4gd2l0aCBzdWZmaWNpZW50IGluZm9ybWF0aW9uIGZvciB0aGUNCiAgIGRvd25zdHJlYW0gQ0RO IHRvIHNlcnZpY2UgY29udGVudCByZXF1ZXN0cyBvbiBiZWhhbGYgb2YgYW4gdXBzdHJlYW0NCiAg IENETi4gIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGJvdGggdGhlIGNvcmUgc2V0IG9mIENETkkg bWV0YWRhdGEgYW5kDQogICB0aGUgcHJvdG9jb2wgZm9yIGV4Y2hhbmdpbmcgdGhhdCBtZXRhZGF0 YS4NCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBp dCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lv biB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRv b2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From internet-drafts@ietf.org Mon Oct 21 13:53:15 2013 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 D301111E8669; Mon, 21 Oct 2013 13:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6QalkIa3zGs; Mon, 21 Oct 2013 13:53:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D7AF711E8416; Mon, 21 Oct 2013 13:53:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021205312.32495.84546.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 13:53:12 -0700 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-footprint-capabilities-semantics-01.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 20:53:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Content Delivery Networks Interconnection= Working Group of the IETF. Title : CDNI Request Routing: Footprint and Capabilities Semanti= cs Author(s) : Jan Seedorf Jon Peterson Stefano Previdi Ray van Brandenburg Kevin J. Ma Filename : draft-ietf-cdni-footprint-capabilities-semantics-01.txt Pages : 18 Date : 2013-10-21 Abstract: This document tries to capture the semantics of the "Footprint and Capabilities Advertisement" part of the CDNI Request Routing interface, i.e. the desired meaning and what "Footprint and Capabilities Advertisement" is expected to offer within CDNI. The discussion in this document has the goal to facilitate the choosing of one or more suitable protocols for "Footprint and Capabilities Advertisement" within CDNI Request Routing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-footprint-capabilities-sem= antics There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-footprint-capabilities-semantics= -01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-footprint-capabilities-s= emantics-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From D.Malas@cablelabs.com Wed Oct 23 10:16:29 2013 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 502FE11E8176 for ; Wed, 23 Oct 2013 10:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.867 X-Spam-Level: X-Spam-Status: No, score=-99.867 tagged_above=-999 required=5 tests=[AWL=-1.262, BAYES_20=-0.74, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVFgf29SIl0f for ; Wed, 23 Oct 2013 10:16:25 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 35B1311E846C for ; Wed, 23 Oct 2013 10:16:24 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id r9NHGJs2007249; Wed, 23 Oct 2013 11:16:20 -0600 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Wed, 23 Oct 2013 11:16:19 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.03.0146.000; Wed, 23 Oct 2013 11:16:19 -0600 From: Daryl Malas To: "cdni@ietf.org" Thread-Topic: [CDNi] RE: Vancouver CDNI WG Slot requests/Draft Agenda Posted Thread-Index: AQHO0BOWVxoTCOAtxk6l7GoFQHvoHQ== Date: Wed, 23 Oct 2013 17:16:19 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.5.0.27] Content-Type: text/plain; charset="us-ascii" Content-ID: <6521D7CB3DDDBD4FB80F3EEA7A5D9428@cablelabs.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: [CDNi] RE: Vancouver CDNI WG Slot requests/Draft Agenda Posted X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 23 Oct 2013 17:16:29 -0000 The draft agenda for the CDNI working group meeting in Vancouver has been posted: https://datatracker.ietf.org/meeting/88/agenda/cdni/ Please let us know if you have any questions, concerns or do not see a requested time slot listed. --Daryl & Francois On 10/18/13 7:51 PM, "Daryl Malas" wrote: >As a reminder, please send your agenda slot requests as soon as possible. > >Thanks, > >Daryl & Francois > >________________________________________ >From: Francois Le Faucheur (flefauch) [flefauch@cisco.com] >Sent: Wednesday, October 16, 2013 3:26 AM >To: cdni@ietf.org >Cc: Francois Le Faucheur (flefauch); Daryl Malas >Subject: Vancouver CDNI WG Slot requests > >All, > >Please unicast your slot request to Daryl and I by Monday 21 October >(earlier is better). > >Thanks > >Francois & Daryl > > >PS: As per final agenda >(https://datatracker.ietf.org/meeting/88/agenda.html), the CDNI WG will >hold a single session: > * Thursday Nov 7, 1520-1720 PST. >_______________________________________________ >CDNi mailing list >CDNi@ietf.org >https://www.ietf.org/mailman/listinfo/cdni