[Gnso-ppsai-pdp-wg] PP transfer issue

Thu Jan 28 22:05:32 UTC 2016

I have a strictly procedural question:  what is the role of the Issues Team after the PDP has been approved but before it gets underway?  I'm a little concerned that we are either modifying the issues (with no community opportunity to comment on any outcomes) or are starting the formal PDP proceedings without the rest of the team signed up and before it is actually commenced.

However, if this is just unofficial warm up to the formal PDP proceedings (or we are writing as hobbyists only), no worries.

I hope you all are well.

Best,
Paul

From: gnso-ppsai-pdp-wg-bounces at icann.org [mailto:gnso-ppsai-pdp-wg-bounces at icann.org] On Behalf Of Holly Raiche
Sent: Thursday, January 28, 2016 3:52 PM
To: Carlton Samuels
Cc: gnso-ppsai-pdp-wg at icann.org
Subject: Re: [Gnso-ppsai-pdp-wg] PP transfer issue

Hi Carlton

I think we can use the reasoning we used when discussing lawyers holding a domain name for their clients - but are not accredited.  In that situation, the lawyer is the client - the registrant - a very different situation than when both the originating and receiving registrars are accredited and P/P providers and covered by the same rules.  We just need to work through what rules should be in place so that a beneficial registrant can transfer from one accredited P/P provider to another accredited P/P provider (provided by a different registrar) because in both cases, there are requirements on registrars relating to collecting and checking on the accuracy of the Whois data. We started down that road, with useful discussion which, as Kathy points out - needs more work.

Holly

On 29 Jan 2016, at 4:18 am, Carlton Samuels <carlton.samuels at gmail.com<mailto:carlton.samuels at gmail.com>> wrote:

Coming on the new dispensation, would it make a difference if both the originating and receiving Registrars are ICANN-accredited P/P providers?

-Carlton

==============================
Carlton A Samuels
Mobile: 876-818-1799
Strategy, Planning, Governance, Assessment & Turnaround
=============================

On Thu, Jan 28, 2016 at 12:37 AM, Holly Raiche <h.raiche at internode.on.net<mailto:h.raiche at internode.on.net>> wrote:
Kathy/Mary

In a F2F (LA, I think) James talked through the problem. Under the RAA, registrars are responsible for the accuracy of the Whois (RDS) data.  As yet, there isn't a mechanism by which a registrar, taking on a P/P customer from another from another registrar, can be assured that the Whois data relating to that new customer is accurate.  So the short answer is that the new registrar cannot now take at face value the custom of a P/P customer without checking the accuracy of their Whois data.  The trouble with the recommendation below is that it fudges the issue.  What we should be asking is the extent to which a P/P provider must verify new P/P data - and the extent to which that data can remain confidential in the transfer process.  (not the best wording, but we need to accommodate two apparently conflicting requirements: the confidentiality of the data of the P/P customer, and the requirement on registrars for the accuracy of the Whois data for all their customers.)

Holly

On 27 Jan 2016, at 3:45 am, Mary Wong <mary.wong at icann.org<mailto:mary.wong at icann.org>> wrote:

Hello Kathy and all,

Thanks for your note; it reminded that I should have also included the further recommendation below in my previous email that noted two specific WG recommendations containing references to the IRTP. This additional recommendation that I'm now pasting came about as a result of the WG's email and live discussions, following the November email exchanges which you and others are referring to today:

"The next review of the IRTP should include an analysis of the impact on P/P service customers, to ensure that adequate safeguards are in place as regards P/P service protection when domain names are transferred pursuant to an IRTP process. Where a P/P service customer initiates a transfer of a domain name, the WG recognizes that a registrar should have the same flexibility that it has currently to reject incoming transfers from any individual or entity, including those initiated by accredited P/P services. Nevertheless, the WG recommends that, in implementing those elements of the P/P service accreditation program that pertain to or that affect domain name transfers and in addition to its specific recommendations contained in this Final Report, ICANN should perform a general "compatibility check" of each proposed implementation mechanism with the then-current IRTP."

I believe the context for this - and the other two IRTP-related recommendations approved in the Final Report that I'd pasted in my earlier email - is the WG's recognition that the effect of the IRTP changes on P/P services and their customers may need to be more directly addressed in the next review of the IRTP. This WG's final recommendations therefore addressed particular situations for which specific exceptions may be warranted due, e.g., to the need to ensure continuing customer protection during the deaccreditation of a P/P service provider.

Thanks and cheers
Mary

Mary Wong
Senior Policy Director
Internet Corporation for Assigned Names and Numbers (ICANN)
Email: mary.wong at icann.org<mailto:mary.wong at icann.org>
Telephone: +1-603-5744889<tel:%2B1-603-5744889>

From: <gnso-ppsai-pdp-wg-bounces at icann.org<mailto:gnso-ppsai-pdp-wg-bounces at icann.org>> on behalf of Kathy Kleiman <kathy at kathykleiman.com<mailto:kathy at kathykleiman.com>>
Date: Tuesday, January 26, 2016 at 23:08
To: "gnso-ppsai-pdp-wg at icann.org<mailto:gnso-ppsai-pdp-wg at icann.org>" <gnso-ppsai-pdp-wg at icann.org<mailto:gnso-ppsai-pdp-wg at icann.org>>
Subject: Re: [Gnso-ppsai-pdp-wg] PP transfer issue

Tx Mary, but I am still missing the impact of the discussion below on our PPSAI recommendations. If I want to transfer my domain name(s) from Registrar A to Registrar B, both with Privacy and Proxy services, and to keep the data private as the transfer takes place (something we all agreed should happen) -- is there a problem, a limitation, a barrier? If so, how can we overcome it?

Best,
Kathy
On 11/25/2015 2:04 PM, Mary Wong wrote:
Hello everyone,

Just a quick note for those WG members who may not be familiar with the IRTP, the changes to IRTP-C, or the implementation discussions - it may help to note the following definition for the IRTP. I believe that James is referring to the registrar's discretion in determining whether the purported change is or is not typographical in nature (see in particular the words I've highlighted in bold and italics). This is illustrated by the examples given:

"Material Change" means a non-typographical correction.  The following will be considered material changes:
(i)    A change to the Registered Name Holder's name or organization that does not appear to be a merely a typographical correction;
(ii)    Any change to the Registered Name Holder's name or organization that is accompanied by a change of address or phone number;
(iii)    Any change to the Registered Name Holder's email address.

The point about having discretion on this matter can be significant because, under the Policy, a Material Change to a registrant's name, organizational address or email address will be considered a Change of Registrant and thus trigger the 60-day lock. Hence, disabling/removal of a proxy service would trigger a lock - although the current Policy contemplates another possible instance of registrar discretion in such instances, i.e. a registrar has the discretion ("may") to permit the Registered Name Holder to opt out of the lock prior to the Change of Registrant request.

I'm far from an expert on the IRTP, but hopefully the above helps to explain the current proposed recommendation in the Final Report where, in referring to IRTP-C, the WG is recommending that - in relation to de-accreditation - "where a Change of Registrant (as defined under the IRTP) takes place during the process of de-accreditation of a proxy service provider, a registrar should lift the mandatory 60-day lock at the express request of the beneficial user, provided the registrar has also been notified of the de-accreditation of the proxy service provider".

Thanks and cheers
Mary

Mary Wong
Senior Policy Director
Internet Corporation for Assigned Names & Numbers (ICANN)
Telephone: +1 603 574 4889<tel:%2B1%20603%20574%204889>
Email: mary.wong at icann.org<mailto:mary.wong at icann.org>

From: <gnso-ppsai-pdp-wg-bounces at icann.org<mailto:gnso-ppsai-pdp-wg-bounces at icann.org>> on behalf of "James M. Bladel" <jbladel at godaddy.com<mailto:jbladel at godaddy.com>>
Date: Wednesday, November 25, 2015 at 11:24
To: Mike Zupke <Mike.Zupke at icann.org<mailto:Mike.Zupke at icann.org>>, "Metalitz, Steven" <met at msk.com<mailto:met at msk.com>>, Volker Greimann <vgreimann at key-systems.net<mailto:vgreimann at key-systems.net>>, "gnso-ppsai-pdp-wg at icann.org<mailto:gnso-ppsai-pdp-wg at icann.org>" <gnso-ppsai-pdp-wg at icann.org<mailto:gnso-ppsai-pdp-wg at icann.org>>, Amy Bivins <amy.bivins at icann.org<mailto:amy.bivins at icann.org>>
Subject: Re: [Gnso-ppsai-pdp-wg] PP transfer issue

Hi folks.  Just responding to Mike's post from last Wednesday:

The question of P/P services triggering the "Change of Registrant" policy was not, IMO, sufficiently addressed by the IRTP WG.  It was, however, the subject of extensive discussion by the Implementation team, which ultimately determined that Registrar's should have the discretion to determine whether or not this qualified as a Change of Registrant. For example, a Registrar may determine that adding/removing an affiliated P/P service does NOT trigger the change of registrant policy, but that an unaffiliated P/P service contains too many unknowns, so explicit consent and a 60-day transfer lock may be warranted.

There are a number of practical scenarios where this flexibility is needed, including dealing with transfers as part of an aftermarket sale, implementation of a UDRP decision, billing or payment failures for the P/P service, or termination due to a violation of the P/P services terms.  I would also caution against recommendations of any particular WG (PPSAI) explicitly reverse recommendations or Implementation decisions of prior WGs (IRTP-C) even before they have been adopted.

I don't think this should materially affect the overall recommendations of PPSAI, nor do I see any incompatibilities with this and our recommendations.  But happy to discuss this point on our next call.

Thanks-

J.

From: Mike Zupke <Mike.Zupke at icann.org<mailto:Mike.Zupke at icann.org>>
Date: Wednesday, November 18, 2015 at 7:10
To: "Metalitz, Steven" <met at msk.com<mailto:met at msk.com>>, Volker Greimann <vgreimann at key-systems.net<mailto:vgreimann at key-systems.net>>, James Bladel <jbladel at godaddy.com<mailto:jbladel at godaddy.com>>, PPSAI WG <gnso-ppsai-pdp-wg at icann.org<mailto:gnso-ppsai-pdp-wg at icann.org>>, Amy Bivins <amy.bivins at icann.org<mailto:amy.bivins at icann.org>>
Subject: RE: [Gnso-ppsai-pdp-wg] PP transfer issue

Sorry for the delayed reply.  We needed to consult with a few others.

In answer to Steve's question ("Could you clarify whether the 60-day lock provision is part of the IRTP as a consensus policy, or part of the implementation of that policy?"), the lock was included in the policy recommendations of IRTP WG C, which were adopted by the Council and Board.  There was no mention of privacy or proxy services in that part of the recommendation.  So our implementation of the IRTP C recommendations was done "to the letter" of the recommendation, so to speak.  I.e., no exception was made for privacy and proxy services.

We don't believe the PPSAI working group is necessarily precluded from addressing questions about how the to-be-created type of PP registrations interact with the Transfer Policy just because the Transfer Policy is an existing policy.  PPSAI charter question B-3 (here: https://community.icann.org/x/ihLRAg) spoke to having the WG "[c]larify how transfers, renewals, and PEDNR policies should apply."

With regard to the point James made, during implementation of the IRTP C recommendations, we talked a good bit about how a proxy (or the beneficial customer) could disable a proxy or privacy service in a world where consent of the other party would now be required in order to make the change in Whois.  The solution to that question was to allow use of "designated agents" (see https://www.icann.org/resources/pages/transfer-policy-2015-09-24-en#II at 1.1.2) to approve Changes of Registrant.  I don't believe the matter of exempting PP registrations from the 60 day lock was raised by the IRT or in public comment, although I do recall occasionally that people would reference the work of this WG as potentially being necessary to addressing interaction with accredited PP service registrations and the Transfer Policy.

Hope that helps.

Mike Zupke
Director, Registrar Services
Internet Corporation for Assigned Names and Numbers

From: gnso-ppsai-pdp-wg-bounces at icann.org<mailto:gnso-ppsai-pdp-wg-bounces at icann.org> [mailto:gnso-ppsai-pdp-wg-bounces at icann.org] On Behalf Of James M. Bladel
Sent: Wednesday, November 18, 2015 6:12 AM
To: Volker Greimann <vgreimann at key-systems.net<mailto:vgreimann at key-systems.net>>; gnso-ppsai-pdp-wg at icann.org<mailto:gnso-ppsai-pdp-wg at icann.org>
Subject: Re: [Gnso-ppsai-pdp-wg] PP transfer issue

Agree, and I thought this was also the final determination of the IRTP-C Implementation Review Team.  It came up several times...

Thanks-

J.

From: <gnso-ppsai-pdp-wg-bounces at icann.org<mailto:gnso-ppsai-pdp-wg-bounces at icann.org>> on behalf of Volker Greimann <vgreimann at key-systems.net<mailto:vgreimann at key-systems.net>>
Date: Wednesday, November 18, 2015 at 4:22
To: PPSAI WG <gnso-ppsai-pdp-wg at icann.org<mailto:gnso-ppsai-pdp-wg at icann.org>>
Subject: Re: [Gnso-ppsai-pdp-wg] PP transfer issue

In all honesty, a removal of an accredited privacy service should not trigger the transfer lock as it does not imply an owner change. I am therefore in favor of option 2)

Best,

Volker
Am 17.11.2015 um 19:01 schrieb Amy Bivins:
Dear PPSAI WG Members:

Here is the issue you asked staff to address by email today.  This came to our attention after reflecting on the work done Friday by the "implementation issues" sub-team.

In short, disabling a proxy or privacy service will trigger the 60-day inter-registrar transfer lock required by IRTP C (which takes effect on 1 August 2016, https://www.icann.org/resources/pages/transfer-policy-2015-09-24-en ). Although applicable generally, this issue is of particular concern following de-accreditation of a privacy or proxy service (if transfer to another registrar is required to maintain privacy).

Here are 3 things the WG could consider doing to address this:
1. Maintain the status quo and leave the 60-day IRTP C lock in place.
2. Create an exception for Privacy and Proxy Service customers, so the 60 day IRTP C (inter-registrar transfer) lock doesn't apply when/if the customer changes or removes the PP service.
3. Create an exception for PP users only if a PP service is de-accredited, so the IRTP C (inter-registrar transfer) lock can be lifted by the beneficial user if the registrar has been notified of de-accreditation.

Please let us know if you'd like to us to provide any further background.

Thank you!

Amy E. Bivins
Registrar Policy Services Manager
Internet Corporation for Assigned Names and Numbers (ICANN)
amy.bivins at icann.org<mailto:amy.bivins at icann.org>

One World. One Internet.

Direct: +1 (202) 249-7551<tel:%2B1%20%28202%29%20249-7551>
Fax:  +1 (202) 789-0104<tel:%2B1%20%28202%29%20789-0104>
801 17th Street NW, Suite 400
Washington, DC 20006

_______________________________________________

Gnso-ppsai-pdp-wg mailing list

Gnso-ppsai-pdp-wg at icann.org<mailto:Gnso-ppsai-pdp-wg at icann.org>https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg

--

Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.

Mit freundlichen Grüßen,

Volker A. Greimann

- Rechtsabteilung -

Key-Systems GmbH

Im Oberen Werk 1

66386 St. Ingbert

Tel.: +49 (0) 6894 - 9396 901<tel:%2B49%20%280%29%206894%20-%209396%20901>

Fax.: +49 (0) 6894 - 9396 851<tel:%2B49%20%280%29%206894%20-%209396%20851>

Email: vgreimann at key-systems.net<mailto:vgreimann at key-systems.net>

Web: www.key-systems.net<http://www.key-systems.net/> / www.RRPproxy.net<http://www.rrpproxy.net/>www.domaindiscount24.com<http://www.domaindiscount24.com/> / www.BrandShelter.com<http://www.brandshelter.com/>

Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:

www.facebook.com/KeySystems<http://www.facebook.com/KeySystems>www.twitter.com/key_systems<http://www.twitter.com/key_systems>

Geschäftsführer: Alexander Siffrin

Handelsregister Nr.: HR B 18835 - Saarbruecken

Umsatzsteuer ID.: DE211006534

Member of the KEYDRIVE GROUP

www.keydrive.lu<http://www.keydrive.lu/>

Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.

--------------------------------------------

Should you have any further questions, please do not hesitate to contact us.

Best regards,

Volker A. Greimann

- legal department -

Key-Systems GmbH

Im Oberen Werk 1

66386 St. Ingbert

Tel.: +49 (0) 6894 - 9396 901<tel:%2B49%20%280%29%206894%20-%209396%20901>

Fax.: +49 (0) 6894 - 9396 851<tel:%2B49%20%280%29%206894%20-%209396%20851>

Email: vgreimann at key-systems.net<mailto:vgreimann at key-systems.net>

Web: www.key-systems.net<http://www.key-systems.net/> / www.RRPproxy.net<http://www.rrpproxy.net/>www.domaindiscount24.com<http://www.domaindiscount24.com/> / www.BrandShelter.com<http://www.brandshelter.com/>

Follow us on Twitter or join our fan community on Facebook and stay updated:

www.facebook.com/KeySystems<http://www.facebook.com/KeySystems>www.twitter.com/key_systems<http://www.twitter.com/key_systems>

CEO: Alexander Siffrin

Registration No.: HR B 18835 - Saarbruecken

V.A.T. ID.: DE211006534

Member of the KEYDRIVE GROUP

www.keydrive.lu<http://www.keydrive.lu/>

This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.

_______________________________________________

Gnso-ppsai-pdp-wg mailing list

Gnso-ppsai-pdp-wg at icann.org<mailto:Gnso-ppsai-pdp-wg at icann.org>https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg

_______________________________________________
Gnso-ppsai-pdp-wg mailing list
Gnso-ppsai-pdp-wg at icann.org<mailto:Gnso-ppsai-pdp-wg at icann.org>
https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg

_______________________________________________
Gnso-ppsai-pdp-wg mailing list
Gnso-ppsai-pdp-wg at icann.org<mailto:Gnso-ppsai-pdp-wg at icann.org>
https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg

The contents of this message may be privileged and confidential. Therefore, if this message has been received in error, please delete it without reading it. Your receipt of this message is not intended to waive any applicable privilege. Please do not disseminate this message without the permission of the author.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-ppsai-pdp-wg/attachments/20160128/3e9fd475/attachment-0001.html>