Re: [gnso-irtpc] Your input requested - Ideal Process Change of Control

[Paul Diaz <pdiaz@xxxxxxx>]

Apologies for not attending Tuesday's call.  I also won't be available for the 
24 April call, but hope that this input assists the WG's deliberations.

On Apr 20, 2012, at 3:06 AM, Marika Konings wrote:

Dear All,

In the Tuesday WG meeting, the 'Ideal Process' Sub-Team presented a first rough 
outline of a possible process for change of control (see attached). Everyone is 
encouraged to review this outline and share it with their respective 
stakeholder groups / constituencies for input, if deemed appropriate. In 
addition to general comments, there are a couple of specific issues the 
sub-team would like to receive input on. These are highlighted in the attached 
document as 'note' and include the following:

 *   Decide on terminology of the process (e.g. Change of control vs. change of 
registrant, losing / gaining registrant vs. old / new registrant)

When we mention "Change of Control" we're talking about modifying the 
registrant contact information while the domain name remains with the same 
sponsoring registrar, right?   If so, why are gTLD Registry Operators being 
considered in the process flows below?  Updating registrant contact information 
is a Registrar function/responsibility.  If a change of Registrar also occurs, 
then such a process is -- by definition -- a "transfer" and the IRTP rules 
apply.


 *   Clarify / define difference between AuthInfo code and FOA in order to 
determine whether one or both could also serve as credentials in the case of a 
change of control (does somebody have a definition for either one)

Per ICANN's own FAQs (see 
http://www.icann.org/en/resources/registrars/transfers/name-holder-faqs):

The AuthInfo Code is a unique code generated on a per-domain basis and is used 
for authorization or confirmation of a transfer request.  Some registrars offer 
facilities for you to generate and manage your own AuthInfo code.  In other 
cases, you will need to contact the registrar directly to obtain it.  The 
registrar must provide you with the AuthInfo code within 5 calendar days of 
your request.

The AuthInfo code is applicable to transfers of all gTLD names, with the 
exception of .gov, .edu, .mil, .museum, and .int names.

Any "credentialing" process must reside at the Registrar-level as they have the 
customer relationship and/or means of determining registration rights to a 
domain name under their management.  IMO, the current Form of Authorization 
(FOA) is not a "credential" but rather just an expression of interest that 
Registrars are supposed to use to demonstrate a user's intention ...after a 
genuine vetting process has already occurred.  In fact, ICANN only provides 
guidance on what the FOA should look like, and does not require a single form.


 *   Clarify role of 'thick' vs. 'thin' registry in relation to providing / 
setting AuthInfo code AND/OR being capable to verify authorization for a 
transfer (it is our understanding currently that each registry using EPP can 
use Auth Codes, regardless of being thick or thin – does anybody have 
information that would contradict this?)

While EPP clearly accommodates AuthInfo codes, the real question is what 
restrictions apply to the generation and acceptance of the actual codes?  The 
WG might want to consult an expert like VeriSign's Scott Hollenbeck.

Also, I hope a false distinction is not being made re: "thick" versus "thin" 
registries.  In either model all of the contact data is collected by the 
Registrar.  Hence, Registrars alone are capable of determining registration 
rights to a particular domain name to "verify authorization for a transfer" or 
approve a Change of Control request.  "Thick" registries just publish the 
contact data for all of the active domain names in their own Whois database, 
while "thin" registries just redirect Whois queries back to the Sponsoring 
Registrar.  A "thick" registry is not inherently more secure or more accurate 
re: its Whois data.


 *   Determine what can be used as transfer authorization credentials, the idea 
is that these will need to be produced and transmitted to the 
registry/registrar(?) by the new registrant (PIN, password, string, code, 
AuthInfo code) in order to prove that the previous registrant has given their 
consent to a transfer out

Just to confirm: gTLD Registry Operators are just links in the chain re: this 
proposed process as they have no means of "proving" (or disproving) that a user 
has registration rights to a particular domain name, correct?


 *   Who provides notification to old and new registrant – gaining registrar, 
registry? In the case of thin registries, should both registrars or only the 
gaining registrar make this determination (in case the change of control is 
combined with a change of registrar)

Again, gTLD Registry Operators would merely be a conduit here, right?  It's 
essential that the verification & approval process already have occurred at the 
Registrar level.


 *   Should this process be conducted with the same authorization credentials 
or separate ones from existing ones such as the AuthInfo code, or should a 
combined model be explored?

The WG must focus on defining standards for Registrars to use when 
"credentialing" users with valid registration rights.  Only Registrars are 
positioned to make such determinations.


Your comments would be appreciated ahead of next week's IRTP Part C WG meeting.

Thanks,

Marika
<IRTP -- Ideal Process v4.pdf>