9.4. Reclaiming Assigned Values

Reclaiming previously assigned values for reuse is tricky, because doing so can lead to interoperability problems with deployed systems still using the assigned values. Moreover, it can be extremely difficult to determine the extent of deployment of systems making use of a particular value. However, in cases where the namespace is running out of unassigned values and additional ones are needed, it may be desirable to attempt to reclaim unused values. When reclaiming unused values, the following (at a minimum) should be considered:

• Attempts should be made to contact the original party to which a value is assigned, to determine if the value was ever used, and if so, the extent of deployment. (In some cases, products were never shipped or have long ceased being used. In other cases, it may be known that a value was never actually used at all.)

• Reassignments should not normally be made without the concurrence of the original requester. Reclamation under such conditions should only take place where there is strong evidence that a value is not widely used, and the need to reclaim the value outweighs the cost of a hostile reclamation. IESG Approval is needed in this case.

• It may be appropriate to write up the proposed action and solicit comments from relevant user communities. In some cases, it may be appropriate to write an RFC that goes through a formal IETF process (including IETF Last Call) as was done when DHCP reclaimed some of its "Private Use" options [RFC3942].

• It may be useful to differentiate between revocation, release, and transfer. Revocation occurs when IANA removes an assignment, release occurs when the assignee initiates that removal, and transfer occurs when either revocation or release is coupled with immediate reassignment. It may be useful to specify procedures for each of these or to explicitly prohibit combinations that are not desired.