Thanks for the feedback. Gorry
> Benoit Claise has entered the following ballot position for > draft-ietf-aqm-ecn-benefits-06: 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 https://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: > https://datatracker.ietf.org/doc/draft-ietf-aqm-ecn-benefits/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > - The discard of packets serves > as a signal to the end-to-end transport that there may be congestion > on the network path being used. > > Why not? > The discard of packets serves > as a signal to the end-to-end transport that there is congestion > on the network path being used. > Because a loss can also be due to other reasons than congestion, it would help to explain this. I will add. > > - Section 3.5. Bleaching and Middlebox Requirements to deploy ECN > > Sligthly confused by ECT(0) is different the zero codepoint > > When ECN-capable IP packets, marked as ECT(0) or ECT(1), are remarked > to non-ECN-capable (i.e., the ECN field is set to zero codepoint), > OK, We'll add - probably need to explain the numerical value for non-ECT, etc. > ... > > A network device must not change a packet with a CE mark to a zero > codepoint, if the network device decides not to forward the packet > with the CE-mark, > > I had to look up https://tools.ietf.org/html/rfc3168 > > +-----+-----+ > | ECN FIELD | > +-----+-----+ > ECT CE [Obsolete] RFC 2481 names for the ECN bits. > 0 0 Not-ECT > 0 1 ECT(1) > 1 0 ECT(0) > 1 1 CE > > If you had one or two sentences to introduce the codepoints, that would > avoid the confusion and would ease the readability. > > And below is Dan Romascanu's OPS DIR review: > The following three comments are editorial in nature, triggered by > difficulties in understanding some of the information (otherwise clearly > presented): > > > > 1. It would be useful to break the definition of âECN-capableâ > in > two separate definitions for âECN-capable packetâ and âECN-capable > network deviceâ. It also would be good to copy or refer the definition > of > ECN codepoint from RFC 3168. > Understood, will update. > 2. Section 2.5 uses both CE-marking and ECN-marking terms. They are > meant to be synonymous, so chosing one of them would make the text more > clear > All should be "CE-marked", will change. > 3. Sections 4.3 and 5 uses the following phrase about endpoints â > âit can ⦠conservatively react to congestionâ. Please explain what > this means. > I'll discuss with my co-author on how to add more text here. Gorry _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
