[gnso-impl-irtpc-rt] Follow-up from Implementation Review Team Call

[Theo Geurts]

A few quick comments. 

3.2(a) is the part where the registrar gets consent and i assume the non consent if that is the case ? 

Regarding the notifications mentioned in 3.2(b) 
(iii) If consent was given in 3.2(a), then (iii) might throw a wrench into the process when the new registrant has not entered into agreement and forgets or refuses. The text in (i) sets a 24 hours window. And in my opinion this adds a layer of complexity. 

Same goes for (iv) and (v) and (vi). These shouldn't be in all cases part of a notification process. To ensure flexibillity i would suggest to rewrite 3.2 completly and make them a directive. Then a Registrar can determine based on it's business model and operational implementation to decide what goes where during the change of registrant process. 

To be clear, I am not suggesting the notifications should not be removed and or any of the above sections. It should part of a directive. And perhaps directive is the wrong word/term here, I am simply trying to find some balance here and I am aware this also affects parts of 3.1. 

As this was section was removed :" The Registrar should not provide the Change of Registrant Credential to the Account Holder unless the Account Holder and Prior Registrant are the same. In the event the Prior Registrant can no longer access its email address, phone number or address, the Registrar would not be limited to use of contact information on file in providing the Change of Registrant Credential". 

The reason for removing it is clear to me as the credential part is now part of the secure mechanism definition. However what we have created here is the situation that under all circumstances, provided it is a material change, triggers the change of registrant process. So the balance we tried to achieve a few months ago is gone, as you can no longer login to your registrar account to correct an email address. So we might want to circle back on this during the next call. 

Regarding the issue I brought up during the last call when it comes to privacy protect providers and or registrars offering spam reduction solutions. A Designated Agent could indeed be the solution. This would be part of the terms and conditions set by those agents between them and the registrants, read pre authorise. 
We need to come up with a solution regarding the notifications as part of the current procedure. As I can imagine that in certain specific situations you want to skip the notification part as updating the email address might be part of an automatic procedure and will generate alot of notifications and create confusion. 

I think with the above and Bob's comments from the last call we have a starting point to explore this designated agent role more. I think the process for Registrars should be low profile yet accountable. If we start to define the role too deep we will create a can of worms here with questions like, how long is the pre authorisation period etc etc. I don't think we should head that direction. 

Best 

Theo 


Van: "Caitlin Tubergen" <caitlin.tubergen at icann.org> 
Aan: gnso-impl-irtpc-rt at icann.org, "Bob Mountain" <bmountain at godaddy.com> 
Verzonden: Vrijdag 10 juli 2015 00:49:11 
Onderwerp: [gnso-impl-irtpc-rt] Follow-up from Implementation Review Team Call 

Hi, Team. 

Please save the date for our next Implementation Review Team call on Thursday, 16 July at 1600UTC . 

For the recording of today’s call, please use the following link: https://icann.adobeconnect.com/p5l1f520ora/ 

I have attached the draft policy that we discussed during today’s call. A few of you mentioned that you would like to further tweak some sections, namely the definition of designated agent in 1(d) of the policy and the circumstances described in section 2.3. Please feel free to propose any edits on the list. If you would like one additional week, please let me know, and we can postpone next week’s call by one week (Thursday, 23 July). 

Thank you, all, for your participation today — it was very helpful! 

Kind regards, 

Caitlin 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-impl-irtpc-rt/attachments/20150713/f29dbeed/attachment.html>