ICANN/GNSO GNSO Email List Archives

[registrars]


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

Re: [registrars] Ballot Request: Adopt as Constituency Position

  • Subject: Re: [registrars] Ballot Request: Adopt as Constituency Position
  • From: Ross Rader <ross@xxxxxxxxxx>
  • Date: Wed, 05 Oct 2005 10:24:10 -0400
  • Cc: registrars@xxxxxxxx
  • In-reply-to: <E1EMtR3-000Bii-VV@mail.momentous.ca>
  • Organization: Tucows Research & Innovation
  • References: <E1EMtR3-000Bii-VV@mail.momentous.ca>
  • Reply-to: ross@xxxxxxxxxx
  • Sender: owner-registrars@xxxxxxxxxxxxxx
  • User-agent: Thunderbird 1.4 (Windows/20050908)

Rob Hall wrote:

I see that we are moving away from publishing the Registrant address
information.  Can you give me some of the background on why this is a good
idea, especially as I believe it is defined in the transfer policy as one of
the possible authoritative figures to allow a transfer.

The proposal intends to streamline the data presented in the Whois, which will require adjustment to other policy. The requirement to include Registrant contact data has many privacy implications and it is much easier for us to collect and publish data for a representative of the registrant than it is to force the blanket collection and publication of Registrant data itself.


We also seem to be moving to the thin, distributed whois that .com has, when
all of the latest TLD's are moving in the opposite direction, to a
centralized whois.  Are we sure we want to go back to the old standard,
given the problems it has lent itself to ?  Should we not be moving more
towards the centralized, standardized version of whois that ICANN and many
other TLD's are moving towards ?

ICANN has made several mistakes with its policy over the years, the first of which is to over-centralize elements of an otherwise distributed system. The problems that you describe are best dealt with by making the distributed system more effective - scrapping it entirely is nonsense. There are also many legal issues associated with thick whois, the first of which is that registrant privacy rights should be different based on where you query the whois data - especially if one of those sources is non-authoritative.


From what I also read, I think you are proposing to remove the expiry date
of the domain from all published records.  I see you have "creation date" in
both the Registry and Registrar records, but no mention of Expiry date.  I
know from our experience, that our customers very often want to see this
expiry date on their record, as it is really the key date they care about.
It is actually the only date that they have to do something on or by.  I am
concerned about our removing it from view.  Can you perhaps shed some light
on why you are suggesting this, or was it just an oversight ?

The primary test that was applied to all data elements was its reasonableness for inclusion based on the purpose of the Whois system as stated by the document. No deference was given to any of the data based on its legacy status. Any data removed was simply found not to have a compelling reason for inclusion based on the stated purpose.


On the subject of handling of a report of inaccurate whois data, I think you
are suggesting that we only have to verify the email address for
correctness.

In instances where an inaccuracy has been reported and corrected data has been supplied, the registrar would needs to "test" the newly supplied email address before accepting the correction. In other words, registrars would no longer be able to blindly accept submitted corrections at face value - a test of reasonableness would need to be applied first.

You also suggest that the Registrant must "defend" the
accuracy of the data in a timely manner.  What do you envision as this
defence ?  Is it simply enough to write back saying "yes it is correct" ?

No, this was not the intent. Demonstrating the accuracy of the registration was the intent. i.e. responding to the inquiry from an email address matching that found in the Whois, providing drivers license details matching the Whois, etc. would all be sufficient to satisfy the "defense" requirement.

Does the Registrar have any obligation to check the information provided,
other than the email address ?

Not within this proposal, no.


And on part c) of the handling of innacurate data, you state that we MUST
put the name on hold if the Registrant does not update his information.  I
assume that you also mean that we would not have to put the name on hold if
the Registrant defended his information.  I think the way it is worded, we
would have to put the name on hold unless the Registrant provided new
information somehow, even though the existing might be correct.

The intent was that if the registrant did not *defend* or update the information, then the name must be put on hold. This could be made more clear in the document and I'd be happy to take a friendly amendment on this point...

In part a) of the handling of inaccurate data, you state that the Registrar
must notify the operational contact OR Registered name holder.  I gather
this implies that you intend to keep contact information for the Registered
name holder, even though you no longer plan to display it.  Will this not
lead to the possibility of the invisible Registrant data being correct, but
the published operational data being incorrect, but still be OK within this
framework ?

Yes - alternatively, the private data could also be incorrect and the public data correct :) In practice, this already occurs today - billing details are mostly private, and despite large-scale whois inaccuracy, registrars still seem to get paid :)

What must the user correct, the unpublished data, the
operational data, or other published contacts, including any additional,
voluntary ones.

The public data - the entire proposal is limited to data that we are required to publish within the Whois system itself.

Thank you in advance for taking the time to enlighten me on your thinking on
these matters.

My pleasure. I hope the added clarity leads to some formal support for the motion in the form of a second or two :)

-rwr



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