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/