IETF conflict review for draft-alimi-decade

Note: This ballot was opened for revision 00 and is now closed.

Ballot question: "Is this the correct conflict review response?"

(Spencer Dawkins) Yes

(Martin Stiemerling) Yes

(Jari Arkko) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

Comment (2013-09-26)
No email
send info
I double-checked with François Le Faucheur. For the record, here is his message:

Hello Benoit,

We investigated the relationship between CDNI and the work of the former DECADE WG a while back. The conclusions are captured in Appendix B.2.2 of RFC6707 (CDNI Problem Statement).
From a quick scan of draft-alimi-decade-04, it seems that the fundamentals of teh architecture/solutions have not changed so the earlier conclusions would still apply.

So I would say this would be a 1. (in your 5 options below) , or possibly a 2.



PS: If you are aware of significant/sensitive changes (that I may have missed from scanning the document) between draft-alimi-decade-04 and the earlier draft work of the DECADE WG, let me know and I can have a specific look on such changes.

PPS: below is teh relevant text from RFC6707


   The DECADE working group [DECADE-Charter] is addressing the problem
   of reducing traffic on the last-mile uplink, as well as backbone and
   transit links caused by peer-to-peer (P2P) streaming and file-sharing
   applications.  It addresses the problem by enabling an application
   endpoint to make content available from an in-network storage service
   and by enabling other application endpoints to retrieve the content
   from there.

   Exchanging data through the in-network storage service in this
   manner, instead of through direct communication, provides significant
   gain where:

   o  The network capacity/bandwidth from the in-network storage service
      to the application endpoint significantly exceeds the capacity/
      bandwidth from application endpoint to application endpoint (e.g.,
      because of an end-user uplink bottleneck); and

   o  The content is to be accessed by multiple instances of application
      endpoints (e.g., as is typically the case for P2P applications).

   While, as is the case for any other data distribution application,
   the DECADE architecture and mechanisms could potentially be used for
   exchange of CDNI control plane information via an in-network storage
   service (as opposed to directly between the entities terminating the
   CDNI interfaces in the neighbor CDNs), we observe that:

   o  CDNI would operate as a "Content Distribution Application" from
      the DECADE viewpoint (i.e., would operate on top of DECADE).

   o  There do not seem to be obvious benefits in integrating the DECADE
      control plane responsible for signaling information relating to
      control of the in-network storage service itself, and the CDNI
      control plane responsible for application-specific CDNI
      interactions (such as exchange of CDNI Metadata, CDNI request
      redirection, and transfer of CDNI logging information).

   o  There would typically be limited benefits in making use of a
      DECADE in-network storage service because the CDNI interfaces are
      expected to be terminated by a very small number of CDNI clients
      (if not one) in each CDN, and the CDNI clients are expected to
      benefit from high bandwidth/capacity when communicating directly
      to each other (at least as high as if they were communicating via
      an in-network storage server).

   The DECADE in-network storage architecture and mechanisms may
   theoretically be used for the acquisition of the content objects
   themselves between interconnected CDNs.  It is not expected that this
   would have obvious benefits in typical situations where a content
   object is acquired only once from an Upstream CDN to a Downstream CDN
   (and then distributed as needed inside the Downstream CDN).  But it
   might have benefits in some particular situations.  Since the
   acquisition protocol between CDNs is outside the scope of the CDNI
   work, this question is left for further study.

   The DECADE in-network storage architecture and mechanisms may
   potentially also be used within a given CDN for the distribution of
   the content objects themselves among Surrogates of that CDN.  Since
   the CDNI work does not concern itself with operation within a CDN,
   this question is left for further study.

   Therefore, the work of DECADE may be complementary to, but does not
   overlap with, the CDNI work described in this document.

On 24 Sep 2013, at 12:47, Benoit Claise <>

> Hi François,
> As explained in my voice mail, can you please review, and let me know if there is any conflict with your CDNI work at the IETF. This draft will be discussed during the Thursday IESG telechat.
> By conflict, I mean section 3. The IESG has to select one of the 5 standard actions:
>   1. The IESG has concluded that there is no conflict between this
>      document and IETF work.
>   2. The IESG has concluded that this work is related to IETF work done
>      in WG <X>, but this relationship does not prevent publishing.
>   3. The IESG has concluded that publication could potentially disrupt
>      the IETF work done in WG <X> and recommends not publishing the
>      document at this time.
>   4. The IESG has concluded that this document violates IETF procedures
>      for <Y> and should therefore not be published without IETF review
>      and IESG approval.
>   5. The IESG has concluded that this document extends an IETF protocol
>      in a way that requires IETF review and should therefore not be
>      published without IETF review and IESG approval.
> Regards, Benoit

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2013-09-26)
No email
send info
- The decade wg was closed. If there were a way to nicely
explain that here, that could be good, in case some reader
gets confused when they read this and see that there once
was a decade wg.

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

Barry Leiba No Objection

(Ted Lemon) No Objection

(Pete Resnick) No Objection

(Sean Turner) No Objection