--- 1/draft-ietf-tcpm-3517bis-00.txt	2012-01-26 19:13:57.854671266 +0100
+++ 2/draft-ietf-tcpm-3517bis-01.txt	2012-01-26 19:13:57.886671507 +0100
@@ -1,23 +1,23 @@
 
 Internet Engineering Task Force                               E. Blanton
 INTERNET-DRAFT                                         Purdue University
-draft-ietf-tcpm-3517bis-00.txt                                 M. Allman
+draft-ietf-tcpm-3517bis-01.txt                                 M. Allman
                                                                     ICSI
                                                                  L. Wang
                                                         Juniper Networks
                                                              I. Jarvinen
                                                                  M. Kojo
                                                   University of Helsinki
                                                               Y. Nishida
                                                             WIDE Project
-                                                        January 12, 2012
+                                                        January 26, 2012
 
          A Conservative Selective Acknowledgment (SACK)-based
                     Loss Recovery Algorithm for TCP
 
 Status of this Memo
 
     This Internet-Draft is submitted to IETF in full conformance with
     the provisions of BCP 78 and BCP 79.
 
     Internet-Drafts are working documents of the Internet Engineering
@@ -255,26 +255,20 @@
           window allows, the sequence range of one segment of up to SMSS
           octets of previously unsent data starting with sequence number
           HighData+1 MUST be returned.
 
       (3) If the conditions for rules (1) and (2) fail, but there exists
           an unSACKed sequence number 'S3' that meets the criteria for
           detecting loss given in steps (1.a) and (1.b) above
           (specifically excluding step (1.c)) then one segment of up to
           SMSS octets starting with S3 SHOULD be returned.
 
-          We believe that the triggering of rule (3) will be rare and
-          that the implications are likely limited to corner cases
-          relative to the entire recovery algorithm.  Therefore we leave
-          the decision of whether or not to use rule (3) to
-          implementors.
-
       (4) If the conditions for (1), (2), and (3) fail, but there
           exists outstanding unSACKed data, we provide the
           opportunity for a single "rescue" retransmission per entry
           into loss recovery.  If HighACK is greater than RescueRxt
           (or RescueRxt is undefined), then one segment of up to
           SMSS octets which MUST include the highest outstanding
           unSACKed sequence number SHOULD be returned, and RescueRxt
           set to RecoveryPoint.  HighRxt MUST NOT be updated.
 
           Note that rules (3) and (4) are a sort of retransmission "last