Subject: Re: [CDNi] 答复: 答复: 答复: Updated version of the CDNI charter

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 19 Apr 2011 03:16:52 +0000

Hi Xiaoyan,

IMHO why we only explicitly mention removal and invalidate of the content because there is a business requirement to remove a content. However, there is no business requirement to add or inject the content. When we design the content API, I think it is natural to define an API to ask the dCDN to add a content, however, the dCDN can reject it if it dodsn't want to add it. For removal, the dCDN must honor it due to business (legal) requirement. This is why only removal was listed in the charter.

Does this make sense to you?

Kind regards,
Yiu

From: He Xiaoyan <[email-masked]<mailto:[email-masked]>>
Date: Tue, 19 Apr 2011 11:09:02 +0800
To: Microsoft Office User <[email-masked]<mailto:[email-masked]>>, 'Ben Niven-Jenkins' <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>
Subject: 答复: [CDNi] 答复: 答复: Updated version of the CDNI charter

My comment is control of a content not only includes removal and invalidate, it should also includes ingesting/adding a content?  Why we exclude adding the content but emphasize removal and invalidate in control API in the charter? Then where is the description of adding a content (if content acquisition under metadata API in not equivalent to adding a content)?
Thanks for your clarification.

---

From: He Xiaoyan <[email-masked]>
Date: Tue, 19 Apr 2011 11:42:28 +0800

Hi Yiu,

IMO, content acquisition is equivalent to add or inject the content which
means pre-position or dynamic acquisition alternatives in technique words.
We’ve already have some description of content acquisition in the charter.

What’s your thought on the difference of “content acquisition” and ”add
or inject a content”? 

Best Regards

Xiaoyan(Susan) He

  _____  

发件人: Lee, Yiu [mailto:[email-masked]] 
发送时间: 2011年4月19日 11:17
收件人: He Xiaoyan; 'Ben Niven-Jenkins'
抄送: [email-masked]
主题: Re: 答复: [CDNi] 答复: 答复: Updated version of the CDNI charter

Hi Xiaoyan,

IMHO why we only explicitly mention removal and invalidate of the content
because there is a business requirement to remove a content. However, there
is no business requirement to add or inject the content. When we design the
content API, I think it is natural to define an API to ask the dCDN to add a
content, however, the dCDN can reject it if it dodsn't want to add it. For
removal, the dCDN must honor it due to business (legal) requirement. This is
why only removal was listed in the charter.

Kind regards,

Yiu

From: He Xiaoyan <[email-masked]>
Date: Tue, 19 Apr 2011 11:09:02 +0800
To: Microsoft Office User <[email-masked]>, 'Ben Niven-Jenkins'
<[email-masked]>
Cc: <[email-masked]>
Subject: 答复: [CDNi] 答复: 答复: Updated version of the CDNI charter

My comment is control of a content not only includes removal and invalidate,
it should also includes ingesting/adding a content?  Why we exclude adding
the content but emphasize removal and invalidate in control API in the
charter? Then where is the description of adding a content (if content
acquisition under metadata API in not equivalent to adding a content)?

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 19 Apr 2011 13:24:07 +0000

Hi Xiaoyan,

IMHO, the charter should not be too specific of what method we would support for the CDNI (pre-position vs. dynamic content acquisition). This is more like an architecture discussion. This is why the charter doesn't mention pre-position or dynamic content acquisition. That said, the charter explicitly mentions we need to support content removal because this is a strong requirement coming from both Content Providers and CDN operators to make sure the content must be invalidated by request.

Thoughts?
/Yiu

From: He Xiaoyan <[email-masked]<mailto:[email-masked]>>
Date: Tue, 19 Apr 2011 11:42:28 +0800
To: Microsoft Office User <[email-masked]<mailto:[email-masked]>>, 'Ben Niven-Jenkins' <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>
Subject: 答复: 答复: [CDNi] 答复: 答复: Updated version of the CDNI charter

Hi Yiu,
IMO, content acquisition is equivalent to add or inject the content which means pre-position or dynamicacquisition alternatives in technique words.  We’ve already have some description of content acquisition in the charter.
What’s your thought on the difference of “content acquisition” and ”add or inject a content”?

Best Regards
Xiaoyan(Susan) He
________________________________
发件人: Lee, Yiu [mailto:[email-masked]]
发送时间: 2011年4月19日 11:17
收件人: He Xiaoyan; 'Ben Niven-Jenkins'
抄送: [email-masked]<mailto:[email-masked]>
主题: Re: 答复: [CDNi] 答复: 答复: Updated version of the CDNI charter

Hi Xiaoyan,

IMHO why we only explicitly mention removal and invalidate of the content because there is abusiness requirement to remove a content. However, there is no business requirement to add or inject the content. When we design the content API, I think it is natural to define an API to ask the dCDN to add a content, however, the dCDN can reject it if it dodsn't want to add it. For removal, the dCDN musthonor it due to business (legal) requirement. This is why only removal was listed in the charter.

Kind regards,
Yiu

My comment is control of acontent not only includes removal and invalidate, it should also includes ingesting/adding a content?  Why we exclude adding the content but emphasize removal and invalidate in control API in the charter? Then where is the description of adding a content (if content acquisition under metadata API in not equivalent to adding a content)?
Thanks for your clarification.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 19 Apr 2011 14:44:51 +0100

On 19 Apr 2011, at 04:09, He Xiaoyan wrote:
> I am also OK with the roles of control API and metadata API regarding the content and metadata as you and Ben stated “Control API will be used to control "the content" in the downstream CDN and Metadata API will be used to control "the Metadata" associated with the content in the downstream CDN”.
>  
> My comment is control of a content not only includes removal and invalidate, it should also includes ingesting/adding a content?

No. Look at how the majority of deployed CDNs operate today. Content acquisition is performed dynamically on demand, it is not "controlled" directly by an upstream point (Content Provider or in the case of CDNI an upstream CDN).

When a surrogate receives a request for content from a user it retrieves the metadata associated with that content, validates that it should deliver the content (e.g. geo-blocking and authorisation policies are met) and then acquires the content on demand if it is not already cached. The description of how to acquire the content is part of the distribution metadata. It is not a specific control request.

>  Why we exclude adding the content but emphasize removal and invalidate in control API in the charter? Then where is the description of adding a content (if content acquisition under metadata API in not equivalent to adding a content)?

As I stated during my presentation at the BoF the control interface is primarily about effecting or reporting state changes in another CDN.

When a Content Provider (or upstream CDN) needs a downstream CDN to invalidate or remove content they need to specifically ask for that action to occur - i.e. "Can you please invalidate/remove this content". They would not typically specifically request an acquisition action - i.e. the acquisition semantic is for the upstream CDN to say "here is the metadata for the content and it includes how to come and get it when you need to do that", the semantic is not "Can you come and acquire this piece of content now".

Also remember that content invalidation/removal is a strong requirement placed on deployed CDNs today and therefore critical to having a solution that is acceptable to the market. Content pre-positioning is not.

Ben

---

From: He Xiaoyan <[email-masked]>
Date: Wed, 20 Apr 2011 15:26:03 +0800

Hi Ben,
I do not have any strong position on content pre-position, I agree that
whether to support it in CDNi is up to the operators.

I think our opinion diverge from each other on which API should link to the
dynamic content acquisition request. IMO, when cache miss occurred in a
downstream CDN, the request of it send to the upstream CDN to know where and
how to obtain the content is an implementation of content acquisition(pull
model) ,this is relevant to content not metadata, hence,It should be put
under the control API (relevant to content) not metadata API.

Dynamic content acquisition request, and other content management
requests(removal, invalidation, distribution status report etc) should all
implement in one API, split them to two different APIs will make Control API
incomplete(lack of content acquisition request)， meanwhile will make
Metadata API intertwined(involved both content acquisition request, and
other metadata distribution request).

Whether to put dynamic content acquisition request under control API is not
a strong opinion. However, IMO, it would make metadata and control API more
clear from functionality definition. 

Best Regards
Xiaoyan(Susan) He
-----邮件原件-----
发件人: Ben Niven-Jenkins [mailto:[email-masked]] 
发送时间: 2011年4月19日 21:45
收件人: He Xiaoyan
抄送: 'Lee, Yiu'; [email-masked]
主题: Re: 答复: [CDNi] 答复: 答复: Updated version of the CDNI charter

On 19 Apr 2011, at 04:09, He Xiaoyan wrote:
> I am also OK with the roles of control API and metadata API regarding the
content and metadata as you and Ben stated “Control API will be used to
control "the content" in the downstream CDN and Metadata API will be used to
control "the Metadata" associated with the content in the downstream CDN”.
>  
> My comment is control of a content not only includes removal and
invalidate, it should also includes ingesting/adding a content?

No. Look at how the majority of deployed CDNs operate today. Content
acquisition is performed dynamically on demand, it is not "controlled"
directly by an upstream point (Content Provider or in the case of CDNI an
upstream CDN).

When a surrogate receives a request for content from a user it retrieves the
metadata associated with that content, validates that it should deliver the
content (e.g. geo-blocking and authorisation policies are met) and then
acquires the content on demand if it is not already cached. The description
of how to acquire the content is part of the distribution metadata. It is
not a specific control request.

>  Why we exclude adding the content but emphasize removal and invalidate in
control API in the charter? Then where is the description of adding a
content (if content acquisition under metadata API in not equivalent to
adding a content)?
> Thanks for your clarification.

As I stated during my presentation at the BoF the control interface is
primarily about effecting or reporting state changes in another CDN.

When a Content Provider (or upstream CDN) needs a downstream CDN to
invalidate or remove content they need to specifically ask for that action
to occur - i.e. "Can you please invalidate/remove this content". They would
not typically specifically request an acquisition action - i.e. the
acquisition semantic is for the upstream CDN to say "here is the metadata
for the content and it includes how to come and get it when you need to do
that", the semantic is not "Can you come and acquire this piece of content
now".

Also remember that content invalidation/removal is a strong requirement
placed on deployed CDNs today and therefore critical to having a solution
that is acceptable to the market. Content pre-positioning is not.

Ben

---

From: He Xiaoyan <[email-masked]>
Date: Wed, 20 Apr 2011 15:30:02 +0800

Hi Yiu,

Please see my  response to Ben in another e-mail. 

Best Regards

Xiaoyan(Susan) He

  _____  

发件人: Lee, Yiu [mailto:[email-masked]] 
发送时间: 2011年4月19日 21:24
收件人: He Xiaoyan; 'Ben Niven-Jenkins'
抄送: [email-masked]
主题: Re: 答复: 答复: [CDNi] 答复: 答复: Updated version of the CDNI charter

Hi Xiaoyan,

IMHO, the charter should not be too specific of what method we would support
for the CDNI (pre-position vs. dynamic content acquisition). This is more
like an architecture discussion. This is why the charter doesn't mention
pre-position or dynamic content acquisition. That said, the charter
explicitly mentions we need to support content removal because this is a
strong requirement coming from both Content Providers and CDN operators to
make sure the content must be invalidated by request.

Thoughts?

/Yiu

Hi Yiu,

IMO, content acquisition is equivalent to add or inject the content which
means pre-position or dynamicacquisition alternatives in technique words.
We’ve already have some description of content acquisition in the charter.

Best Regards

Xiaoyan(Susan) He

  _____  

Hi Xiaoyan,

IMHO why we only explicitly mention removal and invalidate of the content
because there is abusiness requirement to remove a content. However, there
is no business requirement to add or inject the content. When we design the
content API, I think it is natural to define an API to ask the dCDN to add a
content, however, the dCDN can reject it if it dodsn't want to add it. For
removal, the dCDN musthonor it due to business (legal) requirement. This is
why only removal was listed in the charter.

Kind regards,

Yiu

My comment is control of acontent not only includes removal and invalidate,

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 20 Apr 2011 13:19:22 +0000

Hi Xiaoyan,

I think this is where we diverse. The current charter only states what the
WG must work on, it absolutely makes no assumption "how" the API should
look like. When we develop the protocol and decide to have a single API
for all these functions, it is fine. But this should not part of the
charter.

Regards,
/Yiu

On 4/20/11 3:26 AM, "He Xiaoyan" <[email-masked]> wrote:

>APIs will make Control API