[tcpm] draft-ietf-tcpm-tcp-uto-06

Alfred Hönes <ah@tr-sys.de> Fri, 02 November 2007 13:30 UTC

Return-path: <tcpm-bounces@ietf.org>
Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InwbX-0002yH-Ct; Fri, 02 Nov 2007 09:30:31 -0400
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1ImYVW-0004nu-LH for tcpm-confirm+ok@megatron.ietf.org; Mon, 29 Oct 2007 13:34:34 -0400
Received: from [] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImYVW-0003zd-9P for tcpm@ietf.org; Mon, 29 Oct 2007 13:34:34 -0400
Received: from dsl.tr-sys.de ([] helo=WOTAN.TR-Sys.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImYV8-0002v1-8Q for tcpm@ietf.org; Mon, 29 Oct 2007 13:34:11 -0400
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: $/16.3) id AA100459207; Mon, 29 Oct 2007 18:33:27 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id SAA13049; Mon, 29 Oct 2007 18:33:24 +0100 (MEZ)
From: Alfred Hönes <ah@tr-sys.de>
Message-Id: <200710291733.SAA13049@TR-Sys.de>
To: fernando@gont.com.ar, lars.eggert@nokia.com
Date: Mon, 29 Oct 2007 18:33:24 +0100
X-Mailer: ELM [$Revision: $]
Mime-Version: 1.0
Content-Type: text/plain; charset="hp-roman8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
X-Mailman-Approved-At: Fri, 02 Nov 2007 09:30:29 -0400
Cc: tcpm@ietf.org
Subject: [tcpm] draft-ietf-tcpm-tcp-uto-06
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Errors-To: tcpm-bounces@ietf.org

I've also studied the latest rev. of your TCP UTO draft,
and would once again like to point out a few nits I found there.
(I do not want to engage in the requirements language discussion
 as well :-))

(1)  Terminology -- Section 3, 3.1 et al.

Section 3 newly has introduced the variable 'USER_TIMEOUT':

      TCP's USER TIMEOUT parameter, as specified in [RFC0793].

The subsequent text uses 'user timeout', 'USER TIMEOUT', and
'USER_TIMEOUT' in a way that seems to be a bit confusing; the
distinction between these terms, and the rationale for selecting
one of these terms remains unclear in some places.
In particular, according to the quoted definition, I do not see
a significant difference between 'USER TIMEOUT' and 'USER_TIMEOUT'
that might justify wording like:
   ... the local TCP USER TIMEOUT (USER_TIMEOUT) ...
(Section 3.1, 2nd paragraph).
Also, the title of Section 3.1 contains 'User Timeout' whereas most
occurrences of 'user timeout' have been changed to 'USER TIMEOUT'
in the body of Section 3.1.
I propose to reconsider the distinction, and to use 'USER TIMEOUT'
only in the immediate context of RFC 793 as opposed to this draft;
most of the occurrences of 'USER TIMEOUT' should better be replaced
by 'USER_TIMEOUT' (the TCP state variable) or 'user timeout' (the
abstract concept as seen from the application / user).

Also, the names of the two variables, USER_TIMEOUT and LOCAL_UTO,
are not good mnemonics for the intended purpose of these variables;
IMHO, the naming should be reconsidered again (I already had argued
in this matter).  In particular, 'LOCAL_UTO' now has much diminuished
*local* significance, it it just the value advertised to the peer
(=> my new proposal: ADV_UTO ); USER_TIMEOUT ist the important local
state variable, and there's now only a loose coupling between both.

(2)  Section 3

In the second-to-last paragraph of Section 3, there's an unnecessary
word replication:

   vvvvvvvvv                          vvvvvvvvv
                  [...].  Section 3.1 discusses user timeout limits and
   discusses potentially problematic effects of some user timeout

Perhaps, the second instance should be removed from the text:

                  [...].  Section 3.1 discusses user timeout limits and
|  potentially problematic effects of some user timeout settings.

(3)  Section 3.3

In the last paragraph, remove the duplicate full-stop in "connection.."

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