RFC 7937
Content Distribution Network Interconnection (CDNI) Logging Interface
Pages: 63
Proposed Standard
Proposed Standard
Part 3 of 3 – Pages 44 to 63
4. Protocol for Exchange of CDNI Logging File after Full Collection
This section specifies a protocol for the exchange of CDNI Logging Files as specified in Section 3 after the CDNI Logging File is fully collected by the dCDN. This protocol comprises: o a CDNI Logging feed, allowing the dCDN to notify the uCDN about the CDNI Logging Files that can be retrieved by that uCDN from the dCDN, as well as all the information necessary for retrieving each of these CDNI Logging Files. The CDNI Logging feed is specified in Section 4.1. o a CDNI Logging File pull mechanism, allowing the uCDN to obtain from the dCDN a given CDNI Logging File at the uCDN's convenience. The CDNI Logging File pull mechanism is specified in Section 4.2.
An implementation of the CDNI Logging interface on the dCDN side (the entity generating the CDNI Logging File) MUST support the server side of the CDNI Logging feed (as specified in Section 4.1) and the server side of the CDNI Logging pull mechanism (as specified in Section 4.2). An implementation of the CDNI Logging interface on the uCDN side (the entity consuming the CDNI Logging File) MUST support the client side of the CDNI Logging feed (as specified in Section 4.1) and the client side of the CDNI Logging pull mechanism (as specified in Section 4.2).4.1. CDNI Logging Feed
The server-side implementation of the CDNI Logging feed MUST produce an Atom feed [RFC4287]. This feed is used to advertise log files that are available for the client-side to retrieve using the CDNI Logging pull mechanism.4.1.1. Atom Formatting
A CDNI Logging feed MUST be structured as an Archived feed, as defined in [RFC5005], and MUST be formatted in Atom [RFC4287]. This means it consists of a subscription document that is regularly updated as new CDNI Logging Files become available, and information about older CDNI Logging Files is moved into archive documents. Once created, archive documents are never modified. Each CDNI Logging File listed in an Atom feed MUST be described in an atom:entry container element. The atom:entry MUST contain an atom:content element whose "src" attribute is a link to the CDNI Logging File and whose "type" attribute is the MIME Media Type indicating that the entry is a CDNI Logging File. This MIME Media Type is defined as "application/cdni" (See [RFC7736]) with the Payload Type (ptype) parameter set to "logging-file". For compatibility with some Atom feed readers, the atom:entry MAY also contain an atom:link entry whose "href" attribute is a link to the CDNI Logging File and whose "type" attribute is the MIME Media Type indicating that the entry is a CDNI Logging File using the "application/cdni" MIME Media Type with the Payload Type (ptype) parameter set to "logging-file" (see [RFC7736]).
The URI used in the atom:id of the atom:entry MUST contain the UUID of the CDNI Logging File. The atom:updated in the atom:entry MUST indicate the time at which the CDNI Logging File was last updated.4.1.2. Updates to Log Files and the Feed
CDNI Logging Files MUST NOT be modified by the dCDN once published in the CDNI Logging feed. The frequency with which the subscription feed is updated, the period of time covered by each CDNI Logging File or each archive document, and timeliness of publishing of CDNI Logging Files are outside the scope of the present document and are expected to be agreed upon by uCDN and dCDN via other means (e.g., human agreement). The server-side implementation MUST be able to set, and SHOULD set, HTTP-cache control headers on the subscription feed to indicate the frequency at which the client-side is to poll for updates. The client-side MAY use HTTP-cache control headers (set by the server-side) on the subscription feed to determine the frequency at which to poll for updates. The client-side MAY instead, or in addition, use other information to determine when to poll for updates (e.g., a polling frequency that may have been negotiated between the uCDN and dCDN by mechanisms outside the scope of the present document and that is to override the indications provided in the HTTP-cache control headers). The potential retention limits (e.g., sliding time window) within which the dCDN is to retain and be ready to serve an archive document is outside the scope of the present document and is expected to be agreed upon by uCDN and dCDN via other means (e.g., human agreement). The server-side implementation MUST retain, and be ready to serve, any archive document within the agreed retention limits. Outside these agreed limits, the server-side implementation MAY indicate its inability to serve (e.g., with HTTP status code 404) an archive document or MAY refuse to serve it (e.g., with HTTP status code 403 or 410).
4.1.3. Redundant Feeds
The server-side implementation MAY present more than one CDNI Logging feed for redundancy. Each CDNI Logging File MAY be published in more than one feed. A client-side implementation MAY support such redundant CDNI Logging feeds. If it supports a redundant CDNI Logging feed, the client-side 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 a given CDNI Logging File more than once.4.1.4. Example CDNI Logging Feed
Figure 8 illustrates an example of the subscription document of a CDNI Logging feed.
<?xml version="1.0" encoding="utf-8"?> <feed xmlns="http://www.w3.org/2005/Atom"> <title type="text">CDNI Logging Feed</title> <updated>2013-03-23T14:46:11Z</updated> <id>urn:uuid:663ae677-40fb-e99a-049d-c5642916b8ce</id> <link href="https://dcdn.example/logfeeds/ucdn1" rel="self" type="application/atom+xml" /> <link href="https://dcdn.example/logfeeds/ucdn1" rel="current" type="application/atom+xml" /> <link href="https://dcdn.example/logfeeds/ucdn1/201303231400" rel="prev-archive" type="application/atom+xml" /> <generator version="example version 1">CDNI Log Feed Generator</generator> <author><name>dcdn.example</name></author> <entry> <title type="text">CDNI Logging File for uCDN at 2013-03-23 14:15:00</title> <id>urn:uuid:12345678-1234-abcd-00aa-01234567abcd</id> <updated>2013-03-23T14:15:00Z</updated> <content src="https://dcdn.example/logs/ucdn/ http-requests-20130323141500000000" type="application/cdni" ptype="logging-file"/> <summary>CDNI Logging File for uCDN at 2013-03-23 14:15:00</summary> </entry> <entry> <title type="text">CDNI Logging File for uCDN at 2013-03-23 14:30:00</title> <id>urn:uuid:87654321-4321-dcba-aa00-dcba7654321</id> <updated>2013-03-23T14:30:00Z</updated> <content src="https://dcdn.example/logs/ucdn/ http-requests-20130323143000000000" type="application/cdni" ptype="logging-file"/> <summary>CDNI Logging File for uCDN at 2013-03-23 14:30:00</summary> </entry> ... <entry> ... </entry> </feed> Figure 8: Example Subscription Document of a CDNI Logging Feed
4.2. CDNI Logging File Pull
A client-side implementation of the CDNI Logging interface MAY pull, at its convenience, a CDNI Logging File that is published by the server-side in the CDNI Logging Feed (in the subscription document or an archive document). To do so, the client-side: o MUST implement HTTP/1.1 ([RFC7230] [RFC7231] [RFC7232] [RFC7233] [RFC7234] [RFC7235]), MAY also support other HTTP versions (e.g., HTTP/2 [RFC7540]), and MAY negotiate which HTTP version is actually used. This allows operators and implementers to choose to use later versions of HTTP to take advantage of new features, while still ensuring interoperability with systems that only support HTTP/1.1; o MUST use the URI that was associated to the CDNI Logging File (within the "src" attribute of the corresponding atom:content element) in the CDNI Logging Feed; o MUST support exchange of CDNI Logging Files with no content encoding applied to the representation; o MUST support exchange of CDNI Logging Files with "gzip" content encoding (as defined in [RFC7230]) applied to the representation. Note that a client-side implementation of the CDNI Logging interface MAY pull a CDNI Logging File that it has already pulled. The server-side implementation MUST respond to a valid pull request by a client-side implementation for a CDNI Logging File published by the server-side in the CDNI Logging Feed (in the subscription document or an archive document). The server-side implementation: o MUST implement HTTP/1.1 to handle the client-side request and MAY also support other HTTP versions (e.g., HTTP/2); o MUST include the CDNI Logging File identified by the request URI inside the body of the HTTP response; o MUST support exchange of CDNI Logging Files with no content encoding applied to the representation; o MUST support exchange of CDNI Logging Files with "gzip" content encoding (as defined in [RFC7231]) applied to the representation.
Content negotiation approaches defined in [RFC7231] (e.g., using Accept-Encoding request-header field or Content-Encoding entity- header field) MAY be used by the client-side and server-side implementations to establish the content coding to be used for a particular exchange of a CDNI Logging File. Applying compression content encoding (such as "gzip") is expected to mitigate the impact of exchanging the large volumes of logging information expected across CDNs. This is expected to be particularly useful in the presence of HTTP Adaptive Streaming (HAS) that, as per the present version of the document, will result in a separate CDNI Log Record for each HAS segment delivery in the CDNI Logging File. The potential retention limits (e.g., sliding time window and maximum aggregate file storage quotas) within which the dCDN is to retain and be ready to serve a CDNI Logging File previously advertised in the CDNI Logging Feed is outside the scope of the present document and is expected to be agreed upon by uCDN and dCDN via other means (e.g., human agreement). The server-side implementation MUST retain, and be ready to serve, any CDNI Logging File within the agreed retention limits. Outside these agreed limits, the server-side implementation MAY indicate its inability to serve (e.g., with HTTP status code 404) a CDNI Logging File or MAY refuse to serve it (e.g., with HTTP status code 403 or 410).5. Protocol for Exchange of CDNI Logging File During Collection
We note that, in addition to the CDNI Logging File exchange protocol specified in Section 4, implementations of the CDNI Logging interface may also support other mechanisms to exchange CDNI Logging Files. In particular, such mechanisms might allow the exchange of the CDNI Logging File to start before the file is fully collected. This can allow CDNI Logging Records to be communicated by the dCDN to the uCDN as they are gathered by the dCDN without having to wait until all the CDNI Logging Records of the same logging period are collected in the corresponding CDNI Logging File. This approach is commonly referred to as the "tailing" of the file. Such an approach could be used, for example, to exchange logging information with a significantly reduced time-lag (e.g., sub-minute or sub-second) between when the event occurred in the dCDN and when the corresponding CDNI Logging Record is made available to the uCDN. This can satisfy log-consuming applications requiring extremely fresh logging information such as near-real-time content delivery monitoring. Such mechanisms are for further study and are outside the scope of this document.
6. IANA Considerations
6.1. CDNI Logging Directive Names Registry
IANA has created a new "CDNI Logging Directive Names" subregistry under the "Content Delivery Networks Interconnection (CDNI) Parameters" registry. The initial contents of the "CDNI Logging Directives" registry comprise the names of the directives specified in Section 3.3 of the present document and are as follows: +------------------------------+-----------+ | Directive Name | Reference | +------------------------------+-----------+ | version | RFC 7937 | | UUID | RFC 7937 | | claimed-origin | RFC 7937 | | established-origin | RFC 7937 | | remark | RFC 7937 | | record-type | RFC 7937 | | fields | RFC 7937 | | SHA256-hash | RFC 7937 | +------------------------------+-----------+ Figure 9: CDNI Logging Directive Names Registry Within the registry, names are to be allocated by IANA according to the "Specification Required" policy specified in [RFC5226]. Directive names are to be allocated by IANA with a format of NAMEFORMAT (see Section 3.1). All directive names defined in the Logging File are case-insensitive as per the basic ABNF ([RFC5234]). Each specification that defines a new CDNI Logging directive needs to contain a description for the new directive with the same set of information as provided in Section 3.3 (i.e., format, directive value, and occurrence).6.2. CDNI Logging File version Registry
IANA has created a new "CDNI Logging File version" subregistry under the "Content Delivery Networks Interconnection (CDNI) Parameters" registry.
The initial contents of the "CDNI Logging File version" registry comprise the value "cdni/1.0" specified in Section 3.3 of the present document and are as follows: +-----------------+-----------+----------------------------------+ | version | Reference | Description | +-----------------+-----------+----------------------------------+ | cdni/1.0 | RFC 7937 | CDNI Logging File version 1.0 | | | | as specified in RFC 7937 | +-----------------+-----------+----------------------------------+ Figure 10: CDNI Logging File version Registry Within the registry, version values are to be allocated by IANA according to the "Specification Required" policy specified in [RFC5226]. Version values are to be allocated by IANA with a format 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
IANA has created a new "CDNI Logging record-types" subregistry under the "Content Delivery Networks Interconnection (CDNI) Parameters" registry. The initial contents of the "CDNI Logging record-types" registry comprise the names of the CDNI Logging record-types specified in Section 3.4 of the present document and are as follows: +----------------------+-----------+---------------------------------+ | record-types | Reference | Description | +----------------------+-----------+---------------------------------+ | cdni_http_request_v1 | RFC 7937 | CDNI Logging Record version 1 | | | | for content delivery using HTTP | +----------------------+-----------+---------------------------------+ Figure 11: CDNI Logging record-types Registry Within the registry, record-types are to be allocated by IANA according to the "Specification Required" policy specified in [RFC5226]. Record-types are to be allocated by IANA with a format of 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 description for the new record-type with the same set of information as provided in Section 3.4.1. This includes: o A list of all the CDNI Logging fields that can appear in a CDNI Logging Record of the new record-type o For all these fields: a specification of the occurrence for each Field in the new record-type o For every newly defined Field, i.e., for every Field that results in a registration in the "CDNI Logging Field Names" registry (Section 6.4): a specification of the field name, format, and field value.6.4. CDNI Logging Field Names Registry
IANA has created a new "CDNI Logging Field Names" subregistry under the "Content Delivery Networks Interconnection (CDNI) Parameters" registry. This registry is intended to be shared across the currently defined record-type (i.e., cdni_http_request_v1) as well as potentially other CDNI Logging record-types that may be defined in separate specifications. When a field from this registry is used by another CDNI Logging record-type, it is to be used with the exact semantics and format specified in the document that registered this field and that is identified in the Reference column of the registry. If another CDNI Logging record-type requires a field with semantics that are not strictly identical, or a format that is not strictly identical, then this new field is to be registered in the registry with a different field name. When a field from this registry is used by another CDNI Logging record-type, it can be used with different occurrence rules.
The initial contents of the "CDNI Logging Fields Names" registry comprise the names of the CDNI Logging fields specified in Section 3.4 of the present document and are as follows: +------------------------------------------+-----------+ | Field Name | Reference | +------------------------------------------+-----------+ | date | RFC 7937 | | time | RFC 7937 | | time-taken | RFC 7937 | | c-groupid | RFC 7937 | | s-ip | RFC 7937 | | s-hostname | RFC 7937 | | s-port | RFC 7937 | | cs-method | RFC 7937 | | cs-uri | RFC 7937 | | u-uri | RFC 7937 | | protocol | RFC 7937 | | sc-status | RFC 7937 | | sc-total-bytes | RFC 7937 | | sc-entity-bytes | RFC 7937 | | cs(insert_HTTP_header_name_here) | RFC 7937 | | sc(insert_HTTP_header_name_here) | RFC 7937 | | s-ccid | RFC 7937 | | s-sid | RFC 7937 | | s-cached | RFC 7937 | +------------------------------------------+-----------+ Figure 12: CDNI Logging Field Names Registry Within the registry, names are to be allocated by IANA according to the "Specification Required" policy specified in [RFC5226]. Field names are to be allocated by IANA with a format of NHTABSTRING (see Section 3.1). All field names defined in the Logging File are case- insensitive as per the basic ABNF ([RFC5234]).
6.5. CDNI Logging Payload Type
IANA has registered the following new Payload Type in the "CDNI Payload Types" registry for use with the application/cdni MIME media type. +----------------------+---------------+ | Payload Type | Specification | +----------------------+---------------+ | logging-file | RFC 7937] | +----------------------+---------------+ Figure 13: CDNI Logging Payload Type The purpose of the logging-file payload type is to distinguish between CDNI Logging Files and other CDNI messages. o Interface: LI o Encoding: See Section 3.2, Section 3.3, and Section 3.47. Security Considerations
7.1. Authentication, Authorization, Confidentiality, and Integrity Protection
An implementation of the CDNI Logging interface MUST support TLS transport of the CDNI Logging feed (Section 4.1) and of the CDNI Logging File pull (Section 4.2) as per [RFC2818] and [RFC7230]. TLS MUST be used by the server-side and the client-side of the CDNI Logging feed, as well as the server-side and the client-side of the CDNI Logging File pull mechanism, including authentication of the remote end, unless alternate methods are used for ensuring the security of the information exchanged over the LI interface (such as setting up an IPsec tunnel between the two CDNs or using a physically secured internal network between two CDNs that are owned by the same corporate entity). The use of TLS for transport of the CDNI Logging feed and CDNI Logging File pull allows: o the dCDN and uCDN to authenticate each other using TLS client auth and TLS server auth.
And, once they have mutually authenticated each other, it allows:
o the dCDN and uCDN to authorize each other (to ensure they are
transmitting/receiving CDNI Logging File to/from an authorized
CDN).
o the CDNI Logging information to be transmitted with
confidentiality.
o the integrity of the CDNI Logging information to be protected
during the exchange.
When TLS is used, the general TLS usage guidance in [RFC7525] MUST be
followed.
The SHA256-hash directive inside the CDNI Logging File provides
additional integrity protection, this time targeting potential
corruption of the CDNI Logging information during the CDNI Logging
File generation, storage, or exchange. This mechanism does not
itself allow restoration of the corrupted CDNI Logging information,
but it allows detection of such corruption, and therefore triggering
of appropriate corrective actions (e.g., discard of corrupted
information, and attempt to re-obtain the CDNI Logging information).
Note that the SHA256-hash does not protect against tampering by a
third party, since such a third party could have recomputed and
updated the SHA256-hash after tampering. Protection against third-
party tampering, when the CDNI Logging File is communicated over the
CDN Logging interface, can be achieved as discussed above through the
use of TLS.
7.2. Denial of Service
This document does not define a specific mechanism to protect against
Denial-of-Service (DoS) attacks on the Logging interface. However,
the CDNI Logging feed and CDNI Logging pull endpoints are typically
to be accessed only by a very small number of valid remote endpoints,
and therefore can be easily protected against DoS attacks through the
usual conventional DoS-protection mechanisms such as firewalling or
use of Virtual Private Networks (VPNs).
Protection of dCDN Surrogates against spoofed delivery requests is
outside the scope of the CDNI Logging interface.
7.3. Privacy
CDNs have the opportunity to collect detailed information about the downloads performed by end users. A dCDN is expected to collect such information into CDNI Logging Files, which are then communicated to a uCDN. Having detailed CDNI Logging information known by the dCDN in itself does not represent a particular privacy concern since the dCDN is obviously fully aware of all information logged since it generated the information in the first place. Transporting detailed CDNI Logging information over the HTTP-based CDNI Logging interface does not represent a particular privacy concern because it is protected by the usual privacy-protection mechanism (e.g., TLS). When HTTP redirection is used between the uCDN and the dCDN, making detailed CDNI Logging information known to the uCDN does not represent a particular privacy concern because the uCDN is already exposed at request redirection time to most of the information that shows up as CDNI Logging information (e.g., end-user IP address, URL, and HTTP headers). When DNS redirection is used between the uCDN and the dCDN, there are cases where there is no privacy concern in making detailed CDNI logging information known to the uCDN; this may be the case, for example, where (1) it is considered that because the uCDN has the authority (with respect to the CSP) and control on how the requests are delivered (including whether it is served by the uCDN itself or by a dCDN), the uCDN is entitled to access all detailed information related to the corresponding deliveries, and (2) there is no legal reason to restrict access by the uCDN to all this detailed information. Conversely still, when DNS redirection is used between the uCDN and the dCDN, there are cases where there may be some privacy concern in making detailed CDNI Logging information known to the uCDN; this may be the case, for example, because the uCDN is in a different jurisdiction to the dCDN, resulting is some legal reasons to restrict access by the uCDN to all the detailed information related to the deliveries. In this latter case, the privacy concerns can be taken into account when the uCDN and dCDN agree about which fields are to be conveyed inside the CDNI Logging Files and which privacy protection mechanism is to be used as discussed in the definition of the c-groupid field specified in Section 3.4.1. Another privacy concern arises from the fact that large volumes of detailed information about content delivery to users, potentially traceable back to individual users, may be collected in CDNI Logging Files. These CDNI Logging Files represent high-value targets, likely concentrated in a fairly centralized system (although the CDNI
Logging architecture does not mandate a particular level of centralization/distribution) and 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, etc.). This privacy concern calls for some protection. The collection of large volumes of such information into CDNI Logging Files introduces potential end-users' privacy protection concerns. Mechanisms to address these concerns are discussed in the definition of the c-groupid field specified in Section 3.4.1. The use of mutually authenticated TLS to establish a secure session for the transport of the CDNI Logging feed and CDNI Logging pull as discussed in Section 7.1 provides confidentiality while the Logging information is in transit and prevents any party other than the authorized uCDN to gain access to the logging information. We also note that the query string portion of the URL that may be conveyed inside the cs-uri and u-uri fields of CDNI Logging Files, or the HTTP cookies( [RFC6265]) that may be conveyed as part of the cs(<HTTP-header-name>) field of CDNI Logging Files, may contain personal information or information that can be exploited to derive personal information. Where this is a concern, the CDNI Logging interface specification allows the dCDN to not include the cs-uri and to include a u-uri that removes (or hides) the sensitive part of the query string and allows the dCDN to not include the cs(<HTTP-header- name>) fields corresponding to HTTP headers associated with cookies.8. References
8.1. Normative References
[AES] NIST, "Advanced Encryption Standard (AES)", National Institute of Standards and Technology FIPS 197, November 2001, <http://csrc.nist.gov/publications/fips/fips197/ fips-197.pdf>. [GCM] NIST, "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", National Institute of Standards and Technology SP 800-38D, DOI 10.6028/NIST.SP.800-38D, November 2007, <http://csrc.nist.gov/publications/nistpubs/800-38D/ SP-800-38D.pdf>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 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 Resource Identifier (URI): Generic Syntax", STD 66, 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 Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, <http://www.rfc-editor.org/info/rfc4122>. [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom Syndication Format", RFC 4287, DOI 10.17487/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, DOI 10.17487/RFC5005, September 2007, <http://www.rfc-editor.org/info/rfc5005>. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>. [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>. [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 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., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, DOI 10.17487/RFC7232, June 2014, <http://www.rfc-editor.org/info/rfc7232>. [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, DOI 10.17487/RFC7233, June 2014, <http://www.rfc-editor.org/info/rfc7233>. [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, <http://www.rfc-editor.org/info/rfc7234>. [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 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, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (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, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, <http://www.rfc-editor.org/info/rfc7540>. [SHA-3] NIST, "SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions", National Institute of Standards and Technology FIPS 202, DOI 10.6028/NIST.FIPS.202, August 2015, <http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf>.
8.2. Informative References
[ATOMPUB] Snell, J., "Atom Link Extensions", Work in Progress, draft-snell-atompub-link-extensions-09, June 2012. [CDNI-META] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, "CDN Interconnection Metadata", Work in Progress, draft-ietf-cdni-metadata-20, August 2016. [CHAR_SET] IANA, "Character Sets", <http://www.iana.org/assignments/character-sets>. [ELF] Phillip M. Hallam-Baker, and Brian Behlendorf, "Extended Log File Format", W3C Working Draft, WD-logfile-960323, <http://www.w3.org/TR/WD-logfile.html>. [RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext 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, DOI 10.17487/RFC2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>. [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 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, DOI 10.17487/RFC6265, April 2011, <http://www.rfc-editor.org/info/rfc6265>. [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content Distribution Network Interconnection (CDNI) Problem Statement", RFC 6707, DOI 10.17487/RFC6707, September 2012, <http://www.rfc-editor.org/info/rfc6707>.
[RFC6770] Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley, P., Ma, K., and G. Watson, "Use Cases for Content Delivery 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., and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware Content Distribution Network Interconnection (CDNI)", RFC 6983, DOI 10.17487/RFC6983, July 2013, <http://www.rfc-editor.org/info/rfc6983>. [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., "Framework for Content Distribution Network Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, August 2014, <http://www.rfc-editor.org/info/rfc7336>. [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution Network Interconnection (CDNI) Requirements", RFC 7337, DOI 10.17487/RFC7337, August 2014, <http://www.rfc-editor.org/info/rfc7337>. [RFC7736] Ma, K., "Content Delivery Network Interconnection (CDNI) Media Type Registration", RFC 7736, DOI 10.17487/RFC7736, December 2015, <http://www.rfc-editor.org/info/rfc7736>. [TLS-1.3] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", Work in Progress, draft-ietf-tls-tls13-15, August 2016.
Acknowledgments
This document borrows from the W3C Extended Log Format [ELF]. Rob Murray significantly contributed into the text of Section 4.1. The authors thank Ben Niven-Jenkins, Kevin Ma, David Mandelberg, and Ray van Brandenburg for their ongoing input. Brian Trammel and Rich Salz made significant contributions into making this interface privacy-friendly. Finally, we also thank Sebastien Cubaud, Pawel Grochocki, Christian Jacquenet, Yannick Le Louedec, Anne Marrec, Emile Stephan, Fabio Costa, Sara Oueslati, Yvan Massot, Renaud Edel, Joel Favier, and the contributors of the EU FP7 OCEAN project for their input in the early draft versions of this document.Authors' Addresses
Francois Le Faucheur (editor) France Phone: +33 6 19 98 50 90 Email: flefauch@gmail.com Gilles Bertrand (editor) Phone: +41 76 675 91 44 Email: gilbertrand@gmail.com Iuniana Oprescu (editor) France Email: iuniana.oprescu@gmail.com Roy Peterkofsky Google Inc. 345 Spear St, 4th Floor San Francisco CA 94105 United States of America Email: peterkofsky@google.com