Kent and all,

  You may reply to Roeland so that others won't be fooled, but in doing
so you are attempting to fool those same people and ICANN seems
to be heading in this direction as well.  Some of us are not as easily
FOOLED by what ICANN is proposing.  I can only hope that the
NTIA and the USG in general isn't either, but I am beginning to have my
doubts on that score.

  More to the point however is that any TLD can be made visible globally
WITHOUT being in the legacy roots.  We have already proved this
almost two years ago now.  We, and possibly MHSC or ORSC will
be doing so again in the near future.  If at any point the ICANN or
any of its new registrars decides to register DN's within those
TLD name spaces it WILL than be denial of service, and a violation
of US law as well and quite a few other countries as well.

  My suggestion to you is that you start doing a better job of doing your
homework and paying much better attention before making such
broad statements as you have done here.  I would also suggest
the the ICANN Interim board consider the same....

Kent Crispin wrote:

> On Thu, Apr 01, 1999 at 10:44:41PM -0800, Roeland M.J. Meyer wrote:
> [...]
>
> > >Uh, Roeland, if ICANN decides that it needs to change to a Swiss
> > >corporation, what are you going to do? Sue in Swiss Court? Do you
> > >have a Swiss trademark?
> >
> > Irrelevant, they're definitely NOT going to do that, the USG won't let
> > them, period. Are you going to claim otherwise?
>
> 1) Yes, I am going to claim otherwise.  The USG has an oversight
> role for ICANN at this point in time; that won't continue
> indefinitely.  The USG has made that very clear, and there is strong
> pressure from other governments to get the USG out of this role.
>
> 2) I'm sure that ICANN has no intention at this point of
> incorporating in another country, but it would be trivial for them
> to do so at any time -- it's a political issue, not a legal one.
>
> 3) The general point is that you are operating with provincial
> blinders -- your scheme *depends* on certain assumptions of
> jurisdiction, and doesn't generalize to an international context.
>
> [...]
>
> > >> nodes of the private PNET TLD would be able to access any node on the
> > >> public PNET TLD. This is a Denial of Service issue.
> > >
> > >No, it isn't.  They are not denying your customers any service that
> > >they are currently getting.  It's true that the customers won't be
> > >able to get to someone who registers a name in the new official TLD
> > >-- that's something that registrants in that TLD might consider for
> > >about 2 milliseconds, but that is their problem, not ICANNs.
> > >
> > >If you make a stupid choice and run a private TLD this way, it is you
> > >who are limiting your customers' future access, not ICANN.
> >
> > First off, I presented this case as a hypothetical. The actual case, which
> > you are completely ignoring, is the overlayment. This hypothetical is to
> > highlight the limits of current technology implementation. Note that I did
> > NOT say "capability". Optimal capability is better than this, but it is not
> > completely deployed. Also, there is no current problem with this because
> > they are not allowing new TLDs. When service is denied, whether intentional
> > or not, service is still being denied. Do you disagree that this is a valid
> > problem scenario?
>
> I deny that it is a denial of service.  "Denial of service" means
> obstructing a service that exists.  If you use a private TLD for any
> purpose, and ICANN adopts a public TLD with the same name, it is not
> a denial of service to anyone.  The service to your private TLD will
> continue unimpeded.  Anyone who uses the public TLD can't get to your
> private TLD, but they couldn't do that anyway, so that's not a denial
> of service.
>
> It's true that *you* (and the unfortunate people who made the mistake
> of being your customers) can't get to domains that might be
> registered in the new public TLD, after it is created.  But that's
> not a denial of service, either: people registering in the public new
> domain can't be seen by *anyone* who has been using a private TLD by
> the same name.  That is and always has been true -- if I register a
> .com name, I know that my domain won't be visible to anyone running a
> private .com TLD.
>
> [Incidentally, just FYI, in my real job I actually run the root zone
> for a large private network, and we have private TLDs.  And we
> actually do run private versions of the .com and .gov TLDs.  But in
> our case, we know the networks will always be separate.]
>
> So there is no denial of service anywhere.  If you are so foolish as
> to use a private TLD as you describe, you run a risk of causing
> *yourself* problems down the line.  That is a risk you knowingly took
> by creating a private TLD in the first place.  If you don't disclaim
> that risk to your customers, they could sue *you* for mismanagement.
>
> > Why do you make such a stupid statement? What is your point?
>
> I guess I was a bit subtle.
>
> >>> For this reason, the
> >>> root-servers must acknowledge private TLDs, even if they don't list them in
> >>> the roots.
> >>
> >>Oh sure.
> >
> > Again you make these blank statements. What is your point?
>
> It is completely impossible for ICANN to know of every private TLD in
> existence, and therefore completely unreasonable to expect that ICANN
> must be aware of every private TLD in existence, in every country of
> the world.  The law may be an ass, but it's more often than not a
> reasonable ass.
>
> > You make blank statements and present no points.
>
> I made points -- whether you choose to pay any attention to them is
> your business, and you can waste your time and money however you
> like.  In general, I don't reply to you for your benefit, I reply so
> that other people won't be fooled.
>
> --
> Kent Crispin                               "Do good, and you'll be
> [EMAIL PROTECTED]                           lonesome." -- Mark Twain

Regards,

--
Jeffrey A. Williams
CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail [EMAIL PROTECTED]
Contact Number:  972-447-1894
Address: 5 East Kirkwood Blvd. Grapevine Texas 75208

Reply via email to