Re: Single DNS root

At 21:10 01/09/2005, John C Klensin wrote:
> --On Thursday, 01 September, 2005 02:49 +0200 "JFC (Jefsey)
> Morfin" <jefsey(_at_)jefsey(_dot_)com> 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf