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

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

 



Sally,


This is great, many thanks. I am pleased to see this is again progressing, and suggest we put this on the agenda for the DCCP meeting in San Francisco.

I hope we can upload this soon after the I-D archives re-open on 2009-03-24. I have some comments below.

Best wishes,

Gorry

---

I have two questions, that relates to RFC3448 v. RFC 5348:

* There is also a citation of [RFC4342Errat] - which I think used to be referenced from:

   We don't expect that errata would be added to CCID	
   3 that didn't apply to CCID 4, but if this should happen, we would	
   say this explicitly in the errata.

The original text related to RFC3448, but if this is still the intention a similar clause may be useful at some point in section 3.1.


* The new text refers to RFC3448 in section 5, where the new text says:

    For CCID 4, this loss event rate, a round-
333 trip time estimate, and a nominal packet size of 1460 bytes are
334 plugged into the TCP throughput equation, as specified in RFC 3448
335 (Section 3.1) and [RFC4828].

I wonder if this was intentional? - Please could you comment?

---

I also have a few editorial notes:

* I see from IDNits that there are still some boilerplate issues that need to be fixed (places where there is a mix of old and new styles), although these seem minor, they'll need to be fixed prior to progressing this along the path to publication.

* I see you also need to update the copyright year.

* I also note that we have a citation of [RFC3448Errat] that is now no longer used - should this be deleted?

* RFC 2434 was replaced by RFC 5226.

---

A few comments on comments, again thanks for doing this quickly.

Sally Floyd wrote:
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.

This was a typo sorry, I wanted to mention the Erata pages, but mis-pasted the comment.

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.
- Thanks:-)

---
- 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.

OK, but see note above.

- 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.

Looks good to me.

---
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