|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
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. ----