Subject: [CDNi] comments on draft-bertrand-cdni-use-cases-02

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 26 Jul 2011 16:54:06 -0400

Hello,

Please find my review comments below.
Cheers

Francois

*** Abstract & Introduction:
"
It provides the business motivations for CDNI Working Group, which can be used to
   validate different interconnection arrangements, and requirements of the various CDNI interfaces.
"
Now the WG is formed you may want to adjust into something like:
"
It can be used to provide guidance to the CDNI WG about the interconnection arrangements to be supported and to validate the requirements of the various CDNI interfaces."

*** Introduction:
"
This document now merges input from [I-D.watson-cdni-use-cases] and
   [I-D.ma-cdni-publisher-use-cases].
"
I suggest you remove this historical info in new revs, as the document gradually matures towards WG material.

*** Introduction:
"
There are many possible combinations for the relationships between
   the different parties (Network Service Provider (NSP), CDN Provider,
   Content Service Provider (CSP) and End User) involved in end-to-end
   content delivery.  However, in the context of interconnecting CDNs
   the key relationships are listed below.
   o  How the CSP interacts with the CDN provider, so that the CDN
      delivers content in a manner compliant with CSP's distribution
      policies.
   o  How the End User interacts with the CSP and one or more CDNs to
      request and receive content.
   o  How the different CDN providers, operating their CDNs, interact
      with one another to deliver the CSP's content to the End User
      while continuing to enforce the CSP's distribution policies.
"
I don't quite see the relevance of this text in the use-case document, or what point it is trying to bring across.
In particular, it is a little confusing sine it talks about interfaces that are out of scope for CDNI without saying so.

*** 1.1 Terminology
 o I expect that terminology across problem-statement, requirements and use-case needs to be aligned and made probably moved into one document and referred by all the others. 
o "CDN Peering": I am not sure we need that term. 
o "Recursive request routing/ Recursive request routing": see discussion on the list about moving those terms in a single doc 

*** 1.3 High Level Use Cases for Multi-CDN Systems
I found it a little confusing to have the word "use cases" used here in the introduction as well as later in teh individual use-cases.
How about something like "Rationale or Multi-CDN Systems"?

*** 1.3 High Level Use Cases for Multi-CDN Systems
"
 CSP-1 benefits because it only needs to make one business agreement
   and one physical connection, with CDN Provider A, but its End Users
   get a service quality as though it had also gone to the trouble of
   making a business agreement with CDN Provider B.
"
s/as though it had /as though CSP-1 had /

*** 1.4.  The Need for CDNI Standards
"
   Existing CDN interfaces are proprietary and an external CDN typically
   cannot use them, especially if the two CDNs rely on different
   solutions. 
"
It is difficult to use existing interfaces because they are proprietary, but also because they have often been designed as intra-CDN/intra-domain interfaces, so they don't have all the right attributes.
Also, I think by "solutions" you mean "implementations".
So perhaps:
"
   Existing CDN interfaces are proprietary and have often been design for intra-CDN/intra-domain operations. So an external CDN typically cannot use them, especially if the two CDNs rely on different implementations.
"

"
 Nevertheless, [I-D.bertrand-cdni-experiments] shows that
   some level of CDN interconnection can be achieved experimentally
   without standardized interfaces between the CDNs.  The methods used
   in these experiments are hardly usable in an operational context,
   because they suffer from several limitations in terms of
   functionalities, scalability, and security level.
"
s/ The methods used/However, the methods used/

"
   The aim of the CDNI standards work is therefore to overcome such
   shortcomings; a full list of requirements is being developed in
   [I-D.lefaucheur-cdni-requirements].
"
s/the CDNI standards work/IETF CDNI WG solution/

***2.1.  Geographic Extension
"
   In this use case, the CDN Provider wants to extend the geographic
   distribution that it can offer CSPs, without

   o  compromising the quality of delivery

   o  attracting transit and other network costs by serving from
      geographically or topologically remote surrogates.
"
I think would read better as:
"
   In this use case, the CDN Provider wants to extend the geographic
   distribution that it can offer to its CSPs:

   o  without compromising the quality of delivery

   o  without incurring additional transit and other network costs that would result from serving content from
      geographically or topologically remote surrogates.
"

"
As an example, suppose a French CSP wants to distribute its TV
   programs to End Users located in various countries in Europe and
   North Africa.  It asks a French CDN Provider to deliver the content.
   The French CDN Provider's network only covers France, so it makes an
   agreement with another CDN Provider that covers North Africa.
   Overall, from the CSP's perspective the French CDN Provider provides
   a CDN service for both France and North Africa.
"
The example initially mentions a required coverage of Europe+ North Africa, but then seem to descrive a solution for a coverage of France+North Africa.

*** 2.2.  Region to Region Interconnection
I don't find the phrase "Region to Region" very distinctive versus the previous "Geographic Extension".
I think the key differences here is that the different CDNs are operated by different organization that are affiliates of the same company.
So how about "Inter-Affiliates Interconnection"?

*** 2.3.  Nomadic Users
You may want to mention that this is often loosely referred to as "TV everywhere".

"
 The motivation in this case is to allow nomadic users to maintain access,
   rather than to allow all residents within a region access to the
   content.
"
s/to maintain access/to maintain access with consistent quality of experience/

You may want to expand a little on which CDNs need to be interconnected to address the use case (ie with CDN of "home NSP" interconnected to CDN of visited NSP) possibly with a picture.

*** 2.4.  Delivery Restrictions
"Hence, the exchange through the CDN interconnection of information
   for controlling the footprint of the delivery is an important use
   case.
"
To me this is not an additional use cases, this is a requirement that has to be met in the use cases described earlier. In fact, the document mixes use cases and requirements in a few places.
I would suggest that :
	* you refer to  things discussed in that section as "requirements"
	* add a statement clarifying these requirements apply to the use cases discussed in the document.

"
   o  an expiration time (i.e., the time at which the content files
      should be expunged from all CDN storage).
"
I understand this is saying that CDNI metadata need to include this expiration time (triggering cache removal) , in addition to deactivation time. 
I don't think this is discussed in cdni-requirements yet. Can you bring that up on the list with the cdni-reqts authors?

"
   The delivery of content may be further influenced by policies which
   may include quality of service rules that specify:
   o  the maximum resolution deliverable to specific devices,
   o  the maximum resolution deliverable though a specific NSP, or
   o  the maximum resolution deliverable to users based on their
      subscription levels.
"
I don't think this is covered in the cdni-requirements doc. 
It is not obvious to me that absolutely all of those ought to be in phase 1. The first bullet only makes sense if the solution supports transcoding/transrating, which I don't know if it will be supported in Initial scope.
The last bullet does not make sense to me as we don;t want the CDNs to be aware of any user subscription levels (ie only CSP is aware of user subscription level).

*** 3.1.  Overload Handling and Dimensioning
"
This brings dimensioning savings to the CDNs as they can use the resources
   of each other during their peaks of activity.
"
s/their peaks of activity./ their respective peaks of activity./

*** 3.3.  Branding Consideration
Again, this seems more of a requirement than a use case per-say. I recommend you make that clear upfront in teh section (ie this is not an extra use cases, but a requirement applying to use-cases discussed before).
Also, is there a reason this applicable to only the use cases in section 3 and not section 2?
Anotehr option may be to move 2.4 and 3.3 under a separate heading somewhere collecting key requirements applicable to the many use cases. 

*** 4.1.  Device and Network Technology Extension
Again I think some of the discussion assumes that there is some conversion of quality done inside the CDNs (as opposed to different terminal requesting different URIs).
I think we need to discuss whether this is going to come in Initial Scope or not.

*** in Figure 2: 
s/CDN Provider A/CDN Provider 1/

*** co-authors. You have a long list of co-authors. As per current practice, you would want to split that into "editors" and "contributors".

---

From: Kevin J Ma <[email-masked]>
Date: Tue, 26 Jul 2011 18:22:59 -0400

Francois,

  I think that 2.4, 3.3, and 4.1 generally describe the way a CSP would use a
  CDN, which may influence CDNI considerations, as opposed to use cases which
  are say request routing specific.  Would it make sense to break out 2.4 and
  3.3 into a separate policy-based distribution use case section?  wrt 4.1, I
  can see your point about separate URIs vs other intelligence functionality.
  Would it make sense to simplify 4.1 and merged it back into 2.3?

> -----Original Message-----
> From: Francois Le Faucheur [mailto:[email-masked]]
> Sent: Tuesday, July 26, 2011 4:54 PM
> To: [email-masked]
> Cc: Le Faucheur Francois; [email-masked]
> Subject: comments on draft-bertrand-cdni-use-cases-02
> 
> Hello,
> 
> It can be used to provide guidance to the CDNI WG about the
> interconnection arrangements to be supported and to validate the
> requirements of the various CDNI interfaces."
> 
> 
> *** Introduction:
> "
> In particular, it is a little confusing sine it talks about interfaces
> that are out of scope for CDNI without saying so.
> 
> 
> *** 1.1 Terminology
>  o I expect that terminology across problem-statement, requirements and
> use-case needs to be aligned and made probably moved into one document and
> referred by all the others.
> o "Recursive request routing/ Recursive request routing": see discussion
> on the list about moving those terms in a single doc
> 
> 
> I found it a little confusing to have the word "use cases" used here in
> the introduction as well as later in teh individual use-cases.
> It is difficult to use existing interfaces because they are proprietary,
> but also because they have often been designed as intra-CDN/intra-domain
> interfaces, so they don't have all the right attributes.
>    Existing CDN interfaces are proprietary and have often been design for
> intra-CDN/intra-domain operations. So an external CDN typically cannot use
> them, especially if the two CDNs rely on different implementations.
> "
> 
> "
> The example initially mentions a required coverage of Europe+ North
> Africa, but then seem to descrive a solution for a coverage of
> France+North Africa.
> 
> 
> I think the key differences here is that the different CDNs are operated
> by different organization that are affiliates of the same company.
> You may want to expand a little on which CDNs need to be interconnected to
> address the use case (ie with CDN of "home NSP" interconnected to CDN of
> visited NSP) possibly with a picture.
> 
> 
> To me this is not an additional use cases, this is a requirement that has
> to be met in the use cases described earlier. In fact, the document mixes
> use cases and requirements in a few places.
> I would suggest that :
> I understand this is saying that CDNI metadata need to include this
> expiration time (triggering cache removal) , in addition to deactivation
> time.
> I don't think this is discussed in cdni-requirements yet. Can you bring
> that up on the list with the cdni-reqts authors?
> 
> "
> It is not obvious to me that absolutely all of those ought to be in phase
> 1. The first bullet only makes sense if the solution supports
> transcoding/transrating, which I don't know if it will be supported in
> Initial scope.
> The last bullet does not make sense to me as we don;t want the CDNs to be
> aware of any user subscription levels (ie only CSP is aware of user
> subscription level).
> 
> 
> Again, this seems more of a requirement than a use case per-say. I
> recommend you make that clear upfront in teh section (ie this is not an
> extra use cases, but a requirement applying to use-cases discussed
> before).
> Anotehr option may be to move 2.4 and 3.3 under a separate heading
> somewhere collecting key requirements applicable to the many use cases.
> 
> 
> Again I think some of the discussion assumes that there is some conversion
> of quality done inside the CDNs (as opposed to different terminal
> requesting different URIs).
> *** co-authors. You have a long list of co-authors. As per current
> practice, you would want to split that into "editors" and "contributors".

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Thu, 28 Jul 2011 11:55:19 -0700

Hi.  I'll pile on my comments under the same subject line.

1. Sect 1.1 Terminology: The following are not new terms: CDN Provider,
dCDN, CDNI.  These terms should go to one document later.
2. "Asymmetric Distribution" term doesn't match description well, IMHO.
Maybe something like "Authorized Content Distribution"? It's probably
not much better.
3. Sect 1.2 Abbreviations: ISP, PC, STB, UE, VoD, WiFI are not used in
document.  Maybe others too?
4. Consistency use of "CDN Interconnect" vs "CDN Interconnection"
5. Make sure to use terms properly "surrogate" -> "Surrogate",
"end-user" -> "End User", etc.
6. Sect 2.4 Delivery Restrictions: Typo "geo- location-based"
7. The bullets for maximum resolution do not seem relevant to CDNI.
Would this be controlled by the CSP/SP that authorizes access to the
content by providing the URL to this type of resolution?  The line is
blurring between content delivery limitations (in non-CDNI case) and
metadata relevant to CDNI.  Definitely subscription should not be a
factor.  It seems to me that if the request reaches the uCDN, access to
the content has already been authorized (i.e. to the End User or
device).
8. Sect 3.2.1 and 3.2.2 Failure of Content: I'm not clear if dCDN is
allowed to obtain contain directly from CSP?  If so, then the CDNI model
should have a Request Interface from dCDN to CSP.
9. Sect 4.1 Device and Network: The example assumes that CSP licensed
both high and low resolution content to CDN A, right?  Not clear how UA
(mobile device) can get authorization to high resolution content?  I
assume there will be some URL validation at uCDN.
10. Sect 7 Security: Typo "situtations" -> "situations"

Kent

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Francois Le Faucheur (flefauch)
Sent: Tuesday, July 26, 2011 1:54 PM
To: [email-masked]
Cc: [email-masked]
Subject: [CDNi] comments on draft-bertrand-cdni-use-cases-02

Hello,

Francois

*** Abstract & Introduction:
"
It provides the business motivations for CDNI Working Group, which can
be used to
   validate different interconnection arrangements, and requirements of
the various CDNI interfaces.
"
Now the WG is formed you may want to adjust into something like:
"
It can be used to provide guidance to the CDNI WG about the
interconnection arrangements to be supported and to validate the
requirements of the various CDNI interfaces."

*** Introduction:
"
This document now merges input from [I-D.watson-cdni-use-cases] and
   [I-D.ma-cdni-publisher-use-cases].
"
I suggest you remove this historical info in new revs, as the document
gradually matures towards WG material.

*** Introduction:
"
I don't quite see the relevance of this text in the use-case document,
or what point it is trying to bring across.

*** 1.1 Terminology
 o I expect that terminology across problem-statement, requirements and
use-case needs to be aligned and made probably moved into one document
and referred by all the others. 
o "CDN Peering": I am not sure we need that term. 
o "Recursive request routing/ Recursive request routing": see discussion
on the list about moving those terms in a single doc 

*** 1.4.  The Need for CDNI Standards
"
   Existing CDN interfaces are proprietary and an external CDN typically
   cannot use them, especially if the two CDNs rely on different
   solutions. 
"
It is difficult to use existing interfaces because they are proprietary,
but also because they have often been designed as intra-CDN/intra-domain
interfaces, so they don't have all the right attributes.
Also, I think by "solutions" you mean "implementations".
So perhaps:
"
   Existing CDN interfaces are proprietary and have often been design
for intra-CDN/intra-domain operations. So an external CDN typically
cannot use them, especially if the two CDNs rely on different
implementations.
"

"

"

   o  without incurring additional transit and other network costs that
would result from serving content from
      geographically or topologically remote surrogates.
"

"

*** 2.2.  Region to Region Interconnection
I don't find the phrase "Region to Region" very distinctive versus the
previous "Geographic Extension".
I think the key differences here is that the different CDNs are operated
by different organization that are affiliates of the same company.
So how about "Inter-Affiliates Interconnection"?

*** 2.3.  Nomadic Users
You may want to mention that this is often loosely referred to as "TV
everywhere".

"
 The motivation in this case is to allow nomadic users to maintain
access,
   rather than to allow all residents within a region access to the
   content.
"
s/to maintain access/to maintain access with consistent quality of
experience/

You may want to expand a little on which CDNs need to be interconnected
to address the use case (ie with CDN of "home NSP" interconnected to CDN
of visited NSP) possibly with a picture.

*** 2.4.  Delivery Restrictions
"Hence, the exchange through the CDN interconnection of information
   for controlling the footprint of the delivery is an important use
   case.
"
To me this is not an additional use cases, this is a requirement that
has to be met in the use cases described earlier. In fact, the document
mixes use cases and requirements in a few places.
I would suggest that :
	* you refer to  things discussed in that section as
"requirements"
	* add a statement clarifying these requirements apply to the use
cases discussed in the document.

"

"
   The delivery of content may be further influenced by policies which
   may include quality of service rules that specify:
   o  the maximum resolution deliverable to specific devices,
   o  the maximum resolution deliverable though a specific NSP, or
   o  the maximum resolution deliverable to users based on their
      subscription levels.
"
I don't think this is covered in the cdni-requirements doc. 
It is not obvious to me that absolutely all of those ought to be in
phase 1. The first bullet only makes sense if the solution supports
transcoding/transrating, which I don't know if it will be supported in
Initial scope.
The last bullet does not make sense to me as we don;t want the CDNs to
be aware of any user subscription levels (ie only CSP is aware of user
subscription level).

*** 3.1.  Overload Handling and Dimensioning
"
This brings dimensioning savings to the CDNs as they can use the
resources
   of each other during their peaks of activity.
"
s/their peaks of activity./ their respective peaks of activity./

Also, is there a reason this applicable to only the use cases in section
3 and not section 2?

*** 4.1.  Device and Network Technology Extension
Again I think some of the discussion assumes that there is some
conversion of quality done inside the CDNs (as opposed to different
terminal requesting different URIs).
I think we need to discuss whether this is going to come in Initial
Scope or not.

*** in Figure 2: 

*** co-authors. You have a long list of co-authors. As per current
practice, you would want to split that into "editors" and
"contributors".

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

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Thu, 28 Jul 2011 13:10:16 -0700

Hi Francois.  Responding to comments related to the requirements draft
below.

KL> I've seen references to content expiration time (i.e. removal) in
some drafts.  So it seems to be needed in the CDNI Metadata.  Noted as
requirement (possibly part of availability window) unless others object.

"

KL> I'm not yet convinced that this should be part of the CDNI Metadata.
Based on the discussion conclusion, we can track this as possible
requirement for now.

Kent

---

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 28 Jul 2011 16:16:57 -0400

Kent and all,

> requirement (possibly part of availability window) unless others object.

FLF as an Individual: that works for me.

> Based on the discussion conclusion, we can track this as possible

FLF as a chair: I will raise a discussion in the "Open Items" slot towards the end of the WG meeting on "Content Adaptation" and what shoudl be in scope of CDNI. This will give us some sense on the WG views on that.

Francois

> Kent

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

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

 Think before you print.

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

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

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

---

From: Kevin J Ma <[email-masked]>
Date: Thu, 28 Jul 2011 16:54:27 -0400

Just one quick comment: it was not necessarily the intent of the use cases to imply
that CDNI requirements be generated for each piece of metadata; the metadata may be
useful for certain deployments, but opaque metadata distribution may be sufficient?

There was discussion early on about metadata with implied actions like: expiration,
or sunset/sunrise, or ssl only, or url hashing required, or content transformation,
or do accounting, or other proprietary optimization or policy enforcement features,
etc., but its not clear that we would want CDNI requirements for each of these?

It seems like a more generic notion of defining metadata (and their actions), and
allowing CDNs to advertise or decline metadata (action) support would useful, as
opposed to adding a requirement for each piece of metadata?

From: Francois Le Faucheur [mailto:[email-masked]]
Sent: Thursday, July 28, 2011 4:17 PM
To: Kent Leung (kleung)
Cc: Francois Le Faucheur; [email-masked]; [email-masked]
Subject: Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02

Kent and all,

"

Francois

Kent

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

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

 Think before you print.

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Thu, 28 Jul 2011 14:18:01 -0700

Hi Kevin.  The requirements are written generically.  It has examples of the basic cases.  Since content expiration seems to be useful, we’ll add this to Req draft so the solutions will consider and hopefully incorporate the features (i.e. reminder not to forget).

Kent

From: Kevin J Ma [mailto:[email-masked]] 
Sent: Thursday, July 28, 2011 1:54 PM
To: Francois Le Faucheur (flefauch); Kent Leung (kleung)
Cc: [email-masked]; [email-masked]
Subject: RE: [CDNi] comments on draft-bertrand-cdni-use-cases-02

 

Kent and all,

	
	
	"

Francois

Kent

 

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

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

 Think before you print.

---

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 28 Jul 2011 17:22:10 -0400

> opposed to adding a requirement for each piece of metadata?

I have been assuming that we'd want to specify:
	*A* a set of well-accepted metadata elements with their semantics (eg start of time window, end of time window,...), AND
	*B* probably, also a mechanism to allow exchange of opaque metadata element, whose semantic is not defined in CDNI but up to private CDN agreement.

I believe *A* is needed to facilitate actual base interoperation across CDNs.
I believe *B* is useful to allow CDNs to do extra thing on top of what has been specified in CDNI.
Are you saying that you feel only *B* is needed?

Cheers

Francois

Francois Le Faucheur
Distinguished Engineer
Corporate Development
[email-masked]
Phone: +33 49 723 2619

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

 Think before you print.

---

From: Kevin J Ma <[email-masked]>
Date: Thu, 28 Jul 2011 17:35:22 -0400

i think there could be alot of debate about what qualifies as A.

one solution would be to go with just B, for requirements, but
either way is ok with me.

Sent from my iPhone

On Jul 28, 2011, at 5:22 PM, "Francois Le Faucheur" <[email-masked]<mailto:[email-masked]>> wrote:

Cheers

Francois

From: Francois Le Faucheur [mailto:[email-masked]]
Sent: Thursday, July 28, 2011 4:17 PM
To: Kent Leung (kleung)
Cc: Francois Le Faucheur; <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>; <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02

Kent and all,

"

Francois

Kent

Francois Le Faucheur
Distinguished Engineer
Corporate Development

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

 Think before you print.

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

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

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

 Think before you print.

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

---

From: Kevin J Ma <[email-masked]>
Date: Thu, 28 Jul 2011 17:39:01 -0400

I still think the ability to advertise support for specific metadata is needed...

From: [email-masked] [mailto:[email-masked]] On Behalf Of Kevin J Ma
Sent: Thursday, July 28, 2011 5:35 PM
To: Francois Le Faucheur
Cc: [email-masked]; [email-masked]
Subject: Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02

Sent from my iPhone

Cheers

Francois

From: Francois Le Faucheur [mailto:[email-masked]]
Sent: Thursday, July 28, 2011 4:17 PM
To: Kent Leung (kleung)
Cc: Francois Le Faucheur; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02

Kent and all,

"

Francois

Kent

Francois Le Faucheur
Distinguished Engineer
Corporate Development

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

 Think before you print.

Francois Le Faucheur
Distinguished Engineer
Corporate Development

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

 Think before you print.

---

From: Francois Le Faucheur <[email-masked]>
Date: Fri, 29 Jul 2011 10:03:18 -0400

Ken, Yiu,

Can you add into your list of tracked candidate items something reflecting this thread? ie ensuring cdni-requirements incorporates requirements on the CDNI Metadata interface covering:
	*A* ability to exchange a set of well-accepted metadata elements with specified semantics (eg start of time window, end of time window,...), AND
	*B* ability to allow exchange of opaque metadata element, whose semantic is not defined in CDNI but left up to private CDN agreement.

Dave Oran also privately suggested that we expand on *B* to cover the usual distribution options for treatment of opaque element (eg ignore-and-pass-on-when-not-understood, etc). Which makes sense to me.

Thanks

Francois

Begin forwarded message:

> From: Kevin J Ma <[email-masked]>
> Date: 28 July 2011 17:35:22 EDT
> To: Francois Le Faucheur <[email-masked]>
> Cc: Francois Le Faucheur <[email-masked]>, "Kent Leung (kleung)" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
> On Jul 28, 2011, at 5:22 PM, "Francois Le Faucheur" <[email-masked]> wrote:
> 
>> 

Francois Le Faucheur
Distinguished Engineer
Corporate Development
[email-masked]
Phone: +33 49 723 2619

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

 Think before you print.

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Fri, 29 Jul 2011 07:31:13 -0700

Got it. - Kent

From: Francois Le Faucheur (flefauch) 
Sent: Friday, July 29, 2011 7:03 AM
To: Kent Leung (kleung); Yiu Lee
Cc: Francois Le Faucheur (flefauch); [email-masked]; Dave Oran (oran)
Subject: Fwd: [CDNi] comments on draft-bertrand-cdni-use-cases-02

Ken, Yiu,

Thanks

Francois

Begin forwarded message:

Sent from my iPhone

	

	Cheers

	Francois

	 

	Kent and all,

	

	

		
		
		"

	Francois

	

	Kent

	

Francois Le Faucheur
Distinguished Engineer
Corporate Development

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

 Think before you print.

	 

Francois Le Faucheur
Distinguished Engineer
Corporate Development
[email-masked]
Phone: +33 49 723 2619

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

 Think before you print.

 

Francois Le Faucheur
Distinguished Engineer
Corporate Development

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

 Think before you print.