idnits 2.17.1 draft-ietf-cdni-logging-18.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 (March 21, 2015) is 3295 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 2302, but no explicit reference was found in the text ** 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) == 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: 8 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force F. Le Faucheur, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track G. Bertrand, Ed. 5 Expires: September 22, 2015 I. Oprescu, Ed. 6 Orange 7 R. Peterkofsky 8 Skytide, Inc. 9 March 21, 2015 11 CDNI Logging Interface 12 draft-ietf-cdni-logging-18 14 Abstract 16 This memo specifies the Logging interface between a downstream CDN 17 (dCDN) and an upstream CDN (uCDN) that are interconnected as per the 18 CDN Interconnection (CDNI) framework. First, it describes a 19 reference model for CDNI logging. Then, it specifies the CDNI 20 Logging File format and the actual protocol for exchange of CDNI 21 Logging Files. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 22, 2015. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 60 2. CDNI Logging Reference Model . . . . . . . . . . . . . . . . 5 61 2.1. CDNI Logging interactions . . . . . . . . . . . . . . . . 5 62 2.2. Overall Logging Chain . . . . . . . . . . . . . . . . . . 8 63 2.2.1. Logging Generation and During-Generation Aggregation 9 64 2.2.2. Logging Collection . . . . . . . . . . . . . . . . . 10 65 2.2.3. Logging Filtering . . . . . . . . . . . . . . . . . . 10 66 2.2.4. Logging Rectification and Post-Generation Aggregation 11 67 2.2.5. Log-Consuming Applications . . . . . . . . . . . . . 12 68 2.2.5.1. Maintenance/Debugging . . . . . . . . . . . . . . 12 69 2.2.5.2. Accounting . . . . . . . . . . . . . . . . . . . 12 70 2.2.5.3. Analytics and Reporting . . . . . . . . . . . . . 13 71 2.2.5.4. Content Protection . . . . . . . . . . . . . . . 13 72 2.2.5.5. Notions common to multiple Log Consuming 73 Applications . . . . . . . . . . . . . . . . . . 13 74 3. CDNI Logging File . . . . . . . . . . . . . . . . . . . . . . 15 75 3.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 3.2. CDNI Logging File Structure . . . . . . . . . . . . . . . 17 77 3.3. CDNI Logging Directives . . . . . . . . . . . . . . . . . 19 78 3.4. CDNI Logging Records . . . . . . . . . . . . . . . . . . 23 79 3.4.1. HTTP Request Logging Record . . . . . . . . . . . . . 24 80 3.5. CDNI Logging File Example . . . . . . . . . . . . . . . . 34 81 3.6. Cascaded CDNI Logging Files Example . . . . . . . . . . . 35 82 4. Protocol for Exchange of CDNI Logging File After Full 83 Collection . . . . . . . . . . . . . . . . . . . . . . . . . 38 84 4.1. CDNI Logging Feed . . . . . . . . . . . . . . . . . . . . 39 85 4.1.1. Atom Formatting . . . . . . . . . . . . . . . . . . . 39 86 4.1.2. Updates to Log Files and the Feed . . . . . . . . . . 39 87 4.1.3. Redundant Feeds . . . . . . . . . . . . . . . . . . . 40 88 4.1.4. Example CDNI Logging Feed . . . . . . . . . . . . . . 40 89 4.2. CDNI Logging File Pull . . . . . . . . . . . . . . . . . 42 90 5. Protocol for Exchange of CDNI Logging File During Collection 43 91 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 92 6.1. CDNI Logging Directive Names Registry . . . . . . . . . . 44 93 6.2. CDNI Logging File Version Registry . . . . . . . . . . . 44 94 6.3. CDNI Logging Record-Types Registry . . . . . . . . . . . 45 95 6.4. CDNI Logging Field Names Registry . . . . . . . . . . . . 46 96 6.5. CDNI Logging MIME Media Type . . . . . . . . . . . . . . 47 98 7. Security Considerations . . . . . . . . . . . . . . . . . . . 47 99 7.1. Authentication, Authorization, Confidentiality, Integrity 100 Protection . . . . . . . . . . . . . . . . . . . . . . . 48 101 7.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 49 102 7.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 49 103 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50 104 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 105 9.1. Normative References . . . . . . . . . . . . . . . . . . 50 106 9.2. Informative References . . . . . . . . . . . . . . . . . 51 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 109 1. Introduction 111 This memo specifies the CDNI Logging interface between a downstream 112 CDN (dCDN) and an upstream CDN (uCDN). First, it describes a 113 reference model for CDNI logging. Then, it specifies the CDNI 114 Logging File format and the actual protocol for exchange of CDNI 115 Logging Files. 117 The reader should be familiar with the following documents: 119 o CDNI problem statement [RFC6707] and framework [RFC7336] identify 120 a Logging interface, 122 o Section 8 of [RFC7337] specifies a set of requirements for 123 Logging, 125 o [RFC6770] outlines real world use-cases for interconnecting CDNs. 126 These use cases require the exchange of Logging information 127 between the dCDN and the uCDN. 129 As stated in [RFC6707], "the CDNI Logging interface enables details 130 of logs or events to be exchanged between interconnected CDNs". 132 The present document describes: 134 o The CDNI Logging reference model (Section 2), 136 o The CDNI Logging File format (Section 3), 138 o The CDNI Logging File Exchange protocol (Section 4). 140 1.1. Terminology 142 In this document, the first letter of each CDNI-specific term is 143 capitalized. We adopt the terminology described in [RFC6707] and 144 [RFC7336], and extend it with the additional terms defined below. 146 Intra-CDN Logging information: logging information generated and 147 collected within a CDN. The format of the Intra-CDN Logging 148 information may be different to the format of the CDNI Logging 149 information. 151 CDNI Logging information: logging information exchanged across CDNs 152 using the CDNI Logging Interface. 154 Logging information: logging information generated and collected 155 within a CDN or obtained from another CDN using the CDNI Logging 156 Interface. 158 CDNI Logging Field: an atomic element of information that can be 159 included in a CDNI Logging Record. The time an event/task started, 160 the IP address of an End User to whom content was delivered, and the 161 Uniform Resource Identifier (URI) of the content delivered, are 162 examples of CDNI Logging Fields. 164 CDNI Logging Record: an information record providing information 165 about a specific event. This comprises a collection of CDNI Logging 166 Fields. 168 CDNI Logging File: a file containing CDNI Logging Records, as well as 169 additional information facilitating the processing of the CDNI 170 Logging Records. 172 CDN Reporting: the process of providing the relevant information that 173 will be used to create a formatted content delivery report provided 174 to the CSP in deferred time. Such information typically includes 175 aggregated data that can cover a large period of time (e.g., from 176 hours to several months). Uses of Reporting include the collection 177 of charging data related to CDN services and the computation of Key 178 Performance Indicators (KPIs). 180 CDN Monitoring: the process of providing or displaying content 181 delivery information in a timely fashion with respect to the 182 corresponding deliveries. Monitoring typically includes visibility 183 of the deliveries in progress for service operation purposes. It 184 presents a view of the global health of the services as well as 185 information on usage and performance, for network services 186 supervision and operation management. In particular, monitoring data 187 can be used to generate alarms. 189 1.2. Requirements Language 191 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 192 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 193 document are to be interpreted as described in RFC 2119 [RFC2119]. 195 2. CDNI Logging Reference Model 197 2.1. CDNI Logging interactions 199 The CDNI logging reference model between a given uCDN and a given 200 dCDN involves the following interactions: 202 o customization by the uCDN of the CDNI Logging information to be 203 provided by the dCDN to the uCDN (e.g., control of which CDNI 204 Logging Fields are to be communicated to the uCDN for a given task 205 performed by the dCDN or control of which types of events are to 206 be logged). The dCDN takes into account this CDNI Logging 207 customization information to determine what Logging information to 208 provide to the uCDN, but it may, or may not, take into account 209 this CDNI Logging customization information to influence what CDN 210 logging information is to be generated and collected within the 211 dCDN (e.g., even if the uCDN requests a restricted subset of the 212 logging information, the dCDN may elect to generate a broader set 213 of logging information). The mechanism to support the 214 customization by the uCDN of CDNI Logging information is outside 215 the scope of this document and left for further study. Until such 216 a mechanism is available, the uCDN and dCDN are expected to agree 217 off-line on what exact set of CDNI Logging information is to be 218 provided by the dCDN to the uCDN, and to rely on management plane 219 actions to configure the CDNI Logging functions in the dCDN to 220 generate this information set and in the uCDN to expect this 221 information set. 223 o generation and collection by the dCDN of the intra-CDN Logging 224 information related to the completion of any task performed by the 225 dCDN on behalf of the uCDN (e.g., delivery of the content to an 226 End User) or related to events happening in the dCDN that are 227 relevant to the uCDN (e.g., failures or unavailability in dCDN). 228 This takes place within the dCDN and does not directly involve 229 CDNI interfaces. 231 o communication by the dCDN to the uCDN of the Logging information 232 collected by the dCDN relevant to the uCDN. This is supported by 233 the CDNI Logging interface and in the scope of the present 234 document. For example, the uCDN may use this Logging information 235 to charge the CSP, to perform analytics and monitoring for 236 operational reasons, to provide analytics and monitoring views on 237 its content delivery to the CSP or to perform trouble-shooting. 238 This document exclusively specifies non-real-time exchange of 239 Logging information. Closer to real-time exchange of Logging 240 information (say sub-minute or sub-second) is outside the scope of 241 the present document and left for further study. This document 242 exclusively specifies exchange of Logging information related to 243 content delivery. Exchange of Logging information related to 244 operational events (e.g., dCDN request routing function 245 unavailable, content acquisition failure by dCDN) for audit or 246 operational reactive adjustments by uCDN is outside the scope of 247 the present document and left for further study. 249 o customization by the dCDN of the CDNI Logging information to be 250 provided by the uCDN on behalf of the dCDN. The mechanism to 251 support the customization by the dCDN of CDNI Logging information 252 is outside the scope of this document and left for further study. 254 o generation and collection by the uCDN of Intra-CDN Logging 255 information related to the completion of any task performed by the 256 uCDN on behalf of the dCDN (e.g., serving of content by uCDN to 257 dCDN for acquisition purposes by dCDN) or related to events 258 happening in the uCDN that are relevant to the dCDN. This takes 259 place within the uCDN and does not directly involve CDNI 260 interfaces. 262 o communication by the uCDN to the dCDN of the Logging information 263 collected by the uCDN relevant to the dCDN. For example, the dCDN 264 might potentially benefit from this information for security 265 auditing or content acquisition troubleshooting. This is outside 266 the scope of this document and left for further study. 268 Figure 1 provides an example of CDNI Logging interactions (focusing 269 only on the interactions that are in the scope of this document) in a 270 particular scenario where four CDNs are involved in the delivery of 271 content from a given CSP: the uCDN has a CDNI interconnection with 272 dCDN-1 and dCDN-2. In turn, dCDN-2 has a CDNI interconnection with 273 dCDN-3, where dCDN-2 is acting as an upstream CDN relative to dCDN-3. 274 In this example, uCDN, dCDN-1, dCDN-2 and dCDN-3 all participate in 275 the delivery of content for the CSP. In this example, the CDNI 276 Logging interface enables the uCDN to obtain Logging information from 277 all the dCDNs involved in the delivery. In the example, the uCDN 278 uses the Logging information: 280 o to analyze the performance of the delivery performed by the dCDNs 281 and to adjust its operations after the fact (e.g., request 282 routing) as appropriate, 284 o to provide (non-real-time) reporting and monitoring information to 285 the CSP. 287 For instance, the uCDN merges Logging information, extracts relevant 288 KPIs, and presents a formatted report to the CSP, in addition to a 289 bill for the content delivered by uCDN itself or by its dCDNs on the 290 CSP's behalf. The uCDN may also provide Logging information as raw 291 log files to the CSP, so that the CSP can use its own logging 292 analysis tools. 294 +-----+ 295 | CSP | 296 +-----+ 297 ^ Reporting and monitoring data 298 * Billing 299 ,--*--. 300 Logging ,-' `-. 301 Data =>( uCDN )<= Logging 302 // `-. _,-' \\ Data 303 || `-'-'-' || 304 ,-----. ,-----. 305 ,-' `-. ,-' `-. 306 ( dCDN-1 ) ( dCDN-2 )<== Logging 307 `-. ,-' `-. _,-' \\ Data 308 `--'--' `--'-' || 309 ,-----. 310 ,' `-. 311 ( dCDN-3 ) 312 `. ,-' 313 `--'--' 315 ===> CDNI Logging Interface 316 ***> outside the scope of CDNI 318 Figure 1: Interactions in CDNI Logging Reference Model 320 A downstream CDN relative to uCDN (e.g., dCDN-2) integrates the 321 relevant Logging information obtained from its own downstream CDNs 322 (i.e., dCDN-3) in the Logging information that it provides to the 323 uCDN, so that the uCDN ultimately obtains all Logging information 324 relevant to a CSP for which it acts as the authoritative CDN. Such 325 aggregation is further discussed in Section 3.6. 327 Note that the format of Logging information that a CDN provides over 328 the CDNI interface might be different from the one that the CDN uses 329 internally. In this case, the CDN needs to reformat the Logging 330 information before it provides this information to the other CDN over 331 the CDNI Logging interface. Similarly, a CDN might reformat the 332 Logging information that it receives over the CDNI Logging interface 333 before injecting it into its log-consuming applications or before 334 providing some of this Logging information to the CSP. Such 335 reformatting operations introduce latency in the logging distribution 336 chain and introduce a processing burden. Therefore, there are 337 benefits in specifying CDNI Logging formats that are suitable for use 338 inside CDNs and also are close to the intra-CDN Logging formats 339 commonly used in CDNs today. 341 2.2. Overall Logging Chain 343 This section discusses the overall logging chain within and across 344 CDNs to clarify how CDN Logging information is expected to fit in 345 this overall chain. Figure 2 illustrates the overall logging chain 346 within the dCDN, across CDNs using the CDNI Logging interface and 347 within the uCDN. Note that the logging chain illustrated in the 348 Figure is obviously only an example and varies depending on the 349 specific environments. For example, there may be more or fewer 350 instantiations of each entity (e.g., there may be 4 Log consuming 351 applications in a given CDN). As another example, there may be one 352 instance of Rectification process per Log Consuming Application 353 instead of a shared one. 355 Log Consuming Log Consuming 356 App App 357 ^ ^ 358 | | 359 Rectification---------- 360 ^ 361 | 362 Filtering 363 ^ 364 | 365 Collection 366 ^ ^ 367 | | 368 | Generation 369 | 370 | uCDN 371 CDNI Logging --------------------------------------------------- 372 exchange dCDN 373 ^ 374 | Log Consuming Log Consuming 375 | App App 376 | ^ ^ 377 | | | 378 Rectification Rectification--------- 379 ^ ^ 380 | | 381 Filtering 382 ^ 383 | 384 Collection 385 ^ ^ 386 | | 387 Generation Generation 389 Figure 2: CDNI Logging in the overall Logging Chain 391 The following subsections describe each of the processes potentially 392 involved in the logging chain of Figure 2. 394 2.2.1. Logging Generation and During-Generation Aggregation 396 CDNs typically generate Logging information for all significant task 397 completions, events, and failures. Logging information is typically 398 generated by many devices in the CDN including the surrogates, the 399 request routing system, and the control system. 401 The amount of Logging information generated can be huge. Therefore, 402 during contract negotiations, interconnected CDNs often agree on a 403 retention duration for Logging information, and/or potentially on a 404 maximum volume of Logging information that the dCDN ought to keep. 405 If this volume is exceeded, the dCDN is expected to alert the uCDN 406 but may not keep more Logging information for the considered time 407 period. In addition, CDNs may aggregate Logging information and 408 transmit only summaries for some categories of operations instead of 409 the full Logging information. Note that such aggregation leads to an 410 information loss, which may be problematic for some usages of the 411 Logging information (e.g., debugging). 413 [RFC6983] discusses logging for HTTP Adaptive Streaming (HAS). In 414 accordance with the recommendations articulated there, it is expected 415 that a surrogate will generate separate Logging information for 416 delivery of each chunk of HAS content. This ensures that separate 417 Logging information can then be provided to interconnected CDNs over 418 the CDNI Logging interface. Still in line with the recommendations 419 of [RFC6983], the Logging information for per-chunk delivery may 420 include some information (a Content Collection IDentifier and a 421 Session IDentifier) intended to facilitate subsequent post-generation 422 aggregation of per-chunk logs into per-session logs. Note that a CDN 423 may also elect to generate aggregate per-session logs when performing 424 HAS delivery, but this needs to be in addition to, and not instead 425 of, the per-chunk delivery logs. We note that aggregate per-session 426 logs for HAS delivery are for further study and outside the scope of 427 this document. 429 2.2.2. Logging Collection 431 This is the process that continuously collects Logging information 432 generated by the log-generating entities within a CDN. 434 In a CDNI environment, in addition to collecting Logging information 435 from log-generating entities within the local CDN, the Collection 436 process also collects Logging information provided by another CDN, or 437 other CDNs, through the CDNI Logging interface. This is illustrated 438 in Figure 2 where we see that the Collection process of the uCDN 439 collects Logging information from log-generating entities within the 440 uCDN as well as Logging information coming from the dCDNs through the 441 CDNI Logging interface. 443 2.2.3. Logging Filtering 445 A CDN may be required to only present different subsets of the whole 446 Logging information collected to various log-consuming applications. 447 This is achieved by the Filtering process. 449 In particular, the Filtering process can also filter the right subset 450 of Logging information that needs to be provided to a given 451 interconnected CDN. For example, the filtering process in the dCDN 452 can be used to ensure that only the Logging information related to 453 tasks performed on behalf of a given uCDN are made available to that 454 uCDN (thereby filtering out all the Logging information related to 455 deliveries by the dCDN of content for its own CSPs). Similarly, the 456 Filtering process may filter or partially mask some fields, for 457 example, to protect End Users' privacy when communicating CDNI 458 Logging information to another CDN. Filtering of Logging information 459 prior to communication of this information to other CDNs via the CDNI 460 Logging interface requires that the downstream CDN can recognize the 461 subset of Logging information that relate to each interconnected CDN. 463 The CDN will also filter some internal scope information such as 464 information related to its internal alarms (security, failures, load, 465 etc). 467 In some use cases described in [RFC6770], the interconnected CDNs do 468 not want to disclose details on their internal topology. The 469 filtering process can then also filter confidential data on the 470 dCDNs' topology (number of servers, location, etc.). In particular, 471 information about the requests served by each Surrogate may be 472 confidential. Therefore, the Logging information needs to be 473 protected so that data such as Surrogates' hostnames are not 474 disclosed to the uCDN. In the "Inter-Affiliates Interconnection" use 475 case, this information may be disclosed to the uCDN because both the 476 dCDN and the uCDN are operated by entities of the same group. 478 2.2.4. Logging Rectification and Post-Generation Aggregation 480 If Logging information is generated periodically, it is important 481 that the sessions that start in one Logging period and end in another 482 are correctly reported. If they are reported in the starting period, 483 then the Logging information of this period will be available only 484 after the end of the session, which delays the Logging information 485 generation. A simple approach is to provide the complete Logging 486 Record for a session in the Logging Period of the session end. 488 A Logging rectification/update mechanism could be useful to reach a 489 good trade-off between the Logging information generation delay and 490 the Logging information accuracy. 492 In the presence of HAS, some log-consuming applications can benefit 493 from aggregate per-session logs. For example, for analytics, per- 494 session logs allow display of session-related trends which are much 495 more meaningful for some types of analysis than chunk-related trends. 496 In the case where aggregate logs have been generated directly by the 497 log-generating entities, those can be used by the applications. In 498 the case where aggregate logs have not been generated, the 499 Rectification process can be extended with a Post-Generation 500 Aggregation process that generates per-session logs from the per- 501 chunk logs, possibly leveraging the information included in the per- 502 chunk logs for that purpose (Content Collection IDentifier and a 503 Session IDentifier). However, in accordance with [RFC6983], this 504 document does not define exchange of such aggregate logs on the CDNI 505 Logging interface. We note that this is for further study and 506 outside the scope of this document. 508 2.2.5. Log-Consuming Applications 510 2.2.5.1. Maintenance/Debugging 512 Logging information is useful to permit the detection (and limit the 513 risk) of content delivery failures. In particular, Logging 514 information facilitates the detection of configuration issues. 516 To detect faults, Logging information needs to report success and 517 failure of CDN delivery operations. The uCDN can summarize such 518 information into KPIs. For instance, Logging information needs to 519 allow the computation of the number of times, during a given time 520 period, that content delivery related to a specific service succeeds/ 521 fails. 523 Logging information enables the CDN providers to identify and 524 troubleshoot performance degradations. In particular, Logging 525 information enables tracking of traffic data (e.g., the amount of 526 traffic that has been forwarded by a dCDN on behalf of an uCDN over a 527 given period of time), which is particularly useful for CDN and 528 network planning operations. 530 Some of these maintenance and debugging applications only require 531 aggregate logging information highly compatible with anonymization of 532 IP addresses (as supported by the present document and specified in 533 Section 3.4.1). However, in some situations, it may be useful, where 534 compatible with privacy protection, to access some CDNI Logging 535 Records containing full non-anonymized IP addresses. For example, 536 this may be useful for detailed fault tracking of a particular end 537 user content delivery issue. 539 2.2.5.2. Accounting 541 Logging information is essential for accounting, to permit inter-CDN 542 billing and CSP billing by uCDNs. For instance, Logging information 543 provided by dCDNs enables the uCDN to compute the total amount of 544 traffic delivered by every dCDN for a particular Content Provider, as 545 well as, the associated bandwidth usage (e.g., peak, 95th 546 percentile), and the maximum number of simultaneous sessions over a 547 given period of time. 549 2.2.5.3. Analytics and Reporting 551 The goal of analytics is to gather any relevant information to track 552 audience, analyze user behavior, and monitor the performance and 553 quality of content delivery. For instance, Logging information 554 enables the CDN providers to report on content consumption (e.g., 555 delivered sessions per content) in a specific geographic area. 557 The goal of reporting is to gather any relevant information to 558 monitor the performance and quality of content delivery and allow 559 detection of delivery issues. For instance, reporting could track 560 the average delivery throughput experienced by End Users in a given 561 region for a specific CSP or content set over a period of time. 563 2.2.5.4. Content Protection 565 The goal of content protection is to prevent and monitor unauthorized 566 access, misuse, modification, and denial of access to a content. A 567 set of information is logged in a CDN for security purposes. In 568 particular, a record of access to content is usually collected to 569 permit the CSP to detect infringements of content delivery policies 570 and other abnormal End User behaviors. 572 2.2.5.5. Notions common to multiple Log Consuming Applications 574 2.2.5.5.1. Logging Information Views 576 Within a given log-consuming application, different views may be 577 provided to different users depending on privacy, business, and 578 scalability constraints. 580 For example, an analytics tool run by the uCDN can provide one view 581 to an uCDN operator that exploits all the Logging information 582 available to the uCDN, while the tool may provide a different view to 583 each CSP exploiting only the Logging information related to the 584 content of the given CSP. 586 As another example, maintenance and debugging tools may provide 587 different views to different CDN operators, based on their 588 operational role. 590 2.2.5.5.2. Key Performance Indicators (KPIs) 592 This section presents, for explanatory purposes, a non-exhaustive 593 list of Key Performance Indicators (KPIs) that can be extracted/ 594 produced from logs. 596 Multiple log-consuming applications, such as analytics, monitoring, 597 and maintenance applications, often compute and track such KPIs. 599 In a CDNI environment, depending on the situation, these KPIs may be 600 computed by the uCDN or by the dCDN. But it is usually the uCDN that 601 computes KPIs, because the uCDN and dCDN may have different 602 definitions of the KPIs and the computation of some KPIs requires a 603 vision of all the deliveries performed by the uCDN and all its dCDNs. 605 Here is a list of important examples of KPIs: 607 o Number of delivery requests received from End Users in a given 608 region for each piece of content, during a given period of time 609 (e.g., hour/day/week/month) 611 o Percentage of delivery successes/failures among the aforementioned 612 requests 614 o Number of failures listed by failure type (e.g., HTTP error code) 615 for requests received from End Users in a given region and for 616 each piece of content, during a given period of time (e.g., 617 hour/day/week/month) 619 o Number and cause of premature delivery termination for End Users 620 in a given region and for each piece of content, during a given 621 period of time (e.g., hour/day/week/month) 623 o Maximum and mean number of simultaneous sessions established by 624 End Users in a given region, for a given Content Provider, and 625 during a given period of time (e.g., hour/day/week/month) 627 o Volume of traffic delivered for sessions established by End Users 628 in a given region, for a given Content Provider, and during a 629 given period of time (e.g., hour/day/week/month) 631 o Maximum, mean, and minimum delivery throughput for sessions 632 established by End Users in a given region, for a given Content 633 Provider, and during a given period of time (e.g., hour/day/week/ 634 month) 636 o Cache-hit and byte-hit ratios for requests received from End Users 637 in a given region for each piece of content, during a given period 638 of time (e.g., hour/day/week/month) 640 o Top 10 most popularly requested contents (during a given day/week/ 641 month) 643 o Terminal type (mobile, PC, STB, if this information can be 644 acquired from the browser type inferred from the User Agent 645 string, for example). 647 Additional KPIs can be computed from other sources of information 648 than the Logging information, for instance, data collected by a 649 content portal or by specific client-side application programming 650 interfaces. Such KPIs are out of scope for the present document. 652 The KPIs used depend strongly on the considered log-consuming 653 application -- the CDN operator may be interested in different 654 metrics than the CSP is. In particular, CDN operators are often 655 interested in delivery and acquisition performance KPIs, information 656 related to Surrogates' performance, caching information to evaluate 657 the cache-hit ratio, information about the delivered file size to 658 compute the volume of content delivered during peak hour, etc. 660 Some of the KPIs, for instance those providing an instantaneous 661 vision of the active sessions for a given CSP's content, are useful 662 essentially if they are provided in a timely manner. By contrast, 663 some other KPIs, such as those averaged on a long period of time, can 664 be provided in non-real-time. 666 3. CDNI Logging File 668 3.1. Rules 670 This specification uses the Augmented Backus-Naur Form (ABNF) 671 notation and core rules of [RFC5234]. In particular, the present 672 document uses the following rules from [RFC5234]: 674 CR = %x0D ; carriage return 676 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z 678 DIGIT = %x30-39 ; 0-9 680 DQUOTE = %x22 ; " (Double Quote) 682 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 OCTET = %x00-FF ; 8 bits of data 691 The present document also uses the following rules from [RFC3986]: 693 host = as specified in section 3.2.2 of [RFC3986]. 695 IPv4address = as specified in section 3.2.2 of [RFC3986]. 697 IPv6address = as specified in section 3.2.2 of [RFC3986]. 699 The present document also defines the following additional rules: 701 ADDRESS = IPv4address / IPv6address 703 ALPHANUM = ALPHA / DIGIT 705 DATE = 4DIGIT "-" 2DIGIT "-" 2DIGIT 707 Dates are encoded as "full-date" specified in [RFC3339]. 709 DEC = 1*DIGIT ["." *DIGIT] 711 NAMEFORMAT = ALPHANUM *(ALPHANUM / "_" / "-") 713 QSTRING = DQUOTE *NDQUOTE DQUOTE 715 NDQUOTE = / 2DQUOTE ; whereby a 716 DQUOTE is conveyed inside a QSTRING unambiguously by repeating it. 718 [Editor's Note: The definition of NDQUOTE is being discussed as 719 part of IESG review and needs editing] 721 NHTABSTRING = *NHTAB 723 NHTAB = 725 TIME = 2DIGIT ":" 2DIGIT ":" 2DIGIT ["." *DIGIT] 727 Times are encoded as "partial-time" specified in [RFC3339]. 729 3.2. CDNI Logging File Structure 731 As defined in Section 1.1: a CDNI Logging Field is as an atomic 732 logging information element, a CDNI Logging Record is a collection of 733 CDNI Logging Fields containing all logging information corresponding 734 to a single logging event, and a CDNI Logging File contains a 735 collection of CDNI Logging Records. This structure is illustrated in 736 Figure 3. The use of a file structure for transfer of CDNI Logging 737 information is selected since this is the most common practise today 738 for exchange of logging information within and across CDNs. 740 +----------------------------------------------------------+ 741 |CDNI Logging File | 742 | | 743 | #Directive 1 | 744 | #Directive 2 | 745 | ... | 746 | #Directive P | 747 | | 748 | +------------------------------------------------------+ | 749 | |CDNI Logging Record 1 | | 750 | | +-------------+ +-------------+ +-------------+ | | 751 | | |CDNI Logging | |CDNI Logging | ... |CDNI Logging | | | 752 | | | Field 1 | | Field 2 | | Field N | | | 753 | | +-------------+ +-------------+ +-------------+ | | 754 | +------------------------------------------------------+ | 755 | | 756 | +------------------------------------------------------+ | 757 | |CDNI Logging Record 2 | | 758 | | +-------------+ +-------------+ +-------------+ | | 759 | | |CDNI Logging | |CDNI Logging | ... |CDNI Logging | | | 760 | | | Field 1 | | Field 2 | | Field N | | | 761 | | +-------------+ +-------------+ +-------------+ | | 762 | +------------------------------------------------------+ | 763 | | 764 | ... | 765 | | 766 | #Directive P+1 | 767 | | 768 | ... | 769 | | 770 | +------------------------------------------------------+ | 771 | |CDNI Logging Record M | | 772 | | +-------------+ +-------------+ +-------------+ | | 773 | | |CDNI Logging | |CDNI Logging | ... |CDNI Logging | | | 774 | | | Field 1 | | Field 2 | | Field N | | | 775 | | +-------------+ +-------------+ +-------------+ | | 776 | +------------------------------------------------------+ | 777 | | 778 | | 779 | #Directive P+Q | 780 +----------------------------------------------------------+ 782 Figure 3: Structure of Logging Files 784 The CDNI Logging File format is inspired from the W3C Extended Log 785 File Format [ELF]. However, it is fully specified by the present 786 document. Where the present document differs from the W3C Extended 787 Log File Format, an implementation of the CDNI Logging interface MUST 788 comply with the present document. The W3C Extended Log File Format 789 was used as a starting point, reused where possible and expanded when 790 necessary. 792 Using a format that resembles the W3C Extended Log File Format is 793 intended to keep CDNI logging format close to the intra-CDN Logging 794 information format commonly used in CDNs today, thereby minimizing 795 systematic translation at CDN/CDNI boundary. 797 A CDNI Logging File MUST contain a sequence of lines containing US- 798 ASCII characters [CHAR_SET] terminated by CRLF. [Editor's Note: This 799 needs editing to explain explain how CRLF/HTAB inside a QSTRING does 800 not act as a separator. ] 802 Each line of a CDNI Logging File MUST contain either a directive or a 803 CDNI Logging Record. 805 Directives record information about the CDNI Logging process itself. 806 Lines containing directives MUST begin with the "#" character. 807 Directives are specified in Section 3.3. 809 Logging Records provide actual details of the logged event. Logging 810 Records are specified in Section 3.4. 812 The CDNI Logging File ("CDNILOGFILE") structure is defined by the 813 following rules: 815 DIRLINE = "#" directive CRLF 817 DIRGROUP = 1*DIRLINE 819 RECLINE = CDNILOGREC CRLF 821 RECGROUP = *RECLINE 823 CDNILOGFILE = 1*(DIRGROUP RECGROUP) 825 See Section 3.4 for the definition of CDNILOGREC. 827 3.3. CDNI Logging Directives 829 The CDNI Logging directives are defined by the following rules: 831 directive = DIRNAME ":" HTAB DIRVAL 833 DIRNAME = NAMEFORMAT 834 DIRNAME = 837 DIRVAL = 841 An implementation of the CDNI Logging interface MUST support all of 842 the following directives, listed below by their directive name: 844 o Version: 846 * format: NHTABSTRING 848 * directive value: indicates the version of the CDNI Logging File 849 format. The entity transmitting a CDNI Logging File as per the 850 present document MUST set the value to "CDNI/1.0". In the 851 future, other versions of CDNI Logging File might be specified; 852 those would use a value different to "CDNI/1.0" allowing the 853 entity receiving the CDNI Logging File to identify the 854 corresponding version. 856 * occurrence: there MUST be one and only one instance of this 857 directive per CDNI Logging File. It MUST be the first line of 858 the CDNI Logging File. 860 o UUID: 862 * format: NHTABSTRING 864 * directive value: this a Uniform Resource Name (URN) from the 865 Universally Unique IDentifier (UUID) URN namespace specified in 866 [RFC4122]). The UUID contained in the URN uniquely identifies 867 the CDNI Logging File. 869 * occurrence: there MUST be one and only one instance of this 870 directive per CDNI Logging File. 872 o Claimed-Origin: 874 * format: host 876 * directive value: this contains the claimed identification of 877 the entity transmitting the CDNI Logging File (e.g., the host 878 in a dCDN supporting the CDNI Logging interface) or the entity 879 responsible for transmitting the CDNI Logging File (e.g., the 880 dCDN). 882 * occurrence: there MUST be zero or exactly one instance of this 883 directive per CDNI Logging File. This directive MAY be 884 included by the dCDN. It MUST NOT be included or modified by 885 the uCDN. 887 o Established-Origin: 889 * format: host 891 * directive value: this contains the identification, as 892 established by the entity receiving the CDNI Logging File, of 893 the entity transmitting the CDNI Logging File (e.g., the host 894 in a dCDN supporting the CDNI Logging interface) or the entity 895 responsible for transmitting the CDNI Logging File (e.g., the 896 dCDN). 898 * occurrence: there MUST be zero or exactly one instance of this 899 directive per CDNI Logging File. This directive MAY be added 900 by the uCDN (e.g., before storing the CDNI Logging File). It 901 MUST NOT be included by the dCDN. The mechanisms used by the 902 uCDN to establish and validate the entity responsible for the 903 CDNI Logging File is outside the scope of the present document. 904 We observe that, in particular, this may be achieved through 905 authentication mechanisms that are part of the transport layer 906 of the CDNI Logging File pull mechanism (Section 4.2). 908 o Remark: 910 * format: NHTABSTRING 912 * directive value: this contains comment information. Data 913 contained in this field is to be ignored by analysis tools. 915 * occurrence: there MAY be zero, one or any number of instance of 916 this directive per CDNI Logging File. 918 o Record-Type: 920 * format: NAMEFORMAT 922 * directive value: indicates the type of the CDNI Logging Records 923 that follow this directive, until another Record-Type directive 924 (or the end of the CDNI Logging File). This can be any CDNI 925 Logging Record type registered in the CDNI Logging Record-types 926 registry (Section 6.3). For example this may be 927 "cdni_http_request_v1" as specified in Section 3.4.1. 929 * occurrence: there MUST be at least one instance of this 930 directive per CDNI Logging File. The first instance of this 931 directive MUST precede a Fields directive and MUST precede all 932 CDNI Logging Records. 934 o Fields: 936 * format: FIENAME *(HTAB FIENAME) ; where FIENAME can take any 937 CDNI Logging field name registered in the CDNI Logging Field 938 Names registry (Section 6.4). 940 * directive value: this lists the names of all the fields for 941 which a value is to appear in the CDNI Logging Records that 942 follow the instance of this directive (until another instance 943 of this directive). The names of the fields, as well as their 944 occurrences, MUST comply with the corresponding rules specified 945 in the document referenced in the CDNI Logging Record-types 946 registry (Section 6.3) for the corresponding CDNI Logging 947 Record-Type. 949 * occurrence: there MUST be at least one instance of this 950 directive per Record-Type directive. The first instance of 951 this directive for a given Record-Type MUST appear before any 952 CDNI Logging Record for this Record-Type. One situation where 953 more than one instance of the Fields directive can appear 954 within a given CDNI Logging File, is when there is a change, in 955 the middle of a fairly large logging period, in the agreement 956 between the uCDN and the dCDN about the set of Fields that are 957 to be exchanged. The multiple occurrences allow records with 958 the old set of fields and records with the new set of fields to 959 be carried inside the same Logging File. 961 o SHA256-Hash: 963 * format: 32HEXDIG 965 * directive value: This directive permits the detection of a 966 corrupted CDNI Logging File. This can be useful, for instance, 967 if a problem occurs on the filesystem of the dCDN Logging 968 system and leads to a truncation of a logging file. The valid 969 SHA256-Hash value is included in this directive by the entity 970 that transmits the CDNI Logging File. It MUST be computed by 971 applying the SHA-256 ([RFC6234]) cryptographic hash function on 972 the CDNI Logging File, including all the directives and logging 973 records, up to the SHA256-Hash directive itself, excluding the 974 SHA256-Hash directive itself. The SHA256-Hash value MUST be 975 represented as a US-ASCII encoded hexadecimal number, 64 digits 976 long (representing a 256 bit hash value). The entity receiving 977 the CDNI Logging File also computes in a similar way the 978 SHA-256 hash on the received CDNI Logging File and compares 979 this hash to the value of the SHA256-Hash directive. If the 980 two values are equal, then the received CDNI Logging File is to 981 be considered non-corrupted. If the two values are different, 982 the received CDNI Logging File is to be considered corrupted. 983 The behavior of the entity that received a corrupted CDNI 984 Logging File is outside the scope of this specification; we 985 note that the entity MAY attempt to pull again the same CDNI 986 Logging File from the transmitting entity. If the entity 987 receiving a non-corrupted CDNI Logging File adds an 988 Established-Origin directive, it MUST then recompute and update 989 the SHA256-Hash directive so it also protects the added 990 Established-Origin directive. 992 * occurrence: there MUST be zero or exactly one instance of this 993 directive. There SHOULD be exactly one instance of this 994 directive. One situation where that directive could be omitted 995 is where integrity protection is already provided via another 996 mechanism (for example if an integrity hash is associated to 997 the CDNI Logging File out of band through the CDNI Logging Feed 998 ( Section 4.1) leveraging ATOM extensions such as those 999 proposed in [I-D.snell-atompub-link-extensions]. When present, 1000 the SHA256-Hash field MUST be the last line of the CDNI Logging 1001 File. 1003 An uCDN-side implementation of the CDNI Logging interface MUST reject 1004 a CDNI Logging File that does not comply with the occurences 1005 specified above for each and every directive. For example, an uCDN- 1006 side implementation of the CDNI Logging interface receiving a CDNI 1007 Logging file with zero occurence of the Version directive, or with 1008 two occurences of the SHA256-Hash, MUST reject this CDNI Logging 1009 File. 1011 An entity receiving a CDNI Logging File with a value set to 1012 "CDNI/1.0" MUST process the CDNI Logging File as per the present 1013 document. An entity receiving a CDNI Logging File with a value set 1014 to a different value MUST process the CDNI Logging File as per the 1015 specification referenced in the CDNI Logging File Version registry 1016 (see Section 6.1) if the implementation supports this specification 1017 and MUST reject the CDNI Logging File otherwise. 1019 3.4. CDNI Logging Records 1021 A CDNI Logging Record consists of a sequence of CDNI Logging Fields 1022 relating to that single CDNI Logging Record. 1024 CDNI Logging Fields MUST be separated by the "horizontal tabulation 1025 (HTAB)" character. [Editor's Note: This needs editing to explain 1026 explain how CRLF/HTAB inside a QSTRING does not act as a separator. 1027 ] 1029 To facilitate readability, a prefix scheme is used for CDNI Logging 1030 field names in a similar way to the one used in W3C Extended Log File 1031 Format [ELF]. The semantics of the prefix in the present document 1032 is: 1034 o "c-" refers to the User Agent that issues the request (corresponds 1035 to the "client" of W3C Extended Log Format) 1037 o "d-" refers to the dCDN (relative to a given CDN acting as a uCDN) 1039 o "s-" refers to the dCDN Surrogate that serves the request 1040 (corresponds to the "server" of W3C Extended Log Format) 1042 o "u-" refers to the uCDN (relative to a given CDN acting as a dCDN) 1044 o "cs-" refers to communication from the User Agent towards the dCDN 1045 Surrogate 1047 o "sc-" refers to communication from the dCDN Surrogate towards the 1048 User Agent 1050 An implementation of the CDNI Logging interface as per the present 1051 specification MUST support the CDNI HTTP Request Logging Record as 1052 specified in Section 3.4.1. 1054 A CDNI Logging Record (CDNILOGREC) is defined by the following rules: 1056 CDNILOGREC = FIEVAL *(HTAB FIEVAL) 1058 FIEVAL = 1062 3.4.1. HTTP Request Logging Record 1064 This section defines the CDNI Logging Record of Record-Type 1065 "cdni_http_request_v1". It is applicable to content delivery 1066 performed by the dCDN using HTTP/1.0([RFC1945]), 1067 HTTP/1.1([RFC7230],[RFC7231], [RFC7232], [RFC7233], [RFC7234], 1068 [RFC7235]) or HTTPS ([RFC2818], [RFC7230]). We observe that, in the 1069 case of HTTPS delivery, there may be value in logging additional 1070 information specific to the operation of HTTP over TLS and we note 1071 that this is outside the scope of the present document and may be 1072 addressed in a future document defining another CDNI Logging Record 1073 or another version of the HTTP Request Logging Record. 1075 The "cdni_http_request_v1" Record-Type is also expected to be 1076 applicable to HTTP/2 [I-D.ietf-httpbis-http2] (which is still under 1077 development at the time of writing the present document) since a 1078 fundamental design tenet of HTTP/2 is to preserve the HTTP/1.1 1079 semantics. We observe that, in the case of HTTP/2 delivery, there 1080 may be value in logging additional information specific to the 1081 additional functionality of HTTP/2 (e.g. information related to 1082 connection identification, to stream identification, to stream 1083 priority and to flow control). We note that such additional 1084 information is outside the scope of the present document and may be 1085 addressed in a future document defining another CDNI Logging Record 1086 or another version of the HTTP Request Logging Record. 1088 The "cdni_http_request_v1" Record-Type contains the following CDNI 1089 Logging Fields, listed by their field name: 1091 o date: 1093 * format: DATE 1095 * field value: the date at which the processing of request 1096 completed on the Surrogate. 1098 * occurrence: there MUST be one and only one instance of this 1099 field. 1101 o time: 1103 * format: TIME 1105 * field value: the time at which the processing of request 1106 completed on the Surrogate. 1108 * occurrence: there MUST be one and only one instance of this 1109 field. 1111 o time-taken: 1113 * format: DEC 1115 * field value: decimal value of the duration, in seconds, between 1116 the start of the processing of the request and the completion 1117 of the request processing (e.g., completion of delivery) by the 1118 Surrogate. 1120 * occurrence: there MUST be one and only one instance of this 1121 field. 1123 o c-ip: 1125 * format: ADDRESS 1127 * field value: the source IPv4 or IPv6 address (i.e., the 1128 "client" address) in the request received by the Surrogate. 1130 * occurrence: there MUST be one and only one instance of this 1131 field. 1133 o c-ip-anonymizing: 1135 * format: 1*DIGIT 1137 * field value: the number of rightmost bits of the IPv4 address 1138 in the c-ip field that are zeroed-out in order to anonymize the 1139 logging record. The mechanism by which the two ends of the 1140 CDNI Logging interface agree on whether anonymization is to be 1141 supported and the number of bits that need to be zeroed-out for 1142 this purpose are outside the scope of the present document. 1143 IPv4 addresses SHOULD be anonymized to /24 boundary (i.e., with 1144 c-ip-anonymizing set to 8), and IPv6 addresses SHOULD be 1145 anonymized to a /48 boundary (i.e., with c-ip-anonymizing set 1146 to 80). 1148 * occurrence: there MUST be zero or exactly one instance of this 1149 field. 1151 o c-port: 1153 * format: 1*DIGIT 1155 * field value: the source TCP port (i.e., the "client" port) in 1156 the request received by the Surrogate. 1158 * occurrence: there MUST be zero or exactly one instance of this 1159 field. 1161 o c-port-anonymizing: 1163 * format: 1*DIGIT 1165 * field value: the number of rightmost bits of the port in the 1166 c-port field that are zeroed-out in order to anonymize the 1167 logging record. The mechanism by which the two ends of the 1168 CDNI Logging interface agree on whether anonymization is to be 1169 supported and the number of bits that need to be zeroed-out for 1170 this purpose are outside the scope of the present document. 1172 * occurrence: there MUST be zero or exactly one instance of this 1173 field. 1175 o s-ip: 1177 * format: ADDRESS 1179 * field value: the IPv4 or IPv6 address of the Surrogate that 1180 served the request (i.e., the "server" address). 1182 * occurrence: there MUST be zero or exactly one instance of this 1183 field. 1185 o s-hostname: 1187 * format: host 1189 * field value: the hostname of the Surrogate that served the 1190 request (i.e., the "server" hostname). 1192 * occurrence: there MUST be zero or exactly one instance of this 1193 field. 1195 o s-port: 1197 * format: 1*DIGIT 1199 * field value: the destination TCP port (i.e., the "server" port) 1200 in the request received by the Surrogate. 1202 * occurrence: there MUST be zero or exactly one instance of this 1203 field. 1205 o cs-method: 1207 * format: NHTABSTRING 1209 * field value: this is the method of the request received by the 1210 Surrogate. In the case of HTTP delivery, this is the HTTP 1211 method in the request. 1213 * occurrence: There MUST be one and only one instance of this 1214 field. 1216 o cs-uri: 1218 * format: NHTABSTRING 1220 * field value: this is the "effective request URI" of the request 1221 received by the Surrogate as specified in [RFC7230]. It 1222 complies with the "http" URI scheme or the "https" URI scheme 1223 as specified in [RFC7230]). Note that cs-uri can be privacy 1224 sensitive. In that case, and where appropriate, u-uri could be 1225 used instead of cs-uri. 1227 * occurrence: there MUST be zero or exactly one instance of this 1228 field. 1230 o u-uri: 1232 * format: NHTABSTRING 1234 * field value: this is a complete URI, derived from the 1235 "effective request URI" ([RFC7230]) of the request received by 1236 the Surrogate (i.e., the cs-uri) but transformed by the entity 1237 generating or transmitting the CDNI Logging Record, in a way 1238 that is agreed upon between the two ends of the CDNI Logging 1239 interface, so the transformed URI is meaningful to the uCDN. 1240 For example, the two ends of the CDNI Logging interface could 1241 agree that the u-uri is constructed from the cs-uri by removing 1242 the part of the hostname that exposes which individual 1243 Surrogate actually performed the delivery. The details of 1244 modification performed to generate the u-uri, as well as the 1245 mechanism to agree on these modifications between the two sides 1246 of the CDNI Logging interface are outside the scope of the 1247 present document. 1249 * occurrence: there MUST be one and only one instance of this 1250 field. 1252 o protocol: 1254 * format: NHTABSTRING 1256 * field value: this is value of the HTTP-Version field as 1257 specified in [RFC7230] of the Request-Line of the request 1258 received by the Surrogate (e.g., "HTTP/1.1"). 1260 * occurrence: there MUST be one and only one instance of this 1261 field. 1263 o sc-status: 1265 * format: 3DIGIT 1267 * field value: this is the Status-Code in the response from the 1268 Surrogate. In the case of HTTP delivery, this is the HTTP 1269 Status-Code in the HTTP response. 1271 * occurrence: There MUST be one and only one instance of this 1272 field. 1274 o sc-total-bytes: 1276 * format: 1*DIGIT 1278 * field value: this is the total number of bytes of the response 1279 sent by the Surrogate in response to the request. In the case 1280 of HTTP delivery, this includes the bytes of the Status-Line, 1281 the bytes of the HTTP headers and the bytes of the message- 1282 body. 1284 * occurrence: There MUST be one and only one instance of this 1285 field. 1287 o sc-entity-bytes: 1289 * format: 1*DIGIT 1291 * field value: this is the number of bytes of the message-body in 1292 the HTTP response sent by the Surrogate in response to the 1293 request. This does not include the bytes of the Status-Line or 1294 the bytes of the HTTP headers. 1296 * occurrence: there MUST be zero or exactly one instance of this 1297 field. 1299 o cs(): 1301 * format: QSTRING 1303 * field value: the value of the HTTP header (identified by the 1304 in the CDNI Logging field name) as it 1305 appears in the request processed by the Surrogate, but 1306 prepended by a DQUOTE and appended by a DQUOTE. For example, 1307 when the CDNI Logging field name (FIENAME) listed in the 1308 preceding Fields directive is cs(User-Agent), this CDNI Logging 1309 field value contains the value of the User-Agent HTTP header as 1310 received by the Surrogate in the request it processed, but 1311 prepended by a DQUOTE and appended by a DQUOTE. If the HTTP 1312 header as it appeared in the request processed by the Surrogate 1313 contains one or more DQUOTE, each DQUOTE MUST be escaped by an 1314 additional DQUOTE. For example, if the HTTP header contains 1315 My_Header"value", then the field value of the cs() is "My_Header""value""". The entity transmitting the 1317 CDNI Logging File MUST ensure that the of 1318 the cs(): 1328 * format: QSTRING 1330 * field value: the value of the HTTP header (identified by the 1331 in the CDNI Logging field name) as it 1332 appears in the response issued by the Surrogate to serve the 1333 request, but prepended by a DQUOTE and appended by a DQUOTE. 1334 If the HTTP header as it appeared in the request processed by 1335 the Surrogate contains one or more DQUOTE, each DQUOTE MUST be 1336 escaped by an additional DQUOTE. For example, if the HTTP 1337 header contains My_Header"value", then the field value of the 1338 cs() is "My_Header""value""". The entity 1339 transmitting the CDNI Logging File MUST ensure that the of the cs(, there MUST be 1348 zero or exactly one instance of this field. 1350 o s-ccid: 1352 * format: QSTRING 1354 * field value: this contains the value of the Content Collection 1355 IDentifier (CCID) associated by the uCDN to the content served 1356 by the Surrogate via the CDNI Metadata interface 1357 ([I-D.ietf-cdni-metadata]), prepended by a DQUOTE and appended 1358 by a DQUOTE. If the CCID conveyed in the CDNI Metadata 1359 interface contains one or more DQUOTE, each DQUOTE MUST be 1360 escaped by an additional DQUOTE. For example, if the CCID 1361 conveyed in the CDNI Metadata interface is My_CCIDD"value", 1362 then the field value of the s-ccid is "My_CCID""value""". 1364 * occurrence: there MUST be zero or exactly one instance of this 1365 field. For a given , there MUST be zero or 1366 exactly one instance of this field. 1368 o s-sid: 1370 * format: QSTRING 1372 * field value: this contains the value of a Session IDentifier 1373 (SID) generated by the dCDN for a specific HTTP session, 1374 prepended by a DQUOTE and appended by a DQUOTE. In particular, 1375 for HTTP Adaptive Streaming (HAS) session, the Session 1376 IDentifier value is included in the Logging record for every 1377 content chunk delivery of that session in view of facilitating 1378 the later correlation of all the per content chunk log records 1379 of a given HAS session. See section 3.4.2.2. of [RFC6983] for 1380 more discussion on the concept of Session IDentifier in the 1381 context of HAS. If the SID conveyed contains one or more 1382 DQUOTE, each DQUOTE MUST be escaped by an additional DQUOTE. 1383 For example, if the SID is My_SID"value", then the field value 1384 of the s-sid is "My_SID""value""". 1386 * occurrence: there MUST be zero or exactly one instance of this 1387 field. 1389 o s-cached: 1391 * format: 1DIGIT 1393 * field value: this characterises whether the Surrogate served 1394 the request using content already stored on its local cache or 1395 not. The allowed values are "0" (for miss) and "1" (for hit). 1396 "1" MUST be used when the Surrogate did serve the request using 1397 exclusively content already stored on its local cache. "0" MUST 1398 be used otherwise (including cases where the Surrogate served 1399 the request using some, but not all, content already stored on 1400 its local cache). Note that a "0" only means a cache miss in 1401 the Surrogate and does not provide any information on whether 1402 the content was already stored, or not, in another device of 1403 the dCDN, i.e., whether this was a "dCDN hit" or "dCDN miss". 1405 * occurrence: there MUST be zero or exactly one instance of this 1406 field. 1408 The "Fields" directive corresponding to a HTTP Request Logging Record 1409 MUST contain all the fields names whose occurrence is specified above 1410 as "There MUST be one and only one instance of this field". The 1411 corresponding fields value MUST be present in every HTTP Request 1412 Logging Record. 1414 The "Fields" directive corresponding to a HTTP Request Logging Record 1415 MAY list all the fields value whose occurrence is specified above as 1416 "there MUST be zero or exactly one instance of this field" or "there 1417 MAY be zero, one or any number of instances of this field". The set 1418 of such field names actually listed in the "Fields" directive is 1419 selected by the CDN generating the CDNI Logging File based on 1420 agreements between the interconnected CDNs established through 1421 mechanisms outside the scope of this specification (e.g., contractual 1422 agreements). When such a field name is not listed in the "Fields" 1423 directive, the corresponding field value MUST NOT be included in the 1424 Logging Record. When such a field name is listed in the "Fields" 1425 directive, the corresponding field value MUST be included in the 1426 Logging Record; if the value for the field is not available, this 1427 MUST be conveyed via a dash character ("-"). 1429 The fields names listed in the "Fields" directive MAY be listed in 1430 the order in which they are listed in Section 3.4.1 or MAY be listed 1431 in any other order. 1433 A dCDN-side implementation of the CDNI Logging interface MUST 1434 implement all the following Logging Fields in a CDNI Logging Record 1435 of Record-Type "cdni_http_request_v1", and MUST support the ability 1436 to include valid values for each of them: 1438 o date 1440 o time 1442 o time-taken 1444 o c-ip 1446 o c-ip-anonymizing 1448 o c-port 1450 o c-port-anonymizing 1452 o s-ip 1454 o s-hostname 1455 o s-port 1457 o cs-method 1459 o cs-uri 1461 o u-uri 1463 o protocol 1465 o sc-status 1467 o sc-total-bytes 1469 o sc-entity-bytes 1471 o cs() 1473 o sc() 1475 o s-cached 1477 A dCDN-side implementation of the CDNI Logging interface MAY support 1478 the following Logging Fields in a CDNI Logging Record of Record-Type 1479 "cdni_http_request_v1": 1481 o s-ccid 1483 o s-sid 1485 If a dCDN-side implementation of the CDNI Logging interface supports 1486 these Fields, it MUST support the ability to include valid values for 1487 them. 1489 An uCDN-side implementation of the CDNI Logging interface MUST be 1490 able to accept CDNI Logging Files with CDNI Logging Records of 1491 Record-Type "cdni_http_request_v1" containing any CDNI Logging Field 1492 defined in Section 3.4.1 as long as the CDNI Logging Record and the 1493 CDNI Logging File are compliant with the present document. 1495 In case, an uCDN-side implementation of the CDNI Logging interface 1496 receives a CDNI Logging File with HTTP Request Logging Records that 1497 do not contain field values for exactly the set of field names 1498 actually listed in the preceding "Fields" directive, the 1499 implementation MUST reject those HTTP Request Logging Records, and 1500 MUST accept the other HTTP Request Logging Records . 1502 3.5. CDNI Logging File Example 1504 Let us consider the upstream CDN and the downstream CDN labelled uCDN 1505 and dCDN-1 in Figure 1. When dCDN-1 acts as a downstream CDN for 1506 uCDN and performs content delivery on behalf of uCDN, dCDN-1 will 1507 include the CDNI Logging Records corresponding to the content 1508 deliveries performed on behalf of uCDN in the CDNI Logging Files for 1509 uCDN. An example CDNI Logging File communicated by dCDN-1 to uCDN is 1510 shown below in Figure 4. 1512 #Version:CDNI/1.0 1514 #UUID:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 1516 #Claimed-Origin:cdni-logging-entity.dcdn-1.example.com 1518 #Record-Type:cdni_http_request_v1 1520 #Fields:datetimetime-takenc-ip 1521 c-ip-anonymizingcs-methodu-uriprotocol 1522 sc-statussc-total-bytescs(User-Agent) 1523 cs(Referer)s-cached 1525 2013-05-1700:38:06.8259.05810.5.7.08GET 1526 http://cdni-ucdn.dcdn-1.example.com/video/movie100.mp4 1527 HTTP/1.12006729891"Mozilla/5.0 1528 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like 1529 Gecko) Chrome/5.0.375.127 Safari/533.4" 1530 "host1.example.com"1 1532 2013-05-1700:39:09.14515.3210.5.10.08GET 1533 http://cdni-ucdn.dcdn-1.example.com/video/movie118.mp4 1534 HTTP/1.120015799210"Mozilla/5.0 1535 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like 1536 Gecko) Chrome/5.0.375.127 Safari/533.4" 1537 "host1.example.com"1 1539 2013-05-1700:42:53.43752.87910.5.10.08GET 1540 http://cdni-ucdn.dcdn-1.example.com/video/picture11.mp4 1541 HTTP/1.020097234724"Mozilla/5.0 1542 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like 1543 Gecko) Chrome/5.0.375.127 Safari/533.4" 1544 "host5.example.com"0 1546 #SHA256-Hash:...32-hexadecimal-digit hash value... 1548 Figure 4: CDNI Logging File Example 1550 If uCDN establishes by some means (e.g. via TLS authentication when 1551 pulling the CDNI Logging File) the identity of the entity from which 1552 it pulled the CDNI Logging File, uCDN can add to the CDNI Logging an 1553 Established-Origin directive as illustrated below: 1555 #Established-Origin:cdni-logging-entity.dcdn- 1556 1.example.com 1558 As illustrated in Figure 2, uCDN will then ingest the corresponding 1559 CDNI Logging Records into its Collection process, alongside the 1560 Logging Records generated locally by the uCDN itself. This allows 1561 uCDN to aggregate Logging Records for deliveries performed by itself 1562 (through Records generated locally) as well as for deliveries 1563 performed by its downstream CDN(s). This aggregate information can 1564 then be used (after Filtering and Rectification, as illustrated in 1565 Figure 2) by Log Consuming Applications that take into account 1566 deliveries performed by uCDN as well as by all of its downstream 1567 CDNs. 1569 We observe that the time between 1571 1. when a delivery is completed in dCDN and 1573 2. when the corresponding Logging Record is ingested by the 1574 Collection process in uCDN 1576 depends on a number of parameters such as the Logging Period agreed 1577 to by uCDN and dCDN, how much time uCDN waits before pulling the CDNI 1578 Logging File once it is advertised in the CDNI Logging Feed, and the 1579 time to complete the pull of the CDNI Logging File. Therefore, if we 1580 consider the set of Logging Records aggregated by the Collection 1581 process in uCDN in a given time interval, there could be a permanent 1582 significant timing difference between the CDNI Logging Records 1583 received from the dCDN and the Logging Records generated locally. 1584 For example, in a given time interval, the Collection process in uCDN 1585 may be aggregating Logging Records generated locally by uCDN for 1586 deliveries performed in the last hour and CDNI Logging Records 1587 generated in the dCDN for deliveries in the hour before last. 1589 3.6. Cascaded CDNI Logging Files Example 1591 Let us consider the cascaded CDN scenario of uCDN, dCDN-2 and dCDN-3 1592 as depicted in Figure 1. After completion of a delivery by dCDN-3 on 1593 behalf of dCDN-2, dCDN-3 will include a corresponding Logging Record 1594 in a CDNI Logging File that will be pulled by dCDN-2 and that is 1595 illustrated below in Figure 5. In practice, a CDNI Logging File is 1596 likely to contain a very high number of CDNI Logging Records. 1598 However, for readability, the example in Figure 5 contains a single 1599 CDNI Logging Record. 1601 #Version:CDNI/1.0 1603 #UUID:urn:uuid:65718ef-0123-9876-adce4321bcde 1605 #Claimed-Origin:cdni-logging-entity.dcdn-3.example.com 1607 #Record-Type:cdni_http_request_v1 1609 #Fields:datetimetime-takenc-ip 1610 c-ip-anonymizingcs-methodu-uriprotocol 1611 sc-statussc-total-bytescs(User-Agent) 1612 cs(Referer)s-cached 1614 2013-05-1700:39:09.11914.0710.5.10.08GET 1615 http://cdni-dcdn-2.dcdn-3.example.com/video/movie118.mp4 1616 HTTP/1.120015799210"Mozilla/5.0 1617 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like 1618 Gecko) Chrome/5.0.375.127 Safari /533.4" 1619 "host1.example.com"1 1621 #SHA256-Hash:...32-hexadecimal-digit hash value... 1623 Figure 5: Cascaded CDNI Logging File Example (dCDN-3 to dCDN-2) 1625 If dCDN-2 establishes by some means (e.g. via TLS authentication when 1626 pulling the CDNI Logging File) the identity of the entity from which 1627 it pulled the CDNI Logging File, dCDN-2 can add to the CDNI Logging 1628 an Established-Origin directive as illustrated below: 1630 #Established-Origin:cdni-logging-entity.dcdn- 1631 3.example.com 1633 dCDN-2 (behaving as an upstream CDN from the viewpoint of dCDN-3) 1634 will then ingest the CDNI Logging Record for the considered dCDN-3 1635 delivery into its Collection process (as illustrated in Figure 2). 1636 This Logging Record may be aggregated with Logging Records generated 1637 locally by dCDN-2 for deliveries performed by dCDN-2 itself. Say, 1638 for illustration, that the content delivery performed by dCDN-3 on 1639 behalf of dCDN-2 had actually been redirected to dCDN-2 by uCDN, and 1640 say that another content delivery has just been redirected by uCDN to 1641 dCDN-2 and that dCDN-2 elected to perform the corresponding delivery 1642 itself. Then after Filtering and Rectification (as illustrated in 1643 Figure 2), dCDN-2 will include the two Logging Records corresponding 1644 respectively to the delivery performed by dCDN-3 and the delivery 1645 performed by dCDN-2, in the next CDNI Logging File that will be 1646 communicated to uCDN. An example of such CDNI Logging File is 1647 illustrated below in Figure 6. 1649 #Version:CDNI/1.0 1651 #UUID:urn:uuid:1234567-8fedc-abab-0987654321ff 1653 #Claimed-Origin:cdni-logging-entity.dcdn-2.example.com 1655 #Record-Type:cdni_http_request_v1 1657 #Fields:datetimetime-takenc-ip 1658 c-ip-anonymizingcs-methodu-uriprotocol 1659 sc-statussc-total-bytescs(User-Agent) 1660 cs(Referer)s-cached 1662 2013-05-1700:39:09.11914.0710.5.10.08GET 1663 http://cdni-ucdn.dcdn-2.example.com/video/movie118.mp4 1664 HTTP/1.120015799210"Mozilla/5.0 1665 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like 1666 Gecko) Chrome/5.0.375.127 Safari /533.4" 1667 "host1.example.com"1 1669 2013-05-1701:42:53.43752.87910.5.10.08GET 1670 http://cdni-ucdn.dcdn-2.example.com/video/picture11.mp4 1671 HTTP/1.020097234724"Mozilla/5.0 1672 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like 1673 Gecko) Chrome/5.0.375.127 Safari /533.4" 1674 "host5.example.com"0 1676 #SHA256-Hash:...32-hexadecimal-digit hash value... 1678 Figure 6: Cascaded CDNI Logging File Example (dCDN-2 to uCDN) 1680 If uCDN establishes by some means (e.g. via TLS authentication when 1681 pulling the CDNI Logging File) the identity of the entity from which 1682 it pulled the CDNI Logging File, uCDN can add to the CDNI Logging an 1683 Established-Origin directive as illustrated below: 1685 #Established-Origin:cdni-logging-entity.dcdn- 1686 2.example.com 1688 In the example of Figure 6, we observe that: 1690 o the first Logging Record corresponds to the Logging Record 1691 communicated earlier to dCDN-2 by dCDN-3, which corresponds to a 1692 delivery redirected by uCDN to dCDN-2 and then redirected by 1693 dCDN-2 to dCDN-3. The fields values in this Logging Record are 1694 copied from the corresponding CDNI Logging REcord communicated to 1695 dCDN2 by dCDN-3, with the exception of the u-uri that now reflects 1696 the URI convention between uCDN and dCDN-2 and that presents the 1697 delivery to uCDN as if it was performed by dCDN-2 itself. This 1698 reflects the fact that dCDN-2 had taken the full responsibility of 1699 the corresponding delivery (even if in this case, dCDN-2 elected 1700 to redirect the delivery to dCDN-3 so it is actually performed by 1701 dCDN-3 on behalf of dCDN-2). 1703 o the second Logging Record corresponds to a delivery redirected by 1704 uCDN to dCDN-2 and performed by dCDN-2 itself. The time of the 1705 delivery in this Logging Record may be significantly more recent 1706 than the first Logging Record since it was generated locally while 1707 the first Logging Record was generated by dCDN-3 and had to be 1708 advertised , and then pulled and then ingested into the dCDN-2 1709 Collection process, before being aggregated with the second 1710 Logging Record. 1712 4. Protocol for Exchange of CDNI Logging File After Full Collection 1714 This section specifies a protocol for the exchange of CDNI Logging 1715 Files as specified in Section 3 after the CDNI Logging File is fully 1716 collected by the dCDN. 1718 This protocol comprises: 1720 o a CDNI Logging feed, allowing the dCDN to notify the uCDN about 1721 the CDNI Logging Files that can be retrieved by that uCDN from the 1722 dCDN, as well as all the information necessary for retrieving each 1723 of these CDNI Logging Files. The CDNI Logging feed is specified 1724 in Section 4.1. 1726 o a CDNI Logging File pull mechanism, allowing the uCDN to obtain 1727 from the dCDN a given CDNI Logging File at the uCDN's convenience. 1728 The CDNI Logging File pull mechanisms is specified in Section 4.2. 1730 An implementation of the CDNI Logging interface on the dCDN side (the 1731 entity generating the CDNI Logging file) MUST support the server side 1732 of the CDNI Logging feed (as specified in Section 4.1) and the server 1733 side of the CDNI Logging pull mechanism (as specified in 1734 Section 4.2). 1736 An implementation of the CDNI Logging interface on the uCDN side (the 1737 entity consuming the CDNI Logging file) MUST support the client side 1738 of the CDNI Logging feed (as specified in Section 4.1) and the client 1739 side of the CDNI Logging pull mechanism (as specified in 1740 Section 4.2). 1742 4.1. CDNI Logging Feed 1744 The server-side implementation of the CDNI Logging feed MUST produce 1745 an Atom feed [RFC4287]. This feed is used to advertise log files 1746 that are available for the client-side to retrieve using the CDNI 1747 Logging pull mechanism. 1749 4.1.1. Atom Formatting 1751 A CDNI Logging feed MUST be structured as an Archived feed, as 1752 defined in [RFC5005], and MUST be formatted in Atom [RFC4287]. This 1753 means it consists of a subscription document that is regularly 1754 updated as new CDNI Logging Files become available, and information 1755 about older CDNI Logging files is moved into archive documents. Once 1756 created, archive documents are never modified. 1758 Each CDNI Logging File listed in an Atom feed MUST be described in an 1759 atom:entry container element. 1761 The atom:entry MUST contain an atom:content element whose "src" 1762 attribute is a link to the CDNI Logging File and whose "type" 1763 attribute is the MIME Media Type indicating that the entry is a CDNI 1764 Logging File. We define this MIME Media Type as "application/ 1765 cdni.LoggingFile" (See Section 6.5). 1767 For compatibility with some Atom feed readers the atom:entry MAY also 1768 contain an atom:link entry whose "href" attribute is a link to the 1769 CDNI Logging File and whose "type" attribute is the MIME Media Type 1770 indicating that the entry is a CDNI Logging File using the 1771 "application/cdni.LoggingFile" MIME Media Type (See Section 6.5). 1773 The URI used in the atom:id of the atom:entry MUST contain the UUID 1774 of the CDNI Logging File. 1776 The atom:updated in the atom:entry MUST indicate the time at which 1777 the CDNI Logging File was last updated. 1779 4.1.2. Updates to Log Files and the Feed 1781 CDNI Logging Files MUST NOT be modified by the dCDN once published in 1782 the CDNI Logging feed. 1784 The frequency with which the subscription feed is updated, the period 1785 of time covered by each CDNI Logging File or each archive document, 1786 and timeliness of publishing of CDNI Logging Files are outside the 1787 scope of the present document and are expected to be agreed upon by 1788 uCDN and dCDN via other means (e.g., human agreement). 1790 The server-side implementation MUST be able to set, and SHOULD set, 1791 HTTP cache control headers on the subscription feed to indicate the 1792 frequency at which the client-side is to poll for updates. 1794 The client-side MAY use HTTP cache control headers (set by the 1795 server-side) on the subscription feed to determine the frequency at 1796 which to poll for updates. The client-side MAY instead, or in 1797 addition, use other information to determine when to poll for updates 1798 (e.g., a polling frequency that may have been negotiated between the 1799 uCDN and dCDN by mechanisms outside the scope of the present document 1800 and that is to override the indications provided in the HTTP cache 1801 control headers). 1803 The potential retention limits (e.g., sliding time window) within 1804 which the dCDN is to retain and be ready to serve an archive document 1805 is outside the scope of the present document and is expected to be 1806 agreed upon by uCDN and dCDN via other means (e.g., human agreement). 1807 The server-side implementation MUST retain, and be ready to serve, 1808 any archive document within the agreed retention limits. Outside 1809 these agreed limits, the server-side implementation MAY indicate its 1810 inability to serve (e.g., with HTTP status code 404) an archive 1811 document or MAY refuse to serve it (e.g., with HTTP status code 403 1812 or 410). 1814 4.1.3. Redundant Feeds 1816 The server-side implementation MAY present more than one CDNI Logging 1817 feed for redundancy. Each CDNI Logging File MAY be published in more 1818 than one feed. 1820 A client-side implementation MAY support such redundant CDNI Logging 1821 feeds. If it supports redundant CDNI Logging feed, the client-side 1822 can use the UUID of the CDNI Logging File, presented in the atom:id 1823 element of the Atom feed, to avoid unnecessarily pulling and storing 1824 a given CDNI Logging File more than once. 1826 4.1.4. Example CDNI Logging Feed 1828 Figure 7 illustrates an example of the subscription document of a 1829 CDNI Logging feed. 1831 1832 1833 CDNI Logging Feed 1834 2013-03-23T14:46:11Z 1835 urn:uuid:663ae677-40fb-e99a-049d-c5642916b8ce 1836 1838 1840 1842 CDNI Log Feed 1843 Generator 1844 dcdn.example 1845 1846 CDNI Logging File for uCDN at 1847 2013-03-23 14:15:00 1848 urn:uuid:12345678-1234-abcd-00aa-01234567abcd 1849 2013-03-23T14:15:00Z 1850 1853 CDNI Logging File for uCDN at 1854 2013-03-23 14:15:00 1855 1856 1857 CDNI Logging File for uCDN at 1858 2013-03-23 14:30:00 1859 urn:uuid:87654321-4321-dcba-aa00-dcba7654321 1860 2013-03-23T14:30:00Z 1861 1864 CDNI Logging File for uCDN at 1865 2013-03-23 14:30:00 1866 1867 ... 1868 1869 ... 1870 1871 1873 Figure 7: Example subscription document of a CDNI Logging Feed 1875 4.2. CDNI Logging File Pull 1877 A client-side implementation of the CDNI Logging interface MAY pull, 1878 at its convenience, a CDNI Logging File that is published by the 1879 server-side in the CDNI Logging Feed (in the subscription document or 1880 an archive document). To do so, the client-side: 1882 o MUST implement HTTP/1.1 ([RFC7230],[RFC7231], [RFC7232], 1883 [RFC7233], [RFC7234], [RFC7235]), MAY also support other HTTP 1884 versions (e.g., HTTP/2 [I-D.ietf-httpbis-http2]) and MAY negotiate 1885 which HTTP version is actually used. This allows operators and 1886 implementers to choose to use later versions of HTTP to take 1887 advantage of new features, while still ensuring interoperability 1888 with systems that only support HTTP/1.1. 1890 o MUST use the URI that was associated to the CDNI Logging File 1891 (within the "src" attribute of the corresponding atom:content 1892 element) in the CDNI Logging Feed; 1894 o MUST support exchange of CDNI Logging Files with no content 1895 encoding applied to the representation; 1897 o MUST support exchange of CDNI Logging Files with "gzip" content 1898 encoding (as defined in [RFC7230]) applied to the representation. 1900 Note that a client-side implementation of the CDNI Logging interface 1901 MAY pull a CDNI Logging File that it has already pulled. 1903 The server-side implementation MUST respond to valid pull request by 1904 a client-side implementation for a CDNI Logging File published by the 1905 server-side in the CDNI Logging Feed (in the subscription document or 1906 an archive document). The server-side implementation: 1908 o MUST implement HTTP/1.1 to handle the client-side request and MAY 1909 also support other HTTP versions (e.g., HTTP/2); 1911 o MUST include the CDNI Logging File identified by the request URI 1912 inside the body of the HTTP response; 1914 o MUST support exchange of CDNI Logging Files with no content 1915 encoding applied to the representation; 1917 o MUST support exchange of CDNI Logging Files with "gzip" content 1918 encoding (as defined in [RFC7231]) applied to the representation. 1920 Content negotiation approaches defined in [RFC7231] (e.g., using 1921 Accept-Encoding request-header field or Content-Encoding entity- 1922 header field) MAY be used by the client-side and server-side 1923 implementations to establish the content-coding to be used for a 1924 particular exchange of a CDNI Logging File. 1926 Applying compression content encoding (such as "gzip") is expected to 1927 mitigate the impact of exchanging the large volumes of logging 1928 information expected across CDNs. This is expected to be 1929 particularly useful in the presence of HTTP Adaptive Streaming (HAS) 1930 which, as per the present version of the document, will result in a 1931 separate CDNI Log Record for each HAS segment delivery in the CDNI 1932 Logging File. 1934 The potential retention limits (e.g., sliding time window, maximum 1935 aggregate file storage quotas) within which the dCDN is to retain and 1936 be ready to serve a CDNI Logging File previously advertised in the 1937 CDNI Logging Feed is outside the scope of the present document and is 1938 expected to be agreed upon by uCDN and dCDN via other means (e.g., 1939 human agreement). The server-side implementation MUST retain, and be 1940 ready to serve, any CDNI Logging File within the agreed retention 1941 limits. Outside these agreed limits, the server-side implementation 1942 MAY indicate its inability to serve (e.g., with HTTP status code 404) 1943 a CDNI Logging File or MAY refuse to serve it (e.g., with HTTP status 1944 code 403 or 410). 1946 5. Protocol for Exchange of CDNI Logging File During Collection 1948 We note that, in addition to the CDNI Logging File exchange protocol 1949 specified in Section 4, implementations of the CDNI Logging interface 1950 may also support other mechanisms to exchange CDNI Logging Files. In 1951 particular, such mechanisms might allow the exchange of the CDNI 1952 Logging File to start before the file is fully collected. This can 1953 allow CDNI Logging Records to be communicated by the dCDN to the uCDN 1954 as they are gathered by the dCDN without having to wait until all the 1955 CDNI Logging Records of the same logging period are collected in the 1956 corresponding CDNI Logging File. This approach is commonly referred 1957 to as "tailing" of the file. 1959 Such an approach could be used, for example, to exchange logging 1960 information with a significantly reduced time-lag (e.g., sub-minute 1961 or sub-second) between when the event occurred in the dCDN and when 1962 the corresponding CDNI Logging Record is made available to the uCDN. 1963 This can satisfy log-consuming applications requiring extremely fresh 1964 logging information such as near-real-time content delivery 1965 monitoring. Such mechanisms are for further study and outside the 1966 scope of this document. 1968 6. IANA Considerations 1970 6.1. CDNI Logging Directive Names Registry 1972 The IANA is requested to create a new registry, CDNI Logging 1973 Directive Names. 1975 The initial contents of the CDNI Logging Directives registry comprise 1976 the names of the directives specified in Section 3.3 of the present 1977 document, and are as follows: 1979 +------------------------------+-----------+ 1980 | Directive Name | Reference | 1981 +------------------------------+-----------+ 1982 | Version | RFC xxxx | 1983 | UUID | RFC xxxx | 1984 | Claimed-Origin | RFC xxxx | 1985 | Established-Origin | RFC xxxx | 1986 | Remark | RFC xxxx | 1987 | Record-Type | RFC xxxx | 1988 | Fields | RFC xxxx | 1989 | SHA256-Hash | RFC xxxx | 1990 +------------------------------+-----------+ 1992 Figure 8 1994 [Instructions to IANA: Replace "RFC xxxx" above by the RFC number of 1995 the present document] 1997 Within the registry, names are to be allocated by IANA according to 1998 the "Specification Required" policy specified in [RFC5226]. 1999 Directive names are to be allocated by IANA with a format of 2000 NAMEFORMAT (see Section 3.1). 2002 Each specification that defines a new CDNI Logging directive needs to 2003 contain a description for the new directive with the same set of 2004 information as provided in Section 3.3 (i.e., format, directive value 2005 and occurrence). 2007 6.2. CDNI Logging File Version Registry 2009 The IANA is requested to create a new registry, CDNI Logging File 2010 Version. 2012 The initial contents of the CDNI Logging Logging File Version 2013 registry comprise the value "CDNI/1.0" specified in Section 3.3 of 2014 the present document, and are as follows: 2016 +-----------------+-----------+----------------------------------+ 2017 | Version | Reference | Description | 2018 +-----------------+-----------+----------------------------------+ 2019 | CDNI/1.0 | RFC xxxx | CDNI Logging File version 1.0 | 2020 | | | as specified in RFC xxxx | 2021 +-----------------+-----------+----------------------------------+ 2023 Figure 9 2025 [Instructions to IANA: Replace "RFC xxxx" above by the RFC number of 2026 the present document] 2028 Within the registry, Version values are to be allocated by IANA 2029 according to the "Specification Required" policy specified in 2030 [RFC5226]. Version values are to be allocated by IANA with a format 2031 of NAMEFORMAT (see Section 3.1). 2033 6.3. CDNI Logging Record-Types Registry 2035 The IANA is requested to create a new registry, CDNI Logging Record- 2036 Types. 2038 The initial contents of the CDNI Logging Record-Types registry 2039 comprise the names of the CDNI Logging Record types specified in 2040 Section 3.4 of the present document, and are as follows: 2042 +----------------------+-----------+----------------------------------+ 2043 | Record-Types | Reference | Description | 2044 +----------------------+-----------+----------------------------------+ 2045 | cdni_http_request_v1 | RFC xxxx | CDNI Logging Record version 1 | 2046 | | | for content delivery using HTTP | 2047 +----------------------+-----------+----------------------------------+ 2049 Figure 10 2051 [Instructions to IANA: Replace "RFC xxxx" above by the RFC number of 2052 the present document] 2054 Within the registry, Record-Types are to be allocated by IANA 2055 according to the "Specification Required" policy specified in 2056 [RFC5226]. Record-Types are to be allocated by IANA with a format of 2057 NAMEFORMAT (see Section 3.1). 2059 Each specification that defines a new Record-Type needs to contain a 2060 description for the new Record-Type with the same set of information 2061 as provided in Section 3.4.1. This includes: 2063 o a list of all the CDNI Logging Fields that can appear in a CDNI 2064 Logging Record of the new Record-Type 2066 o for all these Fields: a specification of the occurrence for each 2067 Field in the new Record-Type 2069 o for every newly defined Field, i.e., for every Field that results 2070 in a registration in the CDNI Logging Field Names Registry 2071 (Section 6.4): a specification of the field name, format and field 2072 value. 2074 6.4. CDNI Logging Field Names Registry 2076 The IANA is requested to create a new registry, CDNI Logging Field 2077 Names. 2079 This registry is intended to be shared across the currently defined 2080 Record-Type (i.e., cdni_http_request_v1) as well as potential other 2081 CDNI Logging Record-Types that may be defined in separate 2082 specifications. When a Field from this registry is used by another 2083 CDNI Logging Record-Type, it is to be used with the exact semantics 2084 and format specified in the document that registered this field and 2085 that is identified in the Reference column of the registry. If 2086 another CDNI Logging Record-Type requires a Field with semantics that 2087 are not strictly identical, or a format that is not strictly 2088 identical then this new Field is to be registered in the registry 2089 with a different Field name. When a Field from this registry is used 2090 by another CDNI Logging Record-Type, it can be used with different 2091 occurence rules. 2093 The initial contents of the CDNI Logging Fields Names registry 2094 comprise the names of the CDNI Logging fields specified in 2095 Section 3.4 of the present document, and are as follows: 2097 +------------------------------------------+-----------+ 2098 | Field Name | Reference | 2099 +------------------------------------------+-----------+ 2100 | date | RFC xxxx | 2101 | time | RFC xxxx | 2102 | time-taken | RFC xxxx | 2103 | c-ip | RFC xxxx | 2104 | c-ip-anonymizing | RFC xxxx | 2105 | c-port | RFC xxxx | 2106 | s-ip | RFC xxxx | 2107 | s-hostname | RFC xxxx | 2108 | s-port | RFC xxxx | 2109 | cs-method | RFC xxxx | 2110 | cs-uri | RFC xxxx | 2111 | u-uri | RFC xxxx | 2112 | protocol | RFC xxxx | 2113 | sc-status | RFC xxxx | 2114 | sc-total-bytes | RFC xxxx | 2115 | sc-entity-bytes | RFC xxxx | 2116 | cs() | RFC xxxx | 2117 | sc() | RFC xxxx | 2118 | s-ccid | RFC xxxx | 2119 | s-sid | RFC xxxx | 2120 | s-cached | RFC xxxx | 2121 +------------------------------------------+-----------+ 2123 Figure 11 2125 [Instructions to IANA: Replace "RFC xxxx" above by the RFC number of 2126 the present document] 2128 Within the registry, names are to be allocated by IANA according to 2129 the "Specification Required" policy specified in [RFC5226]. Field 2130 names are to be allocated by IANA with a format of NHTABSTRING (see 2131 Section 3.1). 2133 6.5. CDNI Logging MIME Media Type 2135 The IANA is requested to allocate the "application/cdni.LoggingFile" 2136 MIME Media Type (whose use is specified in Section 4.1.1 of the 2137 present document) in the MIME Media Types registry. 2139 7. Security Considerations 2140 7.1. Authentication, Authorization, Confidentiality, Integrity 2141 Protection 2143 An implementation of the CDNI Logging interface MUST support TLS 2144 transport of the CDNI Logging feed (Section 4.1) and of the CDNI 2145 Logging File pull (Section 4.2) as per [RFC2818] and [RFC7230]. 2147 The use of TLS for transport of the CDNI Logging feed and CDNI 2148 Logging File pull allows: 2150 o the dCDN and uCDN to authenticate each other 2152 and, once they have mutually authenticated each other, it allows:: 2154 o the dCDN and uCDN to authorize each other (to ensure they are 2155 transmitting/receiving CDNI Logging File to/from an authorized 2156 CDN) 2158 o the CDNI Logging information to be transmitted with 2159 confidentiality 2161 o the integrity of the CDNI Logging information to be protected 2162 during the exchange. 2164 In an environment where any such protection is required, the use of a 2165 mutually authenticated encrypted transport MUST be used to ensure 2166 confidentiality of the logging information. TLS MUST be used 2167 (including authentication of the remote end) by the server- side and 2168 the client-side of the CDNI Logging feed, as well as the server- side 2169 and the client-side of the CDNI Logging File pull mechanism. 2171 The general TLS usage guidance in [I-D.ietf-uta-tls-bcp] SHOULD be 2172 followed. 2174 The SHA256-Hash directive inside the CDNI Logging File provides 2175 additional integrity protection, this time targeting potential 2176 corruption of the CDNI logging information during the CDNI Logging 2177 File generation, storage or exchange. This mechanism does not itself 2178 allow restoration of the corrupted CDNI Logging information, but it 2179 allows detection of such corruption and therefore triggering of 2180 appropriate corrective actions (e.g., discard of corrupted 2181 information, attempt to re-obtain the CDNI Logging information). 2182 Note that the SHA256-Hash does not protect against tampering by a 2183 third party, since such a third party could have recomputed and 2184 updated the SHA256-Hash after tampering. Protection against third 2185 party tampering can be achieved as discussed above through the use of 2186 TLS. 2188 7.2. Denial of Service 2190 This document does not define specific mechanism to protect against 2191 Denial of Service (DoS) attacks on the Logging Interface. However, 2192 the CDNI Logging feed and CDNI Logging pull endpoints are typically 2193 to be accessed only by a very small number of valid remote endpoints 2194 and therefore can be easily protected against DoS attacks through the 2195 usual conventional DOS protection mechanisms such as firewalling or 2196 use of Virtual Private Networks (VPNs). 2198 Protection of dCDN Surrogates against spoofed delivery requests is 2199 outside the scope of the CDNI Logging interface. 2201 7.3. Privacy 2203 CDNs have the opportunity to collect detailed information about the 2204 downloads performed by End Users. The provision of this information 2205 to another CDN introduces potential End Users privacy protection 2206 concerns. 2208 The use of mutually authenticated TLS to establish a secure session 2209 for the transport of the CDNI Logging feed and CDNI Logging pull as 2210 discussed in Section 7.1 access to the logging information. This 2211 provides confidentiality while the logging information is in transit 2212 and prevents any other party than the authorised uCDN to gain access 2213 to the logging information. 2215 We observe that when CDNI interconnection is realised as per 2216 [RFC7336], the uCDN handles the initial End User requests (before it 2217 is redirected to the dCDN) so, regardless of which information is, or 2218 is not, communicated to the uCDN through the CDNI Logging interface, 2219 the uCDN has visibility on significant information such as the IP 2220 address of the End User request and the URL of the request. 2222 Nonetheless, if the dCDN and uCDN agree that anonymization is 2223 required to avoid making some detailed information available to the 2224 uCDN (such as how many bytes of the content have been watched by an 2225 End User and/or at what time) or is required to meet some legal 2226 obligations, then the uCDN and dCDN can agree to exchange anonymized 2227 End Users IP address in CDNI Logging Files and the c-ip-anonymization 2228 field can be used to convey the number of bits that have been 2229 anonymized so that the meaningful information can still be easily 2230 extracted from the anonymized addressses (e.g., for geolocation aware 2231 analytics). 2233 We note that anonymization of End Users IP address does not fully 2234 protect against deriving potentially sensitive information about 2235 traffic patterns; in general, increasing the number of bits that are 2236 anonymized can mitigate the risks of deriving such sensitive traffic 2237 pattern information. 2239 We also note that independently of IP addresses, the query string 2240 portion of the URL that may be conveyed inside the cs-uri and u-uri 2241 fields of CDNI Logging Files, or the HTTP cookies( [RFC6265]) that 2242 may be conveyed inside the cs() field of CDNI 2243 Logging Fields, may contain personnal information or information that 2244 can be exploited to derive personal information. Where this is a 2245 concern, the CDNI Logging interface specification allows the dCDN to 2246 not include the cs-uri and to include a u-uri that removes (or hides) 2247 the sensitive part of the query string and allows the dCDN to not 2248 include the cs() fields corresponding to HTTP 2249 headers associated with cookies. 2251 8. Acknowledgments 2253 This document borrows from the W3C Extended Log Format [ELF]. 2255 Rob Murray significantly contributed into the text of Section 4.1. 2257 The authors thank Ben Niven-Jenkins, Kevin Ma, David Mandelberg and 2258 Ray van Brandenburg for their ongoing input. 2260 Finally, we also thank Sebastien Cubaud, Pawel Grochocki, Christian 2261 Jacquenet, Yannick Le Louedec, Anne Marrec , Emile Stephan, Fabio 2262 Costa, Sara Oueslati, Yvan Massot, Renaud Edel, Joel Favier and the 2263 contributors of the EU FP7 OCEAN project for their input in the early 2264 versions of this document. 2266 9. References 2268 9.1. Normative References 2270 [I-D.ietf-uta-tls-bcp] 2271 Sheffer, Y., Holz, R., and P. Saint-Andre, 2272 "Recommendations for Secure Use of TLS and DTLS", draft- 2273 ietf-uta-tls-bcp-11 (work in progress), February 2015. 2275 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2276 Requirement Levels", BCP 14, RFC 2119, March 1997. 2278 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 2279 Internet: Timestamps", RFC 3339, July 2002. 2281 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2282 Resource Identifier (URI): Generic Syntax", STD 66, RFC 2283 3986, January 2005. 2285 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 2286 Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2287 2005. 2289 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom 2290 Syndication Format", RFC 4287, December 2005. 2292 [RFC5005] Nottingham, M., "Feed Paging and Archiving", RFC 5005, 2293 September 2007. 2295 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2296 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2297 May 2008. 2299 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2300 Specifications: ABNF", STD 68, RFC 5234, January 2008. 2302 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 2303 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 2304 August 2008. 2306 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 2307 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2308 2014. 2310 [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 2311 (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. 2313 [RFC7232] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 2314 (HTTP/1.1): Conditional Requests", RFC 7232, June 2014. 2316 [RFC7233] Fielding, R., Lafon, Y., and J. Reschke, "Hypertext 2317 Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, 2318 June 2014. 2320 [RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext 2321 Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 2322 2014. 2324 [RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 2325 (HTTP/1.1): Authentication", RFC 7235, June 2014. 2327 9.2. Informative References 2329 [CHAR_SET] 2330 "IANA Character Sets registry", 2331 . 2334 [ELF] Phillip M. Hallam-Baker, and Brian Behlendorf, "Extended 2335 Log File Format, W3C (work in progress), WD-logfile- 2336 960323", . 2338 [I-D.ietf-cdni-metadata] 2339 Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 2340 "CDN Interconnection Metadata", draft-ietf-cdni- 2341 metadata-09 (work in progress), March 2015. 2343 [I-D.ietf-httpbis-http2] 2344 Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer 2345 Protocol version 2", draft-ietf-httpbis-http2-17 (work in 2346 progress), February 2015. 2348 [I-D.snell-atompub-link-extensions] 2349 Snell, J., "Atom Link Extensions", draft-snell-atompub- 2350 link-extensions-09 (work in progress), June 2012. 2352 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext 2353 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 2355 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 2357 [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 2358 (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. 2360 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 2361 April 2011. 2363 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 2364 Distribution Network Interconnection (CDNI) Problem 2365 Statement", RFC 6707, September 2012. 2367 [RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, 2368 K., and G. Watson, "Use Cases for Content Delivery Network 2369 Interconnection", RFC 6770, November 2012. 2371 [RFC6983] van Brandenburg, R., van Deventer, O., Le Faucheur, F., 2372 and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware 2373 Content Distribution Network Interconnection (CDNI)", RFC 2374 6983, July 2013. 2376 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, 2377 "Framework for Content Distribution Network 2378 Interconnection (CDNI)", RFC 7336, August 2014. 2380 [RFC7337] Leung, K. and Y. Lee, "Content Distribution Network 2381 Interconnection (CDNI) Requirements", RFC 7337, August 2382 2014. 2384 Authors' Addresses 2386 Francois Le Faucheur (editor) 2387 Cisco Systems 2388 E.Space Park - Batiment D 2389 6254 Allee des Ormes - BP 1200 2390 Mougins cedex 06254 2391 FR 2393 Phone: +33 4 97 23 26 19 2394 Email: flefauch@cisco.com 2396 Gilles Bertrand (editor) 2397 Orange 2398 38-40 rue du General Leclerc 2399 Issy les Moulineaux 92130 2400 FR 2402 Phone: +33 1 45 29 89 46 2403 Email: gilles.bertrand@orange.com 2405 Iuniana Oprescu (editor) 2406 Orange 2407 38-40 rue du General Leclerc 2408 Issy les Moulineaux 92130 2409 FR 2411 Phone: +33 6 89 06 92 72 2412 Email: iuniana.oprescu@orange.com 2414 Roy Peterkofsky 2415 Skytide, Inc. 2416 One Kaiser Plaza, Suite 785 2417 Oakland CA 94612 2418 USA 2420 Phone: +01 510 250 4284 2421 Email: roy@skytide.com