Skip to main content

Request Routing Redirection Interface for Content Delivery Network (CDN) Interconnection
draft-ietf-cdni-redirection-20

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: "IETF-Announce" <ietf-announce@ietf.org>
Cc: "Kevin J. Ma" <kevin.j.ma@ericsson.com>, cdni-chairs@ietf.org, draft-ietf-cdni-redirection@ietf.org, kevin.j.ma@ericsson.com, "The IESG" <iesg@ietf.org>, alexey.melnikov@isode.com, cdni@ietf.org, rfc-editor@rfc-editor.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/


Ballot Text

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.

RFC Editor Note