RE: [registrars] Important Issues - Please Read

["Ross Wm. Rader" <ross@tucows.com>]

> 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.

Nor has anyone asked us what those concerns are - which is a big part of
the problem. We're running a business here just like everyone else.
Typically when suppliers are thinking about changing the nature of their
relationship with their customers they tend to consult with their
customers. As far as I can tell, this isn't happening in this case to
any degree that we would be comfortable with. Were it not for a chance
post to a mailing list, our organization probably wouldn't have heard a
thing about how Neulevel is changing the rules until it had already
happened.

I would hope in the future that one of the registrars on the council, or
more appropriately, someone at Neulevel HQ, give their customers a
heads-up that changes of this ilk are coming down the pipe. A big part
of running a strong business lies with the organizations capability to
provide straight answers to tough questions when they are asked. We
can't do this if our suppliers are playing shell games with the rules.



                     -rwr




Got Blog? http://www.byte.org/blog

"People demand freedom of speech as a compensation for the freedom of
thought which they seldom use."
 - Soren Kierkegaard



                       -rwr




"There's a fine line between fishing and standing on the shore like an
idiot."
- Steven Wright

Get Blog... http://www.byte.org/blog


 

> -----Original Message-----
> From: owner-registrars@dnso.org 
> [mailto:owner-registrars@dnso.org] On Behalf Of Michael D. Palage
> Sent: Thursday, January 23, 2003 3:15 AM
> To: registrars@dnso.org
> Subject: [registrars] Important Issues - Please Read
> Importance: High
> 
> 
> 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
> 
> 
> 
> 
> 
>