Informal meeting on blind caching

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Informal meeting on blind caching

Martin Thomson-3
We are having a meeting on blind caching on Tuesday 08:30 in
Charlottenburg I.  Folks who are interested are invited to join us.

Rough agenda is to discuss what this is, the status of specs and
implementations.  Then we are looking to get some input on the work
that has been done and what might need to happen next.

For those not familiar with this, the following drafts are recommended reading:
https://tools.ietf.org/html/draft-thomson-http-scd
https://tools.ietf.org/html/draft-thomson-http-bc
https://tools.ietf.org/html/draft-reschke-http-oob-encoding
https://tools.ietf.org/html/draft-thomson-http-mice
https://tools.ietf.org/html/draft-ietf-httpbis-encryption-encoding

Reply | Threaded
Open this post in threaded view
|

Re: Informal meeting on blind caching

Göran Eriksson AP


>We are having a meeting on blind caching on Tuesday 08:30 in
>Charlottenburg I.  Folks who are interested are invited to join us.

Please note 08:30 AM, morning. Unfortunately, no beer and no bartender or
other refreshments. Sorry for that! Make sure to have a (big) breakfast
before...

Many Regards
Göran

>
>Rough agenda is to discuss what this is, the status of specs and
>implementations.  Then we are looking to get some input on the work
>that has been done and what might need to happen next.
>
>For those not familiar with this, the following drafts are recommended
>reading:
>https://tools.ietf.org/html/draft-thomson-http-scd
>https://tools.ietf.org/html/draft-thomson-http-bc
>https://tools.ietf.org/html/draft-reschke-http-oob-encoding
>https://tools.ietf.org/html/draft-thomson-http-mice
>https://tools.ietf.org/html/draft-ietf-httpbis-encryption-encoding

Reply | Threaded
Open this post in threaded view
|

Re: Informal meeting on blind caching

Kevin Marks
In reply to this post by Martin Thomson-3
any remote attending/streaming options?

On Sun, Jul 17, 2016 at 10:03 AM, Martin Thomson
<[hidden email]> wrote:

> We are having a meeting on blind caching on Tuesday 08:30 in
> Charlottenburg I.  Folks who are interested are invited to join us.
>
> Rough agenda is to discuss what this is, the status of specs and
> implementations.  Then we are looking to get some input on the work
> that has been done and what might need to happen next.
>
> For those not familiar with this, the following drafts are recommended reading:
> https://tools.ietf.org/html/draft-thomson-http-scd
> https://tools.ietf.org/html/draft-thomson-http-bc
> https://tools.ietf.org/html/draft-reschke-http-oob-encoding
> https://tools.ietf.org/html/draft-thomson-http-mice
> https://tools.ietf.org/html/draft-ietf-httpbis-encryption-encoding
>

Reply | Threaded
Open this post in threaded view
|

Re: Informal meeting on blind caching

Göran Eriksson AP


>any remote attending/streaming options?

Hi

Sorry but unfortunately this meeting came up a bit sudden and we haven’t
been able to arrange that.

But I hope this is not the last opportunity for discussing the subject.

I can see to that we take notes and share these on the list afterwards if
that is desired?

Best Regards
Göran

>
>On Sun, Jul 17, 2016 at 10:03 AM, Martin Thomson
><[hidden email]> wrote:
>> We are having a meeting on blind caching on Tuesday 08:30 in
>> Charlottenburg I.  Folks who are interested are invited to join us.
>>
>> Rough agenda is to discuss what this is, the status of specs and
>> implementations.  Then we are looking to get some input on the work
>> that has been done and what might need to happen next.
>>
>> For those not familiar with this, the following drafts are recommended
>>reading:
>> https://tools.ietf.org/html/draft-thomson-http-scd
>> https://tools.ietf.org/html/draft-thomson-http-bc
>> https://tools.ietf.org/html/draft-reschke-http-oob-encoding
>> https://tools.ietf.org/html/draft-thomson-http-mice
>> https://tools.ietf.org/html/draft-ietf-httpbis-encryption-encoding
>>

Reply | Threaded
Open this post in threaded view
|

Re: Informal meeting on blind caching

Göran Eriksson AP
Hi,

Slides from the meeting in PDF format attached.

Drafts GitHub at: https://github.com/EricssonResearch/Blind-Cache-Drafts.

Notes to come (before Wednesday lunch, promise).

Regards
Göran



>
>>
>>On Sun, Jul 17, 2016 at 10:03 AM, Martin Thomson
>><[hidden email]> wrote:
>>> We are having a meeting on blind caching on Tuesday 08:30 in
>>> Charlottenburg I.  Folks who are interested are invited to join us.
>>>
>>> Rough agenda is to discuss what this is, the status of specs and
>>> implementations.  Then we are looking to get some input on the work
>>> that has been done and what might need to happen next.
>>>
>>> For those not familiar with this, the following drafts are recommended
>>>reading:
>>> https://tools.ietf.org/html/draft-thomson-http-scd
>>> https://tools.ietf.org/html/draft-thomson-http-bc
>>> https://tools.ietf.org/html/draft-reschke-http-oob-encoding
>>> https://tools.ietf.org/html/draft-thomson-http-mice
>>> https://tools.ietf.org/html/draft-ietf-httpbis-encryption-encoding
>>>
>


BC_info_Berlin.pdf (4M) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Informal meeting on blind caching

Richard Bradbury
In reply to this post by Martin Thomson-3
On 17/07/2016 18:03, Martin Thomson wrote:
We are having a meeting on blind caching on Tuesday 08:30 in
Charlottenburg I.  Folks who are interested are invited to join us.

Rough agenda is to discuss what this is, the status of specs and
implementations.  Then we are looking to get some input on the work
that has been done and what might need to happen next.

For those not familiar with this, the following drafts are recommended reading:
https://tools.ietf.org/html/draft-thomson-http-scd
https://tools.ietf.org/html/draft-thomson-http-bc
https://tools.ietf.org/html/draft-reschke-http-oob-encoding
https://tools.ietf.org/html/draft-thomson-http-mice
https://tools.ietf.org/html/draft-ietf-httpbis-encryption-encoding

Hi. Thanks for an interesting session last week.

Based on my reading of the Internet Drafts I think these are the two main Use Cases under consideration here:

  1. Blind caching in a CDN edge cache that is acting as a delegated origin server.
    • Described in draft-thomson-http-scd.
    • Making use of the techniques described in draft-reschke-http-oob-encoding, draft-thomson-http-mice and draft-ietf-httpbis-encryption-encoding.
  2. Blind caching in an explicitly configured proxy server.
    • Described in draft-thomson-http-bc.
    • Making use of the techniques described in draft-reschke-http-oob-encoding, draft-thomson-http-mice and draft-ietf-httpbis-encryption-encoding.

The discussion in Berlin last Tuesday morning flowed fairly freely between the two Use Cases, so I just wanted to check my understanding. In particular, the I-D for the second Use Case doesn't have a sequence diagram, so I attach my best guess of how everything fits together and invite comments from the authors.

Finally, a basic question: For this to work, both the origin server and the proxy server need to support blind caching. So how does a User Agent discover whether both do? Through trial and error?


Regards,

-- 
Richard Bradbury | Lead Research Engineer
BBC Research & Development
Centre House, 56 Wood Lane, London  W12 7SB.
T: 0303 040 9672  F: 020 8811 8815

blind-proxy-cache-sequence_2016-07-27.png (185K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Informal meeting on blind caching

Martin Thomson-3
Hi Richard,

Yes you have correctly understood the draft.

On 27 July 2016 at 12:33, Richard Bradbury
<[hidden email]> wrote:
> Finally, a basic question: For this to work, both the origin server and the
> proxy server need to support blind caching. So how does a User Agent
> discover whether both do? Through trial and error?

We use Accept-Encoding and a new header field to signal to the origin
server that the client is willing to do this.  The proxy is explicitly
configured and this capability could be part of that configuration,
but we could do something better than that.  Trial and error might
work, but again, a better plan would be to have explicit signaling.
Off the cuff, /.well-known/ might work.

Reply | Threaded
Open this post in threaded view
|

Re: Informal meeting on blind caching

Amos Jeffries-2
On 27/07/2016 11:11 p.m., Martin Thomson wrote:

> Hi Richard,
>
> Yes you have correctly understood the draft.
>
> On 27 July 2016 at 12:33, Richard Bradbury wrote:
>> Finally, a basic question: For this to work, both the origin server and the
>> proxy server need to support blind caching. So how does a User Agent
>> discover whether both do? Through trial and error?
>
> We use Accept-Encoding and a new header field to signal to the origin
> server that the client is willing to do this.  The proxy is explicitly
> configured and this capability could be part of that configuration,
> but we could do something better than that.  Trial and error might
> work, but again, a better plan would be to have explicit signaling.
> Off the cuff, /.well-known/ might work.
>

As would a BC reply header in the initial CONNECT tunnel reply message
which is generated by the explicit proxy.

Amos


Reply | Threaded
Open this post in threaded view
|

Re: Informal meeting on blind caching

Richard Bradbury
On 27/07/2016 13:49, Amos Jeffries wrote:
On 27/07/2016 11:11 p.m., Martin Thomson wrote:
Yes you have correctly understood the draft.

On 27 July 2016 at 12:33, Richard Bradbury wrote:
Finally, a basic question: For this to work, both the origin server and the
proxy server need to support blind caching. So how does a User Agent
discover whether both do? Through trial and error?
We use Accept-Encoding and a new header field to signal to the origin
server that the client is willing to do this.  The proxy is explicitly
configured and this capability could be part of that configuration,
but we could do something better than that.  Trial and error might
work, but again, a better plan would be to have explicit signaling.
Off the cuff, /.well-known/ might work.

As would a BC reply header in the initial CONNECT tunnel reply message
which is generated by the explicit proxy.

Ah yes... A simple and neat idea. The proxy could verify that the origin at the far end of the TLS tunnel also supports out-of-band encoding before returning that BC response header, thereby killing two birds with one stone.

I have added this additional pre-flight negotiation to the attached sequence. You'll see that I have included BC and Accept-encoding request headers in the initial CONNECT. Is this necessary to initiate the negotiation? Or should the response just include BC regardless?


Thanks both,

-- 
Richard Bradbury | Lead Research Engineer
BBC Research & Development
Centre House, 56 Wood Lane, London  W12 7SB.
T: 0303 040 9672  F: 020 8811 8815

blind-proxy-cache-sequence_2016-07-28.png (204K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Informal meeting on blind caching

Richard Bradbury
In reply to this post by Richard Bradbury
On 27/07/2016 11:33, Richard Bradbury wrote:
On 17/07/2016 18:03, Martin Thomson wrote:
We are having a meeting on blind caching on Tuesday 08:30 in
Charlottenburg I.  Folks who are interested are invited to join us.

Rough agenda is to discuss what this is, the status of specs and
implementations.  Then we are looking to get some input on the work
that has been done and what might need to happen next.

For those not familiar with this, the following drafts are recommended reading:
https://tools.ietf.org/html/draft-thomson-http-scd
https://tools.ietf.org/html/draft-thomson-http-bc
https://tools.ietf.org/html/draft-reschke-http-oob-encoding
https://tools.ietf.org/html/draft-thomson-http-mice
https://tools.ietf.org/html/draft-ietf-httpbis-encryption-encoding

Hi. Thanks for an interesting session last week.

Based on my reading of the Internet Drafts I think these are the two main Use Cases under consideration here:

  1. Blind caching in a CDN edge cache that is acting as a delegated origin server.
    • Described in draft-thomson-http-scd.
    • Making use of the techniques described in draft-reschke-http-oob-encoding, draft-thomson-http-mice and draft-ietf-httpbis-encryption-encoding.
  2. Blind caching in an explicitly configured proxy server.
    • Described in draft-thomson-http-bc.
    • Making use of the techniques described in draft-reschke-http-oob-encoding, draft-thomson-http-mice and draft-ietf-httpbis-encryption-encoding.

The discussion in Berlin last Tuesday morning flowed fairly freely between the two Use Cases, so I just wanted to check my understanding.


OK. Now I feed I understand Use Case 2 better, I attach a couple of sequences describing my (incomplete) understanding of Use Case 1 above. The main question in my mind here is whether the resources are explicitly pushed into the CDN cache (what I have called "Mode P") or whether they are retrieved on demand from the origin server by the CDN only on cache miss ("Mode G").

Perhaps you are looking to support both modes of operation? The Internet Draft could usefully clarify this.

Mode G
In the cache pull-through mode, there appears to be a requirement for the CDN to know the resource mapping in order to support the URL obfuscation feature. But that appears to negate one of the key benefits of the feature – keeping the mapping secret from the CDN provider. I'm clearly missing something here. Or maybe URL obfuscation just doesn't fly in this mode, which would be a shame since this is our primary mode of operation for some media types.
Mode P
With the push mode, the resource mapping can remain secret to the origin server, which is great. But the mechanism for pushing content onto the CDN remains a bit of a mystery, so I have made an educated guess on my diagram. Perhaps you intend this mechanism to remain private? In which case, perhaps the Internet Draft could include a note to this effect?

Clarifications and comments gratefully received.


Regards,
-- 
Richard Bradbury | Lead Research Engineer
BBC Research & Development
Centre House, 56 Wood Lane, London  W12 7SB.
T: 0303 040 9672  F: 020 8811 8815

secure-content-delegation_mode-p_sequence_2016-07-28.png (119K) Download Attachment
secure-content-delegation_mode-g_sequence_2016-07-28.png (139K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Informal meeting on blind caching

Erik Nygren-2
For the "Blind caching in a CDN edge cache that is acting as a delegated origin server" scenario I think we'd be better off separating out the high-level mechanism (ie, getting oob-encoding) right from the actual business model and implementation details for how the caches get populated.  The former is something we can tractably do here (have a way to delegate content bodies out to third-parties) but the latter is something that could easily fill up its own working group to get all of the details worked through.

I also think that we shouldn't refer to "CDN" in this scenario as much as referring to delegating between a server acting as an authoritative origin and a collection of servers at a lower trust level.  (In some deployment scenarios, the former might be a CDN and the latter might be either a different trust tier of CDN nodes or federated-but-less-trusted partners.)

The specific blind caching with a configured proxy cache is a well-defined use-case, but the others have many different ways to implement that trying to standardize something now before there has been more experience with implementations and business models seems like asking for trouble (and is something that some of us may be less interested in than in defining common underlying mechanisms and affordances to allow developing technologies in this area).

        Erik




On Thu, Jul 28, 2016 at 5:07 AM, Richard Bradbury <[hidden email]> wrote:
On 27/07/2016 11:33, Richard Bradbury wrote:
On 17/07/2016 18:03, Martin Thomson wrote:
We are having a meeting on blind caching on Tuesday 08:30 in
Charlottenburg I.  Folks who are interested are invited to join us.

Rough agenda is to discuss what this is, the status of specs and
implementations.  Then we are looking to get some input on the work
that has been done and what might need to happen next.

For those not familiar with this, the following drafts are recommended reading:
https://tools.ietf.org/html/draft-thomson-http-scd
https://tools.ietf.org/html/draft-thomson-http-bc
https://tools.ietf.org/html/draft-reschke-http-oob-encoding
https://tools.ietf.org/html/draft-thomson-http-mice
https://tools.ietf.org/html/draft-ietf-httpbis-encryption-encoding

Hi. Thanks for an interesting session last week.

Based on my reading of the Internet Drafts I think these are the two main Use Cases under consideration here:

  1. Blind caching in a CDN edge cache that is acting as a delegated origin server.
    • Described in draft-thomson-http-scd.
    • Making use of the techniques described in draft-reschke-http-oob-encoding, draft-thomson-http-mice and draft-ietf-httpbis-encryption-encoding.
  2. Blind caching in an explicitly configured proxy server.
    • Described in draft-thomson-http-bc.
    • Making use of the techniques described in draft-reschke-http-oob-encoding, draft-thomson-http-mice and draft-ietf-httpbis-encryption-encoding.

The discussion in Berlin last Tuesday morning flowed fairly freely between the two Use Cases, so I just wanted to check my understanding.


OK. Now I feed I understand Use Case 2 better, I attach a couple of sequences describing my (incomplete) understanding of Use Case 1 above. The main question in my mind here is whether the resources are explicitly pushed into the CDN cache (what I have called "Mode P") or whether they are retrieved on demand from the origin server by the CDN only on cache miss ("Mode G").

Perhaps you are looking to support both modes of operation? The Internet Draft could usefully clarify this.

Mode G
In the cache pull-through mode, there appears to be a requirement for the CDN to know the resource mapping in order to support the URL obfuscation feature. But that appears to negate one of the key benefits of the feature – keeping the mapping secret from the CDN provider. I'm clearly missing something here. Or maybe URL obfuscation just doesn't fly in this mode, which would be a shame since this is our primary mode of operation for some media types.
Mode P
With the push mode, the resource mapping can remain secret to the origin server, which is great. But the mechanism for pushing content onto the CDN remains a bit of a mystery, so I have made an educated guess on my diagram. Perhaps you intend this mechanism to remain private? In which case, perhaps the Internet Draft could include a note to this effect?

Clarifications and comments gratefully received.


Regards,
-- 
Richard Bradbury | Lead Research Engineer
BBC Research & Development
Centre House, 56 Wood Lane, London  W12 7SB.
T: 0303 040 9672  F: 020 8811 8815

Reply | Threaded
Open this post in threaded view
|

Re: Informal meeting on blind caching

Göran Eriksson AP


On 28/07/16 16:31, "[hidden email] on behalf of Erik Nygren" <[hidden email] on behalf of [hidden email]> wrote:

I also think that we shouldn't refer to "CDN" in this scenario as much as referring to delegating between a server acting as an authoritative origin and a collection of servers at a lower trust level.  (In some deployment scenarios, the former might be a CDN and the latter might be either a different trust tier of CDN nodes or federated-but-less-trusted partners.)

+1. We should not restrict the discussions (or mechanisms) to existing CDN deployments- using CDN's as concrete examples can be useful but we must not limit the discussion to these cases.

For instance, the case when the same actor is running the origin (primary) as well as the secondary server but on someone else site and/or could platform are also relevant. 

The specific blind caching with a configured proxy cache is a well-defined use-case, but the others have many different ways to implement that trying to standardize something now before there has been more experience with implementations and business models seems like asking for trouble (and is something that some of us may be less interested in than in defining common underlying mechanisms and affordances to allow developing technologies in this area).

Agreed. Getting the basic HTTP mechanisms in place should be the initial focus. But discussing different use cases may be useful when identifying requirements on the various mechanisms.

Regards
Göran
Reply | Threaded
Open this post in threaded view
|

Re: Informal meeting on blind caching

Kevin Marks
In reply to this post by Göran Eriksson AP
where is the x-object-meta-sha1base36 header used in the example defined?

On Tue, Jul 19, 2016 at 2:54 AM, Göran Eriksson AP
<[hidden email]> wrote:

> Hi,
>
> Slides from the meeting in PDF format attached.
>
> Drafts GitHub at: https://github.com/EricssonResearch/Blind-Cache-Drafts.
>
> Notes to come (before Wednesday lunch, promise).
>
> Regards
> Göran
>
>
>
>>
>>>
>>>On Sun, Jul 17, 2016 at 10:03 AM, Martin Thomson
>>><[hidden email]> wrote:
>>>> We are having a meeting on blind caching on Tuesday 08:30 in
>>>> Charlottenburg I.  Folks who are interested are invited to join us.
>>>>
>>>> Rough agenda is to discuss what this is, the status of specs and
>>>> implementations.  Then we are looking to get some input on the work
>>>> that has been done and what might need to happen next.
>>>>
>>>> For those not familiar with this, the following drafts are recommended
>>>>reading:
>>>> https://tools.ietf.org/html/draft-thomson-http-scd
>>>> https://tools.ietf.org/html/draft-thomson-http-bc
>>>> https://tools.ietf.org/html/draft-reschke-http-oob-encoding
>>>> https://tools.ietf.org/html/draft-thomson-http-mice
>>>> https://tools.ietf.org/html/draft-ietf-httpbis-encryption-encoding
>>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

RE: Informal meeting on blind caching

Mike Bishop
In reply to this post by Erik Nygren-2

I would go a little further and say that, at least initially, how the closer node gets the content is entirely an implementation detail and out of scope for the IETF, regardless of working group.

 

While you’re right that this isn’t restricted to CDNs, that’s the mental model that makes it easiest to understand.  There are several use-cases, each of which will have a different means of acquiring the content – and those means don’t need to be specified by this group in most cases.  If the origin is a CDN while the less-trusted server is a CDN node in an unsecured location, the content acquisition is entirely internal.  For the blind caching case, both servers are the same machine, so the acquisition is internal in an even-more-literal sense.  If the origin is a customer while the less-trusted server is a CDN, that mirrors existing deployments; we don’t seem to have a problem configuring where the CDN goes to get updated versions of a cached resource today, and I would imagine similar techniques could be applied here satisfactorily.

 

If use-cases arise beyond those that require an explicit “how do I find encrypted content <foo>?” protocol, we can pursue it then.  Let’s not muddy the waters in advance.

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Erik Nygren
Sent: Thursday, July 28, 2016 7:32 AM
To: Richard Bradbury <[hidden email]>
Cc: [hidden email] Group <[hidden email]>
Subject: Re: Informal meeting on blind caching

 

For the "Blind caching in a CDN edge cache that is acting as a delegated origin server" scenario I think we'd be better off separating out the high-level mechanism (ie, getting oob-encoding) right from the actual business model and implementation details for how the caches get populated.  The former is something we can tractably do here (have a way to delegate content bodies out to third-parties) but the latter is something that could easily fill up its own working group to get all of the details worked through.

I also think that we shouldn't refer to "CDN" in this scenario as much as referring to delegating between a server acting as an authoritative origin and a collection of servers at a lower trust level.  (In some deployment scenarios, the former might be a CDN and the latter might be either a different trust tier of CDN nodes or federated-but-less-trusted partners.)

The specific blind caching with a configured proxy cache is a well-defined use-case, but the others have many different ways to implement that trying to standardize something now before there has been more experience with implementations and business models seems like asking for trouble (and is something that some of us may be less interested in than in defining common underlying mechanisms and affordances to allow developing technologies in this area).

 

        Erik




On Thu, Jul 28, 2016 at 5:07 AM, Richard Bradbury <[hidden email]> wrote:

On 27/07/2016 11:33, Richard Bradbury wrote:

On 17/07/2016 18:03, Martin Thomson wrote:

We are having a meeting on blind caching on Tuesday 08:30 in
Charlottenburg I.  Folks who are interested are invited to join us.
 
Rough agenda is to discuss what this is, the status of specs and
implementations.  Then we are looking to get some input on the work
that has been done and what might need to happen next.
 
For those not familiar with this, the following drafts are recommended reading:
https://tools.ietf.org/html/draft-thomson-http-scd
https://tools.ietf.org/html/draft-thomson-http-bc
https://tools.ietf.org/html/draft-reschke-http-oob-encoding
https://tools.ietf.org/html/draft-thomson-http-mice
https://tools.ietf.org/html/draft-ietf-httpbis-encryption-encoding

 

Hi. Thanks for an interesting session last week.

Based on my reading of the Internet Drafts I think these are the two main Use Cases under consideration here:

  1. Blind caching in a CDN edge cache that is acting as a delegated origin server.
    • Described in draft-thomson-http-scd.
    • Making use of the techniques described in draft-reschke-http-oob-encoding, draft-thomson-http-mice and draft-ietf-httpbis-encryption-encoding.
  1. Blind caching in an explicitly configured proxy server.
    • Described in draft-thomson-http-bc.
    • Making use of the techniques described in draft-reschke-http-oob-encoding, draft-thomson-http-mice and draft-ietf-httpbis-encryption-encoding.

The discussion in Berlin last Tuesday morning flowed fairly freely between the two Use Cases, so I just wanted to check my understanding.

 

OK. Now I feed I understand Use Case 2 better, I attach a couple of sequences describing my (incomplete) understanding of Use Case 1 above. The main question in my mind here is whether the resources are explicitly pushed into the CDN cache (what I have called "Mode P") or whether they are retrieved on demand from the origin server by the CDN only on cache miss ("Mode G").

Perhaps you are looking to support both modes of operation? The Internet Draft could usefully clarify this.

Mode G

In the cache pull-through mode, there appears to be a requirement for the CDN to know the resource mapping in order to support the URL obfuscation feature. But that appears to negate one of the key benefits of the feature – keeping the mapping secret from the CDN provider. I'm clearly missing something here. Or maybe URL obfuscation just doesn't fly in this mode, which would be a shame since this is our primary mode of operation for some media types.

Mode P

With the push mode, the resource mapping can remain secret to the origin server, which is great. But the mechanism for pushing content onto the CDN remains a bit of a mystery, so I have made an educated guess on my diagram. Perhaps you intend this mechanism to remain private? In which case, perhaps the Internet Draft could include a note to this effect?

Clarifications and comments gratefully received.


Regards,

-- 
Richard Bradbury | Lead Research Engineer
BBC Research & Development
Centre House, 56 Wood Lane, London  W12 7SB.
T: 0303 040 9672  F: 020 8811 8815