<DIV>Ross,</DIV>
<DIV> </DIV>
<DIV>I understand your concerns about section 4. But I am more concerned
with the removal of the registry whois create and
expiry dates. I know it's been previously debated but after a
lot of thought I am not convinced it is a good idea.</DIV>
<DIV> </DIV>
<DIV>Our experience has been that a number of registrants use that
information as part of their name management. The reason may be that
the registry whois is more reliable, easier to query, whatever. And as
you know, there are a number of popular software products and web
based services that are available for name management, or that provide
other services, that rely on the registry Whois. These will all
become broken once the dates are removed from the registry
Whois.<BR></DIV>
<DIV>One registrant use for that information that I think has merit
is keeping the registrar honest so to speak. Many registrants know that
what may appear in the registrar whois does not necessarily reflect
what has actually taken place. For example, if you pay for a multi-year
renewal is the registrar putting them through one year at a time, or all
together? </DIV>
<DIV> </DIV>
<DIV>Registrars may also use that information in legitimate ways to
make transfers less problematic for their customers, but I'll admit that
this is a convenience not a necessity. Still, it should be
given some consideration.</DIV>
<DIV> </DIV>
<DIV>I think that if the OPoC concept does become policy, some time
needs to be given to see how it works, how it is enforced, how it is
received by registrants, etc. Then we can consider taking it further by
removing the dates from the registry if it becomes necessary. But to
remove these dates at the same time as the implementation of the OPoC
concept will just serve to further confuse registrants, software
developers, and web service providers who have relied on that
data for lawful purposes.</DIV>
<DIV> </DIV>
<DIV>I am aware of two arguments for removing it from the
registry whois. </DIV>
<DIV> </DIV>
<DIV>1. Renewal slamming. But as I've said in the past, removing the
registry dates is not the real solution to this problem. The bad
guys are going to find a way, especially since the worse offenders are
often registrars themselves. </DIV>
<DIV> </DIV>
<DIV>2. The inconsistent expiry dates between registrars and registries
due to the autorenew grace period. This can be fixed without
removing the dates, and perhaps a solution could be included as at
least advice in the OPoC proposal. I'd be happy to offer a possible
solution for discussion, and I am sure others would as well.</DIV>
<DIV> </DIV>
<DIV><BR>Tim <BR></DIV>
<DIV id=wmMessageComp name="wmMessageComp"><BR><BR>
<BLOCKQUOTE style="PADDING-LEFT: 8px; MARGIN-LEFT: 8px; BORDER-LEFT:
blue 2px solid">-------- Original Message --------<BR>Subject: Re:
[registrars] OPOC Proposal<BR>From: Ross Rader
<ross@tucows.com><BR>Date: Thu, September 21, 2006 7:20 am<BR>To:
ross@tucows.com<BR>Cc: Registrars Constituency
<registrars@gnso.icann.org><BR><BR>Ross Rader wrote:<BR>> Your
feedback on this iteration of the Whois Operational Point of <BR>>
Contact proposal would be appreciated:<BR>> <BR>>
http://www.writely.com/Doc.aspx?id=dgsxrsww_2gjfj37<BR>> <BR>>
There are some newly proposed additions that I've boxed out with
<BR>> [PROPOSED:] - your feedback on the notice requirements would
be <BR>> especially helpful...<BR><BR>Apologies, I forwarded a link
to an older revision, here is the correct
<BR>link:<BR><BR>http://www.writely.com/View.aspx?docID=dgsxrsww_2gjfj37&revision=_latest<BR><BR>My
personal concerns lie primarily with section 4 in that they require
<BR>registrars to expose registrants to a level of detail that might
<BR>otherwise be made transparent in various registrar business models.
I <BR>have deep concerns that ICANN's policies are interfering more and
more <BR>in the business of registration, and less and less with the
DNS. Domain <BR>name registration has been made significantly more
complex in the last <BR>four years, with very little apparent benefit
for registrants.<BR><BR>-r </BLOCKQUOTE></DIV>