idnits 2.17.1 draft-ietf-cdni-logging-21.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 2, 2015) is 3095 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCthis' is mentioned on line 2265, but not defined ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7232 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7233 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) ** Obsolete normative reference: RFC 7235 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) == Outdated reference: A later version (-21) exists of draft-ietf-cdni-metadata-12 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force F. Le Faucheur, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track G. Bertrand, Ed. 5 Expires: May 5, 2016 I. Oprescu, Ed. 6 Orange 7 R. Peterkofsky 8 Skytide, Inc. 9 November 2, 2015 11 CDNI Logging Interface 12 draft-ietf-cdni-logging-21 14 Abstract 16 This memo specifies the Logging interface between a downstream CDN 17 (dCDN) and an upstream CDN (uCDN) that are interconnected as per the 18 CDN Interconnection (CDNI) framework. First, it describes a 19 reference model for CDNI logging. Then, it specifies the CDNI 20 Logging File format and the actual protocol for exchange of CDNI 21 Logging Files. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on May 5, 2016. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 60 2. CDNI Logging Reference Model . . . . . . . . . . . . . . . . 5 61 2.1. CDNI Logging interactions . . . . . . . . . . . . . . . . 5 62 2.2. Overall Logging Chain . . . . . . . . . . . . . . . . . . 8 63 2.2.1. Logging Generation and During-Generation Aggregation 9 64 2.2.2. Logging Collection . . . . . . . . . . . . . . . . . 10 65 2.2.3. Logging Filtering . . . . . . . . . . . . . . . . . . 10 66 2.2.4. Logging Rectification and Post-Generation Aggregation 11 67 2.2.5. Log-Consuming Applications . . . . . . . . . . . . . 12 68 2.2.5.1. Maintenance/Debugging . . . . . . . . . . . . . . 12 69 2.2.5.2. Accounting . . . . . . . . . . . . . . . . . . . 13 70 2.2.5.3. Analytics and Reporting . . . . . . . . . . . . . 13 71 2.2.5.4. Content Protection . . . . . . . . . . . . . . . 13 72 2.2.5.5. Notions common to multiple Log Consuming 73 Applications . . . . . . . . . . . . . . . . . . 14 74 3. CDNI Logging File . . . . . . . . . . . . . . . . . . . . . . 16 75 3.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 16 76 3.2. CDNI Logging File Structure . . . . . . . . . . . . . . . 17 77 3.3. CDNI Logging Directives . . . . . . . . . . . . . . . . . 20 78 3.4. CDNI Logging Records . . . . . . . . . . . . . . . . . . 24 79 3.4.1. HTTP Request Logging Record . . . . . . . . . . . . . 25 80 3.5. CDNI Logging File Example . . . . . . . . . . . . . . . . 35 81 3.6. Cascaded CDNI Logging Files Example . . . . . . . . . . . 37 82 4. Protocol for Exchange of CDNI Logging File After Full 83 Collection . . . . . . . . . . . . . . . . . . . . . . . . . 40 84 4.1. CDNI Logging Feed . . . . . . . . . . . . . . . . . . . . 41 85 4.1.1. Atom Formatting . . . . . . . . . . . . . . . . . . . 41 86 4.1.2. Updates to Log Files and the Feed . . . . . . . . . . 41 87 4.1.3. Redundant Feeds . . . . . . . . . . . . . . . . . . . 42 88 4.1.4. Example CDNI Logging Feed . . . . . . . . . . . . . . 42 89 4.2. CDNI Logging File Pull . . . . . . . . . . . . . . . . . 44 90 5. Protocol for Exchange of CDNI Logging File During Collection 45 91 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 92 6.1. CDNI Logging Directive Names Registry . . . . . . . . . . 46 93 6.2. CDNI Logging File version Registry . . . . . . . . . . . 47 94 6.3. CDNI Logging record-types Registry . . . . . . . . . . . 47 95 6.4. CDNI Logging Field Names Registry . . . . . . . . . . . . 48 96 6.5. CDNI Logging MIME Media Type . . . . . . . . . . . . . . 49 98 7. Security Considerations . . . . . . . . . . . . . . . . . . . 50 99 7.1. Authentication, Authorization, Confidentiality, Integrity 100 Protection . . . . . . . . . . . . . . . . . . . . . . . 50 101 7.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 51 102 7.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 51 103 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52 104 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 105 9.1. Normative References . . . . . . . . . . . . . . . . . . 53 106 9.2. Informative References . . . . . . . . . . . . . . . . . 54 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56 109 1. Introduction 111 This memo specifies the CDNI Logging interface between a downstream 112 CDN (dCDN) and an upstream CDN (uCDN). First, it describes a 113 reference model for CDNI logging. Then, it specifies the CDNI 114 Logging File format and the actual protocol for exchange of CDNI 115 Logging Files. 117 The reader should be familiar with the following documents: 119 o CDNI problem statement [RFC6707] and framework [RFC7336] identify 120 a Logging interface, 122 o Section 8 of [RFC7337] specifies a set of requirements for 123 Logging, 125 o [RFC6770] outlines real world use-cases for interconnecting CDNs. 126 These use cases require the exchange of Logging information 127 between the dCDN and the uCDN. 129 As stated in [RFC6707], "the CDNI Logging interface enables details 130 of logs or events to be exchanged between interconnected CDNs". 132 The present document describes: 134 o The CDNI Logging reference model (Section 2), 136 o The CDNI Logging File format (Section 3), 138 o The CDNI Logging File Exchange protocol (Section 4). 140 1.1. Terminology 142 In this document, the first letter of each CDNI-specific term is 143 capitalized. We adopt the terminology described in [RFC6707] and 144 [RFC7336], and extend it with the additional terms defined below. 146 Intra-CDN Logging information: logging information generated and 147 collected within a CDN. The format of the Intra-CDN Logging 148 information may be different to the format of the CDNI Logging 149 information. 151 CDNI Logging information: logging information exchanged across CDNs 152 using the CDNI Logging Interface. 154 Logging information: logging information generated and collected 155 within a CDN or obtained from another CDN using the CDNI Logging 156 Interface. 158 CDNI Logging Field: an atomic element of information that can be 159 included in a CDNI Logging Record. The time an event/task started, 160 the IP address of an End User to whom content was delivered, and the 161 Uniform Resource Identifier (URI) of the content delivered, are 162 examples of CDNI Logging fields. 164 CDNI Logging Record: an information record providing information 165 about a specific event. This comprises a collection of CDNI Logging 166 fields. 168 CDNI Logging File: a file containing CDNI Logging Records, as well as 169 additional information facilitating the processing of the CDNI 170 Logging Records. 172 CDN Reporting: the process of providing the relevant information that 173 will be used to create a formatted content delivery report provided 174 to the CSP in deferred time. Such information typically includes 175 aggregated data that can cover a large period of time (e.g., from 176 hours to several months). Uses of Reporting include the collection 177 of charging data related to CDN services and the computation of Key 178 Performance Indicators (KPIs). 180 CDN Monitoring: the process of providing or displaying content 181 delivery information in a timely fashion with respect to the 182 corresponding deliveries. Monitoring typically includes visibility 183 of the deliveries in progress for service operation purposes. It 184 presents a view of the global health of the services as well as 185 information on usage and performance, for network services 186 supervision and operation management. In particular, monitoring data 187 can be used to generate alarms. 189 1.2. Requirements Language 191 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 192 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 193 "OPTIONAL" in this document are to be interpreted as described in RFC 194 2119 [RFC2119]. 196 2. CDNI Logging Reference Model 198 2.1. CDNI Logging interactions 200 The CDNI logging reference model between a given uCDN and a given 201 dCDN involves the following interactions: 203 o customization by the uCDN of the CDNI Logging information to be 204 provided by the dCDN to the uCDN (e.g., control of which CDNI 205 Logging fields are to be communicated to the uCDN for a given task 206 performed by the dCDN or control of which types of events are to 207 be logged). The dCDN takes into account this CDNI Logging 208 customization information to determine what Logging information to 209 provide to the uCDN, but it may, or may not, take into account 210 this CDNI Logging customization information to influence what CDN 211 logging information is to be generated and collected within the 212 dCDN (e.g., even if the uCDN requests a restricted subset of the 213 logging information, the dCDN may elect to generate a broader set 214 of logging information). The mechanism to support the 215 customization by the uCDN of CDNI Logging information is outside 216 the scope of this document and left for further study. Until such 217 a mechanism is available, the uCDN and dCDN are expected to agree 218 off-line on what exact set of CDNI Logging information is to be 219 provided by the dCDN to the uCDN, and to rely on management plane 220 actions to configure the CDNI Logging functions in the dCDN to 221 generate this information set and in the uCDN to expect this 222 information set. 224 o generation and collection by the dCDN of the intra-CDN Logging 225 information related to the completion of any task performed by the 226 dCDN on behalf of the uCDN (e.g., delivery of the content to an 227 End User) or related to events happening in the dCDN that are 228 relevant to the uCDN (e.g., failures or unavailability in dCDN). 229 This takes place within the dCDN and does not directly involve 230 CDNI interfaces. 232 o communication by the dCDN to the uCDN of the Logging information 233 collected by the dCDN relevant to the uCDN. This is supported by 234 the CDNI Logging interface and in the scope of the present 235 document. For example, the uCDN may use this Logging information 236 to charge the CSP, to perform analytics and monitoring for 237 operational reasons, to provide analytics and monitoring views on 238 its content delivery to the CSP or to perform trouble-shooting. 239 This document exclusively specifies non-real-time exchange of 240 Logging information. Closer to real-time exchange of Logging 241 information (say sub-minute or sub-second) is outside the scope of 242 the present document and left for further study. This document 243 exclusively specifies exchange of Logging information related to 244 content delivery. Exchange of Logging information related to 245 operational events (e.g., dCDN request routing function 246 unavailable, content acquisition failure by dCDN) for audit or 247 operational reactive adjustments by uCDN is outside the scope of 248 the present document and left for further study. 250 o customization by the dCDN of the CDNI Logging information to be 251 provided by the uCDN on behalf of the dCDN. The mechanism to 252 support the customization by the dCDN of CDNI Logging information 253 is outside the scope of this document and left for further study. 255 o generation and collection by the uCDN of Intra-CDN Logging 256 information related to the completion of any task performed by the 257 uCDN on behalf of the dCDN (e.g., serving of content by uCDN to 258 dCDN for acquisition purposes by dCDN) or related to events 259 happening in the uCDN that are relevant to the dCDN. This takes 260 place within the uCDN and does not directly involve CDNI 261 interfaces. 263 o communication by the uCDN to the dCDN of the Logging information 264 collected by the uCDN relevant to the dCDN. For example, the dCDN 265 might potentially benefit from this information for security 266 auditing or content acquisition troubleshooting. This is outside 267 the scope of this document and left for further study. 269 Figure 1 provides an example of CDNI Logging interactions (focusing 270 only on the interactions that are in the scope of this document) in a 271 particular scenario where four CDNs are involved in the delivery of 272 content from a given CSP: the uCDN has a CDNI interconnection with 273 dCDN-1 and dCDN-2. In turn, dCDN-2 has a CDNI interconnection with 274 dCDN-3, where dCDN-2 is acting as an upstream CDN relative to dCDN-3. 275 In this example, uCDN, dCDN-1, dCDN-2 and dCDN-3 all participate in 276 the delivery of content for the CSP. In this example, the CDNI 277 Logging interface enables the uCDN to obtain Logging information from 278 all the dCDNs involved in the delivery. In the example, the uCDN 279 uses the Logging information: 281 o to analyze the performance of the delivery performed by the dCDNs 282 and to adjust its operations after the fact (e.g., request 283 routing) as appropriate, 285 o to provide (non-real-time) reporting and monitoring information to 286 the CSP. 288 For instance, the uCDN merges Logging information, extracts relevant 289 KPIs, and presents a formatted report to the CSP, in addition to a 290 bill for the content delivered by uCDN itself or by its dCDNs on the 291 CSP's behalf. The uCDN may also provide Logging information as raw 292 log files to the CSP, so that the CSP can use its own logging 293 analysis tools. 295 +-----+ 296 | CSP | 297 +-----+ 298 ^ Reporting and monitoring data 299 * Billing 300 ,--*--. 301 Logging ,-' `-. 302 Data =>( uCDN )<= Logging 303 // `-. _,-' \\ Data 304 || `-'-'-' || 305 ,-----. ,-----. 306 ,-' `-. ,-' `-. 307 ( dCDN-1 ) ( dCDN-2 )<== Logging 308 `-. ,-' `-. _,-' \\ Data 309 `--'--' `--'-' || 310 ,-----. 311 ,' `-. 312 ( dCDN-3 ) 313 `. ,-' 314 `--'--' 316 ===> CDNI Logging Interface 317 ***> outside the scope of CDNI 319 Figure 1: Interactions in CDNI Logging Reference Model 321 A downstream CDN relative to uCDN (e.g., dCDN-2) integrates the 322 relevant Logging information obtained from its own downstream CDNs 323 (i.e., dCDN-3) in the Logging information that it provides to the 324 uCDN, so that the uCDN ultimately obtains all Logging information 325 relevant to a CSP for which it acts as the authoritative CDN. Such 326 aggregation is further discussed in Section 3.6. 328 Note that the format of Logging information that a CDN provides over 329 the CDNI interface might be different from the one that the CDN uses 330 internally. In this case, the CDN needs to reformat the Logging 331 information before it provides this information to the other CDN over 332 the CDNI Logging interface. Similarly, a CDN might reformat the 333 Logging information that it receives over the CDNI Logging interface 334 before injecting it into its log-consuming applications or before 335 providing some of this Logging information to the CSP. Such 336 reformatting operations introduce latency in the logging distribution 337 chain and introduce a processing burden. Therefore, there are 338 benefits in specifying CDNI Logging formats that are suitable for use 339 inside CDNs and also are close to the intra-CDN Logging formats 340 commonly used in CDNs today. 342 2.2. Overall Logging Chain 344 This section discusses the overall logging chain within and across 345 CDNs to clarify how CDN Logging information is expected to fit in 346 this overall chain. Figure 2 illustrates the overall logging chain 347 within the dCDN, across CDNs using the CDNI Logging interface and 348 within the uCDN. Note that the logging chain illustrated in the 349 Figure is obviously only an example and varies depending on the 350 specific environments. For example, there may be more or fewer 351 instantiations of each entity (e.g., there may be 4 Log consuming 352 applications in a given CDN). As another example, there may be one 353 instance of Rectification process per Log Consuming Application 354 instead of a shared one. 356 Log Consuming Log Consuming 357 App App 358 ^ ^ 359 | | 360 Rectification---------- 361 ^ 362 | 363 Filtering 364 ^ 365 | 366 Collection 367 ^ ^ 368 | | 369 | Generation 370 | 371 | uCDN 372 CDNI Logging --------------------------------------------------- 373 exchange dCDN 374 ^ 375 | Log Consuming Log Consuming 376 | App App 377 | ^ ^ 378 | | | 379 Rectification Rectification--------- 380 ^ ^ 381 | | 382 Filtering 383 ^ 384 | 385 Collection 386 ^ ^ 387 | | 388 Generation Generation 390 Figure 2: CDNI Logging in the overall Logging Chain 392 The following subsections describe each of the processes potentially 393 involved in the logging chain of Figure 2. 395 2.2.1. Logging Generation and During-Generation Aggregation 397 CDNs typically generate Logging information for all significant task 398 completions, events, and failures. Logging information is typically 399 generated by many devices in the CDN including the surrogates, the 400 request routing system, and the control system. 402 The amount of Logging information generated can be huge. Therefore, 403 during contract negotiations, interconnected CDNs often agree on a 404 retention duration for Logging information, and/or potentially on a 405 maximum volume of Logging information that the dCDN ought to keep. 406 If this volume is exceeded, the dCDN is expected to alert the uCDN 407 but may not keep more Logging information for the considered time 408 period. In addition, CDNs may aggregate Logging information and 409 transmit only summaries for some categories of operations instead of 410 the full Logging information. Note that such aggregation leads to an 411 information loss, which may be problematic for some usages of the 412 Logging information (e.g., debugging). 414 [RFC6983] discusses logging for HTTP Adaptive Streaming (HAS). In 415 accordance with the recommendations articulated there, it is expected 416 that a surrogate will generate separate Logging information for 417 delivery of each chunk of HAS content. This ensures that separate 418 Logging information can then be provided to interconnected CDNs over 419 the CDNI Logging interface. Still in line with the recommendations 420 of [RFC6983], the Logging information for per-chunk delivery may 421 include some information (a Content Collection IDentifier and a 422 Session IDentifier) intended to facilitate subsequent post-generation 423 aggregation of per-chunk logs into per-session logs. Note that a CDN 424 may also elect to generate aggregate per-session logs when performing 425 HAS delivery, but this needs to be in addition to, and not instead 426 of, the per-chunk delivery logs. We note that aggregate per-session 427 logs for HAS delivery are for further study and outside the scope of 428 this document. 430 2.2.2. Logging Collection 432 This is the process that continuously collects Logging information 433 generated by the log-generating entities within a CDN. 435 In a CDNI environment, in addition to collecting Logging information 436 from log-generating entities within the local CDN, the Collection 437 process also collects Logging information provided by another CDN, or 438 other CDNs, through the CDNI Logging interface. This is illustrated 439 in Figure 2 where we see that the Collection process of the uCDN 440 collects Logging information from log-generating entities within the 441 uCDN as well as Logging information coming from the dCDNs through the 442 CDNI Logging interface. 444 2.2.3. Logging Filtering 446 A CDN may be required to only present different subsets of the whole 447 Logging information collected to various log-consuming applications. 448 This is achieved by the Filtering process. 450 In particular, the Filtering process can also filter the right subset 451 of Logging information that needs to be provided to a given 452 interconnected CDN. For example, the filtering process in the dCDN 453 can be used to ensure that only the Logging information related to 454 tasks performed on behalf of a given uCDN are made available to that 455 uCDN (thereby filtering out all the Logging information related to 456 deliveries by the dCDN of content for its own CSPs). Similarly, the 457 Filtering process may filter or partially mask some fields, for 458 example, to protect End Users' privacy when communicating CDNI 459 Logging information to another CDN. Filtering of Logging information 460 prior to communication of this information to other CDNs via the CDNI 461 Logging interface requires that the downstream CDN can recognize the 462 subset of Logging information that relate to each interconnected CDN. 464 The CDN will also filter some internal scope information such as 465 information related to its internal alarms (security, failures, load, 466 etc). 468 In some use cases described in [RFC6770], the interconnected CDNs do 469 not want to disclose details on their internal topology. The 470 filtering process can then also filter confidential data on the 471 dCDNs' topology (number of servers, location, etc.). In particular, 472 information about the requests served by each Surrogate may be 473 confidential. Therefore, the Logging information needs to be 474 protected so that data such as Surrogates' hostnames are not 475 disclosed to the uCDN. In the "Inter-Affiliates Interconnection" use 476 case, this information may be disclosed to the uCDN because both the 477 dCDN and the uCDN are operated by entities of the same group. 479 2.2.4. Logging Rectification and Post-Generation Aggregation 481 If Logging information is generated periodically, it is important 482 that the sessions that start in one Logging period and end in another 483 are correctly reported. If they are reported in the starting period, 484 then the Logging information of this period will be available only 485 after the end of the session, which delays the Logging information 486 generation. A simple approach is to provide the complete Logging 487 Record for a session in the Logging Period of the session end. 489 A Logging rectification/update mechanism could be useful to reach a 490 good trade-off between the Logging information generation delay and 491 the Logging information accuracy. 493 In the presence of HAS, some log-consuming applications can benefit 494 from aggregate per-session logs. For example, for analytics, per- 495 session logs allow display of session-related trends which are much 496 more meaningful for some types of analysis than chunk-related trends. 497 In the case where aggregate logs have been generated directly by the 498 log-generating entities, those can be used by the applications. In 499 the case where aggregate logs have not been generated, the 500 Rectification process can be extended with a Post-Generation 501 Aggregation process that generates per-session logs from the per- 502 chunk logs, possibly leveraging the information included in the per- 503 chunk logs for that purpose (Content Collection IDentifier and a 504 Session IDentifier). However, in accordance with [RFC6983], this 505 document does not define exchange of such aggregate logs on the CDNI 506 Logging interface. We note that this is for further study and 507 outside the scope of this document. 509 2.2.5. Log-Consuming Applications 511 2.2.5.1. Maintenance/Debugging 513 Logging information is useful to permit the detection (and limit the 514 risk) of content delivery failures. In particular, Logging 515 information facilitates the detection of configuration issues. 517 To detect faults, Logging information needs to report success and 518 failure of CDN delivery operations. The uCDN can summarize such 519 information into KPIs. For instance, Logging information needs to 520 allow the computation of the number of times, during a given time 521 period, that content delivery related to a specific service succeeds/ 522 fails. 524 Logging information enables the CDN providers to identify and 525 troubleshoot performance degradations. In particular, Logging 526 information enables tracking of traffic data (e.g., the amount of 527 traffic that has been forwarded by a dCDN on behalf of an uCDN over a 528 given period of time), which is particularly useful for CDN and 529 network planning operations. 531 Some of these maintenance and debugging applications only require 532 aggregate logging information highly compatible with use of 533 anonymization of IP addresses (as supported by the present document 534 and specified in the definition of the c-groupid field under 535 Section 3.4.1). However, in some situations, it may be useful, where 536 compatible with privacy protection, to access some CDNI Logging 537 Records containing full non-anonymized IP addresses. This is allowed 538 in the definition of the c-groupid (under Section 3.4.1), with very 539 significant privacy protection limitations that are discussed in the 540 definition of the c-groupid field. For example, this may be useful 541 for detailed fault tracking of a particular end user content delivery 542 issue. Where there is a hard requirement by uCDN or CSP to associate 543 a given enduser to individual CDNI Logging Records (e.g., to allow 544 a-posteriori analysis of individual delivery for example in 545 situations of performance-based penalties), instead of using 546 aggregates containing a single client as discussed in the c-groupid 547 field definition, an alternate approach is to ensure that a client 548 identifier is embedded in the request fields that can be logged in a 549 CDNI Logging Record (for example by including the client identifier 550 in the URI query string or in a HTTP Header). That latter approach 551 offers two strong benefits: first, the aggregate inside the c-groupid 552 can contain more than one client, thereby ensuring stronger privacy 553 protection; second, it allows a reliable identification of the client 554 while IP address does not in many situations (e.g., behind NAT, where 555 dynamic IP addresses are used and reused,...). However, care SHOULD 556 be taken that the client identifiers exposed in other fields of the 557 CDNI Records cannot themselves be linked back to actual users. 559 2.2.5.2. Accounting 561 Logging information is essential for accounting, to permit inter-CDN 562 billing and CSP billing by uCDNs. For instance, Logging information 563 provided by dCDNs enables the uCDN to compute the total amount of 564 traffic delivered by every dCDN for a particular Content Provider, as 565 well as, the associated bandwidth usage (e.g., peak, 95th 566 percentile), and the maximum number of simultaneous sessions over a 567 given period of time. 569 2.2.5.3. Analytics and Reporting 571 The goals of analytics include gathering any relevant information in 572 order to be able to develop statistics on content download, analyze 573 user behavior, and monitor the performance and quality of content 574 delivery. For instance, Logging information enables the CDN 575 providers to report on content consumption (e.g., delivered sessions 576 per content) in a specific geographic area. 578 The goal of reporting is to gather any relevant information to 579 monitor the performance and quality of content delivery and allow 580 detection of delivery issues. For instance, reporting could track 581 the average delivery throughput experienced by End Users in a given 582 region for a specific CSP or content set over a period of time. 584 2.2.5.4. Content Protection 586 The goal of content protection is to prevent and monitor unauthorized 587 access, misuse, modification, and denial of access to a content. A 588 set of information is logged in a CDN for security purposes. In 589 particular, a record of access to content is usually collected to 590 permit the CSP to detect infringements of content delivery policies 591 and other abnormal End User behaviors. 593 2.2.5.5. Notions common to multiple Log Consuming Applications 595 2.2.5.5.1. Logging Information Views 597 Within a given log-consuming application, different views may be 598 provided to different users depending on privacy, business, and 599 scalability constraints. 601 For example, an analytics tool run by the uCDN can provide one view 602 to an uCDN operator that exploits all the Logging information 603 available to the uCDN, while the tool may provide a different view to 604 each CSP exploiting only the Logging information related to the 605 content of the given CSP. 607 As another example, maintenance and debugging tools may provide 608 different views to different CDN operators, based on their 609 operational role. 611 2.2.5.5.2. Key Performance Indicators (KPIs) 613 This section presents, for explanatory purposes, a non-exhaustive 614 list of Key Performance Indicators (KPIs) that can be extracted/ 615 produced from logs. 617 Multiple log-consuming applications, such as analytics, monitoring, 618 and maintenance applications, often compute and track such KPIs. 620 In a CDNI environment, depending on the situation, these KPIs may be 621 computed by the uCDN or by the dCDN. But it is usually the uCDN that 622 computes KPIs, because the uCDN and dCDN may have different 623 definitions of the KPIs and the computation of some KPIs requires a 624 vision of all the deliveries performed by the uCDN and all its dCDNs. 626 Here is a list of important examples of KPIs: 628 o Number of delivery requests received from End Users in a given 629 region for each piece of content, during a given period of time 630 (e.g., hour/day/week/month) 632 o Percentage of delivery successes/failures among the aforementioned 633 requests 635 o Number of failures listed by failure type (e.g., HTTP error code) 636 for requests received from End Users in a given region and for 637 each piece of content, during a given period of time (e.g., 638 hour/day/week/month) 640 o Number and cause of premature delivery termination for End Users 641 in a given region and for each piece of content, during a given 642 period of time (e.g., hour/day/week/month) 644 o Maximum and mean number of simultaneous sessions established by 645 End Users in a given region, for a given Content Provider, and 646 during a given period of time (e.g., hour/day/week/month) 648 o Volume of traffic delivered for sessions established by End Users 649 in a given region, for a given Content Provider, and during a 650 given period of time (e.g., hour/day/week/month) 652 o Maximum, mean, and minimum delivery throughput for sessions 653 established by End Users in a given region, for a given Content 654 Provider, and during a given period of time (e.g., hour/day/week/ 655 month) 657 o Cache-hit and byte-hit ratios for requests received from End Users 658 in a given region for each piece of content, during a given period 659 of time (e.g., hour/day/week/month) 661 o Top 10 most popularly requested contents (during a given day/week/ 662 month) 664 o Terminal type (mobile, PC, STB, if this information can be 665 acquired from the browser type inferred from the User Agent 666 string, for example). 668 Additional KPIs can be computed from other sources of information 669 than the Logging information, for instance, data collected by a 670 content portal or by specific client-side application programming 671 interfaces. Such KPIs are out of scope for the present document. 673 The KPIs used depend strongly on the considered log-consuming 674 application -- the CDN operator may be interested in different 675 metrics than the CSP is. In particular, CDN operators are often 676 interested in delivery and acquisition performance KPIs, information 677 related to Surrogates' performance, caching information to evaluate 678 the cache-hit ratio, information about the delivered file size to 679 compute the volume of content delivered during peak hour, etc. 681 Some of the KPIs, for instance those providing an instantaneous 682 vision of the active sessions for a given CSP's content, are useful 683 essentially if they are provided in a timely manner. By contrast, 684 some other KPIs, such as those averaged on a long period of time, can 685 be provided in non-real-time. 687 3. CDNI Logging File 689 3.1. Rules 691 This specification uses the Augmented Backus-Naur Form (ABNF) 692 notation and core rules of [RFC5234]. In particular, the present 693 document uses the following rules from [RFC5234]: 695 CR = %x0D ; carriage return 697 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z 699 DIGIT = %x30-39 ; 0-9 701 DQUOTE = %x22 ; " (Double Quote) 703 CRLF = CR LF ; Internet standard newline 705 HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" 707 HTAB = %x09 ; horizontal tab 709 LF = %x0A ; linefeed 711 VCHAR = %x21-7E ; visible (printing) characters 713 OCTET = %x00-FF ; 8 bits of data 715 The present document also uses the following rules from [RFC3986]: 717 host = as specified in section 3.2.2 of [RFC3986]. 719 IPv4address = as specified in section 3.2.2 of [RFC3986]. 721 IPv6address = as specified in section 3.2.2 of [RFC3986]. 723 The present document also defines the following additional rules: 725 ADDRESS = IPv4address / IPv6address 727 ALPHANUM = ALPHA / DIGIT 729 DATE = 4DIGIT "-" 2DIGIT "-" 2DIGIT 731 ; Dates are encoded as "full-date" specified in [RFC3339]. 733 DEC = 1*DIGIT ["." *DIGIT] 735 NAMEFORMAT = ALPHANUM *(ALPHANUM / "_" / "-") 737 QSTRING = DQUOTE *(NDQUOTE / PCT-ENCODED) DQUOTE 739 NDQUOTE = %x20-21 / %x23-24 / %x26-7E / UTF8-2 / UTF8-3 / UTF8-4 741 ; whereby a DQUOTE is conveyed inside a QSTRING unambiguously 742 by escaping it with PCT-ENCODED. 744 PCT-ENCODED = "%" HEXDIG HEXDIG 746 ; percent encoding is used for escaping octets that might be 747 possible in HTTP headers such as bare CR, bare LF, CR LF, HTAB, 748 SP or null. These octets are rendered with percent encoding in 749 ABNF as specified by [RFC3986] in order to avoid considering 750 them as separators for the logging records. 752 NHTABSTRING = 1*(SP / VCHAR) 754 TIME = 2DIGIT ":" 2DIGIT ":" 2DIGIT ["." *DIGIT] 756 ; Times are encoded as "partial-time" specified in [RFC3339]. 758 USER-COMMENT = * (SP / VCHAR / UTF8-2 / UTF8-3 / UTF8-4) 760 3.2. CDNI Logging File Structure 762 As defined in Section 1.1: a CDNI Logging Field is as an atomic 763 logging information element, a CDNI Logging Record is a collection of 764 CDNI Logging fields containing all logging information corresponding 765 to a single logging event, and a CDNI Logging File contains a 766 collection of CDNI Logging Records. This structure is illustrated in 767 Figure 3. The use of a file structure for transfer of CDNI Logging 768 information is selected since this is the most common practise today 769 for exchange of logging information within and across CDNs. 771 +----------------------------------------------------------+ 772 |CDNI Logging File | 773 | | 774 | #Directive 1 | 775 | #Directive 2 | 776 | ... | 777 | #Directive P | 778 | | 779 | +------------------------------------------------------+ | 780 | |CDNI Logging Record 1 | | 781 | | +-------------+ +-------------+ +-------------+ | | 782 | | |CDNI Logging | |CDNI Logging | ... |CDNI Logging | | | 783 | | | Field 1 | | Field 2 | | Field N | | | 784 | | +-------------+ +-------------+ +-------------+ | | 785 | +------------------------------------------------------+ | 786 | | 787 | +------------------------------------------------------+ | 788 | |CDNI Logging Record 2 | | 789 | | +-------------+ +-------------+ +-------------+ | | 790 | | |CDNI Logging | |CDNI Logging | ... |CDNI Logging | | | 791 | | | Field 1 | | Field 2 | | Field N | | | 792 | | +-------------+ +-------------+ +-------------+ | | 793 | +------------------------------------------------------+ | 794 | | 795 | ... | 796 | | 797 | #Directive P+1 | 798 | | 799 | ... | 800 | | 801 | +------------------------------------------------------+ | 802 | |CDNI Logging Record M | | 803 | | +-------------+ +-------------+ +-------------+ | | 804 | | |CDNI Logging | |CDNI Logging | ... |CDNI Logging | | | 805 | | | Field 1 | | Field 2 | | Field N | | | 806 | | +-------------+ +-------------+ +-------------+ | | 807 | +------------------------------------------------------+ | 808 | | 809 | | 810 | #Directive P+Q | 811 +----------------------------------------------------------+ 813 Figure 3: Structure of Logging Files 815 The CDNI Logging File format is inspired from the W3C Extended Log 816 File Format [ELF]. However, it is fully specified by the present 817 document. Where the present document differs from the W3C Extended 818 Log File Format, an implementation of the CDNI Logging interface MUST 819 comply with the present document. The W3C Extended Log File Format 820 was used as a starting point, reused where possible and expanded when 821 necessary. 823 Using a format that resembles the W3C Extended Log File Format is 824 intended to keep CDNI logging format close to the intra-CDN Logging 825 information format commonly used in CDNs today, thereby minimizing 826 systematic translation at CDN/CDNI boundary. 828 A CDNI Logging File MUST contain a sequence of lines containing US- 829 ASCII characters [CHAR_SET] terminated by CRLF. Each line of a CDNI 830 Logging File MUST contain either a directive or a CDNI Logging 831 Record. 833 Directives record information about the CDNI Logging process itself. 834 Lines containing directives MUST begin with the "#" character. 835 Directives are specified in Section 3.3. 837 Logging Records provide actual details of the logged event. Logging 838 Records are specified in Section 3.4. 840 The CDNI Logging File has a specific structure. It always starts 841 with a directive line and the first directive it contains MUST be the 842 version. 844 The directive lines form together a group that contains at least one 845 directive line. Each directives group is followed by a group of 846 logging records. The records group contains zero or more actual 847 logging record lines about the event being logged. A record line 848 consists of the values corresponding to all or a subset of the 849 possible Logging fields defined within the scope of the record-type 850 directive. These values MUST appear in the order defined by the 851 fields directive. 853 Note that future extensions MUST be compliant with the previous 854 description. The following examples depict the structure of a 855 CDNILOGFILE as defined currently by the record-type 856 "cdni_http_request_v1." 858 DIRLINE = "#" directive CRLF 860 DIRGROUP = 1*DIRLINE 862 RECLINE = any subset of record values that match what is expected 863 according to the fields directive within the immediately preceding 864 DIRGROUP. 866 RECGROUP = *RECLINE 868 CDNILOGFILE = 1*(DIRGROUP RECGROUP) 870 All directive names and field names defined in the logging file are 871 case-insensitive as per the basic ABNF([RFC5234]). 873 3.3. CDNI Logging Directives 875 A CDNI Logging directive line contains the directive name followed by 876 ":" HTAB and the directive value. 878 Directive names MUST be of the format NAMEFORMAT. All directive 879 names MUST be registered in the CDNI Logging Directives Names 880 registry. Unknown directives MUST be ignored. Directive values can 881 have various formats. All possible directive values for the record- 882 type "cdni_http_request_v1" are further detailed in this section. 884 The following example shows the structure of a directive and 885 enumerates strictly the directive values presently defined in the 886 record-type "cdni_http_request_v1." 888 directive = DIRNAME ":" HTAB DIRVAL 890 DIRNAME = NAMEFORMAT 892 DIRVAL = NHTABSTRING / QSTRING / host / USER-COMMENT / FIENAME * 893 (HTAB FIENAME) / 64HEXDIG 895 An implementation of the CDNI Logging interface MUST support all of 896 the following directives, listed below by their directive name: 898 o version: 900 * format: NHTABSTRING 902 * directive value: indicates the version of the CDNI Logging File 903 format. The entity transmitting a CDNI Logging File as per the 904 present document MUST set the value to "CDNI/1.0". In the 905 future, other versions of CDNI Logging File might be specified; 906 those would use a value different to "CDNI/1.0" allowing the 907 entity receiving the CDNI Logging File to identify the 908 corresponding version. 910 * occurrence: there MUST be one and only one instance of this 911 directive per CDNI Logging File. It MUST be the first line of 912 the CDNI Logging File. 914 * example: "version: HTAB CDNI/1.0". 916 o UUID: 918 * format: NHTABSTRING 920 * directive value: this a Uniform Resource Name (URN) from the 921 Universally Unique IDentifier (UUID) URN namespace specified in 922 [RFC4122]). The UUID contained in the URN uniquely identifies 923 the CDNI Logging File. 925 * occurrence: there MUST be one and only one instance of this 926 directive per CDNI Logging File. 928 * example: "UUID: HTAB NHTABSTRING". 930 o claimed-origin: 932 * format: host 934 * directive value: this contains the claimed identification of 935 the entity transmitting the CDNI Logging File (e.g., the host 936 in a dCDN supporting the CDNI Logging interface) or the entity 937 responsible for transmitting the CDNI Logging File (e.g., the 938 dCDN). 940 * occurrence: there MUST be zero or exactly one instance of this 941 directive per CDNI Logging File. This directive MAY be 942 included by the dCDN. It MUST NOT be included or modified by 943 the uCDN. 945 * example: "claimed-origin: HTAB host". 947 o established-origin: 949 * format: host 951 * directive value: this contains the identification, as 952 established by the entity receiving the CDNI Logging File, of 953 the entity transmitting the CDNI Logging File (e.g., the host 954 in a dCDN supporting the CDNI Logging interface) or the entity 955 responsible for transmitting the CDNI Logging File (e.g., the 956 dCDN). 958 * occurrence: there MUST be zero or exactly one instance of this 959 directive per CDNI Logging File. This directive MAY be added 960 by the uCDN (e.g., before storing the CDNI Logging File). It 961 MUST NOT be included by the dCDN. The mechanisms used by the 962 uCDN to establish and validate the entity responsible for the 963 CDNI Logging File is outside the scope of the present document. 964 We observe that, in particular, this may be achieved through 965 authentication mechanisms that are part of the transport layer 966 of the CDNI Logging File pull mechanism (Section 4.2). 968 * ABNF example: "established-origin: HTAB host". 970 o remark: 972 * format: USER-COMMENT 974 * directive value: this contains comment information. Data 975 contained in this field is to be ignored by analysis tools. 977 * occurrence: there MAY be zero, one or any number of instance of 978 this directive per CDNI Logging File. 980 * example: "remark: HTAB USER-COMMENT". 982 o record-type: 984 * format: NAMEFORMAT 986 * directive value: indicates the type of the CDNI Logging Records 987 that follow this directive, until another record-type directive 988 (or the end of the CDNI Logging File). This can be any CDNI 989 Logging Record type registered in the CDNI Logging Record-types 990 registry (Section 6.3). For example this may be 991 "cdni_http_request_v1" as specified in Section 3.4.1. 993 * occurrence: there MUST be at least one instance of this 994 directive per CDNI Logging File. The first instance of this 995 directive MUST precede a fields directive and MUST precede all 996 CDNI Logging Records. 998 * example: "record-type: HTAB cdni_http_request_v1". 1000 o fields: 1002 * format: FIENAME *(HTAB FIENAME) ; where FIENAME can take any 1003 CDNI Logging field name registered in the CDNI Logging Field 1004 Names registry (Section 6.4). 1006 * directive value: this lists the names of all the fields for 1007 which a value is to appear in the CDNI Logging Records that 1008 follow the instance of this directive (until another instance 1009 of this directive). The names of the fields, as well as their 1010 occurrences, MUST comply with the corresponding rules specified 1011 in the document referenced in the CDNI Logging Record-types 1012 registry (Section 6.3) for the corresponding CDNI Logging 1013 record-type. 1015 * occurrence: there MUST be at least one instance of this 1016 directive per record-type directive. The first instance of 1017 this directive for a given record-type MUST appear before any 1018 CDNI Logging Record for this record-type. One situation where 1019 more than one instance of the fields directive can appear 1020 within a given CDNI Logging File, is when there is a change, in 1021 the middle of a fairly large logging period, in the agreement 1022 between the uCDN and the dCDN about the set of fields that are 1023 to be exchanged. The multiple occurrences allow records with 1024 the old set of fields and records with the new set of fields to 1025 be carried inside the same Logging File. 1027 * example: "fields: HTAB FIENAME * (HTAB FIENAME)". 1029 o SHA256-hash: 1031 * format: 64HEXDIG 1033 * directive value: This directive permits the detection of a 1034 corrupted CDNI Logging File. This can be useful, for instance, 1035 if a problem occurs on the filesystem of the dCDN Logging 1036 system and leads to a truncation of a logging file. The valid 1037 SHA256-hash value is included in this directive by the entity 1038 that transmits the CDNI Logging File. It MUST be computed by 1039 applying the SHA-256 ([RFC6234]) cryptographic hash function on 1040 the CDNI Logging File, including all the directives and logging 1041 records, up to the SHA256-hash directive itself, excluding the 1042 SHA256-hash directive itself. The SHA256-hash value MUST be 1043 represented as a US-ASCII encoded hexadecimal number, 64 digits 1044 long (representing a 256 bit hash value). The entity receiving 1045 the CDNI Logging File also computes in a similar way the 1046 SHA-256 hash on the received CDNI Logging File and compares 1047 this hash to the value of the SHA256-hash directive. If the 1048 two values are equal, then the received CDNI Logging File is to 1049 be considered non-corrupted. If the two values are different, 1050 the received CDNI Logging File is to be considered corrupted. 1051 The behavior of the entity that received a corrupted CDNI 1052 Logging File is outside the scope of this specification; we 1053 note that the entity MAY attempt to pull again the same CDNI 1054 Logging File from the transmitting entity. If the entity 1055 receiving a non-corrupted CDNI Logging File adds an 1056 established-origin directive, it MUST then recompute and update 1057 the SHA256-hash directive so it also protects the added 1058 established-origin directive. 1060 * occurrence: there MUST be zero or exactly one instance of this 1061 directive. There SHOULD be exactly one instance of this 1062 directive. One situation where that directive could be omitted 1063 is where integrity protection is already provided via another 1064 mechanism (for example if an integrity hash is associated to 1065 the CDNI Logging File out-of-band through the CDNI Logging Feed 1066 ( Section 4.1) leveraging ATOM extensions such as those 1067 proposed in [I-D.snell-atompub-link-extensions]. When present, 1068 the SHA256-hash field MUST be the last line of the CDNI Logging 1069 File. 1071 * example: "SHA256-hash: HTAB 64HEXDIG". 1073 An uCDN-side implementation of the CDNI Logging interface MUST reject 1074 a CDNI Logging File that does not comply with the occurrences 1075 specified above for each and every directive. For example, an uCDN- 1076 side implementation of the CDNI Logging interface receiving a CDNI 1077 Logging file with zero occurrence of the version directive, or with 1078 two occurrences of the SHA256-hash, MUST reject this CDNI Logging 1079 File. 1081 An entity receiving a CDNI Logging File with a value set to 1082 "CDNI/1.0" MUST process the CDNI Logging File as per the present 1083 document. An entity receiving a CDNI Logging File with a value set 1084 to a different value MUST process the CDNI Logging File as per the 1085 specification referenced in the CDNI Logging File version registry 1086 (see Section 6.1) if the implementation supports this specification 1087 and MUST reject the CDNI Logging File otherwise. 1089 3.4. CDNI Logging Records 1091 A CDNI Logging Record consists of a sequence of CDNI Logging fields 1092 relating to that single CDNI Logging Record. 1094 CDNI Logging fields MUST be separated by the "horizontal tabulation 1095 (HTAB)" character. 1097 To facilitate readability, a prefix scheme is used for CDNI Logging 1098 field names in a similar way to the one used in W3C Extended Log File 1099 Format [ELF]. The semantics of the prefix in the present document 1100 is: 1102 o "c-" refers to the User Agent that issues the request (corresponds 1103 to the "client" of W3C Extended Log Format) 1105 o "d-" refers to the dCDN (relative to a given CDN acting as an 1106 uCDN) 1108 o "s-" refers to the dCDN Surrogate that serves the request 1109 (corresponds to the "server" of W3C Extended Log Format) 1111 o "u-" refers to the uCDN (relative to a given CDN acting as a dCDN) 1113 o "cs-" refers to communication from the User Agent towards the dCDN 1114 Surrogate 1116 o "sc-" refers to communication from the dCDN Surrogate towards the 1117 User Agent 1119 An implementation of the CDNI Logging interface as per the present 1120 specification MUST support the CDNI HTTP Request Logging Record as 1121 specified in Section 3.4.1. 1123 A CDNI Logging Record contains the corresponding values for the 1124 fields that are enumerated in the last fields directive before the 1125 current log line. Note that the order in which the field values 1126 appear is dictated by the order of the fields names in the fields 1127 directive. There SHOULD be no dependency between the various fields 1128 values. 1130 3.4.1. HTTP Request Logging Record 1132 This section defines the CDNI Logging Record of record-type 1133 "cdni_http_request_v1". It is applicable to content delivery 1134 performed by the dCDN using HTTP/1.0([RFC1945]), 1135 HTTP/1.1([RFC7230],[RFC7231], [RFC7232], [RFC7233], [RFC7234], 1136 [RFC7235]) or HTTPS ([RFC2818], [RFC7230]). We observe that, in the 1137 case of HTTPS delivery, there may be value in logging additional 1138 information specific to the operation of HTTP over TLS and we note 1139 that this is outside the scope of the present document and may be 1140 addressed in a future document defining another CDNI Logging Record 1141 or another version of the HTTP Request Logging Record. 1143 The "cdni_http_request_v1" record-type is also expected to be 1144 applicable to HTTP/2 [RFC7540] since a fundamental design tenet of 1145 HTTP/2 is to preserve the HTTP/1.1 semantics. We observe that, in 1146 the case of HTTP/2 delivery, there may be value in logging additional 1147 information specific to the additional functionality of HTTP/2 (e.g., 1148 information related to connection identification, to stream 1149 identification, to stream priority and to flow control). We note 1150 that such additional information is outside the scope of the present 1151 document and may be addressed in a future document defining another 1152 CDNI Logging Record or another version of the HTTP Request Logging 1153 Record. 1155 The "cdni_http_request_v1" record-type contains the following CDNI 1156 Logging fields, listed by their field name: 1158 o date: 1160 * format: DATE 1162 * field value: the date at which the processing of request 1163 completed on the Surrogate. 1165 * occurrence: there MUST be one and only one instance of this 1166 field. 1168 o time: 1170 * format: TIME 1172 * field value: the time at which the processing of request 1173 completed on the Surrogate. 1175 * occurrence: there MUST be one and only one instance of this 1176 field. 1178 o time-taken: 1180 * format: DEC 1182 * field value: decimal value of the duration, in seconds, between 1183 the start of the processing of the request and the completion 1184 of the request processing (e.g., completion of delivery) by the 1185 Surrogate. 1187 * occurrence: there MUST be one and only one instance of this 1188 field. 1190 o c-groupid: 1192 * format: NHTABSTRING 1194 * field value: an opaque identifier for an aggregate set of 1195 clients, derived from the client IPv4 or IPv6 address in the 1196 request received by the Surrogate and/or other network-level 1197 identifying information. The c-groupid serves to group clients 1198 into aggregates. Example aggregates include civil geolocation 1199 information (the country, second-level administrative division, 1200 or postal code from which the client is presumed to make the 1201 request based on a geolocation database lookup) or network 1202 topological information (e.g., the BGP AS number announcing the 1203 prefix containing the address). The c-groupid MAY be 1204 structured e.g., US/TN/MEM/38138. Agreement between the dCDN 1205 and the uCDN on a mapping between IPv4 and IPv6 addresses and 1206 aggregates is presumed to occur out-of-band. The aggregation 1207 mapping SHOULD be chosen such that each aggregate contains more 1208 than one client. When the aggregate is chosen so that it 1209 contains a single client (e.g., to allow more detailed 1210 analytics, or to allow a-posteriori analysis of individual 1211 delivery for example in situations of performance-based 1212 penalties): 1214 + the c-groupid MAY be structured (e.g., US/TN/ 1215 MEM/38138/43a5bdd6-95c4-4d62-be65-7410df0021e2) where some 1216 elements identify aggregates and one element identifies the 1217 client. 1219 + the address with a shared secret that is pre-synchronised 1220 and rotated at a predefined time interval. It is 1221 RECOMMENDED that the mapping varies at least once every 24 1222 hours. The mapping from IP address to the element 1223 identifying the client (effectively an encryption of the 1224 address) SHOULD be done using a symmetric key that is known 1225 only to both the uCDN and dCDN. One method of doing this is 1226 to use an analog of how key derivation is via HKDF 1227 ([RFC5869]), as will be used in TLS 1.3 1228 ([I-D.ietf-tls-rfc5246-bis]). When the two CDNs set up the 1229 relationship, they agree out-of-band on a mapping between 1230 IPv4 and IPv6 addresses and aggregates and on the 1231 algorithmic mapping from IPv4/IPv6 addresses and the element 1232 identifying the client; they agree on the salt and input key 1233 material, as described in [RFC5869], Section 2.2, the hash 1234 mechanism to use (SHA-2 or SHA-3 SHOULD be used), and the 1235 key lifetime which SHOULD NOT exceed 25 hours. They also 1236 agree on an initial "info" parameter, which can be something 1237 such as the business names of the two organizations in UTF- 1238 8, concatenated. The encryption algorithm also needs to be 1239 defined, and SHOULD be 128-bit AES-GCM or better. The PRK 1240 should be chosen by both parties contributing alternate 1241 random bytes until sufficient length exists. After this 1242 initial setup, client-information is encrypted using the key 1243 generated by the "expand" step, Section 2.3 of [RFC5869], 1244 and hex-encoded or base64-encoded. At the agreed-upon 1245 lifetime, a new key is used, indicated by prefixing the key 1246 with a special character such as exclamation point. In this 1247 way, shorter lifetimes can be used as needed. 1249 + the element identifying the client SHOULD be algorithmically 1250 generated (from the client IPv4 or IPv6 address in the 1251 request received by the Surrogate and/or other network-level 1252 identifying information) in a way that SHOULD NOT be 1253 linkable back to the global addressing context and that 1254 SHOULD vary over time (to offer protection against long term 1255 attacks); one example way to achieve this is to hash. 1257 + The algorithmic mapping and variation over time MAY allow 1258 the uCDN (with the knowledge of the algorithm and time 1259 variation and associated attributes and keys) to reconstruct 1260 the actual enduser IPv4/IPv6 addresses where that is 1261 required (e.g., to allow a-posteriori analysis of individual 1262 delivery for example in situations of performance-based 1263 penalties). However, these enduser IPv4/IPv6 addresses 1264 SHOULD only be reconstructed on-demand and the CDNI Logging 1265 File SHOULD only be stored with the anonymised c-groupid 1266 value. 1268 + Using the c-groupid field in this way carries with it grave 1269 risks to end-user privacy. Since the c-groupid is in this 1270 case equivalent in identification power to a client IP 1271 address, its use may be restricted by regulation or law as 1272 personally identifiable information. For this reason, such 1273 use is NOT RECOMMENDED. 1275 * occurrence: there MUST be one and only one instance of this 1276 field. 1278 o s-ip: 1280 * format: ADDRESS 1282 * field value: the IPv4 or IPv6 address of the Surrogate that 1283 served the request (i.e., the "server" address). 1285 * occurrence: there MUST be zero or exactly one instance of this 1286 field. 1288 o s-hostname: 1290 * format: host 1292 * field value: the hostname of the Surrogate that served the 1293 request (i.e., the "server" hostname). 1295 * occurrence: there MUST be zero or exactly one instance of this 1296 field. 1298 o s-port: 1300 * format: 1*DIGIT 1302 * field value: the destination TCP port (i.e., the "server" port) 1303 in the request received by the Surrogate. 1305 * occurrence: there MUST be zero or exactly one instance of this 1306 field. 1308 o cs-method: 1310 * format: NHTABSTRING 1312 * field value: this is the method of the request received by the 1313 Surrogate. In the case of HTTP delivery, this is the HTTP 1314 method in the request. 1316 * occurrence: There MUST be one and only one instance of this 1317 field. 1319 o cs-uri: 1321 * format: NHTABSTRING 1323 * field value: this is the "effective request URI" of the request 1324 received by the Surrogate as specified in [RFC7230]. It 1325 complies with the "http" URI scheme or the "https" URI scheme 1326 as specified in [RFC7230]). Note that cs-uri can be privacy 1327 sensitive. In that case, and where appropriate, u-uri could be 1328 used instead of cs-uri. 1330 * occurrence: there MUST be zero or exactly one instance of this 1331 field. 1333 o u-uri: 1335 * format: NHTABSTRING 1337 * field value: this is a complete URI, derived from the 1338 "effective request URI" ([RFC7230]) of the request received by 1339 the Surrogate (i.e., the cs-uri) but transformed by the entity 1340 generating or transmitting the CDNI Logging Record, in a way 1341 that is agreed upon between the two ends of the CDNI Logging 1342 interface, so the transformed URI is meaningful to the uCDN. 1343 For example, the two ends of the CDNI Logging interface could 1344 agree that the u-uri is constructed from the cs-uri by removing 1345 the part of the hostname that exposes which individual 1346 Surrogate actually performed the delivery. The details of 1347 modification performed to generate the u-uri, as well as the 1348 mechanism to agree on these modifications between the two sides 1349 of the CDNI Logging interface are outside the scope of the 1350 present document. 1352 * occurrence: there MUST be one and only one instance of this 1353 field. 1355 o protocol: 1357 * format: NHTABSTRING 1359 * field value: this is value of the HTTP-Version field as 1360 specified in [RFC7230] of the Request-Line of the request 1361 received by the Surrogate (e.g., "HTTP/1.1"). 1363 * occurrence: there MUST be one and only one instance of this 1364 field. 1366 o sc-status: 1368 * format: 3DIGIT 1370 * field value: this is the Status-Code in the response from the 1371 Surrogate. In the case of HTTP delivery, this is the HTTP 1372 Status-Code in the HTTP response. 1374 * occurrence: There MUST be one and only one instance of this 1375 field. 1377 o sc-total-bytes: 1379 * format: 1*DIGIT 1381 * field value: this is the total number of bytes of the response 1382 sent by the Surrogate in response to the request. In the case 1383 of HTTP delivery, this includes the bytes of the Status-Line, 1384 the bytes of the HTTP headers and the bytes of the message- 1385 body. 1387 * occurrence: There MUST be one and only one instance of this 1388 field. 1390 o sc-entity-bytes: 1392 * format: 1*DIGIT 1393 * field value: this is the number of bytes of the message-body in 1394 the HTTP response sent by the Surrogate in response to the 1395 request. This does not include the bytes of the Status-Line or 1396 the bytes of the HTTP headers. 1398 * occurrence: there MUST be zero or exactly one instance of this 1399 field. 1401 o cs(insert_HTTP_header_name_here): 1403 * format: QSTRING 1405 * field value: the value of the HTTP header (identified by the 1406 insert_HTTP_header_name_here in the CDNI Logging field name) as 1407 it appears in the request processed by the Surrogate, but 1408 prepended by a DQUOTE and appended by a DQUOTE. For example, 1409 when the CDNI Logging field name (FIENAME) listed in the 1410 preceding fields directive is cs(User-Agent), this CDNI Logging 1411 field value contains the value of the User-Agent HTTP header as 1412 received by the Surrogate in the request it processed, but 1413 prepended by a DQUOTE and appended by a DQUOTE. If the HTTP 1414 header as it appeared in the request processed by the Surrogate 1415 contains one or more DQUOTE, each DQUOTE MUST be escaped with 1416 percent encoding. For example, if the HTTP header contains 1417 My_Header"value", then the field value of the 1418 cs(insert_HTTP_header_name_here) is "My_Header%x22value%x22". 1419 The entity transmitting the CDNI Logging File MUST ensure that 1420 the respective insert_HTTP_header_name_here of the 1421 cs(insert_HTTP_header_name_here) listed in the fields directive 1422 comply with HTTP specifications. In particular, this field 1423 name does not include any HTAB, since this would prevent proper 1424 parsing of the fields directive by the entity receiving the 1425 CDNI Logging File. 1427 * occurrence: there MAY be zero, one or any number of instance of 1428 this field. 1430 o sc(insert_HTTP_header_name_here): 1432 * format: QSTRING 1434 * field value: the value of the HTTP header (identified by the 1435 insert_HTTP_header_name_here in the CDNI Logging field name) as 1436 it appears in the response issued by the Surrogate to serve the 1437 request, but prepended by a DQUOTE and appended by a DQUOTE. 1438 If the HTTP header as it appeared in the request processed by 1439 the Surrogate contains one or more DQUOTE, each DQUOTE MUST be 1440 escaped with percent encoding. For example, if the HTTP header 1441 contains My_Header"value", then the field value of the 1442 sc(insert_HTTP_header_name_here) is "My_Header%x22value%x22". 1443 The entity transmitting the CDNI Logging File MUST ensure that 1444 the respective insert_HTTP_header_name_here of the 1445 cs(insert_HTTP_header_name_here) listed in the fields directive 1446 comply with HTTP specifications. In particular, this field 1447 name does not include any HTAB, since this would prevent proper 1448 parsing of the fields directive by the entity receiving the 1449 CDNI Logging File. 1451 * occurrence: there MAY be zero, one or any number of instances 1452 of this field. For a given insert_HTTP_header_name_here, there 1453 MUST be zero or exactly one instance of this field. 1455 o s-ccid: 1457 * format: QSTRING 1459 * field value: this contains the value of the Content Collection 1460 IDentifier (CCID) associated by the uCDN to the content served 1461 by the Surrogate via the CDNI Metadata interface 1462 ([I-D.ietf-cdni-metadata]), prepended by a DQUOTE and appended 1463 by a DQUOTE. If the CCID conveyed in the CDNI Metadata 1464 interface contains one or more DQUOTE, each DQUOTE MUST be 1465 escaped with percent encoding. For example, if the CCID 1466 conveyed in the CDNI Metadata interface is My_CCIDD"value", 1467 then the field value of the s-ccid is "My_CCID%x22value%X22". 1469 * occurrence: there MUST be zero or exactly one instance of this 1470 field. For a given insert_HTTP_header_name_here, there MUST be 1471 zero or exactly one instance of this field. 1473 o s-sid: 1475 * format: QSTRING 1477 * field value: this contains the value of a Session IDentifier 1478 (SID) generated by the dCDN for a specific HTTP session, 1479 prepended by a DQUOTE and appended by a DQUOTE. In particular, 1480 for HTTP Adaptive Streaming (HAS) session, the Session 1481 IDentifier value is included in the Logging record for every 1482 content chunk delivery of that session in view of facilitating 1483 the later correlation of all the per content chunk log records 1484 of a given HAS session. See section 3.4.2.2. of [RFC6983] for 1485 more discussion on the concept of Session IDentifier in the 1486 context of HAS. If the SID conveyed contains one or more 1487 DQUOTE, each DQUOTE MUST be escaped with percent encoding. For 1488 example, if the SID is My_SID"value", then the field value of 1489 the s-sid is "My_SID%x22value%x22". 1491 * occurrence: there MUST be zero or exactly one instance of this 1492 field. 1494 o s-cached: 1496 * format: 1DIGIT 1498 * field value: this characterises whether the Surrogate served 1499 the request using content already stored on its local cache or 1500 not. The allowed values are "0" (for miss) and "1" (for hit). 1501 "1" MUST be used when the Surrogate did serve the request using 1502 exclusively content already stored on its local cache. "0" MUST 1503 be used otherwise (including cases where the Surrogate served 1504 the request using some, but not all, content already stored on 1505 its local cache). Note that a "0" only means a cache miss in 1506 the Surrogate and does not provide any information on whether 1507 the content was already stored, or not, in another device of 1508 the dCDN, i.e., whether this was a "dCDN hit" or "dCDN miss". 1510 * occurrence: there MUST be zero or exactly one instance of this 1511 field. 1513 The "fields" directive corresponding to a HTTP Request Logging Record 1514 MUST contain all the fields names whose occurrence is specified above 1515 as "There MUST be one and only one instance of this field". The 1516 corresponding fields value MUST be present in every HTTP Request 1517 Logging Record. 1519 The "fields" directive corresponding to a HTTP Request Logging Record 1520 MAY list all the fields value whose occurrence is specified above as 1521 "there MUST be zero or exactly one instance of this field" or "there 1522 MAY be zero, one or any number of instances of this field". The set 1523 of such field names actually listed in the "fields" directive is 1524 selected by the CDN generating the CDNI Logging File based on 1525 agreements between the interconnected CDNs established through 1526 mechanisms outside the scope of this specification (e.g., contractual 1527 agreements). When such a field name is not listed in the "fields" 1528 directive, the corresponding field value MUST NOT be included in the 1529 Logging Record. When such a field name is listed in the "fields" 1530 directive, the corresponding field value MUST be included in the 1531 Logging Record; if the value for the field is not available, this 1532 MUST be conveyed via a dash character ("-"). 1534 The fields names listed in the "fields" directive MAY be listed in 1535 the order in which they are listed in Section 3.4.1 or MAY be listed 1536 in any other order. 1538 A dCDN-side implementation of the CDNI Logging interface MUST 1539 implement all the following Logging fields in a CDNI Logging Record 1540 of record-type "cdni_http_request_v1", and MUST support the ability 1541 to include valid values for each of them: 1543 o date 1545 o time 1547 o time-taken 1549 o c-groupid 1551 o s-ip 1553 o s-hostname 1555 o s-port 1557 o cs-method 1559 o cs-uri 1561 o u-uri 1563 o protocol 1565 o sc-status 1567 o sc-total-bytes 1569 o sc-entity-bytes 1571 o cs(insert_HTTP_header_name_here) 1573 o sc(insert_HTTP_header_name_here) 1575 o s-cached 1577 A dCDN-side implementation of the CDNI Logging interface MAY support 1578 the following Logging fields in a CDNI Logging Record of record-type 1579 "cdni_http_request_v1": 1581 o s-ccid 1582 o s-sid 1584 If a dCDN-side implementation of the CDNI Logging interface supports 1585 these fields, it MUST support the ability to include valid values for 1586 them. 1588 An uCDN-side implementation of the CDNI Logging interface MUST be 1589 able to accept CDNI Logging Files with CDNI Logging Records of 1590 record-type "cdni_http_request_v1" containing any CDNI Logging Field 1591 defined in Section 3.4.1 as long as the CDNI Logging Record and the 1592 CDNI Logging File are compliant with the present document. 1594 In case an uCDN-side implementation of the CDNI Logging interface 1595 receives a CDNI Logging File with HTTP Request Logging Records that 1596 do not contain field values for exactly the set of field names 1597 actually listed in the preceding "fields" directive, the 1598 implementation MUST reject those HTTP Request Logging Records, and 1599 MUST accept the other HTTP Request Logging Records. 1601 To ensure that the logging file is correct, the text MUST be 1602 sanitized before being logged. Null, bare CR, bare LF and HTAB have 1603 to be removed by escaping them through percent encoding to avoid 1604 confusion with the logging record separators. 1606 3.5. CDNI Logging File Example 1608 Let us consider the upstream CDN and the downstream CDN labelled uCDN 1609 and dCDN-1 in Figure 1. When dCDN-1 acts as a downstream CDN for 1610 uCDN and performs content delivery on behalf of uCDN, dCDN-1 will 1611 include the CDNI Logging Records corresponding to the content 1612 deliveries performed on behalf of uCDN in the CDNI Logging Files for 1613 uCDN. An example CDNI Logging File communicated by dCDN-1 to uCDN is 1614 shown below in Figure 4. 1616 #version:cdni/1.0 1618 #UUID:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 1620 #claimed-origin:cdni-logging-entity.dcdn-1.example.com 1622 #record-type:cdni_http_request_v1 1624 #fields:datetimetime-takenc-groupid 1625 cs-methodu-uriprotocol 1626 sc-statussc-total-bytescs(User-Agent) 1627 cs(Referer)s-cached 1629 2013-05-1700:38:06.8259.058US/TN/MEM/38138 1630 GET 1631 http://cdni-ucdn.dcdn-1.example.com/video/movie100.mp4 1632 HTTP/1.12006729891"Mozilla/5.0 1633 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like 1634 Gecko) Chrome/5.0.375.127 Safari/533.4" 1635 "host1.example.com"1 1637 2013-05-1700:39:09.14515.32FR/PACA/NCE/06100 1638 GET 1639 http://cdni-ucdn.dcdn-1.example.com/video/movie118.mp4 1640 HTTP/1.120015799210"Mozilla/5.0 1641 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like 1642 Gecko) Chrome/5.0.375.127 Safari/533.4" 1643 "host1.example.com"1 1645 2013-05-1700:42:53.43752.879US/TN/MEM/38138 1646 GET 1647 http://cdni-ucdn.dcdn-1.example.com/video/picture11.mp4 1648 HTTP/1.020097234724"Mozilla/5.0 1649 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like 1650 Gecko) Chrome/5.0.375.127 Safari/533.4" 1651 "host5.example.com"0 1653 #SHA256-hash: 64-hexadecimal-digit hash value 1655 Figure 4: CDNI Logging File Example 1657 If uCDN establishes by some means (e.g., via TLS authentication when 1658 pulling the CDNI Logging File) the identity of the entity from which 1659 it pulled the CDNI Logging File, uCDN can add to the CDNI Logging an 1660 established-origin directive as illustrated below: 1662 #established-origin:cdni-logging-entity.dcdn- 1663 1.example.com 1664 As illustrated in Figure 2, uCDN will then ingest the corresponding 1665 CDNI Logging Records into its Collection process, alongside the 1666 Logging Records generated locally by the uCDN itself. This allows 1667 uCDN to aggregate Logging Records for deliveries performed by itself 1668 (through Records generated locally) as well as for deliveries 1669 performed by its downstream CDN(s). This aggregate information can 1670 then be used (after Filtering and Rectification, as illustrated in 1671 Figure 2) by Log Consuming Applications that take into account 1672 deliveries performed by uCDN as well as by all of its downstream 1673 CDNs. 1675 We observe that the time between 1677 1. when a delivery is completed in dCDN and 1679 2. when the corresponding Logging Record is ingested by the 1680 Collection process in uCDN 1682 depends on a number of parameters such as the Logging Period agreed 1683 to by uCDN and dCDN, how much time uCDN waits before pulling the CDNI 1684 Logging File once it is advertised in the CDNI Logging Feed, and the 1685 time to complete the pull of the CDNI Logging File. Therefore, if we 1686 consider the set of Logging Records aggregated by the Collection 1687 process in uCDN in a given time interval, there could be a permanent 1688 significant timing difference between the CDNI Logging Records 1689 received from the dCDN and the Logging Records generated locally. 1690 For example, in a given time interval, the Collection process in uCDN 1691 may be aggregating Logging Records generated locally by uCDN for 1692 deliveries performed in the last hour and CDNI Logging Records 1693 generated in the dCDN for deliveries in the hour before last. 1695 3.6. Cascaded CDNI Logging Files Example 1697 Let us consider the cascaded CDN scenario of uCDN, dCDN-2 and dCDN-3 1698 as depicted in Figure 1. After completion of a delivery by dCDN-3 on 1699 behalf of dCDN-2, dCDN-3 will include a corresponding Logging Record 1700 in a CDNI Logging File that will be pulled by dCDN-2 and that is 1701 illustrated below in Figure 5. In practice, a CDNI Logging File is 1702 likely to contain a very high number of CDNI Logging Records. 1703 However, for readability, the example in Figure 5 contains a single 1704 CDNI Logging Record. 1706 #version:CDNI/1.0 1708 #UUID:urn:uuid:65718ef-0123-9876-adce4321bcde 1710 #claimed-origin:cdni-logging-entity.dcdn-3.example.com 1712 #record-type:cdni_http_request_v1 1714 #fields:datetimetime-takenc-groupid 1715 cs-methodu-uriprotocol 1716 sc-statussc-total-bytescs(User-Agent) 1717 cs(Referer)s-cached 1719 2013-05-1700:39:09.11914.07US/CA/SFO/94114 1720 GET 1721 http://cdni-dcdn-2.dcdn-3.example.com/video/movie118.mp4 1722 HTTP/1.120015799210"Mozilla/5.0 1723 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like 1724 Gecko) Chrome/5.0.375.127 Safari /533.4" 1725 "host1.example.com"1 1727 #SHA256-hash: 64-hexadecimal-digit hash value 1729 Figure 5: Cascaded CDNI Logging File Example (dCDN-3 to dCDN-2) 1731 If dCDN-2 establishes by some means (e.g., via TLS authentication 1732 when pulling the CDNI Logging File) the identity of the entity from 1733 which it pulled the CDNI Logging File, dCDN-2 can add to the CDNI 1734 Logging an established-origin directive as illustrated below: 1736 #established-origin:cdni-logging-entity.dcdn- 1737 3.example.com 1739 dCDN-2 (behaving as an upstream CDN from the viewpoint of dCDN-3) 1740 will then ingest the CDNI Logging Record for the considered dCDN-3 1741 delivery into its Collection process (as illustrated in Figure 2). 1742 This Logging Record may be aggregated with Logging Records generated 1743 locally by dCDN-2 for deliveries performed by dCDN-2 itself. Say, 1744 for illustration, that the content delivery performed by dCDN-3 on 1745 behalf of dCDN-2 had actually been redirected to dCDN-2 by uCDN, and 1746 say that another content delivery has just been redirected by uCDN to 1747 dCDN-2 and that dCDN-2 elected to perform the corresponding delivery 1748 itself. Then after Filtering and Rectification (as illustrated in 1749 Figure 2), dCDN-2 will include the two Logging Records corresponding 1750 respectively to the delivery performed by dCDN-3 and the delivery 1751 performed by dCDN-2, in the next CDNI Logging File that will be 1752 communicated to uCDN. An example of such CDNI Logging File is 1753 illustrated below in Figure 6. 1755 #version:CDNI/1.0 1757 #UUID:urn:uuid:1234567-8fedc-abab-0987654321ff 1759 #claimed-origin:cdni-logging-entity.dcdn-2.example.com 1761 #record-type:cdni_http_request_v1 1763 #fields:datetimetime-takenc-groupid 1764 cs-methodu-uriprotocol 1765 sc-statussc-total-bytescs(User-Agent) 1766 cs(Referer)s-cached 1768 2013-05-1700:39:09.11914.07US/CA/SFO/94114 1769 GET 1770 http://cdni-ucdn.dcdn-2.example.com/video/movie118.mp4 1771 HTTP/1.120015799210"Mozilla/5.0 1772 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like 1773 Gecko) Chrome/5.0.375.127 Safari /533.4" 1774 "host1.example.com"1 1776 2013-05-1701:42:53.43752.879FR/IDF/PAR/75001 1777 GET 1778 http://cdni-ucdn.dcdn-2.example.com/video/picture11.mp4 1779 HTTP/1.020097234724"Mozilla/5.0 1780 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like 1781 Gecko) Chrome/5.0.375.127 Safari /533.4" 1782 "host5.example.com"0 1784 #SHA256-hash: 64-hexadecimal-digit hash value 1786 Figure 6: Cascaded CDNI Logging File Example (dCDN-2 to uCDN) 1788 If uCDN establishes by some means (e.g., via TLS authentication when 1789 pulling the CDNI Logging File) the identity of the entity from which 1790 it pulled the CDNI Logging File, uCDN can add to the CDNI Logging an 1791 established-origin directive as illustrated below: 1793 #established-origin:cdni-logging-entity.dcdn- 1794 2.example.com 1796 In the example of Figure 6, we observe that: 1798 o the first Logging Record corresponds to the Logging Record 1799 communicated earlier to dCDN-2 by dCDN-3, which corresponds to a 1800 delivery redirected by uCDN to dCDN-2 and then redirected by 1801 dCDN-2 to dCDN-3. The fields values in this Logging Record are 1802 copied from the corresponding CDNI Logging REcord communicated to 1803 dCDN2 by dCDN-3, with the exception of the u-uri that now reflects 1804 the URI convention between uCDN and dCDN-2 and that presents the 1805 delivery to uCDN as if it was performed by dCDN-2 itself. This 1806 reflects the fact that dCDN-2 had taken the full responsibility of 1807 the corresponding delivery (even if in this case, dCDN-2 elected 1808 to redirect the delivery to dCDN-3 so it is actually performed by 1809 dCDN-3 on behalf of dCDN-2). 1811 o the second Logging Record corresponds to a delivery redirected by 1812 uCDN to dCDN-2 and performed by dCDN-2 itself. The time of the 1813 delivery in this Logging Record may be significantly more recent 1814 than the first Logging Record since it was generated locally while 1815 the first Logging Record was generated by dCDN-3 and had to be 1816 advertised , and then pulled and then ingested into the dCDN-2 1817 Collection process, before being aggregated with the second 1818 Logging Record. 1820 4. Protocol for Exchange of CDNI Logging File After Full Collection 1822 This section specifies a protocol for the exchange of CDNI Logging 1823 Files as specified in Section 3 after the CDNI Logging File is fully 1824 collected by the dCDN. 1826 This protocol comprises: 1828 o a CDNI Logging feed, allowing the dCDN to notify the uCDN about 1829 the CDNI Logging Files that can be retrieved by that uCDN from the 1830 dCDN, as well as all the information necessary for retrieving each 1831 of these CDNI Logging Files. The CDNI Logging feed is specified 1832 in Section 4.1. 1834 o a CDNI Logging File pull mechanism, allowing the uCDN to obtain 1835 from the dCDN a given CDNI Logging File at the uCDN's convenience. 1836 The CDNI Logging File pull mechanisms is specified in Section 4.2. 1838 An implementation of the CDNI Logging interface on the dCDN side (the 1839 entity generating the CDNI Logging file) MUST support the server side 1840 of the CDNI Logging feed (as specified in Section 4.1) and the server 1841 side of the CDNI Logging pull mechanism (as specified in 1842 Section 4.2). 1844 An implementation of the CDNI Logging interface on the uCDN side (the 1845 entity consuming the CDNI Logging file) MUST support the client side 1846 of the CDNI Logging feed (as specified in Section 4.1) and the client 1847 side of the CDNI Logging pull mechanism (as specified in 1848 Section 4.2). 1850 4.1. CDNI Logging Feed 1852 The server-side implementation of the CDNI Logging feed MUST produce 1853 an Atom feed [RFC4287]. This feed is used to advertise log files 1854 that are available for the client-side to retrieve using the CDNI 1855 Logging pull mechanism. 1857 4.1.1. Atom Formatting 1859 A CDNI Logging feed MUST be structured as an Archived feed, as 1860 defined in [RFC5005], and MUST be formatted in Atom [RFC4287]. This 1861 means it consists of a subscription document that is regularly 1862 updated as new CDNI Logging Files become available, and information 1863 about older CDNI Logging files is moved into archive documents. Once 1864 created, archive documents are never modified. 1866 Each CDNI Logging File listed in an Atom feed MUST be described in an 1867 atom:entry container element. 1869 The atom:entry MUST contain an atom:content element whose "src" 1870 attribute is a link to the CDNI Logging File and whose "type" 1871 attribute is the MIME Media Type indicating that the entry is a CDNI 1872 logging file. This MIME Media Type is defined as "application/cdni" 1873 (See [I-D.ietf-cdni-media-type]) with the Payload Type (ptype) 1874 parameter set to "logging-file". 1876 For compatibility with some Atom feed readers the atom:entry MAY also 1877 contain an atom:link entry whose "href" attribute is a link to the 1878 CDNI Logging File and whose "type" attribute is the MIME Media Type 1879 indicating that the entry is a CDNI Logging File using the 1880 "application/cdni" MIME Media Type with the Payload Type (ptype) 1881 parameter set to "logging-file"(See [I-D.ietf-cdni-media-type]). 1883 The URI used in the atom:id of the atom:entry MUST contain the UUID 1884 of the CDNI Logging File. 1886 The atom:updated in the atom:entry MUST indicate the time at which 1887 the CDNI Logging File was last updated. 1889 4.1.2. Updates to Log Files and the Feed 1891 CDNI Logging Files MUST NOT be modified by the dCDN once published in 1892 the CDNI Logging feed. 1894 The frequency with which the subscription feed is updated, the period 1895 of time covered by each CDNI Logging File or each archive document, 1896 and timeliness of publishing of CDNI Logging Files are outside the 1897 scope of the present document and are expected to be agreed upon by 1898 uCDN and dCDN via other means (e.g., human agreement). 1900 The server-side implementation MUST be able to set, and SHOULD set, 1901 HTTP cache control headers on the subscription feed to indicate the 1902 frequency at which the client-side is to poll for updates. 1904 The client-side MAY use HTTP cache control headers (set by the 1905 server-side) on the subscription feed to determine the frequency at 1906 which to poll for updates. The client-side MAY instead, or in 1907 addition, use other information to determine when to poll for updates 1908 (e.g., a polling frequency that may have been negotiated between the 1909 uCDN and dCDN by mechanisms outside the scope of the present document 1910 and that is to override the indications provided in the HTTP cache 1911 control headers). 1913 The potential retention limits (e.g., sliding time window) within 1914 which the dCDN is to retain and be ready to serve an archive document 1915 is outside the scope of the present document and is expected to be 1916 agreed upon by uCDN and dCDN via other means (e.g., human agreement). 1917 The server-side implementation MUST retain, and be ready to serve, 1918 any archive document within the agreed retention limits. Outside 1919 these agreed limits, the server-side implementation MAY indicate its 1920 inability to serve (e.g., with HTTP status code 404) an archive 1921 document or MAY refuse to serve it (e.g., with HTTP status code 403 1922 or 410). 1924 4.1.3. Redundant Feeds 1926 The server-side implementation MAY present more than one CDNI Logging 1927 feed for redundancy. Each CDNI Logging File MAY be published in more 1928 than one feed. 1930 A client-side implementation MAY support such redundant CDNI Logging 1931 feeds. If it supports redundant CDNI Logging feed, the client-side 1932 can use the UUID of the CDNI Logging File, presented in the atom:id 1933 element of the Atom feed, to avoid unnecessarily pulling and storing 1934 a given CDNI Logging File more than once. 1936 4.1.4. Example CDNI Logging Feed 1938 Figure 7 illustrates an example of the subscription document of a 1939 CDNI Logging feed. 1941 1942 1943 CDNI Logging Feed 1944 2013-03-23T14:46:11Z 1945 urn:uuid:663ae677-40fb-e99a-049d-c5642916b8ce 1946 1948 1950 1952 CDNI Log Feed 1953 Generator 1954 dcdn.example 1955 1956 CDNI Logging File for uCDN at 1957 2013-03-23 14:15:00 1958 urn:uuid:12345678-1234-abcd-00aa-01234567abcd 1959 2013-03-23T14:15:00Z 1960 1964 CDNI Logging File for uCDN at 1965 2013-03-23 14:15:00 1966 1967 1968 CDNI Logging File for uCDN at 1969 2013-03-23 14:30:00 1970 urn:uuid:87654321-4321-dcba-aa00-dcba7654321 1971 2013-03-23T14:30:00Z 1972 1976 CDNI Logging File for uCDN at 1977 2013-03-23 14:30:00 1978 1979 ... 1980 1981 ... 1982 1983 1985 Figure 7: Example subscription document of a CDNI Logging Feed 1987 4.2. CDNI Logging File Pull 1989 A client-side implementation of the CDNI Logging interface MAY pull, 1990 at its convenience, a CDNI Logging File that is published by the 1991 server-side in the CDNI Logging Feed (in the subscription document or 1992 an archive document). To do so, the client-side: 1994 o MUST implement HTTP/1.1 ([RFC7230],[RFC7231], [RFC7232], 1995 [RFC7233], [RFC7234], [RFC7235]), MAY also support other HTTP 1996 versions (e.g., HTTP/2 [RFC7540]) and MAY negotiate which HTTP 1997 version is actually used. This allows operators and implementers 1998 to choose to use later versions of HTTP to take advantage of new 1999 features, while still ensuring interoperability with systems that 2000 only support HTTP/1.1. 2002 o MUST use the URI that was associated to the CDNI Logging File 2003 (within the "src" attribute of the corresponding atom:content 2004 element) in the CDNI Logging Feed; 2006 o MUST support exchange of CDNI Logging Files with no content 2007 encoding applied to the representation; 2009 o MUST support exchange of CDNI Logging Files with "gzip" content 2010 encoding (as defined in [RFC7230]) applied to the representation. 2012 Note that a client-side implementation of the CDNI Logging interface 2013 MAY pull a CDNI Logging File that it has already pulled. 2015 The server-side implementation MUST respond to valid pull request by 2016 a client-side implementation for a CDNI Logging File published by the 2017 server-side in the CDNI Logging Feed (in the subscription document or 2018 an archive document). The server-side implementation: 2020 o MUST implement HTTP/1.1 to handle the client-side request and MAY 2021 also support other HTTP versions (e.g., HTTP/2); 2023 o MUST include the CDNI Logging File identified by the request URI 2024 inside the body of the HTTP response; 2026 o MUST support exchange of CDNI Logging Files with no content 2027 encoding applied to the representation; 2029 o MUST support exchange of CDNI Logging Files with "gzip" content 2030 encoding (as defined in [RFC7231]) applied to the representation. 2032 Content negotiation approaches defined in [RFC7231] (e.g., using 2033 Accept-Encoding request-header field or Content-Encoding entity- 2034 header field) MAY be used by the client-side and server-side 2035 implementations to establish the content-coding to be used for a 2036 particular exchange of a CDNI Logging File. 2038 Applying compression content encoding (such as "gzip") is expected to 2039 mitigate the impact of exchanging the large volumes of logging 2040 information expected across CDNs. This is expected to be 2041 particularly useful in the presence of HTTP Adaptive Streaming (HAS) 2042 which, as per the present version of the document, will result in a 2043 separate CDNI Log Record for each HAS segment delivery in the CDNI 2044 Logging File. 2046 The potential retention limits (e.g., sliding time window, maximum 2047 aggregate file storage quotas) within which the dCDN is to retain and 2048 be ready to serve a CDNI Logging File previously advertised in the 2049 CDNI Logging Feed is outside the scope of the present document and is 2050 expected to be agreed upon by uCDN and dCDN via other means (e.g., 2051 human agreement). The server-side implementation MUST retain, and be 2052 ready to serve, any CDNI Logging File within the agreed retention 2053 limits. Outside these agreed limits, the server-side implementation 2054 MAY indicate its inability to serve (e.g., with HTTP status code 404) 2055 a CDNI Logging File or MAY refuse to serve it (e.g., with HTTP status 2056 code 403 or 410). 2058 5. Protocol for Exchange of CDNI Logging File During Collection 2060 We note that, in addition to the CDNI Logging File exchange protocol 2061 specified in Section 4, implementations of the CDNI Logging interface 2062 may also support other mechanisms to exchange CDNI Logging Files. In 2063 particular, such mechanisms might allow the exchange of the CDNI 2064 Logging File to start before the file is fully collected. This can 2065 allow CDNI Logging Records to be communicated by the dCDN to the uCDN 2066 as they are gathered by the dCDN without having to wait until all the 2067 CDNI Logging Records of the same logging period are collected in the 2068 corresponding CDNI Logging File. This approach is commonly referred 2069 to as "tailing" of the file. 2071 Such an approach could be used, for example, to exchange logging 2072 information with a significantly reduced time-lag (e.g., sub-minute 2073 or sub-second) between when the event occurred in the dCDN and when 2074 the corresponding CDNI Logging Record is made available to the uCDN. 2075 This can satisfy log-consuming applications requiring extremely fresh 2076 logging information such as near-real-time content delivery 2077 monitoring. Such mechanisms are for further study and outside the 2078 scope of this document. 2080 6. IANA Considerations 2082 When IANA allocates new extensions to CDNI Logging Directive Names 2083 Registry, CDNI Logging File version Registry, CDNI Logging record- 2084 type Registry or CDNI Logging fields Registry, IANA MUST take into 2085 account that the directive names are case-insensitive as per the 2086 basic ABNF([RFC5234]). 2088 6.1. CDNI Logging Directive Names Registry 2090 The IANA is requested to create a new "CDNI Logging Directive Names" 2091 registry under the "Content Delivery Networks Interconnection (CDNI) 2092 Parameters" category. 2094 The initial contents of the CDNI Logging Directives registry comprise 2095 the names of the directives specified in Section 3.3 of the present 2096 document, and are as follows: 2098 +------------------------------+-----------+ 2099 | Directive Name | Reference | 2100 +------------------------------+-----------+ 2101 | version | RFC xxxx | 2102 | UUID | RFC xxxx | 2103 | claimed-origin | RFC xxxx | 2104 | established-origin | RFC xxxx | 2105 | remark | RFC xxxx | 2106 | record-type | RFC xxxx | 2107 | fields | RFC xxxx | 2108 | SHA256-hash | RFC xxxx | 2109 +------------------------------+-----------+ 2111 Figure 8 2113 [Instructions to IANA: Replace "RFC xxxx" above by the RFC number of 2114 the present document] 2116 Within the registry, names are to be allocated by IANA according to 2117 the "Specification Required" policy specified in [RFC5226]. 2118 Directive names are to be allocated by IANA with a format of 2119 NAMEFORMAT (see Section 3.1). All directive names and field names 2120 defined in the logging file are case-insensitive as per the basic 2121 ABNF([RFC5234]). 2123 Each specification that defines a new CDNI Logging directive needs to 2124 contain a description for the new directive with the same set of 2125 information as provided in Section 3.3 (i.e., format, directive value 2126 and occurrence). 2128 6.2. CDNI Logging File version Registry 2130 The IANA is requested to create a new "CDNI Logging File version" 2131 registry under the "Content Delivery Networks Interconnection (CDNI) 2132 Parameters" category. 2134 The initial contents of the CDNI Logging Logging File version 2135 registry comprise the value "CDNI/1.0" specified in Section 3.3 of 2136 the present document, and are as follows: 2138 +-----------------+-----------+----------------------------------+ 2139 | version | Reference | Description | 2140 +-----------------+-----------+----------------------------------+ 2141 | cdni/1.0 | RFC xxxx | CDNI Logging File version 1.0 | 2142 | | | as specified in RFC xxxx | 2143 +-----------------+-----------+----------------------------------+ 2145 Figure 9 2147 [Instructions to IANA: Replace "RFC xxxx" above by the RFC number of 2148 the present document] 2150 Within the registry, version values are to be allocated by IANA 2151 according to the "Specification Required" policy specified in 2152 [RFC5226]. Version values are to be allocated by IANA with a format 2153 of NAMEFORMAT (see Section 3.1). 2155 6.3. CDNI Logging record-types Registry 2157 The IANA is requested to create a new "CDNI Logging record-types" 2158 under the "Content Delivery Networks Interconnection (CDNI) 2159 Parameters" category. 2161 The initial contents of the CDNI Logging record-types registry 2162 comprise the names of the CDNI Logging Record types specified in 2163 Section 3.4 of the present document, and are as follows: 2165 +----------------------+-----------+----------------------------------+ 2166 | record-types | Reference | Description | 2167 +----------------------+-----------+----------------------------------+ 2168 | cdni_http_request_v1 | RFC xxxx | CDNI Logging Record version 1 | 2169 | | | for content delivery using HTTP | 2170 +----------------------+-----------+----------------------------------+ 2172 Figure 10 2174 [Instructions to IANA: Replace "RFC xxxx" above by the RFC number of 2175 the present document] 2176 Within the registry, record-types are to be allocated by IANA 2177 according to the "Specification Required" policy specified in 2178 [RFC5226]. record-types are to be allocated by IANA with a format of 2179 NAMEFORMAT (see Section 3.1). 2181 Each specification that defines a new record-type needs to contain a 2182 description for the new record-type with the same set of information 2183 as provided in Section 3.4.1. This includes: 2185 o a list of all the CDNI Logging fields that can appear in a CDNI 2186 Logging Record of the new record-type 2188 o for all these fields: a specification of the occurrence for each 2189 Field in the new record-type 2191 o for every newly defined Field, i.e., for every Field that results 2192 in a registration in the CDNI Logging Field Names Registry 2193 (Section 6.4): a specification of the field name, format and field 2194 value. 2196 6.4. CDNI Logging Field Names Registry 2198 The IANA is requested to create a new "CDNI Logging Field Names" 2199 under the "Content Delivery Networks Interconnection (CDNI) 2200 Parameters" category. 2202 This registry is intended to be shared across the currently defined 2203 record-type (i.e., cdni_http_request_v1) as well as potential other 2204 CDNI Logging record-types that may be defined in separate 2205 specifications. When a Field from this registry is used by another 2206 CDNI Logging record-type, it is to be used with the exact semantics 2207 and format specified in the document that registered this field and 2208 that is identified in the Reference column of the registry. If 2209 another CDNI Logging record-type requires a Field with semantics that 2210 are not strictly identical, or a format that is not strictly 2211 identical then this new Field is to be registered in the registry 2212 with a different Field name. When a Field from this registry is used 2213 by another CDNI Logging record-type, it can be used with different 2214 occurrence rules. 2216 The initial contents of the CDNI Logging fields Names registry 2217 comprise the names of the CDNI Logging fields specified in 2218 Section 3.4 of the present document, and are as follows: 2220 +------------------------------------------+-----------+ 2221 | Field Name | Reference | 2222 +------------------------------------------+-----------+ 2223 | date | RFC xxxx | 2224 | time | RFC xxxx | 2225 | time-taken | RFC xxxx | 2226 | c-groupid | RFC xxxx | 2227 | s-ip | RFC xxxx | 2228 | s-hostname | RFC xxxx | 2229 | s-port | RFC xxxx | 2230 | cs-method | RFC xxxx | 2231 | cs-uri | RFC xxxx | 2232 | u-uri | RFC xxxx | 2233 | protocol | RFC xxxx | 2234 | sc-status | RFC xxxx | 2235 | sc-total-bytes | RFC xxxx | 2236 | sc-entity-bytes | RFC xxxx | 2237 | cs(insert_HTTP_header_name_here) | RFC xxxx | 2238 | sc(insert_HTTP_header_name_here) | RFC xxxx | 2239 | s-ccid | RFC xxxx | 2240 | s-sid | RFC xxxx | 2241 | s-cached | RFC xxxx | 2242 +------------------------------------------+-----------+ 2244 Figure 11 2246 [Instructions to IANA: Replace "RFC xxxx" above by the RFC number of 2247 the present document] 2249 Within the registry, names are to be allocated by IANA according to 2250 the "Specification Required" policy specified in [RFC5226]. Field 2251 names are to be allocated by IANA with a format of NHTABSTRING (see 2252 Section 3.1). 2254 6.5. CDNI Logging MIME Media Type 2256 The IANA is requested to register the following new Payload Type in 2257 the CDNI Payload Type registry for use with the application/cdni MIME 2258 media type. 2260 [RFC Editor Note: Please replace the references to [RFCthis] below 2261 with this document's RFC number before publication.] 2262 +----------------------+---------------+ 2263 | Payload Type | Specification | 2264 +----------------------+---------------+ 2265 | logging-file | [RFCthis] | 2266 +----------------------+---------------+ 2268 Figure 12: MIME Media Type payload 2270 The purpose of the logging-file payload type is to distinguish 2271 between CDNI Logging Files and other CDNI messages. 2273 Interface: LI 2275 Encoding: see Section 3.2, Section 3.3 and Section 3.4 2277 7. Security Considerations 2279 7.1. Authentication, Authorization, Confidentiality, Integrity 2280 Protection 2282 An implementation of the CDNI Logging interface MUST support TLS 2283 transport of the CDNI Logging feed (Section 4.1) and of the CDNI 2284 Logging File pull (Section 4.2) as per [RFC2818] and [RFC7230]. 2286 The use of TLS for transport of the CDNI Logging feed and CDNI 2287 Logging File pull allows: 2289 o the dCDN and uCDN to authenticate each other 2291 and, once they have mutually authenticated each other, it allows: 2293 o the dCDN and uCDN to authorize each other (to ensure they are 2294 transmitting/receiving CDNI Logging File to/from an authorized 2295 CDN) 2297 o the CDNI Logging information to be transmitted with 2298 confidentiality 2300 o the integrity of the CDNI Logging information to be protected 2301 during the exchange. 2303 In an environment where any such protection is required, mutually 2304 authenticated encrypted transport MUST be used to ensure 2305 confidentiality of the logging information. To that end, TLS MUST be 2306 used (including authentication of the remote end) by the server-side 2307 and the client-side of the CDNI Logging feed, as well as the server- 2308 side and the client-side of the CDNI Logging File pull mechanism. 2310 When TLS is used, the general TLS usage guidance in [RFC7525] MUST be 2311 followed. 2313 The SHA256-hash directive inside the CDNI Logging File provides 2314 additional integrity protection, this time targeting potential 2315 corruption of the CDNI logging information during the CDNI Logging 2316 File generation, storage or exchange. This mechanism does not itself 2317 allow restoration of the corrupted CDNI Logging information, but it 2318 allows detection of such corruption and therefore triggering of 2319 appropriate corrective actions (e.g., discard of corrupted 2320 information, attempt to re-obtain the CDNI Logging information). 2321 Note that the SHA256-hash does not protect against tampering by a 2322 third party, since such a third party could have recomputed and 2323 updated the SHA256-hash after tampering. Protection against third 2324 party tampering can be achieved as discussed above through the use of 2325 TLS. 2327 7.2. Denial of Service 2329 This document does not define specific mechanism to protect against 2330 Denial of Service (DoS) attacks on the Logging Interface. However, 2331 the CDNI Logging feed and CDNI Logging pull endpoints are typically 2332 to be accessed only by a very small number of valid remote endpoints 2333 and therefore can be easily protected against DoS attacks through the 2334 usual conventional DOS protection mechanisms such as firewalling or 2335 use of Virtual Private Networks (VPNs). 2337 Protection of dCDN Surrogates against spoofed delivery requests is 2338 outside the scope of the CDNI Logging interface. 2340 7.3. Privacy 2342 CDNs have the opportunity to collect detailed information about the 2343 downloads performed by End Users. A dCDN is expected to collect such 2344 information into CDNI Logging Files, which are then communicatd to an 2345 uCDN. 2347 Having detailed CDNI logging information known by the dCDN in itself 2348 does not represent a particular privacy concern since the dCDN is 2349 obviously fully aware of all information logged since it generated 2350 the information in the first place. Making detailed CDNI logging 2351 information known to the uCDN does not represent a particular privacy 2352 concern because the uCDN is already exposed at request redirection 2353 time to most of the information that shows up as CDNI logging 2354 information (e.g., enduser IP@, URL, HTTP headers - at least when 2355 HTTP redirection is used between uCDN and dCDN). Transporting 2356 detailed CDNI logging information over the HTTP based CDNI Logging 2357 Interface does not represent a particular privacy concern because it 2358 is protected by usual IETF privacy-protection mechanism (e.g.,TLS). 2360 However, one privacy concern arises from the fact that large volumes 2361 of detailed information about content delivery to users, potentially 2362 traceable back to indvidual users, may be collected in CDNI Logging 2363 files. These CDNI Logging files represent high-value targets, likely 2364 concentrated in a fairly centralised system (although the CDNI 2365 Logging architecture does not manadate a particular level of 2366 centralisation/distribution) and at risk of potential data 2367 exfiltration. Note that the means of such data exfiltration are 2368 beyond the scope of the CDNI Logging interface itself (e.g., 2369 corrupted employee, corrupted logging storage system,...). This 2370 privacy concern calls for some protection. 2372 The collection of large volumes of such information into CDNI Logging 2373 Files introduces potential End Users privacy protection concerns. 2374 Mechanisms to address these concerns are discussed in the definition 2375 of the c-groupid field specified in Section 3.4.1. 2377 The use of mutually authenticated TLS to establish a secure session 2378 for the transport of the CDNI Logging feed and CDNI Logging pull as 2379 discussed in Section 7.1 provides confidentiality while the logging 2380 information is in transit and prevents any party other than the 2381 authorised uCDN to gain access to the logging information. 2383 We also note that the query string portion of the URL that may be 2384 conveyed inside the cs-uri and u-uri fields of CDNI Logging Files, or 2385 the HTTP cookies( [RFC6265]) that may be conveyed as part of the 2386 cs() field of CDNI Logging files, may contain 2387 personnal information or information that can be exploited to derive 2388 personal information. Where this is a concern, the CDNI Logging 2389 interface specification allows the dCDN to not include the cs-uri and 2390 to include a u-uri that removes (or hides) the sensitive part of the 2391 query string and allows the dCDN to not include the cs() fields corresponding to HTTP headers associated with cookies. 2394 8. Acknowledgments 2396 This document borrows from the W3C Extended Log Format [ELF]. 2398 Rob Murray significantly contributed into the text of Section 4.1. 2400 The authors thank Ben Niven-Jenkins, Kevin Ma, David Mandelberg and 2401 Ray van Brandenburg for their ongoing input. 2403 Brian Trammel and Rich Salz made significant contributions into 2404 making this interface privacy-friendly. 2406 Finally, we also thank Sebastien Cubaud, Pawel Grochocki, Christian 2407 Jacquenet, Yannick Le Louedec, Anne Marrec, Emile Stephan, Fabio 2408 Costa, Sara Oueslati, Yvan Massot, Renaud Edel, Joel Favier and the 2409 contributors of the EU FP7 OCEAN project for their input in the early 2410 versions of this document. 2412 9. References 2414 9.1. Normative References 2416 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2417 Requirement Levels", BCP 14, RFC 2119, 2418 DOI 10.17487/RFC2119, March 1997, 2419 . 2421 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 2422 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 2423 . 2425 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2426 Resource Identifier (URI): Generic Syntax", STD 66, 2427 RFC 3986, DOI 10.17487/RFC3986, January 2005, 2428 . 2430 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 2431 Unique IDentifier (UUID) URN Namespace", RFC 4122, 2432 DOI 10.17487/RFC4122, July 2005, 2433 . 2435 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom 2436 Syndication Format", RFC 4287, DOI 10.17487/RFC4287, 2437 December 2005, . 2439 [RFC5005] Nottingham, M., "Feed Paging and Archiving", RFC 5005, 2440 DOI 10.17487/RFC5005, September 2007, 2441 . 2443 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2444 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2445 DOI 10.17487/RFC5226, May 2008, 2446 . 2448 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2449 Specifications: ABNF", STD 68, RFC 5234, 2450 DOI 10.17487/RFC5234, January 2008, 2451 . 2453 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2454 Protocol (HTTP/1.1): Message Syntax and Routing", 2455 RFC 7230, DOI 10.17487/RFC7230, June 2014, 2456 . 2458 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2459 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 2460 DOI 10.17487/RFC7231, June 2014, 2461 . 2463 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2464 Protocol (HTTP/1.1): Conditional Requests", RFC 7232, 2465 DOI 10.17487/RFC7232, June 2014, 2466 . 2468 [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., 2469 "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", 2470 RFC 7233, DOI 10.17487/RFC7233, June 2014, 2471 . 2473 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 2474 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 2475 RFC 7234, DOI 10.17487/RFC7234, June 2014, 2476 . 2478 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2479 Protocol (HTTP/1.1): Authentication", RFC 7235, 2480 DOI 10.17487/RFC7235, June 2014, 2481 . 2483 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 2484 "Recommendations for Secure Use of Transport Layer 2485 Security (TLS) and Datagram Transport Layer Security 2486 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2487 2015, . 2489 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 2490 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 2491 DOI 10.17487/RFC7540, May 2015, 2492 . 2494 9.2. Informative References 2496 [CHAR_SET] 2497 "IANA Character Sets registry", 2498 . 2501 [ELF] Phillip M. Hallam-Baker, and Brian Behlendorf, "Extended 2502 Log File Format, W3C (work in progress), WD-logfile- 2503 960323", . 2505 [I-D.ietf-cdni-media-type] 2506 Ma, K., "CDNI Media Type Registration", draft-ietf-cdni- 2507 media-type-06 (work in progress), October 2015. 2509 [I-D.ietf-cdni-metadata] 2510 Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 2511 "CDN Interconnection Metadata", draft-ietf-cdni- 2512 metadata-12 (work in progress), October 2015. 2514 [I-D.ietf-tls-rfc5246-bis] 2515 Dierks, T. and E. Rescorla, "The Transport Layer Security 2516 (TLS) Protocol Version 1.3", draft-ietf-tls-rfc5246-bis-00 2517 (work in progress), April 2014. 2519 [I-D.snell-atompub-link-extensions] 2520 Snell, J., "Atom Link Extensions", draft-snell-atompub- 2521 link-extensions-09 (work in progress), June 2012. 2523 [RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext 2524 Transfer Protocol -- HTTP/1.0", RFC 1945, 2525 DOI 10.17487/RFC1945, May 1996, 2526 . 2528 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 2529 DOI 10.17487/RFC2818, May 2000, 2530 . 2532 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 2533 Key Derivation Function (HKDF)", RFC 5869, 2534 DOI 10.17487/RFC5869, May 2010, 2535 . 2537 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 2538 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 2539 DOI 10.17487/RFC6234, May 2011, 2540 . 2542 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 2543 DOI 10.17487/RFC6265, April 2011, 2544 . 2546 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 2547 Distribution Network Interconnection (CDNI) Problem 2548 Statement", RFC 6707, DOI 10.17487/RFC6707, September 2549 2012, . 2551 [RFC6770] Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley, 2552 P., Ma, K., and G. Watson, "Use Cases for Content Delivery 2553 Network Interconnection", RFC 6770, DOI 10.17487/RFC6770, 2554 November 2012, . 2556 [RFC6983] van Brandenburg, R., van Deventer, O., Le Faucheur, F., 2557 and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware 2558 Content Distribution Network Interconnection (CDNI)", 2559 RFC 6983, DOI 10.17487/RFC6983, July 2013, 2560 . 2562 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 2563 "Framework for Content Distribution Network 2564 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 2565 August 2014, . 2567 [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution 2568 Network Interconnection (CDNI) Requirements", RFC 7337, 2569 DOI 10.17487/RFC7337, August 2014, 2570 . 2572 Authors' Addresses 2574 Francois Le Faucheur (editor) 2575 Cisco Systems 2576 E.Space Park - Batiment D 2577 6254 Allee des Ormes - BP 1200 2578 Mougins cedex 06254 2579 FR 2581 Phone: +33 4 97 23 26 19 2582 Email: flefauch@cisco.com 2584 Gilles Bertrand (editor) 2585 Orange 2586 38-40 rue du General Leclerc 2587 Issy les Moulineaux 92130 2588 FR 2590 Phone: +33 1 45 29 89 46 2591 Email: gilles.bertrand@orange.com 2592 Iuniana Oprescu (editor) 2593 Orange 2594 38-40 rue du General Leclerc 2595 Issy les Moulineaux 92130 2596 FR 2598 Phone: +33 6 89 06 92 72 2599 Email: iuniana.oprescu@orange.com 2601 Roy Peterkofsky 2602 Skytide, Inc. 2603 One Kaiser Plaza, Suite 785 2604 Oakland CA 94612 2605 USA 2607 Phone: +01 510 250 4284 2608 Email: roy@skytide.com