[Internal-cg] ICG Proposal Submission Expectations (was: Role of the board)

Drazek, Keith kdrazek at verisign.com
Wed Oct 29 12:44:56 UTC 2014

Thanks to Lynn for getting us started in addressing this issue. I support this first draft.


-----Original Message-----
From: internal-cg-bounces at icann.org [mailto:internal-cg-bounces at icann.org] On Behalf Of Lynn St.Amour
Sent: Tuesday, October 28, 2014 11:10 PM
Subject: [Internal-cg] ICG Proposal Submission Expectations (was: Role of the board)

Dear ICG colleagues,

this memo follows up on the broader task in front of us re defining our requirements and expectations vis a vis the proposal submission process.  It is drafty but given the thread started yesterday by Alissa it seemed helpful to get this out ASAP.    Apologies to Jandyr and Xiaodong for an incomplete consultation.

In our last f2f meeting, there was a discussion on ICANN Board resolution 2014.10.16.16 related to the Cross-Community Working Group on ICANN Accountability & Governance (CCWG Accountability).  That resolution sprang from questions regarding how the ICANN Board will address the consensus recommendations developed through the Cross Community Working Group on Enhancing ICANN Accountability.   In our discussion, I believe there was quite strong agreement not to follow a similar process for the IANA Stewardship Transition, but as this is less clear in the minutes it may need further confirmation.  I have tried to address that issue here.  Once there is agreement on the desired process, we will need to ensure there is appropriate awareness and acceptance - from the communities, ICANN and the ICANN Board in particular.

What follows is a train of thought (may not be needed for the final document) and then some recommendations (incorporating text from Alissa's email).   This can clearly be improved upon.

Soooo, train of thought (or operating assumptions?):  

As in all we do, our goal is for the submission to have a broad and robust consensus - from inter alia:  three IANA Function Communities, ICG, ICANN, ICANN Board.  

Given the community's expectations for this process, it is clear that the proposal is to be developed through the communities with the ICG acting as a coordination group.  No additional approval is expected.  This means that all affected or interested parties must participate fully in the various community development processes.    Additionally, the ICG Charter describes quite well the coordination role of the ICG (again per the community's desire); thereby highlighting the necessity for engagement with the communities during the development process as the only acceptable/viable route for impacting the transition plan.

Many of the organizations involved in/impacted by this transition have fiduciary (or fiduciary equivalent) responsibilities.  These will need to be managed by each organization and the development of the transition proposal tracked to ensure no late breaking concerns.  Again, the community was clear that no additional approval is expected prior to submission to NTIA.  [This is because the "policy and oversight responsibilities" for the IANA Functions is done in the three (3) operational communities and not by the IANA Functions Operator.   Those processes determine where their IANA requirements will be "operationalized".]

At the same time, the ICG should proactively reach out and ensure all key parties understand the paths available to them for participation, the associated timelines, and submission process expectations.  This is intended to minimize any misunderstandings or late breaking surprises. 

Finally, the "ICG Guidelines for Decision Making, approved 17 September 2014, may be a useful guide for input during the development process.


ICG's Expectations regarding the proposal submission:    DRAFT DRAFT DRAFT

* The ICG expects all interested parties, including ICANN, and the ICANN Board and its members, to follow or participate the operational community processes that are developing the transition plan.

* If concerns arise at the ICANN or ICANN Board level during the transition plan development process, the ICG expects individual Staff or Board members to raise these concerns within the community processes, or, exceptionally, to raise them with the ICG via the ICANN liaisons - during the proposal development.

* As broad and robust consensus is the community's goal, it is imperative that concerns are raised early and with clear statements on the objection(s) and suggestions on how to mediate the concerns.  Again, in this regard, the "ICG Guidelines for Decision Making, approved 17 September 2014, may be a useful guide.

* Public comment periods occur per the ICG Charter and timeline (note to ICG: more specificity may be needed here).   As a matter of good practice, if not courtesy, outreach to ICANN and the ICANN Board should occur here as well.  The purpose would be to ensure full and broad support for the proposal, vs. assuming participation/support.  

* The ICG will post the final proposal on its public web site. 

* The ICG will transmit the final proposal to ICANN.

* The ICG expects ICANN to transmit the proposal unmodified to NTIA and to publish that transmission on its public web site. 

* Should ICANN or the ICANN Board have concerns over their ability to support (and hence transmit) the community's proposal, it is imperative that this be indicated in a timely enough manner in order to allow resolution of any open items within the established timeline.

There is more detail that might usefully be added but hopefully this is enough to begin discussion and permit an agreement in principle. So, please thrash away.

Best regards,

Internal-cg mailing list
Internal-cg at icann.org

More information about the Internal-cg mailing list