Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

From: Scott Wainner <[email-masked]>
Date: Mon, 03 Oct 2011 09:36:55 -0400

Kevin,

     My comments in-line ...

On 9/30/11 10:45 AM, Kevin J Ma wrote:
>
> Hi Scott,
>
>   We are currently updating section 2.3.  I think the nomadic use case
>   includes not only geographic extension, but more generically footprint
>   extension.  A carrier CDN with only an in-network presense for specific
>   devices (e.g., mobile vs TV) may want to increase its device footprint
>   by interconnecting with another local carrier CDN that supports other
>   devices or subscribers.  We are also looking at removing section 5.1.3.
>
Understood.
>
>
> > As an example, the uCDN might use URL appended
> > tokens for authentication while dCDN might use URL appended hashes.
>   ...
> > Clearly, the choice of
> > authentication method is determined by the respective CDN's.
>
>   Content providers typically implement apps today with an 
> understanding that
>   the uCDN has a specific authentication method.  If the uCDN delegates
>   delivery to a dCDN that the content provider has no relationship 
> with, the
>   app may have no ability to switch authentication methods.  Would the 
> uCDN be
>   responsible for generating of the proper dCDN credentials for the user?
>
That is exactly my point.  I don't have an answer.

The CSP may accept the uCDN's approach to authentication; however, that 
method of authentication may not be supported on the dCDN which has the 
authority to choose its own method of authentication independent of the CSP.

1. Does the dCDN have to support multiple authentication methods - one 
for each uCDN it establishes a relationship?

2. Does the uCDN have to support (and get approval from the CSP) for 
multiple authentication methods - one for each dCDN for which it 
establishes a relationship?

3. Do we define a standard authentication method between the client and 
all CDN such that the CSP approves one method and all uCDN and dCDN 
support the standard method?

4. Do we define a proxy authentication method where the dCDN 
authenticates the client using their method of choice, the uCDN 
authenticates clients using their method of choice, AND CDNi defines a 
standard proxy method between the dCDN and uCDN?  In this case, the CSP 
must accept that the methods used by dCDN and uCDN are equivalent but 
not necessarily the same.

In what manner is the client informed of the appropriate method to 
authenticate their transaction with either the dCDN or uCDN?

Scott
>
>
> thanx.
>
> --  Kevin J. Ma
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of
> > Scott Wainner
> > Sent: Thursday, September 29, 2011 8:02 PM
> > To: [email-masked]
> > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
> >
> > Section 2.3 Nomadic Users
> >    This description falls under the category of Geographic Extension yet
> > the third paragraph states the case where a different device is used in
> > the same CDN coverage area.  The intent of this use case needs to be
> > clarified.  Perhaps the use case is trying to address the scenario where
> > a Nomadic User-A with an agreement allowing access to content from CSP-A
> > via uCDN moves to a dCDN in a different region.  The dCDN is allowed to
> > distribute the content of CSP-A to User-A; however, not other users in
> > the region of the dCDN are allowed to retrieve the content unless they
> > too have such an agreement.
> >
> > Section 5.1.3 Content Encoding Restrictions
> >    Need to clarify if we're talking about the restrictions on the
> > delivery of specific content or the restrictions on the ability of a CDN
> > to deliver specific content.  I certainly understand the case where a
> > CSP will restrict the distribution of content to a "managed path" if
> > such content is HD while allowing the content distribution via an
> > un-managed path if such content is SD (same could apply to encryption
> > methods, delivery methods, etc.).  On the contrary, the dCDN may have
> > its own restrictions of blocking the distribution of HD content while
> > allowing the distribution of SD content.
> >
> >    o first bullet makes sense if the dCDN can perform a subset of
> > encapsulations for a reference set of media (e.g. HLS, HSS, but not 
> DASH)
> >    o second bullet makes sense where the dCDN doesn't want to offer high
> > bit-rate variants of the media
> >    o third bullet make sense if the policy addresses QoE but I don't
> > think subscriber rights/authorizations apply.
> >
> > Section 10 Security Considerations
> >
> > Aside from the security considerations WITHIN the uCDN and dCDN, I think
> > we can describe this in four contexts:
> >
> > a. The relationship between the CSP and the uCDN (the principle contract
> > arrangement for distribution)
> > b. The relationship between the uCDN and dCDN (the transitive trust
> > relationship that extends the contract defined in (a) above)
> > c. The relationship between the User and dCDN (the recognition of right
> > to download predicated on (b) above)
> > d. The relationship between the User and CSP (the contract authorizing
> > the user access to the content)
> >
> > The user is not interested in the a-b nor the b-c relationship. The user
> > is only interested in the transparency and interoperability of the
> > security relationship between d-b or d-c to the point that the
> > authorization granted in d-a is viable when the delivery is initiated
> > via either d-b or d-c.  As an example, the uCDN might use URL appended
> > tokens for authentication while dCDN might use URL appended hashes.  The
> > user doesn't want to know about the distinct methods, but transparency
> > is only afforded if the methods are interoperable clearly defined when
> > the delegation for content delivery is executed.  Clearly, the choice of
> > authentication method is determined by the respective CDN's.
> >
> > Scott
> > _______________________________________________
> > CDNi mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/cdni
>

---

From: Kevin J Ma <[email-masked]>
Date: Mon, 3 Oct 2011 14:27:50 -0400

Hi Scott,

  One option is that CPs that want strict authentication do not allow delegation.
  In a non-interconnected environment, the CP has to configure the authentication
  method on each CDN?  If the uCDN is going to delegate to a dCDN, the uCDN would
 have to configure the dCDN on behalf of the CP (passwords, certs, etc.)?  That
 brings up other transative trust issues that this CP probably does not want to
 deal with?  For other CPs, imo, end user transparency is the most important.
  That could mean options 1 or 3 as you describe them below, or possibly a proxy
 where the dCDN sends the credentials to the uCDN for verification, so that the
 client does not need to know anything about the dCDN?

  wrt the use case draft, do you feel that the security section needs expanded, or
  that additional use cases are required?

thanx.

--  Kevin J. Ma

From: Scott Wainner [mailto:[email-masked]]
Sent: Monday, October 03, 2011 9:37 AM
To: Kevin J Ma
Cc: [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Kevin,

    My comments in-line ...

Hi Scott,

  ...
  > authentication method is determined by the respective CDN's.

  Content providers typically implement apps today with an understanding that
  the uCDN has a specific authentication method.  If the uCDN delegates
  delivery to a dCDN that the content provider has no relationship with, the
  app may have no ability to switch authentication methods.  Would the uCDN be
  responsible for generating of the proper dCDN credentials for the user?
That is exactly my point.  I don't have an answer.

The CSP may accept the uCDN's approach to authentication; however, that method of authentication may not be supported on the dCDN which has the authority to choose its own method of authentication independent of the CSP.

1. Does the dCDN have to support multiple authentication methods - one for each uCDN it establishes a relationship?

2. Does the uCDN have to support (and get approval from the CSP) for multiple authentication methods - one for each dCDN for which it establishes a relationship?

3. Do we define a standard authentication method between the client and all CDN such that the CSP approves one method and all uCDN and dCDN support the standard method?

4. Do we define a proxy authentication method where the dCDN authenticates the client using their method of choice, the uCDN authenticates clients using their method of choice, AND CDNi defines a standard proxy method between the dCDN and uCDN?  In this case, the CSP must accept that the methods used by dCDN and uCDN are equivalent but not necessarily the same.

In what manner is the client informed of the appropriate method to authenticate their transaction with either the dCDN or uCDN?

Scott

thanx.

--  Kevin J. Ma

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of
> Scott Wainner
> To: [email-masked]<mailto:[email-masked]>
> encapsulations for a reference set of media (e.g. HLS, HSS, but not DASH)
> [email-masked]<mailto:[email-masked]>

---

From: Scott Wainner <[email-masked]>
Date: Mon, 03 Oct 2011 15:27:35 -0400

I think any of the uses presume that the security infrastructure 
facilitates interoperability as I previously described in options 1, 2, 
3, and 4.  In the absence of an interoperable security framework, you 
have no viable use case.

Perhaps the use case documents simply need to call out the per-requisite 
for negotiating a security method between the 4 parties or a method for 
confirming authorization along the chain of trust (CSP -> uCDN -> dCDN 
-> client).

A requirement for negotiating or confirming security of the download 
should be in the Requirements document.

Scott

On 10/3/11 2:27 PM, Kevin J Ma wrote:
> *From:*Scott Wainner [mailto:[email-masked]]
> *Sent:* Monday, October 03, 2011 9:37 AM
> *To:* Kevin J Ma
> *Cc:* [email-masked]
> *Subject:* Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
>
> Kevin,
>
>     My comments in-line ...
>
> The CSP may accept the uCDN's approach to authentication; however, 
> that method of authentication may not be supported on the dCDN which 
> has the authority to choose its own method of authentication 
> independent of the CSP.
>
> 3. Do we define a standard authentication method between the client 
> and all CDN such that the CSP approves one method and all uCDN and 
> dCDN support the standard method?
>
> standard proxy method between the dCDN and uCDN?  In this case, the 
> CSP must accept that the methods used by dCDN and uCDN are equivalent 
> but not necessarily the same.
>
> > From: [email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked]] On Behalf Of
> > Scott Wainner
> > To: [email-masked] <mailto:[email-masked]>
> > [email-masked] <mailto:[email-masked]>

---

From: <[email-masked]>
Date: Tue, 4 Oct 2011 11:47:39 +0200

Hi Scott,

Thanks for your review.

- "Section 2.3 Nomadic Users" => I fully agree, we will clarify this section. 

- "Section 5.1.3 Content Encoding Restrictions" => we will most probably remove this section, because it is not clear enough as you highlighted and as Kent and François previously noted in their review of draft-bertrand-cdni-use-cases-02.

- "Section 10 Security Considerations" => I agree with your proposal to express "the pre-requisite for negotiating a security method between the 4 parties or a method for confirming authorization along the chain of trust (CSP -> uCDN -> dCDN -> client).". I think it will clarify the issues. 

Cheers,

Gilles

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Scott Wainner
Envoyé : vendredi 30 septembre 2011 02:02
À : [email-masked]
Objet : Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Section 2.3 Nomadic Users
   This description falls under the category of Geographic Extension yet the third paragraph states the case where a different device is used in the same CDN coverage area.  The intent of this use case needs to be clarified.  Perhaps the use case is trying to address the scenario where a Nomadic User-A with an agreement allowing access to content from CSP-A via uCDN moves to a dCDN in a different region.  The dCDN is allowed to distribute the content of CSP-A to User-A; however, not other users in the region of the dCDN are allowed to retrieve the content unless they too have such an agreement.

Section 5.1.3 Content Encoding Restrictions
   Need to clarify if we're talking about the restrictions on the delivery of specific content or the restrictions on the ability of a CDN to deliver specific content.  I certainly understand the case where a CSP will restrict the distribution of content to a "managed path" if such content is HD while allowing the content distribution via an un-managed path if such content is SD (same could apply to encryption methods, delivery methods, etc.).  On the contrary, the dCDN may have its own restrictions of blocking the distribution of HD content while allowing the distribution of SD content.

   o first bullet makes sense if the dCDN can perform a subset of encapsulations for a reference set of media (e.g. HLS, HSS, but not DASH)
   o second bullet makes sense where the dCDN doesn't want to offer high bit-rate variants of the media
   o third bullet make sense if the policy addresses QoE but I don't think subscriber rights/authorizations apply.

Aside from the security considerations WITHIN the uCDN and dCDN, I think we can describe this in four contexts:

a. The relationship between the CSP and the uCDN (the principle contract arrangement for distribution) b. The relationship between the uCDN and dCDN (the transitive trust relationship that extends the contract defined in (a) above) c. The relationship between the User and dCDN (the recognition of right to download predicated on (b) above) d. The relationship between the User and CSP (the contract authorizing the user access to the content)

The user is not interested in the a-b nor the b-c relationship. The user is only interested in the transparency and interoperability of the security relationship between d-b or d-c to the point that the authorization granted in d-a is viable when the delivery is initiated via either d-b or d-c.  As an example, the uCDN might use URL appended tokens for authentication while dCDN might use URL appended hashes.  The user doesn't want to know about the distinct methods, but transparency is only afforded if the methods are interoperable clearly defined when the delegation for content delivery is executed.  Clearly, the choice of authentication method is determined by the respective CDN's.

Scott

---

From: ZhouZhipeng <[email-masked]>
Date: Sat, 08 Oct 2011 07:20:39 +0000

Following Scott's comments on section 5.1.3, I feel Scott's description on the use case of HD and SD is not exactly correct.
If one movie has two formats of HD and SD, then we have two content with different identifier. In DRM scope, the basic unit is a content copy.

Here the first bullet "a subset of encodings deliverable to specific devices," has listed the case of content adaptation.
In last month, I have contacted the Authors of this document and taken some email exchanges with Grant and Philip (BT).
I have shown BT with some information that I know in this case and area to explain the content flexibility is currently a basic requirement for CDN service and related negotiation is needed in the CDN interconnection.
Meanwhile, I should also invite you in this group raising your comments or questions on this case since I hope my use case may be incorporated in the use case draft.

If you have any more question or comments, pls share in this thread.
Thanks.
Zhipeng

-----Original Message-----
From: Scott Wainner [mailto:[email-masked]] 
Sent: Friday, September 30, 2011 8:02 AM
To: [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Scott

---

From: Vishwas Manral <[email-masked]>
Date: Sat, 8 Oct 2011 14:01:36 -0700

Hi Kevin,

I think Scott has a point when he says that we need to define some base
authentication method to be supported between the CDN's.

Ofcourse in particular cases if a particular authentication method is
required it could mean to disallow delegation to a dCDN.

Thanks,
Vishwas
On Mon, Oct 3, 2011 at 11:27 AM, Kevin J Ma <[email-masked]>wrote:

>  Hi Scott,****
>
> ** **
>
>   One option is that CPs that want strict authentication do not allow
> delegation.****
>
>   In a non-interconnected environment, the CP has to configure the
> authentication****
>
>   method on each CDN?  If the uCDN is going to delegate to a dCDN, the uCDN
> would****
>
>  have to configure the dCDN on behalf of the CP (passwords, certs, etc.)?
> That****
>
>  brings up other transative trust issues that this CP probably does not
> want to****
>
>  deal with?  For other CPs, imo, end user transparency is the most
> important.****
>
>   That could mean options 1 or 3 as you describe them below, or possibly a
> proxy****
>
>  where the dCDN sends the credentials to the uCDN for verification, so that
> the****
>
>  client does not need to know anything about the dCDN?****
>
> ** **
>
>   wrt the use case draft, do you feel that the security section needs
> expanded, or****
>
>   that additional use cases are required?****
>
> ** **
>
> thanx.****
>
> ** **
>
> --  Kevin J. Ma****
>
> ** **
>
> *From:* Scott Wainner [mailto:[email-masked]]
> *Subject:* Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt****
>
>   ** **
>
> Kevin,
>
>     My comments in-line ...
>
> On 9/30/11 10:45 AM, Kevin J Ma wrote: ****
>
> Hi Scott,
>
>   devices or subscribers.  We are also looking at removing section 5.1.3.*
> ***
>
> Understood.
>
> ****
>
>
>   responsible for generating of the proper dCDN credentials for the user?*
> ***
>
> multiple authentication methods - one for each dCDN for which it establishes
> a relationship?
>
> 3. Do we define a standard authentication method between the client and all
> CDN such that the CSP approves one method and all uCDN and dCDN support the
> standard method?
>
> 4. Do we define a proxy authentication method where the dCDN authenticates
> the client using their method of choice, the uCDN authenticates clients
> using their method of choice, AND CDNi defines a standard proxy method
> between the dCDN and uCDN?  In this case, the CSP must accept that the
> methods used by dCDN and uCDN are equivalent but not necessarily the same.
>
> ****
> > From: [email-masked] [mailto:[email-masked]<[email-masked]>]
> On Behalf Of
> > Scott Wainner
> > https://www.ietf.org/mailman/listinfo/cdni****
>
> ** **
>

---

From: Kevin J Ma <[email-masked]>
Date: Sat, 8 Oct 2011 18:45:49 -0400

Hi Vishwas,

  Just to clarify, when you say "between the CDNs", we are still
  taking about CDNs authenticating end users, as opposed to CDNs
  authenticating each other, correct?

  I do think that CDNs will need to be able to authenticate with
  each other, but with respect to CDNs authenticating end users,
  I agree that it would be best if the CDNs agreed upon a single
  authentication method, and that delegation be denied if a dCDN
  cannot support the method specified by the uCDN.  IMO, the way
  to do that is through opaque metadata.

  I do not think I was disagreeing with Scott, I just raised two
  issues to consider:
  1) If the CP configures the uCDN with an authentication method
     and credentials, the CP does not necessarily give that uCDN 
     permission to pass those credentials along to a dCDN.
  2) The client app cannot be expected to support authentication
     methods that are not known to the CP; the dCDNs cannot just
     select a method that the CP is unaware of.

  Going with an opaque metadata approach we can certainly define
  metadata for advertising authentication, beyond that, however,
  the CDN to client interface seems to be out of scope of CDNI?

thanx.

--  Kevin J. Ma

From: Vishwas Manral [mailto:[email-masked]] 
Sent: Saturday, October 08, 2011 5:02 PM
To: Kevin J Ma
Cc: Scott Wainner; [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Hi Kevin,
 
I think Scott has a point when he says that we need to define some base authentication method to be supported between the CDN's. 
 
Ofcourse in particular cases if a particular authentication method is required it could mean to disallow delegation to a dCDN.
 
Thanks,
Vishwas
On Mon, Oct 3, 2011 at 11:27 AM, Kevin J Ma <[email-masked]> wrote:
Hi Scott,

 
thanx.
 
--  Kevin J. Ma

 
Kevin,

    My comments in-line ...

  > As an example, the uCDN might use URL appended
  > tokens for authentication while dCDN might use URL appended hashes.
  ...
  > Clearly, the choice of
  > authentication method is determined by the respective CDN's.

Scott

thanx.

--  Kevin J. Ma

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 10 Oct 2011 12:04:28 +0100

Colleagues,

IMO Section 5.1.3 should be removed from the Use Cases draft. Content Adaptation (i.e. taking in a content item in one format and transforming it to another format or representation) is not a "core" function of a CDN which typically delivers the content that is requested without explicit knowledge of what that content actually is.

Let's not forget that in building an end to end content service the CDN is only one component and is the component tasked with executing the delivery of a specific representation (version/copy/format etc.) of the selected content not the component tasked with deciding (or applying policy) on which version/copy/representation of content should be delivered.

The decision as to which version/copy/representation to offer and allow to be delivered to a given device/user is implemented outside of the CDN (e.g. by the "portal" where the user first makes their content selection prior to the CDN becoming involved in the delivery of the selected content).

Ben

---

From: <[email-masked]>
Date: Mon, 10 Oct 2011 16:21:59 +0100

Ben, Zhipeng, all, 

I think that Content Adaptation is more an issue for the Requirements doc than for the Use cases draft. 

The key question is whether we want the CDNI interfaces to be able to cope with a scenario where (say) HD/SD conversion is done in the dCDN & to signal about this.

I think that coping with this scenario is a second order requirement, ie we should not worry about it in the initial standards-track work. I don't know, did we ever decide whether the Use cases doc is restricted to "initial" scenarios, or whether it's all-encompassing, ie covering "future" scenarios as well? 

Scott,
Reading some of your examples, they seem to be valid even if content adaptation (HD/SD) is out of scope. 
- a dCDN might for some reason be unwilling to distribute HD?
- a CSP might want to make sure the dCDN can use HLS encapsulation?
But these sorts of examples seem to be static policy things (to do with the capabilities & preferences of the CDNs & CSP), rather than metadata associated with a particular piece of content. In the discussion so far, I think negotiation about static policy stuff is rather out of scope(?)

On security considerations, an interesting question is whether trust is transitive. Don't think it need be - just because CSP trusts uCDN, and uCDN trusts dCDN doesn't mean that the CSP automatically trusts the dCDN. However, i suspect this can get arbitrarily complex - so one possibility is to say that we will only handle cases where the trust is transitive.

Best wishes
phil

Philip Eardley   
Research and Technology Strategy

This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails.
British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
Sent: 10 October 2011 12:04
To: ZhouZhipeng
Cc: [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Colleagues,

Ben

---

From: ZhouZhipeng <[email-masked]>
Date: Tue, 11 Oct 2011 04:16:40 +0000

Ben and Philip,
I like to respond your concern in this one email:

Ben,
I feel what we are now discussing is what is the "core" function of CDN.
As you say, CDN is used to deliver content. That is absolutely correct that the delivery capability is the core requirement for CDN system.
While CDN is used to provide the content delivery service.
What means service. It should include "time" "location" and "media type", etc. These features are all the core feature for a service.
If we only concern "delivering one data block", I am not sure whether the issues such as "logging" "geographic constraint" are the core of CDN.

For "without explicit knowledge of what that content actually is ", I am not sure whether the wording is accurate since generally a CDN may claim it support different medias.
By this opportunity, I like to share a use case: a call from a GSM phone to a PSTN telephone, the voice stream should be transformed from GSM voice to G.711.
For the user, he does not need to know what type of data has been transferred, but the operator has done some work to interconnect two systems, right.
I like to know whether you may accept that my use case is similar to this case above.

As for you said selecting media by the "portal", you may see the way " uCDN delivers multiple media streams to dCDN" is not good than "uCDN delivers one media stream to dCDN and dCDN takes some adaptation to support multiple media types". 

A good question is "security" since I have done six years on the DRM and like to promote the DRM all around the world:)
If the content is needed to be protected, generally you may know all the systems should be granted by the content owner.
Here I also like to clarify that not only the media itself but the information related to service itself (such as the geographic constraint) should be protected also.
So, trust is not a problem for the media.

Philip,
Thank you that you feel Content Adaption is an issue for "Requirements" but I do not know why it is not for Use case.
I like to clarify to U that it is important for you operator since it may save investment if the system may support different services.
For us vendor, we are happy operator may install a system for the mobile service and another system for the FBB service.
But the reality is all operators ask us to provide a system that may support different service systems.

Frankly, Ben and Philip, I remember I have explained somewhere that to implement this is rather simple .
At least the Use case and Requirement are informational to be referred in future work. So I do really feel you may accept it.
Of course I like to respond your more concern and comments.
Thanks.
Zhipeng

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, October 10, 2011 11:22 PM
To: [email-masked]; ZhouZhipeng
Cc: [email-masked]
Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Ben, Zhipeng, all, 

Scott,

Best wishes
phil

Philip Eardley   

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
Sent: 10 October 2011 12:04
To: ZhouZhipeng
Cc: [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Colleagues,

Ben

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Tue, 11 Oct 2011 12:12:28 +0000

Hi all,

While I am neutral to the Content Adaptation discussion, I would like to make sure that we do not throw out all features related to multiple representations, which would happen if we would just remove section 5.1.3 completely as suggested by Ben. 

The previous version of the use case document (betrand-02) had a slightly different wording in section 2.4 than is now being used in section 5.1  of the new WG-version. I think the concept of resolution-based constraints, that was included in betrand-02, should remain in some form. While it is not the CDNs responsibility/decision whether to allow a specific representation to be delivered, I think a use case in which some dCDN only offers a subset of the representations available on the uCDN is quite valid (such as in a dedicated mobile CDN). 

Ray

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
Sent: maandag 10 oktober 2011 13:04
To: ZhouZhipeng
Cc: [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Colleagues,

Ben

On 8 Oct 2011, at 08:20, ZhouZhipeng wrote:

>   This description falls under the category of Geographic Extension 
> yet the third paragraph states the case where a different device is 
> used in the same CDN coverage area.  The intent of this use case needs 
> to be clarified.  Perhaps the use case is trying to address the 
> scenario where a Nomadic User-A with an agreement allowing access to 
> content from CSP-A via uCDN moves to a dCDN in a different region.  
> The dCDN is allowed to distribute the content of CSP-A to User-A; 
> however, not other users in the region of the dCDN are allowed to 
> retrieve the content unless they too have such an agreement.
> 
> delivery of specific content or the restrictions on the ability of a 
> CDN to deliver specific content.  I certainly understand the case 
> where a CSP will restrict the distribution of content to a "managed 
> path" if such content is HD while allowing the content distribution 
> via an un-managed path if such content is SD (same could apply to 
> encryption methods, delivery methods, etc.).  On the contrary, the 
> dCDN may have its own restrictions of blocking the distribution of HD 
> content while allowing the distribution of SD content.
> 
> Aside from the security considerations WITHIN the uCDN and dCDN, I 
> think we can describe this in four contexts:
> 
> a. The relationship between the CSP and the uCDN (the principle 
> contract arrangement for distribution) b. The relationship between the 
> uCDN and dCDN (the transitive trust relationship that extends the 
> contract defined in (a) above) c. The relationship between the User 
> and dCDN (the recognition of right to download predicated on (b) 
> above) d. The relationship between the User and CSP (the contract 
> authorizing the user access to the content)
> 
> The user is not interested in the a-b nor the b-c relationship. The 
> user is only interested in the transparency and interoperability of 
> the security relationship between d-b or d-c to the point that the 
> The user doesn't want to know about the distinct methods, but 
> transparency is only afforded if the methods are interoperable clearly 
> defined when the delegation for content delivery is executed.  
> Clearly, the choice of authentication method is determined by the respective CDN's.
> 
> Scott
> 

_______________________________________________
CDNi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cdni
This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 11 Oct 2011 14:26:07 +0100

> While I am neutral to the Content Adaptation discussion, I would like to make sure that we do not throw out all features related to multiple representations, which would happen if we would just rem…

I'm not sure how you draw that conclusion as removing section 5.1.3 does not throw out the ability to support multiple representations IMO.

> The previous version of the use case document (betrand-02) had a slightly different wording in section 2.4 than is now being used in section 5.1  of the new WG-version. I think the concept of resol…

I don't believe that dCDNs will only offer a subset of representations in the way you describe. They may only deliver to a subset of users (and maybe by implication a subset of possible devices) for example as a consequence of  them being a dedicated mobile CDN (as opposed to an active decision they make).

Let's look at how a content service is deployed. A Content Provider has some content (let's say a video) that the Content Provider may produce in a variety of representations (codecs, bit rates, resolutions, etc.). They may do that encoding themselves or outsource it (although that's not relevant to the point I'm making).

A User will connect to the Content Provider's "portal" (which may be a web portal, an application, an EPG etc.). The Content Provider (through their portal) will offer the User the content in one or more of the available representations (e.g. by device type but how that decision is made is purely up to the Content Provider). The User selects a representation and the Content Provider offloads the delivery of that representation to the CDN (e.g. by returning the appropriate URI for that representation within the CDN to the User's client). The User then connects to the CDN and requests the representation they have selected (from the choice of representations offered to them by the Content Provider).

At its essence a CDN maps incoming URIs (from User's clients) to specific content files on an upstream source (e.g. on-net storage or a Content Provider's Origin server) it has no explicit knowledge of what actual content that specific URI maps to or that it is one of X possible representations of the same content.

At no point has the CDN been involved in the selection or restriction of the representations offered to or delivered to the User. In a CDNI scenario things are no different. A uCDN may select a dCDN based on some capability (e.g. what Users it can deliver to, what delivery protocols it can support) but I do not think that the specific representation of the content will enter into the equation beyond those constraints.

For example, the dCDN is not going to say "I can only deliver representations with resolutions below AxB" and the uCDN often will not even know what the resolution or a particular representation is. 

What might happen is that a User on a particular network (or using a particular client/device) connects to the Content Provider's portal and is only offered a subset of the possible representations tailored (by the Content Provider's policy implemented in the Content Provider's portal) based on that User's Network/Client/Device. A dCDN may subsequently be selected that can serve that Network/Client/Service and that dCDN may only end up delivering to its Users a subset of all the possible representations the Content Provider has produced. But that is a consequence of the Network/Clients/Devices the dCDN is capable of serving, not an explicit decision made by the dCDN and communicated to the uCDN for that specific Content Provider's service.

Ben

---

From: Scott Wainner <[email-masked]>
Date: Tue, 11 Oct 2011 10:28:17 -0400

>    authenticating each other, correct?
That was my intent.

Each CDN will (most likely) want to use some means of authenticating the 
user for permission to download content.  Since the CDN's are operated 
independently, they will likely independently choose their method of 
authentication and authorization.  The point being the use case could 
describe a scenario where there is no authentication and authorization 
(we're just trying to find a way to deliver content efficiently) AND a 
use case can be described where there is authentication and 
authorization (between the client and the CDN).  In the later case, we 
need to coordinate the method of authentication and authorization.

1. Default / Standard method for all CDN's?
2. Set of methods with order preference?

Does the CP dictate the minimum level of authentication / authorization 
acceptable by ANY CDN used for deliver?  In that case, the uCDN may 
support a method and the dCDN may or may not.  A decision has to be made 
prior to delegating the content request to the dCDN.
>    the CDN to client interface seems to be out of scope of CDNI?
If the authentication / authorization between the client and the dCDN is 
a viable use case in CDNi, then I don't see how you can avoid at least 
defining a requirement for specifying a compatible means of 
authentication/authorization in order for CDNi to work.
> On Mon, Oct 3, 2011 at 11:27 AM, Kevin J Ma<[email-masked]>  wrote:
> Hi Scott,
>

---

From: Scott Wainner <[email-masked]>
Date: Tue, 11 Oct 2011 10:42:29 -0400

On 10/10/11 7:04 AM, Ben Niven-Jenkins wrote:
>
> Colleagues,
>
> IMO Section 5.1.3 should be removed from the Use Cases draft. Content 
> Adaptation (i.e. taking in a content item in one format and 
> transforming it to another format or representation) is not a "core" 
> function of a CDN which typically delivers the content that is 
> requested without explicit knowledge of what that content actually is.
>
I tend to agree.  Although content adaptation may be desirable, it's not 
clear that we could effectively bound the number permutations of content 
adaptation that may be possible (encryption, watermark, transrate, 
transcode, etc.)
>
>
> Let's not forget that in building an end to end content service the 
> CDN is only one component and is the component tasked with executing 
> the delivery of a specific representation (version/copy/format etc.) 
> of the selected content not the component tasked with deciding (or 
> applying policy) on which version/copy/representation of content 
> should be delivered.
>
> The decision as to which version/copy/representation to offer and 
> allow to be delivered to a given device/user is implemented outside of 
> the CDN (e.g. by the "portal" where the user first makes their content 
> selection prior to the CDN becoming involved in the delivery of the 
> selected content).
>
Agreed.  This means the portal makes a decision about the specific 
content object without regard to the capabilities of the CDN(s).  There 
is a presumption that the set of CDN's can deliver the content.  That 
assumption has a high probability of success with regards to the 
relationship between the uCDN and CP because there is an explicit 
business relationship.  That assumption may not be valid when dealing 
with a dCDN that has a business relationship with the uCDN.

So let's assume there is ONE URL that is provided by the CP (portal) for 
the asset.  If that URL makes sense ONLY on the uCDN, then somewhere 
outside of the CP (portal) a decision must be made to re-write the URL 
such that it is appropriate for the dCDN.  That can be a simple re-write 
(modified FQDN with same PATH) or a more complex re-write (modified FQDN 
and PATH).

Are we bounding the use case ONLY those scenarios where the PATH 
structure remains unmodified and we're only changing the delivery 
point?  In this case, the uCDN and every dCDN would understand how to 
handle the exact same PATH structure.

If the use case is expanded to include the URL PATH re-write, where 
would this be done?  If the CP (portal) does it, it needs to know 
information about which CDN will be used in order to pick the correct 
URL structure.  Otherwise, the uCDN must do the re-write into the 
appropriate PATH structure for the dCDN.  Is this in scope or not?

Scott
> > Following Scott's comments on section 5.1.3, I feel Scott's 
> description on the use case of HD and SD is not exactly correct.
> > If one movie has two formats of HD and SD, then we have two content 
> with different identifier. In DRM scope, the basic unit is a content copy.
> >
> > Here the first bullet "a subset of encodings deliverable to specific 
> devices," has listed the case of content adaptation.
> > In last month, I have contacted the Authors of this document and 
> taken some email exchanges with Grant and Philip (BT).
> > I have shown BT with some information that I know in this case and 
> area to explain the content flexibility is currently a basic 
> requirement for CDN service and related negotiation is needed in the 
> CDN interconnection.
> > Meanwhile, I should also invite you in this group raising your 
> comments or questions on this case since I hope my use case may be 
> incorporated in the use case draft.
> >

---

From: Scott Wainner <[email-masked]>
Date: Tue, 11 Oct 2011 10:50:48 -0400

On 10/10/11 11:21 AM, [email-masked] wrote:
> The key question is whether we want the CDNI interfaces to be able to 
> cope with a scenario where (say) HD/SD conversion is done in the dCDN 
> & to signal about this.
>
> I think that coping with this scenario is a second order requirement, 
> ie we should not worry about it in the initial standards-track work. I 
> don't know, did we ever decide whether the Use cases doc is restricted 
> to "initial" scenarios, or whether it's all-encompassing, ie covering 
> "future" scenarios as well?
>
> Scott,
Exactly my point.  Lot's of policy constraints here some of which are 
defined by the CP and some of which are defined by the dCDN.
Example: CP only allows content to be delivered over network 
infrastructure that uCDN owns (no delegation allowed)
Example: dCDN doesn't want to allow HD streams over their low-bandwidth 
network infrastructure.
Example: uCDN decides its more economical to deliver from their own 
network as opposed to a dCDN
> But these sorts of examples seem to be static policy things (to do 
> with the capabilities & preferences of the CDNs & CSP), rather than 
> metadata associated with a particular piece of content. In the 
> discussion so far, I think negotiation about static policy stuff is 
> rather out of scope(?)
>
Policy - communicated by people or by protocol.  Certainly, the simple 
case is the communication by people with static configuration in which 
case we need no protocol.  The question is what policy attributes are in 
scope and which ones are out of scope.
>
>
> On security considerations, an interesting question is whether trust 
> is transitive. Don't think it need be - just because CSP trusts uCDN, 
> and uCDN trusts dCDN doesn't mean that the CSP automatically trusts 
> the dCDN.
>
I would think that this is the norm (the CSP does NOT implicitly trust a 
dCDN).  With a well defined framework, the CSP may be persuaded to trust 
a dCDN under certain conditions.
>
> However, i suspect this can get arbitrarily complex - so one 
> possibility is to say that we will only handle cases where the trust 
> is transitive.
>
That is the fundamental question ... are we only dealing with cases 
where trust is transitive and there is presumably a common method of 
enforcing that transitive trust.

Scott
> This email contains BT information, which may be privileged or 
> confidential. It's meant only for the individual(s) or entity named 
> above. If you're not the intended recipient, note that disclosing, 
> copying, distributing or using this information is prohibited. If 
> you've received this email in error, please let me know immediately on 
> the email address above. Thank you. We monitor our email system, and 
> may record your emails.

---

From: Kevin J Ma <[email-masked]>
Date: Tue, 11 Oct 2011 10:48:56 -0400

Hi Ben,

  I do not disagree with the statements made below, however, I think
  that there is one point that is missing: in a non-interconnected
  world, CPs can (and do) put different representations into different
  CDNs, knowing that representation-A will not be accessible via CDN-B.
  It is true that the CDN did not make any decision, the CP did, however,
  the enforcement is based on the fact that those CDNs will not share
  with each other and are physically separated.  With CDNI, if the uCDN
  has access to all representations but the CP needs to enforce that
  specific dCDNs only have access to subsets of representations (due to
  content licensing restrictions), enforcing that probably requires
  metadata to describe those delivery restrictions?

thanx.

--  Kevin J. Ma

> Ben Niven-Jenkins
> Sent: Tuesday, October 11, 2011 9:26 AM
> To: Brandenburg, R. (Ray) van
> Cc: [email-masked]; ZhouZhipeng
> > While I am neutral to the Content Adaptation discussion, I would like to
> make sure that we do not throw out all features related to multiple
> representations, which would happen if we would just remove section 5.1.3
> completely as suggested by Ben.
> 
> I'm not sure how you draw that conclusion as removing section 5.1.3 does
> not throw out the ability to support multiple representations IMO.
> 
> > The previous version of the use case document (betrand-02) had a
> slightly different wording in section 2.4 than is now being used in
> section 5.1  of the new WG-version. I think the concept of resolution-
> based constraints, that was included in betrand-02, should remain in some
> form. While it is not the CDNs responsibility/decision whether to allow a
> specific representation to be delivered, I think a use case in which some
> dCDN only offers a subset of the representations available on the uCDN is
> quite valid (such as in a dedicated mobile CDN).
> 
> I don't believe that dCDNs will only offer a subset of representations in
> the way you describe. They may only deliver to a subset of users (and
> maybe by implication a subset of possible devices) for example as a
> consequence of  them being a dedicated mobile CDN (as opposed to an active
> decision they make).
> 
> Let's look at how a content service is deployed. A Content Provider has
> some content (let's say a video) that the Content Provider may produce in
> a variety of representations (codecs, bit rates, resolutions, etc.). They
> may do that encoding themselves or outsource it (although that's not
> relevant to the point I'm making).
> 
> A User will connect to the Content Provider's "portal" (which may be a web
> portal, an application, an EPG etc.). The Content Provider (through their
> portal) will offer the User the content in one or more of the available
> representations (e.g. by device type but how that decision is made is
> purely up to the Content Provider). The User selects a representation and
> the Content Provider offloads the delivery of that representation to the
> CDN (e.g. by returning the appropriate URI for that representation within
> the CDN to the User's client). The User then connects to the CDN and
> requests the representation they have selected (from the choice of
> representations offered to them by the Content Provider).
> 
> At its essence a CDN maps incoming URIs (from User's clients) to specific
> content files on an upstream source (e.g. on-net storage or a Content
> Provider's Origin server) it has no explicit knowledge of what actual
> content that specific URI maps to or that it is one of X possible
> representations of the same content.
> 
> At no point has the CDN been involved in the selection or restriction of
> the representations offered to or delivered to the User. In a CDNI
> scenario things are no different. A uCDN may select a dCDN based on some
> capability (e.g. what Users it can deliver to, what delivery protocols it
> can support) but I do not think that the specific representation of the
> content will enter into the equation beyond those constraints.
> 
> For example, the dCDN is not going to say "I can only deliver
> representations with resolutions below AxB" and the uCDN often will not
> even know what the resolution or a particular representation is.
> 
> What might happen is that a User on a particular network (or using a
> particular client/device) connects to the Content Provider's portal and is
> only offered a subset of the possible representations tailored (by the
> Content Provider's policy implemented in the Content Provider's portal)
> based on that User's Network/Client/Device. A dCDN may subsequently be
> selected that can serve that Network/Client/Service and that dCDN may only
> end up delivering to its Users a subset of all the possible
> representations the Content Provider has produced. But that is a
> consequence of the Network/Clients/Devices the dCDN is capable of serving,
> not an explicit decision made by the dCDN and communicated to the uCDN for
> that specific Content Provider's service.
> 
> Ben
> 
> 
>

---

From: Kevin J Ma <[email-masked]>
Date: Tue, 11 Oct 2011 10:49:44 -0400

Hi Scott,

  > 2. Set of methods with order preference?

  I think either is fine.  I would just be concerned if we had requirements
  in CDNI that CDNs support specific protocols.  Doing it through metadata
  does not require the CDNI interfaces to change every time a new protocol
  comes along, and does not dictate what protocols CDNs must support if they
  want to engage in just basic interconnection?

  > prior to delegating the content request to the dCDN.

  I would think yes, the CP dictates, and delegation should be restricted.

thanx.

--  Kevin J. Ma

> Sent: Tuesday, October 11, 2011 10:28 AM
> To: Kevin J Ma
> Cc: Vishwas Manral; [email-masked]
> delegation.
> authentication
> want to
> important.
> expanded, or
> must accept that the methods used by dCDN and uCDN are equivalent but not
> necessarily the same.
> >
> yet
> CDN
> contract
> user
> The

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Tue, 11 Oct 2011 15:09:32 +0000

Hi Ben,

You make the assumption that selecting a specific representation is a conscious decision, made either by a user or the CP, before the actual content delivery commences. In this case, I agree with you completely. 

However, there are situations imaginable in which there is a switch between representations during content delivery. Let's take the HTTP Adaptive Streaming situation for example. A given video might be encoded in 10 different qualities (representations), ranging from a 1080p stream all the way to 128kbps stream meant for small-screen mobile devices. Depending on network conditions or user preferences, a device might switch between these representation multiple times during video delivery. In your case it will only be possible for a dCDN to host/deliver either all 10 of the representations, or none at all. What I meant was that in some situations, a dedicated mobile dCDN might want to host/deliver the content, but  not in all 10 representations since the highest quality representations (e.g. 1080p) are of no use to mobile clients. 

I understand that this would mean that a CDN is no longer agnostic to the content it delivers, but this is true for a lot of use cases that are included in the current draft. 

Ray

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: dinsdag 11 oktober 2011 15:26
To: Brandenburg, R. (Ray) van
Cc: ZhouZhipeng; [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 11 Oct 2011 16:26:09 +0100

Scott,

On 11 Oct 2011, at 15:42, Scott Wainner wrote:

> Agreed.  This means the portal makes a decision about the specific content object without regard to the capabilities of the CDN(s).  There is a presumption that the set of CDN's can deliver the content.  That assumption has a high probability of success with regards to the relationship between the uCDN and CP because there is an explicit business relationship.  That assumption may not be valid when dealing with a dCDN that has a business relationship with the uCDN.

The CP will enter a business agreement with a uCDN for the delivery of its content and will ensure that the uCDN is able to deliver both the types of content the CP requires delivery of and to the geographic regions that the CP requires delivery to. That is typically known in advance as part of the RFP/contract negotiation between the CP & the uCDN.

The uCDN may decide to make use of dCDNs to assist in the delivery of some or all of that content. The technical interconnect of the uCDN and dCDN is not occurring in a vacuum. The uCDN better make sure that it can cover its obligations to the CP either by itself or by ensuring that it has one or more dCDNs that can meet those obligations for it.

If the uCDN overcommits itself compared to its (or its dCDN's) capabilities bad things will happen (from the point of view of the CSP and the CSP's Users). The solution to that problem is not a technical solution IMO.

At the end of the day CPs will talk to their CPs about what they require and configure policies in their platform appropriately. Likewise uCDNs will talk with their dCDNs about what they require and configure policies in their platform appropriately. There isn't any magical protocol dust that means those conversations do not need to happen and IMO if those conversations are happening there's no need for protocol semantics to duplicate what is happening outside of the CDNI protocols themselves as part of those conversations and the per-CP/per-CDN configuration happening as a result.
 
> So let's assume there is ONE URL that is provided by the CP (portal) for the asset.  If that URL makes sense ONLY on the uCDN, then somewhere outside of the CP (portal) a decision must be made to re-write the URL such that it is appropriate for the dCDN.  That can be a simple re-write (modified FQDN with same PATH) or a more complex re-write (modified FQDN and PATH).

I don't see how URI rewriting applies to content adaptation. The URI a client uses to access the same content representation may differ by CDN and the URI may be transformed as part of CDNI request routing for example but the content itself is not transformed - the different URIs in each CDN still refer to the same specific content file.

Ben

> 
> Are we bounding the use case ONLY those scenarios where the PATH structure remains unmodified and we're only changing the delivery point?  In this case, the uCDN and every dCDN would understand how to handle the exact same PATH structure.
> 
> If the use case is expanded to include the URL PATH re-write, where would this be done?  If the CP (portal) does it, it needs to know information about which CDN will be used in order to pick the correct URL structure.  Otherwise, the uCDN must do the re-write into the appropriate PATH structure for the dCDN.  Is this in scope or not?
> 
> Scott
>> 
>> Ben
>>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 11 Oct 2011 16:41:39 +0100

Ray,

> However, there are situations imaginable in which there is a switch between representations during content delivery. Let's take the HTTP Adaptive Streaming situation for example. A given video migh…

Ultimately, even with adaptive streaming, the Content Provider chooses what representations they make available. HTTP Adaptive streaming is no different to my original example except instead of providing a URI for a specific representation the Content Provider provides a "manifest" containing URIs for one or more representations. At no point does the CDN get to decide which representations the Content Provider includes in their manifest.

Typically, the CDN only caches those representations that are actually requested from it. Therefore it is not a black & white "all 10" or "none" as you suggest.

The Content Provider has ownership of what service they offer and the experience they want the User to experience, not the CDN. It is not acceptable for a CDN to decide (outside of a business agreement) that it doesn't want to support some subset of the representations the Content Provider is offering and use "content adaptation" to modify the content to what the CDN would prefer to deliver.

Ben

---

From: Scott Wainner <[email-masked]>
Date: Tue, 11 Oct 2011 11:52:58 -0400

Ben,

     I agree.  Multiple client representations (i.e. unique URI) for the 
same content representation.  I'm not suggesting content adaptation as a 
use case.  My only point (which was made by others) is that a given 
representation MAY or MAY NOT be viable or advisable on a dCDN.  That 
decision is presumably not made by the CSP.  That decision is made by 
the uCDN.  The input for that decision can be made statically 
(configured policy) or learned dynamically (conveyed via CDNi).

     I agree that we can use statically configured policy to make that 
decision.

Scott

On 10/11/11 11:26 AM, Ben Niven-Jenkins wrote:
> content object without regard to the capabilities of the CDN(s).  
> There is a presumption that the set of CDN's can deliver the content.  
> That assumption has a high probability of success with regards to the 
> The CP will enter a business agreement with a uCDN for the delivery of 
> its content and will ensure that the uCDN is able to deliver both the 
> types of content the CP requires delivery of and to the geographic 
> regions that the CP requires delivery to. That is typically known in 
> advance as part of the RFP/contract negotiation between the CP & the uCDN.
>
> The uCDN may decide to make use of dCDNs to assist in the delivery of 
> some or all of that content. The technical interconnect of the uCDN 
> and dCDN is not occurring in a vacuum. The uCDN better make sure that 
> it can cover its obligations to the CP either by itself or by ensuring 
> that it has one or more dCDNs that can meet those obligations for it.
>
> If the uCDN overcommits itself compared to its (or its dCDN's) 
> capabilities bad things will happen (from the point of view of the CSP 
> and the CSP's Users). The solution to that problem is not a technical 
> solution IMO.
>
> At the end of the day CPs will talk to their CPs about what they 
> require and configure policies in their platform appropriately. 
> Likewise uCDNs will talk with their dCDNs about what they require and 
> configure policies in their platform appropriately. There isn't any 
> magical protocol dust that means those conversations do not need to 
> happen and IMO if those conversations are happening there's no need 
> for protocol semantics to duplicate what is happening outside of the 
> CDNI protocols themselves as part of those conversations and the 
> per-CP/per-CDN configuration happening as a result.
>
> > So let's assume there is ONE URL that is provided by the CP (portal) 
> for the asset.  If that URL makes sense ONLY on the uCDN, then 
> somewhere outside of the CP (portal) a decision must be made to 
> re-write the URL such that it is appropriate for the dCDN.  That can 
> be a simple re-write (modified FQDN with same PATH) or a more complex 
> re-write (modified FQDN and PATH).
>
> I don't see how URI rewriting applies to content adaptation. The URI a 
> client uses to access the same content representation may differ by 
> CDN and the URI may be transformed as part of CDNI request routing for 
> example but the content itself is not transformed - the different URIs 
> in each CDN still refer to the same specific content file.
>
> Ben
>
> >
> >> > If one movie has two formats of HD and SD, then we have two 
> content with different identifier. In DRM scope, the basic unit is a 
> content copy.
> >> >
> >> > Here the first bullet "a subset of encodings deliverable to 
> specific devices," has listed the case of content adaptation.
> >> > I have shown BT with some information that I know in this case 
> and area to explain the content flexibility is currently a basic

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 11 Oct 2011 16:50:56 +0100

Kevin,

>  metadata to describe those delivery restrictions?

I'd like to understand these requirements better as I am aware of Content Providers that choose to use different CDNs for different representations based on business policy and I think that can be solved at the business agreement level in the same way as dealing with what delivery protocols or delivery footprint the Content Provider requires.

I am aware of licensing agreements that restrict what geographies content can be delivered from and what geographies content can be delivered to. Such requirements are already handled by the metadata proposal I co-authored through the use of SelectionACL & DeliveryACLs. 

However, I've not heard of a licensing agreement that mandated that some representations of a piece of content absolutely must be delivered by a different CDN to other representations of the same content.

Can you expand on the motivation and drivers behind that requirement?

Thanks
Ben

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Tue, 11 Oct 2011 15:51:15 +0000

Ben,

> Ultimately, even with adaptive streaming, the Content Provider chooses what representations they make available. HTTP Adaptive streaming is no different to my original example except instead of pro…

The CDN does not get to decide which representations the Content Provider should include, but maybe the uCDN may get to decide which representations it wants to 'outsource' to the dCDN and which to deliver himself. And yes, this may require changes to the manifest. However I would not want to call changing the URLs embedded in the manifest file content adaptation. As long as the client still has access to all content put in the manifest by the CP, I don't see a problem. 

Ray

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: dinsdag 11 oktober 2011 17:42
To: Brandenburg, R. (Ray) van
Cc: ZhouZhipeng; [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Ray,

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 11 Oct 2011 16:56:11 +0100

Ray,

> The CDN does not get to decide which representations the Content Provider should include, but maybe the uCDN may get to decide which representations it wants to 'outsource' to the dCDN and which to…

Personally I believe uCDNs are unlikely to make choices of whether to use a dCDN or not based on a subset of representations in a manifest. I think the overriding factors will be things like which network the User is on and what the delivery protocol is.

In any case, even if a uCDN did want to split like that then there are methods to achieve that without requiring rewriting the manifest.

Ben

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Tue, 11 Oct 2011 16:01:37 +0000

Ben,

> Personally I believe uCDNs are unlikely to make choices of whether to use a dCDN or not based on a subset of representations in a manifest. I think the overriding factors will be things like which…

I think there might be some situations (e.g. live or mobile CDNs) where this is a valid situation. The question is whether we should allow or deny these kinds of situation within our CDNI work. My personal opinion is in favor of allowing it, but if the consensus should point otherwise...

Ray

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: dinsdag 11 oktober 2011 17:56
To: Brandenburg, R. (Ray) van
Cc: ZhouZhipeng; [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Ray,

Ben

---

From: Kevin J Ma <[email-masked]>
Date: Tue, 11 Oct 2011 12:04:18 -0400

Ben,

  The restriction is not that content "absolutely must be delivered by a
  different CDN", the restriction is that content should only be delivered
  in specific formats to specific end users, and certain users may only
  get access through specific CDNs.  This can be (and is) enforced today by
  using different CDNs (e.g., separate CDNs for TV vs mobile).  Once those
  two CDNs combine, it removes an inherent physical restriction, which some
  CPs may have been relying on.

thanx.

--  Kevin J. Ma

> Sent: Tuesday, October 11, 2011 11:51 AM
> To: Kevin J Ma
> Cc: Brandenburg, R. (Ray) van; [email-masked]; ZhouZhipeng
> I'd like to understand these requirements better as I am aware of Content
> Providers that choose to use different CDNs for different representations
> based on business policy and I think that can be solved at the business
> agreement level in the same way as dealing with what delivery protocols or
> delivery footprint the Content Provider requires.
> 
> I am aware of licensing agreements that restrict what geographies content
> can be delivered from and what geographies content can be delivered to.
> Such requirements are already handled by the metadata proposal I co-
> authored through the use of SelectionACL & DeliveryACLs.
> 
> However, I've not heard of a licensing agreement that mandated that some
> representations of a piece of content absolutely must be delivered by a
> different CDN to other representations of the same content.
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 11 Oct 2011 17:19:29 +0100

Zhipeng,

> I like to know whether you may accept that my use case is similar to this case above.

I don't think your use case is similar to the analogy of mobile networks being interconnected to PSTN networks. In the case of content delivery the negotiation is done between the User/Client and the Content Provider and the CDN is just used to execute/perform the delivery that has been negotiated. The CDN is not involved in the decision making of what representations the Content Provider decides to offer to the User/Client or in what representations the User/Client decides to request.
 
> As for you said selecting media by the "portal", you may see the way " uCDN delivers multiple media streams to dCDN" is not good than "uCDN delivers one media stream to dCDN and dCDN takes some ada…

Now what you're talking about is an optimisation, not a core function required to actually deliver the content (and report, bill, etc. for that delivery). 

My position is that we should focus on how to enable the interconnection of the core CDN functionality offered by CDNs today (which is also my interpretation of the scope of the CDNI working group as expressed in its charter) because doing so is a significant piece of work in itself. Let's not start trying to add in additional functionality beyond what the majority of CDNs support today as that will just delay us getting usable specifications into the market in a timely fashion IMO.

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 11 Oct 2011 17:30:06 +0100

Kevin,

>  CPs may have been relying on.

The services I am aware of enforce such restrictions by requiring content delivery to be authenticated (e.g. through use of a token/cookie) and the Content Provider's portal only handing out the necessary tokens/cookies for certain content to the appropriate users/clients. By doing so there is no need to rely on some inherent physical separation of different CDNs in order to be able to enforce the COntent Provider's policy and therefore no need to rely on the implicit physical separation of different CDNs.

After all the entire purpose of a CDN is to offer multiple independent services off a single physical platform, so if a CDN is not capable of meeting the separation needs of the services offered by a single Content Provider, I'd suggest they have some pretty big issues that would mean it is unlikely that a Content Provider would want to use them at all for any kind of delivery.

Ben

---

From: ZhouZhipeng <[email-masked]>
Date: Wed, 12 Oct 2011 09:22:57 +0000

Hello Ben,
The UE may select the content format on the CP web. After that the user only desires to get his selected content. 
But how the content is transferred to the client is not worried by the user.
The CP may create a special format as required by the user and ask the CDN to deliver to user.
While CP may give a HD format content to uCDN and the dCDN may then transform to the format as the user select.
In this case, it is nothing related to how the user select formats on CP website.
So, it is the CP and user to decide the content format not the CDN(your assert is not correct and seems you take that assert as your base for the discussion).

As for "the core CDN functionality offered by CDNs today", I have ever raised an email before that your company's webpage has claimed supporting media transformation and multi-screen service.
Perhaps, I like asking you list some features that you feel are the core functionalities by existing main stream CDNs. Thus we may compare and take deep look.

I guess many people have the experience/knowledge of content related service. The user and CP only care whether the CDN providers may satisfy their requirement while not care the internal process. Just as GSM/PSTN interconnection, the user only care successful interconnection while not care how the voice is transformed in process.

Besides, I like raise a case:
Given currently BBC recruits CDN providers that may support 10 media formats.
One candidate is your company, another is CDN-X. The users are located in France.
So both your company and CDN-X should connect a France CDN provider(CDN-Y).
If your company's solution is to send 10 streams of different format of one content to CDN-Y;
While CDN-X's solution is to send 1 stream to CDN-Y while CDN-Y may conduct some adaptation.
Comparing these two solutions, for your company and CDN-X, absolutely the cost of CDN-X is much lower.
For CDN-Y, in solution-1, it should receive/forward 10 streams ; while in solution-2, it should only receive 1 stream but need to take transformation to output 10 streams.

Which solution is more competitive. it is Solution 1, right. Remember the price from BBC is same to both your company and CDN-X or BBC would select one CDN provider with the lower price.
If a CDN provider may not get the contract from CP, how it may say it is not a core functionality. 

So, if we all realize that currently the media type is rich, the CDN providers should survive in the existing ecosystem and support the media types as required by the market.

Back to the case of GSM/G.711, it just when concerning the interconnection, the transformation should at once be solved. Otherwise the interconnection may not be operated.

Br,
Zhipeng

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: Wednesday, October 12, 2011 12:19 AM
To: ZhouZhipeng
Cc: [email-masked]; [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

 

Ben

---

From: ZhouZhipeng <[email-masked]>
Date: Wed, 12 Oct 2011 09:40:30 +0000

Sorry a typo below : 
Which solution is more competitive. it is "not" Solution 1, right.

-----Original Message-----
From: ZhouZhipeng 
Sent: Wednesday, October 12, 2011 5:23 PM
To: 'Ben Niven-Jenkins'
Cc: [email-masked]; [email-masked]
Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Hello Ben,

Br,
Zhipeng

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: Wednesday, October 12, 2011 12:19 AM
To: ZhouZhipeng
Cc: [email-masked]; [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

 

Ben

---

From: ZhouZhipeng <[email-masked]>
Date: Wed, 12 Oct 2011 09:42:46 +0000

Scott,
>>I tend to agree.  Although content adaptation may be desirable, it's not clear that we could effectively bound the number permutations of content adaptation that may be possible (encryption, watermark, transrate, transcode, etc.)
it means you have felt the scenario is valuable, right.
But you have some uncertainty (permutations of content adaptation).

Perhaps the content protection(encryption, watermark) is a little professional, i may just give a short conclusion that the security risk is mainly on the client not the server.
And the CDN use case has not brought new feature for the content protection. In fact the DRM work has done much complicated description of all possible scenarios.
As for transrate, transcode, too simple for the current equipment capability. And the CDNs(not CDN interconnection) may support such functionalities.

Zhipeng

From: Scott Wainner [mailto:[email-masked]]
Sent: Tuesday, October 11, 2011 10:42 PM
To: Ben Niven-Jenkins
Cc: ZhouZhipeng; [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Colleagues,

IMO Section 5.1.3 should be removed from the Use Cases draft. Content Adaptation (i.e. taking in a content item in one format and transforming it to another format or representation) is not a "core" function of a CDN which typically delivers the content that is requested without explicit knowledge of what that content actually is.
I tend to agree.  Although content adaptation may be desirable, it's not clear that we could effectively bound the number permutations of content adaptation that may be possible (encryption, watermark, transrate, transcode, etc.)

Scott

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 12 Oct 2011 18:12:36 +0100

Zhipeng,

> While CP may give a HD format content to uCDN and the dCDN may then transform to the format as the user select.

Lots of things may be possible to do and CDN providers offer many additional services on top of the "core" service of content delivery. However, our objective (based on my interpretation of the CDNI charter) is to focus on what is necessary to interconnect CDNs to deliver content from a CSP to an End User that is targeted and deployable within a short time frame (18-24 months).

Content transformation/adaptation is not an essential requirement in order to achieve that aim (we can deliver content from CSPs to End Users via multiple CDNs without needing or requiring any CDN supports content adaptation).

In my opinion we have enough work to do already without trying to expand the scope of our work to include additional requirements that do not help us address our core objectives as laid out in the CDNI charter.

> Perhaps, I like asking you list some features that you feel are the core functionalities by existing main stream CDNs. Thus we may compare and take deep look.

I think the core functionality maps pretty well to the CDNI interfaces, namely: Request Routing, Metadata configuration, log production and control plus content acquisition and content delivery.
 
> If a CDN provider may not get the contract from CP, how it may say it is not a core functionality. 

What you are describing is a possible optimization that a particular CDN may wish to implement not a core functionality required to enable content delivery between interconnected CDNs. I can think of many optimizations that a CDN could implement to differentiate their service but the internal workings of an individual CDN are out of scope of our charter.

So to repeat my position for a final time: Content adaptation is not a core function required to enable content delivery between interconnected CDNs and therefore given the workload we already have to specify solutions that do address the core functionality required to interconnect CDNs I do not think we should be trying to add more work into that workload as it will only distract us from achieving our goal of producing deployable solutions within the timeframe we are being told by operators they needs solutions within.

Ben

---

From: Kevin J Ma <[email-masked]>
Date: Wed, 12 Oct 2011 19:41:24 -0400

Hi Ben,

  While I agree that authentication is also a good feature, it is
  not exactly the same as preventing delegation.  Having users never
  ask for content-A over CDN-B, is not the same as preventing
  content-A from ever being delivered over CDN-B, where a less than
  lawful user could still possibly get to content-A via CDN-B.
  There will always be prevention measures, but the ability to
  blacklist/whitelist dCDNs for specific content seems like a
  reasonable thing to do, and should be achievable via metadata?

thanx.

--  Kevin J. Ma

> Sent: Tuesday, October 11, 2011 12:30 PM
> To: Kevin J Ma
> The services I am aware of enforce such restrictions by requiring content
> delivery to be authenticated (e.g. through use of a token/cookie) and the
> Content Provider's portal only handing out the necessary tokens/cookies
> for certain content to the appropriate users/clients. By doing so there is
> no need to rely on some inherent physical separation of different CDNs in
> order to be able to enforce the COntent Provider's policy and therefore no
> need to rely on the implicit physical separation of different CDNs.
> 
> 
> After all the entire purpose of a CDN is to offer multiple independent
> services off a single physical platform, so if a CDN is not capable of
> meeting the separation needs of the services offered by a single Content
> Provider, I'd suggest they have some pretty big issues that would mean it
> is unlikely that a Content Provider would want to use them at all for any
> kind of delivery.
> 
> Ben
> 
> 
> 
> >
> > thanx.
> >
> > --  Kevin J. Ma
> >
> >>>>> While I am neutral to the Content Adaptation discussion, I would
> like
> >> to
> >>>> form. While it is not the CDNs responsibility/decision whether to
> allow
> >> a
> >>>> dCDN only offers a subset of the representations available on the
> uCDN
> >> is
> >>>> I don't believe that dCDNs will only offer a subset of
> representations
> >> in
> >>>> some content (let's say a video) that the Content Provider may
> produce
> >> in
> >>>> A User will connect to the Content Provider's "portal" (which may be
> a
> >> web
> >>>> capability (e.g. what Users it can deliver to, what delivery
> protocols
> >> it
> >>>> particular client/device) connects to the Content Provider's portal
> and
> >> is
> >>>> not an explicit decision made by the dCDN and communicated to the
> uCDN
> >> for

---

From: Kevin J Ma <[email-masked]>
Date: Wed, 12 Oct 2011 19:41:35 -0400

Hi all,

  Just wanted to get back to the point that Phil raised earlier:

  > did we ever decide whether the Use cases doc is restricted to
  > "initial" scenarios, or whether it's all-encompassing, ie covering

  Are we saying that only "initial" scenarios should be documented?

  Many of the "future" scenarios seem as though opaque metadata would
  be sufficient?  If so, does defining optional metadata significantly
  increase our workload?

  e.g.: Given two pieces of metadata: "format" and "allow transform",
  are they sufficient to support a content transformation use case?
  The latter can by default prevent transformation, and the former
  provides the information necessary to do transformation, assuming
  transformation is allowed?  Beyond that, CDNI should be indifferent,
  and the dCDN is either empowered to optimize or not, as determined
  by the content provider who set the metadata?

thanx.

--  Kevin J. Ma

> Sent: Wednesday, October 12, 2011 1:13 PM
> To: ZhouZhipeng
> Cc: [email-masked]
> > The UE may select the content format on the CP web. After that the user
> only desires to get his selected content.
> > While CP may give a HD format content to uCDN and the dCDN may then
> transform to the format as the user select.
>
> Lots of things may be possible to do and CDN providers offer many
> additional services on top of the "core" service of content delivery.
> However, our objective (based on my interpretation of the CDNI charter) is
> to focus on what is necessary to interconnect CDNs to deliver content from
> a CSP to an End User that is targeted and deployable within a short time
> frame (18-24 months).
>
> Content transformation/adaptation is not an essential requirement in order
> to achieve that aim (we can deliver content from CSPs to End Users via
> multiple CDNs without needing or requiring any CDN supports content
> adaptation).
>
> In my opinion we have enough work to do already without trying to expand
> the scope of our work to include additional requirements that do not help
> us address our core objectives as laid out in the CDNI charter.
>
> > So, it is the CP and user to decide the content format not the CDN(your
> assert is not correct and seems you take that assert as your base for the
> discussion).
> >
> > As for "the core CDN functionality offered by CDNs today", I have ever
> raised an email before that your company's webpage has claimed supporting
> media transformation and multi-screen service.
> > Perhaps, I like asking you list some features that you feel are the core
> functionalities by existing main stream CDNs. Thus we may compare and take
> deep look.
>
> I think the core functionality maps pretty well to the CDNI interfaces,
> namely: Request Routing, Metadata configuration, log production and
> control plus content acquisition and content delivery.
>
> > I guess many people have the experience/knowledge of content related
> service. The user and CP only care whether the CDN providers may satisfy
> their requirement while not care the internal process. Just as GSM/PSTN
> interconnection, the user only care successful interconnection while not
> care how the voice is transformed in process.
> >
> > For CDN-Y, in solution-1, it should receive/forward 10 streams ; while
> in solution-2, it should only receive 1 stream but need to take
> transformation to output 10 streams.
> >
> > Which solution is more competitive. it is Solution 1, right. Remember
> the price from BBC is same to both your company and CDN-X or BBC would
> select one CDN provider with the lower price.
> What you are describing is a possible optimization that a particular CDN
> may wish to implement not a core functionality required to enable content
> delivery between interconnected CDNs. I can think of many optimizations
> that a CDN could implement to differentiate their service but the internal
> workings of an individual CDN are out of scope of our charter.
>
> So to repeat my position for a final time: Content adaptation is not a
> core function required to enable content delivery between interconnected
> CDNs and therefore given the workload we already have to specify solutions
> that do address the core functionality required to interconnect CDNs I do
> not think we should be trying to add more work into that workload as it
> will only distract us from achieving our goal of producing deployable
> solutions within the timeframe we are being told by operators they needs
> solutions within.
>
> Ben
>
> > So, if we all realize that currently the media type is rich, the CDN
> providers should survive in the existing ecosystem and support the media
> types as required by the market.
> >
> > Back to the case of GSM/G.711, it just when concerning the
> interconnection, the transformation should at once be solved. Otherwise
> the interconnection may not be operated.
> >
> > Br,
> > Zhipeng
> >
> >
> >
> >
> >> As you say, CDN is used to deliver content. That is absolutely correct
> that the delivery capability is the core requirement for CDN system.
> >> What means service. It should include "time" "location" and "media
> type", etc. These features are all the core feature for a service.
> >> If we only concern "delivering one data block", I am not sure whether
> the issues such as "logging" "geographic constraint" are the core of CDN.
> >>
> >> For "without explicit knowledge of what that content actually is ", I
> am not sure whether the wording is accurate since generally a CDN may
> claim it support different medias.
> >> By this opportunity, I like to share a use case: a call from a GSM
> phone to a PSTN telephone, the voice stream should be transformed from GSM
> voice to G.711.
> >> For the user, he does not need to know what type of data has been
> transferred, but the operator has done some work to interconnect two
> systems, right.
> > I don't think your use case is similar to the analogy of mobile networks
> being interconnected to PSTN networks. In the case of content delivery the
> negotiation is done between the User/Client and the Content Provider and
> the CDN is just used to execute/perform the delivery that has been
> negotiated. The CDN is not involved in the decision making of what
> representations the Content Provider decides to offer to the User/Client
> or in what representations the User/Client decides to request.
> >
> >> As for you said selecting media by the "portal", you may see the way "
> uCDN delivers multiple media streams to dCDN" is not good than "uCDN
> delivers one media stream to dCDN and dCDN takes some adaptation to
> support multiple media types".
> >
> > Now what you're talking about is an optimisation, not a core function
> required to actually deliver the content (and report, bill, etc. for that
> delivery).
> >
> > My position is that we should focus on how to enable the interconnection
> of the core CDN functionality offered by CDNs today (which is also my
> interpretation of the scope of the CDNI working group as expressed in its
> charter) because doing so is a significant piece of work in itself. Let's
> not start trying to add in additional functionality beyond what the
> majority of CDNs support today as that will just delay us getting usable
> specifications into the market in a timely fashion IMO.
> >
> > Ben
> >
> >> A good question is "security" since I have done six years on the DRM
> and like to promote the DRM all around the world:)
> >> If the content is needed to be protected, generally you may know all
> the systems should be granted by the content owner.
> >> Here I also like to clarify that not only the media itself but the
> information related to service itself (such as the geographic constraint)
> should be protected also.
> >> Thank you that you feel Content Adaption is an issue for "Requirements"
> but I do not know why it is not for Use case.
> >> I like to clarify to U that it is important for you operator since it
> may save investment if the system may support different services.
> >> For us vendor, we are happy operator may install a system for the
> mobile service and another system for the FBB service.
> >> At least the Use case and Requirement are informational to be referred
> in future work. So I do really feel you may accept it.
> cope with a scenario where (say) HD/SD conversion is done in the dCDN & to
> signal about this.
> >>
> don't know, did we ever decide whether the Use cases doc is restricted to
> "initial" scenarios, or whether it's all-encompassing, ie covering
> >> But these sorts of examples seem to be static policy things (to do with
> the capabilities & preferences of the CDNs & CSP), rather than metadata
> associated with a particular piece of content. In the discussion so far, I
> think negotiation about static policy stuff is rather out of scope(?)
> >>
> >> On security considerations, an interesting question is whether trust is
> transitive. Don't think it need be - just because CSP trusts uCDN, and
> uCDN trusts dCDN doesn't mean that the CSP automatically trusts the dCDN.
> However, i suspect this can get arbitrarily complex - so one possibility
> is to say that we will only handle cases where the trust is transitive.
> >>
> >> Best wishes
> >> phil
> >>
> >>
> >> Philip Eardley
> confidential. It's meant only for the individual(s) or entity named above.
> If you're not the intended recipient, note that disclosing, copying,
> distributing or using this information is prohibited. If you've received
> this email in error, please let me know immediately on the email address
> above. Thank you. We monitor our email system, and may record your emails.
> Adaptation (i.e. taking in a content item in one format and transforming
> it to another format or representation) is not a "core" function of a CDN
> which typically delivers the content that is requested without explicit
> knowledge of what that content actually is.
> >>
> >> Let's not forget that in building an end to end content service the CDN
> is only one component and is the component tasked with executing the
> delivery of a specific representation (version/copy/format etc.) of the
> selected content not the component tasked with deciding (or applying
> policy) on which version/copy/representation of content should be
> delivered.
> >>
> >> The decision as to which version/copy/representation to offer and allow
> to be delivered to a given device/user is implemented outside of the CDN
> (e.g. by the "portal" where the user first makes their content selection
> prior to the CDN becoming involved in the delivery of the selected
> content).
> >>
> >> Ben
> >>
> >>> In last month, I have contacted the Authors of this document and taken
> some email exchanges with Grant and Philip (BT).
> area to explain the content flexibility is currently a basic requirement
> for CDN service and related negotiation is needed in the CDN
> interconnection.

---

From: ZhouZhipeng <[email-masked]>
Date: Thu, 13 Oct 2011 01:51:10 +0000

Ben,
I respect your personal standpoint while seems you are only repeating your personal conclusion without new reason/evidence.
In my case, I have explained the uCDN may deliver 10 streams to the dCDN.
But in our reality, we should consider whether it is a proper solution that will be used by the market.
If the standard may not support the market requirements, it is just the problem for its deployment.

Meanwhile in my feeling you have not carefully thought about how it will bring to the standard. I have repeated it is very simple in fact and I do not know whether you have any special concern that will make you feel it would not be able to be done within 18-24 months.
Ben, as I repeat, if you have any question, I like respond via reflector or to you individually.
Thanks.
Zhipeng

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: Thursday, October 13, 2011 1:13 AM
To: ZhouZhipeng
Cc: [email-masked]; [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

 

Ben

---

From: Kevin J Ma <[email-masked]>
Date: Wed, 12 Oct 2011 22:44:46 -0400

Zhipeng,

  One practical concern to consider with the use case of downloading one
  (as opposed to ten) streams is that premium content providers generally
  are very concerned with quality control and are unlikely to trust dCDNs
  to modify the content, and most likely, the content will be encrypted?

thanx.

--  Kevin J. Ma

> ZhouZhipeng
> Sent: Wednesday, October 12, 2011 9:51 PM
> To: Ben Niven-Jenkins
> Cc: [email-masked]
> I respect your personal standpoint while seems you are only repeating your
> personal conclusion without new reason/evidence.
> Meanwhile in my feeling you have not carefully thought about how it will
> bring to the standard. I have repeated it is very simple in fact and I do
> not know whether you have any special concern that will make you feel it
> would not be able to be done within 18-24 months.

---

From: ZhouZhipeng <[email-masked]>
Date: Thu, 13 Oct 2011 03:25:09 +0000

Kevin,

As we ever discussed in previous email that the content format in fact is decided by the CP.
Only under the permission, the HD video may be transformed to the mobile video. i.e. if the CP support both IPTV and mobile video service, then it may require the CDN to support multiple video formats. The multi-screen service means the content source is from the same CP while the target devices/clients include different groups. All content businesses are under the permission of the content owner.

For the content protection, I like talk a little more in this email for reference:
Given there are two areas: London and Paris.
And in these two areas, each has deployed the DRM. Generally each DRM implementation is independent.
If the content is delivered from London to Paris, absolutely the whole process should be granted by the CP.
For the DRM standard, it mainly concern the security on the terminal and the interface between the SP/Client.
You may see that the servers that are granted by the CP is secure and we do not need to worry that secure server would be the hacker.
Hence, if the content is delivered from one server to another server( these servers are the equipments granted by CP that may handle and encrypt the content), the content is safe. Whether decrypt/re-encrypt or just deliver unencrypted content between these two servers are secure.

Also, we may see such security issue for content distribution is a general scenario that is not related to whether taking content adaptation.

Thanks.
Zhipeng

-----Original Message-----
From: Kevin J Ma [mailto:[email-masked]] 
Sent: Thursday, October 13, 2011 10:45 AM
To: ZhouZhipeng; Ben Niven-Jenkins
Cc: [email-masked]
Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

thanx.

--  Kevin J. Ma

---

From: Kevin J Ma <[email-masked]>
Date: Thu, 13 Oct 2011 00:01:36 -0400

Zhipeng,

  If the CP has tight integration with both CDN providers as you describe
  below, I do not see why they would need CDNI at all?  What would be the
  benefit if they already have custom servers and security?

  Premium content providers that I am familiar with pregenerate content
  encodings, run them through rigorous quality control tests, and do
  not allow any modifications after that, to guarantee quality.  To do
  that in a CDN, let alone across CDNs, seems unlikely.  Content is
  processed in a secure facility and never released unencrypted to the
  CDN.  The CDN just acts a transparent delivery medium.

thanx.

--  Kevin J. Ma

> From: ZhouZhipeng [mailto:[email-masked]]
> Sent: Wednesday, October 12, 2011 11:25 PM
> To: Kevin J Ma; Ben Niven-Jenkins
> Cc: [email-masked]
> Only under the permission, the HD video may be transformed to the mobile
> video. i.e. if the CP support both IPTV and mobile video service, then it
> may require the CDN to support multiple video formats. The multi-screen
> service means the content source is from the same CP while the target
> devices/clients include different groups. All content businesses are under
> the permission of the content owner.
>
> You may see that the servers that are granted by the CP is secure and we
> do not need to worry that secure server would be the hacker.
> Hence, if the content is delivered from one server to another server(
> these servers are the equipments granted by CP that may handle and encrypt
> the content), the content is safe. Whether decrypt/re-encrypt or just
> deliver unencrypted content between these two servers are secure.
>
> Also, we may see such security issue for content distribution is a general
> scenario that is not related to whether taking content adaptation.
>
> Thanks.
> Zhipeng
>
>
>
> > > In this case, it is nothing related to how the user select formats on
> CP
> > website.
> > > So both your company and CDN-X should connect a France CDN
> provider(CDN-
> > Y).
> > > If your company's solution is to send 10 streams of different format
> of
> > one content to CDN-Y;
> > > If a CDN provider may not get the contract from CP, how it may say it
> is
> > not a core functionality.
> >
> > >> Frankly, Ben and Philip, I remember I have explained somewhere that
> to
> > implement this is rather simple .
> with
> above.
> taken
> > >>> the delegation for content delivery is executed.  Clearly, the
> choice
> > of

---

From: ZhouZhipeng <[email-masked]>
Date: Thu, 13 Oct 2011 05:26:44 +0000

Kevin,
For the content distribution scenario, I like share the real case of Olypic games.
The NBC sells to CCTV the copy right of Olypic game content including all kinds of media channel within China Mainland. CCTV may use the content in its own TV system meanwhile it resell the copy right to specific channel including MTV and internet video channels.
You may see in this business, the original content has been transformed for different target consumers and each channel has its own DRM solutions(Cable TV uses CA, others use OMA DRM,etc.)

As for the content quality, as I know for example the IPTV, the USA content producer only provides the HD format to the IPTV operator, but the IPTV operator may provide both HD and SD channel. The content encryption/transcoding/delivery are all done by iptv operator while the CP should has grant that.
The CP only provide the source content while the equipments are all belonged to the operators. 

CDN is a channel while it is a business channel. Even the content is not encrypted, the CDN would not attack the content. For example the content with advertisement, the CDN would not replace the original advertisement for its own advertisement. Otherwise the CDN may not continue its own business.

In fact your question is to analyze what job/role is done by CP and operators. 
I check that azuki platform includes the DRM capabilities. Of course I like to know your more information on this issue.
Thanks.
Zhipeng

-----Original Message-----
From: Kevin J Ma [mailto:[email-masked]] 
Sent: Thursday, October 13, 2011 12:02 PM
To: ZhouZhipeng; Ben Niven-Jenkins
Cc: [email-masked]
Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

thanx.

--  Kevin J. Ma

---

From: <[email-masked]>
Date: Thu, 13 Oct 2011 11:34:05 +0100

I'd support that perspective. Today CPs, in my experience, sometimes even actively seeks assurances that the content will NOT be modified by the CDN or by other downstream processes. So to envisage a CP allowing/wanting that to happen in a dCDN (that is likely out of their control, perhaps in another geography and with no quality feedback) feels like a very, very unlikely scenario. In general the content arrives encrypted and is shipped transparently, in my experience. Indeed the CPs desire to ship to different devices / screens etc. is also transparent to the CDN, they're just different objects requested by logic that is out-of-band to the CDN.

I know of cases where content is transcoded/modified for mobile access by transparent caching, for example. But TC is not relevant to CDNI.

IMHO content adaption/modification/transcoding is not a fundamental issue for CDNI. The issues around solving the fundamentals of how to Interconnect CDN are challenging enough. So I feel we should focus the scope on widely deployed use-cases / features and very likely new use-cases that are created by CDNI.

g-

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kevin J Ma
Sent: 13 October 2011 05:02
To: ZhouZhipeng; Ben Niven-Jenkins
Cc: [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

thanx.

--  Kevin J. Ma

> Only under the permission, the HD video may be transformed to the
> mobile video. i.e. if the CP support both IPTV and mobile video
> service, then it may require the CDN to support multiple video
> formats. The multi-screen service means the content source is from the
> same CP while the target devices/clients include different groups. All
> content businesses are under the permission of the content owner.
>
> For the content protection, I like talk a little more in this email
> for
> reference:
> You may see that the servers that are granted by the CP is secure and
> we do not need to worry that secure server would be the hacker.
> these servers are the equipments granted by CP that may handle and
> encrypt the content), the content is safe. Whether decrypt/re-encrypt
> or just deliver unencrypted content between these two servers are secure.
>
> Also, we may see such security issue for content distribution is a
> general scenario that is not related to whether taking content adaptation.
>
> Thanks.
> Zhipeng
>
>
>
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of ZhouZhipeng
> > I respect your personal standpoint while seems you are only
> > repeating
> your
> > But in our reality, we should consider whether it is a proper
> > solution that will be used by the market.
> > Meanwhile in my feeling you have not carefully thought about how it
> > will bring to the standard. I have repeated it is very simple in
> > fact and I
> do
> > not know whether you have any special concern that will make you
> > feel it would not be able to be done within 18-24 months.
> > > But how the content is transferred to the client is not worried by
> > > the
> > user.
> > > The CP may create a special format as required by the user and ask
> > > the
> > CDN to deliver to user.
> > However, our objective (based on my interpretation of the CDNI
> > charter)
> is
> > to focus on what is necessary to interconnect CDNs to deliver
> > content
> from
> > a CSP to an End User that is targeted and deployable within a short
> > time frame (18-24 months).
> >
> > to achieve that aim (we can deliver content from CSPs to End Users
> > via multiple CDNs without needing or requiring any CDN supports
> > content adaptation).
> >
> > In my opinion we have enough work to do already without trying to
> > expand the scope of our work to include additional requirements that
> > do not
> help
> > assert is not correct and seems you take that assert as your base
> > for
> the
> > discussion).
> > >
> > > Perhaps, I like asking you list some features that you feel are
> > > the
> core
> > functionalities by existing main stream CDNs. Thus we may compare
> > and
> take
> > deep look.
> >
> > service. The user and CP only care whether the CDN providers may
> > satisfy their requirement while not care the internal process. Just
> > as GSM/PSTN interconnection, the user only care successful
> > interconnection while not care how the voice is transformed in process.
> > >
> > > Given currently BBC recruits CDN providers that may support 10
> > > media
> > formats.
> > > One candidate is your company, another is CDN-X. The users are
> > > located
> > in France.
> > > While CDN-X's solution is to send 1 stream to CDN-Y while CDN-Y
> > > may
> > conduct some adaptation.
> > > Comparing these two solutions, for your company and CDN-X,
> > > absolutely
> > the cost of CDN-X is much lower.
> > the price from BBC is same to both your company and CDN-X or BBC
> > would select one CDN provider with the lower price.
> > What you are describing is a possible optimization that a particular
> > CDN may wish to implement not a core functionality required to
> > enable
> content
> > delivery between interconnected CDNs. I can think of many
> > optimizations that a CDN could implement to differentiate their
> > service but the
> internal
> > So to repeat my position for a final time: Content adaptation is not
> > a core function required to enable content delivery between
> > interconnected CDNs and therefore given the workload we already have
> > to specify
> solutions
> > that do address the core functionality required to interconnect CDNs
> > I
> do
> > not think we should be trying to add more work into that workload as
> > it will only distract us from achieving our goal of producing
> > deployable solutions within the timeframe we are being told by
> > operators they needs solutions within.
> >
> > Ben
> >
> > providers should survive in the existing ecosystem and support the
> > media types as required by the market.
> > >
> > interconnection, the transformation should at once be solved.
> > Otherwise the interconnection may not be operated.
> > >
> > > Br,
> > > Zhipeng
> > >
> > >
> > >
> > >
> > >> I feel what we are now discussing is what is the "core" function
> > >> of
> > CDN.
> > am not sure whether the wording is accurate since generally a CDN
> > may claim it support different medias.
> > phone to a PSTN telephone, the voice stream should be transformed
> > from
> GSM
> > voice to G.711.
> > >> I like to know whether you may accept that my use case is similar
> > >> to
> > this case above.
> > >
> > being interconnected to PSTN networks. In the case of content
> > delivery
> the
> > negotiation is done between the User/Client and the Content Provider
> > and the CDN is just used to execute/perform the delivery that has
> > been negotiated. The CDN is not involved in the decision making of
> > what representations the Content Provider decides to offer to the
> > User/Client or in what representations the User/Client decides to request.
> > >
> > >> As for you said selecting media by the "portal", you may see the
> > >> way
> "
> > of the core CDN functionality offered by CDNs today (which is also
> > my interpretation of the scope of the CDNI working group as
> > expressed in
> its
> > majority of CDNs support today as that will just delay us getting
> > usable specifications into the market in a timely fashion IMO.
> > >
> > > Ben
> > >
> > >> But the reality is all operators ask us to provide a system that
> > >> may
> > support different service systems.
> > >>
> > >> I think that Content Adaptation is more an issue for the
> > >> Requirements
> > doc than for the Use cases draft.
> > >>
> > cope with a scenario where (say) HD/SD conversion is done in the
> > dCDN &
> to
> > signal about this.
> > >>
> > ie we should not worry about it in the initial standards-track work.
> > I don't know, did we ever decide whether the Use cases doc is
> > restricted
> to
> > >> Reading some of your examples, they seem to be valid even if
> > >> content
> > adaptation (HD/SD) is out of scope.
> > the capabilities & preferences of the CDNs & CSP), rather than
> > discussion so far,
> I
> > transitive. Don't think it need be - just because CSP trusts uCDN,
> > the
> dCDN.
> > possibility is to say that we will only handle cases where the trust is transitive.
> > >>
> > >> Best wishes
> > >> phil
> > >>
> > >>
> > >> Philip Eardley
> > distributing or using this information is prohibited. If you've
> > received this email in error, please let me know immediately on the
> > email address above. Thank you. We monitor our email system, and may
> > record your
> emails.
> > >> Registered office: 81 Newgate Street London EC1A 7AJ Registered
> > >> in England no: 1800000
> > >>
> > >>
> > >> From: [email-masked] [mailto:[email-masked]] On
> > >> Behalf
> Of
> > Ben Niven-Jenkins
> > function of a
> > which typically delivers the content that is requested without
> > explicit knowledge of what that content actually is.
> > >>
> > delivery of a specific representation (version/copy/format etc.) of
> > the selected content not the component tasked with deciding (or
> > applying
> > to be delivered to a given device/user is implemented outside of the
> > CDN (e.g. by the "portal" where the user first makes their content
> > >>> content
> > >>> specific
> > >>> the third paragraph states the case where a different device is
> > >>> used
> > in
> > >>> the same CDN coverage area.  The intent of this use case needs
> > >>> scenario
> > where
> > >>> a Nomadic User-A with an agreement allowing access to content
> > >>> from
> > CSP-A
> > >>> via uCDN moves to a dCDN in a different region.  The dCDN is
> > >>> allowed
> > to
> > >>> distribute the content of CSP-A to User-A; however, not other
> > >>> users
> in
> > >>> the region of the dCDN are allowed to retrieve the content
> > >>> unless
> they
> > >>> Section 5.1.3 Content Encoding Restrictions Need to clarify if
> > >>> we're talking about the restrictions on the delivery of specific
> > >>> content or the restrictions on the ability of a
> > CDN
> > >>> to deliver specific content.  I certainly understand the case
> > >>> where
> a
> > >>> CSP will restrict the distribution of content to a "managed
> > >>> path" if such content is HD while allowing the content
> > >>> distribution via an un-managed path if such content is SD (same
> > >>> could apply to
> encryption
> > >>> o third bullet make sense if the policy addresses QoE but I
> > >>> don't think subscriber rights/authorizations apply.
> > >>>
> > >>> b. The relationship between the uCDN and dCDN (the transitive
> > >>> trust relationship that extends the contract defined in (a)
> > >>> above) c. The relationship between the User and dCDN (the
> > >>> recognition of
> > right
> > >>> to download predicated on (b) above) d. The relationship between
> > >>> the User and CSP (the contract
> authorizing
> > >>> is only interested in the transparency and interoperability of
> > >>> the security relationship between d-b or d-c to the point that
> > >>> the authorization granted in d-a is viable when the delivery is
> initiated
> > >>> is only afforded if the methods are interoperable clearly
> > >>> defined
> when

---

From: Scott Wainner <[email-masked]>
Date: Thu, 13 Oct 2011 07:54:14 -0400

Seems there are potentially two classes of use cases:

1) Premium Content - CSP specifies available formats, encrypts, 
establishes relationship with client, agrees upon the available formats, 
and provides the client with a URL of their authorized delivery partner 
(uCDN) with permission to delegate delivery (assuming no content 
modification).  The uCDN needs to qualify the dCDN via CDNi; however, 
the dCDN will merely be a transparent transfer point.  The URL provided 
by the CSP needs to be modified somehow to point to the dCDN delivery 
node as opposed to the uCDN delivery node.   The selected format (by the 
client) may NOT be viable for delivery over the dCDN; therefore, the 
uCDN should not delegate the delivery.  That is the point of CDNi.

NOTE: I still think there needs to be some basic elements covered by 
CDNi that addresses client <-> CDN authentication methods.  CDN's use 
different authentication methods that ALLOW the client to even talk to 
the delivery nodes.

2) Public Content - CSP provides content in a specified format, 
unencrypted, doesn't specify the potential alternative formats, but 
provides the client with a URL of their preferred delivery partner 
(uCDN) with implicit permission to delegate delivery.  No assumption or 
assertion is made about content modification.  From the uCDN's 
perspective, they are simply looking for the dCDN's ability to delivery 
the content as presented by the CSP.  The dCDN may indicate that it can 
deliver the content in which case the uCDN delegates the delivery.  At 
this point, the dCDN is at liberty to transcode / transrate the content 
to optimize their transport resources.  What knowledge does the dCDN 
have that the client can actually receive the modified content?

The only way I can see (2) being resolved is if the dCDN had knowledge 
(metadata) about the capabilities / limitations of the client or a 
bounded set of viable adaptations of the content itself.

Scott

On 10/13/11 12:01 AM, Kevin J Ma wrote:
> > As we ever discussed in previous email that the content format in 
> fact is
> > decided by the CP.
> encrypt
> general
> Behalf Of
> > > If the standard may not support the market requirements, it is 
> just the
> > > problem for its deployment.
> > >
> feel it
> > > Ben, as I repeat, if you have any question, I like respond via 
> reflector
> > > or to you individually.
> > > Thanks.
> > > Zhipeng
> > >
> > > > But how the content is transferred to the client is not worried 
> by the
> > > user.
> > > > The CP may create a special format as required by the user and 
> ask the
> > > CDN to deliver to user.
> expand
> satisfy
> optimizations
> > > >> I like to know whether you may accept that my use case is 
> similar to
> > > this case above.
> > > >
> > > >> As for you said selecting media by the "portal", you may see 
> the way
> > "
> usable
> > > >> But the reality is all operators ask us to provide a system 
> that may
> metadata
> > > associated with a particular piece of content. In the discussion 
> so far,
> > I
> possibility
> received
> transforming
> explicit
> requirement
> > > >>> the third paragraph states the case where a different device 
> is used
> > > in
> to be
> path" if
> trust

---

From: ZhouZhipeng <[email-masked]>
Date: Thu, 13 Oct 2011 12:11:31 +0000

Grant, 
Nice to see your comment.
May I conclude that by now the core issue for the content adaptation is " content protection".
As a DRM people for years, I fully understand this concern.
In fact the DRM circle have fully understood this concern since DRM should consider both the protection and the service implementation.

May I ask a question, if the content has been encrypted and would not be modified in the CDNI process, but the devices in two areas have deployed different DRM system, how it will be for the CDNI.
It is not related to the content transcoding while you still face the issue for the protection transformation. For example, how your company's IPTV may connect the FT's terminals.

Even in the internet that the PCs in different area may install the same soft DRM client, it may still has the problem of the content's duplication and content's verification(integrity protection).
Take the OMA DRM DCF as an example, each content copy has its unique identifier(contentId) and each content copy has its unique Hash value. 
Hence in OMA DRM system, you( the device) may not duplicate a protected content copy that may be verified successfully by the device.
Only the CP that encrypt the content may create a new copy of the content with another identifier.

While in CDN system, we all know for the load balancing the CDN should be able to duplicate the hot content when needed. How it may be realized if the CDN may not create a new content copy that comply with the DRM solution.

So you may see, there should be a secure facility within the CDN that may create/encrypt the content which may be accepted by the DRM client.

Above is my analysis on this issue. Hope you may take a look at the OMA DRM specification to check the reason.
For any question, I would like to respond as long as I know.
Also note that the analysis is not specific to the content adaptation. I mean only general functionality of CDN.
Thanks.
Zhipeng 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, October 13, 2011 6:34 PM
To: [email-masked]; ZhouZhipeng; [email-masked]
Cc: [email-masked]
Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

g-

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kevin J Ma
Sent: 13 October 2011 05:02
To: ZhouZhipeng; Ben Niven-Jenkins
Cc: [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

thanx.

--  Kevin J. Ma

> > reflector or to you individually.
> > Thanks.
> > Zhipeng
> >

---

From: <[email-masked]>
Date: Thu, 13 Oct 2011 13:40:44 +0100

Hi,

"May I ask a question, if the content has been encrypted and would not be modified in the CDNI process, but the devices in two areas have deployed different DRM system, how it will be for the CDNI."

Just like it works right now: If objects are encrypted differently or use different DRMs generally it translates as separate objects in the CDN, Interconnected or otherwise. DRM is implemented by the CP, in the knowledge of what end devices and DRM platforms they are delivering to. IMHO that works right now and would work in a CDNI scenario.

Frankly, I am even more convinced that this is best left out of scope now. IMHO duplication of content assets inside the CDN to facilitate cross DRM delivery is not a CDNI issue. I can see how this may be optimised perhaps, to reduce the amount of assets for example, but again that is not a CDNI issue - the issue exists for both CDN today and Interconnected CDN.

g-

-----Original Message-----
From: ZhouZhipeng [mailto:[email-masked]]
Sent: 13 October 2011 13:12
To: Watson,G,Grant,DMK5 R; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Grant,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, October 13, 2011 6:34 PM
To: [email-masked]; ZhouZhipeng; [email-masked]
Cc: [email-masked]
Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

g-

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kevin J Ma
Sent: 13 October 2011 05:02
To: ZhouZhipeng; Ben Niven-Jenkins
Cc: [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

thanx.

--  Kevin J. Ma

---

From: "Woundy, Richard" <[email-masked]>
Date: Thu, 13 Oct 2011 15:35:04 +0000

(Not speaking as working group co-chair)

I would agree with Grant's comments below.

I believe that CDNI can usefully focus on centralized content adaptation for now, eg encoding, fragmenting, and encryption. Two items that make sense to push to the edge (and therefore be a consideration for CDNI interfaces) are session-based encryption and watermarking.

There is a technical paper "Unified Content Packaging Architectures for Managed Video Content Delivery" for an upcoming SCTE conference that does a good job of discussing and analyzing the centralized vs edge topic. Unfortunately, the conference is the same week as IETF 82, and SCTE may charge to get a copy of the paper and presentation. If that does not deter you, see <http://expo.scte.org/content/sessions/workshopsdescriptions.cfm#CDN>.

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, October 13, 2011 8:41 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Hi,

g-

-----Original Message-----
From: ZhouZhipeng [mailto:[email-masked]]
Sent: 13 October 2011 13:12
To: Watson,G,Grant,DMK5 R; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Grant,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, October 13, 2011 6:34 PM
To: [email-masked]; ZhouZhipeng; [email-masked]
Cc: [email-masked]
Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

g-

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kevin J Ma
Sent: 13 October 2011 05:02
To: ZhouZhipeng; Ben Niven-Jenkins
Cc: [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

thanx.

--  Kevin J. Ma

---

From: Saurabh Chattopadhyay <[email-masked]>
Date: Thu, 13 Oct 2011 23:01:05 +0530

Colleagues,

While I’m also of the opinion that the particular case is best left out of
scope for now, I think the scoping shall get defined/refined in a more
appropriate place, possibly in CDN-I problem statement draft.

Following is a relevant part from ‘draft-ietf-cdni-problem-statement’ –

“NSPs have often deployed CDNs as specialized cost-reduction projects

   within the context of a particular service or environment, some NSPs

   operate separate CDNs for separate services.  For example, there may

   be a CDN for managed IPTV service delivery, a CDN for web-TV delivery

   and a CDN for video delivery to Mobile terminals.  As NSPs integrate

   their service portfolio, there is a need for interconnecting these

   CDNs.  Again, NSPs face the problem of lack of open interfaces for

   CDN interconnection.

”

Unquestionably, primary responsibility of CDN-I is to standardize open
interfaces for core content delivery function, however, while the CDNs adopt
the particular Service Profiles, the scope of CDN-I gets naturally extended
to interconnect the different service profiles. To clarify, a CDN for Video
Delivery to Mobile Terminals, to me is a CDN adopting Service Profile of
‘Video Delivery to Mobile Terminals’. And current discussion on Content
Adaptation appears as a particular case for interconnecting CDNs of
different Service Profiles.

To that end, many aspects of ongoing work will get questioned to realize the
extent of the interconnection use cases supporting Service Portfolio
transformations and whether to be considered part of the current scope or
not.

IMHO the overall work needs to be staged in a manner that core Content
Delivery Function gets the immediate attention, and subsequently the work
group shall decide on the relevant part of service profile interconnection
to standardize till required extent.

Regards,
Saurabh

On Thu, Oct 13, 2011 at 6:10 PM, <[email-masked]> wrote:

> Hi,
>
> "May I ask a question, if the content has been encrypted and would not be
> modified in the CDNI process, but the devices in two areas have deployed
> different DRM system, how it will be for the CDNI."
>
> Just like it works right now: If objects are encrypted differently or use
> different DRMs generally it translates as separate objects in the CDN,
> Interconnected or otherwise. DRM is implemented by the CP, in the knowledge
> of what end devices and DRM platforms they are delivering to. IMHO that
> works right now and would work in a CDNI scenario.
>
> Frankly, I am even more convinced that this is best left out of scope now.
> IMHO duplication of content assets inside the CDN to facilitate cross DRM
> delivery is not a CDNI issue. I can see how this may be optimised perhaps,
> to reduce the amount of assets for example, but again that is not a CDNI
> issue - the issue exists for both CDN today and Interconnected CDN.
>
> g-
>
>
> In fact the DRM circle have fully understood this concern since DRM should
> consider both the protection and the service implementation.
>
> May I ask a question, if the content has been encrypted and would not be
> modified in the CDNI process, but the devices in two areas have deployed
> different DRM system, how it will be for the CDNI.
> It is not related to the content transcoding while you still face the issue
> for the protection transformation. For example, how your company's IPTV may
> connect the FT's terminals.
>
> Even in the internet that the PCs in different area may install the same
> soft DRM client, it may still has the problem of the content's duplication
> and content's verification(integrity protection).
> Take the OMA DRM DCF as an example, each content copy has its unique
> identifier(contentId) and each content copy has its unique Hash value.
> Hence in OMA DRM system, you( the device) may not duplicate a protected
> content copy that may be verified successfully by the device.
> While in CDN system, we all know for the load balancing the CDN should be
> able to duplicate the hot content when needed. How it may be realized if the
> CDN may not create a new content copy that comply with the DRM solution.
>
> So you may see, there should be a secure facility within the CDN that may
> create/encrypt the content which may be accepted by the DRM client.
>
> I'd support that perspective. Today CPs, in my experience, sometimes even
> actively seeks assurances that the content will NOT be modified by the CDN
> or by other downstream processes. So to envisage a CP allowing/wanting that
> to happen in a dCDN (that is likely out of their control, perhaps in another
> geography and with no quality feedback) feels like a very, very unlikely
> scenario. In general the content arrives encrypted and is shipped
> transparently, in my experience. Indeed the CPs desire to ship to different
> devices / screens etc. is also transparent to the CDN, they're just
> different objects requested by logic that is out-of-band to the CDN.
>
> I know of cases where content is transcoded/modified for mobile access by
> transparent caching, for example. But TC is not relevant to CDNI.
>
> IMHO content adaption/modification/transcoding is not a fundamental issue
> for CDNI. The issues around solving the fundamentals of how to Interconnect
> CDN are challenging enough. So I feel we should focus the scope on widely
> deployed use-cases / features and very likely new use-cases that are created
> by CDNI.
>
> g-
>
> Kevin J Ma

---

From: ZhouZhipeng <[email-masked]>
Date: Fri, 14 Oct 2011 02:01:28 +0000

Grant,
I am not sure whether you mean that DRM is not a problem for the CDNI scenario as I suggested since initiation. 
Philip and you have the concern of DRM, therefore several emails have been given clarifying this issue.
And as I explain the content adaptation does not bring new protection requirement to the CDNi. i.e. that works right now.

>>"IMHO duplication of content assets inside the CDN to facilitate cross DRM delivery is not a CDNI issue."  
I guess you have not caught the core meaning of my explanation. 
It means in a single CDN, since the content duplication is needed while DRM protection requires that the entity that may duplicate the content should be secure to handle that.

So totally my conclusion is DRM is mature enough for the scenarios we discussed and has no special to the content adaptation.
Pls kindly check my conclusion. 
Thanks.
Zhipeng

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, October 13, 2011 8:41 PM
To: ZhouZhipeng; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Hi,

g-

-----Original Message-----
From: ZhouZhipeng [mailto:[email-masked]]
Sent: 13 October 2011 13:12
To: Watson,G,Grant,DMK5 R; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Grant,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, October 13, 2011 6:34 PM
To: [email-masked]; ZhouZhipeng; [email-masked]
Cc: [email-masked]
Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

g-

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kevin J Ma
Sent: 13 October 2011 05:02
To: ZhouZhipeng; Ben Niven-Jenkins
Cc: [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

thanx.

--  Kevin J. Ma

---

From: ZhouZhipeng <[email-masked]>
Date: Fri, 14 Oct 2011 02:36:46 +0000

Woundy,
Nice for your sharing the information below.
I am also happy to see there is a session on related issue. 

As for CDNI, may I suggest we may have a use case first since it does not bring problem for other issues.

Thanks.
Zhipeng
-----Original Message-----
From: Woundy, Richard [mailto:[email-masked]] 
Sent: Thursday, October 13, 2011 11:35 PM
To: [email-masked]; ZhouZhipeng; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, October 13, 2011 8:41 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Hi,

g-

-----Original Message-----
From: ZhouZhipeng [mailto:[email-masked]]
Sent: 13 October 2011 13:12
To: Watson,G,Grant,DMK5 R; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Grant,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, October 13, 2011 6:34 PM
To: [email-masked]; ZhouZhipeng; [email-masked]
Cc: [email-masked]
Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

g-

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kevin J Ma
Sent: 13 October 2011 05:02
To: ZhouZhipeng; Ben Niven-Jenkins
Cc: [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

thanx.

--  Kevin J. Ma

---

From: ZhouZhipeng <[email-masked]>
Date: Fri, 14 Oct 2011 03:10:07 +0000

Saurabh,

On the core functionality as always.
Right now across the world, the convergence of mobile/internet/fixed system is the key requirement for the industry.
Generally CDN is not restricted to a special service. A CDN may support either web-TV delivery or managed IPTV service delivery.

The multi-screen service, means the CDN may deliver content to TV, PAD, PHONE, PC... any screen.
Because the PC may display HD while PHONE may only display small video, the content adaptation may be used before the CDN deliver content to each terminal.

This thread is raised from the concern: whether the protection will be a problem for the content adaptation.
If the people may know that content adaption has no impact for existing DRM,  our discussion has achieved good effect.

Thanks.
Zhipeng

From: Saurabh Chattopadhyay [mailto:[email-masked]]
Sent: Friday, October 14, 2011 1:31 AM
To: [email-masked]
Cc: ZhouZhipeng; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Colleagues,
While I'm also of the opinion that the particular case is best left out of scope for now, I think the scoping shall get defined/refined in a more appropriate place, possibly in CDN-I problem statement draft.
Following is a relevant part from 'draft-ietf-cdni-problem-statement' -
"NSPs have often deployed CDNs as specialized cost-reduction projects
   within the context of a particular service or environment, some NSPs
   operate separate CDNs for separate services.  For example, there may
   be a CDN for managed IPTV service delivery, a CDN for web-TV delivery
   and a CDN for video delivery to Mobile terminals.  As NSPs integrate
   their service portfolio, there is a need for interconnecting these
   CDNs.  Again, NSPs face the problem of lack of open interfaces for
   CDN interconnection.
"
Unquestionably, primary responsibility of CDN-I is to standardize open interfaces for core content delivery function, however, while the CDNs adopt the particular Service Profiles, the scope of CDN-I gets naturally extended to interconnect the different service profiles. To clarify, a CDN for Video Delivery to Mobile Terminals, to me is a CDN adopting Service Profile of 'Video Delivery to Mobile Terminals'. And current discussion on Content Adaptation appears as a particular case for interconnecting CDNs of different Service Profiles.
To that end, many aspects of ongoing work will get questioned to realize the extent of the interconnection use cases supporting Service Portfolio transformations and whether to be considered part of the current scope or not.
IMHO the overall work needs to be staged in a manner that core Content Delivery Function gets the immediate attention, and subsequently the work group shall decide on the relevant part of service profile interconnection to standardize till required extent.
Regards,
Saurabh

On Thu, Oct 13, 2011 at 6:10 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

g-

-----Original Message-----
From: ZhouZhipeng [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 13 October 2011 13:12
To: Watson,G,Grant,DMK5 R; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Grant,

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, October 13, 2011 6:34 PM
To: [email-masked]<mailto:[email-masked]>; ZhouZhipeng; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

g-

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Kevin J Ma
Sent: 13 October 2011 05:02
To: ZhouZhipeng; Ben Niven-Jenkins
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

thanx.

--  Kevin J. Ma

> From: ZhouZhipeng [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: [email-masked]<mailto:[email-masked]>
> From: Kevin J Ma [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: [email-masked]<mailto:[email-masked]>
> > From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf
> > Of ZhouZhipeng
> > Cc: [email-masked]<mailto:[email-masked]>
> > From: Ben Niven-Jenkins [mailto:[email-masked]<mailto:[email-masked]>]
> > Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> > > From: Ben Niven-Jenkins [mailto:[email-masked]<mailto:[email-masked]>]
> > > Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> > >> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
> > >> To: [email-masked]<mailto:[email-masked]>; ZhouZhipeng
> > >> Cc: [email-masked]<mailto:[email-masked]>
> > >> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
> > >> Behalf
> Of
> > Ben Niven-Jenkins
> > >> Cc: [email-masked]<mailto:[email-masked]>
> > >>> From: Scott Wainner [mailto:[email-masked]<mailto:[email-masked]>]

---

From: Songhaibin <[email-masked]>
Date: Tue, 18 Oct 2011 09:46:55 +0000

Following this discussion, I think there are two basic questions for the WG to answer:

1.       Whether a capability negotiation is needed for an upstream CDN to select one eligible downstream CDN (assume that business is out of scope), provided that different CDNs have different "service profiles".

2.       Whether content is transparent to current CDNs. If yes, there is NO transcoding/transrating kind of content adaptation in CDNs, and of course there will be NO parameter related to such kind of capability in CDNI scope.  If content is NOT transparent to current CDNs, then IMO CDNI has interoperability concerns to use the content adaptation parameters.

BR,
-Haibin

From: [email-masked] [mailto:[email-masked]] On Behalf Of ZhouZhipeng
Sent: Friday, October 14, 2011 11:10 AM
To: Saurabh Chattopadhyay; [email-masked]
Cc: [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Saurabh,

Thanks.
Zhipeng

Colleagues,

g-

-----Original Message-----
From: ZhouZhipeng [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 13 October 2011 13:12
To: Watson,G,Grant,DMK5 R; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Grant,

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, October 13, 2011 6:34 PM
To: [email-masked]<mailto:[email-masked]>; ZhouZhipeng; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

g-

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Kevin J Ma
Sent: 13 October 2011 05:02
To: ZhouZhipeng; Ben Niven-Jenkins
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

thanx.

--  Kevin J. Ma

---

From: Alan Kavanagh <[email-masked]>
Date: Wed, 26 Oct 2011 09:37:02 -0400

Kevin/Ben

I know im late punting this out, but felt its important we clarify this in the use case document.

Isnt it more the case that the CP does a business agreement with a CDN provider to ensure he can deliver the content in a number of format and screen density types and if this CDN provider is unable to do so the CP would not do a business agreement with this CDN Provider in the first place. 

Similarly, today a lot of CP's provide one Video Source and while I agree with Ben that encoding is done outside the delivery node itself its typically part of the CDN eco-system from my point of view. Yes both models exist but then both should be captured in the use case document. This is important to convey another major benefit of CDN and CDN-I thus that CP delivers one high video source to the uCDN and that CDN is responsible for content delivery in a number of format and screen density types etc. Similarly and I believe Kevin Ma and other raised this at the Quebec IETF meeting in that CDN-I should cover supporting transcoding, the main advantage is see is that the uCDN delivers one high video source to the dCDN and that in turns does the transcoding instead of having to fetch the same file x number of times when it doesn't do the transcoding. I see this more so for Broadcast TV etc so imho its something that should be in the CDN-I scope and somehow conveyed in the appropriate docs.

Alan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kevin J Ma
Sent: October-11-11 12:04 PM
To: Ben Niven-Jenkins
Cc: ZhouZhipeng; [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Ben,

thanx.

--  Kevin J. Ma

> >  It is true that the CDN did not make any decision, the CP did, 
> > however,  the enforcement is based on the fact that those CDNs will 
> > not share  with each other and are physically separated.  With CDNI, 
> > if the uCDN  has access to all representations but the CP needs to 
> > enforce that  specific dCDNs only have access to subsets of 
> > representations (due to  content licensing restrictions), enforcing 
> > that probably requires  metadata to describe those delivery restrictions?
> 
> I'd like to understand these requirements better as I am aware of 
> Content Providers that choose to use different CDNs for different 
> representations based on business policy and I think that can be 
> solved at the business agreement level in the same way as dealing with 
> what delivery protocols or delivery footprint the Content Provider requires.
> 
> I am aware of licensing agreements that restrict what geographies 
> content can be delivered from and what geographies content can be delivered to.
> However, I've not heard of a licensing agreement that mandated that 
> some representations of a piece of content absolutely must be 
> delivered by a different CDN to other representations of the same content.
> 
> >> Behalf Of Ben Niven-Jenkins
> >> section 5.1  of the new WG-version. I think the concept of 
> >> resolution- based constraints, that was included in betrand-02, 
> >> should remain in
> some
> >> specific representation to be delivered, I think a use case in 
> >> which
> some
> >> the way you describe. They may only deliver to a subset of users 
> >> (and maybe by implication a subset of possible devices) for example 
> >> as a consequence of  them being a dedicated mobile CDN (as opposed 
> >> to an
> active
> >> decision they make).
> >>
> >> Let's look at how a content service is deployed. A Content Provider 
> >> has some content (let's say a video) that the Content Provider may 
> >> produce
> in
> >> may do that encoding themselves or outsource it (although that's 
> >> not relevant to the point I'm making).
> >>
> >> A User will connect to the Content Provider's "portal" (which may 
> >> be a
> web
> >> portal) will offer the User the content in one or more of the 
> >> available representations (e.g. by device type but how that 
> >> decision is made is purely up to the Content Provider). The User 
> >> selects a representation
> and
> >> the Content Provider offloads the delivery of that representation 
> >> to
> the
> >> the CDN to the User's client). The User then connects to the CDN 
> >> and requests the representation they have selected (from the choice 
> >> of representations offered to them by the Content Provider).
> >>
> >> content files on an upstream source (e.g. on-net storage or a 
> >> Content Provider's Origin server) it has no explicit knowledge of 
> >> what actual content that specific URI maps to or that it is one of 
> >> X possible representations of the same content.
> >>
> >> At no point has the CDN been involved in the selection or 
> >> restriction
> of
> >> can support) but I do not think that the specific representation of 
> >> the content will enter into the equation beyond those constraints.
> >>
> >> representations with resolutions below AxB" and the uCDN often will 
> >> not even know what the resolution or a particular representation is.
> >>
> >> What might happen is that a User on a particular network (or using 
> >> a particular client/device) connects to the Content Provider's 
> >> portal and
> is
> >> only offered a subset of the possible representations tailored (by 
> >> the Content Provider's policy implemented in the Content Provider's 
> >> portal) based on that User's Network/Client/Device. A dCDN may 
> >> subsequently be selected that can serve that Network/Client/Service 
> >> and that dCDN may
> only

---

From: Alan Kavanagh <[email-masked]>
Date: Wed, 26 Oct 2011 15:11:46 -0400

Hi Zhou

Slowly catching up on all these CDN-I emails :-)

I fully agree with your assertion here, I had the same puzzlement when reading the use cases and looking at the lat few "hundred plus" emails on this.

To me a core functionality of CDN's as Ben et.al has pointed out is to reduce cost, sending 1 stream as opposed to 10 streams is definitely a core requirement and a core use case for CDN-I too.

Somewhat orthogonal to the use cases, but a case I feel is missing from the current metadata drafts I have read is to define this case of supporting transcoding for CDN-I. It makes perfect sense that CDN-I must support this scenario so that CDN's leverage on cost reduction by supporting transcoding.

Alan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ZhouZhipeng
Sent: October-12-11 5:23 AM
To: Ben Niven-Jenkins
Cc: [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Hello Ben,

If your company's solution is to send 10 streams of different format of one content to CDN-Y; While CDN-X's solution is to send 1 stream to CDN-Y while CDN-Y may conduct some adaptation.

Br,
Zhipeng

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]]
Sent: Wednesday, October 12, 2011 12:19 AM
To: ZhouZhipeng
Cc: [email-masked]; [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

Ben

> and like to promote the DRM all around the world:) If the content is needed to be protected, generally you may know all the systems should be granted by the content owner.
> Registered office: 81 Newgate Street London EC1A 7AJ Registered in
> England no: 1800000
>
>
> Of Ben Niven-Jenkins
>> used in the same CDN coverage area.  The intent of this use case
>> needs to be clarified.  Perhaps the use case is trying to address the
>> Section 5.1.3 Content Encoding Restrictions  Need to clarify if we're
>> talking about the restrictions on the delivery of specific content or
>> the restrictions on the ability of a CDN to deliver specific content.
>> I certainly understand the case where a CSP will restrict the
>> distribution of content to a "managed path" if such content is HD
>> while allowing the content distribution via an un-managed path if
>> such content is SD (same could apply to encryption methods, delivery
>> methods, etc.).  On the contrary, the dCDN may have its own
>> restrictions of blocking the distribution of HD content while
>> DASH)  o second bullet makes sense where the dCDN doesn't want to
>> offer high bit-rate variants of the media  o third bullet make sense
>> if the policy addresses QoE but I don't think subscriber
>> rights/authorizations apply.
>>
>> relationship that extends the contract defined in (a) above) c. The
>> relationship between the User and dCDN (the recognition of right to
>> download predicated on (b) above) d. The relationship between the
>> User and CSP (the contract authorizing the user access to the
>> content)
>>
>> via either d-b or d-c.  As an example, the uCDN might use URL
>> appended tokens for authentication while dCDN might use URL appended
>> hashes.  The user doesn't want to know about the distinct methods,
>> but transparency is only afforded if the methods are interoperable
>> clearly defined when the delegation for content delivery is executed.

---

From: Alan Kavanagh <[email-masked]>
Date: Wed, 26 Oct 2011 15:33:15 -0400

Ben

Im assuming then based on your comments below are you suggesting we are going to have a number of versions of the CDN-I Metadata?

I sympathise with what you are pointing out below and do agree that there is some work to be done, but I still feel that content adaptation is to me a fundamental requirement to what collectively we should address in the CDN-I WG. I do agree with you that content adaptation is an optimization between CDN's but it's a very important one that I know Network Service Providers particularly require.

Alan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
Sent: October-12-11 1:13 PM
To: ZhouZhipeng
Cc: [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

> of one content to CDN-Y; While CDN-X's solution is to send 1 stream to CDN-Y while CDN-Y may conduct some adaptation.

Ben

>>> needs to be clarified.  Perhaps the use case is trying to address
>>> the scenario where a Nomadic User-A with an agreement allowing
>>> access to content from CSP-A via uCDN moves to a dCDN in a different
>>> region.  The dCDN is allowed to distribute the content of CSP-A to
>>> User-A; however, not other users in the region of the dCDN are
>>> allowed to retrieve the content unless they too have such an agreement.
>>>
>>> talking about the restrictions on the delivery of specific content
>>> or the restrictions on the ability of a CDN to deliver specific
>>> content.  I certainly understand the case where a CSP will restrict
>>> the distribution of content to a "managed path" if such content is
>>> HD while allowing the content distribution via an un-managed path if
>>> authorization granted in d-a is viable when the delivery is
>>> initiated via either d-b or d-c.  As an example, the uCDN might use
>>> URL appended tokens for authentication while dCDN might use URL
>>> appended hashes.  The user doesn't want to know about the distinct
>>> methods, but transparency is only afforded if the methods are
>>> interoperable clearly defined when the delegation for content
>>> delivery is executed.  Clearly, the choice of authentication method is determined by the respective CDN's.
>>>
>>> Scott
>>>

---

From: Mark de Jong <[email-masked]>
Date: Wed, 26 Oct 2011 21:02:20 +0100

Hi Alan,

As Ben stated the overall discussion right now is about delivery, not on adaptation. It is hard enough to get consensus on the delivery aspect already not to mention your requirement from content adaptation added to that, so I agree with Ben we should stick with the delivery aspect for the first specs. I can imagine this could be a discussion later on but please let us keep the scope of this be clean and transparent. It is of benefit of everyone to get the first specs as fast as possible. Thanks.

Met vriendelijke groet,
Kind regards,

Mark de Jong
International Business Developer
Jet-Stream BV

E-mail: [email-masked]
Office: +31 (0)50 5261820
Mobile: +31 (0)6 81108263
Fax: +31 (0)50 5264214

- Event: Meet us at Streaming Media Europe, 17-18 October, London, UK
- Event: Meet us at Online Video Strategies, 19 October, London, UK
- Event: Meet us at CDN World Summit, 25-28 October, London, UK
- News: Pre-request your Technology Whitepaper now and be the first to have it, check www.jet-stream.com
- News: Check http://www.jet-stream.com to download our 'Six Trends in CDNs' brochure

- Blog: www.jet-stream.com/blog/
- VideoExchange: www.vdo-x.net
- Streamzilla: www.streamzillacdn.com
- Corporate: www.jet-stream.com

---

From: Mark de Jong <[email-masked]>
Date: Wed, 26 Oct 2011 21:20:12 +0100

Hi Alan,

Met vriendelijke groet,
Kind regards,

Mark de Jong

---

From: Mark de Jong <[email-masked]>
Date: Wed, 26 Oct 2011 21:21:18 +0100

Hi Alan,

Met vriendelijke groet,
Kind regards,

Mark de Jong

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Wed, 26 Oct 2011 14:01:33 -0700

I also agree with Ben that content adaptation is an optimization that is
out of scope.  We have enough to do in the WG already.

Kent

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mark de Jong
Sent: Wednesday, October 26, 2011 1:21 PM
To: Alan Kavanagh
Cc: [email-masked]; ZhouZhipeng
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Hi Alan,

As Ben stated the overall discussion right now is about delivery, not on
adaptation. It is hard enough to get consensus on the delivery aspect
already not to mention your requirement from content adaptation added to
that, so I agree with Ben we should stick with the delivery aspect for
the first specs. I can imagine this could be a discussion later on but
please let us keep the scope of this be clean and transparent. It is of
benefit of everyone to get the first specs as fast as possible. Thanks.

Met vriendelijke groet,

Kind regards,

Mark de Jong

- News: Pre-request your Technology Whitepaper now and be the first to
have it, check www.jet-stream.com

- News: Check http://www.jet-stream.com to download our 'Six Trends in
CDNs' brochure

Ben

Im assuming then based on your comments below are you suggesting we are
going to have a number of versions of the CDN-I Metadata?

I sympathise with what you are pointing out below and do agree that
there is some work to be done, but I still feel that content adaptation
is to me a fundamental requirement to what collectively we should
address in the CDN-I WG. I do agree with you that content adaptation is
an optimization between CDN's but it's a very important one that I know
Network Service Providers particularly require.

Alan

-----Original Message-----

Zhipeng,

Hello Ben,

	The UE may select the content format on the CP web. After that
the user only desires to get his selected content.

by the user.

	The CP may create a special format as required by the user and
ask the CDN to deliver to user.

	While CP may give a HD format content to uCDN and the dCDN may
then transform to the format as the user select.

Lots of things may be possible to do and CDN providers offer many
additional services on top of the "core" service of content delivery.
However, our objective (based on my interpretation of the CDNI charter)
is to focus on what is necessary to interconnect CDNs to deliver content
from a CSP to an End User that is targeted and deployable within a short
time frame (18-24 months).

Content transformation/adaptation is not an essential requirement in
order to achieve that aim (we can deliver content from CSPs to End Users
via multiple CDNs without needing or requiring any CDN supports content
adaptation).

In my opinion we have enough work to do already without trying to expand
the scope of our work to include additional requirements that do not
help us address our core objectives as laid out in the CDNI charter.

In this case, it is nothing related to how the user select formats on CP
website.

	So, it is the CP and user to decide the content format not the
CDN(your assert is not correct and seems you take that assert as your
base for the discussion).

	As for "the core CDN functionality offered by CDNs today", I
have ever raised an email before that your company's webpage has claimed
supporting media transformation and multi-screen service.

	Perhaps, I like asking you list some features that you feel are
the core functionalities by existing main stream CDNs. Thus we may
compare and take deep look.

media formats.

located in France.

provider(CDN-Y).

	If your company's solution is to send 10 streams of different
format

	of one content to CDN-Y; While CDN-X's solution is to send 1
stream to CDN-Y while CDN-Y may conduct some adaptation.

	Comparing these two solutions, for your company and CDN-X,
absolutely the cost of CDN-X is much lower.

	For CDN-Y, in solution-1, it should receive/forward 10 streams ;
while in solution-2, it should only receive 1 stream but need to take
transformation to output 10 streams.

	Which solution is more competitive. it is Solution 1, right.
Remember the price from BBC is same to both your company and CDN-X or
BBC would select one CDN provider with the lower price.

	If a CDN provider may not get the contract from CP, how it may
say it is not a core functionality.

What you are describing is a possible optimization that a particular CDN
may wish to implement not a core functionality required to enable
content delivery between interconnected CDNs. I can think of many
optimizations that a CDN could implement to differentiate their service
but the internal workings of an individual CDN are out of scope of our
charter.

So to repeat my position for a final time: Content adaptation is not a
core function required to enable content delivery between interconnected
CDNs and therefore given the workload we already have to specify
solutions that do address the core functionality required to
interconnect CDNs I do not think we should be trying to add more work
into that workload as it will only distract us from achieving our goal
of producing deployable solutions within the timeframe we are being told
by operators they needs solutions within.

Ben

	Br,

	Zhipeng

	 

	-----Original Message-----

	To: ZhouZhipeng

	Zhipeng,

		Ben and Philip,

		Ben,

		I feel what we are now discussing is what is the "core"
function of CDN.

		As you say, CDN is used to deliver content. That is
absolutely correct that the delivery capability is the core requirement
for CDN system.

		While CDN is used to provide the content delivery
service.

		What means service. It should include "time" "location"
and "media type", etc. These features are all the core feature for a
service.

		If we only concern "delivering one data block", I am not
sure whether the issues such as "logging" "geographic constraint" are
the core of CDN.

		For "without explicit knowledge of what that content
actually is ", I am not sure whether the wording is accurate since
generally a CDN may claim it support different medias.

		By this opportunity, I like to share a use case: a call
from a GSM phone to a PSTN telephone, the voice stream should be
transformed from GSM voice to G.711.

		For the user, he does not need to know what type of data
has been transferred, but the operator has done some work to
interconnect two systems, right.

		I like to know whether you may accept that my use case
is similar to this case above.

	I don't think your use case is similar to the analogy of mobile
networks being interconnected to PSTN networks. In the case of content
delivery the negotiation is done between the User/Client and the Content
Provider and the CDN is just used to execute/perform the delivery that
has been negotiated. The CDN is not involved in the decision making of
what representations the Content Provider decides to offer to the
User/Client or in what representations the User/Client decides to
request.

		As for you said selecting media by the "portal", you may
see the way " uCDN delivers multiple media streams to dCDN" is not good
than "uCDN delivers one media stream to dCDN and dCDN takes some
adaptation to support multiple media types".

	Now what you're talking about is an optimisation, not a core
function required to actually deliver the content (and report, bill,
etc. for that delivery).

	My position is that we should focus on how to enable the
interconnection of the core CDN functionality offered by CDNs today
(which is also my interpretation of the scope of the CDNI working group
as expressed in its charter) because doing so is a significant piece of
work in itself. Let's not start trying to add in additional
functionality beyond what the majority of CDNs support today as that
will just delay us getting usable specifications into the market in a
timely fashion IMO.

	Ben

		A good question is "security" since I have done six
years on the DRM

		and like to promote the DRM all around the world:) If
the content is needed to be protected, generally you may know all the
systems should be granted by the content owner.

		Here I also like to clarify that not only the media
itself but the information related to service itself (such as the
geographic constraint) should be protected also.

		Philip,

		Thank you that you feel Content Adaption is an issue for
"Requirements" but I do not know why it is not for Use case.

		I like to clarify to U that it is important for you
operator since it may save investment if the system may support
different services.

		For us vendor, we are happy operator may install a
system for the mobile service and another system for the FBB service.

		But the reality is all operators ask us to provide a
system that may support different service systems.

		Frankly, Ben and Philip, I remember I have explained
somewhere that to implement this is rather simple .

		At least the Use case and Requirement are informational
to be referred in future work. So I do really feel you may accept it.

		Of course I like to respond your more concern and
comments.

		Thanks.

		Zhipeng

		-----Original Message-----

		From: [email-masked]
[mailto:[email-masked]]

		Cc: [email-masked]

		Subject: RE: [CDNi] I-D Action:
draft-ietf-cdni-use-cases-00.txt

		Ben, Zhipeng, all,

		I think that Content Adaptation is more an issue for the
Requirements doc than for the Use cases draft.

		The key question is whether we want the CDNI interfaces
to be able to cope with a scenario where (say) HD/SD conversion is done
in the dCDN & to signal about this.

		I think that coping with this scenario is a second order
requirement, ie we should not worry about it in the initial
standards-track work. I don't know, did we ever decide whether the Use
cases doc is restricted to "initial" scenarios, or whether it's
all-encompassing, ie covering "future" scenarios as well?

		Scott,

		Reading some of your examples, they seem to be valid
even if content adaptation (HD/SD) is out of scope.

		- a dCDN might for some reason be unwilling to
distribute HD?

		- a CSP might want to make sure the dCDN can use HLS
encapsulation?

		But these sorts of examples seem to be static policy
things (to do

		with the capabilities & preferences of the CDNs & CSP),
rather than

		metadata associated with a particular piece of content.
In the

		discussion so far, I think negotiation about static
policy stuff is

		rather out of scope(?)

		On security considerations, an interesting question is
whether trust is transitive. Don't think it need be - just because CSP
trusts uCDN, and uCDN trusts dCDN doesn't mean that the CSP
automatically trusts the dCDN. However, i suspect this can get
arbitrarily complex - so one possibility is to say that we will only
handle cases where the trust is transitive.

		Best wishes

		phil

		Philip Eardley

		This email contains BT information, which may be
privileged or confidential. It's meant only for the individual(s) or
entity named above. If you're not the intended recipient, note that
disclosing, copying, distributing or using this information is
prohibited. If you've received this email in error, please let me know
immediately on the email address above. Thank you. We monitor our email
system, and may record your emails.

Registered in

		England no: 1800000

		-----Original Message-----

		From: [email-masked]
[mailto:[email-masked]] On Behalf

		Of Ben Niven-Jenkins

		To: ZhouZhipeng

		Cc: [email-masked]

		Subject: Re: [CDNi] I-D Action:
draft-ietf-cdni-use-cases-00.txt

		Colleagues,

		IMO Section 5.1.3 should be removed from the Use Cases
draft. Content Adaptation (i.e. taking in a content item in one format
and transforming it to another format or representation) is not a "core"
function of a CDN which typically delivers the content that is requested
without explicit knowledge of what that content actually is.

		Let's not forget that in building an end to end content
service the CDN is only one component and is the component tasked with
executing the delivery of a specific representation (version/copy/format
etc.) of the selected content not the component tasked with deciding (or
applying policy) on which version/copy/representation of content should
be delivered.

		The decision as to which version/copy/representation to
offer and allow to be delivered to a given device/user is implemented
outside of the CDN (e.g. by the "portal" where the user first makes
their content selection prior to the CDN becoming involved in the
delivery of the selected content).

		Ben

			Following Scott's comments on section 5.1.3, I
feel Scott's description on the use case of HD and SD is not exactly
correct.

			If one movie has two formats of HD and SD, then
we have two content with different identifier. In DRM scope, the basic
unit is a content copy.

			Here the first bullet "a subset of encodings
deliverable to specific devices," has listed the case of content
adaptation.

			In last month, I have contacted the Authors of
this document and taken some email exchanges with Grant and Philip (BT).

			I have shown BT with some information that I
know in this case and area to explain the content flexibility is
currently a basic requirement for CDN service and related negotiation is
needed in the CDN interconnection.

			Meanwhile, I should also invite you in this
group raising your comments or questions on this case since I hope my
use case may be incorporated in the use case draft.

			If you have any more question or comments, pls
share in this thread.

			Thanks.

			Zhipeng

			 

			-----Original Message-----

			To: [email-masked]

			Subject: Re: [CDNi] I-D Action:
draft-ietf-cdni-use-cases-00.txt

			This description falls under the category of
Geographic Extension

			yet the third paragraph states the case where a
different device is

			used in the same CDN coverage area.  The intent
of this use case

			needs to be clarified.  Perhaps the use case is
trying to address

			the scenario where a Nomadic User-A with an
agreement allowing

			access to content from CSP-A via uCDN moves to a
dCDN in a different

			region.  The dCDN is allowed to distribute the
content of CSP-A to

			User-A; however, not other users in the region
of the dCDN are

			allowed to retrieve the content unless they too
have such an agreement.

			Section 5.1.3 Content Encoding Restrictions Need
to clarify if we're

			talking about the restrictions on the delivery
of specific content

			or the restrictions on the ability of a CDN to
deliver specific

			content.  I certainly understand the case where
a CSP will restrict

			the distribution of content to a "managed path"
if such content is

			HD while allowing the content distribution via
an un-managed path if

			such content is SD (same could apply to
encryption methods, delivery

			methods, etc.).  On the contrary, the dCDN may
have its own

			restrictions of blocking the distribution of HD
content while

			o first bullet makes sense if the dCDN can
perform a subset of

			encapsulations for a reference set of media
(e.g. HLS, HSS, but not

			DASH) o second bullet makes sense where the dCDN
doesn't want to

			offer high bit-rate variants of the media o
third bullet make sense

			if the policy addresses QoE but I don't think
subscriber

			Aside from the security considerations WITHIN
the uCDN and dCDN, I

			a. The relationship between the CSP and the uCDN
(the principle contract

			b. The relationship between the uCDN and dCDN
(the transitive trust

			relationship that extends the contract defined
in (a) above) c. The

			relationship between the User and dCDN (the
recognition of right to

			download predicated on (b) above) d. The
relationship between the

			User and CSP (the contract authorizing the user
access to the

			content)

			The user is not interested in the a-b nor the
b-c relationship. The

			user is only interested in the transparency and
interoperability of

			the security relationship between d-b or d-c to
the point that the

			authorization granted in d-a is viable when the
delivery is

			initiated via either d-b or d-c.  As an example,
the uCDN might use

			URL appended tokens for authentication while
dCDN might use URL

			appended hashes.  The user doesn't want to know
about the distinct

			methods, but transparency is only afforded if
the methods are

			interoperable clearly defined when the
delegation for content

			delivery is executed.  Clearly, the choice of
authentication method is determined by the respective CDN's.

			Scott

			CDNi mailing list

			[email-masked]

		CDNi mailing list

		[email-masked]

---

From: Alan Kavanagh <[email-masked]>
Date: Wed, 26 Oct 2011 17:03:45 -0400

So are we defining a limited set of use cases or should we ensure that use cases at the very least ensure that the realistic use cases both deployed today and ones planed are captured in the use cases document?

Alan

________________________________
From: Kent Leung (kleung) [mailto:[email-masked]]
Sent: October-26-11 5:02 PM
To: Mark de Jong; Alan Kavanagh
Cc: [email-masked]; ZhouZhipeng
Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

I also agree with Ben that content adaptation is an optimization that is out of scope.  We have enough to do in the WG already.

Kent

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark de Jong
Sent: Wednesday, October 26, 2011 1:21 PM
To: Alan Kavanagh
Cc: [email-masked]; ZhouZhipeng
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Hi Alan,

Met vriendelijke groet,
Kind regards,

Mark de Jong

E-mail: [email-masked]<mailto:[email-masked]>
Office: +31 (0)50 5261820
Mobile: +31 (0)6 81108263
Fax: +31 (0)50 5264214

- News: Pre-request your Technology Whitepaper now and be the first to have it, check www.jet-stream.com<http://www.jet-stream.com>

- Blog: www.jet-stream.com/blog/<http://www.jet-stream.com/blog/>
- VideoExchange: www.vdo-x.net<http://www.vdo-x.net>
- Streamzilla: www.streamzillacdn.com<http://www.streamzillacdn.com>
- Corporate: www.jet-stream.com<http://www.jet-stream.com>

Ben

Alan

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
Sent: October-12-11 1:13 PM
To: ZhouZhipeng
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

Hello Ben,

Ben

Br,
Zhipeng

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]]
Sent: Wednesday, October 12, 2011 12:19 AM
To: ZhouZhipeng
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

Ben and Philip,

Ben,

Ben

Philip,

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Monday, October 10, 2011 11:22 PM
To: [email-masked]<mailto:[email-masked]>; ZhouZhipeng
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Ben, Zhipeng, all,

Scott,

Best wishes
phil

Philip Eardley

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf
Of Ben Niven-Jenkins
Sent: 10 October 2011 12:04
To: ZhouZhipeng
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Colleagues,

Ben

-----Original Message-----
From: Scott Wainner [mailto:[email-masked]]
Sent: Friday, September 30, 2011 8:02 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Scott

---

From: ZhouZhipeng <[email-masked]>
Date: Thu, 27 Oct 2011 07:45:36 +0000

Hello Mark,
Nice to meet you on line.
In your company's website, I just find some information that addresses " Vodafone subscribers complained about video performance."
See:
http://www.jet-stream.nl/search/?search=transcoding

Dear all in this group,
In last few days, except the public email discussions I have contacted with some people and discussed with my own colleagues of all details on this issue.
First, although the market requirement for it is very important, I feel I'd better show up more information on the procedure involved. I have explained many times that to support content adaptation is rather simple while the wording is not enough.
I am busy making some contributions on this and plan to upload to ETSI meeting and IETF CDNI.
By these work  I feel the people may catch a whole view on this issue.
Second, for that functionality, in implementation, if some entity does not choose to support it, it may be ok. Since it may be negotiated between two CDNs.
If dCDN does not support that, it may be the uCDN responsible to complete the transcoding and deliver the content of multiple formats and rates to dCDN.
Third, although CDNI is a new architecture, while the content operating has been existed for years. As I know the content from USA to the downstream operator is transferred on one copy and the downstream operator will handle the transcoding.

Perhaps, the content adaptation is more on the mobile operating. But I feel currently most operator will be a all service operator. And for the CDN providers, it may be better to support all kinds of service.
Besides, I like say that the technology on this topic has been for many years and has been rather mature, even some items in ietf such as rfc3507 icap. So from the technique point of view, it is a nature action to be involved in CDN interconnection.
Thanks.
Zhipeng

From: Mark de Jong [mailto:[email-masked]]
Sent: Thursday, October 27, 2011 4:21 AM
To: Alan Kavanagh
Cc: Ben Niven-Jenkins; ZhouZhipeng; [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Hi Alan,

Met vriendelijke groet,
Kind regards,

Mark de Jong

Ben

Alan

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
Sent: October-12-11 1:13 PM
To: ZhouZhipeng
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

Hello Ben,

Ben

Br,
Zhipeng

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]]
Sent: Wednesday, October 12, 2011 12:19 AM
To: ZhouZhipeng
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

Ben and Philip,

Ben,

Ben

Philip,

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Monday, October 10, 2011 11:22 PM
To: [email-masked]<mailto:[email-masked]>; ZhouZhipeng
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Ben, Zhipeng, all,

Scott,

Best wishes
phil

Philip Eardley

-----Original Message-----

Colleagues,

Ben

-----Original Message-----
From: Scott Wainner [mailto:[email-masked]]
Sent: Friday, September 30, 2011 8:02 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Scott

---

From: Mark de Jong <[email-masked]>
Date: Thu, 27 Oct 2011 08:56:57 +0100

Hi Zhipeng,

As said: I agree this can be a discussion later and be added to the requirements in a future release. However: in respect to the speed of the process and as the delivery part is the biggest majority of the business for interconnection (please note: interconnection is a business driver, not technology driver) the focus should be delivery. 

Met vriendelijke groet,
Kind regards,

Mark de Jong

On 27, Oct,2011, at 8:45 AM, ZhouZhipeng wrote:

> In your company’s website, I just find some information that addresses “ Vodafone subscribers complained about video performance.”
> See:
> First, although the market requirement for it is very important, I feel I’d better show up more information on the procedure involved. I have explained many times that to support content adaptation is rather simple while the wording is not enough.

---

From: ZhouZhipeng <[email-masked]>
Date: Thu, 27 Oct 2011 08:11:08 +0000

Hi Mark,
I fully agree that it is a business driver. So I emphasized many times that the content adaptation is a urgent and important market demand.
In fact I am not advertising for some http streaming products, but the variable streaming solution is the real market requirement.
Absolutely CDN is for delivery but it should be also clarified here it is "content delivery" not only "bitrate delivery".
As you see the operator may develop subscribers only when it may provide enough functionality and quality.

Thanks.
Zhipeng

From: Mark de Jong [mailto:[email-masked]]
Sent: Thursday, October 27, 2011 3:57 PM
To: ZhouZhipeng
Cc: Alan Kavanagh; Ben Niven-Jenkins; [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Hi Zhipeng,

Met vriendelijke groet,
Kind regards,

Mark de Jong

Hello Mark,

Dear all in this group,

From: Mark de Jong [mailto:[email-masked]]
Sent: Thursday, October 27, 2011 4:21 AM
To: Alan Kavanagh
Cc: Ben Niven-Jenkins; ZhouZhipeng; [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Hi Alan,

Met vriendelijke groet,
Kind regards,

Mark de Jong

Ben

Alan

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
Sent: October-12-11 1:13 PM
To: ZhouZhipeng
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

Hello Ben,

Ben

Br,
Zhipeng

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]]
Sent: Wednesday, October 12, 2011 12:19 AM
To: ZhouZhipeng
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

Ben and Philip,

Ben,

Ben

Philip,

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Monday, October 10, 2011 11:22 PM
To: [email-masked]<mailto:[email-masked]>; ZhouZhipeng
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Ben, Zhipeng, all,

Scott,

Best wishes
phil

Philip Eardley

-----Original Message-----

Colleagues,

Ben

-----Original Message-----
From: Scott Wainner [mailto:[email-masked]]
Sent: Friday, September 30, 2011 8:02 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Scott

---

From: Mark de Jong <[email-masked]>
Date: Thu, 27 Oct 2011 10:40:29 +0100

Hi Zhipeng,

It is a slowly growing demand but still very little in terms of revenue/demand. The majority of the business nowadays and in respect to interconnection will be about delivery on the short/mid-term. We really don't get much request for content adaptation on our own CDN-service or as a requirement for our CDN-software. So I disagree that adaptation is an important market demand at this moment, especially on interconnection. I think I have made my point that we stick with delivery for the reasons I already mentioned and I think the group agrees with that too. Again: I'm not excluding the option for the future. So please: let us stop this discussion and go forward on the actual work to be done: standards. :)

Met vriendelijke groet,
Kind regards,

Mark de Jong

On 27, Oct,2011, at 9:11 AM, ZhouZhipeng wrote:

> Absolutely CDN is for delivery but it should be also clarified here it is “content delivery” not only “bitrate delivery”.

---

From: "Woundy, Richard" <[email-masked]>
Date: Thu, 27 Oct 2011 11:22:58 +0000

>In your company’s website, I just find some information

I have to step in as co-chair here.

The goal of this WG is not to align vendor product roadmaps, or to equalize all vendor offerings, or to specify the entire CDNI ecosystem. The goal of this WG is to enable the interconnection and interoperation of two or more CDNs, within the bounds of the CDNI wg charter.

It is OK to have a discussion about whether content adaptation needs to be performed by the dCDN, since that decision impacts the uCDN-dCDN interface. So let's find a productive way to discuss this on the mailing list, and to close the discussion by IETF 82 (if not sooner).

Can someone describe real-life examples where downstream CDN (or edge cache-based) content adaptation is needed today in a production environment, or shortly? Not merely a feature in a vendor's product materials?

Speaking as an individual, I can find a lot of examples where downstream content adaptation is not needed, and any adaptation is really part of the CP - uCDN interface (which is out of the scope of our charter).

-- Rich

From: ZhouZhipeng [mailto:[email-masked]]
Sent: Thursday, October 27, 2011 03:45 AM
To: Mark de Jong <[email-masked]>; Alan Kavanagh <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Hello Mark,

Dear all in this group,

Hi Alan,

Met vriendelijke groet,
Kind regards,

Mark de Jong

Ben

Alan

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
Sent: October-12-11 1:13 PM
To: ZhouZhipeng
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

Hello Ben,

Ben

Br,
Zhipeng

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]]
Sent: Wednesday, October 12, 2011 12:19 AM
To: ZhouZhipeng
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

Ben and Philip,

Ben,

Ben

Philip,

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Monday, October 10, 2011 11:22 PM
To: [email-masked]<mailto:[email-masked]>; ZhouZhipeng
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Ben, Zhipeng, all,

Scott,

Best wishes
phil

Philip Eardley

-----Original Message-----

Colleagues,

Ben

-----Original Message-----
From: Scott Wainner [mailto:[email-masked]]
Sent: Friday, September 30, 2011 8:02 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Scott

---

From: "Woundy, Richard" <[email-masked]>
Date: Thu, 27 Oct 2011 13:01:21 +0000

> To me a core functionality of CDN's as Ben et.al has pointed out is to reduce cost, sending 1 stream as opposed to 10 streams is definitely a core requirement and a core use case for CDN-I too.

Maybe. The counter-argument is, do I have to spend much more on surrogates / edge nodes to enable transcoding + fragmentation + encryption? Does that additional cost offset the incremental network savings?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alan Kavanagh
Sent: Wednesday, October 26, 2011 3:12 PM
To: ZhouZhipeng; Ben Niven-Jenkins
Cc: [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Hi Zhou

Alan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ZhouZhipeng
Sent: October-12-11 5:23 AM
To: Ben Niven-Jenkins
Cc: [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Hello Ben,

Br,
Zhipeng

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]]
Sent: Wednesday, October 12, 2011 12:19 AM
To: ZhouZhipeng
Cc: [email-masked]; [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

Ben

---

From: Alan Kavanagh <[email-masked]>
Date: Thu, 27 Oct 2011 09:09:56 -0400

Hi Mark

Alan

Sent: October-26-11 4:21 PM

Hi Alan,

Met vriendelijke groet,
Kind regards,

Mark de Jong

Ben

Alan

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
Sent: October-12-11 1:13 PM
To: ZhouZhipeng
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

Hello Ben,

Ben

Br,
Zhipeng

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]]
Sent: Wednesday, October 12, 2011 12:19 AM
To: ZhouZhipeng
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

Ben and Philip,

Ben,

Ben

Philip,

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Monday, October 10, 2011 11:22 PM
To: [email-masked]<mailto:[email-masked]>; ZhouZhipeng
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Ben, Zhipeng, all,

Scott,

Best wishes
phil

Philip Eardley

-----Original Message-----

Colleagues,

Ben

-----Original Message-----
From: Scott Wainner [mailto:[email-masked]]
Sent: Friday, September 30, 2011 8:02 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Scott

---

From: ZhouZhipeng <[email-masked]>
Date: Fri, 28 Oct 2011 09:25:11 +0000

Dear all,
In these days I am busy making a summary analysis on this topic. As Richard’s request, I like to show my information although perhaps not complete right now.

1)     I have done some work to collect different company’s requirements and opinions on this functionality.

One, I feel most of us have already been aware of the service of content adaptation, and I also sent an email yesterday that Vodaphone now is requiring the solution to enhance the performance of its mobile video service.

Second, here is an article about CISCO : “Cisco urges mobile operators to add value to CDN services” http://www.totaltele.com/view.aspx?ID=468705

Besides, I have checked many CDN company’s websites. Many claim to support transcoding while some may not.

2)     For the wording “content adaptation”, it should be clarified here that it may be two kinds.

One is only the transformation of encapsulation format. For example the H.264 stream is encapsulated in APPLE and Adobe format respectively.

I know that Comcast has a project that needs to pick the H.264 media from the TS stream and then encapsulated them into different formats(APPLE,Adobe…) to different devices.

For this kind of transformation, the computing cost is very very low and may be nearly neglected.

The other is to transcoding.  For example to support different bitrates.  Since encoder is a high value facility, we should compare the capital cost of encoder and transport cost.

Just take a simple model: content is delivered from Node A to Node B.

There are two solutions:

1)     A have the transcoder and deliver multi-format content to B

2)     B have the transcoder; A only delivers one format content to B and B would transcode.

From whole system point of view, either A or B would transcode while the bandwidth would be saved in solution B. Hence solution B is better.

Now provided the bandwidth is paid by B and B should decide whether to install transcoder.

(Richard has said to set transcoder in each edge server)

If the cost of renting bandwidth (for a few months) is more expensive than the price of transcoder supporting the same bandwidth, it would be better to put the transcoder at the receiver Node B.

In fact I have investigated this issue for much time. While in different area the price of bandwidth may be different.  And the transport burden between two distant places or over a bad nature environment would be much higher.

Here the price in USA may be referred as: http://smallbusiness.verizon.com/products/internet/hsi/overview.aspx#plans.

In Verizon, the package for 10-15mbps is $90 per month (I feel the bandwidth quality for business would be guaranteed). I query that the bandwidth price in China may be 50% higher.

I do not know how much the price will be for the bandwidth from Amsterdam to Paris (cross country in the same continent).  But I feel the price from NewYork to Paris would absolutely be very high.  As for the Encoder, it also varies. Perhaps the price in China will be higher than in USA. And in fact the price of bandwidth and encoder depends mostly on the concrete business items. For example the price to Huawei may be lower than the public price.

By my current evaluation in China it is better using the transcoder than renting multiple times broadband.

Some people have told me that for the operator himself probably the bandwidth cost would be very low in the internal capital counting. But for the independent CDN, it may another thing.

So, my suggestion is to let different ways co-exist. I have announced that to let two sides negotiate whether to assign dCDN for the content adaptation.

In fact, from CP to CDN,  there are the real businesses that either let CP to provide multi-format content or let the CDN to receive one format and complete the transformation, depending on the concrete business.

By the same logic, form uCDN to dCDN, it may be either the uCDN to provide multi-format content or the dCDN to receive one format content and then complete the transformation.

Currently there is not the real CDN-CDN connection, hence we are basing our knowledge on the related solution to make our solutions.

3)     As for the procedure of content adaptation, I just draft a diagram as below:

You may see the solution is rather clear and the metadata needed would be clear also.

Dear,

By my analysis above, I kindly invite your ideas whether it may be an applicable and simple part in the CDNI item, provided that the solution is open to the types of content adaptation and may be optionally implemented in the real solutions/business. I feel for those operators that need such functionality it would be very good while it does not impact others that do not implement it.

Thanks.

Zhipeng

From: Woundy, Richard [mailto:[email-masked]]
Sent: Thursday, October 27, 2011 7:23 PM
To: ZhouZhipeng; [email-masked]'; [email-masked]'
Cc: [email-masked]'; Woundy, Richard
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

-- Rich

Hello Mark,

Dear all in this group,

Hi Alan,

Met vriendelijke groet,
Kind regards,

Mark de Jong

Ben

Alan

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
Sent: October-12-11 1:13 PM
To: ZhouZhipeng
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

Hello Ben,

Ben

Br,
Zhipeng

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]]
Sent: Wednesday, October 12, 2011 12:19 AM
To: ZhouZhipeng
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

Ben and Philip,

Ben,

Ben

Philip,

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Monday, October 10, 2011 11:22 PM
To: [email-masked]<mailto:[email-masked]>; ZhouZhipeng
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Ben, Zhipeng, all,

Scott,

Best wishes
phil

Philip Eardley

-----Original Message-----

Colleagues,

Ben

-----Original Message-----
From: Scott Wainner [mailto:[email-masked]]
Sent: Friday, September 30, 2011 8:02 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Scott

---

From: Francois Le Faucheur <[email-masked]>
Date: Fri, 28 Oct 2011 15:46:01 +0200

Hi again Zhipeng,

There is one other point I should have brought up in my previous message:

The question is not so much whether there are benefits to allowing content adaptation for some environments, nor whether one particular individual could conceive an approach for content adaptation that suits him. The question here is rather whether it is justified for the Working Group to focus energy on that problem right now in order to develop a consensus-based approach that suits the community as a whole, while we don't even have the base solution in place.

You have made it clear that you feel the WG should indeed dedicate energy on that problem right away and explained your rationale. Thank you. Others have also expressed their opinions.

Cheers

Francois

On 28 Oct 2011, at 11:25, ZhouZhipeng wrote:

Dear all,

There are two solutions:

Dear,

Thanks.

Zhipeng

-- Rich

Hello Mark,

See:

Dear all in this group,

Thanks.

Zhipeng

Hi Alan,

Met vriendelijke groet,

Kind regards,

Mark de Jong

Ben

Alan

-----Original Message-----

Zhipeng,

Hello Ben,

Ben

Br,

Zhipeng

-----Original Message-----

To: ZhouZhipeng

Zhipeng,

Ben and Philip,

Ben,

Ben

Philip,

Thanks.

Zhipeng

-----Original Message-----

Cc: [email-masked]

Ben, Zhipeng, all,

Scott,

rather out of scope(?)

Best wishes

phil

Philip Eardley

England no: 1800000

-----Original Message-----

Of Ben Niven-Jenkins

To: ZhouZhipeng

Cc: [email-masked]

Colleagues,

Ben

Thanks.

Zhipeng

-----Original Message-----

To: [email-masked]

content)

Scott

CDNi mailing list

[email-masked]

CDNi mailing list

[email-masked]

---

From: Francois Le Faucheur <[email-masked]>
Date: Fri, 28 Oct 2011 15:49:34 +0200

Hi again Zhipeng,

Cheers

Francois

---

From: "Theodore Zahariadis" <[email-masked]>
Date: Sun, 30 Oct 2011 13:28:35 +0200

Dear all,

I think that a good approach would be to proceed in cdni-use cases to ensure
realistic/short-term use cases and then proceed to the advanced use cases
that the Future Media Networks (FMN) cluster of projects have submitted
under the cdni-advanced-use-cases ID.

Best Regards,

Theodore

From: Alan Kavanagh [mailto:[email-masked]] 
Sent: Thursday, October 27, 2011 12:04 AM
To: Kent Leung (kleung); Mark de Jong
Cc: [email-masked]; ZhouZhipeng
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

So are we defining a limited set of use cases or should we ensure that use
cases at the very least ensure that the realistic use cases both deployed
today and ones planed are captured in the use cases document? 

Alan

  _____  

I also agree with Ben that content adaptation is an optimization that is out
of scope.  We have enough to do in the WG already.

Kent

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark
de Jong
Sent: Wednesday, October 26, 2011 1:21 PM
To: Alan Kavanagh
Cc: [email-masked]; ZhouZhipeng
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Hi Alan,

As Ben stated the overall discussion right now is about delivery, not on
adaptation. It is hard enough to get consensus on the delivery aspect
already not to mention your requirement from content adaptation added to
that, so I agree with Ben we should stick with the delivery aspect for the
first specs. I can imagine this could be a discussion later on but please
let us keep the scope of this be clean and transparent. It is of benefit of
everyone to get the first specs as fast as possible. Thanks.

Met vriendelijke groet,

Kind regards,

Mark de Jong

- News: Pre-request your Technology Whitepaper now and be the first to have
it, check www.jet-stream.com

- News: Check http://www.jet-stream.com to download our 'Six Trends in CDNs'
brochure

Ben

I sympathise with what you are pointing out below and do agree that there is
some work to be done, but I still feel that content adaptation is to me a
fundamental requirement to what collectively we should address in the CDN-I
WG. I do agree with you that content adaptation is an optimization between
CDN's but it's a very important one that I know Network Service Providers
particularly require.

Alan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben
Niven-Jenkins
Sent: October-12-11 1:13 PM
To: ZhouZhipeng
Cc: [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

Hello Ben,

The UE may select the content format on the CP web. After that the user only
desires to get his selected content.

The CP may create a special format as required by the user and ask the CDN
to deliver to user.

Lots of things may be possible to do and CDN providers offer many additional
services on top of the "core" service of content delivery. However, our
objective (based on my interpretation of the CDNI charter) is to focus on
what is necessary to interconnect CDNs to deliver content from a CSP to an
End User that is targeted and deployable within a short time frame (18-24
months).

In my opinion we have enough work to do already without trying to expand the
scope of our work to include additional requirements that do not help us
address our core objectives as laid out in the CDNI charter.

I think the core functionality maps pretty well to the CDNI interfaces,
namely: Request Routing, Metadata configuration, log production and control
plus content acquisition and content delivery.

Given currently BBC recruits CDN providers that may support 10 media
formats.

One candidate is your company, another is CDN-X. The users are located in
France.

of one content to CDN-Y; While CDN-X's solution is to send 1 stream to CDN-Y
while CDN-Y may conduct some adaptation.

Comparing these two solutions, for your company and CDN-X, absolutely the
cost of CDN-X is much lower.

For CDN-Y, in solution-1, it should receive/forward 10 streams ; while in
solution-2, it should only receive 1 stream but need to take transformation
to output 10 streams.

Which solution is more competitive. it is Solution 1, right. Remember the
price from BBC is same to both your company and CDN-X or BBC would select
one CDN provider with the lower price.

If a CDN provider may not get the contract from CP, how it may say it is not
a core functionality.

What you are describing is a possible optimization that a particular CDN may
wish to implement not a core functionality required to enable content
delivery between interconnected CDNs. I can think of many optimizations that
a CDN could implement to differentiate their service but the internal
workings of an individual CDN are out of scope of our charter.

So to repeat my position for a final time: Content adaptation is not a core
function required to enable content delivery between interconnected CDNs and
therefore given the workload we already have to specify solutions that do
address the core functionality required to interconnect CDNs I do not think
we should be trying to add more work into that workload as it will only
distract us from achieving our goal of producing deployable solutions within
the timeframe we are being told by operators they needs solutions within.

Ben

Back to the case of GSM/G.711, it just when concerning the interconnection,
the transformation should at once be solved. Otherwise the interconnection
may not be operated.

Br,

Zhipeng

 

-----Original Message-----

To: ZhouZhipeng

Zhipeng,

Ben and Philip,

Ben,

As you say, CDN is used to deliver content. That is absolutely correct that
the delivery capability is the core requirement for CDN system.

What means service. It should include "time" "location" and "media type",
etc. These features are all the core feature for a service.

If we only concern "delivering one data block", I am not sure whether the
issues such as "logging" "geographic constraint" are the core of CDN.

For "without explicit knowledge of what that content actually is ", I am not
sure whether the wording is accurate since generally a CDN may claim it
support different medias.

By this opportunity, I like to share a use case: a call from a GSM phone to
a PSTN telephone, the voice stream should be transformed from GSM voice to
G.711.

I like to know whether you may accept that my use case is similar to this
case above.

I don't think your use case is similar to the analogy of mobile networks
being interconnected to PSTN networks. In the case of content delivery the
negotiation is done between the User/Client and the Content Provider and the
CDN is just used to execute/perform the delivery that has been negotiated.
The CDN is not involved in the decision making of what representations the
Content Provider decides to offer to the User/Client or in what
representations the User/Client decides to request.

As for you said selecting media by the "portal", you may see the way " uCDN
delivers multiple media streams to dCDN" is not good than "uCDN delivers one
media stream to dCDN and dCDN takes some adaptation to support multiple
media types".

My position is that we should focus on how to enable the interconnection of
the core CDN functionality offered by CDNs today (which is also my
interpretation of the scope of the CDNI working group as expressed in its
charter) because doing so is a significant piece of work in itself. Let's
not start trying to add in additional functionality beyond what the majority
of CDNs support today as that will just delay us getting usable
specifications into the market in a timely fashion IMO.

Ben

and like to promote the DRM all around the world:) If the content is needed
to be protected, generally you may know all the systems should be granted by
the content owner.

Philip,

Thank you that you feel Content Adaption is an issue for "Requirements" but
I do not know why it is not for Use case.

I like to clarify to U that it is important for you operator since it may
save investment if the system may support different services.

For us vendor, we are happy operator may install a system for the mobile
service and another system for the FBB service.

But the reality is all operators ask us to provide a system that may support
different service systems.

Frankly, Ben and Philip, I remember I have explained somewhere that to
implement this is rather simple .

At least the Use case and Requirement are informational to be referred in
future work. So I do really feel you may accept it.

Thanks.

Zhipeng

-----Original Message-----

Cc: [email-masked]

Ben, Zhipeng, all,

I think that Content Adaptation is more an issue for the Requirements doc
than for the Use cases draft.

The key question is whether we want the CDNI interfaces to be able to cope
with a scenario where (say) HD/SD conversion is done in the dCDN & to signal
about this.

I think that coping with this scenario is a second order requirement, ie we
should not worry about it in the initial standards-track work. I don't know,
did we ever decide whether the Use cases doc is restricted to "initial"
scenarios, or whether it's all-encompassing, ie covering "future" scenarios
as well?

Scott,

Reading some of your examples, they seem to be valid even if content
adaptation (HD/SD) is out of scope.

rather out of scope(?)

On security considerations, an interesting question is whether trust is
transitive. Don't think it need be - just because CSP trusts uCDN, and uCDN
trusts dCDN doesn't mean that the CSP automatically trusts the dCDN.
However, i suspect this can get arbitrarily complex - so one possibility is
to say that we will only handle cases where the trust is transitive.

Best wishes

phil

Philip Eardley

This email contains BT information, which may be privileged or confidential.
It's meant only for the individual(s) or entity named above. If you're not
the intended recipient, note that disclosing, copying, distributing or using
this information is prohibited. If you've received this email in error,
please let me know immediately on the email address above. Thank you. We
monitor our email system, and may record your emails.

England no: 1800000

-----Original Message-----

Of Ben Niven-Jenkins

To: ZhouZhipeng

Cc: [email-masked]

Colleagues,

IMO Section 5.1.3 should be removed from the Use Cases draft. Content
Adaptation (i.e. taking in a content item in one format and transforming it
to another format or representation) is not a "core" function of a CDN which
typically delivers the content that is requested without explicit knowledge
of what that content actually is.

Let's not forget that in building an end to end content service the CDN is
only one component and is the component tasked with executing the delivery
of a specific representation (version/copy/format etc.) of the selected
content not the component tasked with deciding (or applying policy) on which
version/copy/representation of content should be delivered.

The decision as to which version/copy/representation to offer and allow to
be delivered to a given device/user is implemented outside of the CDN (e.g.
by the "portal" where the user first makes their content selection prior to
the CDN becoming involved in the delivery of the selected content).

Ben

Following Scott's comments on section 5.1.3, I feel Scott's description on
the use case of HD and SD is not exactly correct.

If one movie has two formats of HD and SD, then we have two content with
different identifier. In DRM scope, the basic unit is a content copy.

In last month, I have contacted the Authors of this document and taken some
email exchanges with Grant and Philip (BT).

I have shown BT with some information that I know in this case and area to
explain the content flexibility is currently a basic requirement for CDN
service and related negotiation is needed in the CDN interconnection.

Meanwhile, I should also invite you in this group raising your comments or
questions on this case since I hope my use case may be incorporated in the
use case draft.

Thanks.

Zhipeng

 

-----Original Message-----

To: [email-masked]

content)

delivery is executed.  Clearly, the choice of authentication method is
determined by the respective CDN's.

Scott

CDNi mailing list

[email-masked]

CDNi mailing list

[email-masked]

---

From: "Daniel NEGRU" <[email-masked]>
Date: Sun, 30 Oct 2011 13:44:03 +0100

Dear all,

I would like to add to Theodore’s email that we suggested within this
proposed draft (draft-fmn-cdni-advanced-use-cases-00) a use case for
adaptation. Maybe it could be used, if of interest, for future discussions
on content adaptation.

Best regards,

Daniel 

De : [email-masked] [mailto:[email-masked]] De la part de
Theodore Zahariadis
Envoyé : dimanche 30 octobre 2011 12:29
À : 'Alan Kavanagh'; 'Kent Leung (kleung)'; 'Mark de Jong'
Cc : [email-masked]; 'ZhouZhipeng'
Objet : Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Dear all,

Best Regards,

Theodore

Alan

  _____  

Kent

Hi Alan,

Met vriendelijke groet,

Kind regards,

Mark de Jong

Ben

Alan

-----Original Message-----

Zhipeng,

Hello Ben,

Ben

Br,

Zhipeng

 

-----Original Message-----

To: ZhouZhipeng

Zhipeng,

Ben and Philip,

Ben,

Ben

Philip,

Thanks.

Zhipeng

-----Original Message-----

Cc: [email-masked]

Ben, Zhipeng, all,

Scott,

rather out of scope(?)

Best wishes

phil

Philip Eardley

England no: 1800000

-----Original Message-----

Of Ben Niven-Jenkins

To: ZhouZhipeng

Cc: [email-masked]

Colleagues,

Ben

Thanks.

Zhipeng

 

-----Original Message-----

To: [email-masked]

content)

Scott

CDNi mailing list

[email-masked]

CDNi mailing list

[email-masked]

---

From: ZhouZhipeng <[email-masked]>
Date: Mon, 31 Oct 2011 08:49:09 +0000

Dear Francois, and all,
Thanks for all the group’s attention on this topic.
I am also happy that my proposal has gotten so much valuable response/questions/ comments.
That will be very helpful for all of us to catch a complete understanding and solution for this market demand.
While I feel till now the topic itself has not been completely analyzed and I am busy doing the work. I will expose my contribution soon after I complete that work.
Meanwhile I hope the group may allow some more time for people to consider it. Perhaps some more people will emerge in the group mail list.
Currently, some people has claimed their preference.  I feel perhaps not a few people have supported this use case(the authors of draft-fmn-cdni-advanced-use-cases-00, Alan from Ericsson, ChinaMobile, Chinatelecom,  perhaps also KPN, and me).

I have explained that for CDN-A and CDN-B, they may negotiate whether to support the CDNI adaptation solution. Hence such optional arrangement will only bring benefit when both upstream and downstream agrees that at their appropriate situation.

So, I sincerely suggest two Chairs and the whole group may allow some more days for this topic.   I suggest after the Taipei meeting .
By then we all will get a clearer understanding and decision.

Thanks.
Zhipeng

From: Francois Le Faucheur [mailto:[email-masked]]
Sent: Friday, October 28, 2011 9:50 PM
To: ZhouZhipeng
Cc: [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Hi again Zhipeng,

Cheers

Francois

Dear all,

Dear,

From: Woundy, Richard [mailto:[email-masked]]
Sent: Thursday, October 27, 2011 7:23 PM
To: ZhouZhipeng; [email-masked]<mailto:[email-masked]>'; [email-masked]<mailto:[email-masked]>'
Cc: [email-masked]<mailto:[email-masked]>'; Woundy, Richard
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

-- Rich

From: ZhouZhipeng [mailto:[email-masked]]
Sent: Thursday, October 27, 2011 03:45 AM
To: Mark de Jong <[email-masked]<mailto:[email-masked]>>; Alan Kavanagh <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Hello Mark,

Dear all in this group,

Hi Alan,

Met vriendelijke groet,
Kind regards,

Mark de Jong

Ben

Alan

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
Sent: October-12-11 1:13 PM
To: ZhouZhipeng
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

Hello Ben,

Ben

Br,
Zhipeng

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]]
Sent: Wednesday, October 12, 2011 12:19 AM
To: ZhouZhipeng
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

Ben and Philip,

Ben,

Ben

Philip,

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Monday, October 10, 2011 11:22 PM
To: [email-masked]<mailto:[email-masked]>; ZhouZhipeng
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Ben, Zhipeng, all,

Scott,

Best wishes
phil

Philip Eardley

-----Original Message-----

Colleagues,

Ben

-----Original Message-----
From: Scott Wainner [mailto:[email-masked]]
Sent: Friday, September 30, 2011 8:02 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Scott

---

From: ZhouZhipeng <[email-masked]>
Date: Mon, 31 Oct 2011 09:04:28 +0000

Sorry, not KPN. It is Ray from TNO.
Zhipeng

From: ZhouZhipeng
Sent: Monday, October 31, 2011 4:49 PM
To: 'Francois Le Faucheur'
Cc: [email-masked]
Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Dear Francois, and all,

Thanks.
Zhipeng

Hi again Zhipeng,

Cheers

Francois

Dear all,

Dear,

-- Rich

Hello Mark,

Dear all in this group,

Hi Alan,

Met vriendelijke groet,
Kind regards,

Mark de Jong

Ben

Alan

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
Sent: October-12-11 1:13 PM
To: ZhouZhipeng
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

Hello Ben,

Ben

Br,
Zhipeng

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]]
Sent: Wednesday, October 12, 2011 12:19 AM
To: ZhouZhipeng
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

Ben and Philip,

Ben,

Ben

Philip,

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Monday, October 10, 2011 11:22 PM
To: [email-masked]<mailto:[email-masked]>; ZhouZhipeng
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Ben, Zhipeng, all,

Scott,

Best wishes
phil

Philip Eardley

-----Original Message-----

Colleagues,

Ben

-----Original Message-----
From: Scott Wainner [mailto:[email-masked]]
Sent: Friday, September 30, 2011 8:02 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Scott

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Mon, 31 Oct 2011 09:23:17 +0000

Hi Zhipeng,

To be clear here, I have not given my support to the Content Adaptation use case (nor have I voiced my opposition against it).

The conversation I had with Ben had to do with the concept of Grouped File Delegation and how different quality levels, encoded by the Content Provider, are handled in a CDN interconnection scenario.

Ray

From: [email-masked] [mailto:[email-masked]] On Behalf Of ZhouZhipeng
Sent: maandag 31 oktober 2011 10:04
To: Francois Le Faucheur
Cc: [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

From: ZhouZhipeng

Dear Francois, and all,

Thanks.
Zhipeng

From: Francois Le Faucheur [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Friday, October 28, 2011 9:50 PM
To: ZhouZhipeng
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Hi again Zhipeng,

Cheers

Francois

Dear all,

Dear,

From: Woundy, Richard [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>

-- Rich

From: ZhouZhipeng [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>

Hello Mark,

Dear all in this group,

From: Mark de Jong [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Thursday, October 27, 2011 4:21 AM
To: Alan Kavanagh
Cc: Ben Niven-Jenkins; ZhouZhipeng; [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Hi Alan,

Met vriendelijke groet,
Kind regards,

Mark de Jong

Ben

Alan

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Ben Niven-Jenkins
Sent: October-12-11 1:13 PM
To: ZhouZhipeng
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

Ben

Br,
Zhipeng

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Wednesday, October 12, 2011 12:19 AM
To: ZhouZhipeng
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

Ben and Philip,

Ben,

Ben

Philip,

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Monday, October 10, 2011 11:22 PM
To: [email-masked]<mailto:[email-masked]>; ZhouZhipeng
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Ben, Zhipeng, all,

Scott,

Best wishes
phil

Philip Eardley

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf
Of Ben Niven-Jenkins
Sent: 10 October 2011 12:04
To: ZhouZhipeng
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Colleagues,

Ben

-----Original Message-----
From: Scott Wainner [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Friday, September 30, 2011 8:02 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Scott

---

From: ZhouZhipeng <[email-masked]>
Date: Mon, 31 Oct 2011 09:35:00 +0000

Thanks Ray. welcome your more attention on it.
Zhipeng

From: Brandenburg, R. (Ray) van [mailto:[email-masked]]
Sent: Monday, October 31, 2011 5:23 PM
To: ZhouZhipeng; Francois Le Faucheur
Cc: [email-masked]
Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Hi Zhipeng,

Ray

From: ZhouZhipeng

Dear Francois, and all,

Thanks.
Zhipeng

Hi again Zhipeng,

Cheers

Francois

Dear all,

Dear,

-- Rich

Hello Mark,

Dear all in this group,

Hi Alan,

Met vriendelijke groet,
Kind regards,

Mark de Jong

Ben

Alan

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Ben Niven-Jenkins
Sent: October-12-11 1:13 PM
To: ZhouZhipeng
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

Ben

Br,
Zhipeng

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Wednesday, October 12, 2011 12:19 AM
To: ZhouZhipeng
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

Ben and Philip,

Ben,

Ben

Philip,

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Monday, October 10, 2011 11:22 PM
To: [email-masked]<mailto:[email-masked]>; ZhouZhipeng
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Ben, Zhipeng, all,

Scott,

Best wishes
phil

Philip Eardley

-----Original Message-----

Colleagues,

Ben

-----Original Message-----
From: Scott Wainner [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Friday, September 30, 2011 8:02 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Scott

---

From: Alan Kavanagh <[email-masked]>
Date: Mon, 31 Oct 2011 12:03:13 -0400

Hi Theodore

I do tend to agree with your point, though i would like one Use Case document as the baseline for which the Framework adn Metadata etc use to be built around. I do see the merit in taking on work that should be fullfilled within a given time limit and im all for that as long as we ensure all use cases are captured and not ignored. Im not too picky on where it should be done (current use case or another doc).

Alan

________________________________
From: Theodore Zahariadis [mailto:[email-masked]]
Sent: October-30-11 7:29 AM
To: Alan Kavanagh; 'Kent Leung (kleung)'; 'Mark de Jong'
Cc: [email-masked]; 'ZhouZhipeng'
Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Dear all,

I think that a good approach would be to proceed in cdni-use cases to ensure realistic/short-term use cases and then proceed to the advanced use cases that the Future Media Networks (FMN) cluster of projects have submitted under the cdni-advanced-use-cases ID.

Best Regards,
Theodore

Alan

Kent

Hi Alan,

Met vriendelijke groet,
Kind regards,

Mark de Jong

Ben

Alan

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
Sent: October-12-11 1:13 PM
To: ZhouZhipeng
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

Hello Ben,

Ben

Br,
Zhipeng

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]]
Sent: Wednesday, October 12, 2011 12:19 AM
To: ZhouZhipeng
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

Ben and Philip,

Ben,

Ben

Philip,

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Monday, October 10, 2011 11:22 PM
To: [email-masked]<mailto:[email-masked]>; ZhouZhipeng
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Ben, Zhipeng, all,

Scott,

Best wishes
phil

Philip Eardley

-----Original Message-----

Colleagues,

Ben

-----Original Message-----
From: Scott Wainner [mailto:[email-masked]]
Sent: Friday, September 30, 2011 8:02 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Scott

---

From: "Theodore Zahariadis" <[email-masked]>
Date: Mon, 31 Oct 2011 18:38:40 +0200

Dear Alan,

I also fully agree with your point. As the timeframe is rather short I think
that both the Framework and the Metadata should be built around one
document.

However, the draft we have sent is the result of many discussions, PhC and
research done by a large number of companies and participants from 6
project.

So, I believe it is worth a discussion. Unfortunately, I'll not be able to
participate at this IETF meeting, but our colleague Emile Stephan (Orange)
will and he may present the draft.

Of course there are two options:

a)      To try to merge the two documents towards a joined WG working
document, which could be also the base for the Framework and the Metadata
specification or

b)      Keep the one that you are already working on and just extend/update
this one as forward looking one.

In either case, I will be very happy to help and contribute.

Best Regards,

Theodore

 

From: Alan Kavanagh [mailto:[email-masked]] 
Sent: Monday, October 31, 2011 6:03 PM
To: [email-masked]; 'Kent Leung (kleung)'; 'Mark de Jong'
Cc: [email-masked]; 'ZhouZhipeng'
Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Hi Theodore

I do tend to agree with your point, though i would like one Use Case
document as the baseline for which the Framework adn Metadata etc use to be
built around. I do see the merit in taking on work that should be fullfilled
within a given time limit and im all for that as long as we ensure all use
cases are captured and not ignored. Im not too picky on where it should be
done (current use case or another doc).

Alan

  _____  

Dear all,

Best Regards,

Theodore

Alan

  _____  

Kent

Hi Alan,

Met vriendelijke groet,

Kind regards,

Mark de Jong

Ben

Alan

-----Original Message-----

Zhipeng,

Hello Ben,

Ben

Br,

Zhipeng

 

-----Original Message-----

To: ZhouZhipeng

Zhipeng,

Ben and Philip,

Ben,

Ben

Philip,

Thanks.

Zhipeng

-----Original Message-----

Cc: [email-masked]

Ben, Zhipeng, all,

Scott,

rather out of scope(?)

Best wishes

phil

Philip Eardley

England no: 1800000

-----Original Message-----

Of Ben Niven-Jenkins

To: ZhouZhipeng

Cc: [email-masked]

Colleagues,

Ben

Thanks.

Zhipeng

 

-----Original Message-----

To: [email-masked]

content)

Scott

CDNi mailing list

[email-masked]

CDNi mailing list

[email-masked]