draft-ietf-cdni-logging-04.txt   draft-ietf-cdni-logging-05.txt 
Internet Engineering Task Force G. Bertrand, Ed. Internet Engineering Task Force F. Le Faucheur, Ed.
Internet-Draft I. Oprescu, Ed. Internet-Draft Cisco Systems
Intended status: Informational France Telecom - Orange Intended status: Standards Track G. Bertrand, Ed.
Expires: December 27, 2013 F. Le Faucheur, Ed. Expires: January 13, 2014 I. Oprescu, Ed.
Cisco Systems Orange
R. Peterkofsky R. Peterkofsky
Skytide, Inc. Skytide, Inc.
June 25, 2013 July 12, 2013
CDNI Logging Interface CDNI Logging Interface
draft-ietf-cdni-logging-04 draft-ietf-cdni-logging-05
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 December 27, 2013. This Internet-Draft will expire on January 13, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . 11
2.2.5.1. Maintenance/Debugging . . . . . . . . . . . . . . 11 2.2.5.1. Maintenance/Debugging . . . . . . . . . . . . . . 11
2.2.5.2. Accounting . . . . . . . . . . . . . . . . . . . 12 2.2.5.2. Accounting . . . . . . . . . . . . . . . . . . . 12
skipping to change at page 2, line 47 skipping to change at page 2, line 36
2.2.5.4. Security . . . . . . . . . . . . . . . . . . . . 12 2.2.5.4. Security . . . . . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . . 29 3.5. CDNI Logging File Example . . . . . . . . . . . . . . . . 28
4. CDNI Logging File Exchange Protocol . . . . . . . . . . . . . 30 4. CDNI Logging File Exchange Protocol . . . . . . . . . . . . . 29
4.1. CDNI Logging Feed . . . . . . . . . . . . . . . . . . . . 31 4.1. CDNI Logging Feed . . . . . . . . . . . . . . . . . . . . 30
4.2. CDNI Logging File Pull . . . . . . . . . . . . . . . . . 31 4.1.1. Atom Formatting . . . . . . . . . . . . . . . . . . . 30
5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.1.2. Updates to Log Files and the Feed . . . . . . . . . . 31
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 4.1.3. Redundant Feeds . . . . . . . . . . . . . . . . . . . 31
6.1. CDNI Logging Directive Names Registry . . . . . . . . . . 33 4.1.4. Example CDNI Logging Feed . . . . . . . . . . . . . . 31
6.2. CDNI Logging Record-Type Registry . . . . . . . . . . . . 34 4.2. CDNI Logging File Pull . . . . . . . . . . . . . . . . . 32
6.3. CDNI Logging Field Name Registry . . . . . . . . . . . . 34 5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 33
7. Security Considerations . . . . . . . . . . . . . . . . . . . 35 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
7.1. Authentication, Confidentiality, Integrity Protection . . 35 6.1. CDNI Logging Directive Names Registry . . . . . . . . . . 34
7.2. Non Repudiation . . . . . . . . . . . . . . . . . . . . . 36 6.2. CDNI Logging Record-Types Registry . . . . . . . . . . . 35
7.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 36 6.3. CDNI Logging Field Names Registry . . . . . . . . . . . . 35
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 6.4. CDNI Logging MIME Media Type . . . . . . . . . . . . . . 36
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 7. Security Considerations . . . . . . . . . . . . . . . . . . . 36
9.1. Normative References . . . . . . . . . . . . . . . . . . 37 7.1. Authentication, Confidentiality, Integrity Protection . . 37
9.2. Informative References . . . . . . . . . . . . . . . . . 37 7.2. Non Repudiation . . . . . . . . . . . . . . . . . . . . . 37
Appendix A. Requirements . . . . . . . . . . . . . . . . . . . . 38 7.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 37
A.1. Compliance with cdni-requirements . . . . . . . . . . . . 38 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38
A.2. Additional Requirements . . . . . . . . . . . . . . . . . 39 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
A.2.1. Timeliness . . . . . . . . . . . . . . . . . . . . . 39 9.1. Normative References . . . . . . . . . . . . . . . . . . 38
A.2.2. Reliability . . . . . . . . . . . . . . . . . . . . . 39 9.2. Informative References . . . . . . . . . . . . . . . . . 39
A.2.3. Security . . . . . . . . . . . . . . . . . . . . . . 39 Appendix A. Requirements . . . . . . . . . . . . . . . . . . . . 40
A.2.4. Scalability . . . . . . . . . . . . . . . . . . . . . 39 A.1. Compliance with cdni-requirements . . . . . . . . . . . . 40
A.2.5. Consistency between CDNI Logging and CDN Logging . . 40 A.1.1. General requirements . . . . . . . . . . . . . . . . 40
A.2.6. Dispatching/Filtering . . . . . . . . . . . . . . . . 40 A.1.2. Logging Interface requirements . . . . . . . . . . . 40
Appendix B. Analysis of candidate protocols for Logging A.1.3. Security requirements . . . . . . . . . . . . . . . . 42
Transport . . . . . . . . . . . . . . . . . . . . . 40 A.2. Considerations on CDNI Logging Applicability . . . . . . 42
B.1. Syslog . . . . . . . . . . . . . . . . . . . . . . . . . 40 A.2.1. Timeliness . . . . . . . . . . . . . . . . . . . . . 42
B.2. XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . 40 A.2.2. Reliability . . . . . . . . . . . . . . . . . . . . . 42
B.3. SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . 40 A.2.3. Security . . . . . . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 A.2.4. Scalability . . . . . . . . . . . . . . . . . . . . . 43
A.2.5. Consistency between CDNI Logging and CDN Logging . . 43
A.2.6. Dispatching/Filtering . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction 1. Introduction
This memo specifies the Logging interface between a downstream CDN This memo specifies the CDNI Logging interface between a downstream
(dCDN) and an upstream CDN (uCDN). First, it describes a reference CDN (dCDN) and an upstream CDN (uCDN). First, it describes a
model for CDNI logging. Then, it specifies the CDNI Logging File reference model for CDNI logging. Then, it specifies the CDNI
format and the actual protocol for exchange of CDNI Logging Files. Logging File format and the actual protocol for exchange of CDNI
Logging Files.
The reader should be familiar with the following documents: The reader should be familiar with the following documents:
o CDNI problem statement [RFC6707] and framework o CDNI problem statement [RFC6707] and framework
[I-D.ietf-cdni-framework] identify a Logging interface, [I-D.ietf-cdni-framework] identify a Logging interface,
o Section 8 of [I-D.ietf-cdni-requirements] specifies a set of o Section 8 of [I-D.ietf-cdni-requirements] specifies a set of
requirements for Logging, requirements for Logging,
o [RFC6770] outlines real world use-cases for interconnecting CDNs. o [RFC6770] outlines real world use-cases for interconnecting CDNs.
skipping to change at page 5, line 18 skipping to change at page 5, line 9
Performance Indicators (KPIs). Performance Indicators (KPIs).
CDN Monitoring: the process of providing content delivery information CDN Monitoring: the process of providing content delivery information
in real-time. Monitoring typically includes data in real time to in real-time. Monitoring typically includes data in real time to
provide visibility of the deliveries in progress, for service provide visibility of the deliveries in progress, for service
operation purposes. It presents a view of the global health of the operation purposes. It presents a view of the global health of the
services as well as information on usage and performance, for network services as well as information on usage and performance, for network
services supervision and operation management. In particular, services supervision and operation management. In particular,
monitoring data can be used to generate alarms. monitoring data can be used to generate alarms.
1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. CDNI Logging Reference Model 2. CDNI Logging Reference Model
2.1. CDNI Logging interactions 2.1. CDNI Logging interactions
The CDNI logging reference model between a given uCDN and a given The CDNI logging reference model between a given uCDN and a given
dCDN involves the following interactions: dCDN involves the following interactions:
o customization by the uCDN of the CDNI logging information to be o customization by the uCDN of the CDNI logging information to be
provided by the dCDN to the uCDN (e.g. control of which logging provided by the dCDN to the uCDN (e.g. control of which logging
fields are to be communicated to the uCDN for a given task fields are to be communicated to the uCDN for a given task
skipping to change at page 16, line 26 skipping to change at page 16, line 26
All times are specified in Universal Time Coordinated (UTC). All times are specified in Universal Time Coordinated (UTC).
3.2. CDNI Logging File Structure 3.2. CDNI Logging File Structure
As defined in Section 1.1 a CDNI logging field is as an atomic As defined in Section 1.1 a CDNI logging field is as an atomic
logging information element and a CDNI Logging Record is a collection logging information element and a CDNI Logging Record is a collection
of CDNI Logging Fields containing all logging information of CDNI Logging Fields containing all logging information
corresponding to a single logging event. This document defines a corresponding to a single logging event. This document defines a
third level of structure, the CDNI Logging File, that is a collection third level of structure, the CDNI Logging File, that is a collection
of CDNI Logging Records. This structure is illustrated in Figure 3. of CDNI Logging Records. This structure is illustrated in Figure 3.
The use of a file structure for transfer of CDNI Logging information
is selected since this is the most common practise today for exchange
of logging information within and across CDNs.
+----------------------------------------------------------+ +----------------------------------------------------------+
|CDNI Logging File | |CDNI Logging File |
| | | |
| #Directive 1 | | #Directive 1 |
| #Directive 2 | | #Directive 2 |
| ... | | ... |
| #Directive P | | #Directive P |
| | | |
| +------------------------------------------------------+ | | +------------------------------------------------------+ |
skipping to change at page 17, line 47 skipping to change at page 18, line 4
Directives are specified in Section 3.3. Directives are specified in Section 3.3.
Logging Records provide actual details of the logged event. Logging Logging Records provide actual details of the logged event. Logging
Records are specified in Section 3.4. Records are specified in Section 3.4.
The CDNI File structure is defined by the following rules: The CDNI File structure is defined by the following rules:
DIRLINE = "#" directive CRLF DIRLINE = "#" directive CRLF
DIRGROUP = 1*DIRLINE DIRGROUP = 1*DIRLINE
RECLINE = <CDNI Logging Record> CRLF RECLINE = <CDNI Logging Record> CRLF
RECGROUP = *RECLINE RECGROUP = *RECLINE
<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 = <directive name> = "Version" / "UUID" / "Claimed-Origin" DIRNAME = any CDNI Logging Directive name registered in the CDNI
/ "Verified-Origin" / "Record-Type" / "Fields" / "Integrity-Hash" Logging Directive Names registry (Section 6.1).
/ "Non-Repudiation-Signature"
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 the
following directives, listed below by their directive name: 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. It MUST be the first line of the CDNI Logging file.
o UUID: o UUID:
* format: QSTRING * format: NHTABSTRING
* directive value: this is Universally Unique IDentifier for the * directive value: this a Universally Unique IDentifier (UUID)
CDNI Logging File as specified in [RFC4122]. [Editor's note: from the UUID Uniform Resource Name (URN) namespace specified
check RFC4122 format to see if QSTRING is the right format] 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.
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
skipping to change at page 19, line 40 skipping to change at page 19, line 40
observe that, in particular, this may be achieved through 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). "cdni_http_request_v1" (or the end of the CDNI Logging File). This can be any CDNI
MUST be indicated as the Record-Type directive value for CDNI Logging Record type registered in the CDNI Logging Record-types
Logging records corresponding to HTTP request (e.g. a HTTP registry (Section 6.2). "cdni_http_request_v1" MUST be
delivery request) as specified in Section 3.4.1. indicated as the Record-Type directive value for CDNI Logging
records corresponding to HTTP request (e.g. a HTTP delivery
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. The first instance of this directive MUST precede a
Fields directive and precede any CDNI Logging Record. Fields directive and precede any CDNI Logging Record.
o Fields: o Fields:
* format: FIENAME *<HTAB FIENAME> ; where FIENAME is specified in * format: FIENAME *<HTAB FIENAME> ; where FIENAME can take any
Section 3.4. CDNI Logging field name registered in the CDNI Logging Field
Names registry (Section 6.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 are
after this directive. The names of the fields, as well as after this directive. The names of the fields, as well as
their possible occurrences, are specified for each type of CDNI 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 precede any CDNI
skipping to change at page 21, line 16 skipping to change at page 21, line 18
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 when the
Non-Repudiation-Hash is absent, and MUST be the one before last Non-Repudiation-Hash is absent, and MUST be the one before last
line of the CDNI Logging File when the Non-Repudiation-Hash is line of the CDNI Logging File when the Non-Repudiation-Hash is
present. present.
o Non-Repudiation-Signature:
* format: QSTRING [Editor's Note: revisit format once this field
is specified]
* directive value: This field contains a signature that supports
the non-repudiation of the CDNI Logging File by the entity that
transmitted the CDNI Logging File. [Editor's Note: Detailed
description To Be Added. David Mandelberg has the lead for
drafting text.The text needs to indicate that the Claimed-
Origin directive MUST be covered and the Verified-Origin
directive MUST NOT be covered by the signature. We may want to
refer to RFC4949 for terminology around Non-Redudiation]
* occurrence: there MAY be one and only one instance of this
directive. When present, this directive MUST be the last line
of the CDNI Logging File.
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
field names in a similar way to the one used in W3C Extended Log File field names in a similar way to the one used in W3C Extended Log File
skipping to change at page 22, line 4 skipping to change at page 21, line 35
To facilitate readability, a prefix scheme is used for CDNI Logging To facilitate readability, a prefix scheme is used for CDNI Logging
field names in a similar way to the one used in W3C Extended Log File field names in a similar way to the one used in W3C Extended Log File
Format [ELF] . The semantics of the prefix in the present document Format [ELF] . The semantics of the prefix in the present document
is: is:
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 x: refers to extensions for vendor-specific logging fields o cs: refers to communication from the User-Agent towards the dCDN
Surrogate
o cs: refers to communication from the dCDN Surrogate towards the o sc: refers to communication from the dCDN Surrogate towards the
User-Agent User-Agent
o sc: refers to communication from the User-Agent towards the dCDN
Surrogate
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 delivery specified in Section 3.4.1. [Editor's Note": other types of CDNI
records will be listed here if we specify other types for this Logging records will be listed here if we specify other types for
version eg Request Routing]. 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.
FIENAME = "date" / "time" / "time-taken" / "c-ip" / "c-ip-
anonimizing" / "c-port" / "s-ip" / "s-hostname" / "s-port" / "cs-
method" / "cs-uri" / "u-uri" / "protocol" / "sc-status" / "sc-
total-bytes" / "sc-entity-bytes" / "cs(" <HTTP-header> ")" / "sc("
<HTTP-header> ")" / "s-ccid" / "s-sid" / "s-cached" / "s-uri-
signing" / "x-" <vendor-ID> "-" <vendor-specific-cdni-logging-
field-name>
3.4.1. HTTP Request Logging Record 3.4.1. HTTP Request Logging Record
The HTTP Request Logging Record is a CDNI Logging Record of Record- The HTTP Request Logging Record is a CDNI Logging Record of Record-
Type "cdni_http_request_v1". It contains the following CDNI Logging Type "cdni_http_request_v1". It contains the following CDNI Logging
Fields, listed by their field name: Fields, listed by their field name:
o date: o date:
* format: DATE * format: DATE
skipping to change at page 28, line 33 skipping to change at page 28, line 4
* field value: this characterises the uri signing validation * field value: this characterises the uri signing validation
performed by the Surrogate on the request. The allowed values performed by the Surrogate on the request. The allowed values
are: are:
* *
+ "0" : no uri signature validation performed + "0" : no uri signature validation performed
+ "1" : uri signature validation performed and validated + "1" : uri signature validation performed and validated
+ "2" : uri signature validation performed and rejected + "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.
o x-"vendor-ID"-"vendor-specific-cdni-logging-field-name":
* format: specified by the vendor for the actual vendor-specific
logging field. This format is outside the scope of the present
document.
* field value: this contains a vendor specific logging field.
The "vendor-ID" identifies the vendor and the "vendor-specific-
cdni-logging-field-name" identifies the actual vendor-specific
logging field. For example, a vendor specific field name would
look like "x-vendor1-important_info1".
* occurrence: there MUST be zero, one or any number of instance
of this 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
skipping to change at page 29, line 46 skipping to change at page 29, line 4
#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>
#Fields:<HTAB>date<HTAB>time<TAB>time-taken<HTAB>c-ip<HTAB>cs- #Fields:<HTAB>date<HTAB>time<TAB>time-taken<HTAB>c-ip<HTAB>cs-
method<HTAB>u-uri<HTAB>protocol<HTAB>sc-status<HTAB>sc-total- method<HTAB>u-uri<HTAB>protocol<HTAB>sc-status<HTAB>sc-total-
bytes<HTAB>cs(User-Agent)<HTAB>cs(Referer)<HTAB>s-cached<CRLF> bytes<HTAB>cs(User-Agent)<HTAB>cs(Referer)<HTAB>s-cached<CRLF>
2013-05-17<HTAB>00:38:06.825<HTAB>9.058<HTAB>10.5.7.1<HTAB>GET<HTAB>h
2013-05-17<HTAB>00:38:06.825<HTAB>88.958<HTAB>10.5.7.1<HTAB>GET<HTAB> ttp://cdni-ucdn.dcdn.example.com/video/movie100.mp4<HTAB>HTTP/
http://cdni-ucdn.dcdn.example.com/video/movie100.mp4<HTAB>HTTP/ 1.1<HTAB>200<HTAB>6729891<HTAB>"Mozilla/5.0 (Windows; U; Windows NT
1.1<HTAB>200<HTAB>672989<HTAB>"Mozilla/5.0 (Windows; U; Windows NT
6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127
Safari /533.4"<HTAB>"host1.example.com"<HTAB>1<CRLF> Safari /533.4"<HTAB>"host1.example.com"<HTAB>1<CRLF>
2013-05-17<HTAB>00:39:09.145<HTAB>169.790<HTAB>10.5.10.5<HTAB>GET<HTA
B>http://cdni-ucdn.dcdn.example.com/video/movie118.mp4<HTAB>HTTP/ 2013-05-17<HTAB>00:39:09.145<HTAB>15.32<HTAB>10.5.10.5<HTAB>GET<HTAB>
1.1<HTAB>200<HTAB>1579920<HTAB>"Mozilla/5.0 (Windows; U; Windows NT http://cdni-ucdn.dcdn.example.com/video/movie118.mp4<HTAB>HTTP/
1.1<HTAB>200<HTAB>15799210<HTAB>"Mozilla/5.0 (Windows; U; Windows NT
6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127
Safari /533.4"<HTAB>"host1.example.com"<HTAB>1<CRLF> Safari /533.4"<HTAB>"host1.example.com"<HTAB>1<CRLF>
2013-05-17<HTAB>00:42:53.437<HTAB>2.879<HTAB>10.5.10.5<HTAB>GET<HTAB> 2013-05-17<HTAB>00:42:53.437<HTAB>52.879<HTAB>10.5.10.5<HTAB>GET<HTAB
http://cdni-ucdn.dcdn.example.com/video/picture11.mp4<HTAB>HTTP/ >http://cdni-ucdn.dcdn.example.com/video/picture11.mp4<HTAB>HTTP/
1.0<HTAB>200<HTAB>17724<HTAB>"Mozilla/5.0 (Windows; U; Windows NT 1.0<HTAB>200<HTAB>97234724<HTAB>"Mozilla/5.0 (Windows; U; Windows NT
6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127
Safari /533.4"<HTAB>"host5.example.com"<HTAB>0<CRLF> Safari /533.4"<HTAB>"host5.example.com"<HTAB>0<CRLF>
#Integrity-Hash: 9e107d9d372bb6826bd81d3542a419d6 [Editor's Note: #Integrity-Hash: 9e107d9d372bb6826bd81d3542a419d6 [Editor's Note:
include the correct MD5-hash value for the actual example]<CRLF> include the correct MD5-hash value for the actual example]<CRLF>
4. CDNI Logging File Exchange Protocol 4. CDNI Logging File Exchange Protocol
This document specifies a protocol for the exchange of CDNI Logging This document specifies a protocol for the exchange of CDNI Logging
Files as specified in Section 3. Files as specified in Section 3.
skipping to change at page 30, line 46 skipping to change at page 30, line 5
An implementation of the CDNI Logging interface as per the present An implementation of the CDNI Logging interface as per the present
document generating CDNI Logging file (i.e. on the dCDN side) MUST document generating CDNI Logging file (i.e. on the dCDN side) MUST
support the server side of the CDNI Logging feed and the server side support the server side of the CDNI Logging feed and the server side
of the CDNI Logging pull mechanism. of the CDNI Logging pull mechanism.
An implementation of the CDNI Logging interface as per the present An implementation of the CDNI Logging interface as per the present
document consuming CDNI Logging file (i.e. on the uCDN side) MUST document consuming CDNI Logging file (i.e. on the uCDN side) MUST
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.
[Editor's note: verify that the client side and server side are well
defined in the respective sections]
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 mechanism might be defined in future version of
the present document. the present document.
4.1. CDNI Logging Feed 4.1. CDNI Logging Feed
[Editor's Note: text to be added. Feed is based on ATOM and contains The server-side implementation of the CDNI Logging feed produces an
a UUID + URI for each CDNI Logging File in "window" - if appropriate Atom feed [RFC4287]. This feed is used to advertise log files that
the text should refer to the side generating the CDNI Logging Feed are available for the client-side to retrieve using the CDNI Logging
"as server-side", and the side consuming the Feed as the client- pull mechanism.
side].
4.1.1. Atom Formatting
A CDNI Logging feed MUST be structured as an Archived feed, as
defined in [RFC5005], and MUST be formatted in Atom [RFC4287]. This
means it consists of a subscription document that is regularly
updated as new CDNI logging files become available, and information
about older CDNI Logging files is moved into archive documents. Once
created, archive documents are never modified.
Each CDNI Logging file listed in an Atom feed MUST be described in an
atom:entry container element.
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 the MIME Media Type indicating that the entry if a CDNI
Logging File. We define this MIME Media Type as "application/
cdni.LoggingFile" (See Section 6.4).
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
CDNI Logging file and whose "type" attribute is the MIME Media Type
indicating that the entry if a CDNI Logging File. We define this
MIME Media Type as "application/cdni.LoggingFile" (See Section 6.4).
The IRI used in the atom:id of the atom:entry MUST contain the UUID
of the CDNI Logging file.
The atom:updated in the atom:entry MUST indicate the time at which
the CDNI Logging file was last updated.
4.1.2. Updates to Log Files and the Feed
CDNI Logging files MUST NOT be modified by the dCDN once published in
the CDNI Logging feed.
The frequency with which the subscription feed is updated, the period
of time covered by each CDNI Logging file or each archive document,
and timeliness of publishing of CDNI Logging files is outside the
scope of the present document and is expected to be agreed upon by
uCDN and dCDN via other means (e.g. human agreement).
The server-side implementation SHOULD use HTTP cache control headers
on the subscription feed to indicate the frequency at which the
client-side is to poll for updates.
4.1.3. Redundant Feeds
The server-side implementation MAY present more than one CDNI Logging
feed and for redundancy, CDNI Logging files MAY be published in more
than one feed.
A client-side implementation MAY support such redundant CDNI Logging
feeds. If it supports redundant CDNI Logging feed, the client-side
SHOULD use the UUID of the CDNI Logging file, presented in the
atom:id element of the Atom feed, to avoid uncessarily pulling each
CDNI Logging file more than once.
4.1.4. Example CDNI Logging Feed
Figure 4 illustrates an example of the subscription document of a
CDNI Logging feed.
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom"
<http://www.w3.org/2005/Atom%22>>
<title type="text">CDNI Logging Feed</title>
<updated>2013-03-23T16:21:11Z</updated>
<id>urn:uuid:663ae677-40fb-e99a-049d-c5642916b8ce</id>
<link href="https://dcdn.example/logfeeds/ucdn1"
rel="self" type="application/atom+xml" />
<link href="https://dcdn.example/logfeeds/ucdn1"
rel="current" type="application/atom+xml" />
<link href="https://dcdn.example/logfeeds/ucdn1/201303231400"
rel="prev-archive" type="application/atom+xml" />
<generator version="example version 1">CDNI Log Feed
Generator</generator>
<author><name>dcdn.example</name></author>
<entry>
<title type="text">CDNI Logging File for uCDN at
2013-03-23 14:55:00</title>
<id>urn:uuid:12345678-1234-abcd-00aa-01234567abcd</id>
<updated>2013-03-23T14:55:00Z</updated>
<content src="https://dcdn.example/logs/ucdn/
http-requests-20130323145500000000"
type="application/cdni.LoggingFile" />
<summary>CDNI Logging File for uCDN at
2013-03-23 14:55:00</summary>
</entry>
<entry>
<title type="text">CDNI Logging File for uCDN at
2013-03-23 15:55:00</title>
<id>urn:uuid:87654321-4321-dcba-aa00-dcba7654321</id>
<updated>2013-03-23T15:55:00Z</updated>
<content src="https://dcdn.example/logs/ucdn/
http-requests-20130323155500000000"
type="application/cdni.LoggingFile" />
<summary>CDNI Logging File for uCDN at
2013-03-23 15:55:00</summary>
</entry>
<entry>
...
</entry>
...
?</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 MAY pull A client-side implementation of the CDNI Logging interface pulls, at
at its convenience any CDNI Logging File that is advertised by the its convenience, any 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
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
(see Section 7.1)
o MUST use the URI associated to the CDNI Logging File in the CDNI o MUST use the URI associated to the CDNI Logging File (in the "src"
attribute of the corresponding atom:content element) in the CDNI
Logging Feed Logging Feed
o SHOULD indicate the compression schemes it supports 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 advertised by the server-side in the CDNI Logging the file is still published by the server-side in the subscription
Feed. document of CDNI Logging Feed.
[Editor's note: if a given Logging file is moved away from
subscription document to an archive document, do we agree it may no
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 advertised by by a client-side implementation for a CDNI Logging File published by
the server-side in the CDNI Logging Feed. The server-side the server-side in the subscription document of the CDNI Logging
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 the gzip and deflate compression schemes
o MAY support other compression schemes o MAY support other compression schemes
o when the client-side request indicates client-supported
compression schemes, SHOULD use a compression scheme that it
supports and is supported by the client-side
[Editor's Note: discuss Non-Repudiation : it is a nice to have and o when the client-side request indicates client-supported
how it could be supported, via a different digest than the one for compression schemes, the server-side SHOULD use a compression
integrity] scheme that it supports and is supported by the client-side
5. Open Issues 5. Open Issues
o Compression: <Ben>When we say the server MUST support gzip & o Compression: <Ben>When we say the server MUST support gzip &
deflate we probably need to think through whether we mean content- deflate we probably need to think through whether we mean content-
encoding, transfer-encoding or both. The semantics get a little encoding, transfer-encoding or both. The semantics get a little
confusing so we probably just need to think them through to ensure confusing so we probably just need to think them through to ensure
we allow a server to store compressed logs as transmit them we allow a server to store compressed logs as transmit them
compressed. compressed.
o Handling of Event logs and notifications: There are two aspects of o Handling of Event logs and notifications: There are two aspects of
that question: that question:
* non-real-time exchange of event logs from dCDN to uCDN for * non-real-time exchange of event logs from dCDN to uCDN for
audit purposes. This could be added to current spec presumably audit purposes. This could be added to current spec presumably
in the form of additional Record-Types and without requiring a in the form of additional Record-Types and without requiring a
significant change to the current CDNI LOgging file exchange significant change to the current CDNI Logging file exchange
approach. It is proposed that this be handled as a [MED] approach. It is proposed that this be handled as a [MED]
requirement. e.g. try first specify what events and what requirement. e.g. try first specify what events and what
information needs to be exchanged; and depending on progress, information needs to be exchanged; and depending on progress,
decide to include in initial logging spec or not decide to include in initial logging spec or not
* real-time exchange of event notification from dCDN to uCDN for * real-time exchange of event notification from dCDN to uCDN for
immediate operational action (eg on notification by dCDN that immediate operational action (eg on notification by dCDN that
dCDN request routing is down, uCDN stops redirecting to this dCDN request routing is down, uCDN stops redirecting to this
dCDN). This would presumably require definition/extension of dCDN). This would presumably require definition/extension of
another CDNI interface or significant change/extension to the another CDNI interface or significant change/extension to the
current CDNI logging spec. It is proposed that thisbe kept out current CDNI logging spec. It is proposed that this be kept
of the scope of the current cdni-logging spec . out of the scope of the current cdni-logging spec .
Another question is what set of events should be logged/notified. Another question is what set of events should be logged/notified.
The first type of events realtes to "service-level" events i.e. The first type of events relates to "service-level" events i.e.
high level events that affect the service that the dCDN is high level events that affect the service that the dCDN is
providing to the uCDN (e.g.dCDN request routing is down, 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 overloaded). There is general agreements that it is desirable to
be able to log/notify such service-level events. The second type 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 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 be useful to identify or track a component issue or a delivery
issue. logging/notifying about such events may be useful in some issue. logging/notifying about such events may be useful in some
situations (eg uCDN and dCDN have a particular relationship situations (eg uCDN and dCDN have a particular relationship
allowing them to share detailed operational information) and may allowing them to share detailed operational information) and may
not be useful in some situations (because the dCDN does not want not be useful in some situations (because the dCDN does not want
to expose details of its CDN operation). Ideal approach is to to expose details of its CDN operation). Ideal approach is to
define both types of events and have the first type as MUST and define both types of events and have the first type as MUST and
the second type as MAY. Fall back approach woudl be to only the second type as MAY. Fall back approach would be to only
define the first type initially. define the first type initially.
o Add precise definition of what must be supported by transmitting o Add precise definition of what must be supported by transmitting
implementation and what must be implemented by receiving implementation and what must be implemented by receiving
application (regardless of what may actually be used in a given application (regardless of what may actually be used in a given
deployment). For example, it may be reasonable to mandate that a deployment). For example, it may be reasonable to mandate that a
receiving implementaton but be able to receive all the directives receiving implementation be able to receive all the directives
specified in the doc and all fields. specified in the doc and all fields.
o Clean-up MUST/SHOULD/MAY to clarify (where needed) implementations
requirements (ie what any implementation must be capable of doing)
vs deployment requirements (ie what must be used in a given
environment).
6. IANA Considerations 6. IANA Considerations
6.1. CDNI Logging Directive Names Registry 6.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 |
+------------------------------+-----------+ +------------------------------+-----------+
+ Version + RFC xxxx | + Version + RFC xxxx |
+ UUID + RFC xxxx | + UUID + RFC xxxx |
+ Claimed-Origin + RFC xxxx | + Claimed-Origin + RFC xxxx |
+ Verified-Origin + RFC xxxx | + Verified-Origin + RFC xxxx |
+ Record-Type + RFC xxxx | + Record-Type + RFC xxxx |
+ Fields + RFC xxxx | + Fields + RFC xxxx |
+ Integrity-Hash + RFC xxxx | + Integrity-Hash + RFC xxxx |
+ Non-Repudiation-Signature + RFC xxxx |
+------------------------------+-----------+ +------------------------------+-----------+
Figure 4 Figure 5
[Instructions to IANA: Replace "RFC xxxx" by the RFC number of the
present document]
Additions to that registry are permitted by Standards Action, as [Instructions to IANA: Replace "RFC xxxx" above by the RFC number of
defined by [RFC5226]. the present document]
[Editor's Note: reserve a range of names -e.g."x-" for vendor- Within the registry, names are to be allocated by IANA according to
specific extensions] the "Specification Required" policy specified in [RFC5226].
6.2. CDNI Logging Record-Type Registry 6.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:
+------------------------------+-----------+ +------------------------------+-----------+
+ Directive name + Reference | + Record-Types + Reference |
+------------------------------+-----------+ +------------------------------+-----------+
+ cdni_http_request_v1 + RFC xxxx | + cdni_http_request_v1 + RFC xxxx |
+------------------------------+-----------+ +------------------------------+-----------+
Figure 5 Figure 6
[Instructions to IANA: Replace "RFC xxxx" by the RFC number of the
present document]
Additions to that registry are permitted by Standards Action, as [Instructions to IANA: Replace "RFC xxxx" above by the RFC number of
defined by [RFC5226]. the present document]
[Editor's Note: reserve a range of names -e.g."x-" for vendor- Within the registry, Record-Types are to be allocated by IANA
specific extensions] according to the "Specification Required" policy specified in
[RFC5226].
6.3. CDNI Logging Field Name Registry 6.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 Fiels 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 |
+---------------------------------------------+-----------+ +---------------------------------------------+-----------+
+ date + RFC xxxx | + date + RFC xxxx |
+ time + RFC xxxx | + time + RFC xxxx |
+ time-taken + RFC xxxx | + time-taken + RFC xxxx |
+ c-ip + RFC xxxx | + c-ip + RFC xxxx |
+ c-ip- anonimizing + RFC xxxx | + c-ip-anonimizing + RFC xxxx |
+ c-port + RFC xxxx | + c-port + RFC xxxx |
+ s-ip + RFC xxxx | + s-ip + RFC xxxx |
+ s-hostname + RFC xxxx | + s-hostname + RFC xxxx |
+ s-port + RFC xxxx | + s-port + RFC xxxx |
+ cs- method + RFC xxxx | + cs- method + RFC xxxx |
+ cs-uri + RFC xxxx | + cs-uri + RFC xxxx |
+ 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 | + s-uri-signing + RFC xxxx |
+ x-<vendor-ID> + |
+ -<vendor-specific-cdni-logging-field-name> + RFC xxxx |
+---------------------------------------------+-----------+ +---------------------------------------------+-----------+
Figure 6 Figure 7
[Instructions to IANA: Replace "RFC xxxx" by the RFC number of the [Instructions to IANA: Replace "RFC xxxx" above by the RFC number of
present document] the present document]
Additions to that registry are permitted by Standards Action, as Within the registry, names are to be allocated by IANA according to
defined by [RFC5226]. the "Specification Required" policy specified in [RFC5226].
[Editor's Note: tweak text for the range of names -e.g."x-" for 6.4. CDNI Logging MIME Media Type
vendor-specific extensions]
7. Security Considerations The IANA is requested to allocate the "application/cdni.LoggingFile"
MIME Media Type (whose use is specified in Section 4.1.1 of the
present document) in the MIME Media Types registry.
7. Security Considerations
7.1. Authentication, Confidentiality, Integrity Protection 7.1. Authentication, Confidentiality, Integrity Protection
The use of TLS for transport of the CDNI Logging feed mechanism The use of TLS for transport of the CDNI Logging feed mechanism
(Section 4.1) and CDNI Logging File pull mechanism (Section 4.2) (Section 4.1) and CDNI Logging File pull mechanism (Section 4.2)
allows: 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
In an environment where any such protection is required, TLS SHOULD
be used for transport of the CDNI Logging feed and the CDNI Logging
File pull.
A CDNI Logging implementation MUST support TLS transport of the CDNI
Logging feed and the CDNI Logging File pull.
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).
skipping to change at page 36, line 43 skipping to change at page 38, line 21
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 8. 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 .
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 Rob Murray, Fabio Costa, Sara Massot, Renaud Edel, and Joel Favier for their input and comments.
Oueslati, Yvan 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 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-cdni-metadata]
Niven-Jenkins, B., Murray, R., Watson, G., Caulfield, M.,
Leung, K., and K. Ma, "CDN Interconnect Metadata", draft-
ietf-cdni-metadata-01 (work in progress), February 2013.
[I-D.snell-atompub-link-extensions]
Snell, J., "Atom Link Extensions", draft-snell-atompub-
link-extensions-09 (work in progress), June 2012.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[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.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[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
3986, January 2005. 3986, January 2005.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, July Unique IDentifier (UUID) URN Namespace", RFC 4122, July
2005. 2005.
[RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
Syndication Format", RFC 4287, December 2005.
[RFC5005] Nottingham, M., "Feed Paging and Archiving", RFC 5005,
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.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
9.2. Informative References 9.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] [I-D.brandenburg-cdni-has]
Brandenburg, R., Deventer, O., Faucheur, F., and K. Leung, Brandenburg, R., Deventer, O., Faucheur, F., and K. Leung,
"Models for adaptive-streaming-aware CDN Interconnection", "Models for adaptive-streaming-aware CDN Interconnection",
draft-brandenburg-cdni-has-05 (work in progress), April draft-brandenburg-cdni-has-05 (work in progress), April
2013. 2013.
[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-03 (work in
progress), February 2013. progress), February 2013.
[I-D.ietf-cdni-metadata]
Niven-Jenkins, B., Murray, R., Watson, G., Caulfield, M.,
Leung, K., and K. Ma, "CDN Interconnect Metadata", draft-
ietf-cdni-metadata-01 (work in progress), February 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-07 (work in progress), May 2013. requirements-09 (work in progress), July 2013.
[I-D.snell-atompub-link-extensions]
Snell, J., "Atom Link Extensions", draft-snell-atompub-
link-extensions-09 (work in progress), June 2012.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[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.
Appendix A. Requirements Appendix A. Requirements
A.1. Compliance with cdni-requirements A.1. Compliance with cdni-requirements
This section checks that all the identified requirements in the This section discusses compliance of the present specification
Section 7 of [I-D.ietf-cdni-requirements] are fulfilled by this against all the relevant requirements of
document. [I-D.ietf-cdni-requirements].
[Editor's node: to be written later] [Editor's Note: we may want to re-structure this into a table that
would more clearly show compliance level]
A.2. Additional Requirements A.1.1. General requirements
This section identies additional requirements that must also be met. Some of the general CDNI requirements defined in
[I-D.ietf-cdni-requirements] are not applicable to the CDNI Logging
Interface [GEN-5, GEN-6, GEN-7, GEN-8, GEN-9, GEN-12].
[Editor's node: How do we incorporate this info into the I-D: in The Logging Interface does not define any new protocols [GEN-1], does
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
information is necessary [GEN-4] and the CDNI Logging Interface
supports any interconnection topology [GEN-10]. However, The CDNI
Logging Interface does not define a specific loop avoidance mechanism
[GEN-11], but the exchange of logs is usually done in a point to
point manner between two well identified entities situated
respectively in the uCDN and the dCDN.
The CDNI Loggin Interface supports specific logging for the HTTP
Adaptive Streaming content. [I-D.brandenburg-cdni-has] offers more
details about particular logging fields required for HTTP Adaptive
Streaming.
A.1.2. Logging Interface requirements
Reliable transfer is achieved by the transport protocol: the logging
information is transmitted over HTTP running over TCP [LI-1].
The CDNI Logging Interface supports logs for all content deliveries
both complete and incomplete performed by the dCDN on behalf of the
uCDN [LI-2].
The CDNI Logging Interface does not impose any restrictions related
to the transmission of logs generated by intermediary CDNs. The dCDN
formats internally all the final logging files, including those
received from intermediary CDNs and the files locally generated. The
dCDN then sends all required logging files to the uCDN [LI-3].
The ATOM feed allows the uCDN to trigger the download of logging
files whenever needed [LI-4].
The uCDN can pull logging files from the dCDN whenever a new file is
available. The timing constraints for the generation of the logging
files are to be defined offline, since the CDNI Logging Interface
does not include a negotiation mechanism for the frequency of logging
file generation. Note that the current version of this document
refers strictly to non real-time logging [LI-5].
Section Section 3.4 describes the CDNI Logging Records and the
possible fields that can be included in a record [LI-6].
As a transport mechanism, the CDNI Logging Interface uses the ATOM
protocol over HTTP (or HTTPS) [LI-7].
A CDN can query another CDN for relevant current logging files by
using the ATOM feed that allows to check for newly published content.
Note that the current version of this document refers strictly to non
real-time logging [LI-8].
The current version of the document does not specify any mechanisms
for producing aggregate / summarized logs, but the exchanged logging
files provide all information that is necessary to the uCDN in order
to obtain aggregated logs. Future versions might include such
mechanisms [LI-9].
No logging of performance data or consumed resources for the dCDN
itself or any other cascaded CDN is included in the current version
of the document. Future versions of this document might define such
information [LI-10, LI-11, LI-12].
The current version of the document specifies the logging information
related strictly to the delivery process. Logging files for any
other functionalities (e.g., content purge, request routing events
etc.) might be taken into account in future versions [LI-13].
Extensibility, the logging and exchange of proprietary information
fields are detailed in Section 6 IANA Considerations [LI-14, LI-15].
The ATOM protocol allows the dCDN to publish the list of available
resources (i.e. logging files) [LI-16].
Section 3.4 provides details about the fields of the HTTP Adaptive
Streaming specific logging records, including the Content Collection
Identifier (s-ccid) and Session Identifier (s-sid) [LI-17].
A.1.3. Security requirements
[SEC-3, SEC-5] are not applicable to the CDNI Loggin Interface, all
remaining security requirements are addressed as discussed in
Section 7.
A.2. Considerations on CDNI Logging Applicability
This section discusses a number of considerations related to the
applicability of the CDNI Logging interface as specified in the
present document.
[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?]
A.2.1. Timeliness A.2.1. Timeliness
Some applications consuming CDNI Logging information, such as Some applications consuming CDNI Logging information, such as
accounting or trend analytics, only require logging information to be accounting or trend analytics, only require logging information to be
available with a timeliness of the order of a day or the hour. This available with a timeliness of the order of a day or the hour. This
document focuses on addressing this requirement. document focuses on addressing this requirement.
skipping to change at page 40, line 29 skipping to change at page 44, line 5
possible to intra-CDN logging format commonly used in CDNs today in possible to intra-CDN logging format commonly used in CDNs today in
order to minimize systematic translation at CDN/CDNI boundary. order to minimize systematic translation at CDN/CDNI boundary.
A.2.6. Dispatching/Filtering A.2.6. Dispatching/Filtering
When a CDN is acting as a dCDN for multiple uCDNs, the dCDN needs to When a CDN is acting as a dCDN for multiple uCDNs, the dCDN needs to
dispatch each CDNI Logging Record to the uCDN that redirected the dispatch each CDNI Logging Record to the uCDN that redirected the
corresponding request. The CDNI Logging format need to allow, and corresponding request. The CDNI Logging format need to allow, and
possibly facilitate, such a dispatching. possibly facilitate, such a dispatching.
Appendix B. Analysis of candidate protocols for Logging Transport Authors' Addresses
This section will be expanded later with an analysis of alternative
candidate protocols for transport of CDNI Logging in non-real-time as
well as real-time.
B.1. Syslog
[Ed. node: to be written later]
B.2. XMPP
[Ed. node: to be written later] Francois Le Faucheur (editor)
Cisco Systems
E.Space Park - Batiment D
6254 Allee des Ormes - BP 1200
Mougins cedex 06254
FR
B.3. SNMP Phone: +33 4 97 23 26 19
Email: flefauch@cisco.com
Authors' Addresses
Gilles Bertrand (editor) Gilles Bertrand (editor)
France Telecom - Orange Orange
38-40 rue du General Leclerc 38-40 rue du General Leclerc
Issy les Moulineaux 92130 Issy les Moulineaux 92130
FR FR
Phone: +33 1 45 29 89 46 Phone: +33 1 45 29 89 46
Email: gilles.bertrand@orange.com Email: gilles.bertrand@orange.com
Iuniana Oprescu (editor) Iuniana Oprescu (editor)
France Telecom - Orange Orange
38-40 rue du General Leclerc 38-40 rue du General Leclerc
Issy les Moulineaux 92130 Issy les Moulineaux 92130
FR FR
Phone: +33 6 89 06 92 72 Phone: +33 6 89 06 92 72
Email: iuniana.oprescu@orange.com Email: iuniana.oprescu@orange.com
Francois Le Faucheur (editor)
Cisco Systems
E.Space Park - Batiment D
6254 Allee des Ormes - BP 1200
Mougins cedex 06254
FR
Phone: +33 4 97 23 26 19
Email: flefauch@cisco.com
Roy Peterkofsky Roy Peterkofsky
Skytide, Inc. Skytide, Inc.
One Kaiser Plaza, Suite 785 One Kaiser Plaza, Suite 785
Oakland CA 94612 Oakland CA 94612
USA USA
Phone: +01 510 250 4284 Phone: +01 510 250 4284
Email: roy@skytide.com Email: roy@skytide.com
 End of changes. 89 change blocks. 
257 lines changed or deleted 403 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/