Re: Implementation of EPP AuthInfo
Michele Neylon :: Blacknight <michele <at> blacknight.com>
2013-05-07 08:44:35 GMT
On 7 May 2013, at 07:51, Vlad Dinculescu <sasha <at> dnservices.co.za> wrote:
> Hi Francisco,
> Thanks for the reply, please see responses inline below.
> On 07 May 2013, at 8:33 AM, Francisco Obispo <fobispo <at> isc.org> wrote:
>> Hi Vlad,
>> What are the problems you're trying to address with these measures?
> Simply put, we are attempting to avoid registrars performing updates on Contact information that are not
authorised or requested by the Contact.
> We have found that "bringing out the big stick" doesn't work effectively, so now we are attempting to put
the decision making where it belongs, in the hands of the registrant.
If you're having issues with some of your registrars then you need to address that via the contract you have
Penalising all registrars by creating more work for them and their developers doesn't seem rational to me
>> Some thoughts below:
>> On May 6, 2013, at 11:23 PM, Vlad Dinculescu <sasha <at> dnservices.co.za> wrote:
>>> Please share your thoughts regarding the implementation of the Contact AuthInfo for the approval of
initiated contact updates.
>>> Our current process looks to have the registrant provide the code as an indication of approval
regarding the update of their information, completing the update instantly. Updates that are not
provided with the code will not execute.
>> Do you want to accept an update from a non-sponsoring registrar?
>> If that's not the case, the AuthInfo will be available to the sponsoring registrar anyway.
> We did identify this issue as well, knowing that the sponsoring registrar would have access to the code.
> Does an implementation exist where the AuthInfo is used as an out-of-band means of authorisation from the registrant.
>>> Further to this, we are looking to implement the Domain AuthInfo code as a definite measure for
approving registrant changes to a linked domain. In this instance the current registrant must provide
the Domain AuthInfo code as approval of the registrant change.
>> Same as above, but in addition, a contact object can be independently updated regardless if its used in a
domain name or not, so the restriction will only have effect if you 'replace' the registrant with other ID,
but not if you change the contact underlying data.
> In this instance we are looking at the replacement of the associated domain registrant ID with a different
one. This is a domain update where the current registrant can use the associated domain AuthInfo to
approve the change of the registrant ID to a different one.
>>> Vlad Dinculescu
>>> Domain Name Services
>>> provreg mailing list
>>> provreg <at> ietf.org
>> Francisco Obispo
>> Director of Applications and Services - ISC
>> email: fobispo <at> isc.org
>> Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
>> PGP KeyID = B38DB1BE
> provreg mailing list
> provreg <at> ietf.org
Mr Michele Neylon
Blacknight Solutions ♞
Hosting & Domains
ICANN Accredited Registrar
Intl. +353 (0) 59 9183072
Locall: 1850 929 929
Direct Dial: +353 (0)59 9183090
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,Ireland Company No.: 370845
provreg mailing list
provreg <at> ietf.org