IETF conflict review for draft-alimi-decade
conflict-review-alimi-decade-00

The following approval message was sent
From: The IESG
To: "Nevil Brownlee" , draft-alimi-decade@tools.ietf.org
Cc: The IESG , , 
Subject: Results of IETF-conflict review for draft-alimi-decade-05

The IESG has completed a review of draft-alimi-decade-05 consistent with
RFC5742.


The IESG has no problem with the publication of 'DECoupled Application
Data Enroute (DECADE)'  as an Informational
RFC.


The IESG has concluded that there is no conflict between this document
and IETF work.



The IESG would also like the RFC-Editor to review the comments in the
datatracker related to this document and determine whether or not they
merit incorporation into the document. Comments may exist in both the
ballot and the history log.

The IESG review is documented at:
http://datatracker.ietf.org/doc/conflict-review-alimi-decade/

A URL of the reviewed Internet Draft is:
http://datatracker.ietf.org/doc/draft-alimi-decade/

The process for such documents is described at
http://www.rfc-editor.org/indsubs.html

Thank you,

The IESG Secretary

[Ballot comment]

- 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.

[Ballot comment]
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.

HTH

Francois

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




B.2.2.  DECADE WG

  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
wrote:

> Hi François,
>
> As explained in my voice mail, can you please review http://tools.ietf.org/html/draft-alimi-decade-04, 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 http://tools.ietf.org/html/rfc5742 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 , but this relationship does not prevent publishing.
>
>  3. The IESG has concluded that publication could potentially disrupt
>      the IETF work done in WG  and recommends not publishing the
>      document at this time.
>
>  4. The IESG has concluded that this document violates IETF procedures
>      for  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
>

The draft draft-alimi-decade-04
is ready for publication from the Independent Stream.
Please ask IESG to review it, as set out in RFC 5742.

The following is some background for this draft, please forward it
to IESG along with this request ...

Its abstract says:
"Content distribution applications, such as those those employing
peer-to-peer (P2P) technologies, are widely used on the Internet and
make up a large portion of the traffic in many networks. Often,
however, content distribution applications use network resources in a
counter-productive manner. One way to improve efficiency is to
introduce storage capabilities within the network and enable
cooperation between end-host and in-network content distribution
mechanisms. This is the capability provided by a DECADE system,
which is introduced in this document. DECADE enables applications to
take advantage of in-network storage when distributing data objects
as opposed to using solely end-to-end resources. This document
presents the underlying principles and key functionalities of such a
system and illustrates operation through a set of examples."

It was reviewed for me by Carlos Bernardos and Martin Stiemerling,
the authors worked with them to address the issues raised.


Thanks, Nevil (ISE)