IETF Logo Mail Archive

Re: [tcpm] review of rev 14 of RFC 793 bis part 1 of 2 - Editorial Comments

"Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net> Tue, 17 December 2019 18:31 UTC

Return-Path: <ietf@gndrsh.dnsmgr.net>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B67B120C79 for <tcpm@ietfa.amsl.com>; Tue, 17 Dec 2019 10:31:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.497
X-Spam-Level:
X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ki5nqVqWzad8 for <tcpm@ietfa.amsl.com>; Tue, 17 Dec 2019 10:31:40 -0800 (PST)
Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8C111209DF for <tcpm@ietf.org>; Tue, 17 Dec 2019 10:31:40 -0800 (PST)
Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id xBHIVcem098563; Tue, 17 Dec 2019 10:31:38 -0800 (PST) (envelope-from ietf@gndrsh.dnsmgr.net)
Received: (from ietf@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id xBHIVctl098562; Tue, 17 Dec 2019 10:31:38 -0800 (PST) (envelope-from ietf)
From: "Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net>
Message-Id: <201912171831.xBHIVctl098562@gndrsh.dnsmgr.net>
In-Reply-To: <F3A4BF10-AEF6-4C0D-BD18-01FADCA730A0@gmail.com>
To: Jonathan Morton <chromatix99@gmail.com>
Date: Tue, 17 Dec 2019 10:31:38 -0800
CC: Wesley Eddy <wes@mti-systems.com>, "tcpm@ietf.org" <tcpm@ietf.org>
X-Mailer: ELM [version 2.4ME+ PL121h (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/-5smCtKq2FDKxsr6_Ppg95Vi6l4>
Subject: Re: [tcpm] review of rev 14 of RFC 793 bis part 1 of 2 - Editorial Comments
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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>
X-List-Received-Date: Tue, 17 Dec 2019 18:31:41 -0000

> > On 17 Dec, 2019, at 7:12 pm, Wesley Eddy <wes@mti-systems.com> wrote:
> > 
> > I was looking at the way "crash" is used on a case-by-case basis, and I think we could mostly change this to "endpoint failures" or a host "rebooting" rather than "crashing"?  Is there any other terminology or condition that should be explicitly mentioned somehow?  The important point in most places where "crash" is used is that the host has lost all of its memory about connections in-progress and associated connection state, and that's easy to retain without saying "crash".
> 
> I think using "reboot" would be a good substitute here.

Or define CRASH as terminology:

CRASH:	Lost of state by an endpoint, which may be the result of a reboot, power failure, software failure or any other mechanisim.

Then you can leave all the other text as is, and just s/crash/CRASH/g


>  - Jonathan Morton

--
Rod Grimes                                                 rgrimes@freebsd.org

v2.23.0 | Report a Bug | By Email