<<<
Chronological Index
>>> <<<
Thread Index
>>>
Re: [gnso-irtpc] Your input requested - Ideal Process Change of Control
- To: Marika Konings <marika.konings@xxxxxxxxx>
- Subject: Re: [gnso-irtpc] Your input requested - Ideal Process Change of Control
- From: "Michele Neylon :: Blacknight" <michele@xxxxxxxxxxxxx>
- Date: Mon, 30 Apr 2012 12:50:35 +0000
See answers / comments below
On 30 Apr 2012, at 08:54, Marika Konings wrote:
<snip>
> 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)
> [Based on yesterday's WG meeting, there seems to be a preference to use
> 'change of registrant' and 'prior' and 'new' registrant', noting that there
> would be a need to describe these terms in further detail in the actual
> policy / rules]
Sounds good to me
> • 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) [See
> also Mikey's email in relation to this issue -
> http://forum.icann.org/lists/gnso-irtpc/msg00212.html]
I don't think we should mix things up. The AuthInfo and FOA are for
inter-registrar transfers and repurposing them is going to cause more headaches
than it will resolve
> • 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?) [See also Paul's email in relation
> to this issue - http://forum.icann.org/lists/gnso-irtpc/msg00211.html]
I think this confusion is partially my fault. All of the "change of control"
scenarios that currently work do so because the registries are both "thick" and
also have some kind of relationship with the registrant. That isn't really the
case with gTLDs, with the possible exception of community / sponsored TLDs.
To confirm - all gTLD registry systems use EPP authcodes. You actually cannot
register a domain without generating an authcode at the same time. It's not
simply a matter of registries being able to use it - they've no choice and
registrars have to set them when registering a domain.
> • 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
The process should be handled by the registrar - not the registry. The registry
cannot validate the registrant, as they don't have access to the data nor would
it be their role to do so, with the exception of sponsored / community TLDs
where "membership" or "eligibility" might be needed
> • Who provides notification to old and new registrant – gaining registrar,
> registry?
The registry should not be involved.
> 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)
Registrars or registrants?
There shouldn't be a change of control at exactly the same time. It might be
possible in a future, but I just see it causes more headaches at the moment
> • 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? [See also Mikey's email in relation to
> this issue - http://forum.icann.org/lists/gnso-irtpc/msg00212.html]
See my reply above
<snip>
Regards
Michele
Mr Michele Neylon
Blacknight Solutions ♞
Hosting & Colocation, Brand Protection
ICANN Accredited Registrar
http://www.blacknight.com/
http://blog.blacknight.com/
http://blacknight.biz
http://mneylon.tel
Intl. +353 (0) 59 9183072
US: 213-233-1612
Locall: 1850 929 929
Direct Dial: +353 (0)59 9183090
Facebook: http://fb.me/blacknight
Twitter: http://twitter.com/mneylon
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,Ireland Company No.: 370845
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|