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.