[CCWG-ACCT] Creative solutions for Rec.11

Sat Jan 30 13:29:12 UTC 2016

GAC is an ADVISORY Committe.

gNSO is a SUPPORTING ORGANIZATION.

Of course AC's can never be the same as SOs.

el

--
Sent from Dr Lisse's iPhone 6s

On 30 Jan 2016, 14:34 +0200, Kavouss Arasteh<kavouss.arasteh at gmail.com>, wrote:
> Malcolm
> What you said is
> 
> "*Remove the 2/3 rule; and
> Provide that when providing advice on GNSO policy,GAC advice is given
> directly to the GNSO (during the PDP) instead of to the Board,(after
> the community consensus policy is finalised and ready to be ratified).
> Require that the GNSO consider any such GAC advice before adopting a PDP
> policy. (This is conceptual: lawyers can wordsmith)."
> are you serious?
> DO YOU WANT TO sUBORDINATE ONE community ( GAC) to another Community ( GNSO) ?
> I am sorry that is totally out of question and discusion.
> It is a dangerous round of discussion and totally with no legal , procedural and validity
> I categorically reject that
> Kavouss
> 
> 
> 
> 2016-01-30 11:48 GMT+01:00 Seun Ojedeji<seun.ojedeji at gmail.com(mailto:seun.ojedeji at gmail.com)>:
> > 
> > I would have added a +1~ to this mainly because it removes the 2/3 from the discussion, even though it technically have no impact on ICANN accountability but i have remained concerned about major impact it could cause politically(especially when it is read "wrongly/rightly" as an increase in govt control). However, this assumes that GNSO was not supportive of the 2/3 on the fear of GAC's advice interfering on its policies? but GAC's advice may not always have to do with GNSO related issues.
> > 
> > 
> > Personally, I have always wondered why GAC advice relating to names policies does not get feed directly to the process, but I concluded its perhaps by design since AC (in this context) are meant to provide advice. The question then would be to determine if indeed the PDP would ensure to give recognition to such an advice in the same way it does for its constituencies.
> > 
> > 
> > That said, I think other than the bylaw change, a number of other documents relating to GNSO PDP/decision making processes may need to be updated in other to make your proposal become a reality and I wonder if that won't be a tall order.
> > 
> > 
> > Cheers!
> > 
> > On 30 Jan 2016 10:50 a.m., "Malcolm Hutty"<malcolm at linx.net(mailto:malcolm at linx.net)>wrote:
> > > On 29/01/2016 21:24,Jorge.Cancio at bakom.admin.ch(mailto:Jorge.Cancio at bakom.admin.ch)wrote:
> > > >it is a bit akward you would need to concede that you imply that
> > > >without the 2/3 the GNSO would be able to support Rec 11.
> > > >
> > > >It gives an impression as if Rec 11 (without 2/3) would contain
> > > >anything "that would need to be accepted", when as we all know Rec 11
> > > >(without 2/3) corresponds to 100% of the GNSO starting position.
> > > >
> > > >So there would be any concession. No aspect "in need to be
> > > >accepted".
> > > >
> > > >Just a 100% win-situation for the GNSO.
> > > 
> > > 
> > > On 29/01/2016 22:01,Jorge.Cancio at bakom.admin.ch(mailto:Jorge.Cancio at bakom.admin.ch)wrote:
> > > >I feel that at this critical juncture we all have to keep the whole
> > > >picture in our heads, be creative (as Becky for instance) and look
> > > >for a solution which may be acceptable across the community as a
> > > >whole.
> > > 
> > > The 2/3 rule is evidently unacceptable to the GNSO.
> > > 
> > > Without that rule, Rec.11 would (it seems) be acceptable to them. Jorge
> > > says "But this is their starting position, it would mean a 100%
> > > win-situation for the GNSO". I might observe that the logic of that
> > > seems to be that GNSO ought to have come to CCWG with a more extreme
> > > initial position, so that it could settle on what it really wanted.
> > > Perhaps it will learn to adapt its negotiating tactics.
> > > 
> > > However, I do agree with Jorge: we need to try to respect the need for
> > > all parties to be seen to gain improvements from our changes. I would
> > > therefore like us to take up his challenge to "be creative" in an
> > > attempt to find a solution.
> > > 
> > > Let us consider what the 2/3 rule attempts:
> > > 
> > > - from a government point of view, it provides an assurance that GAC
> > > advice will be given greater weight, affirming the importance of
> > > government input. Such an assurance is necessary to them.
> > > 
> > > - from a GNSO point of view, it ensures that the Board will
> > > automatically follow GAC advice (except in very unusual circumstances)
> > > transforming ICANN into a body which is led by government policy. Such a
> > > transformation is unacceptable to them.
> > > 
> > > With GNSO opposition, I believe we must accept that the 2/3 rule is
> > > dead. But taking up Jorge's challenge, we must replace it not with
> > > nothing, but with something creative that would offer in its place the
> > > assurance to governments the 2/3 rule seeks to achieve, without creating
> > > the transformation that the GNSO opposes.
> > > 
> > > I think it would be useful if people come forward with ideas for
> > > strengthening the input of governments without overbalancing the
> > > decision-making process as the 2/3 rule does.
> > > 
> > > I would therefore like to make the following suggestion of my own:
> > > 
> > > * Remove the 2/3 rule; and
> > > * Provide that when providing advice on GNSO policy, GAC advice is given
> > > directly to the GNSO (during the PDP) instead of to the Board, (after
> > > the community consensus policy is finalised and ready to be ratified).
> > > Require that the GNSO consider any such GAC advice before adopting a PDP
> > > policy. (This is conceptual: lawyers can wordsmith).
> > > 
> > > The advantages of this proposal, as I see them, are as follows:
> > > 
> > > - By accepting GAC advice into an earlier stage of the process, it will
> > > be possible to incorporate it into the design of the policy, rather than
> > > tacking it on as an adjunct. GAC advice will therefore be more effective
> > > and the ultimate outcome more likely to reflect GAC expectations than at
> > > present.
> > > 
> > > - By incorporating the fruits of GAC advice into the community proposal,
> > > it will also benefit from the rule that the Board is expected to accept
> > > GNSO community consensus policy proposals, and can only reject them by
> > > 2/3 supermajority.
> > > 
> > > - By including the GAC in the policy-development process we strengthen
> > > the GAC's role as a part of our community, reducing the "them and us"
> > > tensions and helping to ensure that GAC concerns are given full respect
> > > at every level of the organisation.
> > > 
> > > Most importantly, this suggestions aims to strengthen the GAC's role in
> > > a manner that also strengthens the multi-stakeholder policy development
> > > process, rather than standing in tension with it. It can therefore be
> > > seen not as a zero-sum compromise but a true win-win solution.
> > > 
> > > I look forward to your thoughts,
> > > 
> > > Malcolm.
> > > 
> > > --
> > > Malcolm Hutty | tel:+44 20 7645 3523(tel:%2B44%2020%207645%203523)
> > > Head of Public Affairs | Read the LINX Public Affairs blog
> > > London Internet Exchange |http://publicaffairs.linx.net/
> > > 
> > > London Internet Exchange Ltd
> > > Monument Place, 24 Monument Street, London EC3R 8AJ
> > > 
> > > Company Registered in England No. 3137929
> > > Trinity Court, Trinity Street, Peterborough PE1 1DA
> > > 
> > > 
> > > _______________________________________________
> > > Accountability-Cross-Community mailing list
> > > Accountability-Cross-Community at icann.org(mailto:Accountability-Cross-Community at icann.org)
> > > https://mm.icann.org/mailman/listinfo/accountability-cross-community
> > 
> > _______________________________________________
> > Accountability-Cross-Community mailing list
> > Accountability-Cross-Community at icann.org(mailto:Accountability-Cross-Community at icann.org)
> > https://mm.icann.org/mailman/listinfo/accountability-cross-community
> > 
> 
> _______________________________________________
> Accountability-Cross-Community mailing list
> Accountability-Cross-Community at icann.org
> https://mm.icann.org/mailman/listinfo/accountability-cross-community
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20160130/26931552/attachment.html>