Re: Review comments on CCID-4 (draft-ietf-dccp-ccid4-02.txt)

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

 



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.


[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