Re: IANA SLA Input Sought

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

 



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?

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

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.

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



_______________________________________________

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]