Subject: [CDNi] Start of WG Last Call on draft-ietf-cdni-framework-05.txt

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Tue, 10 Sep 2013 09:05:09 +0000

All,

This is the start of a two-week working group last call on draft-ietf-cdni-framework-05.txt:
https://datatracker.ietf.org/doc/draft-ietf-cdni-framework

This working group last call will end on 25 September 2013. Please send your comments to the CDNI mailing list.

Francois & Daryl

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Tue, 17 Sep 2013 07:43:51 +0000

Hi all,

I've reviewed draft-ietf-cdni-framework-05. Apart from the following comments, which I would like to see resolved, I think the document is ready for publication.

-          I've raised this issue before on the list, but didn't see any response, so let me include it here again: To my knowledge, the current CDNI documents do not explicitly address the case of HTTP Byte-range requests. Although in most cases byte-range requests will function just as any other requests, I think there are some cases where byte-range requests warrant further attention. An example is the Redirection interface. If a uCDN asks a dCDN to deliver a particular user request (containing a byte range), and the dCDN answers positively, can the uCDN assume that the dCDN accepts any future requests for the same file with a different byte range? And if that is the case, is this default behavior or do we need an explicit flag in the inter-CDN redirection request to indicate the uCDN/dCDN's preference? To be clear: I don't think we need any new functionality to handle byte-range requests, but a few sentences in either the Framework or the RI document might clear up any future uncertainty. Since the framework document will be published first, I would like to have discussion now.

-          The security section contains the following text: "CDNs today offer a variety of means to control access to content, such as time-of-day restrictions, geo-blocking, and URI signing. These mechanisms must continue to function in CDNI environments, and this consideration is likely to affect the design of certain CDNI interfaces (e.g. metadata, request routing.)". Now that we, as a group, have decided that URI signing warrants its own specification, and we added it to the charter, would it make sense to expand on this text a little bit?

In addition, two small nits:

-          draft-brandenburg-cdni-has, as listed in the references, has been published as RFC6983.

-          My name in the acknowledgements (BTW: Thanks for that!) is misspelled. Could you add the 'van' in the middle? Thanks!

Best regards,

Ray

From: [email-masked] [mailto:[email-masked]] On Behalf Of Francois Le Faucheur (flefauch)
Sent: dinsdag 10 september 2013 11:05
To: [email-masked]
Subject: [CDNi] Start of WG Last Call on draft-ietf-cdni-framework-05.txt

All,

Francois & Daryl

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Thu, 19 Sep 2013 17:26:35 +0000

Ray and all,

(speaking as an individual)

On 17 Sep 2013, at 09:43, "Brandenburg, R. (Ray) van" <[email-masked]<mailto:[email-masked]>>
 wrote:

Hi all,

I’ve reviewed draft-ietf-cdni-framework-05. Apart from the following comments, which I would like to see resolved, I think the document is ready for publication.

-          I’ve raised this issue before on the list, but didn’t see any response, so let me include it here again: To my knowledge, the current CDNI documents do not explicitly address the case of HTTP Byte-range requests. Although in most cases byte-range requests will function just as any other requests, I think there are some cases where byte-range requests warrant further attention. An example is the Redirection interface. If a uCDN asks a dCDN to deliver a particular user request (containing a byte range), and the dCDN answers positively, can the uCDN assume that the dCDN accepts any future requests for the same file with a different byte range? And if that is the case, is this default behavior or do we need an explicit flag in the inter-CDN redirection request to indicate the uCDN/dCDN's preference?

In my mind, what really determines if the dCDN will accept to serve a request received from a client is the metadata distributed by the uCDN for the corresponding content; and not so much the fact that this particular request was redirected by the uCDN or not.
So in the particular case where byte-range is used in a client request, then the dCDN will makes its decision to honor or not the request based on the CDNI metadata for that content. At this stage, CDNI metadata is associated to a URI (or groups of URI) , and cannot be associated to a subset of bytes for that URI. So, this means that the dCDN would always the same access control rules regardless of the byte range, which means by default that if a certain byte range is allowed, then all other byte ranges are allowed.

Would some text capturing the above help?
Or do you see a strong requirement for wanting to do something different?

To be clear: I don't think we need any new functionality to handle byte-range requests, but a few sentences in either the Framework or the RI document might clear up any future uncertainty. Since the framework document will be published first, I would like to have discussion now.
-          The security section contains the following text: “CDNs today offer a variety of means to control access to content, such as time-of-day restrictions, geo-blocking, and URI signing. These mechanisms must continue to function in CDNI environments, and this consideration is likely to affect the design of certain CDNI interfaces (e.g. metadata, request routing.)”. Now that we, as a group, have decided that URI signing warrants its own specification, and we added it to the charter, would it make sense to expand on this text a little bit?

I don't think we need to expand further on URI signing. It is obviously covered in details in the corresponding document and the specific security considerations associated with URI signing will be detailed there.

Cheers

Francois

-          draft-brandenburg-cdni-has, as listed in the references, has been published as RFC6983.
-          My name in the acknowledgements (BTW: Thanks for that!) is misspelled. Could you add the ‘van’ in the middle? Thanks!

Best regards,

Ray

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Francois Le Faucheur (flefauch)
Sent: dinsdag 10 september 2013 11:05
To: [email-masked]<mailto:[email-masked]>
Subject: [CDNi] Start of WG Last Call on draft-ietf-cdni-framework-05.txt

All,

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

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Fri, 20 Sep 2013 07:35:55 +0000

Hi Francois,

See inline.

Ray

From: Francois Le Faucheur (flefauch) [mailto:[email-masked]]
Sent: donderdag 19 september 2013 19:27
To: Brandenburg, R. (Ray) van
Cc: [email-masked]
Subject: Re: [CDNi] Start of WG Last Call on draft-ietf-cdni-framework-05.txt

Ray and all,

Hi all,

-          I've raised this issue before on the list, but didn't see any response, so let me include it here again: To my knowledge, the current CDNI documents do not explicitly address the case of HTTP Byte-range requests. Although in most cases byte-range requests will function just as any other requests, I think there are some cases where byte-range requests warrant further attention. An example is the Redirection interface. If a uCDN asks a dCDN to deliver a particular user request (containing a byte range), and the dCDN answers positively, can the uCDN assume that the dCDN accepts any future requests for the same file with a different byte range? And if that is the case, is this default behavior or do we need an explicit flag in the inter-CDN redirection request to indicate the uCDN/dCDN's preference?

Yes, I was thinking about something along those lines. Again, what I was mostly concerned about is the complete lack of any mention of byte ranges and how they affect CDNI operation.

How I see the framework document, is as a sort of overall CDNI 'system' description, describing how the CDNI interfaces fit together and allowing a person new to CDNI to get a quick overview. In that sense, I think it would be useful to provide a brief discussion on how the URI Signing document ties in with the other CDNI interfaces.

Cheers

Francois

Best regards,

Ray

All,

Francois & Daryl

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Fri, 20 Sep 2013 07:43:05 +0000

On 20 Sep 2013, at 09:35, "Brandenburg, R. (Ray) van" <[email-masked]<mailto:[email-masked]>>

all fine then.

How I see the framework document, is as a sort of overall CDNI ‘system’ description, describing how the CDNI interfaces fit together and allowing a person new to CDNI to get a quick overview. In that sense, I think it would be useful to provide a brief discussion on how the URI Signing document ties in with the other CDNI interfaces.

I see, but then this brief discussion would probably not belong in the security considerations section. It could be a small section somewhere in the body of the documents.
I personally woudl be fine with that.

Francois

Cheers

Francois

Best regards,

Ray

All,

Francois & Daryl

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Thu, 26 Sep 2013 08:13:12 +0000

Folks,

This closes the WG Last Call on draft-ietf-cdni-framework-05.txt.

If you still have comments/opinion to pass on, please do so right way.

Cheers

Francois

On 10 Sep 2013, at 11:05, Francois Le Faucheur (flefauch) <[email-masked]<mailto:[email-masked]>> wrote:

All,

Francois & Daryl