From nobody Tue Jul 1 11:10:53 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC9141B287B for ; Tue, 1 Jul 2014 11:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.253 X-Spam-Level: X-Spam-Status: No, score=-8.253 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_BACKHAIR_31=1, J_BACKHAIR_34=1, J_BACKHAIR_37=1, J_BACKHAIR_44=1, J_BACKHAIR_52=1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybHQyRNLem6Z for ; Tue, 1 Jul 2014 11:10:14 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 878441B2874 for ; Tue, 1 Jul 2014 11:09:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18585; q=dns/txt; s=iport; t=1404238198; x=1405447798; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Pvg3wvBFAtdhac18U5+nDeyfFXA21m9tY578IXC6jJ0=; b=EzW99lmG26+kn3MqMkhODcM40qRimqBUH39rdwGFW9f7gG4aM05ADFjw NdnnB/ZrEHJyxkrt/tmCVKKMhLIPmEZIbHGmPGFkkhWEy97SKVXU4Srpu Cj1WOegzIZtHu76nDpQxyA7V7flYn4yp64IhNB9poFz61kAcj3C9Imdjg M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FANz4slOtJA2M/2dsb2JhbABQCoMNUlqrd5oPAYENFnWEAwEBAQMBJ1IFCwIBCBguMhcBDQEBBA4FiC4DCQgNwlkIhg4XjQOBQCkzBwKDK4EWBZYJhF2BSIoniBSDQmwBgUM X-IronPort-AV: E=Sophos;i="5.01,583,1400025600"; d="scan'208";a="337127277" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-4.cisco.com with ESMTP; 01 Jul 2014 18:09:57 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s61I9vpn012579 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 1 Jul 2014 18:09:57 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Tue, 1 Jul 2014 13:09:57 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: OPSDIR review of draft-ietf-cdni-logging-10 - cascade logging Thread-Index: Ac9bSqCFXoKjW9oJSsuqRN9aDJPligEATlgADY1t4QA= Date: Tue, 1 Jul 2014 18:09:56 +0000 Message-ID: <05BD7B6B-6886-4277-8A8A-8AE77363939B@cisco.com> References: <038401cf5b4f$0b5ea610$221bf230$@comcast.net> 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.200] Content-Type: text/plain; charset="Windows-1252" Content-ID: <080FFFD79825AE45A666C21EB1CE16B4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/OZgYy4Q7-k5W3WdJJdRjF-4LKZ8 Cc: "Benoit Claise \(bclaise\)" , ietfdbh , "spencer@wonderhamster.org" Subject: Re: [CDNi] OPSDIR review of draft-ietf-cdni-logging-10 - cascade logging X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jul 2014 18:10:26 -0000 Folks, (as a document editor) To address the point around cascaded CDNs that was raised by David Harringt= on as part of his early Ops Review, I have: * expanded section 3.5 =93CDNI Logging File Example=94 * added a section 3.6 "Cascaded CDNI Logging Files Example=94 Draft text is below. I=92d appreciate some reviews. Thanks Francois " 3.5. CDNI Logging File Example Let us consider the upstream CDN and the downstream CDN labelled uCDN and dCDN-1 in Figure 1. When dCDN-1 acts as a downstream CDN for uCDN and performs content delivery on behalf of uCDN, dCDN-1 will include the CDNI Logging Records corresponding to the content deliveries performed on behalf of uCDN in the CDNI Logging Files for uCDN. An example CDNI Logging File communicated by dCDN-1 to uCDN is show below: " #Version:CDNI/1.0 #UUID:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 #Claimed-Origin:cdni-logging-entity.dcdn-1.example.com #Record-Type:cdni_http_request_v1 #Fields:datetimetime-takenc-ipcs- methodu-uriprotocolsc-statussc-total- bytescs(User-Agent)cs(Referer)s-cached 2013-05-1700:38:06.8259.05810.5.7.1GETh ttp://cdni-ucdn.dcdn-1.example.com/video/ movie100.mp4HTTP/1.12006729891"Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 Safari /533.4""host1.example.com"1 2013-05-1700:39:09.14515.3210.5.10.5GET http://cdni-ucdn.dcdn-1.example.com/video/ movie118.mp4HTTP/1.120015799210"Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 Safari /533.4""host1.example.com"1 2013-05-1700:42:53.43752.87910.5.10.5GEThttp://cdni-ucdn.dcdn-1.example.com/video/ picture11.mp4HTTP/1.020097234724"Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 Safari /533.4""host5.example.com"0 #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e [Editor's Note: compute the correct Integrity-Hash value once example is frozen] " As illustrated in Figure 2, uCDN will then ingest the corresponding CDNI Logging Records into its Collection process, alongside the Logging Records generated locally by the uCDN itself. This allows uCDN to aggregate Logging Records for deliveries performed by itself (through Records generated locally) as well as for deliveries performed by its downstream CDN(s). This aggregate information can then be used (after Filtering and Rectification, as illustrated in Figure 2) by Log Consuming Applications considering deliveries performed by uCDN as well as by all its downstream CDN(s). We observe that the time between 1. when a delivery is completed in dCDN and 2. when the corresponding Logging Record is ingested by the Collection process in uCDN depends on a number of parameters such as the Logging Period agreed to by uCDN and dCDN, how much time uCDN waits after it is advertised in the CDNI Logging Feed before pulling the CDNI Logging File, and the time to complete the pull of the CDNI Logging File. Therefore, if we consider the set of Logging Records aggregated by the Collection process in uCDN in a given time interval, there could be a permanent significant timing difference between the CDNI Logging Records received from the dCDN and the Logging Records generated locally. For example, in a given time interval, the Collection process in uCDN may be aggregating Logging Records generated locally by uCDN for deliveries performed in the last hour and CDNI Logging Records generated in the dCDN for deliveries in the hour before last. 3.6. Cascaded CDNI Logging Files Example Let us consider the cascaded CDN scenario of uCDN, dCDN-2 and dCDN-3 as depicted in Figure 1. After completion of a delivery by dCDN-3 on behalf of dCDN-2, dCDN-3 will include a corresponding Logging Record in a CDNI Logging File and will advertise this CDNI Logging File to d-CDN2 in the corresponding CDNI Logging feed. As a result, dCDN-2 will initiate and complete the pull of the corresponding CDNI Logging File that is illustrated below: " #Version:CDNI/1.0 #UUID:urn:uuid:65718ef-0123-9876-adce4321bcde #Claimed-Origin:cdni-logging-entity.dcdn-3.example.com #Record-Type:cdni_http_request_v1 #Fields:datetimetime-takenc-ipcs- methodu-uriprotocolsc-statussc-total- bytescs(User-Agent)cs(Referer)s-cached 2013-05-1700:39:09.14515.3210.5.10.5GET http://cdni-dcdn-2.dcdn-3.example.com/video/movie118.mp4HTTP/ 1.120015799210"Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 Safari /533.4""host1.example.com"1 #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e [Editor's Note: compute the correct Integrity-Hash value once example is frozen] " dCDN-2 (behaving as an upstream CDN from the viewpoint of dCDN-3) will then ingest the CDNI Logging Record for the considered dCDN-3 delivery into its Collection process (as illustrated in Figure 2). This Logging Record may be aggregated with Logging Records generated locally by dCDN-2 for deliveries performed by dCDN-2 itself. Say, for illustration, that the content delivery performed by dCDN-3 on behalf of dCDN-2 had actually been redirected to dCDN-2 by uCDN, and say that another content delivery has just been redirected by uCDN to dCDN-2 and that dCDN-2 elected to perform the corresponding delivery itself. Then after Filtering and Rectification (as illustrated in Figure 2), dCDN-2 will include the two Logging Records corresponding respectively to the delivery performed by dCDN-3 and the delivery performed by dCDN-2, in the next CDNI Logging File that will be communcated to uCDN. An example of such CDNI Logging File is illustrated below: #Version:CDNI/1.0 #UUID:urn:uuid:1234567-8fedc-abab-0987654321ff #Claimed-Origin:cdni-logging-entity.dcdn-2.example.com #Record-Type:cdni_http_request_v1 #Fields:datetimetime-takenc-ipcs- methodu-uriprotocolsc-statussc-total- bytescs(User-Agent)cs(Referer)s-cached 2013-05-1700:39:09.14515.3210.5.10.5GET http://cdni-ucdn.dcdn-2.example.com/video/movie118.mp4HTTP/ 1.120015799210"Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 Safari /533.4""host1.example.com"1 2013-05-1701:42:53.43752.87910.5.10.5GEThttp://cdni-ucdn.dcdn-2.example.com/video/picture11.mp4HTTP/ 1.020097234724"Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 Safari /533.4""host5.example.com"0 #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e [Editor's Note: compute the correct Integrity-Hash value once example is frozen] " In the example above, we observe that: o the first Logging Record corresponds to the Logging Record communicated earlier to dCDN-2 by dCDN-3, which corresponds to a delivery redirected by uCDN to dCDN-2 and then redirected by dCDN-2 to dCDN-3. Its initial fields values are preserved, with the exception of the u-uri that now reflects the URI convention between uCDN and dCDN-2, and which presents the delivery to uCDN as if it was performed by dCDN-2 itself, which reflects the fact that dCDN-2 had taken the full responsibility of the corresponding delivery (even if in this case, dCDN-2 elected to redirect the delivery to dCDN-3 so it is actually performed by dCDN-3 on behalf of dCDN-2). o the second Logging Record corresponds to a delivery redirected by uCDN to dCDN-2 and performed by dCDN-2 itself. The time of the delivery in this Logging Record may be significantly more recent than the first Logging Record since it was generated locally while the first Logging Record was generated by dCDN-3 and had to be advertised , and then pulled and then ingested into the dCDN-2 Collection process, before being aggregated with the second Logging Record. " On 23 Apr 2014, at 20:29, Francois Le Faucheur (flefauch) wrote: > Hello, >=20 > On 18 Apr 2014, at 23:42, ietfdbh wrote: >>>=20 >>> On 5 Apr 2014, at 23:14, ietfdbh wrote: >>>>=20 >>>>=20 >>>> Most notably, the logging from a dCDN to a uCDN typically contains onl= y >>> one >>>> dCDN identifier, such as Verified-origin, and doesn't really permit >>>> specifying a sub-ordinate dCDN. For example, in a cascade such as CDN-= A >> - >>>>=20 >>>> CDN-B -> CDN-C, CDN-C will share logging info with CDN-B, but not with >>>> CDN-A; CDN-B shares logging info with CDN-A. This can be desirable for >>>> hiding the topology and delegation used by the dCDN. However, this >>> document >>>> does not discuss how the logging provided by CDN-C gets converted into >>> the >>>> logs for CDN-B that will be sent to CDN-A. Without some logging >>> information >>>> from CDN-C, it would seem difficult for CDN-A to utilize the informati= on >> to >>>> meet requirements of billing, analytics, and fault and performance >> analysis. >>>> Maybe the logging gets aggregated and reported in CDN-B's logging, >>>=20 >>> Exactly. >>>=20 >>>> but that >>>> "transitive or aggregate logging" doesn't appear to be discussed in th= is >>>> document. >>>=20 >>> It is discussed in section 2.1 through Figure 1 and the following text: >>> " >>> A dCDN (e.g., dCDN-2) integrates the relevant Logging information >>> obtained from its dCDNs (i.e., dCDN-3) in the Logging information >>> that it provides to the uCDN, so that the uCDN ultimately obtains all >>> Logging information relevant to a CSP for which it acts as the >>> authoritative CDN. >>> " >>> Does that address your concern? >>=20 >> No it does not mitigate my concern. >>=20 >> This says the information gets "integrated", but doesn't describe what >> integrated means. >> I could interpret that integration would be that the logging from CDN-C >> would be included in the logs from CDN-B to CDN-A, >> But I think the text says CDN-B will not share the logging entries from >> CDN-C with CDN-A. >> Do I have this wrong? Does CDN-B create a log file and generate entries= , >> and then when it delegates delivery to CDN-C, and CDN-C passes its log f= ile >> back to CDN-B, does CDN-B take the whole log file from CDN-B and insert = it >> into its own log file, then continue adding any more entries, and then w= hen >> done send the CDN-B log file (including a fully inserted CDN-C log file)= to >> CDN-A? >>=20 >> If not, that presumably means that somehow, the data from CDN-C is >> "aggregated" - that's how it is "integrated=94, >=20 > Right. It is aggregated. > Effectively, if CDN-B has sub-delegated a delivery to CDN-C, then when CD= N-C provides a log record for that delivery to CDN-B, CDN-B will aggregate = that log record with the log records for the deliveries that CDN-B conduted= itself. When CDN-B provides log records to CDN-A, the log record correspon= ding to the delivery performed by CDN-C is turned by CDN-B into a log recor= d that looks like the delivery was done by CDN-B. CDN-A will not be aware t= hat the delivery was performed by another CDN than CDN-B (just like the Con= tent Provider is not ware that the delivery was not performed by CDN-A with= whom it has a delivery contract). >=20 >> But there is no discussion of how this aggregation is done. >=20 > That is true. I think it has been assumed by many but never made clear. S= o we need to add some discussion about that. >=20 >> I think your intent is to hide the fact that CDN-B used CDN-C, since tha= t >> may reflect a proprietary approach of CDN-B's business model. >=20 > Right. >=20 >> But CDN-A would presumably have problems performing analytics, and fault= and >> performance analysis, if the data from CDN-C is not included in CDN-B's >> logging to CDN-A.=20 >> So I would like an example to demonstrate what CDN-A would see in CDN-B'= s >> logs if CDN-C had faults or performance problems, and I would like to se= e >> how CDN-A could perform analytics (of any kind) relating to the delivery >> performed by CDN-C. >=20 > The assumption is that CDN-A is only dealing with CDN-B. CDN-A may not no= t even be aware of CDN-C.=20 > So CDN-A analaytics/monitoring will establish whether all the deliveries = delegated to CDN-B (comprising deliveries performed by CDN-B as well as del= iveries redirected by CDN-B to CDN-C and possibly CDN-C2) have received the= right quality (ie if CDN-B has met the SLA committed to CDN-A). > If some deliveries have experienced quality problems, CDN-A will blame CD= N-B. It is up to CDN-B to then do its own analytics and monitoring to decid= e whether the problem lies within his own CDN or CDN-C or CDN-C2.=20 > The whole thing operates as a chain of delegations, like many other busin= ess arrangements: if my SmartPhone does not work, I blame the smartPhone ve= ndor (I don=92t try identify if the problem is coming from the supplier of = the GSM chipset, but the SmartPhone vendor will). >=20 >=20 >=20 >> I am missing how this would be done (especially in a standardized manner= ). >>=20 >>>=20 >>>>=20 >>>> I think Verified-Origin is particularly problematic, because the text >> states >>>> that this can only be added by the uCDN, never the dCDN. So what if >> CDN-B >>>> verifies the origin of the logs from CDN-C and then passes the >> information >>>> (now as a dCDN) to CDN-A? The text mentions that this might be >>> established >>>> using authentication mechanisms; so do we lose this logged >>>> authentication/verification when cascading? >>>>=20 >>>> (Maybe this is resolved by having the uCDN (CDN-B) record a >> "transaction" >>>> that starts when it delegates a task to a dCDN (e.g. CDN-C) and ends >> when >>>> the dCDN completes the task, and the uCDN just records the whole >>> transaction >>>> without the details that are reported by CDN-C. Then CDN-B logs only t= he >>>> whole transaction. I would like to see an explicit example of such >> logging, >>>> using the cdni_http_request_v1 record-type, so this is clear.) >>>=20 >>> Yes, that is pretty much the idea. >>> ie. if CDN-a delegate sto CDN-B then CDB-B is responsible for deliverin= g >> and >>> will provide a delivery record to CDN-A for that delivery. That record >> will be >>> part of a Logging File whose origin in CDN-B, and CDN-A can use >>> authentication mechanism to ensure the Logging File is provided by CDN-= B. >>> All of this completely holds whether CDN-B performed the delivery itsel= f >>> (and created the delivery record in the first place) or CDN-B delegated= to >>> CDN-C who provided the delivery record to CDN-B in a Logging File whose >>> origin was CDN-C. >>>=20 >>> This question has come up before so I will add a clarification along th= e >> lines >>> above under the description of the Verified Origin in case of cascaded >> CDNs. >>=20 >> An example of such integrated cascaded logging might answer many questio= ns. >=20 > Good idea.=20 > It sounds worthwhile to give a descripton of how log records get aggregat= ed in a csacaded scenario, indicate how directives/fields get modified/kept= at each CDN hop, and possibly include an example with some log records and= how they propagate from CDN-C to CDN-B to CDN-A. >=20 >> If logging records from CDN-C get copied into the log from CDN-B, are al= l >> directives and record types copied? >> If so, I think it is important to make clear that a given log might cont= ain >> multiple nested logs, >> And that means that the file received by CDN-A might start with directiv= es >> for CDN-B plus records,=20 >> And then directives for CDN-C, ending with an Integrity-Hash, and more >> records for CDN-B followed by an Integrity-Hash. >> Maybe this is all as designed, but I haven't seen discussion of that, an= d it >> is not reflected in Figure 3, and this is not discussed in the descripti= on >> of fields that are file-specific, such as Integrity-hash, Verfiied-origi= n, >> Version, UUID, etc. >> If you have nested logs, then log-consuming applications need to know th= at >> those file-specific directives un-nest at the end of the included file. = Can >> they tell consistently when they hit the end of the included file? >> Should there be an end-of-log marker for the included log?=20 >>=20 >> The Integrity-Hash directive is allowed to occur zero or once, not multi= ple >> times in a logfile. >> So if the CDN-C logfile contains an Integrity-Hash, should that be check= ed >> by CDN-B, then copy the CDN-C logfile into the CDN-B logfile, but discar= d >> the CDN-C Integrity-Hash, because CDN-B will calculate its own >> Integrity-Hash directive? >=20 > Yes. >=20 >>=20 >>> Let me know if that is not sufficient. >>=20 >> I remain concerned that cascaded logging may not have been adequately >> described and standardized. >=20 > Right. I see that the questions you raised were not answered in the docum= ent. We will work on addressing them. >=20 > Thanks >=20 > Francois >=20 >>=20 >>>=20 >>>=20 >>>=20 >>> Francois >>=20 >> dbh >>=20 >=20 From nobody Wed Jul 2 00:45:27 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB01E1A0ABB for ; Wed, 2 Jul 2014 00:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54QCMm8jrBrv for ; Wed, 2 Jul 2014 00:45:23 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 381D21A0AD9 for ; Wed, 2 Jul 2014 00:45:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1386; q=dns/txt; s=iport; t=1404287123; x=1405496723; h=from:to:subject:date:message-id:mime-version; bh=yY+cjNrqZRukvB2vjJ5f4QzL7BK06ye2+7CeS+TTD1I=; b=IR2v22X0Nyp3wHdwUEPl4ZALCd0cdwnx2HgiluWyzuheysB31gbNZqvv 8NiGkTl4hWdRByrELucSYmCtM3Vodx7n43P+EHpasmtgxU9Gy/7MEgFU7 zPmBoKK0zFiw7jMa609QzYPz3G53d8tf2Y3Bew8bTBl9S3RAGaQB9RtfV A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApcZAKC3s1OtJV2c/2dsb2JhbABagw1SWoQKwhGBDRZ1g3oQgQsBCwF0JwSIVQ2aTqpMEwSLe4MggziBFgWaZpQDg0JsgUQ X-IronPort-AV: E=Sophos; i="5.01,587,1400025600"; d="scan'208,217"; a="57663651" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-6.cisco.com with ESMTP; 02 Jul 2014 07:45:22 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s627jM58005307 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 2 Jul 2014 07:45:22 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Wed, 2 Jul 2014 02:45:21 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: CDNI WG meeting : Thursday, July 24, 15:20-17:20 Thread-Index: AQHPlcmTs4XmxZOUkkK8BtFJDUyNkA== Date: Wed, 2 Jul 2014 07:45:21 +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.200] Content-Type: multipart/alternative; boundary="_000_A3E5603BDAE044849E470EE16548CD80ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/s4wI57oYdRUuN9CUZlez4TQlX9E Subject: [CDNi] CDNI WG meeting : Thursday, July 24, 15:20-17:20 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 07:45:24 -0000 --_000_A3E5603BDAE044849E470EE16548CD80ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, The final agenda for IETF 90 (Toronto) is available. The CDNI WG is scheduled to meet Thursday, July 24, 15:20-17:20. https://datatracker.ietf.org/meeting/90/agenda.html https://datatracker.ietf.org/meeting/90/agenda.txt Francois --_000_A3E5603BDAE044849E470EE16548CD80ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <1B1F293D4A6FFB42AE793F85FE57AA11@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Folks,

The final agenda for IETF 90 (Toronto) is available.
The CDNI WG is scheduled to meet Thursday, July 24, 15:20-17:20.


Francois
--_000_A3E5603BDAE044849E470EE16548CD80ciscocom_-- From nobody Wed Jul 2 07:39:22 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC8D1A0240 for ; Wed, 2 Jul 2014 07:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.152 X-Spam-Level: X-Spam-Status: No, score=-11.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_BACKHAIR_31=1, J_BACKHAIR_37=1, J_BACKHAIR_44=1, J_BACKHAIR_52=1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyFawub-Nwm0 for ; Wed, 2 Jul 2014 07:39:16 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD2301A01AE for ; Wed, 2 Jul 2014 07:39:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29698; q=dns/txt; s=iport; t=1404311957; x=1405521557; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=o2Zbw5/241LEHr1AgwFnp2QowUXBxW7X3XuGBO3ce5Q=; b=DF1TbMG3BkzMkcu6gHOWkjrSsOfGpzmJrGkEj7vOFGPwK8CdAg6lZlIw C9sfzz/Dp2wL7MJwN3hvldcnuyQMYiXv+lbvadqSoXFnJplC/k/eB242P mPa7Che5EixRwFGaGpf4+ZQxrNgmo4ZbwolHR4aQaOmyic6BrHs9GasAm 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsUHABkZtFOtJA2E/2dsb2JhbABQAQmDDVJarAKSWodAAYEHFnWEAwEBAQMBAQEBFw1HCwULAgEIGBUZJwsXAQ0CBA4DAoguAwkIDcAKCIYOF40FgUEBKDMHAgiDI4EWBZYPhF6BSIoriBaDQ0ErAYFD X-IronPort-AV: E=Sophos;i="5.01,588,1400025600"; d="scan'208";a="337235425" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-7.cisco.com with ESMTP; 02 Jul 2014 14:39:14 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s62EdDu5032403 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Jul 2014 14:39:13 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Wed, 2 Jul 2014 09:39:12 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: [CDNi] OPSDIR review of draft-ietf-cdni-logging-10 - cascade logging Thread-Index: AQHPlgNjmkBIYZUj2U2qeEaxouUVuQ== Date: Wed, 2 Jul 2014 14:39:11 +0000 Message-ID: <315A2A4B-C876-4FF7-A836-7D48AC191195@cisco.com> References: <038401cf5b4f$0b5ea610$221bf230$@comcast.net> <05BD7B6B-6886-4277-8A8A-8AE77363939B@cisco.com> In-Reply-To: <05BD7B6B-6886-4277-8A8A-8AE77363939B@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.200] Content-Type: text/plain; charset="Windows-1252" Content-ID: <01903E706A2AC3438A5B465CB5DB8E38@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/9ot-bPjVi3Fqg8ZDHKuU9zGHiaE Cc: "Benoit Claise \(bclaise\)" , ietfdbh , "spencer@wonderhamster.org" Subject: Re: [CDNi] OPSDIR review of draft-ietf-cdni-logging-10 - cascade logging X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 14:39:20 -0000 On 1 Jul 2014, at 20:09, Francois Le Faucheur (flefauch) wrote: > Folks, >=20 > (as a document editor) >=20 > To address the point around cascaded CDNs that was raised by David Harrin= gton as part of his early Ops Review, I have: > * expanded section 3.5 =93CDNI Logging File Example=94 > * added a section 3.6 "Cascaded CDNI Logging Files Example=94 >=20 > Draft text is below. I=92d appreciate some reviews. I did a bit more work on teh text. Latest version below. Again will appreci= ate a good review: 3.5. CDNI Logging File Example Let us consider the upstream CDN and the downstream CDN labelled uCDN and dCDN-1 in Figure 1. When dCDN-1 acts as a downstream CDN for uCDN and performs content delivery on behalf of uCDN, dCDN-1 will include the CDNI Logging Records corresponding to the content deliveries performed on behalf of uCDN in the CDNI Logging Files for uCDN. An example CDNI Logging File communicated by dCDN-1 to uCDN is shown below in Figure 4. #Version:CDNI/1.0 #UUID:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 #Claimed-Origin:cdni-logging-entity.dcdn-1.example.com #Record-Type:cdni_http_request_v1 #Fields:datetimetime-takenc-ip cs-methodu-uriprotocolsc-status sc-total-bytescs(User-Agent)cs(Referer) s-cached 2013-05-1700:38:06.8259.05810.5.7.1GET http://cdni-ucdn.dcdn-1.example.com/video/movie100.mp4 HTTP/1.12006729891"Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 Safari/533.4" "host1.example.com"1 2013-05-1700:39:09.14515.3210.5.10.5GET http://cdni-ucdn.dcdn-1.example.com/video/movie118.mp4 HTTP/1.120015799210"Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 Safari/533.4" "host1.example.com"1 2013-05-1700:42:53.43752.87910.5.10.5GET http://cdni-ucdn.dcdn-1.example.com/video/picture11.mp4 HTTP/1.020097234724"Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 Safari/533.4" "host5.example.com"0 #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e [Editor's Note: compute the correct Integrity-Hash value once example is frozen] Figure 4: CDNI Logging File Example If uCDN establishes by some means (e.g. via TLS authentication when pulling the CDNI Logging File) the identity of the entity from which it pulled the CDNI Logging File, uCDN can add to the CDNI Logging a Verified-Origin directive as illustrated below: #Verified-Origin:cdni-logging-entity.dcdn-1.example.com As illustrated in Figure 2, uCDN will then ingest the corresponding CDNI Logging Records into its Collection process, alongside the Logging Records generated locally by the uCDN itself. This allows uCDN to aggregate Logging Records for deliveries performed by itself (through Records generated locally) as well as for deliveries performed by its downstream CDN(s). This aggregate information can then be used (after Filtering and Rectification, as illustrated in Figure 2) by Log Consuming Applications that take into account deliveries performed by uCDN as well as by all of its downstream CDNs. We observe that the time between 1. when a delivery is completed in dCDN and 2. when the corresponding Logging Record is ingested by the Collection process in uCDN depends on a number of parameters such as the Logging Period agreed to by uCDN and dCDN, how much time uCDN waits before pulling the CDNI Logging File once it is advertised in the CDNI Logging Feed, and the time to complete the pull of the CDNI Logging File. Therefore, if we consider the set of Logging Records aggregated by the Collection process in uCDN in a given time interval, there could be a permanent significant timing difference between the CDNI Logging Records received from the dCDN and the Logging Records generated locally. For example, in a given time interval, the Collection process in uCDN may be aggregating Logging Records generated locally by uCDN for deliveries performed in the last hour and CDNI Logging Records generated in the dCDN for deliveries in the hour before last. 3.6. Cascaded CDNI Logging Files Example Let us consider the cascaded CDN scenario of uCDN, dCDN-2 and dCDN-3 as depicted in Figure 1. After completion of a delivery by dCDN-3 on behalf of dCDN-2, dCDN-3 will include a corresponding Logging Record in a CDNI Logging File that will be pulled by dCDN-2 and that is illustrated below in Figure 5. In practice, a CDNI Logging File is likely to contain a very high number of CDNI Logging Records. However, for readability, the example in Figure 5 contains a single CDNI Logging Record. #Version:CDNI/1.0 #UUID:urn:uuid:65718ef-0123-9876-adce4321bcde #Claimed-Origin:cdni-logging-entity.dcdn-3.example.com #Record-Type:cdni_http_request_v1 #Fields:datetimetime-takenc-ip cs-methodu-uriprotocolsc-status sc-total-bytescs(User-Agent)cs(Referer) s-cached 2013-05-1700:39:09.11914.0710.5.10.9GET http://cdni-dcdn-2.dcdn-3.example.com/video/movie118.mp4 HTTP/1.120015799210"Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 Safari /533.4" "host1.example.com"1 #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e [Editor's Note: compute the correct Integrity-Hash value once example is frozen] Figure 5: Cascaded CDNI Logging File Example (dCDN-3 to dCDN-2) If dCDN-2 establishes by some means (e.g. via TLS authentication when pulling the CDNI Logging File) the identity of the entity from which it pulled the CDNI Logging File, dCDN-2 can add to the CDNI Logging a Verified-Origin directive as illustrated below: #Verified-Origin:cdni-logging-entity.dcdn-3.example.com dCDN-2 (behaving as an upstream CDN from the viewpoint of dCDN-3) will then ingest the CDNI Logging Record for the considered dCDN-3 delivery into its Collection process (as illustrated in Figure 2). This Logging Record may be aggregated with Logging Records generated locally by dCDN-2 for deliveries performed by dCDN-2 itself. Say, for illustration, that the content delivery performed by dCDN-3 on behalf of dCDN-2 had actually been redirected to dCDN-2 by uCDN, and say that another content delivery has just been redirected by uCDN to dCDN-2 and that dCDN-2 elected to perform the corresponding delivery itself. Then after Filtering and Rectification (as illustrated in Figure 2), dCDN-2 will include the two Logging Records corresponding respectively to the delivery performed by dCDN-3 and the delivery performed by dCDN-2, in the next CDNI Logging File that will be communicated to uCDN. An example of such CDNI Logging File is illustrated below in Figure 6. #Version:CDNI/1.0 #UUID:urn:uuid:1234567-8fedc-abab-0987654321ff #Claimed-Origin:cdni-logging-entity.dcdn-2.example.com #Record-Type:cdni_http_request_v1 #Fields:datetimetime-takenc-ip cs-methodu-uriprotocolsc-status sc-total-bytescs(User-Agent)cs(Referer) s-cached 2013-05-1700:39:09.11914.0710.5.10.9GET http://cdni-ucdn.dcdn-2.example.com/video/movie118.mp4 HTTP/1.120015799210"Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 Safari /533.4" "host1.example.com"1 2013-05-1701:42:53.43752.87910.5.10.12GET http://cdni-ucdn.dcdn-2.example.com/video/picture11.mp4 HTTP/1.020097234724"Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 Safari /533.4" "host5.example.com"0 #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e [Editor's Note: compute the correct Integrity-Hash value once example is frozen] Figure 6: Cascaded CDNI Logging File Example (dCDN-2 to uCDN) If uCDN establishes by some means (e.g. via TLS authentication when pulling the CDNI Logging File) the identity of the entity from which it pulled the CDNI Logging File, uCDN can add to the CDNI Logging a Verified-Origin directive as illustrated below: #Verified-Origin:cdni-logging-entity.dcdn-2.example.com In the example of Figure 6, we observe that: o the first Logging Record corresponds to the Logging Record communicated earlier to dCDN-2 by dCDN-3, which corresponds to a delivery redirected by uCDN to dCDN-2 and then redirected by dCDN-2 to dCDN-3. Its initial fields values are preserved, with the exception of the u-uri that now reflects the URI convention between uCDN and dCDN-2, and which presents the delivery to uCDN as if it was performed by dCDN-2 itself, which reflects the fact that dCDN-2 had taken the full responsibility of the corresponding delivery (even if in this case, dCDN-2 elected to redirect the delivery to dCDN-3 so it is actually performed by dCDN-3 on behalf of dCDN-2). o the second Logging Record corresponds to a delivery redirected by uCDN to dCDN-2 and performed by dCDN-2 itself. The time of the delivery in this Logging Record may be significantly more recent than the first Logging Record since it was generated locally while the first Logging Record was generated by dCDN-3 and had to be advertised , and then pulled and then ingested into the dCDN-2 Collection process, before being aggregated with the second Logging Record. Cheers Francois >=20 > Thanks >=20 > Francois >=20 > " >=20 > 3.5. CDNI Logging File Example >=20 > Let us consider the upstream CDN and the downstream CDN labelled uCDN > and dCDN-1 in Figure 1. When dCDN-1 acts as a downstream CDN for > uCDN and performs content delivery on behalf of uCDN, dCDN-1 will > include the CDNI Logging Records corresponding to the content > deliveries performed on behalf of uCDN in the CDNI Logging Files for > uCDN. An example CDNI Logging File communicated by dCDN-1 to uCDN is > show below: >=20 > " >=20 > #Version:CDNI/1.0 >=20 > #UUID:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 >=20 > #Claimed-Origin:cdni-logging-entity.dcdn-1.example.com >=20 > #Record-Type:cdni_http_request_v1 >=20 > #Fields:datetimetime-takenc-ipcs- > methodu-uriprotocolsc-statussc-total- > bytescs(User-Agent)cs(Referer)s-cached >=20 > 2013-05-1700:38:06.8259.05810.5.7.1GETh > ttp://cdni-ucdn.dcdn-1.example.com/video/ > movie100.mp4HTTP/1.12006729891"Mozilla/5.0 > (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like > Gecko) Chrome/5.0.375.127 Safari > /533.4""host1.example.com"1 >=20 > 2013-05-1700:39:09.14515.3210.5.10.5GET > http://cdni-ucdn.dcdn-1.example.com/video/ > movie118.mp4HTTP/1.120015799210"Mozilla/5.0 > (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like > Gecko) Chrome/5.0.375.127 Safari > /533.4""host1.example.com"1 >=20 > 2013-05-1700:42:53.43752.87910.5.10.5GET> http://cdni-ucdn.dcdn-1.example.com/video/ > picture11.mp4HTTP/1.020097234724"Mozilla/5.0 > (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like > Gecko) Chrome/5.0.375.127 Safari > /533.4""host5.example.com"0 >=20 > #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >=20 > [Editor's Note: compute the correct Integrity-Hash value once example > is frozen] >=20 > " >=20 > As illustrated in Figure 2, uCDN will then ingest the corresponding > CDNI Logging Records into its Collection process, alongside the > Logging Records generated locally by the uCDN itself. This allows > uCDN to aggregate Logging Records for deliveries performed by itself > (through Records generated locally) as well as for deliveries > performed by its downstream CDN(s). This aggregate information can > then be used (after Filtering and Rectification, as illustrated in > Figure 2) by Log Consuming Applications considering deliveries > performed by uCDN as well as by all its downstream CDN(s). >=20 > We observe that the time between >=20 > 1. when a delivery is completed in dCDN and >=20 > 2. when the corresponding Logging Record is ingested by the > Collection process in uCDN >=20 > depends on a number of parameters such as the Logging Period agreed > to by uCDN and dCDN, how much time uCDN waits after it is advertised > in the CDNI Logging Feed before pulling the CDNI Logging File, and > the time to complete the pull of the CDNI Logging File. Therefore, > if we consider the set of Logging Records aggregated by the > Collection process in uCDN in a given time interval, there could be a > permanent significant timing difference between the CDNI Logging > Records received from the dCDN and the Logging Records generated > locally. For example, in a given time interval, the Collection > process in uCDN may be aggregating Logging Records generated locally > by uCDN for deliveries performed in the last hour and CDNI Logging > Records generated in the dCDN for deliveries in the hour before last. >=20 > 3.6. Cascaded CDNI Logging Files Example >=20 > Let us consider the cascaded CDN scenario of uCDN, dCDN-2 and dCDN-3 > as depicted in Figure 1. After completion of a delivery by dCDN-3 on > behalf of dCDN-2, dCDN-3 will include a corresponding Logging Record > in a CDNI Logging File and will advertise this CDNI Logging File to > d-CDN2 in the corresponding CDNI Logging feed. As a result, dCDN-2 > will initiate and complete the pull of the corresponding CDNI Logging > File that is illustrated below: >=20 > " >=20 > #Version:CDNI/1.0 >=20 > #UUID:urn:uuid:65718ef-0123-9876-adce4321bcde >=20 > #Claimed-Origin:cdni-logging-entity.dcdn-3.example.com >=20 > #Record-Type:cdni_http_request_v1 >=20 > #Fields:datetimetime-takenc-ipcs- > methodu-uriprotocolsc-statussc-total- > bytescs(User-Agent)cs(Referer)s-cached >=20 > 2013-05-1700:39:09.14515.3210.5.10.5GET > http://cdni-dcdn-2.dcdn-3.example.com/video/movie118.mp4HTTP/ > 1.120015799210"Mozilla/5.0 (Windows; U; Windows NT > 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 > Safari /533.4""host1.example.com"1 >=20 > #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >=20 > [Editor's Note: compute the correct Integrity-Hash value once example > is frozen] >=20 > " >=20 > dCDN-2 (behaving as an upstream CDN from the viewpoint of dCDN-3) > will then ingest the CDNI Logging Record for the considered dCDN-3 > delivery into its Collection process (as illustrated in Figure 2). > This Logging Record may be aggregated with Logging Records generated > locally by dCDN-2 for deliveries performed by dCDN-2 itself. Say, > for illustration, that the content delivery performed by dCDN-3 on > behalf of dCDN-2 had actually been redirected to dCDN-2 by uCDN, and > say that another content delivery has just been redirected by uCDN to > dCDN-2 and that dCDN-2 elected to perform the corresponding delivery > itself. Then after Filtering and Rectification (as illustrated in > Figure 2), dCDN-2 will include the two Logging Records corresponding > respectively to the delivery performed by dCDN-3 and the delivery > performed by dCDN-2, in the next CDNI Logging File that will be > communcated to uCDN. An example of such CDNI Logging File is > illustrated below: >=20 > #Version:CDNI/1.0 >=20 > #UUID:urn:uuid:1234567-8fedc-abab-0987654321ff >=20 > #Claimed-Origin:cdni-logging-entity.dcdn-2.example.com >=20 > #Record-Type:cdni_http_request_v1 >=20 > #Fields:datetimetime-takenc-ipcs- > methodu-uriprotocolsc-statussc-total- > bytescs(User-Agent)cs(Referer)s-cached >=20 > 2013-05-1700:39:09.14515.3210.5.10.5GET > http://cdni-ucdn.dcdn-2.example.com/video/movie118.mp4HTTP/ > 1.120015799210"Mozilla/5.0 (Windows; U; Windows NT > 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 > Safari /533.4""host1.example.com"1 >=20 > 2013-05-1701:42:53.43752.87910.5.10.5GET> http://cdni-ucdn.dcdn-2.example.com/video/picture11.mp4HTTP/ > 1.020097234724"Mozilla/5.0 (Windows; U; Windows NT > 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 > Safari /533.4""host5.example.com"0 >=20 > #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >=20 > [Editor's Note: compute the correct Integrity-Hash value once example > is frozen] >=20 > " >=20 > In the example above, we observe that: >=20 > o the first Logging Record corresponds to the Logging Record > communicated earlier to dCDN-2 by dCDN-3, which corresponds to a > delivery redirected by uCDN to dCDN-2 and then redirected by > dCDN-2 to dCDN-3. Its initial fields values are preserved, with > the exception of the u-uri that now reflects the URI convention > between uCDN and dCDN-2, and which presents the delivery to uCDN > as if it was performed by dCDN-2 itself, which reflects the fact > that dCDN-2 had taken the full responsibility of the corresponding > delivery (even if in this case, dCDN-2 elected to redirect the > delivery to dCDN-3 so it is actually performed by dCDN-3 on behalf > of dCDN-2). >=20 > o the second Logging Record corresponds to a delivery redirected by > uCDN to dCDN-2 and performed by dCDN-2 itself. The time of the > delivery in this Logging Record may be significantly more recent > than the first Logging Record since it was generated locally while > the first Logging Record was generated by dCDN-3 and had to be > advertised , and then pulled and then ingested into the dCDN-2 > Collection process, before being aggregated with the second > Logging Record. >=20 > " >=20 >=20 > On 23 Apr 2014, at 20:29, Francois Le Faucheur (flefauch) wrote: >=20 >> Hello, >>=20 >> On 18 Apr 2014, at 23:42, ietfdbh wrote: >>>>=20 >>>> On 5 Apr 2014, at 23:14, ietfdbh wrote: >>>>>=20 >>>>>=20 >>>>> Most notably, the logging from a dCDN to a uCDN typically contains on= ly >>>> one >>>>> dCDN identifier, such as Verified-origin, and doesn't really permit >>>>> specifying a sub-ordinate dCDN. For example, in a cascade such as CDN= -A >>> - >>>>>=20 >>>>> CDN-B -> CDN-C, CDN-C will share logging info with CDN-B, but not wit= h >>>>> CDN-A; CDN-B shares logging info with CDN-A. This can be desirable fo= r >>>>> hiding the topology and delegation used by the dCDN. However, this >>>> document >>>>> does not discuss how the logging provided by CDN-C gets converted int= o >>>> the >>>>> logs for CDN-B that will be sent to CDN-A. Without some logging >>>> information >>>>> from CDN-C, it would seem difficult for CDN-A to utilize the informat= ion >>> to >>>>> meet requirements of billing, analytics, and fault and performance >>> analysis. >>>>> Maybe the logging gets aggregated and reported in CDN-B's logging, >>>>=20 >>>> Exactly. >>>>=20 >>>>> but that >>>>> "transitive or aggregate logging" doesn't appear to be discussed in t= his >>>>> document. >>>>=20 >>>> It is discussed in section 2.1 through Figure 1 and the following text= : >>>> " >>>> A dCDN (e.g., dCDN-2) integrates the relevant Logging information >>>> obtained from its dCDNs (i.e., dCDN-3) in the Logging information >>>> that it provides to the uCDN, so that the uCDN ultimately obtains all >>>> Logging information relevant to a CSP for which it acts as the >>>> authoritative CDN. >>>> " >>>> Does that address your concern? >>>=20 >>> No it does not mitigate my concern. >>>=20 >>> This says the information gets "integrated", but doesn't describe what >>> integrated means. >>> I could interpret that integration would be that the logging from CDN-C >>> would be included in the logs from CDN-B to CDN-A, >>> But I think the text says CDN-B will not share the logging entries from >>> CDN-C with CDN-A. >>> Do I have this wrong? Does CDN-B create a log file and generate entrie= s, >>> and then when it delegates delivery to CDN-C, and CDN-C passes its log = file >>> back to CDN-B, does CDN-B take the whole log file from CDN-B and insert= it >>> into its own log file, then continue adding any more entries, and then = when >>> done send the CDN-B log file (including a fully inserted CDN-C log file= ) to >>> CDN-A? >>>=20 >>> If not, that presumably means that somehow, the data from CDN-C is >>> "aggregated" - that's how it is "integrated=94, >>=20 >> Right. It is aggregated. >> Effectively, if CDN-B has sub-delegated a delivery to CDN-C, then when C= DN-C provides a log record for that delivery to CDN-B, CDN-B will aggregate= that log record with the log records for the deliveries that CDN-B condute= d itself. When CDN-B provides log records to CDN-A, the log record correspo= nding to the delivery performed by CDN-C is turned by CDN-B into a log reco= rd that looks like the delivery was done by CDN-B. CDN-A will not be aware = that the delivery was performed by another CDN than CDN-B (just like the Co= ntent Provider is not ware that the delivery was not performed by CDN-A wit= h whom it has a delivery contract). >>=20 >>> But there is no discussion of how this aggregation is done. >>=20 >> That is true. I think it has been assumed by many but never made clear. = So we need to add some discussion about that. >>=20 >>> I think your intent is to hide the fact that CDN-B used CDN-C, since th= at >>> may reflect a proprietary approach of CDN-B's business model. >>=20 >> Right. >>=20 >>> But CDN-A would presumably have problems performing analytics, and faul= t and >>> performance analysis, if the data from CDN-C is not included in CDN-B's >>> logging to CDN-A.=20 >>> So I would like an example to demonstrate what CDN-A would see in CDN-B= 's >>> logs if CDN-C had faults or performance problems, and I would like to s= ee >>> how CDN-A could perform analytics (of any kind) relating to the deliver= y >>> performed by CDN-C. >>=20 >> The assumption is that CDN-A is only dealing with CDN-B. CDN-A may not n= ot even be aware of CDN-C.=20 >> So CDN-A analaytics/monitoring will establish whether all the deliveries= delegated to CDN-B (comprising deliveries performed by CDN-B as well as de= liveries redirected by CDN-B to CDN-C and possibly CDN-C2) have received th= e right quality (ie if CDN-B has met the SLA committed to CDN-A). >> If some deliveries have experienced quality problems, CDN-A will blame C= DN-B. It is up to CDN-B to then do its own analytics and monitoring to deci= de whether the problem lies within his own CDN or CDN-C or CDN-C2.=20 >> The whole thing operates as a chain of delegations, like many other busi= ness arrangements: if my SmartPhone does not work, I blame the smartPhone v= endor (I don=92t try identify if the problem is coming from the supplier of= the GSM chipset, but the SmartPhone vendor will). >>=20 >>=20 >>=20 >>> I am missing how this would be done (especially in a standardized manne= r). >>>=20 >>>>=20 >>>>>=20 >>>>> I think Verified-Origin is particularly problematic, because the text >>> states >>>>> that this can only be added by the uCDN, never the dCDN. So what if >>> CDN-B >>>>> verifies the origin of the logs from CDN-C and then passes the >>> information >>>>> (now as a dCDN) to CDN-A? The text mentions that this might be >>>> established >>>>> using authentication mechanisms; so do we lose this logged >>>>> authentication/verification when cascading? >>>>>=20 >>>>> (Maybe this is resolved by having the uCDN (CDN-B) record a >>> "transaction" >>>>> that starts when it delegates a task to a dCDN (e.g. CDN-C) and ends >>> when >>>>> the dCDN completes the task, and the uCDN just records the whole >>>> transaction >>>>> without the details that are reported by CDN-C. Then CDN-B logs only = the >>>>> whole transaction. I would like to see an explicit example of such >>> logging, >>>>> using the cdni_http_request_v1 record-type, so this is clear.) >>>>=20 >>>> Yes, that is pretty much the idea. >>>> ie. if CDN-a delegate sto CDN-B then CDB-B is responsible for deliveri= ng >>> and >>>> will provide a delivery record to CDN-A for that delivery. That record >>> will be >>>> part of a Logging File whose origin in CDN-B, and CDN-A can use >>>> authentication mechanism to ensure the Logging File is provided by CDN= -B. >>>> All of this completely holds whether CDN-B performed the delivery itse= lf >>>> (and created the delivery record in the first place) or CDN-B delegate= d to >>>> CDN-C who provided the delivery record to CDN-B in a Logging File whos= e >>>> origin was CDN-C. >>>>=20 >>>> This question has come up before so I will add a clarification along t= he >>> lines >>>> above under the description of the Verified Origin in case of cascaded >>> CDNs. >>>=20 >>> An example of such integrated cascaded logging might answer many questi= ons. >>=20 >> Good idea.=20 >> It sounds worthwhile to give a descripton of how log records get aggrega= ted in a csacaded scenario, indicate how directives/fields get modified/kep= t at each CDN hop, and possibly include an example with some log records an= d how they propagate from CDN-C to CDN-B to CDN-A. >>=20 >>> If logging records from CDN-C get copied into the log from CDN-B, are a= ll >>> directives and record types copied? >>> If so, I think it is important to make clear that a given log might con= tain >>> multiple nested logs, >>> And that means that the file received by CDN-A might start with directi= ves >>> for CDN-B plus records,=20 >>> And then directives for CDN-C, ending with an Integrity-Hash, and more >>> records for CDN-B followed by an Integrity-Hash. >>> Maybe this is all as designed, but I haven't seen discussion of that, a= nd it >>> is not reflected in Figure 3, and this is not discussed in the descript= ion >>> of fields that are file-specific, such as Integrity-hash, Verfiied-orig= in, >>> Version, UUID, etc. >>> If you have nested logs, then log-consuming applications need to know t= hat >>> those file-specific directives un-nest at the end of the included file.= Can >>> they tell consistently when they hit the end of the included file? >>> Should there be an end-of-log marker for the included log?=20 >>>=20 >>> The Integrity-Hash directive is allowed to occur zero or once, not mult= iple >>> times in a logfile. >>> So if the CDN-C logfile contains an Integrity-Hash, should that be chec= ked >>> by CDN-B, then copy the CDN-C logfile into the CDN-B logfile, but disca= rd >>> the CDN-C Integrity-Hash, because CDN-B will calculate its own >>> Integrity-Hash directive? >>=20 >> Yes. >>=20 >>>=20 >>>> Let me know if that is not sufficient. >>>=20 >>> I remain concerned that cascaded logging may not have been adequately >>> described and standardized. >>=20 >> Right. I see that the questions you raised were not answered in the docu= ment. We will work on addressing them. >>=20 >> Thanks >>=20 >> Francois >>=20 >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Francois >>>=20 >>> dbh >>>=20 >>=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From nobody Thu Jul 3 02:04:18 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E120E1B27FA for ; Thu, 3 Jul 2014 02:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVZAXocfRYkl for ; Thu, 3 Jul 2014 02:04:14 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 949211B2809 for ; Thu, 3 Jul 2014 02:04:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8335; q=dns/txt; s=iport; t=1404378254; x=1405587854; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4wJWUVJguLyowII8cZlHDBNU1dA+sIZMS+7qudXNA4g=; b=ml4YByLdL1zyLXIQ9OYvyFxVr4M3mfhgpwNe7AG/fe4R+spwikz+kjiw aAgfMceAyHYJna/3Wlox1tGcPvPf9mjPk434lCH7eQGH1JJc6ZteerstJ QYzqwFz1pWjrxME6fXVLe5xtmTAOCZ1z9owi/jcSZxYaAj4hyXY2suyql 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAKgbtVOtJA2B/2dsb2JhbABagw2BLMYdAYEKFnWEAwEBAQR5EAIBCBguMiUCBA4FG4gnyBgXiWWFCjMHgy2BFgEEmm2UCoNDgjA X-IronPort-AV: E=Sophos;i="5.01,594,1400025600"; d="scan'208";a="337561428" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-4.cisco.com with ESMTP; 03 Jul 2014 09:04:13 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s6394Df0005451 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Jul 2014 09:04:13 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Thu, 3 Jul 2014 04:04:13 -0500 From: "Francois Le Faucheur (flefauch)" To: ietfdbh Thread-Topic: OPSDIR review of draft-ietf-cdni-logging-10 [Near-Real-Time Monitoring] Thread-Index: AQHPlp3Cr2IVOd5vGUOcoZ07nunjDg== Date: Thu, 3 Jul 2014 09:04:12 +0000 Message-ID: <1D09F2A3-6232-47C2-8461-37DA6AF22C53@cisco.com> References: <081201cf5114$153cdde0$3fb699a0$@comcast.net> <1529E311-1E88-495B-B53C-40E45503F896@cisco.com> In-Reply-To: <1529E311-1E88-495B-B53C-40E45503F896@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.200] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/SHGca8T6BPZraV5-UBI2nf5tkYI Cc: "Benoit Claise \(bclaise\)" , "cdni@ietf.org" , "spencer@wonderhamster.org" Subject: Re: [CDNi] OPSDIR review of draft-ietf-cdni-logging-10 [Near-Real-Time Monitoring] X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 09:04:17 -0000 David and all, (as a document editor) Please see below for the resolution of the comment from David=92s early Ops= Review about Ner-Real-Time Monitoring: On 16 Apr 2014, at 17:25, Francois Le Faucheur (flefauch) wrote: >>=20 >>=20 >> The proposed solution generally looks good for the deferred case, but se= ems >> inadequate for the near-real-time monitoring case. The document declares= the >> near-real-time support to be out of scope.=20 >=20 > Right. >=20 >>=20 >> Given the costs in time and resources of converting between logging form= ats, >> it may be really desirable to have one format that can serve both sets o= f >> needs. >=20 > Agreed. > We discussed this in the Working Group and while people agreed that was d= esirable, the group eventually decided to not aim for the second set of nee= ds because there was an urgent need to serve the first set of needs, it was= clear how to address it, it was not clear to our group how to address the = second and there was no I-Ds submitted on the second. =20 >=20 >> To a large degree, the proposed format could serve both purposes; >=20 > Right. And in fact, file based format is already used in practise today i= n some single-CDN environment for near-real-time monitoring. >=20 >> however, there are various points in the document that specify MUST >> requirements that would prevent using the solution for both use cases. >=20 > It woudl be great if we could clean up the document from the requirements= that prevents that. >=20 >> Mostly, these requirements imply that a "file" must be fully collected >> before sharing, and given the timeliness required by the monitoring use >> case, waiting until a file is fully collected makes the file approach >> unsuitable for monitoring. It can be feasible to use a logging file appr= oach >> for monitoring, if the log can be "tail"ed, thereby allowing the content= s to >> be passed as the collection is performed, without waiting for the file t= o be >> complete. >=20 > Agreed.=20 >=20 > In fact, this is what teh authors had in mind when writing: > =93 > We note that implementations of the CDNI Logging interface MAY also > support other mechanisms to exchange CDNI Logging Files, for example > in view of exchanging logging information with minimum time-lag > (e.g., sub-minute or sub-second) between when the event occurred in > the dCDN and when the corresponding Logging Record is made available > to the uCDN (e.g., for log-consuming applications requiring extremely > fresh logging information such as near-real-time content delivery > monitoring). Such mechanisms are for further study and outside the > scope of this document. > =93 > However, we did not realise that the text of 4.1.2 sort of prevents that. >=20 >>=20 >> In most of the network management protocols designed by the IETF, we >> recognize three parts - a data modeling language, data models, and a >> protocol that can transport portions of the data model. This document >> doesn't do a great job of keeping those separate. If the document was >> written with such separation in mind, then the record formats would be >> independent of how the file was going to be transported, and a logging >> record might be able to be used with two different approaches to transpo= rt - >> one suitable for deferred usage, where it can be expected that the file = is >> completed before transport, and another transport approach suitable for >> near-real-time transport of individual records, possibly using a tail >> approach for a file-based collection of records. The constraint in secti= on >> 4.1.2 is written in a manner that would seem to preclude a tail usage. >>=20 >> This concern might be able to be mitigated by changing some wordings in = the >> document. I think the document would be better if, rather than declaring= one >> set out of scope, it recognized the two sets of needs, and discussed how= the >> design of the data modeling language and data models could address both = sets >> of needs, while recognizing that different transport solutions might be >> needed to meet the two sets of needs, and there might be constraints on = the >> data model designs to be suitable for both needs. >=20 > All good points. >=20 > Currently: > * section 3 defines Fields, Records and FileFormat > * section 4 defines a File Exchange protocol >=20 > Effectively the data model is covered by section 3, while section 4 defin= es a transport solution for non-real-time (with constraints that preclude n= ear-real-time exchange via a =93Tail=94 like approach). >=20 > In line with your suggestion above, would it work for you if we: > * edited section 4 to : > - define it as the Transport Protocol for non-real-time exchange (as op= posed to describe it as THE file exchange protocol)=20 > * added a very brief section 4bis (ie between current section 4 and curr= ent section 5) that: > - discusses the fact that another transport protocol could be defined i= n the future (although out of scope for this document) that could provide n= ear-real-time exchange of the CDNI Logging records defined in section 3, su= ch as a Tail-based approach.=20 > - discusses the fact that this would ensure that the same CDNI logging = information (ie Records) can be used for both non-real-time and near-real-t= ime applications. I have edited the documents as discussed above. The beginning of section 4 now reads: " 4. Protocol for Exchange of CDNI Logging File After Full Collection This section specifies a protocol for the exchange of CDNI Logging Files as specified in Section 3 after the CDNI Logging File is fully collected by the dCDN. This protocol comprises: o a CDNI Logging feed, allowing the dCDN to notify the uCDN about the CDNI Logging Files that can be retrieved by that uCDN from the dCDN, as well as all the information necessary for retrieving each of these CDNI Logging Files. The CDNI Logging feed is specified in Section 4.1. o a CDNI Logging File pull mechanism, allowing the uCDN to obtain from the dCDN a given CDNI Logging File at the uCDN's convenience. The CDNI Logging File pull mechanisms is specified in Section 4.2. An implementation of the CDNI Logging interface on the dCDN side (the entity generating the CDNI Logging file) MUST support the server side of the CDNI Logging feed (as specified in Section 4.1) and the server side of the CDNI Logging pull mechanism (as specified in Section 4.2). An implementation of the CDNI Logging interface on the uCDN side (the entity consuming the CDNI Logging file) MUST support the client side of the CDNI Logging feed (as specified in Section 4.1) and the client side of the CDNI Logging pull mechanism (as specified in Section 4.2). =93 and I have added a new section: =93 5. Protocol for Exchange of CDNI Logging File During Collection We note that, in addition to the CDNI Logging File exchange proptocol specified in Section 4, implementations of the CDNI Logging interface MAY also support other mechanisms to exchange CDNI Logging Files, in particular mechanisms allowing the exchange of the CDNI Logging File to start before the file is fully collected. This can allow CDNI Logging Records to be communicated by the dCDN to the uCDN as they are gathered by the dCDN without having to wait until all the CDNI Logging Records of the same logging period are collected in the corresponding CDNI Logging File (an approach commonly referred to as "tailing" of the file). Such an approach could be used, for example, to exchange logging information with a significantly reduced time-lag (e.g., sub-minute or sub-second) between when the event occurred in the dCDN and when the corresponding CDNI Logging Record is made available to the uCDN. This can satisfy log-consuming applications requiring extremely fresh logging information such as near-real-time content delivery monitoring. Such mechanisms are for further study and outside the scope of this document. =93 Cheers Francois From nobody Thu Jul 3 08:12:09 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCB711A019C for ; Thu, 3 Jul 2014 08:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugrBvKuRU4ZW for ; Thu, 3 Jul 2014 08:12:07 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F7871A00F8 for ; Thu, 3 Jul 2014 08:12:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=267; q=dns/txt; s=iport; t=1404400327; x=1405609927; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=90E3jKlkUWwozUwJqiHANGXHwxKYMpGJhMKs/EMwe00=; b=WwP/NOy0qvF2yyIlDPAxDHn/tIH6VPqVmsMDLzg3qFC+eAzi42YBP9OW 5QZl12eYsT1hK9Ovr2ai8IfgLHrTSJwxnTKIRcIpvSmLX16iXcqvvmqXb hEqio5/uziP0q6ZRhzBDmf8fztScqQM7lcKWCJm7xvZoThlcryxkD7bpC w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQFAKlxtVOtJV2S/2dsb2JhbABagw1SWo0TuQAKgQoWdYQKeRIBgQAnBA4OiDkNySgXjyKDNIEWBZptlAqDQ4Iw X-IronPort-AV: E=Sophos;i="5.01,595,1400025600"; d="scan'208";a="58092263" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-2.cisco.com with ESMTP; 03 Jul 2014 15:12:07 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s63FC6CV032197 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Jul 2014 15:12:07 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Thu, 3 Jul 2014 10:12:04 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: CDNI WG Toronto Meeting Draft Agenda Thread-Index: AQHPltEl7AwYiMmN0kqWK7/QckPR+w== Date: Thu, 3 Jul 2014 15:12:04 +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.200] Content-Type: text/plain; charset="Windows-1252" Content-ID: <40562E864BCBFC4E9A9F21463000A25B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/09cC6p6InuqgvisOOa0YJ-0Gvuk Subject: [CDNi] CDNI WG Toronto Meeting Draft Agenda X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 15:12:09 -0000 Folks, A draft agenda has been posted for our meeting in Toronto: http://www.ietf.org/proceedings/90/agenda/agenda-90-cdni Please review and let us know if you have comments (or if you=92d like a sl= ot that is not there yet). Cheers Francois & Daryl= From nobody Thu Jul 3 10:36:22 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC7CC1A024F for ; Thu, 3 Jul 2014 10:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.1 X-Spam-Level: ** X-Spam-Status: No, score=2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_31=1, J_BACKHAIR_37=1, J_BACKHAIR_44=1, J_BACKHAIR_52=1] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNpQDhvkbagr for ; Thu, 3 Jul 2014 10:36:18 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 03F3C1A016F for ; Thu, 3 Jul 2014 10:36:17 -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 1X2kve-0000Pb-Ic; Thu, 03 Jul 2014 18:36:16 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ben Niven-Jenkins In-Reply-To: <315A2A4B-C876-4FF7-A836-7D48AC191195@cisco.com> Date: Thu, 3 Jul 2014 18:36:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <78CC1EB7-8194-4DC0-9CDC-B588F9FB34D2@niven-jenkins.co.uk> References: <038401cf5b4f$0b5ea610$221bf230$@comcast.net> <05BD7B6B-6886-4277-8A8A-8AE77363939B@cisco.com> <315A2A4B-C876-4FF7-A836-7D48AC191195@cisco.com> To: Francois Le Faucher X-Mailer: Apple Mail (2.1878.2) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/vQOvNEH0acB_VXM6dBenRzaSojc Cc: "Benoit Claise \(bclaise\)" , "cdni@ietf.org" , ietfdbh , "spencer@wonderhamster.org" Subject: Re: [CDNi] OPSDIR review of draft-ietf-cdni-logging-10 - cascade logging X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 17:36:22 -0000 Francois, I reviewed the text and it looks good to me. It did raise a couple of questions in my head around Verified-Origin and = Claimed-Origin field directives but I=92ll raise that in a separate = thread as it is not related to the OPSDIR review. Ben On 2 Jul 2014, at 15:39, Francois Le Faucheur (flefauch) = wrote: >=20 > On 1 Jul 2014, at 20:09, Francois Le Faucheur (flefauch) = wrote: >=20 >> Folks, >>=20 >> (as a document editor) >>=20 >> To address the point around cascaded CDNs that was raised by David = Harrington as part of his early Ops Review, I have: >> * expanded section 3.5 =93CDNI Logging File Example=94 >> * added a section 3.6 "Cascaded CDNI Logging Files Example=94 >>=20 >> Draft text is below. I=92d appreciate some reviews. >=20 > I did a bit more work on teh text. Latest version below. Again will = appreciate a good review: >=20 > 3.5. CDNI Logging File Example >=20 > Let us consider the upstream CDN and the downstream CDN labelled = uCDN > and dCDN-1 in Figure 1. When dCDN-1 acts as a downstream CDN for > uCDN and performs content delivery on behalf of uCDN, dCDN-1 will > include the CDNI Logging Records corresponding to the content > deliveries performed on behalf of uCDN in the CDNI Logging Files for > uCDN. An example CDNI Logging File communicated by dCDN-1 to uCDN = is > shown below in Figure 4. >=20 > #Version:CDNI/1.0 >=20 > #UUID:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 >=20 > #Claimed-Origin:cdni-logging-entity.dcdn-1.example.com >=20 > #Record-Type:cdni_http_request_v1 >=20 > #Fields:datetimetime-takenc-ip > cs-methodu-uriprotocolsc-status > sc-total-bytescs(User-Agent)cs(Referer) > s-cached >=20 > 2013-05-1700:38:06.8259.05810.5.7.1GET > http://cdni-ucdn.dcdn-1.example.com/video/movie100.mp4 > HTTP/1.12006729891"Mozilla/5.0 > (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like > Gecko) Chrome/5.0.375.127 Safari/533.4" > "host1.example.com"1 >=20 > 2013-05-1700:39:09.14515.3210.5.10.5GET > http://cdni-ucdn.dcdn-1.example.com/video/movie118.mp4 > HTTP/1.120015799210"Mozilla/5.0 > (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like > Gecko) Chrome/5.0.375.127 Safari/533.4" > "host1.example.com"1 >=20 > = 2013-05-1700:42:53.43752.87910.5.10.5GET > http://cdni-ucdn.dcdn-1.example.com/video/picture11.mp4 > HTTP/1.020097234724"Mozilla/5.0 > (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like > Gecko) Chrome/5.0.375.127 Safari/533.4" > "host5.example.com"0 >=20 > #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >=20 > [Editor's Note: compute the correct Integrity-Hash value once example > is frozen] >=20 >=20 > Figure 4: CDNI Logging File Example >=20 > If uCDN establishes by some means (e.g. via TLS authentication when > pulling the CDNI Logging File) the identity of the entity from which > it pulled the CDNI Logging File, uCDN can add to the CDNI Logging a > Verified-Origin directive as illustrated below: >=20 > #Verified-Origin:cdni-logging-entity.dcdn-1.example.com >=20 > As illustrated in Figure 2, uCDN will then ingest the corresponding > CDNI Logging Records into its Collection process, alongside the > Logging Records generated locally by the uCDN itself. This allows > uCDN to aggregate Logging Records for deliveries performed by itself > (through Records generated locally) as well as for deliveries > performed by its downstream CDN(s). This aggregate information can > then be used (after Filtering and Rectification, as illustrated in > Figure 2) by Log Consuming Applications that take into account > deliveries performed by uCDN as well as by all of its downstream > CDNs. >=20 > We observe that the time between >=20 > 1. when a delivery is completed in dCDN and >=20 > 2. when the corresponding Logging Record is ingested by the > Collection process in uCDN >=20 > depends on a number of parameters such as the Logging Period agreed > to by uCDN and dCDN, how much time uCDN waits before pulling the = CDNI > Logging File once it is advertised in the CDNI Logging Feed, and the > time to complete the pull of the CDNI Logging File. Therefore, if = we > consider the set of Logging Records aggregated by the Collection > process in uCDN in a given time interval, there could be a permanent > significant timing difference between the CDNI Logging Records > received from the dCDN and the Logging Records generated locally. > For example, in a given time interval, the Collection process in = uCDN > may be aggregating Logging Records generated locally by uCDN for > deliveries performed in the last hour and CDNI Logging Records > generated in the dCDN for deliveries in the hour before last. >=20 > 3.6. Cascaded CDNI Logging Files Example >=20 > Let us consider the cascaded CDN scenario of uCDN, dCDN-2 and dCDN-3 > as depicted in Figure 1. After completion of a delivery by dCDN-3 = on > behalf of dCDN-2, dCDN-3 will include a corresponding Logging Record > in a CDNI Logging File that will be pulled by dCDN-2 and that is > illustrated below in Figure 5. In practice, a CDNI Logging File is > likely to contain a very high number of CDNI Logging Records. > However, for readability, the example in Figure 5 contains a single > CDNI Logging Record. >=20 >=20 > #Version:CDNI/1.0 >=20 > #UUID:urn:uuid:65718ef-0123-9876-adce4321bcde >=20 > #Claimed-Origin:cdni-logging-entity.dcdn-3.example.com >=20 > #Record-Type:cdni_http_request_v1 >=20 > #Fields:datetimetime-takenc-ip > cs-methodu-uriprotocolsc-status > sc-total-bytescs(User-Agent)cs(Referer) > s-cached >=20 > = 2013-05-1700:39:09.11914.0710.5.10.9GET > http://cdni-dcdn-2.dcdn-3.example.com/video/movie118.mp4 > HTTP/1.120015799210"Mozilla/5.0 > (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like > Gecko) Chrome/5.0.375.127 Safari /533.4" > "host1.example.com"1 >=20 > #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >=20 > [Editor's Note: compute the correct Integrity-Hash value once = example > is frozen] >=20 > Figure 5: Cascaded CDNI Logging File Example (dCDN-3 to dCDN-2) >=20 > If dCDN-2 establishes by some means (e.g. via TLS authentication = when > pulling the CDNI Logging File) the identity of the entity from which > it pulled the CDNI Logging File, dCDN-2 can add to the CDNI Logging = a > Verified-Origin directive as illustrated below: >=20 > #Verified-Origin:cdni-logging-entity.dcdn-3.example.com >=20 > dCDN-2 (behaving as an upstream CDN from the viewpoint of dCDN-3) > will then ingest the CDNI Logging Record for the considered dCDN-3 > delivery into its Collection process (as illustrated in Figure 2). > This Logging Record may be aggregated with Logging Records generated > locally by dCDN-2 for deliveries performed by dCDN-2 itself. Say, > for illustration, that the content delivery performed by dCDN-3 on > behalf of dCDN-2 had actually been redirected to dCDN-2 by uCDN, and > say that another content delivery has just been redirected by uCDN = to > dCDN-2 and that dCDN-2 elected to perform the corresponding delivery > itself. Then after Filtering and Rectification (as illustrated in > Figure 2), dCDN-2 will include the two Logging Records corresponding > respectively to the delivery performed by dCDN-3 and the delivery > performed by dCDN-2, in the next CDNI Logging File that will be > communicated to uCDN. An example of such CDNI Logging File is > illustrated below in Figure 6. >=20 > #Version:CDNI/1.0 >=20 > #UUID:urn:uuid:1234567-8fedc-abab-0987654321ff >=20 > #Claimed-Origin:cdni-logging-entity.dcdn-2.example.com >=20 > #Record-Type:cdni_http_request_v1 >=20 > #Fields:datetimetime-takenc-ip > cs-methodu-uriprotocolsc-status > sc-total-bytescs(User-Agent)cs(Referer) > s-cached >=20 > 2013-05-1700:39:09.11914.0710.5.10.9GET > http://cdni-ucdn.dcdn-2.example.com/video/movie118.mp4 > HTTP/1.120015799210"Mozilla/5.0 > (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like > Gecko) Chrome/5.0.375.127 Safari /533.4" > "host1.example.com"1 >=20 > = 2013-05-1701:42:53.43752.87910.5.10.12GET > http://cdni-ucdn.dcdn-2.example.com/video/picture11.mp4 > HTTP/1.020097234724"Mozilla/5.0 > (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like > Gecko) Chrome/5.0.375.127 Safari /533.4" > "host5.example.com"0 >=20 > #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >=20 > [Editor's Note: compute the correct Integrity-Hash value once example > is frozen] >=20 > Figure 6: Cascaded CDNI Logging File Example (dCDN-2 to uCDN) >=20 > If uCDN establishes by some means (e.g. via TLS authentication when > pulling the CDNI Logging File) the identity of the entity from which > it pulled the CDNI Logging File, uCDN can add to the CDNI Logging a > Verified-Origin directive as illustrated below: >=20 > #Verified-Origin:cdni-logging-entity.dcdn-2.example.com >=20 > In the example of Figure 6, we observe that: >=20 > o the first Logging Record corresponds to the Logging Record > communicated earlier to dCDN-2 by dCDN-3, which corresponds to a > delivery redirected by uCDN to dCDN-2 and then redirected by > dCDN-2 to dCDN-3. Its initial fields values are preserved, with > the exception of the u-uri that now reflects the URI convention > between uCDN and dCDN-2, and which presents the delivery to uCDN > as if it was performed by dCDN-2 itself, which reflects the fact > that dCDN-2 had taken the full responsibility of the = corresponding > delivery (even if in this case, dCDN-2 elected to redirect the > delivery to dCDN-3 so it is actually performed by dCDN-3 on = behalf > of dCDN-2). >=20 > o the second Logging Record corresponds to a delivery redirected by > uCDN to dCDN-2 and performed by dCDN-2 itself. The time of the > delivery in this Logging Record may be significantly more recent > than the first Logging Record since it was generated locally = while > the first Logging Record was generated by dCDN-3 and had to be > advertised , and then pulled and then ingested into the dCDN-2 > Collection process, before being aggregated with the second > Logging Record. >=20 >=20 >=20 > Cheers >=20 > Francois >=20 >=20 >=20 >>=20 >> Thanks >>=20 >> Francois >>=20 >> " >>=20 >> 3.5. CDNI Logging File Example >>=20 >> Let us consider the upstream CDN and the downstream CDN labelled = uCDN >> and dCDN-1 in Figure 1. When dCDN-1 acts as a downstream CDN for >> uCDN and performs content delivery on behalf of uCDN, dCDN-1 will >> include the CDNI Logging Records corresponding to the content >> deliveries performed on behalf of uCDN in the CDNI Logging Files for >> uCDN. An example CDNI Logging File communicated by dCDN-1 to uCDN = is >> show below: >>=20 >> " >>=20 >> #Version:CDNI/1.0 >>=20 >> #UUID:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 >>=20 >> #Claimed-Origin:cdni-logging-entity.dcdn-1.example.com >>=20 >> #Record-Type:cdni_http_request_v1 >>=20 >> #Fields:datetimetime-takenc-ipcs- >> methodu-uriprotocolsc-statussc-total- >> bytescs(User-Agent)cs(Referer)s-cached >>=20 >> = 2013-05-1700:38:06.8259.05810.5.7.1GETh >> ttp://cdni-ucdn.dcdn-1.example.com/video/ >> movie100.mp4HTTP/1.12006729891"Mozilla/5.0 >> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >> Gecko) Chrome/5.0.375.127 Safari >> /533.4""host1.example.com"1 >>=20 >> = 2013-05-1700:39:09.14515.3210.5.10.5GET >> http://cdni-ucdn.dcdn-1.example.com/video/ >> movie118.mp4HTTP/1.120015799210"Mozilla/5.0 >> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >> Gecko) Chrome/5.0.375.127 Safari >> /533.4""host1.example.com"1 >>=20 >> = 2013-05-1700:42:53.43752.87910.5.10.5GET>> http://cdni-ucdn.dcdn-1.example.com/video/ >> picture11.mp4HTTP/1.020097234724"Mozilla/5.0 >> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >> Gecko) Chrome/5.0.375.127 Safari >> /533.4""host5.example.com"0 >>=20 >> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >>=20 >> [Editor's Note: compute the correct Integrity-Hash value once = example >> is frozen] >>=20 >> " >>=20 >> As illustrated in Figure 2, uCDN will then ingest the corresponding >> CDNI Logging Records into its Collection process, alongside the >> Logging Records generated locally by the uCDN itself. This allows >> uCDN to aggregate Logging Records for deliveries performed by itself >> (through Records generated locally) as well as for deliveries >> performed by its downstream CDN(s). This aggregate information can >> then be used (after Filtering and Rectification, as illustrated in >> Figure 2) by Log Consuming Applications considering deliveries >> performed by uCDN as well as by all its downstream CDN(s). >>=20 >> We observe that the time between >>=20 >> 1. when a delivery is completed in dCDN and >>=20 >> 2. when the corresponding Logging Record is ingested by the >> Collection process in uCDN >>=20 >> depends on a number of parameters such as the Logging Period agreed >> to by uCDN and dCDN, how much time uCDN waits after it is advertised >> in the CDNI Logging Feed before pulling the CDNI Logging File, and >> the time to complete the pull of the CDNI Logging File. Therefore, >> if we consider the set of Logging Records aggregated by the >> Collection process in uCDN in a given time interval, there could be = a >> permanent significant timing difference between the CDNI Logging >> Records received from the dCDN and the Logging Records generated >> locally. For example, in a given time interval, the Collection >> process in uCDN may be aggregating Logging Records generated locally >> by uCDN for deliveries performed in the last hour and CDNI Logging >> Records generated in the dCDN for deliveries in the hour before = last. >>=20 >> 3.6. Cascaded CDNI Logging Files Example >>=20 >> Let us consider the cascaded CDN scenario of uCDN, dCDN-2 and dCDN-3 >> as depicted in Figure 1. After completion of a delivery by dCDN-3 = on >> behalf of dCDN-2, dCDN-3 will include a corresponding Logging Record >> in a CDNI Logging File and will advertise this CDNI Logging File to >> d-CDN2 in the corresponding CDNI Logging feed. As a result, dCDN-2 >> will initiate and complete the pull of the corresponding CDNI = Logging >> File that is illustrated below: >>=20 >> " >>=20 >> #Version:CDNI/1.0 >>=20 >> #UUID:urn:uuid:65718ef-0123-9876-adce4321bcde >>=20 >> #Claimed-Origin:cdni-logging-entity.dcdn-3.example.com >>=20 >> #Record-Type:cdni_http_request_v1 >>=20 >> #Fields:datetimetime-takenc-ipcs- >> methodu-uriprotocolsc-statussc-total- >> bytescs(User-Agent)cs(Referer)s-cached >>=20 >> = 2013-05-1700:39:09.14515.3210.5.10.5GET >> http://cdni-dcdn-2.dcdn-3.example.com/video/movie118.mp4HTTP/ >> 1.120015799210"Mozilla/5.0 (Windows; U; Windows NT >> 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 >> Safari /533.4""host1.example.com"1 >>=20 >> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >>=20 >> [Editor's Note: compute the correct Integrity-Hash value once = example >> is frozen] >>=20 >> " >>=20 >> dCDN-2 (behaving as an upstream CDN from the viewpoint of dCDN-3) >> will then ingest the CDNI Logging Record for the considered dCDN-3 >> delivery into its Collection process (as illustrated in Figure 2). >> This Logging Record may be aggregated with Logging Records generated >> locally by dCDN-2 for deliveries performed by dCDN-2 itself. Say, >> for illustration, that the content delivery performed by dCDN-3 on >> behalf of dCDN-2 had actually been redirected to dCDN-2 by uCDN, and >> say that another content delivery has just been redirected by uCDN = to >> dCDN-2 and that dCDN-2 elected to perform the corresponding delivery >> itself. Then after Filtering and Rectification (as illustrated in >> Figure 2), dCDN-2 will include the two Logging Records corresponding >> respectively to the delivery performed by dCDN-3 and the delivery >> performed by dCDN-2, in the next CDNI Logging File that will be >> communcated to uCDN. An example of such CDNI Logging File is >> illustrated below: >>=20 >> #Version:CDNI/1.0 >>=20 >> #UUID:urn:uuid:1234567-8fedc-abab-0987654321ff >>=20 >> #Claimed-Origin:cdni-logging-entity.dcdn-2.example.com >>=20 >> #Record-Type:cdni_http_request_v1 >>=20 >> #Fields:datetimetime-takenc-ipcs- >> methodu-uriprotocolsc-statussc-total- >> bytescs(User-Agent)cs(Referer)s-cached >>=20 >> = 2013-05-1700:39:09.14515.3210.5.10.5GET >> http://cdni-ucdn.dcdn-2.example.com/video/movie118.mp4HTTP/ >> 1.120015799210"Mozilla/5.0 (Windows; U; Windows NT >> 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 >> Safari /533.4""host1.example.com"1 >>=20 >> = 2013-05-1701:42:53.43752.87910.5.10.5GET>> http://cdni-ucdn.dcdn-2.example.com/video/picture11.mp4HTTP/ >> 1.020097234724"Mozilla/5.0 (Windows; U; Windows NT >> 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 >> Safari /533.4""host5.example.com"0 >>=20 >> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >>=20 >> [Editor's Note: compute the correct Integrity-Hash value once = example >> is frozen] >>=20 >> " >>=20 >> In the example above, we observe that: >>=20 >> o the first Logging Record corresponds to the Logging Record >> communicated earlier to dCDN-2 by dCDN-3, which corresponds to a >> delivery redirected by uCDN to dCDN-2 and then redirected by >> dCDN-2 to dCDN-3. Its initial fields values are preserved, with >> the exception of the u-uri that now reflects the URI convention >> between uCDN and dCDN-2, and which presents the delivery to uCDN >> as if it was performed by dCDN-2 itself, which reflects the fact >> that dCDN-2 had taken the full responsibility of the = corresponding >> delivery (even if in this case, dCDN-2 elected to redirect the >> delivery to dCDN-3 so it is actually performed by dCDN-3 on = behalf >> of dCDN-2). >>=20 >> o the second Logging Record corresponds to a delivery redirected by >> uCDN to dCDN-2 and performed by dCDN-2 itself. The time of the >> delivery in this Logging Record may be significantly more recent >> than the first Logging Record since it was generated locally = while >> the first Logging Record was generated by dCDN-3 and had to be >> advertised , and then pulled and then ingested into the dCDN-2 >> Collection process, before being aggregated with the second >> Logging Record. >>=20 >> " >>=20 >>=20 >> On 23 Apr 2014, at 20:29, Francois Le Faucheur (flefauch) = wrote: >>=20 >>> Hello, >>>=20 >>> On 18 Apr 2014, at 23:42, ietfdbh wrote: >>>>>=20 >>>>> On 5 Apr 2014, at 23:14, ietfdbh wrote: >>>>>>=20 >>>>>>=20 >>>>>> Most notably, the logging from a dCDN to a uCDN typically = contains only >>>>> one >>>>>> dCDN identifier, such as Verified-origin, and doesn't really = permit >>>>>> specifying a sub-ordinate dCDN. For example, in a cascade such as = CDN-A >>>> - >>>>>>=20 >>>>>> CDN-B -> CDN-C, CDN-C will share logging info with CDN-B, but not = with >>>>>> CDN-A; CDN-B shares logging info with CDN-A. This can be = desirable for >>>>>> hiding the topology and delegation used by the dCDN. However, = this >>>>> document >>>>>> does not discuss how the logging provided by CDN-C gets converted = into >>>>> the >>>>>> logs for CDN-B that will be sent to CDN-A. Without some logging >>>>> information >>>>>> from CDN-C, it would seem difficult for CDN-A to utilize the = information >>>> to >>>>>> meet requirements of billing, analytics, and fault and = performance >>>> analysis. >>>>>> Maybe the logging gets aggregated and reported in CDN-B's = logging, >>>>>=20 >>>>> Exactly. >>>>>=20 >>>>>> but that >>>>>> "transitive or aggregate logging" doesn't appear to be discussed = in this >>>>>> document. >>>>>=20 >>>>> It is discussed in section 2.1 through Figure 1 and the following = text: >>>>> " >>>>> A dCDN (e.g., dCDN-2) integrates the relevant Logging information >>>>> obtained from its dCDNs (i.e., dCDN-3) in the Logging information >>>>> that it provides to the uCDN, so that the uCDN ultimately obtains = all >>>>> Logging information relevant to a CSP for which it acts as the >>>>> authoritative CDN. >>>>> " >>>>> Does that address your concern? >>>>=20 >>>> No it does not mitigate my concern. >>>>=20 >>>> This says the information gets "integrated", but doesn't describe = what >>>> integrated means. >>>> I could interpret that integration would be that the logging from = CDN-C >>>> would be included in the logs from CDN-B to CDN-A, >>>> But I think the text says CDN-B will not share the logging entries = from >>>> CDN-C with CDN-A. >>>> Do I have this wrong? Does CDN-B create a log file and generate = entries, >>>> and then when it delegates delivery to CDN-C, and CDN-C passes its = log file >>>> back to CDN-B, does CDN-B take the whole log file from CDN-B and = insert it >>>> into its own log file, then continue adding any more entries, and = then when >>>> done send the CDN-B log file (including a fully inserted CDN-C log = file) to >>>> CDN-A? >>>>=20 >>>> If not, that presumably means that somehow, the data from CDN-C is >>>> "aggregated" - that's how it is "integrated=94, >>>=20 >>> Right. It is aggregated. >>> Effectively, if CDN-B has sub-delegated a delivery to CDN-C, then = when CDN-C provides a log record for that delivery to CDN-B, CDN-B will = aggregate that log record with the log records for the deliveries that = CDN-B conduted itself. When CDN-B provides log records to CDN-A, the log = record corresponding to the delivery performed by CDN-C is turned by = CDN-B into a log record that looks like the delivery was done by CDN-B. = CDN-A will not be aware that the delivery was performed by another CDN = than CDN-B (just like the Content Provider is not ware that the delivery = was not performed by CDN-A with whom it has a delivery contract). >>>=20 >>>> But there is no discussion of how this aggregation is done. >>>=20 >>> That is true. I think it has been assumed by many but never made = clear. So we need to add some discussion about that. >>>=20 >>>> I think your intent is to hide the fact that CDN-B used CDN-C, = since that >>>> may reflect a proprietary approach of CDN-B's business model. >>>=20 >>> Right. >>>=20 >>>> But CDN-A would presumably have problems performing analytics, and = fault and >>>> performance analysis, if the data from CDN-C is not included in = CDN-B's >>>> logging to CDN-A.=20 >>>> So I would like an example to demonstrate what CDN-A would see in = CDN-B's >>>> logs if CDN-C had faults or performance problems, and I would like = to see >>>> how CDN-A could perform analytics (of any kind) relating to the = delivery >>>> performed by CDN-C. >>>=20 >>> The assumption is that CDN-A is only dealing with CDN-B. CDN-A may = not not even be aware of CDN-C.=20 >>> So CDN-A analaytics/monitoring will establish whether all the = deliveries delegated to CDN-B (comprising deliveries performed by CDN-B = as well as deliveries redirected by CDN-B to CDN-C and possibly CDN-C2) = have received the right quality (ie if CDN-B has met the SLA committed = to CDN-A). >>> If some deliveries have experienced quality problems, CDN-A will = blame CDN-B. It is up to CDN-B to then do its own analytics and = monitoring to decide whether the problem lies within his own CDN or = CDN-C or CDN-C2.=20 >>> The whole thing operates as a chain of delegations, like many other = business arrangements: if my SmartPhone does not work, I blame the = smartPhone vendor (I don=92t try identify if the problem is coming from = the supplier of the GSM chipset, but the SmartPhone vendor will). >>>=20 >>>=20 >>>=20 >>>> I am missing how this would be done (especially in a standardized = manner). >>>>=20 >>>>>=20 >>>>>>=20 >>>>>> I think Verified-Origin is particularly problematic, because the = text >>>> states >>>>>> that this can only be added by the uCDN, never the dCDN. So what = if >>>> CDN-B >>>>>> verifies the origin of the logs from CDN-C and then passes the >>>> information >>>>>> (now as a dCDN) to CDN-A? The text mentions that this might be >>>>> established >>>>>> using authentication mechanisms; so do we lose this logged >>>>>> authentication/verification when cascading? >>>>>>=20 >>>>>> (Maybe this is resolved by having the uCDN (CDN-B) record a >>>> "transaction" >>>>>> that starts when it delegates a task to a dCDN (e.g. CDN-C) and = ends >>>> when >>>>>> the dCDN completes the task, and the uCDN just records the whole >>>>> transaction >>>>>> without the details that are reported by CDN-C. Then CDN-B logs = only the >>>>>> whole transaction. I would like to see an explicit example of = such >>>> logging, >>>>>> using the cdni_http_request_v1 record-type, so this is clear.) >>>>>=20 >>>>> Yes, that is pretty much the idea. >>>>> ie. if CDN-a delegate sto CDN-B then CDB-B is responsible for = delivering >>>> and >>>>> will provide a delivery record to CDN-A for that delivery. That = record >>>> will be >>>>> part of a Logging File whose origin in CDN-B, and CDN-A can use >>>>> authentication mechanism to ensure the Logging File is provided by = CDN-B. >>>>> All of this completely holds whether CDN-B performed the delivery = itself >>>>> (and created the delivery record in the first place) or CDN-B = delegated to >>>>> CDN-C who provided the delivery record to CDN-B in a Logging File = whose >>>>> origin was CDN-C. >>>>>=20 >>>>> This question has come up before so I will add a clarification = along the >>>> lines >>>>> above under the description of the Verified Origin in case of = cascaded >>>> CDNs. >>>>=20 >>>> An example of such integrated cascaded logging might answer many = questions. >>>=20 >>> Good idea.=20 >>> It sounds worthwhile to give a descripton of how log records get = aggregated in a csacaded scenario, indicate how directives/fields get = modified/kept at each CDN hop, and possibly include an example with some = log records and how they propagate from CDN-C to CDN-B to CDN-A. >>>=20 >>>> If logging records from CDN-C get copied into the log from CDN-B, = are all >>>> directives and record types copied? >>>> If so, I think it is important to make clear that a given log might = contain >>>> multiple nested logs, >>>> And that means that the file received by CDN-A might start with = directives >>>> for CDN-B plus records,=20 >>>> And then directives for CDN-C, ending with an Integrity-Hash, and = more >>>> records for CDN-B followed by an Integrity-Hash. >>>> Maybe this is all as designed, but I haven't seen discussion of = that, and it >>>> is not reflected in Figure 3, and this is not discussed in the = description >>>> of fields that are file-specific, such as Integrity-hash, = Verfiied-origin, >>>> Version, UUID, etc. >>>> If you have nested logs, then log-consuming applications need to = know that >>>> those file-specific directives un-nest at the end of the included = file. Can >>>> they tell consistently when they hit the end of the included file? >>>> Should there be an end-of-log marker for the included log?=20 >>>>=20 >>>> The Integrity-Hash directive is allowed to occur zero or once, not = multiple >>>> times in a logfile. >>>> So if the CDN-C logfile contains an Integrity-Hash, should that be = checked >>>> by CDN-B, then copy the CDN-C logfile into the CDN-B logfile, but = discard >>>> the CDN-C Integrity-Hash, because CDN-B will calculate its own >>>> Integrity-Hash directive? >>>=20 >>> Yes. >>>=20 >>>>=20 >>>>> Let me know if that is not sufficient. >>>>=20 >>>> I remain concerned that cascaded logging may not have been = adequately >>>> described and standardized. >>>=20 >>> Right. I see that the questions you raised were not answered in the = document. We will work on addressing them. >>>=20 >>> Thanks >>>=20 >>> Francois >>>=20 >>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Francois >>>>=20 >>>> dbh >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> 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 From nobody Thu Jul 3 10:39:34 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E451A034E for ; Thu, 3 Jul 2014 10:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.1 X-Spam-Level: ** X-Spam-Status: No, score=2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_31=1, J_BACKHAIR_37=1, J_BACKHAIR_44=1, J_BACKHAIR_52=1] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5cA8Z7c2zJWH for ; Thu, 3 Jul 2014 10:39:25 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED871A023E for ; Thu, 3 Jul 2014 10:39:24 -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 1X2kyg-0002QK-7N; Thu, 03 Jul 2014 18:39:23 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ben Niven-Jenkins In-Reply-To: <315A2A4B-C876-4FF7-A836-7D48AC191195@cisco.com> Date: Thu, 3 Jul 2014 18:39:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <038401cf5b4f$0b5ea610$221bf230$@comcast.net> <05BD7B6B-6886-4277-8A8A-8AE77363939B@cisco.com> <315A2A4B-C876-4FF7-A836-7D48AC191195@cisco.com> To: Francois Le Faucher X-Mailer: Apple Mail (2.1878.2) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/Yzzaw2Tt9VLXyByMD5BmAByhDJ4 Cc: "cdni@ietf.org" Subject: [CDNi] Utility of Verified-Origin & Claimed-Origin in CDNI logging X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 17:39:28 -0000 Francois, Colleagues, Reading your suggested text below made me ponder on the purpose and = utility of the Claimed-Origin and Verified-Origin field directives. Let=92s start with Verified-Origin. =46rom your text below and reading = the definition of Verified-Origin in section 3.3 of = draft-ietf-cdni-logging-11 I understand that a dCDN MUST NOT place a = Verified-Origin field directive in a log file it sends to a uCDN (it is = the uCDN=92s job to do that if it wants to once it has verified the = origin). Furthermore in a cascaded scenario (uCDN-tCDN-dCDN) the transit = CDN MUST NOT include a Verified-Origin field directive in a log file it = sends to uCDN and by implication if tCDN inserted a Verified-Origin = directive when receiving from dCDN, it must strip it before sending that = log file on to uCDN. Therefore use of Verified-Origin is purely internal to a given CDN, is = never exchanged between CDNs and has no role to play in interoperation = of CDNI between CDNs, so why does the logging draft need to specify it = at all? CDNs that want the functionality of Verified-Origin can do = whatever they want internally to implement that, it doesn=92t seem we = need something in the RFC to support the internal behaviour of a CDN. That then got me thinking about Claimed-Origin. If I read the text below = correctly, my understanding is that the value of Claimed-Origin should = be the same hostname in the dCDN that the uCDN connects to in order to = retrieve log files. So for example a uCDN could compare the value of = Claimed-Origin against the values of subjectAltName in the TLS = certificate presented by the dCDN and if there is a match then the = Claimed-Origin can be =93verified=94. I=92m struggling to see what value Claimed-Origin gives in practice, = possibly because I don=92t understand the use case for it. If the = purpose is to let a uCDN do the comparison I describe above then I=92m = not sure that gives us much in reality. Claimed-Origin becomes = essentially a hop-by-hop (CDN-by-CDN) property and assuming the dCDN = identifies itself correctly (e.g. hostname in dCDN that uCDN connected = to matches hostname(s) in TLS certificate presented by dCDN) = Claimed-Origin is adding nothing, or have I misunderstood? Thanks Ben On 2 Jul 2014, at 15:39, Francois Le Faucheur (flefauch) = wrote: >=20 > On 1 Jul 2014, at 20:09, Francois Le Faucheur (flefauch) = wrote: >=20 >> Folks, >>=20 >> (as a document editor) >>=20 >> To address the point around cascaded CDNs that was raised by David = Harrington as part of his early Ops Review, I have: >> * expanded section 3.5 =93CDNI Logging File Example=94 >> * added a section 3.6 "Cascaded CDNI Logging Files Example=94 >>=20 >> Draft text is below. I=92d appreciate some reviews. >=20 > I did a bit more work on teh text. Latest version below. Again will = appreciate a good review: >=20 > 3.5. CDNI Logging File Example >=20 > Let us consider the upstream CDN and the downstream CDN labelled = uCDN > and dCDN-1 in Figure 1. When dCDN-1 acts as a downstream CDN for > uCDN and performs content delivery on behalf of uCDN, dCDN-1 will > include the CDNI Logging Records corresponding to the content > deliveries performed on behalf of uCDN in the CDNI Logging Files for > uCDN. An example CDNI Logging File communicated by dCDN-1 to uCDN = is > shown below in Figure 4. >=20 > #Version:CDNI/1.0 >=20 > #UUID:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 >=20 > #Claimed-Origin:cdni-logging-entity.dcdn-1.example.com >=20 > #Record-Type:cdni_http_request_v1 >=20 > #Fields:datetimetime-takenc-ip > cs-methodu-uriprotocolsc-status > sc-total-bytescs(User-Agent)cs(Referer) > s-cached >=20 > 2013-05-1700:38:06.8259.05810.5.7.1GET > http://cdni-ucdn.dcdn-1.example.com/video/movie100.mp4 > HTTP/1.12006729891"Mozilla/5.0 > (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like > Gecko) Chrome/5.0.375.127 Safari/533.4" > "host1.example.com"1 >=20 > 2013-05-1700:39:09.14515.3210.5.10.5GET > http://cdni-ucdn.dcdn-1.example.com/video/movie118.mp4 > HTTP/1.120015799210"Mozilla/5.0 > (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like > Gecko) Chrome/5.0.375.127 Safari/533.4" > "host1.example.com"1 >=20 > = 2013-05-1700:42:53.43752.87910.5.10.5GET > http://cdni-ucdn.dcdn-1.example.com/video/picture11.mp4 > HTTP/1.020097234724"Mozilla/5.0 > (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like > Gecko) Chrome/5.0.375.127 Safari/533.4" > "host5.example.com"0 >=20 > #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >=20 > [Editor's Note: compute the correct Integrity-Hash value once example > is frozen] >=20 >=20 > Figure 4: CDNI Logging File Example >=20 > If uCDN establishes by some means (e.g. via TLS authentication when > pulling the CDNI Logging File) the identity of the entity from which > it pulled the CDNI Logging File, uCDN can add to the CDNI Logging a > Verified-Origin directive as illustrated below: >=20 > #Verified-Origin:cdni-logging-entity.dcdn-1.example.com >=20 > As illustrated in Figure 2, uCDN will then ingest the corresponding > CDNI Logging Records into its Collection process, alongside the > Logging Records generated locally by the uCDN itself. This allows > uCDN to aggregate Logging Records for deliveries performed by itself > (through Records generated locally) as well as for deliveries > performed by its downstream CDN(s). This aggregate information can > then be used (after Filtering and Rectification, as illustrated in > Figure 2) by Log Consuming Applications that take into account > deliveries performed by uCDN as well as by all of its downstream > CDNs. >=20 > We observe that the time between >=20 > 1. when a delivery is completed in dCDN and >=20 > 2. when the corresponding Logging Record is ingested by the > Collection process in uCDN >=20 > depends on a number of parameters such as the Logging Period agreed > to by uCDN and dCDN, how much time uCDN waits before pulling the = CDNI > Logging File once it is advertised in the CDNI Logging Feed, and the > time to complete the pull of the CDNI Logging File. Therefore, if = we > consider the set of Logging Records aggregated by the Collection > process in uCDN in a given time interval, there could be a permanent > significant timing difference between the CDNI Logging Records > received from the dCDN and the Logging Records generated locally. > For example, in a given time interval, the Collection process in = uCDN > may be aggregating Logging Records generated locally by uCDN for > deliveries performed in the last hour and CDNI Logging Records > generated in the dCDN for deliveries in the hour before last. >=20 > 3.6. Cascaded CDNI Logging Files Example >=20 > Let us consider the cascaded CDN scenario of uCDN, dCDN-2 and dCDN-3 > as depicted in Figure 1. After completion of a delivery by dCDN-3 = on > behalf of dCDN-2, dCDN-3 will include a corresponding Logging Record > in a CDNI Logging File that will be pulled by dCDN-2 and that is > illustrated below in Figure 5. In practice, a CDNI Logging File is > likely to contain a very high number of CDNI Logging Records. > However, for readability, the example in Figure 5 contains a single > CDNI Logging Record. >=20 >=20 > #Version:CDNI/1.0 >=20 > #UUID:urn:uuid:65718ef-0123-9876-adce4321bcde >=20 > #Claimed-Origin:cdni-logging-entity.dcdn-3.example.com >=20 > #Record-Type:cdni_http_request_v1 >=20 > #Fields:datetimetime-takenc-ip > cs-methodu-uriprotocolsc-status > sc-total-bytescs(User-Agent)cs(Referer) > s-cached >=20 > = 2013-05-1700:39:09.11914.0710.5.10.9GET > http://cdni-dcdn-2.dcdn-3.example.com/video/movie118.mp4 > HTTP/1.120015799210"Mozilla/5.0 > (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like > Gecko) Chrome/5.0.375.127 Safari /533.4" > "host1.example.com"1 >=20 > #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >=20 > [Editor's Note: compute the correct Integrity-Hash value once = example > is frozen] >=20 > Figure 5: Cascaded CDNI Logging File Example (dCDN-3 to dCDN-2) >=20 > If dCDN-2 establishes by some means (e.g. via TLS authentication = when > pulling the CDNI Logging File) the identity of the entity from which > it pulled the CDNI Logging File, dCDN-2 can add to the CDNI Logging = a > Verified-Origin directive as illustrated below: >=20 > #Verified-Origin:cdni-logging-entity.dcdn-3.example.com >=20 > dCDN-2 (behaving as an upstream CDN from the viewpoint of dCDN-3) > will then ingest the CDNI Logging Record for the considered dCDN-3 > delivery into its Collection process (as illustrated in Figure 2). > This Logging Record may be aggregated with Logging Records generated > locally by dCDN-2 for deliveries performed by dCDN-2 itself. Say, > for illustration, that the content delivery performed by dCDN-3 on > behalf of dCDN-2 had actually been redirected to dCDN-2 by uCDN, and > say that another content delivery has just been redirected by uCDN = to > dCDN-2 and that dCDN-2 elected to perform the corresponding delivery > itself. Then after Filtering and Rectification (as illustrated in > Figure 2), dCDN-2 will include the two Logging Records corresponding > respectively to the delivery performed by dCDN-3 and the delivery > performed by dCDN-2, in the next CDNI Logging File that will be > communicated to uCDN. An example of such CDNI Logging File is > illustrated below in Figure 6. >=20 > #Version:CDNI/1.0 >=20 > #UUID:urn:uuid:1234567-8fedc-abab-0987654321ff >=20 > #Claimed-Origin:cdni-logging-entity.dcdn-2.example.com >=20 > #Record-Type:cdni_http_request_v1 >=20 > #Fields:datetimetime-takenc-ip > cs-methodu-uriprotocolsc-status > sc-total-bytescs(User-Agent)cs(Referer) > s-cached >=20 > 2013-05-1700:39:09.11914.0710.5.10.9GET > http://cdni-ucdn.dcdn-2.example.com/video/movie118.mp4 > HTTP/1.120015799210"Mozilla/5.0 > (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like > Gecko) Chrome/5.0.375.127 Safari /533.4" > "host1.example.com"1 >=20 > = 2013-05-1701:42:53.43752.87910.5.10.12GET > http://cdni-ucdn.dcdn-2.example.com/video/picture11.mp4 > HTTP/1.020097234724"Mozilla/5.0 > (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like > Gecko) Chrome/5.0.375.127 Safari /533.4" > "host5.example.com"0 >=20 > #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >=20 > [Editor's Note: compute the correct Integrity-Hash value once example > is frozen] >=20 > Figure 6: Cascaded CDNI Logging File Example (dCDN-2 to uCDN) >=20 > If uCDN establishes by some means (e.g. via TLS authentication when > pulling the CDNI Logging File) the identity of the entity from which > it pulled the CDNI Logging File, uCDN can add to the CDNI Logging a > Verified-Origin directive as illustrated below: >=20 > #Verified-Origin:cdni-logging-entity.dcdn-2.example.com >=20 > In the example of Figure 6, we observe that: >=20 > o the first Logging Record corresponds to the Logging Record > communicated earlier to dCDN-2 by dCDN-3, which corresponds to a > delivery redirected by uCDN to dCDN-2 and then redirected by > dCDN-2 to dCDN-3. Its initial fields values are preserved, with > the exception of the u-uri that now reflects the URI convention > between uCDN and dCDN-2, and which presents the delivery to uCDN > as if it was performed by dCDN-2 itself, which reflects the fact > that dCDN-2 had taken the full responsibility of the = corresponding > delivery (even if in this case, dCDN-2 elected to redirect the > delivery to dCDN-3 so it is actually performed by dCDN-3 on = behalf > of dCDN-2). >=20 > o the second Logging Record corresponds to a delivery redirected by > uCDN to dCDN-2 and performed by dCDN-2 itself. The time of the > delivery in this Logging Record may be significantly more recent > than the first Logging Record since it was generated locally = while > the first Logging Record was generated by dCDN-3 and had to be > advertised , and then pulled and then ingested into the dCDN-2 > Collection process, before being aggregated with the second > Logging Record. >=20 >=20 >=20 > Cheers >=20 > Francois >=20 >=20 >=20 >>=20 >> Thanks >>=20 >> Francois >>=20 >> " >>=20 >> 3.5. CDNI Logging File Example >>=20 >> Let us consider the upstream CDN and the downstream CDN labelled = uCDN >> and dCDN-1 in Figure 1. When dCDN-1 acts as a downstream CDN for >> uCDN and performs content delivery on behalf of uCDN, dCDN-1 will >> include the CDNI Logging Records corresponding to the content >> deliveries performed on behalf of uCDN in the CDNI Logging Files for >> uCDN. An example CDNI Logging File communicated by dCDN-1 to uCDN = is >> show below: >>=20 >> " >>=20 >> #Version:CDNI/1.0 >>=20 >> #UUID:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 >>=20 >> #Claimed-Origin:cdni-logging-entity.dcdn-1.example.com >>=20 >> #Record-Type:cdni_http_request_v1 >>=20 >> #Fields:datetimetime-takenc-ipcs- >> methodu-uriprotocolsc-statussc-total- >> bytescs(User-Agent)cs(Referer)s-cached >>=20 >> = 2013-05-1700:38:06.8259.05810.5.7.1GETh >> ttp://cdni-ucdn.dcdn-1.example.com/video/ >> movie100.mp4HTTP/1.12006729891"Mozilla/5.0 >> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >> Gecko) Chrome/5.0.375.127 Safari >> /533.4""host1.example.com"1 >>=20 >> = 2013-05-1700:39:09.14515.3210.5.10.5GET >> http://cdni-ucdn.dcdn-1.example.com/video/ >> movie118.mp4HTTP/1.120015799210"Mozilla/5.0 >> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >> Gecko) Chrome/5.0.375.127 Safari >> /533.4""host1.example.com"1 >>=20 >> = 2013-05-1700:42:53.43752.87910.5.10.5GET>> http://cdni-ucdn.dcdn-1.example.com/video/ >> picture11.mp4HTTP/1.020097234724"Mozilla/5.0 >> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >> Gecko) Chrome/5.0.375.127 Safari >> /533.4""host5.example.com"0 >>=20 >> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >>=20 >> [Editor's Note: compute the correct Integrity-Hash value once = example >> is frozen] >>=20 >> " >>=20 >> As illustrated in Figure 2, uCDN will then ingest the corresponding >> CDNI Logging Records into its Collection process, alongside the >> Logging Records generated locally by the uCDN itself. This allows >> uCDN to aggregate Logging Records for deliveries performed by itself >> (through Records generated locally) as well as for deliveries >> performed by its downstream CDN(s). This aggregate information can >> then be used (after Filtering and Rectification, as illustrated in >> Figure 2) by Log Consuming Applications considering deliveries >> performed by uCDN as well as by all its downstream CDN(s). >>=20 >> We observe that the time between >>=20 >> 1. when a delivery is completed in dCDN and >>=20 >> 2. when the corresponding Logging Record is ingested by the >> Collection process in uCDN >>=20 >> depends on a number of parameters such as the Logging Period agreed >> to by uCDN and dCDN, how much time uCDN waits after it is advertised >> in the CDNI Logging Feed before pulling the CDNI Logging File, and >> the time to complete the pull of the CDNI Logging File. Therefore, >> if we consider the set of Logging Records aggregated by the >> Collection process in uCDN in a given time interval, there could be = a >> permanent significant timing difference between the CDNI Logging >> Records received from the dCDN and the Logging Records generated >> locally. For example, in a given time interval, the Collection >> process in uCDN may be aggregating Logging Records generated locally >> by uCDN for deliveries performed in the last hour and CDNI Logging >> Records generated in the dCDN for deliveries in the hour before = last. >>=20 >> 3.6. Cascaded CDNI Logging Files Example >>=20 >> Let us consider the cascaded CDN scenario of uCDN, dCDN-2 and dCDN-3 >> as depicted in Figure 1. After completion of a delivery by dCDN-3 = on >> behalf of dCDN-2, dCDN-3 will include a corresponding Logging Record >> in a CDNI Logging File and will advertise this CDNI Logging File to >> d-CDN2 in the corresponding CDNI Logging feed. As a result, dCDN-2 >> will initiate and complete the pull of the corresponding CDNI = Logging >> File that is illustrated below: >>=20 >> " >>=20 >> #Version:CDNI/1.0 >>=20 >> #UUID:urn:uuid:65718ef-0123-9876-adce4321bcde >>=20 >> #Claimed-Origin:cdni-logging-entity.dcdn-3.example.com >>=20 >> #Record-Type:cdni_http_request_v1 >>=20 >> #Fields:datetimetime-takenc-ipcs- >> methodu-uriprotocolsc-statussc-total- >> bytescs(User-Agent)cs(Referer)s-cached >>=20 >> = 2013-05-1700:39:09.14515.3210.5.10.5GET >> http://cdni-dcdn-2.dcdn-3.example.com/video/movie118.mp4HTTP/ >> 1.120015799210"Mozilla/5.0 (Windows; U; Windows NT >> 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 >> Safari /533.4""host1.example.com"1 >>=20 >> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >>=20 >> [Editor's Note: compute the correct Integrity-Hash value once = example >> is frozen] >>=20 >> " >>=20 >> dCDN-2 (behaving as an upstream CDN from the viewpoint of dCDN-3) >> will then ingest the CDNI Logging Record for the considered dCDN-3 >> delivery into its Collection process (as illustrated in Figure 2). >> This Logging Record may be aggregated with Logging Records generated >> locally by dCDN-2 for deliveries performed by dCDN-2 itself. Say, >> for illustration, that the content delivery performed by dCDN-3 on >> behalf of dCDN-2 had actually been redirected to dCDN-2 by uCDN, and >> say that another content delivery has just been redirected by uCDN = to >> dCDN-2 and that dCDN-2 elected to perform the corresponding delivery >> itself. Then after Filtering and Rectification (as illustrated in >> Figure 2), dCDN-2 will include the two Logging Records corresponding >> respectively to the delivery performed by dCDN-3 and the delivery >> performed by dCDN-2, in the next CDNI Logging File that will be >> communcated to uCDN. An example of such CDNI Logging File is >> illustrated below: >>=20 >> #Version:CDNI/1.0 >>=20 >> #UUID:urn:uuid:1234567-8fedc-abab-0987654321ff >>=20 >> #Claimed-Origin:cdni-logging-entity.dcdn-2.example.com >>=20 >> #Record-Type:cdni_http_request_v1 >>=20 >> #Fields:datetimetime-takenc-ipcs- >> methodu-uriprotocolsc-statussc-total- >> bytescs(User-Agent)cs(Referer)s-cached >>=20 >> = 2013-05-1700:39:09.14515.3210.5.10.5GET >> http://cdni-ucdn.dcdn-2.example.com/video/movie118.mp4HTTP/ >> 1.120015799210"Mozilla/5.0 (Windows; U; Windows NT >> 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 >> Safari /533.4""host1.example.com"1 >>=20 >> = 2013-05-1701:42:53.43752.87910.5.10.5GET>> http://cdni-ucdn.dcdn-2.example.com/video/picture11.mp4HTTP/ >> 1.020097234724"Mozilla/5.0 (Windows; U; Windows NT >> 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 >> Safari /533.4""host5.example.com"0 >>=20 >> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >>=20 >> [Editor's Note: compute the correct Integrity-Hash value once = example >> is frozen] >>=20 >> " >>=20 >> In the example above, we observe that: >>=20 >> o the first Logging Record corresponds to the Logging Record >> communicated earlier to dCDN-2 by dCDN-3, which corresponds to a >> delivery redirected by uCDN to dCDN-2 and then redirected by >> dCDN-2 to dCDN-3. Its initial fields values are preserved, with >> the exception of the u-uri that now reflects the URI convention >> between uCDN and dCDN-2, and which presents the delivery to uCDN >> as if it was performed by dCDN-2 itself, which reflects the fact >> that dCDN-2 had taken the full responsibility of the = corresponding >> delivery (even if in this case, dCDN-2 elected to redirect the >> delivery to dCDN-3 so it is actually performed by dCDN-3 on = behalf >> of dCDN-2). >>=20 >> o the second Logging Record corresponds to a delivery redirected by >> uCDN to dCDN-2 and performed by dCDN-2 itself. The time of the >> delivery in this Logging Record may be significantly more recent >> than the first Logging Record since it was generated locally = while >> the first Logging Record was generated by dCDN-3 and had to be >> advertised , and then pulled and then ingested into the dCDN-2 >> Collection process, before being aggregated with the second >> Logging Record. >>=20 >> " >>=20 >>=20 >> On 23 Apr 2014, at 20:29, Francois Le Faucheur (flefauch) = wrote: >>=20 >>> Hello, >>>=20 >>> On 18 Apr 2014, at 23:42, ietfdbh wrote: >>>>>=20 >>>>> On 5 Apr 2014, at 23:14, ietfdbh wrote: >>>>>>=20 >>>>>>=20 >>>>>> Most notably, the logging from a dCDN to a uCDN typically = contains only >>>>> one >>>>>> dCDN identifier, such as Verified-origin, and doesn't really = permit >>>>>> specifying a sub-ordinate dCDN. For example, in a cascade such as = CDN-A >>>> - >>>>>>=20 >>>>>> CDN-B -> CDN-C, CDN-C will share logging info with CDN-B, but not = with >>>>>> CDN-A; CDN-B shares logging info with CDN-A. This can be = desirable for >>>>>> hiding the topology and delegation used by the dCDN. However, = this >>>>> document >>>>>> does not discuss how the logging provided by CDN-C gets converted = into >>>>> the >>>>>> logs for CDN-B that will be sent to CDN-A. Without some logging >>>>> information >>>>>> from CDN-C, it would seem difficult for CDN-A to utilize the = information >>>> to >>>>>> meet requirements of billing, analytics, and fault and = performance >>>> analysis. >>>>>> Maybe the logging gets aggregated and reported in CDN-B's = logging, >>>>>=20 >>>>> Exactly. >>>>>=20 >>>>>> but that >>>>>> "transitive or aggregate logging" doesn't appear to be discussed = in this >>>>>> document. >>>>>=20 >>>>> It is discussed in section 2.1 through Figure 1 and the following = text: >>>>> " >>>>> A dCDN (e.g., dCDN-2) integrates the relevant Logging information >>>>> obtained from its dCDNs (i.e., dCDN-3) in the Logging information >>>>> that it provides to the uCDN, so that the uCDN ultimately obtains = all >>>>> Logging information relevant to a CSP for which it acts as the >>>>> authoritative CDN. >>>>> " >>>>> Does that address your concern? >>>>=20 >>>> No it does not mitigate my concern. >>>>=20 >>>> This says the information gets "integrated", but doesn't describe = what >>>> integrated means. >>>> I could interpret that integration would be that the logging from = CDN-C >>>> would be included in the logs from CDN-B to CDN-A, >>>> But I think the text says CDN-B will not share the logging entries = from >>>> CDN-C with CDN-A. >>>> Do I have this wrong? Does CDN-B create a log file and generate = entries, >>>> and then when it delegates delivery to CDN-C, and CDN-C passes its = log file >>>> back to CDN-B, does CDN-B take the whole log file from CDN-B and = insert it >>>> into its own log file, then continue adding any more entries, and = then when >>>> done send the CDN-B log file (including a fully inserted CDN-C log = file) to >>>> CDN-A? >>>>=20 >>>> If not, that presumably means that somehow, the data from CDN-C is >>>> "aggregated" - that's how it is "integrated=94, >>>=20 >>> Right. It is aggregated. >>> Effectively, if CDN-B has sub-delegated a delivery to CDN-C, then = when CDN-C provides a log record for that delivery to CDN-B, CDN-B will = aggregate that log record with the log records for the deliveries that = CDN-B conduted itself. When CDN-B provides log records to CDN-A, the log = record corresponding to the delivery performed by CDN-C is turned by = CDN-B into a log record that looks like the delivery was done by CDN-B. = CDN-A will not be aware that the delivery was performed by another CDN = than CDN-B (just like the Content Provider is not ware that the delivery = was not performed by CDN-A with whom it has a delivery contract). >>>=20 >>>> But there is no discussion of how this aggregation is done. >>>=20 >>> That is true. I think it has been assumed by many but never made = clear. So we need to add some discussion about that. >>>=20 >>>> I think your intent is to hide the fact that CDN-B used CDN-C, = since that >>>> may reflect a proprietary approach of CDN-B's business model. >>>=20 >>> Right. >>>=20 >>>> But CDN-A would presumably have problems performing analytics, and = fault and >>>> performance analysis, if the data from CDN-C is not included in = CDN-B's >>>> logging to CDN-A.=20 >>>> So I would like an example to demonstrate what CDN-A would see in = CDN-B's >>>> logs if CDN-C had faults or performance problems, and I would like = to see >>>> how CDN-A could perform analytics (of any kind) relating to the = delivery >>>> performed by CDN-C. >>>=20 >>> The assumption is that CDN-A is only dealing with CDN-B. CDN-A may = not not even be aware of CDN-C.=20 >>> So CDN-A analaytics/monitoring will establish whether all the = deliveries delegated to CDN-B (comprising deliveries performed by CDN-B = as well as deliveries redirected by CDN-B to CDN-C and possibly CDN-C2) = have received the right quality (ie if CDN-B has met the SLA committed = to CDN-A). >>> If some deliveries have experienced quality problems, CDN-A will = blame CDN-B. It is up to CDN-B to then do its own analytics and = monitoring to decide whether the problem lies within his own CDN or = CDN-C or CDN-C2.=20 >>> The whole thing operates as a chain of delegations, like many other = business arrangements: if my SmartPhone does not work, I blame the = smartPhone vendor (I don=92t try identify if the problem is coming from = the supplier of the GSM chipset, but the SmartPhone vendor will). >>>=20 >>>=20 >>>=20 >>>> I am missing how this would be done (especially in a standardized = manner). >>>>=20 >>>>>=20 >>>>>>=20 >>>>>> I think Verified-Origin is particularly problematic, because the = text >>>> states >>>>>> that this can only be added by the uCDN, never the dCDN. So what = if >>>> CDN-B >>>>>> verifies the origin of the logs from CDN-C and then passes the >>>> information >>>>>> (now as a dCDN) to CDN-A? The text mentions that this might be >>>>> established >>>>>> using authentication mechanisms; so do we lose this logged >>>>>> authentication/verification when cascading? >>>>>>=20 >>>>>> (Maybe this is resolved by having the uCDN (CDN-B) record a >>>> "transaction" >>>>>> that starts when it delegates a task to a dCDN (e.g. CDN-C) and = ends >>>> when >>>>>> the dCDN completes the task, and the uCDN just records the whole >>>>> transaction >>>>>> without the details that are reported by CDN-C. Then CDN-B logs = only the >>>>>> whole transaction. I would like to see an explicit example of = such >>>> logging, >>>>>> using the cdni_http_request_v1 record-type, so this is clear.) >>>>>=20 >>>>> Yes, that is pretty much the idea. >>>>> ie. if CDN-a delegate sto CDN-B then CDB-B is responsible for = delivering >>>> and >>>>> will provide a delivery record to CDN-A for that delivery. That = record >>>> will be >>>>> part of a Logging File whose origin in CDN-B, and CDN-A can use >>>>> authentication mechanism to ensure the Logging File is provided by = CDN-B. >>>>> All of this completely holds whether CDN-B performed the delivery = itself >>>>> (and created the delivery record in the first place) or CDN-B = delegated to >>>>> CDN-C who provided the delivery record to CDN-B in a Logging File = whose >>>>> origin was CDN-C. >>>>>=20 >>>>> This question has come up before so I will add a clarification = along the >>>> lines >>>>> above under the description of the Verified Origin in case of = cascaded >>>> CDNs. >>>>=20 >>>> An example of such integrated cascaded logging might answer many = questions. >>>=20 >>> Good idea.=20 >>> It sounds worthwhile to give a descripton of how log records get = aggregated in a csacaded scenario, indicate how directives/fields get = modified/kept at each CDN hop, and possibly include an example with some = log records and how they propagate from CDN-C to CDN-B to CDN-A. >>>=20 >>>> If logging records from CDN-C get copied into the log from CDN-B, = are all >>>> directives and record types copied? >>>> If so, I think it is important to make clear that a given log might = contain >>>> multiple nested logs, >>>> And that means that the file received by CDN-A might start with = directives >>>> for CDN-B plus records,=20 >>>> And then directives for CDN-C, ending with an Integrity-Hash, and = more >>>> records for CDN-B followed by an Integrity-Hash. >>>> Maybe this is all as designed, but I haven't seen discussion of = that, and it >>>> is not reflected in Figure 3, and this is not discussed in the = description >>>> of fields that are file-specific, such as Integrity-hash, = Verfiied-origin, >>>> Version, UUID, etc. >>>> If you have nested logs, then log-consuming applications need to = know that >>>> those file-specific directives un-nest at the end of the included = file. Can >>>> they tell consistently when they hit the end of the included file? >>>> Should there be an end-of-log marker for the included log?=20 >>>>=20 >>>> The Integrity-Hash directive is allowed to occur zero or once, not = multiple >>>> times in a logfile. >>>> So if the CDN-C logfile contains an Integrity-Hash, should that be = checked >>>> by CDN-B, then copy the CDN-C logfile into the CDN-B logfile, but = discard >>>> the CDN-C Integrity-Hash, because CDN-B will calculate its own >>>> Integrity-Hash directive? >>>=20 >>> Yes. >>>=20 >>>>=20 >>>>> Let me know if that is not sufficient. >>>>=20 >>>> I remain concerned that cascaded logging may not have been = adequately >>>> described and standardized. >>>=20 >>> Right. I see that the questions you raised were not answered in the = document. We will work on addressing them. >>>=20 >>> Thanks >>>=20 >>> Francois >>>=20 >>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Francois >>>>=20 >>>> dbh >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> 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 From nobody Thu Jul 3 10:42:18 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B30D91B2B2E; Thu, 3 Jul 2014 10:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7crdjg5TjTB; Thu, 3 Jul 2014 10:42:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C36C1B29D6; Thu, 3 Jul 2014 10:42:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140703174211.12529.27615.idtracker@ietfa.amsl.com> Date: Thu, 03 Jul 2014 10:42:11 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/7d--R7BTK_ZMUorV2YK1Dn-epnQ Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-metadata-07.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 17:42:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Content Delivery Networks Interconnection Working Group of the IETF. Title : CDN Interconnection Metadata Authors : Ben Niven-Jenkins Rob Murray Matt Caulfield Kent Leung Kevin J. Ma Filename : draft-ietf-cdni-metadata-07.txt Pages : 47 Date : 2014-07-03 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 a base set of CDNI metadata and the protocol for exchanging that metadata. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-metadata/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-metadata-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-metadata-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 nobody Thu Jul 3 11:05:06 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD22B1B2870; Thu, 3 Jul 2014 11:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkEwr5vEAYMS; Thu, 3 Jul 2014 11:05:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 923B71B2983; Thu, 3 Jul 2014 11:05:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140703180501.25282.53847.idtracker@ietfa.amsl.com> Date: Thu, 03 Jul 2014 11:05:01 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/oQnlP9cuZZTty9beuckvdJgsI9U Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-control-triggers-03.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 18:05:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Content Delivery Networks Interconnection Working Group of the IETF. Title : CDNI Control Interface / Triggers Authors : Rob Murray Ben Niven-Jenkins Filename : draft-ietf-cdni-control-triggers-03.txt Pages : 38 Date : 2014-07-03 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-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-control-triggers-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 3 11:38:29 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2CFC1B2B10 for ; Thu, 3 Jul 2014 11:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVTh8umuCe2r for ; Thu, 3 Jul 2014 11:38:25 -0700 (PDT) Received: from owa.velocix.com (mail-out1.velocix.com [81.134.152.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12D421B2AF2 for ; Thu, 3 Jul 2014 11:38:25 -0700 (PDT) Received: from EXB01-MLT.corp.velocix.com ([169.254.2.235]) by EXC00CAM.corp.velocix.com ([172.18.4.40]) with mapi id 14.02.0347.000; Thu, 3 Jul 2014 19:38:22 +0100 From: Rob Murray To: Kevin Ma J Thread-Topic: [CDNi] Review of draft-ietf-cdni-control-triggers-02 Thread-Index: Ac9peI0LAh6Z9mxCSYyIvRUaFcFOXQtbQgKA Date: Thu, 3 Jul 2014 18:38:21 +0000 Message-ID: <49C77373835C5A479BC2A84B2A1D66BDDA2D41E3@EXB01-MLT.corp.velocix.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.224.122.205] Content-Type: text/plain; charset="us-ascii" Content-ID: <3F9876E57F7A89449D76C69F1CC00EB3@velocix.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/hDqoPqen0lVgawrN0n-QuQSt70o Cc: "cdni@ietf.org" Subject: Re: [CDNi] Review of draft-ietf-cdni-control-triggers-02 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 18:38:28 -0000 Hi all, Kevin, thank you for the review. All very good comments, sorry it took me s= o long to get to them. Responses inline below, and I've posted an "03" version of the draft... http://datatracker.ietf.org/doc/draft-ietf-cdni-control-triggers/ http://tools.ietf.org/html/draft-ietf-cdni-control-triggers-03 (eventual= ly) Most comments have been addressed, including a couple of earlier ones from = Francois about broken formatting. What I've not dealt with is the idea to separate trigger deletion and cance= llation - in order to make it possible to check the status of a deleted tri= gger. It'd make the interface a little more complicated, and I'm not sure w= hat status the dCDN could usefully report. (Also, I ran out of time for mak= ing edits!) Let's discuss further in Toronto. Cheers, Rob. On 6 May 2014, at 23:15, Kevin Ma J wrote: > Hi All, >=20 > Per the chairs' request for a detailed review of the triggers draft, > I've compiled a list of comments below. >=20 > thanx. >=20 > -- Kevin J. Ma >=20 > comments: >=20 > - General: imo, an article in front of uCDN/dCDN (i.e., the uCDN/dCDN) > makes for easier reading. Done. > - General: There are quite a few lower case "must"s (17), "shall"s (14), > "should"s (7), and "may"s (36) in the document. Are they all > intentionally non-normative?=20 Hopefully sorted now, though I MAY have gone too far! > - section 2: Should cancelling a trigger and removing a trigger status > be separated in some way? Using DELETE for both means > that if I wanted to cancel a trigger, I would have no way > to get status on the cancelled trigger, since the status > resource would be removed at the same time, and delete > does not return a status, per the example in section 7.2.5 See above, it could be a good idea but it'd be good to talk it through a bi= t further (sorry I left this update too late to do it on the list before th= e deadline). > - section 2/4.1: In step 2 of figure 1, it mentions authentication as > does section 4.1, but section 7 and 9 provide no > guidance on either the authentication mechanism or > what precisely is being authenticated. Presumably we > are authenticating that it is a known uCDN making the > request for metadata/content that is known to be owned > by that uCDN? Should we state that? >=20 > Do we have a suggestion (e.g., SSL client auth, HTTP > basic/digest auth, etc.) for authentication method? I've rewritten the Security Considerations section now (based on what's in = the Logging draft, as agreed in London). > - section 2.1: I found the wording of this sentance a little confusing. >=20 > "If uCDN wishes to invalidate or purge content, then immediately > preposition replacement content at the same URLs, it must ensure the > dCDN has completed the invalidate/purge before initiating the > prepositioning. If it fails to do that and the requests overlap, and > dCDN passes the triggers on to a further dCDN in a cascade, that CDN > may preposition content that has not yet been invalidated/purged in > its uCDN." >=20 > Perhaps something like: >=20 > "If uCDN wishes to invalidate or purge content, then immediately > preposition replacement content at the same URLs, it must ensure the > dCDN and all cascaded dCDNs have completed the invalidate/purge > before initiating the prepositioning, otherwise, a cascaded dCDN may > attempt to preposition content that has not yet been invalidated/purg= ed > in its uCDN." Done. >=20 > - section 3: I would break this into two sentances: >=20 > "The dCDN must present a different set of Trigger Status Resources to > each interconnected uCDN, only Trigger Status Resources belonging to > a uCDN shall be visible to it." >=20 > i.e.: >=20 > "The dCDN must present a different set of Trigger Status Resources to > each interconnected uCDN. Only Trigger Status Resources belonging to > a uCDN shall be visible to it." Done (and reworded a bit). > - section 3: This is the first mention of expiry. Perhaps a reference > to Section 4.4? >=20 > "This collection lists all > uCDN triggers that have been accepted by dCDN, and have not yet been > deleted by uCDN or expired and removed by dCDN." Done. > - section 4.1: These are the first mention of etime and mtime, perhaps > there should be a reference to Section 5.2, or some > type of explaination on what etime > mtime means. >=20 > I am not sure about using of etime > mtime as an indicator. > If mtime < now and etime < now, but still etime > mtime, > it would seem to imply that the activity may be complete, > but I don't think that is the intent? >=20 > Should there be some normative language stating that if > etime > mtime, the uCDN must update the status, and the > dCDN must update mtime =3D now and etime > mtime? >=20 > "If dCDN is not able to track triggered activity, it MAY indicate that > it has undertaken to complete the activity but will not report > completion or any further errors. To do this, it must set the > trigger status to "complete", with an estimated completion time in > the future ("etime" greater than "mtime")." I got rid of that and added an extra state, "processed" - it's like "comple= te", but means the dCDN can't provide a success/fail result. (With a recomm= endation that an estimated completion time should be provided in that case.= ) > - section 4.4: Why 24 hours? Seems fast? >=20 > "It > is recommended that Trigger Status Resources are automatically > deleted 24 hours after they become completed or failed." I made it "not less than 24 hours". > - section 4.4: comma after: >=20 > "If any part of the trigger request fails, " >=20 > comma before: >=20 > ", if the trigger is still running for some URLs > or Patterns in the trigger request." >=20 > perhaps clarify "cascaded" dCDNs: >=20 > "pass a trigger request on to any of its affected cascaded dCDNs" Done. > - section 5.2: AbsoluteTime is a Unix Epoch, so should be UTC. > I found the phrase "Time is local to dCDN" confusing as > I first assumed "local" was referencing timezone, but I > think "local" is just related to unsynchronized clocks? > Perhaps: "Time is determined by the dCDN"? Done. > - section 5.4: links is a "List of Relationships". Why not just URLs? > If the trigger collection can only reference trigger > statuses, then why does it need typed relationships? > The use of a relationship here seems overly complex? >=20 > Is relationship standard JSON terminology? Should there > be a reference to the acknowledged work of Mike Kelly? Yes, you're right. It had all got too complicated and bloated. So it's just= a list of URLs now, I got rid of all that JSON relationship stuff. > - section 6: There is a note about MI dependency. > Is it just for PatternMatch? It was, but the dependency wasn't necessary so I've got rid of it. > - section 6.1.6: "ralationship" -> "relationship" Fixed. > - section 6.1.6/6.1.7: I think it would be helpful to define the > Relationship and Link objects the same way as > all the other JSON objects, e.g.: >=20 > How are the keys in the _links dictionary > determined? And how is their meaning known? > The key "self" seems to have a specific meaning? > It is essentially a reserved keyword? Are there > other reserved keywords (e.g., "Trigger"), and > do they have to be registered somewhere? >=20 > Relationship: > Key: _links > Description: List of related objects? > Type: Array of LinkUnions > Mandatory: Yes >=20 > LinkUnion: > Key: ??? > Description: List of related objects? > Type: Array of LinkUnions > Mandatory: No. >=20 > Key: ??? > Description: related objects? > Type: Link > Mandatory: No. >=20 > Link: > Key: href > Description: URI of the addressable object being referenced > Type: URL > Mandatory: Yes >=20 > Key: type > Description: Type of the referenced object > Type: MIME Media Type > Mandatory: No I did that - then decided to get rid of it all, as above. It was only used = in the collections, and they're now just lists of links. > - section 7: There are no examples with "base" or "links". I have an > idea of how "base" might be used, but I don't know what > the purpoes of "links" is. Can we add an example? >=20 > "URLs are under control" -> "URLs are under the control" "links" has gone. > - section 7.2.1/7.2.2: I don't know where the key "Trigger" came from? > Is it derived from some known object, or is it > randomly selected (and somehow registered)? In the "01" draft it was the "relationship type", and I'd not documented th= e change properly. But it's gone now, just a list of URLs. > - section 7.2.5: Would there be value in returning the status on delete? Probably a good idea. Let's wrap it up with discussion on the delete/cancel= question. > - section 9: In the first sentance below, I interpret "access" as the > ability to read (GET) a status object or collection. It > does not necessarily imply to me who can issue a new > trigger request? In the second sentance, it says it can > only "affect" it's own content, which I guess implies > that only it can affect it's own content, as another uCDN > affecting it's content would violate this rule? Should > we make that more explicit? >=20 > "The dCDN must ensure that each uCDN only has access to its own > Trigger Status Resources." >=20 > "The dCDN must ensure that activity triggered by uCDN only affects > metadata or content originating from that uCDN." >=20 > e.g., update the second sentance to something like: >=20 > "The dCDN must ensure that activity triggered by uCDN only affects > metadata or content originating from that uCDN, and that no other > uCDN may trigger activity that affects another uCDN's metadata or > content." Hopefully the re-written section 9 is clearer. > - random: The mention of only affecting a uCDN's own content made me > think of the DNS diamond scenario. Do we believe that the > Content URLs described in section 5.1.1 are sufficient to > ensure this, or is there a caveat for the diamond case? >=20 > "The dCDN must ensure that activity triggered by uCDN only affects > metadata or content originating from that uCDN." Done. >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From nobody Fri Jul 4 01:17:56 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CABF41B2C6E for ; Fri, 4 Jul 2014 01:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.152 X-Spam-Level: X-Spam-Status: No, score=-11.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_BACKHAIR_31=1, J_BACKHAIR_37=1, J_BACKHAIR_44=1, J_BACKHAIR_52=1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8ybm34GGs2q for ; Fri, 4 Jul 2014 01:17:42 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 469231B2C74 for ; Fri, 4 Jul 2014 01:17:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35005; q=dns/txt; s=iport; t=1404461859; x=1405671459; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=aiWbQQ+iJJZhRdSjn37MH4m1Qi7826kDY+FNV0yIApo=; b=DPSyguSDQhhXTGLIQcgNNgmFPeeuGKcpdimt7Luq81Xm5Jz1k31Le07c xN+04tZEisO6Jm+GJHjvybbBAbfQ5iiVfEclMf0m3O3g9HjAGuVBgPtU9 rb44x6smEGHHDQVVmj0i/MEoh9c/JWk4KEc8+2qQHlrwwiQOCRNuxk4ME 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEHANZhtlOtJA2N/2dsb2JhbABQAQmDDVJarAqSXYc/AYEMFnWEAwEBAQMBAQEBFwEMRwsFCwIBCBgVGScLFwENAgQOAwKILgMJCA3DIQiGVxeNBYFBASgzBwIIgyOBFgWWFkaEGoFIii6IFoNDQSsBgUM X-IronPort-AV: E=Sophos;i="5.01,599,1400025600"; d="scan'208";a="337816353" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-4.cisco.com with ESMTP; 04 Jul 2014 08:17:37 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s648HbtX018233 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Jul 2014 08:17:37 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Fri, 4 Jul 2014 03:17:36 -0500 From: "Francois Le Faucheur (flefauch)" To: Niven-Jenkins Ben Thread-Topic: Utility of Verified-Origin & Claimed-Origin in CDNI logging Thread-Index: AQHPluW8wWdZ2VEK5ESkrvRbs+8LfJuP5tkA Date: Fri, 4 Jul 2014 08:17:35 +0000 Message-ID: References: <038401cf5b4f$0b5ea610$221bf230$@comcast.net> <05BD7B6B-6886-4277-8A8A-8AE77363939B@cisco.com> <315A2A4B-C876-4FF7-A836-7D48AC191195@cisco.com> 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.200] Content-Type: text/plain; charset="Windows-1252" Content-ID: <69F3E787C1B10747A75BCF386E9CC3D8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/Q465nhJb1uM9Ss1FWwur3gWz28U Cc: "cdni@ietf.org" Subject: Re: [CDNi] Utility of Verified-Origin & Claimed-Origin in CDNI logging X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 08:17:49 -0000 Hi Ben, On 3 Jul 2014, at 19:39, Ben Niven-Jenkins wrote: > Francois, Colleagues, >=20 > Reading your suggested text below made me ponder on the purpose and utili= ty of the Claimed-Origin and Verified-Origin field directives. >=20 > Let=92s start with Verified-Origin. From your text below and reading the = definition of Verified-Origin in section 3.3 of draft-ietf-cdni-logging-11 = I understand that a dCDN MUST NOT place a Verified-Origin field directive i= n a log file it sends to a uCDN (it is the uCDN=92s job to do that if it wa= nts to once it has verified the origin). Furthermore in a cascaded scenario= (uCDN-tCDN-dCDN) the transit CDN MUST NOT include a Verified-Origin field = directive in a log file it sends to uCDN and by implication if tCDN inserte= d a Verified-Origin directive when receiving from dCDN, it must strip it be= fore sending that log file on to uCDN. Yes. >=20 > Therefore use of Verified-Origin is purely internal to a given CDN, is ne= ver exchanged between CDNs and has no role to play in interoperation of CDN= I between CDNs, so why does the logging draft need to specify it at all? That=92s a good question. I think the train of thought that got us there is the following : * when storing the CDNI Logging File, the uCDN would want to have an easy = way to identify where the CDNI Logging File is coming from * since the dCDN knows who he is, it is trivial for it to include its iden= tification in a field inside the file * the uCDN may be happy with that, in which case it does not have to do an= ything; * or the uCDN may want to record the identification it establishes, in whi= ch case it has to add the corresponding field itself. That=92s more or less how we got there. My personal take would be: *A* if we expect that uCDNs would typically want to have an explicit recor= d inside the CDNI Logging File of the dCDN that originated the file , then = we should define directive(s) to do that. This will make things more consis= tent for processing tools/utilities operating over CDNI Logs. And in the ca= se where the uCDN is happy with the origin as stated by dCDN (say because t= he dCDN is operated by the same administrative entity), it will save any fi= le manipulation by the uCDN. *B* if we expect that uCDNs would typically NOT want to have an explicit r= ecord inside the CDNI Logging File of the dCDN that originated the file (sa= y because they want to encode that information inside the filename), then t= here may not be much value in defining the directives. I personally lean towards *A*, but let=92s hear more opnions or arguments.= =20 Cheers Francois > CDNs that want the functionality of Verified-Origin can do whatever they = want internally to implement that, it doesn=92t seem we need something in t= he RFC to support the internal behaviour of a CDN. >=20 >=20 > That then got me thinking about Claimed-Origin. If I read the text below = correctly, my understanding is that the value of Claimed-Origin should be t= he same hostname in the dCDN that the uCDN connects to in order to retrieve= log files. So for example a uCDN could compare the value of Claimed-Origin= against the values of subjectAltName in the TLS certificate presented by t= he dCDN and if there is a match then the Claimed-Origin can be =93verified= =94. >=20 > I=92m struggling to see what value Claimed-Origin gives in practice, poss= ibly because I don=92t understand the use case for it. If the purpose is t= o let a uCDN do the comparison I describe above then I=92m not sure that gi= ves us much in reality. Claimed-Origin becomes essentially a hop-by-hop (CD= N-by-CDN) property and assuming the dCDN identifies itself correctly (e.g. = hostname in dCDN that uCDN connected to matches hostname(s) in TLS certific= ate presented by dCDN) Claimed-Origin is adding nothing, or have I misunder= stood? >=20 > Thanks > Ben >=20 > On 2 Jul 2014, at 15:39, Francois Le Faucheur (flefauch) wrote: >=20 >>=20 >> On 1 Jul 2014, at 20:09, Francois Le Faucheur (flefauch) wrote: >>=20 >>> Folks, >>>=20 >>> (as a document editor) >>>=20 >>> To address the point around cascaded CDNs that was raised by David Harr= ington as part of his early Ops Review, I have: >>> * expanded section 3.5 =93CDNI Logging File Example=94 >>> * added a section 3.6 "Cascaded CDNI Logging Files Example=94 >>>=20 >>> Draft text is below. I=92d appreciate some reviews. >>=20 >> I did a bit more work on teh text. Latest version below. Again will appr= eciate a good review: >>=20 >> 3.5. CDNI Logging File Example >>=20 >> Let us consider the upstream CDN and the downstream CDN labelled uCDN >> and dCDN-1 in Figure 1. When dCDN-1 acts as a downstream CDN for >> uCDN and performs content delivery on behalf of uCDN, dCDN-1 will >> include the CDNI Logging Records corresponding to the content >> deliveries performed on behalf of uCDN in the CDNI Logging Files for >> uCDN. An example CDNI Logging File communicated by dCDN-1 to uCDN is >> shown below in Figure 4. >>=20 >> #Version:CDNI/1.0 >>=20 >> #UUID:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 >>=20 >> #Claimed-Origin:cdni-logging-entity.dcdn-1.example.com >>=20 >> #Record-Type:cdni_http_request_v1 >>=20 >> #Fields:datetimetime-takenc-ip >> cs-methodu-uriprotocolsc-status >> sc-total-bytescs(User-Agent)cs(Referer) >> s-cached >>=20 >> 2013-05-1700:38:06.8259.05810.5.7.1GET >> http://cdni-ucdn.dcdn-1.example.com/video/movie100.mp4 >> HTTP/1.12006729891"Mozilla/5.0 >> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >> Gecko) Chrome/5.0.375.127 Safari/533.4" >> "host1.example.com"1 >>=20 >> 2013-05-1700:39:09.14515.3210.5.10.5GET >> http://cdni-ucdn.dcdn-1.example.com/video/movie118.mp4 >> HTTP/1.120015799210"Mozilla/5.0 >> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >> Gecko) Chrome/5.0.375.127 Safari/533.4" >> "host1.example.com"1 >>=20 >> 2013-05-1700:42:53.43752.87910.5.10.5GET >> http://cdni-ucdn.dcdn-1.example.com/video/picture11.mp4 >> HTTP/1.020097234724"Mozilla/5.0 >> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >> Gecko) Chrome/5.0.375.127 Safari/533.4" >> "host5.example.com"0 >>=20 >> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >>=20 >> [Editor's Note: compute the correct Integrity-Hash value once example >> is frozen] >>=20 >>=20 >> Figure 4: CDNI Logging File Example >>=20 >> If uCDN establishes by some means (e.g. via TLS authentication when >> pulling the CDNI Logging File) the identity of the entity from which >> it pulled the CDNI Logging File, uCDN can add to the CDNI Logging a >> Verified-Origin directive as illustrated below: >>=20 >> #Verified-Origin:cdni-logging-entity.dcdn-1.example.com >>=20 >> As illustrated in Figure 2, uCDN will then ingest the corresponding >> CDNI Logging Records into its Collection process, alongside the >> Logging Records generated locally by the uCDN itself. This allows >> uCDN to aggregate Logging Records for deliveries performed by itself >> (through Records generated locally) as well as for deliveries >> performed by its downstream CDN(s). This aggregate information can >> then be used (after Filtering and Rectification, as illustrated in >> Figure 2) by Log Consuming Applications that take into account >> deliveries performed by uCDN as well as by all of its downstream >> CDNs. >>=20 >> We observe that the time between >>=20 >> 1. when a delivery is completed in dCDN and >>=20 >> 2. when the corresponding Logging Record is ingested by the >> Collection process in uCDN >>=20 >> depends on a number of parameters such as the Logging Period agreed >> to by uCDN and dCDN, how much time uCDN waits before pulling the CDNI >> Logging File once it is advertised in the CDNI Logging Feed, and the >> time to complete the pull of the CDNI Logging File. Therefore, if we >> consider the set of Logging Records aggregated by the Collection >> process in uCDN in a given time interval, there could be a permanent >> significant timing difference between the CDNI Logging Records >> received from the dCDN and the Logging Records generated locally. >> For example, in a given time interval, the Collection process in uCDN >> may be aggregating Logging Records generated locally by uCDN for >> deliveries performed in the last hour and CDNI Logging Records >> generated in the dCDN for deliveries in the hour before last. >>=20 >> 3.6. Cascaded CDNI Logging Files Example >>=20 >> Let us consider the cascaded CDN scenario of uCDN, dCDN-2 and dCDN-3 >> as depicted in Figure 1. After completion of a delivery by dCDN-3 on >> behalf of dCDN-2, dCDN-3 will include a corresponding Logging Record >> in a CDNI Logging File that will be pulled by dCDN-2 and that is >> illustrated below in Figure 5. In practice, a CDNI Logging File is >> likely to contain a very high number of CDNI Logging Records. >> However, for readability, the example in Figure 5 contains a single >> CDNI Logging Record. >>=20 >>=20 >> #Version:CDNI/1.0 >>=20 >> #UUID:urn:uuid:65718ef-0123-9876-adce4321bcde >>=20 >> #Claimed-Origin:cdni-logging-entity.dcdn-3.example.com >>=20 >> #Record-Type:cdni_http_request_v1 >>=20 >> #Fields:datetimetime-takenc-ip >> cs-methodu-uriprotocolsc-status >> sc-total-bytescs(User-Agent)cs(Referer) >> s-cached >>=20 >> 2013-05-1700:39:09.11914.0710.5.10.9GET >> http://cdni-dcdn-2.dcdn-3.example.com/video/movie118.mp4 >> HTTP/1.120015799210"Mozilla/5.0 >> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >> Gecko) Chrome/5.0.375.127 Safari /533.4" >> "host1.example.com"1 >>=20 >> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >>=20 >> [Editor's Note: compute the correct Integrity-Hash value once example >> is frozen] >>=20 >> Figure 5: Cascaded CDNI Logging File Example (dCDN-3 to dCDN-2) >>=20 >> If dCDN-2 establishes by some means (e.g. via TLS authentication when >> pulling the CDNI Logging File) the identity of the entity from which >> it pulled the CDNI Logging File, dCDN-2 can add to the CDNI Logging a >> Verified-Origin directive as illustrated below: >>=20 >> #Verified-Origin:cdni-logging-entity.dcdn-3.example.com >>=20 >> dCDN-2 (behaving as an upstream CDN from the viewpoint of dCDN-3) >> will then ingest the CDNI Logging Record for the considered dCDN-3 >> delivery into its Collection process (as illustrated in Figure 2). >> This Logging Record may be aggregated with Logging Records generated >> locally by dCDN-2 for deliveries performed by dCDN-2 itself. Say, >> for illustration, that the content delivery performed by dCDN-3 on >> behalf of dCDN-2 had actually been redirected to dCDN-2 by uCDN, and >> say that another content delivery has just been redirected by uCDN to >> dCDN-2 and that dCDN-2 elected to perform the corresponding delivery >> itself. Then after Filtering and Rectification (as illustrated in >> Figure 2), dCDN-2 will include the two Logging Records corresponding >> respectively to the delivery performed by dCDN-3 and the delivery >> performed by dCDN-2, in the next CDNI Logging File that will be >> communicated to uCDN. An example of such CDNI Logging File is >> illustrated below in Figure 6. >>=20 >> #Version:CDNI/1.0 >>=20 >> #UUID:urn:uuid:1234567-8fedc-abab-0987654321ff >>=20 >> #Claimed-Origin:cdni-logging-entity.dcdn-2.example.com >>=20 >> #Record-Type:cdni_http_request_v1 >>=20 >> #Fields:datetimetime-takenc-ip >> cs-methodu-uriprotocolsc-status >> sc-total-bytescs(User-Agent)cs(Referer) >> s-cached >>=20 >> 2013-05-1700:39:09.11914.0710.5.10.9GET >> http://cdni-ucdn.dcdn-2.example.com/video/movie118.mp4 >> HTTP/1.120015799210"Mozilla/5.0 >> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >> Gecko) Chrome/5.0.375.127 Safari /533.4" >> "host1.example.com"1 >>=20 >> 2013-05-1701:42:53.43752.87910.5.10.12GET >> http://cdni-ucdn.dcdn-2.example.com/video/picture11.mp4 >> HTTP/1.020097234724"Mozilla/5.0 >> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >> Gecko) Chrome/5.0.375.127 Safari /533.4" >> "host5.example.com"0 >>=20 >> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >>=20 >> [Editor's Note: compute the correct Integrity-Hash value once example >> is frozen] >>=20 >> Figure 6: Cascaded CDNI Logging File Example (dCDN-2 to uCDN) >>=20 >> If uCDN establishes by some means (e.g. via TLS authentication when >> pulling the CDNI Logging File) the identity of the entity from which >> it pulled the CDNI Logging File, uCDN can add to the CDNI Logging a >> Verified-Origin directive as illustrated below: >>=20 >> #Verified-Origin:cdni-logging-entity.dcdn-2.example.com >>=20 >> In the example of Figure 6, we observe that: >>=20 >> o the first Logging Record corresponds to the Logging Record >> communicated earlier to dCDN-2 by dCDN-3, which corresponds to a >> delivery redirected by uCDN to dCDN-2 and then redirected by >> dCDN-2 to dCDN-3. Its initial fields values are preserved, with >> the exception of the u-uri that now reflects the URI convention >> between uCDN and dCDN-2, and which presents the delivery to uCDN >> as if it was performed by dCDN-2 itself, which reflects the fact >> that dCDN-2 had taken the full responsibility of the corresponding >> delivery (even if in this case, dCDN-2 elected to redirect the >> delivery to dCDN-3 so it is actually performed by dCDN-3 on behalf >> of dCDN-2). >>=20 >> o the second Logging Record corresponds to a delivery redirected by >> uCDN to dCDN-2 and performed by dCDN-2 itself. The time of the >> delivery in this Logging Record may be significantly more recent >> than the first Logging Record since it was generated locally while >> the first Logging Record was generated by dCDN-3 and had to be >> advertised , and then pulled and then ingested into the dCDN-2 >> Collection process, before being aggregated with the second >> Logging Record. >>=20 >>=20 >>=20 >> Cheers >>=20 >> Francois >>=20 >>=20 >>=20 >>>=20 >>> Thanks >>>=20 >>> Francois >>>=20 >>> " >>>=20 >>> 3.5. CDNI Logging File Example >>>=20 >>> Let us consider the upstream CDN and the downstream CDN labelled uCDN >>> and dCDN-1 in Figure 1. When dCDN-1 acts as a downstream CDN for >>> uCDN and performs content delivery on behalf of uCDN, dCDN-1 will >>> include the CDNI Logging Records corresponding to the content >>> deliveries performed on behalf of uCDN in the CDNI Logging Files for >>> uCDN. An example CDNI Logging File communicated by dCDN-1 to uCDN is >>> show below: >>>=20 >>> " >>>=20 >>> #Version:CDNI/1.0 >>>=20 >>> #UUID:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 >>>=20 >>> #Claimed-Origin:cdni-logging-entity.dcdn-1.example.com >>>=20 >>> #Record-Type:cdni_http_request_v1 >>>=20 >>> #Fields:datetimetime-takenc-ipcs- >>> methodu-uriprotocolsc-statussc-total- >>> bytescs(User-Agent)cs(Referer)s-cached >>>=20 >>> 2013-05-1700:38:06.8259.05810.5.7.1GETh >>> ttp://cdni-ucdn.dcdn-1.example.com/video/ >>> movie100.mp4HTTP/1.12006729891"Mozilla/5.0 >>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>> Gecko) Chrome/5.0.375.127 Safari >>> /533.4""host1.example.com"1 >>>=20 >>> 2013-05-1700:39:09.14515.3210.5.10.5GET >>> http://cdni-ucdn.dcdn-1.example.com/video/ >>> movie118.mp4HTTP/1.120015799210"Mozilla/5.0 >>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>> Gecko) Chrome/5.0.375.127 Safari >>> /533.4""host1.example.com"1 >>>=20 >>> 2013-05-1700:42:53.43752.87910.5.10.5GET>>> http://cdni-ucdn.dcdn-1.example.com/video/ >>> picture11.mp4HTTP/1.020097234724"Mozilla/5.0 >>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>> Gecko) Chrome/5.0.375.127 Safari >>> /533.4""host5.example.com"0 >>>=20 >>> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >>>=20 >>> [Editor's Note: compute the correct Integrity-Hash value once example >>> is frozen] >>>=20 >>> " >>>=20 >>> As illustrated in Figure 2, uCDN will then ingest the corresponding >>> CDNI Logging Records into its Collection process, alongside the >>> Logging Records generated locally by the uCDN itself. This allows >>> uCDN to aggregate Logging Records for deliveries performed by itself >>> (through Records generated locally) as well as for deliveries >>> performed by its downstream CDN(s). This aggregate information can >>> then be used (after Filtering and Rectification, as illustrated in >>> Figure 2) by Log Consuming Applications considering deliveries >>> performed by uCDN as well as by all its downstream CDN(s). >>>=20 >>> We observe that the time between >>>=20 >>> 1. when a delivery is completed in dCDN and >>>=20 >>> 2. when the corresponding Logging Record is ingested by the >>> Collection process in uCDN >>>=20 >>> depends on a number of parameters such as the Logging Period agreed >>> to by uCDN and dCDN, how much time uCDN waits after it is advertised >>> in the CDNI Logging Feed before pulling the CDNI Logging File, and >>> the time to complete the pull of the CDNI Logging File. Therefore, >>> if we consider the set of Logging Records aggregated by the >>> Collection process in uCDN in a given time interval, there could be a >>> permanent significant timing difference between the CDNI Logging >>> Records received from the dCDN and the Logging Records generated >>> locally. For example, in a given time interval, the Collection >>> process in uCDN may be aggregating Logging Records generated locally >>> by uCDN for deliveries performed in the last hour and CDNI Logging >>> Records generated in the dCDN for deliveries in the hour before last. >>>=20 >>> 3.6. Cascaded CDNI Logging Files Example >>>=20 >>> Let us consider the cascaded CDN scenario of uCDN, dCDN-2 and dCDN-3 >>> as depicted in Figure 1. After completion of a delivery by dCDN-3 on >>> behalf of dCDN-2, dCDN-3 will include a corresponding Logging Record >>> in a CDNI Logging File and will advertise this CDNI Logging File to >>> d-CDN2 in the corresponding CDNI Logging feed. As a result, dCDN-2 >>> will initiate and complete the pull of the corresponding CDNI Logging >>> File that is illustrated below: >>>=20 >>> " >>>=20 >>> #Version:CDNI/1.0 >>>=20 >>> #UUID:urn:uuid:65718ef-0123-9876-adce4321bcde >>>=20 >>> #Claimed-Origin:cdni-logging-entity.dcdn-3.example.com >>>=20 >>> #Record-Type:cdni_http_request_v1 >>>=20 >>> #Fields:datetimetime-takenc-ipcs- >>> methodu-uriprotocolsc-statussc-total- >>> bytescs(User-Agent)cs(Referer)s-cached >>>=20 >>> 2013-05-1700:39:09.14515.3210.5.10.5GET >>> http://cdni-dcdn-2.dcdn-3.example.com/video/movie118.mp4HTTP/ >>> 1.120015799210"Mozilla/5.0 (Windows; U; Windows NT >>> 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 >>> Safari /533.4""host1.example.com"1 >>>=20 >>> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >>>=20 >>> [Editor's Note: compute the correct Integrity-Hash value once example >>> is frozen] >>>=20 >>> " >>>=20 >>> dCDN-2 (behaving as an upstream CDN from the viewpoint of dCDN-3) >>> will then ingest the CDNI Logging Record for the considered dCDN-3 >>> delivery into its Collection process (as illustrated in Figure 2). >>> This Logging Record may be aggregated with Logging Records generated >>> locally by dCDN-2 for deliveries performed by dCDN-2 itself. Say, >>> for illustration, that the content delivery performed by dCDN-3 on >>> behalf of dCDN-2 had actually been redirected to dCDN-2 by uCDN, and >>> say that another content delivery has just been redirected by uCDN to >>> dCDN-2 and that dCDN-2 elected to perform the corresponding delivery >>> itself. Then after Filtering and Rectification (as illustrated in >>> Figure 2), dCDN-2 will include the two Logging Records corresponding >>> respectively to the delivery performed by dCDN-3 and the delivery >>> performed by dCDN-2, in the next CDNI Logging File that will be >>> communcated to uCDN. An example of such CDNI Logging File is >>> illustrated below: >>>=20 >>> #Version:CDNI/1.0 >>>=20 >>> #UUID:urn:uuid:1234567-8fedc-abab-0987654321ff >>>=20 >>> #Claimed-Origin:cdni-logging-entity.dcdn-2.example.com >>>=20 >>> #Record-Type:cdni_http_request_v1 >>>=20 >>> #Fields:datetimetime-takenc-ipcs- >>> methodu-uriprotocolsc-statussc-total- >>> bytescs(User-Agent)cs(Referer)s-cached >>>=20 >>> 2013-05-1700:39:09.14515.3210.5.10.5GET >>> http://cdni-ucdn.dcdn-2.example.com/video/movie118.mp4HTTP/ >>> 1.120015799210"Mozilla/5.0 (Windows; U; Windows NT >>> 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 >>> Safari /533.4""host1.example.com"1 >>>=20 >>> 2013-05-1701:42:53.43752.87910.5.10.5GET>>> http://cdni-ucdn.dcdn-2.example.com/video/picture11.mp4HTTP/ >>> 1.020097234724"Mozilla/5.0 (Windows; U; Windows NT >>> 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 >>> Safari /533.4""host5.example.com"0 >>>=20 >>> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >>>=20 >>> [Editor's Note: compute the correct Integrity-Hash value once example >>> is frozen] >>>=20 >>> " >>>=20 >>> In the example above, we observe that: >>>=20 >>> o the first Logging Record corresponds to the Logging Record >>> communicated earlier to dCDN-2 by dCDN-3, which corresponds to a >>> delivery redirected by uCDN to dCDN-2 and then redirected by >>> dCDN-2 to dCDN-3. Its initial fields values are preserved, with >>> the exception of the u-uri that now reflects the URI convention >>> between uCDN and dCDN-2, and which presents the delivery to uCDN >>> as if it was performed by dCDN-2 itself, which reflects the fact >>> that dCDN-2 had taken the full responsibility of the corresponding >>> delivery (even if in this case, dCDN-2 elected to redirect the >>> delivery to dCDN-3 so it is actually performed by dCDN-3 on behalf >>> of dCDN-2). >>>=20 >>> o the second Logging Record corresponds to a delivery redirected by >>> uCDN to dCDN-2 and performed by dCDN-2 itself. The time of the >>> delivery in this Logging Record may be significantly more recent >>> than the first Logging Record since it was generated locally while >>> the first Logging Record was generated by dCDN-3 and had to be >>> advertised , and then pulled and then ingested into the dCDN-2 >>> Collection process, before being aggregated with the second >>> Logging Record. >>>=20 >>> " >>>=20 >>>=20 >>> On 23 Apr 2014, at 20:29, Francois Le Faucheur (flefauch) wrote: >>>=20 >>>> Hello, >>>>=20 >>>> On 18 Apr 2014, at 23:42, ietfdbh wrote: >>>>>>=20 >>>>>> On 5 Apr 2014, at 23:14, ietfdbh wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>> Most notably, the logging from a dCDN to a uCDN typically contains = only >>>>>> one >>>>>>> dCDN identifier, such as Verified-origin, and doesn't really permit >>>>>>> specifying a sub-ordinate dCDN. For example, in a cascade such as C= DN-A >>>>> - >>>>>>>=20 >>>>>>> CDN-B -> CDN-C, CDN-C will share logging info with CDN-B, but not w= ith >>>>>>> CDN-A; CDN-B shares logging info with CDN-A. This can be desirable = for >>>>>>> hiding the topology and delegation used by the dCDN. However, this >>>>>> document >>>>>>> does not discuss how the logging provided by CDN-C gets converted i= nto >>>>>> the >>>>>>> logs for CDN-B that will be sent to CDN-A. Without some logging >>>>>> information >>>>>>> from CDN-C, it would seem difficult for CDN-A to utilize the inform= ation >>>>> to >>>>>>> meet requirements of billing, analytics, and fault and performance >>>>> analysis. >>>>>>> Maybe the logging gets aggregated and reported in CDN-B's logging, >>>>>>=20 >>>>>> Exactly. >>>>>>=20 >>>>>>> but that >>>>>>> "transitive or aggregate logging" doesn't appear to be discussed in= this >>>>>>> document. >>>>>>=20 >>>>>> It is discussed in section 2.1 through Figure 1 and the following te= xt: >>>>>> " >>>>>> A dCDN (e.g., dCDN-2) integrates the relevant Logging information >>>>>> obtained from its dCDNs (i.e., dCDN-3) in the Logging information >>>>>> that it provides to the uCDN, so that the uCDN ultimately obtains al= l >>>>>> Logging information relevant to a CSP for which it acts as the >>>>>> authoritative CDN. >>>>>> " >>>>>> Does that address your concern? >>>>>=20 >>>>> No it does not mitigate my concern. >>>>>=20 >>>>> This says the information gets "integrated", but doesn't describe wha= t >>>>> integrated means. >>>>> I could interpret that integration would be that the logging from CDN= -C >>>>> would be included in the logs from CDN-B to CDN-A, >>>>> But I think the text says CDN-B will not share the logging entries fr= om >>>>> CDN-C with CDN-A. >>>>> Do I have this wrong? Does CDN-B create a log file and generate entr= ies, >>>>> and then when it delegates delivery to CDN-C, and CDN-C passes its lo= g file >>>>> back to CDN-B, does CDN-B take the whole log file from CDN-B and inse= rt it >>>>> into its own log file, then continue adding any more entries, and the= n when >>>>> done send the CDN-B log file (including a fully inserted CDN-C log fi= le) to >>>>> CDN-A? >>>>>=20 >>>>> If not, that presumably means that somehow, the data from CDN-C is >>>>> "aggregated" - that's how it is "integrated=94, >>>>=20 >>>> Right. It is aggregated. >>>> Effectively, if CDN-B has sub-delegated a delivery to CDN-C, then when= CDN-C provides a log record for that delivery to CDN-B, CDN-B will aggrega= te that log record with the log records for the deliveries that CDN-B condu= ted itself. When CDN-B provides log records to CDN-A, the log record corres= ponding to the delivery performed by CDN-C is turned by CDN-B into a log re= cord that looks like the delivery was done by CDN-B. CDN-A will not be awar= e that the delivery was performed by another CDN than CDN-B (just like the = Content Provider is not ware that the delivery was not performed by CDN-A w= ith whom it has a delivery contract). >>>>=20 >>>>> But there is no discussion of how this aggregation is done. >>>>=20 >>>> That is true. I think it has been assumed by many but never made clear= . So we need to add some discussion about that. >>>>=20 >>>>> I think your intent is to hide the fact that CDN-B used CDN-C, since = that >>>>> may reflect a proprietary approach of CDN-B's business model. >>>>=20 >>>> Right. >>>>=20 >>>>> But CDN-A would presumably have problems performing analytics, and fa= ult and >>>>> performance analysis, if the data from CDN-C is not included in CDN-B= 's >>>>> logging to CDN-A.=20 >>>>> So I would like an example to demonstrate what CDN-A would see in CDN= -B's >>>>> logs if CDN-C had faults or performance problems, and I would like to= see >>>>> how CDN-A could perform analytics (of any kind) relating to the deliv= ery >>>>> performed by CDN-C. >>>>=20 >>>> The assumption is that CDN-A is only dealing with CDN-B. CDN-A may not= not even be aware of CDN-C.=20 >>>> So CDN-A analaytics/monitoring will establish whether all the deliveri= es delegated to CDN-B (comprising deliveries performed by CDN-B as well as = deliveries redirected by CDN-B to CDN-C and possibly CDN-C2) have received = the right quality (ie if CDN-B has met the SLA committed to CDN-A). >>>> If some deliveries have experienced quality problems, CDN-A will blame= CDN-B. It is up to CDN-B to then do its own analytics and monitoring to de= cide whether the problem lies within his own CDN or CDN-C or CDN-C2.=20 >>>> The whole thing operates as a chain of delegations, like many other bu= siness arrangements: if my SmartPhone does not work, I blame the smartPhone= vendor (I don=92t try identify if the problem is coming from the supplier = of the GSM chipset, but the SmartPhone vendor will). >>>>=20 >>>>=20 >>>>=20 >>>>> I am missing how this would be done (especially in a standardized man= ner). >>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> I think Verified-Origin is particularly problematic, because the te= xt >>>>> states >>>>>>> that this can only be added by the uCDN, never the dCDN. So what if >>>>> CDN-B >>>>>>> verifies the origin of the logs from CDN-C and then passes the >>>>> information >>>>>>> (now as a dCDN) to CDN-A? The text mentions that this might be >>>>>> established >>>>>>> using authentication mechanisms; so do we lose this logged >>>>>>> authentication/verification when cascading? >>>>>>>=20 >>>>>>> (Maybe this is resolved by having the uCDN (CDN-B) record a >>>>> "transaction" >>>>>>> that starts when it delegates a task to a dCDN (e.g. CDN-C) and end= s >>>>> when >>>>>>> the dCDN completes the task, and the uCDN just records the whole >>>>>> transaction >>>>>>> without the details that are reported by CDN-C. Then CDN-B logs onl= y the >>>>>>> whole transaction. I would like to see an explicit example of such >>>>> logging, >>>>>>> using the cdni_http_request_v1 record-type, so this is clear.) >>>>>>=20 >>>>>> Yes, that is pretty much the idea. >>>>>> ie. if CDN-a delegate sto CDN-B then CDB-B is responsible for delive= ring >>>>> and >>>>>> will provide a delivery record to CDN-A for that delivery. That reco= rd >>>>> will be >>>>>> part of a Logging File whose origin in CDN-B, and CDN-A can use >>>>>> authentication mechanism to ensure the Logging File is provided by C= DN-B. >>>>>> All of this completely holds whether CDN-B performed the delivery it= self >>>>>> (and created the delivery record in the first place) or CDN-B delega= ted to >>>>>> CDN-C who provided the delivery record to CDN-B in a Logging File wh= ose >>>>>> origin was CDN-C. >>>>>>=20 >>>>>> This question has come up before so I will add a clarification along= the >>>>> lines >>>>>> above under the description of the Verified Origin in case of cascad= ed >>>>> CDNs. >>>>>=20 >>>>> An example of such integrated cascaded logging might answer many ques= tions. >>>>=20 >>>> Good idea.=20 >>>> It sounds worthwhile to give a descripton of how log records get aggre= gated in a csacaded scenario, indicate how directives/fields get modified/k= ept at each CDN hop, and possibly include an example with some log records = and how they propagate from CDN-C to CDN-B to CDN-A. >>>>=20 >>>>> If logging records from CDN-C get copied into the log from CDN-B, are= all >>>>> directives and record types copied? >>>>> If so, I think it is important to make clear that a given log might c= ontain >>>>> multiple nested logs, >>>>> And that means that the file received by CDN-A might start with direc= tives >>>>> for CDN-B plus records,=20 >>>>> And then directives for CDN-C, ending with an Integrity-Hash, and mor= e >>>>> records for CDN-B followed by an Integrity-Hash. >>>>> Maybe this is all as designed, but I haven't seen discussion of that,= and it >>>>> is not reflected in Figure 3, and this is not discussed in the descri= ption >>>>> of fields that are file-specific, such as Integrity-hash, Verfiied-or= igin, >>>>> Version, UUID, etc. >>>>> If you have nested logs, then log-consuming applications need to know= that >>>>> those file-specific directives un-nest at the end of the included fil= e. Can >>>>> they tell consistently when they hit the end of the included file? >>>>> Should there be an end-of-log marker for the included log?=20 >>>>>=20 >>>>> The Integrity-Hash directive is allowed to occur zero or once, not mu= ltiple >>>>> times in a logfile. >>>>> So if the CDN-C logfile contains an Integrity-Hash, should that be ch= ecked >>>>> by CDN-B, then copy the CDN-C logfile into the CDN-B logfile, but dis= card >>>>> the CDN-C Integrity-Hash, because CDN-B will calculate its own >>>>> Integrity-Hash directive? >>>>=20 >>>> Yes. >>>>=20 >>>>>=20 >>>>>> Let me know if that is not sufficient. >>>>>=20 >>>>> I remain concerned that cascaded logging may not have been adequately >>>>> described and standardized. >>>>=20 >>>> Right. I see that the questions you raised were not answered in the do= cument. We will work on addressing them. >>>>=20 >>>> Thanks >>>>=20 >>>> Francois >>>>=20 >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Francois >>>>>=20 >>>>> dbh >>>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> 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 From nobody Fri Jul 4 01:25:28 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5981B2C71 for ; Fri, 4 Jul 2014 01:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.451 X-Spam-Level: * X-Spam-Status: No, score=1.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, J_BACKHAIR_37=1, J_BACKHAIR_44=1, J_BACKHAIR_52=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bT5xaDFMZ7HP for ; Fri, 4 Jul 2014 01:25:18 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 068AD1B2C7B for ; Fri, 4 Jul 2014 01:25:11 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 3A5F4C013D; Fri, 4 Jul 2014 10:25:09 +0200 (CEST) Received: from PMEXCH51.intranet-paris.francetelecom.fr (unknown [10.100.76.23]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 2563A384077; Fri, 4 Jul 2014 10:25:09 +0200 (CEST) Received: from PMEXCB1D.intranet-paris.francetelecom.fr ([10.100.76.11]) by PMEXCH51.intranet-paris.francetelecom.fr ([10.100.76.23]) with mapi; Fri, 4 Jul 2014 10:25:08 +0200 From: To: "Francois Le Faucheur (flefauch)" , Niven-Jenkins Ben Date: Fri, 4 Jul 2014 10:25:07 +0200 Thread-Topic: [CDNi] Utility of Verified-Origin & Claimed-Origin in CDNI logging Thread-Index: AQHPluW8wWdZ2VEK5ESkrvRbs+8LfJuP5tkA//+tUcA= Message-ID: <5295_1404462309_53B664E5_5295_3874_1_8F0D2F5E4AAB7249BC7339A3E944DEDD228BFE2202@PMEXCB1D.intranet-paris.francetelecom.fr> References: <038401cf5b4f$0b5ea610$221bf230$@comcast.net> <05BD7B6B-6886-4277-8A8A-8AE77363939B@cisco.com> <315A2A4B-C876-4FF7-A836-7D48AC191195@cisco.com> 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: 2014.7.3.74221 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/ipGBUi_B-HflX8QNmH7-K_n7YQA Cc: "cdni@ietf.org" Subject: Re: [CDNi] Utility of Verified-Origin & Claimed-Origin in CDNI logging X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 08:25:22 -0000 Hello all, I was thinking yesterday that these directives come from non-repudiation ti= mes. Also, I was wondering what are the implications of making Validated-Or= igin transitory in the scenario described by Ben. In the case of a visible = relationship between tCDN and dCDN, maybe uCDN wants to know that tCDN prov= ides some guarantee with respect to the lower part of the logging chain (he= re, the dCDN). Do you think it could be useful? -- iuniana -----Message d'origine----- De : CDNi [mailto:cdni-bounces@ietf.org] De la part de Francois Le Faucheur= (flefauch) Envoy=E9 : vendredi 4 juillet 2014 10:18 =C0 : Niven-Jenkins Ben Cc : cdni@ietf.org Objet : Re: [CDNi] Utility of Verified-Origin & Claimed-Origin in CDNI logg= ing Hi Ben, On 3 Jul 2014, at 19:39, Ben Niven-Jenkins wrote: > Francois, Colleagues, > > Reading your suggested text below made me ponder on the purpose and utili= ty of the Claimed-Origin and Verified-Origin field directives. > > Let's start with Verified-Origin. From your text below and reading the de= finition of Verified-Origin in section 3.3 of draft-ietf-cdni-logging-11 I = understand that a dCDN MUST NOT place a Verified-Origin field directive in = a log file it sends to a uCDN (it is the uCDN's job to do that if it wants = to once it has verified the origin). Furthermore in a cascaded scenario (uC= DN-tCDN-dCDN) the transit CDN MUST NOT include a Verified-Origin field dire= ctive in a log file it sends to uCDN and by implication if tCDN inserted a = Verified-Origin directive when receiving from dCDN, it must strip it before= sending that log file on to uCDN. Yes. > > Therefore use of Verified-Origin is purely internal to a given CDN, is ne= ver exchanged between CDNs and has no role to play in interoperation of CDN= I between CDNs, so why does the logging draft need to specify it at all? That's a good question. I think the train of thought that got us there is the following : * when storing the CDNI Logging File, the uCDN would want to have a= n easy way to identify where the CDNI Logging File is coming from * since the dCDN knows who he is, it is trivial for it to include i= ts identification in a field inside the file * the uCDN may be happy with that, in which case it does not have t= o do anything; * or the uCDN may want to record the identification it establishes,= in which case it has to add the corresponding field itself. That's more or less how we got there. My personal take would be: *A* if we expect that uCDNs would typically want to have an explici= t record inside the CDNI Logging File of the dCDN that originated the file = , then we should define directive(s) to do that. This will make things more= consistent for processing tools/utilities operating over CDNI Logs. And in= the case where the uCDN is happy with the origin as stated by dCDN (say be= cause the dCDN is operated by the same administrative entity), it will save= any file manipulation by the uCDN. *B* if we expect that uCDNs would typically NOT want to have an exp= licit record inside the CDNI Logging File of the dCDN that originated the f= ile (say because they want to encode that information inside the filename),= then there may not be much value in defining the directives. I personally lean towards *A*, but let's hear more opnions or arguments. Cheers Francois > CDNs that want the functionality of Verified-Origin can do whatever they = want internally to implement that, it doesn't seem we need something in the= RFC to support the internal behaviour of a CDN. > > > That then got me thinking about Claimed-Origin. If I read the text below = correctly, my understanding is that the value of Claimed-Origin should be t= he same hostname in the dCDN that the uCDN connects to in order to retrieve= log files. So for example a uCDN could compare the value of Claimed-Origin= against the values of subjectAltName in the TLS certificate presented by t= he dCDN and if there is a match then the Claimed-Origin can be "verified". > > I'm struggling to see what value Claimed-Origin gives in practice, possib= ly because I don't understand the use case for it. If the purpose is to le= t a uCDN do the comparison I describe above then I'm not sure that gives us= much in reality. Claimed-Origin becomes essentially a hop-by-hop (CDN-by-C= DN) property and assuming the dCDN identifies itself correctly (e.g. hostna= me in dCDN that uCDN connected to matches hostname(s) in TLS certificate pr= esented by dCDN) Claimed-Origin is adding nothing, or have I misunderstood? > > Thanks > Ben > > On 2 Jul 2014, at 15:39, Francois Le Faucheur (flefauch) wrote: > >> >> On 1 Jul 2014, at 20:09, Francois Le Faucheur (flefauch) wrote: >> >>> Folks, >>> >>> (as a document editor) >>> >>> To address the point around cascaded CDNs that was raised by David Harr= ington as part of his early Ops Review, I have: >>> * expanded section 3.5 "CDNI Logging File Example" >>> * added a section 3.6 "Cascaded CDNI Logging Files Example" >>> >>> Draft text is below. I'd appreciate some reviews. >> >> I did a bit more work on teh text. Latest version below. Again will appr= eciate a good review: >> >> 3.5. CDNI Logging File Example >> >> Let us consider the upstream CDN and the downstream CDN labelled >> uCDN and dCDN-1 in Figure 1. When dCDN-1 acts as a downstream CDN >> for uCDN and performs content delivery on behalf of uCDN, dCDN-1 >> will include the CDNI Logging Records corresponding to the content >> deliveries performed on behalf of uCDN in the CDNI Logging Files for >> uCDN. An example CDNI Logging File communicated by dCDN-1 to uCDN is >> shown below in Figure 4. >> >> #Version:CDNI/1.0 >> >> #UUID:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 >> >> #Claimed-Origin:cdni-logging-entity.dcdn-1.example.com >> >> #Record-Type:cdni_http_request_v1 >> >> #Fields:datetimetime-takenc-ip >> cs-methodu-uriprotocolsc-status >> sc-total-bytescs(User-Agent)cs(Referer) >> s-cached >> >> 2013-05-1700:38:06.8259.05810.5.7.1GET >> http://cdni-ucdn.dcdn-1.example.com/video/movie100.mp4 >> HTTP/1.12006729891"Mozilla/5.0 >> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >> Gecko) Chrome/5.0.375.127 Safari/533.4" >> "host1.example.com"1 >> >> 2013-05-1700:39:09.14515.3210.5.10.5GET >> http://cdni-ucdn.dcdn-1.example.com/video/movie118.mp4 >> HTTP/1.120015799210"Mozilla/5.0 >> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >> Gecko) Chrome/5.0.375.127 Safari/533.4" >> "host1.example.com"1 >> >> 2013-05-1700:42:53.43752.87910.5.10.5GET> > http://cdni-ucdn.dcdn-1.example.com/video/picture11.mp4 >> HTTP/1.020097234724"Mozilla/5.0 >> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >> Gecko) Chrome/5.0.375.127 Safari/533.4" >> "host5.example.com"0 >> >> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >> >> [Editor's Note: compute the correct Integrity-Hash value once example >> is frozen] >> >> >> Figure 4: CDNI Logging File Example >> >> If uCDN establishes by some means (e.g. via TLS authentication when >> pulling the CDNI Logging File) the identity of the entity from which >> it pulled the CDNI Logging File, uCDN can add to the CDNI Logging a >> Verified-Origin directive as illustrated below: >> >> #Verified-Origin:cdni-logging-entity.dcdn-1.example.com >> >> As illustrated in Figure 2, uCDN will then ingest the corresponding >> CDNI Logging Records into its Collection process, alongside the >> Logging Records generated locally by the uCDN itself. This allows >> uCDN to aggregate Logging Records for deliveries performed by itself >> (through Records generated locally) as well as for deliveries >> performed by its downstream CDN(s). This aggregate information can >> then be used (after Filtering and Rectification, as illustrated in >> Figure 2) by Log Consuming Applications that take into account >> deliveries performed by uCDN as well as by all of its downstream >> CDNs. >> >> We observe that the time between >> >> 1. when a delivery is completed in dCDN and >> >> 2. when the corresponding Logging Record is ingested by the >> Collection process in uCDN >> >> depends on a number of parameters such as the Logging Period agreed >> to by uCDN and dCDN, how much time uCDN waits before pulling the CDNI >> Logging File once it is advertised in the CDNI Logging Feed, and the >> time to complete the pull of the CDNI Logging File. Therefore, if we >> consider the set of Logging Records aggregated by the Collection >> process in uCDN in a given time interval, there could be a permanent >> significant timing difference between the CDNI Logging Records >> received from the dCDN and the Logging Records generated locally. >> For example, in a given time interval, the Collection process in >> uCDN may be aggregating Logging Records generated locally by uCDN >> for deliveries performed in the last hour and CDNI Logging Records >> generated in the dCDN for deliveries in the hour before last. >> >> 3.6. Cascaded CDNI Logging Files Example >> >> Let us consider the cascaded CDN scenario of uCDN, dCDN-2 and dCDN-3 >> as depicted in Figure 1. After completion of a delivery by dCDN-3 on >> behalf of dCDN-2, dCDN-3 will include a corresponding Logging Record >> in a CDNI Logging File that will be pulled by dCDN-2 and that is >> illustrated below in Figure 5. In practice, a CDNI Logging File is >> likely to contain a very high number of CDNI Logging Records. >> However, for readability, the example in Figure 5 contains a single >> CDNI Logging Record. >> >> >> #Version:CDNI/1.0 >> >> #UUID:urn:uuid:65718ef-0123-9876-adce4321bcde >> >> #Claimed-Origin:cdni-logging-entity.dcdn-3.example.com >> >> #Record-Type:cdni_http_request_v1 >> >> #Fields:datetimetime-takenc-ip >> cs-methodu-uriprotocolsc-status >> sc-total-bytescs(User-Agent)cs(Referer) >> s-cached >> >> >> 2013-05-1700:39:09.11914.0710.5.10.9GET >> http://cdni-dcdn-2.dcdn-3.example.com/video/movie118.mp4 >> HTTP/1.120015799210"Mozilla/5.0 >> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >> Gecko) Chrome/5.0.375.127 Safari /533.4" >> "host1.example.com"1 >> >> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >> >> [Editor's Note: compute the correct Integrity-Hash value once >> example is frozen] >> >> Figure 5: Cascaded CDNI Logging File Example (dCDN-3 to dCDN-2) >> >> If dCDN-2 establishes by some means (e.g. via TLS authentication >> when pulling the CDNI Logging File) the identity of the entity from >> which it pulled the CDNI Logging File, dCDN-2 can add to the CDNI >> Logging a Verified-Origin directive as illustrated below: >> >> #Verified-Origin:cdni-logging-entity.dcdn-3.example.com >> >> dCDN-2 (behaving as an upstream CDN from the viewpoint of dCDN-3) >> will then ingest the CDNI Logging Record for the considered dCDN-3 >> delivery into its Collection process (as illustrated in Figure 2). >> This Logging Record may be aggregated with Logging Records generated >> locally by dCDN-2 for deliveries performed by dCDN-2 itself. Say, >> for illustration, that the content delivery performed by dCDN-3 on >> behalf of dCDN-2 had actually been redirected to dCDN-2 by uCDN, and >> say that another content delivery has just been redirected by uCDN to >> dCDN-2 and that dCDN-2 elected to perform the corresponding delivery >> itself. Then after Filtering and Rectification (as illustrated in >> Figure 2), dCDN-2 will include the two Logging Records corresponding >> respectively to the delivery performed by dCDN-3 and the delivery >> performed by dCDN-2, in the next CDNI Logging File that will be >> communicated to uCDN. An example of such CDNI Logging File is >> illustrated below in Figure 6. >> >> #Version:CDNI/1.0 >> >> #UUID:urn:uuid:1234567-8fedc-abab-0987654321ff >> >> #Claimed-Origin:cdni-logging-entity.dcdn-2.example.com >> >> #Record-Type:cdni_http_request_v1 >> >> #Fields:datetimetime-takenc-ip >> cs-methodu-uriprotocolsc-status >> sc-total-bytescs(User-Agent)cs(Referer) >> s-cached >> >> 2013-05-1700:39:09.11914.0710.5.10.9GET >> http://cdni-ucdn.dcdn-2.example.com/video/movie118.mp4 >> HTTP/1.120015799210"Mozilla/5.0 >> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >> Gecko) Chrome/5.0.375.127 Safari /533.4" >> "host1.example.com"1 >> >> 2013-05-1701:42:53.43752.87910.5.10.12GET> B> http://cdni-ucdn.dcdn-2.example.com/video/picture11.mp4 >> HTTP/1.020097234724"Mozilla/5.0 >> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >> Gecko) Chrome/5.0.375.127 Safari /533.4" >> "host5.example.com"0 >> >> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >> >> [Editor's Note: compute the correct Integrity-Hash value once example >> is frozen] >> >> Figure 6: Cascaded CDNI Logging File Example (dCDN-2 to uCDN) >> >> If uCDN establishes by some means (e.g. via TLS authentication when >> pulling the CDNI Logging File) the identity of the entity from which >> it pulled the CDNI Logging File, uCDN can add to the CDNI Logging a >> Verified-Origin directive as illustrated below: >> >> #Verified-Origin:cdni-logging-entity.dcdn-2.example.com >> >> In the example of Figure 6, we observe that: >> >> o the first Logging Record corresponds to the Logging Record >> communicated earlier to dCDN-2 by dCDN-3, which corresponds to a >> delivery redirected by uCDN to dCDN-2 and then redirected by >> dCDN-2 to dCDN-3. Its initial fields values are preserved, with >> the exception of the u-uri that now reflects the URI convention >> between uCDN and dCDN-2, and which presents the delivery to uCDN >> as if it was performed by dCDN-2 itself, which reflects the fact >> that dCDN-2 had taken the full responsibility of the corresponding >> delivery (even if in this case, dCDN-2 elected to redirect the >> delivery to dCDN-3 so it is actually performed by dCDN-3 on behalf >> of dCDN-2). >> >> o the second Logging Record corresponds to a delivery redirected by >> uCDN to dCDN-2 and performed by dCDN-2 itself. The time of the >> delivery in this Logging Record may be significantly more recent >> than the first Logging Record since it was generated locally while >> the first Logging Record was generated by dCDN-3 and had to be >> advertised , and then pulled and then ingested into the dCDN-2 >> Collection process, before being aggregated with the second >> Logging Record. >> >> >> >> Cheers >> >> Francois >> >> >> >>> >>> Thanks >>> >>> Francois >>> >>> " >>> >>> 3.5. CDNI Logging File Example >>> >>> Let us consider the upstream CDN and the downstream CDN labelled >>> uCDN and dCDN-1 in Figure 1. When dCDN-1 acts as a downstream CDN >>> for uCDN and performs content delivery on behalf of uCDN, dCDN-1 >>> will include the CDNI Logging Records corresponding to the content >>> deliveries performed on behalf of uCDN in the CDNI Logging Files for >>> uCDN. An example CDNI Logging File communicated by dCDN-1 to uCDN >>> is show below: >>> >>> " >>> >>> #Version:CDNI/1.0 >>> >>> #UUID:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 >>> >>> #Claimed-Origin:cdni-logging-entity.dcdn-1.example.com >>> >>> #Record-Type:cdni_http_request_v1 >>> >>> #Fields:datetimetime-takenc-ipcs- >>> methodu-uriprotocolsc-statussc-total- >>> bytescs(User-Agent)cs(Referer)s-cached >>> >>> 2013-05-1700:38:06.8259.05810.5.7.1GET >>> h ttp://cdni-ucdn.dcdn-1.example.com/video/ >>> movie100.mp4HTTP/1.12006729891"Mozilla/5.0 >>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>> Gecko) Chrome/5.0.375.127 Safari >>> /533.4""host1.example.com"1 >>> >>> 2013-05-1700:39:09.14515.3210.5.10.5GET>> > http://cdni-ucdn.dcdn-1.example.com/video/ >>> movie118.mp4HTTP/1.120015799210"Mozilla/5.0 >>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>> Gecko) Chrome/5.0.375.127 Safari >>> /533.4""host1.example.com"1 >>> >>> 2013-05-1700:42:53.43752.87910.5.10.5GET>> B >>>> http://cdni-ucdn.dcdn-1.example.com/video/ >>> picture11.mp4HTTP/1.020097234724"Mozilla/5.0 >>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>> Gecko) Chrome/5.0.375.127 Safari >>> /533.4""host5.example.com"0 >>> >>> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >>> >>> [Editor's Note: compute the correct Integrity-Hash value once >>> example is frozen] >>> >>> " >>> >>> As illustrated in Figure 2, uCDN will then ingest the corresponding >>> CDNI Logging Records into its Collection process, alongside the >>> Logging Records generated locally by the uCDN itself. This allows >>> uCDN to aggregate Logging Records for deliveries performed by itself >>> (through Records generated locally) as well as for deliveries >>> performed by its downstream CDN(s). This aggregate information can >>> then be used (after Filtering and Rectification, as illustrated in >>> Figure 2) by Log Consuming Applications considering deliveries >>> performed by uCDN as well as by all its downstream CDN(s). >>> >>> We observe that the time between >>> >>> 1. when a delivery is completed in dCDN and >>> >>> 2. when the corresponding Logging Record is ingested by the >>> Collection process in uCDN >>> >>> depends on a number of parameters such as the Logging Period agreed >>> to by uCDN and dCDN, how much time uCDN waits after it is advertised >>> in the CDNI Logging Feed before pulling the CDNI Logging File, and >>> the time to complete the pull of the CDNI Logging File. Therefore, >>> if we consider the set of Logging Records aggregated by the >>> Collection process in uCDN in a given time interval, there could be >>> a permanent significant timing difference between the CDNI Logging >>> Records received from the dCDN and the Logging Records generated >>> locally. For example, in a given time interval, the Collection >>> process in uCDN may be aggregating Logging Records generated locally >>> by uCDN for deliveries performed in the last hour and CDNI Logging >>> Records generated in the dCDN for deliveries in the hour before last. >>> >>> 3.6. Cascaded CDNI Logging Files Example >>> >>> Let us consider the cascaded CDN scenario of uCDN, dCDN-2 and dCDN-3 >>> as depicted in Figure 1. After completion of a delivery by dCDN-3 >>> on behalf of dCDN-2, dCDN-3 will include a corresponding Logging >>> Record in a CDNI Logging File and will advertise this CDNI Logging >>> File to >>> d-CDN2 in the corresponding CDNI Logging feed. As a result, dCDN-2 >>> will initiate and complete the pull of the corresponding CDNI >>> Logging File that is illustrated below: >>> >>> " >>> >>> #Version:CDNI/1.0 >>> >>> #UUID:urn:uuid:65718ef-0123-9876-adce4321bcde >>> >>> #Claimed-Origin:cdni-logging-entity.dcdn-3.example.com >>> >>> #Record-Type:cdni_http_request_v1 >>> >>> #Fields:datetimetime-takenc-ipcs- >>> methodu-uriprotocolsc-statussc-total- >>> bytescs(User-Agent)cs(Referer)s-cached >>> >>> 2013-05-1700:39:09.14515.3210.5.10.5GET>> > >>> http://cdni-dcdn-2.dcdn-3.example.com/video/movie118.mp4HTTP/ >>> 1.120015799210"Mozilla/5.0 (Windows; U; Windows NT >>> 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 >>> Safari /533.4""host1.example.com"1 >>> >>> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >>> >>> [Editor's Note: compute the correct Integrity-Hash value once >>> example is frozen] >>> >>> " >>> >>> dCDN-2 (behaving as an upstream CDN from the viewpoint of dCDN-3) >>> will then ingest the CDNI Logging Record for the considered dCDN-3 >>> delivery into its Collection process (as illustrated in Figure 2). >>> This Logging Record may be aggregated with Logging Records generated >>> locally by dCDN-2 for deliveries performed by dCDN-2 itself. Say, >>> for illustration, that the content delivery performed by dCDN-3 on >>> behalf of dCDN-2 had actually been redirected to dCDN-2 by uCDN, and >>> say that another content delivery has just been redirected by uCDN >>> to >>> dCDN-2 and that dCDN-2 elected to perform the corresponding delivery >>> itself. Then after Filtering and Rectification (as illustrated in >>> Figure 2), dCDN-2 will include the two Logging Records corresponding >>> respectively to the delivery performed by dCDN-3 and the delivery >>> performed by dCDN-2, in the next CDNI Logging File that will be >>> communcated to uCDN. An example of such CDNI Logging File is >>> illustrated below: >>> >>> #Version:CDNI/1.0 >>> >>> #UUID:urn:uuid:1234567-8fedc-abab-0987654321ff >>> >>> #Claimed-Origin:cdni-logging-entity.dcdn-2.example.com >>> >>> #Record-Type:cdni_http_request_v1 >>> >>> #Fields:datetimetime-takenc-ipcs- >>> methodu-uriprotocolsc-statussc-total- >>> bytescs(User-Agent)cs(Referer)s-cached >>> >>> 2013-05-1700:39:09.14515.3210.5.10.5GET>> > http://cdni-ucdn.dcdn-2.example.com/video/movie118.mp4HTTP/ >>> 1.120015799210"Mozilla/5.0 (Windows; U; Windows NT >>> 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 >>> Safari /533.4""host1.example.com"1 >>> >>> 2013-05-1701:42:53.43752.87910.5.10.5GET>> B >>>> http://cdni-ucdn.dcdn-2.example.com/video/picture11.mp4HTTP/ >>> 1.020097234724"Mozilla/5.0 (Windows; U; Windows NT >>> 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 >>> Safari /533.4""host5.example.com"0 >>> >>> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >>> >>> [Editor's Note: compute the correct Integrity-Hash value once >>> example is frozen] >>> >>> " >>> >>> In the example above, we observe that: >>> >>> o the first Logging Record corresponds to the Logging Record >>> communicated earlier to dCDN-2 by dCDN-3, which corresponds to a >>> delivery redirected by uCDN to dCDN-2 and then redirected by >>> dCDN-2 to dCDN-3. Its initial fields values are preserved, with >>> the exception of the u-uri that now reflects the URI convention >>> between uCDN and dCDN-2, and which presents the delivery to uCDN >>> as if it was performed by dCDN-2 itself, which reflects the fact >>> that dCDN-2 had taken the full responsibility of the corresponding >>> delivery (even if in this case, dCDN-2 elected to redirect the >>> delivery to dCDN-3 so it is actually performed by dCDN-3 on behalf >>> of dCDN-2). >>> >>> o the second Logging Record corresponds to a delivery redirected by >>> uCDN to dCDN-2 and performed by dCDN-2 itself. The time of the >>> delivery in this Logging Record may be significantly more recent >>> than the first Logging Record since it was generated locally while >>> the first Logging Record was generated by dCDN-3 and had to be >>> advertised , and then pulled and then ingested into the dCDN-2 >>> Collection process, before being aggregated with the second >>> Logging Record. >>> >>> " >>> >>> >>> On 23 Apr 2014, at 20:29, Francois Le Faucheur (flefauch) wrote: >>> >>>> Hello, >>>> >>>> On 18 Apr 2014, at 23:42, ietfdbh wrote: >>>>>> >>>>>> On 5 Apr 2014, at 23:14, ietfdbh wrote: >>>>>>> >>>>>>> >>>>>>> Most notably, the logging from a dCDN to a uCDN typically >>>>>>> contains only >>>>>> one >>>>>>> dCDN identifier, such as Verified-origin, and doesn't really >>>>>>> permit specifying a sub-ordinate dCDN. For example, in a cascade >>>>>>> such as CDN-A >>>>> - >>>>>>> >>>>>>> CDN-B -> CDN-C, CDN-C will share logging info with CDN-B, but >>>>>>> not with CDN-A; CDN-B shares logging info with CDN-A. This can >>>>>>> be desirable for hiding the topology and delegation used by the >>>>>>> dCDN. However, this >>>>>> document >>>>>>> does not discuss how the logging provided by CDN-C gets >>>>>>> converted into >>>>>> the >>>>>>> logs for CDN-B that will be sent to CDN-A. Without some logging >>>>>> information >>>>>>> from CDN-C, it would seem difficult for CDN-A to utilize the >>>>>>> information >>>>> to >>>>>>> meet requirements of billing, analytics, and fault and >>>>>>> performance >>>>> analysis. >>>>>>> Maybe the logging gets aggregated and reported in CDN-B's >>>>>>> logging, >>>>>> >>>>>> Exactly. >>>>>> >>>>>>> but that >>>>>>> "transitive or aggregate logging" doesn't appear to be discussed >>>>>>> in this document. >>>>>> >>>>>> It is discussed in section 2.1 through Figure 1 and the following te= xt: >>>>>> " >>>>>> A dCDN (e.g., dCDN-2) integrates the relevant Logging information >>>>>> obtained from its dCDNs (i.e., dCDN-3) in the Logging information >>>>>> that it provides to the uCDN, so that the uCDN ultimately obtains >>>>>> all Logging information relevant to a CSP for which it acts as >>>>>> the authoritative CDN. >>>>>> " >>>>>> Does that address your concern? >>>>> >>>>> No it does not mitigate my concern. >>>>> >>>>> This says the information gets "integrated", but doesn't describe >>>>> what integrated means. >>>>> I could interpret that integration would be that the logging from >>>>> CDN-C would be included in the logs from CDN-B to CDN-A, But I >>>>> think the text says CDN-B will not share the logging entries from >>>>> CDN-C with CDN-A. >>>>> Do I have this wrong? Does CDN-B create a log file and generate >>>>> entries, and then when it delegates delivery to CDN-C, and CDN-C >>>>> passes its log file back to CDN-B, does CDN-B take the whole log >>>>> file from CDN-B and insert it into its own log file, then continue >>>>> adding any more entries, and then when done send the CDN-B log >>>>> file (including a fully inserted CDN-C log file) to CDN-A? >>>>> >>>>> If not, that presumably means that somehow, the data from CDN-C is >>>>> "aggregated" - that's how it is "integrated", >>>> >>>> Right. It is aggregated. >>>> Effectively, if CDN-B has sub-delegated a delivery to CDN-C, then when= CDN-C provides a log record for that delivery to CDN-B, CDN-B will aggrega= te that log record with the log records for the deliveries that CDN-B condu= ted itself. When CDN-B provides log records to CDN-A, the log record corres= ponding to the delivery performed by CDN-C is turned by CDN-B into a log re= cord that looks like the delivery was done by CDN-B. CDN-A will not be awar= e that the delivery was performed by another CDN than CDN-B (just like the = Content Provider is not ware that the delivery was not performed by CDN-A w= ith whom it has a delivery contract). >>>> >>>>> But there is no discussion of how this aggregation is done. >>>> >>>> That is true. I think it has been assumed by many but never made clear= . So we need to add some discussion about that. >>>> >>>>> I think your intent is to hide the fact that CDN-B used CDN-C, >>>>> since that may reflect a proprietary approach of CDN-B's business mo= del. >>>> >>>> Right. >>>> >>>>> But CDN-A would presumably have problems performing analytics, and >>>>> fault and performance analysis, if the data from CDN-C is not >>>>> included in CDN-B's logging to CDN-A. >>>>> So I would like an example to demonstrate what CDN-A would see in >>>>> CDN-B's logs if CDN-C had faults or performance problems, and I >>>>> would like to see how CDN-A could perform analytics (of any kind) >>>>> relating to the delivery performed by CDN-C. >>>> >>>> The assumption is that CDN-A is only dealing with CDN-B. CDN-A may not= not even be aware of CDN-C. >>>> So CDN-A analaytics/monitoring will establish whether all the deliveri= es delegated to CDN-B (comprising deliveries performed by CDN-B as well as = deliveries redirected by CDN-B to CDN-C and possibly CDN-C2) have received = the right quality (ie if CDN-B has met the SLA committed to CDN-A). >>>> If some deliveries have experienced quality problems, CDN-A will blame= CDN-B. It is up to CDN-B to then do its own analytics and monitoring to de= cide whether the problem lies within his own CDN or CDN-C or CDN-C2. >>>> The whole thing operates as a chain of delegations, like many other bu= siness arrangements: if my SmartPhone does not work, I blame the smartPhone= vendor (I don't try identify if the problem is coming from the supplier of= the GSM chipset, but the SmartPhone vendor will). >>>> >>>> >>>> >>>>> I am missing how this would be done (especially in a standardized man= ner). >>>>> >>>>>> >>>>>>> >>>>>>> I think Verified-Origin is particularly problematic, because the >>>>>>> text >>>>> states >>>>>>> that this can only be added by the uCDN, never the dCDN. So what >>>>>>> if >>>>> CDN-B >>>>>>> verifies the origin of the logs from CDN-C and then passes the >>>>> information >>>>>>> (now as a dCDN) to CDN-A? The text mentions that this might be >>>>>> established >>>>>>> using authentication mechanisms; so do we lose this logged >>>>>>> authentication/verification when cascading? >>>>>>> >>>>>>> (Maybe this is resolved by having the uCDN (CDN-B) record a >>>>> "transaction" >>>>>>> that starts when it delegates a task to a dCDN (e.g. CDN-C) and >>>>>>> ends >>>>> when >>>>>>> the dCDN completes the task, and the uCDN just records the whole >>>>>> transaction >>>>>>> without the details that are reported by CDN-C. Then CDN-B logs >>>>>>> only the whole transaction. I would like to see an explicit >>>>>>> example of such >>>>> logging, >>>>>>> using the cdni_http_request_v1 record-type, so this is clear.) >>>>>> >>>>>> Yes, that is pretty much the idea. >>>>>> ie. if CDN-a delegate sto CDN-B then CDB-B is responsible for >>>>>> delivering >>>>> and >>>>>> will provide a delivery record to CDN-A for that delivery. That >>>>>> record >>>>> will be >>>>>> part of a Logging File whose origin in CDN-B, and CDN-A can use >>>>>> authentication mechanism to ensure the Logging File is provided by C= DN-B. >>>>>> All of this completely holds whether CDN-B performed the delivery >>>>>> itself (and created the delivery record in the first place) or >>>>>> CDN-B delegated to CDN-C who provided the delivery record to >>>>>> CDN-B in a Logging File whose origin was CDN-C. >>>>>> >>>>>> This question has come up before so I will add a clarification >>>>>> along the >>>>> lines >>>>>> above under the description of the Verified Origin in case of >>>>>> cascaded >>>>> CDNs. >>>>> >>>>> An example of such integrated cascaded logging might answer many ques= tions. >>>> >>>> Good idea. >>>> It sounds worthwhile to give a descripton of how log records get aggre= gated in a csacaded scenario, indicate how directives/fields get modified/k= ept at each CDN hop, and possibly include an example with some log records = and how they propagate from CDN-C to CDN-B to CDN-A. >>>> >>>>> If logging records from CDN-C get copied into the log from CDN-B, >>>>> are all directives and record types copied? >>>>> If so, I think it is important to make clear that a given log >>>>> might contain multiple nested logs, And that means that the file >>>>> received by CDN-A might start with directives for CDN-B plus >>>>> records, And then directives for CDN-C, ending with an >>>>> Integrity-Hash, and more records for CDN-B followed by an >>>>> Integrity-Hash. >>>>> Maybe this is all as designed, but I haven't seen discussion of >>>>> that, and it is not reflected in Figure 3, and this is not >>>>> discussed in the description of fields that are file-specific, >>>>> such as Integrity-hash, Verfiied-origin, Version, UUID, etc. >>>>> If you have nested logs, then log-consuming applications need to >>>>> know that those file-specific directives un-nest at the end of the >>>>> included file. Can they tell consistently when they hit the end of th= e included file? >>>>> Should there be an end-of-log marker for the included log? >>>>> >>>>> The Integrity-Hash directive is allowed to occur zero or once, not >>>>> multiple times in a logfile. >>>>> So if the CDN-C logfile contains an Integrity-Hash, should that be >>>>> checked by CDN-B, then copy the CDN-C logfile into the CDN-B >>>>> logfile, but discard the CDN-C Integrity-Hash, because CDN-B will >>>>> calculate its own Integrity-Hash directive? >>>> >>>> Yes. >>>> >>>>> >>>>>> Let me know if that is not sufficient. >>>>> >>>>> I remain concerned that cascaded logging may not have been >>>>> adequately described and standardized. >>>> >>>> Right. I see that the questions you raised were not answered in the do= cument. We will work on addressing them. >>>> >>>> Thanks >>>> >>>> Francois >>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>> Francois >>>>> >>>>> dbh >>>>> >>>> >>> >>> _______________________________________________ >>> 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 ___________________________________________________________________________= ______________________________________________ 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 nobody Fri Jul 4 01:54:40 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 339F11B279F for ; Fri, 4 Jul 2014 01:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.152 X-Spam-Level: X-Spam-Status: No, score=-12.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_BACKHAIR_37=1, J_BACKHAIR_44=1, J_BACKHAIR_52=1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0i1ObUPxXtrY for ; Fri, 4 Jul 2014 01:54:34 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F14C21B2C95 for ; Fri, 4 Jul 2014 01:54:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=38538; q=dns/txt; s=iport; t=1404464074; x=1405673674; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ASJ6NrMnhPSMYryovrQLePTU8BL35r3VeHgtvLiSaNA=; b=QJmhxYMveY/6y+jhSVxTLNkqKX8g2V6F+U3QNwxhze1f2CKrpv1SQKC/ Xs2g1OX43tWYHQFQVNmbIrNV89vtxMkp/n2yKHb/RDgxS86r9fgHJvwKG H7+g6J0NRVzNXqTzNn7AaOg6yYy3hfFpnvjShR8edLoVbhC/5dqxoCue3 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEHAMpqtlOtJA2N/2dsb2JhbABQAQmDDVJarA2SXYc/AYEMFnWEAwEBAQMBAQEBFwEMRwQHBQsCAQgYFRIHJwsUAwENAgQOAwKILgMJCA3DHAiGVxeNBYE7BgEKAR0IKwcCCIMjgRYFlhZGhBqBSIouiBaDQ0ErAYEDBxcGHA X-IronPort-AV: E=Sophos;i="5.01,599,1400025600"; d="scan'208";a="58301877" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-7.cisco.com with ESMTP; 04 Jul 2014 08:54:32 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s648sV3i002441 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Jul 2014 08:54:31 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Fri, 4 Jul 2014 03:54:31 -0500 From: "Francois Le Faucheur (flefauch)" To: "iuniana.oprescu@orange.com" Thread-Topic: [CDNi] Utility of Verified-Origin & Claimed-Origin in CDNI logging Thread-Index: AQHPl2F6GR1DlAYgNkqt/J9YJ5aSFpuP8CwA Date: Fri, 4 Jul 2014 08:54:31 +0000 Message-ID: References: <038401cf5b4f$0b5ea610$221bf230$@comcast.net> <05BD7B6B-6886-4277-8A8A-8AE77363939B@cisco.com> <315A2A4B-C876-4FF7-A836-7D48AC191195@cisco.com> <5295_1404462309_53B664E5_5295_3874_1_8F0D2F5E4AAB7249BC7339A3E944DEDD228BFE2202@PMEXCB1D.intranet-paris.francetelecom.fr> In-Reply-To: <5295_1404462309_53B664E5_5295_3874_1_8F0D2F5E4AAB7249BC7339A3E944DEDD228BFE2202@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.200] Content-Type: text/plain; charset="Windows-1252" Content-ID: <066567FB629EA34E836E18E8DA330C6D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/dGPY615VDCXs9aNPky9s2zTpKwk Cc: "cdni@ietf.org" Subject: Re: [CDNi] Utility of Verified-Origin & Claimed-Origin in CDNI logging X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 08:54:38 -0000 On 4 Jul 2014, at 10:25, wrote: > Hello all, >=20 > I was thinking yesterday that these directives come from non-repudiation = times. I don=92t think so. In any case, I think we can agree that they do not brin= g any value in terms of non-repudiation. > Also, I was wondering what are the implications of making Validated-Origi= n transitory in the scenario described by Ben. In the case of a visible rel= ationship between tCDN and dCDN, maybe uCDN wants to know that tCDN provide= s some guarantee with respect to the lower part of the logging chain (here,= the dCDN). I don=92t think Ben was proposing to make the Validated Origin transitory. = I don=92t think we should. Our model is that tCDN takes the full responsibi= lity of deliveries (and associated operations such as providing correspondi= ng logs) vis a vis of uCDN. uCDN does not care how the logs were generated = and by who (eg tCDN or a downstream CDN of tCDN) and tCDN does not want to = expose whether it uses further downstream CDNs or not; uCDN only cares that= the logs provided by tCDN are accurate and that tCDN ensured the correspon= ding deliveries were performed as per agreed SLA between uCDN and tCDN. >=20 > Do you think it could be useful? Nope. Francois > -- iuniana >=20 > -----Message d'origine----- > De : CDNi [mailto:cdni-bounces@ietf.org] De la part de Francois Le Fauche= ur (flefauch) > Envoy=E9 : vendredi 4 juillet 2014 10:18 > =C0 : Niven-Jenkins Ben > Cc : cdni@ietf.org > Objet : Re: [CDNi] Utility of Verified-Origin & Claimed-Origin in CDNI lo= gging >=20 > Hi Ben, >=20 > On 3 Jul 2014, at 19:39, Ben Niven-Jenkins wrot= e: >=20 >> Francois, Colleagues, >>=20 >> Reading your suggested text below made me ponder on the purpose and util= ity of the Claimed-Origin and Verified-Origin field directives. >>=20 >> Let's start with Verified-Origin. From your text below and reading the d= efinition of Verified-Origin in section 3.3 of draft-ietf-cdni-logging-11 I= understand that a dCDN MUST NOT place a Verified-Origin field directive in= a log file it sends to a uCDN (it is the uCDN's job to do that if it wants= to once it has verified the origin). Furthermore in a cascaded scenario (u= CDN-tCDN-dCDN) the transit CDN MUST NOT include a Verified-Origin field dir= ective in a log file it sends to uCDN and by implication if tCDN inserted a= Verified-Origin directive when receiving from dCDN, it must strip it befor= e sending that log file on to uCDN. >=20 > Yes. >=20 >>=20 >> Therefore use of Verified-Origin is purely internal to a given CDN, is n= ever exchanged between CDNs and has no role to play in interoperation of CD= NI between CDNs, so why does the logging draft need to specify it at all? >=20 > That's a good question. >=20 > I think the train of thought that got us there is the following : > * when storing the CDNI Logging File, the uCDN would want to have = an easy way to identify where the CDNI Logging File is coming from > * since the dCDN knows who he is, it is trivial for it to include = its identification in a field inside the file > * the uCDN may be happy with that, in which case it does not have = to do anything; > * or the uCDN may want to record the identification it establishes= , in which case it has to add the corresponding field itself. > That's more or less how we got there. >=20 > My personal take would be: > *A* if we expect that uCDNs would typically want to have an explic= it record inside the CDNI Logging File of the dCDN that originated the file= , then we should define directive(s) to do that. This will make things mor= e consistent for processing tools/utilities operating over CDNI Logs. And i= n the case where the uCDN is happy with the origin as stated by dCDN (say b= ecause the dCDN is operated by the same administrative entity), it will sav= e any file manipulation by the uCDN. > *B* if we expect that uCDNs would typically NOT want to have an ex= plicit record inside the CDNI Logging File of the dCDN that originated the = file (say because they want to encode that information inside the filename)= , then there may not be much value in defining the directives. >=20 > I personally lean towards *A*, but let's hear more opnions or arguments. >=20 > Cheers >=20 > Francois >=20 >=20 >> CDNs that want the functionality of Verified-Origin can do whatever they= want internally to implement that, it doesn't seem we need something in th= e RFC to support the internal behaviour of a CDN. >>=20 >>=20 >> That then got me thinking about Claimed-Origin. If I read the text below= correctly, my understanding is that the value of Claimed-Origin should be = the same hostname in the dCDN that the uCDN connects to in order to retriev= e log files. So for example a uCDN could compare the value of Claimed-Origi= n against the values of subjectAltName in the TLS certificate presented by = the dCDN and if there is a match then the Claimed-Origin can be "verified". >>=20 >> I'm struggling to see what value Claimed-Origin gives in practice, possi= bly because I don't understand the use case for it. If the purpose is to l= et a uCDN do the comparison I describe above then I'm not sure that gives u= s much in reality. Claimed-Origin becomes essentially a hop-by-hop (CDN-by-= CDN) property and assuming the dCDN identifies itself correctly (e.g. hostn= ame in dCDN that uCDN connected to matches hostname(s) in TLS certificate p= resented by dCDN) Claimed-Origin is adding nothing, or have I misunderstood= ? >>=20 >> Thanks >> Ben >>=20 >> On 2 Jul 2014, at 15:39, Francois Le Faucheur (flefauch) wrote: >>=20 >>>=20 >>> On 1 Jul 2014, at 20:09, Francois Le Faucheur (flefauch) wrote: >>>=20 >>>> Folks, >>>>=20 >>>> (as a document editor) >>>>=20 >>>> To address the point around cascaded CDNs that was raised by David Har= rington as part of his early Ops Review, I have: >>>> * expanded section 3.5 "CDNI Logging File Example" >>>> * added a section 3.6 "Cascaded CDNI Logging Files Example" >>>>=20 >>>> Draft text is below. I'd appreciate some reviews. >>>=20 >>> I did a bit more work on teh text. Latest version below. Again will app= reciate a good review: >>>=20 >>> 3.5. CDNI Logging File Example >>>=20 >>> Let us consider the upstream CDN and the downstream CDN labelled >>> uCDN and dCDN-1 in Figure 1. When dCDN-1 acts as a downstream CDN >>> for uCDN and performs content delivery on behalf of uCDN, dCDN-1 >>> will include the CDNI Logging Records corresponding to the content >>> deliveries performed on behalf of uCDN in the CDNI Logging Files for >>> uCDN. An example CDNI Logging File communicated by dCDN-1 to uCDN is >>> shown below in Figure 4. >>>=20 >>> #Version:CDNI/1.0 >>>=20 >>> #UUID:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 >>>=20 >>> #Claimed-Origin:cdni-logging-entity.dcdn-1.example.com >>>=20 >>> #Record-Type:cdni_http_request_v1 >>>=20 >>> #Fields:datetimetime-takenc-ip >>> cs-methodu-uriprotocolsc-status >>> sc-total-bytescs(User-Agent)cs(Referer) >>> s-cached >>>=20 >>> 2013-05-1700:38:06.8259.05810.5.7.1GET >>> http://cdni-ucdn.dcdn-1.example.com/video/movie100.mp4 >>> HTTP/1.12006729891"Mozilla/5.0 >>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>> Gecko) Chrome/5.0.375.127 Safari/533.4" >>> "host1.example.com"1 >>>=20 >>> 2013-05-1700:39:09.14515.3210.5.10.5GET >>> http://cdni-ucdn.dcdn-1.example.com/video/movie118.mp4 >>> HTTP/1.120015799210"Mozilla/5.0 >>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>> Gecko) Chrome/5.0.375.127 Safari/533.4" >>> "host1.example.com"1 >>>=20 >>> 2013-05-1700:42:53.43752.87910.5.10.5GET>>> http://cdni-ucdn.dcdn-1.example.com/video/picture11.mp4 >>> HTTP/1.020097234724"Mozilla/5.0 >>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>> Gecko) Chrome/5.0.375.127 Safari/533.4" >>> "host5.example.com"0 >>>=20 >>> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >>>=20 >>> [Editor's Note: compute the correct Integrity-Hash value once example >>> is frozen] >>>=20 >>>=20 >>> Figure 4: CDNI Logging File Example >>>=20 >>> If uCDN establishes by some means (e.g. via TLS authentication when >>> pulling the CDNI Logging File) the identity of the entity from which >>> it pulled the CDNI Logging File, uCDN can add to the CDNI Logging a >>> Verified-Origin directive as illustrated below: >>>=20 >>> #Verified-Origin:cdni-logging-entity.dcdn-1.example.com >>>=20 >>> As illustrated in Figure 2, uCDN will then ingest the corresponding >>> CDNI Logging Records into its Collection process, alongside the >>> Logging Records generated locally by the uCDN itself. This allows >>> uCDN to aggregate Logging Records for deliveries performed by itself >>> (through Records generated locally) as well as for deliveries >>> performed by its downstream CDN(s). This aggregate information can >>> then be used (after Filtering and Rectification, as illustrated in >>> Figure 2) by Log Consuming Applications that take into account >>> deliveries performed by uCDN as well as by all of its downstream >>> CDNs. >>>=20 >>> We observe that the time between >>>=20 >>> 1. when a delivery is completed in dCDN and >>>=20 >>> 2. when the corresponding Logging Record is ingested by the >>> Collection process in uCDN >>>=20 >>> depends on a number of parameters such as the Logging Period agreed >>> to by uCDN and dCDN, how much time uCDN waits before pulling the CDNI >>> Logging File once it is advertised in the CDNI Logging Feed, and the >>> time to complete the pull of the CDNI Logging File. Therefore, if we >>> consider the set of Logging Records aggregated by the Collection >>> process in uCDN in a given time interval, there could be a permanent >>> significant timing difference between the CDNI Logging Records >>> received from the dCDN and the Logging Records generated locally. >>> For example, in a given time interval, the Collection process in >>> uCDN may be aggregating Logging Records generated locally by uCDN >>> for deliveries performed in the last hour and CDNI Logging Records >>> generated in the dCDN for deliveries in the hour before last. >>>=20 >>> 3.6. Cascaded CDNI Logging Files Example >>>=20 >>> Let us consider the cascaded CDN scenario of uCDN, dCDN-2 and dCDN-3 >>> as depicted in Figure 1. After completion of a delivery by dCDN-3 on >>> behalf of dCDN-2, dCDN-3 will include a corresponding Logging Record >>> in a CDNI Logging File that will be pulled by dCDN-2 and that is >>> illustrated below in Figure 5. In practice, a CDNI Logging File is >>> likely to contain a very high number of CDNI Logging Records. >>> However, for readability, the example in Figure 5 contains a single >>> CDNI Logging Record. >>>=20 >>>=20 >>> #Version:CDNI/1.0 >>>=20 >>> #UUID:urn:uuid:65718ef-0123-9876-adce4321bcde >>>=20 >>> #Claimed-Origin:cdni-logging-entity.dcdn-3.example.com >>>=20 >>> #Record-Type:cdni_http_request_v1 >>>=20 >>> #Fields:datetimetime-takenc-ip >>> cs-methodu-uriprotocolsc-status >>> sc-total-bytescs(User-Agent)cs(Referer) >>> s-cached >>>=20 >>>=20 >>> 2013-05-1700:39:09.11914.0710.5.10.9GET >>> http://cdni-dcdn-2.dcdn-3.example.com/video/movie118.mp4 >>> HTTP/1.120015799210"Mozilla/5.0 >>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>> Gecko) Chrome/5.0.375.127 Safari /533.4" >>> "host1.example.com"1 >>>=20 >>> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >>>=20 >>> [Editor's Note: compute the correct Integrity-Hash value once >>> example is frozen] >>>=20 >>> Figure 5: Cascaded CDNI Logging File Example (dCDN-3 to dCDN-2) >>>=20 >>> If dCDN-2 establishes by some means (e.g. via TLS authentication >>> when pulling the CDNI Logging File) the identity of the entity from >>> which it pulled the CDNI Logging File, dCDN-2 can add to the CDNI >>> Logging a Verified-Origin directive as illustrated below: >>>=20 >>> #Verified-Origin:cdni-logging-entity.dcdn-3.example.com >>>=20 >>> dCDN-2 (behaving as an upstream CDN from the viewpoint of dCDN-3) >>> will then ingest the CDNI Logging Record for the considered dCDN-3 >>> delivery into its Collection process (as illustrated in Figure 2). >>> This Logging Record may be aggregated with Logging Records generated >>> locally by dCDN-2 for deliveries performed by dCDN-2 itself. Say, >>> for illustration, that the content delivery performed by dCDN-3 on >>> behalf of dCDN-2 had actually been redirected to dCDN-2 by uCDN, and >>> say that another content delivery has just been redirected by uCDN to >>> dCDN-2 and that dCDN-2 elected to perform the corresponding delivery >>> itself. Then after Filtering and Rectification (as illustrated in >>> Figure 2), dCDN-2 will include the two Logging Records corresponding >>> respectively to the delivery performed by dCDN-3 and the delivery >>> performed by dCDN-2, in the next CDNI Logging File that will be >>> communicated to uCDN. An example of such CDNI Logging File is >>> illustrated below in Figure 6. >>>=20 >>> #Version:CDNI/1.0 >>>=20 >>> #UUID:urn:uuid:1234567-8fedc-abab-0987654321ff >>>=20 >>> #Claimed-Origin:cdni-logging-entity.dcdn-2.example.com >>>=20 >>> #Record-Type:cdni_http_request_v1 >>>=20 >>> #Fields:datetimetime-takenc-ip >>> cs-methodu-uriprotocolsc-status >>> sc-total-bytescs(User-Agent)cs(Referer) >>> s-cached >>>=20 >>> 2013-05-1700:39:09.11914.0710.5.10.9GET >>> http://cdni-ucdn.dcdn-2.example.com/video/movie118.mp4 >>> HTTP/1.120015799210"Mozilla/5.0 >>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>> Gecko) Chrome/5.0.375.127 Safari /533.4" >>> "host1.example.com"1 >>>=20 >>> 2013-05-1701:42:53.43752.87910.5.10.12GET>> B> http://cdni-ucdn.dcdn-2.example.com/video/picture11.mp4 >>> HTTP/1.020097234724"Mozilla/5.0 >>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>> Gecko) Chrome/5.0.375.127 Safari /533.4" >>> "host5.example.com"0 >>>=20 >>> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >>>=20 >>> [Editor's Note: compute the correct Integrity-Hash value once example >>> is frozen] >>>=20 >>> Figure 6: Cascaded CDNI Logging File Example (dCDN-2 to uCDN) >>>=20 >>> If uCDN establishes by some means (e.g. via TLS authentication when >>> pulling the CDNI Logging File) the identity of the entity from which >>> it pulled the CDNI Logging File, uCDN can add to the CDNI Logging a >>> Verified-Origin directive as illustrated below: >>>=20 >>> #Verified-Origin:cdni-logging-entity.dcdn-2.example.com >>>=20 >>> In the example of Figure 6, we observe that: >>>=20 >>> o the first Logging Record corresponds to the Logging Record >>> communicated earlier to dCDN-2 by dCDN-3, which corresponds to a >>> delivery redirected by uCDN to dCDN-2 and then redirected by >>> dCDN-2 to dCDN-3. Its initial fields values are preserved, with >>> the exception of the u-uri that now reflects the URI convention >>> between uCDN and dCDN-2, and which presents the delivery to uCDN >>> as if it was performed by dCDN-2 itself, which reflects the fact >>> that dCDN-2 had taken the full responsibility of the corresponding >>> delivery (even if in this case, dCDN-2 elected to redirect the >>> delivery to dCDN-3 so it is actually performed by dCDN-3 on behalf >>> of dCDN-2). >>>=20 >>> o the second Logging Record corresponds to a delivery redirected by >>> uCDN to dCDN-2 and performed by dCDN-2 itself. The time of the >>> delivery in this Logging Record may be significantly more recent >>> than the first Logging Record since it was generated locally while >>> the first Logging Record was generated by dCDN-3 and had to be >>> advertised , and then pulled and then ingested into the dCDN-2 >>> Collection process, before being aggregated with the second >>> Logging Record. >>>=20 >>>=20 >>>=20 >>> Cheers >>>=20 >>> Francois >>>=20 >>>=20 >>>=20 >>>>=20 >>>> Thanks >>>>=20 >>>> Francois >>>>=20 >>>> " >>>>=20 >>>> 3.5. CDNI Logging File Example >>>>=20 >>>> Let us consider the upstream CDN and the downstream CDN labelled >>>> uCDN and dCDN-1 in Figure 1. When dCDN-1 acts as a downstream CDN >>>> for uCDN and performs content delivery on behalf of uCDN, dCDN-1 >>>> will include the CDNI Logging Records corresponding to the content >>>> deliveries performed on behalf of uCDN in the CDNI Logging Files for >>>> uCDN. An example CDNI Logging File communicated by dCDN-1 to uCDN >>>> is show below: >>>>=20 >>>> " >>>>=20 >>>> #Version:CDNI/1.0 >>>>=20 >>>> #UUID:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 >>>>=20 >>>> #Claimed-Origin:cdni-logging-entity.dcdn-1.example.com >>>>=20 >>>> #Record-Type:cdni_http_request_v1 >>>>=20 >>>> #Fields:datetimetime-takenc-ipcs- >>>> methodu-uriprotocolsc-statussc-total- >>>> bytescs(User-Agent)cs(Referer)s-cached >>>>=20 >>>> 2013-05-1700:38:06.8259.05810.5.7.1GET >>>> h ttp://cdni-ucdn.dcdn-1.example.com/video/ >>>> movie100.mp4HTTP/1.12006729891"Mozilla/5.0 >>>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>>> Gecko) Chrome/5.0.375.127 Safari >>>> /533.4""host1.example.com"1 >>>>=20 >>>> 2013-05-1700:39:09.14515.3210.5.10.5GET>>>> http://cdni-ucdn.dcdn-1.example.com/video/ >>>> movie118.mp4HTTP/1.120015799210"Mozilla/5.0 >>>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>>> Gecko) Chrome/5.0.375.127 Safari >>>> /533.4""host1.example.com"1 >>>>=20 >>>> 2013-05-1700:42:53.43752.87910.5.10.5GET>>> B >>>>> http://cdni-ucdn.dcdn-1.example.com/video/ >>>> picture11.mp4HTTP/1.020097234724"Mozilla/5.0 >>>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>>> Gecko) Chrome/5.0.375.127 Safari >>>> /533.4""host5.example.com"0 >>>>=20 >>>> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >>>>=20 >>>> [Editor's Note: compute the correct Integrity-Hash value once >>>> example is frozen] >>>>=20 >>>> " >>>>=20 >>>> As illustrated in Figure 2, uCDN will then ingest the corresponding >>>> CDNI Logging Records into its Collection process, alongside the >>>> Logging Records generated locally by the uCDN itself. This allows >>>> uCDN to aggregate Logging Records for deliveries performed by itself >>>> (through Records generated locally) as well as for deliveries >>>> performed by its downstream CDN(s). This aggregate information can >>>> then be used (after Filtering and Rectification, as illustrated in >>>> Figure 2) by Log Consuming Applications considering deliveries >>>> performed by uCDN as well as by all its downstream CDN(s). >>>>=20 >>>> We observe that the time between >>>>=20 >>>> 1. when a delivery is completed in dCDN and >>>>=20 >>>> 2. when the corresponding Logging Record is ingested by the >>>> Collection process in uCDN >>>>=20 >>>> depends on a number of parameters such as the Logging Period agreed >>>> to by uCDN and dCDN, how much time uCDN waits after it is advertised >>>> in the CDNI Logging Feed before pulling the CDNI Logging File, and >>>> the time to complete the pull of the CDNI Logging File. Therefore, >>>> if we consider the set of Logging Records aggregated by the >>>> Collection process in uCDN in a given time interval, there could be >>>> a permanent significant timing difference between the CDNI Logging >>>> Records received from the dCDN and the Logging Records generated >>>> locally. For example, in a given time interval, the Collection >>>> process in uCDN may be aggregating Logging Records generated locally >>>> by uCDN for deliveries performed in the last hour and CDNI Logging >>>> Records generated in the dCDN for deliveries in the hour before last. >>>>=20 >>>> 3.6. Cascaded CDNI Logging Files Example >>>>=20 >>>> Let us consider the cascaded CDN scenario of uCDN, dCDN-2 and dCDN-3 >>>> as depicted in Figure 1. After completion of a delivery by dCDN-3 >>>> on behalf of dCDN-2, dCDN-3 will include a corresponding Logging >>>> Record in a CDNI Logging File and will advertise this CDNI Logging >>>> File to >>>> d-CDN2 in the corresponding CDNI Logging feed. As a result, dCDN-2 >>>> will initiate and complete the pull of the corresponding CDNI >>>> Logging File that is illustrated below: >>>>=20 >>>> " >>>>=20 >>>> #Version:CDNI/1.0 >>>>=20 >>>> #UUID:urn:uuid:65718ef-0123-9876-adce4321bcde >>>>=20 >>>> #Claimed-Origin:cdni-logging-entity.dcdn-3.example.com >>>>=20 >>>> #Record-Type:cdni_http_request_v1 >>>>=20 >>>> #Fields:datetimetime-takenc-ipcs- >>>> methodu-uriprotocolsc-statussc-total- >>>> bytescs(User-Agent)cs(Referer)s-cached >>>>=20 >>>> 2013-05-1700:39:09.14515.3210.5.10.5GET>>>>=20 >>>> http://cdni-dcdn-2.dcdn-3.example.com/video/movie118.mp4HTTP/ >>>> 1.120015799210"Mozilla/5.0 (Windows; U; Windows NT >>>> 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 >>>> Safari /533.4""host1.example.com"1 >>>>=20 >>>> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >>>>=20 >>>> [Editor's Note: compute the correct Integrity-Hash value once >>>> example is frozen] >>>>=20 >>>> " >>>>=20 >>>> dCDN-2 (behaving as an upstream CDN from the viewpoint of dCDN-3) >>>> will then ingest the CDNI Logging Record for the considered dCDN-3 >>>> delivery into its Collection process (as illustrated in Figure 2). >>>> This Logging Record may be aggregated with Logging Records generated >>>> locally by dCDN-2 for deliveries performed by dCDN-2 itself. Say, >>>> for illustration, that the content delivery performed by dCDN-3 on >>>> behalf of dCDN-2 had actually been redirected to dCDN-2 by uCDN, and >>>> say that another content delivery has just been redirected by uCDN >>>> to >>>> dCDN-2 and that dCDN-2 elected to perform the corresponding delivery >>>> itself. Then after Filtering and Rectification (as illustrated in >>>> Figure 2), dCDN-2 will include the two Logging Records corresponding >>>> respectively to the delivery performed by dCDN-3 and the delivery >>>> performed by dCDN-2, in the next CDNI Logging File that will be >>>> communcated to uCDN. An example of such CDNI Logging File is >>>> illustrated below: >>>>=20 >>>> #Version:CDNI/1.0 >>>>=20 >>>> #UUID:urn:uuid:1234567-8fedc-abab-0987654321ff >>>>=20 >>>> #Claimed-Origin:cdni-logging-entity.dcdn-2.example.com >>>>=20 >>>> #Record-Type:cdni_http_request_v1 >>>>=20 >>>> #Fields:datetimetime-takenc-ipcs- >>>> methodu-uriprotocolsc-statussc-total- >>>> bytescs(User-Agent)cs(Referer)s-cached >>>>=20 >>>> 2013-05-1700:39:09.14515.3210.5.10.5GET>>>> http://cdni-ucdn.dcdn-2.example.com/video/movie118.mp4HTTP/ >>>> 1.120015799210"Mozilla/5.0 (Windows; U; Windows NT >>>> 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 >>>> Safari /533.4""host1.example.com"1 >>>>=20 >>>> 2013-05-1701:42:53.43752.87910.5.10.5GET>>> B >>>>> http://cdni-ucdn.dcdn-2.example.com/video/picture11.mp4HTTP/ >>>> 1.020097234724"Mozilla/5.0 (Windows; U; Windows NT >>>> 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 >>>> Safari /533.4""host5.example.com"0 >>>>=20 >>>> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >>>>=20 >>>> [Editor's Note: compute the correct Integrity-Hash value once >>>> example is frozen] >>>>=20 >>>> " >>>>=20 >>>> In the example above, we observe that: >>>>=20 >>>> o the first Logging Record corresponds to the Logging Record >>>> communicated earlier to dCDN-2 by dCDN-3, which corresponds to a >>>> delivery redirected by uCDN to dCDN-2 and then redirected by >>>> dCDN-2 to dCDN-3. Its initial fields values are preserved, with >>>> the exception of the u-uri that now reflects the URI convention >>>> between uCDN and dCDN-2, and which presents the delivery to uCDN >>>> as if it was performed by dCDN-2 itself, which reflects the fact >>>> that dCDN-2 had taken the full responsibility of the corresponding >>>> delivery (even if in this case, dCDN-2 elected to redirect the >>>> delivery to dCDN-3 so it is actually performed by dCDN-3 on behalf >>>> of dCDN-2). >>>>=20 >>>> o the second Logging Record corresponds to a delivery redirected by >>>> uCDN to dCDN-2 and performed by dCDN-2 itself. The time of the >>>> delivery in this Logging Record may be significantly more recent >>>> than the first Logging Record since it was generated locally while >>>> the first Logging Record was generated by dCDN-3 and had to be >>>> advertised , and then pulled and then ingested into the dCDN-2 >>>> Collection process, before being aggregated with the second >>>> Logging Record. >>>>=20 >>>> " >>>>=20 >>>>=20 >>>> On 23 Apr 2014, at 20:29, Francois Le Faucheur (flefauch) wrote: >>>>=20 >>>>> Hello, >>>>>=20 >>>>> On 18 Apr 2014, at 23:42, ietfdbh wrote: >>>>>>>=20 >>>>>>> On 5 Apr 2014, at 23:14, ietfdbh wrote: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Most notably, the logging from a dCDN to a uCDN typically >>>>>>>> contains only >>>>>>> one >>>>>>>> dCDN identifier, such as Verified-origin, and doesn't really >>>>>>>> permit specifying a sub-ordinate dCDN. For example, in a cascade >>>>>>>> such as CDN-A >>>>>> - >>>>>>>>=20 >>>>>>>> CDN-B -> CDN-C, CDN-C will share logging info with CDN-B, but >>>>>>>> not with CDN-A; CDN-B shares logging info with CDN-A. This can >>>>>>>> be desirable for hiding the topology and delegation used by the >>>>>>>> dCDN. However, this >>>>>>> document >>>>>>>> does not discuss how the logging provided by CDN-C gets >>>>>>>> converted into >>>>>>> the >>>>>>>> logs for CDN-B that will be sent to CDN-A. Without some logging >>>>>>> information >>>>>>>> from CDN-C, it would seem difficult for CDN-A to utilize the >>>>>>>> information >>>>>> to >>>>>>>> meet requirements of billing, analytics, and fault and >>>>>>>> performance >>>>>> analysis. >>>>>>>> Maybe the logging gets aggregated and reported in CDN-B's >>>>>>>> logging, >>>>>>>=20 >>>>>>> Exactly. >>>>>>>=20 >>>>>>>> but that >>>>>>>> "transitive or aggregate logging" doesn't appear to be discussed >>>>>>>> in this document. >>>>>>>=20 >>>>>>> It is discussed in section 2.1 through Figure 1 and the following t= ext: >>>>>>> " >>>>>>> A dCDN (e.g., dCDN-2) integrates the relevant Logging information >>>>>>> obtained from its dCDNs (i.e., dCDN-3) in the Logging information >>>>>>> that it provides to the uCDN, so that the uCDN ultimately obtains >>>>>>> all Logging information relevant to a CSP for which it acts as >>>>>>> the authoritative CDN. >>>>>>> " >>>>>>> Does that address your concern? >>>>>>=20 >>>>>> No it does not mitigate my concern. >>>>>>=20 >>>>>> This says the information gets "integrated", but doesn't describe >>>>>> what integrated means. >>>>>> I could interpret that integration would be that the logging from >>>>>> CDN-C would be included in the logs from CDN-B to CDN-A, But I >>>>>> think the text says CDN-B will not share the logging entries from >>>>>> CDN-C with CDN-A. >>>>>> Do I have this wrong? Does CDN-B create a log file and generate >>>>>> entries, and then when it delegates delivery to CDN-C, and CDN-C >>>>>> passes its log file back to CDN-B, does CDN-B take the whole log >>>>>> file from CDN-B and insert it into its own log file, then continue >>>>>> adding any more entries, and then when done send the CDN-B log >>>>>> file (including a fully inserted CDN-C log file) to CDN-A? >>>>>>=20 >>>>>> If not, that presumably means that somehow, the data from CDN-C is >>>>>> "aggregated" - that's how it is "integrated", >>>>>=20 >>>>> Right. It is aggregated. >>>>> Effectively, if CDN-B has sub-delegated a delivery to CDN-C, then whe= n CDN-C provides a log record for that delivery to CDN-B, CDN-B will aggreg= ate that log record with the log records for the deliveries that CDN-B cond= uted itself. When CDN-B provides log records to CDN-A, the log record corre= sponding to the delivery performed by CDN-C is turned by CDN-B into a log r= ecord that looks like the delivery was done by CDN-B. CDN-A will not be awa= re that the delivery was performed by another CDN than CDN-B (just like the= Content Provider is not ware that the delivery was not performed by CDN-A = with whom it has a delivery contract). >>>>>=20 >>>>>> But there is no discussion of how this aggregation is done. >>>>>=20 >>>>> That is true. I think it has been assumed by many but never made clea= r. So we need to add some discussion about that. >>>>>=20 >>>>>> I think your intent is to hide the fact that CDN-B used CDN-C, >>>>>> since that may reflect a proprietary approach of CDN-B's business m= odel. >>>>>=20 >>>>> Right. >>>>>=20 >>>>>> But CDN-A would presumably have problems performing analytics, and >>>>>> fault and performance analysis, if the data from CDN-C is not >>>>>> included in CDN-B's logging to CDN-A. >>>>>> So I would like an example to demonstrate what CDN-A would see in >>>>>> CDN-B's logs if CDN-C had faults or performance problems, and I >>>>>> would like to see how CDN-A could perform analytics (of any kind) >>>>>> relating to the delivery performed by CDN-C. >>>>>=20 >>>>> The assumption is that CDN-A is only dealing with CDN-B. CDN-A may no= t not even be aware of CDN-C. >>>>> So CDN-A analaytics/monitoring will establish whether all the deliver= ies delegated to CDN-B (comprising deliveries performed by CDN-B as well as= deliveries redirected by CDN-B to CDN-C and possibly CDN-C2) have received= the right quality (ie if CDN-B has met the SLA committed to CDN-A). >>>>> If some deliveries have experienced quality problems, CDN-A will blam= e CDN-B. It is up to CDN-B to then do its own analytics and monitoring to d= ecide whether the problem lies within his own CDN or CDN-C or CDN-C2. >>>>> The whole thing operates as a chain of delegations, like many other b= usiness arrangements: if my SmartPhone does not work, I blame the smartPhon= e vendor (I don't try identify if the problem is coming from the supplier o= f the GSM chipset, but the SmartPhone vendor will). >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> I am missing how this would be done (especially in a standardized ma= nner). >>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>> I think Verified-Origin is particularly problematic, because the >>>>>>>> text >>>>>> states >>>>>>>> that this can only be added by the uCDN, never the dCDN. So what >>>>>>>> if >>>>>> CDN-B >>>>>>>> verifies the origin of the logs from CDN-C and then passes the >>>>>> information >>>>>>>> (now as a dCDN) to CDN-A? The text mentions that this might be >>>>>>> established >>>>>>>> using authentication mechanisms; so do we lose this logged >>>>>>>> authentication/verification when cascading? >>>>>>>>=20 >>>>>>>> (Maybe this is resolved by having the uCDN (CDN-B) record a >>>>>> "transaction" >>>>>>>> that starts when it delegates a task to a dCDN (e.g. CDN-C) and >>>>>>>> ends >>>>>> when >>>>>>>> the dCDN completes the task, and the uCDN just records the whole >>>>>>> transaction >>>>>>>> without the details that are reported by CDN-C. Then CDN-B logs >>>>>>>> only the whole transaction. I would like to see an explicit >>>>>>>> example of such >>>>>> logging, >>>>>>>> using the cdni_http_request_v1 record-type, so this is clear.) >>>>>>>=20 >>>>>>> Yes, that is pretty much the idea. >>>>>>> ie. if CDN-a delegate sto CDN-B then CDB-B is responsible for >>>>>>> delivering >>>>>> and >>>>>>> will provide a delivery record to CDN-A for that delivery. That >>>>>>> record >>>>>> will be >>>>>>> part of a Logging File whose origin in CDN-B, and CDN-A can use >>>>>>> authentication mechanism to ensure the Logging File is provided by = CDN-B. >>>>>>> All of this completely holds whether CDN-B performed the delivery >>>>>>> itself (and created the delivery record in the first place) or >>>>>>> CDN-B delegated to CDN-C who provided the delivery record to >>>>>>> CDN-B in a Logging File whose origin was CDN-C. >>>>>>>=20 >>>>>>> This question has come up before so I will add a clarification >>>>>>> along the >>>>>> lines >>>>>>> above under the description of the Verified Origin in case of >>>>>>> cascaded >>>>>> CDNs. >>>>>>=20 >>>>>> An example of such integrated cascaded logging might answer many que= stions. >>>>>=20 >>>>> Good idea. >>>>> It sounds worthwhile to give a descripton of how log records get aggr= egated in a csacaded scenario, indicate how directives/fields get modified/= kept at each CDN hop, and possibly include an example with some log records= and how they propagate from CDN-C to CDN-B to CDN-A. >>>>>=20 >>>>>> If logging records from CDN-C get copied into the log from CDN-B, >>>>>> are all directives and record types copied? >>>>>> If so, I think it is important to make clear that a given log >>>>>> might contain multiple nested logs, And that means that the file >>>>>> received by CDN-A might start with directives for CDN-B plus >>>>>> records, And then directives for CDN-C, ending with an >>>>>> Integrity-Hash, and more records for CDN-B followed by an >>>>>> Integrity-Hash. >>>>>> Maybe this is all as designed, but I haven't seen discussion of >>>>>> that, and it is not reflected in Figure 3, and this is not >>>>>> discussed in the description of fields that are file-specific, >>>>>> such as Integrity-hash, Verfiied-origin, Version, UUID, etc. >>>>>> If you have nested logs, then log-consuming applications need to >>>>>> know that those file-specific directives un-nest at the end of the >>>>>> included file. Can they tell consistently when they hit the end of t= he included file? >>>>>> Should there be an end-of-log marker for the included log? >>>>>>=20 >>>>>> The Integrity-Hash directive is allowed to occur zero or once, not >>>>>> multiple times in a logfile. >>>>>> So if the CDN-C logfile contains an Integrity-Hash, should that be >>>>>> checked by CDN-B, then copy the CDN-C logfile into the CDN-B >>>>>> logfile, but discard the CDN-C Integrity-Hash, because CDN-B will >>>>>> calculate its own Integrity-Hash directive? >>>>>=20 >>>>> Yes. >>>>>=20 >>>>>>=20 >>>>>>> Let me know if that is not sufficient. >>>>>>=20 >>>>>> I remain concerned that cascaded logging may not have been >>>>>> adequately described and standardized. >>>>>=20 >>>>> Right. I see that the questions you raised were not answered in the d= ocument. We will work on addressing them. >>>>>=20 >>>>> Thanks >>>>>=20 >>>>> Francois >>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Francois >>>>>>=20 >>>>>> dbh >>>>>>=20 >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> 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 >=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 nobody Fri Jul 4 05:59:15 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F058C1B28F3; Fri, 4 Jul 2014 05:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhfBW5D-1Ids; Fri, 4 Jul 2014 05:59:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B171B28F2; Fri, 4 Jul 2014 05:59:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704125908.11081.85314.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 05:59:08 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/ZuBPyzmV_dH9Z-j4JNbncRbvA6M Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-logging-12.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 12:59:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Content Delivery Networks Interconnection Working Group of the IETF. Title : CDNI Logging Interface Authors : Francois Le Faucheur Gilles Bertrand Iuniana Oprescu Roy Peterkofsky Filename : draft-ietf-cdni-logging-12.txt Pages : 51 Date : 2014-07-04 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-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-logging-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 4 06:02:11 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7564F1B2913 for ; Fri, 4 Jul 2014 06:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ly0m2ECW6aQ4 for ; Fri, 4 Jul 2014 06:02:06 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 292EE1B28E6 for ; Fri, 4 Jul 2014 06:02:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2128; q=dns/txt; s=iport; t=1404478926; x=1405688526; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=HEBnkeorvzjy3sls+d9x2zOBD6vfwVIwZ96jLW4Rq1w=; b=m2d8Ue85tjQtAy0d/VhZZdSyaqbwGOZkYJaMJnXZlXzOCM0z0oFDDd5r xmXIbA9x0J/Mpp/OOOcTMFPogQvLfPL7qfysMmqgbYYZGHr1L/msCu6AV 0GzFQSRY6OlxEv0LiQzuqwDlve2W7N/GVCXIKYjr8jv1RGYoDdcd9gN8L c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An4KACaltlOtJA2I/2dsb2JhbABagw5SUwe+aoc/AYENFnWEAwEBAQMBAQEBNzQLEAIBCDYQJwslAgQOBQmIMQgIBcosF45vMwIFgy2BFgWadoFIjDOGEYNDbIFE X-IronPort-AV: E=Sophos;i="5.01,601,1400025600"; d="scan'208";a="58342942" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-2.cisco.com with ESMTP; 04 Jul 2014 13:02:05 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s64D256f026199 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Jul 2014 13:02:05 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Fri, 4 Jul 2014 08:02:05 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: I-D Action: draft-ietf-cdni-logging-12.txt Thread-Index: AQHPl4fHMjwWc+pTPkqkmaL8YpbAdpuQNQ6A Date: Fri, 4 Jul 2014 13:02:04 +0000 Message-ID: References: <20140704125908.11081.85314.idtracker@ietfa.amsl.com> In-Reply-To: <20140704125908.11081.85314.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.200] Content-Type: text/plain; charset="us-ascii" Content-ID: <376810A07D6F2F41BD47A3A7CFAA239E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/iOnAtvNVT0sMnGZeHy0lgrATUzQ Cc: "Benoit Claise \(bclaise\)" , ietfdbh , "spencer@wonderhamster.org" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-logging-12.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 13:02:08 -0000 Folks, (as a document editor) This version addresses the comments from teh early Ops-Dir review, in line = with the resolutions discussed on the WG list . Cheers Francois On 4 Jul 2014, at 14:59, 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 > Authors : Francois Le Faucheur > Gilles Bertrand > Iuniana Oprescu > Roy Peterkofsky > Filename : draft-ietf-cdni-logging-12.txt > Pages : 51 > Date : 2014-07-04 >=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-12 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-12 >=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 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Fri Jul 4 08:42:09 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A965B1B2DC4 for ; Fri, 4 Jul 2014 08:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qpB-sBHf0XP for ; Fri, 4 Jul 2014 08:41:54 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 834E61B2ADA for ; Fri, 4 Jul 2014 08:41:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19755; q=dns/txt; s=iport; t=1404488514; x=1405698114; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=QrSOZxCkty3sFO1ZxEhKeTQNKhlH7fJKKduHBswr0Sk=; b=iD3qp6UtyWqj0jBos+x78GBfi9POoIs7T1WkdTV3x5bIGq/wo8ELI8K4 5T5Sa5ldhMgGh4e43An5qU2WeTuuBW+Yui+j467DtXefg2w6ErziRlgLJ IYVH/Qf/rTGB+QZNruJAv4Hs7k6B3Jy2B0a25scN1VKhUsaa/r1VVrGkF Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAOnJtlOtJV2c/2dsb2JhbABagw5SWr5qhz8BgQsWdYQDAQEBAwEBAQEkRwICAQYFCwIBFgouJwslAgQOBYg6CA3KSReOPhBUB4RDBZZchBqBSIUOjTaDQ2yBAgICHAYc X-IronPort-AV: E=Sophos;i="5.01,601,1400025600"; d="scan'208";a="58316797" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-1.cisco.com with ESMTP; 04 Jul 2014 15:41:53 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s64FfrWi013608 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Jul 2014 15:41:53 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Fri, 4 Jul 2014 10:41:52 -0500 From: "Francois Le Faucheur (flefauch)" To: Rob Murray Thread-Topic: Comments on draft-ietf-cdni-control-triggers-03 Thread-Index: AQHPl556OSXWoJxs1U+ZNsiOfgq5Ug== Date: Fri, 4 Jul 2014 15:41:52 +0000 Message-ID: References: <49C77373835C5A479BC2A84B2A1D66BDDA2D41E3@EXB01-MLT.corp.velocix.com> In-Reply-To: <49C77373835C5A479BC2A84B2A1D66BDDA2D41E3@EXB01-MLT.corp.velocix.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.200] Content-Type: text/plain; charset="Windows-1252" Content-ID: <61F33FE56D5DB04CB6E4CB6961949E96@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/ZyT7j00-wAervlZ9fjr1YeynkL4 Cc: "cdni@ietf.org" Subject: [CDNi] Comments on draft-ietf-cdni-control-triggers-03 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 15:41:58 -0000 Hi Rob, I read the new version till end of section 4. Below are some comments. Cheers Francois *** in section 1:=20 * remove the reproduction of actual requirements (for consistency with ot= her documents). * reader of the present document may not be familiar with meaning of =93Me= dium=94 and =93High=94, so I=92d suggest: OLD: " Requirements for CI/T are the "High" and "Medium" priority requirements for the CI identified in = section 4 of [I-D.ietf-cdni-requirements],, reproduced here for convenience= : CI-1 [HIGH] The CDNI Control interface shall allow the Upstream ... =20 " NEW: " Section 4 of [I-D.ietf-cdni-requirements] identifies the requirements speci= fic to the CI interface. The subset of these requirements applicable to the= CI/T interafce are CI-1 to CI-6. " *** Section 2: "Requests to invalidate and purge metadata or content apply to all variants of that data with a given URI.=94 What do you mean by =93variants=94 here? *** RFC2119 statements: I think you need to walk through the doc and ensures there are MUST/SHOULD/= MAY for all necessary element of behaviour. For example, I see: * "To trigger activity in the dCDN, the uCDN will POST to the collection o= f Trigger Status Resources.=94 and * "To trigger activity in the dCDN, the uCDN creates a new Trigger Status = Resource by posting to the dCDN's collection of uCDN's Trigger Status Resou= rces.=94 but I don=92t see any =93MUST POST=94. Can you plan a review and make sure you add MUST/SHOULD/MAY wherever it is = needed? As another example, section 2 primarily uses descriptive text (=93dCDN does= this=94, "it will do that=94) but has a few RFC2119 statements ("uCDN MAY = GET=94. "uCDN MAY DELETE=94). Sincxe section 2 is an overview, I woudl sugg= est using only descriptive text and makingh sure all RFC2119 statements are= moved to the more detailed sections. *** section 2.1: s/Timing of triggered activity is under the dCDN's control/Timing of the ex= ecution of the triggered activity is under the dCDN's control/ *** section 2.1: "Invalidate and purge triggers MUST be applied to all data acquired before the trigger was created in the dCDN. The dCDN may apply the triggers to data acquired after trigger creation.=94 why do we have a =93MUST=94 and then a =93may=94 (instead of a =93MAY=94)? This seems like another example of a needed RFC2119 cleanup. *** section 2.1: s/Otherwise, the dCDN may pre-position/Otherwise, there is a risk that the = dCDN pre-positions/ *** section 3: =93 o Complete - Trigger Status Resources representing activity that completed successfully, or for which no further status updates will be made by the dCDN. =93 I think "for which no further status updates will be made by the dCDN=94 me= ans that is in the =93processed=94 status defined in section 4, right? If yes, it may be worth mentioning the word =93processed=94 here to help re= conciliate this list of collection with the various status defined in secti= on 4. e.g.: =93 o Complete - Trigger Status Resources representing activity that completed successfully, or for which no further status updates will be made by the dCDN (.i.e that is already processed). " *** section 4: "The interface is intended to be independent of the set of activities defined now, or that may be defined in future.=94 I had to re-read this a couple of times to understand what you meant. I thi= nk it can be phrased better, perhaps indicating it is independent of the = =93types of triggers=94 (as opposed to "set of activities) and replacing = =93now=94 by =93specified in the present document=94.=20 *** section 4: the terms =93client=94 and =93server=94 are used out of teh blue and need t= o be related to uCDN and dCDN. Perhaps you could do something similar to wh= at we did in cdni-logging i.e. we specified teh =93Server-side=94 and =93cl= ient-side=94 behavior and stated that a dCDN implementation of the interfac= e MUST support the server-side and an uCDN implementation of the interface= MUST support the client-side and an uCDN.=20 *** section 4: =93Since only one CDN can be authoritative for a given item of metadata or content, this requirement means there cannot be any "loops" in trigger requests between CDNs." This may deserve some more explanations. When you say =93there cannot be=94 does it mean =93it will not happen becau= se it is prevented by the law of physics so you don=92t have to worry about= it=94? or does it mean =93you need to make sure it does not happen=94?=20 *** section 4.1: "if it is malformed or the uCDN does not have sufficient access rights it MAY reject the request immediately.=94 shoudl this be just a =93MAY=94? what else can it do with a malformed reque= st? *** section 4.1: s/If the dCDN is not able to track triggered activity/If the dCDN is not ab= le to track the execution of triggered activity/ *** section 4.1: s/If the dCDN is able to track triggered activity/If the dCDN is able to tr= ack the execution of triggered activity/ *** section 4.2: s/described in the following sections/described in section 4.2.1 and 4.2.2/ *** section 4.3: "If an "active" Trigger Status Resource is deleted, the dCDN MAY stop processing the triggered activity. =93 MAY or SHOULD? *** section 4.3: OLD: =93 it is recommended that the uCDN's polling interval is half the time after which records for completed activity will be considered stale. =93 NEW: =93 the uCDN SHOULD set its polling interval to a value that is at most half the time after which records for completed activity will be considered stale. =93 *** Section 4.5: =93 If a surrogate affected by a trigger is offline in the dCDN, or the dCDN is unable to pass a trigger request on to any of its cascaded dCDNs; the dCDN SHOULD report an error if the request is abandoned. Otherwise, it SHOULD keep the trigger in state "pending" or "active" until it's acted upon or the uCDN chooses to cancel it. =93 It is not obvious if =93Otherwise=94 refers to =93if a surrogate=85=94 or = =93if the request is abandoned=94. I think it is teh latter. In which case,= you may want to structure the text with bullets like: =93 If a surrogate affected by a trigger is offline in the dCDN, or the dCDN is unable to pass a trigger request on to any of its cascaded dCDNs: * if the request is abandoned by the dCDN, the dCDN SHOULD report an erro= r * Otherwise, it SHOULD keep the trigger in state "pending" or "active" until it's acted upon or the uCDN chooses to cancel it. " =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Editorial Nits: *** Abstract: s/CDN Interconnect/CDN Interconnection/ s/re-validate or purge/re-validates or purges/ *** section 1: s/Problem scope/problem scope/ *** section 2: s/a request for dCDN/a request for the dCDN/ *** Sometimes you use =93the uCDN=94 and sometimes =93uCDN=94 (e.g. ", uCDN= has access=94). I suggest always using =93the uCDN=94.=20 *** I thought the aprostrophe for the possessive case only applied to human= s and not things, so that one should say =93dCDN control=94 and not =93dCDN= =92s control=94.=20 *** section 4.1: s/it MUST indicate that indicate/it MUST indicate/ On 3 Jul 2014, at 20:38, Rob Murray wrote: > Hi all, >=20 > Kevin, thank you for the review. All very good comments, sorry it took me= so long to get to them. >=20 > Responses inline below, and I've posted an "03" version of the draft... >=20 > http://datatracker.ietf.org/doc/draft-ietf-cdni-control-triggers/ > http://tools.ietf.org/html/draft-ietf-cdni-control-triggers-03 (eventua= lly) >=20 > Most comments have been addressed, including a couple of earlier ones fro= m Francois about broken formatting. >=20 > What I've not dealt with is the idea to separate trigger deletion and can= cellation - in order to make it possible to check the status of a deleted t= rigger. It'd make the interface a little more complicated, and I'm not sure= what status the dCDN could usefully report. (Also, I ran out of time for m= aking edits!) Let's discuss further in Toronto. >=20 > Cheers, > Rob. >=20 > On 6 May 2014, at 23:15, Kevin Ma J wrote: >=20 >> Hi All, >>=20 >> Per the chairs' request for a detailed review of the triggers draft, >> I've compiled a list of comments below. >>=20 >> thanx. >>=20 >> -- Kevin J. Ma >>=20 >> comments: >>=20 >> - General: imo, an article in front of uCDN/dCDN (i.e., the uCDN/dCDN) >> makes for easier reading. >=20 > Done. >=20 >> - General: There are quite a few lower case "must"s (17), "shall"s (14), >> "should"s (7), and "may"s (36) in the document. Are they all >> intentionally non-normative?=20 >=20 > Hopefully sorted now, though I MAY have gone too far! >=20 >> - section 2: Should cancelling a trigger and removing a trigger status >> be separated in some way? Using DELETE for both means >> that if I wanted to cancel a trigger, I would have no way >> to get status on the cancelled trigger, since the status >> resource would be removed at the same time, and delete >> does not return a status, per the example in section 7.2.5 >=20 > See above, it could be a good idea but it'd be good to talk it through a = bit further (sorry I left this update too late to do it on the list before = the deadline). >=20 >> - section 2/4.1: In step 2 of figure 1, it mentions authentication as >> does section 4.1, but section 7 and 9 provide no >> guidance on either the authentication mechanism or >> what precisely is being authenticated. Presumably we >> are authenticating that it is a known uCDN making the >> request for metadata/content that is known to be owned >> by that uCDN? Should we state that? >>=20 >> Do we have a suggestion (e.g., SSL client auth, HTTP >> basic/digest auth, etc.) for authentication method? >=20 > I've rewritten the Security Considerations section now (based on what's i= n the Logging draft, as agreed in London). >=20 >> - section 2.1: I found the wording of this sentance a little confusing. >>=20 >> "If uCDN wishes to invalidate or purge content, then immediately >> preposition replacement content at the same URLs, it must ensure the >> dCDN has completed the invalidate/purge before initiating the >> prepositioning. If it fails to do that and the requests overlap, and >> dCDN passes the triggers on to a further dCDN in a cascade, that CDN >> may preposition content that has not yet been invalidated/purged in >> its uCDN." >>=20 >> Perhaps something like: >>=20 >> "If uCDN wishes to invalidate or purge content, then immediately >> preposition replacement content at the same URLs, it must ensure the >> dCDN and all cascaded dCDNs have completed the invalidate/purge >> before initiating the prepositioning, otherwise, a cascaded dCDN may >> attempt to preposition content that has not yet been invalidated/purg= ed >> in its uCDN." >=20 > Done. >=20 >>=20 >> - section 3: I would break this into two sentances: >>=20 >> "The dCDN must present a different set of Trigger Status Resources to >> each interconnected uCDN, only Trigger Status Resources belonging to >> a uCDN shall be visible to it." >>=20 >> i.e.: >>=20 >> "The dCDN must present a different set of Trigger Status Resources to >> each interconnected uCDN. Only Trigger Status Resources belonging to >> a uCDN shall be visible to it." >=20 > Done (and reworded a bit). >=20 >> - section 3: This is the first mention of expiry. Perhaps a reference >> to Section 4.4? >>=20 >> "This collection lists all >> uCDN triggers that have been accepted by dCDN, and have not yet been >> deleted by uCDN or expired and removed by dCDN." >=20 > Done. >=20 >> - section 4.1: These are the first mention of etime and mtime, perhaps >> there should be a reference to Section 5.2, or some >> type of explaination on what etime > mtime means. >>=20 >> I am not sure about using of etime > mtime as an indicator. >> If mtime < now and etime < now, but still etime > mtime, >> it would seem to imply that the activity may be complete, >> but I don't think that is the intent? >>=20 >> Should there be some normative language stating that if >> etime > mtime, the uCDN must update the status, and the >> dCDN must update mtime =3D now and etime > mtime? >>=20 >> "If dCDN is not able to track triggered activity, it MAY indicate that >> it has undertaken to complete the activity but will not report >> completion or any further errors. To do this, it must set the >> trigger status to "complete", with an estimated completion time in >> the future ("etime" greater than "mtime")." >=20 > I got rid of that and added an extra state, "processed" - it's like "comp= lete", but means the dCDN can't provide a success/fail result. (With a reco= mmendation that an estimated completion time should be provided in that cas= e.) >=20 >> - section 4.4: Why 24 hours? Seems fast? >>=20 >> "It >> is recommended that Trigger Status Resources are automatically >> deleted 24 hours after they become completed or failed." >=20 > I made it "not less than 24 hours". >=20 >> - section 4.4: comma after: >>=20 >> "If any part of the trigger request fails, " >>=20 >> comma before: >>=20 >> ", if the trigger is still running for some URLs >> or Patterns in the trigger request." >>=20 >> perhaps clarify "cascaded" dCDNs: >>=20 >> "pass a trigger request on to any of its affected cascaded dCDNs" >=20 > Done. >=20 >> - section 5.2: AbsoluteTime is a Unix Epoch, so should be UTC. >> I found the phrase "Time is local to dCDN" confusing as >> I first assumed "local" was referencing timezone, but I >> think "local" is just related to unsynchronized clocks? >> Perhaps: "Time is determined by the dCDN"? >=20 > Done. >=20 >> - section 5.4: links is a "List of Relationships". Why not just URLs? >> If the trigger collection can only reference trigger >> statuses, then why does it need typed relationships? >> The use of a relationship here seems overly complex? >>=20 >> Is relationship standard JSON terminology? Should there >> be a reference to the acknowledged work of Mike Kelly? >=20 > Yes, you're right. It had all got too complicated and bloated. So it's ju= st a list of URLs now, I got rid of all that JSON relationship stuff. >=20 >> - section 6: There is a note about MI dependency. >> Is it just for PatternMatch? >=20 > It was, but the dependency wasn't necessary so I've got rid of it. >=20 >> - section 6.1.6: "ralationship" -> "relationship" >=20 > Fixed. >=20 >> - section 6.1.6/6.1.7: I think it would be helpful to define the >> Relationship and Link objects the same way as >> all the other JSON objects, e.g.: >>=20 >> How are the keys in the _links dictionary >> determined? And how is their meaning known? >> The key "self" seems to have a specific meaning? >> It is essentially a reserved keyword? Are there >> other reserved keywords (e.g., "Trigger"), and >> do they have to be registered somewhere? >>=20 >> Relationship: >> Key: _links >> Description: List of related objects? >> Type: Array of LinkUnions >> Mandatory: Yes >>=20 >> LinkUnion: >> Key: ??? >> Description: List of related objects? >> Type: Array of LinkUnions >> Mandatory: No. >>=20 >> Key: ??? >> Description: related objects? >> Type: Link >> Mandatory: No. >>=20 >> Link: >> Key: href >> Description: URI of the addressable object being referenced >> Type: URL >> Mandatory: Yes >>=20 >> Key: type >> Description: Type of the referenced object >> Type: MIME Media Type >> Mandatory: No >=20 > I did that - then decided to get rid of it all, as above. It was only use= d in the collections, and they're now just lists of links. >=20 >> - section 7: There are no examples with "base" or "links". I have an >> idea of how "base" might be used, but I don't know what >> the purpoes of "links" is. Can we add an example? >>=20 >> "URLs are under control" -> "URLs are under the control" >=20 > "links" has gone. >=20 >> - section 7.2.1/7.2.2: I don't know where the key "Trigger" came from? >> Is it derived from some known object, or is it >> randomly selected (and somehow registered)? >=20 > In the "01" draft it was the "relationship type", and I'd not documented = the change properly. But it's gone now, just a list of URLs. >=20 >> - section 7.2.5: Would there be value in returning the status on delete? >=20 > Probably a good idea. Let's wrap it up with discussion on the delete/canc= el question. >=20 >> - section 9: In the first sentance below, I interpret "access" as the >> ability to read (GET) a status object or collection. It >> does not necessarily imply to me who can issue a new >> trigger request? In the second sentance, it says it can >> only "affect" it's own content, which I guess implies >> that only it can affect it's own content, as another uCDN >> affecting it's content would violate this rule? Should >> we make that more explicit? >>=20 >> "The dCDN must ensure that each uCDN only has access to its own >> Trigger Status Resources." >>=20 >> "The dCDN must ensure that activity triggered by uCDN only affects >> metadata or content originating from that uCDN." >>=20 >> e.g., update the second sentance to something like: >>=20 >> "The dCDN must ensure that activity triggered by uCDN only affects >> metadata or content originating from that uCDN, and that no other >> uCDN may trigger activity that affects another uCDN's metadata or >> content." >=20 > Hopefully the re-written section 9 is clearer. >=20 >> - random: The mention of only affecting a uCDN's own content made me >> think of the DNS diamond scenario. Do we believe that the >> Content URLs described in section 5.1.1 are sufficient to >> ensure this, or is there a caveat for the diamond case? >>=20 >> "The dCDN must ensure that activity triggered by uCDN only affects >> metadata or content originating from that uCDN." >=20 > Done. >=20 >>=20 >> _______________________________________________ >> 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 From nobody Fri Jul 4 18:23:57 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E131A00FE for ; Fri, 4 Jul 2014 18:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.585 X-Spam-Level: ** X-Spam-Status: No, score=2.585 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_BACKHAIR_37=1, J_BACKHAIR_44=1, J_BACKHAIR_52=1, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEP7FWCBF9q7 for ; Fri, 4 Jul 2014 18:23:49 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 924691A0011 for ; Fri, 4 Jul 2014 18:23:49 -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 s651Nh7U011194; Fri, 4 Jul 2014 19:23:43 -0600 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Fri, 04 Jul 2014 19:23:43 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([::1]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.03.0174.001; Fri, 4 Jul 2014 19:23:43 -0600 From: Daryl Malas To: "Francois Le Faucheur (flefauch)" , "iuniana.oprescu@orange.com" Thread-Topic: [CDNi] Utility of Verified-Origin & Claimed-Origin in CDNI logging Thread-Index: AQHPl+/BWqy3mSYZ40CopqPVOwVTqA== Date: Sat, 5 Jul 2014 01:23:42 +0000 Message-ID: References: <038401cf5b4f$0b5ea610$221bf230$@comcast.net> <05BD7B6B-6886-4277-8A8A-8AE77363939B@cisco.com> <315A2A4B-C876-4FF7-A836-7D48AC191195@cisco.com> <5295_1404462309_53B664E5_5295_3874_1_8F0D2F5E4AAB7249BC7339A3E944DEDD228BFE2202@PMEXCB1D.intranet-paris.francetelecom.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.5.0.27] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1F5A848A353E47448D2B5F626C4435F1@cablelabs.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/0skaV3kV3CA5OlDNs8frqm_U40A Cc: "cdni@ietf.org" Subject: Re: [CDNi] Utility of Verified-Origin & Claimed-Origin in CDNI logging X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 05 Jul 2014 01:23:54 -0000 On 7/4/14, 5:54 PM, "Francois Le Faucheur (flefauch)" wrote: > >On 4 Jul 2014, at 10:25, > wrote: > >> Hello all, >>=20 >> I was thinking yesterday that these directives come from >>non-repudiation times. > >I don=B9t think so. In any case, I think we can agree that they do not >bring any value in terms of non-repudiation. > >> Also, I was wondering what are the implications of making >>Validated-Origin transitory in the scenario described by Ben. In the >>case of a visible relationship between tCDN and dCDN, maybe uCDN wants >>to know that tCDN provides some guarantee with respect to the lower part >>of the logging chain (here, the dCDN). > >I don=B9t think Ben was proposing to make the Validated Origin transitory. >I don=B9t think we should. Our model is that tCDN takes the full >responsibility of deliveries (and associated operations such as providing >corresponding logs) vis a vis of uCDN. uCDN does not care how the logs >were generated and by who (eg tCDN or a downstream CDN of tCDN) and tCDN >does not want to expose whether it uses further downstream CDNs or not; >uCDN only cares that the logs provided by tCDN are accurate and that tCDN >ensured the corresponding deliveries were performed as per agreed SLA >between uCDN and tCDN. [DM] I agree with this. At least in the US, tCDNs will nearly always indicate they are the only dCDN to the uCDN. The important thing is to ensure they provide an accurate/verified log to the uCDN. I would also lean towards the fact tCDNs are not a realistic definition in US applications of CDNi. In practice, they may happen; however, it will be unknown to the uCDN. > >>=20 >> Do you think it could be useful? > >Nope. > >Francois > >> -- iuniana >>=20 >> -----Message d'origine----- >> De : CDNi [mailto:cdni-bounces@ietf.org] De la part de Francois Le >>Faucheur (flefauch) >> Envoy=E9 : vendredi 4 juillet 2014 10:18 >> =C0 : Niven-Jenkins Ben >> Cc : cdni@ietf.org >> Objet : Re: [CDNi] Utility of Verified-Origin & Claimed-Origin in CDNI >>logging >>=20 >> Hi Ben, >>=20 >> On 3 Jul 2014, at 19:39, Ben Niven-Jenkins >>wrote: >>=20 >>> Francois, Colleagues, >>>=20 >>> Reading your suggested text below made me ponder on the purpose and >>>utility of the Claimed-Origin and Verified-Origin field directives. >>>=20 >>> Let's start with Verified-Origin. From your text below and reading the >>>definition of Verified-Origin in section 3.3 of >>>draft-ietf-cdni-logging-11 I understand that a dCDN MUST NOT place a >>>Verified-Origin field directive in a log file it sends to a uCDN (it is >>>the uCDN's job to do that if it wants to once it has verified the >>>origin). Furthermore in a cascaded scenario (uCDN-tCDN-dCDN) the >>>transit CDN MUST NOT include a Verified-Origin field directive in a log >>>file it sends to uCDN and by implication if tCDN inserted a >>>Verified-Origin directive when receiving from dCDN, it must strip it >>>before sending that log file on to uCDN. >>=20 >> Yes. >>=20 >>>=20 >>> Therefore use of Verified-Origin is purely internal to a given CDN, is >>>never exchanged between CDNs and has no role to play in interoperation >>>of CDNI between CDNs, so why does the logging draft need to specify it >>>at all? >>=20 >> That's a good question. >>=20 >> I think the train of thought that got us there is the following : >> * when storing the CDNI Logging File, the uCDN would want to >>have an easy way to identify where the CDNI Logging File is coming from >> * since the dCDN knows who he is, it is trivial for it to >>include its identification in a field inside the file >> * the uCDN may be happy with that, in which case it does not >>have to do anything; >> * or the uCDN may want to record the identification it >>establishes, in which case it has to add the corresponding field itself. >> That's more or less how we got there. >>=20 >> My personal take would be: >> *A* if we expect that uCDNs would typically want to have an >>explicit record inside the CDNI Logging File of the dCDN that originated >>the file , then we should define directive(s) to do that. This will make >>things more consistent for processing tools/utilities operating over >>CDNI Logs. And in the case where the uCDN is happy with the origin as >>stated by dCDN (say because the dCDN is operated by the same >>administrative entity), it will save any file manipulation by the uCDN. >> *B* if we expect that uCDNs would typically NOT want to have an >>explicit record inside the CDNI Logging File of the dCDN that originated >>the file (say because they want to encode that information inside the >>filename), then there may not be much value in defining the directives. >>=20 >> I personally lean towards *A*, but let's hear more opnions or arguments. >>=20 >> Cheers >>=20 >> Francois >>=20 >>=20 >>> CDNs that want the functionality of Verified-Origin can do whatever >>>they want internally to implement that, it doesn't seem we need >>>something in the RFC to support the internal behaviour of a CDN. >>>=20 >>>=20 >>> That then got me thinking about Claimed-Origin. If I read the text >>>below correctly, my understanding is that the value of Claimed-Origin >>>should be the same hostname in the dCDN that the uCDN connects to in >>>order to retrieve log files. So for example a uCDN could compare the >>>value of Claimed-Origin against the values of subjectAltName in the TLS >>>certificate presented by the dCDN and if there is a match then the >>>Claimed-Origin can be "verified". >>>=20 >>> I'm struggling to see what value Claimed-Origin gives in practice, >>>possibly because I don't understand the use case for it. If the >>>purpose is to let a uCDN do the comparison I describe above then I'm >>>not sure that gives us much in reality. Claimed-Origin becomes >>>essentially a hop-by-hop (CDN-by-CDN) property and assuming the dCDN >>>identifies itself correctly (e.g. hostname in dCDN that uCDN connected >>>to matches hostname(s) in TLS certificate presented by dCDN) >>>Claimed-Origin is adding nothing, or have I misunderstood? >>>=20 >>> Thanks >>> Ben >>>=20 >>> On 2 Jul 2014, at 15:39, Francois Le Faucheur (flefauch) >>> wrote: >>>=20 >>>>=20 >>>> On 1 Jul 2014, at 20:09, Francois Le Faucheur (flefauch) >>>> wrote: >>>>=20 >>>>> Folks, >>>>>=20 >>>>> (as a document editor) >>>>>=20 >>>>> To address the point around cascaded CDNs that was raised by David >>>>>Harrington as part of his early Ops Review, I have: >>>>> * expanded section 3.5 "CDNI Logging File Example" >>>>> * added a section 3.6 "Cascaded CDNI Logging Files Example" >>>>>=20 >>>>> Draft text is below. I'd appreciate some reviews. >>>>=20 >>>> I did a bit more work on teh text. Latest version below. Again will >>>>appreciate a good review: >>>>=20 >>>> 3.5. CDNI Logging File Example >>>>=20 >>>> Let us consider the upstream CDN and the downstream CDN labelled >>>> uCDN and dCDN-1 in Figure 1. When dCDN-1 acts as a downstream CDN >>>> for uCDN and performs content delivery on behalf of uCDN, dCDN-1 >>>> will include the CDNI Logging Records corresponding to the content >>>> deliveries performed on behalf of uCDN in the CDNI Logging Files for >>>> uCDN. An example CDNI Logging File communicated by dCDN-1 to uCDN is >>>> shown below in Figure 4. >>>>=20 >>>> #Version:CDNI/1.0 >>>>=20 >>>> #UUID:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 >>>>=20 >>>> #Claimed-Origin:cdni-logging-entity.dcdn-1.example.com >>>>=20 >>>> #Record-Type:cdni_http_request_v1 >>>>=20 >>>> #Fields:datetimetime-takenc-ip >>>> cs-methodu-uriprotocolsc-status >>>> sc-total-bytescs(User-Agent)cs(Referer) >>>> s-cached >>>>=20 >>>> 2013-05-1700:38:06.8259.05810.5.7.1GET >>>> http://cdni-ucdn.dcdn-1.example.com/video/movie100.mp4 >>>> HTTP/1.12006729891"Mozilla/5.0 >>>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>>> Gecko) Chrome/5.0.375.127 Safari/533.4" >>>> "host1.example.com"1 >>>>=20 >>>> 2013-05-1700:39:09.14515.3210.5.10.5GET >>>> http://cdni-ucdn.dcdn-1.example.com/video/movie118.mp4 >>>> HTTP/1.120015799210"Mozilla/5.0 >>>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>>> Gecko) Chrome/5.0.375.127 Safari/533.4" >>>> "host1.example.com"1 >>>>=20 >>>> 2013-05-1700:42:53.43752.87910.5.10.5GET>>>> http://cdni-ucdn.dcdn-1.example.com/video/picture11.mp4 >>>> HTTP/1.020097234724"Mozilla/5.0 >>>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>>> Gecko) Chrome/5.0.375.127 Safari/533.4" >>>> "host5.example.com"0 >>>>=20 >>>> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >>>>=20 >>>> [Editor's Note: compute the correct Integrity-Hash value once example >>>> is frozen] >>>>=20 >>>>=20 >>>> Figure 4: CDNI Logging File Example >>>>=20 >>>> If uCDN establishes by some means (e.g. via TLS authentication when >>>> pulling the CDNI Logging File) the identity of the entity from which >>>> it pulled the CDNI Logging File, uCDN can add to the CDNI Logging a >>>> Verified-Origin directive as illustrated below: >>>>=20 >>>> #Verified-Origin:cdni-logging-entity.dcdn-1.example.com >>>>=20 >>>> As illustrated in Figure 2, uCDN will then ingest the corresponding >>>> CDNI Logging Records into its Collection process, alongside the >>>> Logging Records generated locally by the uCDN itself. This allows >>>> uCDN to aggregate Logging Records for deliveries performed by itself >>>> (through Records generated locally) as well as for deliveries >>>> performed by its downstream CDN(s). This aggregate information can >>>> then be used (after Filtering and Rectification, as illustrated in >>>> Figure 2) by Log Consuming Applications that take into account >>>> deliveries performed by uCDN as well as by all of its downstream >>>> CDNs. >>>>=20 >>>> We observe that the time between >>>>=20 >>>> 1. when a delivery is completed in dCDN and >>>>=20 >>>> 2. when the corresponding Logging Record is ingested by the >>>> Collection process in uCDN >>>>=20 >>>> depends on a number of parameters such as the Logging Period agreed >>>> to by uCDN and dCDN, how much time uCDN waits before pulling the CDNI >>>> Logging File once it is advertised in the CDNI Logging Feed, and the >>>> time to complete the pull of the CDNI Logging File. Therefore, if we >>>> consider the set of Logging Records aggregated by the Collection >>>> process in uCDN in a given time interval, there could be a permanent >>>> significant timing difference between the CDNI Logging Records >>>> received from the dCDN and the Logging Records generated locally. >>>> For example, in a given time interval, the Collection process in >>>> uCDN may be aggregating Logging Records generated locally by uCDN >>>> for deliveries performed in the last hour and CDNI Logging Records >>>> generated in the dCDN for deliveries in the hour before last. >>>>=20 >>>> 3.6. Cascaded CDNI Logging Files Example >>>>=20 >>>> Let us consider the cascaded CDN scenario of uCDN, dCDN-2 and dCDN-3 >>>> as depicted in Figure 1. After completion of a delivery by dCDN-3 on >>>> behalf of dCDN-2, dCDN-3 will include a corresponding Logging Record >>>> in a CDNI Logging File that will be pulled by dCDN-2 and that is >>>> illustrated below in Figure 5. In practice, a CDNI Logging File is >>>> likely to contain a very high number of CDNI Logging Records. >>>> However, for readability, the example in Figure 5 contains a single >>>> CDNI Logging Record. >>>>=20 >>>>=20 >>>> #Version:CDNI/1.0 >>>>=20 >>>> #UUID:urn:uuid:65718ef-0123-9876-adce4321bcde >>>>=20 >>>> #Claimed-Origin:cdni-logging-entity.dcdn-3.example.com >>>>=20 >>>> #Record-Type:cdni_http_request_v1 >>>>=20 >>>> #Fields:datetimetime-takenc-ip >>>> cs-methodu-uriprotocolsc-status >>>> sc-total-bytescs(User-Agent)cs(Referer) >>>> s-cached >>>>=20 >>>>=20 >>>> 2013-05-1700:39:09.11914.0710.5.10.9GET >>>> http://cdni-dcdn-2.dcdn-3.example.com/video/movie118.mp4 >>>> HTTP/1.120015799210"Mozilla/5.0 >>>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>>> Gecko) Chrome/5.0.375.127 Safari /533.4" >>>> "host1.example.com"1 >>>>=20 >>>> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >>>>=20 >>>> [Editor's Note: compute the correct Integrity-Hash value once >>>> example is frozen] >>>>=20 >>>> Figure 5: Cascaded CDNI Logging File Example (dCDN-3 to dCDN-2) >>>>=20 >>>> If dCDN-2 establishes by some means (e.g. via TLS authentication >>>> when pulling the CDNI Logging File) the identity of the entity from >>>> which it pulled the CDNI Logging File, dCDN-2 can add to the CDNI >>>> Logging a Verified-Origin directive as illustrated below: >>>>=20 >>>> #Verified-Origin:cdni-logging-entity.dcdn-3.example.com >>>>=20 >>>> dCDN-2 (behaving as an upstream CDN from the viewpoint of dCDN-3) >>>> will then ingest the CDNI Logging Record for the considered dCDN-3 >>>> delivery into its Collection process (as illustrated in Figure 2). >>>> This Logging Record may be aggregated with Logging Records generated >>>> locally by dCDN-2 for deliveries performed by dCDN-2 itself. Say, >>>> for illustration, that the content delivery performed by dCDN-3 on >>>> behalf of dCDN-2 had actually been redirected to dCDN-2 by uCDN, and >>>> say that another content delivery has just been redirected by uCDN to >>>> dCDN-2 and that dCDN-2 elected to perform the corresponding delivery >>>> itself. Then after Filtering and Rectification (as illustrated in >>>> Figure 2), dCDN-2 will include the two Logging Records corresponding >>>> respectively to the delivery performed by dCDN-3 and the delivery >>>> performed by dCDN-2, in the next CDNI Logging File that will be >>>> communicated to uCDN. An example of such CDNI Logging File is >>>> illustrated below in Figure 6. >>>>=20 >>>> #Version:CDNI/1.0 >>>>=20 >>>> #UUID:urn:uuid:1234567-8fedc-abab-0987654321ff >>>>=20 >>>> #Claimed-Origin:cdni-logging-entity.dcdn-2.example.com >>>>=20 >>>> #Record-Type:cdni_http_request_v1 >>>>=20 >>>> #Fields:datetimetime-takenc-ip >>>> cs-methodu-uriprotocolsc-status >>>> sc-total-bytescs(User-Agent)cs(Referer) >>>> s-cached >>>>=20 >>>> 2013-05-1700:39:09.11914.0710.5.10.9GET >>>> http://cdni-ucdn.dcdn-2.example.com/video/movie118.mp4 >>>> HTTP/1.120015799210"Mozilla/5.0 >>>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>>> Gecko) Chrome/5.0.375.127 Safari /533.4" >>>> "host1.example.com"1 >>>>=20 >>>> 2013-05-1701:42:53.43752.87910.5.10.12GET>>> B> http://cdni-ucdn.dcdn-2.example.com/video/picture11.mp4 >>>> HTTP/1.020097234724"Mozilla/5.0 >>>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>>> Gecko) Chrome/5.0.375.127 Safari /533.4" >>>> "host5.example.com"0 >>>>=20 >>>> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >>>>=20 >>>> [Editor's Note: compute the correct Integrity-Hash value once example >>>> is frozen] >>>>=20 >>>> Figure 6: Cascaded CDNI Logging File Example (dCDN-2 to uCDN) >>>>=20 >>>> If uCDN establishes by some means (e.g. via TLS authentication when >>>> pulling the CDNI Logging File) the identity of the entity from which >>>> it pulled the CDNI Logging File, uCDN can add to the CDNI Logging a >>>> Verified-Origin directive as illustrated below: >>>>=20 >>>> #Verified-Origin:cdni-logging-entity.dcdn-2.example.com >>>>=20 >>>> In the example of Figure 6, we observe that: >>>>=20 >>>> o the first Logging Record corresponds to the Logging Record >>>> communicated earlier to dCDN-2 by dCDN-3, which corresponds to a >>>> delivery redirected by uCDN to dCDN-2 and then redirected by >>>> dCDN-2 to dCDN-3. Its initial fields values are preserved, with >>>> the exception of the u-uri that now reflects the URI convention >>>> between uCDN and dCDN-2, and which presents the delivery to uCDN >>>> as if it was performed by dCDN-2 itself, which reflects the fact >>>> that dCDN-2 had taken the full responsibility of the corresponding >>>> delivery (even if in this case, dCDN-2 elected to redirect the >>>> delivery to dCDN-3 so it is actually performed by dCDN-3 on behalf >>>> of dCDN-2). >>>>=20 >>>> o the second Logging Record corresponds to a delivery redirected by >>>> uCDN to dCDN-2 and performed by dCDN-2 itself. The time of the >>>> delivery in this Logging Record may be significantly more recent >>>> than the first Logging Record since it was generated locally while >>>> the first Logging Record was generated by dCDN-3 and had to be >>>> advertised , and then pulled and then ingested into the dCDN-2 >>>> Collection process, before being aggregated with the second >>>> Logging Record. >>>>=20 >>>>=20 >>>>=20 >>>> Cheers >>>>=20 >>>> Francois >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> Thanks >>>>>=20 >>>>> Francois >>>>>=20 >>>>> " >>>>>=20 >>>>> 3.5. CDNI Logging File Example >>>>>=20 >>>>> Let us consider the upstream CDN and the downstream CDN labelled >>>>> uCDN and dCDN-1 in Figure 1. When dCDN-1 acts as a downstream CDN >>>>> for uCDN and performs content delivery on behalf of uCDN, dCDN-1 >>>>> will include the CDNI Logging Records corresponding to the content >>>>> deliveries performed on behalf of uCDN in the CDNI Logging Files for >>>>> uCDN. An example CDNI Logging File communicated by dCDN-1 to uCDN >>>>> is show below: >>>>>=20 >>>>> " >>>>>=20 >>>>> #Version:CDNI/1.0 >>>>>=20 >>>>> #UUID:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 >>>>>=20 >>>>> #Claimed-Origin:cdni-logging-entity.dcdn-1.example.com >>>>>=20 >>>>> #Record-Type:cdni_http_request_v1 >>>>>=20 >>>>> #Fields:datetimetime-takenc-ipcs- >>>>> methodu-uriprotocolsc-statussc-total- >>>>> bytescs(User-Agent)cs(Referer)s-cached >>>>>=20 >>>>> 2013-05-1700:38:06.8259.05810.5.7.1GET >>>>> h ttp://cdni-ucdn.dcdn-1.example.com/video/ >>>>> movie100.mp4HTTP/1.12006729891"Mozilla/5.0 >>>>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>>>> Gecko) Chrome/5.0.375.127 Safari >>>>> /533.4""host1.example.com"1 >>>>>=20 >>>>> 2013-05-1700:39:09.14515.3210.5.10.5GET>>>>> http://cdni-ucdn.dcdn-1.example.com/video/ >>>>> movie118.mp4HTTP/1.120015799210"Mozilla/5.0 >>>>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>>>> Gecko) Chrome/5.0.375.127 Safari >>>>> /533.4""host1.example.com"1 >>>>>=20 >>>>> 2013-05-1700:42:53.43752.87910.5.10.5GET>>>> B >>>>>> http://cdni-ucdn.dcdn-1.example.com/video/ >>>>> picture11.mp4HTTP/1.020097234724"Mozilla/5.0 >>>>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>>>> Gecko) Chrome/5.0.375.127 Safari >>>>> /533.4""host5.example.com"0 >>>>>=20 >>>>> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >>>>>=20 >>>>> [Editor's Note: compute the correct Integrity-Hash value once >>>>> example is frozen] >>>>>=20 >>>>> " >>>>>=20 >>>>> As illustrated in Figure 2, uCDN will then ingest the corresponding >>>>> CDNI Logging Records into its Collection process, alongside the >>>>> Logging Records generated locally by the uCDN itself. This allows >>>>> uCDN to aggregate Logging Records for deliveries performed by itself >>>>> (through Records generated locally) as well as for deliveries >>>>> performed by its downstream CDN(s). This aggregate information can >>>>> then be used (after Filtering and Rectification, as illustrated in >>>>> Figure 2) by Log Consuming Applications considering deliveries >>>>> performed by uCDN as well as by all its downstream CDN(s). >>>>>=20 >>>>> We observe that the time between >>>>>=20 >>>>> 1. when a delivery is completed in dCDN and >>>>>=20 >>>>> 2. when the corresponding Logging Record is ingested by the >>>>> Collection process in uCDN >>>>>=20 >>>>> depends on a number of parameters such as the Logging Period agreed >>>>> to by uCDN and dCDN, how much time uCDN waits after it is advertised >>>>> in the CDNI Logging Feed before pulling the CDNI Logging File, and >>>>> the time to complete the pull of the CDNI Logging File. Therefore, >>>>> if we consider the set of Logging Records aggregated by the >>>>> Collection process in uCDN in a given time interval, there could be >>>>> a permanent significant timing difference between the CDNI Logging >>>>> Records received from the dCDN and the Logging Records generated >>>>> locally. For example, in a given time interval, the Collection >>>>> process in uCDN may be aggregating Logging Records generated locally >>>>> by uCDN for deliveries performed in the last hour and CDNI Logging >>>>> Records generated in the dCDN for deliveries in the hour before last. >>>>>=20 >>>>> 3.6. Cascaded CDNI Logging Files Example >>>>>=20 >>>>> Let us consider the cascaded CDN scenario of uCDN, dCDN-2 and dCDN-3 >>>>> as depicted in Figure 1. After completion of a delivery by dCDN-3 >>>>> on behalf of dCDN-2, dCDN-3 will include a corresponding Logging >>>>> Record in a CDNI Logging File and will advertise this CDNI Logging >>>>> File to >>>>> d-CDN2 in the corresponding CDNI Logging feed. As a result, dCDN-2 >>>>> will initiate and complete the pull of the corresponding CDNI >>>>> Logging File that is illustrated below: >>>>>=20 >>>>> " >>>>>=20 >>>>> #Version:CDNI/1.0 >>>>>=20 >>>>> #UUID:urn:uuid:65718ef-0123-9876-adce4321bcde >>>>>=20 >>>>> #Claimed-Origin:cdni-logging-entity.dcdn-3.example.com >>>>>=20 >>>>> #Record-Type:cdni_http_request_v1 >>>>>=20 >>>>> #Fields:datetimetime-takenc-ipcs- >>>>> methodu-uriprotocolsc-statussc-total- >>>>> bytescs(User-Agent)cs(Referer)s-cached >>>>>=20 >>>>> 2013-05-1700:39:09.14515.3210.5.10.5GET>>>>>=20 >>>>> http://cdni-dcdn-2.dcdn-3.example.com/video/movie118.mp4HTTP/ >>>>> 1.120015799210"Mozilla/5.0 (Windows; U; Windows NT >>>>> 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 >>>>> Safari /533.4""host1.example.com"1 >>>>>=20 >>>>> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >>>>>=20 >>>>> [Editor's Note: compute the correct Integrity-Hash value once >>>>> example is frozen] >>>>>=20 >>>>> " >>>>>=20 >>>>> dCDN-2 (behaving as an upstream CDN from the viewpoint of dCDN-3) >>>>> will then ingest the CDNI Logging Record for the considered dCDN-3 >>>>> delivery into its Collection process (as illustrated in Figure 2). >>>>> This Logging Record may be aggregated with Logging Records generated >>>>> locally by dCDN-2 for deliveries performed by dCDN-2 itself. Say, >>>>> for illustration, that the content delivery performed by dCDN-3 on >>>>> behalf of dCDN-2 had actually been redirected to dCDN-2 by uCDN, and >>>>> say that another content delivery has just been redirected by uCDN >>>>> to >>>>> dCDN-2 and that dCDN-2 elected to perform the corresponding delivery >>>>> itself. Then after Filtering and Rectification (as illustrated in >>>>> Figure 2), dCDN-2 will include the two Logging Records corresponding >>>>> respectively to the delivery performed by dCDN-3 and the delivery >>>>> performed by dCDN-2, in the next CDNI Logging File that will be >>>>> communcated to uCDN. An example of such CDNI Logging File is >>>>> illustrated below: >>>>>=20 >>>>> #Version:CDNI/1.0 >>>>>=20 >>>>> #UUID:urn:uuid:1234567-8fedc-abab-0987654321ff >>>>>=20 >>>>> #Claimed-Origin:cdni-logging-entity.dcdn-2.example.com >>>>>=20 >>>>> #Record-Type:cdni_http_request_v1 >>>>>=20 >>>>> #Fields:datetimetime-takenc-ipcs- >>>>> methodu-uriprotocolsc-statussc-total- >>>>> bytescs(User-Agent)cs(Referer)s-cached >>>>>=20 >>>>> 2013-05-1700:39:09.14515.3210.5.10.5GET>>>>> http://cdni-ucdn.dcdn-2.example.com/video/movie118.mp4HTTP/ >>>>> 1.120015799210"Mozilla/5.0 (Windows; U; Windows NT >>>>> 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 >>>>> Safari /533.4""host1.example.com"1 >>>>>=20 >>>>> 2013-05-1701:42:53.43752.87910.5.10.5GET>>>> B >>>>>> http://cdni-ucdn.dcdn-2.example.com/video/picture11.mp4HTTP/ >>>>> 1.020097234724"Mozilla/5.0 (Windows; U; Windows NT >>>>> 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 >>>>> Safari /533.4""host5.example.com"0 >>>>>=20 >>>>> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >>>>>=20 >>>>> [Editor's Note: compute the correct Integrity-Hash value once >>>>> example is frozen] >>>>>=20 >>>>> " >>>>>=20 >>>>> In the example above, we observe that: >>>>>=20 >>>>> o the first Logging Record corresponds to the Logging Record >>>>> communicated earlier to dCDN-2 by dCDN-3, which corresponds to a >>>>> delivery redirected by uCDN to dCDN-2 and then redirected by >>>>> dCDN-2 to dCDN-3. Its initial fields values are preserved, with >>>>> the exception of the u-uri that now reflects the URI convention >>>>> between uCDN and dCDN-2, and which presents the delivery to uCDN >>>>> as if it was performed by dCDN-2 itself, which reflects the fact >>>>> that dCDN-2 had taken the full responsibility of the corresponding >>>>> delivery (even if in this case, dCDN-2 elected to redirect the >>>>> delivery to dCDN-3 so it is actually performed by dCDN-3 on behalf >>>>> of dCDN-2). >>>>>=20 >>>>> o the second Logging Record corresponds to a delivery redirected by >>>>> uCDN to dCDN-2 and performed by dCDN-2 itself. The time of the >>>>> delivery in this Logging Record may be significantly more recent >>>>> than the first Logging Record since it was generated locally while >>>>> the first Logging Record was generated by dCDN-3 and had to be >>>>> advertised , and then pulled and then ingested into the dCDN-2 >>>>> Collection process, before being aggregated with the second >>>>> Logging Record. >>>>>=20 >>>>> " >>>>>=20 >>>>>=20 >>>>> On 23 Apr 2014, at 20:29, Francois Le Faucheur (flefauch) >>>>> wrote: >>>>>=20 >>>>>> Hello, >>>>>>=20 >>>>>> On 18 Apr 2014, at 23:42, ietfdbh wrote: >>>>>>>>=20 >>>>>>>> On 5 Apr 2014, at 23:14, ietfdbh wrote: >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Most notably, the logging from a dCDN to a uCDN typically >>>>>>>>> contains only >>>>>>>> one >>>>>>>>> dCDN identifier, such as Verified-origin, and doesn't really >>>>>>>>> permit specifying a sub-ordinate dCDN. For example, in a cascade >>>>>>>>> such as CDN-A >>>>>>> - >>>>>>>>>=20 >>>>>>>>> CDN-B -> CDN-C, CDN-C will share logging info with CDN-B, but >>>>>>>>> not with CDN-A; CDN-B shares logging info with CDN-A. This can >>>>>>>>> be desirable for hiding the topology and delegation used by the >>>>>>>>> dCDN. However, this >>>>>>>> document >>>>>>>>> does not discuss how the logging provided by CDN-C gets >>>>>>>>> converted into >>>>>>>> the >>>>>>>>> logs for CDN-B that will be sent to CDN-A. Without some logging >>>>>>>> information >>>>>>>>> from CDN-C, it would seem difficult for CDN-A to utilize the >>>>>>>>> information >>>>>>> to >>>>>>>>> meet requirements of billing, analytics, and fault and >>>>>>>>> performance >>>>>>> analysis. >>>>>>>>> Maybe the logging gets aggregated and reported in CDN-B's >>>>>>>>> logging, >>>>>>>>=20 >>>>>>>> Exactly. >>>>>>>>=20 >>>>>>>>> but that >>>>>>>>> "transitive or aggregate logging" doesn't appear to be discussed >>>>>>>>> in this document. >>>>>>>>=20 >>>>>>>> It is discussed in section 2.1 through Figure 1 and the following >>>>>>>>text: >>>>>>>> " >>>>>>>> A dCDN (e.g., dCDN-2) integrates the relevant Logging information >>>>>>>> obtained from its dCDNs (i.e., dCDN-3) in the Logging information >>>>>>>> that it provides to the uCDN, so that the uCDN ultimately obtains >>>>>>>> all Logging information relevant to a CSP for which it acts as >>>>>>>> the authoritative CDN. >>>>>>>> " >>>>>>>> Does that address your concern? >>>>>>>=20 >>>>>>> No it does not mitigate my concern. >>>>>>>=20 >>>>>>> This says the information gets "integrated", but doesn't describe >>>>>>> what integrated means. >>>>>>> I could interpret that integration would be that the logging from >>>>>>> CDN-C would be included in the logs from CDN-B to CDN-A, But I >>>>>>> think the text says CDN-B will not share the logging entries from >>>>>>> CDN-C with CDN-A. >>>>>>> Do I have this wrong? Does CDN-B create a log file and generate >>>>>>> entries, and then when it delegates delivery to CDN-C, and CDN-C >>>>>>> passes its log file back to CDN-B, does CDN-B take the whole log >>>>>>> file from CDN-B and insert it into its own log file, then continue >>>>>>> adding any more entries, and then when done send the CDN-B log >>>>>>> file (including a fully inserted CDN-C log file) to CDN-A? >>>>>>>=20 >>>>>>> If not, that presumably means that somehow, the data from CDN-C is >>>>>>> "aggregated" - that's how it is "integrated", >>>>>>=20 >>>>>> Right. It is aggregated. >>>>>> Effectively, if CDN-B has sub-delegated a delivery to CDN-C, then >>>>>>when CDN-C provides a log record for that delivery to CDN-B, CDN-B >>>>>>will aggregate that log record with the log records for the >>>>>>deliveries that CDN-B conduted itself. When CDN-B provides log >>>>>>records to CDN-A, the log record corresponding to the delivery >>>>>>performed by CDN-C is turned by CDN-B into a log record that looks >>>>>>like the delivery was done by CDN-B. CDN-A will not be aware that >>>>>>the delivery was performed by another CDN than CDN-B (just like the >>>>>>Content Provider is not ware that the delivery was not performed by >>>>>>CDN-A with whom it has a delivery contract). >>>>>>=20 >>>>>>> But there is no discussion of how this aggregation is done. >>>>>>=20 >>>>>> That is true. I think it has been assumed by many but never made >>>>>>clear. So we need to add some discussion about that. >>>>>>=20 >>>>>>> I think your intent is to hide the fact that CDN-B used CDN-C, >>>>>>> since that may reflect a proprietary approach of CDN-B's business >>>>>>>model. >>>>>>=20 >>>>>> Right. >>>>>>=20 >>>>>>> But CDN-A would presumably have problems performing analytics, and >>>>>>> fault and performance analysis, if the data from CDN-C is not >>>>>>> included in CDN-B's logging to CDN-A. >>>>>>> So I would like an example to demonstrate what CDN-A would see in >>>>>>> CDN-B's logs if CDN-C had faults or performance problems, and I >>>>>>> would like to see how CDN-A could perform analytics (of any kind) >>>>>>> relating to the delivery performed by CDN-C. >>>>>>=20 >>>>>> The assumption is that CDN-A is only dealing with CDN-B. CDN-A may >>>>>>not not even be aware of CDN-C. >>>>>> So CDN-A analaytics/monitoring will establish whether all the >>>>>>deliveries delegated to CDN-B (comprising deliveries performed by >>>>>>CDN-B as well as deliveries redirected by CDN-B to CDN-C and >>>>>>possibly CDN-C2) have received the right quality (ie if CDN-B has >>>>>>met the SLA committed to CDN-A). >>>>>> If some deliveries have experienced quality problems, CDN-A will >>>>>>blame CDN-B. It is up to CDN-B to then do its own analytics and >>>>>>monitoring to decide whether the problem lies within his own CDN or >>>>>>CDN-C or CDN-C2. >>>>>> The whole thing operates as a chain of delegations, like many other >>>>>>business arrangements: if my SmartPhone does not work, I blame the >>>>>>smartPhone vendor (I don't try identify if the problem is coming >>>>>>from the supplier of the GSM chipset, but the SmartPhone vendor >>>>>>will). >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> I am missing how this would be done (especially in a standardized >>>>>>>manner). >>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> I think Verified-Origin is particularly problematic, because the >>>>>>>>> text >>>>>>> states >>>>>>>>> that this can only be added by the uCDN, never the dCDN. So what >>>>>>>>> if >>>>>>> CDN-B >>>>>>>>> verifies the origin of the logs from CDN-C and then passes the >>>>>>> information >>>>>>>>> (now as a dCDN) to CDN-A? The text mentions that this might be >>>>>>>> established >>>>>>>>> using authentication mechanisms; so do we lose this logged >>>>>>>>> authentication/verification when cascading? >>>>>>>>>=20 >>>>>>>>> (Maybe this is resolved by having the uCDN (CDN-B) record a >>>>>>> "transaction" >>>>>>>>> that starts when it delegates a task to a dCDN (e.g. CDN-C) and >>>>>>>>> ends >>>>>>> when >>>>>>>>> the dCDN completes the task, and the uCDN just records the whole >>>>>>>> transaction >>>>>>>>> without the details that are reported by CDN-C. Then CDN-B logs >>>>>>>>> only the whole transaction. I would like to see an explicit >>>>>>>>> example of such >>>>>>> logging, >>>>>>>>> using the cdni_http_request_v1 record-type, so this is clear.) >>>>>>>>=20 >>>>>>>> Yes, that is pretty much the idea. >>>>>>>> ie. if CDN-a delegate sto CDN-B then CDB-B is responsible for >>>>>>>> delivering >>>>>>> and >>>>>>>> will provide a delivery record to CDN-A for that delivery. That >>>>>>>> record >>>>>>> will be >>>>>>>> part of a Logging File whose origin in CDN-B, and CDN-A can use >>>>>>>> authentication mechanism to ensure the Logging File is provided=20 >>>>>>>>by CDN-B. >>>>>>>> All of this completely holds whether CDN-B performed the delivery >>>>>>>> itself (and created the delivery record in the first place) or >>>>>>>> CDN-B delegated to CDN-C who provided the delivery record to >>>>>>>> CDN-B in a Logging File whose origin was CDN-C. >>>>>>>>=20 >>>>>>>> This question has come up before so I will add a clarification >>>>>>>> along the >>>>>>> lines >>>>>>>> above under the description of the Verified Origin in case of >>>>>>>> cascaded >>>>>>> CDNs. >>>>>>>=20 >>>>>>> An example of such integrated cascaded logging might answer many=20 >>>>>>>questions. >>>>>>=20 >>>>>> Good idea. >>>>>> It sounds worthwhile to give a descripton of how log records get=20 >>>>>>aggregated in a csacaded scenario, indicate how directives/fields=20 >>>>>>get modified/kept at each CDN hop, and possibly include an example=20 >>>>>>with some log records and how they propagate from CDN-C to CDN-B to=20 >>>>>>CDN-A. >>>>>>=20 >>>>>>> If logging records from CDN-C get copied into the log from CDN-B, >>>>>>> are all directives and record types copied? >>>>>>> If so, I think it is important to make clear that a given log >>>>>>> might contain multiple nested logs, And that means that the file >>>>>>> received by CDN-A might start with directives for CDN-B plus >>>>>>> records, And then directives for CDN-C, ending with an >>>>>>> Integrity-Hash, and more records for CDN-B followed by an >>>>>>> Integrity-Hash. >>>>>>> Maybe this is all as designed, but I haven't seen discussion of >>>>>>> that, and it is not reflected in Figure 3, and this is not >>>>>>> discussed in the description of fields that are file-specific, >>>>>>> such as Integrity-hash, Verfiied-origin, Version, UUID, etc. >>>>>>> If you have nested logs, then log-consuming applications need to >>>>>>> know that those file-specific directives un-nest at the end of the >>>>>>> included file. Can they tell consistently when they hit the end of= =20 >>>>>>>the included file? >>>>>>> Should there be an end-of-log marker for the included log? >>>>>>>=20 >>>>>>> The Integrity-Hash directive is allowed to occur zero or once, not >>>>>>> multiple times in a logfile. >>>>>>> So if the CDN-C logfile contains an Integrity-Hash, should that be >>>>>>> checked by CDN-B, then copy the CDN-C logfile into the CDN-B >>>>>>> logfile, but discard the CDN-C Integrity-Hash, because CDN-B will >>>>>>> calculate its own Integrity-Hash directive? >>>>>>=20 >>>>>> Yes. >>>>>>=20 >>>>>>>=20 >>>>>>>> Let me know if that is not sufficient. >>>>>>>=20 >>>>>>> I remain concerned that cascaded logging may not have been >>>>>>> adequately described and standardized. >>>>>>=20 >>>>>> Right. I see that the questions you raised were not answered in the= =20 >>>>>>document. We will work on addressing them. >>>>>>=20 >>>>>> Thanks >>>>>>=20 >>>>>> Francois >>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Francois >>>>>>>=20 >>>>>>> dbh >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> 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 >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >>=20 >>=20 >>_________________________________________________________________________ >>________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations=20 >>confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=20 >>recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les=20 >>messages electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme= =20 >>ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or privileged= =20 >>information 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=20 >>delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have=20 >>been modified, changed or falsified. >> Thank you. >>=20 > > >_______________________________________________ >CDNi mailing list >CDNi@ietf.org >https://www.ietf.org/mailman/listinfo/cdni From nobody Mon Jul 7 00:46:31 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 778321A0AF5 for ; Mon, 7 Jul 2014 00:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nm0sumClMPcg for ; Mon, 7 Jul 2014 00:46:15 -0700 (PDT) Received: from owa.velocix.com (mail-out1.velocix.com [81.134.152.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE4221B279A for ; Mon, 7 Jul 2014 00:46:10 -0700 (PDT) Received: from EXB01-MLT.corp.velocix.com ([169.254.2.235]) by EXC00CAM.corp.velocix.com ([172.18.4.40]) with mapi id 14.02.0347.000; Mon, 7 Jul 2014 08:46:07 +0100 From: Rob Murray To: "Francois Le Faucheur (flefauch)" Thread-Topic: Comments on draft-ietf-cdni-control-triggers-03 Thread-Index: AQHPmbeCHtnMWfBDC0+9TN5HepSjgw== Date: Mon, 7 Jul 2014 07:46:07 +0000 Message-ID: <49C77373835C5A479BC2A84B2A1D66BDDA2D821F@EXB01-MLT.corp.velocix.com> References: <49C77373835C5A479BC2A84B2A1D66BDDA2D41E3@EXB01-MLT.corp.velocix.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.224.122.205] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/9GSE4Uj4gly-WGB7YA-u3OVWjOs Cc: "cdni@ietf.org" Subject: Re: [CDNi] Comments on draft-ietf-cdni-control-triggers-03 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jul 2014 07:46:22 -0000 Thanks Francois - I'll get these fixed for an update soon after Toronto (al= ong with anything else that comes up). Cheers, Rob. On 4 Jul 2014, at 16:41, Francois Le Faucheur (flefauch) wrote: > Hi Rob, >=20 > I read the new version till end of section 4. Below are some comments. >=20 > Cheers >=20 > Francois >=20 >=20 > *** in section 1:=20 > * remove the reproduction of actual requirements (for consistency with = other documents). > * reader of the present document may not be familiar with meaning of =93= Medium=94 and =93High=94, so I=92d suggest: > OLD: > " > Requirements for CI/T > are the "High" and "Medium" priority requirements for the CI identified i= n section 4 of [I-D.ietf-cdni-requirements],, reproduced here for convenien= ce: >=20 > CI-1 [HIGH] The CDNI Control interface shall allow the Upstream > ... =20 > " > NEW: > " > Section 4 of [I-D.ietf-cdni-requirements] identifies the requirements spe= cific to the CI interface. The subset of these requirements applicable to t= he CI/T interafce are CI-1 to CI-6. > " >=20 >=20 > *** Section 2: > "Requests to invalidate and purge metadata or content apply to all > variants of that data with a given URI.=94 > What do you mean by =93variants=94 here? >=20 >=20 > *** RFC2119 statements: > I think you need to walk through the doc and ensures there are MUST/SHOUL= D/MAY for all necessary element of behaviour. > For example, I see: > * "To trigger activity in the dCDN, the uCDN will POST to the collection= of Trigger Status Resources.=94 and > * "To trigger activity in the dCDN, the uCDN creates a new Trigger Statu= s Resource by posting to the dCDN's collection of uCDN's Trigger Status Res= ources.=94 > but I don=92t see any =93MUST POST=94. > Can you plan a review and make sure you add MUST/SHOULD/MAY wherever it i= s needed? >=20 > As another example, section 2 primarily uses descriptive text (=93dCDN do= es this=94, "it will do that=94) but has a few RFC2119 statements ("uCDN MA= Y GET=94. "uCDN MAY DELETE=94). Sincxe section 2 is an overview, I woudl su= ggest using only descriptive text and makingh sure all RFC2119 statements a= re moved to the more detailed sections. >=20 >=20 >=20 > *** section 2.1: > s/Timing of triggered activity is under the dCDN's control/Timing of the = execution of the triggered activity is under the dCDN's control/ >=20 >=20 > *** section 2.1: > "Invalidate and purge triggers MUST be applied to all data acquired > before the trigger was created in the dCDN. The dCDN may apply the > triggers to data acquired after trigger creation.=94 > why do we have a =93MUST=94 and then a =93may=94 (instead of a =93MAY=94)= ? > This seems like another example of a needed RFC2119 cleanup. >=20 >=20 > *** section 2.1: > s/Otherwise, the dCDN may pre-position/Otherwise, there is a risk that th= e dCDN pre-positions/ >=20 >=20 > *** section 3: > =93 > o Complete - Trigger Status Resources representing activity that > completed successfully, or for which no further status updates > will be made by the dCDN. > =93 > I think "for which no further status updates will be made by the dCDN=94 = means that is in the =93processed=94 status defined in section 4, right? > If yes, it may be worth mentioning the word =93processed=94 here to help = reconciliate this list of collection with the various status defined in sec= tion 4. e.g.: > =93 > o Complete - Trigger Status Resources representing activity that > completed successfully, or for which no further status updates > will be made by the dCDN (.i.e that is already processed). > " >=20 >=20 > *** section 4: > "The interface is > intended to be independent of the set of activities defined now, or > that may be defined in future.=94 > I had to re-read this a couple of times to understand what you meant. I t= hink it can be phrased better, perhaps indicating it is independent of the = =93types of triggers=94 (as opposed to "set of activities) and replacing = =93now=94 by =93specified in the present document=94.=20 >=20 >=20 > *** section 4: > the terms =93client=94 and =93server=94 are used out of teh blue and need= to be related to uCDN and dCDN. Perhaps you could do something similar to = what we did in cdni-logging i.e. we specified teh =93Server-side=94 and =93= client-side=94 behavior and stated that a dCDN implementation of the interf= ace MUST support the server-side and an uCDN implementation of the interfa= ce MUST support the client-side and an uCDN.=20 >=20 >=20 > *** section 4: > =93Since only one CDN > can be authoritative for a given item of metadata or content, this > requirement means there cannot be any "loops" in trigger requests > between CDNs." > This may deserve some more explanations. > When you say =93there cannot be=94 does it mean =93it will not happen bec= ause it is prevented by the law of physics so you don=92t have to worry abo= ut it=94? or does it mean =93you need to make sure it does not happen=94?=20 >=20 >=20 > *** section 4.1: > "if it is malformed > or the uCDN does not have sufficient access rights it MAY reject the > request immediately.=94 > shoudl this be just a =93MAY=94? what else can it do with a malformed req= uest? >=20 >=20 > *** section 4.1: > s/If the dCDN is not able to track triggered activity/If the dCDN is not = able to track the execution of triggered activity/ >=20 >=20 > *** section 4.1: > s/If the dCDN is able to track triggered activity/If the dCDN is able to = track the execution of triggered activity/ >=20 >=20 > *** section 4.2: > s/described in the following sections/described in section 4.2.1 and 4.2.= 2/ >=20 >=20 > *** section 4.3: > "If an "active" Trigger Status Resource is deleted, the dCDN MAY stop > processing the triggered activity. =93 > MAY or SHOULD? >=20 >=20 > *** section 4.3: > OLD: > =93 > it is recommended that the uCDN's polling interval is half > the time after which records for completed activity will be > considered stale. > =93 > NEW: > =93 > the uCDN SHOULD set its polling interval to a value that is at most half > the time after which records for completed activity will be > considered stale. > =93 >=20 >=20 > *** Section 4.5: > =93 > If a surrogate affected by a trigger is offline in the dCDN, or the > dCDN is unable to pass a trigger request on to any of its cascaded > dCDNs; the dCDN SHOULD report an error if the request is abandoned. > Otherwise, it SHOULD keep the trigger in state "pending" or "active" > until it's acted upon or the uCDN chooses to cancel it. > =93 > It is not obvious if =93Otherwise=94 refers to =93if a surrogate=85=94 or= =93if the request is abandoned=94. I think it is teh latter. In which case= , you may want to structure the text with bullets like: > =93 > If a surrogate affected by a trigger is offline in the dCDN, or the > dCDN is unable to pass a trigger request on to any of its cascaded > dCDNs: > * if the request is abandoned by the dCDN, the dCDN SHOULD report an er= ror > * Otherwise, it SHOULD keep the trigger in state "pending" or "active" > until it's acted upon or the uCDN chooses to cancel it. > " >=20 >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Editorial Nits: >=20 >=20 > *** Abstract: > s/CDN Interconnect/CDN Interconnection/ > s/re-validate or purge/re-validates or purges/ >=20 >=20 > *** section 1: > s/Problem scope/problem scope/ >=20 >=20 > *** section 2: > s/a request for dCDN/a request for the dCDN/ >=20 > *** Sometimes you use =93the uCDN=94 and sometimes =93uCDN=94 (e.g. ", uC= DN has access=94). I suggest always using =93the uCDN=94.=20 >=20 > *** I thought the aprostrophe for the possessive case only applied to hum= ans and not things, so that one should say =93dCDN control=94 and not =93dC= DN=92s control=94.=20 >=20 >=20 > *** section 4.1: > s/it MUST indicate that indicate/it MUST indicate/ >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On 3 Jul 2014, at 20:38, Rob Murray wrote: >=20 >> Hi all, >>=20 >> Kevin, thank you for the review. All very good comments, sorry it took m= e so long to get to them. >>=20 >> Responses inline below, and I've posted an "03" version of the draft... >>=20 >> http://datatracker.ietf.org/doc/draft-ietf-cdni-control-triggers/ >> http://tools.ietf.org/html/draft-ietf-cdni-control-triggers-03 (eventua= lly) >>=20 >> Most comments have been addressed, including a couple of earlier ones fr= om Francois about broken formatting. >>=20 >> What I've not dealt with is the idea to separate trigger deletion and ca= ncellation - in order to make it possible to check the status of a deleted = trigger. It'd make the interface a little more complicated, and I'm not sur= e what status the dCDN could usefully report. (Also, I ran out of time for = making edits!) Let's discuss further in Toronto. >>=20 >> Cheers, >> Rob. >>=20 >> On 6 May 2014, at 23:15, Kevin Ma J wrote: >>=20 >>> Hi All, >>>=20 >>> Per the chairs' request for a detailed review of the triggers draft, >>> I've compiled a list of comments below. >>>=20 >>> thanx. >>>=20 >>> -- Kevin J. Ma >>>=20 >>> comments: >>>=20 >>> - General: imo, an article in front of uCDN/dCDN (i.e., the uCDN/dCDN) >>> makes for easier reading. >>=20 >> Done. >>=20 >>> - General: There are quite a few lower case "must"s (17), "shall"s (14)= , >>> "should"s (7), and "may"s (36) in the document. Are they all >>> intentionally non-normative?=20 >>=20 >> Hopefully sorted now, though I MAY have gone too far! >>=20 >>> - section 2: Should cancelling a trigger and removing a trigger status >>> be separated in some way? Using DELETE for both means >>> that if I wanted to cancel a trigger, I would have no way >>> to get status on the cancelled trigger, since the status >>> resource would be removed at the same time, and delete >>> does not return a status, per the example in section 7.2.5 >>=20 >> See above, it could be a good idea but it'd be good to talk it through a= bit further (sorry I left this update too late to do it on the list before= the deadline). >>=20 >>> - section 2/4.1: In step 2 of figure 1, it mentions authentication as >>> does section 4.1, but section 7 and 9 provide no >>> guidance on either the authentication mechanism or >>> what precisely is being authenticated. Presumably we >>> are authenticating that it is a known uCDN making the >>> request for metadata/content that is known to be owned >>> by that uCDN? Should we state that? >>>=20 >>> Do we have a suggestion (e.g., SSL client auth, HTTP >>> basic/digest auth, etc.) for authentication method? >>=20 >> I've rewritten the Security Considerations section now (based on what's = in the Logging draft, as agreed in London). >>=20 >>> - section 2.1: I found the wording of this sentance a little confusing. >>>=20 >>> "If uCDN wishes to invalidate or purge content, then immediately >>> preposition replacement content at the same URLs, it must ensure the >>> dCDN has completed the invalidate/purge before initiating the >>> prepositioning. If it fails to do that and the requests overlap, and >>> dCDN passes the triggers on to a further dCDN in a cascade, that CDN >>> may preposition content that has not yet been invalidated/purged in >>> its uCDN." >>>=20 >>> Perhaps something like: >>>=20 >>> "If uCDN wishes to invalidate or purge content, then immediately >>> preposition replacement content at the same URLs, it must ensure the >>> dCDN and all cascaded dCDNs have completed the invalidate/purge >>> before initiating the prepositioning, otherwise, a cascaded dCDN may >>> attempt to preposition content that has not yet been invalidated/purg= ed >>> in its uCDN." >>=20 >> Done. >>=20 >>>=20 >>> - section 3: I would break this into two sentances: >>>=20 >>> "The dCDN must present a different set of Trigger Status Resources to >>> each interconnected uCDN, only Trigger Status Resources belonging to >>> a uCDN shall be visible to it." >>>=20 >>> i.e.: >>>=20 >>> "The dCDN must present a different set of Trigger Status Resources to >>> each interconnected uCDN. Only Trigger Status Resources belonging to >>> a uCDN shall be visible to it." >>=20 >> Done (and reworded a bit). >>=20 >>> - section 3: This is the first mention of expiry. Perhaps a reference >>> to Section 4.4? >>>=20 >>> "This collection lists all >>> uCDN triggers that have been accepted by dCDN, and have not yet been >>> deleted by uCDN or expired and removed by dCDN." >>=20 >> Done. >>=20 >>> - section 4.1: These are the first mention of etime and mtime, perhaps >>> there should be a reference to Section 5.2, or some >>> type of explaination on what etime > mtime means. >>>=20 >>> I am not sure about using of etime > mtime as an indicator. >>> If mtime < now and etime < now, but still etime > mtime, >>> it would seem to imply that the activity may be complete, >>> but I don't think that is the intent? >>>=20 >>> Should there be some normative language stating that if >>> etime > mtime, the uCDN must update the status, and the >>> dCDN must update mtime =3D now and etime > mtime? >>>=20 >>> "If dCDN is not able to track triggered activity, it MAY indicate that >>> it has undertaken to complete the activity but will not report >>> completion or any further errors. To do this, it must set the >>> trigger status to "complete", with an estimated completion time in >>> the future ("etime" greater than "mtime")." >>=20 >> I got rid of that and added an extra state, "processed" - it's like "com= plete", but means the dCDN can't provide a success/fail result. (With a rec= ommendation that an estimated completion time should be provided in that ca= se.) >>=20 >>> - section 4.4: Why 24 hours? Seems fast? >>>=20 >>> "It >>> is recommended that Trigger Status Resources are automatically >>> deleted 24 hours after they become completed or failed." >>=20 >> I made it "not less than 24 hours". >>=20 >>> - section 4.4: comma after: >>>=20 >>> "If any part of the trigger request fails, " >>>=20 >>> comma before: >>>=20 >>> ", if the trigger is still running for some URLs >>> or Patterns in the trigger request." >>>=20 >>> perhaps clarify "cascaded" dCDNs: >>>=20 >>> "pass a trigger request on to any of its affected cascaded dCDNs" >>=20 >> Done. >>=20 >>> - section 5.2: AbsoluteTime is a Unix Epoch, so should be UTC. >>> I found the phrase "Time is local to dCDN" confusing as >>> I first assumed "local" was referencing timezone, but I >>> think "local" is just related to unsynchronized clocks? >>> Perhaps: "Time is determined by the dCDN"? >>=20 >> Done. >>=20 >>> - section 5.4: links is a "List of Relationships". Why not just URLs? >>> If the trigger collection can only reference trigger >>> statuses, then why does it need typed relationships? >>> The use of a relationship here seems overly complex? >>>=20 >>> Is relationship standard JSON terminology? Should there >>> be a reference to the acknowledged work of Mike Kelly? >>=20 >> Yes, you're right. It had all got too complicated and bloated. So it's j= ust a list of URLs now, I got rid of all that JSON relationship stuff. >>=20 >>> - section 6: There is a note about MI dependency. >>> Is it just for PatternMatch? >>=20 >> It was, but the dependency wasn't necessary so I've got rid of it. >>=20 >>> - section 6.1.6: "ralationship" -> "relationship" >>=20 >> Fixed. >>=20 >>> - section 6.1.6/6.1.7: I think it would be helpful to define the >>> Relationship and Link objects the same way as >>> all the other JSON objects, e.g.: >>>=20 >>> How are the keys in the _links dictionary >>> determined? And how is their meaning known? >>> The key "self" seems to have a specific meaning? >>> It is essentially a reserved keyword? Are there >>> other reserved keywords (e.g., "Trigger"), and >>> do they have to be registered somewhere? >>>=20 >>> Relationship: >>> Key: _links >>> Description: List of related objects? >>> Type: Array of LinkUnions >>> Mandatory: Yes >>>=20 >>> LinkUnion: >>> Key: ??? >>> Description: List of related objects? >>> Type: Array of LinkUnions >>> Mandatory: No. >>>=20 >>> Key: ??? >>> Description: related objects? >>> Type: Link >>> Mandatory: No. >>>=20 >>> Link: >>> Key: href >>> Description: URI of the addressable object being referenced >>> Type: URL >>> Mandatory: Yes >>>=20 >>> Key: type >>> Description: Type of the referenced object >>> Type: MIME Media Type >>> Mandatory: No >>=20 >> I did that - then decided to get rid of it all, as above. It was only us= ed in the collections, and they're now just lists of links. >>=20 >>> - section 7: There are no examples with "base" or "links". I have an >>> idea of how "base" might be used, but I don't know what >>> the purpoes of "links" is. Can we add an example? >>>=20 >>> "URLs are under control" -> "URLs are under the control" >>=20 >> "links" has gone. >>=20 >>> - section 7.2.1/7.2.2: I don't know where the key "Trigger" came from? >>> Is it derived from some known object, or is it >>> randomly selected (and somehow registered)? >>=20 >> In the "01" draft it was the "relationship type", and I'd not documented= the change properly. But it's gone now, just a list of URLs. >>=20 >>> - section 7.2.5: Would there be value in returning the status on delete= ? >>=20 >> Probably a good idea. Let's wrap it up with discussion on the delete/can= cel question. >>=20 >>> - section 9: In the first sentance below, I interpret "access" as the >>> ability to read (GET) a status object or collection. It >>> does not necessarily imply to me who can issue a new >>> trigger request? In the second sentance, it says it can >>> only "affect" it's own content, which I guess implies >>> that only it can affect it's own content, as another uCDN >>> affecting it's content would violate this rule? Should >>> we make that more explicit? >>>=20 >>> "The dCDN must ensure that each uCDN only has access to its own >>> Trigger Status Resources." >>>=20 >>> "The dCDN must ensure that activity triggered by uCDN only affects >>> metadata or content originating from that uCDN." >>>=20 >>> e.g., update the second sentance to something like: >>>=20 >>> "The dCDN must ensure that activity triggered by uCDN only affects >>> metadata or content originating from that uCDN, and that no other >>> uCDN may trigger activity that affects another uCDN's metadata or >>> content." >>=20 >> Hopefully the re-written section 9 is clearer. >>=20 >>> - random: The mention of only affecting a uCDN's own content made me >>> think of the DNS diamond scenario. Do we believe that the >>> Content URLs described in section 5.1.1 are sufficient to >>> ensure this, or is there a caveat for the diamond case? >>>=20 >>> "The dCDN must ensure that activity triggered by uCDN only affects >>> metadata or content originating from that uCDN." >>=20 >> Done. >>=20 >>>=20 >>> _______________________________________________ >>> 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 From nobody Mon Jul 7 06:06:32 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42E291B284E for ; Mon, 7 Jul 2014 06:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.253 X-Spam-Level: X-Spam-Status: No, score=-9.253 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_BACKHAIR_31=1, J_BACKHAIR_37=1, J_BACKHAIR_44=1, J_BACKHAIR_52=1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnhatFJVzjqV for ; Mon, 7 Jul 2014 06:06:13 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28F4A1A0424 for ; Mon, 7 Jul 2014 06:06:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35914; q=dns/txt; s=iport; t=1404738373; x=1405947973; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=kgZ2/0eDOeowmVrN98QmkWWoxySHVB2oBouMQyc8ty8=; b=HFRRBIB6ZfNB7+A4tp2pt76MwumiqFvbH1NtcZbN4ahtVfwwqcqxEQUh zywblLk1TzTjKV7SNf/kix0G7SfOHRu7DpZf4/vmWqWjmyaQezopZm/2n Ya0QDlw+EKB8XhdyWyiviw97pyLTRLM4mc/2hzJ1axwTtKYb+qo6JDmYp I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkILAGWaulOtJA2J/2dsb2JhbABQAQmDDlJNAQELrBeSXYdFAYEUFnWEAwEBAQMBAQEBFwEMRwsFCwIBCBgVGScLFwENAgQOAwKILgMJCA3DIQiGNReNBYFBASgzBwIIgyOBFgWWFkaEGoFIii6IFoNDQSsBgUM X-IronPort-AV: E=Sophos;i="5.01,618,1400025600"; d="scan'208";a="58810288" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-4.cisco.com with ESMTP; 07 Jul 2014 13:06:11 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s67D6B1E012376 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Jul 2014 13:06:11 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Mon, 7 Jul 2014 08:06:10 -0500 From: "Francois Le Faucheur (flefauch)" To: "Francois Le Faucheur (flefauch)" Thread-Topic: Utility of Verified-Origin & Claimed-Origin in CDNI logging Thread-Index: AQHPluW8wWdZ2VEK5ESkrvRbs+8LfJuP5tkAgAUHnYA= Date: Mon, 7 Jul 2014 13:06:09 +0000 Message-ID: <6DA3197C-D6F7-42A4-BDE7-D3BE77E8A625@cisco.com> References: <038401cf5b4f$0b5ea610$221bf230$@comcast.net> <05BD7B6B-6886-4277-8A8A-8AE77363939B@cisco.com> <315A2A4B-C876-4FF7-A836-7D48AC191195@cisco.com> 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.203] Content-Type: text/plain; charset="Windows-1252" Content-ID: <84F267EDBC3789449362AAA2FC46B0C8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/d-pM5QR4qfgOeRG1qpg4lZJ3n4o Cc: "cdni@ietf.org" Subject: Re: [CDNi] Utility of Verified-Origin & Claimed-Origin in CDNI logging X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jul 2014 13:06:22 -0000 Ben, Please see below: On 4 Jul 2014, at 10:17, Francois Le Faucheur (flefauch) wrote: > Hi Ben, >=20 > On 3 Jul 2014, at 19:39, Ben Niven-Jenkins wrot= e: >=20 >> Francois, Colleagues, >>=20 >> Reading your suggested text below made me ponder on the purpose and util= ity of the Claimed-Origin and Verified-Origin field directives. >>=20 >> Let=92s start with Verified-Origin. From your text below and reading the= definition of Verified-Origin in section 3.3 of draft-ietf-cdni-logging-11= I understand that a dCDN MUST NOT place a Verified-Origin field directive = in a log file it sends to a uCDN (it is the uCDN=92s job to do that if it w= ants to once it has verified the origin). Furthermore in a cascaded scenari= o (uCDN-tCDN-dCDN) the transit CDN MUST NOT include a Verified-Origin field= directive in a log file it sends to uCDN and by implication if tCDN insert= ed a Verified-Origin directive when receiving from dCDN, it must strip it b= efore sending that log file on to uCDN. >=20 > Yes. >=20 >>=20 >> Therefore use of Verified-Origin is purely internal to a given CDN, is n= ever exchanged between CDNs and has no role to play in interoperation of CD= NI between CDNs, so why does the logging draft need to specify it at all? >=20 > That=92s a good question. >=20 > I think the train of thought that got us there is the following : > * when storing the CDNI Logging File, the uCDN would want to have an eas= y way to identify where the CDNI Logging File is coming from > * since the dCDN knows who he is, it is trivial for it to include its id= entification in a field inside the file > * the uCDN may be happy with that, in which case it does not have to do = anything; > * or the uCDN may want to record the identification it establishes, in w= hich case it has to add the corresponding field itself. > That=92s more or less how we got there. >=20 > My personal take would be: > *A* if we expect that uCDNs would typically want to have an explicit rec= ord inside the CDNI Logging File of the dCDN that originated the file , the= n we should define directive(s) to do that. This will make things more cons= istent for processing tools/utilities operating over CDNI Logs. And in the = case where the uCDN is happy with the origin as stated by dCDN (say because= the dCDN is operated by the same administrative entity), it will save any = file manipulation by the uCDN. > *B* if we expect that uCDNs would typically NOT want to have an explicit= record inside the CDNI Logging File of the dCDN that originated the file (= say because they want to encode that information inside the filename), then= there may not be much value in defining the directives. Does this make sense to you? What is your take on whether uCDNS would typically want to store the origin= of teh CDNI Logging File inside the file? Tx Francois > I personally lean towards *A*, but let=92s hear more opnions or arguments= .=20 >=20 > Cheers >=20 > Francois >=20 >=20 >> CDNs that want the functionality of Verified-Origin can do whatever they= want internally to implement that, it doesn=92t seem we need something in = the RFC to support the internal behaviour of a CDN. >>=20 >>=20 >> That then got me thinking about Claimed-Origin. If I read the text below= correctly, my understanding is that the value of Claimed-Origin should be = the same hostname in the dCDN that the uCDN connects to in order to retriev= e log files. So for example a uCDN could compare the value of Claimed-Origi= n against the values of subjectAltName in the TLS certificate presented by = the dCDN and if there is a match then the Claimed-Origin can be =93verified= =94. >>=20 >> I=92m struggling to see what value Claimed-Origin gives in practice, pos= sibly because I don=92t understand the use case for it. If the purpose is = to let a uCDN do the comparison I describe above then I=92m not sure that g= ives us much in reality. Claimed-Origin becomes essentially a hop-by-hop (C= DN-by-CDN) property and assuming the dCDN identifies itself correctly (e.g.= hostname in dCDN that uCDN connected to matches hostname(s) in TLS certifi= cate presented by dCDN) Claimed-Origin is adding nothing, or have I misunde= rstood? >>=20 >> Thanks >> Ben >>=20 >> On 2 Jul 2014, at 15:39, Francois Le Faucheur (flefauch) wrote: >>=20 >>>=20 >>> On 1 Jul 2014, at 20:09, Francois Le Faucheur (flefauch) wrote: >>>=20 >>>> Folks, >>>>=20 >>>> (as a document editor) >>>>=20 >>>> To address the point around cascaded CDNs that was raised by David Har= rington as part of his early Ops Review, I have: >>>> * expanded section 3.5 =93CDNI Logging File Example=94 >>>> * added a section 3.6 "Cascaded CDNI Logging Files Example=94 >>>>=20 >>>> Draft text is below. I=92d appreciate some reviews. >>>=20 >>> I did a bit more work on teh text. Latest version below. Again will app= reciate a good review: >>>=20 >>> 3.5. CDNI Logging File Example >>>=20 >>> Let us consider the upstream CDN and the downstream CDN labelled uCDN >>> and dCDN-1 in Figure 1. When dCDN-1 acts as a downstream CDN for >>> uCDN and performs content delivery on behalf of uCDN, dCDN-1 will >>> include the CDNI Logging Records corresponding to the content >>> deliveries performed on behalf of uCDN in the CDNI Logging Files for >>> uCDN. An example CDNI Logging File communicated by dCDN-1 to uCDN is >>> shown below in Figure 4. >>>=20 >>> #Version:CDNI/1.0 >>>=20 >>> #UUID:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 >>>=20 >>> #Claimed-Origin:cdni-logging-entity.dcdn-1.example.com >>>=20 >>> #Record-Type:cdni_http_request_v1 >>>=20 >>> #Fields:datetimetime-takenc-ip >>> cs-methodu-uriprotocolsc-status >>> sc-total-bytescs(User-Agent)cs(Referer) >>> s-cached >>>=20 >>> 2013-05-1700:38:06.8259.05810.5.7.1GET >>> http://cdni-ucdn.dcdn-1.example.com/video/movie100.mp4 >>> HTTP/1.12006729891"Mozilla/5.0 >>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>> Gecko) Chrome/5.0.375.127 Safari/533.4" >>> "host1.example.com"1 >>>=20 >>> 2013-05-1700:39:09.14515.3210.5.10.5GET >>> http://cdni-ucdn.dcdn-1.example.com/video/movie118.mp4 >>> HTTP/1.120015799210"Mozilla/5.0 >>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>> Gecko) Chrome/5.0.375.127 Safari/533.4" >>> "host1.example.com"1 >>>=20 >>> 2013-05-1700:42:53.43752.87910.5.10.5GET >>> http://cdni-ucdn.dcdn-1.example.com/video/picture11.mp4 >>> HTTP/1.020097234724"Mozilla/5.0 >>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>> Gecko) Chrome/5.0.375.127 Safari/533.4" >>> "host5.example.com"0 >>>=20 >>> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >>>=20 >>> [Editor's Note: compute the correct Integrity-Hash value once example >>> is frozen] >>>=20 >>>=20 >>> Figure 4: CDNI Logging File Example >>>=20 >>> If uCDN establishes by some means (e.g. via TLS authentication when >>> pulling the CDNI Logging File) the identity of the entity from which >>> it pulled the CDNI Logging File, uCDN can add to the CDNI Logging a >>> Verified-Origin directive as illustrated below: >>>=20 >>> #Verified-Origin:cdni-logging-entity.dcdn-1.example.com >>>=20 >>> As illustrated in Figure 2, uCDN will then ingest the corresponding >>> CDNI Logging Records into its Collection process, alongside the >>> Logging Records generated locally by the uCDN itself. This allows >>> uCDN to aggregate Logging Records for deliveries performed by itself >>> (through Records generated locally) as well as for deliveries >>> performed by its downstream CDN(s). This aggregate information can >>> then be used (after Filtering and Rectification, as illustrated in >>> Figure 2) by Log Consuming Applications that take into account >>> deliveries performed by uCDN as well as by all of its downstream >>> CDNs. >>>=20 >>> We observe that the time between >>>=20 >>> 1. when a delivery is completed in dCDN and >>>=20 >>> 2. when the corresponding Logging Record is ingested by the >>> Collection process in uCDN >>>=20 >>> depends on a number of parameters such as the Logging Period agreed >>> to by uCDN and dCDN, how much time uCDN waits before pulling the CDNI >>> Logging File once it is advertised in the CDNI Logging Feed, and the >>> time to complete the pull of the CDNI Logging File. Therefore, if we >>> consider the set of Logging Records aggregated by the Collection >>> process in uCDN in a given time interval, there could be a permanent >>> significant timing difference between the CDNI Logging Records >>> received from the dCDN and the Logging Records generated locally. >>> For example, in a given time interval, the Collection process in uCDN >>> may be aggregating Logging Records generated locally by uCDN for >>> deliveries performed in the last hour and CDNI Logging Records >>> generated in the dCDN for deliveries in the hour before last. >>>=20 >>> 3.6. Cascaded CDNI Logging Files Example >>>=20 >>> Let us consider the cascaded CDN scenario of uCDN, dCDN-2 and dCDN-3 >>> as depicted in Figure 1. After completion of a delivery by dCDN-3 on >>> behalf of dCDN-2, dCDN-3 will include a corresponding Logging Record >>> in a CDNI Logging File that will be pulled by dCDN-2 and that is >>> illustrated below in Figure 5. In practice, a CDNI Logging File is >>> likely to contain a very high number of CDNI Logging Records. >>> However, for readability, the example in Figure 5 contains a single >>> CDNI Logging Record. >>>=20 >>>=20 >>> #Version:CDNI/1.0 >>>=20 >>> #UUID:urn:uuid:65718ef-0123-9876-adce4321bcde >>>=20 >>> #Claimed-Origin:cdni-logging-entity.dcdn-3.example.com >>>=20 >>> #Record-Type:cdni_http_request_v1 >>>=20 >>> #Fields:datetimetime-takenc-ip >>> cs-methodu-uriprotocolsc-status >>> sc-total-bytescs(User-Agent)cs(Referer) >>> s-cached >>>=20 >>> 2013-05-1700:39:09.11914.0710.5.10.9GET >>> http://cdni-dcdn-2.dcdn-3.example.com/video/movie118.mp4 >>> HTTP/1.120015799210"Mozilla/5.0 >>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>> Gecko) Chrome/5.0.375.127 Safari /533.4" >>> "host1.example.com"1 >>>=20 >>> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >>>=20 >>> [Editor's Note: compute the correct Integrity-Hash value once example >>> is frozen] >>>=20 >>> Figure 5: Cascaded CDNI Logging File Example (dCDN-3 to dCDN-2) >>>=20 >>> If dCDN-2 establishes by some means (e.g. via TLS authentication when >>> pulling the CDNI Logging File) the identity of the entity from which >>> it pulled the CDNI Logging File, dCDN-2 can add to the CDNI Logging a >>> Verified-Origin directive as illustrated below: >>>=20 >>> #Verified-Origin:cdni-logging-entity.dcdn-3.example.com >>>=20 >>> dCDN-2 (behaving as an upstream CDN from the viewpoint of dCDN-3) >>> will then ingest the CDNI Logging Record for the considered dCDN-3 >>> delivery into its Collection process (as illustrated in Figure 2). >>> This Logging Record may be aggregated with Logging Records generated >>> locally by dCDN-2 for deliveries performed by dCDN-2 itself. Say, >>> for illustration, that the content delivery performed by dCDN-3 on >>> behalf of dCDN-2 had actually been redirected to dCDN-2 by uCDN, and >>> say that another content delivery has just been redirected by uCDN to >>> dCDN-2 and that dCDN-2 elected to perform the corresponding delivery >>> itself. Then after Filtering and Rectification (as illustrated in >>> Figure 2), dCDN-2 will include the two Logging Records corresponding >>> respectively to the delivery performed by dCDN-3 and the delivery >>> performed by dCDN-2, in the next CDNI Logging File that will be >>> communicated to uCDN. An example of such CDNI Logging File is >>> illustrated below in Figure 6. >>>=20 >>> #Version:CDNI/1.0 >>>=20 >>> #UUID:urn:uuid:1234567-8fedc-abab-0987654321ff >>>=20 >>> #Claimed-Origin:cdni-logging-entity.dcdn-2.example.com >>>=20 >>> #Record-Type:cdni_http_request_v1 >>>=20 >>> #Fields:datetimetime-takenc-ip >>> cs-methodu-uriprotocolsc-status >>> sc-total-bytescs(User-Agent)cs(Referer) >>> s-cached >>>=20 >>> 2013-05-1700:39:09.11914.0710.5.10.9GET >>> http://cdni-ucdn.dcdn-2.example.com/video/movie118.mp4 >>> HTTP/1.120015799210"Mozilla/5.0 >>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>> Gecko) Chrome/5.0.375.127 Safari /533.4" >>> "host1.example.com"1 >>>=20 >>> 2013-05-1701:42:53.43752.87910.5.10.12GET >>> http://cdni-ucdn.dcdn-2.example.com/video/picture11.mp4 >>> HTTP/1.020097234724"Mozilla/5.0 >>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>> Gecko) Chrome/5.0.375.127 Safari /533.4" >>> "host5.example.com"0 >>>=20 >>> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >>>=20 >>> [Editor's Note: compute the correct Integrity-Hash value once example >>> is frozen] >>>=20 >>> Figure 6: Cascaded CDNI Logging File Example (dCDN-2 to uCDN) >>>=20 >>> If uCDN establishes by some means (e.g. via TLS authentication when >>> pulling the CDNI Logging File) the identity of the entity from which >>> it pulled the CDNI Logging File, uCDN can add to the CDNI Logging a >>> Verified-Origin directive as illustrated below: >>>=20 >>> #Verified-Origin:cdni-logging-entity.dcdn-2.example.com >>>=20 >>> In the example of Figure 6, we observe that: >>>=20 >>> o the first Logging Record corresponds to the Logging Record >>> communicated earlier to dCDN-2 by dCDN-3, which corresponds to a >>> delivery redirected by uCDN to dCDN-2 and then redirected by >>> dCDN-2 to dCDN-3. Its initial fields values are preserved, with >>> the exception of the u-uri that now reflects the URI convention >>> between uCDN and dCDN-2, and which presents the delivery to uCDN >>> as if it was performed by dCDN-2 itself, which reflects the fact >>> that dCDN-2 had taken the full responsibility of the corresponding >>> delivery (even if in this case, dCDN-2 elected to redirect the >>> delivery to dCDN-3 so it is actually performed by dCDN-3 on behalf >>> of dCDN-2). >>>=20 >>> o the second Logging Record corresponds to a delivery redirected by >>> uCDN to dCDN-2 and performed by dCDN-2 itself. The time of the >>> delivery in this Logging Record may be significantly more recent >>> than the first Logging Record since it was generated locally while >>> the first Logging Record was generated by dCDN-3 and had to be >>> advertised , and then pulled and then ingested into the dCDN-2 >>> Collection process, before being aggregated with the second >>> Logging Record. >>>=20 >>>=20 >>>=20 >>> Cheers >>>=20 >>> Francois >>>=20 >>>=20 >>>=20 >>>>=20 >>>> Thanks >>>>=20 >>>> Francois >>>>=20 >>>> " >>>>=20 >>>> 3.5. CDNI Logging File Example >>>>=20 >>>> Let us consider the upstream CDN and the downstream CDN labelled uCDN >>>> and dCDN-1 in Figure 1. When dCDN-1 acts as a downstream CDN for >>>> uCDN and performs content delivery on behalf of uCDN, dCDN-1 will >>>> include the CDNI Logging Records corresponding to the content >>>> deliveries performed on behalf of uCDN in the CDNI Logging Files for >>>> uCDN. An example CDNI Logging File communicated by dCDN-1 to uCDN is >>>> show below: >>>>=20 >>>> " >>>>=20 >>>> #Version:CDNI/1.0 >>>>=20 >>>> #UUID:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 >>>>=20 >>>> #Claimed-Origin:cdni-logging-entity.dcdn-1.example.com >>>>=20 >>>> #Record-Type:cdni_http_request_v1 >>>>=20 >>>> #Fields:datetimetime-takenc-ipcs- >>>> methodu-uriprotocolsc-statussc-total- >>>> bytescs(User-Agent)cs(Referer)s-cached >>>>=20 >>>> 2013-05-1700:38:06.8259.05810.5.7.1GETh >>>> ttp://cdni-ucdn.dcdn-1.example.com/video/ >>>> movie100.mp4HTTP/1.12006729891"Mozilla/5.0 >>>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>>> Gecko) Chrome/5.0.375.127 Safari >>>> /533.4""host1.example.com"1 >>>>=20 >>>> 2013-05-1700:39:09.14515.3210.5.10.5GET >>>> http://cdni-ucdn.dcdn-1.example.com/video/ >>>> movie118.mp4HTTP/1.120015799210"Mozilla/5.0 >>>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>>> Gecko) Chrome/5.0.375.127 Safari >>>> /533.4""host1.example.com"1 >>>>=20 >>>> 2013-05-1700:42:53.43752.87910.5.10.5GET>>>> http://cdni-ucdn.dcdn-1.example.com/video/ >>>> picture11.mp4HTTP/1.020097234724"Mozilla/5.0 >>>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>>> Gecko) Chrome/5.0.375.127 Safari >>>> /533.4""host5.example.com"0 >>>>=20 >>>> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >>>>=20 >>>> [Editor's Note: compute the correct Integrity-Hash value once example >>>> is frozen] >>>>=20 >>>> " >>>>=20 >>>> As illustrated in Figure 2, uCDN will then ingest the corresponding >>>> CDNI Logging Records into its Collection process, alongside the >>>> Logging Records generated locally by the uCDN itself. This allows >>>> uCDN to aggregate Logging Records for deliveries performed by itself >>>> (through Records generated locally) as well as for deliveries >>>> performed by its downstream CDN(s). This aggregate information can >>>> then be used (after Filtering and Rectification, as illustrated in >>>> Figure 2) by Log Consuming Applications considering deliveries >>>> performed by uCDN as well as by all its downstream CDN(s). >>>>=20 >>>> We observe that the time between >>>>=20 >>>> 1. when a delivery is completed in dCDN and >>>>=20 >>>> 2. when the corresponding Logging Record is ingested by the >>>> Collection process in uCDN >>>>=20 >>>> depends on a number of parameters such as the Logging Period agreed >>>> to by uCDN and dCDN, how much time uCDN waits after it is advertised >>>> in the CDNI Logging Feed before pulling the CDNI Logging File, and >>>> the time to complete the pull of the CDNI Logging File. Therefore, >>>> if we consider the set of Logging Records aggregated by the >>>> Collection process in uCDN in a given time interval, there could be a >>>> permanent significant timing difference between the CDNI Logging >>>> Records received from the dCDN and the Logging Records generated >>>> locally. For example, in a given time interval, the Collection >>>> process in uCDN may be aggregating Logging Records generated locally >>>> by uCDN for deliveries performed in the last hour and CDNI Logging >>>> Records generated in the dCDN for deliveries in the hour before last. >>>>=20 >>>> 3.6. Cascaded CDNI Logging Files Example >>>>=20 >>>> Let us consider the cascaded CDN scenario of uCDN, dCDN-2 and dCDN-3 >>>> as depicted in Figure 1. After completion of a delivery by dCDN-3 on >>>> behalf of dCDN-2, dCDN-3 will include a corresponding Logging Record >>>> in a CDNI Logging File and will advertise this CDNI Logging File to >>>> d-CDN2 in the corresponding CDNI Logging feed. As a result, dCDN-2 >>>> will initiate and complete the pull of the corresponding CDNI Logging >>>> File that is illustrated below: >>>>=20 >>>> " >>>>=20 >>>> #Version:CDNI/1.0 >>>>=20 >>>> #UUID:urn:uuid:65718ef-0123-9876-adce4321bcde >>>>=20 >>>> #Claimed-Origin:cdni-logging-entity.dcdn-3.example.com >>>>=20 >>>> #Record-Type:cdni_http_request_v1 >>>>=20 >>>> #Fields:datetimetime-takenc-ipcs- >>>> methodu-uriprotocolsc-statussc-total- >>>> bytescs(User-Agent)cs(Referer)s-cached >>>>=20 >>>> 2013-05-1700:39:09.14515.3210.5.10.5GET >>>> http://cdni-dcdn-2.dcdn-3.example.com/video/movie118.mp4HTTP/ >>>> 1.120015799210"Mozilla/5.0 (Windows; U; Windows NT >>>> 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 >>>> Safari /533.4""host1.example.com"1 >>>>=20 >>>> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >>>>=20 >>>> [Editor's Note: compute the correct Integrity-Hash value once example >>>> is frozen] >>>>=20 >>>> " >>>>=20 >>>> dCDN-2 (behaving as an upstream CDN from the viewpoint of dCDN-3) >>>> will then ingest the CDNI Logging Record for the considered dCDN-3 >>>> delivery into its Collection process (as illustrated in Figure 2). >>>> This Logging Record may be aggregated with Logging Records generated >>>> locally by dCDN-2 for deliveries performed by dCDN-2 itself. Say, >>>> for illustration, that the content delivery performed by dCDN-3 on >>>> behalf of dCDN-2 had actually been redirected to dCDN-2 by uCDN, and >>>> say that another content delivery has just been redirected by uCDN to >>>> dCDN-2 and that dCDN-2 elected to perform the corresponding delivery >>>> itself. Then after Filtering and Rectification (as illustrated in >>>> Figure 2), dCDN-2 will include the two Logging Records corresponding >>>> respectively to the delivery performed by dCDN-3 and the delivery >>>> performed by dCDN-2, in the next CDNI Logging File that will be >>>> communcated to uCDN. An example of such CDNI Logging File is >>>> illustrated below: >>>>=20 >>>> #Version:CDNI/1.0 >>>>=20 >>>> #UUID:urn:uuid:1234567-8fedc-abab-0987654321ff >>>>=20 >>>> #Claimed-Origin:cdni-logging-entity.dcdn-2.example.com >>>>=20 >>>> #Record-Type:cdni_http_request_v1 >>>>=20 >>>> #Fields:datetimetime-takenc-ipcs- >>>> methodu-uriprotocolsc-statussc-total- >>>> bytescs(User-Agent)cs(Referer)s-cached >>>>=20 >>>> 2013-05-1700:39:09.14515.3210.5.10.5GET >>>> http://cdni-ucdn.dcdn-2.example.com/video/movie118.mp4HTTP/ >>>> 1.120015799210"Mozilla/5.0 (Windows; U; Windows NT >>>> 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 >>>> Safari /533.4""host1.example.com"1 >>>>=20 >>>> 2013-05-1701:42:53.43752.87910.5.10.5GET>>>> http://cdni-ucdn.dcdn-2.example.com/video/picture11.mp4HTTP/ >>>> 1.020097234724"Mozilla/5.0 (Windows; U; Windows NT >>>> 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 >>>> Safari /533.4""host5.example.com"0 >>>>=20 >>>> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >>>>=20 >>>> [Editor's Note: compute the correct Integrity-Hash value once example >>>> is frozen] >>>>=20 >>>> " >>>>=20 >>>> In the example above, we observe that: >>>>=20 >>>> o the first Logging Record corresponds to the Logging Record >>>> communicated earlier to dCDN-2 by dCDN-3, which corresponds to a >>>> delivery redirected by uCDN to dCDN-2 and then redirected by >>>> dCDN-2 to dCDN-3. Its initial fields values are preserved, with >>>> the exception of the u-uri that now reflects the URI convention >>>> between uCDN and dCDN-2, and which presents the delivery to uCDN >>>> as if it was performed by dCDN-2 itself, which reflects the fact >>>> that dCDN-2 had taken the full responsibility of the corresponding >>>> delivery (even if in this case, dCDN-2 elected to redirect the >>>> delivery to dCDN-3 so it is actually performed by dCDN-3 on behalf >>>> of dCDN-2). >>>>=20 >>>> o the second Logging Record corresponds to a delivery redirected by >>>> uCDN to dCDN-2 and performed by dCDN-2 itself. The time of the >>>> delivery in this Logging Record may be significantly more recent >>>> than the first Logging Record since it was generated locally while >>>> the first Logging Record was generated by dCDN-3 and had to be >>>> advertised , and then pulled and then ingested into the dCDN-2 >>>> Collection process, before being aggregated with the second >>>> Logging Record. >>>>=20 >>>> " >>>>=20 >>>>=20 >>>> On 23 Apr 2014, at 20:29, Francois Le Faucheur (flefauch) wrote: >>>>=20 >>>>> Hello, >>>>>=20 >>>>> On 18 Apr 2014, at 23:42, ietfdbh wrote: >>>>>>>=20 >>>>>>> On 5 Apr 2014, at 23:14, ietfdbh wrote: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Most notably, the logging from a dCDN to a uCDN typically contains= only >>>>>>> one >>>>>>>> dCDN identifier, such as Verified-origin, and doesn't really permi= t >>>>>>>> specifying a sub-ordinate dCDN. For example, in a cascade such as = CDN-A >>>>>> - >>>>>>>>=20 >>>>>>>> CDN-B -> CDN-C, CDN-C will share logging info with CDN-B, but not = with >>>>>>>> CDN-A; CDN-B shares logging info with CDN-A. This can be desirable= for >>>>>>>> hiding the topology and delegation used by the dCDN. However, this >>>>>>> document >>>>>>>> does not discuss how the logging provided by CDN-C gets converted = into >>>>>>> the >>>>>>>> logs for CDN-B that will be sent to CDN-A. Without some logging >>>>>>> information >>>>>>>> from CDN-C, it would seem difficult for CDN-A to utilize the infor= mation >>>>>> to >>>>>>>> meet requirements of billing, analytics, and fault and performance >>>>>> analysis. >>>>>>>> Maybe the logging gets aggregated and reported in CDN-B's logging, >>>>>>>=20 >>>>>>> Exactly. >>>>>>>=20 >>>>>>>> but that >>>>>>>> "transitive or aggregate logging" doesn't appear to be discussed i= n this >>>>>>>> document. >>>>>>>=20 >>>>>>> It is discussed in section 2.1 through Figure 1 and the following t= ext: >>>>>>> " >>>>>>> A dCDN (e.g., dCDN-2) integrates the relevant Logging information >>>>>>> obtained from its dCDNs (i.e., dCDN-3) in the Logging information >>>>>>> that it provides to the uCDN, so that the uCDN ultimately obtains a= ll >>>>>>> Logging information relevant to a CSP for which it acts as the >>>>>>> authoritative CDN. >>>>>>> " >>>>>>> Does that address your concern? >>>>>>=20 >>>>>> No it does not mitigate my concern. >>>>>>=20 >>>>>> This says the information gets "integrated", but doesn't describe wh= at >>>>>> integrated means. >>>>>> I could interpret that integration would be that the logging from CD= N-C >>>>>> would be included in the logs from CDN-B to CDN-A, >>>>>> But I think the text says CDN-B will not share the logging entries f= rom >>>>>> CDN-C with CDN-A. >>>>>> Do I have this wrong? Does CDN-B create a log file and generate ent= ries, >>>>>> and then when it delegates delivery to CDN-C, and CDN-C passes its l= og file >>>>>> back to CDN-B, does CDN-B take the whole log file from CDN-B and ins= ert it >>>>>> into its own log file, then continue adding any more entries, and th= en when >>>>>> done send the CDN-B log file (including a fully inserted CDN-C log f= ile) to >>>>>> CDN-A? >>>>>>=20 >>>>>> If not, that presumably means that somehow, the data from CDN-C is >>>>>> "aggregated" - that's how it is "integrated=94, >>>>>=20 >>>>> Right. It is aggregated. >>>>> Effectively, if CDN-B has sub-delegated a delivery to CDN-C, then whe= n CDN-C provides a log record for that delivery to CDN-B, CDN-B will aggreg= ate that log record with the log records for the deliveries that CDN-B cond= uted itself. When CDN-B provides log records to CDN-A, the log record corre= sponding to the delivery performed by CDN-C is turned by CDN-B into a log r= ecord that looks like the delivery was done by CDN-B. CDN-A will not be awa= re that the delivery was performed by another CDN than CDN-B (just like the= Content Provider is not ware that the delivery was not performed by CDN-A = with whom it has a delivery contract). >>>>>=20 >>>>>> But there is no discussion of how this aggregation is done. >>>>>=20 >>>>> That is true. I think it has been assumed by many but never made clea= r. So we need to add some discussion about that. >>>>>=20 >>>>>> I think your intent is to hide the fact that CDN-B used CDN-C, since= that >>>>>> may reflect a proprietary approach of CDN-B's business model. >>>>>=20 >>>>> Right. >>>>>=20 >>>>>> But CDN-A would presumably have problems performing analytics, and f= ault and >>>>>> performance analysis, if the data from CDN-C is not included in CDN-= B's >>>>>> logging to CDN-A.=20 >>>>>> So I would like an example to demonstrate what CDN-A would see in CD= N-B's >>>>>> logs if CDN-C had faults or performance problems, and I would like t= o see >>>>>> how CDN-A could perform analytics (of any kind) relating to the deli= very >>>>>> performed by CDN-C. >>>>>=20 >>>>> The assumption is that CDN-A is only dealing with CDN-B. CDN-A may no= t not even be aware of CDN-C.=20 >>>>> So CDN-A analaytics/monitoring will establish whether all the deliver= ies delegated to CDN-B (comprising deliveries performed by CDN-B as well as= deliveries redirected by CDN-B to CDN-C and possibly CDN-C2) have received= the right quality (ie if CDN-B has met the SLA committed to CDN-A). >>>>> If some deliveries have experienced quality problems, CDN-A will blam= e CDN-B. It is up to CDN-B to then do its own analytics and monitoring to d= ecide whether the problem lies within his own CDN or CDN-C or CDN-C2.=20 >>>>> The whole thing operates as a chain of delegations, like many other b= usiness arrangements: if my SmartPhone does not work, I blame the smartPhon= e vendor (I don=92t try identify if the problem is coming from the supplier= of the GSM chipset, but the SmartPhone vendor will). >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> I am missing how this would be done (especially in a standardized ma= nner). >>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>> I think Verified-Origin is particularly problematic, because the t= ext >>>>>> states >>>>>>>> that this can only be added by the uCDN, never the dCDN. So what i= f >>>>>> CDN-B >>>>>>>> verifies the origin of the logs from CDN-C and then passes the >>>>>> information >>>>>>>> (now as a dCDN) to CDN-A? The text mentions that this might be >>>>>>> established >>>>>>>> using authentication mechanisms; so do we lose this logged >>>>>>>> authentication/verification when cascading? >>>>>>>>=20 >>>>>>>> (Maybe this is resolved by having the uCDN (CDN-B) record a >>>>>> "transaction" >>>>>>>> that starts when it delegates a task to a dCDN (e.g. CDN-C) and en= ds >>>>>> when >>>>>>>> the dCDN completes the task, and the uCDN just records the whole >>>>>>> transaction >>>>>>>> without the details that are reported by CDN-C. Then CDN-B logs on= ly the >>>>>>>> whole transaction. I would like to see an explicit example of such >>>>>> logging, >>>>>>>> using the cdni_http_request_v1 record-type, so this is clear.) >>>>>>>=20 >>>>>>> Yes, that is pretty much the idea. >>>>>>> ie. if CDN-a delegate sto CDN-B then CDB-B is responsible for deliv= ering >>>>>> and >>>>>>> will provide a delivery record to CDN-A for that delivery. That rec= ord >>>>>> will be >>>>>>> part of a Logging File whose origin in CDN-B, and CDN-A can use >>>>>>> authentication mechanism to ensure the Logging File is provided by = CDN-B. >>>>>>> All of this completely holds whether CDN-B performed the delivery i= tself >>>>>>> (and created the delivery record in the first place) or CDN-B deleg= ated to >>>>>>> CDN-C who provided the delivery record to CDN-B in a Logging File w= hose >>>>>>> origin was CDN-C. >>>>>>>=20 >>>>>>> This question has come up before so I will add a clarification alon= g the >>>>>> lines >>>>>>> above under the description of the Verified Origin in case of casca= ded >>>>>> CDNs. >>>>>>=20 >>>>>> An example of such integrated cascaded logging might answer many que= stions. >>>>>=20 >>>>> Good idea.=20 >>>>> It sounds worthwhile to give a descripton of how log records get aggr= egated in a csacaded scenario, indicate how directives/fields get modified/= kept at each CDN hop, and possibly include an example with some log records= and how they propagate from CDN-C to CDN-B to CDN-A. >>>>>=20 >>>>>> If logging records from CDN-C get copied into the log from CDN-B, ar= e all >>>>>> directives and record types copied? >>>>>> If so, I think it is important to make clear that a given log might = contain >>>>>> multiple nested logs, >>>>>> And that means that the file received by CDN-A might start with dire= ctives >>>>>> for CDN-B plus records,=20 >>>>>> And then directives for CDN-C, ending with an Integrity-Hash, and mo= re >>>>>> records for CDN-B followed by an Integrity-Hash. >>>>>> Maybe this is all as designed, but I haven't seen discussion of that= , and it >>>>>> is not reflected in Figure 3, and this is not discussed in the descr= iption >>>>>> of fields that are file-specific, such as Integrity-hash, Verfiied-o= rigin, >>>>>> Version, UUID, etc. >>>>>> If you have nested logs, then log-consuming applications need to kno= w that >>>>>> those file-specific directives un-nest at the end of the included fi= le. Can >>>>>> they tell consistently when they hit the end of the included file? >>>>>> Should there be an end-of-log marker for the included log?=20 >>>>>>=20 >>>>>> The Integrity-Hash directive is allowed to occur zero or once, not m= ultiple >>>>>> times in a logfile. >>>>>> So if the CDN-C logfile contains an Integrity-Hash, should that be c= hecked >>>>>> by CDN-B, then copy the CDN-C logfile into the CDN-B logfile, but di= scard >>>>>> the CDN-C Integrity-Hash, because CDN-B will calculate its own >>>>>> Integrity-Hash directive? >>>>>=20 >>>>> Yes. >>>>>=20 >>>>>>=20 >>>>>>> Let me know if that is not sufficient. >>>>>>=20 >>>>>> I remain concerned that cascaded logging may not have been adequatel= y >>>>>> described and standardized. >>>>>=20 >>>>> Right. I see that the questions you raised were not answered in the d= ocument. We will work on addressing them. >>>>>=20 >>>>> Thanks >>>>>=20 >>>>> Francois >>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Francois >>>>>>=20 >>>>>> dbh >>>>>>=20 >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> 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 >=20 From nobody Thu Jul 17 05:03:28 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B27B41A045B for ; Thu, 17 Jul 2014 05:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zs0bNqhoKyAh for ; Thu, 17 Jul 2014 05:03:27 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA90D1A01DC for ; Thu, 17 Jul 2014 05:03:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=149; q=dns/txt; s=iport; t=1405598607; x=1406808207; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=q6QvxUx7zXw6MNULQ3R51ms8vRXNMYUiBsRFu1+y7+s=; b=VDRoVvjrJzsont+jCBxDF4de4zXuHPbAaAtpsZCTT6Szhct7twfYq568 DDqz7jUDfHh+JXKbaK1ELfzEbWgoVBZtrM8A87yy93B0E20Eq8VsDmBbg Gjz5JqY00WhlqBrHancVspk/gGKyCva0l5/0kc5gBvm4GqVWPoXOeqxM7 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIGAFK6x1OtJA2K/2dsb2JhbABZgw6BLY0evnUWdoQKOlEBPkInBIhVn1SmUBeTAIEYBZsflCyDRIIx X-IronPort-AV: E=Sophos;i="5.01,678,1400025600"; d="scan'208";a="340700353" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-5.cisco.com with ESMTP; 17 Jul 2014 12:03:26 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s6HC3Pva021393 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 17 Jul 2014 12:03:25 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Thu, 17 Jul 2014 07:03:25 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: Slides for IETF-90 Thread-Index: AQHPobccRNYV6qG9w0uGpP6ETNSxUQ== Date: Thu, 17 Jul 2014 12:03:24 +0000 Message-ID: <366BED3E-B042-4307-A4C4-CBAB8BD16F9A@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.106.176] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/G_-IwP-eYP0lN6aPyazWvKW9zJ8 Subject: [CDNi] Slides for IETF-90 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 12:03:27 -0000 To all presenters of the IETF-90 CDNI WG at , Please send Daryl and I your draft slides asap, latest on Sunday. Thanks Francois & Daryl=20 From nobody Fri Jul 18 12:24:35 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B881B2A5C for ; Fri, 18 Jul 2014 12:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.235 X-Spam-Level: X-Spam-Status: No, score=0.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxPkUMgVXAXa for ; Fri, 18 Jul 2014 12:13:36 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 584F61B2A5B for ; Fri, 18 Jul 2014 12:13: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 s6IJDXnC030993 for ; Fri, 18 Jul 2014 13:13:33 -0600 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Fri, 18 Jul 2014 13:13:33 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([::1]) by EXCHANGE.cablelabs.com ([::1]) with mapi id 14.03.0195.001; Fri, 18 Jul 2014 13:13:33 -0600 From: Daryl Malas To: "cdni@ietf.org" Thread-Topic: [CDNi] FW: IETF 90 - Remote Participation Thread-Index: AQHPorxdvKl/a6sBnEmK49MX1uGLqg== Date: Fri, 18 Jul 2014 19:13:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.4.0.105] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <75E85FFBD60A134FBE19E9FC9BDD725E@cablelabs.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/QFyun3O91K4fvTPeU9D94JYnEZE Subject: [CDNi] FW: IETF 90 - Remote Participation X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 19:13:37 -0000 FYI On 7/17/14, 1:00 PM, "IETF Secretariat" wrote: >Can=B9t make it to Toronto? Participate remotely! The IETF offers a number >of ways for remote attendees to audit or even contribute to IETF sessions >throughout the meeting week. > >First, register for the meeting. There is no cost to register as a remote >attendee and by registering you will insure that you receive important >updates on agenda changes and other things of interest to meeting >attendees. Please register here: >http://www.ietf.org/meeting/register.html and select =B3remote participant= =B2 >as your registration type. > >General remote participation information can be found here: >http://www.ietf.org/meeting/90/remote-participation.html. Below is a >breakdown of some of the main services available. > >1) Meetecho=20 >The Meetecho platform provides a synchronized view of the audio/video >stream from the meeting room, which includes slides being presented and >the presenter, as well as official IETF Jabber room. Meetecho will be >supporting six of the eight concurrent working session tracks, along with >both the Administrative and Technical plenaries. If you have a comment or >a question, Meetecho enables you to ask it even if you are not in the >room. In addition, Meetecho will be streaming many of the Sunday >tutorials sessions. For more information on how to join a Meetecho >session, or to watch a recording after the session has concluded, see >here:http://ietf90.conf.meetecho.com/. > >2) Audio Stream >If you only want to listen to the sessions (or if the session you are >interested in isn=B9t supported by Meetecho), the audio stream is a good >choice. All working sessions are streamed; see here for more >channel-to-room assignments: >http://www.ietf.org/meeting/90/remote-participation.html#audio. > >3) Jabber Rooms >All IETF meeting sessions have a corresponding Jabber room. See here for >link to the meeting agenda with corresponding Jabber rooms: >http://tools.ietf.org/agenda/90/. Whenever possible, an in-room volunteer >monitors the Jabber room; this volunteer will stand at the microphone for >remote attendees and relay their questions into the meeting room >microphone so that people in the room can respond. More information on >the IETF Jabber service is available here: http://www.ietf.org/jabber/. > >4) Mailing Lists >The 90attendees@ietf.org is for general discussion of things happening at >the meeting; join the list if you want to hear about Toronto restaurants, >meeting room temperatures and other topics of interest to those who are >physically present at the meeting. Subscribe to 90attendees here: >https://www.ietf.org/mailman/listinfo/90attendees. > >The 90all@ietf.org list is for important announcements only and is not a >discussion list. You automatically subscribed when you register as a >remote participant. Being on 90all is essential if you want to hear about >changes to meeting agenda or other important announcements. Subscribe to >90all here: https://www.ietf.org/mailman/listinfo/90all. > >5) Live Video and Text Streaming of the Technical Plenary on Monday, July >21st. The technical topic is network topology and geography. See >http://www.ietf.org/live/ for more information. > >After the meeting we will be sending a survey to all remote participants >to get feedback on their experience; if you participate remotely, we=B9d >love to hear from you! And don=B9t forget to follow @ietf on Twitter! > >Only 3 days until the Toronto IETF! > From nobody Sun Jul 20 12:52:01 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA691B27BC for ; Sun, 20 Jul 2014 12:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.704 X-Spam-Level: X-Spam-Status: No, score=-0.704 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byfW10_TQC0z for ; Sun, 20 Jul 2014 12:51:52 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A66191A0B0C for ; Sun, 20 Jul 2014 12:51:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 6EDC71005E4; Sun, 20 Jul 2014 21:51:51 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M65LpcpHrpIF; Sun, 20 Jul 2014 21:51:51 +0200 (CEST) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id AD619100575; Sun, 20 Jul 2014 21:51:35 +0200 (CEST) Received: from HYDRA.office.hd ([169.254.4.11]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Sun, 20 Jul 2014 21:51:35 +0200 From: Jan Seedorf To: "cdni@ietf.org" Thread-Topic: Side meeting on CDNI FCI at IETF90 Thread-Index: Ac+kU3YOW5EKP87iScawnkDjWdO7SQ== Date: Sun, 20 Jul 2014 19:51:35 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE8E05A353@Hydra.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.198] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/cfFU4u7cetWjFmg6ruWGQnyo4ys Cc: "Kevin J Ma \(kevin.ma@azukisystems.com\)" Subject: [CDNi] Side meeting on CDNI FCI at IETF90 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 20 Jul 2014 19:51:55 -0000 Dear all, Kevin, Jon, and I are meeting tomorrow (MON, July 21) at 15:20 (at the IETF= registration desk) to discuss progress of the CDNI FCI documents. This is = an informal meeting, but of course anyone interested in this interface or t= he discussion is invited to join. - Jan =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr. Jan Seedorf Senior Researcher NEC Europe Ltd., NEC Laboratories Europe, Network Division=A0=A0=A0=A0=A0 Kurfuerstenanlage 36, D-69115 Heidelberg Tel.=A0=A0=A0=A0 +49 (0)6221 4342-221 Fax:=A0=A0=A0=A0 +49 (0)6221 4342-155 e-mail:=A0 jan.seedorf@neclab.eu =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NEC Europe Ltd, Registered Office: Athene, Odyssey Business Park, West End = Road, London, HA4 6QE, GB, Registered in England 2832014 From nobody Sun Jul 20 20:18:27 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC291B2B44 for ; Sun, 20 Jul 2014 20:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.548 X-Spam-Level: X-Spam-Status: No, score=-1.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G_t4d2xosj2h for ; Sun, 20 Jul 2014 20:18:19 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AC951B2B27 for ; Sun, 20 Jul 2014 20:18:18 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 730E122D7D3 for ; Mon, 21 Jul 2014 05:18:16 +0200 (CEST) Received: from PMEXCH51.intranet-paris.francetelecom.fr (unknown [10.100.76.23]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 5EE45238048 for ; Mon, 21 Jul 2014 05:18:16 +0200 (CEST) Received: from PMEXCB1D.intranet-paris.francetelecom.fr ([10.100.76.9]) by PMEXCH51.intranet-paris.francetelecom.fr ([10.100.76.23]) with mapi; Mon, 21 Jul 2014 05:18:15 +0200 From: To: "cdni@ietf.org" Date: Mon, 21 Jul 2014 05:18:14 +0200 Thread-Topic: [CDNI] FCI analysis Thread-Index: Ac+kkmimU+WLUk38TUW/wMYyeNTCQQ== Message-ID: <14527_1405912696_53CC8678_14527_6881_1_8F0D2F5E4AAB7249BC7339A3E944DEDD228CE579CD@PMEXCB1D.intranet-paris.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_8F0D2F5E4AAB7249BC7339A3E944DEDD228CE579CDPMEXCB1Dintra_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.21.20323 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/TF_We2hWkUOHEA3_0m-PkjK1QsM Subject: [CDNi] [CDNI] FCI analysis X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 03:18:23 -0000 --_000_8F0D2F5E4AAB7249BC7339A3E944DEDD228CE579CDPMEXCB1Dintra_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello CDNI fellows, [It seems I missed posting this directly to the working group mailing list,= so there it is now] Here goes the analysis of the Footprint and Capabilities semantics draft. S= orry for taking holidays just before the IETF, I didn't get around to this = doing this earlier. Hope it helps in taking us closer to WGLC. FCI Semantics, draft-ietf-cdni-footprint-capabilities-semantics-02 ---------------------------------------------------------------------------= ---- The purpose of the draft is to define the type of information a dCDN advert= ises regarding its footprint and capabilities. It states that "it is explic= itly outside the scope of this document to decide on specific protocols to = use for the FCI." It relies on the basic assumption that a bootstrapping pr= ocess has already been done between the uCDN and the set of dCDNs that are = interconnecting. Also, it assumes that footprint and capabilities need not = use the same protocol and that the uCDN directly receives the initial reque= st-routing request from the endpoint demanding the resource. Section 2: Design Decisions for Footprint and Capabilities Emphasizes the need to understand the definition of footprint in terms of "= coverage" and "reachability." The draft also mentions that global CDNs can = have global reachability (through IP connectivity) but CDNs with a more lim= ited coverage are suitable for the CDNi use cases. It states that "capabili= ties with footprint" versus "footprint with capabilities" semantics should = be adapted to the respective use case. 1) Advertising Limited Coverage There is an example of two regional ISPs that both have CDNs : one CDN belo= ngs to the ISP of the customer E (making the content demand) and the other = is the CDN that can offer better coverage to the customer E. Which CDN shou= ld serve the request still remains a dilemma. Same interrogation is valid f= or overlapping footprints advertised by several dCDNS. To answer the dilemma above, a "score" notion is introduced in order to be = able to rank the quality of the dCDN's service, preferably on the same scal= e. The conclusion is that coverage need not be binary. 2) Capabilities and Dynamic Data When footprints overlap, a uCDN might want to evaluate some extra merits of= the competing dCDNs. These criteria include state of the caches, network q= uality and policies, bandwidth etc. that can be highly volatile parameters. 3) Advertisement versus Queries Scalability issues may arise if the volume of FCI updates exceeds the volum= e of content requests to the uCDN. The advantage of a model based on synchr= onous queries is that the uCDN can operate in a stateless way (doesn't need= to keep track of dCDNs status). Choice to be made on a per use case basis. 4) Avoiding or Handling "cheating" dCDNs It's desirable to have a way for the uCDN to qualitatively verify the FCI i= nfo advertised by the dCDNs. Possibly non-real-time out-of-band audits. 5) Focus on Main Use Cases May Simplify Things To narrow down FCI semantics, might be better to pick some real life deploy= ments and tailor according to that. Section 3: Main Use Case to Consider Asks questions about practicalities in a simplified use case: uCDN has two = dCDNs out of which one has another level-2 dCDN. How does the uCDN take int= o account failures/changes of the level-2 dCDN? How does uCDN handle subset= s of the footprint initially served by one of its dCDNs? Section 4: Semantics for Footprint Advertisement Roughly, footprint =3D ability and willingness to serve. How well a dCDN ca= n serve requests is another piece of information that could be added to the= footprint, but will be mostly associated to contractual agreements. Assuming that the initial footprint is established in the contract, FCI pro= vides changes and updates to the previously agreed footprint. The draft fur= ther considers two types of footprint: coverage/reachability (3 types manda= tory to support by FCI: set of IP prefixes, list of AS numbers, country ISO= codes) and resources (location of the surrogates). Section 5: Semantics for Capabilities Advertisement In certain cases, footprint and capabilities cannot be interpreted separate= ly: need to associate the coverage of a geographical region with a certain = delivery protocol. In such cases, it should be possible to combine footprin= t and capabilities advertisements. Advertisement of highly dynamic capabilities is out of scope. Just like for= the footprint, the capabilities advertisement refers to conveying informat= ion to a uCDN about changes/updates with respect to a given contract. Defined "base" capabilities: o Delivery Protocol (HTTP, RTMP) o Acquisition Protocol o Redirection Mode (DNS, HTTP) o Capabilities related to CDNI Logging o Capabilities related to CDNI Metadata The FCI spec should define a generic protocol for sending this type of info= rmation and should allow for the list above to be further expanded if neede= d. 6. Negotiation of Support for Optional Types of Footprint/Capabilities Need to specify the behavior of CDNs that do not support the optional types= of footprint/capabilities : how to react in case of failure? The uCDN can = ignore or select dCDN based only on the parameters it understands. 7. IANA Considerations Requires a new IANA registry "CDNI Capabilities"; this namespace should be = split into standard (for Mandatory To Implement) and optional. A table prov= ides the initial standard partition: Delivery Protocol, Acquisition Protoco= l and Redirection Mode. The optional partition conforms to Expert Review po= licy. No IANA action required for the defined Footprint Sub-Registry or the Proto= col Sub-Registry. A table defines the initial Redirection Modes: Iterative = DNS, Recursive DNS, Iterative HTTP, Recursive HTTP. 8. Security Considerations This section still needs to be done, as there is not much text. Comments: The main purpose of the draft is to say what people understand when they sa= y footprint or capabilities. It does a pretty good job at narrowing down th= e concepts and explaining the implications of the wider notions. There are = several examples provided regarding the basic set we should be considering = in CDNI. I think the draft needs a bit more work in the following points: 1. It's not very clear from the draft how a footprint advertisement o= f resources (location of surrogate nodes) would work and in what practical = context. 2. The draft states that the FCI specification should define a generi= c protocol for conveying any capability information. Maybe we should be mor= e precise of what are the requirements for such a protocol and what it is s= trictly expected to do. What scale of time/reactivity for such a protocol? 3. There is still a note in the document (end of section 5) about sup= port for logging configuration (control vs. metadata). 4. There is still a note in section 7 about logging and metadata: inc= lude these capabilities in the table. The notes from the meeting in London = say something like "Kevin Ma: We still need to add capabilities for optiona= l logging and (if any) for optional metadata fields." 5. The Security considerations section says "to be discussed in a fut= ure version". See you in Toronto! -- iuniana ___________________________________________________________________________= ______________________________________________ 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. --_000_8F0D2F5E4AAB7249BC7339A3E944DEDD228CE579CDPMEXCB1Dintra_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello CDNI fellows,=

 

[It seems I missed posting this directly to the work= ing group mailing list, so there it is now]

 

Here goes the analysis of = the Footprint and Capabilities semantics draft. Sorry for taking holidays j= ust before the IETF, I didn’t get around to this doing this earlier. = Hope it helps in taking us closer to WGLC.

 

FCI Semantics, draft-ietf-cd= ni-footprint-capabilities-semantics-02=

= ---------------------------------------------------------------------------= ----

 

The purpose of the draft is to define the type of information a dC= DN advertises regarding its footprint and capabilities. It states that R= 20;it is explicitly outside the scope of this document to decide on specifi= c protocols to use for the FCI.” It relies on the basic assumption th= at a bootstrapping process has already been done between the uCDN and the s= et of dCDNs that are interconnecting. Also, it assumes that footprint and c= apabilities need not use the same protocol and that the uCDN directly recei= ves the initial request-routing request from the endpoint demanding the res= ource.

 

Section 2: Design Decisions for Footprint and Capabilities

Emphasizes the need to understand the defi= nition of footprint in terms of “coverage” and “reachabil= ity.” The draft also mentions that global CDNs can have global reacha= bility (through IP connectivity) but CDNs with a more limited coverage are = suitable for the CDNi use cases. It states that “capabilities with fo= otprint” versus “footprint with capabilities” semantics s= hould be adapted to the respective use case.=

 

1)      = Advertising Limited Co= verage

There is an example= of two regional ISPs that both have CDNs : one CDN belongs to the ISP of t= he customer E (making the content demand) and the other is the CDN that can= offer better coverage to the customer E. Which CDN should serve the reques= t still remains a dilemma. Same interrogation is valid for overlapping foot= prints advertised by several dCDNS.

To answer the dilemma above,= a “score” notion is introduced in order to be able to rank the= quality of the dCDN’s service, preferably on the same scale. The con= clusion is that coverage need not be binary.

 

2)&nbs= p;     Capabilities and Dynamic Data

When footprints overlap, a uCDN might want to= evaluate some extra merits of the competing dCDNs. These criteria include = state of the caches, network quality and policies, bandwidth etc. that can = be highly volatile parameters.

 

3)   &= nbsp;  Advertisement versus Queries

Scalability issues may arise if the volume of FCI updates excee= ds the volume of content requests to the uCDN. The advantage of a model bas= ed on synchronous queries is that the uCDN can operate in a stateless way (= doesn’t need to keep track of dCDNs status). Choice to be made on a p= er use case basis.

 

4)<= span style=3D'font:7.0pt "Times New Roman"'>      = A= voiding or Handling “cheating” dCDNs

It’s desirable to have a way for the uCDN to qua= litatively verify the FCI info advertised by the dCDNs. Possibly non-real-t= ime out-of-band audits.

&nbs= p;

5)  &n= bsp;   Focus on Main Use Cases May Simplify Things

To na= rrow down FCI semantics, might be better to pick some real life deployments= and tailor according to that.

 

Section 3: Main Use Case to Consider

Asks questions about practicalities in a simplified use case: uCDN h= as two dCDNs out of which one has another level-2 dCDN. How does the uCDN t= ake into account failures/changes of the level-2 dCDN? How does uCDN handle= subsets of the footprint initially served by one of its dCDNs?

 =

Section= 4: Semantics for Footprint Advertisement

Roughly, footprint =3D = ability and willingness to serve. How well a dCDN can serve requests is ano= ther piece of information that could be added to the footprint, but will be= mostly associated to contractual agreements.

Assuming that the initial footprint is established in the contract, = FCI provides changes and updates to the previously agreed footprint. The dr= aft further considers two types of footprint: coverage/reachability (3 type= s mandatory to support by FCI: set of IP prefixes, list of AS numbers, coun= try ISO codes) and resources (location of the surrogates).

 

<= p class=3DMsoNormal>Section 5: S= emantics for Capabilities Advertisement

In certain cases, footpri= nt and capabilities cannot be interpreted separately: need to associate the= coverage of a geographical region with a certain delivery protocol. In suc= h cases, it should be possible to combine footprint and capabilities advert= isements.

Advertisement of highly dynam= ic capabilities is out of scope. Just like for the footprint, the capabilit= ies advertisement refers to conveying information to a uCDN about changes/u= pdates with respect to a given contract.

Defined “base” capabilities: <= /o:p>

           &nbs= p;    o Delivery Protocol (HTTP, RTMP)

          =       o Acqui= sition Protocol

          &= nbsp;     o Redirection Mode (DNS, HTTP)

   = ;             <= /span>o Capabilities related to = CDNI Logging

    &n= bsp;           o Capabili= ties related to CDNI Metadata

The FCI s= pec should define a generic protocol for sending this type of information a= nd should allow for the list above to be further expanded if needed.=

 

6.= Negotiation of Support for Optional Types of Footprint/Capabilities=

Need to specify the behavior of CDNs that do = not support the optional types of footprint/capabilities : how to react in = case of failure? The uCDN can ignore or select dCDN based only on the param= eters it understands.

 

7. IANA Considerations<= o:p>

Requires a new IANA registry “CDNI Capabilities”; thi= s namespace should be split into standard (for Mandatory To Implement) and = optional. A table provides the initial standard partition: Delivery Protoco= l, Acquisition Protocol and Redirection Mode. The optional partition confor= ms to Expert Review policy.

=

No IANA act= ion required for the defined Footprint Sub-Registry or the Protocol Sub-Reg= istry. A table defines the initial Redirection Modes: Iterative DNS, Recurs= ive DNS, Iterative HTTP, Recursive HTTP.

 

8. Security Considerations

This section still needs to be done, as th= ere is not much text.

 

Comments:

The= main purpose of the draft is to say what people understand when they say f= ootprint or capabilities. It does a pretty good job at narrowing down the c= oncepts and explaining the implications of the wider notions. There are sev= eral examples provided regarding the basic set we should be considering in = CDNI.

=  =

I think the draft needs a bit more work in the following points:=

1.    &nb= sp;  It’s not very clear from the draft how a footprint advertise= ment of resources (location of surrogate nodes) would work and in what prac= tical context.

2.       <= /span>The draft states= that the FCI specification should define a generic protocol for conveying = any capability information. Maybe we should be more precise of what are the= requirements for such a protocol and what it is strictly expected to do. W= hat scale of time/reactivity for such a protocol?

3.       There= is still a note in the document (end of section 5) about support for loggi= ng configuration (control vs. metadata).

4.  &= nbsp;    There is still a note in section 7 about logging and= metadata: include these capabilities in the table. The notes from the meet= ing in London say something like “Kevin Ma:= We still need to add capabilities for optional logging and (if any) for op= tional metadata fields.”

5.       The Security consideratio= ns section says “to be discussed in a future version”.

 

See you in Toronto!

= -- iuniana

 

 

 

____________________________________________________________________=
_____________________________________________________

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.
= --_000_8F0D2F5E4AAB7249BC7339A3E944DEDD228CE579CDPMEXCB1Dintra_-- From nobody Sun Jul 20 21:02:11 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3381A0338; Sun, 20 Jul 2014 21:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1chd_z_zYMO; Sun, 20 Jul 2014 21:02:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 21A1F1B2A46; Sun, 20 Jul 2014 21:02:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140721040206.9801.67329.idtracker@ietfa.amsl.com> Date: Sun, 20 Jul 2014 21:02:06 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/teoJmNzSlaxqlStxwCxeGaMuclE Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-footprint-capabilities-semantics-03.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 04:02:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Content Delivery Networks Interconnection Working Group of the IETF. Title : CDNI Request Routing: Footprint and Capabilities Semantics Authors : Jan Seedorf Jon Peterson Stefano Previdi Ray van Brandenburg Kevin J. Ma Filename : draft-ietf-cdni-footprint-capabilities-semantics-03.txt Pages : 18 Date : 2014-07-20 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-semantics/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-footprint-capabilities-semantics-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-footprint-capabilities-semantics-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 21 05:21:48 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59FC51B2DD0 for ; Mon, 21 Jul 2014 05:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKUJU21UZ2kh for ; Mon, 21 Jul 2014 05:21:37 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FD521B2C52 for ; Mon, 21 Jul 2014 05:21:36 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-20-53ccb0850171 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 8A.5B.25146.580BCC35; Mon, 21 Jul 2014 08:17:42 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0174.001; Mon, 21 Jul 2014 08:21:34 -0400 From: Kevin Ma J To: "iuniana.oprescu@orange.com" , "cdni@ietf.org" Thread-Topic: [CDNi] [CDNI] FCI analysis Thread-Index: Ac+kkmimU+WLUk38TUW/wMYyeNTCQQAS3IMg Date: Mon, 21 Jul 2014 12:21:33 +0000 Message-ID: References: <14527_1405912696_53CC8678_14527_6881_1_8F0D2F5E4AAB7249BC7339A3E944DEDD228CE579CD@PMEXCB1D.intranet-paris.francetelecom.fr> In-Reply-To: <14527_1405912696_53CC8678_14527_6881_1_8F0D2F5E4AAB7249BC7339A3E944DEDD228CE579CD@PMEXCB1D.intranet-paris.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_A419F67F880AB2468214E154CB8A55628C3F66eusaamb103ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyuXRPgm7bhjPBBk+fcVo8nf2H1eLwh8vs DkweS5b8ZPJoeXaSLYApissmJTUnsyy1SN8ugStj1hrbgu4pTBX/T55mb2A88Z6xi5GTQ0LA ROLytLusELaYxIV769m6GLk4hASOMkqcXNXBDOEsZ5S4sWgbWBWbgJbE469/mUBsEYEEia4p 7WwgtrCAusSXPV+BajiA4hoSN08ZQZQYSbxZPoMdxGYRUJWYf+c7M4jNK+At0bDuCdSyDqBl P88wgTicAp2MEotm7gFbwAh00vdTa8BsZgFxiVtP5jNBnCogsWTPeWYIW1Ti5eN/UC8oScx5 fY0Zoj5f4sCi1UwQ2wQlTs58wjKBUWQWklGzkJTNQlIGEdeRWLD7ExuErS2xbOFrZhj7zIHH TMjiCxjZVzFylBanluWmGxluYgTG0DEJNscdjAs+WR5iFOBgVOLhTTh9OliINbGsuDL3EKM0 B4uSOK9m9bxgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYy51Xbtt1hU/x8r/y+Znt7if7Ql Y23A9alTOTrePXl4bO2phZzzd/7TXP263Ui/TuXVqTjD9VvNKu7d+dnf87ZxrWHe9rX7WDo4 LTWabF9sKXNKP3hlj8u0RWLMS484Ve2tOxaeLGjRIKdbeFAyN9lenpH3ZsD6c9/Oz9tWfMr+ acKtMywi/cuUWIozEg21mIuKEwG/1KZIggIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/LP8999xBdfj_kSYhBDqkUYTcMtk Subject: Re: [CDNi] [CDNI] FCI analysis X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 12:21:45 -0000 --_000_A419F67F880AB2468214E154CB8A55628C3F66eusaamb103ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Iuniana, Thanx for the review. wrt comments 3/4 logging/metadata capabilities: those were addressed in t= he latest version that was just uploaded. We will review and address the other comments in= the next version. thanx! -- Kevin J. Ma From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of iuniana.oprescu@oran= ge.com Sent: Sunday, July 20, 2014 11:18 PM To: cdni@ietf.org Subject: [CDNi] [CDNI] FCI analysis Hello CDNI fellows, [It seems I missed posting this directly to the working group mailing list,= so there it is now] Here goes the analysis of the Footprint and Capabilities semantics draft. S= orry for taking holidays just before the IETF, I didn't get around to this = doing this earlier. Hope it helps in taking us closer to WGLC. FCI Semantics, draft-ietf-cdni-footprint-capabilities-semantics-02 ---------------------------------------------------------------------------= ---- The purpose of the draft is to define the type of information a dCDN advert= ises regarding its footprint and capabilities. It states that "it is explic= itly outside the scope of this document to decide on specific protocols to = use for the FCI." It relies on the basic assumption that a bootstrapping pr= ocess has already been done between the uCDN and the set of dCDNs that are = interconnecting. Also, it assumes that footprint and capabilities need not = use the same protocol and that the uCDN directly receives the initial reque= st-routing request from the endpoint demanding the resource. Section 2: Design Decisions for Footprint and Capabilities Emphasizes the need to understand the definition of footprint in terms of "= coverage" and "reachability." The draft also mentions that global CDNs can = have global reachability (through IP connectivity) but CDNs with a more lim= ited coverage are suitable for the CDNi use cases. It states that "capabili= ties with footprint" versus "footprint with capabilities" semantics should = be adapted to the respective use case. 1) Advertising Limited Coverage There is an example of two regional ISPs that both have CDNs : one CDN belo= ngs to the ISP of the customer E (making the content demand) and the other = is the CDN that can offer better coverage to the customer E. Which CDN shou= ld serve the request still remains a dilemma. Same interrogation is valid f= or overlapping footprints advertised by several dCDNS. To answer the dilemma above, a "score" notion is introduced in order to be = able to rank the quality of the dCDN's service, preferably on the same scal= e. The conclusion is that coverage need not be binary. 2) Capabilities and Dynamic Data When footprints overlap, a uCDN might want to evaluate some extra merits of= the competing dCDNs. These criteria include state of the caches, network q= uality and policies, bandwidth etc. that can be highly volatile parameters. 3) Advertisement versus Queries Scalability issues may arise if the volume of FCI updates exceeds the volum= e of content requests to the uCDN. The advantage of a model based on synchr= onous queries is that the uCDN can operate in a stateless way (doesn't need= to keep track of dCDNs status). Choice to be made on a per use case basis. 4) Avoiding or Handling "cheating" dCDNs It's desirable to have a way for the uCDN to qualitatively verify the FCI i= nfo advertised by the dCDNs. Possibly non-real-time out-of-band audits. 5) Focus on Main Use Cases May Simplify Things To narrow down FCI semantics, might be better to pick some real life deploy= ments and tailor according to that. Section 3: Main Use Case to Consider Asks questions about practicalities in a simplified use case: uCDN has two = dCDNs out of which one has another level-2 dCDN. How does the uCDN take int= o account failures/changes of the level-2 dCDN? How does uCDN handle subset= s of the footprint initially served by one of its dCDNs? Section 4: Semantics for Footprint Advertisement Roughly, footprint =3D ability and willingness to serve. How well a dCDN ca= n serve requests is another piece of information that could be added to the= footprint, but will be mostly associated to contractual agreements. Assuming that the initial footprint is established in the contract, FCI pro= vides changes and updates to the previously agreed footprint. The draft fur= ther considers two types of footprint: coverage/reachability (3 types manda= tory to support by FCI: set of IP prefixes, list of AS numbers, country ISO= codes) and resources (location of the surrogates). Section 5: Semantics for Capabilities Advertisement In certain cases, footprint and capabilities cannot be interpreted separate= ly: need to associate the coverage of a geographical region with a certain = delivery protocol. In such cases, it should be possible to combine footprin= t and capabilities advertisements. Advertisement of highly dynamic capabilities is out of scope. Just like for= the footprint, the capabilities advertisement refers to conveying informat= ion to a uCDN about changes/updates with respect to a given contract. Defined "base" capabilities: o Delivery Protocol (HTTP, RTMP) o Acquisition Protocol o Redirection Mode (DNS, HTTP) o Capabilities related to CDNI Logging o Capabilities related to CDNI Metadata The FCI spec should define a generic protocol for sending this type of info= rmation and should allow for the list above to be further expanded if neede= d. 6. Negotiation of Support for Optional Types of Footprint/Capabilities Need to specify the behavior of CDNs that do not support the optional types= of footprint/capabilities : how to react in case of failure? The uCDN can = ignore or select dCDN based only on the parameters it understands. 7. IANA Considerations Requires a new IANA registry "CDNI Capabilities"; this namespace should be = split into standard (for Mandatory To Implement) and optional. A table prov= ides the initial standard partition: Delivery Protocol, Acquisition Protoco= l and Redirection Mode. The optional partition conforms to Expert Review po= licy. No IANA action required for the defined Footprint Sub-Registry or the Proto= col Sub-Registry. A table defines the initial Redirection Modes: Iterative = DNS, Recursive DNS, Iterative HTTP, Recursive HTTP. 8. Security Considerations This section still needs to be done, as there is not much text. Comments: The main purpose of the draft is to say what people understand when they sa= y footprint or capabilities. It does a pretty good job at narrowing down th= e concepts and explaining the implications of the wider notions. There are = several examples provided regarding the basic set we should be considering = in CDNI. I think the draft needs a bit more work in the following points: 1. It's not very clear from the draft how a footprint advertisement o= f resources (location of surrogate nodes) would work and in what practical = context. 2. The draft states that the FCI specification should define a generi= c protocol for conveying any capability information. Maybe we should be mor= e precise of what are the requirements for such a protocol and what it is s= trictly expected to do. What scale of time/reactivity for such a protocol? 3. There is still a note in the document (end of section 5) about sup= port for logging configuration (control vs. metadata). 4. There is still a note in section 7 about logging and metadata: inc= lude these capabilities in the table. The notes from the meeting in London = say something like "Kevin Ma: We still need to add capabilities for optiona= l logging and (if any) for optional metadata fields." 5. The Security considerations section says "to be discussed in a fut= ure version". See you in Toronto! -- iuniana ___________________________________________________________________________= ______________________________________________ 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. --_000_A419F67F880AB2468214E154CB8A55628C3F66eusaamb103ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Iuniana,

 

  Thanx for the review.<= /p>

  wrt comments 3/4 logging/metadata capabi= lities: those were addressed in the latest version

  that was just uploaded.  We will re= view and address the other comments in the next version.<= /p>

 

thanx!

 

--  Kevin J. Ma

 

From: CDNi [mailto:cdni-bounces@ietf.org] = On Behalf Of iuniana.oprescu@orange.com
Sent: Sunday, July 20, 2014 11:18 PM
To: cdni@ietf.org
Subject: [CDNi] [CDNI] FCI analysis

 

Hello CDNI fellows,

 

[It seems I missed pos= ting this directly to the working group mailing list, so there it is now]

 

Here goes the analysis= of the Footprint and Capabilities semantics draft. Sorry for taking holida= ys just before the IETF, I didn’t get around to this doing this earli= er. Hope it helps in taking us closer to WGLC.

 

FCI Semantics, draft-i= etf-cdni-footprint-capabilities-semantics-02

----------------------= ---------------------------------------------------------=

 

The purpose of the dra= ft is to define the type of information a dCDN advertises regarding its foo= tprint and capabilities. It states that “it is explicitly outside the= scope of this document to decide on specific protocols to use for the FCI.” It relies on the basic assumption tha= t a bootstrapping process has already been done between the uCDN and the se= t of dCDNs that are interconnecting. Also, it assumes that footprint and ca= pabilities need not use the same protocol and that the uCDN directly receives the initial request-routing request fr= om the endpoint demanding the resource.

 

Section 2: Design Deci= sions for Footprint and Capabilities

Emphasizes the need to= understand the definition of footprint in terms of “coverage” = and “reachability.” The draft also mentions that global CDNs ca= n have global reachability (through IP connectivity) but CDNs with a more limited coverage are suitable for the CDNi use cases. It state= s that “capabilities with footprint” versus “footprint wi= th capabilities” semantics should be adapted to the respective use ca= se.

 

1)      Advertising Li= mited Coverage<= /span>

There is an example of= two regional ISPs that both have CDNs : one CDN belongs to the ISP of the = customer E (making the content demand) and the other is the CDN that can of= fer better coverage to the customer E. Which CDN should serve the request still remains a dilemma. Same interr= ogation is valid for overlapping footprints advertised by several dCDNS.

To answer the dilemma = above, a “score” notion is introduced in order to be able to ra= nk the quality of the dCDN’s service, preferably on the same scale. T= he conclusion is that coverage need not be binary.

 

2)      Capabilities a= nd Dynamic Data

When footprints overla= p, a uCDN might want to evaluate some extra merits of the competing dCDNs. = These criteria include state of the caches, network quality and policies, b= andwidth etc. that can be highly volatile parameters.

 

3)      Advertisement = versus Queries<= /span>

Scalability issues may= arise if the volume of FCI updates exceeds the volume of content requests = to the uCDN. The advantage of a model based on synchronous queries is that = the uCDN can operate in a stateless way (doesn’t need to keep track of dCDNs status). Choice to be made = on a per use case basis.

 

4)      Avoiding or Ha= ndling “cheating” dCDNs

It’s desirable t= o have a way for the uCDN to qualitatively verify the FCI info advertised b= y the dCDNs. Possibly non-real-time out-of-band audits.

 

5)&n= bsp;     Focus on Main = Use Cases May Simplify Things

To narrow down FCI sem= antics, might be better to pick some real life deployments and tailor accor= ding to that.

 

Section 3: Main Use Ca= se to Consider

Asks questions about p= racticalities in a simplified use case: uCDN has two dCDNs out of which one= has another level-2 dCDN. How does the uCDN take into account failures/cha= nges of the level-2 dCDN? How does uCDN handle subsets of the footprint initially served by one of its dCDNs?

 

Section 4: Semantics f= or Footprint Advertisement

Roughly, footprint =3D= ability and willingness to serve. How well a dCDN can serve requests is an= other piece of information that could be added to the footprint, but will b= e mostly associated to contractual agreements.

Assuming that the init= ial footprint is established in the contract, FCI provides changes and upda= tes to the previously agreed footprint. The draft further considers two typ= es of footprint: coverage/reachability (3 types mandatory to support by FCI: set of IP prefixes, list of AS numbe= rs, country ISO codes) and resources (location of the surrogates).

 

Section 5: Semantics f= or Capabilities Advertisement

In certain cases, foot= print and capabilities cannot be interpreted separately: need to associate = the coverage of a geographical region with a certain delivery protocol. In = such cases, it should be possible to combine footprint and capabilities advertisements.

Advertisement of highl= y dynamic capabilities is out of scope. Just like for the footprint, the ca= pabilities advertisement refers to conveying information to a uCDN about ch= anges/updates with respect to a given contract.

Defined “base= 221; capabilities:

   &nbs= p;            o Deli= very Protocol (HTTP, RTMP)

   &nbs= p;            o Acquisition Protocol

 &nbs= p;            &= nbsp; o Redirection Mode (DNS, HTTP)

 &nbs= p;            &= nbsp; o Capabilities related to CDNI Logging=

   &nbs= p;            o Capa= bilities related to CDNI Metadata

The FCI spec should de= fine a generic protocol for sending this type of information and should all= ow for the list above to be further expanded if needed.

 

6. Negotiation of Supp= ort for Optional Types of Footprint/Capabilities

Need to specify the be= havior of CDNs that do not support the optional types of footprint/capabili= ties : how to react in case of failure? The uCDN can ignore or select dCDN = based only on the parameters it understands.

 

7. IANA Considerations=

Requires a new IANA re= gistry “CDNI Capabilities”; this namespace should be split into= standard (for Mandatory To Implement) and optional. A table provides the i= nitial standard partition: Delivery Protocol, Acquisition Protocol and Redirection Mode. The optional partition conforms to Expert R= eview policy.

No IANA action require= d for the defined Footprint Sub-Registry or the Protocol Sub-Registry. A ta= ble defines the initial Redirection Modes: Iterative DNS, Recursive DNS, It= erative HTTP, Recursive HTTP.

 

8. Security Considerat= ions

This section still nee= ds to be done, as there is not much text.

 

Comments:<= /o:p>

The main purpose of th= e draft is to say what people understand when they say footprint or capabil= ities. It does a pretty good job at narrowing down the concepts and explain= ing the implications of the wider notions. There are several examples provided regarding the basic set we should be c= onsidering in CDNI.

 

I think the draft need= s a bit more work in the following points:

1.&n= bsp;      It’s not= very clear from the draft how a footprint advertisement of resources (loca= tion of surrogate nodes) would work and in what practical context.

2.       The draft stat= es that the FCI specification should define a generic protocol for conveyin= g any capability information. Maybe we should be more precise of what are t= he requirements for such a protocol and what it is strictly expected to do. What scale of time/reactivity for = such a protocol?

3.&n= bsp;      There is still= a note in the document (end of section 5) about support for logging config= uration (control vs. metadata).

4.&n= bsp;      There is still= a note in section 7 about logging and metadata: include these capabilities= in the table. The notes from the meeting in London say something like R= 20;Kevin Ma: We still need to add capabilities for optional logging and (if any) for optional metadata field= s.”

5.&n= bsp;      The Security c= onsiderations section says “to be discussed in a future version”= ;.

 

See you in Toronto!

-- iuniana

 

 

 = ;

____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques 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 confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.
--_000_A419F67F880AB2468214E154CB8A55628C3F66eusaamb103ericsso_-- From nobody Tue Jul 22 08:39:11 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D311A0103 for ; Tue, 22 Jul 2014 08:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xcSOhgxFbdRK for ; Tue, 22 Jul 2014 08:39:08 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1D631A0056 for ; Tue, 22 Jul 2014 08:39:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=248; q=dns/txt; s=iport; t=1406043548; x=1407253148; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=D0m+vTslzU+5zmbJBUcGmuvuND2cnHuyWVbSYHLjH8k=; b=i9jN7ZWaD2sbvVbeDI3LV2roKmhgwkmOIoxRZPmY5LHl7AZX06RTuo2q tkhf+SBAu8TjYIe02bU93aK6gGatdDMSJRxdWOiTt4hDHlwHp54OAtTnE DbIVRBkTMxQvoyyyAb4NWz4hwzM3C1QhyQKyheMrjQweyeM0qsCUb/JZa E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAGiFzlOtJA2J/2dsb2JhbABYgw5SW40guW+HP4EbFnaECjpRAT5CJwSIVZkxpkwXkwCBGAWbJoFNkmKDRIIx X-IronPort-AV: E=Sophos;i="5.01,710,1400025600"; d="scan'208";a="63042001" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-7.cisco.com with ESMTP; 22 Jul 2014 15:39:00 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s6MFd0mu031943 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 22 Jul 2014 15:39:00 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Tue, 22 Jul 2014 10:39:00 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: CDNI WG Meeting Material available Thread-Index: AQHPpcMOEdNHqXLenUK9UIR4T3Zo8A== Date: Tue, 22 Jul 2014 15:38:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.212.29] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/FAtAoNwm7KfCLG6PL_jdqtnGBus Subject: [CDNi] CDNI WG Meeting Material available X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2014 15:39:10 -0000 Folks, Just FYI, all draft material for the meeting has been uploaded (accessible = via http://tools.ietf.org/agenda/90/). Presenters, Please check your material and let us know if this is not what you expect. Cheers Francois & Daryl= From nobody Tue Jul 22 09:05:36 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 249611A004D for ; Tue, 22 Jul 2014 09:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05Vj-oUHjLUR for ; Tue, 22 Jul 2014 09:05:24 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12C8F1A0039 for ; Tue, 22 Jul 2014 09:05:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3435; q=dns/txt; s=iport; t=1406045124; x=1407254724; h=from:to:subject:date:message-id:mime-version; bh=6i12/P06OybE/mbkFvF3d2Y/xg2xk8jUmnGDLZ9pfXE=; b=LSg+EDBiM9Ipsogn4YpRVflBfaWq3IJzOIbi2gA0W3QCSeHt6TX++5tS N+Q5YyChiCuefZK3zYGRH+kbMxLxG5vISWB2WQine4kcw9fqVUg5wfqJo Irhann7W/cyr95f4HD79LJWvDpiTmFVbSTuxYx1iF45vUObRzJvtXc8KV Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAEOLzlOtJV2Y/2dsb2JhbABYgkdHUlvOWAGBERZ2hAUBBC1eAQweViYBBBuIOpk0pkoXjxqDZoEYBa9Vg0SCMQ X-IronPort-AV: E=Sophos; i="5.01,710,1400025600"; d="scan'208,217"; a="63051456" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-7.cisco.com with ESMTP; 22 Jul 2014 16:05:22 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6MG5MDM024247 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 22 Jul 2014 16:05:22 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.216]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Tue, 22 Jul 2014 11:05:22 -0500 From: "Kent Leung (kleung)" To: "cdni@ietf.org" Thread-Topic: side meeting for URI Signing Thread-Index: Ac+lxror+NMyEyHbTbuq+aaaj0qL3Q== Date: Tue, 22 Jul 2014 16:05:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.93.187] Content-Type: multipart/alternative; boundary="_000_CD85F32117029D4F9AEF48BDEF5536AB4DED0199xmbalnx03ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/3Gb-xxp5YPV3rDoAVT8EWdVSG4s Subject: [CDNi] side meeting for URI Signing X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2014 16:05:28 -0000 --_000_CD85F32117029D4F9AEF48BDEF5536AB4DED0199xmbalnx03ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all. FYI. Some of us are meeting tomorrow (Wed 7/23) at 5:30 pm (IETF re= g desk) to discuss the sections in the URI Signing draft that need updates.= This is an informal meeting, but anyone interested to contribute to the di= scussion is invited to join. Kent --_000_CD85F32117029D4F9AEF48BDEF5536AB4DED0199xmbalnx03ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all. FYI. Some of us are meeting tomorrow (Wed= 7/23) at 5:30 pm (IETF reg desk) to discuss the sections in the URI Signin= g draft that need updates. This is an informal meeting, but anyone interest= ed to contribute to the discussion is invited to join.

 

Kent

--_000_CD85F32117029D4F9AEF48BDEF5536AB4DED0199xmbalnx03ciscoc_-- From nobody Tue Jul 22 13:53:22 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F10201B2C0C for ; Tue, 22 Jul 2014 13:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWQuOOMjEUn8 for ; Tue, 22 Jul 2014 13:53:18 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09ED61A0365 for ; Tue, 22 Jul 2014 13:53:17 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-bc-53ce79dfb80b Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 01.97.25146.FD97EC35; Tue, 22 Jul 2014 16:49:04 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0174.001; Tue, 22 Jul 2014 16:53:14 -0400 From: Kevin Ma J To: "Brandenburg, R. (Ray) van" , "cdni@ietf.org" Thread-Topic: [CDNi] Fwd: New Version Notification for draft-ietf-cdni-uri-signing-00.txt Thread-Index: AQHPiS3SyiasG05xb0aepX9e4CIB0ZtzTgqPgDkGPBA= Date: Tue, 22 Jul 2014 20:53:12 +0000 Message-ID: References: <20140616064006.29255.50497.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_A419F67F880AB2468214E154CB8A55628C7B67eusaamb103ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyuXRPlO6DynPBBvt/8Fk8nf2H1eLb5uuM DkweS5b8ZPI4uO4CcwBTFJdNSmpOZllqkb5dAlfGy+OXGQvO3GGs+HDoLWMD45WDjF2MnBwS AiYSZ+acYoawxSQu3FvPBmILCRxllJh51r+LkQvIXs4ocXDXQhaQBJuAlsTjr3+ZQGwRgTiJ HcfOgA0SFoiSmD7tDTtEPFqideY7VgjbSuLFk4lgQ1kEVCWunNkMtIyDg1fAW6J7MwvErkKJ W5cvgI3kBCpf9eUN2D2MQPd8P7UGLM4sIC5x68l8Jog7BSSW7DkPdbOoxMvH/1ghbCWJj7/n s0PU50vse9YKdhqvgKDEyZlPWCYwisxCMmoWkrJZSMog4joSC3Z/YoOwtSWWLXzNDGOfOfCY CVl8ASP7KkaO0uLUstx0I8NNjMD4OSbB5riDccEny0OMAhyMSjy8CmbngoVYE8uKK3MPMUpz sCiJ82pWzwsWEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwDj/9I6qem3eT0mmOxLfvBQzMgy/ fE/8qZyr26sLnuLH7cp8FHfMmCFun8z/dvaH4LpG4cns3YvP+3qbLtZr3t5qcyhSL9UpUK7e 51Vni8EbQ/E3stPmqwbk/rPdnfTA+YE2378kM6X0ZXbZEQsUGnoKutWPse32v56da3Xp01rD yPt3rdnmKbEUZyQaajEXFScCAFboB7mAAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/lEubGG02j3zvoImrXkTUd_GJPXU Subject: Re: [CDNi] Fwd: New Version Notification for draft-ietf-cdni-uri-signing-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2014 20:53:21 -0000 --_000_A419F67F880AB2468214E154CB8A55628C7B67eusaamb103ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ray et al, Couple of comments on the latest version: - section 2.5: "Packacke" -> "Package" - section 2.5: wrt the following text: "Adding any such attributes to the Signed URI before the URI Signing Packacke Attribute will cause the URI Signing validation to fail." Theoretically, the implementer could try all possible permutations of query string attributes to see if any of them produce a valid hash, thus determining the valid parameters (not that anyone would necessarily want to spend the cycles to do it)? - section 4: I think that the order of sections 4.1 and 4.2 should be switched, i.e., implementations should verify the signature before doing other validation. The text does not explicitly state which order to perform these sets of steps, but I think it should. The implicit ordering implied by the section ordering would allow an attacker to insert a bad package, with no signature and a bad VER, to launch a DoS attack? Now, that said, it would certainly be easier for the attacker to just add an attribute to the query string before the package attribute, so it's not clear that they would go to the trouble to generate a fake package, but I thought I'd throw it out there? Note: The latter issue could be addressed by putting the whole URL into the package, at a size cost, or permuting the attributes, at a processing cost? Should these be noted in the Security Considerations? - section 4.2, step 3: Do we want to be more specific about the Base64 decoding of the package attribute (similar to the text in section 4.1, step 2)? - section 4.2, step 4.A.a: wrt the following text: "to locate the shared key, which may be one of the keys available to use (i.e. set by configuration or CDNI metadata)." I think "may" should be "MUST"? - section 5.4: The Allowable * sets should define the default to be either allow all or deny all? - section 5.4: This structure of the metadata needs to be defined to clarify the JSON serialization. - section 5.4/5.5: These will also need to address the capabilities advertisement for the metadata properties and logging fields. thanx. -- Kevin J. Ma From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Brandenburg, R. (Ray= ) van Sent: Monday, June 16, 2014 2:57 AM To: cdni@ietf.org Subject: [CDNi] Fwd: New Version Notification for draft-ietf-cdni-uri-signi= ng-00.txt Hi all, As you can see, I've just submitted the post-WGLC version of the URI Signin= g draft as draft-ietf-uri-signing-00. We've addressed the comments received during WGLC from Ben and Iuniana, as = well as minor editorial work. We plan to publish another new revision before the Toronto deadline that wi= ll mostly address the Metadata and IANA considerations sections. Best regards, Ray Begin forwarded message: From: > Date: 16 juni 2014 08:40:06 CEST To: Ray van Brandenburg >, Michel Fisher >, Kent= Leung >, Bill Downey >, Michel Fisher >, Bill Downey >, Kent Leung >, "Francois Le Faucheur" >, Ray van Brandenburg >, Francois Le Faucheur > Subject: New Version Notification for draft-ietf-cdni-uri-signing-00.txt A new version of I-D, draft-ietf-cdni-uri-signing-00.txt has been successfully submitted by Ray van Brandenburg and posted to the IETF repository. Name: draft-ietf-cdni-uri-signing Revision: 00 Title: URI Signing for CDN Interconnection (CDNI) Document date: 2014-06-15 Group: cdni Pages: 35 URL: http://www.ietf.org/internet-drafts/draft-ietf-cdni-uri-sig= ning-00.txt Status: https://datatracker.ietf.org/doc/draft-ietf-cdni-uri-signin= g/ Htmlized: http://tools.ietf.org/html/draft-ietf-cdni-uri-signing-00 Abstract: This document describes how the concept of URI signing supports the content access control requirements of CDNI and proposes a URI signing scheme. The proposed URI signing method specifies the information needed to be included in the URI and the algorithm used to authorize and to validate access requests for the content referenced by the URI. Some of the information may be accessed by the CDN via configuration or CDNI metadata. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u ni= et de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, = wordt u verzocht dat aan de afzender te melden en het bericht te verwijdere= n. TNO aanvaardt geen aansprakelijkheid voor de inhoud van deze e-mail, de = wijze waarop u deze gebruikt en voor schade, van welke aard ook, die verban= d houdt met risico's verbonden aan het elektronisch verzenden van berichten= . This message may contain information that is not intended for you. If you a= re not the addressee or if this message was sent to you by mistake, you are= requested to inform the sender and delete the message. TNO accepts no liab= ility for the content of this e-mail, for the manner in which you use it an= d for damage of any kind resulting from the risks inherent to the electroni= c transmission of messages. --_000_A419F67F880AB2468214E154CB8A55628C7B67eusaamb103ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ray et al,

 

  Couple of comments on the latest version= :

 

- section 2.5: "Packacke" -> "= ;Package"

 

- section 2.5: wrt the following text:

 

  "Adding any such attributes

   to the Signed URI before the URI S= igning Packacke Attribute will

   cause the URI Signing validation t= o fail."

 

  Theoretically, the implementer could try= all possible permutations

  of query string attributes to see if any= of them produce a valid

  hash, thus determining the valid paramet= ers (not that anyone would

  necessarily want to spend the cycles to = do it)?

 

- section 4: I think that the order of sections= 4.1 and 4.2 should be

        = ;    switched, i.e., implementations should verify the<= o:p>

        = ;     signature before doing other validation.  Th= e text does

        = ;     not explicitly state which order to perform these= sets of

        = ;     steps, but I think it should.  The implicit = ordering

        = ;     implied by the section ordering would allow an at= tacker

        = ;     to insert a bad package, with no signature and a = bad VER,

        = ;     to launch a DoS attack?

 

        = ;     Now, that said, it would certainly be easier for = the

        = ;     attacker to just add an attribute to the query st= ring

        = ;     before the package attribute, so it's not clear t= hat they

        = ;     would go to the trouble to generate a fake packag= e, but I

        = ;     thought I'd throw it out there?=

 

        = ;     Note: The latter issue could be addressed by putt= ing the

        = ;     whole URL into the package, at a size cost, or pe= rmuting

        = ;     the attributes, at a processing cost?<= /span>

 

        = ;     Should these be noted in the Security Considerati= ons?

 

- section 4.2, step 3: Do we want to be more sp= ecific about the Base64

        = ;            &n= bsp;  decoding of the package attribute (similar to<= /p>

        = ;            &n= bsp;  the text in section 4.1, step 2)?

 

- section 4.2, step 4.A.a: wrt the following te= xt:

 

  "to locate the shared key, which ma= y

   be one of the keys available to us= e (i.e. set by

   configuration or CDNI metadata).&q= uot;

 

  I think "may" should be "= MUST"?

 

- section 5.4: The Allowable * sets should defi= ne the default to be

        = ;       either allow all or deny all?

 

- section 5.4: This structure of the metadata n= eeds to be defined to

        = ;       clarify the JSON serialization.<= /o:p>

 

- section 5.4/5.5: These will also need to addr= ess the capabilities

        = ;           advertisement= for the metadata properties and

        = ;           logging field= s.

 

thanx.

 

--  Kevin J. Ma

 

From: CDNi [= mailto:cdni-bounces@ietf.org] On Behalf Of Brandenburg, R. (Ray) van
Sent: Monday, June 16, 2014 2:57 AM
To: cdni@ietf.org
Subject: [CDNi] Fwd: New Version Notification for draft-ietf-cdni-ur= i-signing-00.txt

 

Hi all,

 

As you can see, I've just submitted the post-WGLC ve= rsion of the URI Signing draft as draft-ietf-uri-signing-00. 

 

We've addressed the comments received during WGLC fr= om Ben and Iuniana, as well as minor editorial work. 

 

We plan to publish another new revision before the T= oronto deadline that will mostly address the Metadata and IANA consideratio= ns sections. 

 

Best regards,

 

Ray


Begin forwarded message:

From: <internet-drafts@ietf.org> Date: 16 juni 2014 08:40:06 CEST
To: Ray van Brandenburg <ray.vanbrandenburg@tno.nl>, Michel Fisher <mfisher@llnw.com>, Kent Leung <kleung@cisco.com>, Bill Downey <william.s.downey@veriz= on.com>, Michel Fisher <mfish= er@llnw.com>, Bill Downey <william.s.downey@verizon.com>, Kent Leung <kleung@cisco.com>, "Fr= ancois Le Faucheur" <flefauch= @cisco.com>, Ray van Brandenburg <ray.vanbrandenburg@tno.nl>, Francois Le Faucheur <flefauch@cisco.com>
Subject: New Version Notification for draft-ietf-cdni-uri-signing= -00.txt


A new version of I-D, draft-ietf-cdni-uri-signing-00.txt
has been successfully submitted by Ray van Brandenburg and posted to the IETF repository.

Name:        draft-ietf-cdni-uri-signing
Revision:    00
Title:        URI Signing for CDN Interconnection (CDNI= )
Document date:    2014-06-15
Group:        cdni
Pages:        35
URL:            http://www.ietf.org/internet-drafts/draft-ietf-cdni-uri-signing-00.txt<= /a>
Status:         https://datatracker.= ietf.org/doc/draft-ietf-cdni-uri-signing/
Htmlized:       http://tools.ietf.org/html/draft-i= etf-cdni-uri-signing-00


Abstract:
  This document describes how the concept of URI signing supports= the
  content access control requirements of CDNI and proposes a URI<= br>   signing scheme.

  The proposed URI signing method specifies the information neede= d to
  be included in the URI and the algorithm used to authorize and = to
  validate access requests for the content referenced by the URI.=  Some
  of the information may be accessed by the CDN via configuration= or
  CDNI metadata.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u ni= et de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, = wordt u verzocht dat aan de afzender te melden en het bericht te verwijdere= n. TNO aanvaardt geen aansprakelijkheid voor de inhoud van deze e-mail, de wijze waarop u deze gebruikt en voor sc= hade, van welke aard ook, die verband houdt met risico's verbonden aan het = elektronisch verzenden van berichten.

 

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

--_000_A419F67F880AB2468214E154CB8A55628C7B67eusaamb103ericsso_-- From nobody Tue Jul 22 15:12:56 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDFB51B27E9 for ; Tue, 22 Jul 2014 15:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifk3QeW4f5NH for ; Tue, 22 Jul 2014 15:12:48 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A08BC1A03C8 for ; Tue, 22 Jul 2014 15:12:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39571; q=dns/txt; s=iport; t=1406067165; x=1407276765; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=gbBLVxOL+v37NVv3R9sf43h90UbliwRuWQMVjF/epLM=; b=P5YhlpGvsU9nEL9d9/X4AOgSCB8msbT+vrq072Wqa1BoYIEsV3ATvdfp UBcT5tnU1pBf0KR3POteODvZ/vJWYDdy3Nr6FA6bCKodp5fLEohihzmak TO39joxperu7PjqgWjVejilrzQwHzqC5S8bnzH4ic2qxJVxpueUXnfNU3 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArAFAKXgzlOtJV2b/2dsb2JhbABZgkdHUlcExUKBYYdFAYESFnaEAwEBAQQnBj8LEgIBCBEDAQEBCxYBBgcyFAkIAgQBEggBiCUDEQ3AIxeNHoF8IA0KAQaDKIEYBYYjiCKIRIVrkmaDRmwBgQQkHA X-IronPort-AV: E=Sophos; i="5.01,712,1400025600"; d="scan'208,217"; a="63153841" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP; 22 Jul 2014 22:12:43 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s6MMChRL020367 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Jul 2014 22:12:43 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.216]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Tue, 22 Jul 2014 17:12:43 -0500 From: "Kent Leung (kleung)" To: Kevin Ma J , "Brandenburg, R. (Ray) van" , "cdni@ietf.org" Thread-Topic: [CDNi] Fwd: New Version Notification for draft-ietf-cdni-uri-signing-00.txt Thread-Index: AQHPiS3UUQykaEbuQkm2ld8+jh4eX5tzTgqPgDkGPBCAAH2HoA== Date: Tue, 22 Jul 2014 22:12:43 +0000 Message-ID: References: <20140616064006.29255.50497.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.251.172] Content-Type: multipart/alternative; boundary="_000_CD85F32117029D4F9AEF48BDEF5536AB4DED05D1xmbalnx03ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/S6FG7XtSpwwbIvU58jTUS_iOJko Subject: Re: [CDNi] Fwd: New Version Notification for draft-ietf-cdni-uri-signing-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2014 22:12:53 -0000 --_000_CD85F32117029D4F9AEF48BDEF5536AB4DED05D1xmbalnx03ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kevin. Thanks for your feedback on the new draft. See comments below. From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Kevin Ma J Sent: Tuesday, July 22, 2014 1:53 PM To: Brandenburg, R. (Ray) van; cdni@ietf.org Subject: Re: [CDNi] Fwd: New Version Notification for draft-ietf-cdni-uri-s= igning-00.txt Hi Ray et al, Couple of comments on the latest version: - section 2.5: "Packacke" -> "Package" KL> OK. - section 2.5: wrt the following text: "Adding any such attributes to the Signed URI before the URI Signing Packacke Attribute will cause the URI Signing validation to fail." Theoretically, the implementer could try all possible permutations of query string attributes to see if any of them produce a valid hash, thus determining the valid parameters (not that anyone would necessarily want to spend the cycles to do it)? KL> Right, it may be theoretically possible to inject something or munge th= e Signed URI that results in the same hash value. But the challenge is that= the changed URI still needs to be useful to grab unauthorized content. So,= it seems mostly impossible from the practical perspective to achieve gaini= ng access to unauthorized content by inserting attributes in front of the U= RI Signing package attribute. This is a generic issue for security methods = such as message digest, hash, etc. Are you pointing out the issue with the = wording? Or that we should have a length value to prevent insertion? Though= this does not prevent someone from changing the protected parts to result = in the same hash value. In this case, the likelihood of anything useful is = almost zero. - section 4: I think that the order of sections 4.1 and 4.2 should be switched, i.e., implementations should verify the signature before doing other validation. The text does not explicitly state which order to perform these sets of steps, but I think it should. The implicit ordering implied by the section ordering would allow an attacker to insert a bad package, with no signature and a bad VER, to launch a DoS attack? KL> There is a processing cost to validating the URI Signature. If the Clie= nt IP is not allowed or time expired, then there's not much value in authen= ticating the Signed URI. We can let implementation determine what's best in= terms of performance and capacity. If an attacker can change or generate S= igned URI, it will cause some extra processing on the Surrogate. How much i= s the cost depends on the types of bad Signed URI and the implementation. S= o, being specific on implementation would be helpful to an attacker to caus= e the most damage. I understand your point from the conformance perspective= for interoperability. Having said all that, I'm open to specifying the ord= ering of the logic for Signed URI authentication, IE validation, and delive= ry policy enforcement. Others' comments? Now, that said, it would certainly be easier for the attacker to just add an attribute to the query string before the package attribute, so it's not clear that they would go to the trouble to generate a fake package, but I thought I'd throw it out there? KL> An attacker can just change a bit in the query string too. There are ma= ny ways an attacker can do which would result in failed authentication. Note: The latter issue could be addressed by putting the whole URL into the package, at a size cost, or permuting the attributes, at a processing cost? KL> Not sure that will help. If the entire URL is put into the package, but= the attacker adds or munges the attributes before the package, then we wou= ld need to match the received URL with the decoded URL. Why not just assume= that the received URL is the same as the decoded URL and validate that? Ma= ybe we should take it offline to discuss more ... Should these be noted in the Security Considerations? KL> Maybe it's good to point these out in that section. - section 4.2, step 3: Do we want to be more specific about the Base64 decoding of the package attribute (similar to the text in section 4.1, step 2)? KL> Do you mean the text should include the example as indicated by "e.g."?= Sure. - section 4.2, step 4.A.a: wrt the following text: "to locate the shared key, which may be one of the keys available to use (i.e. set by configuration or CDNI metadata)." I think "may" should be "MUST"? KL> OK - section 5.4: The Allowable * sets should define the default to be either allow all or deny all? KL> Right. We should update this section with the default for each metadata= . - section 5.4: This structure of the metadata needs to be defined to clarify the JSON serialization. KL> OK. Will need some help with that. Thanks for volunteering. :) - section 5.4/5.5: These will also need to address the capabilities advertisement for the metadata properties and logging fields. KL> Yes, to be discussed in tomorrow's meeting. Kent thanx. -- Kevin J. Ma From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Brandenburg, R. (Ray= ) van Sent: Monday, June 16, 2014 2:57 AM To: cdni@ietf.org Subject: [CDNi] Fwd: New Version Notification for draft-ietf-cdni-uri-signi= ng-00.txt Hi all, As you can see, I've just submitted the post-WGLC version of the URI Signin= g draft as draft-ietf-uri-signing-00. We've addressed the comments received during WGLC from Ben and Iuniana, as = well as minor editorial work. We plan to publish another new revision before the Toronto deadline that wi= ll mostly address the Metadata and IANA considerations sections. Best regards, Ray Begin forwarded message: From: > Date: 16 juni 2014 08:40:06 CEST To: Ray van Brandenburg >, Michel Fisher >, Kent= Leung >, Bill Downey >, Michel Fisher >, Bill Downey >, Kent Leung >, "Francois Le Faucheur" >, Ray van Brandenburg >, Francois Le Faucheur > Subject: New Version Notification for draft-ietf-cdni-uri-signing-00.txt A new version of I-D, draft-ietf-cdni-uri-signing-00.txt has been successfully submitted by Ray van Brandenburg and posted to the IETF repository. Name: draft-ietf-cdni-uri-signing Revision: 00 Title: URI Signing for CDN Interconnection (CDNI) Document date: 2014-06-15 Group: cdni Pages: 35 URL: http://www.ietf.org/internet-drafts/draft-ietf-cdni-uri-sig= ning-00.txt Status: https://datatracker.ietf.org/doc/draft-ietf-cdni-uri-signin= g/ Htmlized: http://tools.ietf.org/html/draft-ietf-cdni-uri-signing-00 Abstract: This document describes how the concept of URI signing supports the content access control requirements of CDNI and proposes a URI signing scheme. The proposed URI signing method specifies the information needed to be included in the URI and the algorithm used to authorize and to validate access requests for the content referenced by the URI. Some of the information may be accessed by the CDN via configuration or CDNI metadata. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u ni= et de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, = wordt u verzocht dat aan de afzender te melden en het bericht te verwijdere= n. TNO aanvaardt geen aansprakelijkheid voor de inhoud van deze e-mail, de = wijze waarop u deze gebruikt en voor schade, van welke aard ook, die verban= d houdt met risico's verbonden aan het elektronisch verzenden van berichten= . This message may contain information that is not intended for you. If you a= re not the addressee or if this message was sent to you by mistake, you are= requested to inform the sender and delete the message. TNO accepts no liab= ility for the content of this e-mail, for the manner in which you use it an= d for damage of any kind resulting from the risks inherent to the electroni= c transmission of messages. --_000_CD85F32117029D4F9AEF48BDEF5536AB4DED05D1xmbalnx03ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kevin. Thanks for your= feedback on the new draft. See comments below.

 <= /p>

From: CDNi [ma= ilto:cdni-bounces@ietf.org] On Behalf Of Kevin Ma J
Sent: Tuesday, July 22, 2014 1:53 PM
To: Brandenburg, R. (Ray) van; cdni@ietf.org
Subject: Re: [CDNi] Fwd: New Version Notification for draft-ietf-cdn= i-uri-signing-00.txt

 

Hi Ray et al,

 

  Couple of comments on the latest version= :

 

- section 2.5: "Packacke" -> "= ;Package"

 <= /p>

KL> OK.

 

- section 2.5: wrt the following text:

 

  "Adding any such attributes

   to the Signed URI before the URI S= igning Packacke Attribute will

   cause the URI Signing validation t= o fail."

 

  Theoretically, the implementer could try= all possible permutations

  of query string attributes to see if any= of them produce a valid

  hash, thus determining the valid paramet= ers (not that anyone would

  necessarily want to spend the cycles to = do it)?

 <= /p>

KL> Right, it may be t= heoretically possible to inject something or munge the Signed URI that resu= lts in the same hash value. But the challenge is that the changed URI still needs to be useful to grab unauthorized content. So, it seems mo= stly impossible from the practical perspective to achieve gaining access to= unauthorized content by inserting attributes in front of the URI Signing p= ackage attribute. This is a generic issue for security methods such as message digest, hash, etc. Are you poin= ting out the issue with the wording? Or that we should have a length value = to prevent insertion? Though this does not prevent someone from changing th= e protected parts to result in the same hash value. In this case, the likelihood of anything useful is almost= zero.

 <= /p>

 

- section 4: I think that the order of sections= 4.1 and 4.2 should be

        = ;    switched, i.e., implementations should verify the<= o:p>

        = ;     signature before doing other validation.  Th= e text does

        = ;     not explicitly state which order to perform these= sets of

        = ;     steps, but I think it should.  The implicit = ordering

        = ;     implied by the section ordering would allow an at= tacker

        = ;     to insert a bad package, with no signature and a = bad VER,

        = ;     to launch a DoS attack?

 

KL> There is a process= ing cost to validating the URI Signature. If the Client IP is not allowed o= r time expired, then there’s not much value in authenticating the Signed URI. We can let implementation determine what’s best in t= erms of performance and capacity. If an attacker can change or generate Sig= ned URI, it will cause some extra processing on the Surrogate. How much is = the cost depends on the types of bad Signed URI and the implementation. So, being specific on implementation would be = helpful to an attacker to cause the most damage. I understand your point fr= om the conformance perspective for interoperability. Having said all that, = I’m open to specifying the ordering of the logic for Signed URI authentication, IE validation, and delivery po= licy enforcement. Others’ comments?

 <= /p>

        = ;     Now, that said, it would certainly be easier for = the

        = ;     attacker to just add an attribute to the query st= ring

        = ;     before the package attribute, so it's not clear t= hat they

        = ;     would go to the trouble to generate a fake packag= e, but I

        = ;     thought I'd throw it out there?=

 

KL> An attacker can ju= st change a bit in the query string too. There are many ways an attacker ca= n do which would result in failed authentication.

 <= /p>

        = ;     Note: The latter issue could be addressed by putt= ing the

        = ;     whole URL into the package, at a size cost, or pe= rmuting

        = ;     the attributes, at a processing cost?<= /span>

 

KL> Not sure that will= help. If the entire URL is put into the package, but the attacker adds or = munges the attributes before the package, then we would need to match the received URL with the decoded URL. Why not just assume that t= he received URL is the same as the decoded URL and validate that? Maybe we = should take it offline to discuss more …

 <= /p>

        = ;     Should these be noted in the Security Considerati= ons?

 

KL> Maybe it’s g= ood to point these out in that section.

 <= /p>

- section 4.2, step 3: Do we want to be more sp= ecific about the Base64

        = ;            &n= bsp;  decoding of the package attribute (similar to<= /p>

        = ;            &n= bsp;  the text in section 4.1, step 2)?

 

KL> Do you mean the te= xt should include the example as indicated by “e.g.”? Sure.

 <= /p>

- section 4.2, step 4.A.a: wrt the following te= xt:

 

  "to locate the shared key, which ma= y

   be one of the keys available to us= e (i.e. set by

   configuration or CDNI metadata).&q= uot;

 

  I think "may" should be "= MUST"?

 <= /p>

KL> OK

 

- section 5.4: The Allowable * sets should defi= ne the default to be

        = ;       either allow all or deny all?

 

KL> Right. We should u= pdate this section with the default for each metadata.

 <= /p>

- section 5.4: This structure of the metadata n= eeds to be defined to

        = ;       clarify the JSON serialization.<= /o:p>

 <= /p>

KL> OK. Will need some= help with that. Thanks for volunteering. J

 

- section 5.4/5.5: These will also need to addr= ess the capabilities

        = ;           advertisement= for the metadata properties and

        = ;           logging field= s.

 

KL> Yes, to be discuss= ed in tomorrow’s meeting.

 <= /p>

Kent

 <= /p>

thanx.

 

--  Kevin J. Ma

 

From: CDNi [= mailto:cdni-bounces@ietf.org] On Behalf Of Brandenburg, R. (Ray) van
Sent: Monday, June 16, 2014 2:57 AM
To: cdni@ietf.org
Subject: [CDNi] Fwd: New Version Notification for draft-ietf-cdni-ur= i-signing-00.txt

 

Hi all,

 

As you can see, I've just submitted the post-WGLC ve= rsion of the URI Signing draft as draft-ietf-uri-signing-00. 

 

We've addressed the comments received during WGLC fr= om Ben and Iuniana, as well as minor editorial work. 

 

We plan to publish another new revision before the T= oronto deadline that will mostly address the Metadata and IANA consideratio= ns sections. 

 

Best regards,

 

Ray


Begin forwarded message:

From: <internet-drafts@ietf.org> Date: 16 juni 2014 08:40:06 CEST
To: Ray van Brandenburg <ray.vanbrandenburg@tno.nl>, Michel Fisher <mfisher@llnw.com>, Kent Leung <kleung@cisco.com>, Bill Downey <william.s.downey@veriz= on.com>, Michel Fisher <mfish= er@llnw.com>, Bill Downey <william.s.downey@verizon.com>, Kent Leung <kleung@cisco.com>, "Fr= ancois Le Faucheur" <flefauch= @cisco.com>, Ray van Brandenburg <ray.vanbrandenburg@tno.nl>, Francois Le Faucheur <flefauch@cisco.com>
Subject: New Version Notification for draft-ietf-cdni-uri-signing= -00.txt


A new version of I-D, draft-ietf-cdni-uri-signing-00.txt
has been successfully submitted by Ray van Brandenburg and posted to the IETF repository.

Name:        draft-ietf-cdni-uri-signing
Revision:    00
Title:        URI Signing for CDN Interconnection (CDNI= )
Document date:    2014-06-15
Group:        cdni
Pages:        35
URL:            http://www.ietf.org/internet-drafts/draft-ietf-cdni-uri-signing-00.txt<= /a>
Status:         https://datatracker.= ietf.org/doc/draft-ietf-cdni-uri-signing/
Htmlized:       http://tools.ietf.org/html/draft-i= etf-cdni-uri-signing-00


Abstract:
  This document describes how the concept of URI signing supports= the
  content access control requirements of CDNI and proposes a URI<= br>   signing scheme.

  The proposed URI signing method specifies the information neede= d to
  be included in the URI and the algorithm used to authorize and = to
  validate access requests for the content referenced by the URI.=  Some
  of the information may be accessed by the CDN via configuration= or
  CDNI metadata.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u ni= et de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, = wordt u verzocht dat aan de afzender te melden en het bericht te verwijdere= n. TNO aanvaardt geen aansprakelijkheid voor de inhoud van deze e-mail, de wijze waarop u deze gebruikt en voor sc= hade, van welke aard ook, die verband houdt met risico's verbonden aan het = elektronisch verzenden van berichten.

 

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

--_000_CD85F32117029D4F9AEF48BDEF5536AB4DED05D1xmbalnx03ciscoc_-- From nobody Tue Jul 22 15:32:14 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F03C1A02E5 for ; Tue, 22 Jul 2014 15:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EmmmfKGeZ5Lg for ; Tue, 22 Jul 2014 15:32:08 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D38AD1A02BE for ; Tue, 22 Jul 2014 15:32:07 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-4a-53ce937318bc Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 6F.CC.05330.3739EC35; Tue, 22 Jul 2014 18:38:11 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Tue, 22 Jul 2014 18:32:02 -0400 From: Kevin Ma J To: "Kent Leung (kleung)" , "Brandenburg, R. (Ray) van" , "cdni@ietf.org" Thread-Topic: [CDNi] Fwd: New Version Notification for draft-ietf-cdni-uri-signing-00.txt Thread-Index: AQHPpfoTglyWS1a5z0eHb/kJGIuKMZusqRCw Date: Tue, 22 Jul 2014 22:32:01 +0000 Message-ID: References: <20140616064006.29255.50497.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_A419F67F880AB2468214E154CB8A55628C7EB7eusaamb103ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyuXSPn27x5HPBBo/mG1s8nf2H1eLY8V/s Ft82X2d0YPaY8nsjq8eSJT+ZPA6uu8AcwBzFZZOSmpNZllqkb5fAlXFnwgn2ggPXmCpO7Ohj a2D8uYapi5GTQ0LARKLrxkw2CFtM4sK99UA2F4eQwFFGiTcft4IlhASWM0rMmhoGYrMJaEk8 /vqXCaRIRKCDUeL0nS9ADgeHsECUxMOZmiA1IgLRElMXT2GGsI0k1n9YwAhiswioShxacAYs zivgLXFgzQaoZd8YJWacegWW4BTwlTjb/B5sMSPQRd9PQVzKLCAucevJfKirBSSW7DnPDGGL Srx8/I8VwlaS+Ph7PjtEfb5E2/y5TBDLBCVOznzCMoFRZBaSUbOQlM1CUgYR15FYsPsTG4St LbFs4WtmGPvMgcdMyOILGNlXMXKUFqeW5aYbGWxiBMbVMQk23R2Me15aHmIU4GBU4uFVMDsX LMSaWFZcmXuIUZqDRUmcd1btvGAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjAn7n57nLWu9 d75yb6x8rEXIllvbFq5I/2DP7hz/dcvuDrU2nrDKUz4G/rMP1f8QPZn9YsWjQpEJpQsW3+5s 55t6eOn17lNr2IVLLB8GLP8UO1GQt1z9Q/4DlZnnxOunWmhK/jaeGPFu4u91P10/22Y17+Jp 8FZ+8F7ZZs77fefNH8UsCQvijlFiKc5INNRiLipOBABjTGrnjAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/3BO7cRNQOSPtq--l2npzEwU38V0 Subject: Re: [CDNi] Fwd: New Version Notification for draft-ietf-cdni-uri-signing-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2014 22:32:13 -0000 --_000_A419F67F880AB2468214E154CB8A55628C7EB7eusaamb103ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kent, We can discuss more tomorrow, but mostly I think we could just clarify th= e text to explicitly state assumptions or tradeoffs that are being made and any = security implications of those assumptions/tradeoffs. In general, the ability of an attacker to change any URL (signed or not) = allows them to deny service. URI signing could prevent an attacker from substit= uting alternate content by denying access instead? Should there be a more gener= al discussion of what URI signing is and isn't? thanx! -- Kevin J. Ma From: Kent Leung (kleung) [mailto:kleung@cisco.com] Sent: Tuesday, July 22, 2014 6:13 PM To: Kevin Ma J; Brandenburg, R. (Ray) van; cdni@ietf.org Subject: RE: [CDNi] Fwd: New Version Notification for draft-ietf-cdni-uri-s= igning-00.txt Hi Kevin. Thanks for your feedback on the new draft. See comments below. From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Kevin Ma J Sent: Tuesday, July 22, 2014 1:53 PM To: Brandenburg, R. (Ray) van; cdni@ietf.org Subject: Re: [CDNi] Fwd: New Version Notification for draft-ietf-cdni-uri-s= igning-00.txt Hi Ray et al, Couple of comments on the latest version: - section 2.5: "Packacke" -> "Package" KL> OK. - section 2.5: wrt the following text: "Adding any such attributes to the Signed URI before the URI Signing Packacke Attribute will cause the URI Signing validation to fail." Theoretically, the implementer could try all possible permutations of query string attributes to see if any of them produce a valid hash, thus determining the valid parameters (not that anyone would necessarily want to spend the cycles to do it)? KL> Right, it may be theoretically possible to inject something or munge th= e Signed URI that results in the same hash value. But the challenge is that= the changed URI still needs to be useful to grab unauthorized content. So,= it seems mostly impossible from the practical perspective to achieve gaini= ng access to unauthorized content by inserting attributes in front of the U= RI Signing package attribute. This is a generic issue for security methods = such as message digest, hash, etc. Are you pointing out the issue with the = wording? Or that we should have a length value to prevent insertion? Though= this does not prevent someone from changing the protected parts to result = in the same hash value. In this case, the likelihood of anything useful is = almost zero. - section 4: I think that the order of sections 4.1 and 4.2 should be switched, i.e., implementations should verify the signature before doing other validation. The text does not explicitly state which order to perform these sets of steps, but I think it should. The implicit ordering implied by the section ordering would allow an attacker to insert a bad package, with no signature and a bad VER, to launch a DoS attack? KL> There is a processing cost to validating the URI Signature. If the Clie= nt IP is not allowed or time expired, then there's not much value in authen= ticating the Signed URI. We can let implementation determine what's best in= terms of performance and capacity. If an attacker can change or generate S= igned URI, it will cause some extra processing on the Surrogate. How much i= s the cost depends on the types of bad Signed URI and the implementation. S= o, being specific on implementation would be helpful to an attacker to caus= e the most damage. I understand your point from the conformance perspective= for interoperability. Having said all that, I'm open to specifying the ord= ering of the logic for Signed URI authentication, IE validation, and delive= ry policy enforcement. Others' comments? Now, that said, it would certainly be easier for the attacker to just add an attribute to the query string before the package attribute, so it's not clear that they would go to the trouble to generate a fake package, but I thought I'd throw it out there? KL> An attacker can just change a bit in the query string too. There are ma= ny ways an attacker can do which would result in failed authentication. Note: The latter issue could be addressed by putting the whole URL into the package, at a size cost, or permuting the attributes, at a processing cost? KL> Not sure that will help. If the entire URL is put into the package, but= the attacker adds or munges the attributes before the package, then we wou= ld need to match the received URL with the decoded URL. Why not just assume= that the received URL is the same as the decoded URL and validate that? Ma= ybe we should take it offline to discuss more ... Should these be noted in the Security Considerations? KL> Maybe it's good to point these out in that section. - section 4.2, step 3: Do we want to be more specific about the Base64 decoding of the package attribute (similar to the text in section 4.1, step 2)? KL> Do you mean the text should include the example as indicated by "e.g."?= Sure. - section 4.2, step 4.A.a: wrt the following text: "to locate the shared key, which may be one of the keys available to use (i.e. set by configuration or CDNI metadata)." I think "may" should be "MUST"? KL> OK - section 5.4: The Allowable * sets should define the default to be either allow all or deny all? KL> Right. We should update this section with the default for each metadata= . - section 5.4: This structure of the metadata needs to be defined to clarify the JSON serialization. KL> OK. Will need some help with that. Thanks for volunteering. :) - section 5.4/5.5: These will also need to address the capabilities advertisement for the metadata properties and logging fields. KL> Yes, to be discussed in tomorrow's meeting. Kent thanx. -- Kevin J. Ma From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Brandenburg, R. (Ray= ) van Sent: Monday, June 16, 2014 2:57 AM To: cdni@ietf.org Subject: [CDNi] Fwd: New Version Notification for draft-ietf-cdni-uri-signi= ng-00.txt Hi all, As you can see, I've just submitted the post-WGLC version of the URI Signin= g draft as draft-ietf-uri-signing-00. We've addressed the comments received during WGLC from Ben and Iuniana, as = well as minor editorial work. We plan to publish another new revision before the Toronto deadline that wi= ll mostly address the Metadata and IANA considerations sections. Best regards, Ray Begin forwarded message: From: > Date: 16 juni 2014 08:40:06 CEST To: Ray van Brandenburg >, Michel Fisher >, Kent= Leung >, Bill Downey >, Michel Fisher >, Bill Downey >, Kent Leung >, "Francois Le Faucheur" >, Ray van Brandenburg >, Francois Le Faucheur > Subject: New Version Notification for draft-ietf-cdni-uri-signing-00.txt A new version of I-D, draft-ietf-cdni-uri-signing-00.txt has been successfully submitted by Ray van Brandenburg and posted to the IETF repository. Name: draft-ietf-cdni-uri-signing Revision: 00 Title: URI Signing for CDN Interconnection (CDNI) Document date: 2014-06-15 Group: cdni Pages: 35 URL: http://www.ietf.org/internet-drafts/draft-ietf-cdni-uri-sig= ning-00.txt Status: https://datatracker.ietf.org/doc/draft-ietf-cdni-uri-signin= g/ Htmlized: http://tools.ietf.org/html/draft-ietf-cdni-uri-signing-00 Abstract: This document describes how the concept of URI signing supports the content access control requirements of CDNI and proposes a URI signing scheme. The proposed URI signing method specifies the information needed to be included in the URI and the algorithm used to authorize and to validate access requests for the content referenced by the URI. Some of the information may be accessed by the CDN via configuration or CDNI metadata. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u ni= et de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, = wordt u verzocht dat aan de afzender te melden en het bericht te verwijdere= n. TNO aanvaardt geen aansprakelijkheid voor de inhoud van deze e-mail, de = wijze waarop u deze gebruikt en voor schade, van welke aard ook, die verban= d houdt met risico's verbonden aan het elektronisch verzenden van berichten= . This message may contain information that is not intended for you. If you a= re not the addressee or if this message was sent to you by mistake, you are= requested to inform the sender and delete the message. TNO accepts no liab= ility for the content of this e-mail, for the manner in which you use it an= d for damage of any kind resulting from the risks inherent to the electroni= c transmission of messages. --_000_A419F67F880AB2468214E154CB8A55628C7EB7eusaamb103ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kent,

 

  We can discuss more tomorrow, but mostly= I think we could just clarify the text

  to explicitly state assumptions or trade= offs that are being made and any security

  implications of those assumptions/tradeo= ffs.

 

  In general, the ability of an attacker t= o change any URL (signed or not) allows

  them to deny service.  URI signing = could prevent an attacker from substituting

 alternate content by denying access inste= ad?  Should there be a more general

  discussion of what URI signing is and is= n't?

 

thanx!

 

--  Kevin J. Ma

 

From: Kent L= eung (kleung) [mailto:kleung@cisco.com]
Sent: Tuesday, July 22, 2014 6:13 PM
To: Kevin Ma J; Brandenburg, R. (Ray) van; cdni@ietf.org
Subject: RE: [CDNi] Fwd: New Version Notification for draft-ietf-cdn= i-uri-signing-00.txt

 

Hi Kevin. Thanks for your= feedback on the new draft. See comments below.

 <= /p>

From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Kevin Ma J
Sent: Tuesday, July 22, 2014 1:53 PM
To: Brandenburg, R. (Ray) van; cdni= @ietf.org
Subject: Re: [CDNi] Fwd: New Version Notification for draft-ietf-cdn= i-uri-signing-00.txt

 

Hi Ray et al,

 

  Couple of comments on the latest version= :

 

- section 2.5: "Packacke" -> "= ;Package"

 <= /p>

KL> OK.

 

- section 2.5: wrt the following text:

 

  "Adding any such attributes

   to the Signed URI before the URI S= igning Packacke Attribute will

   cause the URI Signing validation t= o fail."

 

  Theoretically, the implementer could try= all possible permutations

  of query string attributes to see if any= of them produce a valid

  hash, thus determining the valid paramet= ers (not that anyone would

  necessarily want to spend the cycles to = do it)?

 <= /p>

KL> Right, it may be t= heoretically possible to inject something or munge the Signed URI that resu= lts in the same hash value. But the challenge is that the changed URI still needs to be useful to grab unauthorized content. So, it seems mo= stly impossible from the practical perspective to achieve gaining access to= unauthorized content by inserting attributes in front of the URI Signing p= ackage attribute. This is a generic issue for security methods such as message digest, hash, etc. Are you poin= ting out the issue with the wording? Or that we should have a length value = to prevent insertion? Though this does not prevent someone from changing th= e protected parts to result in the same hash value. In this case, the likelihood of anything useful is almost= zero.

 <= /p>

 

- section 4: I think that the order of sections= 4.1 and 4.2 should be

        = ;    switched, i.e., implementations should verify the<= o:p>

        = ;     signature before doing other validation.  Th= e text does

        = ;     not explicitly state which order to perform these= sets of

        = ;     steps, but I think it should.  The implicit = ordering

        = ;     implied by the section ordering would allow an at= tacker

        = ;     to insert a bad package, with no signature and a = bad VER,

        = ;     to launch a DoS attack?

 

KL> There is a process= ing cost to validating the URI Signature. If the Client IP is not allowed o= r time expired, then there’s not much value in authenticating the Signed URI. We can let implementation determine what’s best in t= erms of performance and capacity. If an attacker can change or generate Sig= ned URI, it will cause some extra processing on the Surrogate. How much is = the cost depends on the types of bad Signed URI and the implementation. So, being specific on implementation would be = helpful to an attacker to cause the most damage. I understand your point fr= om the conformance perspective for interoperability. Having said all that, = I’m open to specifying the ordering of the logic for Signed URI authentication, IE validation, and delivery po= licy enforcement. Others’ comments?

 <= /p>

        = ;     Now, that said, it would certainly be easier for = the

        = ;     attacker to just add an attribute to the query st= ring

        = ;     before the package attribute, so it's not clear t= hat they

        = ;     would go to the trouble to generate a fake packag= e, but I

        = ;     thought I'd throw it out there?=

 

KL> An attacker can ju= st change a bit in the query string too. There are many ways an attacker ca= n do which would result in failed authentication.

 <= /p>

        = ;     Note: The latter issue could be addressed by putt= ing the

        = ;     whole URL into the package, at a size cost, or pe= rmuting

        = ;     the attributes, at a processing cost?<= /span>

 

KL> Not sure that will= help. If the entire URL is put into the package, but the attacker adds or = munges the attributes before the package, then we would need to match the received URL with the decoded URL. Why not just assume that t= he received URL is the same as the decoded URL and validate that? Maybe we = should take it offline to discuss more …

 <= /p>

        = ;     Should these be noted in the Security Considerati= ons?

 

KL> Maybe it’s g= ood to point these out in that section.

 <= /p>

- section 4.2, step 3: Do we want to be more sp= ecific about the Base64

        = ;            &n= bsp;  decoding of the package attribute (similar to<= /p>

        = ;            &n= bsp;  the text in section 4.1, step 2)?

 

KL> Do you mean the te= xt should include the example as indicated by “e.g.”? Sure.

 <= /p>

- section 4.2, step 4.A.a: wrt the following te= xt:

 

  "to locate the shared key, which ma= y

   be one of the keys available to us= e (i.e. set by

   configuration or CDNI metadata).&q= uot;

 

  I think "may" should be "= MUST"?

 <= /p>

KL> OK

 

- section 5.4: The Allowable * sets should defi= ne the default to be

        = ;       either allow all or deny all?

 

KL> Right. We should u= pdate this section with the default for each metadata.

 <= /p>

- section 5.4: This structure of the metadata n= eeds to be defined to

        = ;       clarify the JSON serialization.<= /o:p>

 <= /p>

KL> OK. Will need some= help with that. Thanks for volunteering. J

 

- section 5.4/5.5: These will also need to addr= ess the capabilities

        = ;           advertisement= for the metadata properties and

        = ;           logging field= s.

 

KL> Yes, to be discuss= ed in tomorrow’s meeting.

 <= /p>

Kent

 <= /p>

thanx.

 

--  Kevin J. Ma

 

From: CDNi [= mailto:cdni-bounces@ietf.org] On Behalf Of Brandenburg, R. (Ray) van
Sent: Monday, June 16, 2014 2:57 AM
To: cdni@ietf.org
Subject: [CDNi] Fwd: New Version Notification for draft-ietf-cdni-ur= i-signing-00.txt

 

Hi all,

 

As you can see, I've just submitted the post-WGLC ve= rsion of the URI Signing draft as draft-ietf-uri-signing-00. 

 

We've addressed the comments received during WGLC fr= om Ben and Iuniana, as well as minor editorial work. 

 

We plan to publish another new revision before the T= oronto deadline that will mostly address the Metadata and IANA consideratio= ns sections. 

 

Best regards,

 

Ray


Begin forwarded message:

From: <internet-drafts@ietf.org> Date: 16 juni 2014 08:40:06 CEST
To: Ray van Brandenburg <ray.vanbrandenburg@tno.nl>, Michel Fisher <mfisher@llnw.com>, Kent Leung <kleung@cisco.com>, Bill Downey <william.s.downey@veriz= on.com>, Michel Fisher <mfish= er@llnw.com>, Bill Downey <william.s.downey@verizon.com>, Kent Leung <kleung@cisco.com>, "Fr= ancois Le Faucheur" <flefauch= @cisco.com>, Ray van Brandenburg <ray.vanbrandenburg@tno.nl>, Francois Le Faucheur <flefauch@cisco.com>
Subject: New Version Notification for draft-ietf-cdni-uri-signing= -00.txt


A new version of I-D, draft-ietf-cdni-uri-signing-00.txt
has been successfully submitted by Ray van Brandenburg and posted to the IETF repository.

Name:        draft-ietf-cdni-uri-signing
Revision:    00
Title:        URI Signing for CDN Interconnection (CDNI= )
Document date:    2014-06-15
Group:        cdni
Pages:        35
URL:            http://www.ietf.org/internet-drafts/draft-ietf-cdni-uri-signing-00.txt<= /a>
Status:         https://datatracker.= ietf.org/doc/draft-ietf-cdni-uri-signing/
Htmlized:       http://tools.ietf.org/html/draft-i= etf-cdni-uri-signing-00


Abstract:
  This document describes how the concept of URI signing supports= the
  content access control requirements of CDNI and proposes a URI<= br>   signing scheme.

  The proposed URI signing method specifies the information neede= d to
  be included in the URI and the algorithm used to authorize and = to
  validate access requests for the content referenced by the URI.=  Some
  of the information may be accessed by the CDN via configuration= or
  CDNI metadata.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u ni= et de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, = wordt u verzocht dat aan de afzender te melden en het bericht te verwijdere= n. TNO aanvaardt geen aansprakelijkheid voor de inhoud van deze e-mail, de wijze waarop u deze gebruikt en voor sc= hade, van welke aard ook, die verband houdt met risico's verbonden aan het = elektronisch verzenden van berichten.

 

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

--_000_A419F67F880AB2468214E154CB8A55628C7EB7eusaamb103ericsso_-- From nobody Wed Jul 23 14:57:05 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 557BB1ABB33 for ; Wed, 23 Jul 2014 14:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.1 X-Spam-Level: ** X-Spam-Status: No, score=2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_31=1, J_BACKHAIR_37=1, J_BACKHAIR_44=1, J_BACKHAIR_52=1] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHD03YGw5IMu for ; Wed, 23 Jul 2014 14:56:57 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 539521A0308 for ; Wed, 23 Jul 2014 14:56:56 -0700 (PDT) Received: from dhcp-a5f6.meeting.ietf.org ([31.133.165.246]) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1XA4Wr-0006Y2-Ih; Wed, 23 Jul 2014 22:56:55 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ben Niven-Jenkins In-Reply-To: <6DA3197C-D6F7-42A4-BDE7-D3BE77E8A625@cisco.com> Date: Wed, 23 Jul 2014 22:56:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1154D50C-6A82-457B-ADE4-F384B8BF9437@niven-jenkins.co.uk> References: <038401cf5b4f$0b5ea610$221bf230$@comcast.net> <05BD7B6B-6886-4277-8A8A-8AE77363939B@cisco.com> <315A2A4B-C876-4FF7-A836-7D48AC191195@cisco.com> <6DA3197C-D6F7-42A4-BDE7-D3BE77E8A625@cisco.com> To: Francois Le Faucher X-Mailer: Apple Mail (2.1878.2) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/bo2WDA0T5TJ8OnhRJMlfjzdlccE Cc: "cdni@ietf.org" Subject: Re: [CDNi] Utility of Verified-Origin & Claimed-Origin in CDNI logging X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 21:57:04 -0000 Francois, See below. On 7 Jul 2014, at 14:06, Francois Le Faucheur (flefauch) = wrote: > On 4 Jul 2014, at 10:17, Francois Le Faucheur (flefauch) = wrote: >=20 >> Hi Ben, >>=20 >> On 3 Jul 2014, at 19:39, Ben Niven-Jenkins = wrote: >>=20 >>> Francois, Colleagues, >>>=20 >>> Reading your suggested text below made me ponder on the purpose and = utility of the Claimed-Origin and Verified-Origin field directives. >>>=20 >>> Let=92s start with Verified-Origin. =46rom your text below and = reading the definition of Verified-Origin in section 3.3 of = draft-ietf-cdni-logging-11 I understand that a dCDN MUST NOT place a = Verified-Origin field directive in a log file it sends to a uCDN (it is = the uCDN=92s job to do that if it wants to once it has verified the = origin). Furthermore in a cascaded scenario (uCDN-tCDN-dCDN) the transit = CDN MUST NOT include a Verified-Origin field directive in a log file it = sends to uCDN and by implication if tCDN inserted a Verified-Origin = directive when receiving from dCDN, it must strip it before sending that = log file on to uCDN. >>=20 >> Yes. >>=20 >>>=20 >>> Therefore use of Verified-Origin is purely internal to a given CDN, = is never exchanged between CDNs and has no role to play in = interoperation of CDNI between CDNs, so why does the logging draft need = to specify it at all? >>=20 >> That=92s a good question. >>=20 >> I think the train of thought that got us there is the following : >> * when storing the CDNI Logging File, the uCDN would want to = have an easy way to identify where the CDNI Logging File is coming from >> * since the dCDN knows who he is, it is trivial for it to = include its identification in a field inside the file >> * the uCDN may be happy with that, in which case it does not = have to do anything; >> * or the uCDN may want to record the identification it = establishes, in which case it has to add the corresponding field itself. >> That=92s more or less how we got there. >>=20 >> My personal take would be: >> *A* if we expect that uCDNs would typically want to have an = explicit record inside the CDNI Logging File of the dCDN that originated = the file , then we should define directive(s) to do that. This will make = things more consistent for processing tools/utilities operating over = CDNI Logs. And in the case where the uCDN is happy with the origin as = stated by dCDN (say because the dCDN is operated by the same = administrative entity), it will save any file manipulation by the uCDN. >> *B* if we expect that uCDNs would typically NOT want to have an = explicit record inside the CDNI Logging File of the dCDN that originated = the file (say because they want to encode that information inside the = filename), then there may not be much value in defining the directives. >=20 > Does this make sense to you? > What is your take on whether uCDNS would typically want to store the = origin of teh CDNI Logging File inside the file? Honestly, I=92m not sure. Defining a directive to allow a uCDN to do = this is not harmful, even if it turns out no-one ends up using it. But that=92s only one half. The other half is that I interpreted the = text as stating that Verified-Origin had a relationship to = Claimed-Origin, i.e. you were defining that Verified-Origin meant the = value of Claimed-Origin had been =91verified=92 in some way. Whereas now what I think you mean is that we define two directives, one = where a dCDN can place what dCDN considers dCDN=92s =91identifier=92 to = be (Claimed-Origin) and one where the uCDN can place what the uCDN = considers dCDN=92s =91identifier=92 to be (Verified-Origin) and how uCDN = determines what it considers dCDN=92s =91identifier=92 to be is not = specified and may not use or rely on the value of Claimed-Origin at all? If I=92ve interpreted your position correctly, then you might want to = make that more explicit in the text. HTH Ben >=20 > Tx >=20 > Francois >=20 >> I personally lean towards *A*, but let=92s hear more opnions or = arguments.=20 >>=20 >> Cheers >>=20 >> Francois >>=20 >>=20 >>> CDNs that want the functionality of Verified-Origin can do whatever = they want internally to implement that, it doesn=92t seem we need = something in the RFC to support the internal behaviour of a CDN. >>>=20 >>>=20 >>> That then got me thinking about Claimed-Origin. If I read the text = below correctly, my understanding is that the value of Claimed-Origin = should be the same hostname in the dCDN that the uCDN connects to in = order to retrieve log files. So for example a uCDN could compare the = value of Claimed-Origin against the values of subjectAltName in the TLS = certificate presented by the dCDN and if there is a match then the = Claimed-Origin can be =93verified=94. >>>=20 >>> I=92m struggling to see what value Claimed-Origin gives in practice, = possibly because I don=92t understand the use case for it. If the = purpose is to let a uCDN do the comparison I describe above then I=92m = not sure that gives us much in reality. Claimed-Origin becomes = essentially a hop-by-hop (CDN-by-CDN) property and assuming the dCDN = identifies itself correctly (e.g. hostname in dCDN that uCDN connected = to matches hostname(s) in TLS certificate presented by dCDN) = Claimed-Origin is adding nothing, or have I misunderstood? >>>=20 >>> Thanks >>> Ben >>>=20 >>> On 2 Jul 2014, at 15:39, Francois Le Faucheur (flefauch) = wrote: >>>=20 >>>>=20 >>>> On 1 Jul 2014, at 20:09, Francois Le Faucheur (flefauch) = wrote: >>>>=20 >>>>> Folks, >>>>>=20 >>>>> (as a document editor) >>>>>=20 >>>>> To address the point around cascaded CDNs that was raised by David = Harrington as part of his early Ops Review, I have: >>>>> * expanded section 3.5 =93CDNI Logging File Example=94 >>>>> * added a section 3.6 "Cascaded CDNI Logging Files Example=94 >>>>>=20 >>>>> Draft text is below. I=92d appreciate some reviews. >>>>=20 >>>> I did a bit more work on teh text. Latest version below. Again will = appreciate a good review: >>>>=20 >>>> 3.5. CDNI Logging File Example >>>>=20 >>>> Let us consider the upstream CDN and the downstream CDN labelled = uCDN >>>> and dCDN-1 in Figure 1. When dCDN-1 acts as a downstream CDN for >>>> uCDN and performs content delivery on behalf of uCDN, dCDN-1 will >>>> include the CDNI Logging Records corresponding to the content >>>> deliveries performed on behalf of uCDN in the CDNI Logging Files = for >>>> uCDN. An example CDNI Logging File communicated by dCDN-1 to uCDN = is >>>> shown below in Figure 4. >>>>=20 >>>> #Version:CDNI/1.0 >>>>=20 >>>> #UUID:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 >>>>=20 >>>> #Claimed-Origin:cdni-logging-entity.dcdn-1.example.com >>>>=20 >>>> #Record-Type:cdni_http_request_v1 >>>>=20 >>>> #Fields:datetimetime-takenc-ip >>>> cs-methodu-uriprotocolsc-status >>>> sc-total-bytescs(User-Agent)cs(Referer) >>>> s-cached >>>>=20 >>>> = 2013-05-1700:38:06.8259.05810.5.7.1GET >>>> http://cdni-ucdn.dcdn-1.example.com/video/movie100.mp4 >>>> HTTP/1.12006729891"Mozilla/5.0 >>>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>>> Gecko) Chrome/5.0.375.127 Safari/533.4" >>>> "host1.example.com"1 >>>>=20 >>>> = 2013-05-1700:39:09.14515.3210.5.10.5GET >>>> http://cdni-ucdn.dcdn-1.example.com/video/movie118.mp4 >>>> HTTP/1.120015799210"Mozilla/5.0 >>>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>>> Gecko) Chrome/5.0.375.127 Safari/533.4" >>>> "host1.example.com"1 >>>>=20 >>>> = 2013-05-1700:42:53.43752.87910.5.10.5GET >>>> http://cdni-ucdn.dcdn-1.example.com/video/picture11.mp4 >>>> HTTP/1.020097234724"Mozilla/5.0 >>>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>>> Gecko) Chrome/5.0.375.127 Safari/533.4" >>>> "host5.example.com"0 >>>>=20 >>>> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >>>>=20 >>>> [Editor's Note: compute the correct Integrity-Hash value once = example >>>> is frozen] >>>>=20 >>>>=20 >>>> Figure 4: CDNI Logging File Example >>>>=20 >>>> If uCDN establishes by some means (e.g. via TLS authentication when >>>> pulling the CDNI Logging File) the identity of the entity from = which >>>> it pulled the CDNI Logging File, uCDN can add to the CDNI Logging a >>>> Verified-Origin directive as illustrated below: >>>>=20 >>>> #Verified-Origin:cdni-logging-entity.dcdn-1.example.com >>>>=20 >>>> As illustrated in Figure 2, uCDN will then ingest the corresponding >>>> CDNI Logging Records into its Collection process, alongside the >>>> Logging Records generated locally by the uCDN itself. This allows >>>> uCDN to aggregate Logging Records for deliveries performed by = itself >>>> (through Records generated locally) as well as for deliveries >>>> performed by its downstream CDN(s). This aggregate information can >>>> then be used (after Filtering and Rectification, as illustrated in >>>> Figure 2) by Log Consuming Applications that take into account >>>> deliveries performed by uCDN as well as by all of its downstream >>>> CDNs. >>>>=20 >>>> We observe that the time between >>>>=20 >>>> 1. when a delivery is completed in dCDN and >>>>=20 >>>> 2. when the corresponding Logging Record is ingested by the >>>> Collection process in uCDN >>>>=20 >>>> depends on a number of parameters such as the Logging Period agreed >>>> to by uCDN and dCDN, how much time uCDN waits before pulling the = CDNI >>>> Logging File once it is advertised in the CDNI Logging Feed, and = the >>>> time to complete the pull of the CDNI Logging File. Therefore, if = we >>>> consider the set of Logging Records aggregated by the Collection >>>> process in uCDN in a given time interval, there could be a = permanent >>>> significant timing difference between the CDNI Logging Records >>>> received from the dCDN and the Logging Records generated locally. >>>> For example, in a given time interval, the Collection process in = uCDN >>>> may be aggregating Logging Records generated locally by uCDN for >>>> deliveries performed in the last hour and CDNI Logging Records >>>> generated in the dCDN for deliveries in the hour before last. >>>>=20 >>>> 3.6. Cascaded CDNI Logging Files Example >>>>=20 >>>> Let us consider the cascaded CDN scenario of uCDN, dCDN-2 and = dCDN-3 >>>> as depicted in Figure 1. After completion of a delivery by dCDN-3 = on >>>> behalf of dCDN-2, dCDN-3 will include a corresponding Logging = Record >>>> in a CDNI Logging File that will be pulled by dCDN-2 and that is >>>> illustrated below in Figure 5. In practice, a CDNI Logging File is >>>> likely to contain a very high number of CDNI Logging Records. >>>> However, for readability, the example in Figure 5 contains a single >>>> CDNI Logging Record. >>>>=20 >>>>=20 >>>> #Version:CDNI/1.0 >>>>=20 >>>> #UUID:urn:uuid:65718ef-0123-9876-adce4321bcde >>>>=20 >>>> #Claimed-Origin:cdni-logging-entity.dcdn-3.example.com >>>>=20 >>>> #Record-Type:cdni_http_request_v1 >>>>=20 >>>> #Fields:datetimetime-takenc-ip >>>> cs-methodu-uriprotocolsc-status >>>> sc-total-bytescs(User-Agent)cs(Referer) >>>> s-cached >>>>=20 >>>> = 2013-05-1700:39:09.11914.0710.5.10.9GET >>>> http://cdni-dcdn-2.dcdn-3.example.com/video/movie118.mp4 >>>> HTTP/1.120015799210"Mozilla/5.0 >>>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>>> Gecko) Chrome/5.0.375.127 Safari /533.4" >>>> "host1.example.com"1 >>>>=20 >>>> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >>>>=20 >>>> [Editor's Note: compute the correct Integrity-Hash value once = example >>>> is frozen] >>>>=20 >>>> Figure 5: Cascaded CDNI Logging File Example (dCDN-3 to dCDN-2) >>>>=20 >>>> If dCDN-2 establishes by some means (e.g. via TLS authentication = when >>>> pulling the CDNI Logging File) the identity of the entity from = which >>>> it pulled the CDNI Logging File, dCDN-2 can add to the CDNI Logging = a >>>> Verified-Origin directive as illustrated below: >>>>=20 >>>> #Verified-Origin:cdni-logging-entity.dcdn-3.example.com >>>>=20 >>>> dCDN-2 (behaving as an upstream CDN from the viewpoint of dCDN-3) >>>> will then ingest the CDNI Logging Record for the considered dCDN-3 >>>> delivery into its Collection process (as illustrated in Figure 2). >>>> This Logging Record may be aggregated with Logging Records = generated >>>> locally by dCDN-2 for deliveries performed by dCDN-2 itself. Say, >>>> for illustration, that the content delivery performed by dCDN-3 on >>>> behalf of dCDN-2 had actually been redirected to dCDN-2 by uCDN, = and >>>> say that another content delivery has just been redirected by uCDN = to >>>> dCDN-2 and that dCDN-2 elected to perform the corresponding = delivery >>>> itself. Then after Filtering and Rectification (as illustrated in >>>> Figure 2), dCDN-2 will include the two Logging Records = corresponding >>>> respectively to the delivery performed by dCDN-3 and the delivery >>>> performed by dCDN-2, in the next CDNI Logging File that will be >>>> communicated to uCDN. An example of such CDNI Logging File is >>>> illustrated below in Figure 6. >>>>=20 >>>> #Version:CDNI/1.0 >>>>=20 >>>> #UUID:urn:uuid:1234567-8fedc-abab-0987654321ff >>>>=20 >>>> #Claimed-Origin:cdni-logging-entity.dcdn-2.example.com >>>>=20 >>>> #Record-Type:cdni_http_request_v1 >>>>=20 >>>> #Fields:datetimetime-takenc-ip >>>> cs-methodu-uriprotocolsc-status >>>> sc-total-bytescs(User-Agent)cs(Referer) >>>> s-cached >>>>=20 >>>> = 2013-05-1700:39:09.11914.0710.5.10.9GET >>>> http://cdni-ucdn.dcdn-2.example.com/video/movie118.mp4 >>>> HTTP/1.120015799210"Mozilla/5.0 >>>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>>> Gecko) Chrome/5.0.375.127 Safari /533.4" >>>> "host1.example.com"1 >>>>=20 >>>> = 2013-05-1701:42:53.43752.87910.5.10.12GET >>>> http://cdni-ucdn.dcdn-2.example.com/video/picture11.mp4 >>>> HTTP/1.020097234724"Mozilla/5.0 >>>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>>> Gecko) Chrome/5.0.375.127 Safari /533.4" >>>> "host5.example.com"0 >>>>=20 >>>> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >>>>=20 >>>> [Editor's Note: compute the correct Integrity-Hash value once = example >>>> is frozen] >>>>=20 >>>> Figure 6: Cascaded CDNI Logging File Example (dCDN-2 to uCDN) >>>>=20 >>>> If uCDN establishes by some means (e.g. via TLS authentication when >>>> pulling the CDNI Logging File) the identity of the entity from = which >>>> it pulled the CDNI Logging File, uCDN can add to the CDNI Logging a >>>> Verified-Origin directive as illustrated below: >>>>=20 >>>> #Verified-Origin:cdni-logging-entity.dcdn-2.example.com >>>>=20 >>>> In the example of Figure 6, we observe that: >>>>=20 >>>> o the first Logging Record corresponds to the Logging Record >>>> communicated earlier to dCDN-2 by dCDN-3, which corresponds to a >>>> delivery redirected by uCDN to dCDN-2 and then redirected by >>>> dCDN-2 to dCDN-3. Its initial fields values are preserved, with >>>> the exception of the u-uri that now reflects the URI convention >>>> between uCDN and dCDN-2, and which presents the delivery to uCDN >>>> as if it was performed by dCDN-2 itself, which reflects the fact >>>> that dCDN-2 had taken the full responsibility of the = corresponding >>>> delivery (even if in this case, dCDN-2 elected to redirect the >>>> delivery to dCDN-3 so it is actually performed by dCDN-3 on = behalf >>>> of dCDN-2). >>>>=20 >>>> o the second Logging Record corresponds to a delivery redirected = by >>>> uCDN to dCDN-2 and performed by dCDN-2 itself. The time of the >>>> delivery in this Logging Record may be significantly more recent >>>> than the first Logging Record since it was generated locally = while >>>> the first Logging Record was generated by dCDN-3 and had to be >>>> advertised , and then pulled and then ingested into the dCDN-2 >>>> Collection process, before being aggregated with the second >>>> Logging Record. >>>>=20 >>>>=20 >>>>=20 >>>> Cheers >>>>=20 >>>> Francois >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> Thanks >>>>>=20 >>>>> Francois >>>>>=20 >>>>> " >>>>>=20 >>>>> 3.5. CDNI Logging File Example >>>>>=20 >>>>> Let us consider the upstream CDN and the downstream CDN labelled = uCDN >>>>> and dCDN-1 in Figure 1. When dCDN-1 acts as a downstream CDN for >>>>> uCDN and performs content delivery on behalf of uCDN, dCDN-1 will >>>>> include the CDNI Logging Records corresponding to the content >>>>> deliveries performed on behalf of uCDN in the CDNI Logging Files = for >>>>> uCDN. An example CDNI Logging File communicated by dCDN-1 to uCDN = is >>>>> show below: >>>>>=20 >>>>> " >>>>>=20 >>>>> #Version:CDNI/1.0 >>>>>=20 >>>>> #UUID:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 >>>>>=20 >>>>> #Claimed-Origin:cdni-logging-entity.dcdn-1.example.com >>>>>=20 >>>>> #Record-Type:cdni_http_request_v1 >>>>>=20 >>>>> #Fields:datetimetime-takenc-ipcs- >>>>> methodu-uriprotocolsc-statussc-total- >>>>> bytescs(User-Agent)cs(Referer)s-cached >>>>>=20 >>>>> = 2013-05-1700:38:06.8259.05810.5.7.1GETh >>>>> ttp://cdni-ucdn.dcdn-1.example.com/video/ >>>>> movie100.mp4HTTP/1.12006729891"Mozilla/5.0 >>>>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>>>> Gecko) Chrome/5.0.375.127 Safari >>>>> /533.4""host1.example.com"1 >>>>>=20 >>>>> = 2013-05-1700:39:09.14515.3210.5.10.5GET >>>>> http://cdni-ucdn.dcdn-1.example.com/video/ >>>>> = movie118.mp4HTTP/1.120015799210"Mozilla/5.0 >>>>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>>>> Gecko) Chrome/5.0.375.127 Safari >>>>> /533.4""host1.example.com"1 >>>>>=20 >>>>> = 2013-05-1700:42:53.43752.87910.5.10.5GET>>>>> http://cdni-ucdn.dcdn-1.example.com/video/ >>>>> = picture11.mp4HTTP/1.020097234724"Mozilla/5.0 >>>>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>>>> Gecko) Chrome/5.0.375.127 Safari >>>>> /533.4""host5.example.com"0 >>>>>=20 >>>>> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >>>>>=20 >>>>> [Editor's Note: compute the correct Integrity-Hash value once = example >>>>> is frozen] >>>>>=20 >>>>> " >>>>>=20 >>>>> As illustrated in Figure 2, uCDN will then ingest the = corresponding >>>>> CDNI Logging Records into its Collection process, alongside the >>>>> Logging Records generated locally by the uCDN itself. This allows >>>>> uCDN to aggregate Logging Records for deliveries performed by = itself >>>>> (through Records generated locally) as well as for deliveries >>>>> performed by its downstream CDN(s). This aggregate information = can >>>>> then be used (after Filtering and Rectification, as illustrated in >>>>> Figure 2) by Log Consuming Applications considering deliveries >>>>> performed by uCDN as well as by all its downstream CDN(s). >>>>>=20 >>>>> We observe that the time between >>>>>=20 >>>>> 1. when a delivery is completed in dCDN and >>>>>=20 >>>>> 2. when the corresponding Logging Record is ingested by the >>>>> Collection process in uCDN >>>>>=20 >>>>> depends on a number of parameters such as the Logging Period = agreed >>>>> to by uCDN and dCDN, how much time uCDN waits after it is = advertised >>>>> in the CDNI Logging Feed before pulling the CDNI Logging File, and >>>>> the time to complete the pull of the CDNI Logging File. = Therefore, >>>>> if we consider the set of Logging Records aggregated by the >>>>> Collection process in uCDN in a given time interval, there could = be a >>>>> permanent significant timing difference between the CDNI Logging >>>>> Records received from the dCDN and the Logging Records generated >>>>> locally. For example, in a given time interval, the Collection >>>>> process in uCDN may be aggregating Logging Records generated = locally >>>>> by uCDN for deliveries performed in the last hour and CDNI Logging >>>>> Records generated in the dCDN for deliveries in the hour before = last. >>>>>=20 >>>>> 3.6. Cascaded CDNI Logging Files Example >>>>>=20 >>>>> Let us consider the cascaded CDN scenario of uCDN, dCDN-2 and = dCDN-3 >>>>> as depicted in Figure 1. After completion of a delivery by dCDN-3 = on >>>>> behalf of dCDN-2, dCDN-3 will include a corresponding Logging = Record >>>>> in a CDNI Logging File and will advertise this CDNI Logging File = to >>>>> d-CDN2 in the corresponding CDNI Logging feed. As a result, = dCDN-2 >>>>> will initiate and complete the pull of the corresponding CDNI = Logging >>>>> File that is illustrated below: >>>>>=20 >>>>> " >>>>>=20 >>>>> #Version:CDNI/1.0 >>>>>=20 >>>>> #UUID:urn:uuid:65718ef-0123-9876-adce4321bcde >>>>>=20 >>>>> #Claimed-Origin:cdni-logging-entity.dcdn-3.example.com >>>>>=20 >>>>> #Record-Type:cdni_http_request_v1 >>>>>=20 >>>>> #Fields:datetimetime-takenc-ipcs- >>>>> methodu-uriprotocolsc-statussc-total- >>>>> bytescs(User-Agent)cs(Referer)s-cached >>>>>=20 >>>>> = 2013-05-1700:39:09.14515.3210.5.10.5GET >>>>> = http://cdni-dcdn-2.dcdn-3.example.com/video/movie118.mp4HTTP/ >>>>> 1.120015799210"Mozilla/5.0 (Windows; U; Windows = NT >>>>> 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) = Chrome/5.0.375.127 >>>>> Safari /533.4""host1.example.com"1 >>>>>=20 >>>>> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >>>>>=20 >>>>> [Editor's Note: compute the correct Integrity-Hash value once = example >>>>> is frozen] >>>>>=20 >>>>> " >>>>>=20 >>>>> dCDN-2 (behaving as an upstream CDN from the viewpoint of dCDN-3) >>>>> will then ingest the CDNI Logging Record for the considered dCDN-3 >>>>> delivery into its Collection process (as illustrated in Figure 2). >>>>> This Logging Record may be aggregated with Logging Records = generated >>>>> locally by dCDN-2 for deliveries performed by dCDN-2 itself. Say, >>>>> for illustration, that the content delivery performed by dCDN-3 on >>>>> behalf of dCDN-2 had actually been redirected to dCDN-2 by uCDN, = and >>>>> say that another content delivery has just been redirected by uCDN = to >>>>> dCDN-2 and that dCDN-2 elected to perform the corresponding = delivery >>>>> itself. Then after Filtering and Rectification (as illustrated in >>>>> Figure 2), dCDN-2 will include the two Logging Records = corresponding >>>>> respectively to the delivery performed by dCDN-3 and the delivery >>>>> performed by dCDN-2, in the next CDNI Logging File that will be >>>>> communcated to uCDN. An example of such CDNI Logging File is >>>>> illustrated below: >>>>>=20 >>>>> #Version:CDNI/1.0 >>>>>=20 >>>>> #UUID:urn:uuid:1234567-8fedc-abab-0987654321ff >>>>>=20 >>>>> #Claimed-Origin:cdni-logging-entity.dcdn-2.example.com >>>>>=20 >>>>> #Record-Type:cdni_http_request_v1 >>>>>=20 >>>>> #Fields:datetimetime-takenc-ipcs- >>>>> methodu-uriprotocolsc-statussc-total- >>>>> bytescs(User-Agent)cs(Referer)s-cached >>>>>=20 >>>>> = 2013-05-1700:39:09.14515.3210.5.10.5GET >>>>> http://cdni-ucdn.dcdn-2.example.com/video/movie118.mp4HTTP/ >>>>> 1.120015799210"Mozilla/5.0 (Windows; U; Windows = NT >>>>> 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) = Chrome/5.0.375.127 >>>>> Safari /533.4""host1.example.com"1 >>>>>=20 >>>>> = 2013-05-1701:42:53.43752.87910.5.10.5GET>>>>> = http://cdni-ucdn.dcdn-2.example.com/video/picture11.mp4HTTP/ >>>>> 1.020097234724"Mozilla/5.0 (Windows; U; Windows = NT >>>>> 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) = Chrome/5.0.375.127 >>>>> Safari /533.4""host5.example.com"0 >>>>>=20 >>>>> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >>>>>=20 >>>>> [Editor's Note: compute the correct Integrity-Hash value once = example >>>>> is frozen] >>>>>=20 >>>>> " >>>>>=20 >>>>> In the example above, we observe that: >>>>>=20 >>>>> o the first Logging Record corresponds to the Logging Record >>>>> communicated earlier to dCDN-2 by dCDN-3, which corresponds to a >>>>> delivery redirected by uCDN to dCDN-2 and then redirected by >>>>> dCDN-2 to dCDN-3. Its initial fields values are preserved, with >>>>> the exception of the u-uri that now reflects the URI convention >>>>> between uCDN and dCDN-2, and which presents the delivery to uCDN >>>>> as if it was performed by dCDN-2 itself, which reflects the fact >>>>> that dCDN-2 had taken the full responsibility of the = corresponding >>>>> delivery (even if in this case, dCDN-2 elected to redirect the >>>>> delivery to dCDN-3 so it is actually performed by dCDN-3 on = behalf >>>>> of dCDN-2). >>>>>=20 >>>>> o the second Logging Record corresponds to a delivery redirected = by >>>>> uCDN to dCDN-2 and performed by dCDN-2 itself. The time of the >>>>> delivery in this Logging Record may be significantly more recent >>>>> than the first Logging Record since it was generated locally = while >>>>> the first Logging Record was generated by dCDN-3 and had to be >>>>> advertised , and then pulled and then ingested into the dCDN-2 >>>>> Collection process, before being aggregated with the second >>>>> Logging Record. >>>>>=20 >>>>> " >>>>>=20 >>>>>=20 >>>>> On 23 Apr 2014, at 20:29, Francois Le Faucheur (flefauch) = wrote: >>>>>=20 >>>>>> Hello, >>>>>>=20 >>>>>> On 18 Apr 2014, at 23:42, ietfdbh wrote: >>>>>>>>=20 >>>>>>>> On 5 Apr 2014, at 23:14, ietfdbh wrote: >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Most notably, the logging from a dCDN to a uCDN typically = contains only >>>>>>>> one >>>>>>>>> dCDN identifier, such as Verified-origin, and doesn't really = permit >>>>>>>>> specifying a sub-ordinate dCDN. For example, in a cascade such = as CDN-A >>>>>>> - >>>>>>>>>=20 >>>>>>>>> CDN-B -> CDN-C, CDN-C will share logging info with CDN-B, but = not with >>>>>>>>> CDN-A; CDN-B shares logging info with CDN-A. This can be = desirable for >>>>>>>>> hiding the topology and delegation used by the dCDN. However, = this >>>>>>>> document >>>>>>>>> does not discuss how the logging provided by CDN-C gets = converted into >>>>>>>> the >>>>>>>>> logs for CDN-B that will be sent to CDN-A. Without some = logging >>>>>>>> information >>>>>>>>> from CDN-C, it would seem difficult for CDN-A to utilize the = information >>>>>>> to >>>>>>>>> meet requirements of billing, analytics, and fault and = performance >>>>>>> analysis. >>>>>>>>> Maybe the logging gets aggregated and reported in CDN-B's = logging, >>>>>>>>=20 >>>>>>>> Exactly. >>>>>>>>=20 >>>>>>>>> but that >>>>>>>>> "transitive or aggregate logging" doesn't appear to be = discussed in this >>>>>>>>> document. >>>>>>>>=20 >>>>>>>> It is discussed in section 2.1 through Figure 1 and the = following text: >>>>>>>> " >>>>>>>> A dCDN (e.g., dCDN-2) integrates the relevant Logging = information >>>>>>>> obtained from its dCDNs (i.e., dCDN-3) in the Logging = information >>>>>>>> that it provides to the uCDN, so that the uCDN ultimately = obtains all >>>>>>>> Logging information relevant to a CSP for which it acts as the >>>>>>>> authoritative CDN. >>>>>>>> " >>>>>>>> Does that address your concern? >>>>>>>=20 >>>>>>> No it does not mitigate my concern. >>>>>>>=20 >>>>>>> This says the information gets "integrated", but doesn't = describe what >>>>>>> integrated means. >>>>>>> I could interpret that integration would be that the logging = from CDN-C >>>>>>> would be included in the logs from CDN-B to CDN-A, >>>>>>> But I think the text says CDN-B will not share the logging = entries from >>>>>>> CDN-C with CDN-A. >>>>>>> Do I have this wrong? Does CDN-B create a log file and generate = entries, >>>>>>> and then when it delegates delivery to CDN-C, and CDN-C passes = its log file >>>>>>> back to CDN-B, does CDN-B take the whole log file from CDN-B and = insert it >>>>>>> into its own log file, then continue adding any more entries, = and then when >>>>>>> done send the CDN-B log file (including a fully inserted CDN-C = log file) to >>>>>>> CDN-A? >>>>>>>=20 >>>>>>> If not, that presumably means that somehow, the data from CDN-C = is >>>>>>> "aggregated" - that's how it is "integrated=94, >>>>>>=20 >>>>>> Right. It is aggregated. >>>>>> Effectively, if CDN-B has sub-delegated a delivery to CDN-C, then = when CDN-C provides a log record for that delivery to CDN-B, CDN-B will = aggregate that log record with the log records for the deliveries that = CDN-B conduted itself. When CDN-B provides log records to CDN-A, the log = record corresponding to the delivery performed by CDN-C is turned by = CDN-B into a log record that looks like the delivery was done by CDN-B. = CDN-A will not be aware that the delivery was performed by another CDN = than CDN-B (just like the Content Provider is not ware that the delivery = was not performed by CDN-A with whom it has a delivery contract). >>>>>>=20 >>>>>>> But there is no discussion of how this aggregation is done. >>>>>>=20 >>>>>> That is true. I think it has been assumed by many but never made = clear. So we need to add some discussion about that. >>>>>>=20 >>>>>>> I think your intent is to hide the fact that CDN-B used CDN-C, = since that >>>>>>> may reflect a proprietary approach of CDN-B's business model. >>>>>>=20 >>>>>> Right. >>>>>>=20 >>>>>>> But CDN-A would presumably have problems performing analytics, = and fault and >>>>>>> performance analysis, if the data from CDN-C is not included in = CDN-B's >>>>>>> logging to CDN-A.=20 >>>>>>> So I would like an example to demonstrate what CDN-A would see = in CDN-B's >>>>>>> logs if CDN-C had faults or performance problems, and I would = like to see >>>>>>> how CDN-A could perform analytics (of any kind) relating to the = delivery >>>>>>> performed by CDN-C. >>>>>>=20 >>>>>> The assumption is that CDN-A is only dealing with CDN-B. CDN-A = may not not even be aware of CDN-C.=20 >>>>>> So CDN-A analaytics/monitoring will establish whether all the = deliveries delegated to CDN-B (comprising deliveries performed by CDN-B = as well as deliveries redirected by CDN-B to CDN-C and possibly CDN-C2) = have received the right quality (ie if CDN-B has met the SLA committed = to CDN-A). >>>>>> If some deliveries have experienced quality problems, CDN-A will = blame CDN-B. It is up to CDN-B to then do its own analytics and = monitoring to decide whether the problem lies within his own CDN or = CDN-C or CDN-C2.=20 >>>>>> The whole thing operates as a chain of delegations, like many = other business arrangements: if my SmartPhone does not work, I blame the = smartPhone vendor (I don=92t try identify if the problem is coming from = the supplier of the GSM chipset, but the SmartPhone vendor will). >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> I am missing how this would be done (especially in a = standardized manner). >>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> I think Verified-Origin is particularly problematic, because = the text >>>>>>> states >>>>>>>>> that this can only be added by the uCDN, never the dCDN. So = what if >>>>>>> CDN-B >>>>>>>>> verifies the origin of the logs from CDN-C and then passes the >>>>>>> information >>>>>>>>> (now as a dCDN) to CDN-A? The text mentions that this might be >>>>>>>> established >>>>>>>>> using authentication mechanisms; so do we lose this logged >>>>>>>>> authentication/verification when cascading? >>>>>>>>>=20 >>>>>>>>> (Maybe this is resolved by having the uCDN (CDN-B) record a >>>>>>> "transaction" >>>>>>>>> that starts when it delegates a task to a dCDN (e.g. CDN-C) = and ends >>>>>>> when >>>>>>>>> the dCDN completes the task, and the uCDN just records the = whole >>>>>>>> transaction >>>>>>>>> without the details that are reported by CDN-C. Then CDN-B = logs only the >>>>>>>>> whole transaction. I would like to see an explicit example of = such >>>>>>> logging, >>>>>>>>> using the cdni_http_request_v1 record-type, so this is clear.) >>>>>>>>=20 >>>>>>>> Yes, that is pretty much the idea. >>>>>>>> ie. if CDN-a delegate sto CDN-B then CDB-B is responsible for = delivering >>>>>>> and >>>>>>>> will provide a delivery record to CDN-A for that delivery. That = record >>>>>>> will be >>>>>>>> part of a Logging File whose origin in CDN-B, and CDN-A can use >>>>>>>> authentication mechanism to ensure the Logging File is provided = by CDN-B. >>>>>>>> All of this completely holds whether CDN-B performed the = delivery itself >>>>>>>> (and created the delivery record in the first place) or CDN-B = delegated to >>>>>>>> CDN-C who provided the delivery record to CDN-B in a Logging = File whose >>>>>>>> origin was CDN-C. >>>>>>>>=20 >>>>>>>> This question has come up before so I will add a clarification = along the >>>>>>> lines >>>>>>>> above under the description of the Verified Origin in case of = cascaded >>>>>>> CDNs. >>>>>>>=20 >>>>>>> An example of such integrated cascaded logging might answer many = questions. >>>>>>=20 >>>>>> Good idea.=20 >>>>>> It sounds worthwhile to give a descripton of how log records get = aggregated in a csacaded scenario, indicate how directives/fields get = modified/kept at each CDN hop, and possibly include an example with some = log records and how they propagate from CDN-C to CDN-B to CDN-A. >>>>>>=20 >>>>>>> If logging records from CDN-C get copied into the log from = CDN-B, are all >>>>>>> directives and record types copied? >>>>>>> If so, I think it is important to make clear that a given log = might contain >>>>>>> multiple nested logs, >>>>>>> And that means that the file received by CDN-A might start with = directives >>>>>>> for CDN-B plus records,=20 >>>>>>> And then directives for CDN-C, ending with an Integrity-Hash, = and more >>>>>>> records for CDN-B followed by an Integrity-Hash. >>>>>>> Maybe this is all as designed, but I haven't seen discussion of = that, and it >>>>>>> is not reflected in Figure 3, and this is not discussed in the = description >>>>>>> of fields that are file-specific, such as Integrity-hash, = Verfiied-origin, >>>>>>> Version, UUID, etc. >>>>>>> If you have nested logs, then log-consuming applications need to = know that >>>>>>> those file-specific directives un-nest at the end of the = included file. Can >>>>>>> they tell consistently when they hit the end of the included = file? >>>>>>> Should there be an end-of-log marker for the included log?=20 >>>>>>>=20 >>>>>>> The Integrity-Hash directive is allowed to occur zero or once, = not multiple >>>>>>> times in a logfile. >>>>>>> So if the CDN-C logfile contains an Integrity-Hash, should that = be checked >>>>>>> by CDN-B, then copy the CDN-C logfile into the CDN-B logfile, = but discard >>>>>>> the CDN-C Integrity-Hash, because CDN-B will calculate its own >>>>>>> Integrity-Hash directive? >>>>>>=20 >>>>>> Yes. >>>>>>=20 >>>>>>>=20 >>>>>>>> Let me know if that is not sufficient. >>>>>>>=20 >>>>>>> I remain concerned that cascaded logging may not have been = adequately >>>>>>> described and standardized. >>>>>>=20 >>>>>> Right. I see that the questions you raised were not answered in = the document. We will work on addressing them. >>>>>>=20 >>>>>> Thanks >>>>>>=20 >>>>>> Francois >>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Francois >>>>>>>=20 >>>>>>> dbh >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> 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 >>=20 >=20 From nobody Thu Jul 24 04:44:48 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC0D1A01CA for ; Thu, 24 Jul 2014 04:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.502 X-Spam-Level: X-Spam-Status: No, score=-10.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_BACKHAIR_31=1, J_BACKHAIR_37=1, J_BACKHAIR_44=1, J_BACKHAIR_52=1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYs4NgbpmHfa for ; Thu, 24 Jul 2014 04:44:42 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E765A1A017E for ; Thu, 24 Jul 2014 04:44:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=38694; q=dns/txt; s=iport; t=1406202282; x=1407411882; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=IBqdyAuSXPKu5p9b5q/Qv8sv07MJltZPnh1PUG66MVE=; b=eY/y9uy6s1/j8sovEh/cS0eDTvYXE2tC3vn+nBBCTJ6vxLIqQ5hPtkvj FvGdjzXdjR9zZIIAn/dH0YexCFTFdpGMXByW3/c8BalqGzAWbfFseG/6p RjUlGms6GBof0a62f8IDP9fNjCFp8RKJUuG8UuEjZhuyWXSvVbqTD9pR4 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArgPANbw0FOtJA2D/2dsb2JhbABPAQmDDlJXBK96mR8Kh0UBgQwWd4QDAQEBAwEBAQEXAQxHBAcFCwIBCBgVGScLFwENAgQOAwKILgMJCA24ZAiHMxeNKYFGASgzBwIIgySBGAWWSkqEH4FSikiIKINIQSsBAYFD X-IronPort-AV: E=Sophos;i="5.01,723,1400025600"; d="scan'208";a="63640012" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-8.cisco.com with ESMTP; 24 Jul 2014 11:44:39 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6OBidxE022700 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Jul 2014 11:44:39 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Thu, 24 Jul 2014 06:44:38 -0500 From: "Francois Le Faucheur (flefauch)" To: Niven-Jenkins Ben Thread-Topic: Utility of Verified-Origin & Claimed-Origin in CDNI logging Thread-Index: AQHPluW8wWdZ2VEK5ESkrvRbs+8LfJuP5tkAgAUHnYCAGbmTAIAA5y2A Date: Thu, 24 Jul 2014 11:44:38 +0000 Message-ID: <8373C544-C53B-4697-9A47-711392ED3472@cisco.com> References: <038401cf5b4f$0b5ea610$221bf230$@comcast.net> <05BD7B6B-6886-4277-8A8A-8AE77363939B@cisco.com> <315A2A4B-C876-4FF7-A836-7D48AC191195@cisco.com> <6DA3197C-D6F7-42A4-BDE7-D3BE77E8A625@cisco.com> <1154D50C-6A82-457B-ADE4-F384B8BF9437@niven-jenkins.co.uk> In-Reply-To: <1154D50C-6A82-457B-ADE4-F384B8BF9437@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.80.230] Content-Type: text/plain; charset="Windows-1252" Content-ID: <2E592E3841A0E1459A6F19F786E8F0CB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/14IUib4m5QbY2qvthBOY47Ud7g4 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Utility of Verified-Origin & Claimed-Origin in CDNI logging X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jul 2014 11:44:46 -0000 Hi Ben and everyone, On 23 Jul 2014, at 17:56, Ben Niven-Jenkins wrote= : > Francois, >=20 > See below. >=20 > On 7 Jul 2014, at 14:06, Francois Le Faucheur (flefauch) wrote: >=20 >> On 4 Jul 2014, at 10:17, Francois Le Faucheur (flefauch) wrote: >>=20 >>> Hi Ben, >>>=20 >>> On 3 Jul 2014, at 19:39, Ben Niven-Jenkins wr= ote: >>>=20 >>>> Francois, Colleagues, >>>>=20 >>>> Reading your suggested text below made me ponder on the purpose and ut= ility of the Claimed-Origin and Verified-Origin field directives. >>>>=20 >>>> Let=92s start with Verified-Origin. From your text below and reading t= he definition of Verified-Origin in section 3.3 of draft-ietf-cdni-logging-= 11 I understand that a dCDN MUST NOT place a Verified-Origin field directiv= e in a log file it sends to a uCDN (it is the uCDN=92s job to do that if it= wants to once it has verified the origin). Furthermore in a cascaded scena= rio (uCDN-tCDN-dCDN) the transit CDN MUST NOT include a Verified-Origin fie= ld directive in a log file it sends to uCDN and by implication if tCDN inse= rted a Verified-Origin directive when receiving from dCDN, it must strip it= before sending that log file on to uCDN. >>>=20 >>> Yes. >>>=20 >>>>=20 >>>> Therefore use of Verified-Origin is purely internal to a given CDN, is= never exchanged between CDNs and has no role to play in interoperation of = CDNI between CDNs, so why does the logging draft need to specify it at all? >>>=20 >>> That=92s a good question. >>>=20 >>> I think the train of thought that got us there is the following : >>> * when storing the CDNI Logging File, the uCDN would want to have an e= asy way to identify where the CDNI Logging File is coming from >>> * since the dCDN knows who he is, it is trivial for it to include its = identification in a field inside the file >>> * the uCDN may be happy with that, in which case it does not have to d= o anything; >>> * or the uCDN may want to record the identification it establishes, in= which case it has to add the corresponding field itself. >>> That=92s more or less how we got there. >>>=20 >>> My personal take would be: >>> *A* if we expect that uCDNs would typically want to have an explicit r= ecord inside the CDNI Logging File of the dCDN that originated the file , t= hen we should define directive(s) to do that. This will make things more co= nsistent for processing tools/utilities operating over CDNI Logs. And in th= e case where the uCDN is happy with the origin as stated by dCDN (say becau= se the dCDN is operated by the same administrative entity), it will save an= y file manipulation by the uCDN. >>> *B* if we expect that uCDNs would typically NOT want to have an explic= it record inside the CDNI Logging File of the dCDN that originated the file= (say because they want to encode that information inside the filename), th= en there may not be much value in defining the directives. >>=20 >> Does this make sense to you? >> What is your take on whether uCDNS would typically want to store the ori= gin of teh CDNI Logging File inside the file? >=20 > Honestly, I=92m not sure. Defining a directive to allow a uCDN to do this= is not harmful, even if it turns out no-one ends up using it. >=20 > But that=92s only one half. The other half is that I interpreted the text= as stating that Verified-Origin had a relationship to Claimed-Origin, i.e.= you were defining that Verified-Origin meant the value of Claimed-Origin h= ad been =91verified=92 in some way. >=20 > Whereas now what I think you mean is that we define two directives, one w= here a dCDN can place what dCDN considers dCDN=92s =91identifier=92 to be (= Claimed-Origin) and one where the uCDN can place what the uCDN considers dC= DN=92s =91identifier=92 to be (Verified-Origin) and how uCDN determines wha= t it considers dCDN=92s =91identifier=92 to be is not specified and may not= use or rely on the value of Claimed-Origin at all? Yes, that is what was intended. But the text did not say it correctly. >=20 > If I=92ve interpreted your position correctly, then you might want to mak= e that more explicit in the text. We will. That sounds like a good plan. Thanks Francois >=20 > HTH > Ben >=20 >>=20 >> Tx >>=20 >> Francois >>=20 >>> I personally lean towards *A*, but let=92s hear more opnions or argumen= ts.=20 >>>=20 >>> Cheers >>>=20 >>> Francois >>>=20 >>>=20 >>>> CDNs that want the functionality of Verified-Origin can do whatever th= ey want internally to implement that, it doesn=92t seem we need something i= n the RFC to support the internal behaviour of a CDN. >>>>=20 >>>>=20 >>>> That then got me thinking about Claimed-Origin. If I read the text bel= ow correctly, my understanding is that the value of Claimed-Origin should b= e the same hostname in the dCDN that the uCDN connects to in order to retri= eve log files. So for example a uCDN could compare the value of Claimed-Ori= gin against the values of subjectAltName in the TLS certificate presented b= y the dCDN and if there is a match then the Claimed-Origin can be =93verifi= ed=94. >>>>=20 >>>> I=92m struggling to see what value Claimed-Origin gives in practice, p= ossibly because I don=92t understand the use case for it. If the purpose i= s to let a uCDN do the comparison I describe above then I=92m not sure that= gives us much in reality. Claimed-Origin becomes essentially a hop-by-hop = (CDN-by-CDN) property and assuming the dCDN identifies itself correctly (e.= g. hostname in dCDN that uCDN connected to matches hostname(s) in TLS certi= ficate presented by dCDN) Claimed-Origin is adding nothing, or have I misun= derstood? >>>>=20 >>>> Thanks >>>> Ben >>>>=20 >>>> On 2 Jul 2014, at 15:39, Francois Le Faucheur (flefauch) wrote: >>>>=20 >>>>>=20 >>>>> On 1 Jul 2014, at 20:09, Francois Le Faucheur (flefauch) wrote: >>>>>=20 >>>>>> Folks, >>>>>>=20 >>>>>> (as a document editor) >>>>>>=20 >>>>>> To address the point around cascaded CDNs that was raised by David H= arrington as part of his early Ops Review, I have: >>>>>> * expanded section 3.5 =93CDNI Logging File Example=94 >>>>>> * added a section 3.6 "Cascaded CDNI Logging Files Example=94 >>>>>>=20 >>>>>> Draft text is below. I=92d appreciate some reviews. >>>>>=20 >>>>> I did a bit more work on teh text. Latest version below. Again will a= ppreciate a good review: >>>>>=20 >>>>> 3.5. CDNI Logging File Example >>>>>=20 >>>>> Let us consider the upstream CDN and the downstream CDN labelled uCDN >>>>> and dCDN-1 in Figure 1. When dCDN-1 acts as a downstream CDN for >>>>> uCDN and performs content delivery on behalf of uCDN, dCDN-1 will >>>>> include the CDNI Logging Records corresponding to the content >>>>> deliveries performed on behalf of uCDN in the CDNI Logging Files for >>>>> uCDN. An example CDNI Logging File communicated by dCDN-1 to uCDN is >>>>> shown below in Figure 4. >>>>>=20 >>>>> #Version:CDNI/1.0 >>>>>=20 >>>>> #UUID:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 >>>>>=20 >>>>> #Claimed-Origin:cdni-logging-entity.dcdn-1.example.com >>>>>=20 >>>>> #Record-Type:cdni_http_request_v1 >>>>>=20 >>>>> #Fields:datetimetime-takenc-ip >>>>> cs-methodu-uriprotocolsc-status >>>>> sc-total-bytescs(User-Agent)cs(Referer) >>>>> s-cached >>>>>=20 >>>>> 2013-05-1700:38:06.8259.05810.5.7.1GET >>>>> http://cdni-ucdn.dcdn-1.example.com/video/movie100.mp4 >>>>> HTTP/1.12006729891"Mozilla/5.0 >>>>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>>>> Gecko) Chrome/5.0.375.127 Safari/533.4" >>>>> "host1.example.com"1 >>>>>=20 >>>>> 2013-05-1700:39:09.14515.3210.5.10.5GET >>>>> http://cdni-ucdn.dcdn-1.example.com/video/movie118.mp4 >>>>> HTTP/1.120015799210"Mozilla/5.0 >>>>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>>>> Gecko) Chrome/5.0.375.127 Safari/533.4" >>>>> "host1.example.com"1 >>>>>=20 >>>>> 2013-05-1700:42:53.43752.87910.5.10.5GET >>>>> http://cdni-ucdn.dcdn-1.example.com/video/picture11.mp4 >>>>> HTTP/1.020097234724"Mozilla/5.0 >>>>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>>>> Gecko) Chrome/5.0.375.127 Safari/533.4" >>>>> "host5.example.com"0 >>>>>=20 >>>>> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >>>>>=20 >>>>> [Editor's Note: compute the correct Integrity-Hash value once example >>>>> is frozen] >>>>>=20 >>>>>=20 >>>>> Figure 4: CDNI Logging File Example >>>>>=20 >>>>> If uCDN establishes by some means (e.g. via TLS authentication when >>>>> pulling the CDNI Logging File) the identity of the entity from which >>>>> it pulled the CDNI Logging File, uCDN can add to the CDNI Logging a >>>>> Verified-Origin directive as illustrated below: >>>>>=20 >>>>> #Verified-Origin:cdni-logging-entity.dcdn-1.example.com >>>>>=20 >>>>> As illustrated in Figure 2, uCDN will then ingest the corresponding >>>>> CDNI Logging Records into its Collection process, alongside the >>>>> Logging Records generated locally by the uCDN itself. This allows >>>>> uCDN to aggregate Logging Records for deliveries performed by itself >>>>> (through Records generated locally) as well as for deliveries >>>>> performed by its downstream CDN(s). This aggregate information can >>>>> then be used (after Filtering and Rectification, as illustrated in >>>>> Figure 2) by Log Consuming Applications that take into account >>>>> deliveries performed by uCDN as well as by all of its downstream >>>>> CDNs. >>>>>=20 >>>>> We observe that the time between >>>>>=20 >>>>> 1. when a delivery is completed in dCDN and >>>>>=20 >>>>> 2. when the corresponding Logging Record is ingested by the >>>>> Collection process in uCDN >>>>>=20 >>>>> depends on a number of parameters such as the Logging Period agreed >>>>> to by uCDN and dCDN, how much time uCDN waits before pulling the CDNI >>>>> Logging File once it is advertised in the CDNI Logging Feed, and the >>>>> time to complete the pull of the CDNI Logging File. Therefore, if we >>>>> consider the set of Logging Records aggregated by the Collection >>>>> process in uCDN in a given time interval, there could be a permanent >>>>> significant timing difference between the CDNI Logging Records >>>>> received from the dCDN and the Logging Records generated locally. >>>>> For example, in a given time interval, the Collection process in uCDN >>>>> may be aggregating Logging Records generated locally by uCDN for >>>>> deliveries performed in the last hour and CDNI Logging Records >>>>> generated in the dCDN for deliveries in the hour before last. >>>>>=20 >>>>> 3.6. Cascaded CDNI Logging Files Example >>>>>=20 >>>>> Let us consider the cascaded CDN scenario of uCDN, dCDN-2 and dCDN-3 >>>>> as depicted in Figure 1. After completion of a delivery by dCDN-3 on >>>>> behalf of dCDN-2, dCDN-3 will include a corresponding Logging Record >>>>> in a CDNI Logging File that will be pulled by dCDN-2 and that is >>>>> illustrated below in Figure 5. In practice, a CDNI Logging File is >>>>> likely to contain a very high number of CDNI Logging Records. >>>>> However, for readability, the example in Figure 5 contains a single >>>>> CDNI Logging Record. >>>>>=20 >>>>>=20 >>>>> #Version:CDNI/1.0 >>>>>=20 >>>>> #UUID:urn:uuid:65718ef-0123-9876-adce4321bcde >>>>>=20 >>>>> #Claimed-Origin:cdni-logging-entity.dcdn-3.example.com >>>>>=20 >>>>> #Record-Type:cdni_http_request_v1 >>>>>=20 >>>>> #Fields:datetimetime-takenc-ip >>>>> cs-methodu-uriprotocolsc-status >>>>> sc-total-bytescs(User-Agent)cs(Referer) >>>>> s-cached >>>>>=20 >>>>> 2013-05-1700:39:09.11914.0710.5.10.9GET >>>>> http://cdni-dcdn-2.dcdn-3.example.com/video/movie118.mp4 >>>>> HTTP/1.120015799210"Mozilla/5.0 >>>>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>>>> Gecko) Chrome/5.0.375.127 Safari /533.4" >>>>> "host1.example.com"1 >>>>>=20 >>>>> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >>>>>=20 >>>>> [Editor's Note: compute the correct Integrity-Hash value once example >>>>> is frozen] >>>>>=20 >>>>> Figure 5: Cascaded CDNI Logging File Example (dCDN-3 to dCDN-2) >>>>>=20 >>>>> If dCDN-2 establishes by some means (e.g. via TLS authentication when >>>>> pulling the CDNI Logging File) the identity of the entity from which >>>>> it pulled the CDNI Logging File, dCDN-2 can add to the CDNI Logging a >>>>> Verified-Origin directive as illustrated below: >>>>>=20 >>>>> #Verified-Origin:cdni-logging-entity.dcdn-3.example.com >>>>>=20 >>>>> dCDN-2 (behaving as an upstream CDN from the viewpoint of dCDN-3) >>>>> will then ingest the CDNI Logging Record for the considered dCDN-3 >>>>> delivery into its Collection process (as illustrated in Figure 2). >>>>> This Logging Record may be aggregated with Logging Records generated >>>>> locally by dCDN-2 for deliveries performed by dCDN-2 itself. Say, >>>>> for illustration, that the content delivery performed by dCDN-3 on >>>>> behalf of dCDN-2 had actually been redirected to dCDN-2 by uCDN, and >>>>> say that another content delivery has just been redirected by uCDN to >>>>> dCDN-2 and that dCDN-2 elected to perform the corresponding delivery >>>>> itself. Then after Filtering and Rectification (as illustrated in >>>>> Figure 2), dCDN-2 will include the two Logging Records corresponding >>>>> respectively to the delivery performed by dCDN-3 and the delivery >>>>> performed by dCDN-2, in the next CDNI Logging File that will be >>>>> communicated to uCDN. An example of such CDNI Logging File is >>>>> illustrated below in Figure 6. >>>>>=20 >>>>> #Version:CDNI/1.0 >>>>>=20 >>>>> #UUID:urn:uuid:1234567-8fedc-abab-0987654321ff >>>>>=20 >>>>> #Claimed-Origin:cdni-logging-entity.dcdn-2.example.com >>>>>=20 >>>>> #Record-Type:cdni_http_request_v1 >>>>>=20 >>>>> #Fields:datetimetime-takenc-ip >>>>> cs-methodu-uriprotocolsc-status >>>>> sc-total-bytescs(User-Agent)cs(Referer) >>>>> s-cached >>>>>=20 >>>>> 2013-05-1700:39:09.11914.0710.5.10.9GET >>>>> http://cdni-ucdn.dcdn-2.example.com/video/movie118.mp4 >>>>> HTTP/1.120015799210"Mozilla/5.0 >>>>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>>>> Gecko) Chrome/5.0.375.127 Safari /533.4" >>>>> "host1.example.com"1 >>>>>=20 >>>>> 2013-05-1701:42:53.43752.87910.5.10.12GET >>>>> http://cdni-ucdn.dcdn-2.example.com/video/picture11.mp4 >>>>> HTTP/1.020097234724"Mozilla/5.0 >>>>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>>>> Gecko) Chrome/5.0.375.127 Safari /533.4" >>>>> "host5.example.com"0 >>>>>=20 >>>>> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >>>>>=20 >>>>> [Editor's Note: compute the correct Integrity-Hash value once example >>>>> is frozen] >>>>>=20 >>>>> Figure 6: Cascaded CDNI Logging File Example (dCDN-2 to uCDN) >>>>>=20 >>>>> If uCDN establishes by some means (e.g. via TLS authentication when >>>>> pulling the CDNI Logging File) the identity of the entity from which >>>>> it pulled the CDNI Logging File, uCDN can add to the CDNI Logging a >>>>> Verified-Origin directive as illustrated below: >>>>>=20 >>>>> #Verified-Origin:cdni-logging-entity.dcdn-2.example.com >>>>>=20 >>>>> In the example of Figure 6, we observe that: >>>>>=20 >>>>> o the first Logging Record corresponds to the Logging Record >>>>> communicated earlier to dCDN-2 by dCDN-3, which corresponds to a >>>>> delivery redirected by uCDN to dCDN-2 and then redirected by >>>>> dCDN-2 to dCDN-3. Its initial fields values are preserved, with >>>>> the exception of the u-uri that now reflects the URI convention >>>>> between uCDN and dCDN-2, and which presents the delivery to uCDN >>>>> as if it was performed by dCDN-2 itself, which reflects the fact >>>>> that dCDN-2 had taken the full responsibility of the corresponding >>>>> delivery (even if in this case, dCDN-2 elected to redirect the >>>>> delivery to dCDN-3 so it is actually performed by dCDN-3 on behalf >>>>> of dCDN-2). >>>>>=20 >>>>> o the second Logging Record corresponds to a delivery redirected by >>>>> uCDN to dCDN-2 and performed by dCDN-2 itself. The time of the >>>>> delivery in this Logging Record may be significantly more recent >>>>> than the first Logging Record since it was generated locally while >>>>> the first Logging Record was generated by dCDN-3 and had to be >>>>> advertised , and then pulled and then ingested into the dCDN-2 >>>>> Collection process, before being aggregated with the second >>>>> Logging Record. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Cheers >>>>>=20 >>>>> Francois >>>>>=20 >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Thanks >>>>>>=20 >>>>>> Francois >>>>>>=20 >>>>>> " >>>>>>=20 >>>>>> 3.5. CDNI Logging File Example >>>>>>=20 >>>>>> Let us consider the upstream CDN and the downstream CDN labelled uCD= N >>>>>> and dCDN-1 in Figure 1. When dCDN-1 acts as a downstream CDN for >>>>>> uCDN and performs content delivery on behalf of uCDN, dCDN-1 will >>>>>> include the CDNI Logging Records corresponding to the content >>>>>> deliveries performed on behalf of uCDN in the CDNI Logging Files for >>>>>> uCDN. An example CDNI Logging File communicated by dCDN-1 to uCDN i= s >>>>>> show below: >>>>>>=20 >>>>>> " >>>>>>=20 >>>>>> #Version:CDNI/1.0 >>>>>>=20 >>>>>> #UUID:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 >>>>>>=20 >>>>>> #Claimed-Origin:cdni-logging-entity.dcdn-1.example.com >>>>>>=20 >>>>>> #Record-Type:cdni_http_request_v1 >>>>>>=20 >>>>>> #Fields:datetimetime-takenc-ipcs- >>>>>> methodu-uriprotocolsc-statussc-total- >>>>>> bytescs(User-Agent)cs(Referer)s-cached >>>>>>=20 >>>>>> 2013-05-1700:38:06.8259.05810.5.7.1GET= h >>>>>> ttp://cdni-ucdn.dcdn-1.example.com/video/ >>>>>> movie100.mp4HTTP/1.12006729891"Mozilla/5.0 >>>>>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>>>>> Gecko) Chrome/5.0.375.127 Safari >>>>>> /533.4""host1.example.com"1 >>>>>>=20 >>>>>> 2013-05-1700:39:09.14515.3210.5.10.5GET >>>>>> http://cdni-ucdn.dcdn-1.example.com/video/ >>>>>> movie118.mp4HTTP/1.120015799210"Mozilla/5.0 >>>>>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>>>>> Gecko) Chrome/5.0.375.127 Safari >>>>>> /533.4""host1.example.com"1 >>>>>>=20 >>>>>> 2013-05-1700:42:53.43752.87910.5.10.5GET>>>>>> http://cdni-ucdn.dcdn-1.example.com/video/ >>>>>> picture11.mp4HTTP/1.020097234724"Mozilla/5.0 >>>>>> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like >>>>>> Gecko) Chrome/5.0.375.127 Safari >>>>>> /533.4""host5.example.com"0 >>>>>>=20 >>>>>> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >>>>>>=20 >>>>>> [Editor's Note: compute the correct Integrity-Hash value once exampl= e >>>>>> is frozen] >>>>>>=20 >>>>>> " >>>>>>=20 >>>>>> As illustrated in Figure 2, uCDN will then ingest the corresponding >>>>>> CDNI Logging Records into its Collection process, alongside the >>>>>> Logging Records generated locally by the uCDN itself. This allows >>>>>> uCDN to aggregate Logging Records for deliveries performed by itself >>>>>> (through Records generated locally) as well as for deliveries >>>>>> performed by its downstream CDN(s). This aggregate information can >>>>>> then be used (after Filtering and Rectification, as illustrated in >>>>>> Figure 2) by Log Consuming Applications considering deliveries >>>>>> performed by uCDN as well as by all its downstream CDN(s). >>>>>>=20 >>>>>> We observe that the time between >>>>>>=20 >>>>>> 1. when a delivery is completed in dCDN and >>>>>>=20 >>>>>> 2. when the corresponding Logging Record is ingested by the >>>>>> Collection process in uCDN >>>>>>=20 >>>>>> depends on a number of parameters such as the Logging Period agreed >>>>>> to by uCDN and dCDN, how much time uCDN waits after it is advertised >>>>>> in the CDNI Logging Feed before pulling the CDNI Logging File, and >>>>>> the time to complete the pull of the CDNI Logging File. Therefore, >>>>>> if we consider the set of Logging Records aggregated by the >>>>>> Collection process in uCDN in a given time interval, there could be = a >>>>>> permanent significant timing difference between the CDNI Logging >>>>>> Records received from the dCDN and the Logging Records generated >>>>>> locally. For example, in a given time interval, the Collection >>>>>> process in uCDN may be aggregating Logging Records generated locally >>>>>> by uCDN for deliveries performed in the last hour and CDNI Logging >>>>>> Records generated in the dCDN for deliveries in the hour before last= . >>>>>>=20 >>>>>> 3.6. Cascaded CDNI Logging Files Example >>>>>>=20 >>>>>> Let us consider the cascaded CDN scenario of uCDN, dCDN-2 and dCDN-3 >>>>>> as depicted in Figure 1. After completion of a delivery by dCDN-3 o= n >>>>>> behalf of dCDN-2, dCDN-3 will include a corresponding Logging Record >>>>>> in a CDNI Logging File and will advertise this CDNI Logging File to >>>>>> d-CDN2 in the corresponding CDNI Logging feed. As a result, dCDN-2 >>>>>> will initiate and complete the pull of the corresponding CDNI Loggin= g >>>>>> File that is illustrated below: >>>>>>=20 >>>>>> " >>>>>>=20 >>>>>> #Version:CDNI/1.0 >>>>>>=20 >>>>>> #UUID:urn:uuid:65718ef-0123-9876-adce4321bcde >>>>>>=20 >>>>>> #Claimed-Origin:cdni-logging-entity.dcdn-3.example.com >>>>>>=20 >>>>>> #Record-Type:cdni_http_request_v1 >>>>>>=20 >>>>>> #Fields:datetimetime-takenc-ipcs- >>>>>> methodu-uriprotocolsc-statussc-total- >>>>>> bytescs(User-Agent)cs(Referer)s-cached >>>>>>=20 >>>>>> 2013-05-1700:39:09.14515.3210.5.10.5GET >>>>>> http://cdni-dcdn-2.dcdn-3.example.com/video/movie118.mp4HTTP/ >>>>>> 1.120015799210"Mozilla/5.0 (Windows; U; Windows NT >>>>>> 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 >>>>>> Safari /533.4""host1.example.com"1 >>>>>>=20 >>>>>> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >>>>>>=20 >>>>>> [Editor's Note: compute the correct Integrity-Hash value once exampl= e >>>>>> is frozen] >>>>>>=20 >>>>>> " >>>>>>=20 >>>>>> dCDN-2 (behaving as an upstream CDN from the viewpoint of dCDN-3) >>>>>> will then ingest the CDNI Logging Record for the considered dCDN-3 >>>>>> delivery into its Collection process (as illustrated in Figure 2). >>>>>> This Logging Record may be aggregated with Logging Records generated >>>>>> locally by dCDN-2 for deliveries performed by dCDN-2 itself. Say, >>>>>> for illustration, that the content delivery performed by dCDN-3 on >>>>>> behalf of dCDN-2 had actually been redirected to dCDN-2 by uCDN, and >>>>>> say that another content delivery has just been redirected by uCDN t= o >>>>>> dCDN-2 and that dCDN-2 elected to perform the corresponding delivery >>>>>> itself. Then after Filtering and Rectification (as illustrated in >>>>>> Figure 2), dCDN-2 will include the two Logging Records corresponding >>>>>> respectively to the delivery performed by dCDN-3 and the delivery >>>>>> performed by dCDN-2, in the next CDNI Logging File that will be >>>>>> communcated to uCDN. An example of such CDNI Logging File is >>>>>> illustrated below: >>>>>>=20 >>>>>> #Version:CDNI/1.0 >>>>>>=20 >>>>>> #UUID:urn:uuid:1234567-8fedc-abab-0987654321ff >>>>>>=20 >>>>>> #Claimed-Origin:cdni-logging-entity.dcdn-2.example.com >>>>>>=20 >>>>>> #Record-Type:cdni_http_request_v1 >>>>>>=20 >>>>>> #Fields:datetimetime-takenc-ipcs- >>>>>> methodu-uriprotocolsc-statussc-total- >>>>>> bytescs(User-Agent)cs(Referer)s-cached >>>>>>=20 >>>>>> 2013-05-1700:39:09.14515.3210.5.10.5GET >>>>>> http://cdni-ucdn.dcdn-2.example.com/video/movie118.mp4HTTP/ >>>>>> 1.120015799210"Mozilla/5.0 (Windows; U; Windows NT >>>>>> 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 >>>>>> Safari /533.4""host1.example.com"1 >>>>>>=20 >>>>>> 2013-05-1701:42:53.43752.87910.5.10.5GET>>>>>> http://cdni-ucdn.dcdn-2.example.com/video/picture11.mp4HTTP/ >>>>>> 1.020097234724"Mozilla/5.0 (Windows; U; Windows NT >>>>>> 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 >>>>>> Safari /533.4""host5.example.com"0 >>>>>>=20 >>>>>> #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e >>>>>>=20 >>>>>> [Editor's Note: compute the correct Integrity-Hash value once exampl= e >>>>>> is frozen] >>>>>>=20 >>>>>> " >>>>>>=20 >>>>>> In the example above, we observe that: >>>>>>=20 >>>>>> o the first Logging Record corresponds to the Logging Record >>>>>> communicated earlier to dCDN-2 by dCDN-3, which corresponds to a >>>>>> delivery redirected by uCDN to dCDN-2 and then redirected by >>>>>> dCDN-2 to dCDN-3. Its initial fields values are preserved, with >>>>>> the exception of the u-uri that now reflects the URI convention >>>>>> between uCDN and dCDN-2, and which presents the delivery to uCDN >>>>>> as if it was performed by dCDN-2 itself, which reflects the fact >>>>>> that dCDN-2 had taken the full responsibility of the corresponding >>>>>> delivery (even if in this case, dCDN-2 elected to redirect the >>>>>> delivery to dCDN-3 so it is actually performed by dCDN-3 on behalf >>>>>> of dCDN-2). >>>>>>=20 >>>>>> o the second Logging Record corresponds to a delivery redirected by >>>>>> uCDN to dCDN-2 and performed by dCDN-2 itself. The time of the >>>>>> delivery in this Logging Record may be significantly more recent >>>>>> than the first Logging Record since it was generated locally while >>>>>> the first Logging Record was generated by dCDN-3 and had to be >>>>>> advertised , and then pulled and then ingested into the dCDN-2 >>>>>> Collection process, before being aggregated with the second >>>>>> Logging Record. >>>>>>=20 >>>>>> " >>>>>>=20 >>>>>>=20 >>>>>> On 23 Apr 2014, at 20:29, Francois Le Faucheur (flefauch) wrote: >>>>>>=20 >>>>>>> Hello, >>>>>>>=20 >>>>>>> On 18 Apr 2014, at 23:42, ietfdbh wrote: >>>>>>>>>=20 >>>>>>>>> On 5 Apr 2014, at 23:14, ietfdbh wrote: >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Most notably, the logging from a dCDN to a uCDN typically contai= ns only >>>>>>>>> one >>>>>>>>>> dCDN identifier, such as Verified-origin, and doesn't really per= mit >>>>>>>>>> specifying a sub-ordinate dCDN. For example, in a cascade such a= s CDN-A >>>>>>>> - >>>>>>>>>>=20 >>>>>>>>>> CDN-B -> CDN-C, CDN-C will share logging info with CDN-B, but no= t with >>>>>>>>>> CDN-A; CDN-B shares logging info with CDN-A. This can be desirab= le for >>>>>>>>>> hiding the topology and delegation used by the dCDN. However, th= is >>>>>>>>> document >>>>>>>>>> does not discuss how the logging provided by CDN-C gets converte= d into >>>>>>>>> the >>>>>>>>>> logs for CDN-B that will be sent to CDN-A. Without some logging >>>>>>>>> information >>>>>>>>>> from CDN-C, it would seem difficult for CDN-A to utilize the inf= ormation >>>>>>>> to >>>>>>>>>> meet requirements of billing, analytics, and fault and performan= ce >>>>>>>> analysis. >>>>>>>>>> Maybe the logging gets aggregated and reported in CDN-B's loggin= g, >>>>>>>>>=20 >>>>>>>>> Exactly. >>>>>>>>>=20 >>>>>>>>>> but that >>>>>>>>>> "transitive or aggregate logging" doesn't appear to be discussed= in this >>>>>>>>>> document. >>>>>>>>>=20 >>>>>>>>> It is discussed in section 2.1 through Figure 1 and the following= text: >>>>>>>>> " >>>>>>>>> A dCDN (e.g., dCDN-2) integrates the relevant Logging information >>>>>>>>> obtained from its dCDNs (i.e., dCDN-3) in the Logging information >>>>>>>>> that it provides to the uCDN, so that the uCDN ultimately obtains= all >>>>>>>>> Logging information relevant to a CSP for which it acts as the >>>>>>>>> authoritative CDN. >>>>>>>>> " >>>>>>>>> Does that address your concern? >>>>>>>>=20 >>>>>>>> No it does not mitigate my concern. >>>>>>>>=20 >>>>>>>> This says the information gets "integrated", but doesn't describe = what >>>>>>>> integrated means. >>>>>>>> I could interpret that integration would be that the logging from = CDN-C >>>>>>>> would be included in the logs from CDN-B to CDN-A, >>>>>>>> But I think the text says CDN-B will not share the logging entries= from >>>>>>>> CDN-C with CDN-A. >>>>>>>> Do I have this wrong? Does CDN-B create a log file and generate e= ntries, >>>>>>>> and then when it delegates delivery to CDN-C, and CDN-C passes its= log file >>>>>>>> back to CDN-B, does CDN-B take the whole log file from CDN-B and i= nsert it >>>>>>>> into its own log file, then continue adding any more entries, and = then when >>>>>>>> done send the CDN-B log file (including a fully inserted CDN-C log= file) to >>>>>>>> CDN-A? >>>>>>>>=20 >>>>>>>> If not, that presumably means that somehow, the data from CDN-C is >>>>>>>> "aggregated" - that's how it is "integrated=94, >>>>>>>=20 >>>>>>> Right. It is aggregated. >>>>>>> Effectively, if CDN-B has sub-delegated a delivery to CDN-C, then w= hen CDN-C provides a log record for that delivery to CDN-B, CDN-B will aggr= egate that log record with the log records for the deliveries that CDN-B co= nduted itself. When CDN-B provides log records to CDN-A, the log record cor= responding to the delivery performed by CDN-C is turned by CDN-B into a log= record that looks like the delivery was done by CDN-B. CDN-A will not be a= ware that the delivery was performed by another CDN than CDN-B (just like t= he Content Provider is not ware that the delivery was not performed by CDN-= A with whom it has a delivery contract). >>>>>>>=20 >>>>>>>> But there is no discussion of how this aggregation is done. >>>>>>>=20 >>>>>>> That is true. I think it has been assumed by many but never made cl= ear. So we need to add some discussion about that. >>>>>>>=20 >>>>>>>> I think your intent is to hide the fact that CDN-B used CDN-C, sin= ce that >>>>>>>> may reflect a proprietary approach of CDN-B's business model. >>>>>>>=20 >>>>>>> Right. >>>>>>>=20 >>>>>>>> But CDN-A would presumably have problems performing analytics, and= fault and >>>>>>>> performance analysis, if the data from CDN-C is not included in CD= N-B's >>>>>>>> logging to CDN-A.=20 >>>>>>>> So I would like an example to demonstrate what CDN-A would see in = CDN-B's >>>>>>>> logs if CDN-C had faults or performance problems, and I would like= to see >>>>>>>> how CDN-A could perform analytics (of any kind) relating to the de= livery >>>>>>>> performed by CDN-C. >>>>>>>=20 >>>>>>> The assumption is that CDN-A is only dealing with CDN-B. CDN-A may = not not even be aware of CDN-C.=20 >>>>>>> So CDN-A analaytics/monitoring will establish whether all the deliv= eries delegated to CDN-B (comprising deliveries performed by CDN-B as well = as deliveries redirected by CDN-B to CDN-C and possibly CDN-C2) have receiv= ed the right quality (ie if CDN-B has met the SLA committed to CDN-A). >>>>>>> If some deliveries have experienced quality problems, CDN-A will bl= ame CDN-B. It is up to CDN-B to then do its own analytics and monitoring to= decide whether the problem lies within his own CDN or CDN-C or CDN-C2.=20 >>>>>>> The whole thing operates as a chain of delegations, like many other= business arrangements: if my SmartPhone does not work, I blame the smartPh= one vendor (I don=92t try identify if the problem is coming from the suppli= er of the GSM chipset, but the SmartPhone vendor will). >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> I am missing how this would be done (especially in a standardized = manner). >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> I think Verified-Origin is particularly problematic, because the= text >>>>>>>> states >>>>>>>>>> that this can only be added by the uCDN, never the dCDN. So what= if >>>>>>>> CDN-B >>>>>>>>>> verifies the origin of the logs from CDN-C and then passes the >>>>>>>> information >>>>>>>>>> (now as a dCDN) to CDN-A? The text mentions that this might be >>>>>>>>> established >>>>>>>>>> using authentication mechanisms; so do we lose this logged >>>>>>>>>> authentication/verification when cascading? >>>>>>>>>>=20 >>>>>>>>>> (Maybe this is resolved by having the uCDN (CDN-B) record a >>>>>>>> "transaction" >>>>>>>>>> that starts when it delegates a task to a dCDN (e.g. CDN-C) and = ends >>>>>>>> when >>>>>>>>>> the dCDN completes the task, and the uCDN just records the whole >>>>>>>>> transaction >>>>>>>>>> without the details that are reported by CDN-C. Then CDN-B logs = only the >>>>>>>>>> whole transaction. I would like to see an explicit example of su= ch >>>>>>>> logging, >>>>>>>>>> using the cdni_http_request_v1 record-type, so this is clear.) >>>>>>>>>=20 >>>>>>>>> Yes, that is pretty much the idea. >>>>>>>>> ie. if CDN-a delegate sto CDN-B then CDB-B is responsible for del= ivering >>>>>>>> and >>>>>>>>> will provide a delivery record to CDN-A for that delivery. That r= ecord >>>>>>>> will be >>>>>>>>> part of a Logging File whose origin in CDN-B, and CDN-A can use >>>>>>>>> authentication mechanism to ensure the Logging File is provided b= y CDN-B. >>>>>>>>> All of this completely holds whether CDN-B performed the delivery= itself >>>>>>>>> (and created the delivery record in the first place) or CDN-B del= egated to >>>>>>>>> CDN-C who provided the delivery record to CDN-B in a Logging File= whose >>>>>>>>> origin was CDN-C. >>>>>>>>>=20 >>>>>>>>> This question has come up before so I will add a clarification al= ong the >>>>>>>> lines >>>>>>>>> above under the description of the Verified Origin in case of cas= caded >>>>>>>> CDNs. >>>>>>>>=20 >>>>>>>> An example of such integrated cascaded logging might answer many q= uestions. >>>>>>>=20 >>>>>>> Good idea.=20 >>>>>>> It sounds worthwhile to give a descripton of how log records get ag= gregated in a csacaded scenario, indicate how directives/fields get modifie= d/kept at each CDN hop, and possibly include an example with some log recor= ds and how they propagate from CDN-C to CDN-B to CDN-A. >>>>>>>=20 >>>>>>>> If logging records from CDN-C get copied into the log from CDN-B, = are all >>>>>>>> directives and record types copied? >>>>>>>> If so, I think it is important to make clear that a given log migh= t contain >>>>>>>> multiple nested logs, >>>>>>>> And that means that the file received by CDN-A might start with di= rectives >>>>>>>> for CDN-B plus records,=20 >>>>>>>> And then directives for CDN-C, ending with an Integrity-Hash, and = more >>>>>>>> records for CDN-B followed by an Integrity-Hash. >>>>>>>> Maybe this is all as designed, but I haven't seen discussion of th= at, and it >>>>>>>> is not reflected in Figure 3, and this is not discussed in the des= cription >>>>>>>> of fields that are file-specific, such as Integrity-hash, Verfiied= -origin, >>>>>>>> Version, UUID, etc. >>>>>>>> If you have nested logs, then log-consuming applications need to k= now that >>>>>>>> those file-specific directives un-nest at the end of the included = file. Can >>>>>>>> they tell consistently when they hit the end of the included file? >>>>>>>> Should there be an end-of-log marker for the included log?=20 >>>>>>>>=20 >>>>>>>> The Integrity-Hash directive is allowed to occur zero or once, not= multiple >>>>>>>> times in a logfile. >>>>>>>> So if the CDN-C logfile contains an Integrity-Hash, should that be= checked >>>>>>>> by CDN-B, then copy the CDN-C logfile into the CDN-B logfile, but = discard >>>>>>>> the CDN-C Integrity-Hash, because CDN-B will calculate its own >>>>>>>> Integrity-Hash directive? >>>>>>>=20 >>>>>>> Yes. >>>>>>>=20 >>>>>>>>=20 >>>>>>>>> Let me know if that is not sufficient. >>>>>>>>=20 >>>>>>>> I remain concerned that cascaded logging may not have been adequat= ely >>>>>>>> described and standardized. >>>>>>>=20 >>>>>>> Right. I see that the questions you raised were not answered in the= document. We will work on addressing them. >>>>>>>=20 >>>>>>> Thanks >>>>>>>=20 >>>>>>> Francois >>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Francois >>>>>>>>=20 >>>>>>>> dbh >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> 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 >>>=20 >>=20 >=20 From nobody Thu Jul 24 07:42:19 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E958E1A03B1; Thu, 24 Jul 2014 07:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNQMm4pb_qA9; Thu, 24 Jul 2014 07:42:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C13641A00C0; Thu, 24 Jul 2014 07:42:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140724144214.30562.55686.idtracker@ietfa.amsl.com> Date: Thu, 24 Jul 2014 07:42:14 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/N8Odw2ZVrgl4Ykqb1eMnI7lhc-M Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-logging-13.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jul 2014 14:42:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Content Delivery Networks Interconnection Working Group of the IETF. Title : CDNI Logging Interface Authors : Francois Le Faucheur Gilles Bertrand Iuniana Oprescu Roy Peterkofsky Filename : draft-ietf-cdni-logging-13.txt Pages : 51 Date : 2014-07-24 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-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-logging-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 24 07:46:43 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3D41A03B7 for ; Thu, 24 Jul 2014 07:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnNQl0Yru2gH for ; Thu, 24 Jul 2014 07:46:25 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05A071A03C7 for ; Thu, 24 Jul 2014 07:46:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8348; q=dns/txt; s=iport; t=1406213183; x=1407422783; h=from:to:subject:date:message-id:references:mime-version; bh=cvRM1Zes17FLqMM5wBysDwQre6+I30+sX/lm+xQPERQ=; b=kzOB+jXieJ+rHWFg23Y87w6g79So7J1x9a3Edo6AKq4lxRuWP3t/Vb/A Mn/+7wMVEAEN6Q7mu4/cH592/3e9k3np88hrmabhXgH4bsdc5UgF34c+1 6zMjPwmoqcL/72wp5Lh5ddpe7vd6DY1JnRvIiCC1I6dm/4BLyFWdagjMo k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAIMb0VOtJA2H/2dsb2JhbABZgw5SUwQEySkBCYdFAYENFneEAwEBAQQBAQFrGwIBGQMBAigHJwsUBwIIAgQTCYg5CAXAaRePOg0KB4IxUySBGAWbM4FSjFWGG4NIbAGBRA X-IronPort-AV: E=Sophos;i="5.01,724,1400025600"; d="scan'208,217";a="342623130" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-4.cisco.com with ESMTP; 24 Jul 2014 14:46:22 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s6OEkM8i014601 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 24 Jul 2014 14:46:22 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Thu, 24 Jul 2014 09:46:21 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: I-D Action: draft-ietf-cdni-logging-13.txt Thread-Index: AQHPp018EkvaV5q9B0qZk3CARWt9VQ== Date: Thu, 24 Jul 2014 14:46:21 +0000 Message-ID: References: <20140724144214.30562.55686.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.94.87] Content-Type: multipart/alternative; boundary="_000_D3EB386DC5DB4E76AE0B63E52DC57AD6ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/Kn38T5QXAIaD2dvREZSOkvIsZFc Subject: [CDNi] Fwd: I-D Action: draft-ietf-cdni-logging-13.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jul 2014 14:46:34 -0000 --_000_D3EB386DC5DB4E76AE0B63E52DC57AD6ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable (as a document Editor), This version reflects the conclusions of the thread around Claimed-Origin a= nd Verified-Origin. Basically the =93Verified-Origin=94 has been replaced by an =93Established-= Origin=94. Cheers Francois Begin forwarded message: From: > Subject: I-D Action: draft-ietf-cdni-logging-13.txt Date: 24 July 2014 10:42:14 GMT-4 To: > Cc: > Reply-To: > 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 Authors : Francois Le Faucheur Gilles Bertrand Iuniana Oprescu Roy Peterkofsky Filename : draft-ietf-cdni-logging-13.txt Pages : 51 Date : 2014-07-24 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-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-13 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --_000_D3EB386DC5DB4E76AE0B63E52DC57AD6ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable (as a document Editor),

This version reflects the conclusions of the thread around Claimed-Ori= gin and Verified-Origin.
Basically the =93Verified-Origin=94 has been replaced by an =93Establi= shed-Origin=94.

Cheers

Francois

Begin forwarded message:

Subje= ct: I-D Action: draft-ietf-c= dni-logging-13.txt
Date:= 24 July 2014 10:42:14 = GMT-4
To: <= /b><i-d-announce@ietf.org>
Cc: <= /b><cdni@ietf.org>
Reply= -To: <internet-drafts@ietf.org>


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     &nb= sp;     : CDNI Logging Interface
       Authors     &= nbsp;   : Francois Le Faucheur
            &nb= sp;            = Gilles Bertrand
            &nb= sp;            = Iuniana Oprescu
            &nb= sp;            = Roy Peterkofsky
Filename &n= bsp;      : draft-ietf-cdni-logging-13.txt Pages  = ;         : 51
Date  =           : 2014-07-24
Abstract:
  This memo specifies the Logging interface between a downstream = CDN
  (dCDN) and an upstream CDN (uCDN) that are interconnected as pe= r 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 CDN= I
  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-13

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


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

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

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--_000_D3EB386DC5DB4E76AE0B63E52DC57AD6ciscocom_-- From nobody Mon Jul 28 12:10:00 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 598B91A0AC4 for ; Mon, 28 Jul 2014 12:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfL36yaPbgit for ; Mon, 28 Jul 2014 12:09:57 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 0D98D1A0AFF for ; Mon, 28 Jul 2014 12:09:57 -0700 (PDT) Received: from 181.red-2-138-227.dynamicip.rima-tde.net ([2.138.227.181] helo=[10.0.0.159]) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1XBqJ1-0007kK-Jp for cdni@ietf.org; Mon, 28 Jul 2014 20:09:55 +0100 From: Ben Niven-Jenkins Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <04E36057-50DA-401C-860C-DB19C7D82049@niven-jenkins.co.uk> Date: Mon, 28 Jul 2014 20:09:54 +0100 To: cdni@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/KwKcf_qA_WpnAT7SSvwOugeEFxw Subject: [CDNi] Including cdn-path in RI responses? X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 28 Jul 2014 19:09:59 -0000 Colleagues, While doing some editing on the Redirection Interface draft, I noticed = that we currently say that can-path MUST be included in both RI requests = and RI responses. Including it in requests is fine and necessary for loop detection. However, I can=92t think of a good reason to include it in responses, = except for debugging purposes, and in a production environment including = can-path in responses may expose information to a uCDN (business = relationships between a dCDN and other CDNs) that the dCDN may not want = to expose. Unless anyone can provide a good reason why cdn-path MUST be included in = RI responses, I plan to change the document to say that can-path MUST be = included in RI requests and MAY be included in RI responses along with a = note that including it in responses may expose business relationships so = need consideration before doing so. Any objections? Thanks Ben