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.
And should not be very different from pre-existing SLAs
specifically:
One would expect the report to also be aligned with the IANA's monthly performance reporting as covered in section 1.4.
As reported here:
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