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

Wesley Eddy <> Tue, 17 December 2019 17:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 63427120220 for <>; Tue, 17 Dec 2019 09:12:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WjxJeIy-GZbD for <>; Tue, 17 Dec 2019 09:12:26 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2B511120B80 for <>; Tue, 17 Dec 2019 09:12:26 -0800 (PST)
Received: by with SMTP id j5so9273215qtq.9 for <>; Tue, 17 Dec 2019 09:12:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=KrWqjCIjqJNUCUV0w1jR2By8De2J4tnLno+Z81MeulQ=; b=sa3aYk8uondXMNO3qWPQRxFiFGRQpniH84IUq+UUSb+4ie+yZOli02D2Yg4RSZKjKD bVUvTWIuZdMAe/CK/JqwO7w+5ClkBDdnho7H9j84cqNloa3fsfS0NTE3EWe4wRA9t7Dj HLqKJFyEoRfLcC3CdE/tdPrsf9/GfV3u4K7r9P0al5HcCNXWmj1chAN1ijYaHbOCLsnO suZKg5dEKG254dIjnBjbyhhZlrRghAtFUVJD5SRAlilTZpDC+0fE6Zpg8qbbVe8t0oar duStpDjsk4nCtpmDZwdViEXmgBq2lp0mhtBGTj/Sy2O3hg3QO+HAtZwwlqZKgKisWKgr tY2Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=KrWqjCIjqJNUCUV0w1jR2By8De2J4tnLno+Z81MeulQ=; b=MIHIRTesEDOpNqxImBozchQCKiY3OrQT3GjtxE3NWDRTRjBBwOt5Z4UvPwn8yxU7zm aRNeCdylk9/cTfNj0J8onQ2sSFTV7M6vQ852KPt6yCyTmcjcIsqF35SNAx+f+NlP0HsD 478WcRF/8DE4YpJX1kB5eIjRpzcnxupuUrxfF8ZzOrqd2+GNgoDHWBQFkLfkf/3z0miq gbEsr5GEF4Jd4f/Bf9TM4/rEBw1yfFLXVkMCWHjKASXji3b4nnHruP4KHaFWXfIbhSYY 9duFi2iFTHGbo1nvonTWpFzji4IWPSXLH/y07vx+u78ph4G3PPwOclZJligbVIuQ0fQW dWIQ==
X-Gm-Message-State: APjAAAVxFMcM+YdbyPiM9B4c0LHP7Un3ZAzo3WRQpJFmd8XjiaKrw593 74hwaLvr5jN7HK5kxZs/cUiV065/CDI=
X-Google-Smtp-Source: APXvYqx3uLO4BdLp4y8WoMxeZgB/u6bdFLXqZFv81hlapvMwPUU+BRP/OFvTmy5xQHtlun2vTUIEew==
X-Received: by 2002:ac8:71cf:: with SMTP id i15mr5461587qtp.383.1576602745098; Tue, 17 Dec 2019 09:12:25 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id y91sm8295859qtd.28.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Dec 2019 09:12:24 -0800 (PST)
To:, "" <>
References: <>
From: Wesley Eddy <>
Message-ID: <>
Date: Tue, 17 Dec 2019 12:12:23 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [tcpm] review of rev 14 of RFC 793 bis part 1 of 2 - Editorial Comments
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 17 Dec 2019 17:12:28 -0000

I've been working on this comment a bit, and wanted to consult the 
wisdom of the working group:

On 8/28/2019 11:20 AM, Gorry Fairhurst wrote:
> I was amused at the frequent reference to "crash" or "crashing". I'm 
> not sure that presents the correct view of the IETf about the 
> stability of the TCP stack and certainly is not what IO would expect 
> in an RFC that could be promoted to full standard. I think this needs 
> to be changed. 

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".