On Jun 11, 2025, at 11:36 AM, Guy Harris <[email protected]> wrote:
> On Jun 11, 2025, at 9:44 AM, Michael Scharf via Datatracker
> <[email protected]> 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.)
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
