[Internal-cg] Extended session in Los Angeles

Kavouss Arasteh kavouss.arasteh at gmail.com
Thu Sep 18 19:35:35 UTC 2014


I fully agree with Joe.
I do not believe that we should meet different group separately and convey
some non-disguised and non coordinated message or understanding
We should have some general guidelines and scope of what we expect to tell
Kavouss

2014-09-18 21:31 GMT+02:00 Kavouss Arasteh <kavouss.arasteh at gmail.com>:

> Alissa,
> Thank you for your brief
> I am of the opinion that those ICG member's who representing the
> operational communities are the front runners for the task before us ,i.e.
> ICG Members from ccNSO,GNSO NRO ,ASO,IETF
> After these ICG  members other ICG members could meet and brief their
> respective communities as well as any other who wish to join.
> We need to be benefited from the expertise of the people.
> What we should be careful is to provide  and share those information that
> we have some expertise ,
> I have no problem that ICG partly or totally meet with some of the group's
> in a combined session and not individually .
> We do not have time to do individual briefing . On the contrary each ICG
> members from those 13 communities fro which were previously identified
> before could meet with their respective community and brief then .In fact
> through that function they discharge their duties and responsibilities .
> I am not in favour of combined meeting just to talk on issues which either
> are obvious or have not yet been identified or just talk for talk
> However, we have an extended open meeting in which those interested people
> could attend and share their views.
> It should be noted that there areas which we do not have a clear idea
> about e.g. ICANN enhanced accountability as the issue has been just raised.
> Some thing came to my mind from the on going exchange of the views
> expressed  recently and that is " Examining " what do we mean by examining
> in ICG apart from those operational communities in particular and other 9
> communities in general that might be in a position to make some test m what
> are the scope  of testing function.
> Could we have some explanation from those raising this issue please?
> Kavouss
> .
>
> 1
>
> *ICG Guidelines for Decision Making 17 September 2014 1. Purpose*
>
> The objective of this document is to assist the ICG (IANA Stewardship
> Transition Coordination
>
> Group) to optimize productivity and effectiveness in the process of making
> decisions.
>
> Participation in the decision making process is reserved to the full
> members of the ICG and
>
> hence does not include ICANN Board Liaison, ICANN Staff Liason Expert, or
> Secretariat.
>
> *2. Individual/Group Behavior and Norms*
>
> The ICG should operate under the principles of transparency and openness,
> which means, *inter*
>
> *alia*, that mailing lists are publicly archived, meetings are normally
> recorded and/or
>
> transcribed, and Statements of Interest (SOIs), to include any conflicts
> of interest (COI), are
>
> required from ICG members and shall be publicly available.
>
> ICG members should make every effort to respect the principles outlined in
> the ICANN
>
> Accountability and Transparency Framework, see
> http://www.icann.org/transparency/acct-transframeworks-
>
> principles-10jan08.pdf for further details1, taking into account that this
>
> accountability is under full review by ICANN within the global
> multistakeholder community.
>
> If an ICG member feels that these standards are being abused, she/he
> should appeal to the
>
> chair or one of the vice-chairs. It is important to emphasize that
> expressed disagreement is
>
> not, by itself, indicative of abusive behavior. At all times, ICG members
> should expect and
>
> hold themselves to respectful articulation of any points of disagreement.
> If abuse is
>
> demonstrated, the chair of the ICG in full consultation and collaboration
> with the two vice
>
> chairs needs to consider the matter and take necessary action, as
> appropriate to properly
>
> handle the case.
>
> ICG members should participate faithfully in the ICG’s process (e.g.,
> attending meetings,
>
> providing timely input, monitoring discussions and fully collaborating
> with each other to
>
> achieve the established objectives).
>
> The ICG will make all reasonable efforts to enable stakeholder communities
> to have
>
> appropriate time to consult on issues on which the ICG will make
> substantive decisions,
>
> including through public comment periods, where practicable and
> appropriate. Public
>
> comments received as a result of a public consultation held in relation to
> the activities of the
>
> ICG should be duly considered and carefully analyzed. In addition, the ICG
> should provide its
>
> 1
>
> Other best practices that can be considered include the ‘Statement on
> Respectful Online Communication’, see
>
> https://www.icann.org/en/system/files/files/respectful-communication.pdf.
>
> 2
>
> rationale for including or not the different comments received and, if
> appropriate, how these
>
> will be addressed in the report of the ICG.
>
> *3. Making, Revisiting and Reconsidering ICG Decisions*
>
> The ICG may make decisions on its public mailing list or during meetings.
> Meetings are to be
>
> conducted face-to-face or through conference calls.
>
> Unless it is specified before a meeting that the ICG is intending to
> finalize a decision during the
>
> meeting, the decisions taken at a meeting in which one or more members are
> absent should
>
> provide 7 calendar days for those absentee members to review the decision
> and provide any input
>
> related to it; such input would be considered at the subsequent meeting
> (physical, by
>
> correspondence, or by conference call) and taken into account, if so
> agreed.
>
> For cases where it has been previously agreed that a decision is to be
> made at a given meeting
>
> and one or more members are not present at that meeting, these members may
> provide their
>
> views to the ICG in advance in order for those views to be considered at
> the scheduled meeting.
>
> Should the decision made not be consistent with the views of those absent,
> there should be
>
> another attempt to find a suitable compromise. Absent members should be
> invited to provide the
>
> ICG with a written statement of their concerns for inclusion in the
> report/conclusions of the ICG.
>
> For cases where ICG proposes to finalize a decision in a scheduled meeting
> and some members
>
> are opposed to the decision reached at such meeting, there should be
> another attempt(s) to find a
>
> suitable compromise. Where that fails, member(s) who oppose should be
> invited to provide the
>
> ICG with a written statement of their concerns for inclusion in the
> report/conclusions of the ICG.
>
> *4. Methodology for Making Decisions a. Administrative Decisions*
>
> The ICG may encounter instances where it needs to select
> person(s)/officer(s) as applicable for
>
> particular tasks. For example, the ICG may need to select secretarial
> support, speakers for
>
> particular events, liaisons to particular groups or the media, or chairs
> or vice chairs. In some
>
> cases, it may become obvious through discussion that all interested ICG
> members (those who
>
> have expressed an opinion) agree on a particular selection. In those
> cases, a chair, vice chair, or
>
> designee may approve a particular selection on the basis of the obvious
> agreement of all of those
>
> who expressed an opinion.
>
> In other cases where multiple different opinions have been expressed, a
> chair, vice chair, or
>
> designee may choose to run a vote to make the selection. The selection
> should be done by a
>
> majority vote.
>
> 3
>
> *b. All Other Decisions*
>
> This section pertains to cases when the ICG encounters instances in which
> it needs to make
>
> decisions unrelated to administrative decisions described in Section 4(a)
> above; obvious
>
> examples are the decision to send the final transition proposal to NTIA as
> well as other
>
> intermediate decisions.
>
> The mechanism that allows the ICG to come to a final decision regarding a
> certain topic is based
>
> on the following principles:
>
> • The decisions addressed in this section relate to the handling and
> assembling of submitted
>
> proposal(s) and not decisions related to approval/rejection of the content
> of the proposals.
>
> The ICG is meant to assemble proposals from the various communities. If
> there is an issue
>
> with the subject matter of the proposals, it is not the role of the ICG to
> redraft them, but
>
> rather to return them to the originating communty for further work with
> guidance as to what
>
> issues need to be addressed.
>
> • The aim of the discussion should be to reach a conclusion that no ICG
> member opposes.
>
> • Reasons for opposition should be clearly stated, along with specific
> alternative language
>
> which would overcome the opposition, allowing the communities and the ICG,
> wherever
>
> possible, to understand concerns and identify compromise solutions.
>
> • The chair will provide a time frame (to be fixed according to the
> prevailing circumstances)
>
> for a given case under consideration, for discussion and consultation
> needed to address the
>
> specific issue.
>
> • When such time, or extension of such time, for the ICG to consider and
> attempt to
>
> accommodate objections has expired, the chair and vice chairs, in
> consultation with the
>
> members, should identify common ground relevant and appropriate to the
> issue under
>
> discussion and do their utmost to propose possible ways forward.
>
> • It is obvious that no single member or a small minority should be
> allowed to block the
>
> decision making process. In other words a situation where a minority would
> feel it needed to
>
> block consensus should be avoided. Counter voices need to be listened to
> very carefully and
>
> a serious attempt must be made to take all concerns into account. If a
> full agreement is not
>
> possible, those still in opposition should be invited to prepare a written
> explanation of their
>
> position that should be published with the decision. See relevant
> paragraphs below.
>
> • Determinations of consensus do not fit into a formula and the concept
> of what is a small
>
> minority will need to be determined on a case-by-case basis. Factors of
> determination may
>
> include the nature and seriousness of the objection, the scope of support
> for the objection
>
> (whole stakeholder community(ies) or a subset of one or more communities)
> and the attempts
>
> that have been made to resolve those objections. While consensus of all
> stakeholder
>
> communities is the objective, it seems clear from the NTIA requirements
> that the objection of
>
> a majority of an operational community would preclude the ability of the
> ICG to submit an
>
> 4
>
> acceptable consensus proposal. In other words, all stakeholder communities
> have a role in the
>
> development of the broad consensus called for; the nature, scope and
> breadth of support of
>
> concerns/objections within and across stakeholder communities will impact
> the ability of the
>
> ICG to submit a proposal that meets the requirements of the NTIA process.
> Concerns of an
>
> operational nature from one or more operational community would also
> significantly limit
>
> the ability of ICG to submit a proposal that meets the terms of the NTIA
> requirements.
>
> *c. Designation of recommendation*
>
> Following these basic principles, the chair will be responsible for
> designating each ICG
>
> position as having one of the following designations:
>
> • *Recommendation by consensus *- when no one in the group speaks against
> the
>
> recommendation in its last readings.
>
> • *Recommendation *- a position where consensus could not be reached
> after the matter is
>
> sufficiently debated and after the chair and two vice chairs together with
> interested parties
>
> have made their utmost efforts to find a satisfactory solution for the
> matter in order to
>
> achieve consensus. Those who still object to the recommendation should be
> invited to
>
> document their objections for the final report.
>
> One possible example in the “Recommendation” category, *inter alia*,
> could be that a
>
> Recommendation could be considered as adopted if at most a small minority
> disagree by
>
> documenting their objection(s), the representatives of an operational
> community significantly
>
> and directly affected by the conclusion have not been overruled, and the
> consensus sought was
>
> inclusive of all ICG communities. The ICG should bear in mind that the
> consensus that we are
>
> seeking must be inclusive of all stakeholder groups: the final proposal
> needs to reflect that there
>
> is broad support for the approach from across the communities, if it is to
> be an acceptable way
>
> forward.
>
> Minority views opposing the recommendation should be documented and
> attributed in the
>
> report.
>
> *The agreed and fundamental objective of the ICG is to reach at least the
> Recommendation designation in favor of forwarding the Proposal for the IANA
> Stewardship Transition to the NTIA.*
>
> In order to examine and evaluate the degree of acceptability of a
> Recommendation the
>
> following method is proposed for consideration, where necessary:
>
> i. The chair and/or vice chairs should establish a time frame for
> discussion about a
>
> particular issue. If that time frame expires and new issues are still
> being raised, the chair
>
> and/or vice chairs may extend the time frame for discussion, as the case
> may be. The
>
> above-mentioned time frame(s) should be clearly included in the summary of
> the
>
> discussions.
>
> ii. After the group has discussed an issue exhaustively for all issues to
> have been raised,
>
> understood and discussed, the chair and/or vice chairs make an evaluation
> of the
>
> 5
>
> designation and publish it for the group with a clear timescale to review.
> In establishing
>
> timescale, account should be taken of the related community discussion
> needed.
>
> iii. If any justified objection is raised concerning the designation, the
> chair and/or vicechairs
>
> should reevaluate and possibly publish an updated evaluation.
>
> Recommendation calls should always be available to the entire ICG and, for
> this reason,
>
> should be published on the designated mailing list to ensure that all ICG
> members have the
>
> opportunity to fully participate in the process. It is the role of the
> chair, in full consultation
>
> and collaboration with vice chairs, to designate that a recommendation has
> been achieved and
>
> to announce this designation to the ICG. Members of the ICG should be
> given the opportunity
>
> to raise objections to the designation done by the chair as part of the
> discussion, per the
>
> methodology outlined above.
>
> Any ICG member who believes that his/her contributions are being
> systematically ignored or
>
> discounted should discuss the circumstances with the ICG chair/vice
> chairs. The chair, in full
>
> consultation with vice chairs, needs to carefully examine the case with
> the view to find a
>
> satisfactory solution for the matter through all appropriate means. The
> conclusions of this
>
> discussion should be documented.
>
> Regarding approval of draft documents, a document is considered as a
> stable draft for approval,
>
> provided that the draft is available at least 7 calendar days before the
> date on which the approval
>
> process is scheduled.
> i.e
> CCS
>
> 2014-09-18 20:48 GMT+02:00 Alissa Cooper <alissa at cooperw.in>:
>
>> I agree with Lynn’s point below about responsibility — I actually think
>> one of the most important functions of this group is, as our charter
>> states, information sharing. And helping people understand how to engage
>> in the transition proposal development process is a critical component of
>> that, in my opinion.
>>
>> Also, I agree with those who have said we should not have an exclusive
>> list of groups that we meet with. We (and “we” can mean one or two people,
>> or a handful, or the whole group) should be willing to meet and talk with
>> any group that needs help understanding how to engage in the process. If
>> that means meeting with ICC-BASIS or doing a webinar for ISOC chapters or
>> having side meetings at ICANN51, we should do as many of those things as
>> we can accommodate. There are 30 of us and we should share the workload,
>> just as we’ve been doing with our other work. And with my IETF hat on,
>> there are plenty of people I could further delegate to who are very
>> capable of explaining the IETF process and how to participate in our
>> IANAPLAN working group process, and I would hope that we could leverage
>> them as well.
>>
>> We started this conversation about side meetings with the GAC and ALAC
>> because those groups pro-actively reached out to us and said “I’d like to
>> hear from you." If we need to proactively do outreach to other groups —
>> ccNSO? CWG? gNSO? RIRs? who else? — to see if they want to talk, we should
>> do it. Patrik, Mohamed, and I can work on that outreach for ICANN51 if
>> people want it and can help with providing appropriate contacts.
>>
>> I also wanted to make clear that the proposed GAC and ALAC side meetings
>> will be public (and likely translated into a few languages at least). So
>> there would be nothing other than scheduling conflicts preventing anyone
>> from attending or tuning in.
>>
>> Alissa
>>
>> On 9/18/14, 4:56 AM, "Lynn St.Amour" <Lynn at lstamour.org> wrote:
>>
>> >Not all communities have the same norms, expectations, or culture; nor
>> >are they necessarily working to the ones we are.   I believe we have a
>> >responsibility to make this process as accessible, inclusive, and
>> >understandable as possible.  In other words, to do whatever we can to
>> >minimize barriers to participation or support.  Dialogue in more focused
>> >groups can be very beneficial to all, as we have just seen in our own G11
>> >group on "consensus".
>> >
>> >I strongly support Martin and Manal's points.  Maybe those that are more
>> >reluctant could expound a bit?
>> >
>> >Best,
>> >Lynn
>> >
>> >On Sep 18, 2014, at 7:44 AM, Martin Boyle <Martin.Boyle at nominet.org.uk>
>> >wrote:
>> >
>> >> Joe is obviously a lot harder touch than me:  I have a lot of sympathy
>> >>for stakeholders in and outside the ICANN environment and the barriers
>> >>that they can confront in engaging in processes.  I also think that the
>> >>non-operational communities probably do need to understand how to engage
>> >>and we need to understand what their concerns are (and any barriers to
>> >>their engagement).  So these meetings should not be a chore but an
>> >>opportunity for us to make sure that what we receive on 15 January is in
>> >>good shape.
>> >>
>> >> So I’d be sympathetic to GAC and to ALAC in the ICANN meeting.
>> >>
>> >> I’m less concerned about the operational communities which are all well
>> >>represented on the ICG.  But even here, dialogue with the
>> >>cross-community working group has to be a useful part of the process.
>> >>
>> >> There will be a bit of an issue if we fail to communicate information
>> >>fairly – a question answered in one group might also be relevant for
>> >>another group.  I do not see this as irresolvable – we should keep a
>> >>note of questions and responses and either publish a FAQ or spend some
>> >>time at the open session bringing everyone up to the same place.
>> >>
>> >> Then we have the post RfP discussions:  surely a new environment and
>> >>again I think we will need to be generous with our time so that we
>> >>understand what people are saying and where concerns lie.  We need to
>> >>keep our dialogue open throughout the whole process so that we do not
>> >>get caught out by issues when we think we’ve sewn a credible package
>> >>together.
>> >>
>> >> Of course we do not all need to cover every stakeholder engagement
>> >>opportunity!
>> >>
>> >> Hope this helps
>> >>
>> >> Martin
>> >>
>> >>
>> >>
>> >> From: internal-cg-bounces at icann.org
>> >>[mailto:internal-cg-bounces at icann.org] On Behalf Of joseph alhadeff
>> >> Sent: 18 September 2014 12:04
>> >> To: internal-cg at icann.org
>> >> Subject: Re: [Internal-cg] Extended session in Los Angeles
>> >>
>> >> Patrik, colleagues:
>> >>
>> >> Based on Heather's comments and my experience interacting with a number
>> >>of governments not accustomed to the multistakeholder process in the Net
>> >>Mundial meeting, I think there may be a justification for a separate
>> >>meeting with GAC...  As much as I would prefer not to have such a
>> >>separate meeting, I am not sure that they would actively participate in
>> >>the extended forum your reference... We should be very specific however
>> >>that is would be a one time accommodation to assist in acclimation to
>> >>the process.
>> >>
>> >> On the forum session, perhaps we could set aside 45 minutes as Q&A with
>> >>communities?
>> >>
>> >> Joe
>> >>
>> >>
>> >> On 9/18/2014 6:29 AM, Patrik Fältström wrote:
>> >> All,
>> >>
>> >> Alice has checked and confirmed we could extend the time for the open
>> >>session in Los Angeles with 30 minutes, to 120 minutes.
>> >>
>> >> The time is as follows (timezone local time in Los Angeles):
>> >>
>> >> Thursday, 16 October.
>> >> Start time: 10:00
>> >> End time: 12:00
>> >>
>> >> I will come back with an updated proposal for agenda.
>> >>
>> >>    Patrik
>> >>
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> Internal-cg mailing list
>> >> Internal-cg at icann.org
>> >> https://mm.icann.org/mailman/listinfo/internal-cg
>> >>
>> >> _______________________________________________
>> >> Internal-cg mailing list
>> >> Internal-cg at icann.org
>> >> https://mm.icann.org/mailman/listinfo/internal-cg
>> >
>> >_______________________________________________
>> >Internal-cg mailing list
>> >Internal-cg at icann.org
>> >https://mm.icann.org/mailman/listinfo/internal-cg
>>
>>
>> _______________________________________________
>> Internal-cg mailing list
>> Internal-cg at icann.org
>> https://mm.icann.org/mailman/listinfo/internal-cg
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/internal-cg/attachments/20140918/0f32b731/attachment.html>


More information about the Internal-cg mailing list