Subject: [CDNi] I-D Action: draft-ietf-cdni-redirection-12.txt

From: [email-masked]
Date: Wed, 07 Oct 2015 01:52:16 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Content Delivery Networks Interconnection Working Group of the IETF.

        Title           : Request Routing Redirection Interface for CDN Interconnection
        Authors         : Ben Niven-Jenkins
                          Ray van Brandenburg
	Filename        : draft-ietf-cdni-redirection-12.txt
	Pages           : 30
	Date            : 2015-10-07

Abstract:
   The Request Routing Interface comprises of (1) the asynchronous
   advertisement of footprint and capabilities by a downstream Content
   Delivery Network (CDN) that allows an upstream CDN to decide whether
   to redirect particular user requests to that downstream CDN; and (2)
   the synchronous operation of an upstream CDN requesting whether a
   downstream CDN is prepared to accept a user request and of a
   downstream CDN responding with how to actually redirect the user
   request.  This document describes an interface for the latter part,
   i.e. the CDNI Request Routing Redirection interface.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-cdni-redirection/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-cdni-redirection-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-redirection-12

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Phil Sorber <[email-masked]>
Date: Wed, 07 Oct 2015 22:15:23 +0000

There is a sentence in section 2 about HTTP redirection:

> Examples of an application level redirection are HTTP 302 Redirection and
RTMP 302 Redirection.

and then various other references to 302 redirection throughout the
document. My question is, what is the expectation for a multi-asset
exchange like segmented video where a UA is sent to a manifest and then
expected to download a series of video segments. Should the UA continually
go back to the redirector, or should it "stick" to the host it was
redirected to?

Perhaps this is out of the scope of this document?

On Wed, Oct 7, 2015 at 2:52 AM <[email-masked]> wrote:

>  This draft is a work item of the Content Delivery Networks
> Interconnection Working Group of the IETF.
>
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni
>

---

From: Kevin Ma J <[email-masked]>
Date: Wed, 7 Oct 2015 22:46:32 +0000

Hi Phil,

  Ray and Ben may have additional thoughts, but I think it depends (relative URL maybe reuse the redirect location vs. full URL reask the request router); either way, I think it's probably beyond the scope of the CDNI RI?

thanx!

--  Kevin J. Ma

Sent from my iPhone

On Oct 7, 2015, at 6:15 PM, Phil Sorber <[email-masked]<mailto:[email-masked]>> wrote:

There is a sentence in section 2 about HTTP redirection:

> Examples of an application level redirection are HTTP 302 Redirection and RTMP 302 Redirection.

and then various other references to 302 redirection throughout the document. My question is, what is the expectation for a multi-asset exchange like segmented video where a UA is sent to a manifest and then expected to download a series of video segments. Should the UA continually go back to the redirector, or should it "stick" to the host it was redirected to?

On Wed, Oct 7, 2015 at 2:52 AM <[email-masked]<mailto:[email-masked]>> wrote:

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

_______________________________________________
CDNi mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cdni
_______________________________________________
CDNi mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cdni

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 8 Oct 2015 08:21:52 +0100

Hi Phil,

> On 7 Oct 2015, at 23:15, Phil Sorber <[email-masked]> wrote:
> 

It depends on the type of reference. Sections 4 & 5 of RFC3986 cover this.  

> Perhaps this is out of the scope of this document?

Yes it is IMO.

Ben

> 
> On Wed, Oct 7, 2015 at 2:52 AM <[email-masked] <mailto:[email-masked]>> wrote:
> 
> https://datatracker.ietf.org/doc/draft-ietf-cdni-redirection/ <https://datatracker.ietf.org/doc/draft-ietf-cdni-redirection/>
> 
> https://tools.ietf.org/html/draft-ietf-cdni-redirection-12 <https://tools.ietf.org/html/draft-ietf-cdni-redirection-12>
> 
> https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-redirection-12 <https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-redirection-12>
> 
> 
> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> 
> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/cdni <https://www.ietf.org/mailman/listinfo/cdni>

---

From: Phil Sorber <[email-masked]>
Date: Thu, 08 Oct 2015 17:52:28 +0000

Just for clarity, I found what I was looking for in
https://tools.ietf.org/html/rfc6983#section-2.2.1 (which is an anagram of
RFC3986). It's really defined as a player behavior, but as far as I can
tell there is currently no way to signal the client player to act in a
specific way so I guess there is no point in signaling this between the
uCDN and dCDN.

Thanks.