Root Server System Advisory Committee (RSSAC) Advice Status

Board Advice Home | ALAC Advice Status | SSAC Advice Status | GAC Advice Status


Latest Advice to the ICANN Board

As of 30 April 2020

Date Advice Document
14 April 2020 RSSAC049 Statement on Joining the Empowered Community

Board Advice Register Phases and Descriptions

Board Advice Register Phases and Descriptions

Advice Items by Phase

Phase RSSAC
Phase 1 | Receive & Acknowledge -
Phase 2 | Understand 2
Phase 3 | Evaluate & Consider 12
Phase 3 | Deferred -
Phase 4 | Implement 1
Phase 4 | Deferred -
Phase 5 | Close 1
Total Open Items 16
Total Items Closed in Past 12 Months 9

Open Advice Items

See also "Advice Status Reports" on Board Advice Home for PDF/Excel versions of the information below.

Advice Item Phase Action(s) Taken

ALAC: DNS Abuse (R-1)

(24 Dec 2019)

Phase 3 | Evaluate & Consider

ICANN org understands ALAC to advise the Board to direct ICANN org to establish a clear definition of "abuse" that is within ICANN's remit. We assume that any such definition would, without limitation, include harmful activity insofar as they intersects with the DNS and involves the use of malware, botnets, phishing, pharming, and spam (when it serves as a delivery mechanism for the other forms of DNS abuse). ICANN org further understands ALAC to advise the Board to direct org to clarify the "purposes and applications of ""abuse"" before further work is done to define DNS abuse." We are unsure, however, what ALAC's reference to "purposes and applications" of abuse is intended to mean and request clarification on this point. Is ALAC's advice to identify the characteristics of abuse (e.g., behavior that affects the DNS in specified ways) that would be within ICANN's remit? If so, ICANN org also understands ALAC to advise that once the scope and characteristics of abuse within ICANN's remit is identified, a determination should be made whether abuse definitions used by outside sources can serve as references for the ICANN community, or whether a new, outcomes-based nomenclature could be useful (including impersonation, fraud, or other types of abuse) to accurately describe problems being addressed. ICANN sent this understanding to the ALAC for review on 27 January 2020. ICANN received confirmation of understanding on 11 April 2020.

ALAC: DNS Abuse (R-2)

(24 Dec 2019)

Phase 3 | Evaluate & Consider

ICANN org understands ALAC to advise the Board to direct ICANN org to prohibit Contracted Parties from rate limiting WHOIS (eventually RDAP) requests or to require Contracted Parties to simplify the process of whitelisting. ICANN understands that ALAC believes that these changes would facilitate improved reporting on the rate of abuse in the registration ecosystem that falls within ICANN's remit. ICANN also understands that ALAC advises the Board to cause ICANN to require Contracted Parties to adopt a uniform and timely access framework for publicly available registrant data, but requests further clarification as to ALAC's expectations in this regard. Does the ALAC recommendation refer to something beyond universal adoption of RDAP and implementation of policies developed by the EPDP? With respect to implementation of this recommendation, and taking into account that ALAC is empowered to initiate discussions leading to the creation of a PDP, ICANN org understands that ALAC advises the Board either to (i) initiate a PDP process by calling for an Issues Report or (ii) cause ICANN Org to enter into voluntary negotiations with Contracted Parties to prohibit rate limiting or simplify the white-listing process and to adopt a uniform and timely framework for access to publicly available registrant data. ICANN sent this understanding to the ALAC for review on 27 January 2020. ICANN received confirmation of understanding on 11 April 2020.

ALAC: DNS Abuse (R-3)

(24 Dec 2019)

Phase 3 | Evaluate & Consider

ICANN org understands ALAC to advise the Board to direct ICANN org to establish low thresholds for identifying bad actors. We interpret this to mean that ALAC advises the Board to direct ICANN org to use DAAR to identify operators with high concentrations of malware, botnets, phishing, pharming, and spam (when it serves as a delivery mechanism for the other forms of DNS abuse) and other abusive behaviors within ICANN's remit once, with respect to the latter, agreement is reached on the scope and characteristics of abuse within ICANN's remit (either through Consensus Policy development or through voluntary contract negotiations between ICANN and Contracted Parties). ICANN also understands that ALAC advises the Board to direct ICANN org to identify and acquire data needed to publish more actionable DAAR data and to identify registrars that sponsor or registries containing high concentrations of domain registrations engaged in such behaviors. ICANN sent this understanding to the ALAC for review on 27 January 2020. ICANN received confirmation of understanding on 11 April 2020.

ALAC: DNS Abuse (R-4)

(24 Dec 2019)

Phase 3 | Evaluate & Consider

ICANN org understands ALAC to advise the Board to provide an explicit mandate to ICANN Contractual Compliance to regularly use the audit function to root out "systemic" abuse; not to regulate content, but to proactively exercise enforceability. We interpret this to mean that the ALAC is advising the Board to direct ICANN org to do so now with respect to malware, botnets, phishing, pharming, and spam (when it serves as a delivery mechanism for the other forms of DNS abuse) and, once agreement is reached on the scope and characteristics of abuse within ICANN's remit (either through Consensus Policy development or through voluntary contract negotiations between ICANN and Contracted Parties), other such behaviors. We understand that the ALAC is advising the Board to direct ICANN org to undertake regular audits of compliance with resulting obligations. ICANN sent this understanding to the ALAC for review on 27 January 2020. ICANN received confirmation of understanding on 11 April 2020.

ALAC: DNS Abuse (R-5)

(24 Dec 2019)

Phase 3 | Evaluate & Consider

ICANN org understands ALAC to advise the Board to direct ICANN org to prohibit Contracted Parties from processing registrations where the payor is or the method of payment belongs to an individual or entity other than the registrant, unless such payment methods have been approved in advance of registration. With respect to implementation of this recommendation, and taking into account that ALAC is empowered to initiate discussions leading to the creation of a PDP, ICANN Org understands that ALAC advises the Board either to (1) initiate a PDP by calling for an Issue Report on this topic or (ii) cause ICANN Org to enter into voluntary negotiations with Contracted Parties to implement ALAC's advice. ICANN sent this understanding to the ALAC for review on 27 January 2020. ICANN received confirmation of understanding on 11 April 2020.

ALAC: DNS Abuse (R-6)

(24 Dec 2019)

Phase 3 | Evaluate & Consider

With respect to implementation of this recommendation, and taking into account that ALAC is empowered to initiate discussions leading to the creation of a PDP, ICANN org understands that ALAC advises the Board either to (1) initiate a PDP by calling for an Issue Report on this topic (ii) or cause ICANN org to enter into voluntary negotiations with Contracted Parties to implement ALAC's advice. ICANN sent this understanding to the ALAC for review on 27 January 2020. ICANN received confirmation of understanding on 11 April 2020.

ALAC: DNS Abuse (R-7)

(24 Dec 2019)

Phase 3 | Evaluate & Consider

ICANN org understands ALAC to advise the Board to direct ICANN org to compel Contracted Parties to adhere to industry-wide good behavior, for example, by increasing per domain transaction fees for registrars that continually demonstrate high abuse rates. With respect to implementation of this recommendation, ICANN org understands that ALAC advises the Board to cause ICANN org to enter into voluntary negotiations with Contracted Parties regarding (i) pricing and (ii) industry best practices. We interpret "abuse" in this context to refer, for the time being, to harmful activity insofar as it intersects with the DNS and involves the use of malware, botnets, phishing, pharming, and spam (when it serves as a delivery mechanism for the other forms of DNS abuse). We understand that the scope of this could expand once agreement has been reached (either through Consensus Policy development or through voluntary contract negotiations between ICANN and Contracted Parties) on the scope and characteristics of "abuse" within ICANN's remit. ICANN sent this understanding to the ALAC for review on 27 January 2020. ICANN received confirmation of understanding on 11 April 2020.

ALAC: DNS Abuse (R-8)

(24 Dec 2019)

Phase 3 | Evaluate & Consider

ICANN org understands ALAC to advise the ICANN Board to direct ICANN org to enter into voluntary contract negotiations with Contracted Parties to implement the above advise, and to include clear enforcement language to facilitates ICANN Contractual Compliance to enforce. ICANN org further understands ALAC to advise the ICANN Board to direct ICANN org to ensure that ICANN Contractual Compliance has the tools it will need to enforce the output of any relevant Consensus Policy and/or voluntary contract negotiations. ICANN sent this understanding to the ALAC for review on 27 January 2020. ICANN received confirmation of understanding on 11 April 2020.

Enabling Inclusive, Informed and Meaningful Participation at ICANN: A Joint Statement by ALAC and GAC (R1)

(2 Nov 2017)

Phase 4 | Implement

The Information Transparency Initiative (ITI) team previewed new Announcements and Blog pages on feedback.icann.org in October 2018. Work on the authoring and content model in the document management system has begun and several content types have been completed. Since the launch of ITI in January 2018, the team has published eight blogs on icann.org and conducted several public sessions to provide the community with updates and input into the progress of this project. On 30 October 2019, the Information Transparency Initiative (ITI) team released the proposed new search experience for Board Meeting content for community input via the ITI feedback site. The improved searchability, which is core to ITI, includes: filters to narrow search by document type (Resolutions, Minutes, Agenda), Board Committees (current and former), and Board Meeting type; a date range filter; an expandable and collapsible table structure, jump-to links for upcoming Board Meetings, Year, and Month/Year; and keyword(s) search within Board Meeting content with results available by relevance (number of instances of the keyword(s)) or newest (search results ordered by publish date). Also, the ITI team is developing an improved Public Comment feature based on invaluable input from members of ICANN's Supporting Organizations and Advisory Committees. This new feature will be available for testing in late January 2020. ITI is aiming for an April 2020 soft launch of the new site. In September 2019 and October 2019, blogs were published to https://icann.org, which provided the community with an update on the project's status. On 7 February 2020, the Information Transparency Initiative (ITI) team released the proposed new Public Comment feature for community input via the ITI feedback site. The improvements include: Closed Proceedings will be searchable via filters (category and date) or keyword, Submissions will be included in search results, the most recent published Submissions and Reports will be more easily accessible, a count of the number of Public Comment Submissions will be displayed, the Submission process will include a guided form to help with the efficiency of the submission process. Alternative processes like bypassing the form and uploading a Submission as a document or emailing Submissions to the org will also be available. During the development phase of this feature, the ITI convened a small group of community participants who aided us in providing requirements, recommendations, and feedback. Additionally, we conducted demos to this same group of community stakeholders from 10-27 February. Their feedback on the implementation of the new Public Comment feature has been very positive. The ITI team is aiming for an 22 April soft launch of the new site. The existing https://icann.org will remain the definitive site during the soft launch period and will run in parallel to the new site. This soft launch period will give the ITI team the opportunity to gather community feedback about the improved site and make subsequent updates before ICANN org officially retires the current site.

Enabling Inclusive, Informed and Meaningful Participation at ICANN: A Joint Statement by ALAC and GAC (R2)

(2 Nov 2017)

Phase 4 | Implement

On 9 February 2018, the ICANN Board sent a letter to Alan Greenberg, chair of the ALAC, regarding this joint ALAC-GAC advice. Please see the letter here: https://www.icann.org/en/system/files/correspondence/chalaby-to-greenber.... In August 2019, ICANN Org shared an update that a meeting will be facilitated at ICANN66 with the ALAC, GAC, and NCSG to discuss the needs of all groups regarding simple language documentation and capacity building activities. Additionally, the co-chairs of the At-Large Consolidated Policy WG will prepare podcasts for each public comment which ALAC has agreed to prepare a statement. During ICANN66, representatives of the ALAC and NPOC, with input from GAC support staff, held an informative session on current communication procedures and tools within their respective groups. They received useful comments from Sally Costerton and Sally Newell-Cohen. Next steps will include the ALAC reaching out to the GAC and NPOC leadership on organizing an inter-sessional call early in 2020 to discuss follow up from their successful session. The ALAC will propose a joint f2f session during ICANN67 in Cancun.

ALAC: DNS Abuse (R-1)

(24 Dec 2019)

Phase 3 | Evaluate & Consider

ICANN org understands ALAC to advise the Board to direct ICANN org to establish a clear definition of "abuse" that is within ICANN's remit. We assume that any such definition would, without limitation, include harmful activity insofar as they intersects with the DNS and involves the use of malware, botnets, phishing, pharming, and spam (when it serves as a delivery mechanism for the other forms of DNS abuse). ICANN org further understands ALAC to advise the Board to direct org to clarify the "purposes and applications of ""abuse"" before further work is done to define DNS abuse." We are unsure, however, what ALAC's reference to "purposes and applications" of abuse is intended to mean and request clarification on this point. Is ALAC's advice to identify the characteristics of abuse (e.g., behavior that affects the DNS in specified ways) that would be within ICANN's remit? If so, ICANN org also understands ALAC to advise that once the scope and characteristics of abuse within ICANN's remit is identified, a determination should be made whether abuse definitions used by outside sources can serve as references for the ICANN community, or whether a new, outcomes-based nomenclature could be useful (including impersonation, fraud, or other types of abuse) to accurately describe problems being addressed. ICANN sent this understanding to the ALAC for review on 27 January 2020. ICANN received confirmation of understanding on 11 April 2020.

ALAC: DNS Abuse (R-2)

(24 Dec 2019)

Phase 3 | Evaluate & Consider

ICANN org understands ALAC to advise the Board to direct ICANN org to prohibit Contracted Parties from rate limiting WHOIS (eventually RDAP) requests or to require Contracted Parties to simplify the process of whitelisting. ICANN understands that ALAC believes that these changes would facilitate improved reporting on the rate of abuse in the registration ecosystem that falls within ICANN's remit. ICANN also understands that ALAC advises the Board to cause ICANN to require Contracted Parties to adopt a uniform and timely access framework for publicly available registrant data, but requests further clarification as to ALAC's expectations in this regard. Does the ALAC recommendation refer to something beyond universal adoption of RDAP and implementation of policies developed by the EPDP? With respect to implementation of this recommendation, and taking into account that ALAC is empowered to initiate discussions leading to the creation of a PDP, ICANN org understands that ALAC advises the Board either to (i) initiate a PDP process by calling for an Issues Report or (ii) cause ICANN Org to enter into voluntary negotiations with Contracted Parties to prohibit rate limiting or simplify the white-listing process and to adopt a uniform and timely framework for access to publicly available registrant data. ICANN sent this understanding to the ALAC for review on 27 January 2020. ICANN received confirmation of understanding on 11 April 2020.

ALAC: DNS Abuse (R-3)

(24 Dec 2019)

Phase 3 | Evaluate & Consider

ICANN org understands ALAC to advise the Board to direct ICANN org to establish low thresholds for identifying bad actors. We interpret this to mean that ALAC advises the Board to direct ICANN org to use DAAR to identify operators with high concentrations of malware, botnets, phishing, pharming, and spam (when it serves as a delivery mechanism for the other forms of DNS abuse) and other abusive behaviors within ICANN's remit once, with respect to the latter, agreement is reached on the scope and characteristics of abuse within ICANN's remit (either through Consensus Policy development or through voluntary contract negotiations between ICANN and Contracted Parties). ICANN also understands that ALAC advises the Board to direct ICANN org to identify and acquire data needed to publish more actionable DAAR data and to identify registrars that sponsor or registries containing high concentrations of domain registrations engaged in such behaviors. ICANN sent this understanding to the ALAC for review on 27 January 2020. ICANN received confirmation of understanding on 11 April 2020.

ALAC: DNS Abuse (R-4)

(24 Dec 2019)

Phase 3 | Evaluate & Consider

ICANN org understands ALAC to advise the Board to provide an explicit mandate to ICANN Contractual Compliance to regularly use the audit function to root out "systemic" abuse; not to regulate content, but to proactively exercise enforceability. We interpret this to mean that the ALAC is advising the Board to direct ICANN org to do so now with respect to malware, botnets, phishing, pharming, and spam (when it serves as a delivery mechanism for the other forms of DNS abuse) and, once agreement is reached on the scope and characteristics of abuse within ICANN's remit (either through Consensus Policy development or through voluntary contract negotiations between ICANN and Contracted Parties), other such behaviors. We understand that the ALAC is advising the Board to direct ICANN org to undertake regular audits of compliance with resulting obligations. ICANN sent this understanding to the ALAC for review on 27 January 2020. ICANN received confirmation of understanding on 11 April 2020.

ALAC: DNS Abuse (R-5)

(24 Dec 2019)

Phase 3 | Evaluate & Consider

ICANN org understands ALAC to advise the Board to direct ICANN org to prohibit Contracted Parties from processing registrations where the payor is or the method of payment belongs to an individual or entity other than the registrant, unless such payment methods have been approved in advance of registration. With respect to implementation of this recommendation, and taking into account that ALAC is empowered to initiate discussions leading to the creation of a PDP, ICANN Org understands that ALAC advises the Board either to (1) initiate a PDP by calling for an Issue Report on this topic or (ii) cause ICANN Org to enter into voluntary negotiations with Contracted Parties to implement ALAC's advice. ICANN sent this understanding to the ALAC for review on 27 January 2020. ICANN received confirmation of understanding on 11 April 2020.

Advice Items Closed in the Last 12 Months

Advice Item Close Date Action(s) Taken

RSSAC002v4: RSSAC Advisory on Measurements for the Root Server System

(12 Mar 2020)

3/23/20

The ICANN organization understands that this advisory is RSSAC002v4: RSSAC Advisory on Measurements for the Root Server System. As this item is purely informational and there is no specific action for the ICANN Board, this item will be considered closed. This understanding was sent to the SSAC on 23 March 2020

RSSAC026v2: RSSAC Lexicon

(12 Mar 2020)

3/20/20

The ICANN organization understands that this advisory is RSSAC026v2: RSSAC Lexicon. As this item is purely informational and there is no specific action for the ICANN Board, this item will be considered closed. This understanding was sent to the RSSAC on 20 March 2020.

RSSAC048: RSSAC Input on Second Security, Stability, and Resiliency (SSR2) Review Team Draft Report

(12 Mar 2020)

3/20/20

The ICANN organization understands this is the RSSAC's comment on Second Security, Stability, and Resiliency (SSR2) Review Team Draft Report. The respective public comment period closes on 20 March 2020. A Report of Public Comments will be published on 03 April 2020 and this comment will be included in that consideration https://www.icann.org/public-comments/ssr2-rt-draft-report-2020-01-24-en. There is no action for the ICANN Board. This understanding was sent to the RSSAC on 20 March 2020.

RSSAC046: RSSAC Statement on IANA's Proposal for Future Root Zone KSK Rollovers

(29 Jan 2020)

2/5/20

The ICANN organization understands this is the RSSAC's comment on IANA's Proposal for Future Root Zone KSK Rollovers. The respective public comment period closed on 31 January 2020. A Report of Public Comments will be published on 21 February 2020 and this comment will be included in that consideration (https://www.icann.org/public-comments/proposal-future-rz-ksk-rollovers-2...). There is no action for the ICANN Board. This understanding was sent to the RSSAC on 05 February 2020.

RSSAC044: Report from the RSSAC October 2019 Workshop

(29 Oct 2019)

12/19/19

The ICANN organization understands that RSSAC044 is a high-level summary of the outcomes of the Root Server System Advisory Committee (RSSAC) eighth workshop held from 01 October 2019 to 03 October 2019. There is no action for the ICANN Board. ICANN sent this understanding to the RSSAC for review on 05 Nov 2019. This item is considered complete as of the RSSAC's confirmation of understanding on 18 Dec 2019.

RSSAC045: RSSAC Statement on Threat Mitigation for the Root Server System

(3 Dec 2019)

12/18/19

ICANN understands that this is the Root Server System Advisory Committee's (RSSAC) Statement on Threat Mitigation for the Root Server System. The RSSAC would like to formally endorse the work of the RSOs on Threat Mitigation for the Root Server System.2 Furthermore, the RSSAC regards the ICANN Board's request for input fulfilled. There is no action for the ICANN Board. ICANN sent this understanding to the RSSAC for review on 16 Dec 2019. This item is considered complete as of the RSSAC's confirmation of understanding on 18 Dec 2019.

RSSAC000v4: RSSAC Operational Procedures

(23 Oct 2019)

11/19/19

ICANN understands that this is the Operational Procedures of the Root Server System Advisory Committee (RSSAC). This documents how the RSSAC will carry out its work, with the rationale for processes where it seems helpful. In case of conflict with the ICANN Bylaws, the ICANN Bylaws take precedence. There is no action for the ICANN Board. ICANN sent this understanding to the RSSAC for review on 18 Nov 2019. This item is considered complete as of the RSSAC's confirmation of understanding on 19 Nov 2019.

RSSAC043: Report from the RSSAC April 2019 Workshop

(4 Jun 2019)

7/10/19

The ICANN organization understands that RSSAC043 is a high-level summary of the outcomes of the Root Server System Advisory Committee (RSSAC) sixth workshop held from 23 April 2019 to 25 April 2019. There is no action for the ICANN Board. ICANN sent this understanding to the RSSAC on 10 Jul 2019.

RSSAC042: RSSAC Statement on Root Server Operator Independence

(17 May 2019)

6/11/19

The ICANN org understands RSSAC042 illustrates important aspects of Root Server Operator (RSO) independence: organizational independence, financial independence, architecture and engineering design, and network operations and administration. RSO independence is a vital quality of the RSS that must be preserved for the purposes recognized in this publication and to ensure the stability, security, and resilience of the DNS. As RSSAC042 does not contain any recommendations for the ICANN Board, the ICANN Org understands that there is no action for the ICANN Board and the item is closed. ICANN sent this understanding to the RSSAC for review on 11 Jun 2019.