IETF Logo Mail Archive

[Tsv-art] Re: draft-ietf-opsawg-pcaplinktype-10 ietf last call Tsvart review

Guy Harris <gharris@sonic.net> Wed, 11 June 2025 18:36 UTC

Return-Path: <gharris@sonic.net>
X-Original-To: tsv-art@mail2.ietf.org
Delivered-To: tsv-art@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 29E5433D5149; Wed, 11 Jun 2025 11:36:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level:
X-Spam-Status: No, score=-2.798 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=sonic.net
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2qIKZPY1te1; Wed, 11 Jun 2025 11:36:35 -0700 (PDT)
Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id A5D2133D5085; Wed, 11 Jun 2025 11:36:30 -0700 (PDT)
Received: from smtpclient.apple (173-228-4-226.dsl.dynamic.fusionbroadband.com [173.228.4.226]) (authenticated bits=0) by d.mail.sonic.net (8.16.1/8.16.1) with ESMTPSA id 55BIaNJm008609 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 11 Jun 2025 11:36:24 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sonic.net; s=net23; t=1749666985; bh=qyJ1YVUKTpPnBNOXo+2dSXoufHjibQqOxP0h3j8Q1Mc=; h=Mime-Version:Subject:From:Date:Message-Id:To:From:Subject; b=nuTLDf/DO5RBqJif4ud3S/8trt78INaShwVxuGURRlZbipVEtzqkM7TLXEjS4KLWK RtNgpIO6FnTE9SQQkAEcKYJRGwxQZURBgZ27ohTNDxyfEsBv6LMEQ7kagPRsJVWOPK dBRCejMh6ICdIKg//Xs5TccEjKiuAbhWFpY9tSwBJGC9oUMR5N+dRkvrBLXdaqnLG2 JzfB2uCCNw9u6hU99yanwFubMeMYLuEWzpf7aaEPIcXOjmMIBY8LBjpXe29+zG5DY0 Yz3xTmBoa3MEsQJ1o5+cZrFnOQIqMnHYZr9luBzNEYPHUynXYTLh1TaBZNST+zAx3g ppnjOBIfLddvg==
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.9\))
From: Guy Harris <gharris@sonic.net>
In-Reply-To: <174966025692.4046220.7499825764842834774@dt-datatracker-59b84fc74f-84jsl>
Date: Wed, 11 Jun 2025 11:36:13 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <4E91CC3E-5FCB-4F8A-A3A9-2A9982336E1D@sonic.net>
References: <174966025692.4046220.7499825764842834774@dt-datatracker-59b84fc74f-84jsl>
To: Michael Scharf <michael.scharf@hs-esslingen.de>
X-Mailer: Apple Mail (2.3731.700.6.1.9)
X-Sonic-CAuth: UmFuZG9tSValmg7egqS9prKabuYQYLFJFSzkhRUqMXtwp0K33gX/UiA4IXfbX30QuKSGn0rWRCUNyLZtXWVzrObgPZb4tcLZ
X-Sonic-ID: C;Kuzm+fJG8BGf+Y+Kd2CUWA== M;lCkX+vJG8BGf+Y+Kd2CUWA==
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
Message-ID-Hash: KUOKFMYGYPWQ7YOWZ5LSPJRANOATNZEO
X-Message-ID-Hash: KUOKFMYGYPWQ7YOWZ5LSPJRANOATNZEO
X-MailFrom: gharris@sonic.net
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tsv-art.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: tsv-art@ietf.org, draft-ietf-opsawg-pcaplinktype.all@ietf.org, last-call@ietf.org, opsawg@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Tsv-art] Re: draft-ietf-opsawg-pcaplinktype-10 ietf last call Tsvart review
List-Id: Transport Area Review Team <tsv-art.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/wA5eA8_lGVpbTXegMSkekF28cro>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Owner: <mailto:tsv-art-owner@ietf.org>
List-Post: <mailto:tsv-art@ietf.org>
List-Subscribe: <mailto:tsv-art-join@ietf.org>
List-Unsubscribe: <mailto:tsv-art-leave@ietf.org>

On Jun 11, 2025, at 9:44 AM, Michael Scharf via Datatracker <noreply@ietf.org> wrote:

> - Section 2.2.2: There may be an implicit assumption that entries in the
> registry will only be added, as neither maintenance (e.g., change of a contact
> person) nor removal procedures are specified. As long as only additions have to
> be dealt with, the current specification seems sufficient. Otherwise additional
> considerations on maintenance and removal could make sense, e.g., similar to
> RFC 6335.

About the only reason I would see for removing an entry would be if somebody requested it but never used it, and requested its removal; even in that case, somebody else may have used it. Given that capture files can live indefinitely long, particular link-layer type values can also live indefinitely long, I don't see other reasons to remove it.

I could see entries being modified, both for reasons such as changing the contact person, changing the location of the specification document, clarification of the description, etc..

I'll look at RFC 6335.

v2.46.0 | Report a Bug | By Email | System Status