Re: PAB I got the feathers, warm up the tar.

From: Werner Staub (werner@axone.ch)
Date: Thu Oct 15 1998 - 23:58:52 PDT


Dear Robert,

This is a very good point and an excellent opportunity for CORE to show
that we can beat NSI. A registrar is in a much better position to verify
data than a central registry.

I wonder if CORE should not take the lead and publish a White Paper on
how it intends to administer data. This can be circulated as a draft
and later approved by the CORE membership.

In the technical solutions proposed, CORE should remain faithful to
the end-to-end principle of the Internet. This means that activities
should be handled as much as the periphery as possible, i.e. rather
by the registrar than by the registry if that is possible. This implicitly
strengthens our position against NSI and other potential monopoly
registries.

Your message leads me to another observation. CORE should set policy
(in consultation with POC where appropriate), but not _wait_ for POC to
act. After all, its a policy _oversight_ committee, not a policy-setting
committee. Resolute action in this direction might help POC find its path
into transition to ICANN.

Regards,

Werner

"Robert F. Connelly" wrote:
>
> Dear Colleagues in PAB, POC and CORE:
>
> Some times we dumb chemists do strange things.
>
> Like, for instance, running tests.
>
> Most of the time, we discover something which differed from what we
> expected, what we "knew" from our "intuition".
>
> My boss man in my second job as a chemist was Ulric B. Bray, a brilliant
> industrial chemist and the father of heavy duty motor oil. Doc Bray would
> come out in the lab to discuss one of my projects, then would say, "Let's
> have a meeting of the Sceptics Society". He'd get a beaker and a graduated
> cylinder, some chemicals and run a test or two. His ideas were usually good.
>
> Or, he'd say, "One test is worth three expert opinions".
>
> Now, back to the subject;-) Oh, I didn't tell you the subject yet.
>
> At the Stanford U and Georgetown U (D.C.) WIPO Conferences there was a
> familiar strain running through the testimonies of many firms with famous
> trademarks --- "The NSI database is full of erroneous data". Some cyber
> pirate was using one of their trade names or brands, perhaps to post hard
> core pornography. Some speakers had tracked down the problem to 1.
> deliberate misrepresentation by the registrants, 2. lack of verification by
> NSI, 3. obsolete data, e.g. a. registrant changed Email address without
> updating record, b. primary or secondary DNS in error, c. an ISP had gone
> out of business or has changed domain name, d. post office box address
> fictitious, e. physical address (street or town) incorrect.
>
> As I listened to the day's testimonies in Stanford, it occurred to me that
> it would be possible for the registry to automatically PING to the domains
> of the Email addresses for Administrative Contact, Technical Contact,
> Billing Contact, primary and secondary DNS servers. (By "domains of the
> Email addresses" I mean if the Email address is "charlie@hometown.com",
> then PING "hometown.com.)
>
> I mentioned my idea to Don Heath after that first day's meeting.
>
> At the Georgetown meeting, I suggested this strategy, proposing that
> registries could ping automatically on a periodic basis (as CPU time is
> available), say weekly or monthly. Of course, there would be occasional
> failures even with perfect data. I suggested that there be a threshold at
> which there would be an "amber light", alerting the Registrar of a
> potential problem. Above some higher threshold, a "red light" would alert
> the Registrar of the need for action. Perhaps a registered letter
> announcing an intent to cancel the registration within 30 days unless the
> registrant contacts the registrar and corrects the errors.
>
> To that point, the whole PINGing idea was "gedanken", just thoughts in my
> cerebellum.
>
> Jet lag got me up this morning at 03:00. I decided to look into our own
> Web-Domains mSQL file of registrations. What did I find?
>
> Test DNS Email Domain
> A Both OK OK But the IP's differed*
> B Both OK Bad
> C Both OK Bad
> D Both OK Bad
> E Both OK OK
> F Both OK OK
> G Both OK OK
> H Both OK OK
> J Both OK OK
> K Both OK OK
> L Both OK Bad
> M Both OK Bad
> N Both OK Bad
> P One Bad Bad
> Q Both OK OK
> R Both OK Bad
> S Both OK Bad
> T Both OK OK
> U Both OK OK
> V Both OK OK
> W Both OK Bad
>
> My original sample was 84. I selected 21 or 25% for analysis. One record
> had both DNS entries bad, one had one DNS name bad, ten had bad Email domains.
>
> In the case of "A", the IPs shown during "lookup" of the domains differed
> from the IP's in the record. The stated IP's were bad. In "P", the
> secondary DNS was shown as "dns.tinker.com". Checking the IP given for the
> secondary, I found it conformed to "troll.tinker.com". Perhaps it was
> changed, perhaps the applicant made a mistake.
>
> How could errors of this type affect us as CORE Registrars?
>
> Toward the end of the afternoon in Stanford, a representative of Cisco made
> this statement: "These problems with bad data only started in 1995 when
> NSI stopped *administrating* the registration process". He was referring
> to the fact that SAIC acquired NSI and then showed it how to turn domain
> name registration into a money machine.
>
> Think about that!
>
> Put it in the context of the proposal by many speakers who proposed that
> registrants be required to designate the *registrar* to accept service of
> process:-{ Can you imagine what will go through the mind of the registrar
> when the first "hot potato" Summons arrives at his or her front stoop?
>
> Other speakers (I think AT&T was one of them) thought that 1. the
> registrar, 2. the registry and 3. ICANN or IANA should *all* be designated
> to accept service of process on behalf of the registrant. If and when that
> happens, registrars will want to have correct data!
>
> The WIPO meeting in Tokyo will occur on Monday, 19 October. I'll be there
> again;-)
>
> Regards,
> BobC

-- 
Tel. +41 22 8200074   Fax +41 22 8200073  http://axone.ch



This archive was generated by hypermail 2b29 : Sun Jan 30 2000 - 03:22:37 PST