Hi,
I am working with Michelle on responses and updates after IETF last call. Most
of the issues give rise to relatively easy changes, and Michelle can handle them
in a new revision with a note saying what has changed and why.
But Eric's email gives rise to a wider and more difficult point on which I want
to comment.
Eric wrote:
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.
This is, indeed, the fundamental issue. And it is sometimes called "squatting".
Squatting arises from legitimate early implementations of Internet-Drafts that
will one day be published as RFCs, from legitimate early implementations of
Internet-Drafts that turn out to be substantially modifies before publication,
from legitimate early implementations of Internet-Drafts that will turn out to
be dead-ends and never get published, from companies that do their own things
that they may or may not reveal to the world, and from other SDOs who decide to
publish standards that need code points.
The way we have handled this in the past is by partitioning our code spaces and
assigning each part an allocation policy. There is a good spectrum of allocation
policies available in RFC 5226, but it is up to working group consensus (backed
by IETF consensus) to assign the allocation policy when the registry is created,
and to vary that policy at any time.
IANA cannot vary the allocation policies for a registry - these are ours to set,
and IANA simply acts on them.
The early allocation thing was created to "blur the edges." That is, to cover
the case where exactly the case that Eric describes arises, but where the
registries require publication of a document (usually an RFC). The procedures
were documented in RFC 4020, but that was almost in the nature of an experiment.
The document in hand is attempting to tighten up the rules so that IANA knows
how to handle early allocations.
The base assumptions are:
- Early implementations really ought to be happening within two years of a
publication request, but if things go wrong we can run an exception process to
save ourselves.
- That implementations that get early deployment (i.e., beyond lab tests) will
be of I-Ds that are fundamentally stable and do not risk code points being
abandoned.
- That some code spaces are quite small and have precious resources.
- That IANA should not have to apply judgement, but should follow rules.
Now, to the rest of Eric's points...
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.
This gives me heartburn. It says that anyone can write any half-arsed protocol,
implement and deploy it and then demand that the code point is allocated
regardless of what the registry allocation rules are. I could even do a DoS on
some protocols by claiming all the remaining available code points.
This is so fundamentally different from the existing way that we run our
registries that I don't think we can hold it as a comment against this document.
You might raise it as part of the discussion of the bis on RFC 5226 that is in
the pipe. Or you might raise it as an existential question for our existing
processes.
However, we can change to read...
d. The working group chairs and ADs judge that there is sufficient
interest in the community for early (pre-RFC) implementation
and deployment, or that failure to make an early allocation might
lead to contention for the code point in the field.
- 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.
Yes, in practice some code points do disappear after early allocation.
This happens when the implementation is not actually deployed, when the
allocated code point is not actually used in the implementation, when the
deployed early implementation is replaced with a different implementation
(perhaps of a more stable spec or perhaps of another protocol).
However, I think that most of your objection here is tied back to your main
point (above) about how we handle our registries and allocations. I don't think
this document can address that, because I don't think that early allocation is
to be used as an end-run on RFC 5226 and our other processes. If they are broken
we should fix them, not use early allocation as a sticking plaster.
- 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.
Well, that is a good point at which to choose.
What "choose carefully" really means is "Don't ask for the code points at the
point of writing the first draft. Don't even ask at the point of starting to
code an implementation. Ask when you need them."
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.
Again, I think this comes back to your main point although it is closer to the
substance of this document.
This text makes early allocations soft state. If there was some screw up or if
the protocol never made it we should be able to reclaim the code points.
Furthermore, as the text explains, the two year limit can be varied by the ADs.
I've seen a number of IETF standardization efforts lag six or seven years
beyond the actual deployment of the standard.
Mutter :-)
I don't think the standard was deployed.
But really, this should not be happening. Let's fix the real problem and not try
to fix the consequences.
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.
This formulation requires the chairs to know what is going on, to drive their
documents, and to ask every year.
I prefer the idea of us getting on with our work in a timely way.
- 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.
I wish that was the case.
When it was common practice to include numbers in I-Ds as they went forward to
publication, there were many cases where two I-Ds would clash for a number.
(This probably arises because people try to pick the next available number).
In several cases this gave rise to implementations competing for a number and
one of them having to change.
OTOH, I see no reason why values should not be included in an I-D once early
allocation has been done. The "formal allocation" should be clarified to include
early allocation.
- 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".
And it takes very strong management of an SDO to its members "you can't have
this standard because the IETF hasn't allocated a code point."
Perhaps we come to the nub of the issue. The standards process and the
management of registries is hugely based on a form of cooperative good will. If
people, companies, or SDOs are not willing to play by the rules of engagement it
would be more useful to set the rules in a way that flushes them out, than it
would be to remove the rules and have a Wild West.
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.
I am sure you do not put yourself in the category of someone who would act like
this. So are you are claiming here that WG chairs and ADs will use their IETF
positions for commercial benefit?
I suggest that if you see it happen you should call it loud and clear. We have a
complaints process and an appeal process. We can recall ADs. Rather than imply
that this will happen, act when/if it does.
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).
OK. Factored into 2d.
- Eliminate the "temporary" and "automatic expiry" features, aldn eliminate
the need to refresh a request after one year.
I don't think so, but I would be interested to hear from others.
For me, the refresh just keeps things clean without causing damage.
- Eliminate the requirement that an i-d not specify a codepoint value until
IANA has allocated it
As above, I disagree with this as well, but would be interested to hear from
others.
With the clarification in 3.1 that early allocation counts for this point, if
you *need* to mention a code point, then get an early allocation.
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.
I don't think that is the job of this document.
I think that people who care about this (for the protocols they work on) should
make sure the registries allow this type of development. RFC 5226 gives plenty
of options for allocation policies where code points can be granted "on demand".
Don't break all of the allocation policies. Pick the one you need.
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.
Right.
Many thanks for the considerable thought you have given this issue.
I hope the above captures at least some of your concerns and gives direction to
the other ones.
Adrian