Re: [tcpm] Some comments on draft-ietf-tcpm-rfc793bis

Wesley Eddy <wes@mti-systems.com> Mon, 22 July 2019 23:49 UTC

Return-Path: <wes@mti-systems.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 BCFA1120048 for <tcpm@ietfa.amsl.com>; Mon, 22 Jul 2019 16:49:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-com.20150623.gappssmtp.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 csJ_41fj-2aX for <tcpm@ietfa.amsl.com>; Mon, 22 Jul 2019 16:49:38 -0700 (PDT)
Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 E6CD5120045 for <tcpm@ietf.org>; Mon, 22 Jul 2019 16:49:37 -0700 (PDT)
Received: by mail-qk1-x730.google.com with SMTP id d79so29792630qke.11 for <tcpm@ietf.org>; Mon, 22 Jul 2019 16:49:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=hbld2l0dYaTrDzeulyMKKCmMboiz9EwcaEhi+/qi2uw=; b=xW3+LcKxhrzoA0Tel54f8kXYAz9BHLTYE1HwSRdAhTRqeyp+cc6GFFXOlBXEfGiqeY 8HyBDQM1ymQRsXHAryApEREIWLHnJpPv1Xya6hK/8aCv1d9Ja3Wks96iC0rj3qpc/NIk b85ZloA1ptAfo3RYhkzNTxQo2k6XBWP02iOAPX8qkCbh5Aw7vW4Od6/cQtS6sIz9ExV4 qmraY9fkisW7Jb9xkEhZtAqce2UdemJcFKSiXljKt8ptDX+8Xuh3DUjB/DXuT5zCtV2M SPNzmmqvzpW60Hj5mk79doMs7r3ND9kzqsAZh0gRAI4L/tmy1wOf7+WIV1/gvWw5r3Og hb2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=hbld2l0dYaTrDzeulyMKKCmMboiz9EwcaEhi+/qi2uw=; b=XRxRyIcUNfQ1mt6C37TxAPPGM6IHryvM1XKwcfv933757WfXq+tv068jhmZCRg88mn uZiDxBArivRtx4A2ZOi2lV3rBawJjfOBjX2DLA7wYNM0WvISUgqcLJl/srvwm1E0NgHl Ab0cqhSz2k9ZdIBsf2aN+qCm2C9JqL0B2P0yG0J2kjtsH5WoKij7FYVrpeKcaml5tON5 4QpGkXUJmYDAnbk5KMv4BRWabLSawNqvJKlvqSG6lP5K9+hMtuNYuARVfEZVN8gPqWll h6aK5sWnQiAiqjic2ZSyKuXid2wpbNfg1Xb2KvDeUumTEuII6lzaTjl2QY4na1sHw9u7 WhwQ==
X-Gm-Message-State: APjAAAWVtxDsRR7uC14nJ54CNca9uJyg60xHMUXpqOU7Paq7Bb4sSIHD qwTaJ+OW5UO9MzFuLv5Hqxy86k8A
X-Google-Smtp-Source: APXvYqzxD0j2rJNtmQjjmqYAJDVn2fQxXKU6fsQCDmGC9hOoO9ygDbphsIFA7PWPyePitd1jgZpjWA==
X-Received: by 2002:a37:f511:: with SMTP id l17mr44010832qkk.99.1563839376839; Mon, 22 Jul 2019 16:49:36 -0700 (PDT)
Received: from [192.168.1.14] (user-12l31c7.cable.mindspring.com. [69.81.133.135]) by smtp.gmail.com with ESMTPSA id w25sm16419606qto.87.2019.07.22.16.49.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jul 2019 16:49:36 -0700 (PDT)
To: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
Cc: "tcpm@ietf.org Extensions" <tcpm@ietf.org>
References: <6EC6417807D9754DA64F3087E2E2E03E2D3BFF25@rznt8114.rznt.rzdir.fht-esslingen.de>
From: Wesley Eddy <wes@mti-systems.com>
Message-ID: <82fda516-59f9-6156-5a08-bd1ada18ac1d@mti-systems.com>
Date: Mon, 22 Jul 2019 19:49:35 -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: <6EC6417807D9754DA64F3087E2E2E03E2D3BFF25@rznt8114.rznt.rzdir.fht-esslingen.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/pQVRM6iSliL91Zsc1LzNIJFKk-U>
Subject: Re: [tcpm] Some comments on draft-ietf-tcpm-rfc793bis
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, 22 Jul 2019 23:49:41 -0000

Hi Michael, thanks for the review.

All of your suggestions look pretty good to me, and I'll plan to apply 
them this week, except for the errata one, which seems like more of an 
open question at the moment.

For historical interest, I did a little homework on the mysterious 
acronym list "SVCs, UUOs, EMTs" refers to, and I think they are:

- SVC = Supervisor Call (IBM S/360)

- UUO = Unimplemented User Operations (DEC-10 system monitor call)

- EMT = Emulator Trap (PDP-11)

In any case, I agree with you that the sentence is more clear to a 
modern reader just by not including the mention of these examples!



On 7/21/2019 10:27 AM, Scharf, Michael wrote:
> Hi Wes,
>
> I went through draft-ietf-tcpm-rfc793bis-13 in the airplane. Here are some minor observations, basically editorial:
>
> * Section 3.6 explains why the document uses the terms "security level" and "compartment" and in what specific context this may matter. However, these terms are used earlier in the document. I believe it could be useful to add a forward reference earlier in the document to Section 3.6 (and Appendix A.1), in particular for implementers who do not implement this. For instance, maybe one could add a forward reference in Section 3.2 Terminology, where these terms seem to be used for the first time.
>
> * Section 3.7.4 defines the Nagle algorithm. The exact same definition is repeated in 3.8.6.2.1 (except for a reference). It is not clear to me why the definition must be repeated in 3.8.6.2.1.
>
> * Section 3.8 states: "The notation used is similar to most procedure or function calls in high level languages, but this usage is not meant to rule out trap type service calls (e.g., SVCs, UUOs, EMTs)." The acronyms SVCs, UUOs and EMTs have not been expanded in RFC 793. I wonder if I am really the only person who is not really familiar with those acronyms? In any case, I believe that "(e.g., SVCs, UUOs, EMTs)" could just be removed from the document.
>
> * I wonder if Erratas should added to the references, in particular if there is an explicit reference to their content. An example would be Errata ID 4772, which is cited like an RFC. Probably this is a formal question to the IESG or the RFC editor... Anyway, I don't know the answer, but it is something we could probably try to find out.
>
> * The Glossary includes terms that are not used in the document. I wonder if we really need to keep entries that maybe mattered in the original RFC 793 only. Actually, I don't even understand why RFC 793 included some entries (e.g., "1822", "leader"), as they do not even show up in the document body of RFC 793.
>
> Finally, I want to note that the document by and large looks good to me and I really encourage others to read it, too.
>
> Thanks
>
> Michael