Subject: [CDNi] Last Call: <draft-ietf-cdni-framework-10.txt> (Framework for CDN Interconnection) to Informational RFC

From: The IESG <[email-masked]>
Date: Mon, 03 Mar 2014 07:33:24 -0800

The IESG has received a request from the Content Delivery Networks
Interconnection WG (cdni) to consider the following document:
- 'Framework for CDN Interconnection'
  <draft-ietf-cdni-framework-10.txt> as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2014-03-24. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.L

This is a three-week IETF Last Call because it's starting during IETF week.
We want to give people a chance to read it and talk about issues this 
week, while still giving two full weeks for people to review while not 
at an IETF meeting.

Abstract

   This document presents a framework for Content Distribution Network
   Interconnection (CDNI).  The purpose of the framework is to provide
   an overall picture of the problem space of CDNI and to describe the
   relationships among the various components necessary to interconnect
   CDNs.  CDN Interconnection requires the specification of interfaces
   and mechanisms to address issues such as request routing,
   distribution metadata exchange, and logging information exchange
   across CDNs.  The intent of this document is to outline what each
   interface needs to accomplish, and to describe how these interfaces
   and mechanisms fit together, while leaving their detailed
   specification to other documents.  It obsoletes RFC 3466.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-cdni-framework/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-cdni-framework/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Tue, 4 Mar 2014 11:09:25 +0000

Hi S.,

Thanks for you comments. Please see my responses inline.

Best regards,

Ray

On 04/03/14 06:00, "S Moonesamy" <[email-masked]> wrote:

>At 07:33 03-03-2014, The IESG wrote:
>
>I took a quick look at the draft.
>
>Section 2.1.1 discusses about "DNS Redirection".  I don't think that
>it fits as redirection as used within a DNS context.  There is an
>assumption that the recursive resolver is local.  The term "DNS
>server" is ambiguous.

I think it¹s important that note that the terminology in this document,
and other CDNI documents, aligns with terminology as found in the CDN
space, some of which may conflict with terminology as used in some other
IETF WGs. A large share of (global) CDNs are currently using DNS to
effectively Œredirect¹ end users to one of their servers, hence the term
DNS Redirection. I appreciate that such terminology would have another
meaning when uttered in e.g. a DNS WG. Ideally, it would be best to line
up our terminology, however, at this point, I would rather make sure the
terminology in this document lines up with other CDNI documents such as
RFC6707 and 6770. 

>
>   "DNS responses are cached by downstream servers so the TTL on the
>    response must be set to an appropriate value so as to preserve the
>    fresheness of the redirection."
>
>These (DNS) servers are not downstream servers.

Are you saying that you would rather use a different term for such
Œdownstream¹ DNS servers? Do you have a suggestion?

>
>Section 2.1.2 does not provide a good discussion about why HTTP
>redirection is not the preferred choice.  The draft mentions that the
>disadvantage of HTTP redirection is that it requires application
>support.  All web browsers support HTTP redirection.  There are
>disadvantages to using DNS to serve content.  There is an assumption
>that a user with an IP address in, for example, Japan will understand
>localized content for that country.

I see your point. I agree that the way it is written right now, the
discussion might seem a bit lopsided, especially since the section on DNS
Redirection does not list disadvantages. I will add those. In general, I
would like to add that for the purposes of the CDNI Framework document, we
are not in a position where we would like to advise for or against either
HTTP or DNS as a redirection mechanism, the only thing that is important
is that the CDNI interfaces allow for CDNs that use either of the two
mechanisms to successfully interconnect.

>
>In Section 3.2:
>
>  "2.   A Request Router for Operator A processes the HTTP request and
>        recognizes that the end-user is best served by another CDN,"
>
>Routers do not process HTTP requests.

Again, I think this a matter of terminology. A Request Router in a CDN is
not a router in the  ŒIP-router¹ sense, but an application level device
which performs (HTTP) 302 redirects in order to load balance between
multiple (HTTP) servers and/or CDNs.

>
>In Section 3.4:
>
>   "One approach to ensuring that the client's IP address
>    prefix is correctly determined in such situations is described in
>    [I-D.vandergaast-edns-client-subnet]"
>
>That Internet-Draft was discussed previously.  There are privacy
>implications in sending information which was not usually sent as
>part of a DNS request.

Since this draft has expired and no longer seems to be active, I will
remove the reference to it.

>
>In Section 4.4, "Referrer" is misspelled.

Thanks. Will update.

>
>The draft does not discuss about content delivered over HTTPS.  There
>are issues, e.g. see
>http://www.ietf.org/mail-archive/web/ietf/current/msg86077.html
>Given that the IETF considers pervasive monitoring as an attack,
>there is an expectation that the problem would be taken into
>consideration for a framework document.

>From the point of CDNI, it doesn¹t really matter whether the actual
content is delivered via HTTP, HTTPS, RTSP or some other mechanism, hence
the fact that most examples use HTTP. What exactly would you like to see
discussed regarding HTTPS?

>
>The CDNI WG Charter mentions that:
>
>  "Such content includes, but is not limited to, web pages and images
>   delivered via HTTP, and streaming of continuous media delivered via
>   HTTP, RTSP, RTMP, etc. CDNs typically provide services to multiple
>   Content Service Providers (CSPs)."
>
>The only upper layer protocol discussed in the draft is HTTP.
>
>Regards,
>S. Moonesamy
>

Thanks again,

Ray

Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. TNO aanvaardt geen aansprakelijkheid voor de inhoud van deze e-mail, de wijze waarop u deze gebruikt en voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

---

From: S Moonesamy <[email-masked]>
Date: Mon, 03 Mar 2014 22:00:17 -0800

In Section 3.2:

In Section 3.4:

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Wed, 05 Mar 2014 04:46:48 -0800

Hi Ray,
At 03:09 04-03-2014, Brandenburg, R. (Ray) van wrote:
>I think it's important that note that the terminology in this document,
>effectively redirect end users to one of their servers, hence the term

If I understood correctly CDNI builds upon existing IETF 
specifications, e.g. DNS.  The draft does not even reference those 
specifications.  I'll defer to the relevant Area Director on the 
question of terminology.

>"downstream" DNS servers? Do you have a suggestion?

I don't think that "downstream" DNS servers is appropriate.  The term 
"recursive name server" is a better fit.

>mechanisms to successfully interconnect.

I was not arguing for or against either alternative.  I think that it 
is worthwhile to provide information which would not mislead the reader.

>not a router in the  IP-router sense, but an application level device

I'll defer to the relevant Area Director on the question of terminology.

> From the point of CDNI, it doesn't really matter whether the actual

I think that the working group could have at least considered HTTPS 
and determine whether there are issues worth discussing or not.  AS 
it stands, the draft looks like HTTP was used as the general case for 
all content that is delivered.

Regards,
S. Moonesamy

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Thu, 6 Mar 2014 15:39:36 +0000

Hi S.,

On 05/03/14 12:46, "S Moonesamy" <[email-masked]> wrote:

>specifications.  

You¹re right that the document mentions DNS, however, I¹m not sure that
warrants an (informative) reference to a DNS specification. Do you have a
specific DNS spec in mind that you would like to see referenced?

>"recursive name server" is a better fit.

In order to understand the meaning of the sentence, I think it¹s helpful
to clarify the fact that we¹re talking about a DNS server in the
Downstream CDN, hence the term downstream DNS server. I¹m a not sure
whether recursive name server would cover the meaning as well. How about
ŒDNS responses are cached by servers in the dCDN¹?

>is worthwhile to provide information which would not mislead the reader.

Again, our intention is not to hint at a Œpreferred¹ choice between HTTP
or DNS, or to Œlead¹ (let alone mislead) the reader in any direction. I
will try to rephrase the paragraph to remove any words that might sound as
such. 

>all content that is delivered.

Ok. 

>S. Moonesamy 

Thanks,

Ray