Re: [ga] a quote from Lynn

[Jeff Williams <jwkckid1@ix.netcom.com>]

Sandy and all assembly members,

Sandy Harris wrote:

> Eric Dierker wrote:
> >
> > "Universal resolvability means the ability to find the same answer to
> > the same query from anywhere on the public Internet. The position
> > advocated by New.net relies on the fundamentally erroneous assumption
> > that universal resolvability is not an important feature of the DNS.
> >
> > To the contrary, universal resolvability is one of the key design
> > elements of the DNS. If users perceived that the DNS began to produce
> > different results in response to the same question, this would seriously
> > undermine confidence in the reliability of the Internet to users and
> > potential users around the world."
> >
> > Yes I take this a little out of context but I do not like the
> > fundamental position that any system would require only one right answer
> > to the same question.
>
> That's been one of the basic ideas all along. Way back in 1987, RFC 1024
> "DOMAIN NAMES - CONCEPTS AND FACILITIES" states the design goal for the
> DNS system, and the very first one was:
>
> " The primary goal is a consistent name space ...
>
> This is fundamental.

  Yes it is fundamental.  However there are many ways in which this
goal, "a consistent name space", can and is being achieved.
However the ICANN BoD and staff don't seem to see this clearly
and have decided to try to dictate the method (only one) that
they believe achieves this fundamental goal.  There iw where the
Market place and the ICANN BoD and staff have parted company,
so to speak....

>
>
> > It sounds like he is saying that users are too
> > stupid to handle a choice therefor we must not give it to them.  No
> > rereading his policy paper; it does not sound like it, it is it.
> >
> > There may be reasons for this policy but to lay it off on the users
> > being to stupid to make alternating choices between roots is wrong both
> > technically and morally.
>
> It's not that the users are stupid or incapable of making choices, the
> issue is that the system should not force them to make such choices.

  Agreed.  By that same token, the "system" should also not prohibit
choices form being made either...

>
> Names should map to addresses and resources in a predictable and
> consistent way.

  Yes they should.  And the ICANN BoD and staff have decidedly to
not comply with this basic fundamental principal by knowingly introducing
colliding TLD's, .BIZ and .INFO...

>
>
> Have you ever used a piece of software where the behaviour you get
> depends on some obscure setting you didn't know about? My example
> would be Word doing various auto-correction and auto-format things
> to text I was writing. Yes, like most users, I'm smart enough to
> dig through menus and documentation and find out to how to fix it,
> but it is still irritating as the devil.
>
> When I type 'www.whatever.biz' into my browser, I don't want the
> result to depend on how some administrator at my ISP has set up
> their DNS server.

  Then you should set you parameters to point to the DNS in-address-arpa
IP address that you choose to point to for your desired resolution
result.

> Yes, I could figure out what was going on and
> complain to the ISP, switch ISPs or set up my own name server if
> I didn't like it. However, I shouldn't have to!

  You don't have to do any of these things.  You can do all of what you are
suggesting/complaining about, with you client software.

>
>
> So the question is not whether we need a single consistent namespace,
> but how to build it.

  Well it seems that the market place disagrees with this assumption or
position and New.Net, amongst others is stark evidence of.  The better
or more accurate question is how can we find ways in which to
share Root structures and independent stand alone registries in a
stable and cooperative fashion.  What are the choices?  Which ones
can be implemented seamlessly or without too much overhead, and
what methods (Technical) are beneficial to expansion of the DNS
in a meaningful and market based demand fashion.

>
>
> I'd say we do that by accepting the fact that ICANN has been created
> to do this job and given the responsibility for that namespace, then
> trying to make ICANN work as it should. Among the things I'd like to
> push for:

  ICANN was created to work with the stakeholder community in a cooperative
way to meet market demand and provide stability in doing so...  Thus far
this has not occurred adequately.  As a result, the market place will
search using various methods to do this itself without the top-down
approach that the ICANN BoD and staff have decidedly to undertake.

>
>
> The complex political compromise process during ICANN formation led
> to a board that was to have nine elected at large directors and nine
> from various interest groups. Step one is to achieve that balance.

  Yes and no here.  Step one is to have the @large as the majority or
equal footing as seats on the board with other various interest groups.

>
> (It isn't the balance I'd have chosen -- I'd like to see public
> interest groups like EFF with as many votes as all the business
> constituencies combined -- but it's in the bylaws and better than
> what we have to date.)
>
> Think about remedies for the over-use and over-selling of .com, the
> biggest problem in the current namespace.
> (My first thought is just stop .com registration, but is there a
> better solution?)
>
> Fix the UDRP; see my comments in other threads.
> (I'd like to say scrap it, but doubt that's practical.)

  Fixing the UDRP is possible but not likely to happen or
practical on a global basis.

>
>
> Technically, a TLD is no harder to set up than an SLD. The $50,000
> application fee is absurd. Scrap it. Aim at 100 new TLDs by 2002,
> with cost well under $1000. If it's possible to give the "alternate
> root" people some sort of olive branch in the process, so much the
> better.

  We agree here!

>
>

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup - (Over 118k members strong!)
CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail jwkckid1@ix.netcom.com
Contact Number:  972-447-1800 x1894 or 214-244-4827
Address: 5 East Kirkwood Blvd. Grapevine Texas 75208


--
This message was passed to you via the ga-full@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga-full" in the body of the message).
Archives at http://www.dnso.org/archives.html