I have reviewed this document as part of the security directorate's 


ongoing effort to review all IETF documents being processed by the IESG. 


These comments were written primarily for the benefit of the security 


area directors.  Document editors and WG chairs should treat these 


comments just like any other last call comments.






This document describes an experimental change to a TCP and SCTP 


retransmission timer.






I thought about multiple ways to attack the specified algorithm, and 


was unable to come up with anything noteworthy. However, I should note 


that I do not feel qualified to comment on the impact this change might 


have on congestion in the Internet.






The security considerations section primarily references RFC 6298, 


which I believe is sufficient.




As such, I think this document is Ready.




Venturing outside my area of expertise (so feel free to disregard 


this), I have a question about section 4, step 3a. Would it make more 


sense for the "0" to be replaced with a configurable parameter? It seems 


to me that the number should be close to an inter-packet arrival time to 


more accurately avoid the issue mentioned below ("this is required to 


ensure that RTOR does not trigger retransmissions prematurely when 


previously retransmitted segments are acknowledged").




--
David Eric Mandelberg / dseomn


http://david.mandelberg.org/