draft-ietf-cdni-logging-05.txt   draft-ietf-cdni-logging-06.txt 
Internet Engineering Task Force F. Le Faucheur, Ed. Internet Engineering Task Force F. Le Faucheur, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track G. Bertrand, Ed. Intended status: Standards Track G. Bertrand, Ed.
Expires: January 13, 2014 I. Oprescu, Ed. Expires: March 31, 2014 I. Oprescu, Ed.
Orange Orange
R. Peterkofsky R. Peterkofsky
Skytide, Inc. Skytide, Inc.
July 12, 2013 September 27, 2013
CDNI Logging Interface CDNI Logging Interface
draft-ietf-cdni-logging-05 draft-ietf-cdni-logging-06
Abstract Abstract
This memo specifies the Logging interface between a downstream CDN This memo specifies the Logging interface between a downstream CDN
(dCDN) and an upstream CDN (uCDN) that are interconnected as per the (dCDN) and an upstream CDN (uCDN) that are interconnected as per the
CDN Interconnection (CDNI) framework. First, it describes a CDN Interconnection (CDNI) framework. First, it describes a
reference model for CDNI logging. Then, it specifies the CDNI reference model for CDNI logging. Then, it specifies the CDNI
Logging File format and the actual protocol for exchange of CDNI Logging File format and the actual protocol for exchange of CDNI
Logging Files. Logging Files.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 13, 2014. This Internet-Draft will expire on March 31, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 22 skipping to change at page 2, line 22
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. CDNI Logging Reference Model . . . . . . . . . . . . . . . . 5 2. CDNI Logging Reference Model . . . . . . . . . . . . . . . . 5
2.1. CDNI Logging interactions . . . . . . . . . . . . . . . . 5 2.1. CDNI Logging interactions . . . . . . . . . . . . . . . . 5
2.2. Overall Logging Chain . . . . . . . . . . . . . . . . . . 8 2.2. Overall Logging Chain . . . . . . . . . . . . . . . . . . 8
2.2.1. Logging Generation and During-Generation Aggregation 9 2.2.1. Logging Generation and During-Generation Aggregation 9
2.2.2. Logging Collection . . . . . . . . . . . . . . . . . 10 2.2.2. Logging Collection . . . . . . . . . . . . . . . . . 10
2.2.3. Logging Filtering . . . . . . . . . . . . . . . . . . 10 2.2.3. Logging Filtering . . . . . . . . . . . . . . . . . . 10
2.2.4. Logging Rectification and Post-Generation Aggregation 11 2.2.4. Logging Rectification and Post-Generation Aggregation 11
2.2.5. Log-Consuming Applications . . . . . . . . . . . . . 11 2.2.5. Log-Consuming Applications . . . . . . . . . . . . . 12
2.2.5.1. Maintenance/Debugging . . . . . . . . . . . . . . 11 2.2.5.1. Maintenance/Debugging . . . . . . . . . . . . . . 12
2.2.5.2. Accounting . . . . . . . . . . . . . . . . . . . 12 2.2.5.2. Accounting . . . . . . . . . . . . . . . . . . . 12
2.2.5.3. Analytics and Reporting . . . . . . . . . . . . . 12 2.2.5.3. Analytics and Reporting . . . . . . . . . . . . . 12
2.2.5.4. Security . . . . . . . . . . . . . . . . . . . . 12 2.2.5.4. Security . . . . . . . . . . . . . . . . . . . . 13
2.2.5.5. Legal Logging Duties . . . . . . . . . . . . . . 13 2.2.5.5. Legal Logging Duties . . . . . . . . . . . . . . 13
2.2.5.6. Notions common to multiple Log Consuming 2.2.5.6. Notions common to multiple Log Consuming
Applications . . . . . . . . . . . . . . . . . . 13 Applications . . . . . . . . . . . . . . . . . . 13
3. CDNI Logging File . . . . . . . . . . . . . . . . . . . . . . 15 3. CDNI Logging File . . . . . . . . . . . . . . . . . . . . . . 15
3.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2. CDNI Logging File Structure . . . . . . . . . . . . . . . 16 3.2. CDNI Logging File Structure . . . . . . . . . . . . . . . 16
3.3. CDNI Logging File Directives . . . . . . . . . . . . . . 18 3.3. CDNI Logging File Directives . . . . . . . . . . . . . . 18
3.4. CDNI Logging Records . . . . . . . . . . . . . . . . . . 21 3.4. CDNI Logging Records . . . . . . . . . . . . . . . . . . 21
3.4.1. HTTP Request Logging Record . . . . . . . . . . . . . 22 3.4.1. HTTP Request Logging Record . . . . . . . . . . . . . 22
3.5. CDNI Logging File Example . . . . . . . . . . . . . . . . 28 3.5. CDNI Logging File Example . . . . . . . . . . . . . . . . 29
4. CDNI Logging File Exchange Protocol . . . . . . . . . . . . . 29 4. CDNI Logging File Exchange Protocol . . . . . . . . . . . . . 30
4.1. CDNI Logging Feed . . . . . . . . . . . . . . . . . . . . 30 4.1. CDNI Logging Feed . . . . . . . . . . . . . . . . . . . . 31
4.1.1. Atom Formatting . . . . . . . . . . . . . . . . . . . 30 4.1.1. Atom Formatting . . . . . . . . . . . . . . . . . . . 31
4.1.2. Updates to Log Files and the Feed . . . . . . . . . . 31 4.1.2. Updates to Log Files and the Feed . . . . . . . . . . 32
4.1.3. Redundant Feeds . . . . . . . . . . . . . . . . . . . 31 4.1.3. Redundant Feeds . . . . . . . . . . . . . . . . . . . 32
4.1.4. Example CDNI Logging Feed . . . . . . . . . . . . . . 31 4.1.4. Example CDNI Logging Feed . . . . . . . . . . . . . . 32
4.2. CDNI Logging File Pull . . . . . . . . . . . . . . . . . 32 4.2. CDNI Logging File Pull . . . . . . . . . . . . . . . . . 33
5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 33 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 5.1. CDNI Logging Directive Names Registry . . . . . . . . . . 34
6.1. CDNI Logging Directive Names Registry . . . . . . . . . . 34 5.2. CDNI Logging Record-Types Registry . . . . . . . . . . . 35
6.2. CDNI Logging Record-Types Registry . . . . . . . . . . . 35 5.3. CDNI Logging Field Names Registry . . . . . . . . . . . . 35
6.3. CDNI Logging Field Names Registry . . . . . . . . . . . . 35 5.4. CDNI Logging MIME Media Type . . . . . . . . . . . . . . 36
6.4. CDNI Logging MIME Media Type . . . . . . . . . . . . . . 36 6. Security Considerations . . . . . . . . . . . . . . . . . . . 36
7. Security Considerations . . . . . . . . . . . . . . . . . . . 36 6.1. Authentication, Confidentiality, Integrity Protection . . 36
7.1. Authentication, Confidentiality, Integrity Protection . . 37 6.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 37
7.2. Non Repudiation . . . . . . . . . . . . . . . . . . . . . 37
7.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 37 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 8.1. Normative References . . . . . . . . . . . . . . . . . . 38
9.1. Normative References . . . . . . . . . . . . . . . . . . 38 8.2. Informative References . . . . . . . . . . . . . . . . . 39
9.2. Informative References . . . . . . . . . . . . . . . . . 39
Appendix A. Requirements . . . . . . . . . . . . . . . . . . . . 40 Appendix A. Requirements . . . . . . . . . . . . . . . . . . . . 40
A.1. Compliance with cdni-requirements . . . . . . . . . . . . 40 A.1. Compliance with cdni-requirements . . . . . . . . . . . . 40
A.1.1. General requirements . . . . . . . . . . . . . . . . 40 A.1.1. General requirements . . . . . . . . . . . . . . . . 40
A.1.2. Logging Interface requirements . . . . . . . . . . . 40 A.1.2. Logging Interface requirements . . . . . . . . . . . 40
A.1.3. Security requirements . . . . . . . . . . . . . . . . 42 A.1.3. Security requirements . . . . . . . . . . . . . . . . 42
A.2. Considerations on CDNI Logging Applicability . . . . . . 42 A.2. Considerations on CDNI Logging Applicability . . . . . . 42
A.2.1. Timeliness . . . . . . . . . . . . . . . . . . . . . 42 A.2.1. Timeliness . . . . . . . . . . . . . . . . . . . . . 42
A.2.2. Reliability . . . . . . . . . . . . . . . . . . . . . 42 A.2.2. Reliability . . . . . . . . . . . . . . . . . . . . . 42
A.2.3. Security . . . . . . . . . . . . . . . . . . . . . . 43 A.2.3. Security . . . . . . . . . . . . . . . . . . . . . . 42
A.2.4. Scalability . . . . . . . . . . . . . . . . . . . . . 43 A.2.4. Scalability . . . . . . . . . . . . . . . . . . . . . 42
A.2.5. Consistency between CDNI Logging and CDN Logging . . 43 A.2.5. Consistency between CDNI Logging and CDN Logging . . 43
A.2.6. Dispatching/Filtering . . . . . . . . . . . . . . . . 43 A.2.6. Dispatching/Filtering . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
This memo specifies the CDNI Logging interface between a downstream This memo specifies the CDNI Logging interface between a downstream
CDN (dCDN) and an upstream CDN (uCDN). First, it describes a CDN (dCDN) and an upstream CDN (uCDN). First, it describes a
reference model for CDNI logging. Then, it specifies the CDNI reference model for CDNI logging. Then, it specifies the CDNI
Logging File format and the actual protocol for exchange of CDNI Logging File format and the actual protocol for exchange of CDNI
Logging Files. Logging Files.
The reader should be familiar with the following documents: The reader should be familiar with the following documents:
skipping to change at page 6, line 12 skipping to change at page 6, line 12
place within the dCDN and does not directly involve CDNI place within the dCDN and does not directly involve CDNI
interfaces. interfaces.
o communication by the dCDN to the uCDN of the logging information o communication by the dCDN to the uCDN of the logging information
collected by the dCDN relevant to the uCDN. This is supported by collected by the dCDN relevant to the uCDN. This is supported by
the CDNI Logging interface and in the scope of the present the CDNI Logging interface and in the scope of the present
document. For example, the uCDN may use this logging information document. For example, the uCDN may use this logging information
to charge the CSP, to perform analytics and monitoring for to charge the CSP, to perform analytics and monitoring for
operational reasons, to provide analytics and monitoring views on operational reasons, to provide analytics and monitoring views on
its content delivery to the CSP or to perform trouble-shooting. its content delivery to the CSP or to perform trouble-shooting.
This document specifies non-real-time exchange of logging
information; closer to real-time exchange of logging information
(say sub-minute or sub-second) is outside the scope of the present
document and left for further study. This document specifies
exchange of logging information related to content delivery;
exchange of logging information related to operational events
(e.g. dCDN request routing function unavailable, content
acquisition failure by dCDN) for audit or operational reactive
adjustments by uCDN is outside the scope of the present document
and left for further study.
o customization by the dCDN of the logging to be performed by the o customization by the dCDN of the logging to be performed by the
uCDN on behalf of the dCDN. The mechanism to support the uCDN on behalf of the dCDN. The mechanism to support the
customisation by the dCDN of CDNI Logging information is outside customisation by the dCDN of CDNI Logging information is outside
the scope of this document and left for further study. the scope of this document and left for further study.
o generation and collection by the uCDN of logging information o generation and collection by the uCDN of logging information
related to the completion of any task performed by the uCDN on related to the completion of any task performed by the uCDN on
behalf of the dCDN (e.g., serving of content by uCDN to dCDN for behalf of the dCDN (e.g., serving of content by uCDN to dCDN for
acquisition purposes by dCDN) or related to events happening in acquisition purposes by dCDN) or related to events happening in
the uCDN that are relevant to the dCDN. This takes place within the uCDN that are relevant to the dCDN. This takes place within
the uCDN and does not directly involve CDNI interfaces. the uCDN and does not directly involve CDNI interfaces.
o communication by the uCDN to the dCDN of the logging information o communication by the uCDN to the dCDN of the logging information
collected by the uCDN relevant to the dCDN. For example, the dCDN collected by the uCDN relevant to the dCDN. For example, the dCDN
might potentially benefit form this information for security might potentially benefit from this information for security
auditing or content acquisition troubleshooting. This is outside auditing or content acquisition troubleshooting. This is outside
the scope of this document and left for further study. the scope of this document and left for further study.
Figure 1 provides an example of CDNI Logging interactions (focusing Figure 1 provides an example of CDNI Logging interactions (focusing
only on the interactions that are in the scope of this document) in a only on the interactions that are in the scope of this document) in a
particular scenario where 4 CDNs are involved in the delivery of particular scenario where 4 CDNs are involved in the delivery of
content from a given CSP: the uCDN has a CDNI interconnection with content from a given CSP: the uCDN has a CDNI interconnection with
dCDN-1 and dCDN-2. In turn, dCDN2 has a CDNI interconnection with dCDN-1 and dCDN-2. In turn, dCDN2 has a CDNI interconnection with
dCDN3. In this example, uCDN, dCDN-1, dCDN-2 and dCDN-3 all dCDN3. In this example, uCDN, dCDN-1, dCDN-2 and dCDN-3 all
participate in the delivery of content for the CSP. In this example, participate in the delivery of content for the CSP. In this example,
the CDNI Logging interface enables the uCDN to obtain logging the CDNI Logging interface enables the uCDN to obtain logging
information from all the dCDNs involved in the delivery. In the information from all the dCDNs involved in the delivery. In the
example, uCDN uses the Logging data: example, uCDN uses the Logging data:
o to analyze the performance of the delivery operated by the dCDNs o to analyze the performance of the delivery operated by the dCDNs
and to adjust its operations (e.g., request routing) as and to adjust its operations a-posteriori (e.g., request routing)
appropriate, as appropriate,
o to provide reporting (non real-time) and monitoring (real-time) o to provide (non real-time) reporting and monitoring information to
information to CSP. CSP.
For instance, uCDN merges Logging data, extracts relevant KPIs, and For instance, uCDN merges Logging data, extracts relevant KPIs, and
presents a formatted report to the CSP, in addition to a bill for the presents a formatted report to the CSP, in addition to a bill for the
content delivered by uCDN itself or by its dCDNs on his behalf. uCDN content delivered by uCDN itself or by its dCDNs on his behalf. uCDN
may also provide Logging data as raw log files to the CSP, so that may also provide Logging data as raw log files to the CSP, so that
the CSP can use its own logging analysis tools. the CSP can use its own logging analysis tools.
+-----+ +-----+
| CSP | | CSP |
+-----+ +-----+
skipping to change at page 8, line 16 skipping to change at page 8, line 23
and also are close to the CDN Log formats commonly used in CDNs and also are close to the CDN Log formats commonly used in CDNs
today. today.
2.2. Overall Logging Chain 2.2. Overall Logging Chain
This section discusses the overall logging chain within and across This section discusses the overall logging chain within and across
CDNs to clarify how CDN Logging information is expected to fit in CDNs to clarify how CDN Logging information is expected to fit in
this overall chain. Figure 2 illustrates the overall logging chain this overall chain. Figure 2 illustrates the overall logging chain
within the dCDN, across CDNs using the CDNI Logging interface and within the dCDN, across CDNs using the CDNI Logging interface and
within the uCDN. Note that the logging chain illustrated in the within the uCDN. Note that the logging chain illustrated in the
Figure is obviously only indicative and varies depending on the Figure is obviously only an example and varies depending on the
specific environments. For example, there may be more or less specific environments. For example, there may be more or less
instantiations of each entity (i.e., there may be 4 Log consuming instantiations of each entity (i.e., there may be 4 Log consuming
applications in a given CDN). As another example, there may be one applications in a given CDN). As another example, there may be one
instance of Rectification process per Log Consuming Application instance of Rectification process per Log Consuming Application
instead of a shared one. instead of a shared one.
Log Consuming Log Consuming Log Consuming Log Consuming
App App App App
/\ /\ /\ /\
| | | |
skipping to change at page 9, line 30 skipping to change at page 10, line 5
during contract negotiations, interconnected CDNs often agree on a during contract negotiations, interconnected CDNs often agree on a
Logging retention duration, and optionally, on a maximum size of the Logging retention duration, and optionally, on a maximum size of the
Logging data that the dCDN must keep. If this size is exceeded, the Logging data that the dCDN must keep. If this size is exceeded, the
dCDN must alert the uCDN but may not keep more Logs for the dCDN must alert the uCDN but may not keep more Logs for the
considered time period. In addition, CDNs may aggregate logs and considered time period. In addition, CDNs may aggregate logs and
transmit only summaries for some categories of operations instead of transmit only summaries for some categories of operations instead of
the full Logging data. Note that such aggregation leads to an the full Logging data. Note that such aggregation leads to an
information loss, which may be problematic for some usages of Logging information loss, which may be problematic for some usages of Logging
(e.g., debugging). (e.g., debugging).
[I-D.brandenburg-cdni-has] discusses logging for HTTP Adaptive [RFC6983] discusses logging for HTTP Adaptive Streaming (HAS). In
Streaming (HAS). In accordance with the recommendations articulated accordance with the recommendations articulated there, it is expected
there, it is expected that a surrogate will generate separate logging that a surrogate will generate separate logging information for
information for delivery of each chunk of HAS content. This ensures delivery of each chunk of HAS content. This ensures that separate
that separate logging information can then be provided to logging information can then be provided to interconnected CDNs over
interconnected CDNs over the CDNI Logging interface. Still in line the CDNI Logging interface. Still in line with the recommendations
with the recommendations of [I-D.brandenburg-cdni-has], the logging of [RFC6983], the logging information for per-chunck delivery may
information for per-chunck delivery may include some information (a include some information (a Content Collection IDentifier and a
Content Collection IDentifier and a Session IDentifier) intended to Session IDentifier) intended to facilitate subsequent post-generation
facilitate subsequent post-generation aggregation of per-chunk logs aggregation of per-chunk logs into per-session logs. Note that a CDN
into per-session logs. Note that a CDN may also elect to generate may also elect to generate aggregate per-session logs when performing
aggregate per-session logs when performing HAS delivery, but this HAS delivery, but this needs to be in addition to, and not instead
needs to be in addition to, and not instead of, the per-chunk of, the per-chunk delivery logs. We note that this may be revisited
delivery logs. We note that this may be revisited in future versions in future versions of this document.
of this document.
Note that in the case of non real-time logging, the trigger of the Note that in the case of non real-time logging, the trigger of the
transmission or generation of the logging file appears to be a transmission or generation of the logging file appears to be a
synchronous process from a protocol standpoint. The implementation synchronous process from a protocol standpoint. The implementation
algorithm can choose to enforce a maximum size for the logging file algorithm can choose to enforce a maximum size for the logging file
beyond which the transmission is automatically triggered (and thus beyond which the transmission is automatically triggered (and thus
allow for an asynchronous transmission process). allow for an asynchronous transmission process).
2.2.2. Logging Collection 2.2.2. Logging Collection
skipping to change at page 11, line 34 skipping to change at page 12, line 5
from aggregate per-session logs. For example, for analytics, per- from aggregate per-session logs. For example, for analytics, per-
session logs allow display of session-related trends which are much session logs allow display of session-related trends which are much
more meaningful for some types of analysis than chunk-related trends. more meaningful for some types of analysis than chunk-related trends.
In the case where the log-generating entities have generated during- In the case where the log-generating entities have generated during-
generation aggregate logs, those can be used by the applications. In generation aggregate logs, those can be used by the applications. In
the case where aggregate logs have not been generated, the the case where aggregate logs have not been generated, the
Rectification process can be extended with a Post-Generation Rectification process can be extended with a Post-Generation
Aggregation process that generates per-session logs from the per- Aggregation process that generates per-session logs from the per-
chunk logs, possibly leveraging the information included in the per- chunk logs, possibly leveraging the information included in the per-
chunk logs for that purpose (Content Collection IDentifier and a chunk logs for that purpose (Content Collection IDentifier and a
Session IDentifier). However, in accordance with Session IDentifier). However, in accordance with [RFC6983], this
[I-D.brandenburg-cdni-has], this document does not define exchange of document does not define exchange of such aggregate logs on the CDNI
such aggregate logs on the CDNI Logging interface. We note that this Logging interface. We note that this may be revisited in future
may be revisited in future versions of this document. versions of this document.
2.2.5. Log-Consuming Applications 2.2.5. Log-Consuming Applications
2.2.5.1. Maintenance/Debugging 2.2.5.1. Maintenance/Debugging
Logging is useful to permit the detection (and limit the risk) of Logging is useful to permit the detection (and limit the risk) of
content delivery failures. In particular, Logging facilitates the content delivery failures. In particular, Logging facilitates the
resolution of configuration issues. detection of configuration issues.
To detect faults, Logging must enable the reporting of any CDN To detect faults, Logging must enable the reporting of any CDN
operation success and failure, such as request redirection, content delivery operation success and failure. The uCDN can summarize such
acquisition, etc. The uCDN can summarize such information into KPIs. information into KPIs. For instance, Logging needs to allow the
For instance, Logging format should allow the computation of the computation of the number of times, during a given time period, that
number of times during a given epoch that content delivery related to content delivery related to a specific service succeeds/fails.
a specific service succeeds/fails.
Logging enables the CDN providers to identify and troubleshoot Logging enables the CDN providers to identify and troubleshoot
performance degradations. In particular, Logging enables the performance degradations. In particular, Logging enables the
communication of traffic data (e.g., the amount of traffic that has communication of traffic data (e.g., the amount of traffic that has
been forwarded by a dCDN on behalf of an uCDN over a given period of been forwarded by a dCDN on behalf of an uCDN over a given period of
time), which is particularly useful for CDN and network planning time), which is particularly useful for CDN and network planning
operations. operations.
2.2.5.2. Accounting 2.2.5.2. Accounting
skipping to change at page 18, line 17 skipping to change at page 18, line 31
<CDNI Logging File> = 1*<DIRGROUP RECGROUP> <CDNI Logging File> = 1*<DIRGROUP RECGROUP>
3.3. CDNI Logging File Directives 3.3. CDNI Logging File Directives
The CDNI Logging File directives are defined by the following rules: The CDNI Logging File directives are defined by the following rules:
directive = DIRNAME ":" HTAB DIRVAL directive = DIRNAME ":" HTAB DIRVAL
DIRNAME = any CDNI Logging Directive name registered in the CDNI DIRNAME = any CDNI Logging Directive name registered in the CDNI
Logging Directive Names registry (Section 6.1). Logging Directive Names registry (Section 5.1).
DIRVAL = <directive value as specified below for each directive DIRVAL = <directive value as specified below for each directive
name> name>
An implementation of the CDNI Logging interface MUST support the An implementation of the CDNI Logging interface MUST support all of
following directives, listed below by their directive name: the following directives, listed below by their directive name:
o Version: o Version:
* format: "CDNI" "/" 1*DIGIT "." 1*DIGIT * format: "CDNI" "/" 1*DIGIT "." 1*DIGIT
* directive value: indicates the version of the CDNI Logging File * directive value: indicates the version of the CDNI Logging File
format. The value MUST be "CDNI/1.0" for the version specified format. The value MUST be "CDNI/1.0" for the version specified
in the present document. in the present document.
* occurrence: there MUST be one and only one instance of this * occurrence: there MUST be one and only one instance of this
directive. It MUST be the first line of the CDNI Logging file. directive per CDNI Logging File. It MUST be the first line of
the CDNI Logging file.
o UUID: o UUID:
* format: NHTABSTRING * format: NHTABSTRING
* directive value: this a Universally Unique IDentifier (UUID) * directive value: this a Universally Unique IDentifier (UUID)
from the UUID Uniform Resource Name (URN) namespace specified from the UUID Uniform Resource Name (URN) namespace specified
in [RFC4122]) for the CDNI Logging File . in [RFC4122]) for the CDNI Logging File .
* occurrence: there MUST be one and only one instance of this * occurrence: there MUST be one and only one instance of this
directive. directive per CDNI Logging File.
o Claimed-Origin: o Claimed-Origin:
* format: host * format: host
* directive value: this contains the claimed identification of * directive value: this contains the claimed identification of
the entity transmitting the CDNI Logging File (e.g. the host in the entity transmitting the CDNI Logging File (e.g. the host in
a dCDN supporting the CDNI Logging interface) or the entity a dCDN supporting the CDNI Logging interface) or the entity
responsible for transmitting the CDNI Logging File (e.g. the responsible for transmitting the CDNI Logging File (e.g. the
dCDN). dCDN).
* occurrence: there MUST be zero or one instance of this * occurrence: there MUST be zero or one instance of this
directive. This directive MAY be included by the dCDN. It directive per CDNI Logging File. This directive MAY be
MUST NOT be included or modified by the uCDN. included by the dCDN. It MUST NOT be included or modified by
the uCDN.
o Verified-Origin: o Verified-Origin:
* format: host * format: host
* directive value: this contains the identification, as * directive value: this contains the identification, as
established by the entity receiving the CDNI Logging file, of established by the entity receiving the CDNI Logging file, of
the entity transmitting the CDNI Logging File (e.g. the host in the entity transmitting the CDNI Logging File (e.g. the host in
a dCDN supporting the CDNI Logging interface) or the entity a dCDN supporting the CDNI Logging interface) or the entity
responsible for transmitting the CDNI Logging File (e.g. the responsible for transmitting the CDNI Logging File (e.g. the
dCDN). dCDN).
* occurrence: there MUST be zero or one instance of this * occurrence: there MUST be zero or one instance of this
directive. This directive MAY be added by the uCDN. It MUST directive per CDNI Logging File. This directive MAY be added
NOT be included by the dCDN. The mechanisms used by the uCDN by the uCDN (e.g. before storing the CDNI Logging File). It
to establih and validate the entity respondible for the CDNI MUST NOT be included by the dCDN. The mechanisms used by the
Logging File is outside the scope of the present document. We uCDN to establish and validate the entity responsible for the
observe that, in particular, this may be achieved through CDNI Logging File is outside the scope of the present document.
We observe that, in particular, this may be achieved through
authentication mechanisms that are part of the CDNI Logging authentication mechanisms that are part of the CDNI Logging
File pull mechanism (Section 4.2). File pull mechanism (Section 4.2).
o Record-Type: o Record-Type:
* format: NHTABSTRING * format: NHTABSTRING
* directive value: indicates the type of the CDNI Logging Records * directive value: indicates the type of the CDNI Logging Records
that follow this directive, until another Record-Type directive that follow this directive, until another Record-Type directive
(or the end of the CDNI Logging File). This can be any CDNI (or the end of the CDNI Logging File). This can be any CDNI
Logging Record type registered in the CDNI Logging Record-types Logging Record type registered in the CDNI Logging Record-types
registry (Section 6.2). "cdni_http_request_v1" MUST be registry (Section 5.2). "cdni_http_request_v1" MUST be
indicated as the Record-Type directive value for CDNI Logging indicated as the Record-Type directive value for CDNI Logging
records corresponding to HTTP request (e.g. a HTTP delivery records corresponding to HTTP request (e.g. a HTTP delivery
request) as specified in Section 3.4.1. request) as specified in Section 3.4.1.
* occurrence: there MUST be at least one instance of this * occurrence: there MUST be at least one instance of this
directive. The first instance of this directive MUST precede a directive per CDNI Logging File. The first instance of this
Fields directive and precede any CDNI Logging Record. directive MUST precede a Fields directive and precede any CDNI
Logging Record.
o Fields: o Fields:
* format: FIENAME *<HTAB FIENAME> ; where FIENAME can take any * format: FIENAME *<HTAB FIENAME> ; where FIENAME can take any
CDNI Logging field name registered in the CDNI Logging Field CDNI Logging field name registered in the CDNI Logging Field
Names registry (Section 6.3). Names registry (Section 5.3).
* directive value: this lists the names of all the fields for * directive value: this lists the names of all the fields for
which a value is to appear in the CDNI Logging Records that are which a value is to appear in the CDNI Logging Records that
after this directive. The names of the fields, as well as follow the instance of this directive (until another instance
their possible occurrences, are specified for each type of CDNI of this directive). The names of the fields, as well as their
possible occurrences, are specified for each type of CDNI
Logging Records in Section 3.4. Logging Records in Section 3.4.
* occurrence: there MUST be at least one instance of this * occurrence: there MUST be at least one instance of this
directive per Record-Type directive. The first instance of directive per Record-Type directive. The first instance of
this directive for a given Record-Type MUST precede any CDNI this directive for a given Record-Type MUST appear before any
Logging Record for this Record-Type. CDNI Logging Record for this Record-Type.
o Integrity-Hash: o Integrity-Hash:
* format: 32HEXDIG * format: 32HEXDIG
* directive value: This directive permits the detection of a * directive value: This directive permits the detection of a
corrupted CDNI Logging File. This can be useful, for instance, corrupted CDNI Logging File. This can be useful, for instance,
if a problem occurs on the filesystem of the dCDN Logging if a problem occurs on the filesystem of the dCDN Logging
system and leads to a truncation of a logging file. The system and leads to a truncation of a logging file. The valid
Integrity-Hash value is computed, and included in this Integrity-Hash value is included in this directive by the
directive by the entity that transmits the CDNI Logging File. entity that transmits the CDNI Logging File. It is computed by
It is computed by applying the MD5 ([RFC1321]) cryptographic applying the MD5 ([RFC1321]) cryptographic hash function on the
hash function on the CDNI Logging File, including all the CDNI Logging File, including all the directives and logging
directives and logging records, up to the Intergrity-Hash records, up to the Intergrity-Hash directive itself, excluding
directive itself, excluding the Integrity-Hash directive itself the Integrity-Hash directive itself. The Integrity-Hash value
and, when present, also excluding the Non-Repudiation-Hash is represented as a US-ASCII encoded hexadecimal number, 32
directive. The Integrity-Hash value is represented as a US- digits long (representing a 128 bit hash value). The entity
ASCII encoded hexadecimal number, 32 digits long (representing receiving the CDNI Logging File also computes in a similar way
a 128 bit hash value). The entity receiving the CDNI Logging the MD5 hash on the received CDNI Logging File and compares
File also computes in a similar way the MD5 hash on the this hash to the value of the Integrity-Hash directive. If the
received CDNI Logging File and compares this hash to the value two values are equal, then the received CDNI Logging File MUST
of the Integrity-Hash directive. If the two values are equal, be considered non-corrupted. If the two values are different,
then the received CDNI Logging File MUST be considered non- the received CDNI Logging File MUST be considered corrupted.
corrupted. If the two values are different, the received CDNI The behavior of the entity that received a corrupted CDNI
Logging File MUST be considered corrupted. The behavior of the Logging File is outside the scope of this specification; we
entity that received a corrupted CDNI Logging File is outside note that the entity MAY attempt to pull again the same CDNI
the scope of this specification; we note that the entity MAY Logging file from the transmitting entity. If the entity
attempt to pull again the same CDNI Logging file from the receiving the CDNI Logging File adds a Verified-Origin
transmitting entity. If the entity receiving the CDNI Logging directive, it MUST recompute and update the Integrity-Hash
File adds a Verified-Origin directive, it MUST recompute and directive so it also protects the added Verified-Origin
update the Integrity-Hash directive so it also protects the directive.
added Verified-Origin directive.
* occurrence: there MUST be zero or one instance of this * occurrence: there MUST be zero or one instance of this
directive. There SHOULD be one instance of this directive. directive. There SHOULD be one instance of this directive.
One situation where that directive could be omitted is where One situation where that directive could be omitted is where
integrity protection is already provided via another mechanism integrity protection is already provided via another mechanism
(for example if an integrity hash is associated to the CDNI (for example if an integrity hash is associated to the CDNI
Logging file out of band through the CDNI Logging Logging Feed Logging file out of band through the CDNI Logging Logging Feed
Section 4.1 leveraging ATOM extensions such as those proposed Section 4.1 leveraging ATOM extensions such as those proposed
in [I-D.snell-atompub-link-extensions]. When present, this in [I-D.snell-atompub-link-extensions]. When present, this
field MUST be the last line of the CDNI Logging File when the field MUST be the last line of the CDNI Logging File.
Non-Repudiation-Hash is absent, and MUST be the one before last
line of the CDNI Logging File when the Non-Repudiation-Hash is
present.
3.4. CDNI Logging Records 3.4. CDNI Logging Records
A CDNI Logging Record consists of a sequence of CDNI Logging Fields A CDNI Logging Record consists of a sequence of CDNI Logging Fields
relating to that single CDNI Logging Record. relating to that single CDNI Logging Record.
CDNI Logging Fields MUST be separated by the "horizontal tabulation CDNI Logging Fields MUST be separated by the "horizontal tabulation
(HTAB)" character. (HTAB)" character.
To facilitate readability, a prefix scheme is used for CDNI Logging To facilitate readability, a prefix scheme is used for CDNI Logging
skipping to change at page 21, line 40 skipping to change at page 22, line 4
o c: refers to the User Agent that issues the request (corresponds o c: refers to the User Agent that issues the request (corresponds
to the "client" of W3C Extended Log Format) to the "client" of W3C Extended Log Format)
o d: refers to the dCDN (relative to a given CDN acting as a uCDN) o d: refers to the dCDN (relative to a given CDN acting as a uCDN)
o s: refers to the dCDN Surrogate that serves the request o s: refers to the dCDN Surrogate that serves the request
(corresponds to the "server" of W3C Extended Log Format) (corresponds to the "server" of W3C Extended Log Format)
o u: refers to the uCDN (relative to a given CDN acting as a dCDN) o u: refers to the uCDN (relative to a given CDN acting as a dCDN)
o cs: refers to communication from the User-Agent towards the dCDN o cs: refers to communication from the User-Agent towards the dCDN
Surrogate Surrogate
o sc: refers to communication from the dCDN Surrogate towards the o sc: refers to communication from the dCDN Surrogate towards the
User-Agent User-Agent
An implementation of the CDNI Logging interface as per the present An implementation of the CDNI Logging interface as per the present
specification MUST support the CDNI HTTP Delivery Records as specification MUST support the CDNI HTTP Delivery Records as
specified in Section 3.4.1. [Editor's Note": other types of CDNI specified in Section 3.4.1.
Logging records will be listed here if we specify other types for
this version eg Request Routing].
A CDNI Logging Record is defined by the following rules: A CDNI Logging Record is defined by the following rules:
FIEVAL = <CDNI Logging Field value> FIEVAL = <CDNI Logging Field value>
<CDNI Logging Record> = FIEVAL *<HTAB FIEVAL> ; where FIEVAL <CDNI Logging Record> = FIEVAL *<HTAB FIEVAL> ; where FIEVAL
contains the CDNI Logging field values corresponding to the CDNI contains the CDNI Logging field values corresponding to the CDNI
Logging field names (FIENAME) listed is the last Fields directive Logging field names (FIENAME) listed is the last Fields directive
predecing the present CDNI Logging Record. predecing the present CDNI Logging Record.
skipping to change at page 27, line 13 skipping to change at page 27, line 22
o s-sid: o s-sid:
* format: QSTRING * format: QSTRING
* field value: this contains the value of a Session IDentifier * field value: this contains the value of a Session IDentifier
generated by the dCDN for a specific HTTP Adaptive Streaming generated by the dCDN for a specific HTTP Adaptive Streaming
(HAS) session and whose value is included in the Logging record (HAS) session and whose value is included in the Logging record
for every content chunk delivery of that session in view of for every content chunk delivery of that session in view of
facilitating the later correlation of all the per content chunk facilitating the later correlation of all the per content chunk
log records of a given HAS session. See section 3.4.2.2. of log records of a given HAS session. See section 3.4.2.2. of
[I-D.brandenburg-cdni-has] for more discussion on the concept [RFC6983] for more discussion on the concept of Session
of Session IDentifier. IDentifier.
* occurrence: there MUST be zero or exactly one instance of this * occurrence: there MUST be zero or exactly one instance of this
field. field.
o s-cached: o s-cached:
* format: 1DIGIT * format: 1DIGIT
* field value: this characterises whether the Surrogate could * field value: this characterises whether the Surrogate served
serve the request using content already stored on its local the request using content already stored on its local cache or
cache. The allowed values are "0" (for miss) and "1" for hit). not. The allowed values are "0" (for miss) and "1" (for hit).
"1" MUST be used when the Surrogate could serve the request "1" MUST be used when the Surrogate did serve the request using
using exclusively content already stored on its local cache. exclusively content already stored on its local cache. "0" MUST
"0" MUST be used otherwise (including cases where the Surrogate be used otherwise (including cases where the Surrogate served
served the request using some, but not all, content already the request using some, but not all, content already stored on
stored on its local cache). Note that a "0" only means a cache its local cache). Note that a "0" only means a cache miss in
miss in the Surrogate and does not provide any information on the Surrogate and does not provide any information on whether
whether the content was already stored, or not, in another the content was already stored, or not, in another device of
device of the dCDN i.e. whether this was a "dCDN hit" or "dCDN the dCDN i.e. whether this was a "dCDN hit" or "dCDN miss".
miss".
* occurrence: there MUST be zero or exactly one instance of this
field.
o s-uri-signing:
* format: 1DIGIT
* field value: this characterises the uri signing validation
performed by the Surrogate on the request. The allowed values
are:
*
+ "0" : no uri signature validation performed
+ "1" : uri signature validation performed and validated
+ "2" : uri signature validation performed and rejected
* occurrence: there MUST be zero or exactly one instance of this * occurrence: there MUST be zero or exactly one instance of this
field. field.
The "Fields" directive corresponding to a HTTP Request Logging Record The "Fields" directive corresponding to a HTTP Request Logging Record
MUST list all the fields name whose occurrence is specified above as MUST list all the fields name whose occurrence is specified above as
"There MUST be one and only one instance of this field". The "There MUST be one and only one instance of this field". The
corresponding fields value MUST be present in every HTTP Request corresponding fields value MUST be present in every HTTP Request
Logging Record. Logging Record.
The "Fields" directive corresponding to a HTTP Request Logging Record The "Fields" directive corresponding to a HTTP Request Logging Record
MAY list all the fields value whose occurrence is specified above as MAY list all the fields value whose occurrence is specified above as
"there MUST be zero or exactly one instance of this field" or "there "there MUST be zero or exactly one instance of this field" or "there
MUST be zero, one or any number of instance of this field". The set MUST be zero, one or any number of instance of this field". The set
of such fields name actually listed in the "Fields" directive is of such fields name actually listed in the "Fields" directive is
selected by the implementation generating the CDNI Logging File based selected by the implementation generating the CDNI Logging File based
on agreements between the interconnected CDNs established through on agreements between the interconnected CDNs established through
mechanisms outside the scope of this specification (e.g. contractual mechanisms outside the scope of this specification (e.g. contractual
agreements) . When such a field name is not listed in the "Fields" agreements). When such a field name is not listed in the "Fields"
directive, the corresponding field value MUST NOT be included in the directive, the corresponding field value MUST NOT be included in the
Logging Record. When such a field name is listed in the "Fields" Logging Record. When such a field name is listed in the "Fields"
directive, the corresponding field value MUST be included in the directive, the corresponding field value MUST be included in the
Logging Record; in that case, if the value for the field is not Logging Record; in that case, if the value for the field is not
available, this MUST be conveyed via a dash character ("-"). available, this MUST be conveyed via a dash character ("-").
The fields name listed in the "Fields" directive MAY be listed in the The fields name listed in the "Fields" directive MAY be listed in the
order in which they are listed in Section 3.4.1 or MAY be listed in order in which they are listed in Section 3.4.1 or MAY be listed in
any other order. any other order.
A dCDN-side implementation of the CDNI Logging interface MUST support
the ability to include valid values for the following Logging Fields
in a CDNI Logging Record of Record-Type "cdni_http_request_v1":
o date
o time
o time-taken
o c-ip
o c-port
o s-ip
o s-hostname
o s-port
o cs- method
o cs-uri
o u-uri
o protocol
o sc-status
o sc- total-bytes
o sc-entity-bytes
o cs(<HTTP-header>)
o sc(<HTTP-header>)
o s-ccid
o s-sid
o s-cached
A dCDN-side implementation of the CDNI Logging interface MAY support
the ability to include valid values for the following Logging Fields
in a CDNI Logging Record of Record-Type "cdni_http_request_v1":
o c-ip-anonimizing
o s-ccid
o s-sid
An uCDN-side implementation of the CDNI Logging interface MUST be
able to accept CDNI Logging Files with CDNI Logging Records of
Record-Type "cdni_http_request_v1" containing any CDNI Logging Field
defined in Section 3.4.1 as long as the CDNI Logging Record and the
CDNI Logging File are compliant with the present document.
3.5. CDNI Logging File Example 3.5. CDNI Logging File Example
#Version:<HTAB>CDNI/1.0<CRLF> #Version:<HTAB>CDNI/1.0<CRLF>
#UUID:<HTAB>"urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"<CRLF> #UUID:<HTAB>"urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"<CRLF>
#Claimed-Origin:<HTAB>cdni-logging-entity.dcdn.example.com<CRLF> #Claimed-Origin:<HTAB>cdni-logging-entity.dcdn.example.com<CRLF>
#Record-Type:<HTAB>cdni_http_request_v1<CRLF> #Record-Type:<HTAB>cdni_http_request_v1<CRLF>
skipping to change at page 30, line 12 skipping to change at page 31, line 12
support the client side of the CDNI Logging feed and the client side support the client side of the CDNI Logging feed and the client side
of the CDNI Logging pull mechanism. of the CDNI Logging pull mechanism.
We note that implementations of the CDNI Logging interface MAY also We note that implementations of the CDNI Logging interface MAY also
support other mechanisms to exchange CDNI Logging Files, for example support other mechanisms to exchange CDNI Logging Files, for example
in view of exchanging logging information with minimum time-lag (e.g. in view of exchanging logging information with minimum time-lag (e.g.
sub-minute or sub-second) between when the event occurred in the dCDN sub-minute or sub-second) between when the event occurred in the dCDN
and when the corresponding Logging Record is made available to the and when the corresponding Logging Record is made available to the
uCDN (e.g. for log-consuming applications requiring extremely fresh uCDN (e.g. for log-consuming applications requiring extremely fresh
logging information such as near-real-time content delivery logging information such as near-real-time content delivery
monitoring). Such mechanism might be defined in future version of monitoring). Such mechanisms are outside the scope of the present
the present document. document but might be defined in future version of this document .
4.1. CDNI Logging Feed 4.1. CDNI Logging Feed
The server-side implementation of the CDNI Logging feed produces an The server-side implementation of the CDNI Logging feed MUST produce
Atom feed [RFC4287]. This feed is used to advertise log files that an Atom feed [RFC4287]. This feed is used to advertise log files
are available for the client-side to retrieve using the CDNI Logging that are available for the client-side to retrieve using the CDNI
pull mechanism. Logging pull mechanism.
4.1.1. Atom Formatting 4.1.1. Atom Formatting
A CDNI Logging feed MUST be structured as an Archived feed, as A CDNI Logging feed MUST be structured as an Archived feed, as
defined in [RFC5005], and MUST be formatted in Atom [RFC4287]. This defined in [RFC5005], and MUST be formatted in Atom [RFC4287]. This
means it consists of a subscription document that is regularly means it consists of a subscription document that is regularly
updated as new CDNI logging files become available, and information updated as new CDNI logging files become available, and information
about older CDNI Logging files is moved into archive documents. Once about older CDNI Logging files is moved into archive documents. Once
created, archive documents are never modified. created, archive documents are never modified.
Each CDNI Logging file listed in an Atom feed MUST be described in an Each CDNI Logging file listed in an Atom feed MUST be described in an
atom:entry container element. atom:entry container element.
The atom:entry MUST contain an atom:content element whose "src" The atom:entry MUST contain an atom:content element whose "src"
attribute is a link to the CDNI Logging file and whose "type" attribute is a link to the CDNI Logging file and whose "type"
attribute is the MIME Media Type indicating that the entry if a CDNI attribute is the MIME Media Type indicating that the entry is a CDNI
Logging File. We define this MIME Media Type as "application/ Logging File. We define this MIME Media Type as "application/
cdni.LoggingFile" (See Section 6.4). cdni.LoggingFile" (See Section 5.4).
For compatibility with some Atom feed readers the atom:entry MAY also For compatibility with some Atom feed readers the atom:entry MAY also
contain an atom:link entry whose "href" attribute is a link to the contain an atom:link entry whose "href" attribute is a link to the
CDNI Logging file and whose "type" attribute is the MIME Media Type CDNI Logging file and whose "type" attribute is the MIME Media Type
indicating that the entry if a CDNI Logging File. We define this indicating that the entry is a CDNI Logging File using the
MIME Media Type as "application/cdni.LoggingFile" (See Section 6.4). "application/cdni.LoggingFile" MIME Media Type (See Section 5.4).
The IRI used in the atom:id of the atom:entry MUST contain the UUID The IRI used in the atom:id of the atom:entry MUST contain the UUID
of the CDNI Logging file. of the CDNI Logging file.
The atom:updated in the atom:entry MUST indicate the time at which The atom:updated in the atom:entry MUST indicate the time at which
the CDNI Logging file was last updated. the CDNI Logging file was last updated.
4.1.2. Updates to Log Files and the Feed 4.1.2. Updates to Log Files and the Feed
CDNI Logging files MUST NOT be modified by the dCDN once published in CDNI Logging files MUST NOT be modified by the dCDN once published in
skipping to change at page 31, line 29 skipping to change at page 32, line 29
4.1.3. Redundant Feeds 4.1.3. Redundant Feeds
The server-side implementation MAY present more than one CDNI Logging The server-side implementation MAY present more than one CDNI Logging
feed and for redundancy, CDNI Logging files MAY be published in more feed and for redundancy, CDNI Logging files MAY be published in more
than one feed. than one feed.
A client-side implementation MAY support such redundant CDNI Logging A client-side implementation MAY support such redundant CDNI Logging
feeds. If it supports redundant CDNI Logging feed, the client-side feeds. If it supports redundant CDNI Logging feed, the client-side
SHOULD use the UUID of the CDNI Logging file, presented in the SHOULD use the UUID of the CDNI Logging file, presented in the
atom:id element of the Atom feed, to avoid uncessarily pulling each atom:id element of the Atom feed, to avoid uncessarily pulling and
CDNI Logging file more than once. storing each CDNI Logging file more than once.
4.1.4. Example CDNI Logging Feed 4.1.4. Example CDNI Logging Feed
Figure 4 illustrates an example of the subscription document of a Figure 4 illustrates an example of the subscription document of a
CDNI Logging feed. CDNI Logging feed.
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" <feed xmlns="http://www.w3.org/2005/Atom"
<http://www.w3.org/2005/Atom%22>> <http://www.w3.org/2005/Atom%22>>
<title type="text">CDNI Logging Feed</title> <title type="text">CDNI Logging Feed</title>
skipping to change at page 32, line 25 skipping to change at page 33, line 25
<title type="text">CDNI Logging File for uCDN at <title type="text">CDNI Logging File for uCDN at
2013-03-23 15:55:00</title> 2013-03-23 15:55:00</title>
<id>urn:uuid:87654321-4321-dcba-aa00-dcba7654321</id> <id>urn:uuid:87654321-4321-dcba-aa00-dcba7654321</id>
<updated>2013-03-23T15:55:00Z</updated> <updated>2013-03-23T15:55:00Z</updated>
<content src="https://dcdn.example/logs/ucdn/ <content src="https://dcdn.example/logs/ucdn/
http-requests-20130323155500000000" http-requests-20130323155500000000"
type="application/cdni.LoggingFile" /> type="application/cdni.LoggingFile" />
<summary>CDNI Logging File for uCDN at <summary>CDNI Logging File for uCDN at
2013-03-23 15:55:00</summary> 2013-03-23 15:55:00</summary>
</entry> </entry>
...
<entry> <entry>
... ...
</entry> </entry>
... </feed>
?</feed>
Figure 4: Example subscription document of a CDNI Logging Feed Figure 4: Example subscription document of a CDNI Logging Feed
4.2. CDNI Logging File Pull 4.2. CDNI Logging File Pull
A client-side implementation of the CDNI Logging interface pulls, at A client-side implementation of the CDNI Logging interface MUST pull,
its convenience, any CDNI Logging File that is published by the at its convenience, a CDNI Logging File that is published by the
server-side in the CDNI Logging Feed. To do so, the client-side: server-side in the CDNI Logging Feed. To do so, the client-side:
o MUST use HTTP v1.1 o MUST use HTTP v1.1 ( [RFC2616])
o SHOULD use TLS (i.e. use what is loosely referred to as "HTTPS") o SHOULD use TLS (i.e. use what is loosely referred to as "HTTPS")
whenever protection of the CDNI LOgging information is required as per [RFC2818] whenever protection of the CDNI Logging
(see Section 7.1) information is required (see Section 6.1)
o MUST use the URI associated to the CDNI Logging File (in the "src" o MUST use the URI that was associated to the CDNI Logging File
attribute of the corresponding atom:content element) in the CDNI (within the "src" attribute of the corresponding atom:content
Logging Feed element) in the CDNI Logging Feed
o MUST support exchange of uncompressed CDNI Logging Files (i.e.
using "identity" content coding as defined in [RFC2616])
o SHOULD support exchange of gzip compressed CDNI Logging Files
(i.e. using "gzip" content coding as defined in [RFC2616])
o SHOULD indicate the compression schemes it supports
Note that a client-side implementation of the CDNI Logging interface Note that a client-side implementation of the CDNI Logging interface
MAY pull a CDNI Logging File that it has already pulled, as long as MAY pull a CDNI Logging File that it has already pulled, as long as
the file is still published by the server-side in the subscription the file is still published by the server-side in the subscription
document of CDNI Logging Feed. document of CDNI Logging Feed.
[Editor's note: if a given Logging file is moved away from [Editor's note: if a given Logging file is moved away from
subscription document to an archive document, do we agree it may no subscription document to an archive document, do we agree it may no
longer be accessible to uCDN?] longer be accessible to uCDN?]
The server-side implementation MUST respond to any valid pull request The server-side implementation MUST respond to any valid pull request
by a client-side implementation for a CDNI Logging File published by by a client-side implementation for a CDNI Logging File published by
the server-side in the subscription document of the CDNI Logging the server-side in the subscription document of the CDNI Logging
Feed. The server-side implementation: Feed. The server-side implementation:
o MUST handle the client-side request as per HTTP v1.1 o MUST handle the client-side request as per HTTP v1.1
o MUST include the CDNI Logging File identified by the request URI o MUST include the CDNI Logging File identified by the request URI
inside the body of the HTTP response inside the body of the HTTP response
o MUST support the gzip and deflate compression schemes o MUST support exchange of uncompressed CDNI Logging Files (i.e.
using "identity" content-coding as defined in [RFC2616])
o MAY support other compression schemes
o when the client-side request indicates client-supported
compression schemes, the server-side SHOULD use a compression
scheme that it supports and is supported by the client-side
5. Open Issues
o Compression: <Ben>When we say the server MUST support gzip &
deflate we probably need to think through whether we mean content-
encoding, transfer-encoding or both. The semantics get a little
confusing so we probably just need to think them through to ensure
we allow a server to store compressed logs as transmit them
compressed.
o Handling of Event logs and notifications: There are two aspects of
that question:
* non-real-time exchange of event logs from dCDN to uCDN for
audit purposes. This could be added to current spec presumably
in the form of additional Record-Types and without requiring a
significant change to the current CDNI Logging file exchange
approach. It is proposed that this be handled as a [MED]
requirement. e.g. try first specify what events and what
information needs to be exchanged; and depending on progress,
decide to include in initial logging spec or not
* real-time exchange of event notification from dCDN to uCDN for
immediate operational action (eg on notification by dCDN that
dCDN request routing is down, uCDN stops redirecting to this
dCDN). This would presumably require definition/extension of
another CDNI interface or significant change/extension to the
current CDNI logging spec. It is proposed that this be kept
out of the scope of the current cdni-logging spec .
Another question is what set of events should be logged/notified.
The first type of events relates to "service-level" events i.e.
high level events that affect the service that the dCDN is
providing to the uCDN (e.g.dCDN request routing is down, dCDN is
overloaded). There is general agreements that it is desirable to
be able to log/notify such service-level events. The second type
of events is "atomic-level" events i.e. low level events that may
be useful to identify or track a component issue or a delivery
issue. logging/notifying about such events may be useful in some
situations (eg uCDN and dCDN have a particular relationship
allowing them to share detailed operational information) and may
not be useful in some situations (because the dCDN does not want
to expose details of its CDN operation). Ideal approach is to
define both types of events and have the first type as MUST and
the second type as MAY. Fall back approach would be to only
define the first type initially.
o Add precise definition of what must be supported by transmitting o SHOULD support exchange of gzip compressed CDNI Logging Files
implementation and what must be implemented by receiving (i.e. using "gzip" content-coding as defined in [RFC2616]
application (regardless of what may actually be used in a given
deployment). For example, it may be reasonable to mandate that a
receiving implementation be able to receive all the directives
specified in the doc and all fields.
o Clean-up MUST/SHOULD/MAY to clarify (where needed) implementations Content negotiation approaches defined in [RFC2616] (e.g. using
requirements (ie what any implementation must be capable of doing) Accept-Encoding request-header field or Content-Encoding entity-
vs deployment requirements (ie what must be used in a given header field) MAY be used by the client-side and server-side
environment). implementations to establish the content-coding to be used for a
particular exchange of a CDNI Logging File.
6. IANA Considerations 5. IANA Considerations
6.1. CDNI Logging Directive Names Registry 5.1. CDNI Logging Directive Names Registry
The IANA is requested to create a new registry, CDNI Logging The IANA is requested to create a new registry, CDNI Logging
Directive Names. Directive Names.
The initial contents of the CDNI Logging File Directives registry The initial contents of the CDNI Logging File Directives registry
comprise the names of the directives specified in Section 3.3 of the comprise the names of the directives specified in Section 3.3 of the
present document, and are as follows: present document, and are as follows:
+------------------------------+-----------+ +------------------------------+-----------+
+ Directive Name + Reference | + Directive Name + Reference |
skipping to change at page 35, line 25 skipping to change at page 35, line 21
+------------------------------+-----------+ +------------------------------+-----------+
Figure 5 Figure 5
[Instructions to IANA: Replace "RFC xxxx" above by the RFC number of [Instructions to IANA: Replace "RFC xxxx" above by the RFC number of
the present document] the present document]
Within the registry, names are to be allocated by IANA according to Within the registry, names are to be allocated by IANA according to
the "Specification Required" policy specified in [RFC5226]. the "Specification Required" policy specified in [RFC5226].
6.2. CDNI Logging Record-Types Registry 5.2. CDNI Logging Record-Types Registry
The IANA is requested to create a new registry, CDNI Logging Record- The IANA is requested to create a new registry, CDNI Logging Record-
Types. Types.
The initial contents of the CDNI Logging Record-Types registry The initial contents of the CDNI Logging Record-Types registry
comprise the names of the CDNI Logging Record types specified in comprise the names of the CDNI Logging Record types specified in
Section 3.4 of the present document, and are as follows: Section 3.4 of the present document, and are as follows:
+------------------------------+-----------+ +------------------------------+-----------+
+ Record-Types + Reference | + Record-Types + Reference |
skipping to change at page 35, line 49 skipping to change at page 35, line 45
Figure 6 Figure 6
[Instructions to IANA: Replace "RFC xxxx" above by the RFC number of [Instructions to IANA: Replace "RFC xxxx" above by the RFC number of
the present document] the present document]
Within the registry, Record-Types are to be allocated by IANA Within the registry, Record-Types are to be allocated by IANA
according to the "Specification Required" policy specified in according to the "Specification Required" policy specified in
[RFC5226]. [RFC5226].
6.3. CDNI Logging Field Names Registry 5.3. CDNI Logging Field Names Registry
The IANA is requested to create a new registry, CDNI Logging Field The IANA is requested to create a new registry, CDNI Logging Field
Names. Names.
The initial contents of the CDNI Logging Fields Names registry The initial contents of the CDNI Logging Fields Names registry
comprise the names of the CDNI Logging fields specified in comprise the names of the CDNI Logging fields specified in
Section 3.4 of the present document, and are as follows: Section 3.4 of the present document, and are as follows:
+---------------------------------------------+-----------+ +---------------------------------------------+-----------+
+ Field Name + Reference | + Field Name + Reference |
skipping to change at page 36, line 33 skipping to change at page 36, line 33
+ u-uri + RFC xxxx | + u-uri + RFC xxxx |
+ protocol + RFC xxxx | + protocol + RFC xxxx |
+ sc-status + RFC xxxx | + sc-status + RFC xxxx |
+ sc- total-bytes + RFC xxxx | + sc- total-bytes + RFC xxxx |
+ sc-entity-bytes + RFC xxxx | + sc-entity-bytes + RFC xxxx |
+ cs(<HTTP-header>) + RFC xxxx | + cs(<HTTP-header>) + RFC xxxx |
+ sc(<HTTP-header>) + RFC xxxx | + sc(<HTTP-header>) + RFC xxxx |
+ s-ccid + RFC xxxx | + s-ccid + RFC xxxx |
+ s-sid + RFC xxxx | + s-sid + RFC xxxx |
+ s-cached + RFC xxxx | + s-cached + RFC xxxx |
+ s-uri-signing + RFC xxxx |
+---------------------------------------------+-----------+ +---------------------------------------------+-----------+
Figure 7 Figure 7
[Instructions to IANA: Replace "RFC xxxx" above by the RFC number of [Instructions to IANA: Replace "RFC xxxx" above by the RFC number of
the present document] the present document]
Within the registry, names are to be allocated by IANA according to Within the registry, names are to be allocated by IANA according to
the "Specification Required" policy specified in [RFC5226]. the "Specification Required" policy specified in [RFC5226].
6.4. CDNI Logging MIME Media Type 5.4. CDNI Logging MIME Media Type
The IANA is requested to allocate the "application/cdni.LoggingFile" The IANA is requested to allocate the "application/cdni.LoggingFile"
MIME Media Type (whose use is specified in Section 4.1.1 of the MIME Media Type (whose use is specified in Section 4.1.1 of the
present document) in the MIME Media Types registry. present document) in the MIME Media Types registry.
7. Security Considerations 6. Security Considerations
7.1. Authentication, Confidentiality, Integrity Protection
The use of TLS for transport of the CDNI Logging feed mechanism 6.1. Authentication, Confidentiality, Integrity Protection
(Section 4.1) and CDNI Logging File pull mechanism (Section 4.2) The use of TLS as per [RFC2818] for transport of the CDNI Logging
allows: feed mechanism (Section 4.1) and CDNI Logging File pull mechanism
(Section 4.2) allows:
o the dCDN and uCDN to authenticate each other (to ensure they are o the dCDN and uCDN to authenticate each other (to ensure they are
transmitting/receiving CDNI Logging File from an authenticated transmitting/receiving CDNI Logging File from an authenticated
CDN) CDN)
o the CDNI Logging information to be transmitted with o the CDNI Logging information to be transmitted with
confidentiality confidentiality
o the integrity of the CDNI Logging information to be protected o the integrity of the CDNI Logging information to be protected
during the exchange during the exchange
skipping to change at page 37, line 36 skipping to change at page 37, line 34
The Integrity-Hash directive inside the CDNI Logging File provides The Integrity-Hash directive inside the CDNI Logging File provides
additional integrity protection, this time targeting potential additional integrity protection, this time targeting potential
corruption of the CDNI logging information during the CDNI Logging corruption of the CDNI logging information during the CDNI Logging
File generation. This mechanism does not allow restoration of the File generation. This mechanism does not allow restoration of the
corrupted CDNI Logging information, but it allows detection of such corrupted CDNI Logging information, but it allows detection of such
corruption and therefore triggering of appropraite correcting actions corruption and therefore triggering of appropraite correcting actions
(e.g. discard of corrupted information, attempt to re-obtain the CDNI (e.g. discard of corrupted information, attempt to re-obtain the CDNI
Logging information). Logging information).
7.2. Non Repudiation 6.2. Privacy
The Non-Repudiation-Signature directive in the CDNI Logging File
allows support of non-repudiation of the CDNI Logging File by the
dCDN. The optional Non-Repudiation-Hash can be used on the CDNI
Logging interface where needed.
7.3. Privacy
CDNs have the opportunity to collect detailed information about the CDNs have the opportunity to collect detailed information about the
downloads performed by End-Users. The provision of this information downloads performed by End-Users. The provision of this information
to another CDN introduces potential End-Users privacy protection to another CDN introduces potential End-Users privacy protection
concerns. We observe that when CDNI interconnection is realised as concerns. We observe that when CDNI interconnection is realised as
per [I-D.ietf-cdni-framework], the uCDN handles the initial End-User per [I-D.ietf-cdni-framework], the uCDN handles the initial End-User
requests (before it is redirected to the dCDN) so, regardless of requests (before it is redirected to the dCDN) so, regardless of
which information is, or is not, communicated to the uCDN through the which information is, or is not, communicated to the uCDN through the
CDNI Logging interface, the uCDN has visibility on significant CDNI Logging interface, the uCDN has visibility on significant
information such as the IP address of the End-User request and the information such as the IP address of the End-User request and the
skipping to change at page 38, line 17 skipping to change at page 38, line 8
anonymization is required to avoid making some detailed information anonymization is required to avoid making some detailed information
available to the uCDN (such as how much bytes of the content has been available to the uCDN (such as how much bytes of the content has been
watched by an enduser and/or at what time) or is required to meet watched by an enduser and/or at what time) or is required to meet
some legal obligations, then the uCDN and dCDN can agree to exchange some legal obligations, then the uCDN and dCDN can agree to exchange
anonymized End-User IP addresses in CDNI Logging files and the c-ip- anonymized End-User IP addresses in CDNI Logging files and the c-ip-
anonymization field can be used to convey the number of bits that anonymization field can be used to convey the number of bits that
have been anonymized so that the meaningful information can still be have been anonymized so that the meaningful information can still be
easily extracted from the anonymized addressses (e.g. for geolocation easily extracted from the anonymized addressses (e.g. for geolocation
aware analytics). aware analytics).
8. Acknowledgments 7. Acknowledgments
This document borrows from the W3C Extended Log Format [ELF]. This document borrows from the W3C Extended Log Format [ELF].
Rob Murray significantly contributed into the text of Section 4.1 . Rob Murray significantly contributed into the text of Section 4.1 .
The authors would like to thank Sebastien Cubaud, Pawel Grochocki, The authors would like to thank Sebastien Cubaud, Pawel Grochocki,
Christian Jacquenet, Yannick Le Louedec, Anne Marrec and Emile Christian Jacquenet, Yannick Le Louedec, Anne Marrec and Emile
Stephan for their contributions on early versions of this document. Stephan for their contributions on early versions of this document.
The authors would like also to thank Fabio Costa, Sara Oueslati, Yvan The authors would like also to thank Fabio Costa, Sara Oueslati, Yvan
Massot, Renaud Edel, and Joel Favier for their input and comments. Massot, Renaud Edel, and Joel Favier for their input and comments.
Finally, they thank the contributors of the EU FP7 OCEAN project for Finally, they thank the contributors of the EU FP7 OCEAN project for
valuable inputs. valuable inputs.
9. References 8. References
9.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC Resource Identifier (URI): Generic Syntax", STD 66, RFC
skipping to change at page 39, line 15 skipping to change at page 39, line 8
[RFC5005] Nottingham, M., "Feed Paging and Archiving", RFC 5005, [RFC5005] Nottingham, M., "Feed Paging and Archiving", RFC 5005,
September 2007. September 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
9.2. Informative References 8.2. Informative References
[CHAR_SET] [CHAR_SET]
, "IANA Character Sets registry", , <http://www.iana.org/ , "IANA Character Sets registry", , <http://www.iana.org/
assignments/character-sets/character-sets.xml>. assignments/character-sets/character-sets.xml>.
[ELF] Phillip M. Hallam-Baker, . and . Brian Behlendorf, [ELF] Phillip M. Hallam-Baker, . and . Brian Behlendorf,
"Extended Log File Format, W3C (work in progress), WD- "Extended Log File Format, W3C (work in progress), WD-
logfile-960323", , <http://www.w3.org/TR/WD-logfile.html>. logfile-960323", , <http://www.w3.org/TR/WD-logfile.html>.
[I-D.brandenburg-cdni-has]
Brandenburg, R., Deventer, O., Faucheur, F., and K. Leung,
"Models for adaptive-streaming-aware CDN Interconnection",
draft-brandenburg-cdni-has-05 (work in progress), April
2013.
[I-D.ietf-cdni-framework] [I-D.ietf-cdni-framework]
Peterson, L. and B. Davie, "Framework for CDN Peterson, L. and B. Davie, "Framework for CDN
Interconnection", draft-ietf-cdni-framework-03 (work in Interconnection", draft-ietf-cdni-framework-05 (work in
progress), February 2013. progress), September 2013.
[I-D.ietf-cdni-metadata] [I-D.ietf-cdni-metadata]
Niven-Jenkins, B., Murray, R., Watson, G., Caulfield, M., Niven-Jenkins, B., Murray, R., Watson, G., Caulfield, M.,
Leung, K., and K. Ma, "CDN Interconnect Metadata", draft- Leung, K., and K. Ma, "CDN Interconnect Metadata", draft-
ietf-cdni-metadata-01 (work in progress), February 2013. ietf-cdni-metadata-02 (work in progress), July 2013.
[I-D.ietf-cdni-requirements] [I-D.ietf-cdni-requirements]
Leung, K. and Y. Lee, "Content Distribution Network Leung, K. and Y. Lee, "Content Distribution Network
Interconnection (CDNI) Requirements", draft-ietf-cdni- Interconnection (CDNI) Requirements", draft-ietf-cdni-
requirements-09 (work in progress), July 2013. requirements-10 (work in progress), September 2013.
[I-D.snell-atompub-link-extensions] [I-D.snell-atompub-link-extensions]
Snell, J., "Atom Link Extensions", draft-snell-atompub- Snell, J., "Atom Link Extensions", draft-snell-atompub-
link-extensions-09 (work in progress), June 2012. link-extensions-09 (work in progress), June 2012.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. April 1992.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem Distribution Network Interconnection (CDNI) Problem
Statement", RFC 6707, September 2012. Statement", RFC 6707, September 2012.
[RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, [RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma,
K., and G. Watson, "Use Cases for Content Delivery Network K., and G. Watson, "Use Cases for Content Delivery Network
Interconnection", RFC 6770, November 2012. Interconnection", RFC 6770, November 2012.
[RFC6983] van Brandenburg, R., van Deventer, O., Le Faucheur, F.,
and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware
Content Distribution Network Interconnection (CDNI)", RFC
6983, July 2013.
Appendix A. Requirements Appendix A. Requirements
[Editor's Note: text in this Appendix will be revisited soon]
A.1. Compliance with cdni-requirements A.1. Compliance with cdni-requirements
This section discusses compliance of the present specification This section discusses compliance of the present specification
against all the relevant requirements of against all the relevant requirements of
[I-D.ietf-cdni-requirements]. [I-D.ietf-cdni-requirements].
[Editor's Note: we may want to re-structure this into a table that [Editor's Note: we may want to re-structure this into a table that
would more clearly show compliance level] would more clearly show compliance level]
A.1.1. General requirements A.1.1. General requirements
skipping to change at page 40, line 43 skipping to change at page 40, line 40
not require any change or upgrade on the user agent [GEN-2] or on the not require any change or upgrade on the user agent [GEN-2] or on the
Content Service Provider side [GEN-3]. Also, no intra-CDN Content Service Provider side [GEN-3]. Also, no intra-CDN
information is necessary [GEN-4] and the CDNI Logging Interface information is necessary [GEN-4] and the CDNI Logging Interface
supports any interconnection topology [GEN-10]. However, The CDNI supports any interconnection topology [GEN-10]. However, The CDNI
Logging Interface does not define a specific loop avoidance mechanism Logging Interface does not define a specific loop avoidance mechanism
[GEN-11], but the exchange of logs is usually done in a point to [GEN-11], but the exchange of logs is usually done in a point to
point manner between two well identified entities situated point manner between two well identified entities situated
respectively in the uCDN and the dCDN. respectively in the uCDN and the dCDN.
The CDNI Loggin Interface supports specific logging for the HTTP The CDNI Loggin Interface supports specific logging for the HTTP
Adaptive Streaming content. [I-D.brandenburg-cdni-has] offers more Adaptive Streaming content. [RFC6983] offers more details about
details about particular logging fields required for HTTP Adaptive particular logging fields required for HTTP Adaptive Streaming.
Streaming.
A.1.2. Logging Interface requirements A.1.2. Logging Interface requirements
Reliable transfer is achieved by the transport protocol: the logging Reliable transfer is achieved by the transport protocol: the logging
information is transmitted over HTTP running over TCP [LI-1]. information is transmitted over HTTP running over TCP [LI-1].
The CDNI Logging Interface supports logs for all content deliveries The CDNI Logging Interface supports logs for all content deliveries
both complete and incomplete performed by the dCDN on behalf of the both complete and incomplete performed by the dCDN on behalf of the
uCDN [LI-2]. uCDN [LI-2].
skipping to change at page 42, line 6 skipping to change at page 41, line 49
itself or any other cascaded CDN is included in the current version itself or any other cascaded CDN is included in the current version
of the document. Future versions of this document might define such of the document. Future versions of this document might define such
information [LI-10, LI-11, LI-12]. information [LI-10, LI-11, LI-12].
The current version of the document specifies the logging information The current version of the document specifies the logging information
related strictly to the delivery process. Logging files for any related strictly to the delivery process. Logging files for any
other functionalities (e.g., content purge, request routing events other functionalities (e.g., content purge, request routing events
etc.) might be taken into account in future versions [LI-13]. etc.) might be taken into account in future versions [LI-13].
Extensibility, the logging and exchange of proprietary information Extensibility, the logging and exchange of proprietary information
fields are detailed in Section 6 IANA Considerations [LI-14, LI-15]. fields are detailed in Section 5 IANA Considerations [LI-14, LI-15].
The ATOM protocol allows the dCDN to publish the list of available The ATOM protocol allows the dCDN to publish the list of available
resources (i.e. logging files) [LI-16]. resources (i.e. logging files) [LI-16].
Section 3.4 provides details about the fields of the HTTP Adaptive Section 3.4 provides details about the fields of the HTTP Adaptive
Streaming specific logging records, including the Content Collection Streaming specific logging records, including the Content Collection
Identifier (s-ccid) and Session Identifier (s-sid) [LI-17]. Identifier (s-ccid) and Session Identifier (s-sid) [LI-17].
A.1.3. Security requirements A.1.3. Security requirements
[SEC-3, SEC-5] are not applicable to the CDNI Loggin Interface, all [SEC-3, SEC-5] are not applicable to the CDNI Loggin Interface, all
remaining security requirements are addressed as discussed in remaining security requirements are addressed as discussed in
Section 7. Section 6.
A.2. Considerations on CDNI Logging Applicability A.2. Considerations on CDNI Logging Applicability
This section discusses a number of considerations related to the This section discusses a number of considerations related to the
applicability of the CDNI Logging interface as specified in the applicability of the CDNI Logging interface as specified in the
present document. present document.
[Editor's note: How do we incorporate this info into the I-D: in [Editor's note: How do we incorporate this info into the I-D: in
appendix? in main body? does it remain after publication or is appendix? in main body? does it remain after publication or is
temporary?] temporary?]
skipping to change at page 43, line 8 skipping to change at page 42, line 45
This document leaves this requirement out of scope. This document leaves this requirement out of scope.
A.2.2. Reliability A.2.2. Reliability
CDNI logging information must be transmitted reliably. The transport CDNI logging information must be transmitted reliably. The transport
protocol should contain an anti-replay mechanism. protocol should contain an anti-replay mechanism.
A.2.3. Security A.2.3. Security
CDNI logging information exchange must allow authentication, CDNI logging information exchange must allow authentication,
integrity protection, and confidentiality protection. Also, a non- integrity protection, and confidentiality protection.
repudiation mechanism is mandatory, the transport protocol should
support it.
A.2.4. Scalability A.2.4. Scalability
CDNI logging information exchange must support large scale CDNI logging information exchange must support large scale
information exchange, particularly so in the presence of HTTP information exchange, particularly so in the presence of HTTP
Adaptive Streaming. Adaptive Streaming.
For example, if we consider a client pulling HTTP Progressive For example, if we consider a client pulling HTTP Progressive
Download content with an average duration of 10 minutes, this Download content with an average duration of 10 minutes, this
represents 1/600 CDNI delivery Logging Records per second. If we represents 1/600 CDNI delivery Logging Records per second. If we
 End of changes. 78 change blocks. 
277 lines changed or deleted 263 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/