Subject: Re: [CDNi] OPSDIR review of draft-ietf-cdni-logging-10 - cascade logging

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Tue, 1 Jul 2014 18:09:56 +0000

Folks,

(as a document editor)

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”

Draft text is below. I’d 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:<HTAB>CDNI/1.0<CRLF>

   #UUID:<HTAB>urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6<CRLF>

   #Claimed-Origin:<HTAB>cdni-logging-entity.dcdn-1.example.com<CRLF>

   #Record-Type:<HTAB>cdni_http_request_v1<CRLF>

   #Fields:<HTAB>date<HTAB>time<HTAB>time-taken<HTAB>c-ip<HTAB>cs-
   method<HTAB>u-uri<HTAB>protocol<HTAB>sc-status<HTAB>sc-total-
   bytes<HTAB>cs(User-Agent)<HTAB>cs(Referer)<HTAB>s-cached<CRLF>

   2013-05-17<HTAB>00:38:06.825<HTAB>9.058<HTAB>10.5.7.1<HTAB>GET<HTAB>h
   ttp://cdni-ucdn.dcdn-1.example.com/video/
   movie100.mp4<HTAB>HTTP/1.1<HTAB>200<HTAB>6729891<HTAB>"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"<HTAB>"host1.example.com"<HTAB>1<CRLF>

   2013-05-17<HTAB>00:39:09.145<HTAB>15.32<HTAB>10.5.10.5<HTAB>GET<HTAB>
   http://cdni-ucdn.dcdn-1.example.com/video/
   movie118.mp4<HTAB>HTTP/1.1<HTAB>200<HTAB>15799210<HTAB>"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"<HTAB>"host1.example.com"<HTAB>1<CRLF>

   2013-05-17<HTAB>00:42:53.437<HTAB>52.879<HTAB>10.5.10.5<HTAB>GET<HTAB
   >http://cdni-ucdn.dcdn-1.example.com/video/
   picture11.mp4<HTAB>HTTP/1.0<HTAB>200<HTAB>97234724<HTAB>"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"<HTAB>"host5.example.com"<HTAB>0<CRLF>

   #Integrity-Hash:<HTAB>fe113dfce8fec91323a4fc02261af26e<CRLF>

   [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:<HTAB>CDNI/1.0<CRLF>

   #UUID:<HTAB>urn:uuid:65718ef-0123-9876-adce4321bcde<CRLF>

   #Claimed-Origin:<HTAB>cdni-logging-entity.dcdn-3.example.com<CRLF>

   #Record-Type:<HTAB>cdni_http_request_v1<CRLF>

   #Fields:<HTAB>date<HTAB>time<HTAB>time-taken<HTAB>c-ip<HTAB>cs-
   method<HTAB>u-uri<HTAB>protocol<HTAB>sc-status<HTAB>sc-total-
   bytes<HTAB>cs(User-Agent)<HTAB>cs(Referer)<HTAB>s-cached<CRLF>

   2013-05-17<HTAB>00:39:09.145<HTAB>15.32<HTAB>10.5.10.5<HTAB>GET<HTAB>
   http://cdni-dcdn-2.dcdn-3.example.com/video/movie118.mp4<HTAB>HTTP/
   1.1<HTAB>200<HTAB>15799210<HTAB>"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"<HTAB>"host1.example.com"<HTAB>1<CRLF>

   #Integrity-Hash:<HTAB>fe113dfce8fec91323a4fc02261af26e<CRLF>

   [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:<HTAB>CDNI/1.0<CRLF>

   #UUID:<HTAB>urn:uuid:1234567-8fedc-abab-0987654321ff<CRLF>

   #Claimed-Origin:<HTAB>cdni-logging-entity.dcdn-2.example.com<CRLF>

   #Record-Type:<HTAB>cdni_http_request_v1<CRLF>

   #Fields:<HTAB>date<HTAB>time<HTAB>time-taken<HTAB>c-ip<HTAB>cs-
   method<HTAB>u-uri<HTAB>protocol<HTAB>sc-status<HTAB>sc-total-
   bytes<HTAB>cs(User-Agent)<HTAB>cs(Referer)<HTAB>s-cached<CRLF>

   2013-05-17<HTAB>00:39:09.145<HTAB>15.32<HTAB>10.5.10.5<HTAB>GET<HTAB>
   http://cdni-ucdn.dcdn-2.example.com/video/movie118.mp4<HTAB>HTTP/
   1.1<HTAB>200<HTAB>15799210<HTAB>"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"<HTAB>"host1.example.com"<HTAB>1<CRLF>

   2013-05-17<HTAB>01:42:53.437<HTAB>52.879<HTAB>10.5.10.5<HTAB>GET<HTAB
   >http://cdni-ucdn.dcdn-2.example.com/video/picture11.mp4<HTAB>HTTP/
   1.0<HTAB>200<HTAB>97234724<HTAB>"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"<HTAB>"host5.example.com"<HTAB>0<CRLF>

   #Integrity-Hash:<HTAB>fe113dfce8fec91323a4fc02261af26e<CRLF>

   [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) <[email-masked]> wrote:

> Hello,
> 
> On 18 Apr 2014, at 23:42, ietfdbh <[email-masked]> wrote:
>>> 
>>> On 5 Apr 2014, at 23:14, ietfdbh <[email-masked]> 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 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?
>> 
>> 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 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).
> 
>> 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 model.
> 
> 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 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).
> 
> 
> 
>> I am missing how this would be done (especially in a standardized manner).
>> 
>>> 
>>>> 
>>>> 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 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.
>>> 
>>> 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 questions.
> 
> Good idea. 
> 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.
> 
>> 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 the 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 document. We will work on addressing them.
> 
> Thanks
> 
> Francois
> 
>> 
>>> 
>>> 
>>> 
>>> Francois
>> 
>> dbh
>> 
>

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 2 Jul 2014 14:39:11 +0000

> Draft text is below. I’d appreciate some reviews.

I did a bit more work on teh text. Latest version below. Again will appreciate a good review:

   shown below in Figure 4.

  #Fields:<HTAB>date<HTAB>time<HTAB>time-taken<HTAB>c-ip<HTAB>
  cs-method<HTAB>u-uri<HTAB>protocol<HTAB>sc-status<HTAB>
  sc-total-bytes<HTAB>cs(User-Agent)<HTAB>cs(Referer)<HTAB>
  s-cached<CRLF>

  2013-05-17<HTAB>00:38:06.825<HTAB>9.058<HTAB>10.5.7.1<HTAB>GET<HTAB>
  http://cdni-ucdn.dcdn-1.example.com/video/movie100.mp4<HTAB>
  HTTP/1.1<HTAB>200<HTAB>6729891<HTAB>"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"<HTAB>
  "host1.example.com"<HTAB>1<CRLF>

  2013-05-17<HTAB>00:39:09.145<HTAB>15.32<HTAB>10.5.10.5<HTAB>GET<HTAB>
  http://cdni-ucdn.dcdn-1.example.com/video/movie118.mp4<HTAB>
  HTTP/1.1<HTAB>200<HTAB>15799210<HTAB>"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"<HTAB>
  "host1.example.com"<HTAB>1<CRLF>

  2013-05-17<HTAB>00:42:53.437<HTAB>52.879<HTAB>10.5.10.5<HTAB>GET<HTAB>
  http://cdni-ucdn.dcdn-1.example.com/video/picture11.mp4<HTAB>
  HTTP/1.0<HTAB>200<HTAB>97234724<HTAB>"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"<HTAB>
  "host5.example.com"<HTAB>0<CRLF>

                    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:<HTAB>cdni-logging-entity.dcdn-1.example.com<CRLF>

   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.

   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.

   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.

   #Fields:<HTAB>date<HTAB>time<HTAB>time-taken<HTAB>c-ip<HTAB>
   cs-method<HTAB>u-uri<HTAB>protocol<HTAB>sc-status<HTAB>
   sc-total-bytes<HTAB>cs(User-Agent)<HTAB>cs(Referer)<HTAB>
   s-cached<CRLF>

   2013-05-17<HTAB>00:39:09.119<HTAB>14.07<HTAB>10.5.10.9<HTAB>GET<HTAB>
   http://cdni-dcdn-2.dcdn-3.example.com/video/movie118.mp4<HTAB>
   HTTP/1.1<HTAB>200<HTAB>15799210<HTAB>"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"<HTAB>
   "host1.example.com"<HTAB>1<CRLF>

      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:<HTAB>cdni-logging-entity.dcdn-3.example.com<CRLF>

   communicated to uCDN.  An example of such CDNI Logging File is
   illustrated below in Figure 6.

 #Fields:<HTAB>date<HTAB>time<HTAB>time-taken<HTAB>c-ip<HTAB>
 cs-method<HTAB>u-uri<HTAB>protocol<HTAB>sc-status<HTAB>
 sc-total-bytes<HTAB>cs(User-Agent)<HTAB>cs(Referer)<HTAB>
 s-cached<CRLF>

 2013-05-17<HTAB>00:39:09.119<HTAB>14.07<HTAB>10.5.10.9<HTAB>GET<HTAB>
 http://cdni-ucdn.dcdn-2.example.com/video/movie118.mp4<HTAB>
 HTTP/1.1<HTAB>200<HTAB>15799210<HTAB>"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"<HTAB>
 "host1.example.com"<HTAB>1<CRLF>

 2013-05-17<HTAB>01:42:53.437<HTAB>52.879<HTAB>10.5.10.12<HTAB>GET<HTAB>
 http://cdni-ucdn.dcdn-2.example.com/video/picture11.mp4<HTAB>
 HTTP/1.0<HTAB>200<HTAB>97234724<HTAB>"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"<HTAB>
 "host5.example.com"<HTAB>0<CRLF>

       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:<HTAB>cdni-logging-entity.dcdn-2.example.com<CRLF>

   In the example of Figure 6, we observe that:

Cheers

Francois

> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 3 Jul 2014 18:36:12 +0100

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’ll raise that in a separate thread as it is not related to the OPSDIR review.

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 3 Jul 2014 18:39:21 +0100

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’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.

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’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 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”.

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?

Thanks
Ben

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Fri, 4 Jul 2014 08:17:35 +0000

Hi Ben,

Yes.

> 
> 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?

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 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.

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.

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.
> 
>

---

From: <[email-masked]>
Date: Fri, 4 Jul 2014 10:25:07 +0200

Hello all,

I was thinking yesterday that these directives come from non-repudiation times. 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).

Do you think it could be useful?
-- iuniana

-----Message d'origine-----
De : CDNi [mailto:[email-masked]] De la part de Francois Le Faucheur (flefauch)
Envoyé : vendredi 4 juillet 2014 10:18
À : Niven-Jenkins Ben
Cc : [email-masked]
Objet : Re: [CDNi] Utility of Verified-Origin & Claimed-Origin in CDNI logging

Hi Ben,

On 3 Jul 2014, at 19:39, Ben Niven-Jenkins <[email-masked]> wrote:

> 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.

Yes.

> 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 nee…

That's a good question.

That's more or less how we got there.

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 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".
>
> 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?
>
> Thanks
> Ben
>
>>>     * 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.
>>
>>  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
>>  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
>>  [Editor's Note: compute the correct Integrity-Hash value once
>> example  is frozen]
>>
>>  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:
>>
>> 2013-05-17<HTAB>01:42:53.437<HTAB>52.879<HTAB>10.5.10.12<HTAB>GET<HTA
>> B> http://cdni-ucdn.dcdn-2.example.com/video/picture11.mp4<HTAB>
>>> 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
>>> uCDN.  An example CDNI Logging File communicated by dCDN-1 to uCDN
>>> is show below:
>>>
>>> "
>>>
>>> h ttp://cdni-ucdn.dcdn-1.example.com/video/
>>> 2013-05-17<HTAB>00:39:09.145<HTAB>15.32<HTAB>10.5.10.5<HTAB>GET<HTAB
>>> [Editor's Note: compute the correct Integrity-Hash value once
>>> example is frozen]
>>>
>>> "
>>>
>>> Collection process in uCDN in a given time interval, there could be
>>> a permanent significant timing difference between the CDNI Logging
>>> 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
>>> will initiate and complete the pull of the corresponding CDNI
>>> Logging File that is illustrated below:
>>>
>>> "
>>>
>>> 2013-05-17<HTAB>00:39:09.145<HTAB>15.32<HTAB>10.5.10.5<HTAB>GET<HTAB
>>> >
>>> [Editor's Note: compute the correct Integrity-Hash value once
>>> example is frozen]
>>>
>>> "
>>>
>>> 2013-05-17<HTAB>00:39:09.145<HTAB>15.32<HTAB>10.5.10.5<HTAB>GET<HTAB
>>> [Editor's Note: compute the correct Integrity-Hash value once
>>> example is frozen]
>>>
>>> "
>>>
>>>>>>> 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
>>>>>>> "transitive or aggregate logging" doesn't appear to be discussed
>>>>>>> in this document.
>>>>>>
>>>>>> 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.
>>>>>> "
>>>>> 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?
>>>>>
>>>>> "aggregated" - that's how it is "integrated",
>>>>
>>>> Right. It is aggregated.
>>>>> 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.
>>>>
>>>> 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 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).
>>>>
>>>>
>>>>
>>>>>>> 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,
>>>>>> 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.
>>>>>>
>>>>> 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 the included file?
>>>>> 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.
>>>>
>>>>>
>>>>> I remain concerned that cascaded logging may not have been
>>>>> adequately described and standardized.
>>>>

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles 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 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 confidential or privileged 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 delete 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: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Fri, 4 Jul 2014 08:54:31 +0000

On 4 Jul 2014, at 10:25, <[email-masked]> <[email-masked]> wrote:

> Hello all,
> 
> I was thinking yesterday that these directives come from non-repudiation times.

I don’t 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’t think Ben was proposing to make the Validated Origin transitory. I don’t 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.

> Do you think it could be useful?

Nope.

Francois

---

From: Daryl Malas <[email-masked]>
Date: Sat, 5 Jul 2014 01:23:42 +0000

On 7/4/14, 5:54 PM, "Francois Le Faucheur (flefauch)" <[email-masked]>
wrote:

>I don¹t 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¹t think Ben was proposing to make the Validated Origin transitory.
>I don¹t 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.

>>> Reading your suggested text below made me ponder on the purpose and
>>>utility of the Claimed-Origin and Verified-Origin field directives.
>>> 
>>> 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.
>> 
>> Yes.
>> 
>>> 
>>> 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?
>> 
>> That's a good question.
>> 
>>        * 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
>>        * or the uCDN may want to record the identification it
>>establishes, in which case it has to add the corresponding field itself.
>>        *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.
>> 
>>> 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 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".
>>> 
>>> 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?
>>> 
>>> Thanks
>>> Ben
>>> 
>>>>> To address the point around cascaded CDNs that was raised by David
>>>>>Harrington as part of his early Ops Review,  I have:
>>>>>> 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).
>>>>>> 
>>>>>> That is true. I think it has been assumed by many but never made
>>>>>>clear. So we need to add some discussion about that.
>>>>>> 
>>>>>> 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).
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 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.
>>>>>> 
>>>>>> Right. I see that the questions you raised were not answered in the 
>>>>>>document. We will work on addressing them.
>>>>>> 
>>>>>> Thanks
>>>>>> 
>>>>>> Francois
>>>>>> 
>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Francois
>>>>>>> 
>>>>>>> dbh
>>>>>>> 
>>>>>> 
>>>>> 
>>_________________________________________________________________________
>>________________________________________________
>> 
>> Ce message et ses pieces jointes peuvent contenir des informations 
>>confidentielles 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 electroniques etant susceptibles d'alteration,
>> This message and its attachments may contain confidential or privileged 
>>information that may be protected by law;

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Mon, 7 Jul 2014 13:06:09 +0000

Ben,

Please see below:

> 	*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…

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

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 23 Jul 2014 22:56:50 +0100

Francois,

See below.

> What is your take on whether uCDNS would typically want to store the origin of teh CDNI Logging File inside the file?

Honestly, I’m 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’s 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 ‘verified’ 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’s ‘identifier’ to be (Claimed-Origin) and one where the uCDN can place what the uCDN considers dCDN’s ‘identifier’ to be (Verified-Origin) and how uCDN determines what it considers dCDN’s ‘identifier’ to be is not specified and may not use or rely on the value of Claimed-Origin at all?

If I’ve interpreted your position correctly, then you might want to make that more explicit in the text.

HTH
Ben

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Thu, 24 Jul 2014 11:44:38 +0000

Hi Ben and everyone,

> Whereas now what I think you mean is that we define two directives, one where a dCDN can place what dCDN considers dCDN’s ‘identifier’ to be (Claimed-Origin) and one where the uCDN can place what t…

Yes, that is what was intended. But the text did not say it correctly.

> If I’ve interpreted your position correctly, then you might want to make that more explicit in the text.

We will. That sounds like a good plan.

Thanks

Francois