Process Enhancement

[Doug Ewell]

Mark Davis <mark dot davis at icu dash project dot org> wrote:

> I suggest that we discuss with iana an enhancement of the process used
> for registration. I believe that this is consonant with the current
> rules, although it could be formalized in the 3066ter revision
> eventually.

+1, with reservations.  See below.

> Problem.
> Once a code appears in the registry, we are committed to it. However,
> there are various points of possible failure; either the reviewer or
> the iana staff could make a mistake in transcription.
>
> Proposal.
> To help prevent that, I suggest the following:
>
> 1. All changes to the language subtag registry are first made in a
> trial version of the registry, located at
> http://www.iana.org/assignments/language-subtag-registry-beta.
> 2. Any time this beta file is changed, a notice is sent out to the
> ietf-languages at iana.org list. This starts a 1 week review period
> for of those changes.
> 3. At the end of the period, if nobody on the list raises an
> objection, the reviewer notifies iana to release the beta: the
> contents are copied to
> http://www.iana.org/assignments/language-subtag-registry.
> 4. If an objection is raised, then an additional week will be allowed
> for discussion. At the end of that period, the reviewer will either
> request iana that
> 4a. the release is to proceed or
> 4b. the beta file is to be modified, which returns to Step 2.
>
> (these are numbered for reference).

Stability of a standard or protocol is almost always a Good Thing, and 
in particular it was one of the goals of the LTRU project.  The old 
1766/3066 registry had errors that could be quickly retracted after 
publication; the same is not true of the new registry.  We certainly 
don't want any permanent clerical errors of either the KHMER NNO type or 
the FHTORA type.  So in principle, I'm in favor of this.

I'm concerned, however, about the additional steps and potential for 
additional delay brought on by this proposal.  As we're seeing right 
now, even the simplest possible change to the registry -- with only two 
real steps and no review period -- can end up taking months.  For each 
step of this proposal, we are making an assumption of timeliness on the 
part of either the list, the reviewer, or IANA:

1. IANA will create the beta registry quickly
2. the 1-week review period will take only 1 week
3. the Reviewer will notify IANA quickly;
   IANA will release the beta quickly
4. only 1 additional week will be allowed
4a. (see 3) or
4b. IANA will modified the beta file quickly

All of this takes place *after* the normal two-week review of the 
technical merits of a user-requested addition or change.

I'd like to see two restrictions in particular.  First, objections 
raised during this new beta review period MUST be editorial in nature 
only.  They must not rehash the technical arguments; that is what the 
initial two-week period is for.  (As usual, there should be no technical 
debate at all about standards-driven changes.)

Second, there needs to be some sort of limit on the number of iterations 
allowed in Step 4b.  Otherwise we are setting ourselves up for another 
round of denial-of-service attacks by a lone dissenter.

--
Doug Ewell
Fullerton, California, USA
http://users.adelphia.net/~dewell/