[OPSAWG]Re: [Ext] Re: Éric Vyncke's No Objection on draft-ietf-opsawg-pcaplinktype-12: (with COMMENT)
Amanda Baber <amanda.baber@iana.org> Fri, 10 October 2025 23:07 UTC
Return-Path: <amanda.baber@iana.org>
X-Original-To: opsawg@mail2.ietf.org
Delivered-To: opsawg@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id BF0277129384; Fri, 10 Oct 2025 16:07:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.297
X-Spam-Level:
X-Spam-Status: No, score=-4.297 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, HTTPS_HTTP_MISMATCH=0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=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=iana.org
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 tjzaqKhyi48x; Fri, 10 Oct 2025 16:07:33 -0700 (PDT)
Received: from ppa3.lax.icann.org (ppa3.lax.icann.org [192.0.33.78]) by mail2.ietf.org (Postfix) with ESMTP id DC92D7129370; Fri, 10 Oct 2025 16:07:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iana.org; h= content-type:date:from:message-id:mime-version:subject:to; s= 202509; bh=1Ch7DgRKx3Z33LxrsjGgdOBV4jwq8Nr543cHn4EToyQ=; b=Dbp2s 6y20fFatOVVftDpyTdH6YeODAhJlQ6Gf9qX91PWGz/ygxzpoykBdQfDuHcC3WlfE Dx1hV5wzRJ91AEAbTDcNIRC6mumwhFnxOqJUikYjQ3UEsnA5EarkgUGXj5XYk7/q gSk1hHH6GC9TFzBAM73flD4lOaM9aGHJn3aVbkOYcNrwa1qq1UeUIYbWPFIwET3T 85ZHyvHtiv5XTh5vfUw0AD/4dmo39LI5ZHIVfkMaw0Nv/r/5hGAvlD2Jn1BwPg/F vdOkz4WyrYV/OY1buqYa+QDa60on4exnwgS3XNV1U6xEThQ3gdg1bDDStToEWr1F xZHv0sFVp5Qi5CZpQ==
Received: from MBX112-W2-CO-2.pexch112.icann.org (out.mail.icann.org [64.78.33.6]) by ppa3.lax.icann.org (8.18.1.2/8.18.1.2) with ESMTPS id 59AN7OiU021176 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Oct 2025 23:07:24 GMT
Received: from MBX112-W2-CO-2.pexch112.icann.org (10.226.41.130) by MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.20; Fri, 10 Oct 2025 16:07:22 -0700
Received: from MBX112-W2-CO-2.pexch112.icann.org ([10.226.41.130]) by MBX112-W2-CO-2.pexch112.icann.org ([10.226.41.130]) with mapi id 15.02.2562.020; Fri, 10 Oct 2025 16:07:22 -0700
From: Amanda Baber <amanda.baber@iana.org>
To: "Eric Vyncke (evyncke)" <evyncke=40cisco.com@dmarc.ietf.org>, Michael Richardson <mcr@sandelman.ca>, The IESG <iesg@ietf.org>, "draft-ietf-opsawg-pcaplinktype@ietf.org" <draft-ietf-opsawg-pcaplinktype@ietf.org>, "opsawg-chairs@ietf.org" <opsawg-chairs@ietf.org>, "opsawg@ietf.org" <opsawg@ietf.org>, "Joe Clarke (jclarke)" <jclarke@cisco.com>, "cjbc@it.uc3m.es" <cjbc@it.uc3m.es>
Thread-Topic: [Ext] Re: Éric Vyncke's No Objection on draft-ietf-opsawg-pcaplinktype-12: (with COMMENT)
Thread-Index: AQHcOjqiI7R1O/pZfEeLUyEjD77hWA==
Date: Fri, 10 Oct 2025 23:07:22 +0000
Message-ID: <DC0BDA1C-2F0B-4E1E-A335-118881A100D6@iana.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.63.22070801
x-originating-ip: [192.0.32.235]
x-source-routing-agent: True
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha256"; boundary="B_3842957242_4203478697"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1117,Hydra:6.1.9,FMLib:17.12.80.40 definitions=2025-10-10_06,2025-10-06_01,2025-03-28_01
Message-ID-Hash: 5324RBSAWDA5N34BZSINFWZNUD5S67B7
X-Message-ID-Hash: 5324RBSAWDA5N34BZSINFWZNUD5S67B7
X-MailFrom: amanda.baber@iana.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-opsawg.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [OPSAWG]Re: [Ext] Re: Éric Vyncke's No Objection on draft-ietf-opsawg-pcaplinktype-12: (with COMMENT)
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/vIuxllVeHdJcSXgO3wRIMI3TaPA>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Owner: <mailto:opsawg-owner@ietf.org>
List-Post: <mailto:opsawg@ietf.org>
List-Subscribe: <mailto:opsawg-join@ietf.org>
List-Unsubscribe: <mailto:opsawg-leave@ietf.org>
Hi,
What aspect of FCFS is “First Come First Served With Expert Review” meant to capture?
If it’s just the idea that IANA will address requests as they come in (which may mean requesting clarification from the submitter rather than sending the request directly to the expert), that doesn’t need to be specified by the document.
If the idea is that the review should be extremely minimal, this should be described to the designated expert. 8126 recommends including guidance for the designated expert, and we often see this placed in its own (sometimes brief) subsection.
If the idea is that values will be assigned sequentially, this actually isn’t an FCFS requirement. RFC 8126 says, “IANA generally assigns the next in-sequence unallocated value, but other values may be requested and assigned if an extenuating circumstance exists.”
If sequential assignment is mandatory, this should be stated in the document. If sequential assignment is expected but not mandatory, it could be mentioned to the designated expert. IANA will generally assign values sequentially unless asked to do otherwise.
We do object to “First Come First Served With Expert Review,” though, because “First Come First Served” as defined in RFC 8126 specifically means that there will be no expert review.
Thanks,
Amanda
From: "Eric Vyncke (evyncke)" <evyncke=40cisco.com@dmarc.ietf.org>
Date: Friday, October 10, 2025 at 1:42 PM
To: Michael Richardson <mcr@sandelman.ca>, The IESG <iesg@ietf.org>, "draft-ietf-opsawg-pcaplinktype@ietf.org" <draft-ietf-opsawg-pcaplinktype@ietf.org>, "opsawg-chairs@ietf.org" <opsawg-chairs@ietf.org>, "opsawg@ietf.org" <opsawg@ietf.org>, "Joe Clarke (jclarke)" <jclarke@cisco.com>, "cjbc@it.uc3m.es" <cjbc@it.uc3m.es>
Subject: [Ext] Re: Éric Vyncke's No Objection on draft-ietf-opsawg-pcaplinktype-12: (with COMMENT)
Hello Michael,
Thanks for your quick reply and the proposed changes.
I will let the responsible AD sort out the publication status.
About IANA, I am unsure whether I have seen a FCFS registry with expert review, but happy to stand corrected.
Regards
-éric
On 10/10/2025, 20:50, "Michael Richardson" <mcr@sandelman.ca> wrote:
Éric Vyncke via Datatracker <noreply@ietf.org> wrote:
> ## COMMENTS (non-blocking)
> ### Why informational ?
> The shepherd write-up is rather silent on the intended status of informational
> as it seems to me that proposed standard would be a better fit.
Informational Seems wrong.
I see that the document declares that, and I think that's a copy'n'paste mistake.
It should be std. At one point, we were told that only IETF-stream STD could
create certain categories of registry, and that's why we couldn't go ISE.
> Moreover, draft-ietf-opsawg-pcapng has, rightfully, a normative reference to a
> previous version (draft-richardson-opsawg-pcaplinktype) of this I-D, i.e., this
> creates a downref.
Fixed in my copy.
> ### Abstract
> An abstract should be short of course, but this one is a little too short: why
> not adding reference (expansion at least) for PCAP. It also uses the word
> "describes", which is correct for an informational I-D, even if it actually
> "specifies" the value, i.e., why not 'proposed standard' ?
I'm not sure PCAP still has an expansion, but I've expanded it to "Packet
CAPture". How about:
This document describes a set of Packet CAPture (PCAP)-related LinkType values and
creates an IANA registry for those values.
These values are used by the PCAP and PCAP-Now-Generic specifications.
> ### Section 2
> As I spotted only one use of BCP14 (moreover in an informational I-D) in
> section 3.2 (IANA considerations), please remove this section. See also
> https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/ [datatracker.ietf.org]
> about the use of BCP14 terms in IANA considerations.
fixed.
> ### Section 3.2.2
> Per section 4.2 of RFC 8126, there is no designated expert for a FCFS registry,
> i.e., remove this section or change the registry policy to 'expert review'.
So, we want FCFS with Expert Review.
- [OPSAWG]Éric Vyncke's No Objection on draft-ietf-… Éric Vyncke via Datatracker
- [OPSAWG]Re: Éric Vyncke's No Objection on draft-i… Michael Richardson
- [OPSAWG]Re: Éric Vyncke's No Objection on draft-i… Mahesh Jethanandani
- [OPSAWG]Re: Éric Vyncke's No Objection on draft-i… Mahesh Jethanandani
- [OPSAWG]Re: Éric Vyncke's No Objection on draft-i… Eric Vyncke (evyncke)
- [OPSAWG]Re: Éric Vyncke's No Objection on draft-i… Joe Clarke (jclarke)
- [OPSAWG]Re: Éric Vyncke's No Objection on draft-i… Guy Harris
- [OPSAWG]Re: [Ext] Re: Éric Vyncke's No Objection … Amanda Baber
- [OPSAWG]Re: Éric Vyncke's No Objection on draft-i… Joe Clarke (jclarke)
- [OPSAWG]Re: Éric Vyncke's No Objection on draft-i… Mahesh Jethanandani
- [OPSAWG]Re: Éric Vyncke's No Objection on draft-i… Eric Vyncke (evyncke)
- [OPSAWG]Re: [Ext] Éric Vyncke's No Objection on d… Mahesh Jethanandani
- [OPSAWG]Re: [Ext] Éric Vyncke's No Objection on d… Michael Richardson
- [OPSAWG]Re: [Ext] Éric Vyncke's No Objection on d… Mahesh Jethanandani