Re: IANA SLA Input Sought

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeffrey Hutzelman wrote:
Who does or will pay for the IANA function?  Does funding come from IASA, ICANN, or some other source?
 
Ray Pelletier wrote:
To my knowledge, it's ICANN, not the IETF.
Ray

Brian E Carpenter wrote
Yes, this has been an ICANN contribution to the community since
the creation of ICANN, when these functions were transferred from
their previous home at ISI.
 

Harald Alvestrand wrote:
Note: I think we need to define IETF requirements and get them filled, and that this process is one way of achieving that.
If we find that ICANN isn't willing or able to do what we desire from them, we need to go somewhere else for running registries - at least new ones, and possibly old ones too. (There are some old ones with thorny issues attached to them, but new ones don't have that.)
So ICANN doing this "for free" does not mean that we don't get to say how the job is done.

At 14:54 28/06/2006, Brian E Carpenter wrote:
Indeed, and I would like to underline that the current IANA Manager
over at ICANN, David Conrad, has been working very closely with
us in drafting this SLA. So it isn't based on wishful thinking.

Dear Brian,
I doubt Harald here makes wishful thinking either.
Let get real, please.

Dear Harald,
thank you for publicly disclosing what I explained and documented for 18 months as your probable agenda. This makes plain why you and your affinity group attempted to exclude, block, and discredit me, and my organisation's MDRS work, for 18 months. This is also the reason for my own weak to strong winning strategy.

We both know that the issue is the control, the fragmentation, or the evolution of the IANA. Interestingly, this comes only three weeks before the NTIA hearings. Pressures given, taken, or both?

I documented most of the point in an email yesterday, which had a certain audience outside of the IETF.

However, now that you start speaking more openly, I believe we can also start discussing more openly how to prevent a split between the Internationalized US Internet and the Multilingual Internet of the rest of the world. This is why I proposed an open "concertation meeting" (sorry, an ?en-EU? term) on the issue for the first week of October in Paris. I will formalise the invitation and a proposed agenda in a few weeks.

The technical situation is as follows (everyone will understand the underlying political and commercial situation):

1. when you speak of "at least new [registry] ones" you mean "Language Subtags and Extension Registries". Your ietf-languages@xxxxxxxxxxxxx mailing list still controls "how the job is done" today. However, RFC 3066 Bis gives that control to ietf-languages@xxxxxxxxx Even with the IESG long appeal delays, I am confident that I will get RFC 3066 Bis applied one way or another.

2. The BCP 47 first part (RFC 3066 Bis) and second part (under IESG approval) organise a potentially enormous computer load on these registries (larger than the entire DNS). The WG-LTRU stubbornly refused to consider it (as well as who would bear the cost). Some WG and your list Members explained that - should it occur - it would be supported as the other Unicode registries, by Unicode Members' servers. An other one stated that one sentence in the BCP 47 second part Draft would prevent it, and an other alluded to a dedicated ISO 639 [paid?] server being under consideration. I have no reason to believe that when you (a BoD Member of Unicode) speak of "somewhere else", you did not ran a prior investigation (there are only a few possible "somewhere" locations for such an hosting). May be could you share the estimates with us?

3. Randy Preshun said that when BCP 47 documents are finished (now) we would consider the WG-LTRU "thorny issues". I see that this is the time. I made ISO 11179 to be currently discussed again at the WG, and you introduce now the idea of an IANA transfer outside of ICANN. These are the two serious alternatives to a IANA status quo that a simple library, or search engine application can blow-up at any moment. They are between a unilateral, IANA centric, internationalized Internet and a multilateral, user centric, multilingual, multitechnology, internetting architecture.

Due to the ICANN SLA, the IETF cannot now largely delay (as it does for my appeals which ask the same question) its choice between:

Plan A. ICANN (USG agency as per the Tunis agreement) receives control of the new IETF-claimed world leadership on languages issues. This is/will obviously be contested by many. All of us also know (from the very beginning) that it will not bear the load anyone can generate through Language libraries.

PLAN B. the IETF believes that its job is to help people to build and operate distributed communications solutions and services, over their common digital ecosystem and devise an architecture for them to do so, as I do with the MDRS (multilingual distributed registry system). I sincerely hope that we can work together on the resulting challenge for the benefit of the Internet and its users.

Plan C. Unicode Members' servers (IBM, Microsoft, Google, Yahoo!, etc.) support a core solution using the CLDR locales files as its "meta user agents". This can certainly work. However, we must understand that:

1. the CLDR limitations (and Search Servers economics) realistically limit the number of supported languages to 150, to the use English as a pivotal language, and make the other 7,500 ISO 639-3 languages, 20,000 ISO 639-6 languages, and billions of specialised socio, professional, and idiolects subject to the BCP 47 part 2 Filtering (cultural kill). All of this along with the economic, political, and societal consequences that one can expect.

2. the operators of the Language Registries will obtain immense intelligence on every user ("tell me what you read, I will tell you who you are"). It is likely that this will lead to IANA fragmentation for foreign user protection. We also know how it will be used by the two-tier Internet.

3. the lack of technical support of so many language issues, which the WG-LTRU refused to consider, makes this limited to only some HTML and XML needs.

4. this will obviously not prevent the plan B Multilingual Internet from developing, especially now that I have obtained the current BCP 47 text and in the IGF context.

If I am wrong in the way I read you, I apologise. If I am right I beg you not to split the Internet.

All the  best.
jfc



jfc

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]