Re: Single DNS root

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

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]