draft-ietf-cdni-logging-13.txt   draft-ietf-cdni-logging-14.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 25, 2015 I. Oprescu, Ed. Expires: April 28, 2015 I. Oprescu, Ed.
Orange Orange
R. Peterkofsky R. Peterkofsky
Skytide, Inc. Skytide, Inc.
July 24, 2014 October 25, 2014
CDNI Logging Interface CDNI Logging Interface
draft-ietf-cdni-logging-13 draft-ietf-cdni-logging-14
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 25, 2015. This Internet-Draft will expire on April 28, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 3, line 13 skipping to change at page 3, line 13
6.4. CDNI Logging MIME Media Type . . . . . . . . . . . . . . 46 6.4. CDNI Logging MIME Media Type . . . . . . . . . . . . . . 46
7. Security Considerations . . . . . . . . . . . . . . . . . . . 46 7. Security Considerations . . . . . . . . . . . . . . . . . . . 46
7.1. Authentication, Confidentiality, Integrity Protection . . 46 7.1. Authentication, Confidentiality, Integrity Protection . . 46
7.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 47 7.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 47
7.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 47 7.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 47
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 48
9.1. Normative References . . . . . . . . . . . . . . . . . . 48 9.1. Normative References . . . . . . . . . . . . . . . . . . 48
9.2. Informative References . . . . . . . . . . . . . . . . . 49 9.2. Informative References . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
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:
o CDNI problem statement [RFC6707] and framework o CDNI problem statement [RFC6707] and framework [RFC7336] identify
[I-D.ietf-cdni-framework] identify a Logging interface, a Logging interface,
o Section 8 of [I-D.ietf-cdni-requirements] specifies a set of o Section 8 of [RFC7337] specifies a set of requirements for
requirements for Logging, Logging,
o [RFC6770] outlines real world use-cases for interconnecting CDNs. o [RFC6770] outlines real world use-cases for interconnecting CDNs.
These use cases require the exchange of Logging information These use cases require the exchange of Logging information
between the dCDN and the uCDN. between the dCDN and the uCDN.
As stated in [RFC6707], "the CDNI Logging interface enables details As stated in [RFC6707], "the CDNI Logging interface enables details
of logs or events to be exchanged between interconnected CDNs". of logs or events to be exchanged between interconnected CDNs".
The present document describes: The present document describes:
o The CDNI Logging reference model (Section 2), o The CDNI Logging reference model (Section 2),
o The CDNI Logging File format (Section 3), o The CDNI Logging File format (Section 3),
o The CDNI Logging File Exchange protocol (Section 4). o The CDNI Logging File Exchange protocol (Section 4).
1.1. Terminology 1.1. Terminology
In this document, the first letter of each CDNI-specific term is In this document, the first letter of each CDNI-specific term is
capitalized. We adopt the terminology described in [RFC6707] and capitalized. We adopt the terminology described in [RFC6707] and
[I-D.ietf-cdni-framework], and extend it with the additional terms [RFC7336], and extend it with the additional terms defined below.
defined below.
Intra-CDN Logging information: logging information generated and Intra-CDN Logging information: logging information generated and
collected within a CDN. The format of the Intra-CDN Logging collected within a CDN. The format of the Intra-CDN Logging
information may be different to the format of the CDNI Logging information may be different to the format of the CDNI Logging
information. information.
CDNI Logging information: logging information exchanged across CDNs CDNI Logging information: logging information exchanged across CDNs
using the CDNI Logging Interface. using the CDNI Logging Interface.
Logging information: logging information generated and collected Logging information: logging information generated and collected
within a CDN or obtained from another CDN using the CDNI Logging within a CDN or obtained from another CDN using the CDNI Logging
Interface. Interface.
CDNI Logging Field: an atomic element of information that can be CDNI Logging Field: an atomic element of information that can be
included in a CDNI Logging Record. The time an event/task started, included in a CDNI Logging Record. The time an event/task started,
the IP address of an End User to whom content was delivered, and the the IP address of an End User to whom content was delivered, and the
URI of the content delivered are examples of CDNI Logging Fields. Uniform Resource Identifier (URI) of the content delivered, are
examples of CDNI Logging Fields.
CDNI Logging Record: an information record providing information CDNI Logging Record: an information record providing information
about a specific event. This comprises a collection of CDNI Logging about a specific event. This comprises a collection of CDNI Logging
Fields. Fields.
CDNI Logging File: a file containing CDNI Logging Records, as well as CDNI Logging File: a file containing CDNI Logging Records, as well as
additional information facilitating the processing of the CDNI additional information facilitating the processing of the CDNI
Logging Records. Logging Records.
CDN Reporting: the process of providing the relevant information that CDN Reporting: the process of providing the relevant information that
skipping to change at page 9, line 20 skipping to change at page 9, line 20
^ ^
| |
Filtering Filtering
^ ^
| |
Collection Collection
^ ^ ^ ^
| | | |
| Generation | Generation
| |
| uCDN | uCDN
CDNI Logging ------------------------------------------------------- CDNI Logging ---------------------------------------------------
exchange dCDN exchange dCDN
^ ^
| Log Consuming Log Consuming | Log Consuming Log Consuming
| App App | App App
| ^ ^ | ^ ^
| | | | | |
Rectification Rectification--------- Rectification Rectification---------
^ ^ ^ ^
| | | |
Filtering Filtering
^ ^
skipping to change at page 23, line 51 skipping to change at page 23, line 51
<CDNI Logging Record> = FIEVAL *<HTAB FIEVAL> ; where FIEVAL <CDNI Logging Record> = FIEVAL *<HTAB FIEVAL> ; where FIEVAL
contains the CDNI Logging field value corresponding to the CDNI contains the CDNI Logging field value corresponding to the CDNI
Logging field names (FIENAME) listed is the last Fields directive Logging field names (FIENAME) listed is the last Fields directive
preceding the present CDNI Logging Record. preceding the present CDNI Logging Record.
3.4.1. HTTP Request Logging Record 3.4.1. HTTP Request Logging Record
This section defines the CDNI Logging Record of Record-Type This section defines the CDNI Logging Record of Record-Type
"cdni_http_request_v1". It is applicable to content delivery "cdni_http_request_v1". It is applicable to content delivery
performed by the dCDN using HTTP/1.0([RFC1945]), HTTP/1.1([RFC2616]) performed by the dCDN using HTTP/1.0([RFC1945]),
or HTTPS ([RFC2818]). We observe that, in the case of HTTPS HTTP/1.1([RFC7230],[RFC7231], [RFC7232], [RFC7233], [RFC7234],
delivery, there may be value in logging additional information
specific to the operation of HTTP over TLS and we note that this is [RFC7235]) or HTTPS ([RFC2818], [RFC7230]). We observe that, in the
outside the scope of the present document and may be addressed in a case of HTTPS delivery, there may be value in logging additional
future document defining another CDNI Logging Record or another information specific to the operation of HTTP over TLS and we note
version of the HTTP Request Logging Record. that this is outside the scope of the present document and may be
addressed in a future document defining another CDNI Logging Record
or another version of the HTTP Request Logging Record.
The "cdni_http_request_v1" Record-Type is also expected to be The "cdni_http_request_v1" Record-Type is also expected to be
applicable to HTTP/2.0 [I-D.ietf-httpbis-http2] (which is still under applicable to HTTP/2.0 [I-D.ietf-httpbis-http2] (which is still under
development at the time of writing the present document) since a development at the time of writing the present document) since a
fundamental design tenet of HTTP/2.0 is to preserve the HTTP/1.1 fundamental design tenet of HTTP/2.0 is to preserve the HTTP/1.1
semantics. We observe that, in the case of HTTP/2.0 delivery, there semantics. We observe that, in the case of HTTP/2.0 delivery, there
may be value in logging additional information specific to the may be value in logging additional information specific to the
additional functionality of HTTP/2.0 (e.g. information related to additional functionality of HTTP/2.0 (e.g. information related to
connection identification, to stream identification, to stream connection identification, to stream identification, to stream
priority and to flow control). We note that such additional priority and to flow control). We note that such additional
skipping to change at page 26, line 43 skipping to change at page 26, line 43
Surrogate. In the case of HTTP delivery, this is the HTTP Surrogate. In the case of HTTP delivery, this is the HTTP
method in the request. method in the request.
* occurrence: There MUST be one and only one instance of this * occurrence: There MUST be one and only one instance of this
field. field.
o cs-uri: o cs-uri:
* format: NHTABSTRING * format: NHTABSTRING
* field value: this is the complete URL of the request received * field value: this is the "effective request URI" of the request
by the Surrogate. It is exactly in the format of a http_URL received by the Surrogate as specified in [RFC7230]. It
specified in [RFC2616]) or, when the request was a HTTPS complies with the "http" URI scheme or the "https" URI scheme
request ([RFC2818]), it is in the format of a http_URL but with as specified in [RFC7230]).
the scheme part set to "https" instead of "http".
* 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 u-uri: o u-uri:
* format: NHTABSTRING * format: NHTABSTRING
* field value: this is a complete URL, derived from the complete * field value: this is a complete URI, derived from the
URI of the request received by the Surrogate (i.e., the cs-uri) "effective request URI" ([RFC7230]) of the request received by
but transformed by the entity generating or transmitting the the Surrogate (i.e., the cs-uri) but transformed by the entity
CDNI Logging Record, in a way that is agreed upon between the generating or transmitting the CDNI Logging Record, in a way
two ends of the CDNI Logging interface, so the transformed URI that is agreed upon between the two ends of the CDNI Logging
is meaningful to the uCDN. For example, the two ends of the interface, so the transformed URI is meaningful to the uCDN.
CDNI Logging interface could agree that the u-uri is For example, the two ends of the CDNI Logging interface could
constructed from the cs-uri by removing the part of the agree that the u-uri is constructed from the cs-uri by removing
hostname that exposes which individual Surrogate actually the part of the hostname that exposes which individual
performed the delivery. The details of modification performed Surrogate actually performed the delivery. The details of
to generate the u-uri, as well as the mechanism to agree on modification performed to generate the u-uri, as well as the
these modifications between the two sides of the CDNI Logging mechanism to agree on these modifications between the two sides
interface are outside the scope of the present document. of the CDNI Logging interface are outside the scope of 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
field. field.
o protocol: o protocol:
* format: NHTABSTRING * format: NHTABSTRING
* field value: this is value of the HTTP-Version field as * field value: this is value of the HTTP-Version field as
specified in [RFC2616] of the Request-Line of the request specified in [RFC7230] of the Request-Line of the request
received by the Surrogate (e.g., "HTTP/1.1"). received by the Surrogate (e.g., "HTTP/1.1").
* occurrence: there MUST be one and only one instance of this * occurrence: there MUST be one and only one instance of this
field. field.
o sc-status: o sc-status:
* format: 3DIGIT * format: 3DIGIT
* field value: this is the Status-Code in the response from the * field value: this is the Status-Code in the response from the
skipping to change at page 41, line 12 skipping to change at page 41, line 12
Figure 7: Example subscription document of a CDNI Logging Feed Figure 7: 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 MAY pull,
at its convenience, a 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 (in the subscription document or server-side in the CDNI Logging Feed (in the subscription document or
an archive document). To do so, the client-side: an archive document). To do so, the client-side:
o MUST implement HTTP/1.1 [RFC2616], MAY also support other HTTP o MUST implement HTTP/1.1 ([RFC7230],[RFC7231], [RFC7232],
[RFC7233], [RFC7234], [RFC7235]), MAY also support other HTTP
versions (e.g., HTTP/2.0 [I-D.ietf-httpbis-http2]) and MAY versions (e.g., HTTP/2.0 [I-D.ietf-httpbis-http2]) and MAY
negotiate which HTTP version is actually used. This allows negotiate which HTTP version is actually used. This allows
operators and implementers to choose to use later versions of HTTP operators and implementers to choose to use later versions of HTTP
to take advantage of new features, while still ensuring to take advantage of new features, while still ensuring
interoperability with systems that only support HTTP/1.1. interoperability with systems that only support HTTP/1.1.
o MUST use the URI that was associated to the CDNI Logging File o MUST use the URI that was associated to the CDNI Logging File
(within the "src" attribute of the corresponding atom:content (within the "src" attribute of the corresponding atom:content
element) in the CDNI Logging Feed; element) in the CDNI Logging Feed;
o MUST support exchange of CDNI Logging Files with no content o MUST support exchange of CDNI Logging Files with no content
encoding applied to the representation; encoding applied to the representation;
o MUST support exchange of CDNI Logging Files with "gzip" content o MUST support exchange of CDNI Logging Files with "gzip" content
encoding (as defined in [RFC2616]) applied to the representation. encoding (as defined in [RFC7230]) applied to the representation.
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. MAY pull a CDNI Logging File that it has already pulled.
The server-side implementation MUST respond to valid pull request by The server-side implementation MUST respond to valid pull request by
a client-side implementation for a CDNI Logging File published by the a client-side implementation for a CDNI Logging File published by the
server-side in the CDNI Logging Feed (in the subscription document or server-side in the CDNI Logging Feed (in the subscription document or
an archive document). The server-side implementation: an archive document). The server-side implementation:
o MUST implement HTTP/1.1 to handle the client-side request and MAY o MUST implement HTTP/1.1 to handle the client-side request and MAY
also support other HTTP versions (e.g., HTTP/2.0); also support other HTTP versions (e.g., HTTP/2.0);
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 exchange of CDNI Logging Files with no content o MUST support exchange of CDNI Logging Files with no content
encoding applied to the representation; encoding applied to the representation;
o MUST support exchange of CDNI Logging Files with "gzip" content o MUST support exchange of CDNI Logging Files with "gzip" content
encoding (as defined in [RFC2616]) applied to the representation. encoding (as defined in [RFC7231]) applied to the representation.
Content negotiation approaches defined in [RFC2616] (e.g., using Content negotiation approaches defined in [RFC7231] (e.g., using
Accept-Encoding request-header field or Content-Encoding entity- Accept-Encoding request-header field or Content-Encoding entity-
header field) MAY be used by the client-side and server-side header field) MAY be used by the client-side and server-side
implementations to establish the content-coding to be used for a implementations to establish the content-coding to be used for a
particular exchange of a CDNI Logging File. particular exchange of a CDNI Logging File.
Applying compression content encoding (such as "gzip") is expected to Applying compression content encoding (such as "gzip") is expected to
mitigate the impact of exchanging the large volumes of logging mitigate the impact of exchanging the large volumes of logging
information expected across CDNs. This is expected to be information expected across CDNs. This is expected to be
particularly useful in the presence of HTTP Adaptive Streaming (HAS) particularly useful in the presence of HTTP Adaptive Streaming (HAS)
which, as per the present version of the document, will result in a which, as per the present version of the document, will result in a
skipping to change at page 43, line 16 skipping to change at page 43, line 16
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 |
| Established-Origin | RFC xxxx | | Established-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 |
+------------------------------+-----------+ +------------------------------+-----------+
Figure 8 Figure 8
[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].
Directive names are to be allocated by IANA with a format of Directive names are to be allocated by IANA with a format of
NAMEFORMAT (see Section 3.1). NAMEFORMAT (see Section 3.1).
skipping to change at page 44, line 5 skipping to change at page 44, line 5
6.2. CDNI Logging Record-Types 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:
+------------------------------+-----------+----------------------------------+ +----------------------+-----------+----------------------------------+
| Record-Types | Reference | Description | | Record-Types | Reference | Description |
+------------------------------+-----------+----------------------------------+ +----------------------+-----------+----------------------------------+
| cdni_http_request_v1 | RFC xxxx | CDNI Logging Record version 1 | | cdni_http_request_v1 | RFC xxxx | CDNI Logging Record version 1 |
| | | for content delivery using HTTP | | | | for content delivery using HTTP |
+------------------------------+-----------+----------------------------------+ +----------------------+-----------+----------------------------------+
Figure 9 Figure 9
[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]. Record-Types are to be allocated by IANA with a format of [RFC5226]. Record-Types are to be allocated by IANA with a format of
NAMEFORMAT (see Section 3.1). Record-Types corresponding to NAMEFORMAT (see Section 3.1). Record-Types corresponding to
skipping to change at page 45, line 14 skipping to change at page 45, line 14
are not strictly identical, or a format that is not strictly are not strictly identical, or a format that is not strictly
identical then this new Field is to be registered in the registry identical then this new Field is to be registered in the registry
with a different Field name. When a Field from this registry is used with a different Field name. When a Field from this registry is used
by another CDNI Logging Record-Type, it can be used with different by another CDNI Logging Record-Type, it can be used with different
occurence rules. occurence rules.
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 |
+---------------------------------------------+-----------+ +------------------------------------------+-----------+
| 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-anonymizing | RFC xxxx | | c-ip-anonymizing | 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 |
+---------------------------------------------+-----------+ +------------------------------------------+-----------+
Figure 10 Figure 10
[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]. Field the "Specification Required" policy specified in [RFC5226]. Field
names are to be allocated by IANA with a format of NHTABSTRING (see names are to be allocated by IANA with a format of NHTABSTRING (see
Section 3.1). Section 3.1).
skipping to change at page 46, line 17 skipping to change at page 46, line 17
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 7. Security Considerations
7.1. Authentication, Confidentiality, Integrity Protection 7.1. Authentication, Confidentiality, Integrity Protection
An implementation of the CDNI Logging interface MUST support TLS An implementation of the CDNI Logging interface MUST support TLS
transport of the CDNI Logging feed (Section 4.1) and of the CDNI transport of the CDNI Logging feed (Section 4.1) and of the CDNI
Logging File pull (Section 4.2) as per [RFC2818]. Logging File pull (Section 4.2) as per [RFC2818] and [RFC7230].
The use of TLS for transport of the CDNI Logging feed and CDNI The use of TLS for transport of the CDNI Logging feed and CDNI
Logging File pull allows: Logging File pull 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
skipping to change at page 47, line 37 skipping to change at page 47, line 37
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. concerns.
The use of TLS for transport of the CDNI Logging feed and CDNI The use of TLS for transport of the CDNI Logging feed and CDNI
Logging pull as discussed in Section 7.1 protects the confidentiality Logging pull as discussed in Section 7.1 protects the confidentiality
of logged information by preventing any other party than the of logged information by preventing any other party than the
authorised uCDN to gain access to the logging information. authorised uCDN to gain access to the logging information.
We observe that when CDNI interconnection is realised as per We observe that when CDNI interconnection is realised as per
[I-D.ietf-cdni-framework], the uCDN handles the initial End User [RFC7336], the uCDN handles the initial End User requests (before it
requests (before it is redirected to the dCDN) so, regardless of is redirected to the dCDN) so, regardless of which information is, or
which information is, or is not, communicated to the uCDN through the is not, communicated to the uCDN through the CDNI Logging interface,
CDNI Logging interface, the uCDN has visibility on significant the uCDN has visibility on significant information such as the IP
information such as the IP address of the End User request and the address of the End User request and the URL of the request.
URL of the request.
Nonetheless, if the dCDN and uCDN agree that anonymization is Nonetheless, if the dCDN and uCDN agree that anonymization is
required to avoid making some detailed information available to the required to avoid making some detailed information available to the
uCDN (such as how many bytes of the content have been watched by an uCDN (such as how many bytes of the content have been watched by an
End User and/or at what time) or is required to meet some legal End User and/or at what time) or is required to meet some legal
obligations, then the uCDN and dCDN can agree to exchange anonymized obligations, then the uCDN and dCDN can agree to exchange anonymized
End Users IP address in CDNI Logging Files and the c-ip-anonymization End Users IP address in CDNI Logging Files and the c-ip-anonymization
field can be used to convey the number of bits that have been field can be used to convey the number of bits that have been
anonymized so that the meaningful information can still be easily anonymized so that the meaningful information can still be easily
extracted from the anonymized addressses (e.g., for geolocation aware extracted from the anonymized addressses (e.g., for geolocation aware
skipping to change at page 48, line 47 skipping to change at page 48, line 47
contributors of the EU FP7 OCEAN project for their input in the early contributors of the EU FP7 OCEAN project for their input in the early
versions of this document. versions of this document.
9. References 9. References
9.1. Normative References 9.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.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
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
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 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
Syndication Format", RFC 4287, December 2005. Syndication Format", RFC 4287, December 2005.
skipping to change at page 49, line 30 skipping to change at page 49, line 26
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.
[RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
August 2008. August 2008.
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing", RFC 7230, June
2014.
[RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Semantics and Content", RFC 7231, June 2014.
[RFC7232] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Conditional Requests", RFC 7232, June 2014.
[RFC7233] Fielding, R., Lafon, Y., and J. Reschke, "Hypertext
Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233,
June 2014.
[RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext
Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June
2014.
[RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Authentication", RFC 7235, June 2014.
9.2. Informative References 9.2. Informative References
[CHAR_SET] [CHAR_SET]
"IANA Character Sets registry", "IANA Character Sets registry",
<http://www.iana.org/assignments/character-sets/ <http://www.iana.org/assignments/character-sets/
character-sets.xml>. character-sets.xml>.
[ELF] Phillip M. Hallam-Baker, and Brian Behlendorf, "Extended [ELF] Phillip M. Hallam-Baker, and Brian Behlendorf, "Extended
Log File Format, W3C (work in progress), WD-logfile- Log File Format, W3C (work in progress), WD-logfile-
960323", <http://www.w3.org/TR/WD-logfile.html>. 960323", <http://www.w3.org/TR/WD-logfile.html>.
[I-D.ietf-cdni-framework]
Peterson, L., Davie, B., and R. Brandenburg, "Framework
for CDN Interconnection", draft-ietf-cdni-framework-14
(work in progress), June 2014.
[I-D.ietf-cdni-metadata] [I-D.ietf-cdni-metadata]
Niven-Jenkins, B., Murray, R., Caulfield, M., Leung, K., Niven-Jenkins, B., Murray, R., Caulfield, M., Leung, K.,
and K. Ma, "CDN Interconnection Metadata", draft-ietf- and K. Ma, "CDN Interconnection Metadata", draft-ietf-
cdni-metadata-07 (work in progress), July 2014. cdni-metadata-07 (work in progress), July 2014.
[I-D.ietf-cdni-requirements]
Leung, K. and Y. Lee, "Content Distribution Network
Interconnection (CDNI) Requirements", draft-ietf-cdni-
requirements-17 (work in progress), January 2014.
[I-D.ietf-httpbis-http2] [I-D.ietf-httpbis-http2]
Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer
Protocol version 2", draft-ietf-httpbis-http2-13 (work in Protocol version 2", draft-ietf-httpbis-http2-14 (work in
progress), June 2014. progress), July 2014.
[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.
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
skipping to change at page 50, line 43 skipping to change at page 50, line 47
[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., [RFC6983] van Brandenburg, R., van Deventer, O., Le Faucheur, F.,
and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware
Content Distribution Network Interconnection (CDNI)", RFC Content Distribution Network Interconnection (CDNI)", RFC
6983, July 2013. 6983, July 2013.
[RFC7336] Peterson, L., Davie, B., and R. van Brandenburg,
"Framework for Content Distribution Network
Interconnection (CDNI)", RFC 7336, August 2014.
[RFC7337] Leung, K. and Y. Lee, "Content Distribution Network
Interconnection (CDNI) Requirements", RFC 7337, August
2014.
Authors' Addresses Authors' Addresses
Francois Le Faucheur (editor) Francois Le Faucheur (editor)
Cisco Systems Cisco Systems
E.Space Park - Batiment D E.Space Park - Batiment D
6254 Allee des Ormes - BP 1200 6254 Allee des Ormes - BP 1200
Mougins cedex 06254 Mougins cedex 06254
FR FR
Phone: +33 4 97 23 26 19 Phone: +33 4 97 23 26 19
Email: flefauch@cisco.com Email: flefauch@cisco.com
 End of changes. 30 change blocks. 
110 lines changed or deleted 128 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/