Subject: [CDNi] Tentative agreement to add a "URI Signing" deliverable to the CDNI charter

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Thu, 1 Aug 2013 17:12:40 +0000

Hi everyone,

We've reached a tentative agreement during today's session to add a "URI Signing" deliverable to the CDNI charter.
If you have comments or concerns about that, please express those on the list.

Cheers

Francois

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Mon, 26 Aug 2013 15:55:56 +0000

Hello,

On 1 Aug 2013, at 19:12, Francois Le Faucheur (flefauch) <[email-masked]<mailto:[email-masked]>> wrote:

Hi everyone,

There has been no concerns expressed on the Berlin tentative agreement to add a "URI Signing" deliverable to the CDNI charter; so we will consider this as a WG decision.

Also, we need to update the target dates for existing Deliverables.

Below is a proposal to update the Charter accordingly, with addition over the current charter showing up in red and changes showing up in blue. Please review carefully and let us know if you have any comments on this proposal.

Francois & Daryl

PROPOSED NEW 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 architecture and how they interact with 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
      the CDNI architecture and the CDNI interfaces. 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 specification of the "CDNI request-routing interface". This
      interface will allow an upstream CDN request routing system to obtain
      from the downstream CDN the information necessary to perform request
      redirection.

    - A specification of the "CDNI metadata interface". This interface will
      allow the CDNs to exchange content distribution metadata of inter-CDN
      scope. Content 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).

    - A specification of the "CDNI logging interface". 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.

    - A specification of the "CDNI control interface". In particular, this
      interface will allow an upstream CDN to remove or invalidate content
      in a downstream CDN.

    - A specification of "URI Signing for CDNI" allowing support of content access control across interconnected CDNs through signing of content URIs. In particular, this specification will identify how URI signing impacts (or does not impact) each of the CDNI Interfaces.

    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 CDNI WG will work with other IETF 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. The CDNI WG will also
    coordinate with relevant groups outside the IETF such as UltraViolet.

Goals and Milestones:
  Done     - Submit CDNI problem statement to IESG as Informational
  Done     - Submit CDNI use cases to IESG as Informational
  Dec 2013 - Submit CDNI framework to IESG as Informational
  Sep 2013 - Submit CDNI requirements to IESG as Informational
  April 2014 - Submit specification of the CDNI Request Routing/Redirection interface to IESG as Proposed Standard
  Dec 2013 - Submit specification of the CDNI Logging interface to IESG as Proposed Standard
  April 2014 - Submit specification of the CDNI Control interface to IESG as proposed Standard
  Dec 2013 - Submit specification of the CDNI Metadata Distribution interface to IESG as Proposed Standard
  Sep 2014 - Submit specification of the CDNI Request Routing/Footprint & Capabilities Advertisement interface to IESG as Proposed Standard
  Dec 2014 - Submit specification of URI Signing for CDNI to IESG as Proposed Standard
  Dec 2014 - Recharter or dissolve

Cheers

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

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Thu, 29 Aug 2013 07:09:36 +0000

Hi Francois, all,

Some comments from my side:

-          A specification of "URI Signing for CDNI" allowing support of content access control across interconnected CDNs through signing of content URIs. In particular, this specification will identify how URI signing impacts (or does not impact) each of the CDNI Interfaces. To me, the first sentence captures the subject quite well, I'm not so sure about the second one. While URI signing definitely has an impact on some of the other CDNI interfaces, the sentence seems to imply the URI Signing doc will be some sort of analysis document, instead of a specification. Maybe something like: "A specification for 'CDNI URI Signing'. This document will specify a mechanism that allows interconnected CDNs to support control access control by signing content URIs."

-          The current milestone for URI Signing is Dec 2014. Looking at the maturity of the only candidate draft for URI Signing that is currently out there, Sept 2014 (or maybe even July) seems realistic to me, especially since the current candidate draft is a lot more mature than for example the current FCI proposals, which are also listed for Sept 2014.

-          You might want to re-order the other milestones to line them up chronologically.

-          Now that we're discussing the charter anyway, I noticed the final sentence "The CDNI WG will also coordinate with relevant groups outside the IETF such as UltraViolet" Is this still relevant? Or should we take it out?

-          The same is true for "The CDNI WG aims at delivering a targeted, deployable solution in a short timeframe (18-24 months) as needed by the industry". Now that we're updating the dates, should we remove the '(18-24 months)' from this line?

Best regards,

Ray

From: [email-masked] [mailto:[email-masked]] On Behalf Of Francois Le Faucheur (flefauch)
Sent: maandag 26 augustus 2013 17:56
To: [email-masked]
Subject: [CDNi] Draft CDNI charter update

Hello,

Hi everyone,

Francois & Daryl

PROPOSED NEW CHARTER
=======================
"

Goals and Milestones:

Cheers

Francois

This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Thu, 29 Aug 2013 08:06:44 +0000

Hi Ray and all,

Thanks for these good comments. See below for detailed response:

On 29 Aug 2013, at 09:09, "Brandenburg, R. (Ray) van" <[email-masked]<mailto:[email-masked]>>
 wrote:

Hi Francois, all,

-          A specification of "URI Signing for CDNI" allowing support of content access control across interconnected CDNs through signing of content URIs. In particular, this specification will identify how URI signing impacts (or does not impact) each of the CDNI Interfaces. To me, the first sentence captures the subject quite well, I’m not so sure about the second one. While URI signing definitely has an impact on some of the other CDNI interfaces, the sentence seems to imply the URI Signing doc will be some sort of analysis document, instead of a specification. Maybe something like: “A specification for ‘CDNI URI Signing’. This document will specify a mechanism that allows interconnected CDNs to support control access control by signing content URIs.”

I see your concern. At the same time, I think it woudl be useful to clarify the relationship of that specification with other CDNI interfaces ie it is not about defining an additional interface, but instead may involve extensions to the other CDNI interfaces (eg potentially additonal CDNI metadata, additional logging field).

How about:
“
A specification for ‘CDNI URI Signing’. This document will specify a mechanism that allows interconnected CDNs to support control access control by signing content URIs. This may involve extensions to the CDNI interfaces (e.g. CDNI metadata interface, CDNI logging interface).
”

Let's go for Sept 2014. Remember this target assumes the document has been through a number of steps beyond "being ready" (eg WG Last Call, Chair/AD review…).
But by all means, feel free to beat the target ^).

Agreed.

-          Now that we’re discussing the charter anyway, I noticed the final sentence “The CDNI WG will also coordinate with relevant groups outside the IETF such as UltraViolet” Is this still relevant? Or should we take it out?

I'd agree to remove the explicit mention about Ultra-Violet. It may be worth keeping a placeholder to remember we may have to interact with some external groups (for example we have received a liaison from the NGMN about their "Mobile Content Delivery Optimization" work). So we could rephrase into:
"
The CDNI WG will also coordinate with relevant groups outside the IETF, if and where appropriate.
"

-          The same is true for “The CDNI WG aims at delivering a targeted, deployable solution in a short timeframe (18-24 months) as needed by the industry”. Now that we’re updating the dates, should we remove the ‘(18-24 months)’ from this line?

I'd agree to remove the ‘(18-24 months)’ from this line.

The other clean-up we may want to do is to update the interface names to their final agreed names and add a few words to clarify that the "request routing interface" actually comprises two component interfaces, to make it easier to understand why there are two corresponding deliverables. If folks agree to that idea, we'll propose updated text for that too.

Thanks

Francois

Best regards,

Ray

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Francois Le Faucheur (flefauch)
Sent: maandag 26 augustus 2013 17:56
To: [email-masked]<mailto:[email-masked]>
Subject: [CDNi] Draft CDNI charter update

Hello,

Hi everyone,

Francois & Daryl

PROPOSED NEW CHARTER
=======================
"

Goals and Milestones:

Cheers

Francois

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Thu, 29 Aug 2013 08:31:44 +0000

Hi Francois,

Please see inline.

Thanks,

Ray

From: Francois Le Faucheur (flefauch) [mailto:[email-masked]]
Sent: donderdag 29 augustus 2013 10:07
To: Brandenburg, R. (Ray) van
Cc: Francois Le Faucheur (flefauch); [email-masked]
Subject: Re: Draft CDNI charter update

Hi Ray and all,

Hi Francois, all,

How about:
"
A specification for 'CDNI URI Signing'. This document will specify a mechanism that allows interconnected CDNs to support control access control by signing content URIs. This may involve extensions to the CDNI interfaces (e.g. CDNI metadata interface, CDNI logging interface).

Works for me.

"

Let's go for Sept 2014. Remember this target assumes the document has been through a number of steps beyond "being ready" (eg WG Last Call, Chair/AD review...).
But by all means, feel free to beat the target ^).

I'll give it a shot ;)

Agreed.

Ok.

I'd agree to remove the '(18-24 months)' from this line.

That sounds like something we should definitely do.

Thanks

Francois

Best regards,

Ray

Hello,

Hi everyone,

Francois & Daryl

PROPOSED NEW CHARTER
=======================
"

Goals and Milestones:

Cheers

Francois

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Thu, 29 Aug 2013 08:52:58 +0000

Everyone,

Below is an updated draft proposed charter reflecting the discussion with Ray.
Changes in blue, Additions in red.

Please review.

Cheers

Francois

PROPOSED NEW CHARTER
=======================
"

    targeted, deployable solution in a short timeframe as

    - A specification of the CDNI request-routing interface. This
      interface will allow an upstream CDN request routing system to obtain
      from the downstream CDN the information necessary to perform request
      redirection.  It is actually a logical bundling of two separate
      but related interfaces:

      *  Footprint & Capability Advertisement interface: Asynchronous operations
         to exchange routing information (e.g., the network footprint
         and capabilities served by a given CDN) that enables CDN
         selection for subsequent user requests; and

      *  Request Routing Redirection interface: Synchronous operations to
         select a delivery CDN (surrogate) for a given user request.

    - A specification of the "CDNI Metadata interface". This interface will

    - A specification of the "CDNI Logging interface". This interface will

    - A specification of the "CDNI Control interface". In particular, this
      interface will allow an upstream CDN to remove or invalidate content
      in a downstream CDN.

    - A specification for ‘CDNI URI Signing’. This document will specify a mechanism that allows interconnected CDNs to support access control by signing content URIs. This may involve extensions to the CDNI interfaces (e.g. CDNI metadata interface, CDNI logging interface).

    coordinate with relevant groups outside the IETF, if and where appropriate.

Goals and Milestones:
  Done     - Submit CDNI problem statement to IESG as Informational
  Done     - Submit CDNI use cases to IESG as Informational
  Sep 2013 - Submit CDNI requirements to IESG as Informational
  Dec 2013 - Submit CDNI framework to IESG as Informational
  Dec 2013 - Submit specification of the CDNI Logging interface to IESG as Proposed Standard
  Dec 2013 - Submit specification of the CDNI Metadata interface to IESG as Proposed Standard
  April 2014 - Submit specification of the CDNI Request Routing Redirection interface to IESG as Proposed Standard
  April 2014 - Submit specification of the CDNI Control interface to IESG as proposed Standard
  Sep 2014 - Submit specification of the CDNI Footprint & Capabilities Advertisement interface to IESG as Proposed Standard
  Sep 2014 - Submit specification of URI Signing for CDNI to IESG as Proposed Standard
  Sep 2014 - Recharter or dissolve

On 29 Aug 2013, at 10:31, "Brandenburg, R. (Ray) van" <[email-masked]<mailto:[email-masked]>>
 wrote:

Hi Francois,

Please see inline.

Thanks,

Ray

Cc: Francois Le Faucheur (flefauch); [email-masked]<mailto:[email-masked]>

Hi Ray and all,

Hi Francois, all,

How about:
“

Works for me.

”

I’ll give it a shot ;)

Agreed.

Ok.

Thanks

Francois

Best regards,

Ray

Hello,

Hi everyone,

Francois & Daryl

PROPOSED NEW CHARTER
=======================
"

Goals and Milestones:

Cheers

Francois