Subject: [Ltru] Process

From: "Mark Davis" <[email-masked]>
Date: Mon, 25 Sep 2006 08:49:46 -0700

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: "Debbie Garside" <[email-masked]>
Date: Mon, 25 Sep 2006 19:23:29 +0100

I am not sure that I saw the registration forms being submitted for
inclusion into the Registry... 
 
> 3.2. Language Subtag Review Board
 
In essence, I very much like it, although I have not yet looked at the
detailed wording.  However, I would propose the following change from:
 
----
> Any instance where the LSB does not follow the procedures in this 

> document are grounds for dismissal by the IESG.

-----

To 

-----

Any instance where the LSB does not follow the procedures in this document
MAY be considered as grounds for dismissal by the IESG.

----

I think we need to allow for human error.  A simple human error which can be
corrected should not be grounds for dismissal unless it is truly considered
to be negligence on the part of the LSRB.
 
In response to Doug where he wrote:
 
> I would like to see some provision for limited extension of these 30-day
and 15-day limits, in case one or more of the Reviewers is absent or
unavailable, 

> preventing the two-thirds majority vote. I can easily imagine a problem
arising if a request is filed in early to mid-December.

One Reviewer can be unavailable. You would still have a majority vote; thus
only two Reviewers are ever required to action changes. However, there could
be a situation where two (or even 3) Reviewers were unavailable (unlikely I
know) but maybe some wording to say that the LSRB can advise the list of a
time extension where deemed necessary. Necessary can be defined as being
where two or more Reviewers are absent.

On another note, to protect the Registry from requests that may be made by
people with "ulterior motives" I also think it might be appropriate to state
that  x number (for instance 5) of people need to show support for additions
to the Registry that do not form part of the underlying ISO/UN standards.
But I am not completely hung up on this; although it could also encourage
people to comment more often which can only be good.

Best regards

Debbie Garside

  _____  

From: Mark Davis [mailto:[email-masked]] 
Sent: 25 September 2006 16:50
To: LTRU Working Group
Subject: [Ltru] Process

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
<http://www.inter-locale.com/ID/draft-ietf-ltru-registry-14.html#maintreg>
3.3 (Maintenance of the Registry ). 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]
<http://www.inter-locale.com/ID/draft-ietf-ltru-registry-14.html#RFC2026>
(Bradner, S., "The Internet Standards Process -- Revision 3," October 1996.
)). 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.

The Language Subtag Board MUST ensure that all new subtags meet the
requirements in Section
<http://www.inter-locale.com/ID/draft-ietf-ltru-registry-14.html#choice>
4.1 (Choice of Language Tag) 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. 

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
<http://www.inter-locale.com/ID/draft-ietf-ltru-registry-14.html#possibleReg
>  3.6 (Possibilities for Registration ) for more information. The decision
making process about which tags were initially grandfathered and which were
made redundant is described in [initial-registry]
<http://www.inter-locale.com/ID/draft-ietf-ltru-registry-14.html#initial-reg
istry>  ( Ewell, D., Ed., "Initial Language Subtag Registry," June 2005.).

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]
<http://www.inter-locale.com/ID/draft-ietf-ltru-registry-14.html#RFC3339>
(Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps," July
2002. ) "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
<http://www.inter-locale.com/ID/draft-ietf-ltru-registry-14.html#ianaformat>
3.1 (Format of the IANA Language Subtag Registry ).

---

From: "Doug Ewell" <[email-masked]>
Date: Mon, 25 Sep 2006 13:10:19 -0700

Debbie Garside wrote:

>> We clearly need some more process in the spec -- I didn't realize, 
>> for example, that the armenian tags were added.
>

I agree that there was a process lapse here, although I contend it was a 
minor one.  I'm partially responsible for this.  On September 16 I sent 
a mail to ietf-languages noting that the 2-week review period had passed 
for all four tags and that no serious objections remained, and 
recommending that they be approved.  Michael, who was preparing for a 
meeting halfway around the world, asked me to send him the request forms 
so he could forward them to IANA, which I did.  I can't "approve" the 
requests so I didn't send an announcement to that effect, and IANA 
didn't send announcements to the list that they had updated the Registry 
(though I did receive them through Michael).

Remember that the main objections to all four of these subtags had 
originally come from Michael, who ended up approving them.

> However, I would propose the following change from:
>
> ----
> document MAY be considered as grounds for dismissal by the IESG.
> ----
> I think we need to allow for human error.  A simple human error which 
> can be corrected should not be grounds for dismissal unless it is 
> truly considered to be negligence on the part of the LSRB.

I agree.

> One Reviewer can be unavailable. You would still have a majority vote; 
> thus only two Reviewers are ever required to action changes. However, 
> there could be a situation where two (or even 3) Reviewers were 
> unavailable (unlikely I know) but maybe some wording to say that the 
> LSRB can advise the list of a time extension where deemed necessary. 
> Necessary can be defined as being where two or more Reviewers are 
> absent.

I would also like to see whatever Reviewers we end up with -- one, 
three, or whatever -- drop a note to the list whenever they will be 
unavailable for more than a few days.  Everyone understands the notion 
of conflicting commitments, but we need to know when delays and silence 
can be expected.  I don't propose writing this into the RFC since it 
would be almost impossible to enforce; I just think it's a good idea.

> On another note, to protect the Registry from requests that may be 
> made by people with "ulterior motives" I also think it might be 
> appropriate to state that  x number (for instance 5) of people need to 
> show support for additions to the Registry that do not form part of 
> the underlying ISO/UN standards.  But I am not completely hung up on 
> this; although it could also encourage people to comment more often 
> which can only be good.

I'm not sure how well that would work.  I know the IETF tries to steer 
toward "rough consensus" and stay away from "voting."  Additionally, 5 
or any number we could come up with would be arbitrary.  But I certainly 
agree with the principle: if only 1 or 2 ietf-languages list members out 
of 135 speak up, in favor of a proposal or against it, how much do we 
really know?

--
Doug Ewell
Fullerton, California, USA
http://users.adelphia.net/~dewell/
RFC 4645  *  UTN #14

---

From: "Debbie Garside" <[email-masked]>
Date: Mon, 25 Sep 2006 22:38:26 +0100

Doug wrote:

> I agree that there was a process lapse here, although I 
> contend it was a minor one.  I'm partially responsible for 
> this.  On September 16 I sent a mail to ietf-languages noting 
> that the 2-week review period had passed for all four tags 
> and that no serious objections remained, and recommending 
> that they be approved.  Michael, who was preparing for a 
> meeting halfway around the world, asked me to send him the 
> request forms so he could forward them to IANA, which I did.  
> I can't "approve" the requests so I didn't send an 
> announcement to that effect, and IANA didn't send 
> announcements to the list that they had updated the Registry 
> Remember that the main objections to all four of these 
> subtags had originally come from Michael, who ended up approving them.

I don't think there is any dispute that they should be registered it is just
that the list were not informed as would normally (I thought) be the case.
I think this highlights a need for refining the process as proposed by Mark.
I think the current Reviewer and his able assistant have done a fantastic
job in the past :-) 

> I would also like to see whatever Reviewers we end up with -- 
> one, three, or whatever -- drop a note to the list whenever 
> they will be unavailable for more than a few days.  Everyone 
> understands the notion of conflicting commitments, but we 
> need to know when delays and silence can be expected.  I 
> don't propose writing this into the RFC since it would be 
> almost impossible to enforce; I just think it's a good idea.

I agree. But I think it could quite easily be written in.  

Proposed text:

---

LSRB members to inform IETF-languages of any times when they expect to be
unavailable to perform their functions in this role for a period of more
than 3 days.

---

Or some such... Am sure somebody can come up with something better... It's
been a long day with a lot of documents.

> I'm not sure how well that would work.  I know the IETF tries 
> to steer toward "rough consensus" and stay away from 
> "voting."  Additionally, 5 or any number we could come up 
> with would be arbitrary.  But I certainly agree with the 
> principle: if only 1 or 2 ietf-languages list members out of 
> 135 speak up, in favor of a proposal or against it, how much 
> do we really know?

I think what I would really like to see is list subscribers joining in.  You
quote 135.  Is that the actual number subscribed?  If so, I would estimate
only 15-20% ever comment.  I would like to see more encouragement for list
subscribers to participate... 

I would see it as part of the LSRB's duties to encourage more participation
and to inform list members/subscribers.  I would also like to see those who
are responsible for the lists Chairs/Reviewers etc including links in their
email footers to the current documents that are relevant to the working
group.  Somebody joining the list today will not have a clue what we are
talking about or where to find the documents.  Part of standardisation work
is about getting the message out there.  We can create standards to our
hearts content but if people don't know where to find them they are useless.

Best

Debbie

---

From: "Doug Ewell" <[email-masked]>
Date: Mon, 25 Sep 2006 18:17:11 -0700

Debbie Garside <debbie at ictmarketing dot co dot uk> wrote:

> I don't think there is any dispute that they should be registered it 
> is just that the list were not informed as would normally (I thought) 
> be the case.

It would normally be the case.  I think 90% of it was that Michael was 
headed to Tokyo at the time.

> I think this highlights a need for refining the process as proposed by 

+1

>> unavailable for more than a few days.
>
> LSRB members to inform IETF-languages of any times when they expect to 
> be unavailable to perform their functions in this role for a period of 
> more than 3 days.

I don't disagree that it could be written in easily.  I just don't know 
how it would handled as a requirement.  Clearly it's not proof of severe 
dereliction of duty.

> I think what I would really like to see is list subscribers joining 
> in.  You quote 135.  Is that the actual number subscribed?

The list of subscribers is freely available, and it shows 115 non-digest 
members and 19 digest members.  Either I rounded it, or I can't count. 
The actual number is a bit less since some people are subscribed under 
two or more addresses.  (I'm one of them; the one "private member" is my 
work address.)

> If so, I would estimate only 15-20% ever comment.  I would like to see 
> more encouragement for list subscribers to participate...

So would I, but...

> I would see it as part of the LSRB's duties to encourage more 
> participation and to inform list members/subscribers.

I agree with the intent, and I do my best as I'm sure others do, but 
again I'm not seeing how someone could be held to that.  What guidelines 
could be used to determine how good a job someone is doing at getting 
the word out?

> I would also like to see those who are responsible for the lists 
> Chairs/Reviewers etc including links in their email footers to the 
> current documents that are relevant to the working group.  Somebody 
> joining the list today will not have a clue what we are talking about 
> or where to find the documents.  Part of standardisation work is about 
> getting the message out there.  We can create standards to our hearts 
> content but if people don't know where to find them they are useless.

Bob's your uncle:

--
Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14
http://users.adelphia.net/~dewell/
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages

---

From: Addison Phillips <[email-masked]>
Date: Mon, 25 Sep 2006 19:27:47 -0700

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:
> (Bradner,
> June 
> 2005.)<http://www.inter-locale.com/ID/draft-ietf-ltru-registry-14.html#initial-registry> 
> 
> .
> 
> ------------------------------------------------------------------------
> 

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

Internationalization is an architecture.
It is not a feature.

---

From: "Debbie Garside" <[email-masked]>
Date: Tue, 26 Sep 2006 11:14:08 +0100

Doug wrote:

> I agree with the intent, and I do my best as I'm sure others 
> do, but again I'm not seeing how someone could be held to 
> that.  What guidelines could be used to determine how good a 
> job someone is doing at getting the word out?

I don't think we necessarily need to write it into the document, or, indeed,
hold anyone to account, but I think (from memory) on the occasions when
Chairs/Editors have specifically called for comments it has produced a
better response; even if the response is (just) a +/-1.  This should be
standard practice or, at the very least, encouraged as good practice for
list/WG management. 
 
> > content but if people don't know where to find them they 

Thank you :-)

Debbie
> 
> --
> Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  
> UTN #14 http://users.adelphia.net/~dewell/

---

From: Martin Duerst <[email-masked]>
Date: Tue, 26 Sep 2006 19:17:18 +0900

[partially as a co-chair, and partially as a technical contributor]

The IETF has a tradition to keep process as low-key as possible.
It would in my understanding be the first time that more than a
simple "reviewer" is used for a simple registration.

Creating new process is very difficult; it's easy to get it wrong,
and it's easy to make it too elaborate. It's then very difficult
to make it simpler again.

I personally have my doubts that we need that much more process.
I'm also a bit concerned that the IESG will ask a lot of questions
(at least) when they see things such as "Language Subtag Review Board"
or "vote by majority",...

While a lot of people participate on [email-masked], and
many share an understanding of what's problematic with that list
and the review of language tags, the LTRU list is by definition a
different list. I think it would be good if somebody (Mark?) could
put together a list of the problems he sees. Once we have a better
understanding on what we agree are problems, we have a better
chance of finding the minimal, but necessary, solutions.

Regards,    Martin.

At 00:49 06/09/26, 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. 
>
>
>
>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 <http://www.inter-locale.com/ID/draft-ietf-ltru-registry-14.html#maintreg>Section 3.3 (Maintenance of the Registry ). 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 <http://www.inter-locale.com/ID/draft-ietf-ltru-registry-14.html#RFC2026>[RFC2026] (Bradner, S., "The Internet Standards Process -- Revision 3," October 1996. )). 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>http://www.iana.org/assignments/language-subtag-registry, it is irrevocable.
>
>
>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 <http://www.inter-locale.com/ID/draft-ietf-ltru-registry-14.html#choice>Section 4.1 (Choice of Language Tag) 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>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. 
>
>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 <http://www.inter-locale.com/ID/draft-ietf-ltru-registry-14.html#possibleReg>Section 3.6 (Possibilities for Registration ) for more information. The decision making process about which tags were initially grandfathered and which were made redundant is described in <http://www.inter-locale.com/ID/draft-ietf-ltru-registry-14.html#initial-registry>[initial-registry] ( Ewell, D., Ed., "Initial Language Subtag Registry," June 2005.).
>
>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 <http://www.inter-locale.com/ID/draft-ietf-ltru-registry-14.html#RFC3339>[RFC3339] (Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps," July 2002. ) "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 <http://www.inter-locale.com/ID/draft-ietf-ltru-registry-14.html#ianaformat>Section 3.1 (Format of the IANA Language Subtag Registry ). 
>

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 26 Sep 2006 12:11:44 +0200

Let's just allow more time for the decision.  It's nobody's
business if the reviewer is away for a week or two.  If it's
for months there should a substitute.

> The list of subscribers is freely available

That won't tell you much, the one "gmane" subscription should
be "private" for technical reasons, and it's a gateway to any
number of GMaNe users.  Wherever I'm subscribed the first two
things I do is "hide subscription" and "switch to write only"
(because I read via GMaNe) if possible at all - with mailman
it's normally possible.

For "public" (GMaNe's POV) lists I normally don't subscribe,
the "members only" LTRU was an exception at this time, because
I feared that the LTRU Chairs might need fine-grained control.

> http://www.alvestrand.no/mailman/listinfo/ietf-languages

For Web / news (NNTP) / news (RSS) / search access another URL
is http://dir.gmane.org/gmane.ietf.languages

Frank