IANA registration issues not covered by the "RFC 3066bis" draft
JFC (Jefsey) Morfin
jefsey at jefsey.com
Fri Jan 28 13:54:53 CET 2005
thank you for your detailed responses.
At 08:00 28/01/2005, Doug Ewell wrote:
>JFC (Jefsey) Morfin <jefsey at jefsey dot com> wrote:
> >> Read RFC 3066.
> > I found nothing about Registrar (word does not exist there). I found
> > nothing about his designation process. The duration of his term. His
> > duties. The procedure of appeal, etc. A Registrar is a IANA/ICANN
> > function to manage a Registry, ie with the capacity to register. What
> > is documented in the RFC 3066 is a "reviewer" with a capacity to not
> > register. That Reviewer is also not documented, except as designated
> > by the Applications Area Director what rise many problems since there
> > are two of them.
>Oh, I see. Your original question was intended to expose the fact that
>a person called a Reviewer actually performs registration functions.
>You could have just come out and said so.
No. I did not want to expose, just asking how these functions are de
facto/contractually organized. As you know ICANN is a no member Californian
corporation set-up by Jon Postel, Joe Sims and others to replace Jon Postel
personal involvement (in a similar way IETF is organizing the IASA to
replace Bob Khan). This organization has contracted the management of the
IANA functions with the US Government
http://www.icann.org/general/iana-contract-09feb00.htm . There are two well
known constraints on this contract:
- this contract is uncertain http://www.gao.gov/new.items/og00033r.pdf
according to the US GAO (General Accounting Office) as the only rights of
the USG comes from its interest in developing the US domestic and foreign
communications and commerce, not in governing the world digital system.
- the US Government has published its intent not to renew this contract.
For a certain time ICANN (in opposition to the RFC 2860 which defines the
technical work expected from ICANN by the IETF) presents the IANA as an
ICANN integrated function.
In addition, the work I personally carry for several years (in accordance
with the ICANN ICP-3 document) shows that the evolution of the market
understanding of the Internet architecture comes back to a digital space
user centric vision, shadowed by the OSI/Internet episode and. This
evolution is also demanded for risk containment reasons by businesses and
States and can be summarized into a transition from an Internet under ICANN
dominance (with a single IANA occurrence) towards a totally open Internet:
this is what ICP-3 called experimentation about, the IETF has not
considered yet. Our own work show that we can avoid a balkanization of the
Internet through a third solution (neither an ICANN dominance, nor ITU
supported fragmentation) through the intergovernance of an authoritative
set of matrices, organized by a granularity of reference centers managed in
These contractual, uncertain future and architectural evolution, calls for
the IANA functions to be kept independent and extremely clear as per RFC
2860, ftp://ftp.rfc-editor.org/in-notes/rfc2860.txt, that is under the
control of IESG and not under the control of the ICANN BoD (except the IP
addresses and Domain Names as agreed in RFC 2860 4.3).
RFC 3066 creates the function of Reviewer but does not defines properly its
designation, removal, appeal process. The ICANN management of IANA makes
the ICANN procedures to apply in terms of IANA Manager, Registrars,
appeals, etc. However long terms IANA organization. (it seems we both agree
on the definition of the Registrar and Reviewer roles).
>Probably there was an understanding that the business of reviewing and
>registering language tags was a non-controversial one. It certainly has
>been for the last ten years, with a handful of exceptions.
True. As I noted it, the registration was "for information" and carried by
a non IETF list. This would be changed by the Draft-Phillips- etc. This
aspect has not been covered. The Reviewer function should be better defined
and the IANA's role, rights, appeal procedures etc. should be described.
>Remember that the positions of ISO 15924 Registrar (which Mark Davis was
>referring to) and RFC 3066 Language Tag Reviewer are not the same
>position. It happens that they are both filled by the same individual.
True. But Michael Everson is actually carrying three tasks:
- Reviewer on behalf or IETF as designated by one Application AD (as per
RFC 3066) or both? Assisted by a non-IETF list?
- Registrar of ISO 15924 - what is out of IETF scope
- Registrar for IANA - as per a IANA page I do not find back right now
(sorry, but the IANA is a mess not a menu)
This last function falls into the RFC 2860 field and should be discussed
and defined in the Draft.
> > This function was of low importance as long as registrationswere not
> > mandatory. It will be a key or even "the" key IANA function, as
> > appeals and conflicts will most probably rise on language
> > regsitrations with powerful and decided interest being at stake (cf.
> > .PL/MINC issue), should the Draft be accepted as a BCP. My question is
> > therefore very important.
>The Language Subtag Reviewer in RFC 3066bis has three jobs related to
>1. When ISO 639 adds a new language code, add the corresponding
>language subtag to the Registry. This is clerical and
>2. When ISO 639 changes the code for a language, add the new code as an
>alias for the old code. This is also clerical and non-controversial, so
>long as ISO 639/RA doesn't reuse codes.
>3. When someone submits a request to register a language tag (4 to 8
>letters), that request must be scrutinized carefully before
>registration. Unlike (1) and (2) above, this requires a lot of thought
>and discussion and may be highly controversial. The draft makes it
>clear that such registrations are discouraged.
I am not referring to this. I am referring to the registration of the
documentation of a language tag through a single document, book or authority.
>The ".PL/MINC issue" has nothing whatsoever to do with whether 'ar' is a
>valid language code or whether 'PL' is a valid country code. Neither
>the draft, nor RFC 3066 nor RFC 1766 before it, makes any judgment about
>whether "ar-PL" is an appropriate language tag. Anything else related
>to the ".PL/MINC issue" is out of the scope of language tags. This has
>been explained to you before.
I am afraid you will never understand this as a tag designer while I am a
tag user. In missing the style and authority fields your tag does not
permit the real needs of the words to be documented, leading to conflicts.
Your tag does not scale and is therefore inadequate to real life and
violating RFC 1958.
But this is another issue. Thank you for the input. I will use it to
document the problems ahead and the ways to solve them in good consistency
with the other problems created by the quick coming user centric 3rd
> Fullerton, California
>Ietf-languages mailing list
>Ietf-languages at alvestrand.no
More information about the Ietf-languages