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

Subrenat, Jean-Jacques jjs at dyalog.net
Tue Nov 4 16:53:34 UTC 2014


As a former ICANN Board member, let me offer a few comments:

- At ICANN, contractual, operational and other technical functions are under the responsibility of the CEO, who also ensures the relationships with other entities (ITU, etc.). Matters of principle or orientation are dealt with by the Board of Directors, represented by its Chair.

- The ICG has been tasked with preparing a plan for the transfer of oversight over the IANA functions, which is clearly a matter of principle. The ICG Chair should therefore communicate with the ICANN Board Chair, as is the case for the GAC.

- Yes, the notion of "community" or "communities" needs to be properly documented and clarified in the context of the ICG's remit.

Jean-Jacques.



  

----- Mail original -----
De: "Narelle Clark" <narelle.clark at accan.org.au>
À: "Lynn St.Amour" <Lynn at lstamour.org>, "ICG" <internal-cg at icann.org>
Envoyé: Mardi 4 Novembre 2014 01:07:01
Objet: Re: [Internal-cg] ICG Proposal Submission Expectations (was: Role of	the board)


Comments below.

Narelle

> -----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
<snippage> 
> 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
> 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.

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.

Good catch.

> 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.


Narelle
_______________________________________________
Internal-cg mailing list
Internal-cg at icann.org
https://mm.icann.org/mailman/listinfo/internal-cg


More information about the Internal-cg mailing list