Re: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10]

Alfred,
    I am compiling all the changes including the last call comments into the next revision. I will incorporate all your comments below. 

In particular, regarding your observation of mentioning what the document is doing, I agree that we should mention that it "updates 793". I am hoping that nobody has any objection to this point. 

-Anantha
-----Original Message-----
From: Alfred HÎnes [mailto:ah@tr-sys.de] 
Sent: Wednesday, August 13, 2008 11:50 PM
To: Anantha Ramaiah (ananth); rrs@cisco.com; Mitesh Dalal (mdalal)
Cc: tcpm@ietf.org
Subject: another review of draft-ietf-tcpm-tcpsecure[-10]

Hello all,
I have once more tried to closely read the latest (-10) version of the 'tcpsecure' draft, and only found a very small number of nits -- see below.

Furthermore, I once more advocate making clear in the document metadata what the document does, by adding to the heading:

    Updates: 793 (if approved)

Doing so will definitely help guide implementers to quickly locate the document once published as an RFC.
By WG consensus, the document is intended for Standards Track, and Sections 3.2, 4.2, and 5.2 clearly state that they update RFC 793; thus, this should be made visible at the metadata level as well.

Nits (in recently added / modified text):

(1)
At the very end of section 1, please change:

              [...] please refer to draft [RFC4953]
                                   ^^^^^^          ^
   to:
              [...] please refer to RFC 4953 [RFC4953].
                                   ^^^^^^^^^          ^
   or:
              [...] please refer to [RFC4953].
                                   ^         ^

(2)
In the first paragraph of section 5.2, please correct two punctuation flaws (missing period, and extraneous apostrophe).
I also have included two minor stylistic improvement below:

                                                    [...].  It needs to
|  be noted that RFC 793 page 72 (fifth check) says : "If the ACK is a
                        ^                          ^^
   duplicate (SEG.ACK < SND.UNA), it can be ignored.  If the ACK
   acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an
|  ACK, drop the segment, and return" This mitigation makes the ACK
                                    ^^
   check more stringent since any ACK < SND.UNA wouldn't be accepted,
|  instead only ACK's which are in the range ((SND.UNA - MAX.SND.WND) <=
                   ^^
   SEG.ACK <= SND.NXT) gets through.
---
                                                    [...].  It needs to
|  be noted that RFC 793 on page 72 (fifth check) says: "If the ACK is a
                        ^^^^                          ^
   duplicate (SEG.ACK < SND.UNA), it can be ignored.  If the ACK
   acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an
|  ACK, drop the segment, and return."  This mitigation makes the ACK
                                    ^^^^
   check more stringent since any ACK < SND.UNA wouldn't be accepted,
|  instead only ACKs which are in the range ((SND.UNA - MAX.SND.WND) <=
                   ^^
   SEG.ACK <= SND.NXT) gets through.

Note: The quotation comprises multiple sentences; hence the "rational
      quotation" rule of the RFC-Ed does not apply.

IMO, otherwise the draft is ready to go, and because of the importance of the topic, it should now be advanced quickly!

Kind regards,
  Alfred HÎnes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah@TR-Sys.de                     |
+------------------------+--------------------------------------------+

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm