On 3/21/2016 5:10 PM, Polina Goltsman wrote:
First of all our feedback regarding different "re-entering dropping state" in the document and in the Linux implementation (http://www.ietf.org/mail-archive/web/aqm/current/msg01686.html) was not addressed.
Thank you for double-checking; the editors should look into this and respond.
As FQ-CoDel relies on CoDel, this issue is also (partly) relevant for the FQ-CoDel document. In the introduction FQ-CoDel references ns-3 and Linux implementations where the first one uses the re-entering logic from the CoDel document while the second from CoDel Linux implementation. The algorithm that has seen widespread testing according to Section 7 is (I suppose) the Linux version. Is this situation acceptable for an algorithm specification?
This is a good question. I believe for "Experimental", it's acceptable, but greater clarity would obviously be good.
/[since this comment was supposed to be sent before the end of 2015, feel free to (silently) ignore it]/
Since there are still some things that need to be tweaked in the document, there is still time to make constructive comments, so thanks for providing them!// I'd like the editors to examine them and respond./
/
Second, unlike Rasool Al-Saadi (see http://www.ietf.org/mail-archive/web/aqm/current/msg01693.html) I do not like the document. Although I agree that the pseudocode is sufficient to create a working implementation, however, in my opinion, the rest of the document makes implementing CoDeL more confusing (at least without reading [CODEL2012] first). Is it normal for a RFC, which, as I assume, should primarily contain an algorithm specification to contain the algorithm specification ONLY in form of pseudocode?
To be clear, the RFC doesn't need to completely "stand alone" (there is an Informative References section for good reason), however, it should certainly be internally clear. I definitely think the editors should consider and respond to your specific comments that were below this, as they seem like they might help improve clarity.
Thanks for your feedback!
_______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
