Hi Amy,
This is to provide feedback on issue 1(a) below regarding periodic reporting by Providers.
I believe it is essential for the reports to break out the types of disclosure requests by LEA, IP and other. The PDP WG final report repeatedly stresses the need for a post-implementation evaluation of the
Illustrative Disclosure Framework, and it is hard to see how this could occur without specific data on how these requests are handled. I assume that the same would be true for the LEA framework that is ultimately adopted (for instance, to quantify how many
requests are actually received and processed).
I’d also note that each of the three types of disclosure requests are subject to different rules and so will need to be handled differently by Providers. For instance, with respect to notifying customers of
the request prior to disclosure, this is mandatory for IP requests; generally prohibited for LEA requests (subject to provider TOS and requestor-generate timelines); and left up to the Provider for other disclosure requests (so long as the Provider’s policy
on this point is spelled out in its terms of service). Since Providers are required to observe these operational distinctions, the incremental burden of compiling data on such requests in separate categories would be limited. Furthermore, the reasons for
denying such requests are spelled out in both the IP and LEA frameworks; in both cases the reason(s) need to be communicated to requesters, so here again this information will need to be generated and the burden of compiling it on a periodic basis should
not be excessive.
As to reporting by registrar and by TLD: if a Provider is affiliated with one Registrar, then there is really no burden to compile this information on a per Registrar basis. If a Provider is affiliated with
more than one Registrar within a single registrar family, there certainly would be a value in knowing which registrars were the source for more or fewer disclosure requests, and it would seem the burden of compiling this information would be minimal. For
unaffiliated Providers, this data would be necessary for achieving a complete picture of the volume and type of requests allocable to a particular Registrar whose registrants employ the service of a range of different Providers. We’ve tried to keep the requirements
as similar as possible for affiliated and unaffiliated providers and it is not clear why we should deviate from that principle here. In any case there would be a pre-existing contractual relationship between each unaffiliated proxy provider (since the Provider
would be listed as the registrant) and the registrar.
I’d acknowledge that providers would not necessarily have any relationship with registry operators, so compiling this information on a per TLD basis could require the provider to compile some information that
it might otherwise not collect systematically. While there would certainly be some value from a post-implementation review and compliance perspective for ICANN to have this data, the relative burden of compiling it could be greater than in the case of per-registrar
or per-disclosure-type data, as discussed above.
Steve
Steven J. Metalitz |
Partner, through his professional corporation
T: 202.355.7902
|
met@msk.com
Mitchell Silberberg & Knupp
LLP
|
www.msk.com
1818 N Street NW, 8th Floor, Washington, DC 20036
THE INFORMATION CONTAINED IN THIS E-MAIL MESSAGE IS INTENDED ONLY FOR THE PERSONAL AND CONFIDENTIAL USE OF THE DESIGNATED RECIPIENTS.
THIS MESSAGE MAY BE AN ATTORNEY-CLIENT COMMUNICATION, AND AS SUCH IS PRIVILEGED AND CONFIDENTIAL. IF THE READER OF THIS MESSAGE IS NOT AN INTENDED RECIPIENT, YOU ARE HEREBY NOTIFIED THAT ANY REVIEW, USE, DISSEMINATION, FORWARDING OR COPYING OF THIS MESSAGE
IS STRICTLY PROHIBITED. PLEASE NOTIFY US IMMEDIATELY BY REPLY E-MAIL OR TELEPHONE, AND DELETE THE ORIGINAL MESSAGE AND ALL ATTACHMENTS FROM YOUR SYSTEM. THANK YOU.
From: Gdd-gnso-ppsai-impl [mailto:gdd-gnso-ppsai-impl-bounces@icann.org]
On Behalf Of Amy Bivins
Sent: Tuesday, March 13, 2018 2:01 PM
To: gdd-gnso-ppsai-impl@icann.org
Subject: [Gdd-gnso-ppsai-impl] Update, action items following PP IRT meetings at ICANN61
Dear Colleagues,
I hope you are well. If you were unable to attend the ICANN61 privacy/proxy IRT face-to-face meeting in person or listen in, I encourage you to review the recording, available here:
https://participate.icann.org/p4gkq5rzjbj/
Below, you will see a list of outstanding items, as well as a call for your feedback. Please review carefully. We are requesting your final feedback on items (1)-(2) by this Friday.
During the session on Sunday, the IRT heard a presentation from ICANN org finance regarding the proposed fee schedule. ICANN is reviewing the IRT’s request for additional supporting data and intends to provide a response next week.
The IRT heard an update on discussions between PSWG and registrar members of the IRT on the LEA Disclosure Framework Specification. PSWG and registrar members continue to discuss this topic this week, with the goal of determining whether
a compromise can be reached by this Friday.
IRT Action Items
- Request for feedback on draft reporting specification, per discussion on the list. Any additional IRT feedback is requested by the end of this week. We will draft any updates in response to your feedback
early next week.
- The most significant issue appears to be the level of detail that should be required for the reports. Registrar members of the IRT have asserted that it will be difficult to provide the level of detail proposed
(or that these could be prone to human error in reporting)—regarding types of requests (LEA, IP, Other) and reporting by-registrar and by-TLD.
Any additional feedback is specifically requested on this topic this week. A decision will be made on this after the close of ICANN61, for the purpose of drafting final proposed requirements for public comment.
- There were issues raised about using the RRI reporting system versus allowing forms to be emailed. ICANN provided additional details (attached) on the RRI process (creating spreadsheet using standard format,
converting to CSV, and submitting using API). The RRI process would be largely the same using an emailed form (the only difference would be emailing the CSV or spreadsheet rather than using the API). Considering the benefits of using RRI (less manual review
of reports, immediate notifications to providers if there are problems with the report, less back-and-forth to correct report errors) ICANN proposes to keep the RRI requirement absent significant opposition to this from the IRT. Training for how to use the
RRI system can be provided for providers who need it.
- The most significant issue appears to be the level of detail that should be required for the reports. Registrar members of the IRT have asserted that it will be difficult to provide the level of detail proposed
(or that these could be prone to human error in reporting)—regarding types of requests (LEA, IP, Other) and reporting by-registrar and by-TLD.
Any additional feedback is specifically requested on this topic this week. A decision will be made on this after the close of ICANN61, for the purpose of drafting final proposed requirements for public comment.
- A question on the data escrow specification:
Does the IRT see an issue with making the data escrow specification a separate document from the PPAA, so that it can be more easily updated if/when technical requirements change (as is done for registrars)?
- Any additional IRT feedback on updated PPAA draft (attached) requested by 23 March.
Our next IRT meeting is scheduled for 27 March, 1400 UTC.
Best,
Amy
Amy E. Bivins
Registrar Services and Engagement Senior Manager
Registrar Services and Industry Relations
Internet Corporation for Assigned Names and Numbers (ICANN)
Direct: +1 (202) 249-7551
Fax: +1 (202) 789-0104
Email:
amy.bivins@icann.org