[Internal-cg] ICG Proposal Submission Expectations (was: Role of the board)
narelle.clark at accan.org.au
Tue Nov 4 00:07:01 UTC 2014
> -----Original Message-----
> From: internal-cg-bounces at icann.org [mailto:internal-cg-bounces at icann.org] On Behalf Of Lynn St.Amour
> Sent: Wednesday, 29 October 2014 2:10 PM
> 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.
I think there needs to be a bit more clarity about "ICANN" as in, which part of ICANN? It is a large and amorphous entity, though with some moving parts.
I wonder also: who is the precise contracting party, or nominee, to the NTIA? Is it "the ICANN Board, ie its Chairperson", or "ICANN the corporation, and therefore its CEO" or some other piece?
Other references to "ICANN" beg some further clarity also: I suggest "ICANN communities" or "ICANN stakeholders" or some more precise piece of ICANN's many chunks addressable by acronym or other term.
> 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.
I think we are beholden to do some sort of validation/verification of the responses. It is at least implicit in the RFP itself. Should we get mischievous responses that are clearly incomprehensible, then we should be at liberty to point this out, and I'm confident that the communities will reject such spurious responses out of hand.
Surely also, some sort of commentary on the compatibility, coherence or completeness is warranted also?
> 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".]
Agree, however surely we can act to facilitate dialogue between the groups if, on assessment (and I use the term advisedly) we see incompatibility or other issues. This would involve some sort of commentary.
> 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.
Indeed we should.
> 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.
Here is where I see a lack of clarity on which bit of ICANN is meant.
> * 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
> * 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.
To the Board? To the CEO? To the ICANN community?
All of the above?
> * The ICG expects ICANN to transmit the proposal unmodified to NTIA and to
> publish that transmission on its public web site.
Unmodified, as is, and without alteration. Also without mediation, or set in a context that sets additional unintended context.
> * 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.
Thanks for the effort Lynn and colleagues.
More information about the Internal-cg