Re: AD review: draft-ietf-dccp-tfrc-rtt-option-03

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.


[Index of Archives]     [Linux Kernel Development]     [Linux DCCP]     [IETF Annouce]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [DDR & Rambus]

  Powered by Linux