Subject: [CDNi] Editorial comments on the CDNI charter.

From: zhouzhipeng <[email-masked]>
Date: Wed, 13 Apr 2011 12:09:13 +0800

Rich , Francois, all,

Some editorial comments for CDNI charter as below:

>operating at layer 4 through layer 7

That sentence will bring the meaning that CDN will cover from layer 4 to
layer 7. CDN may be considered either on service layer or an layer over IP
layer and below the service layer. And in fact these several words do not
make sense. May be moved.

>streaming of continuous media delivered via HTTP, RTSP, RTMP,

The RTSP is used to instruct ‘play’ or ‘pause’.  May say “delivered via
HTTP, RTP”.

>a description of the different components of the CDNI solution and how they
interact with and relate to one another.

I think ‘solution’ should be ‘architecture’ and ‘relate to’ seems
redundant .

>"threat analysis" discussing the security concerns and threats, the trust
model and privacy issues specific to CDNI 

I think all security related issues associated to the architecture is the
“trust model”.

Hence it may be :" trust model " discussing the security concerns and
threats, and privacy issues specific to CDNI

Another , Should CDNI co-work with another WG on security area.

>A "framework" document providing a …

I think it needs to clarify acquiring content across CDN should be defined
in the “framework” even if we do not define new protocols.

>A "requirements" document. This document lists the requirements for CDNI
architecture and the protocols 

As for the protocols here, are they existing protocols or new protocols. 

Besides, in the end of this charter, it says some protocols will not be
defined in this WG. So, clarification is expected.

>This document will list the requirements stemming from the threat analysis
and to be met by each of the CDNI interfaces

How may we understand its relationship to the first sentence in this section
“This document lists the requirements for CDNI architecture and the
protocols to support it.”

>This interface will allow an upstream CDN request routing system to obtain
from the downstream CDN the information necessary to perform request
redirection.

May the downstream CDN also request some information from the upstream CDN
for further transfer? I think ‘yes’.

>Distribution metadata refers to the subset of content metadata

I think the “distribution metadata” is the superset of “content
metadata” not the subset. For example, whether the location information of
the end user belong to “ content metadata”.

>CDN control systems. In particular, this interface will allow an upstream
CDN to remove or invalidate content in a downstream CDN.
It is not “control” since two CDNs only take the contract for CDN
interconnection.

It may be “CDN service management” rather than “control”. Besides
“remove content from the downstream CDN”, the upstream CDN mainly may
inform downstream CDN where/who the content is issued to.  

Another, for all these bullets of “systems”, I think the word
“interface” is better than “systems”. “Systems” means multiple
system:) and the explanation following also use the word “interface”: this
interface will….

Thanks.

Zhipeng

-----------------------------------------------------

Huawei Software Technologies Co.,Ltd.

No.101，Software Avenue,Yuhuatai District,Nanjing, P.R.of China
Zipcode:210012
E-Mail:  <mailto:[email-masked]> [email-masked]
Phone:(+86) 25-56620690

Fax:(+86) 25-56624081

Mobile:(+86) 13404162849
-----------------------------------------------------

  _____

---

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 13 Apr 2011 10:52:36 +0200

Hello Zhipeng,

> Some editorial comments for CDNI charter as below:

I understand that the draft charter would be subject to editing by IESG/IAB anyways, but let's see if we can converge anyways.

> That sentence will bring the meaning that CDN will cover from layer 4 to layer 7.

Yes. This sentence is indeed claiming that CDNs can generally be considered as an overlay on top of an IP network and operating over layers 4, 5, 6 and 7. 
That seems reasonable.

> CDN may be considered either on service layer or an layer over IP layer and below the service layer. And in fact these several words do not make sense. May be moved.
> The RTSP is used to instruct ‘play’ or ‘pause’.  May say “delivered via HTTP, RTP”.

How about:
" ... and streaming of continuous media controlled and delivered via HTTP, RTSP/RTP, RTMP, etc."

> >a description of the different components of the CDNI solution and how they interact with and relate to one another.
> I think ‘solution’ should be ‘architecture’ and ‘relate to’ seems redundant .

OK.

> >"threat analysis" discussing the security concerns and threats, the trust model and privacy issues specific to CDNI
> I think all security related issues associated to the architecture is the “trust model”.
> Hence it may be :" trust model " discussing the security concerns and threats, and privacy issues specific to CDNI

I don't agree with that.
To me there needs to be a generic "threat analysis" that discusses all various ways the system may be cheated/attacked. In doing so, it should discuss the "trust model" which is one particular element of this analysis. "Privacy" is another particular angle that needs to be discussed.
I don't see an issue with the current text.

> Another , Should CDNI co-work with another WG on security area.

The draft charter already says that the CDNI WG should work with other relevant WGs. If there is one particular group where it is very clear that CDNI would work with, then it could be mentioned in the charter.

> I think it needs to clarify acquiring content across CDN should be defined in the “framework” even if we do not define new protocols.

It is clear that the framework needs to discuss how content acquisition needs to take place between CDNs, just like it needs to cover how request-routing will take place, and how distribution metadata exchange needs to take place...
The current description is deliberately kept succinct and just says the framework needs to cover all architecture components. I don't see a need to explicitly bring up "acquisition".

> >A "requirements" document. This document lists the requirements for CDNI architecture and the protocols

This is an editing issue. This should have been converted to "interfaces" instead of "protocols". It now reads:
"This document lists the requirements for the CDNI architecture and the CDNI interfaces."

> Besides, in the end of this charter, it says some protocols will not be defined in this WG. So, clarification is expected.
> >This document will list the requirements stemming from the threat analysis and to be met by each of the CDNI interfaces
> How may we understand its relationship to the first sentence in this section “This document lists the requirements for CDNI architecture and the protocols to support it.”

It should be clear now based on the previous correction.
i.e. in particular, the "requirements" document will identify the requirements related to threat/security for each CDNI interface. 

> >This interface will allow an upstream CDN request routing system to obtain from the downstream CDN the information necessary to perform request redirection.
> May the downstream CDN also request some information from the upstream CDN for further transfer? I think ‘yes’.

Not sure I follow that. 

> I think the “distribution metadata” is the superset of “content metadata” not the subset.

Please see the definitions of "Content Metadata" and "Content Distribution Metadata" in the Problem Statement.

> For example, whether the location information of the end user belong to “ content metadata”.
> >CDN control systems. In particular, this interface will allow an upstream CDN to remove or invalidate content in a downstream CDN.
> It is not “control” since two CDNs only take the contract for CDN interconnection.

It is "control" in the sense that one CDN can trigger actions in another CDN.

> It may be “CDN service management” rather than “control”. Besides “remove content from the downstream CDN”, the upstream CDN mainly may inform downstream CDN where/who the content is issued to.  

There is a very strong agreement that CDNI needs to allow the uCDN to trigger/request removal of content in dCDN.

> Another, for all these bullets of “systems”, I think the word “interface” is better than “systems”. “Systems” means multiple system:) and the explanation following also use the word “interface”: this interface will….

The flow of the current text is :
"
	> The working group will focus on the following items: 
		...
		- A detailed specification of the interfaces for the interconnection & interoperation of:
				...
				o CDNI xxx systems.
"
So it should be read as saying that the "WG will specify an interface for the interconnection of CDNI xxx systems."
But I can see that the flow is hard to get through the multiple levels of indentation.

So, unless we hear disagreement, we can take your suggestion and make it read as:
"
	> The working group will focus on the following items: 
		...
		- A specification of the CDNI xxx interface:
"

Thanks

Francois

> E-Mail: [email-masked]
> Phone:(+86) 25-56620690
> Fax:(+86) 25-56624081
> Mobile:(+86) 13404162849

---

From: zhouzhipeng <[email-masked]>
Date: Thu, 14 Apr 2011 15:40:56 +0800

Francois, all:

FYI that:

In the “Problem Statement”, it reads Content Distribution Metadata rather
than Distribution Metadata.

Anyway, the terminations may be discussed more later while I think
Distribution Metadata and Content Metadata can be two different kinds.

For the “trust model”, I had ever sent an email two days before while
seems that it has not been successfully post to the reflector.

Here I copy again in this email as below for reference:

The market requirement for CDNI is to make the CDN service been extensible
by connecting multiple CDNs.

Hence the goal if been realized will be beneficial for the whole CDN
industry chain. The CP may cover more consumers. The consumer may get more
services.

The CDN will have more development.

To achievement the goal as above, the CDNI is very crucial to cover all the
interfaces(connection) including CP-UE, CP-CDN, CDN-CDN.

Just because the service chain will include multiple entities, the trust
chain should be defined before service initiation.( in fact such trust chain
should be the core problem to be solved in CDNI group) 

By for now, I just feel the discussion is whether we should give more
clarified information in the charter.

My opinion is 'yes' since the trust model will determine whether the CDNI
service would be appropriate in the practice hence.

The information needed for exchange totally should be based on the trust
model. Without the trust model, how may we know exactly what will be
exchanged between two CDNs.

We should first get a clear view how multiple entities cooperate in a
complete service not just a simple picture that two CDNs should exchange
some specific information. 

Zhipeng

发件人: Francois Le Faucheur [mailto:[email-masked]] 
发送时间: 2011年4月13日 16:53
收件人: zhouzhipeng
抄送: Francois Le Faucheur; 'Woundy, Richard'; [email-masked]
主题: Re: Editorial comments on the CDNI charter.

Hello Zhipeng,

Rich , Francois, all,

I understand that the draft charter would be subject to editing by IESG/IAB
anyways, but let's see if we can converge anyways.

layer 7. 

Yes. This sentence is indeed claiming that CDNs can generally be considered
as an overlay on top of an IP network and operating over layers 4, 5, 6 and
7. 

That seems reasonable.

CDN may be considered either on service layer or an layer over IP layer and
below the service layer. And in fact these several words do not make sense.
May be moved.

How about:

" ... and streaming of continuous media controlled and delivered via HTTP,
RTSP/RTP, RTMP, etc."

OK.

I don't agree with that.

To me there needs to be a generic "threat analysis" that discusses all
various ways the system may be cheated/attacked. In doing so, it should
discuss the "trust model" which is one particular element of this analysis.
"Privacy" is another particular angle that needs to be discussed.

The draft charter already says that the CDNI WG should work with other
relevant WGs. If there is one particular group where it is very clear that
CDNI would work with, then it could be mentioned in the charter.

It is clear that the framework needs to discuss how content acquisition
needs to take place between CDNs, just like it needs to cover how
request-routing will take place, and how distribution metadata exchange
needs to take place...

The current description is deliberately kept succinct and just says the
framework needs to cover all architecture components. I don't see a need to
explicitly bring up "acquisition".

This is an editing issue. This should have been converted to "interfaces"
instead of "protocols". It now reads:

"This document lists the requirements for the CDNI architecture and the CDNI
interfaces."

i.e. in particular, the "requirements" document will identify the
requirements related to threat/security for each CDNI interface. 

Not sure I follow that. 

I think the “distribution metadata” is the superset of “content
metadata” not the subset.

Please see the definitions of "Content Metadata" and "Content Distribution
Metadata" in the Problem Statement.

For example, whether the location information of the end user belong to “
content metadata”.

It is "control" in the sense that one CDN can trigger actions in another
CDN.

There is a very strong agreement that CDNI needs to allow the uCDN to
trigger/request removal of content in dCDN.

"

       ...

       - A detailed specification of the interfaces for the interconnection
& interoperation of:

              ...

              o CDNI xxx systems.

"

So it should be read as saying that the "WG will specify an interface for
the interconnection of CDNI xxx systems."

But I can see that the flow is hard to get through the multiple levels of
indentation.

So, unless we hear disagreement, we can take your suggestion and make it
read as:

"

       ...

"

Thanks

Francois

Thanks.

Zhipeng

Fax:(+86) 25-56624081

Mobile:(+86) 13404162849

  _____

---

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 14 Apr 2011 10:20:58 +0200

Hi Zhipeng,

On 14 Apr 2011, at 09:40, zhouzhipeng wrote:

> Francois, all:
> FYI that:
> In the “Problem Statement”, it reads Content Distribution Metadata rather than Distribution Metadata.

OK. the draft charter text has been updated to say "content distribution metadata".

> Anyway, the terminations may be discussed more later while I think Distribution Metadata and Content Metadata can be two different kinds.
>  
> For the “trust model”, I had ever sent an email two days before while seems that it has not been successfully post to the reflector.
> The market requirement for CDNI is to make the CDN service been extensible by connecting multiple CDNs.
> Hence the goal if been realized will be beneficial for the whole CDN industry chain. The CP may cover more consumers. The consumer may get more services.
> To achievement the goal as above, the CDNI is very crucial to cover all the interfaces(connection) including CP-UE, CP-CDN, CDN-CDN.
> Just because the service chain will include multiple entities, the trust chain should be defined before service initiation.( in fact such trust chain should be the core problem to be solved in CDNI group)
> By for now, I just feel the discussion is whether we should give more clarified information in the charter.
> My opinion is 'yes' since the trust model will determine whether the CDNI service would be appropriate in the practice hence.
> The information needed for exchange totally should be based on the trust model. Without the trust model, how may we know exactly what will be exchanged between two CDNs.

I believe there is agreement that the trust model impacts some detailed aspects of the CDNI interfaces.
This is why the draft charter does identify documentation of the trust model as part of the early deliverables (the "framework").

Thanks

Francois

> We should first get a clear view how multiple entities cooperate in a complete service not just a simple picture that two CDNs should exchange some specific information.
>  
> Zhipeng
>  

Francois Le Faucheur
Distinguished Engineer
Corporate Development
[email-masked]
Phone: +33 49 723 2619
Mobile: +33 6 19 98 50 90

Cisco Systems France
Greenside
400 Ave de Roumanille
06410 Sophia Antipolis
France
Cisco.com

 Think before you print.

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

Cisco Systems France, Société à responsabiité limitée, Rue Camille Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Moulineaux, Au capital de 91.470 �, 349 166 561 RCS Nanterre, Directeur de la publication: Jean-Luc Michel Givone.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: zhouzhipeng <[email-masked]>
Date: Thu, 14 Apr 2011 17:21:54 +0800

Hi Francois,

As you said, ‘trust model’ and ‘framework’ are the two sides of one
thing.

We plan to support different business models(even some new are expected).

Perhaps one sentence may be included into that section:

“This document will include several architectures in terms of possible
trust models of CDN Interconnection”.

Thks.

Zhipeng

发件人: Francois Le Faucheur [mailto:[email-masked]] 
发送时间: 2011年4月14日 16:21
收件人: zhouzhipeng
抄送: Francois Le Faucheur; 'Woundy, Richard'; [email-masked]
主题: Re: 答复: Editorial comments on the CDNI charter.

Hi Zhipeng,

Francois, all:

FYI that:

OK. the draft charter text has been updated to say "content distribution
metadata".

I believe there is agreement that the trust model impacts some detailed
aspects of the CDNI interfaces.

This is why the draft charter does identify documentation of the trust model
as part of the early deliverables (the "framework").

Thanks

Francois

Zhipeng

Hello Zhipeng,

Rich , Francois, all,

 

That seems reasonable.

How about:

OK.

I don't agree with that.

Not sure I follow that. 

"

       ...

              ...

              o CDNI xxx systems.

"

"

       ...

"

Thanks

Francois

Thanks.

Zhipeng

Fax:(+86) 25-56624081

Mobile:(+86) 13404162849

  _____  

	

Francois Le Faucheur
Distinguished Engineer
Corporate Development
 <mailto:[email-masked]> [email-masked]
Phone: +33 49 723 2619
Mobile: +33 6 19 98 50 90

Cisco Systems France
Greenside
400 Ave de Roumanille
06410 Sophia Antipolis
France
 <http://www.cisco.com> Cisco.com

 Think before you print.

This email may contain confidential and privileged material for the sole use
of the intended recipient. Any review, use, distribution or disclosure by
others is strictly prohibited. If you are not the intended recipient (or
authorized to receive for the recipient), please contact the sender by reply
email and delete all copies of this message.

Cisco Systems France, Société à responsabiité limitée, Rue Camille
Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Moulineaux,
Au capital de 91.470 �, 349 166 561 RCS Nanterre, Directeur de la
publication: Jean-Luc Michel Givone.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 14 Apr 2011 14:46:22 +0100

On 14 Apr 2011, at 10:21, zhouzhipeng wrote:

> Hi Francois,
> As you said, ‘trust model’ and ‘framework’ are the two sides of one thing.
> “This document will include several architectures in terms of possible trust models of CDN Interconnection”.

I'm concerned that there seems to be a lot of suggestions (of which this is only one) to try and make the charter overly precise.

What we want is a WG to work on the problem, the charter covers the scope of the WG it does not solve the problem the WG will be tasked to solve.

Once we have a WG, the WG can decide whether a single trust model architecture is sufficient or not. If we start making decisions like that now and baking them into the charter without having actually done the necessary due diligence (as such due diligence is part of the work of the WG not of the charter scope) the chance that the decision we make is no better than a random decision is approximately 1 IMO.

Ben

---

From: "Woundy, Richard" <[email-masked]>
Date: Thu, 14 Apr 2011 14:00:07 +0000

I tend to agree. We are not going to decide on the final charter text on this mailing list. It will be negotiated and approved by the area director and the IESG/IAB. See http://tools.ietf.org/html/rfc2418#section-2.2 for details.

If there are significant missing items with regards to WG scope, let's discuss them. But let's not spend too much more time with editorial changes.
________________________________________
From: [email-masked] [[email-masked]] on behalf of Ben Niven-Jenkins [[email-masked]]
Sent: Thursday, April 14, 2011 9:46 AM
To: zhouzhipeng
Cc: [email-masked]
Subject: Re: [CDNi] 答复: 答复: Editorial comments on the CDNI charter.

Ben

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

---

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 14 Apr 2011 16:35:30 +0200

> What we want is a WG to work on the problem, the charter covers the scope of the WG it does not solve the problem the WG will be tasked to solve.

+1.

Francois

---

From: zhouzhipeng <[email-masked]>
Date: Fri, 15 Apr 2011 14:40:20 +0800

I tend to agree with U on the understanding of ‘charter’.

Although the charter may be renegotiated later, we may solve the problems
once we find them: )

Since the charter covers the scope of the WG, it should be careful of the
wording of the scope. 

The comment is to avoid the ambiguity clarifying the relationship of “trust
model” and the “architecture” .

Zhipeng

发件人: Francois Le Faucheur [mailto:[email-masked]] 
发送时间: 2011年4月14日 22:35
收件人: zhouzhipeng 54906
抄送: Le Faucheur Francois; [email-masked]; Niven-Jenkins Ben
主题: Re: [CDNi] 答复: 答复: Editorial comments on the CDNI charter.

Hi Francois,

I'm concerned that there seems to be a lot of suggestions (of which this is
only one) to try and make the charter overly precise.

What we want is a WG to work on the problem, the charter covers the scope of
the WG it does not solve the problem the WG will be tasked to solve.

+1.

Francois

Once we have a WG, the WG can decide whether a single trust model
architecture is sufficient or not. If we start making decisions like that
now and baking them into the charter without having actually done the
necessary due diligence (as such due diligence is part of the work of the WG
not of the charter scope) the chance that the decision we make is no better
than a random decision is approximately 1 IMO.

Ben