Re: [tcpm] Please review 793bis!

Wesley Eddy <> Mon, 29 July 2019 18:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 79CCB12001E for <>; Mon, 29 Jul 2019 11:53:50 -0700 (PDT)
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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YPi_PevE8miQ for <>; Mon, 29 Jul 2019 11:53:48 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 25AB412001A for <>; Mon, 29 Jul 2019 11:53:48 -0700 (PDT)
Received: by with SMTP id j5so118243140ioj.8 for <>; Mon, 29 Jul 2019 11:53:48 -0700 (PDT)
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=Eh641ODxZBC3hTwd840ISvbjTLuvaH/Go2SVh86C1TQ=; b=wDYaQA21GidmcoVRflbzzvAcH6xB+Sk+N4sPKDpeQyluLJSFeDFMOydoUi6x86xyAN GAylfTcMKgluyPcgMXUrZdyNPfF5QaFX6qnJjLh9LeqkSM0gldSZ+jcV5ThJOUGozVUG OfnuhIPCyI5cNA5vlHDWr8/X3sKHqtUeZwmAHqutWA7JOwC4GyIvrrj+dTA2TTPU4FiJ 7IIFK+GkNQlo0Fm+8Ja9urIvU8mnLm18FSHFXeCVvXHnbKUw+IBt6ZZe160e93QR7TeO SKq5tljJgKsEItUPbO+v/NS/5fHd13YBSMQCwxq3nEq/G9IG3MNxnZco+lJ0XpAzBhgE D9gA==
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=Eh641ODxZBC3hTwd840ISvbjTLuvaH/Go2SVh86C1TQ=; b=CbMVSif2im3A+Fh9+awq6l0SQTwZu4jvvW9Gbvb1urD3IEmyNHO8culWp/2m3Q6g9O F/076drU2CecTVmowvrrEnKzxS0x2w5V9xNDN5hIk4KhOraIi3SvCV+WSxVZfsQtyTqo N2kvgCmS9TFRwtDttB5N+pBZiZBnrFTbyVNvQXmhE39HyRMjEt+Fs6s2vRyuOc5IHiZw kWdTnLZBRG7mdUXG8fjynGGe46hjBknOoIeStqeyKWwqbmKwowVtn1DDaYundrsBBueG pJsA7MziMsE+eacm0C0UDY+xdjcmhwt1fbBS6FIfNLixlbz/a/sXOl30F8PyNfUEs2Go qvCg==
X-Gm-Message-State: APjAAAVxcmIXxGehQdaxlWsee4gJQ//P8qi6obzWr9otVvnsHL69uVO+ boe7oNg+j+lxRlD58HA5A05w/z0/
X-Google-Smtp-Source: APXvYqz/3OP/SunfMI5UNV2b9bxn0wngyXC+YyRYPzObvDPeveBqiLXtZo2669XLXKJIlieIC4r+mQ==
X-Received: by 2002:a05:6602:2248:: with SMTP id o8mr37526183ioo.90.1564426427175; Mon, 29 Jul 2019 11:53:47 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id p63sm62262651iof.45.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jul 2019 11:53:46 -0700 (PDT)
To: Tommy Pauly <>, "Scharf, Michael" <>, "" <>
References: <> <>
From: Wesley Eddy <>
Message-ID: <>
Date: Mon, 29 Jul 2019 14:53:45 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
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] Please review 793bis!
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: Mon, 29 Jul 2019 18:53:51 -0000

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)

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.

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

> - 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?

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