Dear team, Amendments and comments included in google docs here for review and discussion: https://docs.google.com/document/d/1WTnaEk2pW0V85FRXk1uUN4O-co7DcDIXb_9_-1MCqts/edit#<https://docs.google.com/document/d/1WTnaEk2pW0V85FRXk1uUN4O-co7DcDIXb_9_-1MCqts/edit> Also see proposed response to public comments on action taken in red: BC 29 Focus on Privacy and SSR Measurements and Improving Policies Based on Those Measurements The BC concurs with this recommendation. Duly Noted SSAC 29 Focus on Privacy and SSR Measurements and Improving Policies Based on Those Measurements (3.4.9) Why is the topic of "Privacy" in Workstream 4 a Future Challenge? This would conventionally be classified as a current topic. Does the SSR2 RT have evidence that ICANN org is not adequately focusing on Privacy and SSR Measurements already? The recommendation implies that the review has taken the position that the level of focus and attention is inadequate, but has not provided any material in the report that substantiates such a conclusion. Duly noted. The observation was made in the context of while this is a current issue, as data privacy evolves there needs to be a dedicated focus on ensuring ICANN remains abreast of emerging challenges in data privacy including evolving compliance requirements. The growth of data is exponential and increasing security vulnerabilities has led to data breaches. The logic flows from the weaving together of security measures with managing risk factors such as data breaches. In some organizations the role of a Chief Data Officer has worked alongside the Chief Information Security Officer which has been mentioned in the SSR2 Recommendation 6. SSAC 29 Focus on Privacy and SSR Measurements and Improving Policies Based on Those Measurements (3.4.10) The report notes in the section relating to Rationale and Findings on Privacy, that "ICANN org, in having a privacy policy that covers registration information and having Bylaws that requires it enforce its own policies, is in conflict with their statement that ICANN org is not responsible for data protection and privacy." This is an unusual 17 interpretation of the ICANN statement, in that the disclaimer is about the general state of privacy on the Internet while the org does have a privacy policy relating to data gathered by the org. Noted and language amended to reflect accuracy in the interpretation of the relevant references. RySG 29 Focus on Privacy and SSR Measurements and Improving Policies Based on Those Measurements While the RySG supports ICANN tracking new technology and evolving privacy laws and regulations as part of its overall risk management management, the RySG believes that much of this recommendation is out of scope for SSR2. Specifically, we oppose the creation of specialized compliance officers to micromanage contracted party operations. Registries and registrars are responsible for complying with all local laws - ICANN's compliance team doesn't need to duplicate the function of local law enforcement. The RySG also notes its support for recommendation 31. SSR2 recognizes the close inter-relationship between security and privacy which is why it was identified as a key component that data privacy not be micro managed but managed in order to ensure compliance is ensured whenever there are related regulations and data breaches minimized in collaboration with ICANN org security team. IPC 29 The IPC is supportive of this recommendation, while noting that the following recommendation is unclear and potentially subject to unintended interpretation in implementation: 'ICANN org's DPO should also be responsible for external DNS PII'. Noted and clarification provided as the intent is to ensure that ICANN org is being proactive in identifying and complying with all the laws and regulations that govern data capture, use, retention, security, and disposal SSAC 29.1 ICANN org should monitor and regularly report on the privacy impact of technologies like DoT (DNS over TLS) and DoH (DNS over HTTPS). (3.4.11) In terms of using the SMART criteria for the report's recommendations it is not clear how this particular recommendation is directly relevant to ICANN. The manner of DNS name resolution between stub and recursive name resolvers on the Internet, and the protocols used to perform such resolution appears to fall outside the scope of ICANN's activities and authority. Because of this question of direct relevance to ICANN's scope and mission, this action may be more appropriately included as part of the report's set of "suggestions," and listed on the basis of the broader topic of potential actions by ICANN org that would provide value to the community through the provision of assessments of aspects of the larger environment of the domain name space and its evolving use. The SSAC is aware of current activity within both ICANN org and the ICANN community in this space already, including a recently published SSAC study on the implications of DNS over HTTPS and DNS over TLS, and there is some lack of clarity 18 as to how this recommendation differs from current practice. This suggestion is supported as SSAC sees value but noted it misplacement. SSR2 RT has taken this onboard for evaluation. ICANN Board 29.1 ICANN org should monitor and regularly report on the privacy impact of technologies like DoT (DNS over TLS) and DoH (DNS over HTTPS). If the SSR2 RT believes additional monitoring and reporting of areas that are within ICANN org's remit are needed, the Board would encourage the SSR2 RT to provide clear statements of what issues or risks exist from the current operational model, how the SSR2 RT recommendation will address them, and what relevant metrics could be applied to assess implementation. SSR2 RT notes this and the intent of the recommendation was to ensure that privacy concerns were specifically addressed. RrSG 29.1 ICANN org should monitor and regularly report on the privacy impact of technologies like DoT (DNS over TLS) and DoH (DNS over HTTPS). For recommendation 29.1, this appears to be outside of ICANN's remit. SSR2 RT has noted this comment and has it under evaluation. SSAC 29.2 ICANN org's consensus policies and agreements with registry operators and registrars should, therefore, have clauses to reflect compliance with these while ensuring that the DNS is not fragmented because of the need to maintain/implement minimum requirements governing the collection, retention, escrow, transfer, and display of registration data, which includes contact information of the registrant, administrative, and technical contacts as well as technical information associated with a domain name. (3.4.12) The introduction of the concept of DNS "fragmentation" makes no clear sense in this context. The recommendation should phrase the concern in a different way that avoids the particular term "fragmentation", or explain the concept of "fragmentation" in detail. Amended to provide clarity. RrSG 29.2 ICANN org's consensus policies and agreements with registry operators and registrars should, therefore, have clauses to reflect compliance with these while ensuring that the DNS is not fragmented because of the need to maintain/implement minimum requirements governing the collection, retention, escrow, transfer, and display of registration data, which includes contact information of the registrant, administrative, and technical contacts as well as technical information associated with a domain name. The RrSG needs additional information about recommendation 29.2, as it is not clear what problem or concern this addressing- those obligations already exist. Amended to provide clarity. ICANN Org 29.2 SSR2 Recommendation 29.2: "with these" Requests for clarification of terms Amended to provide clarity. ICANN Board 29.4 ICANN org's DPO should also be responsible for external DNS PII. The DPO should provide guidance to managers and stakeholders regarding responsibilities and procedures and monitor and report on relevant technical developments. It is unclear to the Board what it means for ICANN to "be responsible for external DNS PII." SSR2 RT notes this and recommended for deletion. [OAS.org]<http://www.oas.org/> Sincerely Kerry-Ann Barrett Cybersecurity Program Officer Secretariat of the Inter-American Committee against Terrorism (CICTE) Secretariat for Multidimensional Security (SMS) Organization of American States 1889 F Street NW Washington D.C. 20006 [http://www.oas.org/en/sms/signature_images/phone.png] (202) 370 4675 - [http://www.oas.org/en/sms/signature_images/fax.png] (202) 458 3857 www.oas.org/cyber<http://www.oas.org/cyber> @KerryOAS<https://twitter.com/KerryOAS>| @OEA_Cyber<https://twitter.com/OEA_Cyber> Register to our distribution list here!<http://oas.us11.list-manage.com/subscribe?u=353ff0663258ae5a775d460db&id=10a...>