Re: [aqm] Pete Resnick's No Objection on draft-ietf-aqm-recommendation-09: (with COMMENT)
Pete, Good catch! Authors & doc shepherd: Did the author sign anything? If not, we need the pre-5378 boiler plate. Thanks, Martin Am 19.02.15 um 05:51 schrieb Pete Resnick: Pete Resnick has entered the following ballot position for draft-ietf-aqm-recommendation-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-aqm-recommendation/ -- COMMENT: -- This document does not have the pre-5378 boilerplate. Have all of the authors of 2309 actually signed the appropriate things, or does this document need the pre-5378 boilerplate? ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
Re: [aqm] Benoit Claise's Discuss on draft-ietf-aqm-recommendation-09: (with DISCUSS and COMMENT)
Hi Benoit, -- DISCUSS: -- Hopefully an easy DISCUSS. 3. The algorithms that the IETF recommends SHOULD NOT require operational (especially manual) configuration or tuning. This sentence above could be understood in different ways. For example, that any configuration is wrong. The ability to activate AQM is a good thing IMO. The section 4.3 title is closer to what you intend to say: "AQM algorithms deployed SHOULD NOT require operational tuning" The issue is that you only define what you mean by "operational configuration" in section 4.3 Proposal: OLD: 3. The algorithms that the IETF recommends SHOULD NOT require operational (especially manual) configuration or tuning. NEW: 3. AQM algorithm deployment SHOULD NOT require tuning of initial or configuration parameters. I do not see how your proposal is better than the original text. The original text says that the IETF is not recommending any operational configuration or tuning. You proposal is globally saying that AQM algorithms should not require tuning, etc. OLD: 4.3 AQM algorithms deployed SHOULD NOT require operational tuning NEW: 4.3 AQM algorithm deployment SHOULD NOT require tuning I see even less why this change is required and it makes an even stronger case. The first statement says that tuning in operations should not happen while your statement is saying that in general no tuning is required (even before going for operational). Martin ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
[aqm] Ted Lemon's Yes on draft-ietf-aqm-recommendation-09: (with COMMENT)
Ted Lemon has entered the following ballot position for draft-ietf-aqm-recommendation-09: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-aqm-recommendation/ -- COMMENT: -- I'm quite surprised that the introduction doesn't mention the problems that high or unpredictable latency can cause with flows that are attempting to do congestion control at the ends (e.g., TCP). If I were reading this without already knowing about that, I would assume that the goal of this document is to reduce latency for the benefit of applications that require low latency, like VoIP and gaming. It would be nice if the introduction made mention of the issue of high latency as it affects TCP flows. The document also talks about congestion collapse as a future risk to be prevented, but I think that this isn't telling the whole story: users of the Internet see localized congestion collapse quite frequently, and have done for quite some time. It's essentially normal network behavior in hotels, cafes and on airplanes: anywhere where available bandwidth is substantially short of demand. I don't think this is a problem with technical accuracy, but I think someone reading this document who isn't an expert on congestion control might not realize that this document is talking about that specific sort of failure mode as well as failures deep in the network. I'm really happy to see this document being published. The above comments are just suggestions based on my particular concerns about congestion, and do not reflect any degree of expertise, so if they seem exceptionally clueless you should just ignore them. ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
Re: [aqm] Pete Resnick's No Objection on draft-ietf-aqm-recommendation-09: (with COMMENT)
On 2/19/2015 7:25 AM, Martin Stiemerling wrote: > Pete, > > Good catch! > > Authors & doc shepherd: Did the author sign anything? > > If not, we need the pre-5378 boiler plate. > No they didn't sign anything. In fact many of them have been difficult/impossible to reach, and the author list on 2309 was the entire end-to-end RG at the time, so it's quite long. It seems to me that we certainly need to use the pre-5378 boilerplate. Thanks for catching this, Pete! -- Wes Eddy MTI Systems ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
[aqm] Kathleen Moriarty's No Objection on draft-ietf-aqm-recommendation-09: (with COMMENT)
Kathleen Moriarty has entered the following ballot position for draft-ietf-aqm-recommendation-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-aqm-recommendation/ -- COMMENT: -- Thanks for your work on this draft, it looks good. There are some tiny nits that the SecDir reviewer found that you might want to consider: https://www.ietf.org/mail-archive/web/secdir/current/msg05357.html ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
[aqm] ID Tracker State Update Notice:
IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-aqm-recommendation/ ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
