AT-LARGE GATEWAY

At-Large Website

ALAC

RALOs

At-Large Regional Policy Engagement Program (ARPEP)

At-Large Governance

At-Large Reports

Policy Comments & Advice

Working Groups

ICANN Meetings

At-Large Summit (ATLAS III)

At-Large Review Implementation Plan Development

ALAC and RALO Elections, Selections, and Appointments

At-Large Priority Activities - 2021

Public Comment CloseStatement
Name 

Status

Assignee(s)

Call for
Comments Open		Call for
Comments
Close 		Vote OpenVote CloseDate of SubmissionStaff Contact and EmailStatement Number

10 June 2018

Draft Final Report of the RSSAC2 Review

ADOPTED

14Y, 0N, 0A

Alan Greenberg

Seun Ojedeji

05 June 2018

10 June 2018

11 June 2018

14 June 2018

10 June 2018

Lars Hoffmann
lars.hoffmann@icann.org

AL-ALAC-ST-0618-01-01-EN

Hide the information below, please click here 

Statement on At-Large Website

Brief Overview

Purpose: The purpose of this public comment is to solicit feedback on the Draft Final Report[PDF, 2.63 MB] of the second Root Server System Advisory Committee Review (RSSAC2).

Current Status: Interisle, the independent examiner conducting the RSSAC2 Review, has published its Draft Final Report for public comment. The Draft Final Report contains both an assessment of the RSSAC and recommendations for improving its operations. This public comment proceeding follows the publication of the Assessment Report, which included findings that were discussed with the community via several consultations.

Next Steps: The Draft Final Report will be available for public comment for 40 days. A webinar will be hosted by the independent examiner, Interisle, on 9 May 2018 at 20:00 UTC (see here for more information). Input received from the public comment and webinar will be considered by Interisle for inclusion in the Final Report. The Final Report is expected to be published in July 2018.

Section I: Description and Explanation

Interisle, the independent examiner conducting the second review of the ICANN Root Server System Advisory Committee (RSSAC2), is seeking feedback on its Draft Final Report [PDF, 2.63 MB].

An independent review of the RSSAC is mandated by ICANN's Bylaws and is part of ICANN's commitment to its own evolution, improvement, accountability, and transparency. Interisle began its work in September 2017. A Final Report is expected to be published in July 2018.

As with all Organizational Reviews, the RSSAC2 Review is following a two-phased approach in which the independent examiner first completes its assessment and then makes recommendations to address the findings noted during the assessment. This approach is expected to contribute to more useful and relevant recommendations by providing an opportunity for the community and the independent examiner to discuss what works and what needs improvement before the independent examiner develops recommendations to address the observed situations.

Section II: Background

The purpose of the RSSAC Review is to determine (i) whether the RSSAC has a continuing purpose in the ICANN structure, (ii) if so, whether any change in structure or operations is desirable to improve its effectiveness and (iii) whether the RSSAC is accountable to its constituencies, stakeholder groups, organizations and other stakeholders. The review will also assess assessing the effectiveness of the improvements resulting from the previous reviewconducted in 2008.

The RSSAC advises the ICANN Board and community on matters relating to the operation, administration, security, and integrity of the root server system, as outlined in its charter from the ICANN Bylaws. The RSSAC consists of representatives from the organizations responsible for operating global root name service. The RSSAC also consists of representatives of the organizations responsible for the maintenance of the authoritative root zone as non-voting members. Liaisons from external organizations and groups also participate as non-voting members. Learn more about the RSSAC.

Section III: Relevant Resources



Section IV: Additional Information


Section V: Reports


FINAL VERSION TO BE SUBMITTED IF RATIFIED

The final version to be submitted, if the draft is ratified, will be placed here by upon completion of the vote. 


FINAL DRAFT VERSION TO BE VOTED UPON BY THE ALAC

The final draft version to be voted upon by the ALAC will be placed here before the vote is to begin.

The ALAC appreciates the opportunity to comment on the Independent Review of the ICANN Root Server System Advisory Committee (RSSAC). The ALAC is responsible for representing the interests of Internet Users within ICANN, and there are few parts of the Internet as critical as the Root Server System in allowing Internet Users to enjoy and benefit from the Internet

Recommendation 1

Modify the RSSAC membership criteria to allow the RSSAC to recruit a variety of skills, perspectives, and interests that include but are not limited to those available from the root server operator organizations.

The ALAC supports the intent of this recommendation and adding new members may well be both possible and desirable. But the ALAC is sensitive to rules being imposed which may be difficult to implement. Rather than suggest that additional “members” are the answer, consideration should be given to altering Recommendation 1 to allow forms other than "membership" while achieving the same aim of ensuring that the RSSAC has all of the skills and perspectives to properly fulfill its function.

Recommendation 2

Resolve the apparent mismatch between the charter and operational procedures of the RSSAC and the requirements and expectations of the ICANN Board and Community for interaction with the root server system.

The following paragraph from the report is critical:

To the extent that ICANN either is or is widely held to be responsible for the reliable and secure operation of the root, it requires a relationship with the serving side of the root registry that extends beyond the “exchange of information” limits of the RSSAC charter. The nature of that relationship is primarily an RSO/Board issue, not an RSSAC issue, and therefore out of scope for the present review. But the apparent mismatch between what ICANN needs from an interface to the root server system and what the RSSAC is currently chartered to provide suggests that either the RSSAC scope should be expanded or the attention and expectations of the Board and Community should be explicitly redirected away from the RSSAC to some other group.

Although there is no clear way to address the issue, since ICANN has a part to play in ensuring that the DNS is a trusted and reliable resource, then it must have the ability to interact with all players who have a role in carrying that out and that must include the Root Server Operators. Simply lowering expectations does not address the issue. Whether this is done by widening the scope of the RSSAC or through some other mechanism is less important than noting that the current chasm must be bridged.

Recommendation 5

Engage more actively with the rest of ICANN and its Community.

The ALAC welcomes and supports this recommendation that the RSSAC interacts more actively with the rest of the ICANN Community.


FIRST DRAFT SUBMITTED

The first draft submitted will be placed here before the call for comments begins.

The ALAC appreciates the opportunity to comment on the Independent Review of the ICANN Root Server System Advisory Committee (RSSAC). The ALAC is responsible for representing the interests of Internet Users within ICANN, and there are few parts of the Internet as critical as the Root Server System in allowing Internet Users to enjoy and benefit from the Internet

Recommendation 1

Modify the RSSAC membership criteria to allow the RSSAC to recruit a variety of skills, perspectives, and interests that include but are not limited to those available from the root server operator organizations.

The ALAC supports the intent of this recommendation and adding new members may well be both possible and desirable. But the ALAC is sensitive to rules being imposed which may be difficult to implement. Rather than suggest that additional “members” are the answer, consideration should be given to altering Recommendation 1 to allow forms other than "membership" while achieving the same aim of ensuring that the RSSAC has all of the skills and perspectives to properly fulfill its function.

Recommendation 2

Resolve the apparent mismatch between the charter and operational procedures of the RSSAC and the requirements and expectations of the ICANN Board and Community for interaction with the root server system.

The following paragraph from the report is critical:

To the extent that ICANN either is or is widely held to be responsible for the reliable and secure operation of the root, it requires a relationship with the serving side of the root registry that extends beyond the “exchange of information” limits of the RSSAC charter. The nature of that relationship is primarily an RSO/Board issue, not an RSSAC issue, and therefore out of scope for the present review. But the apparent mismatch between what ICANN needs from an interface to the root server system and what the RSSAC is currently chartered to provide suggests that either the RSSAC scope should be expanded or the attention and expectations of the Board and Community should be explicitly redirected away from the RSSAC to some other group.

Although there is no clear way to address the issue, since ICANN has a part to play in ensuring that the DNS is a trusted and reliable resource, then it must have the ability to interact with all players who have a role in carrying that out and that must include the Root Server Operators. Simply lowering expectations does not address the issue. Whether this is done by widening the scope of the RSSAC or through some other mechanism is less important than noting that the current chasm must be breached.

Recommendation 5

Engage more actively with the rest of ICANN and its Community.

The ALAC supports and welcomes the recommendation regarding communication between RSSAC and other part of the ICANN community.

18 Comments

  1. Seun Ojedeji

    Here is what I have as a draft for edits/comments ALAC appreciates the opportunity to comment on the Independent Review of the ICANN Root Server System Advisory Committee (RSSAC). We will like to raise a concern and a comment on the review - RSSAC is a special purpose committee within ICANN community, while we understand and agree with the recommendation to incoporate non-RSO anycast instance providers and public DNS resolvers, we are concerned that incoporating other part of the ICANN community into RSSAC may create some problems. Perhaps having such setup where those other SO/AC within ICANN has an opportunity to have Liasions to the RSSAC can be useful but certainly not to be full member of RSSAC. ALAC may be interested in considering to be part of such arrangement. - ALAC supports and welcomes the recommendation regarding communication between RSSAC and other part of the ICANN community. AtLarge does occasionally invite RSSAC to our meetings and we will like to see that improved upon to the extent that is necessary and important.

    1. Evin Erdogdu

      Thank you Seun, I have posted to the "first draft" box as per your/Alan's request.

  2. Alan Greenberg

    Several comments:

    1. The ALAC welcomes recommendation 5 that the RSSAC interacts more actively with the rest of the ICANN Communits.
    2. Recommendation 3 does not fully capture the intent of the preceding paragraph.

    To the extent that ICANN either is or is widely held to be responsible for the reliable and secure operation of the root, it requires a relationship with the serving side of the root registry that extends beyond the “exchange of information” limits of the RSSAC charter. The nature of that relationship is primarily an RSO/Board issue, not an RSSAC issue, and therefore out of scope for the present review. But the apparent mismatch between what ICANN needs from an interface to the root server system and what the  RSSAC is currently chartered to provide suggests that either the RSSAC scope should

    Recommendation 3: Formalize the responsibilities of the RSSAC to the ICANN Board and Community in a work plan that is periodically reviewed and published, and hold the RSSAC accountable for work plan deliverables.

    Although there is no clear way to address the issue, since ICANN has a part to play in ensuring that the DNS is a trusted and reliable resource, then it must have the ability to interact with all payers who have a role in carrying that out. Simply lowering expectations does not address the issue. Perhaps this is indeed not a "RSSAC" issue, but it must be addressed.

    With regard to Seun's comments, adding non-RSO members to the RSSAC may well be the way to proceed, but the ALAC is sensitive to rules being imposed which may be difficult to implement. Rather than suggest that liaisons are the answer, I would suggest that altering Recommendation 1 to allow forms other than "membership" while achieving the same aim of ensuring that the RSSAC has all of the skills and perspectives to properly fulfill its function. And lastly, I am hesitant to offer the ALAC as a part of this solution when it is not clear exactly what role it would play.

    1. Seun Ojedeji

      Hello Alan, I will be fine with the wording you've used for the non-RSO members to RSSAC so long as it doesn't have negative impact on the quality of their work as I see the RSSAC as a specialised group and should remain so. With regards to liaison, i wasn't definite that ALAC would do so but that we would consider it. If such provision is made then when we get to the bridge of whether to have a liaison we can decide to agree on its need. I however think making a liaison provision can be a way to ensure that the RSSAC maintains its membership specialty requirement while keeping the other part of the community closer to their work.

  3. Alan Greenberg

    Regarding the ALAC and Liaisons. I thought you were saying that the ALAC would somehow be involved with liaisons from groups such as anycast instance providers. Now I see you were talking about an ALAC Liaison. I think we should leave that to another discussion, just as we have had discussion on a liaison with the ASO.

    The RSSAC IS a sprecialized group and should remain so, but I think the point the reviewers were making is that RSS stands for Root Server SYSTEM and that is wider that just the RSOs.

    1. Seun Ojedeji

      Yes that was indeed my intent; that it can be discussed later. To further clarify, my point was that instead of what is suggested in recommendation 5, that a "liaison like" setup may better preserve the membership speciality of RSSAC. Note that the reviewer was not only suggesting membership of "...anycast instance providers and public DNS resolvers" but also "provisioning- side interested parties (e.g., TLD registries and the ccNSO" ) and am of the opinion that instead of having a membership construct for those, a liaison like structure may be more appropriate to preserve the speciality of RSSAC. That said, perhaps this is an implementation point and RSSAC may be in a better position to determine what will work for them.

  4. Alan Greenberg

    Draft comment inserted.

  5. Justine Chew

    My comments on FIRST DRAFT SUBMITTED

    1) I support the intent of the comment to Recommendation 1, and in focusing on the term "membership criteria" and part (a) of Interisle's Recommendation 1, offer a small amendment for consideration as follows:

    Rather than suggest that additional “members” are the answer, consideration should be given to altering Recommendation 1 to allow the participation of any qualified person other than by way of membership while achieving the same aim of ensuring that the RSSAC has all of the skills and perspectives to properly fulfill its function.

    2) Please clarify whether Recommendation 2 is as presented or if there was meant to also be a comment to Recommendation 3?

    In any case, with reference to:

    Although there is no clear way to address the issue, since ICANN has a part to play in ensuring that the DNS is a trusted and reliable resource, then it must have the ability to interact with all players who have a role in carrying that out and that must include the Root Server Operators. Simply lowering expectations does not address the issue. Whether this is done by widening the scope of the RSSAC or through some other mechanism is less important than noting that the current chasm must be breached.

    • I am unsure that Findings 5, 9, 13 and 22 in Interisle's report allow us to suggest any lowering of expectations. Therefore I would suggest that this sentence be deleted in its entirety. I believe it is also unnecessary as the first sentence connects logically to the last sentence in any case.
    • As for the last sentence, I believe the word "breached" should be "bridged".

    3) Re: Recommendation 5, I prefer Alan's version – i.e. the use of "interact" or even "engage" instead of "communication". So:

    The ALAC welcomes recommendation 5 that the RSSAC interacts more actively with the rest of the ICANN Community.



  6. Amrita Choudhury

    I agree to the amendment suggested by Justine in the wordings under Recommendation 1. 

    Additionally, if possible, a comment could be added that the membership process criteria at RSSAC be made transparent.

    1. Justine Chew

      Hi Amrita,

      Interesting. What do you mean by "membership process criteria"? 

      See: https://www.icann.org/groups/rssac-caucus

      1. Amrita Choudhury

        Hi Justine, I was speaking to a few RSSAC members and interested people to join it. One of their concern is that the process of evaluating and then approving membership is not transparent.

        1. Justine Chew

          Hi Amrita,

          Right, so we're talking about membership recruitment evaluation and approval process. I understand now, thanks!

  7. Alan Greenberg

    I could not support either suggested change. Seun's original comment noted that it may be difficult to have the RSSAC (and the RSO community from which the members currently come) to accept new "members". Both of our comments suggested ways to soften the requirement but still address the critical issues identified in the review.

    The suggested changes potentially would make membership completely open to anyone who walked up with specific qualifications. That is a VERY different result than what was envisioned to address the identified problem.

    If you look at a comparable situation, the SSAC, to become a member, you need to possess specific criteria, but then they also need to decide that they actually need those particular skills at that time. And the SSAC has a FAR wider scope than RSSAC.

    1. Justine Chew

      Hi Alan,

      Concerns re edits to Recommendation 1 are understood. I was reacting to the actual words in the First Draft section of:

      Rather than suggest that additional “members” are the answer, consideration should be given to altering Recommendation 1 to allow forms other than "membership" while achieving the same aim of ensuring that the RSSAC has all of the skills and perspectives to properly fulfill its function.

      What does "...forms other than "membership"..." mean?

      Also, am I correct in understanding that by "either suggested change" you mean mine and Amrita's just in respect of Recommendation 1?

      Thanks.

  8. Alan Greenberg

    Forms other than membership: well, you could follow Seun's suggestion and have other groups end a "liaison" who could contribute to discussions but not have voting or other rights of membership. Or call them "participants" as we do in CCWGs.  The intent is that if full membership is objectionable and may be rejected by the RSSAC, then open the door to other ways of getting people involved.

    Yes, by both I meant yours and Amitra's comments. Both serve to either open the do to far wider than the Recommendation already does by allowing anyone with specific qualifications to become a member. The draft comment says give flexibility to achieve the end by adding needed skills, not change the very nature of the RSSAC.

    I realize I didn't address your other points.

    On lowering expectations,we did not introduce that it is already there and we are saying it is not acceptable.

    Bridged vs Breached. Indeed you are correct!

    Rec 5: ok


    1. Justine Chew

      Alan,

      1) Re: Recommendation 1, I agree with the intent as you explained, and maybe I went too far in my attempt to clarify "...forms other than "membership"..." but I still don't see how "...forms other than "membership"..." matches that intent either. Perhaps, we could say (or not, if others don't agree), ...

      Rather than suggest that additional “members” are the answer, consideration should be given to altering Recommendation 1 to allow varied forms of "membership" criterion to facilitate achieving the same aim of ensuring that the RSSAC has all of the skills and perspectives to properly fulfill its function.

      Also :

      • My reason in using "participation" in my earlier suggested amendment is to distinguish from "membership".
      • My reference to "any qualified person" in my earlier suggested amendment was taken from RSSAC recruitment page (See: https://www.icann.org/groups/rssac-caucus), and I meant any qualified person as determined by RSSAC.
      • I have not touched on or reacted further to the membership application and evaluation, I merely wanted to understand what Amrita meant in her remarks.

      2) Re: Recommendation 2, I withdraw my earlier suggestion to delete a sentence on the basis of having re-read the report and recommendation. In short, Recommendation 2 should stand as drafted.

      1. Seun Ojedeji

        Hello Justine,

        I think we should note that this is a review report from the reviewer contracted by ICANN hence i expect its not a report that has been approved in its entirety by RSSAC(i expect they will most likely have their comments put in as well).

        It is the reviewer that is suggesting opening RSSAC membership up and I was saying that it can be problematic route (a view that I understand Alan share as well). We are saying since the intent is to allow participation from other groups in RSSAC, rather than bring those in as full member which can be problematic, other forms of membership should be considered. My preference was a liaison kind-of arrangement but i am also fine with Alan's construct which "somewhat" leaves that implementation decision to RSSAC themselves but still raises the concern that such full membership should not happen.

        Thanks

        1. Justine Chew

          Hi Seun,

          I take and agree with the point that RSSAC, being the party with the most vested interest in this instance, will undoubtedly respond also taking into considering the sensitivity of the subject matter as it relates to RSSAC and its 'administration', so I am going to leave this discussion as is.

          My thanks to you and Alan for responding.