Hi, below is my AD review for draft-ietf-dccp-tfrc-rtt-option-03. Basically, the document is ready to progress, modulo a few minor issues. Mostly, they are about using more RFC2119 terms in Section 3 to clarify operation. Check if that makes sense, and also check if there are other instances where a similar rewording would add clarity. Lars 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. Section 10.3, paragraph 0: > than 4 can not be determined: such samples have to be discarded. Nit: s/can not/cannot/ 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/ 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.) 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?) 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? 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/ (?) 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?) 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/ (?) Section 6.2., paragraph 19: > - removed recommendation of preferring long-term RTT stamples, Nit: s/stamples,/samples,/ Section 6.2., paragraph 20: > since this can not be generalized (connection may be short or Nit: s/can not/cannot/
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
