Authors, WG,
Here are my comments on CCID-4 rev 0-02,
http://tools.ietf.org/html/draft-ietf-dccp-ccid4-02
Best wishes,
Gorry
----
Overall:
- The document will need revised boiler plate to address new IETF rules
for I-D submission.
----
Abstract:
- It's good to say also that this experimental, but I think this appears
many times at the moment.
---
- Since CCID-4 has not yet been published, I'd expect that all
references to [RFC3448] need to be replaced by [RFC5348], and the
section numbers referenced will need to be updated.
If there are any places were RFC3448 is intended, that text need to be
added to explicitly explain why [RFC4338] can be used and in what
conditions.
- Consider deletion of [RFC3448bis] [RFC3448].
---
Introduction:
- I'd like to see the introduction change this:
/This document contains the profile/
- Please change to:
/This document specifies an experimental profile/
---
/Minimum sending rate:/
- Actually this is *Maximum* sending rate, please correct the heading.
---
Page 7: Section 3.1
- Although the section headers refers to TFRC, it cites TFRC-SP.
- Please consider
---
Page 8: Point 5.
- RFC 5438 is now published.
- This text needs to be updated:
/ If [RFC3448bis] is standardized in the
IETF as a revision of [RFC3448], then [RFC3448bis] MAY be implemented
with CCID4 without having to wait for an explicit update to this
document. /
- My interpretation, is that RFC5348 is now REQUIRED, do you agree?
---
Page 8 first para.
- This text was updated and is a great improvement.
- In the following: I think /IP/ should be replaced by /IPv4/:
/ packets is estimated as 36 bytes (20 bytes for the IP header/
- suggest:
/ packets is estimated as 36 bytes (20 bytes for an IPv4 header/
^^^^^^^
---
Page 10:
- This is a little complicated.
/ For TFRC-SP, for short loss
intervals of at most two round-trip times, the loss interval length
is computed not as the data length of the loss interval, but instead
as the data length divided by the number of dropped or marked data
packets./
Could we say:
/ For short loss intervals of at most two round-trip times,
TFRC-SP computes the loss interval length as the data length
divided by the number of dropped or marked data packets,
(rather than the data length of the loss interval)./
---
Page 11:
/Section 5.4 of RFC 4342 described when to use the most recent loss/
Please replace by:
/Section 5.4 of RFC 4342 describes when to use the most recent loss/
^
---
Page 11, Section 8
- This could be clearer by mentioning the updates:
/and is interpreted in the same way, except as
specified elsewhere in this document./
- Would it be OK to also add:
/ or a subsequent IETF standards-track RFC that updates or obsoletes
this specification./
----
- There is no section that tells the reader WHY this has been given
experimental status, although it is said
progression would rely upon the method defined in RFC4828 being
published as a standards-track RFC.
- I would find it really helpful to include a really brief section that
calls this out, here is my suggestion:
X.X Experimental Status of this document
TFRC-SP is a congestion control method defined in RFC4828.
Section 10 of[RFC4828] describes why this method is currently
specified as experimental and why it is not intended for
widespread deployment at this time in the global Internet.
Since TFRC-SP is experimental, CCID 4 is therefore also
considered experimental. If the IETF publishes a standards-track
RFC that changes the status of TFRC-SP, then CCID-4 should
then be updated to reflect the change of status.
---
References:
- See earlier note on publication of RFC5248.
----
