Re: [tcpm] Roman Danyliw's No Objection on draft-ietf-tcpm-rfc793bis-25: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Thu, 30 September 2021 21:48 UTC

Return-Path: <kaduk@mit.edu>
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 5525F3A0DB6; Thu, 30 Sep 2021 14:48:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level:
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 yIm-yUuhoZLg; Thu, 30 Sep 2021 14:48:36 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0689B3A0C7C; Thu, 30 Sep 2021 14:48:35 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 18ULmGqh015182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 30 Sep 2021 17:48:21 -0400
Date: Thu, 30 Sep 2021 14:48:16 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Colin Perkins <csp@csperkins.org>
Cc: Roman Danyliw <rdd@cert.org>, draft-ietf-tcpm-rfc793bis@ietf.org, tcpm@ietf.org, Stephen McQuistin <stephen.mcquistin@glasgow.ac.uk>, The IESG <iesg@ietf.org>, tcpm-chairs@ietf.org
Message-ID: <20210930214816.GU98042@kduck.mit.edu>
References: <163236958629.2342.800968324528950977@ietfa.amsl.com> <F48A9F91-5385-46A0-9548-08B7AB58D3EB@csperkins.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <F48A9F91-5385-46A0-9548-08B7AB58D3EB@csperkins.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/9zqI-ZVZ0bvFHW63Bw_Pn8gjCE8>
Subject: Re: [tcpm] Roman Danyliw's No Objection on draft-ietf-tcpm-rfc793bis-25: (with COMMENT)
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: Thu, 30 Sep 2021 21:48:41 -0000

On Thu, Sep 23, 2021 at 12:56:46PM +0100, Colin Perkins wrote:
> > On 23 Sep 2021, at 04:59, Roman Danyliw via Datatracker <noreply@ietf.org> wrote:
> > 
> > Roman Danyliw has entered the following ballot position for
> > draft-ietf-tcpm-rfc793bis-25: No Objection
> > 
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> > 
> > 
> > Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
> > for more information about how to handle DISCUSS and COMMENT positions.
> > 
> > 
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/
> > 
> > 
> > 
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> > 
> > Thank you to Kyle Rose for the SECDIR review.
> > 
> > I support Ben, Lars, Warren and Zahed’s DISCUSS positions.
> > 
> > ** Appendix A.1 and the shepherd write-up which explains why the antiquated
> > text around “security compartments” for multi-level systems is still in this
> > draft.  It’s disappointing that there was no prior IETF consensus action to
> > establish the basis of pruning it.  My suggested addition for Appendix A.1
> > would be to make a much clearer statement than “the state of IP security
> > options that may be used by MLS systems is not as clean”.  It isn’t clear what
> > is meant by “clean” – is it intended to say that it is not in fact used?
> > 
> > ** Section 3.1. Per “[TCP Option]; Options#Size == (DOffset-5)*32;”, I found
> > this notation confusing. What does the “#” in “Options#Size” indicate?
> 
> The header format description uses the approach described in draft-mcquistin-augmented-ascii-diagrams-08 to try to be both human and machine readable. 
> 
> It seems this particular syntax fails at the human readable part :-)

Yeah, if you want to ensure I understand this syntax you have to make
draft-mcquistin-augmented-ascii-diagrams a normative reference :)

> It’s also not clear it’s well specified in draft-mcquistin-augmented-ascii-diagrams.
> 
> Maybe Options.size() or size(Options) would be clearer?

Mild preference for the former, here, but either seems a clear improvement
over Options#Size.

-Ben