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

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 7 Apr 2011 18:59:36 +0200

Folks,

Below is an updated version of the CDNI draft charter reflecting the charter discussion/edits during the BOF.
Please bring forward the additional comments you have before this draft charter is assessed by the ADs.

Francois & Rich

PS: do not worry about "editorial" comments for now, let's focus on comment

Content Delivery Networks Interconnection (CDNI) - Draft Charter
----------------------------------------------------------------

Description of Working Group
============================

A Content Delivery Network (CDN) is an infrastructure of network elements operating at layer 4 through layer 7, arranged for the efficient distribution and delivery of digital content. Such content includes, but is not limited to, web pages and images delivered via HTTP, and streaming of continuous media delivered via HTTP, RTSP, RTMP, etc. CDNs typically provide services to multiple Content Service Providers (CSPs).

CDNs provide numerous benefits: a shared platform for multi-service content delivery, reduced transmission costs for cacheable content, improved quality of experience for end users and increased robustness of delivery. For these reasons they are frequently used for large-scale content delivery.

As a result of the significant growth in content delivered over IP networks, existing CDN providers are scaling up their infrastructure and many Network Service Providers and Enterprise Service Providers are deploying their own CDNs. Subject to the policy of the CSP, it is generally desirable that a given item of content can be delivered to an end user regardless of that end user's location or attachment network. This creates a need for interconnecting (previously) standalone CDNs so they can interoperate and collectively behave as a single delivery infrastructure.

The goal of the CDNI Working Group is to allow the interconnection of separately administered CDNs in support of the end-to-end delivery of content from CSPs through multiple CDNs and ultimately to end users (via their respective User Agents). The CDNI WG aims at delivering a targeted, deployable solution in a short timeframe (18-24 months) as needed by the industry. It is expected that the CDNI interfaces will be realized using existing IETF protocols for transport and message exchange, and using existing object notation grammars/languages for the definition of CDNI objects and semantics. In the event that protocol extensions or new protocols are deemed necessary by the WG, the WG will recharter.

The working group will focus on the following items:

- A "problem statement" document providing a description of the problem and a common terminology.

- A "use case" document describing scenarios for usage and applications of the CDNI solution and protocols

- A "framework" document providing a description of the different components of the CDNI solution and how they interact with and relate to one another. This document will also include a "threat analysis" discussing the security concerns and threats, the trust model and privacy issues specific to CDNI.

- A "requirements" document. This document lists the requirements for CDNI architecture and the protocols to support it. In particular, this document will focus on identifying a reasonable set of more urgent and important requirements that will be addressed in the initial set of CDNI protocols and solutions produced by the working group. This document will list the requirements stemming from the threat analysis and to be met by each of the CDNI interfaces.

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

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

	o CDNI metadata distribution systems. This interface will allow the CDNs to exchange distribution metadata of inter-CDN scope. Distribution metadata refers to the subset of content metadata that is relevant to the distribution of the content and therefore is to be processed by CDNs (for example, this may include information enabling: content acquisition, geo-blocking, enforcement of availability windows or access control).

	o CDNI logging systems. This interface will allow CDN logging systems to exchange logging information associated with actions that are relevant across CDNs (such as content distribution, content delivery and content routing actions) for purposes of accounting, analytics, monitoring, etc.

	o CDN control systems. In particular, this interface will allow an upstream CDN to remove or invalidate content in a downstream CDN.

The WG will discuss and address the security, management and operational issues specific to CDNI, inside the above documents and specifications.

The working group will only define solutions for aspects of the CDN Interconnection problem space that require direct communication or interoperation between CDNs.

In particular, the WG will not define:
- New session, transport or network protocols.
- New protocols for delivering content from a CDN to an End User/User Agent.
- New protocols for ingestion of content or metadata between a CSP and a CDN.
- New protocols for acquiring content across CDNs.
- Protocols and algorithms for intra-CDN operations.
- Support for Transparent Caching across CDNs.
- New applications consuming CDNI logs.
- Digital Right Management (DRM) mechanisms

The WG will work with other WGs to assess, and where appropriate, leverage protocols developed by those WGs, in order to realize the CDNI requirements and CDNI interfaces. For example, the WG may assess the suitability of the ALTO protocol as a protocol to enable downstream CDNs to exchange information which may aid an upstream CDN with making CDNI request routing decisions.

Goals & Milestones
==================

WG Creation + 6 months: 	Submit CDNI problem statement to IESG as Informational
WG Creation + 9 months: 	Submit CDNI use cases to IESG as Informational
WG Creation + 12 months: 	Submit CDNI framework to IESG as Informational
WG Creation + 12 months: 	Submit CDNI requirements to IESG as Informational
WG Creation + 18 months: 	Submit specification of the CDNI Request Routing interface to IESG as Proposed Standard
WG Creation + 18 months: 	Submit specification of the CDNI Logging interface to IESG as Proposed Standard
WG Creation + 18 months: 	Submit specification of the CDNI Control interface to IESG as proposed Standard
WG Creation + 24 months: 	Submit specification of the CDNI Metadata Distribution interface to IESG as Proposed Standard
WG Creation + 24 months: 	Recharter or dissolve

On 31 Mar 2011, at 16:43, Woundy, Richard wrote:

> Folks,
>  
> I wanted everyone to have an updated version of the CDNI draft charter below, for discussion at the BOF shortly. This is based on input from many people this week, including people that attended the informal CDNI gathering last night. It is available online at <http://www.ietf.org/proceedings/80/slides/cdni-9.txt>, and has been updated on the BOF wiki <http://trac.tools.ietf.org/bof/trac/wiki/WikiStart>.
>  
> The meeting materials for the BOF are available here: <https://datatracker.ietf.org/meeting/80/materials.html#wg-cdni>.
>  
> -- Rich and Francois
>  
> Content Delivery Networks Interconnection (CDNI) - Draft Charter
> ----------------------------------------------------------------
>  
> Description of Working Group
> ============================
>  
> A Content Delivery Network (CDN) is an infrastructure of network elements operating at layer 4 through layer 7, arranged for the efficient distribution and delivery of digital content. Such content includes, but is not limited to, web pages and images delivered via HTTP, and streaming of continuous media delivered via HTTP, RTSP, RTMP, etc. CDNs typically provide services to multiple Content Service Providers (CSPs).
>  
> CDNs provide numerous benefits: a shared platform for multi-service content delivery, reduced transmission costs for cacheable content, improved quality of experience for end users and increased robustness of delivery. For these reasons they are frequently used for large-scale content delivery.
>  
> As a result of the significant growth in content delivered over IP networks, existing CDN providers are scaling up their infrastructure and many Network Service Providers and Enterprise Service Providers are deploying their own CDNs. Subject to the policy of the CSP, it is generally desirable that a given item of content can be delivered to an end user regardless of that end user's location or attachment network. This creates a need for interconnecting (previously) standalone CDNs so they can interoperate and collectively behave as a single delivery infrastructure.
>  
> The goal of the CDNI Working Group is to allow the interconnection of separately administered CDNs in support of the end-to-end delivery of content from CSPs through multiple CDNs and ultimately to end users (via their respective User Agents). The CDNI WG aims at delivering a targeted, deployable solution in a short timeframe (18-24 months) as needed by the industry. It is expected that the CDNI interfaces will be realized using existing IETF protocols for transport and message exchange, and using existing object notation grammars/languages for the definition of CDNI objects and semantics. In the event that protocol extensions or new protocols are deemed necessary by the WG, the WG will recharter.
>  
> The working group will focus on the following items:
>  
> - A "problem statement" document providing a description of the problem and a common terminology.
>  
> - A "use case" document describing scenarios for usage and applications of the CDNI solution and protocols
>  
> - A "framework" document providing a description of the different components of the CDNI solution and how they interact with and relate to one another.
>  
> - A "requirements" document. This document lists the requirements for CDNI architecture and the protocols to support it. In particular, this document will focus on identifying a reasonable set of more urgent and important requirements that will be addressed in the initial set of CDNI protocols and solutions produced by the working group.
>  
> - A detailed specification of the interfaces for the interconnection & interoperation of:
>  
>         o CDNI request-routing systems. In particular, this interface will allow an upstream CDN request routing system to obtain from the downstream CDN the information necessary to perform request redirection.
>  
>         o CDNI metadata distribution systems. This interface will allow the CDNs to exchange distribution metadata of inter-CDN scope. Distribution metadata refers to the subset of content metadata that is relevant to the distribution of the content and therefore is to be processed by CDNs (for example, this may include information enabling: content acquisition, geo-blocking, enforcement of availability windows or access control).
>  
>         o CDNI logging systems. This interface will allow CDN logging systems to exchange logging information associated with actions that are relevant across CDNs (such as content distribution, content delivery and content routing actions) for purposes of accounting, analytics, monitoring, etc.
>  
>         o CDN control systems. In particular, this interface will allow an upstream CDN to remove or invalidate content in a downstream CDN.
>  
> The WG will discuss and address the security (including threat model), management and operational issues specific to CDNI, inside the above documents and specifications.
>  
> The working group will only define solutions for aspects of the CDN Interconnection problem space that require direct communication or interoperation between CDNs.
>  
> In particular, the WG will not define:
> - New session, transport or network protocols.
> - New protocols for delivering content from a CDN to an End User/User Agent.
> - New protocols for ingestion of content or metadata between a CSP and a CDN.
> - New protocols for acquiring content across CDNs.
> - Protocols and algorithms for intra-CDN operations.
> - Support for Transparent Caching across CDNs.
> - New applications consuming CDNI logs.
>  
> The WG will work with other WGs to assess, and where appropriate, leverage protocols developed by those WGs, in order to realize the CDNI requirements and CDNI interfaces. For example, the WG may assess the suitability of the ALTO protocol as a protocol to enable downstream CDNs to exchange information which may aid an upstream CDN with making CDNI request routing decisions.
>  
>  
> Goals & Milestones
> ==================
>  
> WG Creation + 6 months:        Submit CDNI problem statement to IESG as Informational
> WG Creation + 9 months:        Submit CDNI use cases to IESG as Informational
> WG Creation + 12 months:       Submit CDNI framework to IESG as Informational
> WG Creation + 12 months:       Submit CDNI requirements to IESG as Informational
> WG Creation + 18 months:       Submit specification of the CDNI Request Routing interface to IESG as Proposed Standard
> WG Creation + 18 months:       Submit specification of the CDNI Logging interface to IESG as Proposed Standard
> WG Creation + 18 months:       Submit specification of the CDNI Control interface to IESG as proposed Standard
> WG Creation + 24 months:       Submit specification of the CDNI Metadata Distribution interface to IESG as Proposed Standard
> WG Creation + 24 months:       Recharter or dissolve
>  
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni

---

From: Bhumip Khasnabish <[email-masked]>
Date: Thu, 7 Apr 2011 20:13:48 -0400

You mean  interconnection of *TWO* separately administered CDNs, right .
.anything beyond two is out of scope . .
pls confirm and clarify that in the charter.

>The goal of the CDNI Working Group is to allow the >interconnection of
separately administered CDNs

On Thu, Apr 7, 2011 at 12:59 PM, Francois Le Faucheur <[email-masked]>wrote:

> A Content Delivery Network (CDN) is an infrastructure of network elements
> operating at layer 4 through layer 7, arranged for the efficient
> distribution and delivery of digital content. Such content includes, but is
> not limited to, web pages and images delivered via HTTP, and streaming of
> continuous media delivered via HTTP, RTSP, RTMP, etc. CDNs typically provide
> services to multiple Content Service Providers (CSPs).
>
> CDNs provide numerous benefits: a shared platform for multi-service content
> delivery, reduced transmission costs for cacheable content, improved quality
> of experience for end users and increased robustness of delivery. For these
> reasons they are frequently used for large-scale content delivery.
>
> As a result of the significant growth in content delivered over IP
> networks, existing CDN providers are scaling up their infrastructure and
> many Network Service Providers and Enterprise Service Providers are
> deploying their own CDNs. Subject to the policy of the CSP, it is generally
> desirable that a given item of content can be delivered to an end
> user regardless of that end user's location or attachment network. This
> creates a need for interconnecting (previously) standalone CDNs so they can
> interoperate and collectively behave as a single delivery infrastructure.
>
> The goal of the CDNI Working Group is to allow the interconnection of
> separately administered CDNs in support of the end-to-end delivery of
> content from CSPs through multiple CDNs and ultimately to end users (via
> their respective User Agents). The CDNI WG aims at delivering a targeted,
> deployable solution in a short timeframe (18-24 months) as needed by the
> industry. It is expected that the CDNI interfaces will be realized using
> existing IETF protocols for transport and message exchange, and using
> existing object notation grammars/languages for the definition of CDNI
> objects and semantics. In the event that protocol extensions or new
> protocols are deemed necessary by the WG, the WG will recharter.
>
> - A "framework" document providing a description of the different
> components of the CDNI solution and how they interact with and relate to one
> another. This document will also include a "threat analysis" discussing the
> security concerns and threats, the trust model and privacy issues specific
> to CDNI.
>
> - A "requirements" document. This document lists the requirements for CDNI
> architecture and the protocols to support it. In particular, this document
> will focus on identifying a reasonable set of more urgent and important
> requirements that will be addressed in the initial set of CDNI protocols and
> solutions produced by the working group. This document will list the
> requirements stemming from the threat analysis and to be met by each of the
> CDNI interfaces.
>
> o CDNI request-routing systems. This interface will allow an upstream CDN
> request routing system to obtain from the downstream CDN the information
> necessary to perform request redirection.
>
> o CDNI metadata distribution systems. This interface will allow the CDNs to
> exchange distribution metadata of inter-CDN scope. Distribution metadata
> refers to the subset of content metadata that is relevant to the
> distribution of the content and therefore is to be processed by CDNs (for
> example, this may include information enabling: content
> acquisition, geo-blocking, enforcement of availability windows or access
> control).
>
> o CDNI logging systems. This interface will allow CDN logging systems to
> exchange logging information associated with actions that are relevant
> across CDNs (such as content distribution, content delivery and content
> routing actions) for purposes of accounting, analytics, monitoring, etc.
>
> o CDN control systems. In particular, this interface will allow an upstream
> CDN to remove or invalidate content in a downstream CDN.
>
> The WG will discuss and address the security, management and operational
> issues specific to CDNI, inside the above documents and specifications.
>
> The working group will only define solutions for aspects of the CDN
> Interconnection problem space that require direct communication or
> interoperation between CDNs.
>
> The WG will work with other WGs to assess, and where appropriate, leverage
> protocols developed by those WGs, in order to realize the CDNI requirements
> and CDNI interfaces. For example, the WG may assess the suitability of the
> ALTO protocol as a protocol to enable downstream CDNs to exchange
> information which may aid an upstream CDN with making CDNI request routing
> decisions.
>
>
> Goals & Milestones
> ==================
>
> WG Creation + 24 months:  Submit specification of the CDNI Metadata
> Distribution interface to IESG as Proposed Standard
> I wanted everyone to have an updated version of the CDNI draft charter
> below, for discussion at the BOF shortly. This is based on input from many
> people this week, including people that attended the informal CDNI gathering
> last night. It is available online at <
> http://www.ietf.org/proceedings/80/slides/cdni-9.txt>, and has been
> updated on the BOF wiki <
> http://trac.tools.ietf.org/bof/trac/wiki/WikiStart>.
>
> The meeting materials for the BOF are available here: <
> https://datatracker.ietf.org/meeting/80/materials.html#wg-cdni>.
>
> -- Rich and Francois
>
> A Content Delivery Network (CDN) is an infrastructure of network elements
> operating at layer 4 through layer 7, arranged for the efficient
> distribution and delivery of digital content. Such content includes, but is
> not limited to, web pages and images delivered via HTTP, and streaming of
> continuous media delivered via HTTP, RTSP, RTMP, etc. CDNs typically provide
> services to multiple Content Service Providers (CSPs).
>
> CDNs provide numerous benefits: a shared platform for multi-service content
> delivery, reduced transmission costs for cacheable content, improved quality
> of experience for end users and increased robustness of delivery. For these
> reasons they are frequently used for large-scale content delivery.
>
> As a result of the significant growth in content delivered over IP
> networks, existing CDN providers are scaling up their infrastructure and
> many Network Service Providers and Enterprise Service Providers are
> deploying their own CDNs. Subject to the policy of the CSP, it is generally
> desirable that a given item of content can be delivered to an end
> user regardless of that end user's location or attachment network. This
> creates a need for interconnecting (previously) standalone CDNs so they can
> interoperate and collectively behave as a single delivery infrastructure.
>
> The goal of the CDNI Working Group is to allow the interconnection of
> separately administered CDNs in support of the end-to-end delivery of
> content from CSPs through multiple CDNs and ultimately to end users (via
> their respective User Agents). The CDNI WG aims at delivering a targeted,
> deployable solution in a short timeframe (18-24 months) as needed by
> the industry. It is expected that the CDNI interfaces will be realized using
> existing IETF protocols for transport and message exchange, and using
> existing object notation grammars/languages for the definition of CDNI
> objects and semantics. In the event that protocol extensions or new
> protocols are deemed necessary by the WG, the WG will recharter.
>
> - A "framework" document providing a description of the different
> components of the CDNI solution and how they interact with and relate to one
> another.
>
> - A "requirements" document. This document lists the requirements for CDNI
> architecture and the protocols to support it. In particular, this document
> will focus on identifying a reasonable set of more urgent and important
> requirements that will be addressed in the initial set of CDNI protocols and
> solutions produced by the working group.
>
>         o CDNI request-routing systems. In particular, this interface will
> allow an upstream CDN request routing system to obtain from the downstream
> CDN the information necessary to perform request redirection.
>
>         o CDNI metadata distribution systems. This interface will allow the
> CDNs to exchange distribution metadata of inter-CDN scope. Distribution
> metadata refers to the subset of content metadata that is relevant to the
> distribution of the content and therefore is to be processed by CDNs (for
> example, this may include information enabling: content acquisition,
> geo-blocking, enforcement of availability windows or access control).
>
>         o CDNI logging systems. This interface will allow CDN logging
> systems to exchange logging information associated with actions that are
> relevant across CDNs (such as content distribution, content delivery and
> content routing actions) for purposes of accounting, analytics, monitoring,
> etc.
>
>         o CDN control systems. In particular, this interface will allow an
> upstream CDN to remove or invalidate content in a downstream CDN.
>
> The WG will discuss and address the security (including threat model),
> management and operational issues specific to CDNI, inside the above
> documents and specifications.
>
> The working group will only define solutions for aspects of the CDN
> Interconnection problem space that require direct communication or
> interoperation between CDNs.
>
> The WG will work with other WGs to assess, and where appropriate, leverage
> protocols developed by those WGs, in order to realize the CDNI requirements
> and CDNI interfaces. For example, the WG may assess the suitability of the
> ALTO protocol as a protocol to enable downstream CDNs to exchange
> information which may aid an upstream CDN with making CDNI request routing
> decisions.
>
>
> Goals & Milestones
> ==================
>
> WG Creation + 18 months:       Submit specification of the CDNI Request
> Routing interface to IESG as Proposed Standard
> WG Creation + 24 months:       Submit specification of the CDNI Metadata
> Distribution interface to IESG as Proposed Standard

---

From: Francois Le Faucheur <[email-masked]>
Date: Fri, 8 Apr 2011 10:56:09 +0200

Hi Bhumip,

On 8 Apr 2011, at 02:13, Bhumip Khasnabish wrote:

> You mean  interconnection of TWO separately administered CDNs, right . .anything beyond two is out of scope . .

I believe the CDNI solution needs to allow systems involving multiple CDNs. For example, a given upstream CDN needs to be able to make use of more than one downstream CDNs (eg each covering a different geographical footprint). 
As discussed on the list earlier, it _may_ be possible to specify a simpler initial solution if we were to place restrictions on the topologies of CDNs to be supported (e.g. do not support cascaded CDNs - see http://www.ietf.org/mail-archive/web/cdni/current/msg00224.html), but we felt this is something the WG would have to make a call on, once the trade-offs are better understood.

So I'd recommend we keep the charter text open and stating the generic target (i.e. support systems with multiple CDNs).

There was a discussion during the BOF about the fact that "CDN Federation" was outside the scope of CDNI. This may have created some confusion since "federation" means different things to different people. In my mind, "CDN Federation" implies particular modes of operation across the multiple interconnected CDNs (e.g. they share some common policies/services etc). While this may be one way that a CDNI solution would be used, this seems beyond what a CDNI WG would deal with. In other words, a potential CDNI WG would define how a given CDN inter-operate with another CDN for delivery, with awareness that there may be multiple such CDN-to-CDN inter-operation in the overall system and therefore that delivery features need to operate in multi-CDN systems; but a CDNI WG should not concern itself with the policies/services that may, or may not, be offered on top of that multi-CDN system.

Cheers

Francois

>  
>  
> >The goal of the CDNI Working Group is to allow the >interconnection of separately administered CDNs
> 
>  
> On Thu, Apr 7, 2011 at 12:59 PM, Francois Le Faucheur <[email-masked]> wrote:
> Folks,
> 

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: Bhumip Khasnabish <[email-masked]>
Date: Fri, 8 Apr 2011 06:12:40 -0400

Hi Francois,

You already agreed that  "*Federation"* is out of scope. I am just reminding
you that and requesting to put it in the charter. PLS see below..

+ ?: CDNI only talks about interconnecting two CDNs, but is "CDN Federation"
in scope?
+ *Nabil*: CDNI is about interconnection only. *Federation is a more
controlled environment which requires more policies.
*+ *Francois*: CDNI only defines how to interconnect two CDNs together. This
can then be used in different ways, such as allow many CDNs to interconnect
to many CDNs. *But the notion of "CDN Federation" itself is not in the
scope.
*

>>interconnection of separately administered CDNs

*Also, what about trust*? Do you assume that these two "separately
administered CDNs" trust each other? Pls clarify.

Thanks.

Best.

Bhumip

On Fri, Apr 8, 2011 at 4:56 AM, Francois Le Faucheur <[email-masked]>wrote:

> I believe the CDNI solution needs to allow systems involving multiple CDNs.
> For example, a given upstream CDN needs to be able to make use of more than
> one downstream CDNs (eg each covering a different geographical footprint).
> As discussed on the list earlier, it _may_ be possible to specify a simpler
> initial solution if we were to place restrictions on the topologies of CDNs
> to be supported (e.g. do not support cascaded CDNs - see
> http://www.ietf.org/mail-archive/web/cdni/current/msg00224.html), but we
> felt this is something the WG would have to make a call on, once the
> trade-offs are better understood.
>
> So I'd recommend we keep the charter text open and stating the generic
> target (i.e. support systems with multiple CDNs).
>
> There was a discussion during the BOF about the fact that "CDN Federation"
> was outside the scope of CDNI. This may have created some confusion since
> "federation" means different things to different people. In my mind, "CDN
> Federation" implies particular modes of operation across the multiple
> interconnected CDNs (e.g. they share some common policies/services etc).
> While this may be one way that a CDNI solution would be used, this seems
> beyond what a CDNI WG would deal with. In other words, a potential CDNI WG
> would define how a given CDN inter-operate with another CDN for delivery,
> with awareness that there may be multiple such CDN-to-CDN inter-operation in
> the overall system and therefore that delivery features need to operate in
> multi-CDN systems; but a CDNI WG should not concern itself with the
> policies/services that may, or may not, be offered on top of that multi-CDN
> system.
>
> Cheers
>
> Francois
>
>
>
>> CDNs provide numerous benefits: a shared platform for multi-service
>> content delivery, reduced transmission costs for cacheable content, improved
>> quality of experience for end users and increased robustness of delivery.
>> For these reasons they are frequently used for large-scale content delivery.
>>
>> o CDNI metadata distribution systems. This interface will allow the CDNs
>> to exchange distribution metadata of inter-CDN scope. Distribution metadata
>> CDNs provide numerous benefits: a shared platform for multi-service
>> content delivery, reduced transmission costs for cacheable content, improved
>> quality of experience for end users and increased robustness of delivery.
>> For these reasons they are frequently used for large-scale content delivery.
>>
>>         o CDNI metadata distribution systems. This interface will allow
>> the CDNs to exchange distribution metadata of inter-CDN scope. Distribution
>     *
> Francois Le Faucheur*
> *Distinguished Engineer*
> *Corporate Development*
> 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.
> This email may contain confidential and privileged material for the sole
> use of the intended recipient. Any review, use, distribution or disclosure
> by others is strictly prohibited. If you are not the intended recipient (or
> authorized to receive for the recipient), please contact the sender by reply
> email and delete all copies of this message.
>
> Cisco Systems France, Société à responsabiité limitée, Rue Camille
> Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Moulineaux,
> Au capital de 91.470 €, 349 166 561 RCS Nanterre, Directeur de la
> publication: Jean-Luc Michel Givone.
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 8 Apr 2011 13:18:47 +0300

On Apr 8, 2011, at 1:12 PM, Bhumip Khasnabish wrote:

> Also, what about trust? Do you assume that these two "separately administered CDNs" trust each other? Pls clarify.
> 

Trust is a fuzzy term. Typically, you have to indicate for what purpose they trust each other.

---

From: Bhumip Khasnabish <[email-masked]>
Date: Fri, 8 Apr 2011 06:24:17 -0400

Right. Currently, it is not defined in the charter and hence open to
different interpretations by different CDN operators .. so we need to
clarify it  I guess..

On Fri, Apr 8, 2011 at 6:18 AM, Hannes Tschofenig <[email-masked]
> wrote:

> > Also, what about trust? Do you assume that these two "separately

---

From: Francois Le Faucheur <[email-masked]>
Date: Fri, 8 Apr 2011 14:24:59 +0200

On 8 Apr 2011, at 12:12, Bhumip Khasnabish wrote:

> Hi Francois,
>  
> You already agreed that  "Federation" is out of scope. I am just reminding you that and requesting to put it in the charter. PLS see below..

I don't think the text can simply say that CDN "Federation" is out of scope as "Federation" is not a well understood term. So, how about we add in the draft charter, under  "In particular, the WG will not define:"  something like:
"
	* overarching policies to be followed by all the interconnected CDNs
"

Francois

>  
> + ?: CDNI only talks about interconnecting two CDNs, but is "CDN Federation" in scope?
> + Nabil: CDNI is about interconnection only. Federation is a more controlled environment which requires more policies.
> + Francois: CDNI only defines how to interconnect two CDNs together. This can then be used in different ways, such as allow many CDNs to interconnect to many CDNs. But the notion of "CDN Federation" itself is not in the scope.
>  
> On Fri, Apr 8, 2011 at 4:56 AM, Francois Le Faucheur <[email-masked]> wrote:
> Hi Bhumip,
> 

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: Francois Le Faucheur <[email-masked]>
Date: Fri, 8 Apr 2011 14:30:11 +0200

> Trust is a fuzzy term. Typically, you have to indicate for what purpose they trust each other. 

With respect to the draft charter, the proposal is that the charter explicitly mentions that the trust model be documented in one of the deliverables.

Latest posted draft charter says:
"
This document will also include a "threat analysis" discussing the security concerns and threats, the trust model and privacy issues specific to CDNI.
"

It sounds like you guys are agreeing this needs to be discussed & documented.

Thanks

Francois

---

From: Eric Burger <[email-masked]>
Date: Fri, 8 Apr 2011 15:42:57 -0400

While Federation in not in scope, what is the value of explicitly saying it is out of scope?  Will that not show up in the milestones and the fact the focus is on two-party interconnect?

It is one thing to say we are not going to work on Federation.  It is another to say we are going to ensure Federation cannot happen.

---

From: "Woundy, Richard" <[email-masked]>
Date: Fri, 8 Apr 2011 20:04:27 +0000

(not wearing my Bof co-chair hat)

I agree with Eric -- what issues are we solving by explicitly saying in the charter that CDN federation is out of scope? Or by saying that CDN interconnection is between *two* CDNs?

In the meeting, Eric raised the issue of 'transitive trust', and the meeting participants seemed to think that this was a worthy issue to discuss. But 'transitive trust' implies at least *three* CDNs, right?

I am worried that we are trying to constrain the charter in ways that preclude future business models. Some people see opportunities for bi-lateral business arrangements with CDNI, others see opportunities for multi-lateral business arrangements. There are pros and cons for each model. Do you have compelling reasons why the IETF needs to choose the winning business model right now? What if the right business model changes over time?

And as a reminder, the IETF doesn't specify business models. It specifies open interfaces that might be used by various business models.

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Burger
Sent: Friday, April 08, 2011 3:43 PM
To: Bhumip Khasnabish
Cc: [email-masked]
Subject: Re: [CDNi] Updated version of the CDNI charter

On Apr 8, 2011, at 6:12 AM, Bhumip Khasnabish wrote:

>> - A "use case" document describing scenarios for usage and 
>> applications of the CDNI solution and protocols
>> 
>> WG Creation + 6 months:  Submit CDNI problem statement to IESG as 
>> Informational WG Creation + 9 months:  Submit CDNI use cases to IESG 
>> as Informational WG Creation + 12 months:  Submit CDNI framework to 
>> IESG as Informational WG Creation + 12 months:  Submit CDNI 
>> requirements to IESG as Informational WG Creation + 18 months:  
>> Submit specification of the CDNI Request Routing interface to IESG as 
>> Proposed Standard WG Creation + 18 months:  Submit specification of 
>> the CDNI Logging interface to IESG as Proposed Standard WG Creation + 
>> 18 months:  Submit specification of the CDNI Control interface to 
>> IESG as proposed Standard WG Creation + 24 months:  Submit 
>> specification of the CDNI Metadata Distribution interface to IESG as 
>> Proposed Standard WG Creation + 24 months:  Recharter or dissolve
>> 
>> 
>> 
>> 
>>> - A "use case" document describing scenarios for usage and 
>>> applications of the CDNI solution and protocols
>>>

---

From: <[email-masked]>
Date: Fri, 8 Apr 2011 21:17:32 +0100

(not wearing any hat)

I agree with Rich + Eric. I don't understand the gain from explicitly declaring "federation" out of scope, I think that constraining the charter in this way seems to be more an attempt to address concern about topology or qty of CDN rather than the business model as I currently understand it to be. Either way I don't see a problem with leaving the Charter open in this respect, then let the business model evolve....hopefully consuming CDNI.

Grant

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Woundy, Richard [[email-masked]]
Sent: 08 April 2011 21:04
To: Eric Burger; Bhumip Khasnabish
Cc: [email-masked]
Subject: Re: [CDNi] Updated version of the CDNI charter

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Burger
Sent: Friday, April 08, 2011 3:43 PM
To: Bhumip Khasnabish
Cc: [email-masked]
Subject: Re: [CDNi] Updated version of the CDNI charter

On Apr 8, 2011, at 6:12 AM, Bhumip Khasnabish wrote:

> 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 EUR, 349 166 561 RCS Nanterre, Directeur de la publication: Jean-Luc Michel Givone.
>

---

From: "Woundy, Richard" <[email-masked]>
Date: Fri, 8 Apr 2011 20:17:58 +0000

(not wearing co-chair hat)

> Also, what about trust? Do you assume that these two "separately administered CDNs" trust each other? Pls clarify.

Your question about ‘trust’ is ambiguous.

Let’s use a practical example. We had CDNI presentations from a Verizon employee (Nabil Bitar ) and a Comcast employee (Yiu Lee). In the US, Verizon and Comcast compete vigorously for broadband/phone/TV customers. But I could imagine that Verizon and Comcast might cooperate on CDN interconnection, perhaps to reduce each other’s network costs and/or to provide higher quality service to their respective customers.

So in this example, do Verizon and Comcast trust each other? Or do they not?

There isn’t a simple binary answer (yes / no) to the question. That’s why the proposed charter says that we need to work on a trust model.

-- Rich

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bhumip Khasnabish
Sent: Friday, April 08, 2011 6:13 AM
To: Francois Le Faucheur
Cc: [email-masked]
Subject: Re: [CDNi] Updated version of the CDNI charter

Hi Francois,

Thanks.

Best.

Bhumip

On Fri, Apr 8, 2011 at 4:56 AM, Francois Le Faucheur <[email-masked]<mailto:[email-masked]>> wrote:
Hi Bhumip,

Cheers

Francois

>The goal of the CDNI Working Group is to allow the >interconnection of separately administered CDNs

On Thu, Apr 7, 2011 at 12:59 PM, Francois Le Faucheur <[email-masked]<mailto:[email-masked]>> wrote:
Folks,

Goals & Milestones
==================

Folks,

-- Rich and Francois

Goals & Milestones
==================

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

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

[https://mail.google.com/mail/?ui=2&ik=86562dfa19&view=att&th=12f3492bac4a73e7&attid=0.2&disp=emb&realattid=cbd722cd20315220_0.1.1&zw]

Francois Le Faucheur
Distinguished Engineer
Corporate Development
[email-masked]<mailto:[email-masked]>
Phone: +33 49 723 2619<tel:%2B33%2049%20723%202619>
Mobile: +33 6 19 98 50 90<tel:%2B33%206%2019%2098%2050%2090>

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

[https://mail.google.com/mail/?ui=2&ik=86562dfa19&view=att&th=12f3492bac4a73e7&attid=0.1&disp=emb&realattid=cbd722cd20315220_0.1.2&zw]

 Think before you print.

---

From: Benjamin Niven-Jenkins <[email-masked]>
Date: Fri, 8 Apr 2011 23:04:07 +0100

+1

I think the point being made in the BoF is that the expectation is that any information exchange would happen between two parties at a time (e.g. a client/server request/response mechanism would be a sufficient solution for exchanging CDNI information), not that the scope is limited to interconnection of only two CDNs.

I don't see any need to write that explicitly in the charter though.

IMO the charter is fine as it is and is good to go to the ADs/IESG for approval.

Ben

---

From: Bhumip Khasnabish <[email-masked]>
Date: Sat, 9 Apr 2011 21:28:48 -0400

I see. Now if one CDN operator connects to another CDN operator without
pre-defined

(a) security of the signaling/control interface, and
(b) policy for volume/type/... of content exchange,

this could that open up both trust and regulatory concerns ...

On Fri, Apr 8, 2011 at 4:17 PM, Woundy, Richard <
[email-masked]> wrote:

> >* Also, what about trust*? Do you assume that these two "separately
> Let’s use a practical example. We had CDNI presentations from a Verizon
> employee (Nabil Bitar ) and a Comcast employee (Yiu Lee). In the US, Verizon
> and Comcast compete vigorously for broadband/phone/TV customers. But I could
> imagine that Verizon and Comcast might cooperate on CDN interconnection,
> perhaps to reduce each other’s network costs and/or to provide higher
> quality service to their respective customers.
>
>
>
> There isn’t a simple binary answer (yes / no) to the question. That’s why
> the proposed charter says that we need to work on a trust model.
>
>
>
> -- Rich
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *Bhumip Khasnabish
> *Sent:* Friday, April 08, 2011 6:13 AM
> *To:* Francois Le Faucheur
>
> *Cc:* [email-masked]
> *Subject:* Re: [CDNi] Updated version of the CDNI charter
>
>
>
> Hi Francois,
>
>
>
> You already agreed that  "*Federation"* is out of scope. I am just
> reminding you that and requesting to put it in the charter. PLS see below..
>
>
>
> controlled environment which requires more policies.**
> *+ *Francois*: CDNI only defines how to interconnect two CDNs together.
> This can then be used in different ways, such as allow many CDNs to
> interconnect to many CDNs. *But the notion of "CDN Federation" itself is
> not in the scope.*
>
>
>
> Informational
> Informational

---

From: Bhumip Khasnabish <[email-masked]>
Date: Sat, 9 Apr 2011 21:44:44 -0400

>>*network* costs and/or to provide higher quality service to their
>>respective customers.
Layer 1 to 3 (physical to network) is out of scope, because the charter's
opening statement says that
"A Content Delivery Network (CDN) is an infrastructure of network elements
operating at *layer 4 through layer 7*, arranged for the efficient
distribution and delivery of digital content."

.. the word "network" should probably be taken out of this statement ...

---

From: "Woundy, Richard" <[email-masked]>
Date: Sun, 10 Apr 2011 18:29:44 +0000

>.. the word "network" should probably be taken out of this statement ...

I provided a statement in email about why two competitors might cooperate on CDNI, even as they compete in other areas. I didn't suggest that CDNI should change anything at the network layer, and I never intended to.

I think I understand the charter text. I helped write it.

________________________________
From: Bhumip Khasnabish [[email-masked]]
Sent: Saturday, April 09, 2011 9:44 PM
To: Woundy, Richard
Cc: Francois Le Faucheur; [email-masked]
Subject: Re: [CDNi] Updated version of the CDNI charter

>>network costs and/or to provide higher quality service to their >>respective customers.
Layer 1 to 3 (physical to network) is out of scope, because the charter's opening statement says that
"A Content Delivery Network (CDN) is an infrastructure of network elements operating at layer 4 through layer 7, arranged for the efficient distribution and delivery of digital content."

On Fri, Apr 8, 2011 at 4:17 PM, Woundy, Richard <[email-masked]<mailto:[email-masked]>> wrote:
(not wearing co-chair hat)

-- Rich

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Bhumip Khasnabish
Sent: Friday, April 08, 2011 6:13 AM
To: Francois Le Faucheur

Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] Updated version of the CDNI charter

Hi Francois,

Thanks.

Best.

Bhumip

Cheers

Francois

Goals & Milestones
==================

Folks,

-- Rich and Francois

Goals & Milestones
==================

[X]

Francois Le Faucheur
Distinguished Engineer
Corporate Development

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

[X]

 Think before you print.

---

From: "Lee, Yiu" <[email-masked]>
Date: Mon, 11 Apr 2011 01:23:34 +0000

I respectfully disagree to take out the word "network". CDN is a "network". In this statement, the network refers to CDN network. I don't see any problem of it.

/Yiu

From: Bhumip Khasnabish <[email-masked]<mailto:[email-masked]>>
Date: Sat, 9 Apr 2011 21:44:44 -0400
To: Richard Woundy <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [CDNi] Updated version of the CDNI charter

-- Rich

Hi Francois,

Thanks.

Best.

Bhumip

Cheers

Francois

Goals & Milestones
==================

Folks,

-- Rich and Francois

Goals & Milestones
==================

[X]

Francois Le Faucheur
Distinguished Engineer
Corporate Development

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

[X]

 Think before you print.

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

---

From: "Lee, Yiu" <[email-masked]>
Date: Mon, 11 Apr 2011 01:27:00 +0000

I can imagine two CDN providers would have pre-arranged mutual agreement before interconnecting. I don't see a business case two CDNs would connect without pre-arrangement. That said, it is up to the WG to decide if they want to solve this problem or not. In the BoF, people agreed that we would need to document the transitive trust model. This is in scope.

/Yiu

Date: Sat, 9 Apr 2011 21:28:48 -0400

I see. Now if one CDN operator connects to another CDN operator without pre-defined

-- Rich

Hi Francois,

Thanks.

Best.

Bhumip

Cheers

Francois

Goals & Milestones
==================

Folks,

-- Rich and Francois

Goals & Milestones
==================

[X]

Francois Le Faucheur
Distinguished Engineer
Corporate Development

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

[X]

 Think before you print.

---

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 11 Apr 2011 11:06:03 +0200

Bhumip,

I suggest we clearly distinguish between:
	*A* discussions on what the charter needs to say about CDNI trust model
	*B* discussions about CDNI trust models (and examples of issues/concerns that need to be covered in future CDNI deliverables).

With respect to *A*, I believe there is violent agreement that the charter needs to mention that the CDNI trust model needs to be discussed and documented in deliverables (which the draft charter already does). Let us know if you see differently.

With respect to *B*, starting discussion on the trust model topic itself is all fine, but I recommend you use a different Subject header in order to make it clear that this does not relate to the draft charter discussion.

Thanks

Francois

On 11 Apr 2011, at 03:27, Lee, Yiu wrote:

> From: Bhumip Khasnabish <[email-masked]>
> To: Richard Woundy <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> On Fri, Apr 8, 2011 at 4:17 PM, Woundy, Richard <[email-masked]> wrote:
> _______________________________________________ CDNi mailing list [email-masked] https://www.ietf.org/mailman/listinfo/cdni

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: David R Oran <[email-masked]>
Date: Mon, 11 Apr 2011 16:37:31 -0400

Crawling out of my hole for a moment...

Someone in an earlier post seemed to be saying that you didn't need to worry about trust transitivity if you only had 2 CDNs peering.

I suspect that is wrong. The original content owner is part of the trust chain, so unless the model is that the content owner has a bi-lateral trust agreement with each CDN before these two CDNs are allowed to peer (fairly dubious and a gigantic limitation on CDNi's utility), then transitivity raises its head in even the simplest of CDNi topologies.

Back to your regularly scheduled streaming session...

DaveO.

---

From: "Lee, Yiu" <[email-masked]>
Date: Mon, 11 Apr 2011 22:17:49 +0000

Hi Bhumip,

I don't think we have disagreement here. What I tried to say is "Network" this term in CDNI context it the interconnection network built by CDNs. It doesn't necessarily refer to Layer-3.

Regards,
Yiu

From: Bhumip Khasnabish <[email-masked]<mailto:[email-masked]>>
Date: Mon, 11 Apr 2011 18:03:23 -0400
To: Microsoft Office User <[email-masked]<mailto:[email-masked]>>
Cc: Richard Woundy <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [CDNi] Updated version of the CDNI charter

If I understood correctly, the focus is  interconnection (layer 4 to 7) of the CDNs, not the network that is used for content distribution/delivery.

On Sun, Apr 10, 2011 at 9:23 PM, Lee, Yiu <[email-masked]<mailto:[email-masked]>> wrote:
I respectfully disagree to take out the word "network". CDN is a "network". In this statement, the network refers to CDN network. I don't see any problem of it.

/Yiu

-- Rich

Hi Francois,

Thanks.

Best.

Bhumip

Cheers

Francois

Goals & Milestones
==================

Folks,

-- Rich and Francois

Goals & Milestones
==================

[X]

Francois Le Faucheur
Distinguished Engineer
Corporate Development

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

[X]

 Think before you print.

---

From: Bhumip Khasnabish <[email-masked]>
Date: Mon, 11 Apr 2011 18:03:23 -0400

If I understood correctly, the focus is  *interconnection* (layer 4 to 7) of
the CDNs, not the network that is used for content distribution/delivery.

On Sun, Apr 10, 2011 at 9:23 PM, Lee, Yiu <[email-masked]> wrote:

>  I respectfully disagree to take out the word "network". CDN is a
> "network". In this statement, the network refers to CDN network. I don't see
> any problem of it.
>
> /Yiu
>
>> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
>> Of *Bhumip Khasnabish
>> I believe the CDNI solution needs to allow systems involving multiple
>> CDNs. For example, a given upstream CDN needs to be able to make use of more
>> than one downstream CDNs (eg each covering a different geographical
>> footprint).
>>
>> As discussed on the list earlier, it _may_ be possible to specify a
>> simpler initial solution if we were to place restrictions on the topologies
>> of CDNs to be supported (e.g. do not support cascaded CDNs - see
>   _______________________________________________ CDNi mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/cdni
>

---

From: Bhumip Khasnabish <[email-masked]>
Date: Mon, 11 Apr 2011 18:01:50 -0400

Francois ,

Without getting carried away, I think there is a need to define "the" *
mechanism* to *establish* a trusted
*interconnection* between two CDN providers .. and any two CDN providers
should be able to use it
via appropriate bilateral agreement for seamless delivery of content to the
end user.

Anything else beyond the basic minimum can be developed later.
Pls let me know what you think. Thanks.
On Mon, Apr 11, 2011 at 5:06 AM, Francois Le Faucheur <[email-masked]>wrote:

> *B* discussions about CDNI trust models (and examples of issues/concerns
> that need to be covered in future CDNI deliverables).
>
> With respect to *A*, I believe there is violent agreement that the charter
> needs to mention that the CDNI trust model needs to be discussed and
> documented in deliverables (which the draft charter already does). Let us
> know if you see differently.
>
> With respect to *B*, starting discussion on the trust model topic itself is
> all fine, but I recommend you use a different Subject header in order to
> make it clear that this does not relate to the draft charter discussion.
>
> Thanks
>
> Francois
>
>
>
>  I can imagine two CDN providers would have pre-arranged mutual agreement
> before interconnecting. I don't see a business case two CDNs would connect
> without pre-arrangement. That said, it is up to the WG to decide if they
> want to solve this problem or not. In the BoF, people agreed that we would
> need to document the transitive trust model. This is in scope.
>
> /Yiu
>
>>  There was a discussion during the BOF about the fact that "CDN
>> Federation" was outside the scope of CDNI. This may have created some
>> confusion since "federation" means different things to different people. In
>> my mind, "CDN Federation" implies particular modes of operation across the
>> multiple interconnected CDNs (e.g. they share some common policies/services
>> etc). While this may be one way that a CDNI solution would be used, this
>> seems beyond what a CDNI WG would deal with. In other words, a potential
>> CDNI WG would define how a given CDN inter-operate with another CDN for
>> delivery, with awareness that there may be multiple such CDN-to-CDN
>> inter-operation in the overall system and therefore that delivery features
>> need to operate in multi-CDN systems; but a CDNI WG should not concern
>> itself with the policies/services that may, or may not, be offered on top of
>> that multi-CDN system.
>>
>>  Cheers
>>
>>  Francois
>>
>>
>>
>>

---

From: "Woundy, Richard" <[email-masked]>
Date: Mon, 11 Apr 2011 22:39:12 +0000

> Someone in an earlier post seemed to be saying that you didn't need to worry about trust transitivity if you only had 2 CDNs peering.

That was me, and you make a good point.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David R Oran
Sent: Monday, April 11, 2011 4:38 PM
To: [email-masked]
Subject: Re: [CDNi] Trust Model

DaveO.

---

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 14 Apr 2011 11:07:41 +0200

Hello,

The on-line draft charter (http://www.ietf.org/proceedings/80/slides/cdni-9.txt) has been updated to reflect the charter discussion on the list after the BOF.

Changes include:
	* additional statement that CDNI WG will collaborate with relevant external groups such as UltraViolet.
	* editorials on how CDNI interfaces are listed
	* editorials related to "content distribution metadata" terminology
	* editorials related to intro text in first paragraph giving examples of streaming protocols

No changes were done as a result of the "CDN Federation" thread since more voices argued that it may be counter-productive and unnecessarily restrictive to attempt to rule out something that is not a well understood notion.

No changes were done as a result of the "trust model" thread since the draft charter already addresses the concern of documenting the CDNI trust model.

Francois & Rich

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: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 14 Apr 2011 15:04:05 +0100

Francois,

I have read the latest charter and in my opinion it accurately describes and scopes the work required of a CDNI WG. It is ready to go to our ADs for discussion with the IESG.

Ben

---

From: He Xiaoyan <[email-masked]>
Date: Fri, 15 Apr 2011 17:40:29 +0800

Hi Francois and all,

Although thinking most content of the current charter is clearly and well
defined but I still have a question on the description of the CDNi control
interface, hope it is not too late to raise.

In the current charter it says that the CDNi control interface will allow an
upstream CDN to remove or invalidate content in a downstream CDN. And in the
requirement I-D,  the Req 15 is to reflect this I believe, there is also Req
51 and Req 52  in metadata API describe actions of addition and modification
of objects. Which confused me, In my opinion, actions like removal or
invalidate objects has no essential difference with addition and
modification. They all can be categorized as management actions, right?  Why
we put some of them under the Control API while others under the Metadata
API?

If the above comment is valid, I propose to merge the description” In
particular, this interface will allow an upstream CDN to remove or
invalidate content in a downstream CDN.”into metadata API part.

Or move the “content acquisition” description in metadata API to control
API.

Thanks.

Best Regards

Xiaoyan(Susan) He

  _____  

发件人: [email-masked] [mailto:[email-masked]] 代表 Francois
Le Faucheur
发送时间: 2011年4月14日 17:08
收件人: [email-masked]
主题: Re: [CDNi] Updated version of the CDNI charter

Hello,

The on-line draft charter (http://www.ietf.org/proceedings/80/slides/cdni-9.
txt) has been updated to reflect the charter discussion on the list after
the BOF.

Changes include:

       * additional statement that CDNI WG will collaborate with relevant
external groups such as UltraViolet.

       * editorials related to intro text in first paragraph giving examples
of streaming protocols

No changes were done as a result of the "CDN Federation" thread since more
voices argued that it may be counter-productive and unnecessarily
restrictive to attempt to rule out something that is not a well understood
notion.

No changes were done as a result of the "trust model" thread since the draft
charter already addresses the concern of documenting the CDNI trust model.

Francois & Rich

Folks,

Below is an updated version of the CDNI draft charter reflecting the charter
discussion/edits during the BOF.

Please bring forward the additional comments you have before this draft
charter is assessed by the ADs.

Francois & Rich

As a result of the significant growth in content delivered over IP networks,
existing CDN providers are scaling up their infrastructure and many Network
Service Providers and Enterprise Service Providers are deploying their own
CDNs. Subject to the policy of the CSP, it is generally desirable that a
given item of content can be delivered to an end user regardless of that end
user's location or attachment network. This creates a need for
interconnecting (previously) standalone CDNs so they can interoperate and
collectively behave as a single delivery infrastructure.

- A "problem statement" document providing a description of the problem and
a common terminology.

- A "use case" document describing scenarios for usage and applications of
the CDNI solution and protocols

- A "framework" document providing a description of the different components
of the CDNI solution and how they interact with and relate to one another.
This document will also include a "threat analysis" discussing the security
concerns and threats, the trust model and privacy issues specific to CDNI.

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

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

       o CDNI logging systems. This interface will allow CDN logging systems
to exchange logging information associated with actions that are relevant
across CDNs (such as content distribution, content delivery and content
routing actions) for purposes of accounting, analytics, monitoring, etc.

- New protocols for ingestion of content or metadata between a CSP and a
CDN.

Goals & Milestones
==================

WG Creation + 6 months:   Submit CDNI problem statement to IESG as
Informational
WG Creation + 9 months:   Submit CDNI use cases to IESG as Informational
WG Creation + 12 months:        Submit CDNI framework to IESG as
Informational
WG Creation + 12 months:        Submit CDNI requirements to IESG as
Informational
WG Creation + 18 months:        Submit specification of the CDNI Request
Routing interface to IESG as Proposed Standard
WG Creation + 18 months:        Submit specification of the CDNI Logging
interface to IESG as Proposed Standard
WG Creation + 18 months:        Submit specification of the CDNI Control
interface to IESG as proposed Standard
WG Creation + 24 months:        Submit specification of the CDNI Metadata
Distribution interface to IESG as Proposed Standard
WG Creation + 24 months:        Recharter or dissolve

Folks,
 
I wanted everyone to have an updated version of the CDNI draft charter
below, for discussion at the BOF shortly. This is based on input from many
people this week, including people that attended the informal CDNI gathering
last night. It is available online at
<http://www.ietf.org/proceedings/80/slides/cdni-9.txt>, and has been updated
on the BOF wiki <http://trac.tools.ietf.org/bof/trac/wiki/WikiStart>.
 
The meeting materials for the BOF are available here:
<https://datatracker.ietf.org/meeting/80/materials.html#wg-cdni>.
 
-- Rich and Francois

 

As a result of the significant growth in content delivered over IP networks,
existing CDN providers are scaling up their infrastructure and many Network
Service Providers and Enterprise Service Providers are deploying their own
CDNs. Subject to the policy of the CSP, it is generally desirable that a
given item of content can be delivered to an end user regardless of that end
user's location or attachment network. This creates a need for
interconnecting (previously) standalone CDNs so they can interoperate and
collectively behave as a single delivery infrastructure.

 
- A "problem statement" document providing a description of the problem and
a common terminology.
 
- A "use case" document describing scenarios for usage and applications of
the CDNI solution and protocols
 
- A "framework" document providing a description of the different components
of the CDNI solution and how they interact with and relate to one another.

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

 

 
 
- New protocols for ingestion of content or metadata between a CSP and a
CDN.

Goals & Milestones
==================
 
WG Creation + 6 months:        Submit CDNI problem statement to IESG as
Informational
WG Creation + 9 months:        Submit CDNI use cases to IESG as
Informational
WG Creation + 12 months:       Submit CDNI framework to IESG as
Informational
WG Creation + 12 months:       Submit CDNI requirements to IESG as
Informational
WG Creation + 18 months:       Submit specification of the CDNI Request
Routing interface to IESG as Proposed Standard
WG Creation + 18 months:       Submit specification of the CDNI Logging
interface to IESG as Proposed Standard
WG Creation + 18 months:       Submit specification of the CDNI Control
interface to IESG as proposed Standard
WG Creation + 24 months:       Submit specification of the CDNI Metadata
Distribution interface to IESG as Proposed Standard
WG Creation + 24 months:       Recharter or dissolve

 

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

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

 Think before you print.

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

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

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 15 Apr 2011 12:48:16 +0100

On 15 Apr 2011, at 10:40, He Xiaoyan wrote:

> Hi Francois and all,
>  
> Although thinking most content of the current charter is clearly and well defined but I still have a question on the description of the CDNi control interface, hope it is not too late to raise.
>  
> In the current charter it says that the CDNi control interface will allow an upstream CDN to remove or invalidate content in a downstream CDN. And in the requirement I-D,  the Req 15 is to reflect this I believe, there is also Req 51 and Req 52  in metadata API describe actions of addition and modification of objects. Which confused me, In my opinion, actions like removal or invalidate objects has no essential difference with addition and modification. They all can be categorized as management actions, right?  Why we put some of them under the Control API while others under the Metadata API?

Requirement 51 & 52 relate to the addition/modification/removal of the CDNI Metadata associated with the content, not the actual content itself.

Requirement 15 relates to removal/invalidation of the content itself.

Ben

---

From: He Xiaoyan <[email-masked]>
Date: Mon, 18 Apr 2011 10:27:26 +0800

Hi Ben,

In the latest I-D draft"draft-lefaucheur-cdni-requirements-01", Req15
relates not only to content but also metadata. And Req15 is just an example,
you could also find that Req 17 also relates to metadata but is putting
under the control API now.

So, I think first consensus is needed on the relations of APIs (control API
and metadata API) and data( metadata and content itself), if you proposed
control API is related to content and metadata API relate to the CDNI
metadata, that's OK for me. Then the charter needs to be revised to reflect
this, e.g. move the "content acquisition" out of the control API and add
content acquisition description to the metadata API,e.g." In particular,
this interface will allow an upstream CDN to add, remove or invalidate
content in a downstream CDN". 

Best Regards

Xiaoyan(Susan) He

-----邮件原件-----
发件人: Ben Niven-Jenkins [mailto:[email-masked]] 
发送时间: 2011年4月15日 19:48
收件人: He Xiaoyan
抄送: 'Francois Le Faucheur'; [email-masked]
主题: Re: [CDNi] 答复: Updated version of the CDNI charter

> In the current charter it says that the CDNi control interface will allow
an upstream CDN to remove or invalidate content in a downstream CDN. And in
the requirement I-D,  the Req 15 is to reflect this I believe, there is also
Req 51 and Req 52  in metadata API describe actions of addition and
modification of objects. Which confused me, In my opinion, actions like
removal or invalidate objects has no essential difference with addition and
modification. They all can be categorized as management actions, right?  Why
we put some of them under the Control API while others under the Metadata
API?

Requirement 51 & 52 relate to the addition/modification/removal of the CDNI
Metadata associated with the content, not the actual content itself.

Ben

---

From: "Lee, Yiu" <[email-masked]>
Date: Mon, 18 Apr 2011 20:57:28 +0000

Hi Xiaoyan,

The requirement draft is still an individual draft. If you don't agree with some requirements, we can work on it after the WG is form.

Speaking of the content acquisition and metadata, I am a little bit confused by your suggestion. As Ben stated, Req 15 is about "remove/invalidation of the content", and Req 51 & 52 relate to add/modify/remove CDNI metadata. Control API will be used to control "the content" in the downstream CDN and Metadata API will be used to control "the Metadata" associated with the content in the downstream CDN. As such, Control API will address Req 15 and Metadata API will address Req 51 & 52. I don't agree we should move the "content acquisition" from Control API to Metadata API.

Kind regards,
Yiu

From: He Xiaoyan <[email-masked]<mailto:[email-masked]>>
Date: Mon, 18 Apr 2011 10:27:26 +0800
To: 'Ben Niven-Jenkins' <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>
Subject: [CDNi] 答复: 答复: Updated version of the CDNI charter

Hi Ben,

In the latest I-D draft"draft-lefaucheur-cdni-requirements-01", Req15 relates not only to content but also metadata. And Req15 is just an example, you could also find that Req 17 also relates to metadata but is putting under the control API now.

So, I think first consensus is needed on the relations of APIs (control API and metadata API) and data( metadata and content itself), if you proposed control API is related to content and metadata API relate to the CDNI metadata, that's OK for me. Then the charter needs to be revised to reflect this, e.g. move the "content acquisition" out of the control API and add content acquisition description to the metadata API,e.g." In particular, this interface will allow an upstream CDN to add, remove or invalidate content in a downstream CDN".

Best Regards

Xiaoyan(Susan) He

-----邮件原件-----
发件人: Ben Niven-Jenkins [mailto:[email-masked]]
发送时间: 2011年4月15日 19:48
收件人: He Xiaoyan
抄送: 'Francois Le Faucheur'; [email-masked]<mailto:[email-masked]>
主题: Re: [CDNi] 答复: Updated version of the CDNI charter

> Although thinking most content of the current charter is clearly and well defined but I still have a question on the description of the CDNicontrol interface, hope it is not too late to raise.

Ben