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.