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

Important: GAC Participation in ICG
by Milton L Mueller Aug. 19, 2014

Aug. 19, 2014

In this letter, I find myself unable to decode the meaning of this passage, and am asking Heather and/or other GAC members to clarify: "Your proposal that governments should also contribute as appropriate at the operational community working level is helpful and has been conveyed to the GAC. At this stage it would appear that the GAC and individual governments and inter-governmental organisations can best contribute at this level through the community process for domain name issues." In this statement, does "this level" mean the ICG level? Or does the statement that "governments and inter-governmental organisations can best contribute at this level through the community process for domain name issues" mean that GAC is agreeing with our suggestion that they contribute to the the operational community working level? I can't tell for sure from this statement, but I fear it is the former. If so, are GAC members are telling us that they are unable or unwilling to participate in the actual proposal development process in the operational communities? If so, do they fully understand that the substantive proposals will actually come from that lower level, not from the ICG, and that neither GACs nor governments as actors will be able to second-guess, veto or otherwise modify or intervene substantively in the incoming proposals from the ICG? Milton L Mueller Laura J and L. Douglas Meredith Professor Syracuse University School of Information Studies http://faculty.ischool.syr.edu/mueller/ From: internal-cg-bounces(a)icann.org [mailto:internal-cg-bounces@icann.org] On Behalf Of Patrik Fältström Sent: Tuesday, August 19, 2014 4:41 AM To: Alissa Cooper Cc: ICG Subject: Re: [Internal-cg] FW: GAC Participation in ICG FWIW, I created a folder in Dropbox named "communication" where I saved this letter. Patrik On 19 aug 2014, at 05:18, Alissa Cooper <alissa(a)cooperw.in<mailto:alissa@cooperw.in>> wrote: On 8/18/14, 7:33 PM, "Tom Dale" <tom(a)acig.com.au<mailto:tom@acig.com.au>> wrote: Dear Alissa On behalf of the GAC Chair, please find attached a reply to the ICG's correspondence of 18 July 2014. Regards Tom Dale ACIG GAC Secretariat ACIG - Australian Continuous Improvement Group evaluate :: improve :: innovate Cell: + 61 418 207 376 tom(a)acig.com.au<mailto:michelle@acig.com.au> www.acig.com.au<http://www.acig.com.au/> ACIG is an independent consulting firm engaged to provide secretariat support to ICANN's Governmental Advisory Committee. <GAC ICG ReplyFINAL.docx>_______________________________________________ Internal-cg mailing list Internal-cg(a)icann.org<mailto:Internal-cg@icann.org> https://mm.icann.org/mailman/listinfo/internal-cg

2 2

Annotated agenda for Aug 19 call
by Alissa Cooper Aug. 19, 2014

Aug. 19, 2014

Agenda with document names and links: 12:00 - 12:10 Welcome and logistics (Alissa) Introductions of those who were not present in London 12:10 - 12:15 Chair appointments and roles (Joseph) Minutes approval (Alissa) Documents: Transcript - Call 01 - 10July2014.pdf https://www.dropbox.com/s/a3qyu84lr9tgg17/Transcript%20-%20Call%2001%20-%201 0July2014.pdf Minutes of first meeting of the Coordination Group - Day 1 - v2.docx https://www.dropbox.com/s/qeybo9uouo0ocp1/Minutes%20of%20first%20meeting%20o f%20the%20Coordination%20Group%20-%20Day%201%20-%20v2.docx Minutes of first meeting of the Coordination Group - Day 2 - v2.docx https://www.dropbox.com/s/cmh3y6cy34a5l67/Minutes%20of%20first%20meeting%20o f%20the%20Coordination%20Group%20-%20Day%202%20-%20v2.docx IANA steward correspondence group matrix - v4 https://www.dropbox.com/s/k9wmaq4jx5txl3x/IANA%20steward%20correspondence%20 group%20matrix%20-%20v4.docx 12:15 - 12:40 Consensus process (Wolf-Ulrich) ICG-Consensus Building_draft_v2_MI_wuk.doc https://www.dropbox.com/s/u0gjhuq53kg7nks/ICG-Consensus%20Building_draft_v2_ MI_wuk.doc 12:40 - 13:05 Charter (Jari) Document is forthcoming 13:05 - 13:25 Communities RFP (Paul) IANA Transition RFP v07 (ALC-MM-AAA-MB-MartinB).docx https://www.dropbox.com/s/5255k2ysxg5htbi/IANA%20Transition%20RFP%20v07%20%2 8ALC-MM-AAA-MB-MartinB%29.docx 13:25 - 13:45 Secretariat (Adiel) ICG-Secretariat-v03.docx https://www.dropbox.com/s/i613y9e7oie72r4/ICG-Secretariat-v03.docx 13:45 - 13:55 IGF statement (Joe) 13:55 - 14:00 Wrap-up (Alissa)

4 5

Doodle for Communities RFP call
by Alissa Cooper Aug. 19, 2014

Aug. 19, 2014

Please fill out your availability by Aug 20 at 23:59 UTC so we can get a call on the calendar to discuss the communities RFP: http://doodle.com/2c9q7isrdxtz5fuv The 12:00-14:00 UTC time slot was the most popular on many days in the August call poll, so I narrowed the choices to that time frame. Note: It’s possible that some interpreters will not be available next week. Alice is checking. What do people think about having a call to discuss the communities RFP if we are missing a couple of languages? Thanks, Alissa

1 0

How many proposals? and ccTLDs/gTLDs
by Alissa Cooper Aug. 19, 2014

Aug. 19, 2014

Over in the thread about the communities RFP [1], some of us have been discussing how many proposals the ICG should request and expect. We also discussed this in London. My feeling is that as far as full community proposals — i.e., documents that contain all five sections of the latest RFP proposal [2], fully completed — we should be open to receiving either 3 proposals (names, numbers, protocol parameters) or 4 proposals (gTLDs, ccTLDs, numbers, protocol parameters). >From all the discussions I’ve had with ccTLD folks, it seems as though both their current arrangements and what they may potentially propose for post-transition arrangements could differ from what gets proposed for gTLDs (although not necessarily in incompatible ways). I think we should be open to this possibility. Of course, we would expect the ccTLD community and the gTLD community to work together to try to align themselves on areas of overlap, in the same way that we expect all of the other communities to do so. And our preference would still be for 3 proposals rather than 4. Saying that we should be open to accepting 3 or 4 full proposals is *not* the same as saying we should be open to receiving 10 or 20, where any stakeholder can submit a full proposal. I don’t think this would be productive, and I don’t know what we as the ICG would do with proposals that do not come from the operational communities. Of course, we want individual stakeholders to be able to provide input and feedback, and I think we’ve done a good job of outlining our expectations as far as how that will work in the charter. But soliciting input is different from soliciting a full proposal for any of the functions — those should come from the operational communities. This leaves the case Milton has pointed out, where an operational community splits into two or three groups that produce separate proposals for the same function. Again, this is not ideal, and I think we should set the expectation that we want to receive at most 1 proposal from each operational community (with the caveat above about ccTLDs vs. gTLDs). If it turns out that we get two or three proposals for the same function from different factions of the same community, we’ll have to deal with that then (I don’t know how), but the expectation we should set from the outset is for uniformity within each community. One way to smooth over the potential faction problem would be to build on one of the requirements we already have in the RFP (Section V), which is for the communities to provide an assessment of the consensus level and a description of areas of contention or disagreement. If a particular community develops a minority faction with a counter-proposal to what the rest of the community proposes, it could be documented there (and we would probably want to elaborate that better in the RFP). But I think this would only work if the counter-proposal could be viewed as a minority opinion, and I’m not sure if that’s a plausible scenario for any of the communities. Thoughts? I mostly want to jump start this discussion among the names folks, as I expect it to be fairly straightforward the protocol parameters community to produce a single proposal, and the same for numbers. Thanks, Alissa [1] http://mm.icann.org/pipermail/internal-cg/2014-August/000869.html [2] https://www.dropbox.com/s/ztrzblyax0540m5/IANA%20Transition%20RFP%20v07%20%2 8ALC-MM%29.docx

7 7

FW: GAC Participation in ICG
by Alissa Cooper Aug. 19, 2014

Aug. 19, 2014

On 8/18/14, 7:33 PM, "Tom Dale" <tom(a)acig.com.au> wrote: > Dear Alissa > > On behalf of the GAC Chair, please find attached a reply to the ICG's > correspondence of 18 July 2014. > > Regards > > Tom Dale > ACIG GAC Secretariat > > > ACIG - Australian Continuous Improvement Group > evaluate :: improve :: innovate > > Cell: + 61 418 207 376 > tom(a)acig.com.au <mailto:michelle@acig.com.au> > www.acig.com.au <http://www.acig.com.au/> > > ACIG is an independent consulting firm engaged to provide secretariat support > to ICANN's Governmental Advisory Committee. >

3 2

Today - ICG Call #2
by Alice Jansen Aug. 19, 2014

Aug. 19, 2014

Dear ICG Members, This is to kindly remind you that your ICG call #2 is **TODAY** At 12:00-14:00 UTC See timezone conversion at: http://www.timeanddate.com/worldclock/fixedtime.html?msg=ICG+Call+%232&iso=… Call details were emailed to you in off-list notifications on August 8th. You should also have received an outlook calendar invite which includes the call details. In you cannot find them, please send me an email (off-list) and I will make sure to send you a copy prior to the call. Documents will be projected in the virtual meeting room - https://icann.adobeconnect.com/icg/ (enter as a guest). To avoid echo, please make sure to mute your computer speakers as live audio from the meeting is being broadcast from the virtual meeting room. If you plan to use Skype to join the bridge, see attached instructions on how to mute the virtual meeting room. Note that the virtual meeting room will also be used to monitor the queue. To join the queue, press the "raise your hand" icon in the Adobe Connect room: [cid:0F9BDBB1-1CB3-4647-AD74-7C8B20D7B8D9] If you are not in a position to join the virtual meeting room today, please let me know. We would be very grateful if you could also state your name when speaking as the call will be recorded, transcribed and interpreted (into UN languages + Portuguese). As always, please do not hesitate to contact me should you have any questions or concerns. Thanks, Best regards Alice

1 0

Re: [Internal-cg] Reminder - Travel - ICG Mtg #2 - By tomorrow COB
by Alissa Cooper Aug. 19, 2014

Aug. 19, 2014

Hi Alice, Apologies for not catching this earlier: I believe in London we had some discussion about the importance of ICG participants engaging with constituencies outside of the normal ICANN ones and outside of ICANN meetings. For those who require travel support, having support solely to fly in the night before the ICG meeting, which is taking place after the IGF, seems to severely limit their capability to engage with the broader community attending the IGF. In my view the IGF is perhaps one of the most important broader venues in which ICG participants may engage, since it draws a diverse global audience and has on its own agenda topics related to the work of the ICG. Thus I think it would be preferable if supported travelers can obtain support to arrive in time to participate in the IGF. Please advise the group about this possibility. (Note that I’m asking on behalf of supported travelers and for the benefit of the group as a whole as I’m not seeking travel support myself.) Thanks, Alissa On 8/4/14, 9:16 AM, "Alice Jansen" <alice.jansen(a)icann.org> wrote: > Dear ICG Members, > Should you need travel support to attend the ICG Mtg #2 (6 September), please > be kindly reminded to return the attached travel request form to > cgtravel(a)icann.org by tomorrow – Tuesday, 5 August 2014 – COB. See below for > more information. > Thanks, > Best regards > Alice > From: Alice Jansen <alice.jansen(a)icann.org> > Date: Friday, August 1, 2014 2:34 PM > To: "internal-cg(a)icann.org" <internal-cg(a)icann.org> > Subject: Reminder - Travel & Visas- ICG Mtg #2 > > Dear ICG Members, > Should you need travel support to attend the ICG Mtg #2 (6 September), this is > to kindly remind you to please return the attached travel request form to > cgtravel(a)icann.org as soon as possible and no later than Tuesday, 5 August – > COB. Note that delays in providing your information will not guarantee travel > support. Supported travelers must book their air travel with ICANN's > authorized travel agent, where the cost will be billed directly to ICANN. > Hotel rooms and tax for a specified meeting will be arranged and paid for > directly by ICANN in accordance with the authorized arrival and departure > dates (5-7 September 2014). ICANN will only book and pay for a non-refundable, > lowest logical price airfare, and economy airfare. Reimbursement will be > permitted for meeting attendance and other reasonable incidental expenses > incurred. > May we also invite you to go to https://www.evisa.gov.tr/en/ for visa-related > information. > Thanks - > Best regards > Alice > > From: Alice Jansen <alice.jansen(a)icann.org> > Date: Wednesday, July 30, 2014 11:57 PM > To: "internal-cg(a)icann.org" <internal-cg(a)icann.org> > Subject: PLEASE READ - ICG Mtg #2 - Travel & RP > > Dear ICG Members, > > As announced by Alissa, the ICG in-person meeting # 2 will take place on: > > > ** Saturday, 6 September 2014** > At the Grand Hyatt <http://istanbul.grand.hyatt.com/en/hotel/home.html> in > Istanbul > Meeting room: Tyana 1&2 > 09:00-17:30 EEST – 06:00-14:30 UTC > See timezone conversion at: http://tinyurl.com/qz5zjh3 > > Remote participation (RP) features will be available for ICG members who are > not in a position to attend the meeting in person. > > Remote Participation & Interpreting > The global multistakeholder community will be able to follow your exchanges > through the virtual meeting room: https://icann.adobeconnect.com/icg/ > <https://icann.adobeconnect.com/icg/> . Coordination Group Members > participating remotely in the meeting should join the adobe connect room to > view any material being displayed in the meeting room. > The dial-in bridge details will be sent to you in a separate email (off list). > Please note that we will have interpreting services at the meeting. Links to > the respective languages are available below: > * English - http://stream.icann.org:8000/icg-en.m3u > <http://stream.icann.org:8000/icg-en.m3u> > > * French - http://stream.icann.org:8000/icg-fr.m3u > <http://stream.icann.org:8000/icg-fr.m3u> > > * Spanish - http://stream.icann.org:8000/icg-es.m3u > <http://stream.icann.org:8000/icg-es.m3u> > > * Chinese - http://stream.icann.org:8000/icg-zh.m3u > <http://stream.icann.org:8000/icg-zh.m3u> > > * Russian - http://stream.icann.org:8000/icg-ru.m3u > <http://stream.icann.org:8000/icg-ru.m3u> > > * Arabic - http://stream.icann.org:8000/icg-ar.m3u > <http://stream.icann.org:8000/icg-ar.m3u> > > * Portuguese - http://stream.icann.org:8000/icg-pt.m3u > <http://stream.icann.org:8000/icg-pt.m3u> > > The community will be also be able to follow the real time transcript (RTT) at > http://www.streamtext.net/player?event=06Sep2014icg (also available in the > virtual meeting room). > > > Travel Support > As indicated in the process published on 6 June 2014, meal and lodging costs > for ICG members to participate in ICG meetings will be covered by ICANN, upon > request and in accordance with ICANN's community travel support guidelines > <https://www.icann.org/resources/pages/travel-support-2012-02-25-en> . > Supported travelers must book their air travel with ICANN's authorized travel > agent, where the cost will be billed directly to ICANN. > > Hotel rooms and tax for a specified meeting will be arranged and paid for > directly by ICANN in accordance with the authorized arrival and departure > dates (5-7 September 2014) for each supported traveler. ICANN will only book > and pay for a non-refundable, lowest logical price airfare, and economy > airfare. Reimbursement will be permitted for meeting attendance and other > reasonable incidental expenses incurred. > > Should you need travel support to attend this meeting, please inform ICANN > staff as soon as possible and no later than Tuesday, 5 August – COB. ICANN > staff will require your duly completed travel support request form (attached) > to process your request – kindly ensure to return it to cgtravel(a)icann.org > within the timeframe identified above. Note that delays in providing your > information will not guarantee travel support. > > Should you have already made travel arrangements to attend the IGF meeting in > Istanbul, please inform staff (off list) whether you need travel support to > extend your stay. > > Thank you - > Best regards, > Alice > _______________________________________________ Internal-cg mailing list > Internal-cg(a)icann.org https://mm.icann.org/mailman/listinfo/internal-cg

7 8

Officer vote
by Joseph Alhadeff Aug. 19, 2014

Aug. 19, 2014

Colleagues A short reminder that a number of members have still to cast a vote for chair/vice chair... Joe Sent from my iPad

3 2

Re: [Internal-cg] Revised RFP
by Mohamed El Bashir Aug. 18, 2014

Aug. 18, 2014

Dear All, i have reviewed the latest version of the RFP v7, the document follow and formatting is good. following up the recent comments from Adiel, milton and Alissa, I am concerned that we are planning to limit the proposals submissions only the 3 or 4 operational communities, this approach will sending a negative message to the global internet community observing this process and will rise questions about the transparency, inclusiveness and objective of the process. The current NTIA/ICANN IANA function contract (clause C.1.3 ) identify a list of “interested and affected communities” which ICANN should consult/engage with in matters related to IANA Functions ( this include naming, numbering, protocol, end users communities ), both the affected "operational" interested "non-operational" communities should be able to submit proposals to ICG ( if they wish to do so ). The interested "non-operational" communities are already represented in ICG, the community should decide submit a proposal ( following the RFP requirements and NTIA principles ) or participate in the affected "operational" communities proposal development process and not submit its own proposal . How ICG will review/manage submitted proposals ? we are encouraging the communities to consult with their stakeholders and sub-committees in the process of the proposal development, if a proposal is submitted directly to ICG not through the communities channel, we should be able to direct vendor "submitter" to the community process and not consider the proposal as it dose not meet the submission requirements . ICG is expected to be reviewing the proposals submitted by the communities ( either 3 - 4 from the operational communities and/or 2 if interested communities wished to do so . I have updated v7 in dropbox with my above comments. Regards, Mohamed On Fri, Aug 15, 2014 at 8:13 AM, Russ Mundy <mundy(a)tislabs.com> wrote: > Folks, > > I realize that there have been some folks questioning the need to > request/suggest that the operational communities' proposals make reference > to the ICANN proposal portion of the IANA Functions Contract. I believe > there was only one email from Daniel questioning the need for this > reference but there were a couple of comments in version 6 revision > associated with deleting the wording from the RFP. > > In our current draft Charter, we commit to " • (ii) Assess the outputs > of the three operational communities for compatibility and > interoperability". For the ICG to meet this commitment, we must have some > common point of reference used by all the operational communities in > preparing their respective proposals or we will not be able to meet > commitment (ii). > > Each of the operational communities has a different central focus and > varying degrees of documentation of their own processes but each overlaps > the other to various degrees. The current RFP provides a good structure > for the proposals but the actual content of each proposal will almost > certainly reflect each community's central focus and processes. Since > there is no common reference point for the communities, it is very unlikely > that the proposals will provide enough details in their content for us (the > ICG) to assess compatibility and interoperability of the 3 (or 4) > operational communities' proposals. > > The ICG does not have the time to produce a substantially more detailed > RFP where we could expect comparable proposal content from the operational > communities. I believe that the various versions of the RFP will provide > common format but will not provide comparable information. I believe that > the solution is to ask that the proposals make appropriate references to > the only document that describes current operational implementation of all > the operational communities i.e., the ICANN proposal portion of the IANA > Functions Contract. > > Meeting commitment (ii) will be a challenge even with a single point of > reference for all proposals from the operational community. However, > without a single point of reference, it will not be possible for the ICG to > actually meet commitment (ii). > > As a related point, I do prefer the structure of version 7 over earlier > versions. > > Thoughts and responses are very welcome. > > Regards, > > Russ > > > > > On Aug 14, 2014, at 04:00 AM, Alissa Cooper <alissa(a)cooperw.in> wrote: > > > >> Thanks. Comments in-line. > >> > >> On 8/13/14, 1:31 PM, "Milton L Mueller" <mueller(a)syr.edu> wrote: > >> > >>> Nice job on the whole! Your approach to mapping transitions, which > builds > >>> on mine, is simpler. > >>> I approve of the use of the charter language on operational > communities. > >>> > >>> In the attached version, I've accepted the changes I think are > >>> uncontroversial, so as to produce a cleaner document; made a few minor > >>> changes, and added some comments that address questions raised by > Alissa. > >>> > >>> Only major changes are, I still think we need a checkbox at the > beginning > >>> telling us what community the proposal is coming form, > >> > >> I’m fine with this, with the caveat that I think it should just be > listed > >> in words in Section I. It’s highly likely that the proposal for protocol > >> parameters will come in the form of ASCII text (as all IETF documents > do), > >> and reproducing a checkbox in ASCII seems unnecessary. So I would > suggest > >> that the first sentence of Section I should say: > >> > >> "This section should identify your community as names, numbers, or > >> protocol parameters, and it should list the specific, distinct IANA > >> services or activities your community relies on." > >> > >> > >>> and I think we still need to ask them about overlaps or > interdependencies > >>> among the IANA services requirements across communities. > >> > >> Agreed. > >> > >>> > >>> > >>> Also, I agree with you that we will need to discuss who we expect to > >>> receive proposals from, I make a few comments on that. > >> > >> I will start a separate thread on this. > >> > >> Alissa > >> > >>> > >>> --MM > >>> > >>>> -----Original Message----- > >>>> From: Alissa Cooper [mailto:alissa@cooperw.in] > >>>> Sent: Wednesday, August 13, 2014 3:19 PM > >>>> To: Milton L Mueller; internal-cg(a)icann.org > >>>> Subject: Re: [Internal-cg] Revised RFP > >>>> > >>>> 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 > >>> > >> > >> > >> _______________________________________________ > >> 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 > >

8 8

IANA Stewardship Transition Session at IGF Istanbul ..
by Manal Ismail Aug. 18, 2014

Aug. 18, 2014

Dear All .. This is just to bring to your attention that I have been asked to participate to the IANA stewardship transition part of the session titled "IANA Functions: NTIA's Stewardship Transition and ICANN's Accountability Process", that is to be held at the IGF in Istanbul, on Day 4 - Sep. 5th, 2014 from 09:30 to 11:00 at the Main Meeting Room .. I understand that, apart from an ICG statement, panelists will be representing individual views, yet thought to share with you the below questions, that we've got to know in advance of the session .. Happy to discuss and coordinate as necessary .. Kind Regards --Manal ------------------------------------------------------------------------ -- Transition of NTIA's Stewardship of the IANA Functions: 1. How is the IANA transition discussion evolving? 2. How will the various parties involved in the IANA functions be affected by these proposals? 3. What are the expectations with respect to the timeline and how could the process improve to meet the deadline? 4. Does ICANN internationalization process present a risk in terms of favouring forum shopping or other questionable practices from the organization? 5. What should be the appropriate checks and balances for the new stewardship function - handled by the global multistakeholder community? 6. How is the ICG dealing with the parallel process of the accountability discussion? 7. Are there alternative scenarios if the deadline of Sept. 2015 is not met? -----------------------------------------

2 2