RC members,
Looking at the document I have some comments, but generally support the concerns advanced.
I think there is quite a lot of boot strapping work required, wrt our role, our operating procedures, our procedures for crafting and reviewing the performance report, and our procedures for community engagement.
Up until now, have not made good progress over phone and email.
I am concerned that we are have not scheduled enough time to advance these discussions.
I could easily see spending a whole day in the hallway consulting RC members and putting pen to paper in drafting operating procedures as I did with ASO AC voting procedures in Helsinki.
--------- " C) Committee Second F2F meeting is primarily required for first 2 years of ICANN transition to fulfil the following needs."
Agreed. I do believe there is a bunch of boot strapping work, and as of yet, we have not been very effective advancing things over the phone or email. I am not sure I would specifically scope this to two years. It might be better to decide what are the important milestones, and keep meeting until we can be far enough along that the work can easily complete without in person meetings.
--------- " C) 1) The physical attendance would enable to Gauge the sense of services by the RIRs. Service level needs to be clearly defined and accepted by all stakeholders"
I believe there is work to be done here, but it will be reviewing a sample report, getting consensus on what we should report and its format. And determining our process for creating and reviewing the document.
I believe the SLAs are clearly defined, agreed to, and accepted by the RIRs and ICANN.
https://www.nro.net/wp-content/uploads/SLA-Executed-ICANN-RIRS.pdf
And should not be very different from pre-existing SLAs https://www.ntia.doc.gov/other-publication/2012/icann-proposal
specifically: section 1.2.8.1.vi. https://www.ntia.doc.gov/files/ntia/publications/icann_volume_i_elecsub_part...
One would expect the report to also be aligned with the IANA's monthly performance reporting as covered in section 1.4. https://www.ntia.doc.gov/files/ntia/publications/icann_volume_i_elecsub_part...
As reported here: https://www.iana.org/performance/metrics/20160930#c293
Though I expect we would consider the underlying data, and spot check that it agrees with our perception and recollection of recent events.
I believe Nate plans to come with a preliminary report for our review. I suspect the review of such a report will be non-controversial.
I expect the only concerns to be raised will be cosmetic, such as word smithing, formatting, and consideration that something was left out, or requires more detail.
We also need a procedure for how to compile the report and conduct the review.
My hope is that the report comes together easily, and the review is straight forward and we all agree that the procedure can be very simplistic.
--------- "C) 2) It would also help in sensing if there are conflicting situations developing for example if GAC community feels any major issues/conflicts now or potential ones.
3) To seek the feedback and comments from community. And to get to know the emerging issues."
Agreed. But I believe the customer of the IANA service is the numbers community, and it is the concerns of the participants at the RIR / NOGs that we are concerned about.
Possibly the three members of the RC should have a session at each of their regional RIR meetings, and coordinate with other RC members on any take aways from the community?
------
C) 4) The conference calls are open to public thus many issues/ unexpected questions may emerge and RC has to appear cohesive in tackling such queries. FOR THIS RC NEEDS TO HAVE A VERY CLEAR UNDERSTANDING OF APPROACH TOWARDS ISSUES WITHIN ITS CHARTER AND PROCESSES to handle any issues."
Agreed. I think the point here is that we do not have a clear picture of the role of the RC, especially wrt community engagement. We have already seen how this has slowed down our discussion.
-------
C) 5) Primarily the focus of community is to see and observe and get the confidence that indeed ICANN governance is now truly multi stakeholder and not influenced/controlled by select few in this first ICANN transition year. ASOAC/RC has to put its cohesive approach towards success of transitioned ICANN."
Agreed. I think this goes hand in hand with the previous point.
The NTIA proposal sought to shift its oversight to the relevant community such that the IANA Numbering Services Operator would be held accountable to the Internet Number Community in a way that would support and enhance the multistakeholder model.
The charter states we need to show the report to the community and seek feed back before submitting a recommendation to the NRO EC. But the process nor depth is not specified. This has lots of room for interpretation, and will likely be the most difficult topic.
There is quite a big gap between this two positions.
This could range from simply putting the draft report on a mailing list and asking for community concerns, to making an IANA performance Experience Report at RIR meetings, to having an open meeting where community concerns are regularly solicited. There could be a more formal process for judging that the community has put forward reasonable concerns and desires and out of cycle review. There could be a formal process for SLA Development that can be used if a new SLA is required, or existing performance metrics need changing.
One thing is clear though, the output can only be providing information to the community and recommendation to the RIRs/ NRO EC.
--------
"C) 6) The objective has to be such that clear operational processes are put in place in first two years. We need to keep in mind, it may take close to a year or may be more if ICANN Board ratification is also needed on some matters/processes."
I believe all of this can be sorted within the RC. I think at worst, we decide something that is contrary to the charter, and need to work with the NRO EC / RIRs to see if we can modify the charter.
The only such issue that I currently know of is the provision that all meetings will be by teleconference. It is unclear if a face-to-face meeting with remote participation / observation is inside or outside the spirit of this charter requirement and if this can happen without amending the charter.
If you see specific issues that need to go to the ICANN Board, please provide some discussion.
___Jason
On Sat, Feb 25, 2017 at 7:31 AM, Brajesh Jain brajesh.jain@spectranet.in wrote:
Jason,
I agree with your assessment.
Thanks and regards
Brajesh
*From:* Jason Schiller [mailto:jschiller@google.com] *Sent:* Friday, February 24, 2017 8:07 PM *To:* Brajesh Jain brajesh.jain@spectranet.in *Cc:* German Valdez german@nro.net; AC COORD ac-coord@aso.icann.org; rc@nro.net *Subject:* Re: [AC-COORD] A Note for need of Second f2f meeting of ASOAC/RC
(apologies for cross posting AC-Coord and RC)
Brajesh,
I believe the attached document is in response to action item 20170111-06:
"BJ to send the suggestion about a second F2F meeting to the list."
After review of the document it seems this is justification is based on the need to
complete Review Committee work.
Reading between the line I think you are suggesting that the the Review Committee
members should also meet during the ASO AC face to face at the ICANN meeting.
In addition, the Review Committee needs a second face to face meeting for a few
years while the RC is boot strapping, and settling in.
If my assessment is correct, I would suggest that this discussion moved to the RC list.
If you agree, please respond as such and move ac-coord@aso.icaan.org to bcc
Thanks,
__Jason
On Fri, Feb 24, 2017 at 5:32 AM, Brajesh Jain brajesh.jain@spectranet.in wrote:
Dear all,
I have attempted a brief note as attached for further deliberations.
Basically for Review Committee to function effectively, there is need for in depth multiple deliberations with constant feedback/inputs from Community. Such inputs are best sought through interaction being present at ICANN.
Thanks and regards
Brajesh
AC-coord mailing list AC-coord@aso.icann.org https://aso.icann.org/mailman/listinfo/ac-coord
--
Jason Schiller|NetOps|jschiller@google.com|571-266-0006 <(571)%20266-0006>
Rc mailing list Rc@nro.net https://nro.net/mailman/listinfo/rc