Re: [Ltru] Process

[Addison Phillips <[e-mail]>]

I've spent some time today thinking about this. My thoughts:

I'm not sure that changing the format of the reviewer job from an 
individual to a group would necessarily improve the process. I think the 
problem with the reviewer job as presently constituted is that it allows 
for arbitrary and binding decisions by an individual and that it 
provides a lack of clarity during the process.

I think the process would best be improved if:

1. Requests were posted to a Web site, along with their current status 
and expiry dates for the current review period and/or process state. The 
most recent approved/rejected items should be visible as well as items 
in progress. I-D tracker is a good model here.

2. Requests should be considered as constituted. Consensus decisions 
should be made about a specific record as requested. Changes to the 
requested record should restart the consideration period. This allows 
for a more reasoned discussion with clear date points.

3. Approved items should have a grace period before being forwarded to 
IANA. This allows any disagreements with the reviewer's decision to be 
decided on the list or appealed to the IESG. Infinite delaying tactics 
must be prevented. So should "pocket vetoes" on the part of the 
reviewer. But it should be entirely clear when something is approved and 
a few days delay in case of a "bad decision" will not hurt anything.

4. Rejections must take the form of either rule violations of BCP 47 
(preventing the registration) or must be decisions about list consensus 
by the reviewer. I think the reviewer's opinion should not count for 
more than everyone else on the list's opinion. By reducing the reviewer 
to "chair of the list", we also reduce appeal inducing decisions to 
those normal to the IETF, that is: that the consensus of the list was 
flawed.

I think this last is important. When Mark and I started this adventure, 
Mark also registered some stopgap tags. These did reach list 
consensus--except for the reviewer, who had to be threatened with appeal 
(at that time unprecedented in list history) to get him to forward the 
registrations. Removing the arbitrary judgment element from the 
reviewer's job does not remove the reviewer's "bully pulpit", but it 
does make this process more reasoned.

So I find that I'm not ready quite yet to support Mark's edits as they 
sit, although I'm *highly* sympathetic to them, having observed the 
general dysfunctionality of ietf-languages of late. It should be easy, 
clear, and entirely straightforward to get a registration... and 
rejections should also be clear. If something remedial can be done to 
them, then the registrant should be clear on what that is. I think we 
can achieve that best *not* creating a review board, but rather by 
pulling the sometimes-arcane rules together more tightly and improving 
the transparency of the process.

Best Regards,

Addison

Mark Davis wrote:
> We clearly need some more process in the spec -- I didn't realize, for
> example, that the armenian tags were added.
> 
> Here is a very rough draft revision of 3.2/3.3, incorporating some ideas
> that we've discussed at various times.
> 
> 3.2. Language Subtag Review Board
> 
> The Language Subtag Board (LSB) consists of three Language Subtag 
> Reviewers.
> Each of the Language Subtag Reviewers.must read and thoroughly understand
> all parts of BCP 47. All decisions of the LSB are by a majority vote. The
> Language Subtag Board is appointed by the IESG for an indefinite term,
> subject to removal or replacement at the IESG's discretion. Any instance
> where the LSB does not follow the procedures in this document are grounds
> for dismissal by the IESG.
> 
> The Language Subtag Board moderates the ietf-languages mailing list,
> responds to requests for registration, and performs the other registry
> maintenance duties described in Section 3.3 (Maintenance of the
> Registry)<http://www.inter-locale.com/ID/draft-ietf-ltru-registry-14.html#maintreg>. 
> 
> Only the Language Subtag Board is permitted to request IANA to change,
> update or add records to the Language Subtag Registry.
> 
> The performance or decisions of the Language Subtag Board MAY be 
> appealed to
> the IESG under the same rules as other IETF decisions (see [RFC2026] 
> (Bradner,
> S., "The Internet Standards Process -- Revision 3," October
> 1996.)<http://www.inter-locale.com/ID/draft-ietf-ltru-registry-14.html#RFC2026>). 
> 
> The IESG can reverse or overturn the decision of the Language Subtag Board,
> provide guidance, or take other appropriate actions. Because of the need 
> for
> stability, however, once a change is posted to
> http://www.iana.org/assignments/language-subtag-registry, it is 
> irrevocable.
> 3.3. Maintenance of the Registry
> 
> Maintenance of the registry requires that as codes are assigned or 
> withdrawn
> by ISO 639, ISO 15924, ISO 3166, and UN M.49, the Language Subtag Board 
> MUST
> evaluate each change, determine whether it conflicts with existing registry
> entries, and within 30 days propose a change to the registry as 
> described in
> Section 3.5.
> 
> The Language Subtag Board MUST ensure that all new subtags meet the
> requirements in Section 4.1 (Choice of Language
> Tag)<http://www.inter-locale.com/ID/draft-ietf-ltru-registry-14.html#choice>or 
> 
> submit an appropriate alternate subtag as described in that section.
> The
> Language Subtag Board MUST respond within 15 days to any language subtag
> request form. The response MUST go both to the submitter, and to the
> Language Tag Registry Mailing List. The response MUST indicate whether the
> request is accepted, or not accepted. If it is not accepted, the Language
> Subtag Board MUST indicate which clauses of BCP 47 would be violated by
> acceptance, and which changes to the language subtag request form would 
> make
> it acceptable.
> 
> Upon acceptance, the Language Subtag Board MUST incorporate corresponding
> changes into a public Draft Language Tag Registry, having precisely the 
> same
> syntax as http://www.iana.org/assignments/language-subtag-registry, and
> notify the Language Tag Registry Mailing List. During a 15-day review
> period, people have the opportunity to review the syntax of the change, and
> the Language Subtag Board may make changes in response to feedback. Any 
> such
> change starts the 15-day review period anew. Once the review period has
> completed, the LSB will change the File-Date and forward the entire file to
> IANA for posting within 7 days. Once IANA has posted the file, IANA MUST
> send a message will be sent to the Language Tag Registry Mailing List
> acknowledging that.
> 
> [Move the following to a section on the form]
> 
> If a record represents a new subtag that does not currently exist in the
> registry, then the message's subject line MUST include the word 
> "INSERT". If
> the record represents a change to an existing subtag, then the subject line
> of the message MUST include the word "MODIFY". The message MUST contain 
> both
> the record for the subtag being inserted or modified and the new File-Date
> record. Here is an example of what the body of the message might contain:
> 
> The set of redundant and grandfathered tags is permanent and stable: new
> entries in this section MUST NOT be added and existing entries MUST NOT be
> removed. Records of type 'grandfathered' MAY have their type converted to
> 'redundant': see item 12 in Section 3.6 (Possibilities for
> Registration)<http://www.inter-locale.com/ID/draft-ietf-ltru-registry-14.html#possibleReg>for 
> 
> more information. The decision making process about which tags were
> initially grandfathered and which were made redundant is described in
> [initial-registry] (Ewell, D., Ed., "Initial Language Subtag Registry,"
> June 
> 2005.)<http://www.inter-locale.com/ID/draft-ietf-ltru-registry-14.html#initial-registry> 
> 
> .
> 
> Whenever an entry is created or modified in the registry, the 'File-Date'
> record at the start of the registry is updated to reflect the most recent
> modification date in the [RFC3339] (Klyne, G. and C. Newman, "Date and Time
> on the Internet: Timestamps," July
> 2002.)<http://www.inter-locale.com/ID/draft-ietf-ltru-registry-14.html#RFC3339>"full-date" 
> 
> format.
> 
> Before forwarding a new registration to IANA, the Language Subtag Reviewer
> MUST ensure that values in the 'Subtag' field match case according to the
> description in Section 3.1 (Format of the IANA Language Subtag
> Registry)<http://www.inter-locale.com/ID/draft-ietf-ltru-registry-14.html#ianaformat>. 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ltru mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ltru

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.

Internationalization is an architecture.
It is not a feature.

_______________________________________________
Ltru mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ltru