Skip to main content

Shepherd writeup
draft-ietf-cdni-redirection

1. Summary

   The document shepherd is Kevin J. Ma.  The responsible AD is Barry Leiba.

   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.

2. Review and Consensus

   The protocol is a straightforward RESTful API with JSON payloads
   that contain key/value pairs, for extensibility.  Currently known
   parameters needed for DNS and HTTP redirection are defined.  CDNI
   supports two types of redirection: iterative redirection and
   recursive redirection.  This document specifically addresses
   recursive redirection.  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, but a smaller group of individuals within
   the WG agreed that the parameters defined would be necessary and
   useful.

   Independent reviews were performed by Kevin J. Ma and Bert
   Greevenbosch citing editorial and consistency issues; all comments
   were addressed.  A WG Chair review was performed by Francois Le
   Faucheur citing editorial changes; all comments were addressed.  An
   appsdir early review was performed by Matt Miller, specifically
   looking at the JSON encoding; all comments/nits were addressed.  As
   document shepherd, I performed a final review focusing on IANA
   considerations and normative references, as well as citing
   editorial and consistency issues; all comments 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.

3. Intellectual Property

   Each author has confirmed conformance with BCP 78/79.

   There was one IPR disclosure from Juniper Networks.  The disclosure
   was announced on the list with only one response on the list
   stating that the RAND terms seemed reasonable.  The disclosure was
   also discussed in the WG meeting at IETF94.  The chairs agreed that
   the RAND terms seemed reasonable and that there was no reason to
   hold up the document.  There were no objections from the WG.

4. Other Points

   There are no downward references in the document.

   The IANA Considerations registers two new CDNI Protocol Types.  The
   document shepherd and one of the editors are the two designated
   expert reviewers for the CDNI Protocol Types registry and have
   approved the addition.

   The IANA Considerations also creates a new registry for error codes
   for the protocol with sufficient guidelines provided to both IANA
   and the designated expert reviewer.
Back