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

"Scharf, Michael" <Michael.Scharf@hs-esslingen.de> Tue, 23 July 2019 11:29 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14B5F1201E7 for <tcpm@ietfa.amsl.com>; Tue, 23 Jul 2019 04:29:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xv7TW927lgfG for <tcpm@ietfa.amsl.com>; Tue, 23 Jul 2019 04:29:31 -0700 (PDT)
Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9A601201F0 for <tcpm@ietf.org>; Tue, 23 Jul 2019 04:29:21 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 55D1225A12; Tue, 23 Jul 2019 13:29:20 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1563881360; bh=kZ6/r73dnAbiXFtNAqNkoBIahV5NWKYdZ5bT0VpWWjg=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=z0hHZx4/XdcmWN12qsiwVG74DxtLtloAkqGFb/Fki2TElReXSA+xFUlJTFYeDm5gt yE7BPF86Hb0RqMor+YW1qSACXLa5xqr4Xw+Zb1EwiBAWNzD2MbWISJtAg/2LXml/O7 wO1TiE+QSbOOMhkQBNougJswRJK1ajH/WOSA4RwI=
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de
Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6TMaD2Bl2K6; Tue, 23 Jul 2019 13:29:19 +0200 (CEST)
Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Tue, 23 Jul 2019 13:29:19 +0200 (CEST)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.191]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Tue, 23 Jul 2019 13:29:19 +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/y0QHaugjFL0hTAywGUTGNy0axgBDBYCAABxUN6A=
Date: Tue, 23 Jul 2019 11:29:17 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D3C3F4B@rznt8114.rznt.rzdir.fht-esslingen.de>
References: <6EC6417807D9754DA64F3087E2E2E03E2D3BFF25@rznt8114.rznt.rzdir.fht-esslingen.de> <82fda516-59f9-6156-5a08-bd1ada18ac1d@mti-systems.com>
In-Reply-To: <82fda516-59f9-6156-5a08-bd1ada18ac1d@mti-systems.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [134.108.29.249]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/DCCBvraLzuGxBYkY-wcZ698NDoU>
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: Tue, 23 Jul 2019 11:29:33 -0000

I agree that we can leave the errata citation style as is. The RFC editor may have to sort this out.

BTW, I have tried to reverse engineer "SVC" myself and came to the same conclusion, but then I gave up. 

Thanks

Michael

> -----Original Message-----
> From: Wesley Eddy <wes@mti-systems.com>;
> Sent: Tuesday, July 23, 2019 1:50 AM
> To: Scharf, Michael <Michael.Scharf@hs-esslingen.de>;
> Cc: tcpm@ietf.org Extensions <tcpm@ietf.org>;
> Subject: Re: Some comments on draft-ietf-tcpm-rfc793bis
> 
> 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