Content Comparison

Operational Input

- All to review and confirm operational input is taken into account in report and recommendations.

Rec# #11 Common Interface

- ICANN org to follow up with Susan/Volker and see whether these two highlighted questions can be removed

Rec#10 Privacy/Proxy Services

- Issue #1: leave it as is and remove comment.

Rec#5-9 Data Accuracy

- Alan to address section issues with Lili

Rec#4 Compliance

- Susan to review action items

- Alan to complete action item on paragraph on current situation, and consider GDPR control issues.

Susan

Alan

Rec#3: Outreach

- Add comment in the public comment tool rather than in the report

Single Whois Policy

- p3: "were suspended and later terminated due to the ongoing effort to adress GDPR" (+ remove paragraph afterwards)

- p4: remove dash after "In any event'"

- p4: delete highlighted section

p6: Move four bullet points to "research section", and report "none" under "Recommendations"

Strategic Priority

- p6 Alan to clean up wording on p6 "but that was in fact done"

- p9 Alan to update paragraph

- p10: replace most/many with "some"

- p12: add footnote on "soft policy "such as guidance documents, best practices."

- p13: add a note in the report "any timeline mentioned in the report make reference to when the board takes action."

Review team members/subject matter experts are invited to

• review with care their sections in the report (looking for errors, inconsistencies)
• confirm the section is consistent and tight, by Friday 18 January 2019 23:59 UTC. (Extra day allowed for Stephanie, considering the ePDP meeting)
• come up with suggestions before plenary call #47 as to how the sections can be cleaned up.

WHOIS1 Rec #4: Compliance: Under “Possible Impact GDPR and other applicable laws” Alan to add a paragraph on current situation pointing out the paradox of goodwill vs doing it properly. Add sentence on whether contractual compliance can verify compliance if they can't look at the data.

Subgroup 3 - Law Enforcement Needs: Jackie to emphasize the "at minimum" sentence in rationale. Replace the "or" at the end of the 4th line with an "and".

SG.1: Alan to review body of the report with an eye to section 3.2 of the 2013 RAA.

LE.2

• Add a clause for factoring costs/benefits in this recommendation.
• Remove “extending” , and add “conducting comparable” in the recommendation.

R10.1 Due to the many changes made to the recommendation, send out an email showing recommendation before and after changes.

R3.2Remove “in light of GDPR-driven changes,”, and remove “effectively” in the original text. Move the reference to GDPR, and other substantial policy changes into the dialogue. Add ”in light of substantial policy changes, ICANN should consider the need for education.”

CM.5 Clarify in recommendation what a “risk base approach is”. Stephanie provided: “A risk-based approach simply means that you do a risk assessment before you take an action to determine whether it’s really necessary.”

CM.3 Review team to use the GAC term, which is underserved regions, as there are some conflicting views on Global South.

CM.1 Rephrase the recommendation so that the board decide how to best implement this recommendation.

SG.1: Alan to add clarification as well as a reference to the RAA 2013 section 3.2.

LE.2

Implementation note “review should be implemented as soon as possible and at the latest within 6 months” should be reviewed to factor in section 4.6 of the ICANN Bylaws where  the ICANN Board has six months within receipt of the final report to consider the review team’s recommendations. and to consider he review team’s recommendations.

LE.1

• Implementation note “review should be implemented as soon as possible and at the latest within 6 months” should be reviewed to factor in section 4.6 of the ICANN Bylaws where  the ICANN Board has six months within receipt of the final report to consider the review team’s recommendations.
• Review this recommendation and specify what we mean by regular, by perhaps clarifying recommendation itself and also adding a little rationale to explain the two reasons that review team see for conducting such surveys and studies, which are, A, to do an ex-ante impact assessment of projected new policies or prepare a review team, or B, to evaluate new policies once they are in place. 
• Bring the above and survey questions to the EPDP (Alan) and GAC (Cathrin)

R4.2 Remove “Sanctions should be applied if significant deficiencies in RDS (WHOIS) data validation or verification are identified.” Or make it clear that we are talking about sanctions that are on the books.

R1.1 | R1.2 

• Recommendation refers to reports covering all the ongoing legislative initiatives, but in fact, should also identify previous legislative efforts across the globe.
• Implementation note “review should be implemented as soon as possible and at the latest within 6 months” should be reviewed to factor in section 4.6 of the ICANN Bylaws where  the ICANN Board has six months within receipt of the final report to consider the review team’s recommendations. 

Instead of trying to assign a high, medium or low priority, describe when RT believes this recommendation should be implemented and what the target completion date should be. Include a description of an ideal completion date recognizing some of the ongoing dependencies, and consideration should be given to resources (costs, community resources) that would be needed.

Carlton to reword BY.1

Objective 5: Safeguarding Registrant Data

• Reply to I2C comment: “we support compliance with law and support compliance with ICANN contracts.”
• Reply to BC comment “RT is specifying that they believe ICANN org must be notified of data breaches. Review team is saying use reasonable industry standards in protecting data.”

Susan/Jackie to rework some of the basic language  in this section to lead it up to that recommendation.

LE.2

• Response to ALAC comment: “The only way that they do that is their results may cause entities to take action which may enhance law enforcement activities. There is no direct connection, it depends on the details. Such enhancements may not be possible.”
• Response to I2C comment: “regular basis was our best attempt at identifying a group of people who often work in conjunction with law enforcement but not on a formal basis”.
• Response to NCSG comment, add a clause “factoring costs/benefits analysis”. Also, reword the recommendation to define what “extend” means.
• Response to DNRC comment: “RT is not clear as to how your comment responds to the possibility of polling the third parties that are not law enforcement agencies. We are not proposing noncompliance with law, we are proposing an assessment of needs.”
• Response to RrSG comment: Review team will consider extending concept  of surveys and studies but not the pool of the survey takers.

LE.1

• Reply to RySG, BC and ALAC comment: Noted, and Cathrin to work with Jackie to add clarifying text/update rationale to reflect difference between use of surveys and studies. Surveys and studies may allow us to recognize we have to make changes and that is a multi-stage project.
•  Reply to RrSG comment: RT takes this comment onboard, the need should be addressed in future iterations.
• Reply to NCSG comment: MSSI to estimate number of hours spent on the LE survey in response to NCSG request for estimated cost associated with conducting the survey.

R15.1

• RT to add a sentence to that effect, focusing on outcomes and effectiveness on an annual report basis.
• Stephanie to liaise with Jackie on adding a sentence in recommendation to amplify the impact evaluation. “The impact evaluation not being just greater accuracy for the benefit of third parties seeking data from ICANN, but response burden on the contracted parties that inevitably winds up for higher cost for end users.”

Review Team

Stephanie

Jackie

R11.2: RySG comment: Complete agreement and certainly in line with what RT  were imagining would be done, even though RT is not recommending what to change the name of the page to.

R11.1:

• ALAC comment: At this point, there is data available and lawfully available that the portal is not delivering, and RT believes  that needs to be rectified and not wait for things to change. The portal may well have to change going forward, but not delivering data currently implies broken,  RT stands by the current request to do this in a shorter term.
• BC/NCSG Comment: RT to respond to these two comments, but no action taken to change the recommendation. 

Recommendation CM.3 to be deleted. Alan to add this as a more targeted outreach in the relevant recommendation. The existence of ARS is not relevant in the future and this item will be moved under outreach.

Alan to reword CM.1 so that it does not say “the Board should negotiate …”. The goal is to ensure the recommendation is not dictating a PDP but suggesting a change somehow.

Objective 6: Contractual Compliance Actions: public comment from Domain Name Rights Coalition: Review team is not aware that we are recommending brute force enforceability and anything relating to suspending domains other than what is in our current policies. Review team is not aware of any abuse issues of the ARS because the data in the ARS is randomly sampled. The review team is not aware of the legal issues surrounding unilateral release of the domain name, it is an option given to the complainant currently.

R4.2 (DNRC): What is in the WHOIS database, whatever will be available after RDS changes have been implemented, still needs to remain accurate.

R4.1 (RrSG and NCSG comments) Volker to provide language (suggested text: “Enforce registrar obligations with regard to RDS data accuracy requirements.”) to update recommendation 4.1 based on RrSG and NCSG comments.

R4.1 (DNRC Public Comment):Report in Public Comment form “as we read this, you’re requesting that we essentially ignore certain current contractual terms. That would require policy change and that is outside of this review’s scope”

Double check whether the recommendation number R5.1 was in response to whois1 rec5 or rec 5-9. Adjust numbering as needed.

Outreach: Domain Name Rights Coalition comment: Alan to clarify that there has been a lot of internal communications within ICANN engagement groups, but it’s clear that there's a certain disconnect with the areas.

R1.1, 1.2 (NCSG): Reaffirm/strengthen strategic priority, making sure that in the implementation note, the reference to dialoging with stakeholders is there, and it should not be purely the board acting unilaterally.

Add explanation in the report on recommendations numbering

Review and update glossary

ICANN org to act on NCSG comments on draft report clarity, in preparation of the face-to-face meeting.

Review team to consider extending coverage of the recommendation R1.2  to the council as well.

Emphasize in recommendation R1.1 that the focus should be global as opposed to either just Europe or just the US.

Reword recommendation BY.1 to make sure that ““safeguard registrant data” are incorporated into it.