Request Routing Redirection Interface for Content Delivery Network (CDN) Interconnection
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: "IETF-Announce" <firstname.lastname@example.org> Cc: "Kevin J. Ma" <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, "The IESG" <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org Subject: Protocol Action: 'Request Routing Redirection interface for CDN Interconnection' to Proposed Standard (draft-ietf-cdni-redirection-20.txt) The IESG has approved the following document: - 'Request Routing Redirection interface for CDN Interconnection' (draft-ietf-cdni-redirection-20.txt) as Proposed Standard This document is the product of the Content Delivery Networks Interconnection Working Group. The IESG contact persons are Alexey Melnikov, Ben Campbell and Alissa Cooper. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-redirection/
Technical Summary This document is a standards track submission that defines a protocol by which an upstream CDN (uCDN) may query a downstream CDN (dCDN), in a CDN Interconnection (CDNI), as to whether the dCDN will accept a client redirected from the uCDN, and if so, to where in the dCDN the client should be redirected. It is necessary for the recursive redirection mode of CDNI. The WG believes that a standardized method/protocol for determining if a dCDN is able and willing to serve content for the uCDN is needed and will be useful. Review and Consensus Because iterative redirection is simpler and more widely used today, the WG's focus was primarily on iterative redirection; consequently, there was less discussion on recursive redirection. There was significant review within the working group, with no notable technical disagreement. An early AppsDir review was done, which specifically looked at the JSON encoding, and all comments from that review were addressed. A security concern was raised and discussed by the WG. The protocol supports DNS redirection because CDNs use DNS redirection today. Without DNSSEC, however, a client may not be able to distinguish legitimate DNS redirection from a DNS-based attack. The WG agreed that the concern should be documented (which it has been), but that the existing functionality should move forward with the understanding that DNSSEC is not a reasonable requirement for all DNS redirection. The security aspects are being pursued in a separate draft. Personnel The document shepherd is Kevin J. Ma. The responsible AD is Alexey Melnikov.