ICANN/GNSO GNSO Email List Archives

[registrars]


<<< Chronological Index >>>    <<< Thread Index >>>

RE: [registrars] .net thick/thin discussion

  • To: "Larry Erlich" <erlich@xxxxxxxxxxxxxxxxxx>, "Jens Wagner" <jwagner@xxxxxxxxxxxxxxx>, "Eric Brunner-Williams in Portland Maine" <brunner@xxxxxxxxxxx>, "Marcus Faure" <faure@xxxxxxxxxxx>, "Paul Stahura" <stahura@xxxxxxxx>, "Bruce Tonkin" <Bruce.Tonkin@xxxxxxxxxxxxxxxxxx>, "Tim Ruiz" <tim@xxxxxxxxxxx>
  • Subject: RE: [registrars] .net thick/thin discussion
  • From: "Mitchell, Champ" <Cmitchell@xxxxxxxxxxxxxxxxxxxx>
  • Date: Thu, 29 Jul 2004 09:15:54 -0400
  • Cc: <registrars@xxxxxxxx>, <owner-registrars@xxxxxxxxxxxxxx>
  • Sender: owner-registrars@xxxxxxxxxxxxxx
  • Thread-index: AcR0+CxT5rogwQ4tT3iyOwodQ2+XbAAcxY0g
  • Thread-topic: [registrars] .net thick/thin discussion

Folks,

First let me express how impressed I have been at the erudition and effort that has gone into this exchange. Much of it was beyond me technically, but the overriding issues are clear.

Clearly Marcus is correct that there are no unanimous position was expressed on the thick vs. thin issue. However, the exchange did seem to illuminate many points of agreement also. With that in mind, it seems that we may all agree on some objectives we want to obtain. Among them seem to be:

1. Protection of the registrant's personally identifiable information to the maximum extent possible and consistent with other legitimate needs for information;

2. Providing useful information to registrants and their authorized representatives concerning their registrations in a format that is most useable and most user friendly;

3. Reasonable access to law enforcement agencies for their legitimate needs, with control on that access to avoid, or at least minimize, abuse and to minimize the risk of unauthorized access;

4. Reasonable, but more restricted access to the intellectual property community for its legitimate needs, with control on that access to avoid abuse and to avoid the risk of unauthorized access, at least if they foot the bill for the cost of providing access system with all of its protections.

Probably there are others, but these four at least seemed to be agreed to by all, or at least not argued by anyone. 

So we have a start. 

-----Original Message-----
From: owner-registrars@xxxxxxxxxxxxxx [mailto:owner-registrars@xxxxxxxxxxxxxx] On Behalf Of Larry Erlich
Sent: Tuesday, July 27, 2004 11:47 AM
To: Jens Wagner
Cc: registrars@xxxxxxxx
Subject: Re: [registrars] .net thick/thin discussion

Jens Wagner wrote:
> 
> Larry Erlich schrieb:
> 
> >Marcus Faure wrote:
> >
> >

> >>As long as we do not have standardized whois output, a thin model is more
> >>difficult to deal with. I also think that the per-registrar thin model that
> >>Bruce proposed will cause this extra work, and honestly I do not believe that
> >>the average user understands it.
> >>
> >>
> >
> >Can you explain what you mean by "honestly I do not believe that the average
> >user understands it"?
> >
> What happened during the .ORG Transition? Didn't you receive many
> customer inquiries regarding the WHOIS? We sure did, as our customers
> were confused. We need to think more for the customer and to the benefit
> of the registrant himself instead of solely the registrar.
> 
> The confusion beneath the registrants was exactlly due to the
> thick+thin-whois! There were a lot of problems regarding registrar
> transfers due to one registrar being "thin" and the other "thick", which
> resulted in more support --> higher costs!

We didn't have that issue but I now understand your point.

> 
> >
> >
> >>A registration service provider can be handled with an optional maintainer
> >>field in the whois. We have one on the CORE whois that defaults to the member
> >>number, but can also contain a URL.
> >>
> >>
> >
> >How are you going to translate the "optional maintainer field"
> >in the registry whois output so that a registrant can understand
> >who the reseller is? Are you going to ask the registry to
> >lookup and display 2-3 lines of human readable information? And that they will
> >agree to even make modification to add this field?
> >
> This should be proposed as an EPP extension anyway. At least one line of
> text per domain name should be usable for such purposes.

There would have to be at least two lines of text
per domain. One for the registrar with full contact
information and one for the reseller. But I am still in favor
of a thin model. Keep in mind that our whole system is setup
as a thick model and I would rather not have to have the
expense of re-writing our whole system to accomodate this change.
I don't think you can assume that this is trivial for many
registrars. This will be expensive. 


> 
> >
> >Will you also have the registry (if thick model) display the
> >registrar in a human readable format? Or does the registrant have
> >to do a further search with a code to find out, for example, who
> >registrar "R33-LROR" is?
> >
> >
> This is up to the registry. However there should be a webinterface that
> shows all informations 'pretty-printed'.

Doesn't handle the situation where another entity wants to query
port 43 to display the information without creating their
own routine to "pretty-print" the info. In other words it will
only be nicely human readable if viewed through the registry
web interface but not through another entities web interface.

Larry Erlich

http://www.DomainRegistry.com


> 
> Best regards,
> 
> Jens Wagner
> CTO Key-Systems GmbH
> 
> Key-Systems GmbH
> Prager Ring 4-12
> 66482 Zweibrücken
> Tel.: +49 (0) 6332 - 79 18 50
> Fax.: +49 (0) 6332 - 79 18 51
> Email: support@xxxxxxxxxxxx
> 
> www.key-systems.net
> www.domaindiscount24.com
> www.RRPproxy.net
> www.Key-Fashion.de
> 
> >
> >Larry Erlich
> >
> >http://www.DomainRegistry.com
> >
> >
> >
> >>Yours,
> >>Marcus
> >>
> >>
> >
> >
> >

-- 
-----------------------------------------------------------------
Larry Erlich - DomainRegistry.com, Inc.
215-244-6700 - FAX:215-244-6605 - Reply: erlich@xxxxxxxxxxxxxxxxxx
-----------------------------------------------------------------





<<< Chronological Index >>>    <<< Thread Index >>>