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
Seun Ojedeji
Evin Erdogdu
Thank you Seun, I have posted to the "first draft" box as per your/Alan's request.
Alan Greenberg
Several comments:
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.
Seun Ojedeji
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.
Seun Ojedeji
Alan Greenberg
Draft comment inserted.
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.
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.
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.
Justine Chew
Hi Amrita,
Interesting. What do you mean by "membership process criteria"?
See: https://www.icann.org/groups/rssac-caucus
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.
Justine Chew
Hi Amrita,
Right, so we're talking about membership recruitment evaluation and approval process. I understand now, thanks!
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.
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.
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
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 :
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.
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
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.