ICANN/GNSO GNSO Email List Archives

[registrars]


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

Re: [registrars] unsanctioned whois concepts (long)

  • To: "Mark Jeftovic" <markjr@xxxxxxxxxxx>, <registrars@xxxxxxxx>
  • Subject: Re: [registrars] unsanctioned whois concepts (long)
  • From: "mdierstein" <mdierstein@xxxxxxxxxxx>
  • Date: Sat, 1 Nov 2003 20:55:14 +0100
  • References: <Pine.LNX.4.58.0310301106010.31882@r2d2.easydns.com>
  • Sender: owner-registrars@xxxxxxxxxxxxxx

What I believe to be interesting are the basic premises/opinions. The
difficulties to design and implement technical tools should not be an
obstacle to dig these ideas. The question of  transfers is only a side
question.
Mathieu
Namebay

----- Original Message -----
From: "Mark Jeftovic" <markjr@xxxxxxxxxxx>
To: <registrars@xxxxxxxx>
Sent: Thursday, October 30, 2003 5:59 PM
Subject: [registrars] unsanctioned whois concepts (long)



>
> Over the course of my stint as the second of the 2 registrar reps
> to whois-sc I found myself toying with some unconventional
> ideas about whois data and how to mitigate some of the issues
> surrounding it.
>
> The following is neither endorsed by whois-sc nor the RC, they are
> just the thoughts I've come up with during this, my first experience
> in the field of ICANN/GNSO collaborative work.
>
> Here a couple of basic premises/opinions:
>
> 1) Ultimately, the data around a given Registrant belongs to the
> Registrant. Anything that happens to Registrant data should do
> so with that in mind.
>
> 2) Registrars bear the cost of collecting that data, maintaining it
> and (along with some Registries) disseminating it.
>
> The trouble now is port 43 is inherently mine-able, and the bulk whois
> requirements force us to make Registrant data available en masse.
>
> The complicating factors are how to protect Registrant privacy and still
> maintain legitimate need-to-know contactability; and protect Registrars
> from having to bear the costs & liabilities of disseminating that data
> (including backlash).
>
> My ideas essentially break down to:
>
> - De-centralize the location of the records.
> - Revising the Data Elements attached to those record
>
> 1. De-centralize the location of those records.
> =================================================
>
> Why not push the stewardship of the data back to the ultimate owner?
> The Registrant. Basically, the registrant could store their own
> whois record in a well-known location on their own servers, similar
> to a P3P policy (i.e. /w3c/whois.xml ), and the registrars maintain
> publically accessible "stub" records which point them.
>
> Doing that allows the registrant to assume some control over the
> dissemination of their own data.
>
> The Registrant and the Registrar should each have a copy of the
> full record, modifications should be implemented concurrenltly on both
> sides (a helper application, for example, could detect and flag a website
> whose whois.xml is out of date with the Registrar/Registry's).
>
> Those Registrants that can't or won't make their own whois records
> available, the fallback can be to the Registrar (who may for example,
> only release the record if the remote whois.xml is unavailable).
>
> (Registrars should have access to any whois record, similar to the
> internal Registrars-only Whois call up here in .CA land.)
>
> This is conjunction with some extra fields below (i.e. proposed use)
> allow the Whois data to function a bit more actively, again, somewhat
> like P3P policies.
>
>
> 2. Revise the Data Elements attached to a record.
> =================================================
>
> There are a few obvious fields which can be added to the Whois
> records which enhance usable functionality of looking at a record.
>
> Some additional data elements allow for more flexibility in controlling
> the data set presented and to what end.
>
> For example, a field called "proposed use" we may decide that "personal"
> domain registrants are allowed to withold their phone, address and email
> data from their published whois.xml records.
>
> But a shadowy fraud site would not find this avenue useful for
> enacting fraud anonymously because things like web browsers would
> detect mismatches between the type of page one is on (a form asking
> for a credit card number) and the "proposed use" listed in the published
> whois.xml. Companies conducting ecommerce over the web would be best
> to use a more suitable "proposed use" or "current use" value which
> would have more comprehensive data requirements.
>
> Other possible fields could be: serial number, to track revisions
> to the data; abuse contact; whois reference, containing the pointer
> to Registrant whois.xml; PGP keyid; User defined; etc.
>
> Of course I don't have all the answers, but I just wanted to put this
> idea "out there". I don't know what is going to happen with Whois or
> whether I will have any involvement going forward. Its up to the RC
> if they want to nominate me again for any of the task forces.
>
> From my experience working on the whois-sc thus far I can state that
> I have utmost confidence in Tom Keller and that in any case he's
> probably a great choice to keep carrying the ball.
>
> Bruce Tonkin has been chairing the whois-sc thus far, I'm not sure
> what his involvement will be going forward. Will he continue to chair
> all 3 task forces? If so, he'll do a fine job, if not I would seriously
> recommend him as an appointee if his time allows or he is not otherwise
> conflicted by other appointments.
>
> -mark
>
> --
> Mark Jeftovic <markjr@xxxxxxxxxxx>
> Co-founder, easyDNS Technologies Inc.
> ph. +1-(416)-535-8672 ext 225
> fx. +1-(416)-535-0237
>





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