ICANN/GNSO GNSO Email List Archives

[registrars]


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

Re: [registrars] Whois Operational Point of Contact

  • To: Jay Westerdal <jwesterdal@xxxxxxxxxxxxx>
  • Subject: Re: [registrars] Whois Operational Point of Contact
  • From: Ross Rader <ross@xxxxxxxxxx>
  • Date: Tue, 29 Nov 2005 07:22:24 -0800
  • Cc: registrars@xxxxxxxxxxxxxx, gnso-dow123@xxxxxxxxxxxxxx
  • In-reply-to: <200511291104.jATB4bP16126@holiday.com.at.spry.com>
  • Organization: Tucows Research & Innovation
  • References: <200511291104.jATB4bP16126@holiday.com.at.spry.com>
  • Reply-to: ross@xxxxxxxxxx
  • Sender: owner-registrars@xxxxxxxxxxxxxx
  • User-agent: Thunderbird 1.5 (Windows/20051107)

As a general point, I think it would be helpful if we could discuss this proposal in practical, candid terms. You correctly point out that this proposal isn't a general consensus. It is simply to early for that. This isn't simply the views of large registrars though. I have discussed this proposal with many different parties - registrars large and small, resellers, registrants, registries and general internet users - all with many different interests. This document represents the consensus and interests of those that we have talked to.

One of the interesting aspects of those conversations was the discovery that those that tend to support this proposal are interested in helping prevent abuse of personal contact data and the whois system and to bring new utility to related applications. Those that don't support it fall in one of two camps - they either aren't completely informed about the subtler merits of the proposal or they are abusing the system in some way.

One of the aspects of this proposal will see the actual expiry date information (which aids data miners and renewal scammers) replaced with enhanced status information. i.e. instead of saying "This domain was registered on August 12, 2001", it will simply say "ACTIVE", "PENDING EXPIRY", "EXPIRED", and so on.

By enhancing the context of the status messaging, registrants, resellers, etc. we preserve the publicly accessible trouble-shooting and renewal tools but take some key assets away from the data miners, renewal scammers and other abusers.

Rather than using your valuable time to create a competing proposal, it would be more useful if you would work with us in making this one better. While there are some current points of misunderstanding, I am sure that there are ways that we can work together to bridge those gaps and work together on building a consensus proposal that we can take forward together.

Thanks for your input,

-ross

Jay Westerdal wrote:
Ross,
I think the proposal looks good, except I would stress that the expiration
date at the registry level should NOT be phased out or removed as your
current proposal calls for.

Your proposal of eliminating that expiration date field should be discussed
with domain registrants that have large portfolios. Further outreach is
needed to achieve a larger consensus driven approach to changing this data
element as it effects domain owners more then it does domain registrars.
Last time I publicly objected I had 6 or 7 registrars second my proposal to
keep the field. I heard nothing from you until this posting but I have not
seen any change in position or heard from you to discuss the issue since
then. So I am not sure your current proposal is consensus driven. I welcome
the opportunity to discuss with you the expiration date field later this
week.

Since the first mentioned of this idea on the list I have been discussing
the scenario of removing the expiration date with domain holders for the
last two months and I have found that domain holders are generally against
such an action. Meanwhile large registrars are for it and small registrars
are against it. It would seem registrants and small registrars disagree with
large registrars on this critical field. I would ask that input be sought
from owners of domains before this proposal goes further as well as the
smaller registrars, some of which are not so small actually.

Registrants could not stress enough that they use the expiration date field
daily. Domain Registrants rely on this date field to be uniform and the
registry output is the only place it can be found that is uniformly the
same. If this proposal got ratified as it stands registrars such as Schlund
and Melbourne IT are on the record for saying they would stop showing the
expiration date field altogether in their own registrar output!

This would leave registrants with no PUBLIC way to determine when to renew
their domain or when it expired. The impact on Registrants would be huge. No
hosting company, tech support, or advisor to the domain owner without direct
username and password of a particular domain could check the expiration
date. Even then it would not be as efficient because a person may have
domains are several registrars. I realize the problems Registrars face with
this field currently is that the Registry logic confuses registrants. If the
registries' 45 day grace expiration date confusion was cleared up there is
no sufficient grounds to remove the expiration date from the registry
output.

The additional argument that I have heard is that DROA or other like minded
organizations use this field to trick domain owners into transferring
registrars. With the quote, "It makes their scam look more real to have an
expiration date listed". This theory is not a well thought out, if a domain
owner is so easily tricked into switching and if DROA no longer had access
to the expiration date field then why would DROA not take the creation date
field and add the current year. Now the end user has no way to validate
expiration date publicly and the expiration guess would be right 85% of the
time, would the owner not be more likely to believe the scam now? Clearly it
is easier to trick customers if you take away information from them. The
registrant is more likely to believe this is their current registrar if you
have information they believed is to be private. I reject this whole
argument of hiding expiration date as a means to avoiding scams. Scams will
increase not decrease by the removal of this field. You can quote me on
that. The only solid argument for change is the 45 day issue with registry
display being off by a year after expiration.

I plan to submit a proposal to solve the expiration date confusion at the
registry output and leave the date there, if anyone would like to be
included in helping define such a proposal please email me and I will setup
a separate mailing list to discuss the issue. Perhaps we can informally meet
this week to discuss the issue offline as well. I welcome all to
collaborate, big registrars, small registrars, and domain owners.

Jay Westerdal
Name Intelligence, Inc.
http://www.nameintelligence.com
-----Original Message-----
From: owner-registrars@xxxxxxxxxxxxxx
[mailto:owner-registrars@xxxxxxxxxxxxxx] On Behalf Of Ross Rader
Sent: Monday, November 28, 2005 10:47 PM
To: registrars@xxxxxxxxxxxxxx
Cc: gnso-dow123@xxxxxxxxxxxxxx
Subject: [registrars] Whois Operational Point of Contact

Registrars,

In Mar del Plata, a small group of like-minded registrars got together to discuss possible solutions to the vexing problem of whois. The basic issue that the amount of data that ICANN requires registrars to display in the whois is facilitating all sorts of undesirable behaviors like renewal scams, data-mining, phishing, identity theft, and so on.

The result of this discussion is a proposal to rationalize the whois data output and implement a new contact type called the "Operational Point of Contact" or "oPOC". Complete details can be found in the proposal itself which I've posted to my weblog - http://code.byte.org/blog/_archives/2005/11/28/1426464.html

We are currently seeking feedback and support for this document. If you have any comments, please drop one of the contributors a note. If you would like to formally support this proposal as a signatory, please drop me a note saying so.

Thanks in advance, please let me know if you have any questions.

-ross





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