draft-ietf-cdni-control-triggers-07.txt		draft-ietf-cdni-control-triggers-08.txt
	Network Working Group R. Murray		Network Working Group R. Murray
	Internet-Draft B. Niven-Jenkins		Internet-Draft B. Niven-Jenkins
	Intended status: Standards Track Velocix (Alcatel-Lucent)		Intended status: Standards Track Velocix (Alcatel-Lucent)
	Expires: January 1, 2016 June 30, 2015		Expires: January 3, 2016 July 2, 2015
	CDNI Control Interface / Triggers		CDNI Control Interface / Triggers
	draft-ietf-cdni-control-triggers-07		draft-ietf-cdni-control-triggers-08
	Abstract		Abstract
	This document describes the part of the CDN Interconnection Control		This document describes the part of the CDN Interconnection Control
	Interface that allows a CDN to trigger activity in an interconnected		Interface that allows a CDN to trigger activity in an interconnected
	CDN that is configured to deliver content on its behalf. The		CDN that is configured to deliver content on its behalf. The
	upstream CDN can use this mechanism to request that the downstream		upstream CDN can use this mechanism to request that the downstream
	CDN pre-positions metadata or content, or that it invalidates or		CDN pre-positions metadata or content, or that it invalidates or
	purges metadata or content. The upstream CDN can monitor the status		purges metadata or content. The upstream CDN can monitor the status
	of activity that it has triggered in the downstream CDN.		of activity that it has triggered in the downstream CDN.
	skipping to change at page 1, line 42		skipping to change at page 1, line 42
	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 1, 2016.		This Internet-Draft will expire on January 3, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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 42, line 39		skipping to change at page 42, line 39
	A dCDN implementation of CI/T MUST restrict the actions of a uCDN to		A dCDN implementation of CI/T MUST restrict the actions of a uCDN to
	the data corresponding to that uCDN. Failure to do so would allow		the data corresponding to that uCDN. Failure to do so would allow
	uCDNs to detrimentally affect each other's efficiency by generating		uCDNs to detrimentally affect each other's efficiency by generating
	unnecessary acquisition or re-acquisition load.		unnecessary acquisition or re-acquisition load.
	8.1. Authentication, Authorization, Confidentiality, Integrity		8.1. Authentication, Authorization, Confidentiality, Integrity
	Protection		Protection
	A CI/T implementation MUST support TLS transport for HTTP (https) as		A CI/T implementation MUST support TLS transport for HTTP (https) as
	per [RFC2818].		per [RFC2818] and [RFC7230].
	The use of TLS for transport of the CI/T interface allows:		The use of TLS for transport of the CI/T interface allows:
	o The dCDN and the uCDN to authenticate each other.		o The dCDN and the uCDN to authenticate each other and, once they
			have mutually authenticated each other, it allows:
	and, once they have mutually authenticated each other, it allows:
	o The dCDN and the uCDN to authorize each other (to ensure they are		o The dCDN and the uCDN to authorize each other (to ensure they are
	receiving CI/T Commands from, or reporting status to, an		receiving CI/T Commands from, or reporting status to, an
	authorized CDN).		authorized CDN).
	o CDNI commands and responses to transmitted with confidentiality,		o CDNI commands and responses to be transmitted with
	In an environment where any such protection is required, the use of a		confidentiality.
	mutually authenticated encrypted transport MUST be used to ensure
	confidentiality of the CI/T information. TLS MUST be used by CI/T,
	including authentication of the remote end.
	The general TLS usage guidance in [RFC7525] SHOULD be followed.		o Protection of the integrity of CDNI commands and responses.
			In an environment where any such protection is required, mutually
			authenticated encrypted transport MUST be used to ensure
			confidentiality of the CI/T information. To that end, TLS MUST be
			used by CI/T, including authentication of the remote end.
			When TLS is used, the general TLS usage guidance in [RFC7525] MUST be
			followed.
	HTTP requests that attempt to access or operate on CI/T data		HTTP requests that attempt to access or operate on CI/T data
	belonging to another CDN MUST be rejected using, for example, HTTP		belonging to another CDN MUST be rejected using, for example, HTTP
	"403 Forbidden" or "404 Not Found". This is intended to prevent		"403 Forbidden" or "404 Not Found". This is intended to prevent
	unauthorised users from generating unnecessary load in dCDN or uCDN		unauthorised users from generating unnecessary load in dCDN or uCDN
	due to revalidation, reacquisition, or unnecessary acquisition.		due to revalidation, reacquisition, or unnecessary acquisition.
	Note that in a "diamond" configuration, where one uCDN's content can		Note that in a "diamond" configuration, where one uCDN's content can
	be acquired via more than one directly-connected uCDN, it may not be		be acquired via more than one directly-connected uCDN, it may not be
	possible for the dCDN to determine from which uCDN it acquired		possible for the dCDN to determine from which uCDN it acquired
	skipping to change at page 44, line 22		skipping to change at page 44, line 24
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data		[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
	Interchange Format", RFC 7159, March 2014.		Interchange Format", RFC 7159, March 2014.
			[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
			(HTTP/1.1): Message Syntax and Routing", RFC 7230, June
			2014.
	[RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol		[RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
	(HTTP/1.1): Semantics and Content", RFC 7231, June 2014.		(HTTP/1.1): Semantics and Content", RFC 7231, June 2014.
	[RFC7232] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol		[RFC7232] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
	(HTTP/1.1): Conditional Requests", RFC 7232, June 2014.		(HTTP/1.1): Conditional Requests", RFC 7232, June 2014.
			[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
			"Recommendations for Secure Use of Transport Layer
			Security (TLS) and Datagram Transport Layer Security
			(DTLS)", BCP 195, RFC 7525, May 2015.
	10.2. Informative References		10.2. Informative References
	[I-D.greevenbosch-appsawg-cbor-cddl]		[I-D.greevenbosch-appsawg-cbor-cddl]
	Vigano, C., Birkholz, H., and R. Sun, "CBOR data		Vigano, C., Birkholz, H., and R. Sun, "CBOR data
	definition language: a notational convention to express		definition language: a notational convention to express
	CBOR data structures.", draft-greevenbosch-appsawg-cbor-		CBOR data structures.", draft-greevenbosch-appsawg-cbor-
	cddl-05 (work in progress), March 2015.		cddl-05 (work in progress), March 2015.
	[I-D.ietf-cdni-metadata]		[I-D.ietf-cdni-metadata]
	Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,		Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
	skipping to change at page 45, line 13		skipping to change at page 45, line 24
	Statement", RFC 6707, September 2012.		Statement", RFC 6707, September 2012.
	[RFC7336] Peterson, L., Davie, B., and R. van Brandenburg,		[RFC7336] Peterson, L., Davie, B., and R. van Brandenburg,
	"Framework for Content Distribution Network		"Framework for Content Distribution Network
	Interconnection (CDNI)", RFC 7336, August 2014.		Interconnection (CDNI)", RFC 7336, August 2014.
	[RFC7337] Leung, K. and Y. Lee, "Content Distribution Network		[RFC7337] Leung, K. and Y. Lee, "Content Distribution Network
	Interconnection (CDNI) Requirements", RFC 7337, August		Interconnection (CDNI) Requirements", RFC 7337, August
	2014.		2014.
	[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
	"Recommendations for Secure Use of Transport Layer
	Security (TLS) and Datagram Transport Layer Security
	(DTLS)", BCP 195, RFC 7525, May 2015.
	Authors' Addresses		Authors' Addresses
	Rob Murray		Rob Murray
	Velocix (Alcatel-Lucent)		Velocix (Alcatel-Lucent)
	3 Ely Road		3 Ely Road
	Milton, Cambridge CB24 6DD		Milton, Cambridge CB24 6DD
	UK		UK
	Email: rob.murray@alcatel-lucent.com		Email: rob.murray@alcatel-lucent.com
End of changes. 10 change blocks.
	18 lines changed or deleted		26 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/