draft-ietf-cdni-logging-22.txt   draft-ietf-cdni-logging-23.txt 
Internet Engineering Task Force F. Le Faucheur, Ed. Internet Engineering Task Force F. Le Faucheur, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track G. Bertrand, Ed. Intended status: Standards Track G. Bertrand, Ed.
Expires: September 3, 2016 I. Oprescu, Ed. Expires: September 19, 2016 Orange
Orange I. Oprescu, Ed.
R. Peterkofsky R. Peterkofsky
Skytide, Inc. Google Inc.
March 2, 2016 March 18, 2016
CDNI Logging Interface CDNI Logging Interface
draft-ietf-cdni-logging-22 draft-ietf-cdni-logging-23
Abstract Abstract
This memo specifies the Logging interface between a downstream CDN This memo specifies the Logging interface between a downstream CDN
(dCDN) and an upstream CDN (uCDN) that are interconnected as per the (dCDN) and an upstream CDN (uCDN) that are interconnected as per the
CDN Interconnection (CDNI) framework. First, it describes a CDN Interconnection (CDNI) framework. First, it describes a
reference model for CDNI logging. Then, it specifies the CDNI reference model for CDNI logging. Then, it specifies the CDNI
Logging File format and the actual protocol for exchange of CDNI Logging File format and the actual protocol for exchange of CDNI
Logging Files. Logging Files.
skipping to change at page 1, line 39 skipping to change at page 1, line 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 September 3, 2016. This Internet-Draft will expire on September 19, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. CDNI Logging Reference Model . . . . . . . . . . . . . . . . 5 2. CDNI Logging Reference Model . . . . . . . . . . . . . . . . 5
2.1. CDNI Logging interactions . . . . . . . . . . . . . . . . 5 2.1. CDNI Logging interactions . . . . . . . . . . . . . . . . 5
2.2. Overall Logging Chain . . . . . . . . . . . . . . . . . . 8 2.2. Overall Logging Chain . . . . . . . . . . . . . . . . . . 8
2.2.1. Logging Generation and During-Generation Aggregation 9 2.2.1. Logging Generation and During-Generation Aggregation 9
2.2.2. Logging Collection . . . . . . . . . . . . . . . . . 10 2.2.2. Logging Collection . . . . . . . . . . . . . . . . . 10
2.2.3. Logging Filtering . . . . . . . . . . . . . . . . . . 10 2.2.3. Logging Filtering . . . . . . . . . . . . . . . . . . 10
2.2.4. Logging Rectification and Post-Generation Aggregation 11 2.2.4. Logging Rectification and Post-Generation Aggregation 11
2.2.5. Log-Consuming Applications . . . . . . . . . . . . . 12 2.2.5. Log-Consuming Applications . . . . . . . . . . . . . 12
2.2.5.1. Maintenance/Debugging . . . . . . . . . . . . . . 12 2.2.5.1. Maintenance/Debugging . . . . . . . . . . . . . . 12
2.2.5.2. Accounting . . . . . . . . . . . . . . . . . . . 13 2.2.5.2. Accounting . . . . . . . . . . . . . . . . . . . 13
2.2.5.3. Analytics and Reporting . . . . . . . . . . . . . 13 2.2.5.3. Analytics and Reporting . . . . . . . . . . . . . 13
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 Example . . . . . . . . . . . . . . . . 35 3.5. CDNI Logging File Extension . . . . . . . . . . . . . . . 35
3.6. Cascaded CDNI Logging Files Example . . . . . . . . . . . 37 3.6. CDNI Logging File Example . . . . . . . . . . . . . . . . 36
3.7. Cascaded CDNI Logging Files Example . . . . . . . . . . . 38
4. Protocol for Exchange of CDNI Logging File After Full 4. Protocol for Exchange of CDNI Logging File After Full
Collection . . . . . . . . . . . . . . . . . . . . . . . . . 40 Collection . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.1. CDNI Logging Feed . . . . . . . . . . . . . . . . . . . . 41 4.1. CDNI Logging Feed . . . . . . . . . . . . . . . . . . . . 42
4.1.1. Atom Formatting . . . . . . . . . . . . . . . . . . . 41 4.1.1. Atom Formatting . . . . . . . . . . . . . . . . . . . 42
4.1.2. Updates to Log Files and the Feed . . . . . . . . . . 41 4.1.2. Updates to Log Files and the Feed . . . . . . . . . . 42
4.1.3. Redundant Feeds . . . . . . . . . . . . . . . . . . . 42 4.1.3. Redundant Feeds . . . . . . . . . . . . . . . . . . . 43
4.1.4. Example CDNI Logging Feed . . . . . . . . . . . . . . 42 4.1.4. Example CDNI Logging Feed . . . . . . . . . . . . . . 43
4.2. CDNI Logging File Pull . . . . . . . . . . . . . . . . . 44 4.2. CDNI Logging File Pull . . . . . . . . . . . . . . . . . 45
5. Protocol for Exchange of CDNI Logging File During Collection 45 5. Protocol for Exchange of CDNI Logging File During Collection 46
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
6.1. CDNI Logging Directive Names Registry . . . . . . . . . . 46 6.1. CDNI Logging Directive Names Registry . . . . . . . . . . 47
6.2. CDNI Logging File version Registry . . . . . . . . . . . 47 6.2. CDNI Logging File version Registry . . . . . . . . . . . 48
6.3. CDNI Logging record-types Registry . . . . . . . . . . . 47 6.3. CDNI Logging record-types Registry . . . . . . . . . . . 48
6.4. CDNI Logging Field Names Registry . . . . . . . . . . . . 48 6.4. CDNI Logging Field Names Registry . . . . . . . . . . . . 49
6.5. CDNI Logging MIME Media Type . . . . . . . . . . . . . . 49 6.5. CDNI Logging MIME Media Type . . . . . . . . . . . . . . 50
7. Security Considerations . . . . . . . . . . . . . . . . . . . 51
7. Security Considerations . . . . . . . . . . . . . . . . . . . 50
7.1. Authentication, Authorization, Confidentiality, Integrity 7.1. Authentication, Authorization, Confidentiality, Integrity
Protection . . . . . . . . . . . . . . . . . . . . . . . 50 Protection . . . . . . . . . . . . . . . . . . . . . . . 51
7.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 51 7.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 52
7.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 51 7.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 52
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 54
9.1. Normative References . . . . . . . . . . . . . . . . . . 53 9.1. Normative References . . . . . . . . . . . . . . . . . . 54
9.2. Informative References . . . . . . . . . . . . . . . . . 54 9.2. Informative References . . . . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57
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 7, line 43 skipping to change at page 7, line 46
===> CDNI Logging Interface ===> CDNI Logging Interface
***> outside the scope of CDNI ***> outside the scope of CDNI
Figure 1: Interactions in CDNI Logging Reference Model Figure 1: Interactions in CDNI Logging Reference Model
A downstream CDN relative to uCDN (e.g., dCDN-2) integrates the A downstream CDN relative to uCDN (e.g., dCDN-2) integrates the
relevant Logging information obtained from its own downstream CDNs relevant Logging information obtained from its own downstream CDNs
(i.e., dCDN-3) in the Logging information that it provides to the (i.e., dCDN-3) in the Logging information that it provides to the
uCDN, so that the uCDN ultimately obtains all Logging information uCDN, so that the uCDN ultimately obtains all Logging information
relevant to a CSP for which it acts as the authoritative CDN. Such relevant to a CSP for which it acts as the authoritative CDN. Such
aggregation is further discussed in Section 3.6. aggregation is further discussed in Section 3.7.
Note that the format of Logging information that a CDN provides over Note that the format of Logging information that a CDN provides over
the CDNI interface might be different from the one that the CDN uses the CDNI interface might be different from the one that the CDN uses
internally. In this case, the CDN needs to reformat the Logging internally. In this case, the CDN needs to reformat the Logging
information before it provides this information to the other CDN over information before it provides this information to the other CDN over
the CDNI Logging interface. Similarly, a CDN might reformat the the CDNI Logging interface. Similarly, a CDN might reformat the
Logging information that it receives over the CDNI Logging interface Logging information that it receives over the CDNI Logging interface
before injecting it into its log-consuming applications or before before injecting it into its log-consuming applications or before
providing some of this Logging information to the CSP. Such providing some of this Logging information to the CSP. Such
reformatting operations introduce latency in the logging distribution reformatting operations introduce latency in the logging distribution
skipping to change at page 20, line 24 skipping to change at page 20, line 24
":" HTAB and the directive value. ":" HTAB and the directive value.
Directive names MUST be of the format NAMEFORMAT. All directive Directive names MUST be of the format NAMEFORMAT. All directive
names MUST be registered in the CDNI Logging Directives Names names MUST be registered in the CDNI Logging Directives Names
registry. Unknown directives MUST be ignored. Directive values can registry. Unknown directives MUST be ignored. Directive values can
have various formats. All possible directive values for the record- have various formats. All possible directive values for the record-
type "cdni_http_request_v1" are further detailed in this section. type "cdni_http_request_v1" are further detailed in this section.
The following example shows the structure of a directive and The following example shows the structure of a directive and
enumerates strictly the directive values presently defined in the enumerates strictly the directive values presently defined in the
record-type "cdni_http_request_v1." version "CDNI/1.0" of the CDNI Logging File.
directive = DIRNAME ":" HTAB DIRVAL directive = DIRNAME ":" HTAB DIRVAL
DIRNAME = NAMEFORMAT DIRNAME = NAMEFORMAT
DIRVAL = NHTABSTRING / QSTRING / host / USER-COMMENT / FIENAME * DIRVAL = NHTABSTRING / QSTRING / host / USER-COMMENT / FIENAME *
(HTAB FIENAME) / 64HEXDIG (HTAB FIENAME) / 64HEXDIG
An implementation of the CDNI Logging interface MUST support all of An implementation of the CDNI Logging interface MUST support all of
the following directives, listed below by their directive name: the following directives, listed below by their directive name:
skipping to change at page 22, line 46 skipping to change at page 22, line 46
directive per CDNI Logging File. The first instance of this directive per CDNI Logging File. The first instance of this
directive MUST precede a fields directive and MUST precede all directive MUST precede a fields directive and MUST precede all
CDNI Logging Records. CDNI Logging Records.
* example: "record-type: HTAB cdni_http_request_v1". * example: "record-type: HTAB cdni_http_request_v1".
o fields: o fields:
* format: FIENAME *(HTAB FIENAME) ; where FIENAME can take any * format: FIENAME *(HTAB FIENAME) ; where FIENAME can take any
CDNI Logging field name registered in the CDNI Logging Field CDNI Logging field name registered in the CDNI Logging Field
Names registry (Section 6.4). Names registry (Section 6.4) that is valid for the record type
specified in the record-type directive.
* directive value: this lists the names of all the fields for * directive value: this lists the names of all the fields for
which a value is to appear in the CDNI Logging Records that which a value is to appear in the CDNI Logging Records that
follow the instance of this directive (until another instance follow the instance of this directive (until another instance
of this directive). The names of the fields, as well as their of this directive). The names of the fields, as well as their
occurrences, MUST comply with the corresponding rules specified occurrences, MUST comply with the corresponding rules specified
in the document referenced in the CDNI Logging Record-types in the document referenced in the CDNI Logging Record-types
registry (Section 6.3) for the corresponding CDNI Logging registry (Section 6.3) for the corresponding CDNI Logging
record-type. record-type.
skipping to change at page 27, line 12 skipping to change at page 27, line 12
into aggregates. Example aggregates include civil geolocation into aggregates. Example aggregates include civil geolocation
information (the country, second-level administrative division, information (the country, second-level administrative division,
or postal code from which the client is presumed to make the or postal code from which the client is presumed to make the
request based on a geolocation database lookup) or network request based on a geolocation database lookup) or network
topological information (e.g., the BGP AS number announcing the topological information (e.g., the BGP AS number announcing the
prefix containing the address). The c-groupid MAY be prefix containing the address). The c-groupid MAY be
structured e.g., US/TN/MEM/38138. Agreement between the dCDN structured e.g., US/TN/MEM/38138. Agreement between the dCDN
and the uCDN on a mapping between IPv4 and IPv6 addresses and and the uCDN on a mapping between IPv4 and IPv6 addresses and
aggregates is presumed to occur out-of-band. The aggregation aggregates is presumed to occur out-of-band. The aggregation
mapping SHOULD be chosen such that each aggregate contains more mapping SHOULD be chosen such that each aggregate contains more
than one client. When the aggregate is chosen so that it than one client.
contains a single client (e.g., to allow more detailed
analytics, or to allow a-posteriori analysis of individual
delivery for example in situations of performance-based
penalties):
+ the c-groupid MAY be structured (e.g., US/TN/ + When the aggregate is chosen so that it contains a single
MEM/38138/43a5bdd6-95c4-4d62-be65-7410df0021e2) where some client (e.g., to allow more detailed analytics, or to allow
elements identify aggregates and one element identifies the a-posteriori analysis of individual delivery for example in
client. situations of performance-based penalties) the c-groupid MAY
be structured where some elements identify aggregates and
one element identifies the client, e.g., US/TN/
MEM/38138/43a5bdd6-95c4-4d62-be65-7410df0021e2. In that
case:
+ the address with a shared secret that is pre-synchronised - the element identifying the client SHOULD be
and rotated at a predefined time interval. It is algorithmically generated (from the client IPv4 or IPv6
RECOMMENDED that the mapping varies at least once every 24 address in the request received by the Surrogate and/or
hours. The mapping from IP address to the element other network-level identifying information) in a way
identifying the client (effectively an encryption of the that SHOULD NOT be linkable back to the global addressing
address) SHOULD be done using a symmetric key that is known context and that SHOULD vary over time (to offer
only to both the uCDN and dCDN. One method of doing this is protection against long term attacks).
to use an analog of how key derivation is via HKDF
([RFC5869]), as will be used in TLS 1.3
([I-D.ietf-tls-rfc5246-bis]). When the two CDNs set up the
relationship, they agree out-of-band on a mapping between
IPv4 and IPv6 addresses and aggregates and on the
algorithmic mapping from IPv4/IPv6 addresses and the element
identifying the client; they agree on the salt and input key
material, as described in [RFC5869], Section 2.2, the hash
mechanism to use (SHA-2 or SHA-3 SHOULD be used), and the
key lifetime which SHOULD NOT exceed 25 hours. They also
agree on an initial "info" parameter, which can be something
such as the business names of the two organizations in UTF-
8, concatenated. The encryption algorithm also needs to be
defined, and SHOULD be 128-bit AES-GCM or better. The PRK
should be chosen by both parties contributing alternate
random bytes until sufficient length exists. After this
initial setup, client-information is encrypted using the key
generated by the "expand" step, Section 2.3 of [RFC5869],
and hex-encoded or base64-encoded. At the agreed-upon
lifetime, a new key is used, indicated by prefixing the key
with a special character such as exclamation point. In this
way, shorter lifetimes can be used as needed.
+ the element identifying the client SHOULD be algorithmically - It is RECOMMENDED that the mapping varies at least once
generated (from the client IPv4 or IPv6 address in the every 24 hours.
request received by the Surrogate and/or other network-level
identifying information) in a way that SHOULD NOT be
linkable back to the global addressing context and that
SHOULD vary over time (to offer protection against long term
attacks); one example way to achieve this is to hash.
+ The algorithmic mapping and variation over time MAY allow - The algorithmic mapping and variation over time MAY allow
the uCDN (with the knowledge of the algorithm and time the uCDN (with the knowledge of the algorithm and time
variation and associated attributes and keys) to reconstruct variation and associated attributes and keys) to
the actual enduser IPv4/IPv6 addresses where that is reconstruct the actual client IPv4 or IPv6 address and/or
required (e.g., to allow a-posteriori analysis of individual other network-level identifying information when required
delivery for example in situations of performance-based (e.g., to allow a-posteriori analysis of individual
penalties). However, these enduser IPv4/IPv6 addresses delivery for example in situations of performance-based
SHOULD only be reconstructed on-demand and the CDNI Logging penalties). However, these enduser addresses SHOULD only
File SHOULD only be stored with the anonymised c-groupid be reconstructed on-demand and the CDNI Logging File
value. SHOULD only be stored with the anonymised c-groupid
value.
+ Using the c-groupid field in this way carries with it grave - Allowing reconstruction of client address information
risks to end-user privacy. Since the c-groupid is in this carries with it grave risks to end-user privacy. Since
case equivalent in identification power to a client IP the c-groupid is in this case equivalent in
address, its use may be restricted by regulation or law as identification power to a client IP address, its use may
personally identifiable information. For this reason, such be restricted by regulation or law as personally
use is NOT RECOMMENDED. identifiable information. For this reason, such use is
NOT RECOMMENDED.
- One method for mapping that MAY be be supported by
implementations relies on a symmetric key that is known
only to the uCDN and dCDN and HMAC-based Extract-and-
Expand Key Derivation Function (HKDF) key derivation
([RFC5869]), as will be used in TLS 1.3
([I-D.ietf-tls-rfc5246-bis]). When that method is used:
o The uCDN and dCDN need to agree on the "salt" and
"input keying material", as described in Section 2.2
of [RFC5869] and the initial "info" parameter (which
could be something like the business names of the two
organizations in UTF-8, concatenated), as described in
Section 2.3 of [RFC5869]. The hash SHOULD be either
SHA-2 or SHA-3 and the encryption algorithm SHOULD be
128-bit AES-GCM or better. The PRK SHOULD be chosen
by both parties contributing alternate random bytes
until sufficient length exists. After the initial
setup, client-information can be encrypted using the
key generated by the "expand" step of Section 2.3 of
[RFC5869]. The encrypted value SHOULD be hex or
base64 encoded. At the agreed-upon expiration time, a
new key SHOULD be generated and 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 35, line 46 skipping to change at page 35, line 46
do not contain field values for exactly the set of field names do not contain field values for exactly the set of field names
actually listed in the preceding "fields" directive, the actually listed in the preceding "fields" directive, the
implementation MUST reject those HTTP Request Logging Records, and implementation MUST reject those HTTP Request Logging Records, and
MUST accept the other HTTP Request Logging Records. MUST accept the other HTTP Request Logging Records.
To ensure that the logging file is correct, the text MUST be To ensure that the logging file is correct, the text MUST be
sanitized before being logged. Null, bare CR, bare LF and HTAB have sanitized before being logged. Null, bare CR, bare LF and HTAB have
to be removed by escaping them through percent encoding to avoid to be removed by escaping them through percent encoding to avoid
confusion with the logging record separators. confusion with the logging record separators.
3.5. CDNI Logging File Example 3.5. CDNI Logging File Extension
The CDNI Logging File contains blocks of directives and blocks of
corresponding records. The supported set of directives is defined
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
directive list is not expected to require much extension, but when it
does, the new directive MUST be defined and registered in the "CDNI
Logging Directive Names" registry, as described in Figure 8, and a
new version MUST be defined and registered in the "CDNI Logging File
version" registry, as described in Section 6.2. For example, adding
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
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
Logging Directives of "CDNI/1.0" plus "foo".
It is expected that as new logging requirements arise, the list of
fields to log will change and expand. When adding new fields, the
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
MUST be defined and registered in the "CDNI Logging record-types"
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_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,
e.g., "cdni_http_request_v2", which includes all of the existing CDNI
Logging Fields of "cdni_http_request_v1" plus "c-bar".
3.6. CDNI Logging File Example
Let us consider the upstream CDN and the downstream CDN labelled uCDN Let us consider the upstream CDN and the downstream CDN labelled uCDN
and dCDN-1 in Figure 1. When dCDN-1 acts as a downstream CDN for and dCDN-1 in Figure 1. When dCDN-1 acts as a downstream CDN for
uCDN and performs content delivery on behalf of uCDN, dCDN-1 will uCDN and performs content delivery on behalf of uCDN, dCDN-1 will
include the CDNI Logging Records corresponding to the content include the CDNI Logging Records corresponding to the content
deliveries performed on behalf of uCDN in the CDNI Logging Files for deliveries performed on behalf of uCDN in the CDNI Logging Files for
uCDN. An example CDNI Logging File communicated by dCDN-1 to uCDN is uCDN. An example CDNI Logging File communicated by dCDN-1 to uCDN is
shown below in Figure 4. shown below in Figure 4.
#version:<HTAB>cdni/1.0<CRLF> #version:<HTAB>cdni/1.0<CRLF>
skipping to change at page 37, line 41 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.
3.6. 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 5. In practice, a CDNI Logging File is
likely to contain a very high number of CDNI Logging Records. likely to contain a very high number of CDNI Logging Records.
However, for readability, the example in Figure 5 contains a single However, for readability, the example in Figure 5 contains a single
CDNI Logging Record. CDNI Logging Record.
skipping to change at page 43, line 27 skipping to change at page 44, line 27
Generator</generator> Generator</generator>
<author><name>dcdn.example</name></author> <author><name>dcdn.example</name></author>
<entry> <entry>
<title type="text">CDNI Logging File for uCDN at <title type="text">CDNI Logging File for uCDN at
2013-03-23 14:15:00</title> 2013-03-23 14:15:00</title>
<id>urn:uuid:12345678-1234-abcd-00aa-01234567abcd</id> <id>urn:uuid:12345678-1234-abcd-00aa-01234567abcd</id>
<updated>2013-03-23T14:15:00Z</updated> <updated>2013-03-23T14:15:00Z</updated>
<content src="https://dcdn.example/logs/ucdn/ <content src="https://dcdn.example/logs/ucdn/
http-requests-20130323141500000000" http-requests-20130323141500000000"
type="application/cdni" type="application/cdni"
ptype="logging-file"/> ptype="logging-file"/>
<summary>CDNI Logging File for uCDN at <summary>CDNI Logging File for uCDN at
2013-03-23 14:15:00</summary> 2013-03-23 14:15:00</summary>
</entry> </entry>
<entry> <entry>
<title type="text">CDNI Logging File for uCDN at <title type="text">CDNI Logging File for uCDN at
2013-03-23 14:30:00</title> 2013-03-23 14:30:00</title>
<id>urn:uuid:87654321-4321-dcba-aa00-dcba7654321</id> <id>urn:uuid:87654321-4321-dcba-aa00-dcba7654321</id>
<updated>2013-03-23T14:30:00Z</updated> <updated>2013-03-23T14:30:00Z</updated>
<content src="https://dcdn.example/logs/ucdn/ <content src="https://dcdn.example/logs/ucdn/
http-requests-20130323143000000000" http-requests-20130323143000000000"
type="application/cdni" type="application/cdni"
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 7: Example subscription document of a CDNI Logging Feed
skipping to change at page 46, line 16 skipping to change at page 47, line 16
When IANA allocates new extensions to CDNI Logging Directive Names When IANA allocates new extensions to CDNI Logging Directive Names
Registry, CDNI Logging File version Registry, CDNI Logging record- Registry, CDNI Logging File version Registry, CDNI Logging record-
type Registry or CDNI Logging fields Registry, IANA MUST take into type Registry or CDNI Logging fields Registry, IANA MUST take into
account that the directive names are case-insensitive as per the account that the directive names are case-insensitive as per the
basic ABNF([RFC5234]). basic ABNF([RFC5234]).
6.1. CDNI Logging Directive Names Registry 6.1. CDNI Logging Directive Names Registry
The IANA is requested to create a new "CDNI Logging Directive Names" The IANA is requested to create a new "CDNI Logging Directive Names"
registry under the "Content Delivery Networks Interconnection (CDNI) subregistry under the "Content Delivery Networks Interconnection
Parameters" category. (CDNI) Parameters" registry.
The initial contents of the CDNI Logging Directives registry comprise The initial contents of the CDNI Logging Directives registry comprise
the names of the directives specified in Section 3.3 of the present the names of the directives specified in Section 3.3 of the present
document, and are as follows: document, and are as follows:
+------------------------------+-----------+ +------------------------------+-----------+
| Directive Name | Reference | | Directive Name | Reference |
+------------------------------+-----------+ +------------------------------+-----------+
| version | RFC xxxx | | version | RFC xxxx |
| UUID | RFC xxxx | | UUID | RFC xxxx |
skipping to change at page 47, line 8 skipping to change at page 48, line 8
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"
registry under the "Content Delivery Networks Interconnection (CDNI) subregistry under the "Content Delivery Networks Interconnection
Parameters" category. (CDNI) Parameters" registry.
The initial contents of the CDNI Logging Logging File version The initial contents of the CDNI Logging Logging File version
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 |
skipping to change at page 47, line 35 skipping to change at page 48, line 35
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).
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"
under the "Content Delivery Networks Interconnection (CDNI) subregistry under the "Content Delivery Networks Interconnection
Parameters" category. (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 |
skipping to change at page 48, line 27 skipping to change at page 49, line 27
Field in the new record-type Field in the new record-type
o for every newly defined Field, i.e., for every Field that results o for every newly defined Field, i.e., for every Field that results
in a registration in the CDNI Logging Field Names Registry in a registration in the CDNI Logging Field Names Registry
(Section 6.4): a specification of the field name, format and field (Section 6.4): a specification of the field name, format and field
value. value.
6.4. CDNI Logging Field Names Registry 6.4. CDNI Logging Field Names Registry
The IANA is requested to create a new "CDNI Logging Field Names" The IANA is requested to create a new "CDNI Logging Field Names"
under the "Content Delivery Networks Interconnection (CDNI) subregistry under the "Content Delivery Networks Interconnection
Parameters" category. (CDNI) Parameters" registry.
This registry is intended to be shared across the currently defined This registry is intended to be shared across the currently defined
record-type (i.e., cdni_http_request_v1) as well as potential other record-type (i.e., cdni_http_request_v1) as well as potential other
CDNI Logging record-types that may be defined in separate CDNI Logging record-types that may be defined in separate
specifications. When a Field from this registry is used by another specifications. When a Field from this registry is used by another
CDNI Logging record-type, it is to be used with the exact semantics CDNI Logging record-type, it is to be used with the exact semantics
and format specified in the document that registered this field and and format specified in the document that registered this field and
that is identified in the Reference column of the registry. If that is identified in the Reference column of the registry. If
another CDNI Logging record-type requires a Field with semantics that another CDNI Logging record-type requires a Field with semantics that
are not strictly identical, or a format that is not strictly are not strictly identical, or a format that is not strictly
skipping to change at page 57, line 5 skipping to change at page 58, line 5
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)
Orange
38-40 rue du General Leclerc
Issy les Moulineaux 92130
FR FR
Phone: +33 6 89 06 92 72 Email: iuniana.oprescu@gmail.com
Email: iuniana.oprescu@orange.com
Roy Peterkofsky Roy Peterkofsky
Skytide, Inc. Google Inc.
One Kaiser Plaza, Suite 785 345 Spear St, 4th Floor
Oakland CA 94612 San Francisco CA 94105
USA USA
Phone: +01 510 250 4284 Email: peterkofsky@google.com
Email: roy@skytide.com
 End of changes. 29 change blocks. 
118 lines changed or deleted 146 lines changed or added

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