ICANN/DNSO
DNSO Mailling lists archives

[registrars]


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

[registrars] Important Issues - Please Read


Hello All:

I apologize for not responding sooner but I was away on travel the past two
days and I did not have access to email. Let me take this time to address
some important issues.

Nomination of Bret Fausset:

As Nikolaj properly noted, Bret Fausset should be provided the opportunity
to be nominated as a candidate as the nomination period was scheduled to
close on the 21st. The Executive Committee has been a little short handed
with the pending resignations of Bryan and Tim. I remember now why I did run
for the secretariat position again. I see no valid reason to exclude Bret
from submitting a qualification statement and participating in the
nomination review process.


Registrar Scheduled Call:

There appears to be a potential conflict between PIR and the Registrar
Constituency teleconference. Given that Richard will not be able to
participate because of his illness and we have not yet been able to contact
Bret Fausset, and that PIR will be discussing last minute items involving
the transition of 2.5 million .org domain name between backend registry
providers this week, we may want to consider delaying this teleconference. I
think I suggested this change in timing after Ken Stubbs raised this issue
during the Executive Committee on Monday. At a minimum, we should schedule
an additional call.


IDN Representatives:

There seems to have been some constructive traffic on the list regarding the
IDN representatives. As usual an elected representative to any task force,
is required to conduct outreach within the constituency before advancing any
specific viewpoint/position. Notwithstanding Neteka's potential conflict of
interest as IDN solution provider, I am sure we can rely on these
representatives to advocate the registrar position, whatever, that may
ultimately be. If any registrar believes that this is not the case please
bring it to the attention of the Executive Committee or the Constituency at
large.


.US Whois Policy Proposal:

The designated Registrar representative on the .US Policy Council is
BulkRegister. David and I serve on the committee but were selected because
of other qualifications. I believe David provided a link to the Policy
Council's web site. Rick and Ross appeared to raise some concern with their
posts although I was not able to identify their specific concerns.

I would like to share with you my viewpoints of why the .US Whois proposal
is much better than some other proposed alternatives. Although I believe
that false and inaccurate data must be identified and corrected, there are
two schools of thoughts on how best to achieve this objective. I advocate a
position where registrars must take affirmative action to remedy false
and/or potentially inaccurate after being notified. I believe the current 15
day contractual requirement in the .US and ICANN contracts to be overly
restrictive, and as such innocent domain name registrants might lose their
domain names. That is why I advocated doubling the time frame to 30 days.
Moreover, in order to prevent against potential abuses of the system,
complaints are required to acknowledge that the submission is not intended
to interfere with the lawful operations of the domain name registrant or
registrar.

I spoke with a number of registrars today on the issue and here are the
concerns that they raised.

Issue #1 - What safeguard is there to prevent against abusive repetitive
reporting. When I last spoke to Dan Halloran I believe ICANN was looking to
add some additional categories in the docketing system to allow registrars
to close out tickets. I believe that an option to close out a ticket,
because of a "repetitive and frivolous" complaint seems like a logical
addition if it has not already been added. I think this is a good suggestion
and one which was expected to be flushed out during the public comment
period. Neustar is exploring the possibility of using ICANN's existing
software to assist registrars in this program.

Issue #2 - How is "verified" defined. It was not specifically defined on
purpose. How a registrar verifies whois data is open to numerous
possibilities some of them automated and others manual. One automated
process that comes to mind is an automated email that I recently received
from VeriSign asking me to verify that the Whois information contained in
the email was accurate. Having the registrant hit the reply button to
confirm the accuracy of the email is one possibility. This solution seems
more suited for a larger registrar. A small registrar may just want to call
the registrant and verify the information over the phone, via email or fax.

Issue #3 - How is "documented" proof defined. It also was not specifically
defined. This higher burden is for a second complaint on a domain name. A
faxed photocopy of a government issued ID, a copy of a bill, credit card
address verification, are just some ideas that might be viable. The purpose
here was to show that the registrar was not just letting the registrant
change the whois, from Mickey Mouse, to Donald Duck to Minnie Mouse.

I think these issues were contemplated being raised during the public
comment period and hammered out. If there are other concerns that I missed
please bring them to my attention.

Turning to the second school of thought on inaccurate Whois data, I would
encourage registrars to read the ICANN Security and Stability Committee that
recently release a report of which Rick Wesson, our CTO was a principle
author. This report proposes the following recommendations, see
http://www.icann.org/committees/security/whois-recommendation-01dec02.htm :

- The accuracy of Whois data must be improved, both at the time of its
initial registration and at regular intervals. Whois records known to be
false or inaccurate, or to have information that can not be validated, must
be frozen or held until they can be updated or removed.
- A standard format for Whois data must be developed.
- Whois data must contain a "Last Verified Date" that reflects the last
point in time at which the information was known to contain valid data. It
must also contain a reference to the data verification process.
- A Whois service that supports searching in the current architecture of
distributed indices and separated registry and registrar services must be
developed.
- A publicly available list of publicly available Whois servers must be
available using a widely known and available resource, e.g., a web page or
DNS SRV records.
- Whois services must provide mechanisms to protect the privacy of
registrants.
- A Whois service must discourage the harvesting and mining of its data.

Please note that my proposal only had registrars "verifying" data when a
complaint was received, the ICANN Security and Stability Committee proposes
verifying each record at registration and renewal. In addition this proposal
will require registrars to potentially invest significant resources to
modify the Whois to account for the "Last Verified Date" and "Verification
Process".

I believe that when you look between these two proposals, my proposal is the
lesser of two evils. Regardless of the current practices of today, the
burden on registrars to verify and correct inaccurate data is not going to
lessen. That is why I believe advocating a proactive manageable solution is
much better than having a restrictive, cost prohibitive, and potentially
ineffective solution mandated upon us.


Washington Meeting:

Bob Connelly has identified a potential meeting location in DC for our
Friday meeting. The FTC meeting is currently scheduled to be held at their
DC offices which I believe are located on 600 Pennsylvania Ave.


Miscellaneous:

I have a legal conference that I am speaking at today. Hopefully I will have
final arrangements for the DC meeting by then. I apologize for the delays
but the shrinking Executive Committee has made things a bit difficult.
Anyone needs be call me on my cell.


Best regards,

Michael D. Palage








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