Re: [ga] Comments regarding the LSE Report

[Jeff Williams <jwkckid1@xxxxxxxxxxxxx>]

Michael and all,

  The single biggest single problem I see with your recommendations
is that many, if not most real stakeholders are not members of any
GNSO constituency and cannot be because the rules for many
if not all of these constituencies is closed to many, if not most real
stakeholders.  Additionally as there is no non aligned or non affiliated
constituency as the DNSO general assembly once was, viable
and honest policy cannot ever be developed, as we have already
seem far too much of...

Michael D. Palage wrote:

> Hello All:
>
> Here are my comments in connection with the LSE report. As always I
> welcome any constructive feedback and encourage other individuals to
> speak up as this is an important process to provide stakeholders with an
> important voice in the gTLD policy development process.
>
> Best regards,
>
> Michael D. Palage
>
> Recommendation 1.
>
> A centralised register of all GNSO stakeholders should be established,
> which is up-to date and publicly accessible. It should include the
> members of Constituencies and others involved in the GNSO task forces.
> (Paragraph 2.5).
>
> MDP Comments: I do not diagree with this statement but I believe the LSE
> people need to elaborate a little more on what they are trying to
> achieve and how it would scale.
>
>
> Recommendation 2.
>
> GNSO Constituencies should be required to show how many members have
> participated in developing the policy positions they adopt. (Paragraph
> 2.14)
>
> MDP Comments: Fully support. With no record of who participated in the
> formation of a position, there is no accountability. This is totally
> inconsistent with what the community is demanding from the ICANN Board.
> In order for the Board to make an informed decision, they must have a
> record of how individual members within a constituency voted, not just
> how a handful of council members voted. Failure to have a record
> provides no accountability.
>
>
> Recommendation 3.
>
> There needs to be greater coherence and standardisation across
> Constituency operations. For this to work effectively, more ICANN staff
> support would be needed for constituencies. (Paragraph 2.22)
>
> MDP Comments: Do not disagree with this statement but believe a cost
> benefit analaysis needs to be prepared.  Additionally, there should be
> an exploration of the potential use of independent third party
> contractors instead of ICANN staff to prevent against the appearance of
> any conflict.
>
> Recommendation 4.
>
> A GNSO Constituency support officer should be appointed to help
> Constituencies develop their operations, websites and outreach activity.
> (Paragraph 2.23)
>
> MDP Comments: Same comments as above. Need to see a cost benefit
> analysis, and need to explore the potential use of independent third
> party contractors to prevent potential conflicts.
>
>
> Recommendation 5.
>
> Constituencies should focus on growing balanced representation and
> active participation broadly proportional to wider global distributions
> for relevant indicators. (Paragraph 2.39)
>
> MDP Comments:  I support for this recommendation.
>
> Recommendation 6.
>
> The basis for participation in GNSO activities needs to be revised, from
> Constituency-based membership to one deriving from direct ICANN
> stakeholder participation. (Paragraph 2.44)
>
> MDP Comments:  My personal viewpoint is that the GNSO policy development
> process is not working. During a recent conversation with a business
> constituency member for whom I have a great deal of respect, I asked the
> question why they were no longer actively participating in ICANN. Their
> response "nothing gets done." The GNSO is broken and I believe all
> options including the current constituency structure needs to be put on
> the table for evaluation.
>
>
> Recommendation 7.
>
> The GNSO should improve the design and organization of the current
> website, develop a website strategy for continual improvement and growth
> over the next three years, and review usage statistics on a regular
> basis to check that traffic to the website is growing over time and
> understand more fully what external audiences are interested in.
> (Paragraph 3.10)
>
> MDP Comments: I support this recommendation.
>
>
> Recommendation 8.
> Document management within the GNSO needs to be improved and the
> presentation of policy development work made much more accessible.
> (Paragraph 3.14)
>
> MDP Comments: I support this recommendation.
>
> Recommendation 9.
>
> The GNSO should develop and publish annually a Policy Development Plan
> for the next two years, to act both as a strategy document for current
> and upcoming policy work, and as a communications and marketing tool for
> general consumption outside of the ICANN community. It should dovetail
> with ICANN's budget and strategy documents. (Paragraph 3.16)
>
> MDP Comments. I do not object to the concept, however, I have difficult
> reconciling the prudence of a two year plan when ICANN's operational and
> budget are one year documents.
>
> Recommendation 10.
>
> The GNSO and ICANN should work proactively to provide information-based
> incentives for stakeholder organizations to monitor and participate in
> GNSO issues. (Paragraph 3.19)
>
> MDP Comments. I support the LSE recommendation. ICANN should be
> proactively looking for multiple and diverse voices to participate in
> the ICANN/GNSO process. Increased voices and viewpoints should increase
> the quality of the GNSO's work, provided that such participation is
> balanced. Thus there needs to be safeguards to prevent special interest
> groups from improperly attempting to skew any work.
>
>
> Recommendation 11.
>
> The position of the GNSO Council Chair needs to become much more visible
> within ICANN and to carry more institutional weight. (Paragraph 3.26)
>
> MDP Comments: I support this recommendation.
>
> Recommendation 12.
>
> The policies on GNSO Councillors declaring interests should be
> strengthened. Provision for a vote of "no confidence' leading to
> resignation should be introduced for non-compliance. (Paragraph 3.28)
>
> MDP Comments: I support this recommendation.
>
>
> Recommendation 13.
>
> Fixed term limits should be introduced for GNSO Councillors either of
> two two-year terms (as applied in some Constituencies already) or
> perhaps of a single three-year term. (Paragraph 3.30)
>
> MDP Comments: Term limits are important as it provides a necessary
> influx of new talent and leadership. In fact there should be uniform
> term limits (2 terms) across all ICANN positions. The only exception
> being where positions cannot be filled.
>
>
> Recommendation 14.
>
> The GNSO Council and related policy staff should work more closely
> together to grow the use of project-management methodologies in policy
> development work, particularly focusing on how targeted issue analysis
> can drive data collection from stakeholders (rather than vice versa).
> (Paragraph 4.14)
>
> MDP Comments: I support this recommendation.
>
>
> Recommendation 15.
>
> The GNSO Council should rely more on face-to-face meetings supplemented
> by online collaborative methods of working. The Chair should seek to
> reduce the use of whole-Council teleconferencing. (Paragraph 4.19)
>
> MDP Comments: Concerns. The use of teleconferences still appear to be
> viable mechanism for the council to exchange views and build consensus.
>
>
> Recommendation 16.
>
> The GNSO Councillors should have access to a fund for reasonable travel
> and accommodation expenses to attend designated Council meetings,
> instead of having to meet such costs from their own resources as at
> present. (Paragraph 4.21)
>
> MDP Comments: Qualified support, a cost benefit analysis is needed.
>
>
> Recommendation 17.
>
> The GNSO Council should make more use of Task Forces. Task Force
> participants should be more diverse and should be drawn from a wider
> range of people in the Internet community, and national and
> international policy-making communities. (Paragraph 4.26)
>
> MDP Comments: Full support. To date there is not as much diversity on
> different Task Forces, with some council members serving on almost every
> working group/task force. There should be limits on the number of task
> forces/working groups that an individual can serve on.
>
>
> Recommendation 18.
>
> An ICANN Associate stakeholder category of participation should be
> created, so as to create a pool of readily available external expertise,
> which can be drawn upon to populate Task Forces where relevant.
> (Paragraph 4.27)
>
> MDP Comments: Do not fully appreiate the difference between an associate
> stakeholder and regular stakeholder. Would request further feedback from
> LSE regarding this recommendation.
>
>
> Recommendation 19.
>
> The current GNSO Constituency structure should be radically simplified
> so as to be more capable of responding to rapid changes in the Internet.
> The Constituency structure should be clear, comprehensive (covering all
> potential stakeholders) and flexible, allowing the GNSO to respond
> easily to the rapid changes in the make-up of Internet stakeholders. We
> suggest a set of three larger Constituencies to represent respectively
> Registration interests, Businesses and Civil Society. (Paragraph 4.35)
>
> MDP Comments: I believe looking at alternatives to the constituency
> model would be helpful as the current model is not working. I support
> some of the bigger issues that LSE is raising in connection with this
> recommendation. During my initial discussion with various participants
> within the various constituencies, almost everyone has talked about
> losing or gaining votes. I think this shows how the process is broken in
> that consensus should not come down to the mere tabulation of a small
> universe of council member votes. I also believe a significant portion
> of policy contention within the GNSO could be resolved by a clear
> deliniation from the ICANN general counsel as to what is and is not
> policy.
>
> Recommendation 20.
>
> A reorganization of GNSO Constituencies would also allow the Council to
> be made somewhat smaller (we suggest 16 members) and hence easier to
> manage. (Paragraph 4.36)
>
> MDP Comments: Assuming a diversity of work load among non council
> members, a smaller council would be more viable. I believe this merits
> additional evaluation.
>
>
> Recommendation 21.
>
> The definition of achieving a consensus should be raised to 75 per cent.
> Weighted voting should be abolished. Both measures could help to create
> more incentives for different Constituencies to engage constructively
> with each other, rather than simply reiterating a "bloc' position in
> hopes of picking up enough uncommitted votes so as to win. (Paragraph
> 4.38)
>
> MDP Comments: Qualified support. As discussed above, when GNSO
> participants are more worried about counting votes, it shows how broken
> the process has become. There needs to be mechanisms/processes in place
> to achieve concensus based upon meaningful input, not the mere tallying
> of 16/21 votes. Removing weighted voting but then replacing it with a
> system where certain constituencies would have veto rights given the
> higher threshold for consensus results in no net change from the current
> quagmire. The removal of weighted voting is merely treating a symptom,
> while failing to cure the root problem.
>
>
> Recommendation 22.
>
> The way in which the GNSO Council votes to elect two Directors to the
> ICANN Board should be changed to use the Supplementary Vote system.
> (Paragraph 4.40)
>
> MDP Comments: I support this recommendation.
>
>
> Recommendation 23.
>
> The amount of detailed prescriptive provision in the ICANN Bylaws
> relating to the operations of the GNSO should be reduced. ICANN Bylaws
> should outline broad principles and objectives for the GNSO but the
> detailed operational provision (including the section on the PDP) should
> be transferred to the GNSO Rules of Procedure. This would allow the GNSO
> to agree amendments and to introduce new innovations in its working
> methods and timelines in a more realistic and flexible way, while
> operating within ICANN's guiding principles. (Paragraph 5.7)
>
> MDP Comments: Qualified support. Any changes must be approved by the
> ICANN general counsel to make sure that they are not inconsistent with
> ICANN's existing bylaws or contractual obligations. There also needs to
> be safeguards to provide all parties within the GNSO predictability and
> confidence in the process. If the GNSO council abuse this new discretion
> to constantly move the goal post to the detriment of impacted parties
> this would be a bad thing.
>
> Recommendation 24.
>
> Both ICANN and the GNSO Council should periodically (say once every five
> years) compile or commission a formal (quantitative and qualitative)
> assessment of the influence of the GNSO's work on developing policy for
> generic names. This should include an analysis of how the GNSO's
> influence with national governments, international bodies and the
> commercial sector might be extended. (Paragraph 5.12)
>
> MDP Comments: No preliminary objections.

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is
very often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402
E-Mail jwkckid1@xxxxxxxxxxxxx
 Registered Email addr with the USPS
Contact Number: 214-244-4827