draft-ietf-cdni-logging-19.txt   draft-ietf-cdni-logging-20.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 5, 2016 I. Oprescu, Ed. Expires: April 18, 2016 I. Oprescu, Ed.
Orange Orange
R. Peterkofsky R. Peterkofsky
Skytide, Inc. Skytide, Inc.
July 4, 2015 October 16, 2015
CDNI Logging Interface CDNI Logging Interface
draft-ietf-cdni-logging-19 draft-ietf-cdni-logging-20
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 line 38 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 5, 2016. This Internet-Draft will expire on April 18, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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.
Table of Contents Table of Contents
1. Introduction 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. CDNI Logging Reference Model 2. CDNI Logging Reference Model . . . . . . . . . . . . . . . . 5
2.1. CDNI Logging interactions 2.1. CDNI Logging interactions . . . . . . . . . . . . . . . . 5
2.2. Overall Logging Chain 2.2. Overall Logging Chain . . . . . . . . . . . . . . . . . . 8
2.2.1. Logging Generation and During-Generation Aggregation 2.2.1. Logging Generation and During-Generation Aggregation 9
2.2.2. Logging Collection 2.2.2. Logging Collection . . . . . . . . . . . . . . . . . 10
2.2.3. Logging Filtering 2.2.3. Logging Filtering . . . . . . . . . . . . . . . . . . 10
2.2.4. Logging Rectification and Post-Generation Aggregation 2.2.4. Logging Rectification and Post-Generation Aggregation 11
2.2.5. Log-Consuming Applications 2.2.5. Log-Consuming Applications . . . . . . . . . . . . . 12
2.2.5.1. Maintenance/Debugging 2.2.5.1. Maintenance/Debugging . . . . . . . . . . . . . . 12
2.2.5.2. Accounting 2.2.5.2. Accounting . . . . . . . . . . . . . . . . . . . 13
2.2.5.3. Analytics and Reporting 2.2.5.3. Analytics and Reporting . . . . . . . . . . . . . 13
2.2.5.4. Content Protection 2.2.5.4. Content Protection . . . . . . . . . . . . . . . 13
2.2.5.5. Notions common to multiple Log Consuming 2.2.5.5. Notions common to multiple Log Consuming
Applications Applications . . . . . . . . . . . . . . . . . . 14
3. CDNI Logging File 3. CDNI Logging File . . . . . . . . . . . . . . . . . . . . . . 16
3.1. Rules 3.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2. CDNI Logging File Structure 3.2. CDNI Logging File Structure . . . . . . . . . . . . . . . 17
3.3. CDNI Logging Directives 3.3. CDNI Logging Directives . . . . . . . . . . . . . . . . . 20
3.4. CDNI Logging Records 3.4. CDNI Logging Records . . . . . . . . . . . . . . . . . . 24
3.4.1. HTTP Request Logging Record 3.4.1. HTTP Request Logging Record . . . . . . . . . . . . . 25
3.5. CDNI Logging File Example 3.5. CDNI Logging File Example . . . . . . . . . . . . . . . . 35
3.6. Cascaded CDNI Logging Files Example 3.6. Cascaded CDNI Logging Files Example . . . . . . . . . . . 37
4. Protocol for Exchange of CDNI Logging File After Full 4. Protocol for Exchange of CDNI Logging File After Full
Collection Collection . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.1. CDNI Logging Feed 4.1. CDNI Logging Feed . . . . . . . . . . . . . . . . . . . . 41
4.1.1. Atom Formatting 4.1.1. Atom Formatting . . . . . . . . . . . . . . . . . . . 41
4.1.2. Updates to Log Files and the Feed 4.1.2. Updates to Log Files and the Feed . . . . . . . . . . 41
4.1.3. Redundant Feeds 4.1.3. Redundant Feeds . . . . . . . . . . . . . . . . . . . 42
4.1.4. Example CDNI Logging Feed 4.1.4. Example CDNI Logging Feed . . . . . . . . . . . . . . 42
4.2. CDNI Logging File Pull 4.2. CDNI Logging File Pull . . . . . . . . . . . . . . . . . 44
5. Protocol for Exchange of CDNI Logging File During Collection 5. Protocol for Exchange of CDNI Logging File During Collection 45
6. IANA Considerations 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
6.1. CDNI Logging Directive Names Registry 6.1. CDNI Logging Directive Names Registry . . . . . . . . . . 46
6.2. CDNI Logging File version Registry 6.2. CDNI Logging File version Registry . . . . . . . . . . . 47
6.3. CDNI Logging record-types Registry 6.3. CDNI Logging record-types Registry . . . . . . . . . . . 47
6.4. CDNI Logging Field Names Registry 6.4. CDNI Logging Field Names Registry . . . . . . . . . . . . 48
6.5. CDNI Logging MIME Media Type 6.5. CDNI Logging MIME Media Type . . . . . . . . . . . . . . 49
7. Security Considerations
7. Security Considerations . . . . . . . . . . . . . . . . . . . 50
7.1. Authentication, Authorization, Confidentiality, Integrity 7.1. Authentication, Authorization, Confidentiality, Integrity
Protection Protection . . . . . . . . . . . . . . . . . . . . . . . 50
7.2. Denial of Service 7.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 51
7.3. Privacy 7.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 51
8. Acknowledgments 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52
9. References 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 53
9.1. Normative References 9.1. Normative References . . . . . . . . . . . . . . . . . . 53
9.2. Informative References 9.2. Informative References . . . . . . . . . . . . . . . . . 54
Authors' Addresses Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56
1. Introduction 1. Introduction
This memo specifies the CDNI Logging interface between a downstream This memo specifies the CDNI Logging interface between a downstream
CDN (dCDN) and an upstream CDN (uCDN). First, it describes a CDN (dCDN) and an upstream CDN (uCDN). First, it describes a
reference model for CDNI logging. Then, it specifies the CDNI reference model for CDNI logging. Then, it specifies the CDNI
Logging File format and the actual protocol for exchange of CDNI Logging File format and the actual protocol for exchange of CDNI
Logging Files. Logging Files.
The reader should be familiar with the following documents: The reader should be familiar with the following documents:
skipping to change at line 191 skipping to change at page 4, line 51
corresponding deliveries. Monitoring typically includes visibility corresponding deliveries. Monitoring typically includes visibility
of the deliveries in progress for service operation purposes. It of the deliveries in progress for service operation purposes. It
presents a view of the global health of the services as well as presents a view of the global health of the services as well as
information on usage and performance, for network services information on usage and performance, for network services
supervision and operation management. In particular, monitoring data supervision and operation management. In particular, monitoring data
can be used to generate alarms. can be used to generate alarms.
1.2. Requirements Language 1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "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 CDNI provided by the dCDN to the uCDN (e.g., control of which CDNI
skipping to change at line 530 skipping to change at page 12, line 38
fails. fails.
Logging information enables the CDN providers to identify and Logging information enables the CDN providers to identify and
troubleshoot performance degradations. In particular, Logging troubleshoot performance degradations. In particular, Logging
information enables tracking of traffic data (e.g., the amount of information enables tracking of traffic data (e.g., the amount of
traffic that has been forwarded by a dCDN on behalf of an uCDN over a traffic that has been forwarded by a dCDN on behalf of an uCDN over a
given period of time), which is particularly useful for CDN and given period of time), which is particularly useful for CDN and
network planning operations. network planning operations.
Some of these maintenance and debugging applications only require Some of these maintenance and debugging applications only require
aggregate logging information highly compatible with anonymization of aggregate logging information highly compatible with use of
IP addresses (as supported by the present document and specified in anonymization of IP addresses (as supported by the present document
and specified in the definition of the c-groupid field under
Section 3.4.1). However, in some situations, it may be useful, where Section 3.4.1). However, in some situations, it may be useful, where
compatible with privacy protection, to access some CDNI Logging compatible with privacy protection, to access some CDNI Logging
Records containing full non-anonymized IP addresses. For example, Records containing full non-anonymized IP addresses. This is allowed
this may be useful for detailed fault tracking of a particular end , in the definition of the c-groupid under Section 3.4.1), with very
user content delivery issue. significant privacy protection limitations that are discussed in the
definition of the c-groupid field. For example, this may be useful
for detailed fault tracking of a particular end user content delivery
issue. Where there is a hard requirement by uCDN or CSP to associate
a given enduser to individual CDNI Logging Records (e.g. to allow
a-posteriori analysis of individual delivery for example in
situations of performance-based penalties), instead of using
aggregates containing a single client as discussed in the c-groupid
field definition, an alternate approach is to ensure that a client
identifier is embedded in the request in request fields that can be
logged in a CDNI Logging Record (for example by including the client
identifier in the URI query string or in a HTTP Header). That latter
approach offers two strong benefits: first, the aggregate inside the
c-groupid can contain more than one client, thereby ensuring stronger
privacy protection; second, it allows a reliable identification of
the client while IP address does not allow accurate identification of
clients in many situations (e.g. behind NAT, where dynamic IP
addresses are used and reused,...). However, care SHOULD then be
taken that the client identifier exposed in other fields of the CDNI
Records cannot themselves be linked back to actual users.
2.2.5.2. Accounting 2.2.5.2. Accounting
Logging information is essential for accounting, to permit inter-CDN Logging information is essential for accounting, to permit inter-CDN
billing and CSP billing by uCDNs. For instance, Logging information billing and CSP billing by uCDNs. For instance, Logging information
provided by dCDNs enables the uCDN to compute the total amount of provided by dCDNs enables the uCDN to compute the total amount of
traffic delivered by every dCDN for a particular Content Provider, as traffic delivered by every dCDN for a particular Content Provider, as
well as, the associated bandwidth usage (e.g., peak, 95th well as, the associated bandwidth usage (e.g., peak, 95th
percentile), and the maximum number of simultaneous sessions over a percentile), and the maximum number of simultaneous sessions over a
given period of time. given period of time.
2.2.5.3. Analytics and Reporting 2.2.5.3. Analytics and Reporting
The goal of analytics is to gather any relevant information to track The goals of analytics include gathering any relevant information in
audience, analyze user behavior, and monitor the performance and order to be able to develop statistics on content download, analyze
quality of content delivery. For instance, Logging information user behavior, and monitor the performance and quality of content
enables the CDN providers to report on content consumption (e.g., delivery. For instance, Logging information enables the CDN
delivered sessions per content) in a specific geographic area. providers to report on content consumption (e.g., delivered sessions
per content) in a specific geographic area.
The goal of reporting is to gather any relevant information to The goal of reporting is to gather any relevant information to
monitor the performance and quality of content delivery and allow monitor the performance and quality of content delivery and allow
detection of delivery issues. For instance, reporting could track detection of delivery issues. For instance, reporting could track
the average delivery throughput experienced by End Users in a given the average delivery throughput experienced by End Users in a given
region for a specific CSP or content set over a period of time. region for a specific CSP or content set over a period of time.
2.2.5.4. Content Protection 2.2.5.4. Content Protection
The goal of content protection is to prevent and monitor unauthorized The goal of content protection is to prevent and monitor unauthorized
skipping to change at line 717 skipping to change at page 17, line 11
DATE = 4DIGIT "-" 2DIGIT "-" 2DIGIT DATE = 4DIGIT "-" 2DIGIT "-" 2DIGIT
; Dates are encoded as "full-date" specified in [RFC3339]. ; Dates are encoded as "full-date" specified in [RFC3339].
DEC = 1*DIGIT ["." *DIGIT] DEC = 1*DIGIT ["." *DIGIT]
NAMEFORMAT = ALPHANUM *(ALPHANUM / "_" / "-") NAMEFORMAT = ALPHANUM *(ALPHANUM / "_" / "-")
QSTRING = DQUOTE *(NDQUOTE / PCT-ENCODED) DQUOTE QSTRING = DQUOTE *(NDQUOTE / PCT-ENCODED) DQUOTE
NDQUOTE = %x21 / %x23-24 / %x26-7E / (DQUOTE DQUOTE) NDQUOTE = %x20-21 / %x23-24 / %x26-7E / UTF8-2 / UTF8-3 / UTF8-4
; whereby a DQUOTE is conveyed inside a QSTRING unambiguously ; whereby a DQUOTE is conveyed inside a QSTRING unambiguously
by escaping it with PCT-ENCODED. by escaping it with PCT-ENCODED.
PCT-ENCODED = "%" HEXDIG HEXDIG PCT-ENCODED = "%" HEXDIG HEXDIG
; percent encoding is used for escaping octets that might be ; percent encoding is used for escaping octets that might be
possible in HTTP headers such as bare CR, bare LF, CR LF, HTAB, possible in HTTP headers such as bare CR, bare LF, CR LF, HTAB,
SP or null. These octets are rendered with percent encoding in SP or null. These octets are rendered with percent encoding in
ABNF as specified by [RFC3986] in order to avoid considering ABNF as specified by [RFC3986] in order to avoid considering
them as separators for the logging records. them as separators for the logging records.
NHTABSTRING = *(SP / VCHAR) NHTABSTRING = 1*(SP / VCHAR)
TIME = 2DIGIT ":" 2DIGIT ":" 2DIGIT ["." *DIGIT] TIME = 2DIGIT ":" 2DIGIT ":" 2DIGIT ["." *DIGIT]
; Times are encoded as "partial-time" specified in [RFC3339]. ; Times are encoded as "partial-time" specified in [RFC3339].
USER-COMMENT = * (SP / VCHAR / UTF8-2 / UTF8-3 / UTF8-4) USER-COMMENT = * (SP / VCHAR / UTF8-2 / UTF8-3 / UTF8-4)
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
skipping to change at line 834 skipping to change at page 19, line 42
logging records. The records group contains zero or more actual logging records. The records group contains zero or more actual
logging record lines about the event being logged. A record line logging record lines about the event being logged. A record line
consists of the values corresponding to all or a subset of the consists of the values corresponding to all or a subset of the
possible Logging fields defined within the scope of the record-type possible Logging fields defined within the scope of the record-type
directive. These values MUST appear in the order defined by the directive. These values MUST appear in the order defined by the
fields directive. fields directive.
Note that future extensions MUST be compliant with the previous Note that future extensions MUST be compliant with the previous
description. The following examples depict the structure of a description. The following examples depict the structure of a
CDNILOGFILE as defined currently by the record-type CDNILOGFILE as defined currently by the record-type
"cdni_http_request_v1." The record line in this example enumerates "cdni_http_request_v1."
strictly what is presently defined in the fields directive of the
record-type "cdni_http_request_v1."
DIRLINE = "#" directive CRLF DIRLINE = "#" directive CRLF
DIRGROUP = 1*DIRLINE DIRGROUP = 1*DIRLINE
RECLINE = 1* ([date HTAB] [time HTAB] [time-taken HTAB] [c-ip RECLINE = any subset of record values that match what is expected
HTAB] [c-ip-anonymizing HTAB] [c-port HTAB] [s-ip HTAB] according to the fields directive within the immediately preceding
[s-hostname HTAB] [s-port HTAB] [cs-method HTAB] [cs-uri HTAB] DIRGROUP.
[u-uri HTAB] [protocol HTAB] [sc-status HTAB] [sc-total-bytes
HTAB] [sc-entity-bytes HTAB] [cs(insert_HTTP_header_name_here)
HTAB] [sc(insert_HTTP_header_name_here) HTAB] [s-ccid HTAB]
[s-sid HATB] [s-cached HTAB]) CRLF
RECGROUP = *RECLINE RECGROUP = *RECLINE
CDNILOGFILE = 1*(DIRGROUP RECGROUP) CDNILOGFILE = 1*(DIRGROUP RECGROUP)
All directive names and field names defined in the logging file are All directive names and field names defined in the logging file are
case-insensitive as per the basic ABNF([RFC2234]). case-insensitive as per the basic ABNF([RFC5234]).
3.3. CDNI Logging Directives 3.3. CDNI Logging Directives
A CDNI Logging directive line contains the directive name followed by A CDNI Logging directive line contains the directive name followed by
":" HTAB and the directive value. ":" HTAB and the directive value.
Directive names MUST be of the format NAMEFORMAT. All directive Directive names MUST be of the format NAMEFORMAT. All directive
names MUST be registered in the CDNI Logging Directives Names names MUST be registered in the CDNI Logging Directives Names
registry. Unknown directives MUST be ignored. Directive values can registry. Unknown directives MUST be ignored. Directive values can
have various formats. All possible directive values for the record- have various formats. All possible directive values for the record-
skipping to change at line 1173 skipping to change at page 26, line 40
* format: DEC * format: DEC
* field value: decimal value of the duration, in seconds, between * field value: decimal value of the duration, in seconds, between
the start of the processing of the request and the completion the start of the processing of the request and the completion
of the request processing (e.g., completion of delivery) by the of the request processing (e.g., completion of delivery) by the
Surrogate. Surrogate.
* 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 c-ip: o c-groupid:
* format: ADDRESS
* field value: the source IPv4 or IPv6 address (i.e., the
"client" address) in the request received by the Surrogate.
* occurrence: there MUST be one and only one instance of this
field.
o c-ip-anonymizing:
* format: 1*DIGIT
* field value: the number of rightmost bits of the address in the
c-ip field that are zeroed-out in order to anonymize the
logging record. The mechanism by which the two ends of the
CDNI Logging interface agree on whether anonymization is to be
supported and the number of bits that need to be zeroed-out for
this purpose are outside the scope of the present document.
IPv4 addresses SHOULD be anonymized to /24 boundary (i.e., with
c-ip-anonymizing set to 8), and IPv6 addresses SHOULD be
anonymized to a /48 boundary (i.e., with c-ip-anonymizing set
to 80).
* occurrence: there MUST be zero or exactly one instance of this
field.
o c-port: * format: NHTABSTRING
* format: 1*DIGIT * field value: an opaque identifier for an aggregate set of
clients, derived from the client IPv4 or IPv6 address in the
request received by the Surrogate and/or other network-level
identifying information. The c-groupid serves to group clients
into aggregates. Example aggregates include civil geolocation
information (the country, second-level administrative division,
or postal code from which the client is presumed to make the
request based on a geolocation database lookup) or network
topological information (e.g. the BGP AS number announcing the
prefix containing the address). The c-groupid MAY be
structured e.g. US/TN/MEM/38138. Agreement between the dCDN
and the uCDN on a mapping between IPv4 and IPv6 addresses and
aggregates is presumed to occur out of band. The aggregation
mapping SHOULD be chosen such that each aggregate contains more
than one client. When the aggregate is chosen so that it
contains a single client (e.g. to allow more detailed
analytics, or to allow a-posteriori analysis of individual
delivery for example in situations of performance-based
penalties):
* field value: the source TCP port (i.e., the "client" port) in *
the request received by the Surrogate.
* occurrence: there MUST be zero or exactly one instance of this + the c-groupid MAY be structured (e.g. US/TN/
field. MEM/38138/43a5bdd6-95c4-4d62-be65-7410df0021e2) where some
elements identify aggregates and one element identifies the
client.
o c-port-anonymizing: + the element identifying the client is algorithmically
generated (from the client IPv4 or IPv6 address in the
request received by the Surrogate and/or other network-level
identifying information) in a way that SHOULD NOT be
linkable back to the global addressing context and that
SHOULD vary over time (to offer protection against long term
attacks); one example way to achieve this is to hash the
address with a shared secret that is pre-synchronised and
rotated at a predefined time interval. It is RECOMMENDED
that the mapping varies at least once every 24 hours. The
mapping from IP address to the element identifying the
client (effectively an encryption of the address) SHOULD be
done using a symmetric key that is known only to both the
uCDN and dCDN. One method of doing this is to use an analog
of how key derivation is via HKDF ([RFC5869]), as will be
used in TLS 1.3 ([I-D.ietf-tls-rfc5246-bis]). When the two
CDNs set up the relationship, they agree out of band on a
mapping between IPv4 and IPv6 addresses and aggregates and
on the algorithmic mapping from IPv4/IPv6 addresses and the
element identifying the client; they agree on the salt and
input key material, as described in [RFC5869], Section 2.2,
the hash mechanism to use (SHA-2 or SHA-3 SHOULD be used),
and the key lifetime which SHOULD NOT exceed 25 hours. They
also agree on an initial "info" parameter, which can be
something such as the business names of the two
organizations in UTF-8, concatenated. The encryption
algorithm must also be defined, and SHOULD be 128-bit AES-
GCM or better. The PRK should be chosen by both parties
contributing alternate random bytes until sufficient length
exists. After this initial setup, client-information is
encrypted using the key generated by the "expand" step,
Section 2.3 of [RFC5869], and hex-encoded or base64-encoded.
At the agreed-upon lifetime, a new key is used, indicated by
prefixing the key with a special character such as
exclamation point. In this way, shorter lifetimes can be
used as needed.
* format: 1*DIGIT + The algorithmic mapping and variation over time MAY allow
the uCDN (with the knowledge of the algorithm and time
variation and associated attributes and keys) to reconstruct
the actual enduser IPv4/IPv6 addresses where that is
required (e.g. to allow a-posteriori analysis of individual
delivery for example in situations of performance-based
penalties). However, these enduser IPv4/IPv6 addresses
SHOULD only be reconstructed on-demand and the CDNI Logging
File SHOULD only be stored with the anonymised c-groupid
value.
* field value: the number of rightmost bits of the port in the + Using the c-groupid field in this way carries with it grave
c-port field that are zeroed-out in order to anonymize the risks to end-user privacy. Since the c-groupid is in this
logging record. The mechanism by which the two ends of the case equivalent in identification power to a client IP
CDNI Logging interface agree on whether anonymization is to be address, its use may be restricted by regulation or law as
supported and the number of bits that need to be zeroed-out for personally identifiable information. For this reason, such
this purpose are outside the scope of the present document. use is NOT RECOMMENDED.
* occurrence: there MUST be zero or exactly one instance of this * occurrence: there MUST be one and only one instance of this
field. field.
o s-ip: o s-ip:
* format: ADDRESS * format: ADDRESS
* field value: the IPv4 or IPv6 address of the Surrogate that * field value: the IPv4 or IPv6 address of the Surrogate that
served the request (i.e., the "server" address). served the request (i.e., the "server" address).
* occurrence: there MUST be zero or exactly one instance of this * occurrence: there MUST be zero or exactly one instance of this
skipping to change at line 1497 skipping to change at page 34, line 20
implement all the following Logging fields in a CDNI Logging Record implement all the following Logging fields in a CDNI Logging Record
of record-type "cdni_http_request_v1", and MUST support the ability of record-type "cdni_http_request_v1", and MUST support the ability
to include valid values for each of them: to include valid values for each of them:
o date o date
o time o time
o time-taken o time-taken
o c-ip o c-groupid
o c-ip-anonymizing
o c-port
o c-port-anonymizing
o s-ip o s-ip
o s-hostname o s-hostname
o s-port o s-port
o cs-method o cs-method
o cs-uri o cs-uri
skipping to change at line 1571 skipping to change at page 36, line 5
3.5. CDNI Logging File Example 3.5. CDNI Logging File Example
Let us consider the upstream CDN and the downstream CDN labelled uCDN Let us consider the upstream CDN and the downstream CDN labelled uCDN
and dCDN-1 in Figure 1. When dCDN-1 acts as a downstream CDN for and dCDN-1 in Figure 1. When dCDN-1 acts as a downstream CDN for
uCDN and performs content delivery on behalf of uCDN, dCDN-1 will uCDN and performs content delivery on behalf of uCDN, dCDN-1 will
include the CDNI Logging Records corresponding to the content include the CDNI Logging Records corresponding to the content
deliveries performed on behalf of uCDN in the CDNI Logging Files for deliveries performed on behalf of uCDN in the CDNI Logging Files for
uCDN. An example CDNI Logging File communicated by dCDN-1 to uCDN is uCDN. An example CDNI Logging File communicated by dCDN-1 to uCDN is
shown below in Figure 4. shown below in Figure 4.
#version:<HTAB>cdni/1.0<CRLF> #version:<HTAB>cdni/1.0<CRLF>
#UUID:<HTAB>urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6<CRLF> #UUID:<HTAB>urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6<CRLF>
#claimed-origin:<HTAB>cdni-logging-entity.dcdn-1.example.com<CRLF> #claimed-origin:<HTAB>cdni-logging-entity.dcdn-1.example.com<CRLF>
#record-type:<HTAB>cdni_http_request_v1<CRLF> #record-type:<HTAB>cdni_http_request_v1<CRLF>
#fields:<HTAB>date<HTAB>time<HTAB>time-taken<HTAB>c-ip<HTAB> #fields:<HTAB>date<HTAB>time<HTAB>time-taken<HTAB>c-groupid<HTAB>
c-ip-anonymizing<HTAB>cs-method<HTAB>u-uri<HTAB>protocol<HTAB> cs-method<HTAB>u-uri<HTAB>protocol<HTAB>
sc-status<HTAB>sc-total-bytes<HTAB>cs(User-Agent)<HTAB> sc-status<HTAB>sc-total-bytes<HTAB>cs(User-Agent)<HTAB>
cs(Referer)<HTAB>s-cached<CRLF> cs(Referer)<HTAB>s-cached<CRLF>
2013-05-17<HTAB>00:38:06.825<HTAB>9.058<HTAB>10.5.7.0<HTAB>8<HTAB>GET<HTAB> 2013-05-17<HTAB>00:38:06.825<HTAB>9.058<HTAB>US/TN/MEM/38138<HTAB>
http://cdni-ucdn.dcdn-1.example.com/video/movie100.mp4<HTAB> GET<HTAB>
HTTP/1.1<HTAB>200<HTAB>6729891<HTAB>"Mozilla/5.0 http://cdni-ucdn.dcdn-1.example.com/video/movie100.mp4<HTAB>
(Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like HTTP/1.1<HTAB>200<HTAB>6729891<HTAB>"Mozilla/5.0
Gecko) Chrome/5.0.375.127 Safari/533.4"<HTAB> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like
"host1.example.com"<HTAB>1<CRLF> Gecko) Chrome/5.0.375.127 Safari/533.4"<HTAB>
"host1.example.com"<HTAB>1<CRLF>
2013-05-17<HTAB>00:39:09.145<HTAB>15.32<HTAB>10.5.10.0<HTAB>8<HTAB>GET<HTAB> 2013-05-17<HTAB>00:39:09.145<HTAB>15.32<HTAB>FR/PACA/NCE/06100<HTAB>
http://cdni-ucdn.dcdn-1.example.com/video/movie118.mp4<HTAB> GET<HTAB>
HTTP/1.1<HTAB>200<HTAB>15799210<HTAB>"Mozilla/5.0 http://cdni-ucdn.dcdn-1.example.com/video/movie118.mp4<HTAB>
(Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like HTTP/1.1<HTAB>200<HTAB>15799210<HTAB>"Mozilla/5.0
Gecko) Chrome/5.0.375.127 Safari/533.4"<HTAB> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like
"host1.example.com"<HTAB>1<CRLF> Gecko) Chrome/5.0.375.127 Safari/533.4"<HTAB>
"host1.example.com"<HTAB>1<CRLF>
2013-05-17<HTAB>00:42:53.437<HTAB>52.879<HTAB>10.5.10.0<HTAB>8<HTAB>GET<HTAB> 2013-05-17<HTAB>00:42:53.437<HTAB>52.879<HTAB>US/TN/MEM/38138<HTAB>
http://cdni-ucdn.dcdn-1.example.com/video/picture11.mp4<HTAB> GET<HTAB>
HTTP/1.0<HTAB>200<HTAB>97234724<HTAB>"Mozilla/5.0 http://cdni-ucdn.dcdn-1.example.com/video/picture11.mp4<HTAB>
(Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like HTTP/1.0<HTAB>200<HTAB>97234724<HTAB>"Mozilla/5.0
Gecko) Chrome/5.0.375.127 Safari/533.4"<HTAB> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like
"host5.example.com"<HTAB>0<CRLF> Gecko) Chrome/5.0.375.127 Safari/533.4"<HTAB>
"host5.example.com"<HTAB>0<CRLF>
#SHA256-hash:<HTAB>...32-hexadecimal-digit hash value...<CRLF> #SHA256-hash:<HTAB>...64-hexadecimal-digit hash value...<CRLF>
Figure 4: CDNI Logging File Example Figure 4: CDNI Logging File Example
If uCDN establishes by some means (e.g. via TLS authentication when If uCDN establishes by some means (e.g. via TLS authentication when
pulling the CDNI Logging File) the identity of the entity from which pulling the CDNI Logging File) the identity of the entity from which
it pulled the CDNI Logging File, uCDN can add to the CDNI Logging an it pulled the CDNI Logging File, uCDN can add to the CDNI Logging an
established-origin directive as illustrated below: established-origin directive as illustrated below:
#established-origin:<HTAB>cdni-logging-entity.dcdn- #established-origin:<HTAB>cdni-logging-entity.dcdn-
1.example.com<CRLF> 1.example.com<CRLF>
skipping to change at line 1659 skipping to change at page 38, line 5
Let us consider the cascaded CDN scenario of uCDN, dCDN-2 and dCDN-3 Let us consider the cascaded CDN scenario of uCDN, dCDN-2 and dCDN-3
as depicted in Figure 1. After completion of a delivery by dCDN-3 on as depicted in Figure 1. After completion of a delivery by dCDN-3 on
behalf of dCDN-2, dCDN-3 will include a corresponding Logging Record behalf of dCDN-2, dCDN-3 will include a corresponding Logging Record
in a CDNI Logging File that will be pulled by dCDN-2 and that is in a CDNI Logging File that will be pulled by dCDN-2 and that is
illustrated below in Figure 5. In practice, a CDNI Logging File is illustrated below in Figure 5. In practice, a CDNI Logging File is
likely to contain a very high number of CDNI Logging Records. likely to contain a very high number of CDNI Logging Records.
However, for readability, the example in Figure 5 contains a single However, for readability, the example in Figure 5 contains a single
CDNI Logging Record. CDNI Logging Record.
#version:<HTAB>CDNI/1.0<CRLF> #version:<HTAB>CDNI/1.0<CRLF>
#UUID:<HTAB>urn:uuid:65718ef-0123-9876-adce4321bcde<CRLF> #UUID:<HTAB>urn:uuid:65718ef-0123-9876-adce4321bcde<CRLF>
#claimed-origin:<HTAB>cdni-logging-entity.dcdn-3.example.com<CRLF> #claimed-origin:<HTAB>cdni-logging-entity.dcdn-3.example.com<CRLF>
#record-type:<HTAB>cdni_http_request_v1<CRLF> #record-type:<HTAB>cdni_http_request_v1<CRLF>
#fields:<HTAB>date<HTAB>time<HTAB>time-taken<HTAB>c-ip<HTAB> #fields:<HTAB>date<HTAB>time<HTAB>time-taken<HTAB>c-groupid<HTAB>
c-ip-anonymizing<HTAB>cs-method<HTAB>u-uri<HTAB>protocol<HTAB> cs-method<HTAB>u-uri<HTAB>protocol<HTAB>
sc-status<HTAB>sc-total-bytes<HTAB>cs(User-Agent)<HTAB> sc-status<HTAB>sc-total-bytes<HTAB>cs(User-Agent)<HTAB>
cs(Referer)<HTAB>s-cached<CRLF> cs(Referer)<HTAB>s-cached<CRLF>
2013-05-17<HTAB>00:39:09.119<HTAB>14.07<HTAB>10.5.10.0<HTAB>8<HTAB>GET<HTAB> 2013-05-17<HTAB>00:39:09.119<HTAB>14.07<HTAB>US/CA/SFO/94114<HTAB>
http://cdni-dcdn-2.dcdn-3.example.com/video/movie118.mp4<HTAB> GET<HTAB>
HTTP/1.1<HTAB>200<HTAB>15799210<HTAB>"Mozilla/5.0 http://cdni-dcdn-2.dcdn-3.example.com/video/movie118.mp4<HTAB>
(Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like HTTP/1.1<HTAB>200<HTAB>15799210<HTAB>"Mozilla/5.0
Gecko) Chrome/5.0.375.127 Safari /533.4"<HTAB> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like
"host1.example.com"<HTAB>1<CRLF> Gecko) Chrome/5.0.375.127 Safari /533.4"<HTAB>
"host1.example.com"<HTAB>1<CRLF>
#SHA256-hash:<HTAB>...32-hexadecimal-digit hash value...<CRLF> #SHA256-hash:<HTAB>...64-hexadecimal-digit hash value...<CRLF>
Figure 5: Cascaded CDNI Logging File Example (dCDN-3 to dCDN-2) Figure 5: Cascaded CDNI Logging File Example (dCDN-3 to dCDN-2)
If dCDN-2 establishes by some means (e.g. via TLS authentication when If dCDN-2 establishes by some means (e.g. via TLS authentication when
pulling the CDNI Logging File) the identity of the entity from which pulling the CDNI Logging File) the identity of the entity from which
it pulled the CDNI Logging File, dCDN-2 can add to the CDNI Logging it pulled the CDNI Logging File, dCDN-2 can add to the CDNI Logging
an established-origin directive as illustrated below: an established-origin directive as illustrated below:
#established-origin:<HTAB>cdni-logging-entity.dcdn- #established-origin:<HTAB>cdni-logging-entity.dcdn-
3.example.com<CRLF> 3.example.com<CRLF>
skipping to change at line 1707 skipping to change at page 39, line 5
behalf of dCDN-2 had actually been redirected to dCDN-2 by uCDN, and behalf of dCDN-2 had actually been redirected to dCDN-2 by uCDN, and
say that another content delivery has just been redirected by uCDN to say that another content delivery has just been redirected by uCDN to
dCDN-2 and that dCDN-2 elected to perform the corresponding delivery dCDN-2 and that dCDN-2 elected to perform the corresponding delivery
itself. Then after Filtering and Rectification (as illustrated in itself. Then after Filtering and Rectification (as illustrated in
Figure 2), dCDN-2 will include the two Logging Records corresponding Figure 2), dCDN-2 will include the two Logging Records corresponding
respectively to the delivery performed by dCDN-3 and the delivery respectively to the delivery performed by dCDN-3 and the delivery
performed by dCDN-2, in the next CDNI Logging File that will be performed by dCDN-2, in the next CDNI Logging File that will be
communicated to uCDN. An example of such CDNI Logging File is communicated to uCDN. An example of such CDNI Logging File is
illustrated below in Figure 6. illustrated below in Figure 6.
#version:<HTAB>CDNI/1.0<CRLF> #version:<HTAB>CDNI/1.0<CRLF>
#UUID:<HTAB>urn:uuid:1234567-8fedc-abab-0987654321ff<CRLF> #UUID:<HTAB>urn:uuid:1234567-8fedc-abab-0987654321ff<CRLF>
#claimed-origin:<HTAB>cdni-logging-entity.dcdn-2.example.com<CRLF> #claimed-origin:<HTAB>cdni-logging-entity.dcdn-2.example.com<CRLF>
#record-type:<HTAB>cdni_http_request_v1<CRLF> #record-type:<HTAB>cdni_http_request_v1<CRLF>
#fields:<HTAB>date<HTAB>time<HTAB>time-taken<HTAB>c-ip<HTAB> #fields:<HTAB>date<HTAB>time<HTAB>time-taken<HTAB>c-groupid<HTAB>
c-ip-anonymizing<HTAB>cs-method<HTAB>u-uri<HTAB>protocol<HTAB> cs-method<HTAB>u-uri<HTAB>protocol<HTAB>
sc-status<HTAB>sc-total-bytes<HTAB>cs(User-Agent)<HTAB> sc-status<HTAB>sc-total-bytes<HTAB>cs(User-Agent)<HTAB>
cs(Referer)<HTAB>s-cached<CRLF> cs(Referer)<HTAB>s-cached<CRLF>
2013-05-17<HTAB>00:39:09.119<HTAB>14.07<HTAB>10.5.10.0<HTAB>8<HTAB>GET<HTAB> 2013-05-17<HTAB>00:39:09.119<HTAB>14.07<HTAB>US/CA/SFO/94114<HTAB>
http://cdni-ucdn.dcdn-2.example.com/video/movie118.mp4<HTAB> GET<HTAB>
HTTP/1.1<HTAB>200<HTAB>15799210<HTAB>"Mozilla/5.0 http://cdni-ucdn.dcdn-2.example.com/video/movie118.mp4<HTAB>
(Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like HTTP/1.1<HTAB>200<HTAB>15799210<HTAB>"Mozilla/5.0
Gecko) Chrome/5.0.375.127 Safari /533.4"<HTAB> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like
"host1.example.com"<HTAB>1<CRLF> Gecko) Chrome/5.0.375.127 Safari /533.4"<HTAB>
"host1.example.com"<HTAB>1<CRLF>
2013-05-17<HTAB>01:42:53.437<HTAB>52.879<HTAB>10.5.10.0<HTAB>8<HTAB>GET<HTAB> 2013-05-17<HTAB>01:42:53.437<HTAB>52.879<HTAB>FR/IDF/PAR/75001<HTAB>
http://cdni-ucdn.dcdn-2.example.com/video/picture11.mp4<HTAB> GET<HTAB>
HTTP/1.0<HTAB>200<HTAB>97234724<HTAB>"Mozilla/5.0 http://cdni-ucdn.dcdn-2.example.com/video/picture11.mp4<HTAB>
(Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like HTTP/1.0<HTAB>200<HTAB>97234724<HTAB>"Mozilla/5.0
Gecko) Chrome/5.0.375.127 Safari /533.4"<HTAB> (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like
"host5.example.com"<HTAB>0<CRLF> Gecko) Chrome/5.0.375.127 Safari /533.4"<HTAB>
"host5.example.com"<HTAB>0<CRLF>
#SHA256-hash:<HTAB>...32-hexadecimal-digit hash value...<CRLF> #SHA256-hash:<HTAB>...64-hexadecimal-digit hash value...<CRLF>
Figure 6: Cascaded CDNI Logging File Example (dCDN-2 to uCDN) Figure 6: Cascaded CDNI Logging File Example (dCDN-2 to uCDN)
If uCDN establishes by some means (e.g. via TLS authentication when If uCDN establishes by some means (e.g. via TLS authentication when
pulling the CDNI Logging File) the identity of the entity from which pulling the CDNI Logging File) the identity of the entity from which
it pulled the CDNI Logging File, uCDN can add to the CDNI Logging an it pulled the CDNI Logging File, uCDN can add to the CDNI Logging an
established-origin directive as illustrated below: established-origin directive as illustrated below:
#established-origin:<HTAB>cdni-logging-entity.dcdn- #established-origin:<HTAB>cdni-logging-entity.dcdn-
2.example.com<CRLF> 2.example.com<CRLF>
skipping to change at line 1822 skipping to change at page 41, line 27
updated as new CDNI Logging Files become available, and information updated as new CDNI Logging Files become available, and information
about older CDNI Logging files is moved into archive documents. Once about older CDNI Logging files is moved into archive documents. Once
created, archive documents are never modified. created, archive documents are never modified.
Each CDNI Logging File listed in an Atom feed MUST be described in an Each CDNI Logging File listed in an Atom feed MUST be described in an
atom:entry container element. atom:entry container element.
The atom:entry MUST contain an atom:content element whose "src" The atom:entry MUST contain an atom:content element whose "src"
attribute is a link to the CDNI Logging File and whose "type" attribute is a link to the CDNI Logging File and whose "type"
attribute is the MIME Media Type indicating that the entry is a CDNI attribute is the MIME Media Type indicating that the entry is a CDNI
Logging File. We define this MIME Media Type as "application/ logging file. This MIME Media Type is defined as "application/cdni"
cdni.LoggingFile" (See Section 6.5). (See [I-D.ietf-cdni-media-type]) with the Payload Type (ptype)
parameter set to "logging-file".
For compatibility with some Atom feed readers the atom:entry MAY also For compatibility with some Atom feed readers the atom:entry MAY also
contain an atom:link entry whose "href" attribute is a link to the contain an atom:link entry whose "href" attribute is a link to the
CDNI Logging File and whose "type" attribute is the MIME Media Type CDNI Logging File and whose "type" attribute is the MIME Media Type
indicating that the entry is a CDNI Logging File using the indicating that the entry is a CDNI Logging File using the
"application/cdni.LoggingFile" MIME Media Type (See Section 6.5). "application/cdni" MIME Media Type with the Payload Type (ptype)
parameter set to "logging-file"(See [I-D.ietf-cdni-media-type]).
The URI used in the atom:id of the atom:entry MUST contain the UUID The URI used in the atom:id of the atom:entry MUST contain the UUID
of the CDNI Logging File. of the CDNI Logging File.
The atom:updated in the atom:entry MUST indicate the time at which The atom:updated in the atom:entry MUST indicate the time at which
the CDNI Logging File was last updated. the CDNI Logging File was last updated.
4.1.2. Updates to Log Files and the Feed 4.1.2. Updates to Log Files and the Feed
CDNI Logging Files MUST NOT be modified by the dCDN once published in CDNI Logging Files MUST NOT be modified by the dCDN once published in
skipping to change at line 1910 skipping to change at page 43, line 26
<generator version="example version 1">CDNI Log Feed <generator version="example version 1">CDNI Log Feed
Generator</generator> Generator</generator>
<author><name>dcdn.example</name></author> <author><name>dcdn.example</name></author>
<entry> <entry>
<title type="text">CDNI Logging File for uCDN at <title type="text">CDNI Logging File for uCDN at
2013-03-23 14:15:00</title> 2013-03-23 14:15:00</title>
<id>urn:uuid:12345678-1234-abcd-00aa-01234567abcd</id> <id>urn:uuid:12345678-1234-abcd-00aa-01234567abcd</id>
<updated>2013-03-23T14:15:00Z</updated> <updated>2013-03-23T14:15:00Z</updated>
<content src="https://dcdn.example/logs/ucdn/ <content src="https://dcdn.example/logs/ucdn/
http-requests-20130323141500000000" http-requests-20130323141500000000"
type="application/cdni.LoggingFile" /> type="application/cdni"
ptype="logging-file"/>
<summary>CDNI Logging File for uCDN at <summary>CDNI Logging File for uCDN at
2013-03-23 14:15:00</summary> 2013-03-23 14:15:00</summary>
</entry> </entry>
<entry> <entry>
<title type="text">CDNI Logging File for uCDN at <title type="text">CDNI Logging File for uCDN at
2013-03-23 14:30:00</title> 2013-03-23 14:30:00</title>
<id>urn:uuid:87654321-4321-dcba-aa00-dcba7654321</id> <id>urn:uuid:87654321-4321-dcba-aa00-dcba7654321</id>
<updated>2013-03-23T14:30:00Z</updated> <updated>2013-03-23T14:30:00Z</updated>
<content src="https://dcdn.example/logs/ucdn/ <content src="https://dcdn.example/logs/ucdn/
http-requests-20130323143000000000" http-requests-20130323143000000000"
type="application/cdni.LoggingFile" /> type="application/cdni"
ptype="logging-file"/>
<summary>CDNI Logging File for uCDN at <summary>CDNI Logging File for uCDN at
2013-03-23 14:30:00</summary> 2013-03-23 14:30:00</summary>
</entry> </entry>
... ...
<entry> <entry>
... ...
</entry> </entry>
</feed> </feed>
Figure 7: Example subscription document of a CDNI Logging Feed Figure 7: Example subscription document of a CDNI Logging Feed
skipping to change at line 2032 skipping to change at page 46, line 11
logging information such as near-real-time content delivery logging information such as near-real-time content delivery
monitoring. Such mechanisms are for further study and outside the monitoring. Such mechanisms are for further study and outside the
scope of this document. scope of this document.
6. IANA Considerations 6. IANA Considerations
When IANA allocates new extensions to CDNI Logging Directive Names When IANA allocates new extensions to CDNI Logging Directive Names
Registry, CDNI Logging File version Registry, CDNI Logging record- Registry, CDNI Logging File version Registry, CDNI Logging record-
type Registry or CDNI Logging fields Registry, IANA MUST take into type Registry or CDNI Logging fields Registry, IANA MUST take into
account that the directive names are case-insensitive as per the account that the directive names are case-insensitive as per the
basic ABNF([RFC2234]). basic ABNF([RFC5234]).
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 Directives registry comprise The initial contents of the CDNI Logging Directives registry comprise
the names of the directives specified in Section 3.3 of the present the names of the directives specified in Section 3.3 of the present
document, and are as follows: document, and are as follows:
skipping to change at line 2066 skipping to change at page 46, line 45
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). All directive names and field names NAMEFORMAT (see Section 3.1). All directive names and field names
defined in the logging file are case-insensitive as per the basic defined in the logging file are case-insensitive as per the basic
ABNF([RFC2234]). ABNF([RFC5234]).
Each specification that defines a new CDNI Logging directive needs to Each specification that defines a new CDNI Logging directive needs to
contain a description for the new directive with the same set of contain a description for the new directive with the same set of
information as provided in Section 3.3 (i.e., format, directive value information as provided in Section 3.3 (i.e., format, directive value
and occurrence). and occurrence).
6.2. CDNI Logging File version Registry 6.2. CDNI Logging File version Registry
The IANA is requested to create a new registry, CDNI Logging File The IANA is requested to create a new registry, CDNI Logging File
version. version.
skipping to change at line 2169 skipping to change at page 49, line 11
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-groupid | RFC xxxx |
| c-ip-anonymizing | 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 |
skipping to change at line 2201 skipping to change at page 49, line 41
[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).
6.5. CDNI Logging MIME Media Type 6.5. CDNI Logging MIME Media Type
The IANA is requested to allocate the "application/cdni.LoggingFile" The IANA is requested to register the following new Payload Type in
MIME Media Type (whose use is specified in Section 4.1.1 of the the CDNI Payload Type Parameter registry for use with the
present document) in the MIME Media Types registry. application/cdni MIME media type.
[RFC Editor Note: Please replace the references to [RFCthis] below
with this document's RFC number before publication.
+----------------------+---------------+
| Payload Type | Specification |
+----------------------+---------------+
| logging-file | [RFCthis] |
+----------------------+---------------+
Figure 12: MIME Media Type payload
The purpose of the logging-file payload type is to be able to
distinguish logging messages from other types of messages.
Interface: LI
Encoding: see Section 4.1.1
7. Security Considerations 7. Security Considerations
7.1. Authentication, Authorization, Confidentiality, Integrity 7.1. Authentication, Authorization, Confidentiality, Integrity
Protection 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] and [RFC7230]. Logging File pull (Section 4.2) as per [RFC2818] and [RFC7230].
skipping to change at line 2271 skipping to change at page 51, line 38
and therefore can be easily protected against DoS attacks through the and therefore can be easily protected against DoS attacks through the
usual conventional DOS protection mechanisms such as firewalling or usual conventional DOS protection mechanisms such as firewalling or
use of Virtual Private Networks (VPNs). use of Virtual Private Networks (VPNs).
Protection of dCDN Surrogates against spoofed delivery requests is Protection of dCDN Surrogates against spoofed delivery requests is
outside the scope of the CDNI Logging interface. outside the scope of the CDNI Logging interface.
7.3. Privacy 7.3. Privacy
CDNs have the opportunity to collect detailed information about the CDNs have the opportunity to collect detailed information about the
downloads performed by End Users. The provision of this information downloads performed by End Users. A dCDN is expected to collect such
to another CDN introduces potential End Users privacy protection information into CDNI Logging Files, which are then communicatd to an
concerns. uCDN.
The use of mutually authenticated TLS to establish a secure session Having detailed CDNI logging information known by the dCDN in itself
for the transport of the CDNI Logging feed and CDNI Logging pull as does not represent a particular privacy concern since the dCDN is
discussed in Section 7.1 access to the logging information. This obviously fully aware of all information logged since it generates it
provides confidentiality while the logging information is in transit in the first place. Making detailed CDNI logging information known
and prevents any other party than the authorised uCDN to gain access to the uCDN does not represent a particular privacy concern because
to the logging information. the uCDN is already exposed at request redirection time to most of
the information that shows up as CDNI logging information (e.g.
enduser IP@, URL, HTTP headers - at least when HTTP redirection is
used between uCDN and dCDN). Transporting detailed CDNI logging
information over the HTTP based CDNI Logging Interface does not
represent a particular privacy concern because it is protected by
usual IETF privacy-protection mechanism (TLS).
We observe that when CDNI interconnection is realised as per However, one privacy concern arises from the fact that very large
[RFC7336], the uCDN handles the initial End User requests (before it volumes of detailed information about content delivery to users,
is redirected to the dCDN) so, regardless of which information is, or potentially traceable back to indvidual users, may be collected in
is not, communicated to the uCDN through the CDNI Logging interface, CDNI Logging files, which then represent a high-value target, likely
the uCDN has visibility on significant information such as the IP concentrated in a fairly centralised system (although the CDNI
address of the End User request and the URL of the request. Logging architecture does not manadate a particular level of
centralisation/distribution) and thus is at risk of potential data
exfiltration. Note that the means of such data exfiltration are
beyond the scope of the CDNI Logging interface itself (e.g. corrupted
employee, corrupted logging storage system,...). This privacy
concern calls for some protection.
Nonetheless, if the dCDN and uCDN agree that anonymization is The collection of very large volumes of such information into CDNI
required to avoid making some detailed information available to the Logging Files introduces potential End Users privacy protection
uCDN (such as how many bytes of the content have been watched by an concerns. Mechanisms to address these concerned are discussed in the
End User and/or at what time) or is required to meet some legal definition of the c-groupid field specified in section Section 3.4.1.
obligations, then the uCDN and dCDN can agree to exchange anonymized
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
anonymized so that the meaningful information can still be easily
extracted from the anonymized addressses (e.g., for geolocation aware
analytics).
We note that anonymization of End Users IP address does not fully The use of mutually authenticated TLS to establish a secure session
protect against deriving potentially sensitive information about for the transport of the CDNI Logging feed and CDNI Logging pull as
traffic patterns; in general, increasing the number of bits that are discussed in Section 7.1 provides confidentiality while the logging
anonymized can mitigate the risks of deriving such sensitive traffic information is in transit and prevents any other party than the
pattern information. authorised uCDN to gain access to the logging information.
We also note that independently of IP addresses, the query string We also note that the query string portion of the URL that may be
portion of the URL that may be conveyed inside the cs-uri and u-uri conveyed inside the cs-uri and u-uri fields of CDNI Logging Files, or
fields of CDNI Logging Files, or the HTTP cookies( [RFC6265]) that the HTTP cookies( [RFC6265]) that may be conveyed as part of the
may be conveyed inside the cs(<HTTP-header-name>) field of CDNI cs(<HTTP-header-name>) field of CDNI Logging files, may contain
Logging fields, may contain personnal information or information that personnal information or information that can be exploited to derive
can be exploited to derive personal information. Where this is a personal information. Where this is a concern, the CDNI Logging
concern, the CDNI Logging interface specification allows the dCDN to interface specification allows the dCDN to not include the cs-uri and
not include the cs-uri and to include a u-uri that removes (or hides) to include a u-uri that removes (or hides) the sensitive part of the
the sensitive part of the query string and allows the dCDN to not query string and allows the dCDN to not include the cs(<HTTP-header-
include the cs(<HTTP-header-name>) fields corresponding to HTTP name>) fields corresponding to HTTP headers associated with cookies.
headers associated with cookies.
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. Rob Murray significantly contributed into the text of Section 4.1.
The authors thank Ben Niven-Jenkins, Kevin Ma, David Mandelberg and The authors thank Ben Niven-Jenkins, Kevin Ma, David Mandelberg and
Ray van Brandenburg for their ongoing input. Ray van Brandenburg for their ongoing input.
skipping to change at line 2338 skipping to change at page 53, line 13
Jacquenet, Yannick Le Louedec, Anne Marrec , Emile Stephan, Fabio Jacquenet, Yannick Le Louedec, Anne Marrec , Emile Stephan, Fabio
Costa, Sara Oueslati, Yvan Massot, Renaud Edel, Joel Favier and the Costa, Sara Oueslati, Yvan Massot, Renaud Edel, Joel Favier and the
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,
DOI 10.17487/RFC2119, March 1997,
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax <http://www.rfc-editor.org/info/rfc2119>.
Specifications: ABNF", RFC 2234, November 1997.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Internet: Timestamps", RFC 3339, July 2002. Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<http://www.rfc-editor.org/info/rfc3339>.
[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,
3986, January 2005. RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>.
[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,
2005. DOI 10.17487/RFC4122, July 2005,
<http://www.rfc-editor.org/info/rfc4122>.
[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, DOI 10.17487/RFC4287,
December 2005, <http://www.rfc-editor.org/info/rfc4287>.
[RFC5005] Nottingham, M., "Feed Paging and Archiving", RFC 5005, [RFC5005] Nottingham, M., "Feed Paging and Archiving", RFC 5005,
September 2007. DOI 10.17487/RFC5005, September 2007,
<http://www.rfc-editor.org/info/rfc5005>.
[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. DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, Specifications: ABNF", STD 68, RFC 5234,
August 2008. DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
(HTTP/1.1): Message Syntax and Routing", RFC 7230, June Protocol (HTTP/1.1): Message Syntax and Routing",
2014. RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
(HTTP/1.1): Semantics and Content", RFC 7231, June 2014. Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014,
<http://www.rfc-editor.org/info/rfc7231>.
[RFC7232] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
(HTTP/1.1): Conditional Requests", RFC 7232, June 2014. Protocol (HTTP/1.1): Conditional Requests", RFC 7232,
DOI 10.17487/RFC7232, June 2014,
<http://www.rfc-editor.org/info/rfc7232>.
[RFC7233] Fielding, R., Lafon, Y., and J. Reschke, "Hypertext [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
June 2014. RFC 7233, DOI 10.17487/RFC7233, June 2014,
<http://www.rfc-editor.org/info/rfc7233>.
[RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
2014. RFC 7234, DOI 10.17487/RFC7234, June 2014,
<http://www.rfc-editor.org/info/rfc7234>.
[RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
(HTTP/1.1): Authentication", RFC 7235, June 2014. Protocol (HTTP/1.1): Authentication", RFC 7235,
DOI 10.17487/RFC7235, June 2014,
<http://www.rfc-editor.org/info/rfc7235>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, May 2015. (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Protocol Version 2 (HTTP/2)", RFC 7540, May 2015. Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015,
<http://www.rfc-editor.org/info/rfc7540>.
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-media-type]
Ma, K., "CDNI Media Type Registration", draft-ietf-cdni-
media-type-06 (work in progress), October 2015.
[I-D.ietf-cdni-metadata] [I-D.ietf-cdni-metadata]
Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
"CDN Interconnection Metadata", draft-ietf-cdni- "CDN Interconnection Metadata", draft-ietf-cdni-
metadata-09 (work in progress), March 2015. metadata-11 (work in progress), July 2015.
[I-D.ietf-httpbis-http2] [I-D.ietf-tls-rfc5246-bis]
Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer Dierks, T. and E. Rescorla, "The Transport Layer Security
Protocol version 2", draft-ietf-httpbis-http2-17 (work in (TLS) Protocol Version 1.3", draft-ietf-tls-rfc5246-bis-00
progress), February 2015. (work in progress), April 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.
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext [RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext
Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. Transfer Protocol -- HTTP/1.0", RFC 1945,
DOI 10.17487/RFC1945, May 1996,
<http://www.rfc-editor.org/info/rfc1945>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<http://www.rfc-editor.org/info/rfc2818>.
[RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
(SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010,
<http://www.rfc-editor.org/info/rfc5869>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<http://www.rfc-editor.org/info/rfc6234>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011. DOI 10.17487/RFC6265, April 2011,
<http://www.rfc-editor.org/info/rfc6265>.
[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, DOI 10.17487/RFC6707, September
2012, <http://www.rfc-editor.org/info/rfc6707>.
[RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, [RFC6770] Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley,
K., and G. Watson, "Use Cases for Content Delivery Network P., Ma, K., and G. Watson, "Use Cases for Content Delivery
Interconnection", RFC 6770, November 2012. Network Interconnection", RFC 6770, DOI 10.17487/RFC6770,
November 2012, <http://www.rfc-editor.org/info/rfc6770>.
[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)",
6983, July 2013. RFC 6983, DOI 10.17487/RFC6983, July 2013,
<http://www.rfc-editor.org/info/rfc6983>.
[RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed.,
"Framework for Content Distribution Network "Framework for Content Distribution Network
Interconnection (CDNI)", RFC 7336, August 2014. Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336,
August 2014, <http://www.rfc-editor.org/info/rfc7336>.
[RFC7337] Leung, K. and Y. Lee, "Content Distribution Network [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution
Interconnection (CDNI) Requirements", RFC 7337, August Network Interconnection (CDNI) Requirements", RFC 7337,
2014. DOI 10.17487/RFC7337, August 2014,
<http://www.rfc-editor.org/info/rfc7337>.
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
 End of changes. 94 change blocks. 
301 lines changed or deleted 415 lines changed or added

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