[Gdd-gnso-ppsai-impl] Summary, action items from today's PP IRT call

Chris Pelling chris at netearth.net
Fri Mar 2 20:41:36 UTC 2018


+1 on all ponts mentioned. 

Kind regards, 

Chris 


From: "Michele Neylon" <michele at blacknight.com> 
To: gdd-gnso-ppsai-impl at icann.org 
Sent: Friday, 2 March, 2018 19:03:16 
Subject: Re: [Gdd-gnso-ppsai-impl] Summary, action items from today's PP IRT call 

I agree 100% with all of these points 

Regards 

Michele 

Mr Michele Neylon 
https://www.blacknight.com/ 
https://michele.blog 
Intl. +353 (0)59 9183072 
Sent from mobile so usual disclaimers about typos etc apply 

On 2 Mar 2018, at 13:58, Sara Bockey < sbockey at godaddy.com > wrote: 






As requested, I’m providing feedback to the bulleted items at the bottom of this thread. For ease of reading I’m restating the question and then providing my response. 



Monthly Reporting Specification 

    1. Issue 1: Report frequency—IRT members seemed to support a requirement that these reports be submitted quarterly (current draft suggested monthly). Absent contrary input on the list this week, this change will be made in next draft. Reports could be submitted quarterly at maximum. Bi-annual or annual would be preferred. 




2. Issue 2: Report submission—on-list, some IRT members said that using ICANN reporting interface was too complicated and/or unnecessary. No one commented on this topic during today’s meeting. Absent substantial input on this topic on-list this week indicating that many IRT members would support a contrary reporting mechanism, no changes will be made on this point. 

The reporting spec is overly burdensome. Reporting must be simple enough for smaller companies to use without necessitating technical implementation. Companies should not have to spend significant amounts of money creating a system to support this specification. Reporting can and should therefore be permissible by form of a pre-formatted email. 



For issues 1 and 2, let's start simple and basic. Allow the Provider to fill out a sheet and email it to a designated address. If after submitting the first few reports it’s clear that we need to re-evaluate the process, we can come back and do so. 



3. Issue 3: Report format—on-list, some IRT members took issue with requiring both per-registrar and per-TLD reports. During the call, some IRT members indicating per-TLD could be too labor intensive, but other IRT members supported having per-TLD reports. Additional IRT input is requested on this point. 

Again, the requirements set forth in the current spec are too complicated. Simple is what is needed. The reports should only focus on the number of requests, and the actions taken on a global perspective. 



4. Issue 4: Report fields—on-list, suggestions have been made for eliminating some fields, and adding others. Based on the discussion in today’s call (absent contrary and/or additional suggestions on-list) the specification will be updated to: eliminate “total” numbers for requests for specific contacts, eliminate “publication” fields for LEA and IP requests, add publication/disclosure-other fields to capture non-LEA/IP requests, add coded “reasons for denial” fields. 



PP Applicant Guide 

    1. Issue 1: Shift to “rolling” application period (eliminating application phases). IRT members supported this approach. Absent contrary feedback on-list we will proceed with this approach. 


No issue with this change. 



2. Issue 2: Elimination of many “essay” questions in favor of “checkbox” questions. IRT members supported this approach. Absent contrary feedback on-list we will proceed with this approach. 

No issue with this change. 



3. Issue 3: Fees proposal. IRT requested additional documentation of costs to support fees proposal (ICANN org will work to provide this ASAP). 

Current proposed fees are not acceptable, and we look forward to ICANN providing its justification. Fees must be justified and reasonable considering the business models and volumes of service providers that are to be accredited. The new gTLD application fees were also meant to be cost-neutral, based on cost recovery, and that resulted in a huge surplus. Also, significant savings can be achieved in reducing or eliminating the requirements for background checks. 



LEA Disclosure Framework Specification 

    1. Issue 1: Language re: notices to customers in Sections 6.3 and 4.3, while not directly contradictory, sets different standards for the timing of notice to customers regarding an LEA request. Per IRT input on-list and on today’s call, edits will be made to make clear that Section 4.3 controls, and language to 4.3 to make clear that provide will notify customer of a request in accordance with ToS and timeframe requested by LEA, subject to any other requirements under applicable law or court order. Any additional input on this is requested by the end of the week. 




2. Issue 2: Required provider responses to high priority LEA requests. Per discussion on-list and during today’s call, it appears that 



        1. If “action” is clearly defined to include (1) disclosure of the requested information, (2) refusal to disclose the requested information for one of the reasons listed in section 4.2.2, and/or (3) in exceptional circumstances, informing LEA that the provider requires additional time to respond, then 




2. The IRT appears to find a 24-hour response time acceptable for high-priority requests from LEA that qualify for this specification. 

No. That is an incorrect presumption. The 24-hour response time is still overly strict. I propose the following language: 

Where a disclosure request has been categorized as High Priority, LEA will make every effort to contact the Provider directly to discuss the matter, and should it be determined that Provider has useful information, Provider shall use its best efforts to action the request within one business day, noting that a court order/subpoena may still be required prior to release of any information. Registrar will not be required to take any action in contravention of applicable law. 



3. IRT feedback is specifically requested on this point. Please respond to the list noting whether you (1) support, (2) oppose, or (3) would edit (explain how) the requirement that providers be required to action high-priority requests from LEA within 24 hours of receipt of the request from LEA. If there is disagreement on this, this will be flagged during the public comment period. 

I oppose the requirement that providers be required to action high-priority requests from LEA within 24 hours of receipt of the request from LEA. As previously stated, the 24-hour requirement is overly strict. This does not mean we will not try to move heaven and earth to assist LEA in a dire situation, but having it baked into a contract is a recipe for failure. 



What Section 4.2.2 fails to recognize are extraordinary circumstances that could arise outside of the 3 reasons list. There could be a DDOS attack that cripples the Provider’s systems, or there could be a flu epidemic that leaves the Provider short staffed and with a backlog, just to name a few. The point being that very valid circumstances could arise outside of the reasons listed in 4.2.2 and outside a Provider’s control. 

Again, I would like following language considered: 



Where a disclosure request has been categorized as High Priority, LEA will make every effort to contact the Provider directly to discuss the matter, and should it be determined that Provider has useful information, Provider shall use its best efforts to action the request within one business day, noting that a court order/subpoena may still be required prior to release of any information. Registrar will not be required to take any action in contravention of applicable law. 








sara bockey 

sr. policy manager | Go Daddy ™ 

sbockey at godaddy.com 480-366-3616 

skype: sbockey 



This email message and any attachments hereto is intended for use only by the addressee(s) named herein and may contain confidential information. If you have received this email in error, please immediately notify the sender and permanently delete the original and any copy of this message and its attachments. 







From: Amy Bivins < amy.bivins at icann.org > 
Date: Thursday, February 22, 2018 at 2:24 PM 
To: " gdd-gnso-ppsai-impl at icann.org " < gdd-gnso-ppsai-impl at icann.org > 
Cc: Sara Bockey < sbockey at godaddy.com > 
Subject: Re: [Gdd-gnso-ppsai-impl] Summary, action items from today's PP IRT call 





Hi All, 





We can provide an additional week for IRT input on the items below. Please send any feedback on these topics to the list by the end of next week, 2 March. 





As this will impact our ability to finalize the PPAA draft, next week’s IRT meeting will be canceled. 





Best, 


Amy 



On Feb 22, 2018, at 4:04 PM, theo geurts < gtheo at xs4all.nl > wrote: 

BQ_BEGIN



Agreed, the time we have to invest due to GDPR is weighing heavy on contracted parties and I am pretty sure no one expected we had to deep dive so hard into all these models and many many calls. Did the T&T even reach quorum yesterday? The last meeting it was me and Roger Carney as the only attendees. IRT's and WG's are suffering due to the GDPR, I think we are asking too much of the volunteer workforce here. 

The meeting in PR, 18:30 till 20:00 for the PPSAI, I cannot believe that. My first meeting starts at 8 am that day. Is it normal ICANN staff works from 8 am to 8 pm? I do not find it normal as we do not get paid. This is getting close to slave labor here. 

Theo 




On 22-2-2018 21:51, Sara Bockey wrote: 

BQ_BEGIN


Amy, 



As you know, several registrars were not able to attend Tuesday’s call and I think it’s safe to say many members a facing bandwidth issues. 



As you also know, GDPR is fast approaching and several sessions were held this week on the topic. GDPR is mission critical and requires a lot of registrar time investment. That said, it is likely that IRT members have not had a chance to listen to the recording or catch up on the mailing list. Therefore, I think it would be appropriate to allow an additional week to respond to our punch list below. There is no reason why we cannot allow this additional time. We are not facing a hard deadline as with GDPR, and it is very important for this IRT to produce quality work, not quick work. 



Thanks, 



Sara 




sara bockey 

sr. policy manager | Go Daddy ™ 

sbockey at godaddy.com 480-366-3616 

skype: sbockey 



This email message and any attachments hereto is intended for use only by the addressee(s) named herein and may contain confidential information. If you have received this email in error, please immediately notify the sender and permanently delete the original and any copy of this message and its attachments. 







From: Gdd-gnso-ppsai-impl <gdd-gnso-ppsai-impl-bounces at icann.org> on behalf of Amy Bivins <amy.bivins at icann.org> 
Reply-To: "gdd-gnso-ppsai-impl at icann.org" <gdd-gnso-ppsai-impl at icann.org> 
Date: Thursday, February 22, 2018 at 3:55 AM 
To: "gdd-gnso-ppsai-impl at icann.org" <gdd-gnso-ppsai-impl at icann.org> 
Subject: Re: [Gdd-gnso-ppsai-impl] Summary, action items from today's PP IRT call 





Dear Colleagues, 





This is a reminder to please submit your input on the points below no later than your EOD Friday. 





We will make any final edits to the PPAA draft based on this feedback and intend to send you the updated draft on Monday as soon as the final edits are complete and reviewed internally. You aren’t expected to review the draft prior to Tuesday’s meeting-I realize this is a tight turnaround-I will explain edits that were made so that you can more easily review the updated draft after our call next week. 





Best, 


Amy 





Sent from my iPhone 



On Feb 20, 2018, at 12:27 PM, Amy Bivins < amy.bivins at icann.org > wrote: 

BQ_BEGIN



Dear Colleagues, 



Thank you for your active participation on today’s Privacy/Proxy IRT call. We covered a lot of ground. If you could not attend, I encourage you to listen to the recording, available on the wiki, https://participate.icann.org/p39onhjd1g1/ . 



Please review the items discussed today (summarized below) and provide any additional input to the list no later than your EOD Friday, 23 Feb. 



Monthly Reporting Specification 

    1. Issue 1: Report frequency—IRT members seemed to support a requirement that these reports be submitted quarterly (current draft suggested monthly). Absent contrary input on the list this week, this change will be made in next draft. 
    2. Issue 2: Report submission—on-list, some IRT members said that using ICANN reporting interface was too complicated and/or unnecessary. No one commented on this topic during today’s meeting. Absent substantial input on this topic on-list this week indicating that many IRT members would support a contrary reporting mechanism, no changes will be made on this point. 
    3. Issue 3: Report format—on-list, some IRT members took issue with requiring both per-registrar and per-TLD reports. During the call, some IRT members indicating per-TLD could be too labor intensive, but other IRT members supported having per-TLD reports. Additional IRT input is requested on this point. 


    1. Issue 4: Report fields—on-list, suggestions have been made for eliminating some fields, and adding others. Based on the discussion in today’s call (absent contrary and/or additional suggestions on-list) the specification will be updated to: eliminate “total” numbers for requests for specific contacts, eliminate “publication” fields for LEA and IP requests, add publication/disclosure-other fields to capture non-LEA/IP requests, add coded “reasons for denial” fields. 




PP Applicant Guide 

    1. Issue 1: Shift to “rolling” application period (eliminating application phases). IRT members supported this approach. Absent contrary feedback on-list we will proceed with this approach. 
    2. Issue 2: Elimination of many “essay” questions in favor of “checkbox” questions. IRT members supported this approach. Absent contrary feedback on-list we will proceed with this approach. 
    3. Issue 3: Fees proposal. IRT requested additional documentation of costs to support fees proposal (ICANN org will work to provide this ASAP). 




LEA Disclosure Framework Specification 

    1. Issue 1: Language re: notices to customers in Sections 6.3 and 4.3, while not directly contradictory, sets different standards for the timing of notice to customers regarding an LEA request. Per IRT input on-list and on today’s call, edits will be made to make clear that Section 4.3 controls, and language to 4.3 to make clear that provide will notify customer of a request in accordance with ToS and timeframe requested by LEA, subject to any other requirements under applicable law or court order. Any additional input on this is requested by the end of the week. 
    2. Issue 2: Required provider responses to high priority LEA requests. Per discussion on-list and during today’s call, it appears that 




        1. If “action” is clearly defined to include (1) disclosure of the requested information, (2) refusal to disclose the requested information for one of the reasons listed in section 4.2.2, and/or (3) in exceptional circumstances, informing LEA that the provider requires additional time to respond, then 
        2. The IRT appears to find a 24-hour response time acceptable for high-priority requests from LEA that qualify for this specification. 
        3. IRT feedback is specifically requested on this point. Please respond to the list noting whether you (1) support, (2) oppose, or (3) would edit (explain how) the requirement that providers be required to action high-priority requests from LEA within 24 hours of receipt of the request from LEA. If there is disagreement on this, this will be flagged during the public comment period. 


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 at icann.org 

www.icann.org 





BQ_BEGIN



_______________________________________________ 
Gdd-gnso-ppsai-impl mailing list 
Gdd-gnso-ppsai-impl at icann.org 
https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl 

BQ_END






_______________________________________________ 
Gdd-gnso-ppsai-impl mailing list 
Gdd-gnso-ppsai-impl at icann.org 
https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl 

BQ_END




BQ_END

BQ_BEGIN



_______________________________________________ 
Gdd-gnso-ppsai-impl mailing list 
Gdd-gnso-ppsai-impl at icann.org 
https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl 

BQ_END


BQ_END

BQ_BEGIN

_______________________________________________ 
Gdd-gnso-ppsai-impl mailing list 
Gdd-gnso-ppsai-impl at icann.org 
https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl 

BQ_END


_______________________________________________ 
Gdd-gnso-ppsai-impl mailing list 
Gdd-gnso-ppsai-impl at icann.org 
https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gdd-gnso-ppsai-impl/attachments/20180302/a61fc1f1/attachment-0001.html>


More information about the Gdd-gnso-ppsai-impl mailing list