Hi Michael/Guy, The -13 version of the document is not clear on what the Registration Policy being requested is. The document states:
"Note that historically, values were assigned incrementally following First Come First Served (FCFS) policy with Expert Review.” That statement is referring to what was done historically. Going forward, what is the suggestion for the registry? RFC 8126, Section 4.4 is clear that FCFS with Expert Review does not make sense. You can have a Change Controller as a field in the registration, but that is for each entry. Are you signing up to be a Change Controller for all the entries in the registry? Please clarify. Thanks. > On Oct 10, 2025, at 4:07 PM, Amanda Baber <[email protected]> wrote: > > 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)" <[email protected] > <mailto:[email protected]>> > Date: Friday, October 10, 2025 at 1:42 PM > To: Michael Richardson <[email protected] <mailto:[email protected]>>, The > IESG <[email protected] <mailto:[email protected]>>, > "[email protected] > <mailto:[email protected]>" > <[email protected] > <mailto:[email protected]>>, "[email protected] > <mailto:[email protected]>" <[email protected] > <mailto:[email protected]>>, "[email protected] <mailto:[email protected]>" > <[email protected] <mailto:[email protected]>>, "Joe Clarke (jclarke)" > <[email protected] <mailto:[email protected]>>, "[email protected] > <mailto:[email protected]>" <[email protected] <mailto:[email protected]>> > 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" <[email protected] > <mailto:[email protected]>> wrote: > > Éric Vyncke via Datatracker <[email protected] <mailto:[email protected]>> > 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] > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/__;!!PtGJab4!6ZgeHl_dXC_WAICl8IkA5xqCC4pSGjVhwjFlynomZdn2q5G22n4eBQQfGy4xhsgM6csACMhTGjekJqKqoYA4v5vP99pEcdBNSir4FPs$> > > 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. Mahesh Jethanandani [email protected]
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
