Re: [tcpm] Please review 793bis!

Tommy Pauly <tpauly@apple.com> Mon, 29 July 2019 19:06 UTC

Return-Path: <tpauly@apple.com>
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 9FD2E120019 for <tcpm@ietfa.amsl.com>; Mon, 29 Jul 2019 12:06:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
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 Pxv7F97l2ywl for <tcpm@ietfa.amsl.com>; Mon, 29 Jul 2019 12:06:46 -0700 (PDT)
Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1944E12001A for <tcpm@ietf.org>; Mon, 29 Jul 2019 12:06:46 -0700 (PDT)
Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.27/8.16.0.27) with SMTP id x6TJ6eF1062720; Mon, 29 Jul 2019 12:06:41 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=8DzQX8F13yPtXrqNJZtoZrp/vSv8mnfd5zH0XiU3ETM=; b=tmlBjdp0WjBqXk9t9okXgJG5TUslxpjxZg9EOx/WXriSOo6ASWYnYJLx0zzU8x3Iek1I lToGZSiTU+3hbB4lPBHjYD2Q+t0AfBcveh4qjmbUiFNw/JQ42wfLKBV4VURVHmy75AJY Fq5K7tgQ0RI75CXRT79bKcBeeV90GvYbGfqwOICtsd1WLW/1iOInTK0VFQ5WZ5Uatg1l i0bVFU9SxlWPkfRaoyC6XG1SDz06L0pubwNdweZ2n3C1yfE5QxjXuDLp+Yiebs/zDZlM 34l1DKP7lvf3ErzQN+0fz2hjtzsP20dRhW1VOu6tcsMs9jsSj3EnOgc2wg+1p7yskwh0 Gw==
Received: from ma1-mtap-s03.corp.apple.com (ma1-mtap-s03.corp.apple.com [17.40.76.7]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 2u0n91vmj2-9 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 29 Jul 2019 12:06:41 -0700
Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by ma1-mtap-s03.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PVF0087N3R3LW00@ma1-mtap-s03.corp.apple.com>; Mon, 29 Jul 2019 12:06:39 -0700 (PDT)
Received: from process_milters-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PVF007003QVJI00@nwk-mmpp-sz12.apple.com>; Mon, 29 Jul 2019 12:06:39 -0700 (PDT)
X-Va-A:
X-Va-T-CD: 920b67be76b6a75641fdfd4ea90c4da9
X-Va-E-CD: 69be58a359e0ce403bce9bb83fb8fd92
X-Va-R-CD: 619c007249ad5d72124eaeedc31aa69f
X-Va-CD: 0
X-Va-ID: c9ff08f1-7e6b-4cc0-84a8-0ddefc877279
X-V-A:
X-V-T-CD: 920b67be76b6a75641fdfd4ea90c4da9
X-V-E-CD: 69be58a359e0ce403bce9bb83fb8fd92
X-V-R-CD: 619c007249ad5d72124eaeedc31aa69f
X-V-CD: 0
X-V-ID: e389869b-bfb5-4a80-a923-7cce0e800c42
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-07-29_09:,, signatures=0
Received: from [17.234.85.221] by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PVF00B303R21A90@nwk-mmpp-sz12.apple.com>; Mon, 29 Jul 2019 12:06:39 -0700 (PDT)
Sender: tpauly@apple.com
Content-type: text/plain; charset=utf-8
MIME-version: 1.0 (Mac OS X Mail 12.4 \(3445.104.2\))
From: Tommy Pauly <tpauly@apple.com>
In-reply-to: <3c742459-a280-17b3-c5b3-a3be3b9cb7c5@mti-systems.com>
Date: Mon, 29 Jul 2019 12:06:32 -0700
Cc: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>, "tcpm@ietf.org" <tcpm@ietf.org>
Content-transfer-encoding: quoted-printable
Message-id: <D6FBDB84-4B51-40E7-B463-F51B0FABD6B3@apple.com>
References: <6EC6417807D9754DA64F3087E2E2E03E2D3CB17C@rznt8114.rznt.rzdir.fht-esslingen.de> <0E7412EE-5D31-4757-8DDC-09866629A4D7@apple.com> <3c742459-a280-17b3-c5b3-a3be3b9cb7c5@mti-systems.com>
To: Wesley Eddy <wes@mti-systems.com>
X-Mailer: Apple Mail (2.3445.104.2)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-29_09:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/-eEOjzL4kTfd1CZaHcvYNxvf_3I>
Subject: Re: [tcpm] Please review 793bis!
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: Mon, 29 Jul 2019 19:06:49 -0000


> On Jul 29, 2019, at 11:53 AM, Wesley Eddy <wes@mti-systems.com>; wrote:
> 
> Thanks for looking at this, and trying to figure out how to make it feel less dated.
> 
> I fully agree with you that people doing new implementations are one of the important targets for doing this work.  When we initially adopted it, we mentioned IoT and userspace code as being likely to "get it wrong" if people needed to slog through 793 + 1122 + errata (if they even found them) + all the other relevant RFCs coming later that make little tweaks here and there.
> 
> At high level, I think purely editorial changes are "ok", but we need to be vigilant that they're actually purely editorial!  (actually, one of your suggestions below is not quite technically correct, so it is a good example of how this is harder than it seems and innocent mistakes are easy to creep in ... I have tried to avoid it as much as possible for exactly this reason)

Yes, I absolutely agree that it's critical to make sure that the editorial changes don't change the meaning. These are good opportunities to tease apart the terminology for things that may be confusing to a current audience, as is the example you cite.

> 
> More specific thoughts on your examples below:
> 
> 
> On 7/27/2019 9:43 PM, Tommy Pauly wrote:
>> Some initial examples of changes that came to mind:
>> 
>> - Structure; there is both a Terminology section (3.2) relatively early on, and a glossary (3.11) near the end. It seems more typical nowadays to have a terminology section up front, and just refer inline to supporting documents (like IP, for example).
> 
> These are a bit different, and the section 3.2 labelled "terminology" really is more of a quick overview of a few of the variables that reoccur frequently, along with the state machine states.  It could be split into subsections like "Key Connection State Variables" and "State Machine Overview", if that would be more clear (and that would be purely editorial).  The glossary is more like an actual terminology section ... whether it goes up front or not is not something I have a strong opinion on. Personally, I have never liked the style in some more recent RFCs where terms are defined before a reader has much clue what they're relevant to, so have slight preference to leave it alone at the end.

+1 to splitting up the terminology section into subsections with titles.

I do agree that just placing the full glossary at the front would be a bit much. Usually, the terminology up front is most useful for defining the most common terms that would otherwise lead to misinterpretation. For example, terms that the glossary defines that are otherwise generic, like "connection", may be good to just define in a rigorous manner up front as what "connection" means in this document.

Some of the other glossary entries are already in the terminology section, like RCV.NXT... it's possible they're not needed twice.

A couple of the glossary entries likely should just be RFC references—such as for FTP and IP.

> 
> 
>> - Many of the RFCs referenced are the older or obsoleted versions
> 
> Those cases should probably be fixed, unless there is a reason for them.  If you indicate them, I'll happily make updates.

I can run through these in a review pass, yes.
> 
> 
>> - Consistency and freshness; some of the terminology feels dated, such as "the local and remote socket numbers" for referring to what is called "port numbers" elsewhere in the document and in current parlance.
> 
> That's a case of not rewriting text from 793/1122.  Do you think it would confuse anyone?

Yes, I think it is a bit confusing, since it is not a clear definition in the current version of the document, and doesn't reference anything else. It's fairly particular to the environment in which TCP was implemented when designed.
> 
> To correct you though, the socket numbers are not just the port numbers, they also include the IP addresses.  That might be something good to put in the glossary?  It's explained in RFC 793 at top of page 5 (but this was a section of 793 that we originally decided to leave out, because it was very basic content that people working in the Internet protocols today learn from textbooks - that they didn't have in 1981, so was in the RFC, and it would be harder to update accurately with regard to all the things that have changed in IP, link layers, other transports, etc, in the meantime).

That's a great clarification to make. I don't see exactly how the previous explanation in RFC 793 on page 5 introduces the concept of a "socket number" particularly. I get that a local socket structure contains both the local/remote ports and addresses, and there is also a local fd number allocated to the socket, but there generally isn't just one "remote socket number" that represents both a port and address in my experience.

Elaborating the text to say that the TCB contains the local address, local port, remote address, and remote port, would be the most clear, I would argue.

> 
>