idnits 2.17.1 draft-ietf-cdni-logging-22.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 (March 2, 2016) is 2967 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 2283, 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: September 3, 2016 I. Oprescu, Ed. 6 Orange 7 R. Peterkofsky 8 Skytide, Inc. 9 March 2, 2016 11 CDNI Logging Interface 12 draft-ietf-cdni-logging-22 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 September 3, 2016. 40 Copyright Notice 42 Copyright (c) 2016 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 partial-time = as specified in [RFC3339]. 725 The present document also defines the following additional rules: 727 ADDRESS = IPv4address / IPv6address 729 ALPHANUM = ALPHA / DIGIT 731 DATE = 4DIGIT "-" 2DIGIT "-" 2DIGIT 733 ; Dates are encoded as "full-date" specified in [RFC3339]. 735 DEC = 1*DIGIT ["." 1*DIGIT] 737 NAMEFORMAT = ALPHANUM *(ALPHANUM / "_" / "-") 739 QSTRING = DQUOTE *(NDQUOTE / PCT-ENCODED) DQUOTE 741 NDQUOTE = %x20-21 / %x23-24 / %x26-7E / UTF8-2 / UTF8-3 / UTF8-4 743 ; whereby a DQUOTE is conveyed inside a QSTRING unambiguously 744 by escaping it with PCT-ENCODED. 746 PCT-ENCODED = "%" HEXDIG HEXDIG 748 ; percent encoding is used for escaping octets that might be 749 possible in HTTP headers such as bare CR, bare LF, CR LF, HTAB, 750 SP or null. These octets are rendered with percent encoding in 751 ABNF as specified by [RFC3986] in order to avoid considering 752 them as separators for the logging records. 754 NHTABSTRING = 1*(SP / VCHAR) 756 TIME = partial-time 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 = 865 RECGROUP = *RECLINE 867 CDNILOGFILE = 1*(DIRGROUP RECGROUP) 869 All directive names and field names defined in the logging file are 870 case-insensitive as per the basic ABNF([RFC5234]). 872 3.3. CDNI Logging Directives 874 A CDNI Logging directive line contains the directive name followed by 875 ":" HTAB and the directive value. 877 Directive names MUST be of the format NAMEFORMAT. All directive 878 names MUST be registered in the CDNI Logging Directives Names 879 registry. Unknown directives MUST be ignored. Directive values can 880 have various formats. All possible directive values for the record- 881 type "cdni_http_request_v1" are further detailed in this section. 883 The following example shows the structure of a directive and 884 enumerates strictly the directive values presently defined in the 885 record-type "cdni_http_request_v1." 887 directive = DIRNAME ":" HTAB DIRVAL 889 DIRNAME = NAMEFORMAT 891 DIRVAL = NHTABSTRING / QSTRING / host / USER-COMMENT / FIENAME * 892 (HTAB FIENAME) / 64HEXDIG 894 An implementation of the CDNI Logging interface MUST support all of 895 the following directives, listed below by their directive name: 897 o version: 899 * format: NHTABSTRING 901 * directive value: indicates the version of the CDNI Logging File 902 format. The entity transmitting a CDNI Logging File as per the 903 present document MUST set the value to "CDNI/1.0". In the 904 future, other versions of CDNI Logging File might be specified; 905 those would use a value different to "CDNI/1.0" allowing the 906 entity receiving the CDNI Logging File to identify the 907 corresponding version. 909 * occurrence: there MUST be one and only one instance of this 910 directive per CDNI Logging File. It MUST be the first line of 911 the CDNI Logging File. 913 * example: "version: HTAB CDNI/1.0". 915 o UUID: 917 * format: NHTABSTRING 919 * directive value: this a Uniform Resource Name (URN) from the 920 Universally Unique IDentifier (UUID) URN namespace specified in 921 [RFC4122]). The UUID contained in the URN uniquely identifies 922 the CDNI Logging File. 924 * occurrence: there MUST be one and only one instance of this 925 directive per CDNI Logging File. 927 * example: "UUID: HTAB NHTABSTRING". 929 o claimed-origin: 931 * format: host 933 * directive value: this contains the claimed identification of 934 the entity transmitting the CDNI Logging File (e.g., the host 935 in a dCDN supporting the CDNI Logging interface) or the entity 936 responsible for transmitting the CDNI Logging File (e.g., the 937 dCDN). 939 * occurrence: there MUST be zero or exactly one instance of this 940 directive per CDNI Logging File. This directive MAY be 941 included by the dCDN. It MUST NOT be included or modified by 942 the uCDN. 944 * example: "claimed-origin: HTAB host". 946 o established-origin: 948 * format: host 950 * directive value: this contains the identification, as 951 established by the entity receiving the CDNI Logging File, of 952 the entity transmitting the CDNI Logging File (e.g., the host 953 in a dCDN supporting the CDNI Logging interface) or the entity 954 responsible for transmitting the CDNI Logging File (e.g., the 955 dCDN). 957 * occurrence: there MUST be zero or exactly one instance of this 958 directive per CDNI Logging File. This directive MAY be added 959 by the uCDN (e.g., before storing the CDNI Logging File). It 960 MUST NOT be included by the dCDN. The mechanisms used by the 961 uCDN to establish and validate the entity responsible for the 962 CDNI Logging File is outside the scope of the present document. 963 We observe that, in particular, this may be achieved through 964 authentication mechanisms that are part of the transport layer 965 of the CDNI Logging File pull mechanism (Section 4.2). 967 * ABNF example: "established-origin: HTAB host". 969 o remark: 971 * format: USER-COMMENT 973 * directive value: this contains comment information. Data 974 contained in this field is to be ignored by analysis tools. 976 * occurrence: there MAY be zero, one or any number of instance of 977 this directive per CDNI Logging File. 979 * example: "remark: HTAB USER-COMMENT". 981 o record-type: 983 * format: NAMEFORMAT 985 * directive value: indicates the type of the CDNI Logging Records 986 that follow this directive, until another record-type directive 987 (or the end of the CDNI Logging File). This can be any CDNI 988 Logging Record type registered in the CDNI Logging Record-types 989 registry (Section 6.3). For example this may be 990 "cdni_http_request_v1" as specified in Section 3.4.1. 992 * occurrence: there MUST be at least one instance of this 993 directive per CDNI Logging File. The first instance of this 994 directive MUST precede a fields directive and MUST precede all 995 CDNI Logging Records. 997 * example: "record-type: HTAB cdni_http_request_v1". 999 o fields: 1001 * format: FIENAME *(HTAB FIENAME) ; where FIENAME can take any 1002 CDNI Logging field name registered in the CDNI Logging Field 1003 Names registry (Section 6.4). 1005 * directive value: this lists the names of all the fields for 1006 which a value is to appear in the CDNI Logging Records that 1007 follow the instance of this directive (until another instance 1008 of this directive). The names of the fields, as well as their 1009 occurrences, MUST comply with the corresponding rules specified 1010 in the document referenced in the CDNI Logging Record-types 1011 registry (Section 6.3) for the corresponding CDNI Logging 1012 record-type. 1014 * occurrence: there MUST be at least one instance of this 1015 directive per record-type directive. The first instance of 1016 this directive for a given record-type MUST appear before any 1017 CDNI Logging Record for this record-type. One situation where 1018 more than one instance of the fields directive can appear 1019 within a given CDNI Logging File, is when there is a change, in 1020 the middle of a fairly large logging period, in the agreement 1021 between the uCDN and the dCDN about the set of fields that are 1022 to be exchanged. The multiple occurrences allow records with 1023 the old set of fields and records with the new set of fields to 1024 be carried inside the same Logging File. 1026 * example: "fields: HTAB FIENAME * (HTAB FIENAME)". 1028 o SHA256-hash: 1030 * format: 64HEXDIG 1032 * directive value: This directive permits the detection of a 1033 corrupted CDNI Logging File. This can be useful, for instance, 1034 if a problem occurs on the filesystem of the dCDN Logging 1035 system and leads to a truncation of a logging file. The valid 1036 SHA256-hash value is included in this directive by the entity 1037 that transmits the CDNI Logging File. It MUST be computed by 1038 applying the SHA-256 ([RFC6234]) cryptographic hash function on 1039 the CDNI Logging File, including all the directives and logging 1040 records, up to the SHA256-hash directive itself, excluding the 1041 SHA256-hash directive itself. The SHA256-hash value MUST be 1042 represented as a US-ASCII encoded hexadecimal number, 64 digits 1043 long (representing a 256 bit hash value). The entity receiving 1044 the CDNI Logging File also computes in a similar way the 1045 SHA-256 hash on the received CDNI Logging File and compares 1046 this hash to the value of the SHA256-hash directive. If the 1047 two values are equal, then the received CDNI Logging File is to 1048 be considered non-corrupted. If the two values are different, 1049 the received CDNI Logging File is to be considered corrupted. 1050 The behavior of the entity that received a corrupted CDNI 1051 Logging File is outside the scope of this specification; we 1052 note that the entity MAY attempt to pull again the same CDNI 1053 Logging File from the transmitting entity. If the entity 1054 receiving a non-corrupted CDNI Logging File adds an 1055 established-origin directive, it MUST then recompute and update 1056 the SHA256-hash directive so it also protects the added 1057 established-origin directive. 1059 * occurrence: there MUST be zero or exactly one instance of this 1060 directive. There SHOULD be exactly one instance of this 1061 directive. One situation where that directive could be omitted 1062 is where integrity protection is already provided via another 1063 mechanism (for example if an integrity hash is associated to 1064 the CDNI Logging File out-of-band through the CDNI Logging Feed 1065 ( Section 4.1) leveraging ATOM extensions such as those 1066 proposed in [I-D.snell-atompub-link-extensions]. When present, 1067 the SHA256-hash field MUST be the last line of the CDNI Logging 1068 File. 1070 * example: "SHA256-hash: HTAB 64HEXDIG". 1072 An uCDN-side implementation of the CDNI Logging interface MUST reject 1073 a CDNI Logging File that does not comply with the occurrences 1074 specified above for each and every directive. For example, an uCDN- 1075 side implementation of the CDNI Logging interface receiving a CDNI 1076 Logging file with zero occurrence of the version directive, or with 1077 two occurrences of the SHA256-hash, MUST reject this CDNI Logging 1078 File. 1080 An entity receiving a CDNI Logging File with a value set to 1081 "CDNI/1.0" MUST process the CDNI Logging File as per the present 1082 document. An entity receiving a CDNI Logging File with a value set 1083 to a different value MUST process the CDNI Logging File as per the 1084 specification referenced in the CDNI Logging File version registry 1085 (see Section 6.1) if the implementation supports this specification 1086 and MUST reject the CDNI Logging File otherwise. 1088 3.4. CDNI Logging Records 1090 A CDNI Logging Record consists of a sequence of CDNI Logging fields 1091 relating to that single CDNI Logging Record. 1093 CDNI Logging fields MUST be separated by the "horizontal tabulation 1094 (HTAB)" character. 1096 To facilitate readability, a prefix scheme is used for CDNI Logging 1097 field names in a similar way to the one used in W3C Extended Log File 1098 Format [ELF]. The semantics of the prefix in the present document 1099 is: 1101 o "c-" refers to the User Agent that issues the request (corresponds 1102 to the "client" of W3C Extended Log Format) 1104 o "d-" refers to the dCDN (relative to a given CDN acting as an 1105 uCDN) 1107 o "s-" refers to the dCDN Surrogate that serves the request 1108 (corresponds to the "server" of W3C Extended Log Format) 1110 o "u-" refers to the uCDN (relative to a given CDN acting as a dCDN) 1112 o "cs-" refers to communication from the User Agent towards the dCDN 1113 Surrogate 1115 o "sc-" refers to communication from the dCDN Surrogate towards the 1116 User Agent 1118 An implementation of the CDNI Logging interface as per the present 1119 specification MUST support the CDNI HTTP Request Logging Record as 1120 specified in Section 3.4.1. 1122 A CDNI Logging Record contains the corresponding values for the 1123 fields that are enumerated in the last fields directive before the 1124 current log line. Note that the order in which the field values 1125 appear is dictated by the order of the fields names in the fields 1126 directive. There SHOULD be no dependency between the various fields 1127 values. 1129 3.4.1. HTTP Request Logging Record 1131 This section defines the CDNI Logging Record of record-type 1132 "cdni_http_request_v1". It is applicable to content delivery 1133 performed by the dCDN using HTTP/1.0([RFC1945]), 1134 HTTP/1.1([RFC7230],[RFC7231], [RFC7232], [RFC7233], [RFC7234], 1135 [RFC7235]) or HTTPS ([RFC2818], [RFC7230]). We observe that, in the 1136 case of HTTPS delivery, there may be value in logging additional 1137 information specific to the operation of HTTP over TLS and we note 1138 that this is outside the scope of the present document and may be 1139 addressed in a future document defining another CDNI Logging Record 1140 or another version of the HTTP Request Logging Record. 1142 The "cdni_http_request_v1" record-type is also expected to be 1143 applicable to HTTP/2 [RFC7540] since a fundamental design tenet of 1144 HTTP/2 is to preserve the HTTP/1.1 semantics. We observe that, in 1145 the case of HTTP/2 delivery, there may be value in logging additional 1146 information specific to the additional functionality of HTTP/2 (e.g., 1147 information related to connection identification, to stream 1148 identification, to stream priority and to flow control). We note 1149 that such additional information is outside the scope of the present 1150 document and may be addressed in a future document defining another 1151 CDNI Logging Record or another version of the HTTP Request Logging 1152 Record. 1154 The "cdni_http_request_v1" record-type contains the following CDNI 1155 Logging fields, listed by their field name: 1157 o date: 1159 * format: DATE 1161 * field value: the date at which the processing of request 1162 completed on the Surrogate. 1164 * occurrence: there MUST be one and only one instance of this 1165 field. 1167 o time: 1169 * format: TIME 1171 * field value: the time at which the processing of request 1172 completed on the Surrogate. 1174 * occurrence: there MUST be one and only one instance of this 1175 field. 1177 o time-taken: 1179 * format: DEC 1181 * field value: decimal value of the duration, in seconds, between 1182 the start of the processing of the request and the completion 1183 of the request processing (e.g., completion of delivery) by the 1184 Surrogate. 1186 * occurrence: there MUST be one and only one instance of this 1187 field. 1189 o c-groupid: 1191 * format: NHTABSTRING 1193 * field value: an opaque identifier for an aggregate set of 1194 clients, derived from the client IPv4 or IPv6 address in the 1195 request received by the Surrogate and/or other network-level 1196 identifying information. The c-groupid serves to group clients 1197 into aggregates. Example aggregates include civil geolocation 1198 information (the country, second-level administrative division, 1199 or postal code from which the client is presumed to make the 1200 request based on a geolocation database lookup) or network 1201 topological information (e.g., the BGP AS number announcing the 1202 prefix containing the address). The c-groupid MAY be 1203 structured e.g., US/TN/MEM/38138. Agreement between the dCDN 1204 and the uCDN on a mapping between IPv4 and IPv6 addresses and 1205 aggregates is presumed to occur out-of-band. The aggregation 1206 mapping SHOULD be chosen such that each aggregate contains more 1207 than one client. When the aggregate is chosen so that it 1208 contains a single client (e.g., to allow more detailed 1209 analytics, or to allow a-posteriori analysis of individual 1210 delivery for example in situations of performance-based 1211 penalties): 1213 + the c-groupid MAY be structured (e.g., US/TN/ 1214 MEM/38138/43a5bdd6-95c4-4d62-be65-7410df0021e2) where some 1215 elements identify aggregates and one element identifies the 1216 client. 1218 + the address with a shared secret that is pre-synchronised 1219 and rotated at a predefined time interval. It is 1220 RECOMMENDED that the mapping varies at least once every 24 1221 hours. The mapping from IP address to the element 1222 identifying the client (effectively an encryption of the 1223 address) SHOULD be done using a symmetric key that is known 1224 only to both the uCDN and dCDN. One method of doing this is 1225 to use an analog of how key derivation is via HKDF 1226 ([RFC5869]), as will be used in TLS 1.3 1227 ([I-D.ietf-tls-rfc5246-bis]). When the two CDNs set up the 1228 relationship, they agree out-of-band on a mapping between 1229 IPv4 and IPv6 addresses and aggregates and on the 1230 algorithmic mapping from IPv4/IPv6 addresses and the element 1231 identifying the client; they agree on the salt and input key 1232 material, as described in [RFC5869], Section 2.2, the hash 1233 mechanism to use (SHA-2 or SHA-3 SHOULD be used), and the 1234 key lifetime which SHOULD NOT exceed 25 hours. They also 1235 agree on an initial "info" parameter, which can be something 1236 such as the business names of the two organizations in UTF- 1237 8, concatenated. The encryption algorithm also needs to be 1238 defined, and SHOULD be 128-bit AES-GCM or better. The PRK 1239 should be chosen by both parties contributing alternate 1240 random bytes until sufficient length exists. After this 1241 initial setup, client-information is encrypted using the key 1242 generated by the "expand" step, Section 2.3 of [RFC5869], 1243 and hex-encoded or base64-encoded. At the agreed-upon 1244 lifetime, a new key is used, indicated by prefixing the key 1245 with a special character such as exclamation point. In this 1246 way, shorter lifetimes can be used as needed. 1248 + the element identifying the client SHOULD be algorithmically 1249 generated (from the client IPv4 or IPv6 address in the 1250 request received by the Surrogate and/or other network-level 1251 identifying information) in a way that SHOULD NOT be 1252 linkable back to the global addressing context and that 1253 SHOULD vary over time (to offer protection against long term 1254 attacks); one example way to achieve this is to hash. 1256 + The algorithmic mapping and variation over time MAY allow 1257 the uCDN (with the knowledge of the algorithm and time 1258 variation and associated attributes and keys) to reconstruct 1259 the actual enduser IPv4/IPv6 addresses where that is 1260 required (e.g., to allow a-posteriori analysis of individual 1261 delivery for example in situations of performance-based 1262 penalties). However, these enduser IPv4/IPv6 addresses 1263 SHOULD only be reconstructed on-demand and the CDNI Logging 1264 File SHOULD only be stored with the anonymised c-groupid 1265 value. 1267 + Using the c-groupid field in this way carries with it grave 1268 risks to end-user privacy. Since the c-groupid is in this 1269 case equivalent in identification power to a client IP 1270 address, its use may be restricted by regulation or law as 1271 personally identifiable information. For this reason, such 1272 use is NOT RECOMMENDED. 1274 * occurrence: there MUST be one and only one instance of this 1275 field. 1277 o s-ip: 1279 * format: ADDRESS 1281 * field value: the IPv4 or IPv6 address of the Surrogate that 1282 served the request (i.e., the "server" address). 1284 * occurrence: there MUST be zero or exactly one instance of this 1285 field. 1287 o s-hostname: 1289 * format: host 1291 * field value: the hostname of the Surrogate that served the 1292 request (i.e., the "server" hostname). 1294 * occurrence: there MUST be zero or exactly one instance of this 1295 field. 1297 o s-port: 1299 * format: 1*DIGIT 1301 * field value: the destination TCP port (i.e., the "server" port) 1302 in the request received by the Surrogate. 1304 * occurrence: there MUST be zero or exactly one instance of this 1305 field. 1307 o cs-method: 1309 * format: NHTABSTRING 1311 * field value: this is the method of the request received by the 1312 Surrogate. In the case of HTTP delivery, this is the HTTP 1313 method in the request. 1315 * occurrence: There MUST be one and only one instance of this 1316 field. 1318 o cs-uri: 1320 * format: NHTABSTRING 1322 * field value: this is the "effective request URI" of the request 1323 received by the Surrogate as specified in [RFC7230]. It 1324 complies with the "http" URI scheme or the "https" URI scheme 1325 as specified in [RFC7230]). Note that cs-uri can be privacy 1326 sensitive. In that case, and where appropriate, u-uri could be 1327 used instead of cs-uri. 1329 * occurrence: there MUST be zero or exactly one instance of this 1330 field. 1332 o u-uri: 1334 * format: NHTABSTRING 1336 * field value: this is a complete URI, derived from the 1337 "effective request URI" ([RFC7230]) of the request received by 1338 the Surrogate (i.e., the cs-uri) but transformed by the entity 1339 generating or transmitting the CDNI Logging Record, in a way 1340 that is agreed upon between the two ends of the CDNI Logging 1341 interface, so the transformed URI is meaningful to the uCDN. 1342 For example, the two ends of the CDNI Logging interface could 1343 agree that the u-uri is constructed from the cs-uri by removing 1344 the part of the hostname that exposes which individual 1345 Surrogate actually performed the delivery. The details of 1346 modification performed to generate the u-uri, as well as the 1347 mechanism to agree on these modifications between the two sides 1348 of the CDNI Logging interface are outside the scope of the 1349 present document. 1351 * occurrence: there MUST be one and only one instance of this 1352 field. 1354 o protocol: 1356 * format: NHTABSTRING 1358 * field value: this is value of the HTTP-Version field as 1359 specified in [RFC7230] of the Request-Line of the request 1360 received by the Surrogate (e.g., "HTTP/1.1"). 1362 * occurrence: there MUST be one and only one instance of this 1363 field. 1365 o sc-status: 1367 * format: 3DIGIT 1369 * field value: this is the Status-Code in the response from the 1370 Surrogate. In the case of HTTP delivery, this is the HTTP 1371 Status-Code in the HTTP response. 1373 * occurrence: There MUST be one and only one instance of this 1374 field. 1376 o sc-total-bytes: 1378 * format: 1*DIGIT 1380 * field value: this is the total number of bytes of the response 1381 sent by the Surrogate in response to the request. In the case 1382 of HTTP delivery, this includes the bytes of the Status-Line, 1383 the bytes of the HTTP headers and the bytes of the message- 1384 body. 1386 * occurrence: There MUST be one and only one instance of this 1387 field. 1389 o sc-entity-bytes: 1391 * format: 1*DIGIT 1392 * field value: this is the number of bytes of the message-body in 1393 the HTTP response sent by the Surrogate in response to the 1394 request. This does not include the bytes of the Status-Line or 1395 the bytes of the HTTP headers. 1397 * occurrence: there MUST be zero or exactly one instance of this 1398 field. 1400 o cs(insert_HTTP_header_name_here): 1402 * format: QSTRING 1404 * field value: the value of the HTTP header (identified by the 1405 insert_HTTP_header_name_here in the CDNI Logging field name) as 1406 it appears in the request processed by the Surrogate, but 1407 prepended by a DQUOTE and appended by a DQUOTE. For example, 1408 when the CDNI Logging field name (FIENAME) listed in the 1409 preceding fields directive is cs(User-Agent), this CDNI Logging 1410 field value contains the value of the User-Agent HTTP header as 1411 received by the Surrogate in the request it processed, but 1412 prepended by a DQUOTE and appended by a DQUOTE. If the HTTP 1413 header as it appeared in the request processed by the Surrogate 1414 contains one or more DQUOTE, each DQUOTE MUST be escaped with 1415 percent encoding. For example, if the HTTP header contains 1416 My_Header"value", then the field value of the 1417 cs(insert_HTTP_header_name_here) is "My_Header%x22value%x22". 1418 The entity transmitting the CDNI Logging File MUST ensure that 1419 the respective insert_HTTP_header_name_here of the 1420 cs(insert_HTTP_header_name_here) listed in the fields directive 1421 comply with HTTP specifications. In particular, this field 1422 name does not include any HTAB, since this would prevent proper 1423 parsing of the fields directive by the entity receiving the 1424 CDNI Logging File. 1426 * occurrence: there MAY be zero, one or any number of instance of 1427 this field. 1429 o sc(insert_HTTP_header_name_here): 1431 * format: QSTRING 1433 * field value: the value of the HTTP header (identified by the 1434 insert_HTTP_header_name_here in the CDNI Logging field name) as 1435 it appears in the response issued by the Surrogate to serve the 1436 request, but prepended by a DQUOTE and appended by a DQUOTE. 1437 If the HTTP header as it appeared in the request processed by 1438 the Surrogate contains one or more DQUOTE, each DQUOTE MUST be 1439 escaped with percent encoding. For example, if the HTTP header 1440 contains My_Header"value", then the field value of the 1441 sc(insert_HTTP_header_name_here) is "My_Header%x22value%x22". 1442 The entity transmitting the CDNI Logging File MUST ensure that 1443 the respective insert_HTTP_header_name_here of the 1444 cs(insert_HTTP_header_name_here) listed in the fields directive 1445 comply with HTTP specifications. In particular, this field 1446 name does not include any HTAB, since this would prevent proper 1447 parsing of the fields directive by the entity receiving the 1448 CDNI Logging File. 1450 * occurrence: there MAY be zero, one or any number of instances 1451 of this field. For a given insert_HTTP_header_name_here, there 1452 MUST be zero or exactly one instance of this field. 1454 o s-ccid: 1456 * format: QSTRING 1458 * field value: this contains the value of the Content Collection 1459 IDentifier (CCID) associated by the uCDN to the content served 1460 by the Surrogate via the CDNI Metadata interface 1461 ([I-D.ietf-cdni-metadata]), prepended by a DQUOTE and appended 1462 by a DQUOTE. If the CCID conveyed in the CDNI Metadata 1463 interface contains one or more DQUOTE, each DQUOTE MUST be 1464 escaped with percent encoding. For example, if the CCID 1465 conveyed in the CDNI Metadata interface is My_CCIDD"value", 1466 then the field value of the s-ccid is "My_CCID%x22value%X22". 1468 * occurrence: there MUST be zero or exactly one instance of this 1469 field. For a given insert_HTTP_header_name_here, there MUST be 1470 zero or exactly one instance of this field. 1472 o s-sid: 1474 * format: QSTRING 1476 * field value: this contains the value of a Session IDentifier 1477 (SID) generated by the dCDN for a specific HTTP session, 1478 prepended by a DQUOTE and appended by a DQUOTE. In particular, 1479 for HTTP Adaptive Streaming (HAS) session, the Session 1480 IDentifier value is included in the Logging record for every 1481 content chunk delivery of that session in view of facilitating 1482 the later correlation of all the per content chunk log records 1483 of a given HAS session. See section 3.4.2.2. of [RFC6983] for 1484 more discussion on the concept of Session IDentifier in the 1485 context of HAS. If the SID conveyed contains one or more 1486 DQUOTE, each DQUOTE MUST be escaped with percent encoding. For 1487 example, if the SID is My_SID"value", then the field value of 1488 the s-sid is "My_SID%x22value%x22". 1490 * occurrence: there MUST be zero or exactly one instance of this 1491 field. 1493 o s-cached: 1495 * format: 1DIGIT 1497 * field value: this characterises whether the Surrogate served 1498 the request using content already stored on its local cache or 1499 not. The allowed values are "0" (for miss) and "1" (for hit). 1500 "1" MUST be used when the Surrogate did serve the request using 1501 exclusively content already stored on its local cache. "0" MUST 1502 be used otherwise (including cases where the Surrogate served 1503 the request using some, but not all, content already stored on 1504 its local cache). Note that a "0" only means a cache miss in 1505 the Surrogate and does not provide any information on whether 1506 the content was already stored, or not, in another device of 1507 the dCDN, i.e., whether this was a "dCDN hit" or "dCDN miss". 1509 * occurrence: there MUST be zero or exactly one instance of this 1510 field. 1512 The "fields" directive corresponding to a HTTP Request Logging Record 1513 MUST contain all the fields names whose occurrence is specified above 1514 as "There MUST be one and only one instance of this field". The 1515 corresponding fields value MUST be present in every HTTP Request 1516 Logging Record. 1518 The "fields" directive corresponding to a HTTP Request Logging Record 1519 MAY list all the fields value whose occurrence is specified above as 1520 "there MUST be zero or exactly one instance of this field" or "there 1521 MAY be zero, one or any number of instances of this field". The set 1522 of such field names actually listed in the "fields" directive is 1523 selected by the CDN generating the CDNI Logging File based on 1524 agreements between the interconnected CDNs established through 1525 mechanisms outside the scope of this specification (e.g., contractual 1526 agreements). When such a field name is not listed in the "fields" 1527 directive, the corresponding field value MUST NOT be included in the 1528 Logging Record. When such a field name is listed in the "fields" 1529 directive, the corresponding field value MUST be included in the 1530 Logging Record; if the value for the field is not available, this 1531 MUST be conveyed via a dash character ("-"). 1533 The fields names listed in the "fields" directive MAY be listed in 1534 the order in which they are listed in Section 3.4.1 or MAY be listed 1535 in any other order. 1537 Logging some specific fields from HTTP requests and responses can 1538 introduce serious security and privacy risks. For example, cookies 1539 will often contain (months) long lived token values that can be used 1540 to log into a service as the relevant user. Similar values may be 1541 included in other header fields or within URLs or elsewhere in HTTP 1542 requests and responses. Centralising such values in a CDNI Logging 1543 File can therefore represent a significant increase in risk both for 1544 the user and the web service provider, but also for the CDNs 1545 involved. Implementations ought therefore to attempt to lower the 1546 probability of such bad outcomes e.g. by only allowing a configured 1547 set of headers to be added to CDNI Logging Records, or by not 1548 supporting wildcard selection of HTTP request/response fields to add. 1549 Such mechanisms can reduce the probability that security (or privacy) 1550 sensitive values are centralised in CDNI Logging Files. Also, when 1551 agreeing on which HTTP request/response fields are to be provided in 1552 CDNI Logging Files, the uCDN and dCDN administrators ought to 1553 consider these risks. 1555 A dCDN-side implementation of the CDNI Logging interface MUST 1556 implement all the following Logging fields in a CDNI Logging Record 1557 of record-type "cdni_http_request_v1", and MUST support the ability 1558 to include valid values for each of them: 1560 o date 1562 o time 1564 o time-taken 1566 o c-groupid 1568 o s-ip 1570 o s-hostname 1572 o s-port 1574 o cs-method 1576 o cs-uri 1578 o u-uri 1580 o protocol 1581 o sc-status 1583 o sc-total-bytes 1585 o sc-entity-bytes 1587 o cs(insert_HTTP_header_name_here) 1589 o sc(insert_HTTP_header_name_here) 1591 o s-cached 1593 A dCDN-side implementation of the CDNI Logging interface MAY support 1594 the following Logging fields in a CDNI Logging Record of record-type 1595 "cdni_http_request_v1": 1597 o s-ccid 1599 o s-sid 1601 If a dCDN-side implementation of the CDNI Logging interface supports 1602 these fields, it MUST support the ability to include valid values for 1603 them. 1605 An uCDN-side implementation of the CDNI Logging interface MUST be 1606 able to accept CDNI Logging Files with CDNI Logging Records of 1607 record-type "cdni_http_request_v1" containing any CDNI Logging Field 1608 defined in Section 3.4.1 as long as the CDNI Logging Record and the 1609 CDNI Logging File are compliant with the present document. 1611 In case an uCDN-side implementation of the CDNI Logging interface 1612 receives a CDNI Logging File with HTTP Request Logging Records that 1613 do not contain field values for exactly the set of field names 1614 actually listed in the preceding "fields" directive, the 1615 implementation MUST reject those HTTP Request Logging Records, and 1616 MUST accept the other HTTP Request Logging Records. 1618 To ensure that the logging file is correct, the text MUST be 1619 sanitized before being logged. Null, bare CR, bare LF and HTAB have 1620 to be removed by escaping them through percent encoding to avoid 1621 confusion with the logging record separators. 1623 3.5. CDNI Logging File Example 1625 Let us consider the upstream CDN and the downstream CDN labelled uCDN 1626 and dCDN-1 in Figure 1. When dCDN-1 acts as a downstream CDN for 1627 uCDN and performs content delivery on behalf of uCDN, dCDN-1 will 1628 include the CDNI Logging Records corresponding to the content 1629 deliveries performed on behalf of uCDN in the CDNI Logging Files for 1630 uCDN. An example CDNI Logging File communicated by dCDN-1 to uCDN is 1631 shown below in Figure 4. 1633 #version:cdni/1.0 1635 #UUID:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 1637 #claimed-origin:cdni-logging-entity.dcdn-1.example.com 1639 #record-type:cdni_http_request_v1 1641 #fields:datetimetime-takenc-groupid 1642 cs-methodu-uriprotocol 1643 sc-statussc-total-bytescs(User-Agent) 1644 cs(Referer)s-cached 1646 2013-05-1700:38:06.8259.058US/TN/MEM/38138 1647 GET 1648 http://cdni-ucdn.dcdn-1.example.com/video/movie100.mp4 1649 HTTP/1.12006729891"Mozilla/5.0 1650 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like 1651 Gecko) Chrome/5.0.375.127 Safari/533.4" 1652 "host1.example.com"1 1654 2013-05-1700:39:09.14515.32FR/PACA/NCE/06100 1655 GET 1656 http://cdni-ucdn.dcdn-1.example.com/video/movie118.mp4 1657 HTTP/1.120015799210"Mozilla/5.0 1658 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like 1659 Gecko) Chrome/5.0.375.127 Safari/533.4" 1660 "host1.example.com"1 1662 2013-05-1700:42:53.43752.879US/TN/MEM/38138 1663 GET 1664 http://cdni-ucdn.dcdn-1.example.com/video/picture11.mp4 1665 HTTP/1.020097234724"Mozilla/5.0 1666 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like 1667 Gecko) Chrome/5.0.375.127 Safari/533.4" 1668 "host5.example.com"0 1670 #SHA256-hash: 64-hexadecimal-digit hash value 1672 Figure 4: CDNI Logging File Example 1674 If uCDN establishes by some means (e.g., via TLS authentication when 1675 pulling the CDNI Logging File) the identity of the entity from which 1676 it pulled the CDNI Logging File, uCDN can add to the CDNI Logging an 1677 established-origin directive as illustrated below: 1679 #established-origin:cdni-logging-entity.dcdn- 1680 1.example.com 1682 As illustrated in Figure 2, uCDN will then ingest the corresponding 1683 CDNI Logging Records into its Collection process, alongside the 1684 Logging Records generated locally by the uCDN itself. This allows 1685 uCDN to aggregate Logging Records for deliveries performed by itself 1686 (through Records generated locally) as well as for deliveries 1687 performed by its downstream CDN(s). This aggregate information can 1688 then be used (after Filtering and Rectification, as illustrated in 1689 Figure 2) by Log Consuming Applications that take into account 1690 deliveries performed by uCDN as well as by all of its downstream 1691 CDNs. 1693 We observe that the time between 1695 1. when a delivery is completed in dCDN and 1697 2. when the corresponding Logging Record is ingested by the 1698 Collection process in uCDN 1700 depends on a number of parameters such as the Logging Period agreed 1701 to by uCDN and dCDN, how much time uCDN waits before pulling the CDNI 1702 Logging File once it is advertised in the CDNI Logging Feed, and the 1703 time to complete the pull of the CDNI Logging File. Therefore, if we 1704 consider the set of Logging Records aggregated by the Collection 1705 process in uCDN in a given time interval, there could be a permanent 1706 significant timing difference between the CDNI Logging Records 1707 received from the dCDN and the Logging Records generated locally. 1708 For example, in a given time interval, the Collection process in uCDN 1709 may be aggregating Logging Records generated locally by uCDN for 1710 deliveries performed in the last hour and CDNI Logging Records 1711 generated in the dCDN for deliveries in the hour before last. 1713 3.6. Cascaded CDNI Logging Files Example 1715 Let us consider the cascaded CDN scenario of uCDN, dCDN-2 and dCDN-3 1716 as depicted in Figure 1. After completion of a delivery by dCDN-3 on 1717 behalf of dCDN-2, dCDN-3 will include a corresponding Logging Record 1718 in a CDNI Logging File that will be pulled by dCDN-2 and that is 1719 illustrated below in Figure 5. In practice, a CDNI Logging File is 1720 likely to contain a very high number of CDNI Logging Records. 1721 However, for readability, the example in Figure 5 contains a single 1722 CDNI Logging Record. 1724 #version:CDNI/1.0 1726 #UUID:urn:uuid:65718ef-0123-9876-adce4321bcde 1728 #claimed-origin:cdni-logging-entity.dcdn-3.example.com 1730 #record-type:cdni_http_request_v1 1732 #fields:datetimetime-takenc-groupid 1733 cs-methodu-uriprotocol 1734 sc-statussc-total-bytescs(User-Agent) 1735 cs(Referer)s-cached 1737 2013-05-1700:39:09.11914.07US/CA/SFO/94114 1738 GET 1739 http://cdni-dcdn-2.dcdn-3.example.com/video/movie118.mp4 1740 HTTP/1.120015799210"Mozilla/5.0 1741 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like 1742 Gecko) Chrome/5.0.375.127 Safari /533.4" 1743 "host1.example.com"1 1745 #SHA256-hash: 64-hexadecimal-digit hash value 1747 Figure 5: Cascaded CDNI Logging File Example (dCDN-3 to dCDN-2) 1749 If dCDN-2 establishes by some means (e.g., via TLS authentication 1750 when pulling the CDNI Logging File) the identity of the entity from 1751 which it pulled the CDNI Logging File, dCDN-2 can add to the CDNI 1752 Logging an established-origin directive as illustrated below: 1754 #established-origin:cdni-logging-entity.dcdn- 1755 3.example.com 1757 dCDN-2 (behaving as an upstream CDN from the viewpoint of dCDN-3) 1758 will then ingest the CDNI Logging Record for the considered dCDN-3 1759 delivery into its Collection process (as illustrated in Figure 2). 1760 This Logging Record may be aggregated with Logging Records generated 1761 locally by dCDN-2 for deliveries performed by dCDN-2 itself. Say, 1762 for illustration, that the content delivery performed by dCDN-3 on 1763 behalf of dCDN-2 had actually been redirected to dCDN-2 by uCDN, and 1764 say that another content delivery has just been redirected by uCDN to 1765 dCDN-2 and that dCDN-2 elected to perform the corresponding delivery 1766 itself. Then after Filtering and Rectification (as illustrated in 1767 Figure 2), dCDN-2 will include the two Logging Records corresponding 1768 respectively to the delivery performed by dCDN-3 and the delivery 1769 performed by dCDN-2, in the next CDNI Logging File that will be 1770 communicated to uCDN. An example of such CDNI Logging File is 1771 illustrated below in Figure 6. 1773 #version:CDNI/1.0 1775 #UUID:urn:uuid:1234567-8fedc-abab-0987654321ff 1777 #claimed-origin:cdni-logging-entity.dcdn-2.example.com 1779 #record-type:cdni_http_request_v1 1781 #fields:datetimetime-takenc-groupid 1782 cs-methodu-uriprotocol 1783 sc-statussc-total-bytescs(User-Agent) 1784 cs(Referer)s-cached 1786 2013-05-1700:39:09.11914.07US/CA/SFO/94114 1787 GET 1788 http://cdni-ucdn.dcdn-2.example.com/video/movie118.mp4 1789 HTTP/1.120015799210"Mozilla/5.0 1790 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like 1791 Gecko) Chrome/5.0.375.127 Safari /533.4" 1792 "host1.example.com"1 1794 2013-05-1701:42:53.43752.879FR/IDF/PAR/75001 1795 GET 1796 http://cdni-ucdn.dcdn-2.example.com/video/picture11.mp4 1797 HTTP/1.020097234724"Mozilla/5.0 1798 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like 1799 Gecko) Chrome/5.0.375.127 Safari /533.4" 1800 "host5.example.com"0 1802 #SHA256-hash: 64-hexadecimal-digit hash value 1804 Figure 6: Cascaded CDNI Logging File Example (dCDN-2 to uCDN) 1806 If uCDN establishes by some means (e.g., via TLS authentication when 1807 pulling the CDNI Logging File) the identity of the entity from which 1808 it pulled the CDNI Logging File, uCDN can add to the CDNI Logging an 1809 established-origin directive as illustrated below: 1811 #established-origin:cdni-logging-entity.dcdn- 1812 2.example.com 1814 In the example of Figure 6, we observe that: 1816 o the first Logging Record corresponds to the Logging Record 1817 communicated earlier to dCDN-2 by dCDN-3, which corresponds to a 1818 delivery redirected by uCDN to dCDN-2 and then redirected by 1819 dCDN-2 to dCDN-3. The fields values in this Logging Record are 1820 copied from the corresponding CDNI Logging REcord communicated to 1821 dCDN2 by dCDN-3, with the exception of the u-uri that now reflects 1822 the URI convention between uCDN and dCDN-2 and that presents the 1823 delivery to uCDN as if it was performed by dCDN-2 itself. This 1824 reflects the fact that dCDN-2 had taken the full responsibility of 1825 the corresponding delivery (even if in this case, dCDN-2 elected 1826 to redirect the delivery to dCDN-3 so it is actually performed by 1827 dCDN-3 on behalf of dCDN-2). 1829 o the second Logging Record corresponds to a delivery redirected by 1830 uCDN to dCDN-2 and performed by dCDN-2 itself. The time of the 1831 delivery in this Logging Record may be significantly more recent 1832 than the first Logging Record since it was generated locally while 1833 the first Logging Record was generated by dCDN-3 and had to be 1834 advertised , and then pulled and then ingested into the dCDN-2 1835 Collection process, before being aggregated with the second 1836 Logging Record. 1838 4. Protocol for Exchange of CDNI Logging File After Full Collection 1840 This section specifies a protocol for the exchange of CDNI Logging 1841 Files as specified in Section 3 after the CDNI Logging File is fully 1842 collected by the dCDN. 1844 This protocol comprises: 1846 o a CDNI Logging feed, allowing the dCDN to notify the uCDN about 1847 the CDNI Logging Files that can be retrieved by that uCDN from the 1848 dCDN, as well as all the information necessary for retrieving each 1849 of these CDNI Logging Files. The CDNI Logging feed is specified 1850 in Section 4.1. 1852 o a CDNI Logging File pull mechanism, allowing the uCDN to obtain 1853 from the dCDN a given CDNI Logging File at the uCDN's convenience. 1854 The CDNI Logging File pull mechanisms is specified in Section 4.2. 1856 An implementation of the CDNI Logging interface on the dCDN side (the 1857 entity generating the CDNI Logging file) MUST support the server side 1858 of the CDNI Logging feed (as specified in Section 4.1) and the server 1859 side of the CDNI Logging pull mechanism (as specified in 1860 Section 4.2). 1862 An implementation of the CDNI Logging interface on the uCDN side (the 1863 entity consuming the CDNI Logging file) MUST support the client side 1864 of the CDNI Logging feed (as specified in Section 4.1) and the client 1865 side of the CDNI Logging pull mechanism (as specified in 1866 Section 4.2). 1868 4.1. CDNI Logging Feed 1870 The server-side implementation of the CDNI Logging feed MUST produce 1871 an Atom feed [RFC4287]. This feed is used to advertise log files 1872 that are available for the client-side to retrieve using the CDNI 1873 Logging pull mechanism. 1875 4.1.1. Atom Formatting 1877 A CDNI Logging feed MUST be structured as an Archived feed, as 1878 defined in [RFC5005], and MUST be formatted in Atom [RFC4287]. This 1879 means it consists of a subscription document that is regularly 1880 updated as new CDNI Logging Files become available, and information 1881 about older CDNI Logging files is moved into archive documents. Once 1882 created, archive documents are never modified. 1884 Each CDNI Logging File listed in an Atom feed MUST be described in an 1885 atom:entry container element. 1887 The atom:entry MUST contain an atom:content element whose "src" 1888 attribute is a link to the CDNI Logging File and whose "type" 1889 attribute is the MIME Media Type indicating that the entry is a CDNI 1890 logging file. This MIME Media Type is defined as "application/cdni" 1891 (See [RFC7736]) with the Payload Type (ptype) parameter set to 1892 "logging-file". 1894 For compatibility with some Atom feed readers the atom:entry MAY also 1895 contain an atom:link entry whose "href" attribute is a link to the 1896 CDNI Logging File and whose "type" attribute is the MIME Media Type 1897 indicating that the entry is a CDNI Logging File using the 1898 "application/cdni" MIME Media Type with the Payload Type (ptype) 1899 parameter set to "logging-file"(See [RFC7736]). 1901 The URI used in the atom:id of the atom:entry MUST contain the UUID 1902 of the CDNI Logging File. 1904 The atom:updated in the atom:entry MUST indicate the time at which 1905 the CDNI Logging File was last updated. 1907 4.1.2. Updates to Log Files and the Feed 1909 CDNI Logging Files MUST NOT be modified by the dCDN once published in 1910 the CDNI Logging feed. 1912 The frequency with which the subscription feed is updated, the period 1913 of time covered by each CDNI Logging File or each archive document, 1914 and timeliness of publishing of CDNI Logging Files are outside the 1915 scope of the present document and are expected to be agreed upon by 1916 uCDN and dCDN via other means (e.g., human agreement). 1918 The server-side implementation MUST be able to set, and SHOULD set, 1919 HTTP cache control headers on the subscription feed to indicate the 1920 frequency at which the client-side is to poll for updates. 1922 The client-side MAY use HTTP cache control headers (set by the 1923 server-side) on the subscription feed to determine the frequency at 1924 which to poll for updates. The client-side MAY instead, or in 1925 addition, use other information to determine when to poll for updates 1926 (e.g., a polling frequency that may have been negotiated between the 1927 uCDN and dCDN by mechanisms outside the scope of the present document 1928 and that is to override the indications provided in the HTTP cache 1929 control headers). 1931 The potential retention limits (e.g., sliding time window) within 1932 which the dCDN is to retain and be ready to serve an archive document 1933 is outside the scope of the present document and is expected to be 1934 agreed upon by uCDN and dCDN via other means (e.g., human agreement). 1935 The server-side implementation MUST retain, and be ready to serve, 1936 any archive document within the agreed retention limits. Outside 1937 these agreed limits, the server-side implementation MAY indicate its 1938 inability to serve (e.g., with HTTP status code 404) an archive 1939 document or MAY refuse to serve it (e.g., with HTTP status code 403 1940 or 410). 1942 4.1.3. Redundant Feeds 1944 The server-side implementation MAY present more than one CDNI Logging 1945 feed for redundancy. Each CDNI Logging File MAY be published in more 1946 than one feed. 1948 A client-side implementation MAY support such redundant CDNI Logging 1949 feeds. If it supports redundant CDNI Logging feed, the client-side 1950 can use the UUID of the CDNI Logging File, presented in the atom:id 1951 element of the Atom feed, to avoid unnecessarily pulling and storing 1952 a given CDNI Logging File more than once. 1954 4.1.4. Example CDNI Logging Feed 1956 Figure 7 illustrates an example of the subscription document of a 1957 CDNI Logging feed. 1959 1960 1961 CDNI Logging Feed 1962 2013-03-23T14:46:11Z 1963 urn:uuid:663ae677-40fb-e99a-049d-c5642916b8ce 1964 1966 1968 1970 CDNI Log Feed 1971 Generator 1972 dcdn.example 1973 1974 CDNI Logging File for uCDN at 1975 2013-03-23 14:15:00 1976 urn:uuid:12345678-1234-abcd-00aa-01234567abcd 1977 2013-03-23T14:15:00Z 1978 1982 CDNI Logging File for uCDN at 1983 2013-03-23 14:15:00 1984 1985 1986 CDNI Logging File for uCDN at 1987 2013-03-23 14:30:00 1988 urn:uuid:87654321-4321-dcba-aa00-dcba7654321 1989 2013-03-23T14:30:00Z 1990 1994 CDNI Logging File for uCDN at 1995 2013-03-23 14:30:00 1996 1997 ... 1998 1999 ... 2000 2001 2003 Figure 7: Example subscription document of a CDNI Logging Feed 2005 4.2. CDNI Logging File Pull 2007 A client-side implementation of the CDNI Logging interface MAY pull, 2008 at its convenience, a CDNI Logging File that is published by the 2009 server-side in the CDNI Logging Feed (in the subscription document or 2010 an archive document). To do so, the client-side: 2012 o MUST implement HTTP/1.1 ([RFC7230],[RFC7231], [RFC7232], 2013 [RFC7233], [RFC7234], [RFC7235]), MAY also support other HTTP 2014 versions (e.g., HTTP/2 [RFC7540]) and MAY negotiate which HTTP 2015 version is actually used. This allows operators and implementers 2016 to choose to use later versions of HTTP to take advantage of new 2017 features, while still ensuring interoperability with systems that 2018 only support HTTP/1.1. 2020 o MUST use the URI that was associated to the CDNI Logging File 2021 (within the "src" attribute of the corresponding atom:content 2022 element) in the CDNI Logging Feed; 2024 o MUST support exchange of CDNI Logging Files with no content 2025 encoding applied to the representation; 2027 o MUST support exchange of CDNI Logging Files with "gzip" content 2028 encoding (as defined in [RFC7230]) applied to the representation. 2030 Note that a client-side implementation of the CDNI Logging interface 2031 MAY pull a CDNI Logging File that it has already pulled. 2033 The server-side implementation MUST respond to valid pull request by 2034 a client-side implementation for a CDNI Logging File published by the 2035 server-side in the CDNI Logging Feed (in the subscription document or 2036 an archive document). The server-side implementation: 2038 o MUST implement HTTP/1.1 to handle the client-side request and MAY 2039 also support other HTTP versions (e.g., HTTP/2); 2041 o MUST include the CDNI Logging File identified by the request URI 2042 inside the body of the HTTP response; 2044 o MUST support exchange of CDNI Logging Files with no content 2045 encoding applied to the representation; 2047 o MUST support exchange of CDNI Logging Files with "gzip" content 2048 encoding (as defined in [RFC7231]) applied to the representation. 2050 Content negotiation approaches defined in [RFC7231] (e.g., using 2051 Accept-Encoding request-header field or Content-Encoding entity- 2052 header field) MAY be used by the client-side and server-side 2053 implementations to establish the content-coding to be used for a 2054 particular exchange of a CDNI Logging File. 2056 Applying compression content encoding (such as "gzip") is expected to 2057 mitigate the impact of exchanging the large volumes of logging 2058 information expected across CDNs. This is expected to be 2059 particularly useful in the presence of HTTP Adaptive Streaming (HAS) 2060 which, as per the present version of the document, will result in a 2061 separate CDNI Log Record for each HAS segment delivery in the CDNI 2062 Logging File. 2064 The potential retention limits (e.g., sliding time window, maximum 2065 aggregate file storage quotas) within which the dCDN is to retain and 2066 be ready to serve a CDNI Logging File previously advertised in the 2067 CDNI Logging Feed is outside the scope of the present document and is 2068 expected to be agreed upon by uCDN and dCDN via other means (e.g., 2069 human agreement). The server-side implementation MUST retain, and be 2070 ready to serve, any CDNI Logging File within the agreed retention 2071 limits. Outside these agreed limits, the server-side implementation 2072 MAY indicate its inability to serve (e.g., with HTTP status code 404) 2073 a CDNI Logging File or MAY refuse to serve it (e.g., with HTTP status 2074 code 403 or 410). 2076 5. Protocol for Exchange of CDNI Logging File During Collection 2078 We note that, in addition to the CDNI Logging File exchange protocol 2079 specified in Section 4, implementations of the CDNI Logging interface 2080 may also support other mechanisms to exchange CDNI Logging Files. In 2081 particular, such mechanisms might allow the exchange of the CDNI 2082 Logging File to start before the file is fully collected. This can 2083 allow CDNI Logging Records to be communicated by the dCDN to the uCDN 2084 as they are gathered by the dCDN without having to wait until all the 2085 CDNI Logging Records of the same logging period are collected in the 2086 corresponding CDNI Logging File. This approach is commonly referred 2087 to as "tailing" of the file. 2089 Such an approach could be used, for example, to exchange logging 2090 information with a significantly reduced time-lag (e.g., sub-minute 2091 or sub-second) between when the event occurred in the dCDN and when 2092 the corresponding CDNI Logging Record is made available to the uCDN. 2093 This can satisfy log-consuming applications requiring extremely fresh 2094 logging information such as near-real-time content delivery 2095 monitoring. Such mechanisms are for further study and outside the 2096 scope of this document. 2098 6. IANA Considerations 2100 When IANA allocates new extensions to CDNI Logging Directive Names 2101 Registry, CDNI Logging File version Registry, CDNI Logging record- 2102 type Registry or CDNI Logging fields Registry, IANA MUST take into 2103 account that the directive names are case-insensitive as per the 2104 basic ABNF([RFC5234]). 2106 6.1. CDNI Logging Directive Names Registry 2108 The IANA is requested to create a new "CDNI Logging Directive Names" 2109 registry under the "Content Delivery Networks Interconnection (CDNI) 2110 Parameters" category. 2112 The initial contents of the CDNI Logging Directives registry comprise 2113 the names of the directives specified in Section 3.3 of the present 2114 document, and are as follows: 2116 +------------------------------+-----------+ 2117 | Directive Name | Reference | 2118 +------------------------------+-----------+ 2119 | version | RFC xxxx | 2120 | UUID | RFC xxxx | 2121 | claimed-origin | RFC xxxx | 2122 | established-origin | RFC xxxx | 2123 | remark | RFC xxxx | 2124 | record-type | RFC xxxx | 2125 | fields | RFC xxxx | 2126 | SHA256-hash | RFC xxxx | 2127 +------------------------------+-----------+ 2129 Figure 8 2131 [Instructions to IANA: Replace "RFC xxxx" above by the RFC number of 2132 the present document] 2134 Within the registry, names are to be allocated by IANA according to 2135 the "Specification Required" policy specified in [RFC5226]. 2136 Directive names are to be allocated by IANA with a format of 2137 NAMEFORMAT (see Section 3.1). All directive names and field names 2138 defined in the logging file are case-insensitive as per the basic 2139 ABNF([RFC5234]). 2141 Each specification that defines a new CDNI Logging directive needs to 2142 contain a description for the new directive with the same set of 2143 information as provided in Section 3.3 (i.e., format, directive value 2144 and occurrence). 2146 6.2. CDNI Logging File version Registry 2148 The IANA is requested to create a new "CDNI Logging File version" 2149 registry under the "Content Delivery Networks Interconnection (CDNI) 2150 Parameters" category. 2152 The initial contents of the CDNI Logging Logging File version 2153 registry comprise the value "CDNI/1.0" specified in Section 3.3 of 2154 the present document, and are as follows: 2156 +-----------------+-----------+----------------------------------+ 2157 | version | Reference | Description | 2158 +-----------------+-----------+----------------------------------+ 2159 | cdni/1.0 | RFC xxxx | CDNI Logging File version 1.0 | 2160 | | | as specified in RFC xxxx | 2161 +-----------------+-----------+----------------------------------+ 2163 Figure 9 2165 [Instructions to IANA: Replace "RFC xxxx" above by the RFC number of 2166 the present document] 2168 Within the registry, version values are to be allocated by IANA 2169 according to the "Specification Required" policy specified in 2170 [RFC5226]. Version values are to be allocated by IANA with a format 2171 of NAMEFORMAT (see Section 3.1). 2173 6.3. CDNI Logging record-types Registry 2175 The IANA is requested to create a new "CDNI Logging record-types" 2176 under the "Content Delivery Networks Interconnection (CDNI) 2177 Parameters" category. 2179 The initial contents of the CDNI Logging record-types registry 2180 comprise the names of the CDNI Logging Record types specified in 2181 Section 3.4 of the present document, and are as follows: 2183 +----------------------+-----------+---------------------------------+ 2184 | record-types | Reference | Description | 2185 +----------------------+-----------+---------------------------------+ 2186 | cdni_http_request_v1 | RFC xxxx | CDNI Logging Record version 1 | 2187 | | | for content delivery using HTTP | 2188 +----------------------+-----------+---------------------------------+ 2190 Figure 10 2192 [Instructions to IANA: Replace "RFC xxxx" above by the RFC number of 2193 the present document] 2194 Within the registry, record-types are to be allocated by IANA 2195 according to the "Specification Required" policy specified in 2196 [RFC5226]. record-types are to be allocated by IANA with a format of 2197 NAMEFORMAT (see Section 3.1). 2199 Each specification that defines a new record-type needs to contain a 2200 description for the new record-type with the same set of information 2201 as provided in Section 3.4.1. This includes: 2203 o a list of all the CDNI Logging fields that can appear in a CDNI 2204 Logging Record of the new record-type 2206 o for all these fields: a specification of the occurrence for each 2207 Field in the new record-type 2209 o for every newly defined Field, i.e., for every Field that results 2210 in a registration in the CDNI Logging Field Names Registry 2211 (Section 6.4): a specification of the field name, format and field 2212 value. 2214 6.4. CDNI Logging Field Names Registry 2216 The IANA is requested to create a new "CDNI Logging Field Names" 2217 under the "Content Delivery Networks Interconnection (CDNI) 2218 Parameters" category. 2220 This registry is intended to be shared across the currently defined 2221 record-type (i.e., cdni_http_request_v1) as well as potential other 2222 CDNI Logging record-types that may be defined in separate 2223 specifications. When a Field from this registry is used by another 2224 CDNI Logging record-type, it is to be used with the exact semantics 2225 and format specified in the document that registered this field and 2226 that is identified in the Reference column of the registry. If 2227 another CDNI Logging record-type requires a Field with semantics that 2228 are not strictly identical, or a format that is not strictly 2229 identical then this new Field is to be registered in the registry 2230 with a different Field name. When a Field from this registry is used 2231 by another CDNI Logging record-type, it can be used with different 2232 occurrence rules. 2234 The initial contents of the CDNI Logging fields Names registry 2235 comprise the names of the CDNI Logging fields specified in 2236 Section 3.4 of the present document, and are as follows: 2238 +------------------------------------------+-----------+ 2239 | Field Name | Reference | 2240 +------------------------------------------+-----------+ 2241 | date | RFC xxxx | 2242 | time | RFC xxxx | 2243 | time-taken | RFC xxxx | 2244 | c-groupid | RFC xxxx | 2245 | s-ip | RFC xxxx | 2246 | s-hostname | RFC xxxx | 2247 | s-port | RFC xxxx | 2248 | cs-method | RFC xxxx | 2249 | cs-uri | RFC xxxx | 2250 | u-uri | RFC xxxx | 2251 | protocol | RFC xxxx | 2252 | sc-status | RFC xxxx | 2253 | sc-total-bytes | RFC xxxx | 2254 | sc-entity-bytes | RFC xxxx | 2255 | cs(insert_HTTP_header_name_here) | RFC xxxx | 2256 | sc(insert_HTTP_header_name_here) | RFC xxxx | 2257 | s-ccid | RFC xxxx | 2258 | s-sid | RFC xxxx | 2259 | s-cached | RFC xxxx | 2260 +------------------------------------------+-----------+ 2262 Figure 11 2264 [Instructions to IANA: Replace "RFC xxxx" above by the RFC number of 2265 the present document] 2267 Within the registry, names are to be allocated by IANA according to 2268 the "Specification Required" policy specified in [RFC5226]. Field 2269 names are to be allocated by IANA with a format of NHTABSTRING (see 2270 Section 3.1). 2272 6.5. CDNI Logging MIME Media Type 2274 The IANA is requested to register the following new Payload Type in 2275 the CDNI Payload Type registry for use with the application/cdni MIME 2276 media type. 2278 [RFC Editor Note: Please replace the references to [RFCthis] below 2279 with this document's RFC number before publication.] 2280 +----------------------+---------------+ 2281 | Payload Type | Specification | 2282 +----------------------+---------------+ 2283 | logging-file | [RFCthis] | 2284 +----------------------+---------------+ 2286 Figure 12: MIME Media Type payload 2288 The purpose of the logging-file payload type is to distinguish 2289 between CDNI Logging Files and other CDNI messages. 2291 Interface: LI 2293 Encoding: see Section 3.2, Section 3.3 and Section 3.4 2295 7. Security Considerations 2297 7.1. Authentication, Authorization, Confidentiality, Integrity 2298 Protection 2300 An implementation of the CDNI Logging interface MUST support TLS 2301 transport of the CDNI Logging feed (Section 4.1) and of the CDNI 2302 Logging File pull (Section 4.2) as per [RFC2818] and [RFC7230]. 2304 The use of TLS for transport of the CDNI Logging feed and CDNI 2305 Logging File pull allows: 2307 o the dCDN and uCDN to authenticate each other 2309 and, once they have mutually authenticated each other, it allows: 2311 o the dCDN and uCDN to authorize each other (to ensure they are 2312 transmitting/receiving CDNI Logging File to/from an authorized 2313 CDN) 2315 o the CDNI Logging information to be transmitted with 2316 confidentiality 2318 o the integrity of the CDNI Logging information to be protected 2319 during the exchange. 2321 In an environment where any such protection is required, mutually 2322 authenticated encrypted transport MUST be used to ensure 2323 confidentiality of the logging information. To that end, TLS MUST be 2324 used (including authentication of the remote end) by the server-side 2325 and the client-side of the CDNI Logging feed, as well as the server- 2326 side and the client-side of the CDNI Logging File pull mechanism. 2328 When TLS is used, the general TLS usage guidance in [RFC7525] MUST be 2329 followed. 2331 The SHA256-hash directive inside the CDNI Logging File provides 2332 additional integrity protection, this time targeting potential 2333 corruption of the CDNI logging information during the CDNI Logging 2334 File generation, storage or exchange. This mechanism does not itself 2335 allow restoration of the corrupted CDNI Logging information, but it 2336 allows detection of such corruption and therefore triggering of 2337 appropriate corrective actions (e.g., discard of corrupted 2338 information, attempt to re-obtain the CDNI Logging information). 2339 Note that the SHA256-hash does not protect against tampering by a 2340 third party, since such a third party could have recomputed and 2341 updated the SHA256-hash after tampering. Protection against third 2342 party tampering can be achieved as discussed above through the use of 2343 TLS. 2345 7.2. Denial of Service 2347 This document does not define specific mechanism to protect against 2348 Denial of Service (DoS) attacks on the Logging Interface. However, 2349 the CDNI Logging feed and CDNI Logging pull endpoints are typically 2350 to be accessed only by a very small number of valid remote endpoints 2351 and therefore can be easily protected against DoS attacks through the 2352 usual conventional DOS protection mechanisms such as firewalling or 2353 use of Virtual Private Networks (VPNs). 2355 Protection of dCDN Surrogates against spoofed delivery requests is 2356 outside the scope of the CDNI Logging interface. 2358 7.3. Privacy 2360 CDNs have the opportunity to collect detailed information about the 2361 downloads performed by End Users. A dCDN is expected to collect such 2362 information into CDNI Logging Files, which are then communicated to 2363 an uCDN. 2365 Having detailed CDNI logging information known by the dCDN in itself 2366 does not represent a particular privacy concern since the dCDN is 2367 obviously fully aware of all information logged since it generated 2368 the information in the first place. Making detailed CDNI logging 2369 information known to the uCDN does not represent a particular privacy 2370 concern because the uCDN is already exposed at request redirection 2371 time to most of the information that shows up as CDNI logging 2372 information (e.g., enduser IP@, URL, HTTP headers - at least when 2373 HTTP redirection is used between uCDN and dCDN). Transporting 2374 detailed CDNI logging information over the HTTP based CDNI Logging 2375 Interface does not represent a particular privacy concern because it 2376 is protected by usual IETF privacy-protection mechanism (e.g.,TLS). 2378 However, one privacy concern arises from the fact that large volumes 2379 of detailed information about content delivery to users, potentially 2380 traceable back to indvidual users, may be collected in CDNI Logging 2381 files. These CDNI Logging files represent high-value targets, likely 2382 concentrated in a fairly centralised system (although the CDNI 2383 Logging architecture does not mandate a particular level of 2384 centralisation/distribution) and at risk of potential data 2385 exfiltration. Note that the means of such data exfiltration are 2386 beyond the scope of the CDNI Logging interface itself (e.g., 2387 corrupted employee, corrupted logging storage system,...). This 2388 privacy concern calls for some protection. 2390 The collection of large volumes of such information into CDNI Logging 2391 Files introduces potential End Users privacy protection concerns. 2392 Mechanisms to address these concerns are discussed in the definition 2393 of the c-groupid field specified in Section 3.4.1. 2395 The use of mutually authenticated TLS to establish a secure session 2396 for the transport of the CDNI Logging feed and CDNI Logging pull as 2397 discussed in Section 7.1 provides confidentiality while the logging 2398 information is in transit and prevents any party other than the 2399 authorised uCDN to gain access to the logging information. 2401 We also note that the query string portion of the URL that may be 2402 conveyed inside the cs-uri and u-uri fields of CDNI Logging Files, or 2403 the HTTP cookies( [RFC6265]) that may be conveyed as part of the 2404 cs() field of CDNI Logging files, may contain 2405 personnal information or information that can be exploited to derive 2406 personal information. Where this is a concern, the CDNI Logging 2407 interface specification allows the dCDN to not include the cs-uri and 2408 to include a u-uri that removes (or hides) the sensitive part of the 2409 query string and allows the dCDN to not include the cs() fields corresponding to HTTP headers associated with cookies. 2412 8. Acknowledgments 2414 This document borrows from the W3C Extended Log Format [ELF]. 2416 Rob Murray significantly contributed into the text of Section 4.1. 2418 The authors thank Ben Niven-Jenkins, Kevin Ma, David Mandelberg and 2419 Ray van Brandenburg for their ongoing input. 2421 Brian Trammel and Rich Salz made significant contributions into 2422 making this interface privacy-friendly. 2424 Finally, we also thank Sebastien Cubaud, Pawel Grochocki, Christian 2425 Jacquenet, Yannick Le Louedec, Anne Marrec, Emile Stephan, Fabio 2426 Costa, Sara Oueslati, Yvan Massot, Renaud Edel, Joel Favier and the 2427 contributors of the EU FP7 OCEAN project for their input in the early 2428 versions of this document. 2430 9. References 2432 9.1. Normative References 2434 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2435 Requirement Levels", BCP 14, RFC 2119, 2436 DOI 10.17487/RFC2119, March 1997, 2437 . 2439 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 2440 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 2441 . 2443 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2444 Resource Identifier (URI): Generic Syntax", STD 66, 2445 RFC 3986, DOI 10.17487/RFC3986, January 2005, 2446 . 2448 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 2449 Unique IDentifier (UUID) URN Namespace", RFC 4122, 2450 DOI 10.17487/RFC4122, July 2005, 2451 . 2453 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom 2454 Syndication Format", RFC 4287, DOI 10.17487/RFC4287, 2455 December 2005, . 2457 [RFC5005] Nottingham, M., "Feed Paging and Archiving", RFC 5005, 2458 DOI 10.17487/RFC5005, September 2007, 2459 . 2461 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2462 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2463 DOI 10.17487/RFC5226, May 2008, 2464 . 2466 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2467 Specifications: ABNF", STD 68, RFC 5234, 2468 DOI 10.17487/RFC5234, January 2008, 2469 . 2471 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2472 Protocol (HTTP/1.1): Message Syntax and Routing", 2473 RFC 7230, DOI 10.17487/RFC7230, June 2014, 2474 . 2476 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2477 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 2478 DOI 10.17487/RFC7231, June 2014, 2479 . 2481 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2482 Protocol (HTTP/1.1): Conditional Requests", RFC 7232, 2483 DOI 10.17487/RFC7232, June 2014, 2484 . 2486 [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., 2487 "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", 2488 RFC 7233, DOI 10.17487/RFC7233, June 2014, 2489 . 2491 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 2492 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 2493 RFC 7234, DOI 10.17487/RFC7234, June 2014, 2494 . 2496 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2497 Protocol (HTTP/1.1): Authentication", RFC 7235, 2498 DOI 10.17487/RFC7235, June 2014, 2499 . 2501 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 2502 "Recommendations for Secure Use of Transport Layer 2503 Security (TLS) and Datagram Transport Layer Security 2504 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2505 2015, . 2507 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 2508 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 2509 DOI 10.17487/RFC7540, May 2015, 2510 . 2512 9.2. Informative References 2514 [CHAR_SET] 2515 "IANA Character Sets registry", 2516 . 2519 [ELF] Phillip M. Hallam-Baker, and Brian Behlendorf, "Extended 2520 Log File Format, W3C (work in progress), WD-logfile- 2521 960323", . 2523 [I-D.ietf-cdni-metadata] 2524 Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 2525 "CDN Interconnection Metadata", draft-ietf-cdni- 2526 metadata-12 (work in progress), October 2015. 2528 [I-D.ietf-tls-rfc5246-bis] 2529 Dierks, T. and E. Rescorla, "The Transport Layer Security 2530 (TLS) Protocol Version 1.3", draft-ietf-tls-rfc5246-bis-00 2531 (work in progress), April 2014. 2533 [I-D.snell-atompub-link-extensions] 2534 Snell, J., "Atom Link Extensions", draft-snell-atompub- 2535 link-extensions-09 (work in progress), June 2012. 2537 [RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext 2538 Transfer Protocol -- HTTP/1.0", RFC 1945, 2539 DOI 10.17487/RFC1945, May 1996, 2540 . 2542 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 2543 DOI 10.17487/RFC2818, May 2000, 2544 . 2546 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 2547 Key Derivation Function (HKDF)", RFC 5869, 2548 DOI 10.17487/RFC5869, May 2010, 2549 . 2551 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 2552 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 2553 DOI 10.17487/RFC6234, May 2011, 2554 . 2556 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 2557 DOI 10.17487/RFC6265, April 2011, 2558 . 2560 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 2561 Distribution Network Interconnection (CDNI) Problem 2562 Statement", RFC 6707, DOI 10.17487/RFC6707, September 2563 2012, . 2565 [RFC6770] Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley, 2566 P., Ma, K., and G. Watson, "Use Cases for Content Delivery 2567 Network Interconnection", RFC 6770, DOI 10.17487/RFC6770, 2568 November 2012, . 2570 [RFC6983] van Brandenburg, R., van Deventer, O., Le Faucheur, F., 2571 and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware 2572 Content Distribution Network Interconnection (CDNI)", 2573 RFC 6983, DOI 10.17487/RFC6983, July 2013, 2574 . 2576 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 2577 "Framework for Content Distribution Network 2578 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 2579 August 2014, . 2581 [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution 2582 Network Interconnection (CDNI) Requirements", RFC 7337, 2583 DOI 10.17487/RFC7337, August 2014, 2584 . 2586 [RFC7736] Ma, K., "Content Delivery Network Interconnection (CDNI) 2587 Media Type Registration", RFC 7736, DOI 10.17487/RFC7736, 2588 December 2015, . 2590 Authors' Addresses 2592 Francois Le Faucheur (editor) 2593 Cisco Systems 2594 E.Space Park - Batiment D 2595 6254 Allee des Ormes - BP 1200 2596 Mougins cedex 06254 2597 FR 2599 Phone: +33 4 97 23 26 19 2600 Email: flefauch@cisco.com 2602 Gilles Bertrand (editor) 2603 Orange 2604 38-40 rue du General Leclerc 2605 Issy les Moulineaux 92130 2606 FR 2608 Phone: +33 1 45 29 89 46 2609 Email: gilles.bertrand@orange.com 2610 Iuniana Oprescu (editor) 2611 Orange 2612 38-40 rue du General Leclerc 2613 Issy les Moulineaux 92130 2614 FR 2616 Phone: +33 6 89 06 92 72 2617 Email: iuniana.oprescu@orange.com 2619 Roy Peterkofsky 2620 Skytide, Inc. 2621 One Kaiser Plaza, Suite 785 2622 Oakland CA 94612 2623 USA 2625 Phone: +01 510 250 4284 2626 Email: roy@skytide.com