Note: This ballot was opened for revision 00 and is now closed.
Ballot question: "Is this the correct conflict review response?"
Agree with Alvaro - without the implementation and deployment details, this document is harmful. It only mentions in the abstract that it is based on prototype implementations, the rest of the document references only the RFC, the reader can not distinguish. More than 26 pages of statements on negatives and limitations without details. The implementation of a protocol and how it is deployed are critical in understanding an evaluation - either positive or negative. The independent stream does allow for documents outside the official IETF process that are relevant to the Internet community and achieve reasonable levels of technical and editorial quality. It is questionable if this document is outside the official IETF process based on the refusal of the authors to improve the document after the working group reviewed and questioned the technical quality. As Alvaro noted, justification to publish based on a prior non-IETF conference publication, should not be the basis for IETF's independent stream need to publish.
This document, which "aims at providing a better understanding of possible limits of RPL, notably the possible directions that further protocol developments should explore" was initially published in 2012. The Abstract further says that it "presents a selection of observations on the protocol characteristics, exposes experiences acquired when producing various prototype implementations of RPL, and presents results obtained from testing this protocol - by way of network simulations, in network testbeds and in deployments." While discussing it in the roll WG , the authors were repeatedly asked to provide details of the tests used (implementations, simulations, deployments). However, the answer was always along the lines of not needing to do so because "the experiments only served to help us see "what to look for" in the RPL RFC", and, "the issues raised in this I-D are based on what can be observed from the RPL RFC". As a result the WG lost interest. Sharing experiences gained through deployment and/or experimentation is very valuable in any protocol development setting -- specially if it leads to improvements. RPL is a routing protocol that is used in many different scenarios, from IoT-oriented applications (see RFC5826, RFC5548, RFC5867, RFC5673, RFC7733, RFC8036) to autonomic networking . A clear understanding of the details of the implementation, the types of devices used, and the deployment scenarios is important. Details do matter! Besides not providing appropriate details, the document has failed to even include pointers to work that may address some of the observations; RFC6997 and draft-ietf-roll-dao-projection are two examples. In fact, the document has not significantly changed since its initial publication. Furthermore, the similarities between this document and [rpl-eval] (used as a reference) are evident. The rpl-eval document has already been published as part of the Proceedings of the 5th IEEE International Conference on Wireless & Mobile Computing, Networking & Communication (WiMob) in 2011. Re-publishing that document with minor changes and no updates to reflect the current work doesn't seem valuable. The reasons above have led to the conclusion that publishing this document as an RFC could prove disruptive to the work of the roll WG. At best, the document lacks complete and up-to-date information. Ideally, an up-to-date version of this document, with proper details, could serve as a discussion driver in the roll WG.  https://mailarchive.ietf.org/arch/msg/roll/94pPESUq_4beceta0RKx0GREGpQ/  https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane [rpl-eval] https://hal.inria.fr/inria-00597036/document
The document reads as "things are broken because we think that things are broken".
I'm actually not sure about the conclusion here. I agree to all points that Alvaro brought up and I think these are good reasons for the ISE to not publish this document, however, I am not sure if it warrens an IESG reply that concludes "that publication could potentially disrupt the IETF work", especially as the work is already published elsewhere. However, I only had a brief look at the draft itself and can also see that there is a relation to IETF work which could be disruptive!