Re: [tcpm] Comments on draft-ietf-tcpm-ao-test-vectors

"touch@strayalpha.com" <touch@strayalpha.com> Mon, 11 October 2021 22:15 UTC

Return-Path: <touch@strayalpha.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 C02DE3A0E1E; Mon, 11 Oct 2021 15:15:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 yTxeHpBEEofT; Mon, 11 Oct 2021 15:15:27 -0700 (PDT)
Received: from server217-5.web-hosting.com (server217-5.web-hosting.com [198.54.116.226]) (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 2CBE73A0E1D; Mon, 11 Oct 2021 15:15:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=b8Y05cGpZDgApS1OGJd84VI5uN38LC4tJdIp8DPHbnY=; b=yPS1FzqDB6aXOuxw6tD/AYK8YF +sJzMsfOyAI8WM8wX4+jk49uupJdRDMedEDjTYTZ4VdZswoQY13S5zrO2Xy0BuOcMVY1r3A4MB2l1 VLIxq8lTLqIsE2zG8c6j+Y87qWlhgPQOXXvwjGsue/kBM0Sc7Nj0hlI/AY+ypLTX7Y0sZyiP7CoM2 DlItJW0BV4C3QBZH+Rp996/bvkqAQg799f2dGcEZ1g6acPy5vOzlsZyI5eIloUQ7KQ45cvyViM5nk Dh73VvkEMkQ7hKDhNhTjrXQ7gYe6i8hNNgI6NI0QdVp9SZTNospHtiT7ZosJ/iTghEsUOewW30SW6 WxGdbNfQ==;
Received: from cpe-172-114-237-88.socal.res.rr.com ([172.114.237.88]:61191 helo=smtpclient.apple) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <touch@strayalpha.com>) id 1ma3Zo-006Ekt-7N; Mon, 11 Oct 2021 18:15:24 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_73815A8F-449A-40AB-B0A9-85662E834D8E"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: "touch@strayalpha.com" <touch@strayalpha.com>
In-Reply-To: <60c26250abb14655b192083b00f3cd14@hs-esslingen.de>
Date: Mon, 11 Oct 2021 15:15:19 -0700
Cc: "draft-ietf-tcpm-ao-test-vectors@ietf.org" <draft-ietf-tcpm-ao-test-vectors@ietf.org>, "tcpm@ietf.org" <tcpm@ietf.org>
Message-Id: <CEBDB347-DE84-4525-804A-83BFD37A8749@strayalpha.com>
References: <60c26250abb14655b192083b00f3cd14@hs-esslingen.de>
To: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/gf4zRVOdswFJW4EKlEQVmrVgvnE>
Subject: Re: [tcpm] Comments on draft-ietf-tcpm-ao-test-vectors
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, 11 Oct 2021 22:15:33 -0000

Hi, Michael,

Thanks for the comments - some responses below...
—
Joe Touch, temporal epistemologist
www.strayalpha.com

> On Oct 11, 2021, at 3:10 PM, Scharf, Michael <Michael.Scharf@hs-esslingen.de> wrote:
> 
> Joe, Juhamatti,
> 
> I have read draft-ietf-tcpm-ao-test-vectors-01. I find this document useful. I 
> cannot validate the actual test vectors, but I have some (minor) editorial 
> remarks:
> 
> * Abstract:  "The vectors also validate both whole TCP segments as well as 
> segments whose options are excluded for NAT traversal."
> 
> I find the term "NAT traversal" confusing in this context. As outlined in 
> Section 9.2 of RFC 5925, "TCP-AO cannot interoperate natively across NAT/NAPT 
> (Network Address Port Translation) devices, which modify the IP addresses 
> and/or port numbers." The term "middlebox" used in Section 9.1 of RFC 5925 may 
> be a better choice.

It should cite rfc6978 for the latter, and NAT is the term used there because this isn’t a generic middlebox issue.

> * Introduction: "This document provides test vectors from an implementation 
> that has been validated against another routing vendor for interoperability.."
> 
> IMHO a better wording instead of "another routing vendor" would be "another 
> implementation" or the like.

Agreed.

> Nit: ".." at the end oft he sentence.

Yup. Will fix.

> * Section 3.1: "The terms 'active' and 'passive' are used as defined for TCP 
> [RFC793]."
> 
> I think TCPM could (and should) start using 793bis as reference for TCP in 
> documents finished after 793bis, as far as possible. Why do we not eat our own 
> dogfood?

We don’t necessarily want to hold this doc for that update (if it gets held up). So we’ll take this as it goes (presumably ID nits will complain at some point when the other RFC is published).

> * Section 3.1.1 and elsewhere
> 
> The document uses inconsistent spelling of hex numbers. In section 3.1.1 
> capital letters are used, unlike the later examples. I don't understand why. 

I’ll fix that.

> Also, maybe it could make sense to better emphasise that some values are 
> decimal, while others are hex or binary. In most cases it is relatively clear 
> from the context, but in section 3.1.1 one actually has to look at the numbers 
> to understand the encoding.

Agreed.

> Best regards
> 
> Michael
> (with chair hat off)
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm