I think the procedures proposed in this draft could be simplified a bit if we'd just focus on the actual issue, viz., that the implementation and deployment of a new specification is completely decoupled from the progress of that specification through the standards process. Once any significant deployment has begun, the codepoints used by that deployment become de facto unavailable for future use. The only real issue is whether we want that codepoint usage to be recorded in a public place, or whether we want to pretend officially that the codepoints aren't used, and just let the conflicts arise in the field. >From this perspective, I think the following procedures are problematic: - Section 2, point d: early allocation is conditioned upon whether there is sufficient interest in early (pre-RFC) implementation and deployment in the community as judged by working group chairs or ADs. What the WG chairs and ADs really have to judge is whether failure to issue an early allocation is likely to result in de facto allocation of a codepoint, with consequent conflicts in the future. Of course, there have also been many cases where the codepoint is already in significant deployment before any "official" request for it has been made; WG chairs and ADs should take notice of this fact. - Section 3.1, step 6: "IANA makes an allocation from the appropriate registry, marking it as 'Temporary', valid for a period of one year from the date of allocation. The date of first allocation the date of expiry should also be recorded in the registry and made visible to the public." What is the point of marking it as "temporary"? Once the codepoint is placed into use, it is not any more or less temporary than any other codepoint; the codepoint is unavailable for future reuse as long as the deployments. Any codepoint that is no longer in use can of course be reused, even if its allocation is not marked "temporary". I do not understand the idea of making the allocation "expire" after just one year. Are the deployments going to disappear after one year? If not, then the codepoint allocation will not expire after one year. - Section 3.3: "If early allocations expire before the document progresses to the point where IANA normally makes allocations, the authors and WG chairs may repeat the process in section 3.1 to request renewal of the code points. At most, one renewal request may be made; thus, authors should choose carefully when the original request is to be made." First, it is not up to the authors to "choose carefully" when the original request is to be made. At a certain point in the implementation process, the codepoint is needed. Failure to get the codepoint soon enough will just cause the implementors to make up their own codepoint, which will invariably leak out into deployment. Second, there is no reason whatsoever to put a two-year limit on the early allocation, unless one expects that the deployments using it will magically disappear after two years. I've seen a number of IETF standardization efforts lag six or seven years beyond the actual deployment of the standard. It might be worthwhile for the WG chairs to ask every few years whether the proposed use of a codepoint has been abandoned, but without some assurance that the codepoint will never be used as specified, there is no sense declaring it to be expired. - Section 3.1: "Note that Internet-Drafts should not include a specific value of a code point until this value has been formally allocated by IANA." To me, this seems entirely counter-productive. Failure to publicize the codepoint you're deploying doesn't solve or prevent any problems. To the contrary, including the codepoint values you're using helps to find conflicts. - Section 5: "There is a significant concern that the procedures in this document could be used as an end-run on the IETF process to achieve code point allocation when an RFC will not be published." This concern only makes sense when the codepoint is being requested by another SDO. If it's being requested by a vendor (or set of vendors), well, no vendor will tell it's customers "sorry, you can't have this feature because IETF hasn't allocated a codepoint". The real concern is the opposite -- folks will try to delay the allocation of a codepoint, in order to prevent their quicker competitors from gaining an advantage. But this only leads to the use of codepoints that are not officially allocated. My concrete suggestions for improving the draft would be: - Emphasize that WG chairs and ADs should base their approval of a request on the likelihood that an unofficial codepoint will otherwise get allocated (or the fact that it is already in use). - Eliminate the "temporary" and "automatic expiry" features, aldn eliminate the need to refresh a request after one year. - Eliminate the requirement that an i-d not specify a codepoint value until IANA has allocated it I also think it would be better if the draft stated explicitly that deployment and standardization are completely decoupled, and that pre-RFC deployments are a normal and common practice. The ultimate solution to codepoint allocation problems is to require that new protocols avoid the use of codepoint fields that contain 8 or fewer bits. But perhaps that's not within the scope of this draft.