[Gnso-ppsai-pdp-wg] Transfers Subteam Reporting Back

[Kathy Kleiman]

Hi All,
This is the subteam of James and Kathy reporting back to the WG on the 
issue we were assigned - an outline for protecting privacy in transfer 
situations. Our work is a one-pager that I have pasted below (but 
perhaps easier to read in the attached, formatted version).


Overall, we think there are a narrow set of issues for the WG to look 
at, and staightforward work to be done -- within existing transfer rules 
-- to help improve privacy during domain name transfers. Our thoughts 
are below, and attached. We were not tasked with solving the problem, 
but laying out a path towards evaluating it in a fairly short amount of 
time.


Best,
Kathy


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
_**_

*
*

*PPSAI -- Category B -- Maintenance of Privacy / Proxy Services *

*- Question 3*

*Registrar Transfer and Options for PPSAI Working Group*

**

*(A few questions to consider to help Registrants seeking privacy during 
the transfer process)*

*__*

*1.**_WDRP, Renewal Notifications, etc._*

1.1.The WG/Subteam should consider requirements for P/P services to 
relay "ICANN-Critical" communications from the Registrar to the P/P 
customer.

1.2.These would include WDRP annual reminders, and renewal/expiry 
notifications required under the ERRP.

1.3.Other messages from the registrar might also be designated as 
critical, e.g. status changes to contacts or nameservers.

*2.**_Inter-Registrar Transfers (IRTP)_*

2.1.The WG/Subteam should consider scenarios where either the gaining or 
losing registrar employs a P/P service, or both.

2.2.The four use cases can be arranged in a grid:

A. Non-Private to Non-Private (Current IRTP)

	

B. Private to Non-Private

C. Non-Private to Private

	

D. Private to Private

A.No P/P service involvement, (status quo under current IRTP)

B.Losing registrar has affiliated P/P, Gaining does not.

C.Gaining registrar has affiliated P/P, Losing does not.

D.Both Gaining and Losing registrars have affiliated P/P which the 
customer has opted to use.

2.3.The right-side column (B & D) would require some method for 
registrars and their affiliated P/P services to exchange protected 
contact data, such as a hash function. This exchange would provide 
additional protection for the transfer of the domain name also requires 
transfer of the AUTHINFO code.

*3.**_Transfers in the event of a failed Registrar_*

3.1.Existing IRTP almost sufficiently cover this scenario.

3.2.Registrant and underlying P/P data is currently included in data escrow.

3.3.If both files are passed on to a gaining registrar with an 
affiliated proxy or privacy service and used as a basis for registration 
in the new p/p service, than the privacy of customers would continue to 
be protected even as numerous Registrants pass from a failed or 
de-accredited Registrar to another Registrar.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-ppsai-pdp-wg/attachments/20140512/7ab7e763/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PPSAI Sub Team - Transfer Issues (00663227).DOCX
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 21165 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-ppsai-pdp-wg/attachments/20140512/7ab7e763/PPSAISubTeam-TransferIssues00663227-0001.DOCX>