Summary of Comments in Public Comment Forum - Inter-Registrar Transfer Policy (Initial Report)

[Marika Konings <marika.konings@xxxxxxxxx>]

This summary is not a full and complete recitation of the relevant comments 
received. It is an attempt to capture in broad terms the nature and scope of 
the comments. This summary has been prepared in an effort to highlight key 
elements of these submissions in an abbreviated format, not to replace them. 
Every effort has been made to avoid mischaracterizations and to present fairly 
the views provided.  Any failure to do so is unintentional. The comments may be 
viewed in their entirety at http://forum.icann.org/lists/irtp-initial-report/.

Summary and analysis of public comments for:

Inter-Registrar Transfer Policy (Initial Report)

Comment period ended: 30 January 2009

Summary published: 3 February 2009

Prepared by: Marika Konings, Policy Director

The comment period ran from 9 January 2008 to 30 January 2009. Four comments 
were received of which three commented on the Initial Report (Patrick Mevzek, 
Barbara Steele on behalf of VeriSign and Clarke Walton on behalf of the 
Registrar Constituency). The other comment (from Thom Baird) related to a 
problem with the transfer of a particular domain name. The public comments on 
this forum are archived at http://forum.icann.org/lists/irtp-initial-report/.

Summary

Patrick Mevzek submitted his comments as an individual generic Internet user, 
owner of some domain names for personal and business needs, a founder of a 
company working with ICANN registries, registrars, and domain name providers, a 
participant in IETF Working groups related to EPP & IRIS and creator of 
software implementing both EPP and IRIS. Mevzek provided comments on all three 
issues outlined in the Initial Report. As a general comment he noted that there 
is a 'need to find a middle ground between the ease of transfer to make sure no 
arbitrary registrar locking can take place on the one side and on the other 
side enough guarantees that only legitimate transfer requests happen and 
succeed. He questioned whether sufficient data currently exists to assess 
which, if any, problems exist with the current transfer policy and noted that 
other data on transfers might be helpful 'so that policy procedures and 
energies can be properly spent depending on hard facts'. Nevertheless, he 
considers improvements welcome as long as the current situation is taken into 
account 'before providing too much new requirements in policies or new software 
developments'.

In relation to issue I, the potential exchange of registrant e-mail 
information, Mevzek comments that he does not support the idea of the poll 
mechanism of EPP to be used to transfer messages between registrars. He noted 
that 'it was not intended this way in the protocol'. He also highlights that if 
the current EPP system would be used for this purpose a number of 'security and 
denial of services potential problems' might emerge, 'not even thinking about 
the new specifications that would needed to be written, [and] then the new 
software development at both registries and registrars!'. In Mevzek's view, 
IRIS would be the most appropriate solution for transmitting data between 
registrars and/or registries in a secure manner, including traceability and 
authentication. Mevzek does note that this would imply that every registrar 
would need an IRIS server, which might be an unrealistic goal. Instead, he 
notes that 'a shortcut could be achieved in thick registries, as only a 
registry IRIS server would be needed, available only to registrars'. He also 
notes that costs and time to implement a new technique should not act as a 
deterrent if no other means are available to address a problem. On the 
registrant vs. admin approval issue, Mevzek notes that in his view 'both 
parties should remain involved in the process, they should have the same rights 
regarding initiating, confirming or declining a transfer'. On the AuthInfo 
code, he does not think it would make sense to 'add this new requirement of 
authinfo code to the older one'. In addition to commenting on the different 
options discussed by the Working Group, Mevzek puts forward a number of ideas 
for consideration by the Working Group:


 *   'The EPP protocol has a domain:info operation which reveals all data 
related to the domain, including the contact IDs of the registrant. This 
operation accept[s] an authInfo code, the idea being that if the registrar 
doing it is not the current sponsoring registrar of the domain name, it might 
still get information on it if it has the proper authInfo code'. He does note 
that this would require a policy change as currently 'some registries allow 
domain:info done by all registrars and some do not'. He goes on noting that 
'the contact:info operation works basically the same way [...] with an optional 
AuthInfo', but a small issue might be that this is a different AuthInfo code 
than the one used in the domain:info operation. According to Mevzek, this issue 
could be resolved in a number of ways such as disclosure of the contact 
AuthInfo, change of contacts and changing the AuthInfo structure for the 
contact. He notes that this option would 'need only minor technical 
specification [...] and very little changes in current software both on 
registrar and registry sides'.
 *   'The transfer policy could be simplified a lot and at the same time this 
issue could be resolved if the policy is changed so that it requires only the 
AuthInfo code to start the transfer, removing the contacts email handling. The 
current sponsoring registrar would still be allowed to notify contacts and 
would be allowed to stop the transfer if one of the contacts says so'. Mevzek 
notes that he does not understand the concern raised by the Working Group in 
this regard as not being a 'secure and viable solution compared to the current 
system'.

This last solution has Mevzek's preference. However, he indicates that if such 
a change in policy would not be possible, he would 'recommend working on making 
the registrant contact a same class citizen as the administrative one and maybe 
taking it out of the equation [...] and at the same time working either on IRIS 
and/or EPP [...] to see how exchanges of email addresses could be made simpler 
or exchanged for other authentication, based on the current authInfo'.

On issue II, the potential need for other options for electronic 
authentication, Mevzek wonders why emails 'are still used as primarily token of 
authentication during domain transfers, in contrast of using the more secure 
AuthInfo one'. He highlights a number of ideas such as protection of email by 
openPGP and/or S/MIME and access to a website using SSL certification as 
options to could be explored. However, he does emphasize that he does not think 
that 'the GNSO/ICANN should start defining these mechanisms [...] that would 
apply uniformly to each registrar'. In his view, it should be up to registrars 
to decide 'if they want to use other methods of authentication, and which 
ones'. As a suggestion, he proposes that ICANN 'could monitor which mechanisms 
are used by registrars and verify they meet some requirements'.

On issue III, the potential need for provisions for handling partial bulk 
transfers between registrars, Mevzek again notes that it would be helpful to 
have further data on this issue to guide the discussion. After having reviewed 
the different scenarios outlined by the Working Group, he agrees with its 
conclusion that 'there is no need to incorporate provisions for handling 
partial bulk transfers between registrars at this stage'.

Barbara Steele submitted her comments on the three issues on behalf of VeriSign 
to the public comment forum. On issue I, the potential need for exchange of 
registrant email information between registrars, VeriSign notes that 'the 
majority of Registry Operators that maintain thick Whois information are 
contractually required to make the registrant e-mail address publicly 
available'. It recommends that 'further discussion should occur to determine 
why this is a requirement for some thick Registry Operators but not all and it 
is not a requirement for any Registrars'. VeriSign expresses concern in 
relation to the time and costs of the different options discussed by the 
Working Group. VeriSign comments that it does not consider any future 
discussion on a potential policy change which would prevent the registrant from 
reversing a transfer appropriate as it 'could make it easier for a domain name 
to be hi-jacked'.

On issue II, the potential need for other options for electronic 
authentication, VeriSign notes that other options for electronic authentication 
'may be helpful', but that it 'should be left up to the registrar to choose 
whether or not to provide as a part of its offering'.

On issue III, the potential need for provisions for handling partial bulk 
transfers between registrars, VeriSign 'agrees that market solutions should be 
the preferred method for addressing this issue'.

Clarke Walton submitted the position of the Registrar Constituency (RC) to the 
public comment forum. It should be noted that due to time constraints, no 
formal vote was taking on this position paper by the RC. In comparison to the 
position submitted on 3 October 2008, which is also included in the Initial 
Report, the position paper notes that RC has only revised its view on Issue III 
in response to the conclusions reached by the Working Group in its Initial 
Report.

On issue I, the potential exchange of registrant email information between 
registrars, the RC 'believes that regulatory intervention is not necessary to 
address this issue' as it is 'more appropriate for market based solutions'. The 
RC does recommend further consideration of the issue of the Registrant's 
authority to overrule the Admin contact in future IRTP PDPs.

On issue II, the potential need for other options for electronic 
authentication, the RC supports that this issue is left to market demands 
instead of regulation.

On issue III, the potential need for provisions for handling partial bulk 
transfers between registrars, the RC supports the conclusions of the Working 
Group that at this stage there is no need for specific provisions for handling 
partial bulk transfers.

Conclusion

In relation to issue I, the potential exchange of registrant email information 
between registrars, one comment (the Registrar Constituency) does not see a 
need for policy development in this area as it is of the opinion that this 
should be left to market based solutions (RC). A second comment (VeriSign) does 
recommend further discussion on the requirement for some thick registries to 
make registrant email information available, but does express concern over the 
time and costs involved in the different options discussed by the Working 
Group. The third comment (Peter Mevzek) does see possibilities to address this 
issue via IRIS, the domain:info / contact:info operation or changes which would 
make the AuthInfo code the only authorization for a transfer.

On issue II, the potential need for other options for electronic 
authentication, all comments received agree that this should be left to market 
based solutions.

On issue III, the potential need for provisions for handling partial bulk 
transfers between registrars, all comments received agree with the preliminary 
conclusions of the Working Group that there is currently no need for specific 
provisions for handling partial bulk transfers.

Next Steps

The comments received will be analyzed and used for redrafting of the Initial 
Report into a Final Report to be considered by the GNSO Council for further 
action.

Contributors

Patrick Mevzek
Barbara Steele for VeriSign
Clarke Walton for the Registrar Constituency