[tcpm] draft-ietf-tcpm-rack - editorial impact of target PS

["Scharf, Michael" <[e-mail]>]

Hi all,

I briefly scanned through draft-ietf-tcpm-rack-07 regarding the impact of the new target as PS.

This e-mail is only about editorial and formal issues. Note that I am not the responsible chair for this document.

Questions:

* Metadata: Does the document update other RFCs (such as RFC 5681)? My current thinking is that the answer is "no", but I want to cross-check. As the document now targets PS, it theoretically could update other RFCs. If the document does not update other RFCs, maybe it needs to explain this and the reason for not doing it somewhere?

* Abstract: "It is intended to replace the conventional DUPACK threshold approach and its variants, as well as other nonstandard approaches."

  I am not sure if the word "replace" could be a formal issue, in particular if other RFCs are not updated by this document (see previous comment). Another wording that may work around this question could e.g. be "it is intended to be an alternative to the conventional DUPACK threshold". Do others in the working group have any opinion on that wording (in particular native speakers)?

  The same question applies to later use of the word "replace". 

* Section 4: 

  "This document provides a concrete and detailed reordering window
   adaptation algorithm for implementers.  We note that the specifics of
   the algorithm are likely to evolve over time.  But that is a separate
   engineering optimization that's out of scope for this document."

  This could be understood as an experiment... Thus, I am not sure if this wording will pass an IETF last call on standards track. I wonder if this could be reworded to something along the lines of ...

  "This document provides a concrete and detailed reordering window
   adaptation algorithm as a standard solution that is safe to use. 
   Implementers have to aware that engineering optimization of
   the algorithm are possible."

Section 8.4

  "Nevertheless RACK is still an experimental algorithm.  Since the
   oldest loss detection algorithm, the 3 duplicate ACK threshold
   [RFC5681], has been standardized and widely deployed.  RACK can
   easily and optionally support the conventional approach for
   compatibility."

  The first sentence probably should be removed. I don't really understand the second sentence. And wouldn't it make sense to better emphasize the "compatibility" earlier in the document, say, in the intro?

Thanks

Michael (with no hat)