Re: [tcpm] draft-ietf-tcpm-rfc2581bis-04 -- a few editorials

Ethan Blanton <eblanton@cs.purdue.edu> Sun, 11 May 2008 01:11 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C14F63A6A29; Sat, 10 May 2008 18:11:36 -0700 (PDT)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C809E3A6A27 for <tcpm@core3.amsl.com>; Sat, 10 May 2008 18:11:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.445
X-Spam-Level:
X-Spam-Status: No, score=-1.445 tagged_above=-999 required=5 tests=[AWL=0.855, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5haHOy2dWnq for <tcpm@core3.amsl.com>; Sat, 10 May 2008 18:11:34 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BB7E83A69F7 for <tcpm@ietf.org>; Sat, 10 May 2008 18:11:33 -0700 (PDT)
Received: from [63.168.31.209] (helo=elb.elitists.net) by psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <eblanton@cs.purdue.edu>) id 1Jv05u-000HMl-S8; Sun, 11 May 2008 01:11:28 +0000
Received: from colt.internal (colt [192.168.33.1]) by elb.elitists.net (Postfix) with ESMTP id F03822BE21; Sat, 10 May 2008 21:11:10 -0400 (EDT)
Received: by colt.internal (Postfix, from userid 3000) id C9D982863E; Sat, 10 May 2008 21:11:08 -0400 (EDT)
Date: Sat, 10 May 2008 21:11:08 -0400
From: Ethan Blanton <eblanton@cs.purdue.edu>
To: Alfred Hönes <ah@tr-sys.de>
Message-ID: <20080511011107.GA12264@elb.elitists.net>
References: <200805061312.PAA15671@TR-Sys.de>
MIME-Version: 1.0
In-Reply-To: <200805061312.PAA15671@TR-Sys.de>
X-GnuPG-Fingerprint: A290 14A8 C682 5C88 AE51 4787 AFD9 00F4 883C 1C14
User-Agent: Mutt/1.5.13 (2006-08-11)
Cc: tcpm@ietf.org, vern@icir.org, mallman@icir.org
Subject: Re: [tcpm] draft-ietf-tcpm-rfc2581bis-04 -- a few editorials
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0779593262=="
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

Alfred,

The following are our responses to your comments.  If there are no
remaining technical issues with this document, we consider it
finished.

Thank you for your input.

Ethan

> (1)  Section 1, 2nd paragraph
> 
> Typo:   s/in turned/in turn/

Fixed.

> (2)  Section 1, 3rd paragraph
>     In addition to specifying the congestion control algorithms, this
>     document specifies what TCP connections should do after a relatively
>     long idle period, [...]
> ---                              vv
> |   In addition to specifying these congestion control algorithms, this
>     document specifies what TCP connections should do after a relatively
>     long idle period, [...]

Changed.

> In other words: Taking (3) and (4) together, my net recommendation
> is to swap the second and the fourth paragraph in Section 1.

Changed.

> (5)  Section 3.1 -- additional instance of clarification
> 
> Subsidiary to one of the recent clarifications adopted by the
> draft in a couple of places, I suggest once more to re-state that
> clarification of "outstanding" immediately below formula (4),
> e.g. by changing:
> 
>     where, as discussed above, FlightSize is the amount of outstanding
>     data in the network.
> ---
>     where, as discussed above, FlightSize is the amount of outstanding
>     (i.e., not yet cumulatively acknowledged) data in the network.

This remains unchanged.  We feel it is clear enough as written,
particularly in conjunction with other TCP documents.

> (6)  Section 6
> 
> I suggest to harmonize the text, generally talking about RFC 2581
> in past tense.  To this end, please change:
> 
>          ...  The intention of [RFC2581] is to not change ...
> ---
>          ...  The intention of [RFC2581] was to not change ...

Somewhat more extensive changes were made here.  The paragraph in
question now reads:

    [RFC2001] was extensively rewritten editorially and it is not
    feasible to itemize the list of changes between [RFC2001] and
    [RFC2581]. The intention of [RFC2581] was to not change any of the
    recommendations given in [RFC2001], but to further clarify cases
    that were not discussed in detail in [RFC2001]. Specifically,
    [RFC2581] suggested what TCP connections should do after a
    relatively long idle period, as well as specified and clarified
    some of the issues pertaining to TCP ACK generation.  Finally, the
    allowable upper bound for the initial congestion window was raised
    from one to two segments.

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