[Rds-whois2-implementation-shepherds] Key takeaways from discussions with the RDS-WHOIS2 Implementation Shepherds

[Larisa B. Gurnick]

Sent on behalf of Chris Disspain and the RDS Board Caucus Group

Dear RDS-WHOIS2 Review Team Implementation Shepherds,

The RDS Board Caucus Group would like to thank you for the fruitful discussions held on 19 December 2019 and 29 January 2020. The clarifications are very helpful to understand the intent of recommendations, as well as the context in which they were formulated.

In addition to the input provided by Alan Greenberg (Chair of the RDS-WHOIS2-RT) in advance of the 29 January 2020 call, in response to the preliminary assessment<http://mm.icann.org/pipermail/rds-whois2-implementation-shepherds/attachments/20200122/96e85613/RDS-WHOIS2PreliminaryReviewRecsAnalysis17Jan20201-0001.docx>, the RDS Board Caucus Group understands the main takeaways from the exchange and discussion to be as follows.

Please note that the table of RDS-WHOIS2 recommendations is included below, for ease of reference.

The RDS Board Caucus Group believes the context provided on R4.1, R4.2, R5.1, R11.1, SG.1, CC.1, CC.2, CC.4 and BY.1 (as noted in the sections  below) will be helpful in guiding the Board towards an appropriate consideration.

With respect to recommendation R4.1 that ICANN Contractual Compliance be directed to proactively monitor and enforce registrar obligations with regard to RDS data accuracy to look for and address systemic issues: The preliminary assessment indicated that ICANN org currently proactively monitors registrar obligations as well as uses risk-based analysis in its enforcement activities. The RDS Board Caucus Group notes the RDS-WHOIS2 Implementation Shepherds’ clarification that the intent of the recommendation stems from the lack of clarity on whether ICANN already performs this operation. As indicated in the preliminary assessment, there are challenges in undertaking accuracy studies due to the lack of publicly available registration data. Per the discussion on the call, feasibility of the recommendation might potentially be impacted by Expedited Policy Development Process (EPDP) related work. With that interdependency, the recommendation appears to be appropriate for consideration after Board action on the EPDP recommendations.

With regards to recommendations R4.2 on detecting patterns of failure and R5.1 on monitoring accuracy and/or contactability: As noted in the preliminary assessment, the Accuracy Reporting System (ARS) has been on hold and ICANN org has not published ARS reports since the Board adoption of the Temporary Specification, as there are changes to gTLD registration data requirements and the public availability of such data. Moreover, there are also potential timing issues for recommendation R4.2 with the work of the EPDP Phase 2 on access to non-public data. The RDS Board Caucus notes the RDS-WHOIS2 Implementation Shepherds’ views that the EPDP Phase 1 gives ICANN org the ability to access non-public data for audits to perform something comparable to ARS. The RDS Board Caucus sees a dependency on, or an interaction with, EPDP Phase 2 on access to nonpublic data and appears to be appropriate for consideration after Board action on the EPDP Phase 2 recommendations.

Relative to R11.1 on the definition of metrics or Service Level Agreements (SLAs) and the common interface: Feasibility challenges were identified, as documented in the preliminary assessment. ICANN org cannot collect or log any information relating to what data is being returned from search queries because it does not touch the data. Moreover, the proposed metric #4 does not appear to be feasible even if ICANN were to handle the registration data. In the preliminary assessment ICANN org also identified questions pertaining to the metrics. The RDS Board Caucus Group notes the RDS-WHOIS2 Implementation Shepherds’ clarification that the recommendation does not apply to the current version of the portal. In July 2019, ICANN org launched a Registration Data Access Protocol (RDAP) lookup service. This new lookup service standardized data access and query response formats and allowed for ICANN to be removed from the transaction of a registration data lookup. The RDS-WHOIS2 Implementation Shepherds added that while metrics included in the recommendation had meaning in the former version, it is now unclear whether they are applicable to the current version. The RDS Board Caucus notes that the recommendation is not applicable to the existing system and will therefore base its recommendation to the Board on the clarification received. Separately, the RDS Board Caucus Group understands that ICANN org will look into the concerns raised by the Implementation Shepherds regarding educating users on the output of the current lookup tool, but understands this is separate from the recommendation provided to the Board in the Final Report.

Regarding recommendations CC.1 and SG.1 that suggest policy development or contractual amendments: As articulated in the preliminary assessment, the Board cannot unilaterally impose new obligations on contracted parties through acceptance of a recommendation. The Registry Agreement (RA) and Registrar Accreditation Agreement (RAA) can be modified either via a policy development process or as a result of contract negotiations. In either case, the Board does not have the ability to ensure a particular outcome. The RDS Board Caucus Group notes the RDS-WHOIS2 Implementation Shepherds’ clarification that the RDS-WHOIS2-RT expects the Board to take appropriate action either via a PDP or through directing contract negotiations. It is not expected that specific contract negotiations be initiated in response to an individual recommendation; rather the contract negotiation approach could be pursued the next time contracts are negotiated.

With respect to recommendation CC.2 on the ICANN Board initiating action to ensure all gTLD domain name registration directory entries contain at least one full set of either registrant or admin contact details comparable: The RDS-WHOIS2 Implementation Shepherds were asked to clarify what was meant by “at least one full set of either registrant or admin contact details,” and whether the recommendation has any relationship to recommendation 29 of the EPDP Phase 1 Final Report. The RDS-WHOIS2 Implementation Shepherds confirmed that CC.2 replicates recommendation 29 of the EPDP Phase 1 Final Report. The RDS Board Caucus Group will consider this clarification as part of its recommendation to the Board.

With respect to recommendation CC.4 that the ICANN Board recommend the GNSO adopt a risk-based approach: This recommendation was labeled, in the preliminary assessment, as intended for the GNSO, with request to the Implementation Shepherds for clarification on what additional factors were being requested. The RDS-WHOIS2 Implementation Shepherds confirmed that it would be appropriate for this recommendation to be passed through to the GNSO.

On recommendation BY.1 that suggests amendments to the RDS Review related Bylaw language: In the preliminary assessment, the RDS Board Caucus Group sought clarification on whether the RDS-WHOIS2 consulted on this with the ATRT3, and expressed concerns on the suggested removal of the OECD guidelines. Removal of this reference could significantly broaden the scope of work for future RDS teams, and increase the level of expertise needed. Moreover, keeping up-to-date cross-jurisdictional surveys of data protection and data transfer laws could be quite resource-intensive and entail high maintenance requirements. The RDS-WHOIS2 Implementation Shepherds clarified that as the review teams did not exist concurrently, there was no dialogue with the ATRT3 on this particular recommendation and that all specific review teams have an opportunity to provide this feedback, as articulated in the ICANN Bylaws. The RDS-WHOIS2 Implementation Shepherds consider the OECD guidelines as obsolete and indicated that this was not an attempt at drafting Bylaw language.

Clarifications received on R1.1, R1.2, R1.3, R3.2, R10.1, and CC.2  (as summarized below) informed the RDS Board Caucus Group on how the RDS-WHOIS2 Implementation Shepherds envision implementation.

With respect to recommendations R1.1 and R1.2 that a call for forward-looking mechanism/process that monitors legislative and policy developments: as indicated in the preliminary assessment, the Board has already endorsed this work more broadly through the charter for the legislative and regulatory tracking initiative in January 2019, through the FY20 goals the Board set for ICANN’s President and CEO, and the priorities the Board has identified for itself. Recognizing that there is an existing mechanism and process in place, clarification was sought on how the recommendations should be considered in relation to what ICANN org already has in progress. The RDS-WHOIS2 Implementation Shepherds clarified that these recommendations could be considered as implemented/complete, provided that the existing mechanism is functioning.

Relative to recommendation R1.3 on transparency of a Board working group’s work on RDS: As the recommendation could have potential implications for Board governance matters, and since Board Working Groups do not have delegated authority by the Board, the RDS-WHOIS2 Implementation Shepherds were invited to clarify the type of reporting and records that were envisioned. The RDS-WHOIS2 Implementation Shepherds indicated that the intent of this recommendation is to ensure that the Board is considering issues; i.e. there is no need for formal minutes, but rather documentation that activities are taking place.

With regard to recommendation R3.2 on identifying groups outside of those that routinely engage with ICANN org, for targeted outreach: The need for further dialogue on the objectives or goals of the expected engagement was expressed in the preliminary assessment. The assessment also suggested that efficiencies can be gained by pairing engagement efforts related to RDS with education and awareness related to the implementation of the Registration Data Access Protocol (RDAP). Recognizing a dependency with EPDP, the RDS-WHOIS2 Implementation Shepherds indicated their position that ICANN will have an obligation to ensure registrants understand how information is being treated, including the associated rules. The RDS-WHOIS2 Implementation Shepherds added that the web educational material contemplated to be produced in implementation of R3.2 would also likely address much of what is needed to implement R3.1. The RDS-WHOIS2 Implementation Shepherds noted that it will require thinking to understand who might benefit from more knowledge about the new RDS and that it is currently unclear whether such consideration is feasible at this time. Recognizing that the nature of outreach is going to change, the RDS-WHOIS2 Implementation Shepherds emphasized that the education should not be about ticking boxes, but efforts should rather be based on clear merit and added value.

Relative to the Privacy Proxy Services Accreditation Issues (PPSAI) Policy, and the recommendation that the Board should ensure an amendment to the 2013 RAA (R10.1): As articulated in the preliminary assessment, proposed revisions or negotiations can only occur once a calendar year, and there are other negotiations in process. The RDS-WHOIS2 Implementation Shepherds clarified that the 31 December 2019 date listed in the recommendation is inaccurate,

The above is a summary of what the RDS Board Caucus Group heard on the call. In the event there is a different understanding or interpretation, please raise it. Additionally, the RDS Board Caucus Group also understands that Alan Greenberg took an action to circle back with the full team of RDS-WHOIS2 Implementation Shepherds to address the request for clarification on LE.2: i.e. who the user groups are, and that feedback is still outstanding.

The RDS Board Caucus Group thanks you again for your time and dedication.

Best,
Chris Disspain
on behalf of the RDS Board Caucus Group


REC #

Recommendation

RT Priority

R1.1

To ensure that RDS (WHOIS) is treated as a strategic priority, the ICANN Board should put into place a forward-looking mechanism to monitor possible impacts on the RDS (WHOIS) from legislative and policy developments around the world.

High

R1.2

To support this mechanism, the ICANN Board should instruct the ICANN organization to assign responsibility for monitoring legislative and policy development around the world and to provide regular updates to the ICANN Board.

High

R1.3

The ICANN Board, in drafting the Charter of a Board working group on RDS, should ensure the necessary transparency of the group’s work, such as by providing for records of meetings and meeting minutes, to enable future review of its activities.

Medium

R3.1

The ICANN Board should direct the ICANN organization to update all of the information related to RDS (WHOIS) and by implication other information related to the registration of second-level gTLDs domains. The content should be revised to make the information readily accessible and understandable, and it should provide details of when and how to interact with ICANN organization or contracted parties. Although not the sole focus of this recommendation, interactions with ICANN organization Contractual Compliance, such as when filing WHOIS Inaccuracy Reports, should be a particular focus. The revision of this web documentation and instructional material should not be undertaken as a purely internal operation but should include users and potentially focus groups to ensure that the final result fully meets the requirements. The resultant outward facing documentation of registrant and RDS (WHOIS) issues should be kept up to date as changes are made to associated policy or processes.

Medium

R3.2

With community input, the ICANN Board should instruct the ICANN organization to identify groups outside of those that routinely engage with ICANN organization, and these should be targeted through RDS (WHOIS) outreach. An RDS (WHOIS) outreach plan should then be developed, executed, and documented. There should be an ongoing commitment to ensure that as RDS (WHOIS) policy and processes change, the wider community is made aware of such changes. WHOIS inaccuracy reporting was identified as an issue requiring additional education and outreach and may require a particular focus. RDS (WHOIS) outreach should be included when considering communications in underserved regions. The need for and details of the outreach may vary depending on the ultimate General Data Protection Regulation (GDPR) implementation and cannot be detailed at this point.

High

R4.1

The ICANN Board should initiate action to ensure ICANN Contractual Compliance is directed to proactively monitor and enforce registrar obligations with regard to RDS (WHOIS) data accuracy using data from incoming inaccuracy complaints and RDS accuracy studies or reviews to look for and address systemic issues. A risk-based approach should be executed to assess and understand inaccuracy issues and then take the appropriate actions to mitigate them.

High

R4.2

The ICANN Board should initiate action to ensure that ICANN Contractual Compliance is directed to cross-reference existing data from incoming complaints and studies such as the ARS to detect patterns of failure to validate and verify RDS (WHOIS) data as required by the RAA. When such a pattern is detected, compliance action or an audit should be initiated to review compliance of the Registrar with RDS (WHOIS) contractual obligations and consensus policies.

High

R5.1

The Accuracy Reporting System, which was instituted to address concerns regarding RDS (WHOIS) contact data accuracy, has demonstrated that there is still an accuracy concern and therefore such monitoring must continue. ICANN organization should continue to monitor accuracy and/or contactability through either the ARS or a comparable tool/methodology.

High

R10.1

The Board should monitor the implementation of the PPSAI. If the PPSAI policy does not become operational by 31 December 2019, the ICANN Board should ensure an amendment to the 2013 RAA (or successor documents) is proposed that ensures that the underlying registration data of domain name registrations using Privacy/Proxy providers affiliated with registrars shall be verified and validated in application of the verification and validation requirements under the RAA unless such verification or validation has already occurred at the registrar level for such domain name registrations.

Low

R10.2

Reviewing the effectiveness of the implementation of WHOIS1 Recommendation #10 should be deferred. The ICANN Board should recommend that review be carried out by the next RDS (WHOIS) Review Team after PPSAI Policy is implemented

Low

R11.1

The ICANN Board should direct the ICANN organization to define metrics or SLAs to be tracked and evaluated to determine consistency of results of queries and use of any common interface (existing or future) used to provide one-stop access to registration data across all gTLDs and registrars/resellers. Specific metrics that should be tracked for any such common interface include:
◉ How often are RDS (WHOIS) fields returned blank?
◉ How often is data displayed inconsistently (for the same domain name), overall and per gTLD?
◉ How often does the tool not return any results, overall and per gTLD?
◉ What are the causes for the above results?

Low

R11.2

Reviewing the effectiveness of the implementation of Recs #12-14 should be deferred. The ICANN Board should recommend that review to be carried out by the next RDS Review Team after RDAP is implemented, and the translation and transliteration of the registration data launches

Low

R15.1

The ICANN Board should ensure that implementation of RDS-WHOIS2 Review Team recommendations is based on best practice project management methodology, ensuring that plans and implementation reports clearly address progress, and applicable metrics and tracking tools are used for effectiveness and impact evaluation.

Medium

LE.1

The ICANN Board should resolve that ICANN organization conduct regular data gathering through surveys and studies to inform a future assessment of the effectiveness of RDS (WHOIS) in meeting the needs of law enforcement. This will also aid future policy development (including the current Temporary Specification for gTLD Registration Data Expedited Policy Development Process and related efforts).

High

LE.2

The ICANN Board should consider conducting comparable surveys and/or studies (as described in LE.1) with other RDS (WHOIS) users working with law enforcement on a regular basis.

High

SG.1

The ICANN Board should require that the ICANN org, in consultation with data security and privacy expert(s), ensure that all contracts with contracted parties (to include Privacy/Proxy services when such contracts exist) include uniform and strong requirements for the protection of registrant data and for ICANN to be notified in the event of any data breach. The data security expert(s) should also consider and advise on what level or magnitude of breach warrants such notification. In carrying out this review, the data security and privacy expert(s) should consider to what extent GDPR regulations, which many but not all ICANN contracted parties are subject to, could or should be used as a basis for ICANN requirements. The ICANN Board should initiate action intended to effect such changes. The ICANN Board should consider whether and to what extent notifications of breaches that it receives should be publicly disclosed.

Medium

CC.1

The ICANN Board should initiate action intended to ensure that gTLD domain names suspended due to RDS (WHOIS) contact data which the registrar knows to be incorrect, and that remains incorrect until the registration is due for deletion, should be treated as follows: (1) The RDS (WHOIS) record should include a notation that the domain name is suspended due to incorrect data; and (2) Domain names with this notation should not be unsuspended without correcting the data

High

CC.2

The ICANN Board should initiate action intended to ensure that all gTLD domain name registration directory entries contain at least one full set of either registrant or admin contact details comparable to those required for new registrations under the 2013 RAA (or any subsequent version thereof) or applicable policies.

Medium

CC.3

The ICANN Board should take steps to ensure that ICANN Contractual Compliance is adequately resourced factoring in any increase in workload due to additional work required due to compliance with GDPR or other legislation/regulation.

High

CC.4

The ICANN Board should recommend the GNSO adopt a risk-based approach to incorporating requirements for measurement, auditing, tracking, reporting and enforcement in all new RDS policies.

Low

BY.1

The ICANN Board should take action to extend the reference to “safeguarding registrant data” in ICANN Bylaws section 4.6(e)(ii) and replace section 4.6(e)(iii) of the ICANN Bylaws (which refers to the OECD Guidelines) with a more generic requirement for RDS (WHOIS) Review Teams to assess how well RDS (WHOIS) policy and practice addresses applicable data protection and cross border data transfer regulations, laws and best practices.

Medium


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/rds-whois2-implementation-shepherds/attachments/20200224/bbb90594/attachment-0001.html>