There is a whole section about "Reclaiming Provisional Codepoints" in RFC9000 which requires that the experts check with all implementors if the codepoint is still used. I'm pretty sure that these codepoints are not used anymore (except the latest until we have the final assignment) because all implementations did update with the last couple of revisions, but of course we/the experts can explicitly double-check that. However, otherwise I don't see what we should be waiting for... for how much longer would you want to keep them if you say we can remove later, Martin...?
Also note, that I don't think we did a good job in registering all codepoints we used in different draft versions. If we really want to burn them (for an undefined time frame till we would every need them again), we should add all of them. On 06.02.26, 00:17, "Christian Huitema" <[email protected] <mailto:[email protected]>> wrote: On 2/5/2026 1:38 PM, Martin Thomson wrote: > On Fri, Feb 6, 2026, at 02:31, Roman Danyliw via Datatracker wrote: >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> IANA needs to be instructed to remove, deprecate, or obsolete QUIC Transport >> Parameters enable_multipath provisional and enable_multipath(-06), QUIC Frame >> Type PATH_STATUS, and QUIC Transport Error Code MP_PROTOCOL_VIOLATION > I would not remove these. Instead, I would consider them burned. At least for > now. We have plenty more codepoints available. RFC 9000 provides the option > to have them removed, but that can happen later. Sure, we can say that too. But the authors consensus is "removed", largely based on our assessment of the current deployments -- we do expect that most implementations will move to the final numbers very quickly. If we said "burned", then we are setting the WG for periodic reviews to decide whether the burned numbers should be removed. -- Christian Huitema
