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

Re: (?) Standards set for registering Net domain names



Rik and all,

Rik Thomas wrote:

> At 05:07 PM 3/9/99 +0000, jeff Williams wrote:
> >Rik and all,
> >
> >  The fact or not that this is not your normal service business is
> >not really relevant here, and should not be in any case.
>
> How is it not relevant, explain yourself and post some content instead of
> useless comments.

  I have posted content on this subject at least 4 times in the past
3 years.  Maybe you missed those.  Check the relevant archives
for further documentation.

>
>
> >  Single threading to a central registry is by definition not
> >good for stability, hence I find this argument invalid as well
> >based on what we already KNOW to be the case with NSI
> >presently.
>
> How would you propose to include a company/entity/whatever that has no
> proven track
> record nor the $100k in the bank, nor 5 employees, etc.  How would you
> protect their customers?

  No proven track record in what?  I have been involved in at least
four different companies in the internet business that have had no
track record of any kind in the past, other than the founders were
employees of other companies at the time, and they have all
gone public ( Made IPO offerings ) and are doing VERY well
presently.

  To answer your question more directly, however I have suggested that
the IANA/ICANN have the ability to pick up the responsibility for continued
service in the rare event that a registry/registrar fail and go out of
business until another entity can be found to take over those
responsibilities.  They can achieve in several ways, of course that are
not direct to the ICANN/IANA.  The methods are, of course, many and varied.
Do I need to create an outline for a business plan so that you or anyone
can understand how to accomplish this?  I hope not.  If I do, than
there are more problems here than directly meet the eye....  And I
am sure that you, amongst others on these lists, are bright enough
fellows/gals to figure out many different workable methods by which
this can easly occur or be handled that would meet or exceed the criterion
that you posed your question to me here.  If not, I would be happy, under
a contractual arrangment to do so, as I am from time to time involved
in many similar situations on a contractual basis....

>
>
> >Rik Thomas wrote:
> >
> >> It is very understandable to believe that.  But this is not your normal
> >> service business.  There are real people and real businesses that rely on
> >> this data.  So to dismiss lowering standards as stagnating innovation is
> >> naive at best.
> >>
> >> What solutions are there?  One I have, and this empowers one entity
> >> unfortunately, is keeping a central "entity" and all registrars are
> >> required to update this entity with all information, this way if one of
> >> these smallish startups fail or fade away the data can quickly and
> >> reasonably restored.  I still think that every other requirement,
> >> insurance, staff of 5, and an existing network are necessities.  There has
> >> to be some basis albeit minimal.
> >>
> >> Rik
> >>
> >> At 12:03 PM 3/9/99 -0600, Phil Howard wrote:
> >> >> Unfortunately, I don't think there is a place for an "embryonic" startup
> >> >> acting as a registry.  Imagine the impact if they went out of
> >> business, the
> >> >> owner decided to pursue space flight with the registration money
> >> instead of
> >> >> running the business, imagine a fire/flood/act of whomever, an embryonic
> >> >> startup does not have the facilities nor resources to withstand such
> >> >> potential and varied impact.
> >> >
> >> >This argument can apply to any business.  Actually enforcing it will also
> >> >lead to stagnation since the supply of new and innovative ideas will be
> >> >cut off.  Yes, an "embryonic" startup does present a risk, and we must
> >> >not ignore that.  But it is something that can be dealt with by planning
> >> >for the risk and defining a course of action to take should something
> >> happen.
> >> >The greatest difficulty comes from having failed to make those plans.
> >> >
> >> >--
> >> >Phil Howard | stop7617@s4p3a6m1.edu suck8it1@dumbads0.com
> >> >a3b1c7d5@dumbads0.edu
> >> >  phil      | eat7this@dumbads0.org ads6suck@dumb1ads.edu
> >> > die4spam@anywhere.com
> >> >      at    | blow2me2@spam8mer.org suck2it4@lame9ads.com
> >> > w1x6y2z3@no01ads8.edu
> >> >  ipal      | a9b0c2d7@no9place.com blow7me6@s3p5a9m4.edu
> >> > stop8350@dumbads6.edu
> >> >     dot    | eat4this@dumbads9.org crash653@anyplace.net
> >> > stop9it5@spam8mer.com
> >> >  net       | no99ads6@spam0mer.org no6spam7@lame5ads.org
> >> > die0spam@no2where.org
> >> >
> >> >
> >> >--
> >> >DOMAIN-POLICY administrivia should be sent to <listserv@lists.internic.net>
> >> >To unsubscribe send a message with only one line "SIGNOFF DOMAIN-POLICY"
> >> >For more help regarding Listserv commands send the one line "HELP"
> >>
> >>
> >
> >Regards,
> >
> >
> >--
> >Jeffrey A. Williams
> >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-1894
> >Address: 5 East Kirkwood Blvd. Grapevine Texas 75208

Regards,

--
Jeffrey A. Williams
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-1894
Address: 5 East Kirkwood Blvd. Grapevine Texas 75208