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

theo geurts gtheo at xs4all.nl
Fri Mar 2 19:42:24 UTC 2018


Agreed with all points, except.

1 Since we seem to be reporting for the reporting, annual.

A good weekend,

Theo



On 2-3-2018 19:57, Sara Bockey 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 <mailto: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 
> <mailto:gtheo at xs4all.nl>> wrote:
>
>     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:
>
>         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 <mailto: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>
>         <mailto:gdd-gnso-ppsai-impl-bounces at icann.org> on behalf of
>         Amy Bivins <amy.bivins at icann.org> <mailto:amy.bivins at icann.org>
>         *Reply-To: *"gdd-gnso-ppsai-impl at icann.org"
>         <mailto:gdd-gnso-ppsai-impl at icann.org>
>         <gdd-gnso-ppsai-impl at icann.org>
>         <mailto:gdd-gnso-ppsai-impl at icann.org>
>         *Date: *Thursday, February 22, 2018 at 3:55 AM
>         *To: *"gdd-gnso-ppsai-impl at icann.org"
>         <mailto:gdd-gnso-ppsai-impl at icann.org>
>         <gdd-gnso-ppsai-impl at icann.org>
>         <mailto: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<mailto:amy.bivins at icann.org>> wrote:
>
>             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.
>
>              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.
>              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<mailto:amy.bivins at icann.org>
>
>             www.icann.org<http://www.icann.org>
>
>             _______________________________________________
>             Gdd-gnso-ppsai-impl mailing list
>             Gdd-gnso-ppsai-impl at icann.org<mailto:Gdd-gnso-ppsai-impl at icann.org>
>             https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl
>
>
>
>
>         _______________________________________________
>
>         Gdd-gnso-ppsai-impl mailing list
>
>         Gdd-gnso-ppsai-impl at icann.org<mailto:Gdd-gnso-ppsai-impl at icann.org>
>
>         https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl
>
>     _______________________________________________
>     Gdd-gnso-ppsai-impl mailing list
>     Gdd-gnso-ppsai-impl at icann.org<mailto:Gdd-gnso-ppsai-impl at icann.org>
>     https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl
>
>
>
> _______________________________________________
> 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/b24f5c05/attachment-0001.html>


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