Re: [tcpm] Please review 793bis!

Tim Wicinski <tjw.ietf@gmail.com> Mon, 29 July 2019 19:32 UTC

Return-Path: <tjw.ietf@gmail.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 6D4D012002F for <tcpm@ietfa.amsl.com>; Mon, 29 Jul 2019 12:32:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Hdrs6VDoyNRo for <tcpm@ietfa.amsl.com>; Mon, 29 Jul 2019 12:31:59 -0700 (PDT)
Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96ACC120025 for <tcpm@ietf.org>; Mon, 29 Jul 2019 12:31:59 -0700 (PDT)
Received: by mail-ot1-x333.google.com with SMTP id j19so25284019otq.2 for <tcpm@ietf.org>; Mon, 29 Jul 2019 12:31:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0vaZjmJa4cCgDXwEMfJkSx5v6gTKs+WaUI0RSYAOJuA=; b=bjIWH1uYRK6fK9glYirMelptg0ZArL309hUJdSWZVxTFqMoLbRduh8Jq6ANHRycVaR dXqCAmG5HGTbPkkJyALpOQBmnUKFYX6VqsXGq2aZxXB04VHRRI/Zv1Z+78Hri09NmuxV EcYGItho8NYYbg+V+lrbUvoa4kjlNcSDU1NY4ZcT5fP1N5fWy8UsU07VDEKSzVVa/Nvp DAJ8eXGHOLeQqBMNrwZ8mG5SkS0pKMUu6GxtIxn8Rp900ub902hlg2507N8CIyT+GgBC 2+DV934+7s7vyj6sjQ+DP9ZykJcz0VD6DDWE6w7/yBZ5WX1BCiO2IVT6BTe0Dl1xm+xu yKMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0vaZjmJa4cCgDXwEMfJkSx5v6gTKs+WaUI0RSYAOJuA=; b=KgCJfaBfZNZoU2kKJxap6zC2aFonmSYJqRsUAqNhswRNAAqVw9bl3xxhLB4THA34Ke gqUvBg/5PVIjwS53ylDRyc0VBvqWcz7O5+TXpmVtgRkJlVs1p+EJstRxjt+aufH0wv2b HqCGtZaOlppVhKOvGFVjFNgRgGepEcOFdta6XdK7+G46J9vtVgjsEBiJ4xWXJnSA6q/o Cy6kpzjxBY6Tu4BZ8v13yP//JM/GGbrA+bpxUqM74pYa7xfQDqKMyiB6uNdI0o0VzjWU ZoGbM/00FHple4pPaQvENZ9XW6AT6r8NEw+Yqwm6j5YFNuHFT724DzV9U02jha6V9ZEG s5YQ==
X-Gm-Message-State: APjAAAUe2/oGfSAPAQtbfj1lLBFljqD9posatYAsI3P8sQJeGV/18jAZ /ve2N1vbgErM4wSE/hWR3mWs8LOuhNDZJLa1XVBBmg==
X-Google-Smtp-Source: APXvYqxDynxntraKdgZa4FuW2HQQlVRtxspgu/4F5rLJBzLXjA9iq0/CG35fw+lQkVig2SzHKp7MXuH5p/hhep5Se+4=
X-Received: by 2002:a05:6830:1250:: with SMTP id s16mr13661272otp.158.1564428718818; Mon, 29 Jul 2019 12:31:58 -0700 (PDT)
MIME-Version: 1.0
References: <6EC6417807D9754DA64F3087E2E2E03E2D3CB17C@rznt8114.rznt.rzdir.fht-esslingen.de> <0E7412EE-5D31-4757-8DDC-09866629A4D7@apple.com> <CADyWQ+FNvQOiPhOHNzKWRZLeinBbC6Ci=rny+Ac-SrDUHF0TyA@mail.gmail.com> <7d37be26-70fc-5303-c5bf-3d379585648f@mti-systems.com> <CADyWQ+GpQROh0vWEZzY48izW+64QDu=BmT=Jfq5=_iEt0Xdr3g@mail.gmail.com>
In-Reply-To: <CADyWQ+GpQROh0vWEZzY48izW+64QDu=BmT=Jfq5=_iEt0Xdr3g@mail.gmail.com>
From: Tim Wicinski <tjw.ietf@gmail.com>
Date: Mon, 29 Jul 2019 15:31:48 -0400
Message-ID: <CADyWQ+E22uANwRMY1wOVky=2Ty03Z=oehRE6Lde9+b+L3LZusw@mail.gmail.com>
To: Wesley Eddy <wes@mti-systems.com>
Cc: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>, "tcpm@ietf.org" <tcpm@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000fc8c4058ed6f2a2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/n9crts-CkaOGcqXumrsi2NN9ksA>
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:32:02 -0000

And I don't want to bike shed all the non-normative language.
So I'm going to chew on this for awhile.

Tim


On Mon, Jul 29, 2019 at 3:28 PM Tim Wicinski <tjw.ietf@gmail.com>; wrote:

> Wes
>
> I've been staring at this one sentence
>
>    It does not replicate or attempt to update the introduction
>    and philosophy content in RFC 793 <https://tools.ietf.org/html/rfc793> (sections 1 <https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-13#section-1> and 2 <https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-13#section-2> of *that*
>    document).
>
>
> The 793 link is the link to 793, but sections 1 & 2 are linked to this
> document.
> Is the intention to link to the older document, or to the -bis document?
> That would help clear up "that document" or "this document" to me.
>
> Back in Section 1:
>
>
>     RFC 793 <https://tools.ietf.org/html/rfc793> and other updates also contain
>    informative and descriptive text for human readers to understand
>    aspects of the protocol design and operation.  This document does not
>    attempt to alter or update this informative text, and is focused only
>    on updating the normative protocol specification.
>
>
>
> in DNSOP we struggled with this same question recently with 2845-bis
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc2845bis/
> Initially, the idea was to make as few a changes as possible to the
> document,
> just make minor fixes.  But it became clear part of the reason there was
> an
> issue with implementation was poor wording in the original document.
> Sadly, I have no simple answers.
>
> On Mon, Jul 29, 2019 at 2:59 PM Wesley Eddy <wes@mti-systems.com>; wrote:
>
>> Hi Tim, I think I agree with the spirit of what you're saying, but am
>> unsure what you suggest changing.
>>
>> The abstract and introduction are pretty verbose about the relation to
>> 793 (why it's being obsoleted) and the history (in what ways it's now
>> obsolete), and there are pointers to the TCP roadmap in sections 1 and 2.
>>
>> Do we need to say things differently somehow?  Any suggestions are
>> welcome.
>>
>>
>> On 7/27/2019 10:06 PM, Tim Wicinski wrote:
>>
>> Tommy
>>
>> For Implementation advice, I would refer people to the TCP Roadmap
>> document (rfc7414) which feels to me to be a better location.
>> rfc7414 (or what may be the best location) should be spelled out more
>> clearly to readers.
>>
>> I noticed on reading through the document structure, there are references
>> to RFC793, yet the document is being Obsoleted.
>> If we're obsoleting an entire document, is it wise to refer back to it?
>> Does that confuse a casual reader?   If there are references to the
>>
>> 793, such as in Section 2, I think it should be included.
>>
>> Tim
>>
>>
>>
>>
>> On Sat, Jul 27, 2019 at 9:44 PM Tommy Pauly <tpauly=
>> 40apple.com@dmarc.ietf.org>; wrote:
>>
>>> Hi Michael,
>>>
>>> Thanks for the note about this (indeed important!) document. I
>>> unfortunately had a conflict for tcpm, so missed the recent meeting, but I
>>> do have some questions about what the group wants to see in reviews of this
>>> document.
>>>
>>> As expected, much of the text remains unchanged from RFC793. While I
>>> understand and agree that it is a non-goal to change any behavior, reading
>>> the document does still feel like it is out of place amongst current RFCs
>>> from a terminology and organizational standpoint. If this is going to be
>>> published as a full STD document, it would be great to have something that
>>> also makes the reading clearer and easier for people new to TCP.
>>> Specifically, as some people are now working on implementations of TCP for
>>> user space stacks or minimal IoT devices, a clean reference would be a
>>> fantastic asset.
>>>
>>> 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).
>>> - Many of the RFCs referenced are the older or obsoleted versions
>>> - 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.
>>>
>>> There's a lot of possible work to be done here, so before people embark
>>> on such reviews, can you clarify which of these categories of input are
>>> useful, and would be incorporated?
>>>
>>> Best
>>> Tommy
>>>
>>> > On Jul 26, 2019, at 11:17 AM, Scharf, Michael <
>>> Michael.Scharf@hs-esslingen..de <Michael.Scharf@hs-esslingen.de>>; wrote:
>>> >
>>> > Hi all,
>>> >
>>> > As discussed at IETF 105, we need reviews of draft-ietf-tcpm-rfc793bis
>>> in order to complete this important TCPM milestone. The draft can be found
>>> at:
>>> >
>>> > https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-13
>>> >
>>> > If you care about TCP (after all you have decided to subscribe the
>>> TCPM list for some reason, no?), please try to find some cycles and please
>>> have a look at this document.
>>> >
>>> > Thanks
>>> >
>>> > Michael
>>> >
>>> > _______________________________________________
>>> > tcpm mailing list
>>> > tcpm@ietf.org
>>> > https://www.ietf.org/mailman/listinfo/tcpm
>>>
>>> _______________________________________________
>>> tcpm mailing list
>>> tcpm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>
>>
>> _______________________________________________
>> tcpm mailing listtcpm@ietf.orghttps://www.ietf.org/mailman/listinfo/tcpm
>>
>>