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
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 <email@example.com> 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 <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
- 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.