idnits 2.17.1 draft-ietf-cdni-logging-19.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 2510 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 4, 2015) is 3213 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) == Unused Reference: 'RFC5288' is defined on line 2367, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-httpbis-http2' is defined on line 2416, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** 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-09 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 11 errors (**), 0 flaws (~~), 5 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: January 5, 2016 I. Oprescu, Ed. 6 Orange 7 R. Peterkofsky 8 Skytide, Inc. 9 July 4, 2015 11 CDNI Logging Interface 12 draft-ietf-cdni-logging-19 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 January 5, 2016. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction 58 1.1. Terminology 59 1.2. Requirements Language 60 2. CDNI Logging Reference Model 61 2.1. CDNI Logging interactions 62 2.2. Overall Logging Chain 63 2.2.1. Logging Generation and During-Generation Aggregation 64 2.2.2. Logging Collection 65 2.2.3. Logging Filtering 66 2.2.4. Logging Rectification and Post-Generation Aggregation 67 2.2.5. Log-Consuming Applications 68 2.2.5.1. Maintenance/Debugging 69 2.2.5.2. Accounting 70 2.2.5.3. Analytics and Reporting 71 2.2.5.4. Content Protection 72 2.2.5.5. Notions common to multiple Log Consuming 73 Applications 74 3. CDNI Logging File 75 3.1. Rules 76 3.2. CDNI Logging File Structure 77 3.3. CDNI Logging Directives 78 3.4. CDNI Logging Records 79 3.4.1. HTTP Request Logging Record 80 3.5. CDNI Logging File Example 81 3.6. Cascaded CDNI Logging Files Example 82 4. Protocol for Exchange of CDNI Logging File After Full 83 Collection 84 4.1. CDNI Logging Feed 85 4.1.1. Atom Formatting 86 4.1.2. Updates to Log Files and the Feed 87 4.1.3. Redundant Feeds 88 4.1.4. Example CDNI Logging Feed 89 4.2. CDNI Logging File Pull 90 5. Protocol for Exchange of CDNI Logging File During Collection 91 6. IANA Considerations 92 6.1. CDNI Logging Directive Names Registry 93 6.2. CDNI Logging File version Registry 94 6.3. CDNI Logging record-types Registry 95 6.4. CDNI Logging Field Names Registry 96 6.5. CDNI Logging MIME Media Type 97 7. Security Considerations 98 7.1. Authentication, Authorization, Confidentiality, Integrity 99 Protection 100 7.2. Denial of Service 101 7.3. Privacy 102 8. Acknowledgments 103 9. References 104 9.1. Normative References 105 9.2. Informative References 106 Authors' Addresses 108 1. Introduction 110 This memo specifies the CDNI Logging interface between a downstream 111 CDN (dCDN) and an upstream CDN (uCDN). First, it describes a 112 reference model for CDNI logging. Then, it specifies the CDNI 113 Logging File format and the actual protocol for exchange of CDNI 114 Logging Files. 116 The reader should be familiar with the following documents: 118 o CDNI problem statement [RFC6707] and framework [RFC7336] identify 119 a Logging interface, 121 o Section 8 of [RFC7337] specifies a set of requirements for 122 Logging, 124 o [RFC6770] outlines real world use-cases for interconnecting CDNs. 125 These use cases require the exchange of Logging information 126 between the dCDN and the uCDN. 128 As stated in [RFC6707], "the CDNI Logging interface enables details 129 of logs or events to be exchanged between interconnected CDNs". 131 The present document describes: 133 o The CDNI Logging reference model (Section 2), 135 o The CDNI Logging File format (Section 3), 137 o The CDNI Logging File Exchange protocol (Section 4). 139 1.1. Terminology 141 In this document, the first letter of each CDNI-specific term is 142 capitalized. We adopt the terminology described in [RFC6707] and 143 [RFC7336], and extend it with the additional terms defined below. 145 Intra-CDN Logging information: logging information generated and 146 collected within a CDN. The format of the Intra-CDN Logging 147 information may be different to the format of the CDNI Logging 148 information. 150 CDNI Logging information: logging information exchanged across CDNs 151 using the CDNI Logging Interface. 153 Logging information: logging information generated and collected 154 within a CDN or obtained from another CDN using the CDNI Logging 155 Interface. 157 CDNI Logging Field: an atomic element of information that can be 158 included in a CDNI Logging Record. The time an event/task started, 159 the IP address of an End User to whom content was delivered, and the 160 Uniform Resource Identifier (URI) of the content delivered, are 161 examples of CDNI Logging fields. 163 CDNI Logging Record: an information record providing information 164 about a specific event. This comprises a collection of CDNI Logging 165 fields. 167 CDNI Logging File: a file containing CDNI Logging Records, as well as 168 additional information facilitating the processing of the CDNI 169 Logging Records. 171 CDN Reporting: the process of providing the relevant information that 172 will be used to create a formatted content delivery report provided 173 to the CSP in deferred time. Such information typically includes 174 aggregated data that can cover a large period of time (e.g., from 175 hours to several months). Uses of Reporting include the collection 176 of charging data related to CDN services and the computation of Key 177 Performance Indicators (KPIs). 179 CDN Monitoring: the process of providing or displaying content 180 delivery information in a timely fashion with respect to the 181 corresponding deliveries. Monitoring typically includes visibility 182 of the deliveries in progress for service operation purposes. It 183 presents a view of the global health of the services as well as 184 information on usage and performance, for network services 185 supervision and operation management. In particular, monitoring data 186 can be used to generate alarms. 188 1.2. Requirements Language 190 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 191 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 192 document are to be interpreted as described in RFC 2119 [RFC2119]. 194 2. CDNI Logging Reference Model 196 2.1. CDNI Logging interactions 198 The CDNI logging reference model between a given uCDN and a given 199 dCDN involves the following interactions: 201 o customization by the uCDN of the CDNI Logging information to be 202 provided by the dCDN to the uCDN (e.g., control of which CDNI 203 Logging fields are to be communicated to the uCDN for a given task 204 performed by the dCDN or control of which types of events are to 205 be logged). The dCDN takes into account this CDNI Logging 206 customization information to determine what Logging information to 207 provide to the uCDN, but it may, or may not, take into account 208 this CDNI Logging customization information to influence what CDN 209 logging information is to be generated and collected within the 210 dCDN (e.g., even if the uCDN requests a restricted subset of the 211 logging information, the dCDN may elect to generate a broader set 212 of logging information). The mechanism to support the 213 customization by the uCDN of CDNI Logging information is outside 214 the scope of this document and left for further study. Until such 215 a mechanism is available, the uCDN and dCDN are expected to agree 216 off-line on what exact set of CDNI Logging information is to be 217 provided by the dCDN to the uCDN, and to rely on management plane 218 actions to configure the CDNI Logging functions in the dCDN to 219 generate this information set and in the uCDN to expect this 220 information set. 222 o generation and collection by the dCDN of the intra-CDN Logging 223 information related to the completion of any task performed by the 224 dCDN on behalf of the uCDN (e.g., delivery of the content to an 225 End User) or related to events happening in the dCDN that are 226 relevant to the uCDN (e.g., failures or unavailability in dCDN). 227 This takes place within the dCDN and does not directly involve 228 CDNI interfaces. 230 o communication by the dCDN to the uCDN of the Logging information 231 collected by the dCDN relevant to the uCDN. This is supported by 232 the CDNI Logging interface and in the scope of the present 233 document. For example, the uCDN may use this Logging information 234 to charge the CSP, to perform analytics and monitoring for 235 operational reasons, to provide analytics and monitoring views on 236 its content delivery to the CSP or to perform trouble-shooting. 237 This document exclusively specifies non-real-time exchange of 238 Logging information. Closer to real-time exchange of Logging 239 information (say sub-minute or sub-second) is outside the scope of 240 the present document and left for further study. This document 241 exclusively specifies exchange of Logging information related to 242 content delivery. Exchange of Logging information related to 243 operational events (e.g., dCDN request routing function 244 unavailable, content acquisition failure by dCDN) for audit or 245 operational reactive adjustments by uCDN is outside the scope of 246 the present document and left for further study. 248 o customization by the dCDN of the CDNI Logging information to be 249 provided by the uCDN on behalf of the dCDN. The mechanism to 250 support the customization by the dCDN of CDNI Logging information 251 is outside the scope of this document and left for further study. 253 o generation and collection by the uCDN of Intra-CDN Logging 254 information related to the completion of any task performed by the 255 uCDN on behalf of the dCDN (e.g., serving of content by uCDN to 256 dCDN for acquisition purposes by dCDN) or related to events 257 happening in the uCDN that are relevant to the dCDN. This takes 258 place within the uCDN and does not directly involve CDNI 259 interfaces. 261 o communication by the uCDN to the dCDN of the Logging information 262 collected by the uCDN relevant to the dCDN. For example, the dCDN 263 might potentially benefit from this information for security 264 auditing or content acquisition troubleshooting. This is outside 265 the scope of this document and left for further study. 267 Figure 1 provides an example of CDNI Logging interactions (focusing 268 only on the interactions that are in the scope of this document) in a 269 particular scenario where four CDNs are involved in the delivery of 270 content from a given CSP: the uCDN has a CDNI interconnection with 271 dCDN-1 and dCDN-2. In turn, dCDN-2 has a CDNI interconnection with 272 dCDN-3, where dCDN-2 is acting as an upstream CDN relative to dCDN-3. 273 In this example, uCDN, dCDN-1, dCDN-2 and dCDN-3 all participate in 274 the delivery of content for the CSP. In this example, the CDNI 275 Logging interface enables the uCDN to obtain Logging information from 276 all the dCDNs involved in the delivery. In the example, the uCDN 277 uses the Logging information: 279 o to analyze the performance of the delivery performed by the dCDNs 280 and to adjust its operations after the fact (e.g., request 281 routing) as appropriate, 283 o to provide (non-real-time) reporting and monitoring information to 284 the CSP. 286 For instance, the uCDN merges Logging information, extracts relevant 287 KPIs, and presents a formatted report to the CSP, in addition to a 288 bill for the content delivered by uCDN itself or by its dCDNs on the 289 CSP's behalf. The uCDN may also provide Logging information as raw 290 log files to the CSP, so that the CSP can use its own logging 291 analysis tools. 293 +-----+ 294 | CSP | 295 +-----+ 296 ^ Reporting and monitoring data 297 * Billing 298 ,--*--. 299 Logging ,-' `-. 300 Data =>( uCDN )<= Logging 301 // `-. _,-' \\ Data 302 || `-'-'-' || 303 ,-----. ,-----. 304 ,-' `-. ,-' `-. 305 ( dCDN-1 ) ( dCDN-2 )<== Logging 306 `-. ,-' `-. _,-' \\ Data 307 `--'--' `--'-' || 308 ,-----. 309 ,' `-. 310 ( dCDN-3 ) 311 `. ,-' 312 `--'--' 314 ===> CDNI Logging Interface 315 ***> outside the scope of CDNI 317 Figure 1: Interactions in CDNI Logging Reference Model 319 A downstream CDN relative to uCDN (e.g., dCDN-2) integrates the 320 relevant Logging information obtained from its own downstream CDNs 321 (i.e., dCDN-3) in the Logging information that it provides to the 322 uCDN, so that the uCDN ultimately obtains all Logging information 323 relevant to a CSP for which it acts as the authoritative CDN. Such 324 aggregation is further discussed in Section 3.6. 326 Note that the format of Logging information that a CDN provides over 327 the CDNI interface might be different from the one that the CDN uses 328 internally. In this case, the CDN needs to reformat the Logging 329 information before it provides this information to the other CDN over 330 the CDNI Logging interface. Similarly, a CDN might reformat the 331 Logging information that it receives over the CDNI Logging interface 332 before injecting it into its log-consuming applications or before 333 providing some of this Logging information to the CSP. Such 334 reformatting operations introduce latency in the logging distribution 335 chain and introduce a processing burden. Therefore, there are 336 benefits in specifying CDNI Logging formats that are suitable for use 337 inside CDNs and also are close to the intra-CDN Logging formats 338 commonly used in CDNs today. 340 2.2. Overall Logging Chain 342 This section discusses the overall logging chain within and across 343 CDNs to clarify how CDN Logging information is expected to fit in 344 this overall chain. Figure 2 illustrates the overall logging chain 345 within the dCDN, across CDNs using the CDNI Logging interface and 346 within the uCDN. Note that the logging chain illustrated in the 347 Figure is obviously only an example and varies depending on the 348 specific environments. For example, there may be more or fewer 349 instantiations of each entity (e.g., there may be 4 Log consuming 350 applications in a given CDN). As another example, there may be one 351 instance of Rectification process per Log Consuming Application 352 instead of a shared one. 354 Log Consuming Log Consuming 355 App App 356 ^ ^ 357 | | 358 Rectification---------- 359 ^ 360 | 361 Filtering 362 ^ 363 | 364 Collection 365 ^ ^ 366 | | 367 | Generation 368 | 369 | uCDN 370 CDNI Logging --------------------------------------------------- 371 exchange dCDN 372 ^ 373 | Log Consuming Log Consuming 374 | App App 375 | ^ ^ 376 | | | 377 Rectification Rectification--------- 378 ^ ^ 379 | | 380 Filtering 381 ^ 382 | 383 Collection 384 ^ ^ 385 | | 386 Generation Generation 388 Figure 2: CDNI Logging in the overall Logging Chain 390 The following subsections describe each of the processes potentially 391 involved in the logging chain of Figure 2. 393 2.2.1. Logging Generation and During-Generation Aggregation 395 CDNs typically generate Logging information for all significant task 396 completions, events, and failures. Logging information is typically 397 generated by many devices in the CDN including the surrogates, the 398 request routing system, and the control system. 400 The amount of Logging information generated can be huge. Therefore, 401 during contract negotiations, interconnected CDNs often agree on a 402 retention duration for Logging information, and/or potentially on a 403 maximum volume of Logging information that the dCDN ought to keep. 404 If this volume is exceeded, the dCDN is expected to alert the uCDN 405 but may not keep more Logging information for the considered time 406 period. In addition, CDNs may aggregate Logging information and 407 transmit only summaries for some categories of operations instead of 408 the full Logging information. Note that such aggregation leads to an 409 information loss, which may be problematic for some usages of the 410 Logging information (e.g., debugging). 412 [RFC6983] discusses logging for HTTP Adaptive Streaming (HAS). In 413 accordance with the recommendations articulated there, it is expected 414 that a surrogate will generate separate Logging information for 415 delivery of each chunk of HAS content. This ensures that separate 416 Logging information can then be provided to interconnected CDNs over 417 the CDNI Logging interface. Still in line with the recommendations 418 of [RFC6983], the Logging information for per-chunk delivery may 419 include some information (a Content Collection IDentifier and a 420 Session IDentifier) intended to facilitate subsequent post-generation 421 aggregation of per-chunk logs into per-session logs. Note that a CDN 422 may also elect to generate aggregate per-session logs when performing 423 HAS delivery, but this needs to be in addition to, and not instead 424 of, the per-chunk delivery logs. We note that aggregate per-session 425 logs for HAS delivery are for further study and outside the scope of 426 this document. 428 2.2.2. Logging Collection 430 This is the process that continuously collects Logging information 431 generated by the log-generating entities within a CDN. 433 In a CDNI environment, in addition to collecting Logging information 434 from log-generating entities within the local CDN, the Collection 435 process also collects Logging information provided by another CDN, or 436 other CDNs, through the CDNI Logging interface. This is illustrated 437 in Figure 2 where we see that the Collection process of the uCDN 438 collects Logging information from log-generating entities within the 439 uCDN as well as Logging information coming from the dCDNs through the 440 CDNI Logging interface. 442 2.2.3. Logging Filtering 444 A CDN may be required to only present different subsets of the whole 445 Logging information collected to various log-consuming applications. 446 This is achieved by the Filtering process. 448 In particular, the Filtering process can also filter the right subset 449 of Logging information that needs to be provided to a given 450 interconnected CDN. For example, the filtering process in the dCDN 451 can be used to ensure that only the Logging information related to 452 tasks performed on behalf of a given uCDN are made available to that 453 uCDN (thereby filtering out all the Logging information related to 454 deliveries by the dCDN of content for its own CSPs). Similarly, the 455 Filtering process may filter or partially mask some fields, for 456 example, to protect End Users' privacy when communicating CDNI 457 Logging information to another CDN. Filtering of Logging information 458 prior to communication of this information to other CDNs via the CDNI 459 Logging interface requires that the downstream CDN can recognize the 460 subset of Logging information that relate to each interconnected CDN. 462 The CDN will also filter some internal scope information such as 463 information related to its internal alarms (security, failures, load, 464 etc). 466 In some use cases described in [RFC6770], the interconnected CDNs do 467 not want to disclose details on their internal topology. The 468 filtering process can then also filter confidential data on the 469 dCDNs' topology (number of servers, location, etc.). In particular, 470 information about the requests served by each Surrogate may be 471 confidential. Therefore, the Logging information needs to be 472 protected so that data such as Surrogates' hostnames are not 473 disclosed to the uCDN. In the "Inter-Affiliates Interconnection" use 474 case, this information may be disclosed to the uCDN because both the 475 dCDN and the uCDN are operated by entities of the same group. 477 2.2.4. Logging Rectification and Post-Generation Aggregation 479 If Logging information is generated periodically, it is important 480 that the sessions that start in one Logging period and end in another 481 are correctly reported. If they are reported in the starting period, 482 then the Logging information of this period will be available only 483 after the end of the session, which delays the Logging information 484 generation. A simple approach is to provide the complete Logging 485 Record for a session in the Logging Period of the session end. 487 A Logging rectification/update mechanism could be useful to reach a 488 good trade-off between the Logging information generation delay and 489 the Logging information accuracy. 491 In the presence of HAS, some log-consuming applications can benefit 492 from aggregate per-session logs. For example, for analytics, per- 493 session logs allow display of session-related trends which are much 494 more meaningful for some types of analysis than chunk-related trends. 495 In the case where aggregate logs have been generated directly by the 496 log-generating entities, those can be used by the applications. In 497 the case where aggregate logs have not been generated, the 498 Rectification process can be extended with a Post-Generation 499 Aggregation process that generates per-session logs from the per- 500 chunk logs, possibly leveraging the information included in the per- 501 chunk logs for that purpose (Content Collection IDentifier and a 502 Session IDentifier). However, in accordance with [RFC6983], this 503 document does not define exchange of such aggregate logs on the CDNI 504 Logging interface. We note that this is for further study and 505 outside the scope of this document. 507 2.2.5. Log-Consuming Applications 509 2.2.5.1. Maintenance/Debugging 511 Logging information is useful to permit the detection (and limit the 512 risk) of content delivery failures. In particular, Logging 513 information facilitates the detection of configuration issues. 515 To detect faults, Logging information needs to report success and 516 failure of CDN delivery operations. The uCDN can summarize such 517 information into KPIs. For instance, Logging information needs to 518 allow the computation of the number of times, during a given time 519 period, that content delivery related to a specific service succeeds/ 520 fails. 522 Logging information enables the CDN providers to identify and 523 troubleshoot performance degradations. In particular, Logging 524 information enables tracking of traffic data (e.g., the amount of 525 traffic that has been forwarded by a dCDN on behalf of an uCDN over a 526 given period of time), which is particularly useful for CDN and 527 network planning operations. 529 Some of these maintenance and debugging applications only require 530 aggregate logging information highly compatible with anonymization of 531 IP addresses (as supported by the present document and specified in 532 Section 3.4.1). However, in some situations, it may be useful, where 533 compatible with privacy protection, to access some CDNI Logging 534 Records containing full non-anonymized IP addresses. For example, 535 this may be useful for detailed fault tracking of a particular end 536 user content delivery issue. 538 2.2.5.2. Accounting 540 Logging information is essential for accounting, to permit inter-CDN 541 billing and CSP billing by uCDNs. For instance, Logging information 542 provided by dCDNs enables the uCDN to compute the total amount of 543 traffic delivered by every dCDN for a particular Content Provider, as 544 well as, the associated bandwidth usage (e.g., peak, 95th 545 percentile), and the maximum number of simultaneous sessions over a 546 given period of time. 548 2.2.5.3. Analytics and Reporting 550 The goal of analytics is to gather any relevant information to track 551 audience, analyze user behavior, and monitor the performance and 552 quality of content delivery. For instance, Logging information 553 enables the CDN providers to report on content consumption (e.g., 554 delivered sessions per content) in a specific geographic area. 556 The goal of reporting is to gather any relevant information to 557 monitor the performance and quality of content delivery and allow 558 detection of delivery issues. For instance, reporting could track 559 the average delivery throughput experienced by End Users in a given 560 region for a specific CSP or content set over a period of time. 562 2.2.5.4. Content Protection 564 The goal of content protection is to prevent and monitor unauthorized 565 access, misuse, modification, and denial of access to a content. A 566 set of information is logged in a CDN for security purposes. In 567 particular, a record of access to content is usually collected to 568 permit the CSP to detect infringements of content delivery policies 569 and other abnormal End User behaviors. 571 2.2.5.5. Notions common to multiple Log Consuming Applications 573 2.2.5.5.1. Logging Information Views 575 Within a given log-consuming application, different views may be 576 provided to different users depending on privacy, business, and 577 scalability constraints. 579 For example, an analytics tool run by the uCDN can provide one view 580 to an uCDN operator that exploits all the Logging information 581 available to the uCDN, while the tool may provide a different view to 582 each CSP exploiting only the Logging information related to the 583 content of the given CSP. 585 As another example, maintenance and debugging tools may provide 586 different views to different CDN operators, based on their 587 operational role. 589 2.2.5.5.2. Key Performance Indicators (KPIs) 591 This section presents, for explanatory purposes, a non-exhaustive 592 list of Key Performance Indicators (KPIs) that can be extracted/ 593 produced from logs. 595 Multiple log-consuming applications, such as analytics, monitoring, 596 and maintenance applications, often compute and track such KPIs. 598 In a CDNI environment, depending on the situation, these KPIs may be 599 computed by the uCDN or by the dCDN. But it is usually the uCDN that 600 computes KPIs, because the uCDN and dCDN may have different 601 definitions of the KPIs and the computation of some KPIs requires a 602 vision of all the deliveries performed by the uCDN and all its dCDNs. 604 Here is a list of important examples of KPIs: 606 o Number of delivery requests received from End Users in a given 607 region for each piece of content, during a given period of time 608 (e.g., hour/day/week/month) 610 o Percentage of delivery successes/failures among the aforementioned 611 requests 613 o Number of failures listed by failure type (e.g., HTTP error code) 614 for requests received from End Users in a given region and for 615 each piece of content, during a given period of time (e.g., 616 hour/day/week/month) 618 o Number and cause of premature delivery termination for End Users 619 in a given region and for each piece of content, during a given 620 period of time (e.g., hour/day/week/month) 622 o Maximum and mean number of simultaneous sessions established by 623 End Users in a given region, for a given Content Provider, and 624 during a given period of time (e.g., hour/day/week/month) 626 o Volume of traffic delivered for sessions established by End Users 627 in a given region, for a given Content Provider, and during a 628 given period of time (e.g., hour/day/week/month) 630 o Maximum, mean, and minimum delivery throughput for sessions 631 established by End Users in a given region, for a given Content 632 Provider, and during a given period of time (e.g., hour/day/week/ 633 month) 635 o Cache-hit and byte-hit ratios for requests received from End Users 636 in a given region for each piece of content, during a given period 637 of time (e.g., hour/day/week/month) 639 o Top 10 most popularly requested contents (during a given day/week/ 640 month) 642 o Terminal type (mobile, PC, STB, if this information can be 643 acquired from the browser type inferred from the User Agent 644 string, for example). 646 Additional KPIs can be computed from other sources of information 647 than the Logging information, for instance, data collected by a 648 content portal or by specific client-side application programming 649 interfaces. Such KPIs are out of scope for the present document. 651 The KPIs used depend strongly on the considered log-consuming 652 application -- the CDN operator may be interested in different 653 metrics than the CSP is. In particular, CDN operators are often 654 interested in delivery and acquisition performance KPIs, information 655 related to Surrogates' performance, caching information to evaluate 656 the cache-hit ratio, information about the delivered file size to 657 compute the volume of content delivered during peak hour, etc. 659 Some of the KPIs, for instance those providing an instantaneous 660 vision of the active sessions for a given CSP's content, are useful 661 essentially if they are provided in a timely manner. By contrast, 662 some other KPIs, such as those averaged on a long period of time, can 663 be provided in non-real-time. 665 3. CDNI Logging File 667 3.1. Rules 669 This specification uses the Augmented Backus-Naur Form (ABNF) 670 notation and core rules of [RFC5234]. In particular, the present 671 document uses the following rules from [RFC5234]: 673 CR = %x0D ; carriage return 675 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z 677 DIGIT = %x30-39 ; 0-9 679 DQUOTE = %x22 ; " (Double Quote) 681 CRLF = CR LF ; Internet standard newline 683 HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" 685 HTAB = %x09 ; horizontal tab 687 LF = %x0A ; linefeed 689 VCHAR = %x21-7E ; visible (printing) characters 691 OCTET = %x00-FF ; 8 bits of data 693 The present document also uses the following rules from [RFC3986]: 695 host = as specified in section 3.2.2 of [RFC3986]. 697 IPv4address = as specified in section 3.2.2 of [RFC3986]. 699 IPv6address = as specified in section 3.2.2 of [RFC3986]. 701 The present document also defines the following additional rules: 703 ADDRESS = IPv4address / IPv6address 705 ALPHANUM = ALPHA / DIGIT 707 DATE = 4DIGIT "-" 2DIGIT "-" 2DIGIT 709 ; Dates are encoded as "full-date" specified in [RFC3339]. 711 DEC = 1*DIGIT ["." *DIGIT] 713 NAMEFORMAT = ALPHANUM *(ALPHANUM / "_" / "-") 715 QSTRING = DQUOTE *(NDQUOTE / PCT-ENCODED) DQUOTE 717 NDQUOTE = %x21 / %x23-24 / %x26-7E / (DQUOTE DQUOTE) 719 ; whereby a DQUOTE is conveyed inside a QSTRING unambiguously 720 by escaping it with PCT-ENCODED. 722 PCT-ENCODED = "%" HEXDIG HEXDIG 724 ; percent encoding is used for escaping octets that might be 725 possible in HTTP headers such as bare CR, bare LF, CR LF, HTAB, 726 SP or null. These octets are rendered with percent encoding in 727 ABNF as specified by [RFC3986] in order to avoid considering 728 them as separators for the logging records. 730 NHTABSTRING = *(SP / VCHAR) 732 TIME = 2DIGIT ":" 2DIGIT ":" 2DIGIT ["." *DIGIT] 734 ; Times are encoded as "partial-time" specified in [RFC3339]. 736 USER-COMMENT = * (SP / VCHAR / UTF8-2 / UTF8-3 / UTF8-4) 738 3.2. CDNI Logging File Structure 740 As defined in Section 1.1: a CDNI Logging Field is as an atomic 741 logging information element, a CDNI Logging Record is a collection of 742 CDNI Logging fields containing all logging information corresponding 743 to a single logging event, and a CDNI Logging File contains a 744 collection of CDNI Logging Records. This structure is illustrated in 745 Figure 3. The use of a file structure for transfer of CDNI Logging 746 information is selected since this is the most common practise today 747 for exchange of logging information within and across CDNs. 749 +----------------------------------------------------------+ 750 |CDNI Logging File | 751 | | 752 | #Directive 1 | 753 | #Directive 2 | 754 | ... | 755 | #Directive P | 756 | | 757 | +------------------------------------------------------+ | 758 | |CDNI Logging Record 1 | | 759 | | +-------------+ +-------------+ +-------------+ | | 760 | | |CDNI Logging | |CDNI Logging | ... |CDNI Logging | | | 761 | | | Field 1 | | Field 2 | | Field N | | | 762 | | +-------------+ +-------------+ +-------------+ | | 763 | +------------------------------------------------------+ | 764 | | 765 | +------------------------------------------------------+ | 766 | |CDNI Logging Record 2 | | 767 | | +-------------+ +-------------+ +-------------+ | | 768 | | |CDNI Logging | |CDNI Logging | ... |CDNI Logging | | | 769 | | | Field 1 | | Field 2 | | Field N | | | 770 | | +-------------+ +-------------+ +-------------+ | | 771 | +------------------------------------------------------+ | 772 | | 773 | ... | 774 | | 775 | #Directive P+1 | 776 | | 777 | ... | 778 | | 779 | +------------------------------------------------------+ | 780 | |CDNI Logging Record M | | 781 | | +-------------+ +-------------+ +-------------+ | | 782 | | |CDNI Logging | |CDNI Logging | ... |CDNI Logging | | | 783 | | | Field 1 | | Field 2 | | Field N | | | 784 | | +-------------+ +-------------+ +-------------+ | | 785 | +------------------------------------------------------+ | 786 | | 787 | | 788 | #Directive P+Q | 789 +----------------------------------------------------------+ 791 Figure 3: Structure of Logging Files 793 The CDNI Logging File format is inspired from the W3C Extended Log 794 File Format [ELF]. However, it is fully specified by the present 795 document. Where the present document differs from the W3C Extended 796 Log File Format, an implementation of the CDNI Logging interface MUST 797 comply with the present document. The W3C Extended Log File Format 798 was used as a starting point, reused where possible and expanded when 799 necessary. 801 Using a format that resembles the W3C Extended Log File Format is 802 intended to keep CDNI logging format close to the intra-CDN Logging 803 information format commonly used in CDNs today, thereby minimizing 804 systematic translation at CDN/CDNI boundary. 806 A CDNI Logging File MUST contain a sequence of lines containing US- 807 ASCII characters [CHAR_SET] terminated by CRLF. Each line of a CDNI 808 Logging File MUST contain either a directive or a CDNI Logging 809 Record. 811 Directives record information about the CDNI Logging process itself. 812 Lines containing directives MUST begin with the "#" character. 813 Directives are specified in Section 3.3. 815 Logging Records provide actual details of the logged event. Logging 816 Records are specified in Section 3.4. 818 The CDNI Logging File has a specific structure. It always starts 819 with a directive line and the first directive it contains MUST be the 820 version. 822 The directive lines form together a group that contains at least one 823 directive line. Each directives group is followed by a group of 824 logging records. The records group contains zero or more actual 825 logging record lines about the event being logged. A record line 826 consists of the values corresponding to all or a subset of the 827 possible Logging fields defined within the scope of the record-type 828 directive. These values MUST appear in the order defined by the 829 fields directive. 831 Note that future extensions MUST be compliant with the previous 832 description. The following examples depict the structure of a 833 CDNILOGFILE as defined currently by the record-type 834 "cdni_http_request_v1." The record line in this example enumerates 835 strictly what is presently defined in the fields directive of the 836 record-type "cdni_http_request_v1." 838 DIRLINE = "#" directive CRLF 840 DIRGROUP = 1*DIRLINE 842 RECLINE = 1* ([date HTAB] [time HTAB] [time-taken HTAB] [c-ip 843 HTAB] [c-ip-anonymizing HTAB] [c-port HTAB] [s-ip HTAB] 844 [s-hostname HTAB] [s-port HTAB] [cs-method HTAB] [cs-uri HTAB] 845 [u-uri HTAB] [protocol HTAB] [sc-status HTAB] [sc-total-bytes 846 HTAB] [sc-entity-bytes HTAB] [cs(insert_HTTP_header_name_here) 847 HTAB] [sc(insert_HTTP_header_name_here) HTAB] [s-ccid HTAB] 848 [s-sid HATB] [s-cached HTAB]) CRLF 850 RECGROUP = *RECLINE 852 CDNILOGFILE = 1*(DIRGROUP RECGROUP) 854 All directive names and field names defined in the logging file are 855 case-insensitive as per the basic ABNF([RFC2234]). 857 3.3. CDNI Logging Directives 859 A CDNI Logging directive line contains the directive name followed by 860 ":" HTAB and the directive value. 862 Directive names MUST be of the format NAMEFORMAT. All directive 863 names MUST be registered in the CDNI Logging Directives Names 864 registry. Unknown directives MUST be ignored. Directive values can 865 have various formats. All possible directive values for the record- 866 type "cdni_http_request_v1" are further detailed in this section. 868 The following example shows the structure of a directive and 869 enumerates strictly the directive values presently defined in the 870 record-type "cdni_http_request_v1." 872 directive = DIRNAME ":" HTAB DIRVAL 874 DIRNAME = NAMEFORMAT 876 DIRVAL = NHTABSTRING / QSTRING / host / USER-COMMENT / FIENAME * 877 (HTAB FIENAME) / 64HEXDIG 879 An implementation of the CDNI Logging interface MUST support all of 880 the following directives, listed below by their directive name: 882 o version: 884 * format: NHTABSTRING 886 * directive value: indicates the version of the CDNI Logging File 887 format. The entity transmitting a CDNI Logging File as per the 888 present document MUST set the value to "CDNI/1.0". In the 889 future, other versions of CDNI Logging File might be specified; 890 those would use a value different to "CDNI/1.0" allowing the 891 entity receiving the CDNI Logging File to identify the 892 corresponding version. 894 * occurrence: there MUST be one and only one instance of this 895 directive per CDNI Logging File. It MUST be the first line of 896 the CDNI Logging File. 898 * example: "version: HTAB CDNI/1.0". 900 o UUID: 902 * format: NHTABSTRING 904 * directive value: this a Uniform Resource Name (URN) from the 905 Universally Unique IDentifier (UUID) URN namespace specified in 906 [RFC4122]). The UUID contained in the URN uniquely identifies 907 the CDNI Logging File. 909 * occurrence: there MUST be one and only one instance of this 910 directive per CDNI Logging File. 912 * example: "UUID: HTAB NHTABSTRING". 914 o claimed-origin: 916 * format: host 918 * directive value: this contains the claimed identification of 919 the entity transmitting the CDNI Logging File (e.g., the host 920 in a dCDN supporting the CDNI Logging interface) or the entity 921 responsible for transmitting the CDNI Logging File (e.g., the 922 dCDN). 924 * occurrence: there MUST be zero or exactly one instance of this 925 directive per CDNI Logging File. This directive MAY be 926 included by the dCDN. It MUST NOT be included or modified by 927 the uCDN. 929 * example: "claimed-origin: HTAB host". 931 o established-origin: 933 * format: host 935 * directive value: this contains the identification, as 936 established by the entity receiving the CDNI Logging File, of 937 the entity transmitting the CDNI Logging File (e.g., the host 938 in a dCDN supporting the CDNI Logging interface) or the entity 939 responsible for transmitting the CDNI Logging File (e.g., the 940 dCDN). 942 * occurrence: there MUST be zero or exactly one instance of this 943 directive per CDNI Logging File. This directive MAY be added 944 by the uCDN (e.g., before storing the CDNI Logging File). It 945 MUST NOT be included by the dCDN. The mechanisms used by the 946 uCDN to establish and validate the entity responsible for the 947 CDNI Logging File is outside the scope of the present document. 948 We observe that, in particular, this may be achieved through 949 authentication mechanisms that are part of the transport layer 950 of the CDNI Logging File pull mechanism (Section 4.2). 952 * ABNF example: "established-origin: HTAB host". 954 o remark: 956 * format: USER-COMMENT 958 * directive value: this contains comment information. Data 959 contained in this field is to be ignored by analysis tools. 961 * occurrence: there MAY be zero, one or any number of instance of 962 this directive per CDNI Logging File. 964 * example: "remark: HTAB USER-COMMENT". 966 o record-type: 968 * format: NAMEFORMAT 970 * directive value: indicates the type of the CDNI Logging Records 971 that follow this directive, until another record-type directive 972 (or the end of the CDNI Logging File). This can be any CDNI 973 Logging Record type registered in the CDNI Logging Record-types 974 registry (Section 6.3). For example this may be 975 "cdni_http_request_v1" as specified in Section 3.4.1. 977 * occurrence: there MUST be at least one instance of this 978 directive per CDNI Logging File. The first instance of this 979 directive MUST precede a fields directive and MUST precede all 980 CDNI Logging Records. 982 * example: "record-type: HTAB cdni_http_request_v1". 984 o fields: 986 * format: FIENAME *(HTAB FIENAME) ; where FIENAME can take any 987 CDNI Logging field name registered in the CDNI Logging Field 988 Names registry (Section 6.4). 990 * directive value: this lists the names of all the fields for 991 which a value is to appear in the CDNI Logging Records that 992 follow the instance of this directive (until another instance 993 of this directive). The names of the fields, as well as their 994 occurrences, MUST comply with the corresponding rules specified 995 in the document referenced in the CDNI Logging Record-types 996 registry (Section 6.3) for the corresponding CDNI Logging 997 record-type. 999 * occurrence: there MUST be at least one instance of this 1000 directive per record-type directive. The first instance of 1001 this directive for a given record-type MUST appear before any 1002 CDNI Logging Record for this record-type. One situation where 1003 more than one instance of the fields directive can appear 1004 within a given CDNI Logging File, is when there is a change, in 1005 the middle of a fairly large logging period, in the agreement 1006 between the uCDN and the dCDN about the set of fields that are 1007 to be exchanged. The multiple occurrences allow records with 1008 the old set of fields and records with the new set of fields to 1009 be carried inside the same Logging File. 1011 * example: "fields: HTAB FIENAME * (HTAB FIENAME)". 1013 o SHA256-hash: 1015 * format: 64HEXDIG 1017 * directive value: This directive permits the detection of a 1018 corrupted CDNI Logging File. This can be useful, for instance, 1019 if a problem occurs on the filesystem of the dCDN Logging 1020 system and leads to a truncation of a logging file. The valid 1021 SHA256-hash value is included in this directive by the entity 1022 that transmits the CDNI Logging File. It MUST be computed by 1023 applying the SHA-256 ([RFC6234]) cryptographic hash function on 1024 the CDNI Logging File, including all the directives and logging 1025 records, up to the SHA256-hash directive itself, excluding the 1026 SHA256-hash directive itself. The SHA256-hash value MUST be 1027 represented as a US-ASCII encoded hexadecimal number, 64 digits 1028 long (representing a 256 bit hash value). The entity receiving 1029 the CDNI Logging File also computes in a similar way the 1030 SHA-256 hash on the received CDNI Logging File and compares 1031 this hash to the value of the SHA256-hash directive. If the 1032 two values are equal, then the received CDNI Logging File is to 1033 be considered non-corrupted. If the two values are different, 1034 the received CDNI Logging File is to be considered corrupted. 1035 The behavior of the entity that received a corrupted CDNI 1036 Logging File is outside the scope of this specification; we 1037 note that the entity MAY attempt to pull again the same CDNI 1038 Logging File from the transmitting entity. If the entity 1039 receiving a non-corrupted CDNI Logging File adds an 1040 established-origin directive, it MUST then recompute and update 1041 the SHA256-hash directive so it also protects the added 1042 established-origin directive. 1044 * occurrence: there MUST be zero or exactly one instance of this 1045 directive. There SHOULD be exactly one instance of this 1046 directive. One situation where that directive could be omitted 1047 is where integrity protection is already provided via another 1048 mechanism (for example if an integrity hash is associated to 1049 the CDNI Logging File out of band through the CDNI Logging Feed 1050 ( Section 4.1) leveraging ATOM extensions such as those 1051 proposed in [I-D.snell-atompub-link-extensions]. When present, 1052 the SHA256-hash field MUST be the last line of the CDNI Logging 1053 File. 1055 * example: "SHA256-hash: HTAB 64HEXDIG". 1057 An uCDN-side implementation of the CDNI Logging interface MUST reject 1058 a CDNI Logging File that does not comply with the occurrences 1059 specified above for each and every directive. For example, an uCDN- 1060 side implementation of the CDNI Logging interface receiving a CDNI 1061 Logging file with zero occurrence of the version directive, or with 1062 two occurrences of the SHA256-hash, MUST reject this CDNI Logging 1063 File. 1065 An entity receiving a CDNI Logging File with a value set to 1066 "CDNI/1.0" MUST process the CDNI Logging File as per the present 1067 document. An entity receiving a CDNI Logging File with a value set 1068 to a different value MUST process the CDNI Logging File as per the 1069 specification referenced in the CDNI Logging File version registry 1070 (see Section 6.1) if the implementation supports this specification 1071 and MUST reject the CDNI Logging File otherwise. 1073 3.4. CDNI Logging Records 1075 A CDNI Logging Record consists of a sequence of CDNI Logging fields 1076 relating to that single CDNI Logging Record. 1078 CDNI Logging fields MUST be separated by the "horizontal tabulation 1079 (HTAB)" character. 1081 To facilitate readability, a prefix scheme is used for CDNI Logging 1082 field names in a similar way to the one used in W3C Extended Log File 1083 Format [ELF]. The semantics of the prefix in the present document 1084 is: 1086 o "c-" refers to the User Agent that issues the request (corresponds 1087 to the "client" of W3C Extended Log Format) 1089 o "d-" refers to the dCDN (relative to a given CDN acting as a uCDN) 1091 o "s-" refers to the dCDN Surrogate that serves the request 1092 (corresponds to the "server" of W3C Extended Log Format) 1094 o "u-" refers to the uCDN (relative to a given CDN acting as a dCDN) 1096 o "cs-" refers to communication from the User Agent towards the dCDN 1097 Surrogate 1099 o "sc-" refers to communication from the dCDN Surrogate towards the 1100 User Agent 1102 An implementation of the CDNI Logging interface as per the present 1103 specification MUST support the CDNI HTTP Request Logging Record as 1104 specified in Section 3.4.1. 1106 A CDNI Logging Record contains the corresponding values for the 1107 fields that are enumerated in the last fields directive before the 1108 current log line. Note that the order in which the field values 1109 appear is dictated by the order of the fields names in the fields 1110 directive. There SHOULD be no dependency between the various fields 1111 values. 1113 3.4.1. HTTP Request Logging Record 1115 This section defines the CDNI Logging Record of record-type 1116 "cdni_http_request_v1". It is applicable to content delivery 1117 performed by the dCDN using HTTP/1.0([RFC1945]), 1118 HTTP/1.1([RFC7230],[RFC7231], [RFC7232], [RFC7233], [RFC7234], 1119 [RFC7235]) or HTTPS ([RFC2818], [RFC7230]). We observe that, in the 1120 case of HTTPS delivery, there may be value in logging additional 1121 information specific to the operation of HTTP over TLS and we note 1122 that this is outside the scope of the present document and may be 1123 addressed in a future document defining another CDNI Logging Record 1124 or another version of the HTTP Request Logging Record. 1126 The "cdni_http_request_v1" record-type is also expected to be 1127 applicable to HTTP/2 [RFC7540] since a fundamental design tenet of 1128 HTTP/2 is to preserve the HTTP/1.1 semantics. We observe that, in 1129 the case of HTTP/2 delivery, there may be value in logging additional 1130 information specific to the additional functionality of HTTP/2 (e.g. 1131 information related to connection identification, to stream 1132 identification, to stream priority and to flow control). We note 1133 that such additional information is outside the scope of the present 1134 document and may be addressed in a future document defining another 1135 CDNI Logging Record or another version of the HTTP Request Logging 1136 Record. 1138 The "cdni_http_request_v1" record-type contains the following CDNI 1139 Logging fields, listed by their field name: 1141 o date: 1143 * format: DATE 1145 * field value: the date at which the processing of request 1146 completed on the Surrogate. 1148 * occurrence: there MUST be one and only one instance of this 1149 field. 1151 o time: 1153 * format: TIME 1155 * field value: the time at which the processing of request 1156 completed on the Surrogate. 1158 * occurrence: there MUST be one and only one instance of this 1159 field. 1161 o time-taken: 1163 * format: DEC 1165 * field value: decimal value of the duration, in seconds, between 1166 the start of the processing of the request and the completion 1167 of the request processing (e.g., completion of delivery) by the 1168 Surrogate. 1170 * occurrence: there MUST be one and only one instance of this 1171 field. 1173 o c-ip: 1175 * format: ADDRESS 1177 * field value: the source IPv4 or IPv6 address (i.e., the 1178 "client" address) in the request received by the Surrogate. 1180 * occurrence: there MUST be one and only one instance of this 1181 field. 1183 o c-ip-anonymizing: 1185 * format: 1*DIGIT 1187 * field value: the number of rightmost bits of the address in the 1188 c-ip field that are zeroed-out in order to anonymize the 1189 logging record. The mechanism by which the two ends of the 1190 CDNI Logging interface agree on whether anonymization is to be 1191 supported and the number of bits that need to be zeroed-out for 1192 this purpose are outside the scope of the present document. 1193 IPv4 addresses SHOULD be anonymized to /24 boundary (i.e., with 1194 c-ip-anonymizing set to 8), and IPv6 addresses SHOULD be 1195 anonymized to a /48 boundary (i.e., with c-ip-anonymizing set 1196 to 80). 1198 * occurrence: there MUST be zero or exactly one instance of this 1199 field. 1201 o c-port: 1203 * format: 1*DIGIT 1205 * field value: the source TCP port (i.e., the "client" port) in 1206 the request received by the Surrogate. 1208 * occurrence: there MUST be zero or exactly one instance of this 1209 field. 1211 o c-port-anonymizing: 1213 * format: 1*DIGIT 1215 * field value: the number of rightmost bits of the port in the 1216 c-port field that are zeroed-out in order to anonymize the 1217 logging record. The mechanism by which the two ends of the 1218 CDNI Logging interface agree on whether anonymization is to be 1219 supported and the number of bits that need to be zeroed-out for 1220 this purpose are outside the scope of the present document. 1222 * occurrence: there MUST be zero or exactly one instance of this 1223 field. 1225 o s-ip: 1227 * format: ADDRESS 1229 * field value: the IPv4 or IPv6 address of the Surrogate that 1230 served the request (i.e., the "server" address). 1232 * occurrence: there MUST be zero or exactly one instance of this 1233 field. 1235 o s-hostname: 1237 * format: host 1239 * field value: the hostname of the Surrogate that served the 1240 request (i.e., the "server" hostname). 1242 * occurrence: there MUST be zero or exactly one instance of this 1243 field. 1245 o s-port: 1247 * format: 1*DIGIT 1249 * field value: the destination TCP port (i.e., the "server" port) 1250 in the request received by the Surrogate. 1252 * occurrence: there MUST be zero or exactly one instance of this 1253 field. 1255 o cs-method: 1257 * format: NHTABSTRING 1259 * field value: this is the method of the request received by the 1260 Surrogate. In the case of HTTP delivery, this is the HTTP 1261 method in the request. 1263 * occurrence: There MUST be one and only one instance of this 1264 field. 1266 o cs-uri: 1268 * format: NHTABSTRING 1270 * field value: this is the "effective request URI" of the request 1271 received by the Surrogate as specified in [RFC7230]. It 1272 complies with the "http" URI scheme or the "https" URI scheme 1273 as specified in [RFC7230]). Note that cs-uri can be privacy 1274 sensitive. In that case, and where appropriate, u-uri could be 1275 used instead of cs-uri. 1277 * occurrence: there MUST be zero or exactly one instance of this 1278 field. 1280 o u-uri: 1282 * format: NHTABSTRING 1284 * field value: this is a complete URI, derived from the 1285 "effective request URI" ([RFC7230]) of the request received by 1286 the Surrogate (i.e., the cs-uri) but transformed by the entity 1287 generating or transmitting the CDNI Logging Record, in a way 1288 that is agreed upon between the two ends of the CDNI Logging 1289 interface, so the transformed URI is meaningful to the uCDN. 1290 For example, the two ends of the CDNI Logging interface could 1291 agree that the u-uri is constructed from the cs-uri by removing 1292 the part of the hostname that exposes which individual 1293 Surrogate actually performed the delivery. The details of 1294 modification performed to generate the u-uri, as well as the 1295 mechanism to agree on these modifications between the two sides 1296 of the CDNI Logging interface are outside the scope of the 1297 present document. 1299 * occurrence: there MUST be one and only one instance of this 1300 field. 1302 o protocol: 1304 * format: NHTABSTRING 1306 * field value: this is value of the HTTP-Version field as 1307 specified in [RFC7230] of the Request-Line of the request 1308 received by the Surrogate (e.g., "HTTP/1.1"). 1310 * occurrence: there MUST be one and only one instance of this 1311 field. 1313 o sc-status: 1315 * format: 3DIGIT 1317 * field value: this is the Status-Code in the response from the 1318 Surrogate. In the case of HTTP delivery, this is the HTTP 1319 Status-Code in the HTTP response. 1321 * occurrence: There MUST be one and only one instance of this 1322 field. 1324 o sc-total-bytes: 1326 * format: 1*DIGIT 1328 * field value: this is the total number of bytes of the response 1329 sent by the Surrogate in response to the request. In the case 1330 of HTTP delivery, this includes the bytes of the Status-Line, 1331 the bytes of the HTTP headers and the bytes of the message- 1332 body. 1334 * occurrence: There MUST be one and only one instance of this 1335 field. 1337 o sc-entity-bytes: 1339 * format: 1*DIGIT 1341 * field value: this is the number of bytes of the message-body in 1342 the HTTP response sent by the Surrogate in response to the 1343 request. This does not include the bytes of the Status-Line or 1344 the bytes of the HTTP headers. 1346 * occurrence: there MUST be zero or exactly one instance of this 1347 field. 1349 o cs(insert_HTTP_header_name_here): 1351 * format: QSTRING 1353 * field value: the value of the HTTP header (identified by the 1354 insert_HTTP_header_name_here in the CDNI Logging field name) as 1355 it appears in the request processed by the Surrogate, but 1356 prepended by a DQUOTE and appended by a DQUOTE. For example, 1357 when the CDNI Logging field name (FIENAME) listed in the 1358 preceding fields directive is cs(User-Agent), this CDNI Logging 1359 field value contains the value of the User-Agent HTTP header as 1360 received by the Surrogate in the request it processed, but 1361 prepended by a DQUOTE and appended by a DQUOTE. If the HTTP 1362 header as it appeared in the request processed by the Surrogate 1363 contains one or more DQUOTE, each DQUOTE MUST be escaped with 1364 percent encoding. For example, if the HTTP header contains 1365 My_Header"value", then the field value of the 1366 cs(insert_HTTP_header_name_here) is "My_Header%x22value%x22". 1367 The entity transmitting the CDNI Logging File MUST ensure that 1368 the respective insert_HTTP_header_name_here of the 1369 cs(insert_HTTP_header_name_here) listed in the fields directive 1370 comply with HTTP specifications. In particular, this field 1371 name does not include any HTAB, since this would prevent proper 1372 parsing of the fields directive by the entity receiving the 1373 CDNI Logging File. 1375 * occurrence: there MAY be zero, one or any number of instance of 1376 this field. 1378 o sc(insert_HTTP_header_name_here): 1380 * format: QSTRING 1382 * field value: the value of the HTTP header (identified by the 1383 insert_HTTP_header_name_here in the CDNI Logging field name) as 1384 it appears in the response issued by the Surrogate to serve the 1385 request, but prepended by a DQUOTE and appended by a DQUOTE. 1386 If the HTTP header as it appeared in the request processed by 1387 the Surrogate contains one or more DQUOTE, each DQUOTE MUST be 1388 escaped with percent encoding. For example, if the HTTP header 1389 contains My_Header"value", then the field value of the 1390 sc(insert_HTTP_header_name_here) is "My_Header%x22value%x22". 1391 The entity transmitting the CDNI Logging File MUST ensure that 1392 the respective insert_HTTP_header_name_here of the 1393 cs(insert_HTTP_header_name_here) listed in the fields directive 1394 comply with HTTP specifications. In particular, this field 1395 name does not include any HTAB, since this would prevent proper 1396 parsing of the fields directive by the entity receiving the 1397 CDNI Logging File. 1399 * occurrence: there MAY be zero, one or any number of instances 1400 of this field. For a given insert_HTTP_header_name_here, there 1401 MUST be zero or exactly one instance of this field. 1403 o s-ccid: 1405 * format: QSTRING 1407 * field value: this contains the value of the Content Collection 1408 IDentifier (CCID) associated by the uCDN to the content served 1409 by the Surrogate via the CDNI Metadata interface 1410 ([I-D.ietf-cdni-metadata]), prepended by a DQUOTE and appended 1411 by a DQUOTE. If the CCID conveyed in the CDNI Metadata 1412 interface contains one or more DQUOTE, each DQUOTE MUST be 1413 escaped with percent encoding. For example, if the CCID 1414 conveyed in the CDNI Metadata interface is My_CCIDD"value", 1415 then the field value of the s-ccid is "My_CCID%x22value%X22". 1417 * occurrence: there MUST be zero or exactly one instance of this 1418 field. For a given insert_HTTP_header_name_here, there MUST be 1419 zero or exactly one instance of this field. 1421 o s-sid: 1423 * format: QSTRING 1425 * field value: this contains the value of a Session IDentifier 1426 (SID) generated by the dCDN for a specific HTTP session, 1427 prepended by a DQUOTE and appended by a DQUOTE. In particular, 1428 for HTTP Adaptive Streaming (HAS) session, the Session 1429 IDentifier value is included in the Logging record for every 1430 content chunk delivery of that session in view of facilitating 1431 the later correlation of all the per content chunk log records 1432 of a given HAS session. See section 3.4.2.2. of [RFC6983] for 1433 more discussion on the concept of Session IDentifier in the 1434 context of HAS. If the SID conveyed contains one or more 1435 DQUOTE, each DQUOTE MUST be escaped with percent encoding. For 1436 example, if the SID is My_SID"value", then the field value of 1437 the s-sid is "My_SID%x22value%x22". 1439 * occurrence: there MUST be zero or exactly one instance of this 1440 field. 1442 o s-cached: 1444 * format: 1DIGIT 1446 * field value: this characterises whether the Surrogate served 1447 the request using content already stored on its local cache or 1448 not. The allowed values are "0" (for miss) and "1" (for hit). 1449 "1" MUST be used when the Surrogate did serve the request using 1450 exclusively content already stored on its local cache. "0" MUST 1451 be used otherwise (including cases where the Surrogate served 1452 the request using some, but not all, content already stored on 1453 its local cache). Note that a "0" only means a cache miss in 1454 the Surrogate and does not provide any information on whether 1455 the content was already stored, or not, in another device of 1456 the dCDN, i.e., whether this was a "dCDN hit" or "dCDN miss". 1458 * occurrence: there MUST be zero or exactly one instance of this 1459 field. 1461 The "fields" directive corresponding to a HTTP Request Logging Record 1462 MUST contain all the fields names whose occurrence is specified above 1463 as "There MUST be one and only one instance of this field". The 1464 corresponding fields value MUST be present in every HTTP Request 1465 Logging Record. 1467 The "fields" directive corresponding to a HTTP Request Logging Record 1468 MAY list all the fields value whose occurrence is specified above as 1469 "there MUST be zero or exactly one instance of this field" or "there 1470 MAY be zero, one or any number of instances of this field". The set 1471 of such field names actually listed in the "fields" directive is 1472 selected by the CDN generating the CDNI Logging File based on 1473 agreements between the interconnected CDNs established through 1474 mechanisms outside the scope of this specification (e.g., contractual 1475 agreements). When such a field name is not listed in the "fields" 1476 directive, the corresponding field value MUST NOT be included in the 1477 Logging Record. When such a field name is listed in the "fields" 1478 directive, the corresponding field value MUST be included in the 1479 Logging Record; if the value for the field is not available, this 1480 MUST be conveyed via a dash character ("-"). 1482 The fields names listed in the "fields" directive MAY be listed in 1483 the order in which they are listed in Section 3.4.1 or MAY be listed 1484 in any other order. 1486 A dCDN-side implementation of the CDNI Logging interface MUST 1487 implement all the following Logging fields in a CDNI Logging Record 1488 of record-type "cdni_http_request_v1", and MUST support the ability 1489 to include valid values for each of them: 1491 o date 1493 o time 1495 o time-taken 1497 o c-ip 1499 o c-ip-anonymizing 1501 o c-port 1503 o c-port-anonymizing 1505 o s-ip 1507 o s-hostname 1509 o s-port 1511 o cs-method 1513 o cs-uri 1515 o u-uri 1517 o protocol 1519 o sc-status 1521 o sc-total-bytes 1523 o sc-entity-bytes 1525 o cs(insert_HTTP_header_name_here) 1527 o sc(insert_HTTP_header_name_here) 1529 o s-cached 1531 A dCDN-side implementation of the CDNI Logging interface MAY support 1532 the following Logging fields in a CDNI Logging Record of record-type 1533 "cdni_http_request_v1": 1535 o s-ccid 1537 o s-sid 1539 If a dCDN-side implementation of the CDNI Logging interface supports 1540 these fields, it MUST support the ability to include valid values for 1541 them. 1543 An uCDN-side implementation of the CDNI Logging interface MUST be 1544 able to accept CDNI Logging Files with CDNI Logging Records of 1545 record-type "cdni_http_request_v1" containing any CDNI Logging Field 1546 defined in Section 3.4.1 as long as the CDNI Logging Record and the 1547 CDNI Logging File are compliant with the present document. 1549 In case, an uCDN-side implementation of the CDNI Logging interface 1550 receives a CDNI Logging File with HTTP Request Logging Records that 1551 do not contain field values for exactly the set of field names 1552 actually listed in the preceding "fields" directive, the 1553 implementation MUST reject those HTTP Request Logging Records, and 1554 MUST accept the other HTTP Request Logging Records. 1556 To ensure that the logging file is correct, the text MUST be 1557 sanitized before being logged. Null, bare CR, bare LF and HTAB have 1558 to be removed by escaping them through percent encoding to avoid 1559 confusion with the logging record separators. 1561 3.5. CDNI Logging File Example 1563 Let us consider the upstream CDN and the downstream CDN labelled uCDN 1564 and dCDN-1 in Figure 1. When dCDN-1 acts as a downstream CDN for 1565 uCDN and performs content delivery on behalf of uCDN, dCDN-1 will 1566 include the CDNI Logging Records corresponding to the content 1567 deliveries performed on behalf of uCDN in the CDNI Logging Files for 1568 uCDN. An example CDNI Logging File communicated by dCDN-1 to uCDN is 1569 shown below in Figure 4. 1571 #version:cdni/1.0 1573 #UUID:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 1575 #claimed-origin:cdni-logging-entity.dcdn-1.example.com 1577 #record-type:cdni_http_request_v1 1579 #fields:datetimetime-takenc-ip 1580 c-ip-anonymizingcs-methodu-uriprotocol 1581 sc-statussc-total-bytescs(User-Agent) 1582 cs(Referer)s-cached 1584 2013-05-1700:38:06.8259.05810.5.7.08GET 1585 http://cdni-ucdn.dcdn-1.example.com/video/movie100.mp4 1586 HTTP/1.12006729891"Mozilla/5.0 1587 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like 1588 Gecko) Chrome/5.0.375.127 Safari/533.4" 1589 "host1.example.com"1 1591 2013-05-1700:39:09.14515.3210.5.10.08GET 1592 http://cdni-ucdn.dcdn-1.example.com/video/movie118.mp4 1593 HTTP/1.120015799210"Mozilla/5.0 1594 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like 1595 Gecko) Chrome/5.0.375.127 Safari/533.4" 1596 "host1.example.com"1 1598 2013-05-1700:42:53.43752.87910.5.10.08GET 1599 http://cdni-ucdn.dcdn-1.example.com/video/picture11.mp4 1600 HTTP/1.020097234724"Mozilla/5.0 1601 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like 1602 Gecko) Chrome/5.0.375.127 Safari/533.4" 1603 "host5.example.com"0 1605 #SHA256-hash:...32-hexadecimal-digit hash value... 1607 Figure 4: CDNI Logging File Example 1609 If uCDN establishes by some means (e.g. via TLS authentication when 1610 pulling the CDNI Logging File) the identity of the entity from which 1611 it pulled the CDNI Logging File, uCDN can add to the CDNI Logging an 1612 established-origin directive as illustrated below: 1614 #established-origin:cdni-logging-entity.dcdn- 1615 1.example.com 1617 As illustrated in Figure 2, uCDN will then ingest the corresponding 1618 CDNI Logging Records into its Collection process, alongside the 1619 Logging Records generated locally by the uCDN itself. This allows 1620 uCDN to aggregate Logging Records for deliveries performed by itself 1621 (through Records generated locally) as well as for deliveries 1622 performed by its downstream CDN(s). This aggregate information can 1623 then be used (after Filtering and Rectification, as illustrated in 1624 Figure 2) by Log Consuming Applications that take into account 1625 deliveries performed by uCDN as well as by all of its downstream 1626 CDNs. 1628 We observe that the time between 1630 1. when a delivery is completed in dCDN and 1632 2. when the corresponding Logging Record is ingested by the 1633 Collection process in uCDN 1635 depends on a number of parameters such as the Logging Period agreed 1636 to by uCDN and dCDN, how much time uCDN waits before pulling the CDNI 1637 Logging File once it is advertised in the CDNI Logging Feed, and the 1638 time to complete the pull of the CDNI Logging File. Therefore, if we 1639 consider the set of Logging Records aggregated by the Collection 1640 process in uCDN in a given time interval, there could be a permanent 1641 significant timing difference between the CDNI Logging Records 1642 received from the dCDN and the Logging Records generated locally. 1643 For example, in a given time interval, the Collection process in uCDN 1644 may be aggregating Logging Records generated locally by uCDN for 1645 deliveries performed in the last hour and CDNI Logging Records 1646 generated in the dCDN for deliveries in the hour before last. 1648 3.6. Cascaded CDNI Logging Files Example 1650 Let us consider the cascaded CDN scenario of uCDN, dCDN-2 and dCDN-3 1651 as depicted in Figure 1. After completion of a delivery by dCDN-3 on 1652 behalf of dCDN-2, dCDN-3 will include a corresponding Logging Record 1653 in a CDNI Logging File that will be pulled by dCDN-2 and that is 1654 illustrated below in Figure 5. In practice, a CDNI Logging File is 1655 likely to contain a very high number of CDNI Logging Records. 1656 However, for readability, the example in Figure 5 contains a single 1657 CDNI Logging Record. 1659 #version:CDNI/1.0 1661 #UUID:urn:uuid:65718ef-0123-9876-adce4321bcde 1663 #claimed-origin:cdni-logging-entity.dcdn-3.example.com 1665 #record-type:cdni_http_request_v1 1667 #fields:datetimetime-takenc-ip 1668 c-ip-anonymizingcs-methodu-uriprotocol 1669 sc-statussc-total-bytescs(User-Agent) 1670 cs(Referer)s-cached 1672 2013-05-1700:39:09.11914.0710.5.10.08GET 1673 http://cdni-dcdn-2.dcdn-3.example.com/video/movie118.mp4 1674 HTTP/1.120015799210"Mozilla/5.0 1675 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like 1676 Gecko) Chrome/5.0.375.127 Safari /533.4" 1677 "host1.example.com"1 1679 #SHA256-hash:...32-hexadecimal-digit hash value... 1681 Figure 5: Cascaded CDNI Logging File Example (dCDN-3 to dCDN-2) 1683 If dCDN-2 establishes by some means (e.g. via TLS authentication when 1684 pulling the CDNI Logging File) the identity of the entity from which 1685 it pulled the CDNI Logging File, dCDN-2 can add to the CDNI Logging 1686 an established-origin directive as illustrated below: 1688 #established-origin:cdni-logging-entity.dcdn- 1689 3.example.com 1691 dCDN-2 (behaving as an upstream CDN from the viewpoint of dCDN-3) 1692 will then ingest the CDNI Logging Record for the considered dCDN-3 1693 delivery into its Collection process (as illustrated in Figure 2). 1694 This Logging Record may be aggregated with Logging Records generated 1695 locally by dCDN-2 for deliveries performed by dCDN-2 itself. Say, 1696 for illustration, that the content delivery performed by dCDN-3 on 1697 behalf of dCDN-2 had actually been redirected to dCDN-2 by uCDN, and 1698 say that another content delivery has just been redirected by uCDN to 1699 dCDN-2 and that dCDN-2 elected to perform the corresponding delivery 1700 itself. Then after Filtering and Rectification (as illustrated in 1701 Figure 2), dCDN-2 will include the two Logging Records corresponding 1702 respectively to the delivery performed by dCDN-3 and the delivery 1703 performed by dCDN-2, in the next CDNI Logging File that will be 1704 communicated to uCDN. An example of such CDNI Logging File is 1705 illustrated below in Figure 6. 1707 #version:CDNI/1.0 1709 #UUID:urn:uuid:1234567-8fedc-abab-0987654321ff 1711 #claimed-origin:cdni-logging-entity.dcdn-2.example.com 1713 #record-type:cdni_http_request_v1 1715 #fields:datetimetime-takenc-ip 1716 c-ip-anonymizingcs-methodu-uriprotocol 1717 sc-statussc-total-bytescs(User-Agent) 1718 cs(Referer)s-cached 1720 2013-05-1700:39:09.11914.0710.5.10.08GET 1721 http://cdni-ucdn.dcdn-2.example.com/video/movie118.mp4 1722 HTTP/1.120015799210"Mozilla/5.0 1723 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like 1724 Gecko) Chrome/5.0.375.127 Safari /533.4" 1725 "host1.example.com"1 1727 2013-05-1701:42:53.43752.87910.5.10.08GET 1728 http://cdni-ucdn.dcdn-2.example.com/video/picture11.mp4 1729 HTTP/1.020097234724"Mozilla/5.0 1730 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like 1731 Gecko) Chrome/5.0.375.127 Safari /533.4" 1732 "host5.example.com"0 1734 #SHA256-hash:...32-hexadecimal-digit hash value... 1736 Figure 6: Cascaded CDNI Logging File Example (dCDN-2 to uCDN) 1738 If uCDN establishes by some means (e.g. via TLS authentication when 1739 pulling the CDNI Logging File) the identity of the entity from which 1740 it pulled the CDNI Logging File, uCDN can add to the CDNI Logging an 1741 established-origin directive as illustrated below: 1743 #established-origin:cdni-logging-entity.dcdn- 1744 2.example.com 1746 In the example of Figure 6, we observe that: 1748 o the first Logging Record corresponds to the Logging Record 1749 communicated earlier to dCDN-2 by dCDN-3, which corresponds to a 1750 delivery redirected by uCDN to dCDN-2 and then redirected by 1751 dCDN-2 to dCDN-3. The fields values in this Logging Record are 1752 copied from the corresponding CDNI Logging REcord communicated to 1753 dCDN2 by dCDN-3, with the exception of the u-uri that now reflects 1754 the URI convention between uCDN and dCDN-2 and that presents the 1755 delivery to uCDN as if it was performed by dCDN-2 itself. This 1756 reflects the fact that dCDN-2 had taken the full responsibility of 1757 the corresponding delivery (even if in this case, dCDN-2 elected 1758 to redirect the delivery to dCDN-3 so it is actually performed by 1759 dCDN-3 on behalf of dCDN-2). 1761 o the second Logging Record corresponds to a delivery redirected by 1762 uCDN to dCDN-2 and performed by dCDN-2 itself. The time of the 1763 delivery in this Logging Record may be significantly more recent 1764 than the first Logging Record since it was generated locally while 1765 the first Logging Record was generated by dCDN-3 and had to be 1766 advertised , and then pulled and then ingested into the dCDN-2 1767 Collection process, before being aggregated with the second 1768 Logging Record. 1770 4. Protocol for Exchange of CDNI Logging File After Full Collection 1772 This section specifies a protocol for the exchange of CDNI Logging 1773 Files as specified in Section 3 after the CDNI Logging File is fully 1774 collected by the dCDN. 1776 This protocol comprises: 1778 o a CDNI Logging feed, allowing the dCDN to notify the uCDN about 1779 the CDNI Logging Files that can be retrieved by that uCDN from the 1780 dCDN, as well as all the information necessary for retrieving each 1781 of these CDNI Logging Files. The CDNI Logging feed is specified 1782 in Section 4.1. 1784 o a CDNI Logging File pull mechanism, allowing the uCDN to obtain 1785 from the dCDN a given CDNI Logging File at the uCDN's convenience. 1786 The CDNI Logging File pull mechanisms is specified in Section 4.2. 1788 An implementation of the CDNI Logging interface on the dCDN side (the 1789 entity generating the CDNI Logging file) MUST support the server side 1790 of the CDNI Logging feed (as specified in Section 4.1) and the server 1791 side of the CDNI Logging pull mechanism (as specified in 1792 Section 4.2). 1794 An implementation of the CDNI Logging interface on the uCDN side (the 1795 entity consuming the CDNI Logging file) MUST support the client side 1796 of the CDNI Logging feed (as specified in Section 4.1) and the client 1797 side of the CDNI Logging pull mechanism (as specified in 1798 Section 4.2). 1800 4.1. CDNI Logging Feed 1802 The server-side implementation of the CDNI Logging feed MUST produce 1803 an Atom feed [RFC4287]. This feed is used to advertise log files 1804 that are available for the client-side to retrieve using the CDNI 1805 Logging pull mechanism. 1807 4.1.1. Atom Formatting 1809 A CDNI Logging feed MUST be structured as an Archived feed, as 1810 defined in [RFC5005], and MUST be formatted in Atom [RFC4287]. This 1811 means it consists of a subscription document that is regularly 1812 updated as new CDNI Logging Files become available, and information 1813 about older CDNI Logging files is moved into archive documents. Once 1814 created, archive documents are never modified. 1816 Each CDNI Logging File listed in an Atom feed MUST be described in an 1817 atom:entry container element. 1819 The atom:entry MUST contain an atom:content element whose "src" 1820 attribute is a link to the CDNI Logging File and whose "type" 1821 attribute is the MIME Media Type indicating that the entry is a CDNI 1822 Logging File. We define this MIME Media Type as "application/ 1823 cdni.LoggingFile" (See Section 6.5). 1825 For compatibility with some Atom feed readers the atom:entry MAY also 1826 contain an atom:link entry whose "href" attribute is a link to the 1827 CDNI Logging File and whose "type" attribute is the MIME Media Type 1828 indicating that the entry is a CDNI Logging File using the 1829 "application/cdni.LoggingFile" MIME Media Type (See Section 6.5). 1831 The URI used in the atom:id of the atom:entry MUST contain the UUID 1832 of the CDNI Logging File. 1834 The atom:updated in the atom:entry MUST indicate the time at which 1835 the CDNI Logging File was last updated. 1837 4.1.2. Updates to Log Files and the Feed 1839 CDNI Logging Files MUST NOT be modified by the dCDN once published in 1840 the CDNI Logging feed. 1842 The frequency with which the subscription feed is updated, the period 1843 of time covered by each CDNI Logging File or each archive document, 1844 and timeliness of publishing of CDNI Logging Files are outside the 1845 scope of the present document and are expected to be agreed upon by 1846 uCDN and dCDN via other means (e.g., human agreement). 1848 The server-side implementation MUST be able to set, and SHOULD set, 1849 HTTP cache control headers on the subscription feed to indicate the 1850 frequency at which the client-side is to poll for updates. 1852 The client-side MAY use HTTP cache control headers (set by the 1853 server-side) on the subscription feed to determine the frequency at 1854 which to poll for updates. The client-side MAY instead, or in 1855 addition, use other information to determine when to poll for updates 1856 (e.g., a polling frequency that may have been negotiated between the 1857 uCDN and dCDN by mechanisms outside the scope of the present document 1858 and that is to override the indications provided in the HTTP cache 1859 control headers). 1861 The potential retention limits (e.g., sliding time window) within 1862 which the dCDN is to retain and be ready to serve an archive document 1863 is outside the scope of the present document and is expected to be 1864 agreed upon by uCDN and dCDN via other means (e.g., human agreement). 1865 The server-side implementation MUST retain, and be ready to serve, 1866 any archive document within the agreed retention limits. Outside 1867 these agreed limits, the server-side implementation MAY indicate its 1868 inability to serve (e.g., with HTTP status code 404) an archive 1869 document or MAY refuse to serve it (e.g., with HTTP status code 403 1870 or 410). 1872 4.1.3. Redundant Feeds 1874 The server-side implementation MAY present more than one CDNI Logging 1875 feed for redundancy. Each CDNI Logging File MAY be published in more 1876 than one feed. 1878 A client-side implementation MAY support such redundant CDNI Logging 1879 feeds. If it supports redundant CDNI Logging feed, the client-side 1880 can use the UUID of the CDNI Logging File, presented in the atom:id 1881 element of the Atom feed, to avoid unnecessarily pulling and storing 1882 a given CDNI Logging File more than once. 1884 4.1.4. Example CDNI Logging Feed 1886 Figure 7 illustrates an example of the subscription document of a 1887 CDNI Logging feed. 1889 1890 1891 CDNI Logging Feed 1892 2013-03-23T14:46:11Z 1893 urn:uuid:663ae677-40fb-e99a-049d-c5642916b8ce 1894 1896 1898 1900 CDNI Log Feed 1901 Generator 1902 dcdn.example 1903 1904 CDNI Logging File for uCDN at 1905 2013-03-23 14:15:00 1906 urn:uuid:12345678-1234-abcd-00aa-01234567abcd 1907 2013-03-23T14:15:00Z 1908 1911 CDNI Logging File for uCDN at 1912 2013-03-23 14:15:00 1913 1914 1915 CDNI Logging File for uCDN at 1916 2013-03-23 14:30:00 1917 urn:uuid:87654321-4321-dcba-aa00-dcba7654321 1918 2013-03-23T14:30:00Z 1919 1922 CDNI Logging File for uCDN at 1923 2013-03-23 14:30:00 1924 1925 ... 1926 1927 ... 1928 1929 1931 Figure 7: Example subscription document of a CDNI Logging Feed 1933 4.2. CDNI Logging File Pull 1935 A client-side implementation of the CDNI Logging interface MAY pull, 1936 at its convenience, a CDNI Logging File that is published by the 1937 server-side in the CDNI Logging Feed (in the subscription document or 1938 an archive document). To do so, the client-side: 1940 o MUST implement HTTP/1.1 ([RFC7230],[RFC7231], [RFC7232], 1941 [RFC7233], [RFC7234], [RFC7235]), MAY also support other HTTP 1942 versions (e.g., HTTP/2 [RFC7540]) and MAY negotiate which HTTP 1943 version is actually used. This allows operators and implementers 1944 to choose to use later versions of HTTP to take advantage of new 1945 features, while still ensuring interoperability with systems that 1946 only support HTTP/1.1. 1948 o MUST use the URI that was associated to the CDNI Logging File 1949 (within the "src" attribute of the corresponding atom:content 1950 element) in the CDNI Logging Feed; 1952 o MUST support exchange of CDNI Logging Files with no content 1953 encoding applied to the representation; 1955 o MUST support exchange of CDNI Logging Files with "gzip" content 1956 encoding (as defined in [RFC7230]) applied to the representation. 1958 Note that a client-side implementation of the CDNI Logging interface 1959 MAY pull a CDNI Logging File that it has already pulled. 1961 The server-side implementation MUST respond to valid pull request by 1962 a client-side implementation for a CDNI Logging File published by the 1963 server-side in the CDNI Logging Feed (in the subscription document or 1964 an archive document). The server-side implementation: 1966 o MUST implement HTTP/1.1 to handle the client-side request and MAY 1967 also support other HTTP versions (e.g., HTTP/2); 1969 o MUST include the CDNI Logging File identified by the request URI 1970 inside the body of the HTTP response; 1972 o MUST support exchange of CDNI Logging Files with no content 1973 encoding applied to the representation; 1975 o MUST support exchange of CDNI Logging Files with "gzip" content 1976 encoding (as defined in [RFC7231]) applied to the representation. 1978 Content negotiation approaches defined in [RFC7231] (e.g., using 1979 Accept-Encoding request-header field or Content-Encoding entity- 1980 header field) MAY be used by the client-side and server-side 1981 implementations to establish the content-coding to be used for a 1982 particular exchange of a CDNI Logging File. 1984 Applying compression content encoding (such as "gzip") is expected to 1985 mitigate the impact of exchanging the large volumes of logging 1986 information expected across CDNs. This is expected to be 1987 particularly useful in the presence of HTTP Adaptive Streaming (HAS) 1988 which, as per the present version of the document, will result in a 1989 separate CDNI Log Record for each HAS segment delivery in the CDNI 1990 Logging File. 1992 The potential retention limits (e.g., sliding time window, maximum 1993 aggregate file storage quotas) within which the dCDN is to retain and 1994 be ready to serve a CDNI Logging File previously advertised in the 1995 CDNI Logging Feed is outside the scope of the present document and is 1996 expected to be agreed upon by uCDN and dCDN via other means (e.g., 1997 human agreement). The server-side implementation MUST retain, and be 1998 ready to serve, any CDNI Logging File within the agreed retention 1999 limits. Outside these agreed limits, the server-side implementation 2000 MAY indicate its inability to serve (e.g., with HTTP status code 404) 2001 a CDNI Logging File or MAY refuse to serve it (e.g., with HTTP status 2002 code 403 or 410). 2004 5. Protocol for Exchange of CDNI Logging File During Collection 2006 We note that, in addition to the CDNI Logging File exchange protocol 2007 specified in Section 4, implementations of the CDNI Logging interface 2008 may also support other mechanisms to exchange CDNI Logging Files. In 2009 particular, such mechanisms might allow the exchange of the CDNI 2010 Logging File to start before the file is fully collected. This can 2011 allow CDNI Logging Records to be communicated by the dCDN to the uCDN 2012 as they are gathered by the dCDN without having to wait until all the 2013 CDNI Logging Records of the same logging period are collected in the 2014 corresponding CDNI Logging File. This approach is commonly referred 2015 to as "tailing" of the file. 2017 Such an approach could be used, for example, to exchange logging 2018 information with a significantly reduced time-lag (e.g., sub-minute 2019 or sub-second) between when the event occurred in the dCDN and when 2020 the corresponding CDNI Logging Record is made available to the uCDN. 2021 This can satisfy log-consuming applications requiring extremely fresh 2022 logging information such as near-real-time content delivery 2023 monitoring. Such mechanisms are for further study and outside the 2024 scope of this document. 2026 6. IANA Considerations 2028 When IANA allocates new extensions to CDNI Logging Directive Names 2029 Registry, CDNI Logging File version Registry, CDNI Logging record- 2030 type Registry or CDNI Logging fields Registry, IANA MUST take into 2031 account that the directive names are case-insensitive as per the 2032 basic ABNF([RFC2234]). 2034 6.1. CDNI Logging Directive Names Registry 2036 The IANA is requested to create a new registry, CDNI Logging 2037 Directive Names. 2039 The initial contents of the CDNI Logging Directives registry comprise 2040 the names of the directives specified in Section 3.3 of the present 2041 document, and are as follows: 2043 +------------------------------+-----------+ 2044 | Directive Name | Reference | 2045 +------------------------------+-----------+ 2046 | version | RFC xxxx | 2047 | UUID | RFC xxxx | 2048 | claimed-origin | RFC xxxx | 2049 | established-origin | RFC xxxx | 2050 | remark | RFC xxxx | 2051 | record-type | RFC xxxx | 2052 | fields | RFC xxxx | 2053 | SHA256-hash | RFC xxxx | 2054 +------------------------------+-----------+ 2056 Figure 8 2058 [Instructions to IANA: Replace "RFC xxxx" above by the RFC number of 2059 the present document] 2061 Within the registry, names are to be allocated by IANA according to 2062 the "Specification Required" policy specified in [RFC5226]. 2063 Directive names are to be allocated by IANA with a format of 2064 NAMEFORMAT (see Section 3.1). All directive names and field names 2065 defined in the logging file are case-insensitive as per the basic 2066 ABNF([RFC2234]). 2068 Each specification that defines a new CDNI Logging directive needs to 2069 contain a description for the new directive with the same set of 2070 information as provided in Section 3.3 (i.e., format, directive value 2071 and occurrence). 2073 6.2. CDNI Logging File version Registry 2075 The IANA is requested to create a new registry, CDNI Logging File 2076 version. 2078 The initial contents of the CDNI Logging Logging File version 2079 registry comprise the value "CDNI/1.0" specified in Section 3.3 of 2080 the present document, and are as follows: 2082 +-----------------+-----------+----------------------------------+ 2083 | version | Reference | Description | 2084 +-----------------+-----------+----------------------------------+ 2085 | cdni/1.0 | RFC xxxx | CDNI Logging File version 1.0 | 2086 | | | as specified in RFC xxxx | 2087 +-----------------+-----------+----------------------------------+ 2089 Figure 9 2091 [Instructions to IANA: Replace "RFC xxxx" above by the RFC number of 2092 the present document] 2094 Within the registry, version values are to be allocated by IANA 2095 according to the "Specification Required" policy specified in 2096 [RFC5226]. Version values are to be allocated by IANA with a format 2097 of NAMEFORMAT (see Section 3.1). 2099 6.3. CDNI Logging record-types Registry 2101 The IANA is requested to create a new registry, CDNI Logging record- 2102 types. 2104 The initial contents of the CDNI Logging record-types registry 2105 comprise the names of the CDNI Logging Record types specified in 2106 Section 3.4 of the present document, and are as follows: 2108 +----------------------+-----------+----------------------------------+ 2109 | record-types | Reference | Description | 2110 +----------------------+-----------+----------------------------------+ 2111 | cdni_http_request_v1 | RFC xxxx | CDNI Logging Record version 1 | 2112 | | | for content delivery using HTTP | 2113 +----------------------+-----------+----------------------------------+ 2115 Figure 10 2117 [Instructions to IANA: Replace "RFC xxxx" above by the RFC number of 2118 the present document] 2120 Within the registry, record-types are to be allocated by IANA 2121 according to the "Specification Required" policy specified in 2122 [RFC5226]. record-types are to be allocated by IANA with a format of 2123 NAMEFORMAT (see Section 3.1). 2125 Each specification that defines a new record-type needs to contain a 2126 description for the new record-type with the same set of information 2127 as provided in Section 3.4.1. This includes: 2129 o a list of all the CDNI Logging fields that can appear in a CDNI 2130 Logging Record of the new record-type 2132 o for all these fields: a specification of the occurrence for each 2133 Field in the new record-type 2135 o for every newly defined Field, i.e., for every Field that results 2136 in a registration in the CDNI Logging Field Names Registry 2137 (Section 6.4): a specification of the field name, format and field 2138 value. 2140 6.4. CDNI Logging Field Names Registry 2142 The IANA is requested to create a new registry, CDNI Logging Field 2143 Names. 2145 This registry is intended to be shared across the currently defined 2146 record-type (i.e., cdni_http_request_v1) as well as potential other 2147 CDNI Logging record-types that may be defined in separate 2148 specifications. When a Field from this registry is used by another 2149 CDNI Logging record-type, it is to be used with the exact semantics 2150 and format specified in the document that registered this field and 2151 that is identified in the Reference column of the registry. If 2152 another CDNI Logging record-type requires a Field with semantics that 2153 are not strictly identical, or a format that is not strictly 2154 identical then this new Field is to be registered in the registry 2155 with a different Field name. When a Field from this registry is used 2156 by another CDNI Logging record-type, it can be used with different 2157 occurrence rules. 2159 The initial contents of the CDNI Logging fields Names registry 2160 comprise the names of the CDNI Logging fields specified in 2161 Section 3.4 of the present document, and are as follows: 2163 +------------------------------------------+-----------+ 2164 | Field Name | Reference | 2165 +------------------------------------------+-----------+ 2166 | date | RFC xxxx | 2167 | time | RFC xxxx | 2168 | time-taken | RFC xxxx | 2169 | c-ip | RFC xxxx | 2170 | c-ip-anonymizing | RFC xxxx | 2171 | c-port | RFC xxxx | 2172 | s-ip | RFC xxxx | 2173 | s-hostname | RFC xxxx | 2174 | s-port | RFC xxxx | 2175 | cs-method | RFC xxxx | 2176 | cs-uri | RFC xxxx | 2177 | u-uri | RFC xxxx | 2178 | protocol | RFC xxxx | 2179 | sc-status | RFC xxxx | 2180 | sc-total-bytes | RFC xxxx | 2181 | sc-entity-bytes | RFC xxxx | 2182 | cs(insert_HTTP_header_name_here) | RFC xxxx | 2183 | sc(insert_HTTP_header_name_here) | RFC xxxx | 2184 | s-ccid | RFC xxxx | 2185 | s-sid | RFC xxxx | 2186 | s-cached | RFC xxxx | 2187 +------------------------------------------+-----------+ 2189 Figure 11 2191 [Instructions to IANA: Replace "RFC xxxx" above by the RFC number of 2192 the present document] 2194 Within the registry, names are to be allocated by IANA according to 2195 the "Specification Required" policy specified in [RFC5226]. Field 2196 names are to be allocated by IANA with a format of NHTABSTRING (see 2197 Section 3.1). 2199 6.5. CDNI Logging MIME Media Type 2201 The IANA is requested to allocate the "application/cdni.LoggingFile" 2202 MIME Media Type (whose use is specified in Section 4.1.1 of the 2203 present document) in the MIME Media Types registry. 2205 7. Security Considerations 2207 7.1. Authentication, Authorization, Confidentiality, Integrity 2208 Protection 2210 An implementation of the CDNI Logging interface MUST support TLS 2211 transport of the CDNI Logging feed (Section 4.1) and of the CDNI 2212 Logging File pull (Section 4.2) as per [RFC2818] and [RFC7230]. 2214 The use of TLS for transport of the CDNI Logging feed and CDNI 2215 Logging File pull allows: 2217 o the dCDN and uCDN to authenticate each other 2219 and, once they have mutually authenticated each other, it allows: 2221 o the dCDN and uCDN to authorize each other (to ensure they are 2222 transmitting/receiving CDNI Logging File to/from an authorized 2223 CDN) 2225 o the CDNI Logging information to be transmitted with 2226 confidentiality 2228 o the integrity of the CDNI Logging information to be protected 2229 during the exchange. 2231 In an environment where any such protection is required, mutually 2232 authenticated encrypted transport MUST be used to ensure 2233 confidentiality of the logging information. To that end, TLS MUST be 2234 used (including authentication of the remote end) by the server-side 2235 and the client-side of the CDNI Logging feed, as well as the server- 2236 side and the client-side of the CDNI Logging File pull mechanism. 2238 When TLS is used, the general TLS usage guidance in [RFC7525] MUST be 2239 followed. 2241 The SHA256-hash directive inside the CDNI Logging File provides 2242 additional integrity protection, this time targeting potential 2243 corruption of the CDNI logging information during the CDNI Logging 2244 File generation, storage or exchange. This mechanism does not itself 2245 allow restoration of the corrupted CDNI Logging information, but it 2246 allows detection of such corruption and therefore triggering of 2247 appropriate corrective actions (e.g., discard of corrupted 2248 information, attempt to re-obtain the CDNI Logging information). 2249 Note that the SHA256-hash does not protect against tampering by a 2250 third party, since such a third party could have recomputed and 2251 updated the SHA256-hash after tampering. Protection against third 2252 party tampering can be achieved as discussed above through the use of 2253 TLS. 2255 7.2. Denial of Service 2257 This document does not define specific mechanism to protect against 2258 Denial of Service (DoS) attacks on the Logging Interface. However, 2259 the CDNI Logging feed and CDNI Logging pull endpoints are typically 2260 to be accessed only by a very small number of valid remote endpoints 2261 and therefore can be easily protected against DoS attacks through the 2262 usual conventional DOS protection mechanisms such as firewalling or 2263 use of Virtual Private Networks (VPNs). 2265 Protection of dCDN Surrogates against spoofed delivery requests is 2266 outside the scope of the CDNI Logging interface. 2268 7.3. Privacy 2270 CDNs have the opportunity to collect detailed information about the 2271 downloads performed by End Users. The provision of this information 2272 to another CDN introduces potential End Users privacy protection 2273 concerns. 2275 The use of mutually authenticated TLS to establish a secure session 2276 for the transport of the CDNI Logging feed and CDNI Logging pull as 2277 discussed in Section 7.1 access to the logging information. This 2278 provides confidentiality while the logging information is in transit 2279 and prevents any other party than the authorised uCDN to gain access 2280 to the logging information. 2282 We observe that when CDNI interconnection is realised as per 2283 [RFC7336], the uCDN handles the initial End User requests (before it 2284 is redirected to the dCDN) so, regardless of which information is, or 2285 is not, communicated to the uCDN through the CDNI Logging interface, 2286 the uCDN has visibility on significant information such as the IP 2287 address of the End User request and the URL of the request. 2289 Nonetheless, if the dCDN and uCDN agree that anonymization is 2290 required to avoid making some detailed information available to the 2291 uCDN (such as how many bytes of the content have been watched by an 2292 End User and/or at what time) or is required to meet some legal 2293 obligations, then the uCDN and dCDN can agree to exchange anonymized 2294 End Users IP address in CDNI Logging Files and the c-ip-anonymization 2295 field can be used to convey the number of bits that have been 2296 anonymized so that the meaningful information can still be easily 2297 extracted from the anonymized addressses (e.g., for geolocation aware 2298 analytics). 2300 We note that anonymization of End Users IP address does not fully 2301 protect against deriving potentially sensitive information about 2302 traffic patterns; in general, increasing the number of bits that are 2303 anonymized can mitigate the risks of deriving such sensitive traffic 2304 pattern information. 2306 We also note that independently of IP addresses, the query string 2307 portion of the URL that may be conveyed inside the cs-uri and u-uri 2308 fields of CDNI Logging Files, or the HTTP cookies( [RFC6265]) that 2309 may be conveyed inside the cs() field of CDNI 2310 Logging fields, may contain personnal information or information that 2311 can be exploited to derive personal information. Where this is a 2312 concern, the CDNI Logging interface specification allows the dCDN to 2313 not include the cs-uri and to include a u-uri that removes (or hides) 2314 the sensitive part of the query string and allows the dCDN to not 2315 include the cs() fields corresponding to HTTP 2316 headers associated with cookies. 2318 8. Acknowledgments 2320 This document borrows from the W3C Extended Log Format [ELF]. 2322 Rob Murray significantly contributed into the text of Section 4.1. 2324 The authors thank Ben Niven-Jenkins, Kevin Ma, David Mandelberg and 2325 Ray van Brandenburg for their ongoing input. 2327 Finally, we also thank Sebastien Cubaud, Pawel Grochocki, Christian 2328 Jacquenet, Yannick Le Louedec, Anne Marrec , Emile Stephan, Fabio 2329 Costa, Sara Oueslati, Yvan Massot, Renaud Edel, Joel Favier and the 2330 contributors of the EU FP7 OCEAN project for their input in the early 2331 versions of this document. 2333 9. References 2335 9.1. Normative References 2337 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2338 Requirement Levels", BCP 14, RFC 2119, March 1997. 2340 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2341 Specifications: ABNF", RFC 2234, November 1997. 2343 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 2344 Internet: Timestamps", RFC 3339, July 2002. 2346 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2347 Resource Identifier (URI): Generic Syntax", STD 66, RFC 2348 3986, January 2005. 2350 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 2351 Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2352 2005. 2354 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom 2355 Syndication Format", RFC 4287, December 2005. 2357 [RFC5005] Nottingham, M., "Feed Paging and Archiving", RFC 5005, 2358 September 2007. 2360 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2361 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2362 May 2008. 2364 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2365 Specifications: ABNF", STD 68, RFC 5234, January 2008. 2367 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 2368 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 2369 August 2008. 2371 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 2372 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2373 2014. 2375 [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 2376 (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. 2378 [RFC7232] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 2379 (HTTP/1.1): Conditional Requests", RFC 7232, June 2014. 2381 [RFC7233] Fielding, R., Lafon, Y., and J. Reschke, "Hypertext 2382 Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, 2383 June 2014. 2385 [RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext 2386 Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 2387 2014. 2389 [RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 2390 (HTTP/1.1): Authentication", RFC 7235, June 2014. 2392 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 2393 "Recommendations for Secure Use of Transport Layer 2394 Security (TLS) and Datagram Transport Layer Security 2395 (DTLS)", BCP 195, RFC 7525, May 2015. 2397 [RFC7540] Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer 2398 Protocol Version 2 (HTTP/2)", RFC 7540, May 2015. 2400 9.2. Informative References 2402 [CHAR_SET] 2403 "IANA Character Sets registry", 2404 . 2407 [ELF] Phillip M. Hallam-Baker, and Brian Behlendorf, "Extended 2408 Log File Format, W3C (work in progress), WD-logfile- 2409 960323", . 2411 [I-D.ietf-cdni-metadata] 2412 Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 2413 "CDN Interconnection Metadata", draft-ietf-cdni- 2414 metadata-09 (work in progress), March 2015. 2416 [I-D.ietf-httpbis-http2] 2417 Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer 2418 Protocol version 2", draft-ietf-httpbis-http2-17 (work in 2419 progress), February 2015. 2421 [I-D.snell-atompub-link-extensions] 2422 Snell, J., "Atom Link Extensions", draft-snell-atompub- 2423 link-extensions-09 (work in progress), June 2012. 2425 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext 2426 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 2428 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 2430 [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 2431 (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. 2433 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 2434 April 2011. 2436 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 2437 Distribution Network Interconnection (CDNI) Problem 2438 Statement", RFC 6707, September 2012. 2440 [RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, 2441 K., and G. Watson, "Use Cases for Content Delivery Network 2442 Interconnection", RFC 6770, November 2012. 2444 [RFC6983] van Brandenburg, R., van Deventer, O., Le Faucheur, F., 2445 and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware 2446 Content Distribution Network Interconnection (CDNI)", RFC 2447 6983, July 2013. 2449 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, 2450 "Framework for Content Distribution Network 2451 Interconnection (CDNI)", RFC 7336, August 2014. 2453 [RFC7337] Leung, K. and Y. Lee, "Content Distribution Network 2454 Interconnection (CDNI) Requirements", RFC 7337, August 2455 2014. 2457 Authors' Addresses 2459 Francois Le Faucheur (editor) 2460 Cisco Systems 2461 E.Space Park - Batiment D 2462 6254 Allee des Ormes - BP 1200 2463 Mougins cedex 06254 2464 FR 2466 Phone: +33 4 97 23 26 19 2467 Email: flefauch@cisco.com 2469 Gilles Bertrand (editor) 2470 Orange 2471 38-40 rue du General Leclerc 2472 Issy les Moulineaux 92130 2473 FR 2475 Phone: +33 1 45 29 89 46 2476 Email: gilles.bertrand@orange.com 2478 Iuniana Oprescu (editor) 2479 Orange 2480 38-40 rue du General Leclerc 2481 Issy les Moulineaux 92130 2482 FR 2484 Phone: +33 6 89 06 92 72 2485 Email: iuniana.oprescu@orange.com 2487 Roy Peterkofsky 2488 Skytide, Inc. 2489 One Kaiser Plaza, Suite 785 2490 Oakland CA 94612 2491 USA 2493 Phone: +01 510 250 4284 2494 Email: roy@skytide.com