Subject: Re: IANA SLA Input Sought

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 26 Jun 2006 16:38:06 -0400

On Monday, June 26, 2006 04:22:57 PM -0400 IETF Administrative Director 
<[email-masked]> wrote:

> The IAOC is negotiating a service level agreement with ICANN/IANA for
> services it performs on behalf of the IETF.  The SLA supplements the MOU
> executed by ICANN and the IETF in 2000.

Who does or will pay for the IANA function?  Does funding come from IASA, 
ICANN, or some other source?

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

---

From: Ray Pelletier <[email-masked]>
Date: Mon, 26 Jun 2006 16:44:00 -0400

Jeffrey Hutzelman wrote:

> Who does or will pay for the IANA function?  Does funding come from 
> IASA, ICANN, or some other source?

To my knowledge, it's ICANN, not the IETF.
Ray

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Jun 2006 10:31:10 +0200

> To my knowledge, it's ICANN, not the IETF.

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.

    Brian

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Tue, 27 Jun 2006 12:29:32 +0200

At 10:31 27/06/2006, Brian E Carpenter wrote:
>Ray Pelletier wrote:
>>Jeffrey Hutzelman wrote:
>>
>>>Who does or will pay for the IANA function?  Does funding come 
>>>from IASA, ICANN, or some other source?
>>

The IANA functions have been progressively enlarged by the BPC 47. 
There are today four main IANA areas:
- names
- numbers
- protocols
- languages

The first three areas are historic and delegated by the IETF to ICANN 
through the IAB/IETF/ICANN/IANA MoU, in conformance to the IANA 
contract between the USG and ICANN. Revising this MoU is certainly in 
the capacity of ICANN, IANA, IETF and IAB.

The languages are is a new area where IETF claims a de facto non 
interoperable (cf. the IETF denial of "en-EU") world's leadership 
most are not ready to acknowledge to the IANA. The current Draft of 
the BCP 47 second part shows an additional problem that the WG-LTRU, 
IETF, IESG and IAB refused to consider, and a WG-LTRU co-Chair 
eventually de facto acknowledged after the end of the IETF LC period. 
This problem is the possible load imposed on the IANA due to the 
undocumented level of access to the language database, and therefore 
the resulting cost and practical arrangements.

No one knows what the user applications will do to check the current 
validity/signification of a language Sub-Tag or Extension. If we 
consider that 97.5% of the root server load (before the huge amount 
of additional TLD typos IDN.IDN will add) is illegitimate (hence not 
necessary) one may guess the resolution need and resulting load of a 
variable information needed to evaluate most of the Web pages, 
e-mails, etc. where retro-meta-spam will probably be very active.

To my knowledge five proposition/projects at least are concerned:

a. the IANA Language Sub-Tags and Extensions Registries currently 
lead by UNICODE Members with IESG support.
b. the possible IETF repository, documented by Leslie Daigle and 
Brian Carpenter in their response to the NTIA
c. a possible independent ISO 639 repository
d. the MDRS project I conduct which includes its own langroot 
designed to comply with
   - the ISO 11179 strictly conformant (cf. ISO 11179-3 Part 6) 
solutions adopted by the JTC1/SC32/WG2 [what the current debate of 
the WG-LTRU (involving different position of the authors of ISO 639-3 
and ISO 639-6 Drafts) shows it might not be the IETF intent].
   - the IGF conclusions and subsequent projects.
   - the UNESCO demands in terms of cyberspace multilingualism
e. the IGF which put multilingualism as one of its four priorities 
and supports an extended work in the area of lingual codes.

There may be other projects by private services, such as search 
engines and/or ISPs as part of the two-tier Internet.

I note that due to the size of the langroot (whatever the 
format/system) and its probable use, the size or the architecture of 
its global repository or distributed referential system make the 
names, numbers, and protocols repositories a small addition that each 
of the considered systems would easily support to provide users with 
a single service. This means that we face at least five IANA 
functions systems in a near future, each of them with a significant 
background. Three of them (c,d,e) want/need to be interoperable, one 
(b) being improbable (b) and one (a) being currently denied interoperability.

This is why in a mail sent yesterday to the IESG I propose a meeting 
of all the concerned parties early October in Paris, to try to work 
out a common approach.
jfc

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 28 Jun 2006 02:44:16 -0700

> their previous home at ISI. 
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.

                              Harald

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Jun 2006 14:54:29 +0200

> So ICANN doing this "for free" does not mean that we don't get to say 

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.

     Brian

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Thu, 29 Jun 2006 02:19:55 +0200

>>>Brian E Carpenter 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:

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 
[email-masked] mailing list still controls "how the job 
is done" today. However, RFC 3066 Bis gives that control to 
[email-masked]. 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

---

From: IETF Administrative Director <[email-masked]>
Date: Mon, 26 Jun 2006 16:22:57 -0400

The IAOC is negotiating a service level agreement with ICANN/IANA for services
it performs on behalf of the IETF.  The SLA supplements the MOU executed by
ICANN and the IETF in 2000.

The SLA can be found in .pdf and .doc format at
http://koi.uoregon.edu/~iaoc/

The IAOC is seeking input to refine the SLA based on existing and required
practices.  Any suggestions regarding apparent omissions or refinements would be
appreciated.  Please send comments to iad at ietf.org by Monday July 3, 2006.

The SLA includes, among others, the following elements:
1.  Services
2.  Service Levels
3.  Escalation
4.  Reports
5.  Collaboration
6.  Service Time Commitments

Your time and comments are greatly appreciated.

Regards,
Ray Pelletier
IAD