tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7937

 
 
 

Content Distribution Network Interconnection (CDNI) Logging Interface

Part 3 of 3, p. 44 to 63
Prev Section

 


prevText      Top      ToC       Page 44 
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.

Top      Up      ToC       Page 45 
   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]).

Top      Up      ToC       Page 46 
   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).

Top      Up      ToC       Page 47 
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.

Top      Up      ToC       Page 48 
   <?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

Top      Up      ToC       Page 49 
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.

Top      Up      ToC       Page 50 
   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.

Top      Up      ToC       Page 51 
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.

Top      Up      ToC       Page 52 
   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]).

Top      Up      ToC       Page 53 
   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.

Top      Up      ToC       Page 54 
   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]).

Top      Up      ToC       Page 55 
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.4

7.  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.

Top      Up      ToC       Page 56 
   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.

Top      Up      ToC       Page 57 
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

Top      Up      ToC       Page 58 
   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>.

Top      Up      ToC       Page 59 
   [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>.

Top      Up      ToC       Page 60 
   [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>.

Top      Up      ToC       Page 61 
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>.

Top      Up      ToC       Page 62 
   [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.

Top      Up      ToC       Page 63 
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