Gorry -
Here are my comments on CCID-4 rev 0-02,
http://tools.ietf.org/html/draft-ietf-dccp-ccid4-02
Many thanks for the feedback. Unfortunately, I missed the
deadline for submitting the revised draft, but it is available at:
"http://www.icir.org/floyd/papers/draft-ietf-dccp-ccid4-03.txt";
"http://www.icir.org/floyd/papers/draft-ietf-dccp-ccid4-03.pdf";.
I made all of the changes that you suggested, with the exception
of the following:
---
References:
- See earlier note on publication of RFC5248.
----
What was this about? I couldn't find the earlier note.
Many thanks,
- Sally
http://www.icir.org/floyd/
-----------------------------------------------------------------------------------------------------------------------
Details:
----
Overall:
- The document will need revised boiler plate to address new IETF
rules
for I-D submission.
Done.
----
Abstract:
- It's good to say also that this experimental, but I think this
appears
many times at the moment.
OK, it now says "experimental" a few fewer times.
---
- 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.
Done.
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.
I don't believe there are any cases where RFC3448 is needed, instead
of RFC5348.
- Consider deletion of [RFC3448bis] [RFC3448].
I deleted [RFC3448bis], but kept [RFC3448] just for a note that the
CCID3 RFC
predates RFC 5348, and is written in terms of RFC 3448.
---
Introduction:
- I'd like to see the introduction change this:
/This document contains the profile/
- Please change to:
/This document specifies an experimental profile/
Done.
---
/Minimum sending rate:/
- Actually this is *Maximum* sending rate, please correct the heading.
Thanks, corrected.
---
Page 7: Section 3.1
- Although the section headers refers to TFRC, it cites TFRC-SP.
- Please consider
I changed it.
---
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. /
Done.
- My interpretation, is that RFC5348 is now REQUIRED, do you agree?
Yep. I think that the document now says so.
---
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/
^^^^^^^
Done.
---
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)./
Done.
---
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/
^
Done.
---
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./
Done.
----
- 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.
Thanks, I added it.
