draft-ietf-cdni-logging-12.txt   draft-ietf-cdni-logging-13.txt 
Internet Engineering Task Force F. Le Faucheur, Ed. Internet Engineering Task Force F. Le Faucheur, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track G. Bertrand, Ed. Intended status: Standards Track G. Bertrand, Ed.
Expires: January 5, 2015 I. Oprescu, Ed. Expires: January 25, 2015 I. Oprescu, Ed.
Orange Orange
R. Peterkofsky R. Peterkofsky
Skytide, Inc. Skytide, Inc.
July 4, 2014 July 24, 2014
CDNI Logging Interface CDNI Logging Interface
draft-ietf-cdni-logging-12 draft-ietf-cdni-logging-13
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 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 5, 2015. This Internet-Draft will expire on January 25, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 20, line 43 skipping to change at page 20, line 43
the entity transmitting the CDNI Logging File (e.g., the host the entity transmitting the CDNI Logging File (e.g., the host
in a dCDN supporting the CDNI Logging interface) or the entity in a dCDN supporting the CDNI Logging interface) or the entity
responsible for transmitting the CDNI Logging File (e.g., the responsible for transmitting the CDNI Logging File (e.g., the
dCDN). dCDN).
* occurrence: there MUST be zero or exactly one instance of this * occurrence: there MUST be zero or exactly one instance of this
directive per CDNI Logging File. This directive MAY be directive per CDNI Logging File. This directive MAY be
included by the dCDN. It MUST NOT be included or modified by included by the dCDN. It MUST NOT be included or modified by
the uCDN. the uCDN.
o Verified-Origin: o Established-Origin:
* format: host * format: host
* directive value: this contains the identification, as * directive value: this contains the identification, as
established by the entity receiving the CDNI Logging File, of established by the entity receiving the CDNI Logging File, of
the entity transmitting the CDNI Logging File (e.g., the host the entity transmitting the CDNI Logging File (e.g., the host
in a dCDN supporting the CDNI Logging interface) or the entity in a dCDN supporting the CDNI Logging interface) or the entity
responsible for transmitting the CDNI Logging File (e.g., the responsible for transmitting the CDNI Logging File (e.g., the
dCDN). dCDN).
skipping to change at page 22, line 35 skipping to change at page 22, line 35
receiving the CDNI Logging File also computes in a similar way receiving the CDNI Logging File also computes in a similar way
the MD5 hash on the received CDNI Logging File and compares the MD5 hash on the received CDNI Logging File and compares
this hash to the value of the Integrity-Hash directive. If the this hash to the value of the Integrity-Hash directive. If the
two values are equal, then the received CDNI Logging File MUST two values are equal, then the received CDNI Logging File MUST
be considered non-corrupted. If the two values are different, be considered non-corrupted. If the two values are different,
the received CDNI Logging File MUST be considered corrupted. the received CDNI Logging File MUST be considered corrupted.
The behavior of the entity that received a corrupted CDNI The behavior of the entity that received a corrupted CDNI
Logging File is outside the scope of this specification; we Logging File is outside the scope of this specification; we
note that the entity MAY attempt to pull again the same CDNI note that the entity MAY attempt to pull again the same CDNI
Logging File from the transmitting entity. If the entity Logging File from the transmitting entity. If the entity
receiving a non-corrupted CDNI Logging File adds a Verified- receiving a non-corrupted CDNI Logging File adds an
Origin directive, it MUST then recompute and update the Established-Origin directive, it MUST then recompute and update
Integrity-Hash directive so it also protects the added the Integrity-Hash directive so it also protects the added
Verified-Origin directive. Established-Origin directive.
* occurrence: there MUST be zero or exactly one instance of this * occurrence: there MUST be zero or exactly one instance of this
directive. There SHOULD be exactly one instance of this directive. There SHOULD be exactly one instance of this
directive. One situation where that directive could be omitted directive. One situation where that directive could be omitted
is where integrity protection is already provided via another is where integrity protection is already provided via another
mechanism (for example if an integrity hash is associated to mechanism (for example if an integrity hash is associated to
the CDNI Logging File out of band through the CDNI Logging Feed the CDNI Logging File out of band through the CDNI Logging Feed
( Section 4.1) leveraging ATOM extensions such as those ( Section 4.1) leveraging ATOM extensions such as those
proposed in [I-D.snell-atompub-link-extensions]. When present, proposed in [I-D.snell-atompub-link-extensions]. When present,
the Integrity-Hash field MUST be the last line of the CDNI the Integrity-Hash field MUST be the last line of the CDNI
skipping to change at page 27, line 40 skipping to change at page 27, line 40
received by the Surrogate (e.g., "HTTP/1.1"). received by the Surrogate (e.g., "HTTP/1.1").
* 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 sc-status: o sc-status:
* format: 3DIGIT * format: 3DIGIT
* field value: this is the Status-Code in the response from the * field value: this is the Status-Code in the response from the
Surrogate. tIn the case of HTTP delivery, this is the HTTP Surrogate. In the case of HTTP delivery, this is the HTTP
Status-Code in the HTTP response. Status-Code in the HTTP response.
* 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 sc-total-bytes: o sc-total-bytes:
* format: 1*DIGIT * format: 1*DIGIT
* field value: this is the total number of bytes of the response * field value: this is the total number of bytes of the response
skipping to change at page 33, line 48 skipping to change at page 33, line 48
#Integrity-Hash:<HTAB>fe113dfce8fec91323a4fc02261af26e<CRLF> #Integrity-Hash:<HTAB>fe113dfce8fec91323a4fc02261af26e<CRLF>
[Editor's Note: compute the correct Integrity-Hash value once example [Editor's Note: compute the correct Integrity-Hash value once example
is frozen] is frozen]
Figure 4: CDNI Logging File Example Figure 4: CDNI Logging File Example
If uCDN establishes by some means (e.g. via TLS authentication when If uCDN establishes by some means (e.g. via TLS authentication when
pulling the CDNI Logging File) the identity of the entity from which pulling the CDNI Logging File) the identity of the entity from which
it pulled the CDNI Logging File, uCDN can add to the CDNI Logging a it pulled the CDNI Logging File, uCDN can add to the CDNI Logging an
Verified-Origin directive as illustrated below: Established-Origin directive as illustrated below:
#Established-Origin:<HTAB>cdni-logging-entity.dcdn-
1.example.com<CRLF>
#Verified-Origin:<HTAB>cdni-logging-entity.dcdn-1.example.com<CRLF>
As illustrated in Figure 2, uCDN will then ingest the corresponding As illustrated in Figure 2, uCDN will then ingest the corresponding
CDNI Logging Records into its Collection process, alongside the CDNI Logging Records into its Collection process, alongside the
Logging Records generated locally by the uCDN itself. This allows Logging Records generated locally by the uCDN itself. This allows
uCDN to aggregate Logging Records for deliveries performed by itself uCDN to aggregate Logging Records for deliveries performed by itself
(through Records generated locally) as well as for deliveries (through Records generated locally) as well as for deliveries
performed by its downstream CDN(s). This aggregate information can performed by its downstream CDN(s). This aggregate information can
then be used (after Filtering and Rectification, as illustrated in then be used (after Filtering and Rectification, as illustrated in
Figure 2) by Log Consuming Applications that take into account Figure 2) by Log Consuming Applications that take into account
deliveries performed by uCDN as well as by all of its downstream deliveries performed by uCDN as well as by all of its downstream
CDNs. CDNs.
skipping to change at page 35, line 34 skipping to change at page 35, line 34
#Integrity-Hash:<HTAB>fe113dfce8fec91323a4fc02261af26e<CRLF> #Integrity-Hash:<HTAB>fe113dfce8fec91323a4fc02261af26e<CRLF>
[Editor's Note: compute the correct Integrity-Hash value once example [Editor's Note: compute the correct Integrity-Hash value once example
is frozen] is frozen]
Figure 5: Cascaded CDNI Logging File Example (dCDN-3 to dCDN-2) Figure 5: Cascaded CDNI Logging File Example (dCDN-3 to dCDN-2)
If dCDN-2 establishes by some means (e.g. via TLS authentication when If dCDN-2 establishes by some means (e.g. via TLS authentication when
pulling the CDNI Logging File) the identity of the entity from which pulling the CDNI Logging File) the identity of the entity from which
it pulled the CDNI Logging File, dCDN-2 can add to the CDNI Logging a it pulled the CDNI Logging File, dCDN-2 can add to the CDNI Logging
Verified-Origin directive as illustrated below: an Established-Origin directive as illustrated below:
#Verified-Origin:<HTAB>cdni-logging-entity.dcdn-3.example.com<CRLF> #Established-Origin:<HTAB>cdni-logging-entity.dcdn-
3.example.com<CRLF>
dCDN-2 (behaving as an upstream CDN from the viewpoint of dCDN-3) dCDN-2 (behaving as an upstream CDN from the viewpoint of dCDN-3)
will then ingest the CDNI Logging Record for the considered dCDN-3 will then ingest the CDNI Logging Record for the considered dCDN-3
delivery into its Collection process (as illustrated in Figure 2). delivery into its Collection process (as illustrated in Figure 2).
This Logging Record may be aggregated with Logging Records generated This Logging Record may be aggregated with Logging Records generated
locally by dCDN-2 for deliveries performed by dCDN-2 itself. Say, locally by dCDN-2 for deliveries performed by dCDN-2 itself. Say,
for illustration, that the content delivery performed by dCDN-3 on for illustration, that the content delivery performed by dCDN-3 on
behalf of dCDN-2 had actually been redirected to dCDN-2 by uCDN, and behalf of dCDN-2 had actually been redirected to dCDN-2 by uCDN, and
say that another content delivery has just been redirected by uCDN to say that another content delivery has just been redirected by uCDN to
dCDN-2 and that dCDN-2 elected to perform the corresponding delivery dCDN-2 and that dCDN-2 elected to perform the corresponding delivery
skipping to change at page 36, line 43 skipping to change at page 36, line 43
#Integrity-Hash:<HTAB>fe113dfce8fec91323a4fc02261af26e<CRLF> #Integrity-Hash:<HTAB>fe113dfce8fec91323a4fc02261af26e<CRLF>
[Editor's Note: compute the correct Integrity-Hash value once example [Editor's Note: compute the correct Integrity-Hash value once example
is frozen] is frozen]
Figure 6: Cascaded CDNI Logging File Example (dCDN-2 to uCDN) Figure 6: Cascaded CDNI Logging File Example (dCDN-2 to uCDN)
If uCDN establishes by some means (e.g. via TLS authentication when If uCDN establishes by some means (e.g. via TLS authentication when
pulling the CDNI Logging File) the identity of the entity from which pulling the CDNI Logging File) the identity of the entity from which
it pulled the CDNI Logging File, uCDN can add to the CDNI Logging a it pulled the CDNI Logging File, uCDN can add to the CDNI Logging an
Verified-Origin directive as illustrated below: Established-Origin directive as illustrated below:
#Verified-Origin:<HTAB>cdni-logging-entity.dcdn-2.example.com<CRLF> #Established-Origin:<HTAB>cdni-logging-entity.dcdn-
2.example.com<CRLF>
In the example of Figure 6, we observe that: In the example of Figure 6, we observe that:
o the first Logging Record corresponds to the Logging Record o the first Logging Record corresponds to the Logging Record
communicated earlier to dCDN-2 by dCDN-3, which corresponds to a communicated earlier to dCDN-2 by dCDN-3, which corresponds to a
delivery redirected by uCDN to dCDN-2 and then redirected by delivery redirected by uCDN to dCDN-2 and then redirected by
dCDN-2 to dCDN-3. The fields values in this Logging Record are dCDN-2 to dCDN-3. The fields values in this Logging Record are
copied from the corresponding CDNI Logging REcord communicated to copied from the corresponding CDNI Logging REcord communicated to
dCDN2 by dCDN-3, with the exception of the u-uri that now reflects dCDN2 by dCDN-3, with the exception of the u-uri that now reflects
the URI convention between uCDN and dCDN-2 and that presents the the URI convention between uCDN and dCDN-2 and that presents the
skipping to change at page 43, line 22 skipping to change at page 43, line 22
The initial contents of the CDNI Logging File Directives registry The initial contents of the CDNI Logging File Directives registry
comprise the names of the directives specified in Section 3.3 of the comprise the names of the directives specified in Section 3.3 of the
present document, and are as follows: present document, and are as follows:
+------------------------------+-----------+ +------------------------------+-----------+
| Directive Name | Reference | | Directive Name | Reference |
+------------------------------+-----------+ +------------------------------+-----------+
| Version | RFC xxxx | | Version | RFC xxxx |
| UUID | RFC xxxx | | UUID | RFC xxxx |
| Claimed-Origin | RFC xxxx | | Claimed-Origin | RFC xxxx |
| Verified-Origin | RFC xxxx | | Established-Origin | RFC xxxx |
| Record-Type | RFC xxxx | | Record-Type | RFC xxxx |
| Fields | RFC xxxx | | Fields | RFC xxxx |
| Integrity-Hash | RFC xxxx | | Integrity-Hash | RFC xxxx |
+------------------------------+-----------+ +------------------------------+-----------+
Figure 8 Figure 8
[Instructions to IANA: Replace "RFC xxxx" above by the RFC number of [Instructions to IANA: Replace "RFC xxxx" above by the RFC number of
the present document] the present document]
skipping to change at page 44, line 45 skipping to change at page 44, line 45
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.3): a specification of the field name, format and field (Section 6.3): a specification of the field name, format and field
value. value.
6.3. CDNI Logging Field Names Registry 6.3. CDNI Logging Field Names Registry
The IANA is requested to create a new registry, CDNI Logging Field The IANA is requested to create a new registry, CDNI Logging Field
Names. Names.
The above registry is intended to be shared across the currently This registry is intended to be shared across the currently defined
defined Record-Type (i.e., cdni_http_request_v1) as well as potential Record-Type (i.e., cdni_http_request_v1) as well as potential other
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
identical then this new Field is to be registered in the registry 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 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 by another CDNI Logging Record-Type, it can be used with different
occurence rules. occurence rules.
 End of changes. 15 change blocks. 
23 lines changed or deleted 27 lines changed or added

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