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.
On 17:25 31/08/2005, Paul Hoffman said:
At 3:24 PM +0200 8/31/05, Peter Dambier wrote:
the Public-Root is not an alternative root but a solution.
<http://public-root.com/tlds.htm>
It also confuses Registries and Registrars (cf. presentation of ccTLDs)
makes it very clear that this set of root-like servers intends to
answer affirmatively and authoritatively for TLDs that the
real/generally-accepted
root servers would say do not exist. From the material on that page,
it is also likely that, in the future, the NS records returned by
these root-like servers for some TLDs will be different than those
returned by the real/generally-accepted root servers.
There is an USG/ICANN contract over IANA functions confirmed by RFC
2860. Not to make any politics let call it "legacy" root as results
from the 1984 agreement (RFC 920, claimed source of the ICANN
legitimacy). The resulting "legacy top zone" - through server
declarations - is already larger than documented by its root file.
In other words, the statement "the Public-Root is not an alternative
root but a solution" seems dishonest when one reads the material at
the site describing the service.
Correct. The "Public-Root" is technically a decentralised root file.
It is not a "solution".
At 13:44 31/08/2005, Harald Tveit Alvestrand wrote:
Anyone who wishes to avail themselves of this service would be well
advised to read RFC 2826 - "IAB Technical Comment on the Unique DNS Root".
Harald, RFC 2826 has been used and partly out-dated by the 2001
response ICANN (http://www.icann.org/icp/icp-3.htm ) you ignored for
practical reasons I accept, but none one commented. It calls for an
experimentation to document the evolution we face today unprepared.
When there is more than an unique authoritative root file.
I lead such an experimentation for two years, along with the ICANN
criteria. Most of my positions you oppose have been tested and
validated there. I am sure would you run a similar test-bed, our
strategies could still oppose, but our understandings of the network
architectural evolution would be similar.
When IETF documents refer to the DNS, I think it's a safe bet that
they are intending to refer to the system under the single root that
most people regard as "the root".
May be, but this is wrong. We are to face the balkanisation vs.
compartmentalisation reality. Chinese law and US Statements of
Principles have enforced a new situation leading to sovereign
alt-roots. We can say "obey RFC ....", be disregarded and get
balkanisation. Or we can work on solutions adapted to the current
evolution, imagine a distributed root system (no big deal) and
possibly obtain a unique authoritative root matrix. A few months from
now it will practically be too late.
Harald, we are in direct competition over the language root. "my"
solution there can survive a balkanisation of the IANA, not yours. So
it is a common interest to quickly review and document the evolution
of the name root before it is too late for you and a pain for others.
I don't think any of the fundamentals have changed in the last 5 years.
This _IS_ the problem. You have not seen and acknowledged the change
(first act: Tokyo 2000, call for the first change in RFC 920 status
quo), leading to (2001) considering the obsolescence of these
"fundamentals". In that area nothing has changed since 1984 on the
internet root side, while the Internet _has_changed_ into the
international network it only interfaced in 1984.
This change is not trivial, it must be matched by a serious "how to".
jfc
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf