Hi Guy, > -----Original Message----- > From: Guy Harris <ghar...@sonic.net> > Sent: Wednesday, June 11, 2025 11:10 PM > To: Scharf, Michael <michael.sch...@hs-esslingen.de> > Cc: tsv-...@ietf.org; draft-ietf-opsawg-pcaplinktype....@ietf.org; last- > c...@ietf.org; Ops Area WG <opsawg@ietf.org> > Subject: Re: draft-ietf-opsawg-pcaplinktype-10 ietf last call Tsvart review > > On Jun 11, 2025, at 11:36 AM, Guy Harris <ghar...@sonic.net> wrote: > > > On Jun 11, 2025, at 9:44 AM, Michael Scharf via Datatracker > <nore...@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. > > RFC 6335 is for port numbers and service names. Those are probably more > likely to be un-registered, or reused for a different purpose, than are > LinkTypes. It says, in section 8.2 "Service Name and Port Number De- > Assignment": > > The Assignee of a granted port number assignment can return the port > number to IANA at any time if they no longer have a need for it. The > port number will be de-assigned and will be marked as Reserved. IANA > should not reassign port numbers that have been de-assigned until all > unassigned port numbers in the specific range have been assigned. > > Even if somebody who has requested a given LinkType no longer has any need > for it, there may still be capture files that use it, so it should remain in > the > registry. > > So I'm not sure there needs to be a procedure for releasing an assignment. > > Section 8.4 "Service Name and Port Number Revocation" describes it as > something that "can be thought of as an IANA-initiated de-assignment"; the > only reason I can see of for a de-assignment would be if 1) it was never used > for the assigned purpose and 2) it *is* or *was* used for some other purpose. > The latter would only happen if somebody grabbed the number without telling > the maintainers of the registry or they grabbed it before tcpdump.org started > managing the assignment process. I'm not sure we need a procedure for > working around the first of those two, and I'm not sure how we would > discover the second of those two, given how long tcpdump.org has been > managing the registry. > > Section 8.5 "Service Name and Port Number Transfers" covers transferring the > port number; it describes that process as "a coordinated de-assignment > and assignment". If we don't allow de-assignment, there are no coordinated > de-assignments and reassignment. > > Section 8.6 "Maintenance Issues" says > > In addition to the formal procedures described above, updates to the > Description and Contact information are coordinated by IANA in an > informal manner, and may be initiated by either the Assignee or by > IANA, e.g., by the latter requesting an update to current Contact > information. > > That sounds good as a policy for this registry. (Note that there is no Contact > information provided in the I-D for any LinkTypes.)
I'd be fine with whatever the community decides - including no change at all. I agree that updates of the registry are most likely a corner case, and that is why I have just flagged this comment only as "nit". Michael _______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
