<<<
Chronological Index
>>> <<<
Thread Index
>>>
Re: [registrars] FW: [dow1tf] TR: IPC constituency statement for Whois TF1
- To: Paul Stahura <stahura@xxxxxxxx>
- Subject: Re: [registrars] FW: [dow1tf] TR: IPC constituency statement for Whois TF1
- From: "Ross Wm. Rader" <ross@xxxxxxxxxx>
- Date: Tue, 30 Mar 2004 21:43:41 -0500
- Cc: Tim Ruiz <tim@xxxxxxxxxxx>, registrars@xxxxxxxx
- In-reply-to: <DA6F8AFB015C544AB4385B5DEBDE1FBB0C1C4A@mail.enom.com>
- Organization: Tucows Inc.
- References: <DA6F8AFB015C544AB4385B5DEBDE1FBB0C1C4A@mail.enom.com>
- Reply-to: ross@xxxxxxxxxx
- Sender: owner-registrars@xxxxxxxxxxxxxx
- User-agent: Mozilla Thunderbird 0.5a (Windows/20040113)
On 3/30/2004 9:13 PM Paul Stahura noted that:
What happens with thick registries?
.com and .net will switch to EPP, and who knows, probably thick EPP.
Do we get to choose "b allow registrars to manage the service as they see
fit" by not providing them with the whois information?
I think this is almost a separate conversation, but my preference would
be to evaluate the utility of the thick registry model before we permit
the creation of any more. Based on the testbed experience, I'm not
convinced that centralizing customer data in this way without getting
the guarantees we all need from a legal perspective is necessarily a
wise thing moving forward.
To the point as it relates to this policy - registrars shouldn't be
obligated to provide the data to any party that can't guarantee that the
data will be treated in a manner consistent with the policies and
legislation under which it was collected.
Are you proposing we be allowed to not give the info to anyone?
That would be one potential implementation. Or just to parties that we
have a relationship with. Or just to parties that acts a brokers between
registrars and potential licensee's or...
--
-rwr
"Don't be too timid and squeamish about your actions.
All life is an experiment.
The more experiments you make the better."
- Ralph Waldo Emerson
Got Blog? http://www.blogware.com
My Blogware: http://www.byte.org
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|