Re: [tcpm] Erik Kline's No Objection on draft-ietf-tcpm-ao-test-vectors-08: (with COMMENT)

"touch@strayalpha.com" <touch@strayalpha.com> Wed, 02 March 2022 22:58 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 82F1E3A0D02; Wed, 2 Mar 2022 14:58:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.329
X-Spam-Level:
X-Spam-Status: No, score=-1.329 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, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=no 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 ARDw3boMQSoh; Wed, 2 Mar 2022 14:58:52 -0800 (PST)
Received: from server217-1.web-hosting.com (server217-1.web-hosting.com [198.54.114.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 196C73A0D01; Wed, 2 Mar 2022 14:58:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To: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=uBkLK29jOr1DEBTLLcWqq6UBbe0+j9oz5XTnHG5VCXo=; b=5BTjH3BEa6widziA38xFcZVSwQ QQ5k03Zv/wLMV2so2+f0MMXIkfATdg1TjpRhTGSwUV+Pxe6+f+8LS22gQlNpGmQIWyrogjg5MoFjd q7RBvHm2cR4AcdYdmJCw4+p2dXRUicfXLflGH5trSo/NC1qz7Ro6CVQ+Aa2vDZtzCEAi5900jLQ/T lYD4My7IeSJOyKozAxTu59NBnaIDEuBpUZ1cLtWgnPWCvYNFCgWAPwWx+UoJ9wQ5EUe253LELwxmq p6EWZ+Jkfn98I3rPWBbdcEGBHI/swO1ZjDUlG3sw38k+5/59x9YN8Y49daYpoD50mC8Su2owey2gC 8VyMOjXg==;
Received: from cpe-172-114-237-88.socal.res.rr.com ([172.114.237.88]:61541 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 1nPXvi-00FvmM-Uq; Wed, 02 Mar 2022 17:58:51 -0500
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\))
From: "touch@strayalpha.com" <touch@strayalpha.com>
In-Reply-To: <164626001240.28345.8340839844892831962@ietfa.amsl.com>
Date: Wed, 02 Mar 2022 14:58:43 -0800
Cc: The IESG <iesg@ietf.org>, draft-ietf-tcpm-ao-test-vectors@ietf.org, tcpm-chairs <tcpm-chairs@ietf.org>, "tcpm@ietf.org Extensions" <tcpm@ietf.org>, michael.scharf@hs-esslingen.de
Content-Transfer-Encoding: quoted-printable
Message-Id: <91AE1A34-AC44-4BCE-A0E2-5190478B7597@strayalpha.com>
References: <164626001240.28345.8340839844892831962@ietfa.amsl.com>
To: Erik Kline <ek.ietf@gmail.com>
X-Mailer: Apple Mail (2.3693.60.0.1.1)
X-OutGoing-Spam-Status: No, score=-0.2
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/dRTUwT_SSDoEL3EUvN2ViRx3eRg>
Subject: Re: [tcpm] Erik Kline's No Objection on draft-ietf-tcpm-ao-test-vectors-08: (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: Wed, 02 Mar 2022 22:58:57 -0000

Hi, Erik,

Thanks for your review. Comments below; please let me know if you concur or have a better suggestion forward.

Thanks,

Joe

> On Mar 2, 2022, at 2:26 PM, Erik Kline via Datatracker <noreply@ietf.org> wrote:
> 
> Erik Kline has entered the following ballot position for
> draft-ietf-tcpm-ao-test-vectors-08: 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/about/groups/iesg/statements/handling-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-ao-test-vectors/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> [S3.1, etc.; nit]
> 
> * I'm somewhat surprised that IETF standard documentation prefixes aren't
>  being used (192.0.2.0/24, 2001:db8::/32).
> 
>  I do not feel strongly enough, however, to suggest that the examples need
>  to be rewritten and the values recomputed.

We considered this, but test vectors are an odd case. Although they are for “documentation” purposes, the IP addresses given need to be those that can be used in an actual test environment. That’s why we used private addresses rather than documentation addresses.

> [S3.1.4; nit]
> 
> * If these examples are typical of BGP sessions and GSTM (RFC 5082) is
>  a typical BGP deployment practice I would have expected to see the IPv6
>  hop limit in use also be 255, rather than 64.
> 
>  Again: no need to redo all the examples.

Hopcount is not included in the calculation so would not affect the overall results. We can change them if needed, but it would affect only parts of the examples that are not being tested or validated.

--