ICANN/GNSO
DNSO and GNSO Mailling lists archives

[ga]


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

Re: [ga] whois: issues with uniformity


Don and all former GA members,

  Don, it is not just privacy that is in the balance or under pressure.
It is Privacy AND Security, which for public data, go hand in hand.
This is especially true with Whois data and displayed Data fields
on a Whois query.  Some hard and fast policy on a global basis
is needed.  The question is, is such a policy possible to implement
or even enforce.  I agree with you that at present, I don't think so.
The other problem is with gTLD's vs ccTLD's as to Whois
data and privacy AND Security.

  The countries and their respective ccTLD's will do as their
legal statutes require regardless of what the IPC and BC or
the ICANN BOD and Staff will wish to hoist upon them.
gTLD's are another matter entirely.  Hence the need or
strong desire for a global policy on Whois data displayed
with respect to Privacy and Security...

Don Brown wrote:

> 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

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup - (Over 127k members/stakeholders strong!)
CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail jwkckid1@ix.netcom.com
Contact Number: 214-244-4827 or 972-244-3801
Address: 5 East Kirkwood Blvd. Grapevine Texas 75208


--
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 >>>