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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf