<<<
Chronological Index
>>> <<<
Thread Index
>>>
[ga-sys] FW: WHOIS - conditions of use
> -----Original Message-----
> From: Joanna Lane [mailto:jo-uk@rcn.com]
> Sent: Wednesday, May 16, 2001 7:32 PM
> To: Roeland Meyer
> Subject: Re: WHOIS - conditions of use
>
>
> Roeland,
> You might want to forward this to the list because I
> previously hit the
> reply button instead of the reply to all button, so no
> intention to keep
> private, and have now forwarded seperately to the list, but
> exceeded the
> posting limit today and will leave any response until tomorrow.
> Have a great evening.
>
> Regards,
> Joanna
>
> on 5/16/01 9:54 PM, Roeland Meyer at rmeyer@mhsc.com wrote:
>
> >> From: Joanna Lane [mailto:jo-uk@rcn.com]
> >> Sent: Wednesday, May 16, 2001 5:41 PM
> >>
> >> on 5/16/01 8:10 PM, Roeland Meyer at rmeyer@mhsc.com wrote:
> >>
> >>> I hate to be doing any parade raining but,
> >>
> >> That's ok...:-)
> >>
> >> whois isn't a centralized or
> >>> centralizable system.
> >>
> >> I question that it cannot be centralized, but I understand
> >> that there is
> >> only one WHOIS server for each TLD. If so, provided they all
> >> comply to the
> >> same regulations, I don't see it as a problem.
> >
> > There is an issue of legal enforcement. If they don't
> comply, who is gonna
> > make them?
> >
> >> At issue is that the registry customarily runs the
> >>> whois server.It is also true that not all registries
> support whois.
> >>
> >> I don't see that as a problem, provided they comply with
> centralized
> >> regulations. Which Registries do not run a WHOIS server and
> >> why not? Does
> >> that mean there is no data at all in the public domain for
> some TLDs?
> >
> > That's exactly what it means. No publically accessable
> data, for those TLDs.
> >
> >> To
> >>> bring them all together in a centralized place would break
> >> more than one
> >>> existing compromise
> >>
> >> What compromise?
> >
> > Here is where I have to either depend on faulty memory or
> spend a few hours
> > looking it up. I ain't gottsa da hours... I hope you'll be satisfied
> > otherwise <g>. When RIPE was first commissioned they didn't
> want to do whois
> > at all. There was a major hue and cry from the ARPANET
> community. Lottsa
> > political wrangling later (and RIPE had to write the whoisd
> code themselves)
> > RIPE did whois, but it was a different format from that of
> NSI. That was the
> > compromise, ARPAnet folks wanted NSI whoisd to be
> definitive for RIPE as
> > well as ARIN. RIPE wanted their own or none at all. The USG
> graciously *let*
> > RIPE run their own whois.
> >
> > Frankly, I don't think that you'll get a lot of cooperation
> from either, to
> > place whoisd in a independent location and even less
> cooperation (from the
> > other) to put it in either one exclusively. Oh yeah ...
> then there is
> > APNIC... once your done play'n' 'round with the other two.
> >
> >> , as well as, creating a monstrous synchronization
> >>> problem.
> >>
> >> You're not going to like this but.... tech problems should
> never drive
> >> anything related to policy development for social issues.
> >
> > Actually, that point is something I preach to my techs whenever they
> > push-back on business requirements. So, there's no
> disagreement here. But,
> > there are other issues. There's also the laws of physics to
> contend with. A
> > centrally located whoisd, for the entire planet, will have serious
> > performance problems that are insoluble. This is why the system's
> > distributed in the first place.
> >
> >> There is also the issue of creating a single point of failure that
> >>> doesn't exist now.
> >>
> >> Agreed, but if there's only one WHOIS server for each TLD,
> >> that is already a
> >> single point of failure for that TLD isn't it?
> >
> > Not for the whole whois system in toto. Not even for a
> single TLD, like COM.
> > One whoisd could be down, yet the others are still working.
> If the NorthAm
> > to EU connection ever got cut then either one contimues to
> serve their local
> > population. Most folks would never notice. There is also
> the issue of JP
> > whois being served out of CH. That'll never fly, for the
> performance reasons
> > stated earlier.
> >
> >>> I have a whois client that looks up the TLD and queries the
> >> appropriate
> >>> host. It then takes the referer reference and re-queries
> >> the actual host
> >>> that has the data. Note that ripe.net is already under EU
> >> dominion and
> >>> they've already altered their whois output.
> >>
> >> ... and over time the rest will follow as they realize that
> >> they have no
> >> idea how many EU citizens are already in their database.
> >> Interesting...
> >
> > There is another issue here. When MHSC ran a registry, the
> registration
> > agreement specifically stated that the registrant would
> abide by Delaware
> > law.
> >
> > See section 9.3 of http://www.mhsc.net/host.htm
> >
> > you might want to see http://www.mhsc.net/services.htm as well.
> >
> > BTW, I'm still looking over the following.
> >
> >>>> WHOIS CONDITIONS OF USE
> >>>>
> >>>> 1.Purpose:
> >>>> Denial of Service Attack
> >>>> Data required:
> >>>> Technical contact phone number, email,
> >>>> Primary and secondary servers
> >>>>
> >>>>
> >>>> 2. Purpose:
> >>>> Network troubleshooting (clarify specific purpose)
> >>>> Data required:
> >>>> Availability:
> >>>>
> >>>> 3. Purpose
> >>>> Service of Legal Notices for trademark infringement
> >>>> Data required:
> >>>> Service Agent Name and address
> >>>>
> >>>>
> >>>> 4.Purpose:
> >>>> Criminal investigation by Police and Relevant authorities
> >>>> Access required:
> >>>> All data
> >>>>
> >>>> 5. Purpose:
> >>>> Registry records of customers
> >>>> Data required:
> >>>>
> >>>>
> >>>> 6. Purpose:
> >>>> Reviewing data on record and updating contact details
> >>>> Data required:
> >>>> All data
> >>>>
> >>>> 7. Purpose:
> >>>>
> >>
>
--
This message was passed to you via the ga-sys@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga-sys" in the body of the message).
Archives at http://www.dnso.org/archives.html
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|