Subject: [Ltru] Language Subtag Reviewer Appointment

From: "Scott Hollenbeck" <[email-masked]>
Date: Tue, 21 Feb 2006 08:00:12 -0500

Section 3.2 of draft-ietf-ltru-registry requires the IESG to appoint a
language subtag reviewer.  Given that we currently have a reviewer in
Michael Everson who has been performing this service under the terms of RFCs
1766 and 3066, I recently asked him if he would be willing to continue given
the additional duties, such as list moderation and IANA coordination, that
are described in the recently approved draft.  An, um, enlightening
discussion followed.  Start of thread on the ietf-languages list here:

http://www.alvestrand.no/pipermail/ietf-languages/2006-February/003923.html

Mr. Everson has stated that he is willing to review language tags, but he is
unwilling to moderate or maintain the ietf-languages list.  He has also
suggested that the draft should be changed to remove the description of list
management duties.  I have cc'd him here so that he can add his own comments
or correct any errors in my summary of our conversation.

An Area Director can not unilaterally change an approved Internet-Draft.
Ted and I are not willing to appoint a reviewer who is not willing to
perform the duties described in the document.  We thus have a conflict that
needs to be resolved before the IESG can appoint a reviewer.

Given that this document is a BCP candidate produced by the LTRU working
group, a change in the approved practices needs to be considered by the
group itself.  So, on behalf of the IESG, I am asking the LTRU working group
to consider your options (I see three) and to then tell Ted and me which you
wish to pursue:

1. Revise the document, which will mean pulling it out of the RFC Editor
queue and starting a new last call and IESG approval process.  I am
suggesting that a new last call etc. is required because this document was
approved for publication as a Best Current Practice (BCP) document, and
changing one of the practices is not a trivial matter.

2. Leave the document alone and appoint a reviewer who is willing to
delegate list management duties.  There has been some debate over whether or
not the reviewer has the authority to delegate administrative tasks, but I
believe that there are a number of precedents in place to support such a
decision.

3. Appoint a reviewer who is willing to perform the duties as currently
described in the document.

These may not be your only options.  My only stipulation is that whatever
you decide must be consistent with the document you produce.

WG chairs: please manage the discussion and report back to Ted and I when
you believe that a consensus position has been reached.

Scott Hollenbeck
LTRU Area Advisor

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

---

From: Mark Davis <[email-masked]>
Date: Tue, 21 Feb 2006 09:54:06 -0800

My take: either

or

2. Leave the document alone and appoint a reviewer who is willing to
delegate list management duties.

Mark

---

From: John Cowan <[email-masked]>
Date: Tue, 21 Feb 2006 13:07:35 -0500

> believe that there are a number of precedents in place to support such a

As should be obvious by now, I strongly favor this option.  Option 1 will
cause months of delay, thanks to the machinations of Him Who Must Not Be
Named; option 3 falls down on the lack of a suitable victim^Wcandidate,
as HWMNBN will promise everything and deliver nothing but blood, toil,
tears, and sweat, all of them ours.

-- 
John Cowan  [email-masked]  www.ap.org  ccil.org/~cowan
Dievas dave dantis; Dievas duos duonos          --Lithuanian proverb
Deus dedit dentes; deus dabit panem             --Latin version thereof
Deity donated dentition;
  deity'll donate doughnuts                     --English version by Muke Tever
God gave gums; God'll give granary              --Version by Mat McVeagh

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Tue, 21 Feb 2006 13:44:30 -0500

Mr. Everson,

Nothing I wrote below casts aspersions on you.  I provided statements of
fact that the LTRU working group must consider as they decide what to do
with the document they produced.

Whether you like it or not, this is how the IETF works.  I am not going to
put myself or the IESG in jeopardy to suit your preferences.

Thank you for sharing your opinion.

-Scott-

> -----Original Message-----
> From: Michael Everson [mailto:[email-masked]] 
> Sent: Tuesday, February 21, 2006 1:19 PM
> To: Scott Hollenbeck; 'LTRU Working Group'
> Cc: 'Ted Hardie'; IETF Languages Discussion
> Subject: Re: Language Subtag Reviewer Appointment
> 
> At 08:00 -0500 2006-02-21, Scott Hollenbeck wrote:
> 
> >unwilling to moderate or maintain the ietf-languages list.
> 
> Because that function is not something I have ever done, nor is it 
> something that should have been added to the reviewer's 
> responsibilities. And no one ever bothered to ask me my opinion of 
> this until the draft was "approved". This is NOT my fault.
> 
> >perform the duties described in the document.
> 
> If you people are more concerned about your rules and processes than 
> in the actual content of the work, then there are problems indeed 
> with your organization. I am not willing to take on the responsiblity 
> to manage an IESG-rule-bound list precisely because of all the crap 
> we have had to put up with Mr Morfin. It is YOUR process that is 
> broken, Mr Hollenbeck, and it is rather nasty of you to be 
> high-handed about not being willing to appoint me to do a job I have 
> been doing for years because I am not willing to take on additional 
> responsibilities that no one informed me about until it was already 
> set in stone. I assure you I would have made my views clear then. 
> Don't try to make *me* the bad-guy here.
> 
> This *is* a trivial matter, and your "last call" should state 
> explicitly that the ONLY thing on the table up for approval is the 
> one or two sentences it will take to correct the error in 
> responsibility assignment which exists in the document. This is NOT a 
> large technical change. It is administrative, and should be 
> fast-tracked. Your organization should do this in order to meet the 
> urgent market need for this RFC.
> 
> I do not want to make a delegation choice either. Why should I -- or 
> any language tag reviewer -- be considered competent to do this? This 
> is not what a reviewer is chosen for. You need to fix the document, 
> which conflates responsibilities in ways which do not make any sense 
> at all.
> 
> That's my opinion.
> -- 
> Michael Everson * http://www.evertype.com
>

---

From: "Debbie Garside" <[email-masked]>
Date: Tue, 21 Feb 2006 19:14:05 -0000

Gentlemen Please... !!!

I propose a fifth option.

I think we would all agree that it is in the majority's interest to allow
the draft to proceed as is.

Therefore, I propose that Michael Everson be appointed as Language Subtag
Reviewer with all that that position entails.

I propose that Michael accept the position and that he propose to the
IETF/LTRU that whilst he is happy to accept the position of Language Subtag
Reviewer the constraints on his time do not allow for him to also take up
the duties as List Moderator.  

Michael can further propose to this list and the LTRU that he is allowed to
designate an experienced person to deputise for him in this aspect of the
role and that the person he would like to deputise is Harald (assuming he is
OK with this).

The IETF/LTRU group are advised by Scott that there is precedent for this
and the proposal is put to the list.  The list membership approve on the
basis that the two positions are separated when RFC3066ter comes along (in
the not too distant future given the impending publication of ISO 639-6).

Job Done!

Best wishes

Debbie

> From: Scott Hollenbeck [mailto:[email-masked]]
> Sent: 21 February 2006 18:45
> To: 'Michael Everson'; 'LTRU Working Group'
> Cc: 'IETF Languages Discussion'
> Subject: [Ltru] RE: Language Subtag Reviewer Appointment
> 
> Mr. Everson,
>

---

From: "Addison Phillips" <[email-masked]>
Date: Tue, 21 Feb 2006 11:32:54 -0800

+1

Addison Phillips
Internationalization Architect - Yahoo! Inc.

Internationalization is an architecture.
It is not a feature. 
> From: Mark Davis [mailto:[email-masked]]
> Sent: Tuesday, February 21, 2006 9:54 AM
> To: Scott Hollenbeck
> Cc: 'Michael Everson'; 'LTRU Working Group'
> Subject: Re: [Ltru] Language Subtag Reviewer Appointment
> 
> My take: either
>

---

From: "Debbie Garside" <[email-masked]>
Date: Tue, 21 Feb 2006 20:55:28 -0000

Which basically means that I support option 2 with the added bit about
updating job specs when RFC3066ter comes along :-)

(Thanks John)

PS Slip of the finger I should have written "impending publication of ISO
639-3"

> From: Debbie Garside [mailto:[email-masked]]
> Sent: 21 February 2006 19:14
> To: 'Scott Hollenbeck'; 'Michael Everson'; 'LTRU Working Group'
> Subject: RE: [Ltru] RE: Language Subtag Reviewer Appointment
> 
> Gentlemen Please... !!!
>

---

From: Michael Everson <[email-masked]>
Date: Tue, 21 Feb 2006 18:19:16 +0000

That's my opinion.

---

From: r&d afrac <[email-masked]>
Date: Wed, 22 Feb 2006 03:12:05 +0100

The response to my RFC 3066 Bis appeal suggests the possibility of an 
RFC on the use of RFC 3066 Bis. My intent is to use that suggestion. 
I plan to start from the text of my appeal and of the text of the 
IESG comment. This should achieve several targets, among them.

1. tell the history of RFC 3066 Bis and why the security 
considerations have not been updated.
2. warn users on the security risks I listed.
3. introduce the responses of the IESG
4. document the attitude concerning compatibility with RFC 3066 format
5. document the opposition to RFC 4151
6. introduce an open experimental proposition as suggested by the 
IESG and a non-WG mailing list to discuss it.
7. cover the existing or planned alternatives, and their 
interoperability issues.

I am certainly interested in any additional suggestion any of you may 
have. I was copied two quotes of Peter Constable and Mark Davis 
raising a problem this Draft could immediately address. I quote:

PC. "I was guessing it amounted to this. To me, this doesn't clearly 
state that *all* must be added unless there's a conflict. We read it 
that way because we wrote it and we know what we meant; but I would 
be not at all surprised if someone who didn't contribute to writing 
this came away with a different interpretation. If anyone is taking 
notes for the next round (I'm not suggesting another draft for bis), 
I think this should be tightened up."

MD. "It was certainly the intent; that all must be added unless there 
is a conflict ( in which case a substitute needs to be found). And I 
think that is the clearest reading of the text. However, I agree that 
in the next version it should be clarified to remove all doubt."

I appealed to the IESG about the "Langtags Registry" header 
confusion. I could use it in the same way for a part on the issue, 
the role of the Language Subtag Reviewer. The resulting conflicts and 
conflicts management this may imply.

The same, Michael Everson raised objections which were discussed. 
This could lead to a part detailing better the way the LSR must be 
organised, staffed and budgeted. I would certainly welcome inputs 
from Michael's experience and suggestions and remarks from Scott 
Hollenbeck and Ted Hardy.

If I am correct I have two months to produce that Draft and to appeal 
to the IAB if the IESG did not approve it as an RFC. If the IESG 
approves it this would remove the delays due to an appeal.

I have no problem to introduce that Draft as a WG-Draft. But I 
suppose Chairs will prefer that it is discussed on a private 
list?  Upon confirmation I will set-it up and start working on the 
Draft. I am buzy with meetings and developments about the langroot, 
but I hope I could have a text within two or three weeks.

jfc

---

From: Martin Duerst <[email-masked]>
Date: Wed, 22 Feb 2006 13:25:14 +0900

I think the situation isn't as bad as it looks.

A careful observation, and an additional option, below.

[this is a personal contribution]

 >or correct any errors in my summary of our conversation.

Looking at Section 3.2., Language Subtag Reviewer, of RFC 3066 bis,
I find the word "moderate", but NOT the word manage or any similar
word (such as "administrate"). Unless I have overlooked something,
this indicates to me that the basic split between Expert Reviewer
and list administrator, as e.g. explained with several examples by
Ned Freed, is not affected by the currently approved text.

So the discussion here should only be about the 'moderate' part.
As Addison has pointed out, Michael already did some amount of
moderation (indicating on-topic and off-topic issues, closing
discussions). Let's call this 'moderation in the narrow sense'.
The only thing that Michael didn't do was pronouncing suspensions
according to RFC 3934. If we include this in moderation, let's
call this 'moderation in the wide sense'.

Because moderation in the wide sense is an extension of moderation
in the narrow sense, and because RFC 3934 assigns responsibility
for suspensions to WG chairs in the WG case, and the closest to
WG chairs we have on review lists are expert reviewers, it seems
most natural to (at least initially) assign this responsibility
to the expert reviewer. So in this sense, I can find no problem
with the current wording.

Given some recent mail from Michael, it is also my guess that indeed
in the past, Michael delegated the responsibility for suspensions to
Harald.

My guess (I haven't gone through the archives, sorry, lack of time)
is that things roughly happened as follows:
- Michael sending a mail saying 'this is off-topic' to the
   person in question.
...
- Michael getting more and more concerned, and asking around
   what to do, or probably proposing to just remove the person
   in question from the ability to post (without any time limit).
- Harald proposing/explaining RFC 3934.
- Michael more than willing to let Harald do whatever possible
   to keep the mailing list to its job.
Even if things didn't happen as above, Michael was more that happy
to let Harald do what he did.

I see no problem in continuing this arrangement in the future.
To take the change from the Language Tag Reviewer to the Language
Subtag Reviewer and the recent IESG announcement re. non-WG mailing
lists into account, I think it would be good to have a mail from
Michael to the list about this. But a single, one-time mail
should be enough. I cannot immagine that this would be too much
to ask from Michael.

What I think is more important is that Michael carefully check the
rest of RFC 3066 bis, and tell us whether he feels okay to take
on the new job. While most of the job is very similar, there are
some aspects that have changed. The change from tags to subtags
is the most important one.

 >changing one of the practices is not a trivial matter.

I think that with respect to the job of expert reviewer, the document
does very much describe both current and desirable practice, and it
would be a mistake to change it.

 >believe that there are a number of precedents in place to support such a

As far as list *administration* is concerned, there is nothing for the
reviewer to delegate, because the reviewer isn't charged with administration.
If anybody is (administratively) delegating list adminitstration, it would
be IANA, because it's them who sets the alias for [email-masked].

As far as list *moderation* is concerned, I think that Micheal has been
more than willing in the past to delegate this job. The only thing that
would change is that this should be documented with an mail. I can't
immagine that writing a single mail is too much of an administrative
job for Michael, but of course that's his decision.

 >described in the document.

That would of course be fine.

 >you decide must be consistent with the document you produce.

I propose an additional option (I think 4 is already taken):

5. Appoint two or more people to share the job of Language Subtag Reviewer.

While the document doesn't explicitly use "Reviewer(s)", I think that it
wouldn't be an inconsistency, because we can view "Language Subtag Reviewer"
as a function, just with some job-sharing.

Regards,    Martin.

 >you believe that a consensus position has been reached.

[OT] Just a small linguistic point: It should be "Ted and me".

---

From: Martin Duerst <[email-masked]>
Date: Wed, 22 Feb 2006 13:48:40 +0900

The following is my personal understanding.

At 11:12 06/02/22, r&d afrac wrote:
 >The response to my RFC 3066 Bis appeal suggests the possibility of an RFC 
on the use of RFC 3066 Bis. My intent is to use that suggestion. I plan to 
start from the text of my appeal and of the text of the IESG comment. This 
should achieve several targets, among them.
 >
 >1. tell the history of RFC 3066 Bis and why the security considerations 
have not been updated.
 >6. introduce an open experimental proposition as suggested by the IESG 
and a non-WG mailing list to discuss it.
 >7. cover the existing or planned alternatives, and their interoperability 
issues.

The IETF prefers documents on well-defined topics. If you want to write
a history of RFC 3066 bis, I suggest you write a separate document.
Similar for other issues.

 >I am certainly interested in any additional suggestion any of you may 
have. I was copied two quotes of Peter Constable and Mark Davis raising a 
 >PC. "I was guessing it amounted to this. To me, this doesn't clearly 
state that *all* must be added unless there's a conflict. We read it that 
way because we wrote it and we know what we meant; but I would be not at 
all surprised if someone who didn't contribute to writing this came away 
with a different interpretation. If anyone is taking notes for the next 
round (I'm not suggesting another draft for bis), I think this should be 
tightened up."
 >
 >MD. "It was certainly the intent; that all must be added unless there is 
a conflict ( in which case a substitute needs to be found). And I think 
that is the clearest reading of the text. However, I agree that in the next 
version it should be clarified to remove all doubt."

This should be handled, if necessary, as an erratum to the soon-to-be RFC.

 >I appealed to the IESG about the "Langtags Registry" header confusion. I 
could use it in the same way for a part on the issue, the role of the 
Language Subtag Reviewer. The resulting conflicts and conflicts management 
this may imply.
 >
 >
 >The same, Michael Everson raised objections which were discussed. This 
could lead to a part detailing better the way the LSR must be organised, 
staffed and budgeted. I would certainly welcome inputs from Michael's 
experience and suggestions and remarks from Scott Hollenbeck and Ted Hardy.
 >
 >
 >If I am correct I have two months to produce that Draft and to appeal to 
the IAB if the IESG did not approve it as an RFC. If the IESG approves it 
this would remove the delays due to an appeal.

My understanding is that the IESG just pointed out the possibility of
publishing an Informational RFC as one reason for denying your appeal,
but that otherwise that appeal and an potential Informational RFC are
not linked at all. The IESG does NOT require you to write a draft.
They don't even say that such a draft is needed.

In case you start working on such a draft, it will most probably take
more than 2 months to get it done. Also, please note that it is possible
to submit an Internet-Draft directly to the RFC Editor for publication;
in this case, if I remember correctly, the IESG gets a chance to comment
(and if necessary, add a note at the start of the document), but does not
approve publication.

 >I have no problem to introduce that Draft as a WG-Draft. But I suppose 
Chairs will prefer that it is discussed on a private list?  Upon 
confirmation I will set-it up and start working on the Draft. I am buzy 
with meetings and developments about the langroot, but I hope I could have 
a text within two or three weeks.

If you really think an Informational RFC is needed, I'd personally
prefer it if you did that on your own. Once a draft is published,
you can send a notice here so that interested people can comment.

Regards,    Martin.

---

From: r&d afrac <[email-masked]>
Date: Wed, 22 Feb 2006 07:08:52 +0100

>you can send a notice here so that interested people can comment.

We basically share the same understanding of the IESG position. And I 
agree with all your comments.
I will stick to this. I will copy the IESG your mail if they required 
more information.

This work IETF Draft preparation will be supported by the 
[email-masked].
It will be installed on my site in the coming days.
The current status of the Draft will be maintained at 
http://jefsey.com/ietf-languages.pdf.
jfc

---

From: r&d afrac <[email-masked]>
Date: Wed, 22 Feb From [email-masked] Wed Feb 22 01:09:34 2006

---

From: r&d afrac <[email-masked]>
Date: Wed, 22 Feb 2006 07:09:21 +0100

>as a function, just with some job-sharing.

I have not the time right now to go into archives. I proposed that. 
And it was consensually opposed. This is when I considered the real 
job and workload. I did not pursue because the job is obviously for a 
structured entity.

Martin, I would propose a similar solution everyone could agree. 
Instead of waiting for my Draft on RFC 3066 Bis, it would be to 
quickly document through a "Language Subtags and Tag Extension 
Reviewing Management" Draft, the Language Subtag Reviewer entity organisation.

The advantage is that we could then adapt it easily upon experience 
as a separated document. We would strictly have a single LSR, fully 
respecting Scott's requirements, addressing all the IESG concerns 
(since it would be an RFC approved by the IESG). This organisation 
could either be independent or sponsored/hosted by an existing 
entity, it would still match our requirements. And the policies we will decide.

I insist, but the job will have not much to do with the old 7 
langtags a year job. And nothing that can be managed in using RFC 
3934 like stuff. And most probably not something which can seriously 
be managed for free and part time. We have to be careful about that. 
We would all hate that Michael accepts to take the job and then be 
professionally hurt because it will said he does not deliver. I 
strongly advise Michael to tell how many hours a week he can dedicate.

I am also not sure you understand the context. Up to now, a very few 
people came to add a language tag (72 in 10 years, when ISO is adding 
more than 7.000 and next more than 12.000 more. You complain about my 
attitude. I am afraid you miss something: I am the only one who is 
_also_ friendly to the IETF, and I made a huge effort for that. You 
want others to come. Others will only want a job done. Most will not 
be interested with the Internet and many not with languages as you 
are used to discuss them. They will only want a consistency RFC 3066 
Bis constraints will often prevent. The IGF sets multilingualisation 
as a priority. If the IETF is interested in staying abreast and 
compatible in the coming two years, a very serious effort will have 
to be undertaken. And a mental revolution.

The debate we had during the past months was very nice be2006 07:09:21 +0100
To: Martin Duerst <[email-masked]>,
	"Scott Hollenbeck" <[email-masked]>,
	"'LTRU Working Group'" <[email-masked]>
From: r&d afrac <[email-masked]>
Subject: Re: [Ltru] Language Subtag Reviewer Appointment
Cc: 'Michael Everson' <[email-masked]>

>as a function, just with some job-sharing.

I have not the time right now to go into archives. I proposed that. 
And it was consensually opposed. This is when I considered the real 
job and workload. I did not pursue because the job is obviously for a 
structured entity.

Martin, I would propose a similar solution everyone could agree. 
Instead of waiting for my Draft on RFC 3066 Bis, it would be to 
quickly document through a "Language Subtags and Tag Extension 
Reviewing Management" Draft, the Language Subtag Reviewer entity organisation.

The advantage is that we could then adapt it easily upon experience 
as a separated document. We would strictly have a single LSR, fully 
respecting Scott's requirements, addressing all the IESG concerns 
(since it would be an RFC approved by the IESG). This organisation 
could either be independent or sponsored/hosted by an existing 
entity, it would still match our requirements. And the policies we will decide.

I insist, but the job will have not much to do with the old 7 
langtags a year job. And nothing that can be managed in using RFC 
3934 like stuff. And most probably not something which can seriously 
be managed for free and part time. We have to be careful about that. 
We would all hate that Michael accepts to take the job and then be 
professionally hurt because it will said he does not deliver. I 
strongly advise Michael to tell how many hours a week he can dedicate.

I am also not sure you understand the context. Up to now, a very few 
people came to add a language tag (72 in 10 years, when ISO is adding 
more than 7.000 and next more than 12.000 more. You complain about my 
attitude. I am afraid you miss something: I am the only one who is 
_also_ friendly to the IETF, and I made a huge effort for that. You 
want others to come. Others will only want a job done. Most will not 
be interested with the Internet and many not with languages as you 
are used to discuss them. They will only want a consistency RFC 3066 
Bis constraints will often prevent. The IGF sets multilingualisation 
as a priority. If the IETF is interested in staying abreast and 
compatible in the coming two years, a very serious effort will have 
to be undertaken. And a mental revolution.

The debate we had during the past months was very nice because this 
was transition and very small lists. When dealing with codes of 
thousands of entities, industrial constraints, business requirements, 
authoritative people from 192 countries, on a real IANA list, 
with  serious money directly involved, things will be quite 
different. It seems that I was a problem. Dear ... I was a nice 
training for what is to come. I know you want Michael to accept and 
then put the responsibilty on him. I know the job. I know what it 
requires. And I know it in setting the rules myself. In this case the 
LSR will have to obey RFC 3066 Bis constraints everyone, except 
Unicode supporters, will object to. I do not want to hide this to 
Michael. RFC 3934 or 3683 will be of no use against a Circle-ID, or 
New-York Times opposition. The language root is more important to 
real people than the DNS root. Yet Bush called Barroso over the DNS root file.

There is also a COI problem. I doubt that an ISO 639, ISO 15924 and 
ISO 3166 responsible can be involved in the LSR function. If there 
are demands of subtag registrations conflicting with the personal 
vision of the reviewer, in his own ISO area of responsibility, what 
will happen? What will be the IANA Language Subtag/Tag extension 
Registries image? The only arbitration we have in case of conflict is 
the IESG and the IAB. Are they technically prepared to this? The 
Draft I propose could include, within the LSR entity, an Ombudsman.

jfc

cause this 
was transition and very small lists. When dealing with codes of 
thousands of entities, industrial constraints, business requirements, 
authoritative people from 192 countries, on a real IANA list, 
with  serious money directly involved, things will be quite 
different. It seems that I was a problem. Dear ... I was a nice 
training for what is to come. I know you want Michael to accept and 
then put the responsibilty on him. I know the job. I know what it 
requires. And I know it in setting the rules myself. In this case the 
LSR will have to obey RFC 3066 Bis constraints everyone, except 
Unicode supporters, will object to. I do not want to hide this to 
Michael. RFC 3934 or 3683 will be of no use against a Circle-ID, or 
New-York Times opposition. The language root is more important to 
real people than the DNS root. Yet Bush called Barroso over the DNS root file.

There is also a COI problem. I doubt that an ISO 639, ISO 15924 and 
ISO 3166 responsible can be involved in the LSR function. If there 
are demands of subtag registrations conflicting with the personal 
vision of the reviewer, in his own ISO area of responsibility, what 
will happen? What will be the IANA Language Subtag/Tag extension 
Registries image? The only arbitration we have in case of conflict is 
the IESG and the IAB. Are they technically prepared to this? The 
Draft I propose could include, within the LSR entity, an Ombudsman.

jfc

---

From: Martin Duerst <[email-masked]>
Date: Wed, 22 Feb 2006 16:04:35 +0900

Please note that I don't think such an Informational RFC is needed at all.

Regards,    Martin.

---

From: Martin Duerst <[email-masked]>
Date: Wed, 22 Feb 2006 16:35:33 +0900

At 15:09 06/02/22, r&d afrac wrote:
 >I have not the time right now to go into archives. I proposed that. And 
it was consensually opposed. This is when I considered the real job and 
workload. I did not pursue because the job is obviously for a structured entity.

I am definitely not proposing a structured entity. The only thing
I'm proposing, as one additional option (not my first choice), is to
use job-sharing on the reviewer job. There are quite a number of expert 
reviewer entries in the IANA registry where there is more than one reviewer.
While I'm quite sure the idea of a structured entity was rejected,
I don't think that would apply to job-sharing.

[I very much think that a structured entity will not be necessary at all.
The language reviewer has approved 72 requests in 10 years. A significant
number (by rough count, between 30% and 50%) of these requests wouldn't
have been needed if RFC 3066 bis were already in place, or would have
been reduced from a series of entries to a single subtag entry.

If somebody had a need to label a language, they could already have
made a registration request in the past 10 years. Apparently, the
people who choose to do that were very few.]

 >I am also not sure you understand the context. Up to now, a very few 
people came to add a language tag (72 in 10 years, when ISO is adding more 
than 7.000 and next more than 12.000 more.

These will be handled by updates to RFC 3066 bis and/or batch processing.
RFC 3066 has added (most of) the 3-letter codes in addition to the 2-letter
codes that were allowed in RFC 1766, without going through the review
process.

Regards,    Martin.

---

From: Michael Everson <[email-masked]>
Date: Wed, 22 Feb 2006 10:36:15 +0000

Mr Morfin

I insist that you stop sending mail to me. I have nothing to say to 
you and do not wish to receive mail from you. I do not read your 
mails or your advice as to what I should or should not do. Leave me 
alone.
-- 
Michael Everson * http://www.evertype.com

---

From: r&d afrac <[email-masked]>
Date: Wed, 22 Feb 2006 16:19:24 +0100

At 08:04 22/02/2006, Martin Duerst wrote:

> >We basically share the same understanding of the IESG position. 
> And I agree with all your comments.
>

I understand that. This is where we disagree.
jfc

---

From: r&d afrac <[email-masked]>
Date: Wed, 22 Feb 2006 17:02:16 +0100

At 11:36 22/02/2006, Michael Everson wrote:

>mails or your advice as to what I should or should not do. Leave me alone.

Dear Michael,
I have no objection to that.

But I am the reviewer of a language registry of which I delay the 
publication only to try to insure before hand a structural 
interoperability with the IETF Language Subtag and Tag-Extension 
Registry. Several tend to think that the architectural location and 
approach of that registry will make it a key element of future 
inter-networking.

I want to be clear that as such I and the Members of my organisations 
will be active members of the [email-masked]. Should I be 
PR-defamacted at your co-initiative by the IESG this would change 
nothing to that situation. Several think it would only be detrimental 
to the IETF propositions interoperability, would only rigidify our 
relations through numerous proxies and accelerate the transition from 
the IETF internationalization to the IGF multilingualisation in a 
possibly less organised manner than we should all strive for.

This request of yours is public. I can therefore publicly quote it 
from now. I however consider it as possibly detrimental for you, 
while I respect both your achievements and expertise. I therefore 
thank to confirm it publicly.

I cannot unfortunately warrant you that you will not hear from me, 
but I will strive to remove your name from my out lists (I will 
certainly keep it it my in list).
jfc

---

From: Michael Everson <[email-masked]>
Date: Wed, 22 Feb 2006 16:30:13 +0000

>I have no objection to that.

Mr Morfin,

Do not address me by my first name.

>I want to be clear that as such I and the Members of my 
>organisations will be active members of the [email-masked]. 
>Should I be PR-defamacted at your co-initiative by the IESG this 
>would change nothing to that situation. Several think it would only 
>be detrimental to the IETF propositions interoperability, would only 
>rigidify our relations through numerous proxies and accelerate the 
>transition from the IETF internationalization to the IGF 
>multilingualisation in a possibly less organised manner than we 
>should all strive for.

You have offered nothing but poison to this entire enterprise, which 
is why I told you to cease sending mail to me.

Kindly refrain from responding to this message from me.
-- 
Michael Everson * http://www.evertype.com

---

From: Mark Davis <[email-masked]>
Date: Wed, 22 Feb 2006 11:23:05 -0800

Michael, it is of little use to ask Morfin to stop sending you mail. 
Just filter him out in your mail.

Mark