draft-ietf-cdni-logging-25.txt   draft-ietf-cdni-logging-26.txt 
Internet Engineering Task Force F. Le Faucheur, Ed. Internet Engineering Task Force F. Le Faucheur, Ed.
Internet-Draft Cisco Systems Internet-Draft
Intended status: Standards Track G. Bertrand, Ed. Intended status: Standards Track G. Bertrand, Ed.
Expires: October 9, 2016 Orange Expires: November 26, 2016 Orange
I. Oprescu, Ed. I. Oprescu, Ed.
R. Peterkofsky R. Peterkofsky
Google Inc. Google Inc.
April 7, 2016 May 25, 2016
CDNI Logging Interface CDNI Logging Interface
draft-ietf-cdni-logging-25 draft-ietf-cdni-logging-26
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 40 skipping to change at page 1, line 40
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 October 9, 2016. This Internet-Draft will expire on November 26, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 37 skipping to change at page 2, line 37
2.2.5.4. Content Protection . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . 14 Applications . . . . . . . . . . . . . . . . . . 14
3. CDNI Logging File . . . . . . . . . . . . . . . . . . . . . . 16 3. CDNI Logging File . . . . . . . . . . . . . . . . . . . . . . 16
3.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2. CDNI Logging File Structure . . . . . . . . . . . . . . . 17 3.2. CDNI Logging File Structure . . . . . . . . . . . . . . . 17
3.3. CDNI Logging Directives . . . . . . . . . . . . . . . . . 20 3.3. CDNI Logging Directives . . . . . . . . . . . . . . . . . 20
3.4. CDNI Logging Records . . . . . . . . . . . . . . . . . . 24 3.4. CDNI Logging Records . . . . . . . . . . . . . . . . . . 24
3.4.1. HTTP Request Logging Record . . . . . . . . . . . . . 25 3.4.1. HTTP Request Logging Record . . . . . . . . . . . . . 25
3.5. CDNI Logging File Extension . . . . . . . . . . . . . . . 36 3.5. CDNI Logging File Extension . . . . . . . . . . . . . . . 36
3.6. CDNI Logging File Example . . . . . . . . . . . . . . . . 36 3.6. CDNI Logging File Examples . . . . . . . . . . . . . . . 36
3.7. Cascaded CDNI Logging Files Example . . . . . . . . . . . 38 3.7. Cascaded CDNI Logging Files Example . . . . . . . . . . . 39
4. Protocol for Exchange of CDNI Logging File After Full 4. Protocol for Exchange of CDNI Logging File After Full
Collection . . . . . . . . . . . . . . . . . . . . . . . . . 41 Collection . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.1. CDNI Logging Feed . . . . . . . . . . . . . . . . . . . . 42 4.1. CDNI Logging Feed . . . . . . . . . . . . . . . . . . . . 43
4.1.1. Atom Formatting . . . . . . . . . . . . . . . . . . . 42 4.1.1. Atom Formatting . . . . . . . . . . . . . . . . . . . 43
4.1.2. Updates to Log Files and the Feed . . . . . . . . . . 42 4.1.2. Updates to Log Files and the Feed . . . . . . . . . . 43
4.1.3. Redundant Feeds . . . . . . . . . . . . . . . . . . . 43 4.1.3. Redundant Feeds . . . . . . . . . . . . . . . . . . . 44
4.1.4. Example CDNI Logging Feed . . . . . . . . . . . . . . 43 4.1.4. Example CDNI Logging Feed . . . . . . . . . . . . . . 44
4.2. CDNI Logging File Pull . . . . . . . . . . . . . . . . . 45 4.2. CDNI Logging File Pull . . . . . . . . . . . . . . . . . 46
5. Protocol for Exchange of CDNI Logging File During Collection 46 5. Protocol for Exchange of CDNI Logging File During Collection 47
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
6.1. CDNI Logging Directive Names Registry . . . . . . . . . . 47 6.1. CDNI Logging Directive Names Registry . . . . . . . . . . 48
6.2. CDNI Logging File version Registry . . . . . . . . . . . 48 6.2. CDNI Logging File version Registry . . . . . . . . . . . 49
6.3. CDNI Logging record-types Registry . . . . . . . . . . . 48 6.3. CDNI Logging record-types Registry . . . . . . . . . . . 49
6.4. CDNI Logging Field Names Registry . . . . . . . . . . . . 49 6.4. CDNI Logging Field Names Registry . . . . . . . . . . . . 50
6.5. CDNI Logging MIME Media Type . . . . . . . . . . . . . . 50 6.5. CDNI Logging MIME Media Type . . . . . . . . . . . . . . 51
7. Security Considerations . . . . . . . . . . . . . . . . . . . 51 7. Security Considerations . . . . . . . . . . . . . . . . . . . 52
7.1. Authentication, Authorization, Confidentiality, Integrity 7.1. Authentication, Authorization, Confidentiality, Integrity
Protection . . . . . . . . . . . . . . . . . . . . . . . 51 Protection . . . . . . . . . . . . . . . . . . . . . . . 52
7.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 52 7.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 53
7.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 52 7.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 53
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 55
9.1. Normative References . . . . . . . . . . . . . . . . . . 54 9.1. Normative References . . . . . . . . . . . . . . . . . . 55
9.2. Informative References . . . . . . . . . . . . . . . . . 55 9.2. Informative References . . . . . . . . . . . . . . . . . 57
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58
1. Introduction 1. Introduction
This memo specifies the CDNI Logging interface between a downstream This memo specifies the CDNI Logging interface between a downstream
CDN (dCDN) and an upstream CDN (uCDN). First, it describes a CDN (dCDN) and an upstream CDN (uCDN). First, it describes a
reference model for CDNI logging. Then, it specifies the CDNI reference model for CDNI logging. Then, it specifies the CDNI
Logging File format and the actual protocol for exchange of CDNI Logging File format and the actual protocol for exchange of CDNI
Logging Files. Logging Files.
The reader should be familiar with the following documents: The reader should be familiar with the following documents:
skipping to change at page 28, line 20 skipping to change at page 28, line 20
Expand Key Derivation Function (HKDF) key derivation Expand Key Derivation Function (HKDF) key derivation
([RFC5869]), as will be used in TLS 1.3 ([RFC5869]), as will be used in TLS 1.3
([I-D.ietf-tls-rfc5246-bis]). When that method is used: ([I-D.ietf-tls-rfc5246-bis]). When that method is used:
o The uCDN and dCDN need to agree on the "salt" and o The uCDN and dCDN need to agree on the "salt" and
"input keying material", as described in Section 2.2 "input keying material", as described in Section 2.2
of [RFC5869] and the initial "info" parameter (which of [RFC5869] and the initial "info" parameter (which
could be something like the business names of the two could be something like the business names of the two
organizations in UTF-8, concatenated), as described in organizations in UTF-8, concatenated), as described in
Section 2.3 of [RFC5869]. The hash SHOULD be either Section 2.3 of [RFC5869]. The hash SHOULD be either
SHA-2 or SHA-3 and the encryption algorithm SHOULD be SHA-2 or SHA-3 [SHA-3] and the encryption algorithm
128-bit AES-GCM or better. The PRK SHOULD be chosen SHOULD be 128-bit AES [AES] in Galois Counter Mode
by both parties contributing alternate random bytes (GCM) [GCM] (AES-GCM) or better. The PRK SHOULD be
until sufficient length exists. After the initial chosen by both parties contributing alternate random
setup, client-information can be encrypted using the bytes until sufficient length exists. After the
key generated by the "expand" step of Section 2.3 of initial setup, client-information can be encrypted
[RFC5869]. The encrypted value SHOULD be hex or using the key generated by the "expand" step of
base64 encoded. At the agreed-upon expiration time, a Section 2.3 of [RFC5869]. The encrypted value SHOULD
new key SHOULD be generated and used. New keys SHOULD be hex encoded or base64 encoded (as specified in
be indicated by prefixing the key with a special section 4 of [RFC4648]). At the agreed-upon
character such as exclamation point. In this way, expiration time, a new key SHOULD be generated and
shorter lifetimes can be used as needed. used. New keys SHOULD be indicated by prefixing the
key with a special character such as exclamation
point. In this way, shorter lifetimes can be used as
needed.
* 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 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).
skipping to change at page 36, line 13 skipping to change at page 36, line 18
confusion with the logging record separators. confusion with the logging record separators.
3.5. CDNI Logging File Extension 3.5. CDNI Logging File Extension
The CDNI Logging File contains blocks of directives and blocks of The CDNI Logging File contains blocks of directives and blocks of
corresponding records. The supported set of directives is defined corresponding records. The supported set of directives is defined
relative to the CDNI Logging File Format version. The complete set relative to the CDNI Logging File Format version. The complete set
of directives for version "CDNI/1.0" are defined in Section 3.3. The of directives for version "CDNI/1.0" are defined in Section 3.3. The
directive list is not expected to require much extension, but when it directive list is not expected to require much extension, but when it
does, the new directive MUST be defined and registered in the "CDNI does, the new directive MUST be defined and registered in the "CDNI
Logging Directive Names" registry, as described in Figure 8, and a Logging Directive Names" registry, as described in Figure 9, and a
new version MUST be defined and registered in the "CDNI Logging File new version MUST be defined and registered in the "CDNI Logging File
version" registry, as described in Section 6.2. For example, adding version" registry, as described in Section 6.2. For example, adding
a new CDNI Logging Directive, e.g., "foo", to the set of directives a new CDNI Logging Directive, e.g., "foo", to the set of directives
defined for "CDNI/1.0" in Section 3.3, would require registering both defined for "CDNI/1.0" in Section 3.3, would require registering both
the new CDNI Logging Directive "foo" and a new CDNI Logging File the new CDNI Logging Directive "foo" and a new CDNI Logging File
version, e.g., "CDNI/2.0", which includes all of the existing CDNI version, e.g., "CDNI/2.0", which includes all of the existing CDNI
Logging Directives of "CDNI/1.0" plus "foo". Logging Directives of "CDNI/1.0" plus "foo".
It is expected that as new logging requirements arise, the list of It is expected that as new logging requirements arise, the list of
fields to log will change and expand. When adding new fields, the fields to log will change and expand. When adding new fields, the
new fields MUST be defined and registered in the "CDNI Logging Field new fields MUST be defined and registered in the "CDNI Logging Field
Names" registry, as described in Section 6.4, and a new record-type Names" registry, as described in Section 6.4, and a new record-type
MUST be defined and registered in the "CDNI Logging record-types" MUST be defined and registered in the "CDNI Logging record-types"
registry, as described in Section 6.3. For example, adding a new registry, as described in Section 6.3. For example, adding a new
CDNI Logging Field, e.g., "c-bar", to the set of fields defined for CDNI Logging Field, e.g., "c-bar", to the set of fields defined for
"cdni_http_request_v1" in Section 3.4.1, would require registering "cdni_http_request_v1" in Section 3.4.1, would require registering
both the new CDNI Logging Field "c-bar" and a new CDNI record-type, both the new CDNI Logging Field "c-bar" and a new CDNI record-type,
e.g., "cdni_http_request_v2", which includes all of the existing CDNI e.g., "cdni_http_request_v2", which includes all of the existing CDNI
Logging Fields of "cdni_http_request_v1" plus "c-bar". Logging Fields of "cdni_http_request_v1" plus "c-bar".
3.6. CDNI Logging File Example 3.6. CDNI Logging File Examples
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>
skipping to change at page 38, line 35 skipping to change at page 38, line 35
time to complete the pull of the CDNI Logging File. Therefore, if we time to complete the pull of the CDNI Logging File. Therefore, if we
consider the set of Logging Records aggregated by the Collection consider the set of Logging Records aggregated by the Collection
process in uCDN in a given time interval, there could be a permanent process in uCDN in a given time interval, there could be a permanent
significant timing difference between the CDNI Logging Records significant timing difference between the CDNI Logging Records
received from the dCDN and the Logging Records generated locally. received from the dCDN and the Logging Records generated locally.
For example, in a given time interval, the Collection process in uCDN For example, in a given time interval, the Collection process in uCDN
may be aggregating Logging Records generated locally by uCDN for may be aggregating Logging Records generated locally by uCDN for
deliveries performed in the last hour and CDNI Logging Records deliveries performed in the last hour and CDNI Logging Records
generated in the dCDN for deliveries in the hour before last. generated in the dCDN for deliveries in the hour before last.
Say, that for some reason (for example a Surrogate bug), dCDN-1 could
not collect the total number of bytes of the responses sent by the
Surrogate (in other words, the value for sc-total-bytes is not
available). Then the corresponding CDNI Logging records would
contain a dash character ("-") in lieu of the value for the sc-total-
bytes field (as specified in Section 3.4.1). In that case, the CDNI
Logging File that would be communicated by dCDN-1 to uCDN is shown
below in Figure 5.
#version:<HTAB>cdni/1.0<CRLF>
#UUID:<HTAB>urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6<CRLF>
#claimed-origin:<HTAB>cdni-logging-entity.dcdn-1.example.com<CRLF>
#record-type:<HTAB>cdni_http_request_v1<CRLF>
#fields:<HTAB>date<HTAB>time<HTAB>time-taken<HTAB>c-groupid<HTAB>
cs-method<HTAB>u-uri<HTAB>protocol<HTAB>
sc-status<HTAB>sc-total-bytes<HTAB>cs(User-Agent)<HTAB>
cs(Referer)<HTAB>s-cached<CRLF>
2013-05-17<HTAB>00:38:06.825<HTAB>9.058<HTAB>US/TN/MEM/38138<HTAB>
GET<HTAB>
http://cdni-ucdn.dcdn-1.example.com/video/movie100.mp4<HTAB>
HTTP/1.1<HTAB>200<HTAB>-<HTAB>"Mozilla/5.0
(Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like
Gecko) Chrome/5.0.375.127 Safari/533.4"<HTAB>
"host1.example.com"<HTAB>1<CRLF>
2013-05-17<HTAB>00:39:09.145<HTAB>15.32<HTAB>FR/PACA/NCE/06100<HTAB>
GET<HTAB>
http://cdni-ucdn.dcdn-1.example.com/video/movie118.mp4<HTAB>
HTTP/1.1<HTAB>200<HTAB>-<HTAB>"Mozilla/5.0
(Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like
Gecko) Chrome/5.0.375.127 Safari/533.4"<HTAB>
"host1.example.com"<HTAB>1<CRLF>
2013-05-17<HTAB>00:42:53.437<HTAB>52.879<HTAB>US/TN/MEM/38138<HTAB>
GET<HTAB>
http://cdni-ucdn.dcdn-1.example.com/video/picture11.mp4<HTAB>
HTTP/1.0<HTAB>200<HTAB>-<HTAB>"Mozilla/5.0
(Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like
Gecko) Chrome/5.0.375.127 Safari/533.4"<HTAB>
"host5.example.com"<HTAB>0<CRLF>
#SHA256-hash:<HTAB> 64-hexadecimal-digit hash value <CRLF>
Figure 5: CDNI Logging File Example With A Missing Field Value
3.7. Cascaded CDNI Logging Files Example 3.7. Cascaded CDNI Logging Files Example
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 6. 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 6 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>
skipping to change at page 39, line 28 skipping to change at page 40, line 31
2013-05-17<HTAB>00:39:09.119<HTAB>14.07<HTAB>US/CA/SFO/94114<HTAB> 2013-05-17<HTAB>00:39:09.119<HTAB>14.07<HTAB>US/CA/SFO/94114<HTAB>
GET<HTAB> GET<HTAB>
http://cdni-dcdn-2.dcdn-3.example.com/video/movie118.mp4<HTAB> http://cdni-dcdn-2.dcdn-3.example.com/video/movie118.mp4<HTAB>
HTTP/1.1<HTAB>200<HTAB>15799210<HTAB>"Mozilla/5.0 HTTP/1.1<HTAB>200<HTAB>15799210<HTAB>"Mozilla/5.0
(Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like
Gecko) Chrome/5.0.375.127 Safari /533.4"<HTAB> Gecko) Chrome/5.0.375.127 Safari /533.4"<HTAB>
"host1.example.com"<HTAB>1<CRLF> "host1.example.com"<HTAB>1<CRLF>
#SHA256-hash:<HTAB> 64-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 6: Cascaded CDNI Logging File Example (dCDN-3 to dCDN-2)
If dCDN-2 establishes by some means (e.g., via TLS authentication If dCDN-2 establishes by some means (e.g., via TLS authentication
when pulling the CDNI Logging File) the identity of the entity from when 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 which it pulled the CDNI Logging File, dCDN-2 can add to the CDNI
Logging an established-origin directive as illustrated below: Logging 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>
dCDN-2 (behaving as an upstream CDN from the viewpoint of dCDN-3) dCDN-2 (behaving as an upstream CDN from the viewpoint of dCDN-3)
skipping to change at page 39, line 52 skipping to change at page 41, line 7
locally by dCDN-2 for deliveries performed by dCDN-2 itself. Say, locally by dCDN-2 for deliveries performed by dCDN-2 itself. Say,
for illustration, that the content delivery performed by dCDN-3 on for illustration, that the content delivery performed by dCDN-3 on
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 7.
#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-groupid<HTAB> #fields:<HTAB>date<HTAB>time<HTAB>time-taken<HTAB>c-groupid<HTAB>
skipping to change at page 40, line 36 skipping to change at page 41, line 40
2013-05-17<HTAB>01:42:53.437<HTAB>52.879<HTAB>FR/IDF/PAR/75001<HTAB> 2013-05-17<HTAB>01:42:53.437<HTAB>52.879<HTAB>FR/IDF/PAR/75001<HTAB>
GET<HTAB> GET<HTAB>
http://cdni-ucdn.dcdn-2.example.com/video/picture11.mp4<HTAB> http://cdni-ucdn.dcdn-2.example.com/video/picture11.mp4<HTAB>
HTTP/1.0<HTAB>200<HTAB>97234724<HTAB>"Mozilla/5.0 HTTP/1.0<HTAB>200<HTAB>97234724<HTAB>"Mozilla/5.0
(Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like
Gecko) Chrome/5.0.375.127 Safari /533.4"<HTAB> Gecko) Chrome/5.0.375.127 Safari /533.4"<HTAB>
"host5.example.com"<HTAB>0<CRLF> "host5.example.com"<HTAB>0<CRLF>
#SHA256-hash:<HTAB> 64-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 7: 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>
In the example of Figure 6, we observe that: In the example of Figure 7, we observe that:
o the first Logging Record corresponds to the Logging Record o the first Logging Record corresponds to the Logging Record
communicated earlier to dCDN-2 by dCDN-3, which corresponds to a communicated earlier to dCDN-2 by dCDN-3, which corresponds to a
delivery redirected by uCDN to dCDN-2 and then redirected by delivery redirected by uCDN to dCDN-2 and then redirected by
dCDN-2 to dCDN-3. The fields values in this Logging Record are dCDN-2 to dCDN-3. The fields values in this Logging Record are
copied from the corresponding CDNI Logging REcord communicated to copied from the corresponding CDNI Logging REcord communicated to
dCDN2 by dCDN-3, with the exception of the u-uri that now reflects dCDN2 by dCDN-3, with the exception of the u-uri that now reflects
the URI convention between uCDN and dCDN-2 and that presents the the URI convention between uCDN and dCDN-2 and that presents the
delivery to uCDN as if it was performed by dCDN-2 itself. This delivery to uCDN as if it was performed by dCDN-2 itself. This
reflects the fact that dCDN-2 had taken the full responsibility of reflects the fact that dCDN-2 had taken the full responsibility of
skipping to change at page 43, line 45 skipping to change at page 44, line 49
than one feed. than one feed.
A client-side implementation MAY support such redundant CDNI Logging A client-side implementation MAY support such redundant CDNI Logging
feeds. If it supports redundant CDNI Logging feed, the client-side feeds. If it supports redundant CDNI Logging feed, the client-side
can use the UUID of the CDNI Logging File, presented in the atom:id can use the UUID of the CDNI Logging File, presented in the atom:id
element of the Atom feed, to avoid unnecessarily pulling and storing element of the Atom feed, to avoid unnecessarily pulling and storing
a given CDNI Logging File more than once. a given CDNI Logging File more than once.
4.1.4. Example CDNI Logging Feed 4.1.4. Example CDNI Logging Feed
Figure 7 illustrates an example of the subscription document of a Figure 8 illustrates an example of the subscription document of a
CDNI Logging feed. CDNI Logging feed.
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom"> <feed xmlns="http://www.w3.org/2005/Atom">
<title type="text">CDNI Logging Feed</title> <title type="text">CDNI Logging Feed</title>
<updated>2013-03-23T14:46:11Z</updated> <updated>2013-03-23T14:46:11Z</updated>
<id>urn:uuid:663ae677-40fb-e99a-049d-c5642916b8ce</id> <id>urn:uuid:663ae677-40fb-e99a-049d-c5642916b8ce</id>
<link href="https://dcdn.example/logfeeds/ucdn1" <link href="https://dcdn.example/logfeeds/ucdn1"
rel="self" type="application/atom+xml" /> rel="self" type="application/atom+xml" />
<link href="https://dcdn.example/logfeeds/ucdn1" <link href="https://dcdn.example/logfeeds/ucdn1"
skipping to change at page 44, line 49 skipping to change at page 45, line 49
ptype="logging-file"/> 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 8: 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 ([RFC7230],[RFC7231], [RFC7232], o MUST implement HTTP/1.1 ([RFC7230],[RFC7231], [RFC7232],
[RFC7233], [RFC7234], [RFC7235]), MAY also support other HTTP [RFC7233], [RFC7234], [RFC7235]), MAY also support other HTTP
skipping to change at page 47, line 36 skipping to change at page 48, line 36
| 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 |
| remark | RFC xxxx | | remark | RFC xxxx |
| record-type | RFC xxxx | | record-type | RFC xxxx |
| fields | RFC xxxx | | fields | RFC xxxx |
| SHA256-hash | RFC xxxx | | SHA256-hash | RFC xxxx |
+------------------------------+-----------+ +------------------------------+-----------+
Figure 8 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, 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 defined in the
defined in the logging file are case-insensitive as per the basic logging file are case-insensitive as per the basic ABNF([RFC5234]).
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 "CDNI Logging File version" The IANA is requested to create a new "CDNI Logging File version"
subregistry under the "Content Delivery Networks Interconnection subregistry under the "Content Delivery Networks Interconnection
skipping to change at page 48, line 22 skipping to change at page 49, line 22
registry comprise the value "CDNI/1.0" specified in Section 3.3 of registry comprise the value "CDNI/1.0" specified in Section 3.3 of
the present document, and are as follows: the present document, and are as follows:
+-----------------+-----------+----------------------------------+ +-----------------+-----------+----------------------------------+
| version | Reference | Description | | version | Reference | Description |
+-----------------+-----------+----------------------------------+ +-----------------+-----------+----------------------------------+
| cdni/1.0 | RFC xxxx | CDNI Logging File version 1.0 | | cdni/1.0 | RFC xxxx | CDNI Logging File version 1.0 |
| | | as specified in RFC xxxx | | | | as specified in RFC xxxx |
+-----------------+-----------+----------------------------------+ +-----------------+-----------+----------------------------------+
Figure 9 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, version values are to be allocated by IANA Within the registry, version values are to be allocated by IANA
according to the "Specification Required" policy specified in according to the "Specification Required" policy specified in
[RFC5226]. Version values are to be allocated by IANA with a format [RFC5226]. Version values are to be allocated by IANA with a format
of NAMEFORMAT (see Section 3.1). of NAMEFORMAT (see Section 3.1). All version values defined in the
logging file are case-insensitive as per the basic ABNF([RFC5234]).
6.3. CDNI Logging record-types Registry 6.3. CDNI Logging record-types Registry
The IANA is requested to create a new "CDNI Logging record-types" The IANA is requested to create a new "CDNI Logging record-types"
subregistry under the "Content Delivery Networks Interconnection subregistry under the "Content Delivery Networks Interconnection
(CDNI) Parameters" registry. (CDNI) Parameters" registry.
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 10 Figure 11
[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). NAMEFORMAT (see Section 3.1). All record-types defined in the
logging file are case-insensitive as per the basic ABNF([RFC5234]).
Each specification that defines a new record-type needs to contain a Each specification that defines a new record-type needs to contain a
description for the new record-type with the same set of information description for the new record-type with the same set of information
as provided in Section 3.4.1. This includes: as provided in Section 3.4.1. This includes:
o a list of all the CDNI Logging fields that can appear in a CDNI o a list of all the CDNI Logging fields that can appear in a CDNI
Logging Record of the new record-type Logging Record of the new record-type
o for all these fields: a specification of the occurrence for each o for all these fields: a specification of the occurrence for each
Field in the new record-type Field in the new record-type
skipping to change at page 50, line 29 skipping to change at page 51, line 29
| 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(insert_HTTP_header_name_here) | RFC xxxx | | cs(insert_HTTP_header_name_here) | RFC xxxx |
| sc(insert_HTTP_header_name_here) | RFC xxxx | | sc(insert_HTTP_header_name_here) | 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 11 Figure 12
[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). All field names defined in the logging file are case-
insensitive as per the basic ABNF([RFC5234]).
6.5. CDNI Logging MIME Media Type 6.5. CDNI Logging MIME Media Type
The IANA is requested to register the following new Payload Type in The IANA is requested to register the following new Payload Type in
the CDNI Payload Type registry for use with the application/cdni MIME the CDNI Payload Type registry for use with the application/cdni MIME
media type. media type.
[RFC Editor Note: Please replace the references to [RFCthis] below [RFC Editor Note: Please replace the references to [RFCthis] below
with this document's RFC number before publication.] with this document's RFC number before publication.]
+----------------------+---------------+ +----------------------+---------------+
| Payload Type | Specification | | Payload Type | Specification |
+----------------------+---------------+ +----------------------+---------------+
| logging-file | [RFCthis] | | logging-file | [RFCthis] |
+----------------------+---------------+ +----------------------+---------------+
Figure 12: MIME Media Type payload Figure 13: MIME Media Type payload
The purpose of the logging-file payload type is to distinguish The purpose of the logging-file payload type is to distinguish
between CDNI Logging Files and other CDNI messages. between CDNI Logging Files and other CDNI messages.
Interface: LI Interface: LI
Encoding: see Section 3.2, Section 3.3 and Section 3.4 Encoding: see Section 3.2, Section 3.3 and Section 3.4
7. Security Considerations 7. Security Considerations
skipping to change at page 52, line 19 skipping to change at page 53, line 19
additional integrity protection, this time targeting potential additional integrity protection, this time targeting potential
corruption of the CDNI logging information during the CDNI Logging corruption of the CDNI logging information during the CDNI Logging
File generation, storage or exchange. This mechanism does not itself File generation, storage or exchange. This mechanism does not itself
allow restoration of the corrupted CDNI Logging information, but it allow restoration of the corrupted CDNI Logging information, but it
allows detection of such corruption and therefore triggering of allows detection of such corruption and therefore triggering of
appropriate corrective actions (e.g., discard of corrupted appropriate corrective actions (e.g., discard of corrupted
information, attempt to re-obtain the CDNI Logging information). information, attempt to re-obtain the CDNI Logging information).
Note that the SHA256-hash does not protect against tampering by a Note that the SHA256-hash does not protect against tampering by a
third party, since such a third party could have recomputed and third party, since such a third party could have recomputed and
updated the SHA256-hash after tampering. Protection against third updated the SHA256-hash after tampering. Protection against third
party tampering can be achieved as discussed above through the use of party tampering when the CDNI Logging File is communicated over the
TLS. CDN Logging Interface can be achieved as discussed above through the
use of TLS.
7.2. Denial of Service 7.2. Denial of Service
This document does not define specific mechanism to protect against This document does not define specific mechanism to protect against
Denial of Service (DoS) attacks on the Logging Interface. However, Denial of Service (DoS) attacks on the Logging Interface. However,
the CDNI Logging feed and CDNI Logging pull endpoints are typically the CDNI Logging feed and CDNI Logging pull endpoints are typically
to be accessed only by a very small number of valid remote endpoints to be accessed only by a very small number of valid remote endpoints
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).
skipping to change at page 54, line 15 skipping to change at page 55, line 15
Finally, we also thank Sebastien Cubaud, Pawel Grochocki, Christian Finally, we also thank Sebastien Cubaud, Pawel Grochocki, Christian
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
[AES] NIST, "Advanced Encryption Standard (AES)", August 2015,
<FIPS 197>.
[GCM] NIST, "Recommendation for Block Cipher Modes of Operation:
Galois/Counter Mode (GCM) and GMAC", November 2007, <SP
800-38D>.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<http://www.rfc-editor.org/info/rfc3339>. <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
skipping to change at page 54, line 38 skipping to change at page 55, line 45
[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, Unique IDentifier (UUID) URN Namespace", RFC 4122,
DOI 10.17487/RFC4122, July 2005, DOI 10.17487/RFC4122, July 2005,
<http://www.rfc-editor.org/info/rfc4122>. <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, DOI 10.17487/RFC4287, Syndication Format", RFC 4287, DOI 10.17487/RFC4287,
December 2005, <http://www.rfc-editor.org/info/rfc4287>. December 2005, <http://www.rfc-editor.org/info/rfc4287>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<http://www.rfc-editor.org/info/rfc4648>.
[RFC5005] Nottingham, M., "Feed Paging and Archiving", RFC 5005, [RFC5005] Nottingham, M., "Feed Paging and Archiving", RFC 5005,
DOI 10.17487/RFC5005, September 2007, DOI 10.17487/RFC5005, September 2007,
<http://www.rfc-editor.org/info/rfc5005>. <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,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc5226>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
skipping to change at page 55, line 46 skipping to change at page 57, line 10
"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, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <http://www.rfc-editor.org/info/rfc7525>. 2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
<http://www.rfc-editor.org/info/rfc7540>. <http://www.rfc-editor.org/info/rfc7540>.
[SHA-3] NIST, "SHA-3 STANDARD: PERMUTATION-BASED HASH AND
EXTENDABLE OUTPUT FUNCTIONS", November 2001,
<http://dx.doi.org/10.6028/NIST.FIPS.202>.
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-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-13 (work in progress), March 2016. metadata-17 (work in progress), May 2016.
[I-D.ietf-tls-rfc5246-bis] [I-D.ietf-tls-rfc5246-bis]
Dierks, T. and E. Rescorla, "The Transport Layer Security Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.3", draft-ietf-tls-rfc5246-bis-00 (TLS) Protocol Version 1.3", draft-ietf-tls-rfc5246-bis-00
(work in progress), April 2014. (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.
skipping to change at page 57, line 33 skipping to change at page 58, line 47
DOI 10.17487/RFC7337, August 2014, DOI 10.17487/RFC7337, August 2014,
<http://www.rfc-editor.org/info/rfc7337>. <http://www.rfc-editor.org/info/rfc7337>.
[RFC7736] Ma, K., "Content Delivery Network Interconnection (CDNI) [RFC7736] Ma, K., "Content Delivery Network Interconnection (CDNI)
Media Type Registration", RFC 7736, DOI 10.17487/RFC7736, Media Type Registration", RFC 7736, DOI 10.17487/RFC7736,
December 2015, <http://www.rfc-editor.org/info/rfc7736>. December 2015, <http://www.rfc-editor.org/info/rfc7736>.
Authors' Addresses Authors' Addresses
Francois Le Faucheur (editor) Francois Le Faucheur (editor)
Cisco Systems
E.Space Park - Batiment D
6254 Allee des Ormes - BP 1200
Mougins cedex 06254
FR
Phone: +33 4 97 23 26 19
Email: flefauch@cisco.com
Phone: +33 6 19 98 50 90
Email: flefauch@gmail.com
Gilles Bertrand (editor) Gilles Bertrand (editor)
Orange Orange
38-40 rue du General Leclerc 38-40 rue du General Leclerc
Issy les Moulineaux 92130 Issy les Moulineaux 92130
FR FR
Phone: +33 1 45 29 89 46 Phone: +33 1 45 29 89 46
Email: gilles.bertrand@orange.com Email: gilles.bertrand@orange.com
Iuniana Oprescu (editor) Iuniana Oprescu (editor)
FR FR
Email: iuniana.oprescu@gmail.com Email: iuniana.oprescu@gmail.com
Roy Peterkofsky Roy Peterkofsky
Google Inc. Google Inc.
345 Spear St, 4th Floor 345 Spear St, 4th Floor
San Francisco CA 94105 San Francisco CA 94105
USA USA
 End of changes. 38 change blocks. 
75 lines changed or deleted 142 lines changed or added

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