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.