Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-16.txt

"Scharf, Michael" <Michael.Scharf@hs-esslingen.de> Wed, 25 March 2020 20:23 UTC

Return-Path: <Michael.Scharf@hs-esslingen.de>
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 4173C3A0DB7 for <tcpm@ietfa.amsl.com>; Wed, 25 Mar 2020 13:23:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de
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 kx6DiwYQ1lyd for <tcpm@ietfa.amsl.com>; Wed, 25 Mar 2020 13:23:21 -0700 (PDT)
Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D83493A0DA3 for <tcpm@ietf.org>; Wed, 25 Mar 2020 13:23:20 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 9E5D225A13; Wed, 25 Mar 2020 21:23:18 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1585167798; bh=pzLuzbN24O+8HUlxNJDdL9fANQpJImIwyCDQHFWDVoU=; h=From:To:Subject:Date:References:In-Reply-To:From; b=k0UvYYRTpM63idUxHzT/a2RkvefejplEvjUIgzY+YHg/v7rP3Vt1CkaTCBz/ia0/G O1ka/UCjt/HWmsQi5KyOA6WF8XfVezz1NjQDPKJ3LSB9BfLt1uVROkozVtywNQNyKQ GoC8FVZXs+EZ0PdDJ0/qF0wqg7geDcxzS9SXJ42E=
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de
Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOkYW573IWeO; Wed, 25 Mar 2020 21:23:16 +0100 (CET)
Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Wed, 25 Mar 2020 21:23:16 +0100 (CET)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.209]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Wed, 25 Mar 2020 21:23:16 +0100
From: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
To: Wesley Eddy <wes@mti-systems.com>, "tcpm@ietf.org" <tcpm@ietf.org>
Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-16.txt
Thread-Index: AQHWAeQDVOPAwP3wcE+cSz2/l6gpBKhXtwMAgAIDhJA=
Date: Wed, 25 Mar 2020 20:23:15 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2DA3C193@rznt8114.rznt.rzdir.fht-esslingen.de>
References: <158505800923.11744.10324863157807137499@ietfa.amsl.com> <58154b27-7a38-1ec3-9ab3-8a1acd25f952@mti-systems.com>
In-Reply-To: <58154b27-7a38-1ec3-9ab3-8a1acd25f952@mti-systems.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [134.108.48.164]
Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2DA3C193rznt8114rzntrzd_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/cutUC_TJhjhDa0opPwICWq2RaAo>
Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-16.txt
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: Wed, 25 Mar 2020 20:23:29 -0000

Hi Wes,

Regarding 1), I think that has been some (supportive) list discussion on cleaning up the IANA registry.

To provide some data point, here is how I would answer the first two questions in my summary – as usually as individual contributor:


Question 1: Should an IANA registry be created for bits 4, 5, and 6 with status "Reserved", which are missing on https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml?

=> Michael’s opinion: Yes, I think this should be done in 793bis


Question 2: Should the IANA registry move to a sub-registry on the Transmission Control Protocol (TCP) Parameters page (https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml).

=> Michael’s opinion: Yes, I think this should be done in 793bis


A little bit more tricky is the third question, which mostly matters for the entry created by RFC 8311…

Question 3: Should past (and current) use of bits be documented in the IANA registry, and, if so, how?

=> Michael’s opinion: We could discuss whether to change the table structure (see https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml#tcp-header-flags-1) to record past use, e.g., by adding another column and moving the statement “previously used by Historic [RFC3540] as NS (Nonce Sum)” to that new column. The new column could have a title such as “Comments”, “Past Use”, etc. That would be a purely editorial change, as it would just reorganize the table, but not change any entry. I don’t have a particularly strong opinion on that, though. Even if we decided that this was useful, we could also postpone that change to the first standards-track document that actually needs this, e.g., by reallocation bit 7 to a new use. Until this happens, the current table format still works. So my suggestion would be to do nothing unless others from the community strongly support a change by 793bis.


Of course, comments from others would really help, too.

Michael



From: tcpm <tcpm-bounces@ietf.org> On Behalf Of Wesley Eddy
Sent: Tuesday, March 24, 2020 3:09 PM
To: tcpm@ietf.org
Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-16.txt


In this update, I think everything is addressed except for 4 topics:

1) Reserved bits description - I made no changes yet.  Discussion spanned a few threads, but didn't look to me like it converged.  Michael's summary thread covers a number of options and relevant questions: https://mailarchive.ietf.org/arch/msg/tcpm/UOHo4tXQPpBV90U-pRmdt_LfjRA/

2) R1 and R2 values - Gorry questioned whether (A) applications should still be notified with R1 is reached, and (B) whether R1 = 3 RTOs and R2 >= 100s are still recommended values.  I don't think any other RFC or errata has revised these, so am inclined to leave it alone for now in this doc, but maybe bookmark it as a topic for future consideration in the working group.

3) Dead gateway detection - I made no changes yet; this may be another topic for potential future consideration.  The question is posed here: https://mailarchive.ietf.org/arch/msg/tcpm/IGhHYUOCwES7I-DjsgHnFsa-zVY/

4) OPEN+LISTEN while same local port is in SYN-SENT/RECEIVED - I made no changes yet, but Gorry suggested that the text below may need updating with regard to modern systems (I'll be grateful for specific suggested changes on this):

A TCP that supports multiple concurrent users MUST provide an
OPEN call that will functionally allow an application to LISTEN
on a port while a connection block with the same local port is
in SYN-SENT or SYN-RECEIVED state (MUST-42).



On 3/24/2020 9:53 AM, internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> wrote:



A New Internet-Draft is available from the on-line Internet-Drafts directories.

This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF.



        Title           : Transmission Control Protocol Specification

        Author          : Wesley M. Eddy

 Filename        : draft-ietf-tcpm-rfc793bis-16.txt

 Pages           : 106

 Date            : 2020-03-24



Abstract:

   This document specifies the Internet's Transmission Control Protocol

   (TCP).  TCP is an important transport layer protocol in the Internet

   stack, and has continuously evolved over decades of use and growth of

   the Internet.  Over this time, a number of changes have been made to

   TCP as it was specified in RFC 793, though these have only been

   documented in a piecemeal fashion.  This document collects and brings

   those changes together with the protocol specification from RFC 793.

   This document obsoletes RFC 793, as well as 879, 2873, 6093, 6429,

   6528, and 6691 that updated parts of RFC 793.  It updates RFC 1122,

   and should be considered as a replacement for the portions of that

   document dealing with TCP requirements.  It updates RFC 5961 due to a

   small clarification in reset handling while in the SYN-RECEIVED

   state.



   RFC EDITOR NOTE: If approved for publication as an RFC, this should

   be marked additionally as "STD: 7" and replace RFC 793 in that role.







The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/



There are also htmlized versions available at:

https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-16

https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-16



A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-16





Please note that it may take a couple of minutes from the time of submission

until the htmlized version and diff are available at tools.ietf.org.



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/





_______________________________________________

tcpm mailing list

tcpm@ietf.org<mailto:tcpm@ietf.org>

https://www.ietf.org/mailman/listinfo/tcpm