At 21:10 01/09/2005, John C Klensin wrote:
--On Thursday, 01 September, 2005 02:49 +0200 "JFC (Jefsey)
Morfin" <jefsey@xxxxxxxxxx> wrote:
> Dear Harald and Paul,
> May be time to stop 3683ing this issue. Major moves in the
> naming area are probable in the year to come (PADs - shared
> root under UN - National TLDs, CENTR move.); while an ICANN
> request of update of RFC 2826 stays unanswered or opposed for
> four years.
Jefsey,
Just to understand the relationship between your reality and
mine,
Dear John,
No problem. What is a reality (back-ground, referent and context) is
precisely the ultimate question of this R&D. But you jump into
something complex enough, at the core of an evolution the IETF does
not consider much.
what "ICANN request for an update of RFC 2826" are you
talking about?
I quoted it in the mail. This is the ICP-3 document. This document is
often confused as an anti-New.net pamphlet. This is key document
which discusses:
- the legitimacy of ICANN, rooting in the consensus we had in 1984,
JonPostel documented in RFC 920
- the need of a unique authoritative root as documented in RFC 2826,
plus harping on alt-roots, etc.
- the development of the Internet technology based upon
experimentation and the need of a community experimentation for the
evolution of the DNS. The IETF is quoted there as both a possible
experimentation leader and further standardiser.
I have asked several times that IETF addresses that request. I was
usually responded that IETF is ill suited to lead an experimentation.
I therefore ran such a test-bed for two years, involving up to 30
machines (2002/2003) from all over the planet (dot-root project). The
results of this experimentation lead to several
conclusions/proposition validations. They are the base of my
positions and several initiatives.
Certainly there was some discussion within ICANN
circles about whether 2826 meant what it said. But, of course,
anyone can say just about anything in an ICANN meeting or on an
ICANN mailing list as long as it is consistent with the
organization's norms for appropriate behavior (just as with
Internet Drafts and IETF mailing lists). Such a comment is not
equivalent to an "ICANN request".
I am aware of one informal inquiry from an ICANN staff member as
to whether the IAB was likely to have more to say on the
subject. The informal response (from one of the editors of 2826
but with general sympathy from the IAB) was, if I recall,
approximately "which part of 'unique' are you having trouble
understanding?".
This was during the writing of ICP-3 and the fuss over alt(sic)roots.
RFC 2860 deals with the past. Not with the evolution of the Internet.
ICP-3 investigates the possibility of the end of the concept of
unique authoritative root file. It takes advantage from your draft on
classes: this a way to show where and how far to investigate and
respond the question "what does experimentation teach about the
internet evolution?". This was also the time IDN started being
considered. IMO a lot of things would have been different had we
considered that well written document.
ICP-3 also gives the criteria for such an experimentation we strictly
followed (except in extending to what we named ULDs [upper/user level
domains] to be able also to test real users behaviours in a
consistent way with these criteria). In that area we experimented that:
- the management of the current root file can be far more efficient,
secure, TLD Manager directed and universally controlled than by ICANN
or investigated by the CENTR.
- the single authoritative root should be a notion to stay, but the
file concept should develop into a structured matrix. We also
identified that these notions could find an adequate solution in the
evolution of the IANA concept itself to adapt to ISO 11179 conformant
ideas to CRCs (Common Reference Center) organising a DRS (Distributed
Registry System). The report I published - paid by Govs and
international instances - was ... thick but it only partly covered
our small budge. The AFRAC organisation we created to continue
experimentation and development on the DRS part for France. It gives
additional experience.
ICP-3 document refers to classes (in using a Draft of yours). This is
a more complex issue, we identified as a general problem (I
documented in a mail a few weeks ago) of the Internet architecture.
Several architectural parameters default to "one". The problems of
partitioning we face and started a balkanisation of the network, can
be structurally solved without conflict and more easily in turning
that parameters to "multiple set". There is one class, one (may be a
little more) group, one IPv6 plan, one namespace, one IANA, one
language, one ICANN, one IP, etc.
At least in my memory and reality, there has been no "ICANN
request" for an update, much less one that has been "unanswered
or opposed".
I argued that IETF should comment. This did not attract people.
Yourself now ask, in spite I explained it and gave the URL in the
mail you comment. You are used as the main example to exemplified a
possible evolution...
There were two main questions into this: national
security/sovereignty and multilingualism.
- you may recall your own comments on Vint Cerf's inputs, on this
list, over the stability of the root server system protected by
ICANN. They helped a lot to rise the attention of some Governments
(with direct impact on their interest in ITU and on WSIS). This
motivation is well documented by http://whitehouse.gov/pcipb and has
led to the US Statements of Principle. It has however a low echo at
the IETF. But we identified we could tackle it through an evolution
towards a user-centric architecture, the DRS and a country based
distribution of an IPv6 /3 block.
- the main engine to make things and classes moving (with some R&D
funding) is multilingualism. Because there is a need, there is a risk
of balkanisation, there are budgets. But IAB forgot about it in RFC
3869 - so there is work ahead to correct that. Harald has never been
impressed by the capacity of IETF to deal with multilingualism.
However with Paul Hoffman and you, he is one of the really few with a
vision on the issue (I disagree with much of it - at least what I
understand from his RFCs, remarks and involvements I know?).
This is why I created Eurolinc with Louis Pouzin, Gov and Industry
people a few years ago, which was quite active at the WSIS as you may know.
Capitalising on our experience, I have engaged a project, presented
in Luxembourg ccTLD Meeting among others, for such a test-bed to be
now a collective effort by ccTLDs and national Internet communities.
It has the support of a few countries communities and ccTLD Managers,
and the opposition of some IETF members. This project started with
the proposition of a liaison IETF/ccTLDs (I documented in a mail on
IETF) which is very similar to the US Statement of Principles
published further on.
Could you explain what you are talking about and identify the
request to which you are referring?
Or stop this, lest the claim about such a request become part of
Harald's 3683 case?
Harald's claim is a welcome commercial/political blunder in a complex
competition between his organisation and mine, over the
centralisation or the distribution of the Multilingual Internet
registries (control of the IANA vs. DRS). It was long awaited as a
public confirmation of our analysis.
As far as I am concerned it concludes the IETF part of my RFC 3066
bis saga. In spite of a tough opposition - I obtained most of the
revamps of the December LC failed Draft I wanted, so it does not
conflict with IRI-tags. I am sorry if Harald does not like them: they
are in the Draft now. The GenArt seems in a position to obtain some
of the others. IESG has now all the elements to decide of the future
of the IANA.
I submit that the resulting future image of the IANA under the
application of that Draft (and the resulting trust the public will
attach to it) will substantially weight in the future DNS
organisation acceptation.
Obviously other findings we made, in the DNS area, which may pop-up
sometimes and so substantially affect the joly old name space.
jfc
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf