Thanks a lot for the review. We have revised the document with regard to the points listed below. The updated document has been uploaded, please see the detailed list of changes below. | From: Lars Eggert <lars.eggert@xxxxxxxxx> | Date: Fri, 4 Mar 2011 11:00:59 +0200 | Subject: AD review: draft-ietf-dccp-tfrc-rtt-option-03 | <...> | INTRODUCTION, paragraph 3: | > Abstract | | The draft header indicates that this document updates RFC4342/RFC5622, | but the abstract doesn't seem to mention this, which it should. | --- The abstract has been rewritten to clarify this point and to define abbreviations used by the document (which previously was not done). | Section 10.3, paragraph 0: | > than 4 can not be determined: such samples have to be discarded. | | Nit: s/can not/cannot/ | | --- Done. | Section 10.3, paragraph 4: | > for example, uses a fixed value of 1 second when it can not obtain an | | Nit: s/can not/cannot/ | --- Done. | Section 2.2.2., paragraph 1: | > Since a loss event is defined as one or more lost (ECN-marked) data | > packets in one RTT ([RFC5348], 5.2), the receiver needs accurate RTT | > estimates to validate and accurately separate loss events. | | I think you mean "(or ECN-marked)" here, right? (The sentence could be | misread as "and ECN-marked.) | --- Clarified as suggested. | Section 3.2.1., paragraph 6: | > Column meanings are as per [RFC4340], section 5.8 (table 3). This | > option is permitted in any DCCP packet, has option number XX and a | > length of 3-5 bytes. | | s/is permitted/MAY be placed/ (or some other way to use a RFC2119 | term?) | --- Done. | Section 3.2.2., paragraph 7: | > The column meanings are described in [RFC4340], section 6.4. In | > particular, the feature is by default off (initial value of 0), and | > the extension is not required to be understood by every DCCP | > implementation (cf. [RFC4340], section 15). | | So it is OPTIONAL to implement? Can you use an RFC2119 term for | clarity? | --- Done. | Section 3.4., paragraph 3: | > Until the first numeric RTT option arrives, the receiver uses a value | > of 0.5 seconds for receiver_RTT (to match the initial 2 second | > timeout of the TFRC nofeedback timer, [RFC5348], 4.2). | | s/uses/MUST use/ (?) | --- Done. | Section 3.4., paragraph 5: | > The sender is permitted to occasionally send no-number RTT options, | > covering for transient changes and spurious disruptions. During | > these times, the receiver continues to use its long-term receiver_RTT | > value. | | s/is permitted to/MAY/ and s/continues to/MUST continue to/ (or some | other way to use a RFC2119 term?) | --- Done, using 'SHOULD continue to' in the second part. | Section 3.4., paragraph 6: | > To avoid that the long-term estimate at the receiver drifts in such a | > way that it under-estimates the RTT, a simple back-off scheme is | > employed: | | s/is employed/MUST be employed/ and maybe s/the simple/the following | simple/ (?) | --- Used this term, sentence slightly rephrased to fit into context. | Section 6.2., paragraph 19: | > - removed recommendation of preferring long-term RTT stamples, | | Nit: s/stamples,/samples,/ | --- Done. | Section 6.2., paragraph 20: | > since this can not be generalized (connection may be short or | | Nit: s/can not/cannot/ | --- After consultation, we left this in the changelog.
