[email protected] <[email protected]> wrote: > > If you see ambiguity in "network device", by all means send us propose > text again (I must have missed that detail.
You're welcome to my text from July 2: http://www.ietf.org/mail-archive/web/aqm/current/msg00701.html I don't know whether that matches your intent: I have no desire to change your intent. > Apart from that, does this mean you have no specific comments on this > version? If Bob makes any fuss about "congestive collapse" I support him. Otherwise, I make a strong request that you add a definition of that term: I have no idea what you mean that's consistent with what you wrote and the way the Internet works. I do remain convinced that the charter wording calling for obsoleting RFC 2309 was ill-advised, and is not what this WG actually chose to do. I'd much prefer to fix the charter milestone language; but I detect no enthusiasm for that. I'll settle for being listed "in the rough" in the Shepherd's writeup. My thorough review was of version -05. Since then, I note the change in the Abstract from "updated" to "and replaces these" [recommendations of 2309]. I don't see any particular reason for that change, but won't fuss over it if nobody else cares. I note the addition of a section header for "1.1 Congestion Collapse" which correctly includes "fix for Internet meltdown"; but I think the switching between "Congestion Collapse" and "congestive collapse" is confusing. ("Congestion Collapse" is a well-defined term of art; and wouldn't need a definiton unless you think you can write one which will make the usage of that term correct in this document.) Most of my comments about version -05 can simply be listed as "ignored" or perhaps "considered and ignored"; but a few never made it onto the list because I thought the change from "obsoletes" to "updates" needed to be discussed first. In Section 3 subsection 3, I would prefer that we not perpetuate the idea that flows must be "TCP-friendly". While there are indeed cases of unfriendly-to-TCP flows, that really isn't an AQM issue. In Section 4.6, in talking of "elastic transport congestion control", I fail to see how this relates to AQM; and I'd prefer not jawboning about how transports "should" function. (This sort of text would be entirely proper in an IRTF document; but we're now doing an IETF BCP concerned with queue management in network devices.) Section 4.7 returns to 2309's "need further research" conclusion. It seems to me out-of-place to list these things in a BCP. In Section 8 Acknowledgements, I don't think it correct to say, "This is an edited version of that document". (I agree it started that way, but I find that not an acceptable basis for a BCP.) ==== You have every right to say I should have raised these points earlier; but that's a poor substitute for evaluating their merit. It is the intent of a Working Group Last Call to solicit thorough reviews by WG participants -- and follow through on those with merit. The habit of tossing the WGLC comments at the authors and marginalizing any further comments to the authors' response is a bad habit. I wish we would break it. -- John Leslie <[email protected]> _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
