December 2012 - ALAC - lists.icann.org

Prague Schedule / Tuesday 16 October 2012
by At-Large Staff July 17, 2013

July 17, 2013

Dear All, Please find hereafter the At-Large schedule for tomorrow, Tuesday 16 October 2012 with all remote participation details listed on the ICANN Schedule: Wiki Agenda page: http://tinyurl.com/9h95fo6 ICANN Schedule: http://toronto45.icann.org/full-schedule Meeting Room Map: http://toronto45.icann.org/files/meetings/toronto2012/45-Toronto-VenueMap-3O ct12.png * 07:00 - 08:00 NARALO Capacity Building Session 2 Regatta Room http://toronto45.icann.org/node/34285 * 08:00 - 09:00 Joint NARALO / Fellows Meeting 2 Frontenac http://toronto45.icann.org/node/34283 * 08:30 09:30: Meeting with ICANN Board Metro East http://toronto45.icann.org/node/34289 * 10:00 - 11:00: At-Large Capacity Building: Next Steps Regatta http://toronto45.icann.org/node/34307 * 11:00 13:00: ALAC Policy Discussion Part 1 Regatta http://toronto45.icann.org/node/34313 13:00 - 14:00 LUNCH break * 14:00 16:00: ALAC Policy Discussion Part 2 Regatta http://toronto45.icann.org/node/34327 * 16:00 - 17:00: Registrant Rights and Responsibilities Working Group Regatta http://toronto45.icann.org/node/34353 * 17:00 18:00: At-Large Outreach Sub-Committee Meeting Regatta http://toronto45.icann.org/node/34361 General Meetings: Please refer to full Schedule: http://prague44.icann.org/full-schedule Thank you. Regards, Heidi Ullrich, Silvia Vivanco, Matt Ashtiani, Gisella Gruber, and Nathalie Peregrine ICANN Policy Staff in support of ALAC E-mail: staff(a)atlarge.icann.org

4 14

Fwd: Re: Realignment of SO and At-Large appointed seats on the ICANN Board
by Olivier MJ Crepin-Leblond Dec. 23, 2012

Dec. 23, 2012

FYI -------- Original Message -------- Subject: Re: Realignment of SO and At-Large appointed seats on the ICANN Board Date: Sun, 23 Dec 2012 23:15:45 +0100 From: Olivier MJ Crepin-Leblond <ocl(a)gih.com> To: Steve Crocker <steve(a)shinkuro.com> CC: louie(a)louie.net Lee <louie(a)louie.net>, Lesley Cowley <lesley(a)nominet.org.uk>, Jonathan Robinson <jonathan.robinson(a)ipracon.com>, Bruce Tonkin <Bruce.Tonkin(a)melbourneit.com.au>, John Jeffrey <john.jeffrey(a)icann.org>, Diane Schroeder <diane.schroeder(a)icann.org> Dear Steve, thank you very much for your kind message explaining the changes. As you know, the ALAC has supported this realignment in its statement published at: http://www.atlarge.icann.org/correspondence/correspondence-2-10nov12-en.htm The news will therefore be very much welcomed by our community. Best wishes, Olivier MJ Crépin-Leblond ALAC Chair On 23/12/2012 22:09, Steve Crocker wrote: > [Resending with an updated address for Jonathan] > > > Louie, Lesley, Jonathan and Olivier, > > I write to you in roles as the chairs of the ASO, ccNSO, GNSO and ALAC. You are likely already aware that last Thursday the ICANN Board passed the resolution realigning the terms of the Board seats your organizations fill, and you will receive further correspondence through regular official channels, but I also wanted to pass the news myself and offer a brief comment. > > The resolution and corresponding rationale are posted at http://www.icann.org/en/groups/board/documents/resolutions-20dec12-en.htm#2… > > With this change, the seating of the Board members you appoint is aligned with the seating of Board members appointed by the Nomcom. Thus all voting seats, except for the CEO, will be for three years beginning and end with the Annual General Meeting (AGM). We will now have three voting seats being selected each year, two or three by the Nomcom, two by the SOs, and one by At-Large during the years the Nomcom selects two. > > A key provision of this change is your selection of Board members is unchanged. The original reason for the offset was to provide information to the Nomcom on the geographic balance of the Board. The Nomcom still needs that information, so your selection process should proceed on the same schedule it always has. > > In the upcoming year, Bruce Tonkin's and Kuo-Wei Wu's terms expire. Under the prior rule, their terms would have expired in April. Under the new rule, their terms expire in November. Similar extensions apply to the others in the following years. > > I am pleased this change moved through the process smoothly. while it is not our most important piece of work this year, it will helpful in smoothing Board operations. In particular, I believe it will actually enhance the position of the SO and At-Large appointed Board members. In the past these Board members have sometimes been unable to move into leadership positions during the their first half year and sometimes have stepped down from from leadership positions during their last half year. > > Let me also take this opportunity to thank you for your extraordinary dedication and leadership. It has been and will continue to be a pleasure to work with all you. > > I hope this note finds you well and well into a period of relaxation and enjoyment of the holiday period. > > Cheers, > > Steve Crocker > ICANN Board Chair > -- Olivier MJ Crépin-Leblond, PhD http://www.gih.com/ocl.html

1 0

Re: [ALAC] Fwd: [council] Draft reply to Fadi
by Alan Greenberg Dec. 20, 2012

Dec. 20, 2012

Regardless of agreement or disagreement with the content, the letter WAS extremely well crafted. Alan At 20/12/2012 10:58 AM, Carlton Samuels wrote: >Um, the letter is quite clever in the use of the FUD technique; it >appropriates Fadi's words and writings to a) show his agreement with >their positions or b) suggests confusion on the implications of his >words with their positions. All things to all people. Should be a >doozy, the discussion. > >On one hand, it is adamant that TMCH should cover only existing >rights and not extended for non-justiciable rights. So that is >settled he goes; hold the current line on 'local' marks etc., >regardless of implications for new GTLDs. > >However,the letter also seems to be conceding that there are trade >mark rights 'beyond law' - the only rational meaning I can think of >here is 'the body of law to which they generally subscribe' - some >of which are now excluded in the TMCH concept. I would, for >example, put said 'local' marks in this category. > >So now, he seems to be messaging, never mind the left-handed >approach, the GNSO may be open to consider RPMs for these in another PDP. > >And then it seems to be shaking the finger at the ICANN Board for >not only its apparent embrace of 'additional rights' before they are >told to but for setting expectations that RPMs will be in place to >address them in time for launch of new GTLDs! Almost in the same >breath, it also refers to [U.S.] DoC letter urging considerations >for additional rights protection "across all TLDs". > >Hmm, wonder what he was thinking here? Who's tail is wagging the >ICANN dog? In any event, this fella has some very useful skills for >this arena. I'm impressed. > >-Carlton > >============================== >Carlton A Samuels >Mobile: 876-818-1799 >Strategy, Planning, Governance, Assessment & Turnaround >============================= > > >On Wed, Dec 19, 2012 at 7:00 PM, Alan Greenberg ><<mailto:alan.greenberg@mcgill.ca>alan.greenberg(a)mcgill.ca> wrote: >Of some interest to the ALAC, here is a draft letter to the CEO in >response to his asking for GNSO guidance on the strawman proposal. > >Note that this is a letter drafted by one Councillor and has not >been ratified by the Council. If it is actually sent, it could well >be substantially modified. > >The GNSO Council meeting overlaps with the ALAC meeting tomorrow, >and I will be joining the ALAC call half-way through. I will report >at that time how this played out. > >Alan > > >From: Mason Cole <<mailto:mcole@5x5com.com>mcole(a)5x5com.com> >Subject: [council] Draft reply to Fadi >Date: Fri, 14 Dec 2012 11:11:47 -0800 >To: "<mailto:council@gnso.icann.org>council(a)gnso.icann.org List" ><<mailto:council@gnso.icann.org>council(a)gnso.icann.org> > >Council colleagues -- > >I have taken the liberty of drafting a reply to Fadi's request for >Council advice on the BC/IPC request for more RPMs. Jonathan and I >have spoken about a process from here and I am happy to keep the pen >for possible suggestions and edits. Speaking for myself, though I >realize the holidays are fast approaching I would hope we can get a >communication to Fadi expeditiously. > >Many thanks -- > >Mason > > >_______________________________________________ >ALAC mailing list ><mailto:ALAC@atlarge-lists.icann.org>ALAC(a)atlarge-lists.icann.org >https://atlarge-lists.icann.org/mailman/listinfo/alac > >At-Large Online: <http://www.atlarge.icann.org>http://www.atlarge.icann.org >ALAC Working Wiki: ><https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(AL…>https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(AL… >

2 1

Fwd: [council] Draft reply to Fadi
by Alan Greenberg Dec. 20, 2012

Dec. 20, 2012

Of some interest to the ALAC, here is a draft letter to the CEO in response to his asking for GNSO guidance on the strawman proposal. Note that this is a letter drafted by one Councillor and has not been ratified by the Council. If it is actually sent, it could well be substantially modified. The GNSO Council meeting overlaps with the ALAC meeting tomorrow, and I will be joining the ALAC call half-way through. I will report at that time how this played out. Alan >From: Mason Cole <mcole(a)5x5com.com> >Subject: [council] Draft reply to Fadi >Date: Fri, 14 Dec 2012 11:11:47 -0800 >To: "council(a)gnso.icann.org List" <council(a)gnso.icann.org> > >Council colleagues -- > >I have taken the liberty of drafting a reply to Fadi's request for >Council advice on the BC/IPC request for more RPMs. Jonathan and I >have spoken about a process from here and I am happy to keep the pen >for possible suggestions and edits. Speaking for myself, though I >realize the holidays are fast approaching I would hope we can get a >communication to Fadi expeditiously. > >Many thanks -- > >Mason

2 1

ICANN and measurement of "consumer trust" -- yeah, right
by Evan Leibovitch Dec. 18, 2012

Dec. 18, 2012

GNSO's Consumer Choice, Trust, and Competition Working Group<http://gnso.icann.org/en/group-activities/consumer-trust-wg.htm>, on which I have sat since its inception, was an ill-conceived 2010 direction from the Board to identify metrics that could be used to demonstrate that the new gTLD program provides benefit to registrants and end-users. (Of course, in any sane organization such measurement would have been done *before* actually determining need for gTLD expansion, but I digress...) So this working group was tasked with developing metrics that would -- after the fact -- serve to demonstrate that ICANN has justified in going through the expansion. This working group has finished its final report<http://gnso.icann.org/en/issues/cctc/cctc-final-advice-letter-05dec12-en.pdf>, and will be submitting it to the GNSO council soon. If endorsement of the report comes to ALAC for consideration as-is, I will oppose its endorsement and I ask for other ALAC members to join me in its rejection. To be sure, there are some possibly-useful metrics for registrants proposed -- such as whether trademark takedown claims will be higher with new gTLDs than with the existing ones. But it is already noted that some of these metrics will be difficult or expensive to implement, and may either be unsupported or actively impeded by registrars if not required in the RAA. The biggest metric from and end-user point of view -- a survey of whether end users around the world will encounter less cybersquatting, confusion, park sites, malware, etc -- is crammed into a single item (1.4), with a proposed "picked from thin air" budget of $100,000, and acknowledgement that even the creation of the survey's questions will be challenging. More important, though, is what is missing from the recommendations. Much like ICANN exists in its own bubble shielded from the world, there are no metrics that go outside the scope of the TLD expansion itself. Nothing is proposed to determine whether people are even preferring domain names to get to Internet content over alternatives such as search engines, QR codes, domain-name-shorterning services or social media portals and shortcuts(*). That is -- IMO one of the most important metrics -- whether the gTLD expansion is turning people away from the DNS itself, towards friendlier and less confusing ways for end-users to reach their Internet destinations. I have been presenting this issue to the WG from day one. It was deemed out of scope. Though wording of mine indicating the need for greater scope was put in the report's preamble, it is highly unlikely that ICANN will act upon anything not called for in this report. Still, I was willing to support the recommendations as being better than nothing. In October a "final" statement<http://forum.icann.org/lists/gnso-consumercci-dt/bin58KclzeJuJ.bin>, that had the consensus support of the working group, was produced and prepared for the GNSO. (The link has a "bin" extension but opens as an msword document). At that point, a member the registry constituency -- who had not been part of the consensus, or for that matter ever participated in the working group up to that moment -- demanded that significant parts of the metrics be dropped. The metrics to be dropped eliminated "closed" TLDs from many important measurements. They elimininated, for one thing, the masurement of whether "closed" TLDs are providing easy-to-find information of how to report abuse, or how domains in that TLD are allocated. After more than a year of hard-fought consensus, during a call which I was unable to attend, these demands caused changes to many specific metrics that now renders them useless. What were once objective audits (2.1 and 2.2) are now undefined "measurements of understanding", a process that is difficult, expensive, and trivially ease to deliberately misinterpret. I don't believe that measuring public attitudes should distinguish between "closed" and "open" TLDs whose domains are all publicly accessible. If a domain in a new TLD is the source of malware, spam or any kind of end-user confusion, does it matter to the end user whether that domain is open or closed? Anyway, what is now being presented to the GNSO is a "new" final report that incorporates these demands. My protests about both the content changes and their last-minute inclusion have been met with personal attack and threats that the Registry SG would scuttle approval of the Report unless it incorporated their demands. So much for consensus. The registries have a vote at GNSO and we don't. The report includes a letter I send in August in its appendix, but refuses to note any minority dissent to the last-minute changes to its "final" report. One might be tempted to say, "having some metrics is better than having no metrics", especially having invested substantial personal capital in creating them. But I suggest otherwise -- that the newly-created biases in the questions, along with the changes from audits to uselessly subjective measurements, will lead to results that will be embarassing to ICANN while demonstrating nothing after much needless expense -- in other words, worse than if nothing is done. In its non-consensus revised report, the WG has pacified the domain industry's refusal to measure things whose results would be embarrassing, at the expense of ICANN's own credibility to measure itself. There are two other At-Large members on this WG who did not support my objections -- Cheryl and Olivier can certainly speak for themselves why not. So perhaps the accusations were correct, and I stand alone in my assertion -- that these metrics in their current form are just a PR stunt so that ICANN can justify its TLD expansion after-the-fact. In any case, I ask you to consider the issue and understand why I refuse to endorse it. The main saving grace of all this is that, in the scheme of things, it's not very important. If ICANN botches how it measures its success, others (with non-ICANN-positive biases) will be happy to step in to fill the void.It's not even policy (which makes me wonder why the Board gave this to the GNSO in the first place). If anyone is interested in working with me on an alternative ALAC statement on how ICANN can demonstrate the improvement of consumer trust in its actions, please let me know. Otherwise, I'll explain my objection, vote appropriately if endorsement comes to a vote, and move on. - Evan (*) yes, QR codes and shortening services still require the DNS, but they don't need a TLD expansion either, as they could work with obscure or third-level domains in existing TLDs.

4 5

Urgent - ALAC consideration of governance oversight and review mechanism for IDNA Label Generation Rules for the Root Zone
by Rinalia Abdul Rahim Dec. 18, 2012

Dec. 18, 2012

Dear ALAC, The IDN Working Group is currently working on a draft ALAC statement in response to the Procedure to Develop and Maintain the Label Generation Rules for the Root Zone in Respect of IDNA Labels – Second Public Comment Draft<http://www.icann.org/en/resources/idn/draft-lgr-procedure-07dec12-en.pdf> [PDF, 790 KB]. There is one critical aspect of this document that I believe merits an urgent ALAC discussion prior to the finalization of the statement: *The only governance oversight for the decisions of the Integration (Expert) Panel is **the ICANN Public Comments and there is no alternative formal review/appeal mechanism*. There appears to be a resistance to alternative forms of governance oversight. This resistance is premised on a position that the Integrated Panel of experts needs to be independent because what is at stake is the security and stability of the root, which affect all Internet users. The ALAC needs to consider whether there should be alternative governance and policy oversight as well as periodic review of the process as per other key aspects of ICANN work. In considering alternative options, the ALAC should consider both the advantages as well as the risks involved. I have requested Edmon Chung as the At-Large IDN Policy Liaison to lead this discussion at the ALAC level. The deadline for submitting a statement in response to the document is Jan 6, 2013. Given the upcoming holiday period and the need to address this critical matter satisfactorily, urgency is recommended. Below I have pasted what I consider to be relevant extracts from the document to help inform the discussion - I apologize for the length - the actual document is about 70 pages long. I highly recommend that ALAC members read the full document for a more comprehensive view. Best regards, Rinalia Abdul Rahim * Extracts related to the Public Comments Process as governance oversight mechanism* (bold emphasis is mine) "Submitting proposals: The generation panel, when it has completed its work, sends its proposals to the integration panel. At the same time, the generation panel’s proposals are posted for public comment using the ICANN public comment procedures then prevailing. This permits those who did not participate in the generation panel in question to make their views known to the integration panel. A well-functioning public comment procedure is a critical component of this procedure, because there is no formal appeal mechanism. If ICANN’s public comment procedures do not attract attention to the proposals, the procedure is at serious risk of capture by those who do take an interest." "A rejection of a proposal (by the Integration Panel) must be accompanied by a justification citing the specific issues with the proposal that gave rise to the rejection. The justification must include an accounting of which (if any) of the Principles the proposal violates according to the integration panel, as well as every other justification the integration panel has for its decision. Every rejection by the integration panel must be available on the Internet; a web-accessible archive of the decisions is sufficient to meet this requirement." "Decisions by the integration panel are required to be unanimous; any proposal that does not attract unanimous acceptance is automatically not accepted, on the grounds that any proposal that does not attract unanimous support within the integration panel (assuming that panel is doing its job) must be violating one or more of the Principles. The integration panel must take into account any public comments submitted in response to the posting of the generation panel’s output. The integration panel must also publish its decisions and rationales for public comment, and must explicitly take all public comments into account, and publish a report on this review (see B.4.5). Public comment is the only mechanism, short of dismissal of some (or every) integration panel member, by which the integration panel can be held accountable." "Since the integration panel is required to make its determination unanimously, a single objector in disagreement with the rest of the integration panel will prevent the integration panel from accepting a generation panel’s proposal. In case of such disagreement, the integration panel’s reasons for rejection should include an indication that the panel is divided, must include the reasoning behind the objection, and should include details of any disagreement within the panel." "Decision of the integration panel is atomic: The integration panel’s evaluation of a given generation panel’s output is atomic: either it accepts a proposal completely, or it rejects it completely. That is, the integration panel is free to reject a generation panel’s recommendations, but it is not free to amend the details of the generation panel’s proposal. It may, however, return a generation panel’s proposal with a suggestion about what would change the opinion of the integration panel. Most importantly, the integration panel is required to provide detailed reasoning for its rejection in every case. The integration panel’s decision is public; it cannot be appealed, but the generation panel is free to submit the proposal again (altered or unaltered)." *One exceptional review by ICANN Board specified in the document* "Panels, Conservatism, and the Limits of Knowledge: In all matters the integration panel’s judgment is to be governed by the Conservatism and Stability Principles. If the integration panel delivers a repertoire while there is still work to be done on other parts of Unicode, as is inevitable, we expect subsequent iterations of the repertoire. We expect those iterations to increase the size of the repertoire, and not to remove any code point or change any code point variant rules to reflect the new inclusions. *If an iteration of the process causes a subsequent repertoire to remove a code point that was in an earlier repertoire or to change an existing variant rule, all operation of the procedure must halt. A review of the process must ensue to determine whether it is effective at following the principles outlined in Section A.3, and whether it is possible (and how) to add additional checks to the procedure to avoid recurrence of similar failures. Because it is impossible to state in advance what the failure might be (since if we knew, we could write rules to avoid it), the ICANN Board will determine the nature and scope of the review, and will appoint the reviewers.* If such halts are called frequently, that is a reason to believe that this procedure does not work, in which case a new (likely more conservative) procedure will be needed. One effect of the overarching Conservatism Principle should be that these events will not happen frequently; but given the procedure’s reliance on human judgment, it may be necessary to tolerate errors from time to time." * **Overview of Two Pass Process involving Generation Panel and Integration Panel *Process for developing IDN TLD variant label generation rules consists of two passes. "The first pass creates a set of label generation rules specific to a given script, writing system, language, or all of these; this task is carried out by Rule Generation Panels composed of people with deep experience or interest in the script, writing system or language used by some community of Internet users - Generation Panel. These panels will submit their proposals for the LGR to an ICANN TLD IDN Label Generation Rule Integration Panel consisting of independent experts in DNS, Unicode and scripts that has responsibility for the second pass. This second pass involves integrating the proposals into a single unified LGR for the root zone, taking into account the need for a secure, stable and reliable DNS root zone. These two kinds of panels are assisted by advisors, who observe the activities of any or all active panels; who provide comment and advice on the topics of IDNA, Unicode, DNS, linguistics, ICANN policy and process, or other matters; but who do not otherwise have a formal role in making a decision..." * Composition of Integration Panel* (bold emphasis is mine to illustrate controls that should be in place to govern conduct of Panel members) "The integration panel, whether made of consultants, staff, or both, should consist entirely of experts selected by ICANN on the basis of established expertise. *The experts are to be duly qualified against ethical conflicts, in order to minimize the possibility, or any appearance, that the interested parties might capture the process. Experts are to be in a contractual relation with ICANN, so that ICANN may require, as part of its contract with the panelists, impartial and unbiased evaluation.* The panel requires at least one expert in Unicode issues, at least one expert in IDNA and DNS issues (or one for each), and at least one expert in linguistics and writing systems (who could be the same as the first expert, but need not and often will not be). It is worth emphasizing that the supply of actual general experts in any of the relevant areas of expertise is extremely limited. This represents a potential risk to the procedure. The integration panel is a technical working panel, not a representative or deliberative body. It should be kept small in the interest of efficiency, but should not contain fewer then three members at any time. The integration panel is expected to make extensive use of advisors to aid their deliberations. No current or past member of any generation panel may be a member of the integration panel, because the integration panel is responsible for reviewing output from the generation panels." *Label generation rule integration procedure* (bold emphasis is mine) "The integration panel reviews the output of every generation panel from which a proposal is available at the time the integration panel begins review. The integration panel evaluates each proposal. The integration panel first confirms that the proposal stays within the maximal set of code points for the root zone defined by the integration panel, and that it conforms to the other requirements for output set forth in this document. It then evaluates the proposal for consistency with the Principles and for the risk it presents, in the context of the maximal set of Unicode code points for the root zone.* Proposals that do not meet the principles or create, in the judgment of the integration panel, unacceptable systemic risk are rejected.* A generation panel's proposal may be to permanently exclude a code point, which would factor in this evaluation. The integration panel further ensures all proposals together form an internally coherent set of label generation rules, and rejects any proposals that are in conflict. It is at this stage that the integration panel reviews the whole-label evaluation rules, both in the context of the given generation panel proposal, as well as in the context of all such proposals. Based on the Simplicity and Predictability Principles, the integration panel ensures that structurally comparable writing systems have consistent whole-label evaluation rules. Finally, it reviews whether the proposals collectively meet any other requirements (e.g. symmetry) set forth in this document. Proposals that fail this review will be rejected. A rejection of a proposal must be accompanied by a justification citing the specific issues with the proposal that gave rise to the rejection. The justification must include an accounting of which (if any) of the Principles the proposal violates according to the integration panel, as well as every other justification the integration panel has for its decision. Every rejection by the integration panel must be available on the Internet; a web-accessible archive of the decisions is sufficient to meet this requirement. Unlike the generation panels, the integration panel will consider possible interactions with Unicode characters outside the proposed set of rules and, if necessary, reject the generation panel's proposal based on such issues. The integration panel includes in its evaluation possible sets of rules that are not yet proposed, as might happen when a writing system did not initially attract a generation panel but might be expected to attract one in future. Decisions by the integration panel are required to be unanimous; any proposal that does not attract unanimous acceptance is automatically not accepted, on the grounds that any proposal that does not attract unanimous support within the integration panel (assuming that panel is doing its job) must be violating one or more of the Principles. The integration panel must take into account any public comments submitted in response to the posting of the generation panel’s output. The integration panel must also publish its decisions and rationales for public comment, and must explicitly take all public comments into account, and publish a report on this review (see B.4.5). Public comment is the only mechanism, short of dismissal of some (or every) integration panel member, by which the integration panel can be held accountable. While there may be a “first mover advantage” to the establishment of generation panels, the order in which the integration panel would evaluate proposals would be based roughly on the order in which the generation panels produce their proposals, and in any case constrained by the need to evaluate all proposals in context of each other, and compared to the rest of the basic constrained repertoire. Since the integration panel is required to make its determination unanimously, a single objector in disagreement with the rest of the integration panel will prevent the integration panel from accepting a generation panel’s proposal. In case of such disagreement, the integration panel’s reasons for rejection should include an indication that the panel is divided, must include the reasoning behind the objection, and should include details of any disagreement within the panel." END

3 3

Fwd: [governance] Reply to Milton's blog post
by Oksana Prykhodko Dec. 16, 2012

Dec. 16, 2012

Dear all, I am extremely sorry for my mistake. I received the letter from Olivier, and I decided, that it was posted on this list. I wrote my comments to it as for ALAC members. But it was IGC list((( For IGC list I was preparing to raise broader scale of issues. This was written espesially for ALAC. Now I just resend my letter to this list. It is extremely important for me to receive your feed-backs. Best regards, Oksana ---------- Forwarded message ---------- From: Oksana Prykhodko <sana.pryhod(a)gmail.com> Date: 2012/12/16 Subject: Re: [governance] Reply to Milton's blog post To: governance(a)lists.igcaucus.org, "Peter H. Hellmonds" <peter.hellmonds(a)hellmonds.eu> Копия: Olivier MJ Crepin-Leblond <ocl(a)gih.com> Dear Olivier, Thank you very-very-very much for all your work at all and for this letter especially. My country signed (according to official information on ITU web-site) ITRs. But there were some chances they would not do it. And I am sure that we just lacked some pressure on our official delegates at this moment, so physical absence of Ukrainian CS was wery negative. I asked to include me in the official delegation, and they did not do it, because they did not have money for my trip. I am not sure that they really did it if I had money, but at that moment I had nothing to answer to them. I had real chance to participate in this conference as a journalist (by the way, Ukrainian media absolutely ignored this event). I am sure that it might have some impact, but again I did not have money. In Baku I participated on my own expences, and it was real financial disaster for me. But the workshop I organized (thousand of thanks to all who participated in it) and a lot of other discussions are priceless for me. I like very much the word multistakeholderism, but let us stop just to talk about it! We have to analyze where it works and where and when it does not work and why. I am sure that in developing countries it nearly does not work, while exactly multistakeholderism (in all sheres) and informational technologies can transform developing countries into developed one. Just few remarks on it. 1. Respective roles of each stakeholder. Our former prime-minister Yulia Timoshenko is in prison now for signing international treaty without enough seal. I am not saying that I support such treatment, but I am sure that dozens of Ukrainian officials HAVE to be in prison for signing international treaties without enough seal.Very often the only one reason to sign any treaty for them is to put money into their own pockets. Our government concerns with Internet issues. Our Communication Administration (State Service of Special Communication and Information Protection of Ukraine !!!!!) ignored my propositions because they could not open my file in .odt (!!!!!). They use only Windows, and 70 % of this software (in governmental agencies!!!) are steal. And they will protect cybersecurity and dictate to me what to do and what not to do in Internet! 2. Transparency - Ukraine is the member of GAC (on paper). But now I am said that ICANN is not international organization, so why Ukraine has to be the member of it? But WE ARE the member! But it is impossible now to find documents who and when apllied for GAC from Ukraine. I am not even talking on WCIT - no ANY information on official site of Ukrainian agency. 3. Accountability - no words at all( 4. Consensus - some opponents in prison or Hudson, a few to buy. What to do? Yes, of course, we urgently need literacy, capacity buiding, awareness raising, engagement, and in this case the role of ICANN is nearly zero. I extremely thankful to Olivier, Sebastien, Wolf, Bertrand, Sandra, Wolfgang, Yulia (I hope I did not miss anybody) for coming to Ukraine and participating in our events. They realy did great job, and influence a lot on many discussions! But on institutional level ICANN did not ever participate in them! With OFFICIAL meetings with Ukrainian officials, with discussions of the most critical issues, with organizing some educational programs! That is why a lot of in Ukraine really don't know what is ICANN, and a lot of prefer to make show that they don't know. I talk about Ukraine, but I mention all post-Soviet Russian-speaking culture. That is why during teleconference call with Ambassador Kramer I proposed to organize in Ukraine sub-regional Forum and to initiate standing discussion on multistakeholderism and freedom of Internet. I can not imagine it without pro-active role of ICANN. I am sorry for such long letter, but I would like to add some words about trust. I do not trust to my government, so there is no dissapointment with their activity in Dubai. But now how I can trust to Dr. Toure and to Chair of the conference, if they can't keep their words (about consensus instead of voting)? How can I trust to ITU at all, which fully demonstrates its absurdism? How can I trust to UN at all, if by mouth it defends human rights and democracy, but by hands it puts me behind the bars of criminal regime and close before me the door to open and prosperious informational society? Once again sorry for bothering you with our problems, Best regards, Oksana 2012/12/16 Peter H. Hellmonds <peter.hellmonds(a)hellmonds.eu>: > Thank you, Olivier, for sharing your very passionate and personal, yet balanced experience and viewpoint on the happenings and the mood on the ground in Dubai. > > Peter H. Hellmonds > <peter.hellmonds(a)hellmonds.eu> > +49 (160) 360-2852 > > On 15.12.2012, at 22:55, "Olivier MJ Crepin-Leblond" <ocl(a)gih.com> wrote: > > Dear all, > > I've been asked by several people to post my reply to Milton's blog post > here, to widen the discussion. Please find below. > > --- snip --- snip --- snip --- > > Dear Milton, > many of us on the ground were really sorry not to see you in the room in > Dubai. Perhaps then would you have actually understood the situation and > tension that was present in the room. > Without wanting to go into details, several parts of the ITRs were > deeply flawed. > 5A needs to be read along with ITU Standard Y.2770 which makes it > mandatory to implement deep packet inspection (and not even a mild case > of DPI) to all “next generation networks” which could be easily > interpreted as the IPv6 network. As a standard it is far from mandatory. > But 5A and 5B bring this much closer to make it mandatory – and you’ll > notice that the language in Y.2770 is very close to the language of 5A > and 5B. > 5B is an absolute NO-NO when the beginning of the document says that the > ITRs are not about content. In fact, in it is unclear whether later > recommendations take precedence over earlier recommendations in a > document as is the case in some legislatures. Indeed, you should have > seen the opposition from some countries to having the “no content” > clause included – which completely killed any remains of trust between > the two “sides”. > Then you have the Resolution at the end which is a real provocation for > some and not enough for others who would have wanted the Internet to be > included in the ITRs, including taking over numbering and addressing by > States. > The EU came very close to signing although many countries had serious > reservations about ITRs which simply did NOT make any sense. How can > Spam not be content? The Spam debate was fuelled by claims that it > flooded some country networks yet email traffic is less that 5% of > Internet traffic, less that 3% of all telecom traffic (estimated) and > therefore with Spam being at, say 50% of email traffic, countries were > arguing for a Regulation to filter traffic and perform DPI on maximum 2% > traffic gain? It simply did not make sense. > So the strategy of the EU countries, after having made a lot of > concessions, was to wait and see the final proposal from the Chair, > which although it had all of these inadequate articles, was a real > improvement. > But for some governments this was not enough! They insisted on the right > of States to telecommunication services and put it on a par basis with > Human Rights. They argued the Rights of States was the same as the > Rights of individuals. One of the most balanced Countries, Switzerland, > expressed its outrage. Tension was rising fast. We got lectured by some > countries that oppress their people about Human Rights. And then Iran > called for an abrupt end to the discussion, after having intervened more > than any country in the past 2 weeks, and called for a vote — when I > remind you that on many many occasions Dr. Touré and the Chair has > assured us there would be no vote. > This derailment was self-inflicted and this was the drop that got the > vase to overflow. Where the heck was the consensus? What kind of shotgun > tactics are those? It was obvious by the numbers that the countries > opposing the aggressive manner in which this was conducted, would lose a > vote. > For me, sitting in this room, this was Game, Set and Match. My country, > the UK, did not sign and I am ever so glad they did not. Yes, I had a > say in the matter since I was a full UK delegate, one of the many > countries which brought multiple stakeholders at the table and guess > what, most of these countries have not signed. Does this not tell you > something? > > So that is my personal assessment of what happened and I was at the > heart of it. I saw some very ugly stuff going on there, stuff which I > would really like the Internet to be preserved from. > > But I am sad too. I am sad because I also heard some very valid concerns > from developing countries that they were not able to participate in the > multi-stakeholder model because of lack of funding, lack of > understanding and a lack of proactive work from our “own” side. > I am planning to report fully to ICANN on the matter – we should do more > to bridge the gap. At the moment, these countries only have two fora in > which they can participate and that’s the IGF where nobody listens to > them and the ITU where they have a voice. During the hour that followed > the dramatic vote, I went to see my “opponents”. Many of us did – and > whilst not apologizing for not signing, we exchanged business cards and > I intend on following up. In fact, many European countries are intent on > following up with countries that do not appear to have hidden intentions > are are genuine about the level of despair they displayed at this > conference. Because sadly, there was despair too. This is the start of a > better dialogue, one which we must make efforts in promoting, reaching > out, building capacity. > > In closing, I’d say that this was not only a failure of the ITRs and the > ITU, it was a failure of Internet Governance too. Civil Society has the > ability to bridge the gap – and I know of several governments that have > understood this. Let’s work together to ensure we will never live again > a similar WCIT full of mistrust and despair. > > Olivier > (speaking entirely on my own behalf) > > > -- > Olivier MJ Crépin-Leblond, PhD > http://www.gih.com/ocl.html > > > ____________________________________________________________ > You received this message as a subscriber on the list: > governance(a)lists.igcaucus.org > To be removed from the list, visit: > http://www.igcaucus.org/unsubscribing > > For all other list information and functions, see: > http://lists.igcaucus.org/info/governance > To edit your profile and to find the IGC's charter, see: > http://www.igcaucus.org/ > > Translate this email: http://translate.google.com/translate_t > > ____________________________________________________________ > You received this message as a subscriber on the list: > governance(a)lists.igcaucus.org > To be removed from the list, visit: > http://www.igcaucus.org/unsubscribing > > For all other list information and functions, see: > http://lists.igcaucus.org/info/governance > To edit your profile and to find the IGC's charter, see: > http://www.igcaucus.org/ > > Translate this email: http://translate.google.com/translate_t >

1 0

ICANN Board agenda for Thursday 20 December 2012
by Alan Greenberg Dec. 14, 2012

Dec. 14, 2012

From: http://www.icann.org/en/groups/board/documents/agenda-20dec12-en.htm 1. Consent Agenda a. Minutes: 13 October 2012 Regular Meeting of the ICANN Board 18 October 2012 Regular Meeting of the ICANN Board 18 October 2012 Organizational Meeting of the ICANN Board 8 November 2012 Special Meeting of the ICANN Board b. SSAC Thank You to Departing Member c. SSAC Member Reappointments d. GNSO Council Recommendations IRTP Part C e. Root Server System Advisory Committee (RSSAC) Bylaws Revisions for Public Comment f. Review of the ICANN Nominating Committee (NomCom) g. ICANN New gTLD Funds Investment Policy h. Location of November 2013 ICANN Meeting 48 2. Main Agenda a. Board Term Alignment b. Accountability Structures Expert Panel Recommendation c. Location of ICANN Meetings in 2014 and the Establishment of a Multi-stakeholder Meeting Strategy Working Group d. Any Other Business

2 1

Fwd: Input requested for PDP on the Protection of IGO and INGO Identifiers in all gTLDs (IGO-INGO)
by Olivier MJ Crepin-Leblond Dec. 9, 2012

Dec. 9, 2012

Dear ALAC, please be so kind to find enclosed a message from the Chair of the IGO/INGO WG. May I suggest that if there is enough momentum, the ALAC submits a consolidated statement answering the questions asked even though this is not a formal public comment process? Kind regards, Olivier MJ Crépin-Leblond ALAC Chair -------- Original Message -------- Subject: Input requested for PDP on the Protection of IGO and INGO Identifiers in all gTLDs (IGO-INGO) Date: Fri, 7 Dec 2012 12:20:27 -0800 From: Glen de Saint Géry <Glen(a)icann.org> To: Olivier MJ Crepin-Leblond (ocl(a)gih.com) <ocl(a)gih.com>, Evan Leibovitch (evan(a)telly.org) <evan(a)telly.org> CC: Heidi Ullrich <Heidi.Ullrich(a)icann.org>, "gnso-secs(a)icann.org" <gnso-secs(a)icann.org>, Berry Cobb Mail <mail(a)berrycobb.com>, Brian Peck <brian.peck(a)icann.org> Dear SO/AC Chair, As you may be aware, the GNSO Council recently initiated a Policy Development Process (PDP) on the Protection of IGO and INGO Identifiers in all gTLDs (IGO-INGO). The GNSO Council is looking to expedite this PDP to accommodate requests from the ICANN Board and GAC. As part of its efforts to obtain input from the broader ICANN Community, at an early stage of its deliberations, the IGO-INGO Protections Working Group tasked with addressing this issue is looking for any input or information that may help inform its deliberations. You are strongly encouraged to provide any input your respective communities may have by providing it to the GNSO Secretariat (gnso.secretariat(a)gnso.icann.org <mailto:gnso.secretariat@gnso.icann.org>) by *_15 January 2013_*. For further background information on the WG's activities to date, please see: * IGO-INGO Web Page(see http://gnso.icann.org/en/group-activities/protection-igo-names.htm) * Final Issue Report for insight into the current practices and issues experienced (see http://gnso.icann.org/en/issues/protection-igo-names-final-issue-report-01o…) * The IOC/RCRC DT page is also a good reference for how those efforts were combined with this PDP (see http://gnso.icann.org/en/group-activities/red-cross-ioc.htm) *Below are elements of the approved charter that the WG has been tasked to address:* As part of its deliberations on the first issue as to whether there is a need for special protections for IGO and INGO organizations at the top and second level in all gTLDs (existing and new), the PDP WG should, at a minimum, consider the following elements as detailed in the Final Issue Report: * Quantifying the Entities whose names may be Considered for Special Protection * Evaluating the Scope of Existing Protections under International Treaties/Laws for the IGO-INGO organizations concerned; * Establishing Qualification Criteria for Special Protection of names of the IGO and INGO organizations concerned; * Distinguishing any Substantive Differences between the RCRC and IOC designations from those of other IGO-INGO Organizations. Should the PDP WG reach consensus on a recommendation that there is a need for special protections at the top and second levels in all existing and new gTLDs for IGO and INGO organization identifiers; the PDP WG is expected to: * Develop specific recommendations for appropriate special protections, if any, for the identifiers of any or all IGO and INGO organizations at the first and second levels. * Determine the appropriate protections, if any, for RCRC and IOC names at the second level for the initial round of new gTLDs and make recommendations on the implementation of such protection. * Determine whether the current special protections being provided to RCRC and IOC names at the top and second level of the initial round of new gTLDs should be made permanent for RCRC and IOC names in all gTLDs; if so, determine whether the existing protections are sufficient and comprehensive; if not, develop specific recommendations for appropriate special protections (if any) for these identifiers. *Questions to Consider:* * * 1. What kinds of entities should be considered for Special Protections at the top and second level in all gTLDs (existing and new)? 2. What facts or law are you aware of which might form an objective basis for Special Protections under International Treaties/Domestic Laws for IGOs, INGOs as they may relate to gTLDs and the DNS? 3. Do you have opinions about what criteria should be used for Special Protection of the IGO and INGO identifiers? 4. Do you think there are substantive differences between the RCRC/IOC and IGOs and INGOs? 5. Should appropriate Special Protections at the top and second level for the identifiers of IGOs and INGOs be made? 6. In addition, should Special Protections for the identifiers of IGOs and INGOs at the second level be in place for the initial round of new gTLDs? 7. Should the current Special Protections provided to the RCRC and IOC names at the top and second level of the initial round for new gTLDs be made permanent in all gTLDs and if not, what specific recommendations for appropriate Special Protections (if any) do you have? 8. Do you feel existing RPMs or proposed RPMs for the new gTLD program are adequate to offer protections to IGO and INGOs (understanding that UDRP and TMCH may not be eligible for all IGOs and INGOs)? If possible, the WG would greatly appreciate receiving your input by *_15 January 2013_* at the latest. Your input will be very much appreciated. With best regards, Thomas Rickert, Chair of the IGO-INGO WG Glen de Saint Géry GNSO Secretariat gnso.secretariat(a)gnso.icann.org <mailto:gnso.secretariat@gnso.icann.org> http://gnso.icann.org

2 1

UK IPv6 advocacy group gives up, disbands
by Evan Leibovitch Dec. 7, 2012

Dec. 7, 2012

http://www.6uk.org.uk/2012/12/6uk-powerless-to-encourage-ipv6-adoption-boar… -- Evan Leibovitch Toronto Canada Em: evan at telly dot org Sk: evanleibovitch Tw: el56

1 0