ICANN/GNSO
DNSO and GNSO Mailling lists archives

[ga]


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

Re: [ga] whois: issues with uniformity


I really don't see the big problem here.

I recognize the forces of privacy vs the opposite are at work.

If Europeans or certain ccTLDs can't provide certain data or they feel
uncomfortable in doing so, then the whois just returns those fields
blank or with a "not available" message.  The same for US Registars.

The question is what is the minimum amount of data needed for the DNS
to work.  Does that include the name servers, Tech contact info and
admin contact info?

What's the bottom line data required?  If there is some kind of
geographical exception to any of that, then the global Internet will
just have to deal with it.

The WIPO bunch want everything and there is nothing wrong with the
wanting part.  What we need to deal with is the practical part, in
order for it to work for anyone, at all.

We'll never solve the politics or make everyone universally happy.
So, let's forget about that and deal with what is practical and even
expect exceptions to that.

Thanks,


Thursday, December 26, 2002, 5:48:04 AM, Vittorio Bertola <vb@bertola.eu.org> wrote:
VB> On Tue, 24 Dec 2002 13:41:41 +0100, you wrote:

>>This was hotly debated in the CRISP WG (not only on the basis of
>>privacy but also because of the cost it will imply for the registries,
>>whose machines would have to act as benevolent servers for this
>>task). The standard IETF reply is "The requirment is on the protocol,
>>not on the actual registries. In other words, the service MUST be
>>defined, but the registries MAY choose not to implement it."

VB> Which may be even worse, because then you might start to rely on this
VB> service, and then you will discover that it's broken in some TLDs that
VB> won't support it.

>>> "privileged" so that the access can be restricted to privileged
>>> accounts (which, I hope, will only be released to law enforcement
>>> agencies),
>>
>>No, priviledged will typically mean people who pay. Do not forget that
>>there is an actual market for cross-registries whois searches (I know
>>people who make a living from it).

VB> And I guess this market would disappear if cross-registry searches
VB> would become trivial.

VB> Anyway, as an individual it really makes me feel bad that the
VB> distinction between someone who can have access to all my personal
VB> data and someone who can't is how much will he pay. 

VB> Moreover, this is clearly illegal, at least in Europe. When
VB> registering a domain, nobody ever asked my agreement in publishing my
VB> personal data to the whole world, nor can it be reasonably said that
VB> it is necessary for the DNS to work.

>>> be written by the non-technical customer, with techies acting just as
>>> support to translate the customer's needs into technically meaningful
>>> language. In other words, this document (differently from the rest of
>>> this WG's work) should be discussed in ICANN, not in the IETF. 
>>
>>I disagree here. Why would the ICANN specify the requirments for the
>>future information service of .fr? The ICANN has no rights to discuss
>>the whois issues in domains outside of the gTLD it manages. 

VB> Then, why should the IETF do it? If you are talking about the actual
VB> policy choices of any ccTLD, nobody outside the country has the right
VB> to impose anything - at most, it may ask and give good reasons for the
VB> request, so that people who run the ccTLD are likely to consider it
VB> reasonable and adhere to the request.

VB> But we are talking about requirements for a new protocol, which will
VB> necessarily be unique all over the Internet. You can't specify a new
VB> Internet protocol at the country level - you need to do it at the
VB> global level. But if this new global protocol doesn't incorporate the
VB> ability to support the policy choices you might want to make at the
VB> country level, the ccTLDs will be prevented from adopting them,
VB> because the protocol won't support them. (Or they will have to choose
VB> not to support the new official Internet "WHOIS-2" protocol, which is
VB> never a nice choice to do.)

VB> This is why requirements for new global protocols (protocols, not
VB> actual implementations) have to be developed at a global policy level.
VB> If they are developed at a local policy level, they won't be global
VB> protocols - each country will start to talk its flavour of WHOIS, and
VB> I don't think this would be a good result. But if they are developed
VB> at the global *technical* level, they will lack proper policy
VB> considerations, and thus they will be unable to support all the
VB> different policies that the countries want to implement. 

VB> So the global policy level in this field (ICANN) should act as a
VB> collector of all the different policies that the g- and cc-TLDs want
VB> to implement locally, and ensure that new protocols are designed so
VB> that all these policies are supported by the protocol. It should not
VB> decide which types of policy are to be included in the protocol and
VB> which ones are not - it should simply ensure that all reasonable
VB> requests for features of the new protocol are included in its
VB> specifications.



----
Don Brown - Dallas, Texas USA     Internet Concepts, Inc.
donbrown_l@inetconcepts.net         http://www.inetconcepts.net
PGP Key ID: 04C99A55              (972) 788-2364  Fax: (972) 788-5049
Providing Internet Solutions Worldwide - An eDataWeb Affiliate
----

--
This message was passed to you via the ga@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html




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