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

"Scharf, Michael" <Michael.Scharf@hs-esslingen.de> Sun, 21 July 2019 14:27 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 []) by ietfa.amsl.com (Postfix) with ESMTP id CD87A12013D for <tcpm@ietfa.amsl.com>; Sun, 21 Jul 2019 07:27:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 9wSmQFTRnHMa for <tcpm@ietfa.amsl.com>; Sun, 21 Jul 2019 07:27:56 -0700 (PDT)
Received: from mail.hs-esslingen.de (mail.hs-esslingen.de []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6D0C120159 for <tcpm@ietf.org>; Sun, 21 Jul 2019 07:27:55 -0700 (PDT)
Received: from localhost (localhost.localdomain []) by mail.hs-esslingen.de (Postfix) with ESMTP id 0DEFB25A12; Sun, 21 Jul 2019 16:27:54 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1563719274; bh=SFlqJqipyYGx/6EnGozRnMRmz3iRdNEUYQBZHpLX9VA=; h=From:To:CC:Subject:Date:From; b=YobmE224OoeqvKIpzhuVEfh2uophPHkXDHct7br5NDFcQGx7Hbl9rCq7VfSUvPQFv o5pGF066VJ0ljXkvfX7H2fNNIqVsOV2a2HS/hbrdniQML1ydQ0vKZAOvwn7H9dKB69 iVqu0bsVpuNGEuI/IYFj/fwqI15cdjEB4K1lMjDQ=
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de
Received: from mail.hs-esslingen.de ([]) by localhost (hs-esslingen.de []) (amavisd-new, port 10024) with ESMTP id qNXXAtzAoeqO; Sun, 21 Jul 2019 16:27:53 +0200 (CEST)
Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Sun, 21 Jul 2019 16:27:53 +0200 (CEST)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Sun, 21 Jul 2019 16:27:53 +0200
From: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
To: Wesley Eddy <wes@mti-systems.com>
CC: "tcpm@ietf.org Extensions" <tcpm@ietf.org>
Thread-Topic: Some comments on draft-ietf-tcpm-rfc793bis
Thread-Index: AdU/y0QHaugjFL0hTAywGUTGNy0axg==
Date: Sun, 21 Jul 2019 14:27:52 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D3BFF25@rznt8114.rznt.rzdir.fht-esslingen.de>
Accept-Language: de-DE, en-US
Content-Language: de-DE
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/ybqYC8D39qPMbR7rVfSRksYAxBU>
Subject: [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: Sun, 21 Jul 2019 14:28:06 -0000

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 (except for a reference). It is not clear to me why the definition must be repeated in 

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