August 2014 - Internal-cg - lists.icann.org

SSAC Document that describes IANA: SAC067
by Patrik Fältström Aug. 17, 2014

Aug. 17, 2014

All, As I have mentioned a few times The Security and Stability Advisory Committee of ICANN (SSAC) has been working on a description of IANA. We just released document SAC067, "Overview and History of the IANA Functions". https://www.icann.org/en/system/files/files/sac-067-en.pdf Regards, Patrik

3 2

Reminder: Charter comments due
by Alissa Cooper Aug. 15, 2014

Aug. 15, 2014

Just a reminder that if you have comments on the charter, or if you have comments to deliver from your community, they should be sent to the list by 23:59 UTC today so that Jari can propose a revised charter prior to the August 19 call. Thanks, Alissa

1 0

Subject lines and Silence was RE: Consensus building process
by Narelle Clark Aug. 15, 2014

Aug. 15, 2014

[I'm sorry to add to the procedural/working methods topics. Most of them I consider 'bike shed' items.] > -----Original Message----- > From: internal-cg-bounces(a)icann.org [mailto:internal-cg-bounces@icann.org] On Behalf Of Joseph Alhadeff > Sent: Tuesday, 12 August 2014 11:26 PM > > The first thing we need for a mostly online process is an interpretation of > silence. Does it mean consent? If there are two positions put forward how > is silence understood? As we all know silence comes from several sources: - attention elsewhere (for whatever project related/unrelated/good/bad reason) - everything needed to be said has been said by others - irrelevant/low priority item - missed/lost item I want to mention the last option right now as I am finding the volume of mail is swamping things on the list that actually need my attention. Can I please therefore request a couple of norms: - adjusting the subject line when the topic shifts - prepending the subject with some useful tags eg: URG=urgent, ACT=requires action, VOTE=vote required, FYI... That way I know if there is a time sensitive, urgent action required, and don't have to unpick it from a mail trail. > Based on our current track record as a group, > everything will end up in a doodle poll. At the end of the day, perhaps we > need to publish statistics on who's participating in the process? None of us > were nominated to be mere observers, and if the will of the group in > question is not to have an opinion on a specific topic, then they should say > so. If they need more time for consultation they should say so. If they > agree or disagree, or have comments, they should say so in a timely basis. > Silence is very counterproductive.... Old whine in a new post :-) Your idea of timely is in a vastly different time zone to me. Some mornings I find 20 posts in a thread. Repeating other well-worded posts on a topic adds to the noise, not the signal within this group. This does not mean a lack of participation, either now or in the future. Also, if topics are not clearly broken out from mail trails/threads they are buried. Narelle -- Narelle Clark Director of Operations - Deputy CEO Australian Communications Consumer Action Network Suite 402 Level 4, 55 Mountain St Ultimo NSW 2007 Ph: 02 9288 4000 Direct: +61 2 9288 4007 Fax: 02 9288 4019 TTY: 02 9281 5322 Follow us on twitter @ACCAN_AU – Sign up for our weekly WebNews – Visit our website --------------------------------------------- The information contained in or attached to this message is intended only for the people it is addressed to. If you are not the intended recipient, any use, disclosure or copying of this information is unauthorised and prohibited. This information may be confidential or subject to legal privilege. If you receive this e-mail in error, please notify the sender immediately and delete the e-mail and any attachments. The Australian Communications Consumer Action Network does not warrant that the information in this e-mail or any attachments are free from any viruses, defects, errors, interception or interference.

1 0

Re: [Internal-cg] Revised RFP
by Alissa Cooper Aug. 15, 2014

Aug. 15, 2014

Hi all, I reviewed the various RFP versions, including the version that Milton recently sent. I’ve attached and uploaded to Dropbox my own suggested version. I know there is a danger in suggesting yet another different format, but let me try to explain my thinking. I sympathize with Milton’s concern that the community proposals need to make a clear distinction between existing, pre-transition arrangements and proposed, post-transition ones. However, by creating a table with a “now” column and a “future” column for every element in the RFP, I think we would be giving the communities the wrong impression that they should be thinking about possible changes to all aspects of IANA. That is a much wider scope than what we have all agreed to work on and what NTIA is asking for, I believe. Of course discussions about stewardship transition may (and already have) spurred discussions about changes to other aspects, which is great, but I don’t think those things are in the scope of what we specifically are asking the communities for. So, in the attached version, I’ve done a re-organization. The document is divided into two main parts: Introduction and Required Proposal Elements. The outline of the Required Proposal Elements section is as follows: I. Description of Community’s Use of IANA II. Existing, Pre-Transition Arrangements A. Policy B. Oversight and Accountability III. Proposed Post-Transition Oversight and Accountability Arrangements IV. Transition Implications V. Community Process I think this structure makes it more clear where we’re asking for descriptions of existing arrangements, and where we’re asking for proposed changes related to the transition (and specifically related to oversight and accountability). Some other changes I suggest: * I think we still need more clarity on who we’re asking for proposals from and how many we expect to receive. I found the existing drafts muddled on this point and tried to clarify. We might also still have some disagreements about this — good topic for discussion on the call next week. In any event, I adopted the “operational communities” language from the charter so that we can be consistent. * On Russ Mundy’s point about the current contract: I agree with Daniel that we can’t really require the communities to leverage the existing contract any more than they want to. So I softened this language a bit. * In the Required Proposal Elements sections, I tried to re-use as many of the existing bullet points/table rows as possible, but for many of them I found myself wondering what the bullets actually meant. I think this is not the best sign, since as an IETF participant I wouldn’t necessarily know what to put in a protocol parameters proposal in response to this RFP. So I tried to elaborate on the bullet points somewhat. I may or may not have captured their intended meaning, and I put comments in on some of them when I really didn’t know what they were aiming towards. Best, Alissa On 8/11/14, 1:33 PM, "Milton L Mueller" <mueller(a)syr.edu> wrote: >Dear colleagues >I spent some time thinking about the RFP and how it could be improved and >came up with the attached draft, which is also in Dropbox. >I changed some language in the preamble, with some comments in Word >explaining why. > >The main change, however is one of format. I think when commnities fill >out this form we will need a clear distinction between what their >requirements, policy processes, etc. are NOW, and what they are proposing >to CHANGE. Therefore I have > created a series of tables that lines up Current arrangements from >Proposed arrangements. This should make it clearer what exactly they are >proposing to change and what the implications might be. > > >Take a look > >Milton L Mueller >Professor, Syracuse University School of Information Studies >Internet Governance Project >http://internetgovernance.org > > > > > >_______________________________________________ >Internal-cg mailing list >Internal-cg@icann.orghttps://mm.icann.org/mailman/listinfo/internal-cg

5 5

Draft agenda for Aug 19 call
by Alissa Cooper Aug. 14, 2014

Aug. 14, 2014

A draft agenda for the Aug 19 call is below. All times are listed in UTC. Please send feedback/edits. 12:00 - 12:10 Welcome and logistics (Alissa) 12:10 - 12:35 Consensus process (Wolf-Ulrich) 12:35 - 13:00 Charter (Jari) 13:00 - 13:25 Communities RFP (Paul) 13:25 - 13:45 Secretariat (Adiel) 13:45 - 13:55 IGF statement (Joe) 13:55 - 14:00 Wrap-up (Alissa) Note: I intend to use the “raise hand” feature of Adobe Connect to run the speaking queue during the call, so everyone will need to join the Adobe Connect room. Thanks, Alissa

2 2

Chair/Co-Chair Votes
by James M. Bladel Aug. 14, 2014

Aug. 14, 2014

Chair: Alissa Co-Chair: Wolf-Ulrich Co-Chair: Patrik ________________________________ Thanks- J.

2 1

ICG Officer Vote
by Hartmut Richard Glaser Aug. 14, 2014

Aug. 14, 2014

chair => Alissa Cooper vice-chair => Mohamed El Bashir vice-chair => Wolf-Ulrich Knoben

1 0

Re: [Internal-cg] Public observers at Sept F2F
by Alice Jansen Aug. 13, 2014

Aug. 13, 2014

Dear All, This is to confirm that the information was added to the announcement - see: https://www.icann.org/news/announcement-2014-07-16-en Thanks, Best regards Alice On 8/11/14 10:30 PM, "Alissa Cooper" <alissa(a)cooperw.in> wrote: >Hi all, > >I think a few folks have been receiving questions about whether we will be >able to accommodate public observers in the room with us during the Sept 6 >face-to-face meeting. Because we had to find meeting space on short >notice, we were not able to find a room where there will be space for >public observers to attend in person. Of course the meeting will be live >streamed via Adobe Connect. > >I¹d like to ask the ICANN folks to add this bit of information to the web >site where the meeting information has been posted. > >Also, it would be helpful to know if ICG participants would generally >prefer to try to meet in spaces that can accommodate public observers in >the future. > >Thanks, >Alissa > > >_______________________________________________ >Internal-cg mailing list >Internal-cg(a)icann.org >https://mm.icann.org/mailman/listinfo/internal-cg

1 0

Public observers at Sept F2F
by Alissa Cooper Aug. 13, 2014

Aug. 13, 2014

Hi all, I think a few folks have been receiving questions about whether we will be able to accommodate public observers in the room with us during the Sept 6 face-to-face meeting. Because we had to find meeting space on short notice, we were not able to find a room where there will be space for public observers to attend in person. Of course the meeting will be live streamed via Adobe Connect. I’d like to ask the ICANN folks to add this bit of information to the web site where the meeting information has been posted. Also, it would be helpful to know if ICG participants would generally prefer to try to meet in spaces that can accommodate public observers in the future. Thanks, Alissa

9 8

Re: [Internal-cg] Consensus building process
by Kavouss Arasteh Aug. 13, 2014

Aug. 13, 2014

Dear Martin, I DO NOT BELIEVE, YOU NEED ANY CROSS REF ERNCE TO SOMEBODY ELSE , VIEWS. It is his views and no more . Voting is one of the major and fundamental criteria in any democracy society. LEADERSHIP AND PRESEIDENTS AND PARTIES TO TAKE POWER IN ANY DENMOCRATIC COUNTRY are electedf through voting No doubt ,every and utmost efforts should be made to avoid voting at conférences, meeting and foa and take an internationally agreed approach of CONSENSUS BUILDING. However, if othe circumstances do not allow that we need to look for avaialble alternative. Having said that I am in favour of consensus ( without anxy adjective) building KAVOUSS 2014-08-13 9:22 GMT+02:00 Martin Boyle <Martin.Boyle(a)nominet.org.uk>: > Dear Kavouss, > > > > OFF LIST as I generally agree with both Milton’s comments and your reply > to him. > > > > My reference to WCIT was to the statement from Dr Touré about voting and > the breakdown in the search for compromise that we saw at the end of the > process. > > > > I think I have been quite clear about my views on consensus (hence why > this is off list) – soft, rough, whatever: if it leaves a significant > party out, it is not consensus and will break down later. The discussions > should never try to impose an unreasonable compromise. > > > > As you note, the process should be one of continued discussion to find > real consensus (within the constraints of time), to which I would add the > importance of there being a real effort to achieve this consensus by all > parties. > > > > Regards > > > > Martin > > > > > > *From:* Kavouss Arasteh [mailto:kavouss.arasteh@gmail.com] > *Sent:* 12 August 2014 19:16 > *To:* Martin Boyle > > *Cc:* Coordination Group > *Subject:* Re: [Internal-cg] Consensus building process > > > > Dear Martin > > I do not clearly understand your illusion to WCIT. > > Please just tell me, what happened if the views of those dealing with > naming, or numbers, or protocle remained a minority views and the rest > are joining what do you call rough consensus. > > Let us imagine also that we go ahead with such soft consensus in which a > valid views of one of these groups are not taken into account > > > > Do you still believe that such a soft or rough consensus disregarding the > views of one key player could be considered a valid outcome > > Pls comment. > > I am of the strong view that the chair should further and further discuss > until we find a real ( not rough .not soft ,not hard ) consensus > > Kavouss > > > > 2014-08-12 19:23 GMT+02:00 Martin Boyle <Martin.Boyle(a)nominet.org.uk>: > > Hi All, > > > > First thanks to Wolf-Ulrich for his paper. I greatly like the idea of > standards of good behaviour and mutual respect – and I’m pleased to see > that this is already very much the framework for the way that the ICG > works. I’d also note that the analysis of shades of grey in levels of > support is interesting – was it Patrik who first noted the two extremes > (non-substantial and substantial issues) and the level of consensus that > might be needed? I’m just not sure I know how to use them… > > > > I’d firmly endorse the aim that “the ICG … reach at least Consensus on the > Proposal for the IANA Stewardship Transition to be forwarded to the NTIA” > subject to our continued effort to try to achieve full/unanimous consensus > or (at least) to have addressed address points of concern. > > > > However, I do not like processes that are supposed to be by consensus > being resolved by voting (cf WCIT): voting leaves winners and losers. It > also means that people get lazy and fail to look for compromise or common > ground or ways to address “reasonable” concerns. That aversion is not > really addressed by supermajorities: even at an 80% supermajority, all the > domain name registries or all the government representatives or all GNSO > members could be overruled. At 85% all the ccTLD registries, at 90% all > the gTLD registries could be ignored. > > > > I do recognise the need for a mechanism that allows us to come to a final > recommendation and I’m afraid that I do not see any magic wand. But I > would suggest a number of basic principles: > > > > · The aim of the discussion should be to try to find a solution > where **no member of the ICG still maintains serious opposition to the > outcome.** Reasons for objections should be given, allowing the ICG > wherever possible to try to address those concerns. > > · **Recourse to any form of voting should be the exception.** > Its use might be fine for non-substantive issues. For substantive issues, > at least none of the “customer groups” (numbers, protocols, gTLDs or > ccTLDs) of the IANA remains strongly opposed. > > · Group members who still have problems with the evaluation > should be invited to **identify possible ways in which the proposal could > be modified to make it acceptable to them.** > > · Discussions should continue until **no “IANA customer” group is > firmly opposed.** > > > > One final point: I would be willing to allow anyone who feels that they > have not been heard to put a minority view into the final report. I’d > rather that did not happen, but if the views are strong enough, it would be > best to have then documented in the report than to be first aired in the > discussion that follows the publication of our final report. > > > > Cheers > > > > Martin > > > > > > > > *From:* internal-cg-bounces(a)icann.org [mailto: > internal-cg-bounces(a)icann.org] *On Behalf Of *Kavouss Arasteh > *Sent:* 11 August 2014 20:48 > *To:* Drazek, Keith > > > *Cc:* Coordination Group > *Subject:* Re: [Internal-cg] Consensus building process > > > > Dear All, > > Undoubtedly, it would be super majority either 2/3 or 4/5 . > > Kavouss > > > > 2014-08-11 18:18 GMT+02:00 Drazek, Keith <kdrazek(a)verisign.com>: > > I agree that we will need a clear process for determining consensus that > falls somewhere on the spectrum between humming and requiring a unanimous > vote. > > If we get in to discussions of voting, we'll also need to address the > thresholds required to establish consensus. Is it a simple majority? > Super-majority? Unanimous voting is an unhelpful requirement that would > likely obstruct our work and our ability to deliver, so I believe that > should be a non-starter for the ICG. We need to avoid the possibility of > one dissenting vote undermining an otherwise strongly supported > recommendation that represents broad community consensus. > > However, if/when there is not full consensus, it will be important that we > have a mechanism for expressing dissenting opinions. The GNSO Registries > Stakeholder Group employs a "minority statement" mechanism to allow for all > views to be expressed when there is consensus but not unanimity on a > particular topic. Perhaps we should consider a similar mechanism for the > ICG. > > Keith > > > -----Original Message----- > From: internal-cg-bounces(a)icann.org [mailto:internal-cg-bounces@icann.org] > On Behalf Of Subrenat, Jean-Jacques > Sent: Monday, August 11, 2014 6:09 AM > To: Kavouss Arasteh > Cc: Coordination Group > Subject: Re: [Internal-cg] Consensus building process > > Hello Colleagues, > > From the experience of the past few weeks, unfortunately we can conclude > that the current process is not successful. Rather than meting out blame or > praise, we need to understand why it's not working. Group dynamics and a > bit of sociology can help. > > Our Coordination Group is different from what some of us/you have come to > consider as "normal". The technical bodies (IETF, IAB) have developed an > efficient process where "rough consensus" is understood and accepted. But > other components of the ICG have different habits, and also a different > accountability mechanism: however attractive "rough" may be, it is > insufficient. For example, the GAC has its own rules (a joint position can > only be reached by unanimity), and the ALAC routinely conducts all its > votes on a full-membership basis (each member has to say ay, nay, abstain, > or be noted down as not having cast a vote). > > So the challenge is this: is the "rough consensus" really adapted to all > the needs of our group? With the experience gained collectively in London, > and especially since then, I would recommend a dual approach: > > A/ MATTERS REQUIRING ALL MEMBERS TO VOTE (typically, to be decided as soon > as possible, with the exception of our Transition plan) > - Chair structure and membership, > - Charter of the ICG, > - choice of Secretariat (ICANN or outside of ICANN, or a mixture of > both), > - choice of near-final drafts and approval of final draft of our > Transition plan, before presentation to the NTIA. > > B/ MATTERS WHERE OTHER FORMS OF DECISION-MAKING ARE ACCEPTABLE > - Appraisal of specific community input, as a contribution to the ICG's > recommended plan (e.g. ALAC should appraise input from its own community > before submitting it to the whole ICG), > - external relations and communications of the ICG (once the Chair > structure has been chosen and populated, it may wish to ask Chair, or > another of its members, to be the point of contact), > - administrative & logistic matters, in conjunction with the chosen > Secretariat (here too, delegation would be possible). > > I'm prepared to provide a more detailed proposal for the above items. > > Best regards, > Jean-Jacques. > > > > ----- Mail original ----- > De: "Kavouss Arasteh" <kavouss.arasteh(a)gmail.com> > À: "Patrik Fältström" <paf(a)frobbit.se> > Cc: "Coordination Group" <internal-cg(a)icann.org> > Envoyé: Lundi 11 Août 2014 10:40:08 > Objet: Re: [Internal-cg] Consensus building process > > > > > Dear Wolf > Thank you very much for reply > My point is that if one or more ICG Mmember(s) is7are againszt the ruling > of the Chir ,They could raise their issue and the matter must be settled by > simple explanation or if not resolved by voting . I.E. CHAIR DOES NOT HAVE > DECISION MAKING POWER ON HE OR HIS OWN WISHES RATHER TO TAKE INTO ACCOUNT > VIEWS OF MEMBERS Regards KAVOUSS Regards > > > > > > 2014-08-11 8:33 GMT+02:00 Patrik Fältström < paf(a)frobbit.se > : > > > > > On 11 aug 2014, at 08:09, WUKnoben < wolf-ulrich.knoben(a)t-online.de > > wrote: > > > The chair’s designation that consensus is reached is not her/his own > decision rather than a wrap-up of extensive discussions. Of course this > designation can be challenged by members. And this is what triggers your > question about “If several participants in the ICG disagree with the > designation given ...”. I’m open to any helpful suggestion on how we could > procede in such a case. > > In the end consensus - as defined – has to be achieved. > > Let me emphasize what you say here, which I strongly agree with. > > We must deliver. > > This implies we must be able to reach consensus. > > The last couple of weeks discussions on various topics makes me a bit > pessimistic on the ability for us to reach consensus, but I am optimistic, > always optimistic, on peoples ability and interest in actually deliver. > > Remember that the chair is calling on the consensus question, not the > substance. That way the power of the chair is decreased to a minimum and > process issues. > > Patrik > > > > _______________________________________________ > Internal-cg mailing list > Internal-cg(a)icann.org > https://mm.icann.org/mailman/listinfo/internal-cg > _______________________________________________ > Internal-cg mailing list > Internal-cg(a)icann.org > https://mm.icann.org/mailman/listinfo/internal-cg > _______________________________________________ > Internal-cg mailing list > Internal-cg(a)icann.org > https://mm.icann.org/mailman/listinfo/internal-cg > > > > > _______________________________________________ > Internal-cg mailing list > Internal-cg(a)icann.org > https://mm.icann.org/mailman/listinfo/internal-cg > > >

1 0