idnits 2.17.1 draft-ietf-cdni-logging-11.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 25, 2014) is 3685 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) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-14) exists of draft-ietf-cdni-framework-10 == Outdated reference: A later version (-21) exists of draft-ietf-cdni-metadata-06 == Outdated reference: A later version (-17) exists of draft-ietf-httpbis-http2-10 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 2 errors (**), 0 flaws (~~), 4 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 26, 2014 I. Oprescu, Ed. 6 Orange 7 R. Peterkofsky 8 Skytide, Inc. 9 March 25, 2014 11 CDNI Logging Interface 12 draft-ietf-cdni-logging-11 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 26, 2014. 40 Copyright Notice 42 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . 12 70 2.2.5.3. Analytics and Reporting . . . . . . . . . . . . . 12 71 2.2.5.4. Security . . . . . . . . . . . . . . . . . . . . 13 72 2.2.5.5. Legal Logging Duties . . . . . . . . . . . . . . 13 73 2.2.5.6. Notions common to multiple Log Consuming 74 Applications . . . . . . . . . . . . . . . . . . 13 75 3. CDNI Logging File . . . . . . . . . . . . . . . . . . . . . . 15 76 3.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 3.2. CDNI Logging File Structure . . . . . . . . . . . . . . . 16 78 3.3. CDNI Logging File Directives . . . . . . . . . . . . . . 19 79 3.4. CDNI Logging Records . . . . . . . . . . . . . . . . . . 22 80 3.4.1. HTTP Request Logging Record . . . . . . . . . . . . . 23 81 3.5. CDNI Logging File Example . . . . . . . . . . . . . . . . 32 82 4. CDNI Logging File Exchange Protocol . . . . . . . . . . . . . 32 83 4.1. CDNI Logging Feed . . . . . . . . . . . . . . . . . . . . 33 84 4.1.1. Atom Formatting . . . . . . . . . . . . . . . . . . . 33 85 4.1.2. Updates to Log Files and the Feed . . . . . . . . . . 34 86 4.1.3. Redundant Feeds . . . . . . . . . . . . . . . . . . . 34 87 4.1.4. Example CDNI Logging Feed . . . . . . . . . . . . . . 35 88 4.2. CDNI Logging File Pull . . . . . . . . . . . . . . . . . 37 89 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 90 5.1. CDNI Logging Directive Names Registry . . . . . . . . . . 38 91 5.2. CDNI Logging Record-Types Registry . . . . . . . . . . . 39 92 5.3. CDNI Logging Field Names Registry . . . . . . . . . . . . 40 93 5.4. CDNI Logging MIME Media Type . . . . . . . . . . . . . . 41 94 6. Security Considerations . . . . . . . . . . . . . . . . . . . 41 95 6.1. Authentication, Confidentiality, Integrity Protection . . 41 96 6.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 42 97 6.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 42 98 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43 99 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 100 8.1. Normative References . . . . . . . . . . . . . . . . . . 44 101 8.2. Informative References . . . . . . . . . . . . . . . . . 44 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 104 1. Introduction 106 This memo specifies the CDNI Logging interface between a downstream 107 CDN (dCDN) and an upstream CDN (uCDN). First, it describes a 108 reference model for CDNI logging. Then, it specifies the CDNI 109 Logging File format and the actual protocol for exchange of CDNI 110 Logging Files. 112 The reader should be familiar with the following documents: 114 o CDNI problem statement [RFC6707] and framework 115 [I-D.ietf-cdni-framework] identify a Logging interface, 117 o Section 8 of [I-D.ietf-cdni-requirements] specifies a set of 118 requirements for Logging, 120 o [RFC6770] outlines real world use-cases for interconnecting CDNs. 121 These use cases require the exchange of Logging information 122 between the dCDN and the uCDN. 124 As stated in [RFC6707], "the CDNI Logging interface enables details 125 of logs or events to be exchanged between interconnected CDNs". 127 The present document describes: 129 o The CDNI Logging reference model (Section 2), 131 o The CDNI Logging File format (Section 3), 133 o The CDNI Logging File Exchange protocol (Section 4). 135 1.1. Terminology 137 In this document, the first letter of each CDNI-specific term is 138 capitalized. We adopt the terminology described in [RFC6707] and 139 [I-D.ietf-cdni-framework], and extend it with the additional terms 140 defined below. 142 Intra-CDN Logging information: logging information generated and 143 collected within a CDN. The format of the Intra-CDN Logging 144 information may be different to the format of the CDNI Logging 145 information. 147 CDNI Logging information: logging information exchanged across CDNs 148 using the CDNI Logging Interface. 150 Logging information: logging information generated and collected 151 within a CDN or obtained from another CDN using the CDNI Logging 152 Interface. 154 CDNI Logging Field: an atomic element of information that can be 155 included in a CDNI Logging Record. The time an event/task started, 156 the IP address of an End User to whom content was delivered, and the 157 URI of the content delivered are examples of CDNI Logging Fields. 159 CDNI Logging Record: an information record providing information 160 about a specific event. This comprises a collection of CDNI Logging 161 Fields. 163 CDNI Logging File: a file containing CDNI Logging Records, as well as 164 additional information facilitating the processing of the CDNI 165 Logging Records. 167 CDN Reporting: the process of providing the relevant information that 168 will be used to create a formatted content delivery report provided 169 to the CSP in deferred time. Such information typically includes 170 aggregated data that can cover a large period of time (e.g., from 171 hours to several months). Uses of Reporting include the collection 172 of charging data related to CDN services and the computation of Key 173 Performance Indicators (KPIs). 175 CDN Monitoring: the process of providing or displaying content 176 delivery information in a timely fashion with respect to the 177 corresponding deliveries. Monitoring typically includes visibility 178 of the deliveries in progress for service operation purposes. It 179 presents a view of the global health of the services as well as 180 information on usage and performance, for network services 181 supervision and operation management. In particular, monitoring data 182 can be used to generate alarms. 184 1.2. Requirements Language 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 188 document are to be interpreted as described in RFC 2119 [RFC2119]. 190 2. CDNI Logging Reference Model 192 2.1. CDNI Logging interactions 194 The CDNI logging reference model between a given uCDN and a given 195 dCDN involves the following interactions: 197 o customization by the uCDN of the CDNI Logging information to be 198 provided by the dCDN to the uCDN (e.g., control of which CDNI 199 Logging Fields are to be communicated to the uCDN for a given task 200 performed by the dCDN or control of which types of events are to 201 be logged). The dCDN takes into account this CDNI Logging 202 customization information to determine what Logging information to 203 provide to the uCDN, but it may, or may not, take into account 204 this CDNI Logging customization information to influence what CDN 205 logging information is to be generated and collected within the 206 dCDN (e.g., even if the uCDN requests a restricted subset of the 207 logging information, the dCDN may elect to generate a broader set 208 of logging information). The mechanism to support the 209 customization by the uCDN of CDNI Logging information is outside 210 the scope of this document and left for further study. Until such 211 a mechanism is available, the uCDN and dCDN are expected to agree 212 off-line on what exact set of CDNI Logging information is to be 213 provided by the dCDN to the uCDN, and to rely on management plane 214 actions to configure the CDNI Logging functions in the dCDN to 215 generate this information set and in the uCDN to expect this 216 information set. 218 o generation and collection by the dCDN of the intra-CDN Logging 219 information related to the completion of any task performed by the 220 dCDN on behalf of the uCDN (e.g., delivery of the content to an 221 End User) or related to events happening in the dCDN that are 222 relevant to the uCDN (e.g., failures or unavailability in dCDN). 223 This takes place within the dCDN and does not directly involve 224 CDNI interfaces. 226 o communication by the dCDN to the uCDN of the Logging information 227 collected by the dCDN relevant to the uCDN. This is supported by 228 the CDNI Logging interface and in the scope of the present 229 document. For example, the uCDN may use this Logging information 230 to charge the CSP, to perform analytics and monitoring for 231 operational reasons, to provide analytics and monitoring views on 232 its content delivery to the CSP or to perform trouble-shooting. 233 This document exclusively specifies non-real-time exchange of 234 Logging information. Closer to real-time exchange of Logging 235 information (say sub-minute or sub-second) is outside the scope of 236 the present document and left for further study. This document 237 exclusively specifies exchange of Logging information related to 238 content delivery. Exchange of Logging information related to 239 operational events (e.g., dCDN request routing function 240 unavailable, content acquisition failure by dCDN) for audit or 241 operational reactive adjustments by uCDN is outside the scope of 242 the present document and left for further study. 244 o customization by the dCDN of the CDNI Logging information to be 245 provided by the uCDN on behalf of the dCDN. The mechanism to 246 support the customization by the dCDN of CDNI Logging information 247 is outside the scope of this document and left for further study. 249 o generation and collection by the uCDN of Intra-CDN Logging 250 information related to the completion of any task performed by the 251 uCDN on behalf of the dCDN (e.g., serving of content by uCDN to 252 dCDN for acquisition purposes by dCDN) or related to events 253 happening in the uCDN that are relevant to the dCDN. This takes 254 place within the uCDN and does not directly involve CDNI 255 interfaces. 257 o communication by the uCDN to the dCDN of the Logging information 258 collected by the uCDN relevant to the dCDN. For example, the dCDN 259 might potentially benefit from this information for security 260 auditing or content acquisition troubleshooting. This is outside 261 the scope of this document and left for further study. 263 Figure 1 provides an example of CDNI Logging interactions (focusing 264 only on the interactions that are in the scope of this document) in a 265 particular scenario where four CDNs are involved in the delivery of 266 content from a given CSP: the uCDN has a CDNI interconnection with 267 dCDN-1 and dCDN-2. In turn, dCDN2 has a CDNI interconnection with 268 dCDN3. In this example, uCDN, dCDN-1, dCDN-2 and dCDN-3 all 269 participate in the delivery of content for the CSP. In this example, 270 the CDNI Logging interface enables the uCDN to obtain Logging 271 information from all the dCDNs involved in the delivery. In the 272 example, the uCDN uses the Logging information: 274 o to analyze the performance of the delivery performed by the dCDNs 275 and to adjust its operations after the fact (e.g., request 276 routing) as appropriate, 278 o to provide (non-real-time) reporting and monitoring information to 279 the CSP. 281 For instance, the uCDN merges Logging information, extracts relevant 282 KPIs, and presents a formatted report to the CSP, in addition to a 283 bill for the content delivered by uCDN itself or by its dCDNs on the 284 CSP's behalf. The uCDN may also provide Logging information as raw 285 log files to the CSP, so that the CSP can use its own logging 286 analysis tools. 288 +-----+ 289 | CSP | 290 +-----+ 291 ^ Reporting and monitoring data 292 * Billing 293 ,--*--. 294 Logging ,-' `-. 295 Data =>( uCDN )<= Logging 296 // `-. _,-' \\ Data 297 || `-'-'-' || 298 ,-----. ,-----. 299 ,-' `-. ,-' `-. 300 ( dCDN-1 ) ( dCDN-2 )<== Logging 301 `-. ,-' `-. _,-' \\ Data 302 `--'--' `--'-' || 303 ,-----. 304 ,' `-. 305 ( dCDN-3 ) 306 `. ,-' 307 `--'--' 309 ===> CDNI Logging Interface 310 ***> outside the scope of CDNI 312 Figure 1: Interactions in CDNI Logging Reference Model 314 A dCDN (e.g., dCDN-2) integrates the relevant Logging information 315 obtained from its dCDNs (i.e., dCDN-3) in the Logging information 316 that it provides to the uCDN, so that the uCDN ultimately obtains all 317 Logging information relevant to a CSP for which it acts as the 318 authoritative CDN. 320 Note that the format of Logging information that a CDN provides over 321 the CDNI interface might be different from the one that the CDN uses 322 internally. In this case, the CDN needs to reformat the Logging 323 information before it provides this information to the other CDN over 324 the CDNI Logging interface. Similarly, a CDN might reformat the 325 Logging information that it receives over the CDNI Logging interface 326 before injecting it into its log-consuming applications or before 327 providing some of this Logging information to the CSP. Such 328 reformatting operations introduce latency in the logging distribution 329 chain and introduce a processing burden. Therefore, there are 330 benefits in specifying CDNI Logging formats that are suitable for use 331 inside CDNs and also are close to the intra-CDN Logging formats 332 commonly used in CDNs today. 334 2.2. Overall Logging Chain 336 This section discusses the overall logging chain within and across 337 CDNs to clarify how CDN Logging information is expected to fit in 338 this overall chain. Figure 2 illustrates the overall logging chain 339 within the dCDN, across CDNs using the CDNI Logging interface and 340 within the uCDN. Note that the logging chain illustrated in the 341 Figure is obviously only an example and varies depending on the 342 specific environments. For example, there may be more or fewer 343 instantiations of each entity (e.g., there may be 4 Log consuming 344 applications in a given CDN). As another example, there may be one 345 instance of Rectification process per Log Consuming Application 346 instead of a shared one. 348 Log Consuming Log Consuming 349 App App 350 ^ ^ 351 | | 352 Rectification---------- 353 ^ 354 | 355 Filtering 356 ^ 357 | 358 Collection 359 ^ ^ 360 | | 361 | Generation 362 | 363 | uCDN 364 CDNI Logging ------------------------------------------------------- 365 exchange dCDN 366 ^ 367 | Log Consuming Log Consuming 368 | App App 369 | ^ ^ 370 | | | 371 Rectification Rectification--------- 372 ^ ^ 373 | | 374 Filtering 375 ^ 376 | 377 Collection 378 ^ ^ 379 | | 380 Generation Generation 382 Figure 2: CDNI Logging in the overall Logging Chain 384 The following subsections describe each of the processes potentially 385 involved in the logging chain of Figure 2. 387 2.2.1. Logging Generation and During-Generation Aggregation 389 CDNs typically generate Logging information for all significant task 390 completions, events, and failures. Logging information is typically 391 generated by many devices in the CDN including the surrogates, the 392 request routing system, and the control system. 394 The amount of Logging information generated can be huge. Therefore, 395 during contract negotiations, interconnected CDNs often agree on a 396 retention duration for Logging information, and/or potentially on a 397 maximum volume of Logging information that the dCDN must keep. If 398 this volume is exceeded, the dCDN is expected to alert the uCDN but 399 may not keep more Logging information for the considered time period. 400 In addition, CDNs may aggregate Logging information and transmit only 401 summaries for some categories of operations instead of the full 402 Logging information. Note that such aggregation leads to an 403 information loss, which may be problematic for some usages of the 404 Logging information (e.g., debugging). 406 [RFC6983] discusses logging for HTTP Adaptive Streaming (HAS). In 407 accordance with the recommendations articulated there, it is expected 408 that a surrogate will generate separate Logging information for 409 delivery of each chunk of HAS content. This ensures that separate 410 Logging information can then be provided to interconnected CDNs over 411 the CDNI Logging interface. Still in line with the recommendations 412 of [RFC6983], the Logging information for per-chunck delivery may 413 include some information (a Content Collection IDentifier and a 414 Session IDentifier) intended to facilitate subsequent post-generation 415 aggregation of per-chunk logs into per-session logs. Note that a CDN 416 may also elect to generate aggregate per-session logs when performing 417 HAS delivery, but this needs to be in addition to, and not instead 418 of, the per-chunk delivery logs. We note that aggregate per-session 419 logs for HAS delivery are for further study and outside the scope of 420 this document. 422 2.2.2. Logging Collection 424 This is the process that continuously collects Logging information 425 generated by the log-generating entities within a CDN. 427 In a CDNI environment, in addition to collecting Logging information 428 from log-generating entities within the local CDN, the Collection 429 process also collects Logging information provided by another CDN, or 430 other CDNs, through the CDNI Logging interface. This is illustrated 431 in Figure 2 where we see that the Collection process of the uCDN 432 collects Logging information from log-generating entities within the 433 uCDN as well as Logging information coming from the dCDNs through the 434 CDNI Logging interface. 436 2.2.3. Logging Filtering 438 A CDN may be required to only present different subsets of the whole 439 Logging information collected to various log-consuming applications. 440 This is achieved by the Filtering process. 442 In particular, the Filtering process can also filter the right subset 443 of Logging information that needs to be provided to a given 444 interconnected CDN. For example, the filtering process in the dCDN 445 can be used to ensure that only the Logging information related to 446 tasks performed on behalf of a given uCDN are made available to that 447 uCDN (thereby filtering out all the Logging information related to 448 deliveries by the dCDN of content for its own CSPs). Similarly, the 449 Filtering process may filter or partially mask some fields, for 450 example, to protect End Users' privacy when communicating CDNI 451 Logging information to another CDN. Filtering of Logging information 452 prior to communication of this information to other CDNs via the CDNI 453 Logging interface requires that the downstream CDN can recognize the 454 subset of Logging information that relate to each interconnected CDN. 456 The CDN will also filter some internal scope information such as 457 information related to its internal alarms (security, failures, load, 458 etc). 460 In some use cases described in [RFC6770], the interconnected CDNs do 461 not want to disclose details on their internal topology. The 462 filtering process can then also filter confidential data on the 463 dCDNs' topology (number of servers, location, etc.). In particular, 464 information about the requests served by each Surrogate may be 465 confidential. Therefore, the Logging information must be protected 466 so that data such as Surrogates' hostnames are not disclosed to the 467 uCDN. In the "Inter-Affiliates Interconnection" use case, this 468 information may be disclosed to the uCDN because both the dCDN and 469 the uCDN are operated by entities of the same group. 471 2.2.4. Logging Rectification and Post-Generation Aggregation 473 If Logging information is generated periodically, it is important 474 that the sessions that start in one Logging period and end in another 475 are correctly reported. If they are reported in the starting period, 476 then the Logging information of this period will be available only 477 after the end of the session, which delays the Logging information 478 generation. 480 A Logging rectification/update mechanism could be useful to reach a 481 good trade-off between the Logging information generation delay and 482 the Logging information accuracy. 484 In the presence of HAS, some log-consuming applications can benefit 485 from aggregate per-session logs. For example, for analytics, per- 486 session logs allow display of session-related trends which are much 487 more meaningful for some types of analysis than chunk-related trends. 488 In the case where aggregate logs have been generated directly by the 489 log-generating entities, those can be used by the applications. In 490 the case where aggregate logs have not been generated, the 491 Rectification process can be extended with a Post-Generation 492 Aggregation process that generates per-session logs from the per- 493 chunk logs, possibly leveraging the information included in the per- 494 chunk logs for that purpose (Content Collection IDentifier and a 495 Session IDentifier). However, in accordance with [RFC6983], this 496 document does not define exchange of such aggregate logs on the CDNI 497 Logging interface. We note that this is for further study and 498 outside the scope of this document.. 500 2.2.5. Log-Consuming Applications 502 2.2.5.1. Maintenance/Debugging 504 Logging information is useful to permit the detection (and limit the 505 risk) of content delivery failures. In particular, Logging 506 information facilitates the detection of configuration issues. 508 To detect faults, Logging information needs to report success and 509 failure of CDN delivery operations. The uCDN can summarize such 510 information into KPIs. For instance, Logging information needs to 511 allow the computation of the number of times, during a given time 512 period, that content delivery related to a specific service succeeds/ 513 fails. 515 Logging information enables the CDN providers to identify and 516 troubleshoot performance degradations. In particular, Logging 517 information enables tracking of traffic data (e.g., the amount of 518 traffic that has been forwarded by a dCDN on behalf of an uCDN over a 519 given period of time), which is particularly useful for CDN and 520 network planning operations. 522 2.2.5.2. Accounting 524 Logging information is essential for accounting, to permit inter-CDN 525 billing and CSP billing by uCDNs. For instance, Logging information 526 provided by dCDNs enables the uCDN to compute the total amount of 527 traffic delivered by every dCDN for a particular Content Provider, as 528 well as, the associated bandwidth usage (e.g., peak, 95th 529 percentile), and the maximum number of simultaneous sessions over a 530 given period of time. 532 2.2.5.3. Analytics and Reporting 534 The goal of analytics is to gather any relevant information to track 535 audience, analyze user behavior, and monitor the performance and 536 quality of content delivery. For instance, Logging information 537 enables the CDN providers to report on content consumption (e.g., 538 delivered sessions per content) in a specific geographic area. 540 The goal of reporting is to gather any relevant information to 541 monitor the performance and quality of content delivery and allow 542 detection of delivery issues. For instance, reporting could track 543 the average delivery throughput experienced by End Users in a given 544 region for a specific CSP or content set over a period of time. 546 2.2.5.4. Security 548 The goal of security is to prevent and monitor unauthorized access, 549 misuse, modification, and denial of access of a service. A set of 550 information is logged for security purposes. In particular, a record 551 of access to content is usually collected to permit the CSP to detect 552 infringements of content delivery policies and other abnormal End 553 User behaviors. 555 2.2.5.5. Legal Logging Duties 557 Depending on the country considered, the CDNs may have to retain 558 specific Logging information during a legal retention period, to 559 comply with judicial requisitions. 561 2.2.5.6. Notions common to multiple Log Consuming Applications 563 2.2.5.6.1. Logging Information Views 565 Within a given log-consuming application, different views may be 566 provided to different users depending on privacy, business, and 567 scalability constraints. 569 For example, an analytics tool run by the uCDN can provide one view 570 to an uCDN operator that exploits all the Logging information 571 available to the uCDN, while the tool may provide a different view to 572 each CSP exploiting only the Logging information related to the 573 content of the given CSP. 575 As another example, maintenance and debugging tools may provide 576 different views to different CDN operators, based on their 577 operational role. 579 2.2.5.6.2. Key Performance Indicators (KPIs) 581 This section presents, for explanatory purposes, a non-exhaustive 582 list of Key Performance Indicators (KPIs) that can be extracted/ 583 produced from logs. 585 Multiple log-consuming applications, such as analytics, monitoring, 586 and maintenance applications, often compute and track such KPIs. 588 In a CDNI environment, depending on the situation, these KPIs may be 589 computed by the uCDN or by the dCDN. But it is usually the uCDN that 590 computes KPIs, because the uCDN and dCDN may have different 591 definitions of the KPIs and the computation of some KPIs requires a 592 vision of all the deliveries performed by the uCDN and all its dCDNs. 594 Here is a list of important examples of KPIs: 596 o Number of delivery requests received from End Users in a given 597 region for each piece of content, during a given period of time 598 (e.g., hour/day/week/month) 600 o Percentage of delivery successes/failures among the aforementioned 601 requests 603 o Number of failures listed by failure type (e.g., HTTP error code) 604 for requests received from End Users in a given region and for 605 each piece of content, during a given period of time (e.g., hour/ 606 day/week/month) 608 o Number and cause of premature delivery termination for End Users 609 in a given region and for each piece of content, during a given 610 period of time (e.g., hour/day/week/month) 612 o Maximum and mean number of simultaneous sessions established by 613 End Users in a given region, for a given Content Provider, and 614 during a given period of time (e.g., hour/day/week/month) 616 o Volume of traffic delivered for sessions established by End Users 617 in a given region, for a given Content Provider, and during a 618 given period of time (e.g., hour/day/week/month) 620 o Maximum, mean, and minimum delivery throughput for sessions 621 established by End Users in a given region, for a given Content 622 Provider, and during a given period of time (e.g., hour/day/week/ 623 month) 625 o Cache-hit and byte-hit ratios for requests received from End Users 626 in a given region for each piece of content, during a given period 627 of time (e.g., hour/day/week/month) 629 o Top 10 most popularly requested contents (during a given day/week/ 630 month) 632 o Terminal type (mobile, PC, STB, if this information can be 633 acquired from the browser type header, for example). 635 Additional KPIs can be computed from other sources of information 636 than the Logging information, for instance, data collected by a 637 content portal or by specific client-side application programming 638 interfaces. Such KPIs are out of scope for the present document. 640 The KPIs used depend strongly on the considered log-consuming 641 application -- the CDN operator may be interested in different 642 metrics than the CSP is. In particular, CDN operators are often 643 interested in delivery and acquisition performance KPIs, information 644 related to Surrogates' performance, caching information to evaluate 645 the cache-hit ratio, information about the delivered file size to 646 compute the volume of content delivered during peak hour, etc. 648 Some of the KPIs, for instance those providing an instantaneous 649 vision of the active sessions for a given CSP's content, are useful 650 essentially if they are provided in a timely manner. By contrast, 651 some other KPIs, such as those averaged on a long period of time, can 652 be provided in non-real-time. 654 3. CDNI Logging File 656 3.1. Rules 658 This specification uses the Augmented Backus-Naur Form (ABNF) 659 notation and core rules of [RFC5234]. In particular, the present 660 document uses the following rules from [RFC5234]: 662 CR = %x0D ; carriage return 664 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z 666 DIGIT = %x30-39 ; 0-9 668 DQUOTE = %x22 ; " (Double Quote) 670 CRLF = CR LF ; Internet standard newline 672 HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" 674 HTAB = %x09 ; horizontal tab 676 LF = %x0A ; linefeed 678 OCTET = %x00-FF ; 8 bits of data 680 The present document also uses the following rules from [RFC3986]: 682 host = as specified in section 3.2.2 of [RFC3986]. 684 IPv4address = as specified in section 3.2.2 of [RFC3986]. 686 IPv6address = as specified in section 3.2.2 of [RFC3986]. 688 The present document also defines the following additional rules: 690 ADDRESS = IPv4address / IPv6address 692 ALPHANUM = ALPHA / DIGIT 694 DATE = 4DIGIT "-" 2DIGIT "-" 2DIGIT 696 Dates are recorded in the format YYYY-MM-DD where YYYY, MM and 697 DD stand for the numeric year, month and day respectively. All 698 dates are specified in Universal Time Coordinated (UTC). 700 DEC = 1*DIGIT ["." *DIGIT] 702 NAMEFORMAT = ALPHANUM *(ALPHANUM / "_" / "-") 704 QSTRING = DQUOTE *NDQUOTE DQUOTE ; where 706 NDQUOTE = / 2DQUOTE ; whereby a 707 DQUOTE is conveyed inside a QSTRING unambiguously by repeating 708 it. 710 NHTABSTRING = *NHTAB ; where 712 NHTAB = 714 TIME = 2DIGIT ":" 2DIGIT ":" 2DIGIT ["." *DIGIT] 716 Times are recorded in the form HH:MM:SS or HH:MM:SS.S where HH 717 is the hour in 24 hour format, MM is minutes and SS is seconds. 718 All times are specified in Universal Time Coordinated (UTC). 720 3.2. CDNI Logging File Structure 722 As defined in Section 1.1: a CDNI Logging Field is as an atomic 723 logging information element, a CDNI Logging Record is a collection of 724 CDNI Logging Fields containing all logging information corresponding 725 to a single logging event, and a CDNI Logging File contains a 726 collection of CDNI Logging Records. This structure is illustrated in 727 Figure 3. The use of a file structure for transfer of CDNI Logging 728 information is selected since this is the most common practise today 729 for exchange of logging information within and across CDNs. 731 +----------------------------------------------------------+ 732 |CDNI Logging File | 733 | | 734 | #Directive 1 | 735 | #Directive 2 | 736 | ... | 737 | #Directive P | 738 | | 739 | +------------------------------------------------------+ | 740 | |CDNI Logging Record 1 | | 741 | | +-------------+ +-------------+ +-------------+ | | 742 | | |CDNI Logging | |CDNI Logging | ... |CDNI Logging | | | 743 | | | Field 1 | | Field 2 | | Field N | | | 744 | | +-------------+ +-------------+ +-------------+ | | 745 | +------------------------------------------------------+ | 746 | | 747 | +------------------------------------------------------+ | 748 | |CDNI Logging Record 2 | | 749 | | +-------------+ +-------------+ +-------------+ | | 750 | | |CDNI Logging | |CDNI Logging | ... |CDNI Logging | | | 751 | | | Field 1 | | Field 2 | | Field N | | | 752 | | +-------------+ +-------------+ +-------------+ | | 753 | +------------------------------------------------------+ | 754 | | 755 | ... | 756 | | 757 | #Directive P+1 | 758 | | 759 | ... | 760 | | 761 | +------------------------------------------------------+ | 762 | |CDNI Logging Record M | | 763 | | +-------------+ +-------------+ +-------------+ | | 764 | | |CDNI Logging | |CDNI Logging | ... |CDNI Logging | | | 765 | | | Field 1 | | Field 2 | | Field N | | | 766 | | +-------------+ +-------------+ +-------------+ | | 767 | +------------------------------------------------------+ | 768 | | 769 | | 770 | #Directive P+Q | 771 +----------------------------------------------------------+ 773 Figure 3: Structure of Logging Files 775 The CDNI Logging File format is inspired from the W3C Extended Log 776 File Format [ELF]. However, it is fully specified by the present 777 document. Where the present document differs from the W3C Extended 778 Log File Format, an implementation of CDNI Logging MUST comply with 779 the present document. 781 Using a format that resembles the W3C Extended Log File Format is 782 intended to keep CDNI logging format close to the intra-CDN Logging 783 information format commonly used in CDNs today, thereby minimizing 784 systematic translation at CDN/CDNI boundary. 786 A CDNI Logging File MUST contain a sequence of lines containing US- 787 ASCII characters [CHAR_SET] terminated by CRLF. 789 Each line of a CDNI Logging File MUST contain either a directive or a 790 CDNI Logging Record. 792 Directives record information about the CDNI Logging process itself. 793 Lines containing directives MUST begin with the "#" character. 794 Directives are specified in Section 3.3. 796 Logging Records provide actual details of the logged event. Logging 797 Records are specified in Section 3.4. 799 The CDNI File structure is defined by the following rules: 801 DIRLINE = "#" directive CRLF 803 DIRGROUP = 1*DIRLINE 805 RECLINE = CRLF 807 RECGROUP = *RECLINE 809 = 1* 811 3.3. CDNI Logging File Directives 813 The CDNI Logging File directives are defined by the following rules: 815 directive = DIRNAME ":" HTAB DIRVAL 817 DIRNAME = 820 DIRVAL = 824 An implementation of the CDNI Logging interface MUST support all of 825 the following directives, listed below by their directive name: 827 o Version: 829 * format: "CDNI" "/" 1*DIGIT "." 1*DIGIT 831 * directive value: indicates the version of the CDNI Logging File 832 format. The value MUST be "CDNI/1.0" for the version specified 833 in the present document. 835 * occurrence: there MUST be one and only one instance of this 836 directive per CDNI Logging File. It MUST be the first line of 837 the CDNI Logging File. 839 o UUID: 841 * format: NHTABSTRING 843 * directive value: this a Universally Unique IDentifier (UUID) 844 from the UUID Uniform Resource Name (URN) namespace specified 845 in [RFC4122]) for the CDNI Logging File. 847 * occurrence: there MUST be one and only one instance of this 848 directive per CDNI Logging File. 850 o Claimed-Origin: 852 * format: host 854 * directive value: this contains the claimed identification of 855 the entity transmitting the CDNI Logging File (e.g., the host 856 in a dCDN supporting the CDNI Logging interface) or the entity 857 responsible for transmitting the CDNI Logging File (e.g., the 858 dCDN). 860 * occurrence: there MUST be zero or exactly one instance of this 861 directive per CDNI Logging File. This directive MAY be 862 included by the dCDN. It MUST NOT be included or modified by 863 the uCDN. 865 o Verified-Origin: 867 * format: host 869 * directive value: this contains the identification, as 870 established by the entity receiving the CDNI Logging File, of 871 the entity transmitting the CDNI Logging File (e.g., the host 872 in a dCDN supporting the CDNI Logging interface) or the entity 873 responsible for transmitting the CDNI Logging File (e.g., the 874 dCDN). 876 * occurrence: there MUST be zero or exactly one instance of this 877 directive per CDNI Logging File. This directive MAY be added 878 by the uCDN (e.g., before storing the CDNI Logging File). It 879 MUST NOT be included by the dCDN. The mechanisms used by the 880 uCDN to establish and validate the entity responsible for the 881 CDNI Logging File is outside the scope of the present document. 882 We observe that, in particular, this may be achieved through 883 authentication mechanisms that are part of the CDNI Logging 884 File pull mechanism (Section 4.2). 886 o Record-Type: 888 * format: NAMEFORMAT 890 * directive value: indicates the type of the CDNI Logging Records 891 that follow this directive, until another Record-Type directive 892 (or the end of the CDNI Logging File). This can be any CDNI 893 Logging Record type registered in the CDNI Logging Record-types 894 registry (Section 5.2). "cdni_http_request_v1" MUST be 895 indicated as the Record-Type directive value for CDNI Logging 896 records corresponding to HTTP requests (e.g., a HTTP delivery 897 request) as specified in Section 3.4.1. 899 * occurrence: there MUST be at least one instance of this 900 directive per CDNI Logging File. The first instance of this 901 directive MUST precede a Fields directive and MUST precede all 902 CDNI Logging Records. 904 o Fields: 906 * format: FIENAME * ; where FIENAME can take any 907 CDNI Logging field name registered in the CDNI Logging Field 908 Names registry (Section 5.3). 910 * directive value: this lists the names of all the fields for 911 which a value is to appear in the CDNI Logging Records that 912 follow the instance of this directive (until another instance 913 of this directive). The names of the fields, as well as their 914 occurrences, MUST comply with the corresponding rules specified 915 in the document referenced in the CDNI Logging Record-types 916 registry (Section 5.2) for the corresponding CDNI Logging 917 Record-Type. 919 * occurrence: there MUST be at least one instance of this 920 directive per Record-Type directive. The first instance of 921 this directive for a given Record-Type MUST appear before any 922 CDNI Logging Record for this Record-Type. 924 o Integrity-Hash: 926 * format: 32HEXDIG 928 * directive value: This directive permits the detection of a 929 corrupted CDNI Logging File. This can be useful, for instance, 930 if a problem occurs on the filesystem of the dCDN Logging 931 system and leads to a truncation of a logging file. The valid 932 Integrity-Hash value is included in this directive by the 933 entity that transmits the CDNI Logging File. It is computed by 934 applying the MD5 ([RFC1321]) cryptographic hash function on the 935 CDNI Logging File, including all the directives and logging 936 records, up to the Integrrity-Hash directive itself, excluding 937 the Integrity-Hash directive itself. The Integrity-Hash value 938 is represented as a US-ASCII encoded hexadecimal number, 32 939 digits long (representing a 128 bit hash value). The entity 940 receiving the CDNI Logging File also computes in a similar way 941 the MD5 hash on the received CDNI Logging File and compares 942 this hash to the value of the Integrity-Hash directive. If the 943 two values are equal, then the received CDNI Logging File MUST 944 be considered non-corrupted. Note that this is not a guarantee 945 that the file has not been tampered with by a third party. If 946 the two values are different, the received CDNI Logging File 947 MUST be considered corrupted. The behavior of the entity that 948 received a corrupted CDNI Logging File is outside the scope of 949 this specification; we note that the entity MAY attempt to pull 950 again the same CDNI Logging File from the transmitting entity. 951 If the entity receiving a non-corrupted CDNI Logging File adds 952 a Verified-Origin directive, it MUST then recompute and update 953 the Integrity-Hash directive so it also protects the added 954 Verified-Origin directive. 956 * occurrence: there MUST be zero or exactly one instance of this 957 directive. There SHOULD be exactly one instance of this 958 directive. One situation where that directive could be omitted 959 is where integrity protection is already provided via another 960 mechanism (for example if an integrity hash is associated to 961 the CDNI Logging File out of band through the CDNI Logging 962 Logging Feed Section 4.1 leveraging ATOM extensions such as 963 those proposed in [I-D.snell-atompub-link-extensions]. When 964 present, this field MUST be the last line of the CDNI Logging 965 File. 967 3.4. CDNI Logging Records 969 A CDNI Logging Record consists of a sequence of CDNI Logging Fields 970 relating to that single CDNI Logging Record. 972 CDNI Logging Fields MUST be separated by the "horizontal tabulation 973 (HTAB)" character. 975 To facilitate readability, a prefix scheme is used for CDNI Logging 976 field names in a similar way to the one used in W3C Extended Log File 977 Format [ELF]. The semantics of the prefix in the present document 978 is: 980 o c: refers to the User Agent that issues the request (corresponds 981 to the "client" of W3C Extended Log Format) 983 o d: refers to the dCDN (relative to a given CDN acting as a uCDN) 985 o s: refers to the dCDN Surrogate that serves the request 986 (corresponds to the "server" of W3C Extended Log Format) 988 o u: refers to the uCDN (relative to a given CDN acting as a dCDN) 990 o cs: refers to communication from the User Agent towards the dCDN 991 Surrogate 993 o sc: refers to communication from the dCDN Surrogate towards the 994 User Agent 996 An implementation of the CDNI Logging interface as per the present 997 specification MUST support the CDNI HTTP Delivery Records as 998 specified in Section 3.4.1. 1000 A CDNI Logging Record is defined by the following rules: 1002 FIEVAL = 1004 = FIEVAL * ; where FIEVAL 1005 contains the CDNI Logging field values corresponding to the CDNI 1006 Logging field names (FIENAME) listed is the last Fields directive 1007 predecing the present CDNI Logging Record. 1009 3.4.1. HTTP Request Logging Record 1011 This section defines the CDNI Logging Record of Record-Type 1012 "cdni_http_request_v1". It is applicable to content delivery 1013 performed by the dCDN using HTTP/1.0([RFC1945]), HTTP/1.1([RFC2616]) 1014 or HTTPS ([RFC2818]). We observe that, in the case of HTTPS 1015 delivery, there may be value in logging additional information 1016 specific to the operation of HTTP over TLS and we note that this is 1017 outside the scope of the present document and may be addressed in a 1018 future document defining another CDNI Logging Record or another 1019 version of the HTTP Request Logging Record. 1021 The "cdni_http_request_v1" Record-Type is also expected to be 1022 applicable to HTTP/2.0 [I-D.ietf-httpbis-http2] (which is still under 1023 development at the time of writing the present document) since a 1024 fundamental design tenet of HTTP/2.0 is to preserve the HTTP/1.1 1025 semantics. We observe that, in the case of HTTP/2.0 delivery, there 1026 may be value in logging additional information specific to the 1027 additional functionality of HTTP/2.0 (e.g. information related to 1028 connection identification, to stream identification, to stream 1029 priority and to flow control). We note that such additional 1030 information is outside the scope of the present document and may be 1031 addressed in a future document defining another CDNI Logging Record 1032 or another version of the HTTP Request Logging Record. 1034 The "cdni_http_request_v1" Record-Type contains the following CDNI 1035 Logging Fields, listed by their field name: 1037 o date: 1039 * format: DATE 1041 * field value: the date at which the processing of request 1042 completed on the Surrogate. 1044 * occurrence: there MUST be one and only one instance of this 1045 field. 1047 o time: 1049 * format: TIME 1051 * field value: the time at which the processing of request 1052 completed on the Surrogate. 1054 * occurrence: there MUST be one and only one instance of this 1055 field. 1057 o time-taken: 1059 * format: DEC 1061 * field value: decimal value of the duration, in seconds, between 1062 the start of the processing of the request and the completion 1063 of the request processing (e.g., completion of delivery) by the 1064 Surrogate. 1066 * occurrence: there MUST be one and only one instance of this 1067 field. 1069 o c-ip: 1071 * format: ADDRESS 1073 * field value: the source IPv4 or IPv6 address (i.e., the 1074 "client" address) in the request received by the Surrogate. 1076 * occurrence: there MUST be one and only one instance of this 1077 field. 1079 o c-ip-anonymizing: 1081 * format: 1*DIGIT 1083 * field value: the number of rightmost bits of the address in the 1084 c-ip field that are zeroed-out in order to anonymize the 1085 logging record. The mechanism by which the two ends of the 1086 CDNI Logging interface agree on whether anonymization is to be 1087 supported and the number of bits that need to be zeroed-out for 1088 this purpose are outside the scope of the present document. 1090 * occurrence: there MUST be zero or exactly one instance of this 1091 field. 1093 o c-port: 1095 * format: 1*DIGIT 1097 * field value: the source TCP port (i.e., the "client" port) in 1098 the request received by the Surrogate. 1100 * occurrence: there MUST be zero or exactly one instance of this 1101 field. 1103 o s-ip: 1105 * format: ADDRESS 1107 * field value: the IPv4 or IPv6 address of the Surrogate that 1108 served the request (i.e., the "server" address). 1110 * occurrence: there MUST be zero or exactly one instance of this 1111 field. 1113 o s-hostname: 1115 * format: host 1116 * field value: the hostname of the Surrogate that served the 1117 request (i.e., the "server" hostname). 1119 * occurrence: there MUST be zero or exactly one instance of this 1120 field. 1122 o s-port: 1124 * format: 1*DIGIT 1126 * field value: the destination TCP port (i.e., the "server" port) 1127 in the request received by the Surrogate. 1129 * occurrence: there MUST be zero or exactly one instance of this 1130 field. 1132 o cs-method: 1134 * format: NHTABSTRING 1136 * field value: this is the HTTP method of the HTTP request 1137 received by the Surrogate. 1139 * occurrence: There MUST be one and only one instance of this 1140 field. 1142 o cs-uri: 1144 * format: NHTABSTRING 1146 * field value: this is the complete URL of the request received 1147 by the Surrogate. It is exactly in the format of a http_URL 1148 specified in [RFC2616]) or, when the request was a HTTPS 1149 request ([RFC2818]), it is in the format of a http_URL but with 1150 the scheme part set to "https" instead of "http". 1152 * occurrence: there MUST be zero or exactly one instance of this 1153 field. 1155 o u-uri: 1157 * format: NHTABSTRING 1159 * field value: this is a complete URL, derived from the complete 1160 URI of the request received by the Surrogate (i.e., the cs-uri) 1161 but transformed by the entity generating or transmitting the 1162 CDNI Logging Record, in a way that is agreed upon between the 1163 two ends of the CDNI Logging interface, so the transformed URI 1164 is meaningful to the uCDN. For example, the two ends of the 1165 CDNI Logging interface could agree that the u-uri is 1166 constructed from the cs-uri by removing the part of the 1167 hostname that exposes which individual Surrogate actually 1168 performed the delivery. The details of modification performed 1169 to generate the u-uri, as well as the mechanism to agree on 1170 these modifications between the two sides of the CDNI Logging 1171 interface are outside the scope of the present document. 1173 * occurrence: there MUST be one and only one instance of this 1174 field. 1176 o protocol: 1178 * format: NHTABSTRING 1180 * field value: this is value of the HTTP-Version field as 1181 specified in [RFC2616] of the Request-Line of the request 1182 received by the Surrogate (e.g., "HTTP/1.1"). 1184 * occurrence: there MUST be one and only one instance of this 1185 field. 1187 o sc-status: 1189 * format: 3DIGIT 1191 * field value: this is the HTTP Status-Code in the HTTP response 1192 from the Surrogate. 1194 * occurrence: There MUST be one and only one instance of this 1195 field. 1197 o sc-total-bytes: 1199 * format: 1*DIGIT 1201 * field value: this is the total number of bytes of the HTTP 1202 response sent by the Surrogate in response to the request. 1203 This includes the bytes of the Status-Line, the bytes of the 1204 HTTP headers and the bytes of the message-body. 1206 * occurrence: There MUST be one and only one instance of this 1207 field. 1209 o sc-entity-bytes: 1211 * format: 1*DIGIT 1212 * field value: this is the number of bytes of the message-body in 1213 the HTTP response sent by the Surrogate in response to the 1214 request. This does not include the bytes of the Status-Line or 1215 the bytes of the HTTP headers. 1217 * occurrence: there MUST be zero or exactly one instance of this 1218 field. 1220 o cs(): 1222 * format: QSTRING 1224 * field value: the value of the HTTP header (identified by the 1225 in the CDNI Logging field name) as it 1226 appears in the request processed by the Surrogate, but 1227 prepended by a DQUOTE and appended by a DQUOTE. For example, 1228 when the CDNI Logging field name (FIENAME) listed in the 1229 preceding Fields directive is cs(User-Agent), this CDNI Logging 1230 field value contains the value of the User-Agent HTTP header as 1231 received by the Surrogate in the request it processed, but 1232 prepended by a DQUOTE and appended by a DQUOTE. If the HTTP 1233 header as it appeared in the request processed by the Surrogate 1234 contains one or more DQUOTE, each DQUOTE MUST be escaped by an 1235 additional DQUOTE. For example, if the HTTP header contains 1236 My_Header"value", then the field value of the cs() is "My_Header""value""". 1239 * occurrence: there MAY be zero, one or any number of instance of 1240 this field. 1242 o sc(): 1244 * format: QSTRING 1246 * field value: the value of the HTTP header (identified by the 1247 in the CDNI Logging field name) as it 1248 appears in the response issued by the Surrogate to serve the 1249 request, but prepended by a DQUOTE and appended by a DQUOTE. 1250 If the HTTP header as it appeared in the request processed by 1251 the Surrogate contains one or more DQUOTE, each DQUOTE MUST be 1252 escaped by an additional DQUOTE. For example, if the HTTP 1253 header contains My_Header"value", then the field value of the 1254 cs() is "My_Header""value""". 1256 * occurrence: there MAY be zero, one or any number of instances 1257 of this field. For a given , there MUST be 1258 zero or exactly one instance of this field. 1260 o s-ccid: 1262 * format: QSTRING 1264 * field value: this contains the value of the Content Collection 1265 IDentifier (CCID) associated by the uCDN to the content served 1266 by the Surrogate via the CDNI Metadata interface 1267 ([I-D.ietf-cdni-metadata]), prepended by a DQUOTE and appended 1268 by a DQUOTE. If the CCID conveyed in the CDNI Metadata 1269 interface contains one or more DQUOTE, each DQUOTE MUST be 1270 escaped by an additional DQUOTE. For example, if the CCID 1271 conveyed in the CDNI Metadata interface is My_CCIDD"value", 1272 then the field value of the s-ccid is "My_CCID""value""". 1274 * occurrence: there MUST be zero or exactly one instance of this 1275 field. For a given , there MUST be zero or 1276 exactly one instance of this field. 1278 o s-sid: 1280 * format: QSTRING 1282 * field value: this contains the value of a Session IDentifier 1283 (SID) generated by the dCDN for a specific HTTP session, 1284 prepended by a DQUOTE and appended by a DQUOTE. In particular, 1285 for HTTP Adaptive Streaming (HAS) session, the Session 1286 IDentifier value is included in the Logging record for every 1287 content chunk delivery of that session in view of facilitating 1288 the later correlation of all the per content chunk log records 1289 of a given HAS session. See section 3.4.2.2. of [RFC6983] for 1290 more discussion on the concept of Session IDentifier in the 1291 context of HAS. If the SID conveyed contains one or more 1292 DQUOTE, each DQUOTE MUST be escaped by an additional DQUOTE. 1293 For example, if the SID is My_SID"value", then the field value 1294 of the s-sid is "My_SID""value""". 1296 * occurrence: there MUST be zero or exactly one instance of this 1297 field. 1299 o s-cached: 1301 * format: 1DIGIT 1303 * field value: this characterises whether the Surrogate served 1304 the request using content already stored on its local cache or 1305 not. The allowed values are "0" (for miss) and "1" (for hit). 1306 "1" MUST be used when the Surrogate did serve the request using 1307 exclusively content already stored on its local cache. "0" MUST 1308 be used otherwise (including cases where the Surrogate served 1309 the request using some, but not all, content already stored on 1310 its local cache). Note that a "0" only means a cache miss in 1311 the Surrogate and does not provide any information on whether 1312 the content was already stored, or not, in another device of 1313 the dCDN, i.e., whether this was a "dCDN hit" or "dCDN miss". 1315 * occurrence: there MUST be zero or exactly one instance of this 1316 field. 1318 The "Fields" directive corresponding to a HTTP Request Logging Record 1319 MUST contain all the fields names whose occurrence is specified above 1320 as "There MUST be one and only one instance of this field". The 1321 corresponding fields value MUST be present in every HTTP Request 1322 Logging Record. 1324 The "Fields" directive corresponding to a HTTP Request Logging Record 1325 MAY list all the fields value whose occurrence is specified above as 1326 "there MUST be zero or exactly one instance of this field" or "there 1327 MAY be zero, one or any number of instances of this field". The set 1328 of such field names actually listed in the "Fields" directive is 1329 selected by the CDN generating the CDNI Logging File based on 1330 agreements between the interconnected CDNs established through 1331 mechanisms outside the scope of this specification (e.g., contractual 1332 agreements). When such a field name is not listed in the "Fields" 1333 directive, the corresponding field value MUST NOT be included in the 1334 Logging Record. When such a field name is listed in the "Fields" 1335 directive, the corresponding field value MUST be included in the 1336 Logging Record; if the value for the field is not available, this 1337 MUST be conveyed via a dash character ("-"). 1339 The fields names listed in the "Fields" directive MAY be listed in 1340 the order in which they are listed in Section 3.4.1 or MAY be listed 1341 in any other order. 1343 A dCDN-side implementation of the CDNI Logging interface MUST 1344 implement all the following Logging Fields in a CDNI Logging Record 1345 of Record-Type "cdni_http_request_v1", and MUST support the ability 1346 to include valid values for each of them: 1348 o date 1350 o time 1352 o time-taken 1354 o c-ip 1355 o c-port 1357 o s-ip 1359 o s-hostname 1361 o s-port 1363 o cs-method 1365 o cs-uri 1367 o u-uri 1369 o protocol 1371 o sc-status 1373 o sc-total-bytes 1375 o sc-entity-bytes 1377 o cs() 1379 o sc() 1381 o s-cached 1383 A dCDN-side implementation of the CDNI Logging interface MAY support 1384 the following Logging Fields in a CDNI Logging Record of Record-Type 1385 "cdni_http_request_v1": 1387 o c-ip-anonymizing 1389 o s-ccid 1391 o s-sid 1393 If a dCDN-side implementation of the CDNI Logging interface supports 1394 these Fields, it MUST support the ability to include valid values for 1395 them. 1397 An uCDN-side implementation of the CDNI Logging interface MUST be 1398 able to accept CDNI Logging Files with CDNI Logging Records of 1399 Record-Type "cdni_http_request_v1" containing any CDNI Logging Field 1400 defined in Section 3.4.1 as long as the CDNI Logging Record and the 1401 CDNI Logging File are compliant with the present document. 1403 3.5. CDNI Logging File Example 1405 #Version:CDNI/1.0 1407 #UUID:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 1409 #Claimed-Origin:cdni-logging-entity.dcdn.example.com 1411 #Record-Type:cdni_http_request_v1 1413 #Fields:datetimetime-takenc-ipcs- 1414 methodu-uriprotocolsc-statussc-total- 1415 bytescs(User-Agent)cs(Referer)s-cached 1417 2013-05-1700:38:06.8259.05810.5.7.1GETh 1418 ttp://cdni-ucdn.dcdn.example.com/video/movie100.mp4HTTP/ 1419 1.12006729891"Mozilla/5.0 (Windows; U; Windows NT 1420 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 1421 Safari /533.4""host1.example.com"1 1423 2013-05-1700:39:09.14515.3210.5.10.5GET 1424 http://cdni-ucdn.dcdn.example.com/video/movie118.mp4HTTP/ 1425 1.120015799210"Mozilla/5.0 (Windows; U; Windows NT 1426 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 1427 Safari /533.4""host1.example.com"1 1429 2013-05-1700:42:53.43752.87910.5.10.5GEThttp://cdni-ucdn.dcdn.example.com/video/picture11.mp4HTTP/ 1431 1.020097234724"Mozilla/5.0 (Windows; U; Windows NT 1432 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 1433 Safari /533.4""host5.example.com"0 1435 #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e 1437 4. CDNI Logging File Exchange Protocol 1439 This document specifies a protocol for the exchange of CDNI Logging 1440 Files as specified in Section 3. 1442 This protocol comprises: 1444 o a CDNI Logging feed, allowing the dCDN to notify the uCDN about 1445 the CDNI Logging Files that can be retrieved by that uCDN from the 1446 dCDN, as well as all the information necessary for retrieving each 1447 of these CDNI Logging Files. The CDNI Logging feed is specified 1448 in Section 4.1. 1450 o a CDNI Logging File pull mechanism, allowing the uCDN to obtain 1451 from the dCDN a given CDNI Logging File at the uCDN's convenience. 1452 The CDNI Logging File pull mechanisms is specified in Section 4.2. 1454 An implementation of the CDNI Logging interface on the dCDN side (the 1455 entity generating the CDNI Logging file) MUST support the server side 1456 of the CDNI Logging feed and the server side of the CDNI Logging pull 1457 mechanism. 1459 An implementation of the CDNI Logging interface on the uCDN side (the 1460 entity consuming the CDNI Logging file) MUST support the client side 1461 of the CDNI Logging feed and the client side of the CDNI Logging pull 1462 mechanism. 1464 We note that implementations of the CDNI Logging interface MAY also 1465 support other mechanisms to exchange CDNI Logging Files, for example 1466 in view of exchanging logging information with minimum time-lag 1467 (e.g., sub-minute or sub-second) between when the event occurred in 1468 the dCDN and when the corresponding Logging Record is made available 1469 to the uCDN (e.g., for log-consuming applications requiring extremely 1470 fresh logging information such as near-real-time content delivery 1471 monitoring). Such mechanisms are for further study and outside the 1472 scope of this document. 1474 4.1. CDNI Logging Feed 1476 The server-side implementation of the CDNI Logging feed MUST produce 1477 an Atom feed [RFC4287]. This feed is used to advertise log files 1478 that are available for the client-side to retrieve using the CDNI 1479 Logging pull mechanism. 1481 4.1.1. Atom Formatting 1483 A CDNI Logging feed MUST be structured as an Archived feed, as 1484 defined in [RFC5005], and MUST be formatted in Atom [RFC4287]. This 1485 means it consists of a subscription document that is regularly 1486 updated as new CDNI Logging Files become available, and information 1487 about older CDNI Logging files is moved into archive documents. Once 1488 created, archive documents are never modified. 1490 Each CDNI Logging File listed in an Atom feed MUST be described in an 1491 atom:entry container element. 1493 The atom:entry MUST contain an atom:content element whose "src" 1494 attribute is a link to the CDNI Logging File and whose "type" 1495 attribute is the MIME Media Type indicating that the entry is a CDNI 1496 Logging File. We define this MIME Media Type as "application/ 1497 cdni.LoggingFile" (See Section 5.4). 1499 For compatibility with some Atom feed readers the atom:entry MAY also 1500 contain an atom:link entry whose "href" attribute is a link to the 1501 CDNI Logging File and whose "type" attribute is the MIME Media Type 1502 indicating that the entry is a CDNI Logging File using the 1503 "application/cdni.LoggingFile" MIME Media Type (See Section 5.4). 1505 The URI used in the atom:id of the atom:entry MUST contain the UUID 1506 of the CDNI Logging File. 1508 The atom:updated in the atom:entry MUST indicate the time at which 1509 the CDNI Logging File was last updated. 1511 4.1.2. Updates to Log Files and the Feed 1513 CDNI Logging Files MUST NOT be modified by the dCDN once published in 1514 the CDNI Logging feed. 1516 The frequency with which the subscription feed is updated, the period 1517 of time covered by each CDNI Logging File or each archive document, 1518 and timeliness of publishing of CDNI Logging Files are outside the 1519 scope of the present document and are expected to be agreed upon by 1520 uCDN and dCDN via other means (e.g., human agreement). 1522 The server-side implementation SHOULD use HTTP cache control headers 1523 on the subscription feed to indicate the frequency at which the 1524 client-side is to poll for updates. 1526 The potential retention limits (e.g., sliding time window) within 1527 which the dCDN is to retain and be ready to serve an archive document 1528 is outside the scope of the present document and is expected to be 1529 agreed upon by uCDN and dCDN via other means (e.g., human agreement). 1530 The server-side implementation MUST retain, and be ready to serve, 1531 any archive document within the agreed retention limits. Outside 1532 these agreed limits, the server-side implementation MAY indicate its 1533 inability to serve (e.g., with HTTP status code 404) an archive 1534 document or MAY refuse to serve it (e.g., with HTTP status code 403 1535 or 410). 1537 4.1.3. Redundant Feeds 1539 The server-side implementation MAY present more than one CDNI Logging 1540 feed and for redundancy. CDNI Logging Files MAY be published in more 1541 than one feed. 1543 A client-side implementation MAY support such redundant CDNI Logging 1544 feeds. If it supports redundant CDNI Logging feed, the client-side 1545 SHOULD use the UUID of the CDNI Logging File, presented in the 1546 atom:id element of the Atom feed, to avoid unnecessarily pulling and 1547 storing each CDNI Logging File more than once. 1549 4.1.4. Example CDNI Logging Feed 1551 Figure 4 illustrates an example of the subscription document of a 1552 CDNI Logging feed. 1554 1555 > 1557 CDNI Logging Feed 1558 2013-03-23T14:46:11Z 1559 urn:uuid:663ae677-40fb-e99a-049d-c5642916b8ce 1560 1562 1564 1566 CDNI Log Feed 1567 Generator 1568 dcdn.example 1569 1570 CDNI Logging File for uCDN at 1571 2013-03-23 14:15:00 1572 urn:uuid:12345678-1234-abcd-00aa-01234567abcd 1573 2013-03-23T14:15:00Z 1574 1577 CDNI Logging File for uCDN at 1578 2013-03-23 14:15:00 1579 1580 1581 CDNI Logging File for uCDN at 1582 2013-03-23 14:30:00 1583 urn:uuid:87654321-4321-dcba-aa00-dcba7654321 1584 2013-03-23T14:30:00Z 1585 1588 CDNI Logging File for uCDN at 1589 2013-03-23 14:30:00 1590 1591 ... 1592 1593 ... 1594 1595 1597 Figure 4: Example subscription document of a CDNI Logging Feed 1599 4.2. CDNI Logging File Pull 1601 A client-side implementation of the CDNI Logging interface MAY pull, 1602 at its convenience, a CDNI Logging File that is published by the 1603 server-side in the CDNI Logging Feed (in the subscription document or 1604 an archive document). To do so, the client-side: 1606 o MUST use HTTP v1.1 [RFC2616]; 1608 o SHOULD use TLS (i.e., use what is loosely referred to as "HTTPS") 1609 as per [RFC2818] whenever protection of the CDNI Logging 1610 information is required (see Section 6.1); 1612 o MUST use the URI that was associated to the CDNI Logging File 1613 (within the "src" attribute of the corresponding atom:content 1614 element) in the CDNI Logging Feed; 1616 o MUST support exchange of CDNI Logging Files with no content 1617 encoding applied to the representation; 1619 o SHOULD support exchange of CDNI Logging Files with "gzip" content 1620 encoding (as defined in [RFC2616]) applied to the representation. 1622 Note that a client-side implementation of the CDNI Logging interface 1623 MAY pull a CDNI Logging File that it has already pulled. 1625 The server-side implementation MUST respond to valid pull request by 1626 a client-side implementation for a CDNI Logging File published by the 1627 server-side in the CDNI Logging Feed (in the subscription document or 1628 an archive document). The server-side implementation: 1630 o MUST handle the client-side request as per HTTP v1.1; 1632 o MUST include the CDNI Logging File identified by the request URI 1633 inside the body of the HTTP response; 1635 o MUST support exchange of CDNI Logging Files with no content 1636 encoding applied to the representation; 1638 o SHOULD support exchange of CDNI Logging Files with "gzip" content 1639 encoding (as defined in [RFC2616]) applied to the representation. 1641 Content negotiation approaches defined in [RFC2616] (e.g., using 1642 Accept-Encoding request-header field or Content-Encoding entity- 1643 header field) MAY be used by the client-side and server-side 1644 implementations to establish the content-coding to be used for a 1645 particular exchange of a CDNI Logging File. 1647 Applying compression content encoding (such as "gzip") is expected to 1648 mitigate the impact of exchanging the large volumes of logging 1649 information expected across CDNs. This is expected to be 1650 particularly useful in the presence of HTTP Adaptive Streaming (HAS) 1651 which, as per the present version of the document, will result in a 1652 separate CDNI Log Record for each HAS segment delivery in the CDNI 1653 Logging File. 1655 The potential retention limits (e.g., sliding time window, maximum 1656 aggregate file storage quotas) within which the dCDN is to retain and 1657 be ready to serve a CDNI Logging File previously advertised in the 1658 CDNI Logging Feed is outside the scope of the present document and is 1659 expected to be agreed upon by uCDN and dCDN via other means (e.g., 1660 human agreement). The server-side implementation MUST retain, and be 1661 ready to serve, any CDNI Logging File within the agreed retention 1662 limits. Outside these agreed limits, the server-side implementation 1663 MAY indicate its inability to serve (e.g., with HTTP status code 404) 1664 a CDNI Logging File or MAY refuse to serve it (e.g., with HTTP status 1665 code 403 or 410). 1667 5. IANA Considerations 1669 5.1. CDNI Logging Directive Names Registry 1671 The IANA is requested to create a new registry, CDNI Logging 1672 Directive Names. 1674 The initial contents of the CDNI Logging File Directives registry 1675 comprise the names of the directives specified in Section 3.3 of the 1676 present document, and are as follows: 1678 +------------------------------+-----------+ 1679 | Directive Name + Reference | 1680 +------------------------------+-----------+ 1681 | Version + RFC xxxx | 1682 | UUID + RFC xxxx | 1683 | Claimed-Origin + RFC xxxx | 1684 | Verified-Origin + RFC xxxx | 1685 | Record-Type + RFC xxxx | 1686 | Fields + RFC xxxx | 1687 | Integrity-Hash + RFC xxxx | 1688 +------------------------------+-----------+ 1690 Figure 5 1692 [Instructions to IANA: Replace "RFC xxxx" above by the RFC number of 1693 the present document] 1694 Within the registry, names are to be allocated by IANA according to 1695 the "Specification Required" policy specified in [RFC5226]. 1696 Directive names are to be allocated by IANA with a format of 1697 NAMEFORMAT (see Section 3.1). 1699 Each specification that defines a new CDNI Logging directive needs to 1700 contain a description for the new directive with the same set of 1701 information as provided in Section 3.3 (i.e., format, directive value 1702 and occurrence). 1704 5.2. CDNI Logging Record-Types Registry 1706 The IANA is requested to create a new registry, CDNI Logging Record- 1707 Types. 1709 The initial contents of the CDNI Logging Record-Types registry 1710 comprise the names of the CDNI Logging Record types specified in 1711 Section 3.4 of the present document, and are as follows: 1713 +------------------------------+-----------+ 1714 | Record-Types + Reference | 1715 +------------------------------+-----------+ 1716 | cdni_http_request_v1 + RFC xxxx | 1717 +------------------------------+-----------+ 1719 Figure 6 1721 [Instructions to IANA: Replace "RFC xxxx" above by the RFC number of 1722 the present document] 1724 Within the registry, Record-Types are to be allocated by IANA 1725 according to the "Specification Required" policy specified in 1726 [RFC5226]. Record-Types are to be allocated by IANA with a format of 1727 NAMEFORMAT (see Section 3.1). 1729 Each specification that defines a new Record-Type needs to contain a 1730 description for the new Record-Type with the same set of information 1731 as provided in Section 3.4.1. This includes: 1733 o a list of all the CDNI Logging Fields that can appear in a CDNI 1734 Logging Record of the new Record-Type 1736 o for all these Fields: a specification of the occurrence for each 1737 Field in the new Record-Type 1739 o for every newly defined Field, i.e., for every Field that results 1740 in a registration in the CDNI Logging Field Names Registry 1741 (Section 5.3): a specification of the field name, format and field 1742 value. 1744 5.3. CDNI Logging Field Names Registry 1746 The IANA is requested to create a new registry, CDNI Logging Field 1747 Names. 1749 The initial contents of the CDNI Logging Fields Names registry 1750 comprise the names of the CDNI Logging fields specified in 1751 Section 3.4 of the present document, and are as follows: 1753 +---------------------------------------------+-----------+ 1754 | Field Name + Reference | 1755 +---------------------------------------------+-----------+ 1756 | date + RFC xxxx | 1757 | time + RFC xxxx | 1758 | time-taken + RFC xxxx | 1759 | c-ip + RFC xxxx | 1760 | c-ip-anonymizing + RFC xxxx | 1761 | c-port + RFC xxxx | 1762 | s-ip + RFC xxxx | 1763 | s-hostname + RFC xxxx | 1764 | s-port + RFC xxxx | 1765 | cs-method + RFC xxxx | 1766 | cs-uri + RFC xxxx | 1767 | u-uri + RFC xxxx | 1768 | protocol + RFC xxxx | 1769 | sc-status + RFC xxxx | 1770 | sc-total-bytes + RFC xxxx | 1771 | sc-entity-bytes + RFC xxxx | 1772 | cs() + RFC xxxx | 1773 | sc() + RFC xxxx | 1774 | s-ccid + RFC xxxx | 1775 | s-sid + RFC xxxx | 1776 | s-cached + RFC xxxx | 1777 +---------------------------------------------+-----------+ 1779 Figure 7 1781 [Instructions to IANA: Replace "RFC xxxx" above by the RFC number of 1782 the present document] 1784 Within the registry, names are to be allocated by IANA according to 1785 the "Specification Required" policy specified in [RFC5226]. Field 1786 names are to be allocated by IANA with a format of NHTABSTRING (see 1787 Section 3.1). 1789 The above registry is intended to be shared across the currently 1790 defined Record-Type (i.e., cdni_http_request_v1) as well as potential 1791 other CDNI Logging Record-Types that may be defined in separate 1792 specifications. When a Field from this registry is used by another 1793 CDNI Logging Record-Type, it is to be used with the exact semantics 1794 and format specified in the document that registered this field and 1795 that is identified in the Reference column of the registry. If 1796 another CDNI Logging Record-Type requires a Field with semantics that 1797 are not strictly identical, or a format that is not strictly 1798 identical then this new Field is to be registered in the registry 1799 with a different Field name. When a Field from this registry is used 1800 by another CDNI Logging Record-Type, it can be used with different 1801 occurence rules. 1803 5.4. CDNI Logging MIME Media Type 1805 The IANA is requested to allocate the "application/cdni.LoggingFile" 1806 MIME Media Type (whose use is specified in Section 4.1.1 of the 1807 present document) in the MIME Media Types registry. 1809 6. Security Considerations 1811 6.1. Authentication, Confidentiality, Integrity Protection 1813 A CDNI Logging implementation MUST support TLS transport of the CDNI 1814 Logging feed (Section 4.1) and of the CDNI Logging File pull 1815 (Section 4.2) as per [RFC2818]. 1817 The use of TLS for transport of the CDNI Logging feed and CDNI 1818 Logging File pull allows: 1820 o the dCDN and uCDN to authenticate each other (to ensure they are 1821 transmitting/receiving CDNI Logging File from an authenticated 1822 CDN) 1824 o the CDNI Logging information to be transmitted with 1825 confidentiality 1827 o the integrity of the CDNI Logging information to be protected 1828 during the exchange 1830 In an environment where any such protection is required, TLS SHOULD 1831 be used for transport of the CDNI Logging feed and the CDNI Logging 1832 File pull unless alternate methods are used for ensuring the 1833 confidentiality of the information in the logging files (such as 1834 setting up an IPsec tunnel between the two CDNs or using a physically 1835 secured internal network between two CDNs that are owned by the same 1836 corporate entity). Both parties of the transaction (uCDN and dCDN) 1837 SHOULD use mutual authentication. 1839 A CDNI Logging implementation MUST support the 1840 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite ( [RFC5288]). An 1841 implementation of the CDNI Logging Interface SHOULD prefer cipher 1842 suites which support perfect forward secrecy over cipher suites that 1843 don't. 1845 The Integrity-Hash directive inside the CDNI Logging File provides 1846 additional integrity protection, this time targeting potential 1847 corruption of the CDNI logging information during the CDNI Logging 1848 File generation. This mechanism does not allow restoration of the 1849 corrupted CDNI Logging information, but it allows detection of such 1850 corruption and therefore triggering of appropriate correcting actions 1851 (e.g., discard of corrupted information, attempt to re-obtain the 1852 CDNI Logging information). 1854 6.2. Denial of Service 1856 This document does not define specific mechanism to protect against 1857 Denial of Service (DoS) attacks on the Logging Interface. However, 1858 the CDNI Logging feed and CDNI Logging pull endpoints can be 1859 protected against DoS attacks through the use of TLS transport and/or 1860 via mechanisms outside the scope of the CDNI Logging interface such 1861 as firewalling or use of Virtual Private Networks (VPNs). 1863 Protection of dCDN Surrogates against spoofed delivery requests is 1864 outside the scope of the CDNI Logging interface. 1866 6.3. Privacy 1868 CDNs have the opportunity to collect detailed information about the 1869 downloads performed by End Users. The provision of this information 1870 to another CDN introduces potential End Users privacy protection 1871 concerns. 1873 The use of TLS for transport of the CDNI Logging feed and CDNI 1874 Logging pull as discussed in Section 6.1 protects the confidentiality 1875 of logged information by preventing any other party than the 1876 authorised uCDN to gain access to the logging information. 1878 We observe that when CDNI interconnection is realised as per 1879 [I-D.ietf-cdni-framework], the uCDN handles the initial End User 1880 requests (before it is redirected to the dCDN) so, regardless of 1881 which information is, or is not, communicated to the uCDN through the 1882 CDNI Logging interface, the uCDN has visibility on significant 1883 information such as the IP address of the End User request and the 1884 URL of the request. 1886 Nonetheless, if the dCDN and uCDN agree that anonymization is 1887 required to avoid making some detailed information available to the 1888 uCDN (such as how many bytes of the content have been watched by an 1889 End User and/or at what time) or is required to meet some legal 1890 obligations, then the uCDN and dCDN can agree to exchange anonymized 1891 End Users IP address in CDNI Logging Files and the c-ip-anonymization 1892 field can be used to convey the number of bits that have been 1893 anonymized so that the meaningful information can still be easily 1894 extracted from the anonymized addressses (e.g., for geolocation aware 1895 analytics). 1897 We note that anonymization of End Users IP address does not fully 1898 protect against deriving potentially sensitive information about 1899 traffic patterns; in general, increasing the number of bits that are 1900 anonymized can mitigate the risks of deriving such sensitive traffic 1901 pattern information. 1903 We also note that independently of IP addresses, the query string 1904 portion of the URL that may be conveyed inside the cs-uri and u-uri 1905 fields of CDNI Logging Files, or the HTTP cookies( [RFC6265]) that 1906 may be conveyed inside the cs() field of CDNI 1907 Logging Fields, may contain personnal information or information that 1908 can be exploited to derive personal information. Where this is a 1909 concern, the CDNI Logging interface specification allows the dCDN to 1910 not include the cs-uri and to include a u-uri that removes (or hides) 1911 the sensitive part of the query string and allows the dCDN to not 1912 include the cs() fields corresponding to HTTP 1913 headers associated with cookies. 1915 7. Acknowledgments 1917 This document borrows from the W3C Extended Log Format [ELF]. 1919 Rob Murray significantly contributed into the text of Section 4.1. 1921 The authors thank Ben Niven-Jenkins, Kevin Ma, David Mandelberg and 1922 Ray van Brandenburg for their ongoing input. 1924 Finally, we also thank Sebastien Cubaud, Pawel Grochocki, Christian 1925 Jacquenet, Yannick Le Louedec, Anne Marrec , Emile Stephan, Fabio 1926 Costa, Sara Oueslati, Yvan Massot, Renaud Edel, Joel Favier and the 1927 contributors of the EU FP7 OCEAN project for their input in the early 1928 versions of this document. 1930 8. References 1932 8.1. Normative References 1934 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1935 Requirement Levels", BCP 14, RFC 2119, March 1997. 1937 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1938 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1939 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1941 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1942 Resource Identifier (URI): Generic Syntax", STD 66, RFC 1943 3986, January 2005. 1945 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1946 Unique IDentifier (UUID) URN Namespace", RFC 4122, July 1947 2005. 1949 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom 1950 Syndication Format", RFC 4287, December 2005. 1952 [RFC5005] Nottingham, M., "Feed Paging and Archiving", RFC 5005, 1953 September 2007. 1955 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1956 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1957 May 2008. 1959 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1960 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1962 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 1963 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 1964 August 2008. 1966 8.2. Informative References 1968 [CHAR_SET] 1969 "IANA Character Sets registry", . 1972 [ELF] Phillip M. Hallam-Baker, and Brian Behlendorf, "Extended 1973 Log File Format, W3C (work in progress), WD- 1974 logfile-960323", . 1976 [I-D.ietf-cdni-framework] 1977 Peterson, L., Davie, B., and R. Brandenburg, "Framework 1978 for CDN Interconnection", draft-ietf-cdni-framework-10 1979 (work in progress), March 2014. 1981 [I-D.ietf-cdni-metadata] 1982 Niven-Jenkins, B., Murray, R., Watson, G., Caulfield, M., 1983 Leung, K., and K. Ma, "CDN Interconnect Metadata", draft- 1984 ietf-cdni-metadata-06 (work in progress), February 2014. 1986 [I-D.ietf-cdni-requirements] 1987 Leung, K. and Y. Lee, "Content Distribution Network 1988 Interconnection (CDNI) Requirements", draft-ietf-cdni- 1989 requirements-17 (work in progress), January 2014. 1991 [I-D.ietf-httpbis-http2] 1992 Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer 1993 Protocol version 2", draft-ietf-httpbis-http2-10 (work in 1994 progress), February 2014. 1996 [I-D.snell-atompub-link-extensions] 1997 Snell, J., "Atom Link Extensions", draft-snell-atompub- 1998 link-extensions-09 (work in progress), June 2012. 2000 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 2001 April 1992. 2003 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext 2004 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 2006 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 2008 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 2009 April 2011. 2011 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 2012 Distribution Network Interconnection (CDNI) Problem 2013 Statement", RFC 6707, September 2012. 2015 [RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, 2016 K., and G. Watson, "Use Cases for Content Delivery Network 2017 Interconnection", RFC 6770, November 2012. 2019 [RFC6983] van Brandenburg, R., van Deventer, O., Le Faucheur, F., 2020 and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware 2021 Content Distribution Network Interconnection (CDNI)", RFC 2022 6983, July 2013. 2024 Authors' Addresses 2026 Francois Le Faucheur (editor) 2027 Cisco Systems 2028 E.Space Park - Batiment D 2029 6254 Allee des Ormes - BP 1200 2030 Mougins cedex 06254 2031 FR 2033 Phone: +33 4 97 23 26 19 2034 Email: flefauch@cisco.com 2036 Gilles Bertrand (editor) 2037 Orange 2038 38-40 rue du General Leclerc 2039 Issy les Moulineaux 92130 2040 FR 2042 Phone: +33 1 45 29 89 46 2043 Email: gilles.bertrand@orange.com 2045 Iuniana Oprescu (editor) 2046 Orange 2047 38-40 rue du General Leclerc 2048 Issy les Moulineaux 92130 2049 FR 2051 Phone: +33 6 89 06 92 72 2052 Email: iuniana.oprescu@orange.com 2054 Roy Peterkofsky 2055 Skytide, Inc. 2056 One Kaiser Plaza, Suite 785 2057 Oakland CA 94612 2058 USA 2060 Phone: +01 510 250 4284 2061 Email: roy@skytide.com