Steve Miholovich mentioned autorenewal as an issue which many customers had. How to validate on autorenewal, and at what point should the registrant validate on autorenewal? How would notices be implemented prior to expiry date.

Bruce Tonkin replied that validation does not have to be tied to the instant of autorenewal. A check should be done regularly.

Bruce Tonkin stated that a domain name could be used maliciously if the data is accurate or inaccurate and the accuracy provisions could be used as a back door for malicious use of the domain name. A real e-mail address does not give information as to who the person is and leaves all sorts of ways for a spammer to gain the system.
It was thus suggested to remove the part of the recommendation pertaining to dispute resolutions.
Recommendation 3 -
removal of dispute process, removal of the specific time-limit, a requirement that a registrar require justification of a new address is it fails automated checks (which MAY be documentary evidence), and a requirement that after a name is put on HOLD status, that it may not be returned to active status until the registrar has confirmed that the registrant is contactable.
- a separate recommendation regarding the time limit - to decouple from recommendation 3

Ken Stubbs proposed a stratified approach to protect the registrar from liability.
Discussion followed on verification of data from an e-mail and a postal address. Postal address verification was considered to be burdensome to the registrar and entailed additional costs. Requiring that the registrant pay, imposes the burden of collecting these costs on the registrar. Much would depend on the volume of such requests whether it could be done on a manual basis and whether it could be on a cost recovery basis.
Bruce Tonkin's suggested alternative was to have an automated process, also relying on the registrant's good faith.

Bruce Tonkin suggested that the dispute resolution statement should be dropped.
AGREED by all members on the call

On the point of Registrar Hold, Bruce Tonkin said that the only way to get it off Registrar Hold was to update the contact details. The registrant would respond to a new massage that would come to the Registrar via a new e-mail address that would prove the person is contactable, but it would not necessarily say whether the postal address is correct.
Elana Broitman asked if the details are confirmed, if the message comes back, what is the proactive responsibility on the registrar, to which Bruce Tonkin said commercially reasonable steps. These may however vary from country to country.
Steve Metalitz from the task force suggested that if the data is implausible, it should be put on registrar hold unless the registrar can obtain and review documentation verification, at which point a human being should be involved.

Steve Miholovich felt that the registrant should have the benefit of the doubt and that the plausibility check not be used for registrar hold.
Bruce Tonkin said that there should be another policy for malicious domain name use, rather than involve accuracy. An independent mechanism is needed that defines what is malicious, and then the name can be taken down. The issue is cost of accuracy to the registrars versus malicious domain name use.

Time line and reports

Bruce Tonkin said that he would do another draft, put it out for comment for 24 hours, before he sent it the Council as the process had to be finished before the end of January.
Thomas Roessler said that there was convergence with the task force, except on the 15 day versus 30 days suggested by the implementation committee.
Steve Metalitz said that 30 days meant the inaccurate data would stay in the system longer and that it was hard to accept as a process for a task force looking at accuracy.
Bruce Tonkin maintained that the registrars and registries would not move on the 30 day period, and there was now a formal process around inaccurate data which is an improvement. Registrars can contact registrants in a defined process.
The next step would be to look at the malicious domain name use.
Thomas Roessler mentioned that the key issue was involving judgment on content. ICANN's strength, up to now has been that it has not been involved in judging content.

Bruce Tonkin mapped out the consensus process:
- the WHOIS Task Force has made recommendations,
- the Whois implementation committee has proposed alternate suggestions and implementation issues.
- Council members could decide to put the WHOIS recommendations as they are to the vote
or
- Council could put alternate recommendations suggested by the implementation committee up to the vote.

The definition of Consensus policy:
- Show consensus and show the Council vote on the consensus
In the task Force there is no consensus thus even if the council voted, it would not meet the consensus policy requirements.
The sections where consensus has been shown:
- marketing
- updating data at regular intervals

Thomas Roessler suggested redrafting the redemption grace period text which was policy, but he process was not, suggesting that process moved to practical advice and Bruce Tonkin suggested that the time period be defined as in the Registrars Accreditation Agreement.
Ken Stubbs expressed concern that "studying an approach" led to procrastination and that in all processes the registrars had to write codes and operational procedures, so it should not be put off for too long.

Bruce Tonkin summed up and said the task force was concerned about malicious data staying in the system for 30 days if the period of time was extended from 15 to 30, while Steve Metalitz said documented proof of 30 days would be required to satisfy the task force.
Bruce Tonkin went on to say that there was an overall improvement coming from the automated process, the registrant is contacted, the name put on hold is more desirable than delete, there are commercially reasonable steps to check and in general there is greater registrar involvement in the process.

Bruce Tonkin thanked everyone for their participation.

The call ended at 22:30 Thursday 30, CET, 8:30 Friday 31, Melbourne

Information from:

© GNSO Council