[gnso-impl-irtpc-rt] IRTPC CORP and spam reduction measurements.

[Theo Geurts <theo.geurts@xxxxxxxxxxxx>]

Hi all, 

I think we need to take a few steps back when it comes to the drafted language 
here when it comes to the change of registrant procedure, unless i am proven 
wrong. 

There are several registrars that offer spam reduction measurements by having a 
unique email address listed in the whois, usually in conjuction with the domain 
name that gets changed when there is a whois lookup or set a certain interval. 
This service is not only related to P/P services but also offered as a paid or 
non paid service to reduce spam by Registrars. 

If a change of the email address remains a material change then we are actually 
throwing above services under the bus here, or at a bare minimum create alot of 
overhead for the registrants and there is potential abuse lying around the 
corner. Personally i would not be able to sell an ICANN policy that plays into 
the hands of spammers and potentially increases spam. That would look very bad 
in my eyes and some folks would love to spin this and it will not be in favor 
of ICANN and the WG. 

Few options here to address the issue. 
Go back to the GNSO regarding the material change, i totally do NOT favor that 
option. 

Or throw some services under the bus that we know that are out there with the 
risk of throwing other services under the bus we did not identify yet, but 
heavilly rely on changing the email address for certain reasons or other data 
that is considered a material change. Full disclosure, the Registrar i work for 
does offer any of those services. 

Or remove the entire exchange of credentials part and go for a notification 
only procedure if there is a material change. This was discussed in December 
last year and i had the impression that was in scope of the recommendations of 
the WG. This would be in my opinion the best move and then we addressed alot of 
comments and we should be able to wrap this one up real quick as the rest of 
the policy is fine and mostly issue free. 

The above solution would also address the designated agent potential issues, I 
have not dived into that one, but I am sure we will run into issues with that 
one and lose alot of time again as parts need to be re-written. 

Thoughts ? 

Theo Geurts 

Realtime Register B.V. 

Ceintuurbaan 32A 
8024 AA - ZWOLLE - The Netherlands 

T: +31.384530759 
F: +31.384524734 
U: www.realtimeregister.com 
E: support@xxxxxxxxxxxxxxxxxxxx