November 2013 - ALAC - lists.icann.org

Re: [ALAC] [technical-issues] Fwd: Invitation to an ICANN Advice kick-off workshop, Sunday, November 17 in Buenos Aires
by Olivier MJ Crepin-Leblond Nov. 13, 2013

Nov. 13, 2013

Dear Lutz, I wouldn't go as far as saying that ALAC is no longer necessary if the ALAC cannot fulfil its technical part of its mandate because that's what it actually is: a part of its mandate. There are many other parts too many of which are to do with capacity building and with policy development that might be non technical in nature. That said, we do have the ability to comment on *all* of ICANN's processes and some of ICANN's work is technical in nature. As a result, we need to have a strong "Technical Issues" WG and I ask you all if you would like to join the WG or if you know anyone who might be an asset to the WG. With the "retirement" of some members, I do feel that we do not have enough people who have a broad technical knowledge that can help us with our Statements and relaying of messages from the technical part of the At-Large community. Kind regards, Olivier On 13/11/2013 04:39, Lutz Donnerhacke wrote: > On Tue, Nov 12, 2013 at 09:06:12AM +0800, Rinalia Abdul Rahim wrote: >> 4. The ALAC, as a community of Internet Users, is not positioned to offer >> technical advice, but our community would certainly be affected by >> technical issues and we certainly are a consumer of technical advice. We >> therefore would want that advice to be available "on tap" as and when >> needed, in an easily understandable way, but also forthcoming proactively >> when there are issues of concern such as in the case of name and variant >> collisions. > I do not agree with this point. IMHO the problem is simply the inability of > AtLarge to give the technically skilled people (we have them!) the necessary > voice. > > Most of the active AtLarge community appears to be a small group of > omnipresent people dealing with organizational issues. The AtLarge structure > makes it hard for the typical technical ones to participate and bring their > expertise in. > > If we conclude that ALAC as the visible part of AtLarge is unable to fulfil > their technical obligations, ALAC is not longer necessary for an > organization which produces mainly technically driven results. > > Yes, I'm guilty. > -- Olivier MJ Crépin-Leblond, PhD http://www.gih.com/ocl.html

2 2

Re: [ALAC] [APAC-Discuss] [NA-Discuss] NOW OPEN: 2013 ALAC ALT and Liaison Nominations
by Salanieta T. Tamanikaiwaimaro Nov. 13, 2013

Nov. 13, 2013

Thanks Darlene. I think it is important to have many candidates to stand for any one position so that the ALAC has room to draw from as wide a range of persons as possible. This goes for all other positions as well. On Thu, Nov 14, 2013 at 4:37 AM, Darlene Thompson < thompson.darlene(a)gmail.com> wrote: > Hi all, > > I would like to put myself forward as the .MOBI liaison. > > Thank you, > > D > > > On Tue, Nov 12, 2013 at 6:03 PM, Alan Greenberg <alan.greenberg(a)mcgill.ca > >wrote: > > > According to the RoP, there are a total of five ALAC Leadership Team > (ALT) > > positions, one from each of the five regions, and Olivier from EURALO is > > already in the position of Chair. I also note that there is a minor issue > > in the call for nominations in that under the new RoP, we no longer have > a > > rapporteur and it should be vice-chairs instead of vice-presidents. > > > > I nominate the following for the ALT: > > > > Tijani Ben Jemaa (AFRALO) - Vice-chair > > Evan Leibovitch (NARALO) - Vice-chair > > Holly Raiche (APRALO) > > Dev Anand Teelucksingh (LACRALO) > > > > I of course support the nomination of Maureen Hilyard as ccNSO Liaison, > > and I nominate Julie Hammer as SSAC Liaison > > > > Last year I agreed to serve as GNSO Liaison with the understanding that > we > > would consciously get more people involved in GNSO activities. That has > not > > happened to any great extent. As such, if the ALAC desires, I am willing > to > > continue to serve in this capacity, but with the understanding that we > take > > posative action to get someone else into the role as quickly as possible. > > > > Alan > > > > > > At 11/11/2013 04:22 PM, ICANN At-Large Staff wrote: > > > >> Dear All, > >> > >> On behalf of Olivier Crépin-Leblond, Chair of the ALAC, the 2013 call > for > >> nomination of ALAC Leadership Team (ALT) members and ALAC Liaisons is > now > >> open. > >> > >> ALT: > >> > >> The available positions are for the following ALT Members: > >> > >> · Vice-President (2 positions) > >> > >> · Rapporteur (1 position) > >> > >> · Regional Representative (1 position) > >> > >> Proposed ALT Schedule: > >> > >> · Call for Nominees: 11 November - 18 November > >> > >> · Nominees acceptance period: 18 November - 20 November > >> > >> · ALAC votes by consensus: 21 November > >> > >> All terms run from the end of the 2013 AGM to the end of the 2014 AGM. > >> > >> Please see the 2013 ALAC Leadership Team and Liaison Selection > Workspace< > >> https://community.icann.org/display/atlarge/ > >> 2013+ALAC+Leadership+Team+and+Liaison+Selection+Workspace> for important > >> information on the ALT requirements and responsibility > >> > >> Nominations, including self-nominations may be made directly on the 2013 > >> ALAC Leadership Team and Liaison Selection Workspace<https://community. > >> icann.org/display/atlarge/2013+ALAC+Leadership+Team+and+ > >> Liaison+Selection+Workspace> or by sending a note to At-Large > >> staff<mailto:staff@atlarge.icann.org>. Only members of the ALAC after > >> the close of the 2013 AGM are eligible for these positions. Only sitting > >> ALAC Members are eligible and entitled to vote. > >> > >> Terms run from the end of the 2013 AGM to the end of the 2014 AGM. > >> > >> Please see the 2013 ALAC Leadership Team and Liaison Selection > Workspace< > >> https://community.icann.org/display/atlarge/ > >> 2013+ALAC+Leadership+Team+and+Liaison+Selection+Workspace> for important > >> information on the ALT requirements and responsibilities. > >> > >> Nominations, including self-nominations may be made directly on the 2013 > >> ALAC Leadership Team and Liaison Selection Workspace<https://community. > >> icann.org/display/atlarge/2013+ALAC+Leadership+Team+and+ > >> Liaison+Selection+Workspace> or by sending a note to At-Large > >> staff<mailto:staff@atlarge.icann.org>. > >> > >> Liaisons: > >> > >> The available positions are for the following liaisons: > >> * ALAC Liaison to the GNSO > >> * ALAC Liaison to the ccNSO > >> * ALAC Liaison to .MOBI > >> * ALAC Liaison to the SSAC > >> > >> Proposed Liaison Schedule: > >> Call for Nominees: 11 November - 18 November > >> ALAC votes by consensus: 21 November > >> > >> All terms run from the end of the 2013 AGM to the end of the 2014 AGM. > >> > >> Please see the 2013 ALAC Leadership Team and Liaison Selection > Workspace< > >> https://community.icann.org/display/atlarge/ > >> 2013+ALAC+Leadership+Team+and+Liaison+Selection+Workspace> for important > >> information on the ALAC Liaisons requirements and responsibilities. > >> > >> Nominations, including self-nominations may be made directly on the 2013 > >> ALAC Leadership Team and Liaison Selection Workspace<https://community. > >> icann.org/display/atlarge/2013+ALAC+Leadership+Team+and+ > >> Liaison+Selection+Workspace> or by sending a note to At-Large > >> staff<mailto:staff@atlarge.icann.org>. > >> > >> Regards, > >> > >> Heidi Ullrich, Silvia Vivanco, Matt Ashtiani, Gisella Gruber, Nathalie > >> Peregrine and Julia Charvolen ICANN Policy Staff in support of ALAC > >> E-mail: staff(a)atlarge.icann.org<mailto:staff@atlarge.icann.org<mailto: > >> staff@atlarge.icann.org%3cmailto:staff@atlarge.icann.org>> > >> > >> _______________________________________________ > >> lac-discuss-en mailing list > >> lac-discuss-en(a)atlarge-lists.icann.org > >> https://atlarge-lists.icann.org/mailman/listinfo/lac-discuss-en > >> > > > > ------ > > NA-Discuss mailing list > > NA-Discuss(a)atlarge-lists.icann.org > > https://atlarge-lists.icann.org/mailman/listinfo/na-discuss > > > > Visit the NARALO online at http://www.naralo.org > > ------ > > > _______________________________________________ > APAC-Discuss mailing list > APAC-Discuss(a)atlarge-lists.icann.org > https://atlarge-lists.icann.org/mailman/listinfo/apac-discuss > > Homepage for the region: http://www.apralo.org >

1 0

Fwd: Re: Follow-up on an enquiry during Durban Public Forum
by Olivier MJ Crepin-Leblond Nov. 13, 2013

Nov. 13, 2013

Dear all, please be so kind to find the answer below, to the question which Evan had asked at the public forum in Durban. The question was: "why is Section 9 of the RAA entitled 'Registrant Benefits and Responsibilities' ?" Kind regards, Olivier MJ Crépin-Leblond ALAC Chair -------- Original Message -------- Subject: Re: Follow-up on an enquiry during Durban Public Forum Date: Wed, 30 Oct 2013 12:46:34 -0700 From: Samantha Eisner <Samantha.Eisner(a)icann.org> To: Evan Leibovitch <evan(a)telly.org>, Olivier MJ Crepin-Leblond <ocl(a)gih.com> CC: Fadi Chehade <fadi.chehade(a)icann.org>, John Jeffrey <john.jeffrey(a)icann.org>, Cyrus Namazi <cyrus.namazi(a)icann.org>, ICANN At-Large Staff <staff(a)atlarge.icann.org>, Cassia Oliveira <cassia.oliveira(a)icann.org> Dear Olivier and Evan, In response to your query below, during the course of the 2013 RAA negotiations, it became clear that the negotiating teams and the community had different understandings of what purpose the document formerly referred to as "Registrant Rights and Responsibilities" was intended to serve. While the negotiating teams from ICANN and the Registrars agreed that this document would be a compilation only of obligations clearly found in the contract, the community input at public sessions on this topic, as well as in the public comment forum, suggested that the "Registrant Rights and Responsibilities" document should serve a broader scope, encompassing issues such as external legal rights relating to privacy and intellectual property. As explained in the summary of public comments on a proposed final version of the RAA, "For the Registrant Rights and Responsibilities document, there were two versions of a new document posted by commenters as alternatives to the version posted for comment. The current Registrant Rights and Responsibilities document, as posted with the agreement, was not mean to be a full statement of all registrant rights and responsibilities arising out of being a domain name registrant. Rather, it is specifically targeted to identify contractual rights and responsibilities that are stated within the RAA, as opposed to looking to consensus policy or to broader principles of privacy rights. While the suggestions raised in the versions presented during the comment period incorporate some ideas that could be of great value for the community to discuss, they are not geared to the limited purpose of the document. To help clarify the purpose of the document, ICANN will be considering clarifying the title of the document prior to finalizing the RAA." http://www.icann.org/en/news/public-comment/report-comments-proposed-raa-21 jun13-en.pdf. The term "benefits" was agreed upon by ICANN and the Registrars Negotiating Team to achieve two purposes - first, to clarify the purpose of the document so that it was not seen a broad, sweeping statement of registrant rights, as commenters clearly identified. Second, the use of the term "benefits" helps denote a balance between the listing of key contractual responsibilities to which registrants are bound, and the positive things that the registrants are provided under the agreement, such as access to information. There is no explicit legal meaning that we were trying to afford to the word "benefit", instead the focus was on removing the confusion inherent in the continued use of the term "rights" where not all applicable rights were enumerated. Best, Samantha -- Samantha Eisner Senior Counsel, ICANN 12025 Waterfront Drive, Suite 300 Los Angeles, California 90094 Direct Dial: +1 310 578 8631 samantha.eisner(a)icann.org On 9/25/13 6:33 PM, "Olivier MJ Crepin-Leblond" <ocl(a)gih.com> wrote: >ALAC Correspondence Ref: AL-ALAC-CO-0913-01-00-EN > >Dear Fadi, > >I am following up on a question which was asked as an individual by my >colleague Evan Leibovitch during the Public Forum in Durban: > >Quoting the transcript of the session, page 87: > >EVAN LEIBOVITCH: Thanks, Steve. I'm Evan Leibovitch, vice chair of the >ALAC speaking on my own behalf. But this is based on a number of >conversations with a number of people within the At-Large and elsewhere. >Without coordinating it at all with Phil, it relates to something he >said and it has to do with the relationship between benefits and rights. >Somewhere, somehow, section 9 of the RAA had some strange search and >replace happen where the words "rights" were taken out and >"responsibilities" put in. Not only that but it was done in a confusing >way. The document for section 9 heading says "benefits and >responsibilities" and the first section talks about rights. Since then >there have been many talks this week about rights and responsibilities. >The "B" word hasn't been used anywhere, but there it is in the RAA. Can >someone explain how it crept in, why it's there, and what is meant by >the distinction between rights and benefits? I think to a lot of people, >there's a very real distinction in the word. I'd like to know how it >crept into the RAA. > >STEVE CROCKER: Management response here? > >FADI CHEHADE: We'll look into that. That's all I can say. I'm trying to >find out some facts, but I appreciate your comment. I appreciate the >distinction between the two. That's all I can say. > >--- end of transcript --- > >The ALAC has discussed this point during its August and its September >monthly calls and on its mailing lists and this has proved to be a >particularly important point which needed clarification. I am therefore >writing to you to ask for this clarification. > >It is understood that the RAA is a legal contractual document, several >copies of which were signed in Durban. The page in question is Section >9, entitled "Registrants' Benefits and Responsibilities", page 68. > >Until the title of this section appeared, the notion of "Registrant >Rights and Responsibilities" was the notion that prevailed, certainly in >the At-Large world. As Evan Leibovitch mentions in his comment during >the public meeting, there is much difference between a Registrants' >Rights and a Registrants' Benefits. > >But the confusion is then exacerbated by the fact that the next line on >that same RAA page is a sub-heading of "Domain Name Registrants' Rights" >and the list printed on that page very clearly reads as a list of >Registrant Rights. RAA signatories are therefore clearly signing on a >list of Registrants' Rights. > >Furthermore, Section 3.16 of the same RAA document points to "an >educational webpage summarizing the terms of the Registrar Accreditation >Agreement and related Consensus Policies (as of the date of this >Agreement, located at: >http://www.icann.org/en/registrars/registrant-rights-responsibilities-en.h >tm)." > >On the other hand, Section 3.7.10 mentions "Registrants' Benefits and >Responsibilities" as: "Registrar shall publish on its website(s) and/or >provide a link to the Registrants¹ Benefits and Responsibilities >Specification attached hereto and shall not take any action inconsistent >with the corresponding provisions of this Agreement or applicable law." > >and: > >"3.12.7 Its Resellers shall publish on their website(s) and/or provide a >link to the Registrants¹ Benefits and Responsibilities Specification >attached hereto and shall not take any action inconsistent with the >corresponding provisions of this Agreement or applicable law." > >So what we have is references to both Rights and Benefits, and I, like >my colleague Evan Leibovitch, would like to point out that these are >entirely different words meaning entirely different things -- and I note >that from your response in the ICANN Public Forum, you appreciate the >distinction between the two. > >Would you then please kindly provide clarification as to how the title >of that section is called "Registrants' Benefits and Responsibilities" >when there are clearly no "Benefits" but indeed there are "Rights" listed? > >Warmest regards, > >Olivier MJ Crépin-Leblond >ALAC Chair

2 1

Board seat electorate
by Alan Greenberg Nov. 13, 2013

Nov. 13, 2013

It appears that we have an issue that was not thought about when the new ALAC RoP were contemplated. Specifically, we have a person who will be both a RALO Chair and an ALAC member (for APRALO), thus holding two votes in the Board member election. From my point of view, this is not a great situation. We can either leave things as they are, or approve an additional rule allowing the Chair vote to be cast by someone else. That is similar to rules we already have for potential voters who cannot vote due a conflict. Since the RoP are silent on this issue, the under RoP 10.1.3, the ALAC is empowered to approve an additional rule without formally modifying the RoP. I would suggest the following. The second sentence also covers another case we forgot, specifically if an ALAC member is sick or otherwise unavailable to participate. >If A RALO Chair is not currently filled, or unavailable to >participate as an elector, or should the RALO Chair also hold a vote >as an ALAC member, the RALO for his/her region will name a >replacement for the purposes of the vote. This replacement must be >approved by vote of the RALO according to its rules. If an ALAC >member is unavailable to participate as an elector, the RALO for >his/her region will name a replacement for the purposes of the vote. >This replacement must be approved by vote of the RALO according to its rules. If we want to make such a change, it should really be done in BA. Alan

9 8

Re: [ALAC] Board seat electorate
by tijani.benjemaa＠topnet.tn Nov. 13, 2013

Nov. 13, 2013

Good morning, I do support the modification proposed by Alan. In the meantime, and since we will change the RoP, I propose to add a restriction for the number of candidates added by RALOs on the slate: Each RALO can not support more than 1 candidate to be added on the slate. The reason of such modification is to avoid to have 5 additionnal candidates who failed the evaluation process, and who are proposed to be added. Tijani On mer 13/11/13 4:55 , Olivier MJ Crepin-Leblond <ocl(a)gih.com> wrote: > Dear Alan, > > thank you for proposing a potential solution. Everyone - please be so > kind to indicate support or make alternative proposals. > Many thanks, > > Olivier > > On 12/11/2013 19:49, Alan Greenberg wrote: > > It appears that we have an issue that was not thought about when the > > new ALAC RoP were contemplated. Specifically, we have a person who > > will be both a RALO Chair and an ALAC member (for APRALO), thus > > holding two votes in the Board member election. From my point of view, > > this is not a great situation. > > > > We can either leave things as they are, or approve an additional rule > > allowing the Chair vote to be cast by someone else. That is similar to > > rules we already have for potential voters who cannot vote due a > > conflict. Since the RoP are silent on this issue, the under RoP > > 10.1.3, the ALAC is empowered to approve an additional rule without > > formally modifying the RoP. I would suggest the following. The second > > sentence also covers another case we forgot, specifically if an ALAC > > member is sick or otherwise unavailable to participate. > > > >> If A RALO Chair is not currently filled, or unavailable to > >> participate as an elector, or should the RALO Chair also hold a vote > >> as an ALAC member, the RALO for his/her region will name a > >> replacement for the purposes of the vote. This replacement must be > >> approved by vote of the RALO according to its rules. If an ALAC > >> member is unavailable to participate as an elector, the RALO for > >> his/her region will name a replacement for the purposes of the vote. > >> This replacement must be approved by vote of the RALO according to > >> its rules. > > > > If we want to make such a change, it should really be done in BA. > > > > Alan > > > > _______________________________________________ > > ALAC mailing list > > ALAC(a)atlarge-lists.icann.org > > https://atlarge-lists.icann.org/mailman/listinfo/alac [1] > > > > At-Large Online: http://www.atlarge.icann.org [2] > > ALAC Working Wiki: > > > https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(AL > AC[3]) > > > > -- > Olivier MJ Crépin-Leblond, PhD > http://www.gih.com/ocl.html [4] > > _______________________________________________ > ALAC mailing list > ALAC(a)atlarge-lists.icann.org > https://atlarge-lists.icann.org/mailman/listinfo/alac [5] > > At-Large Online: http://www.atlarge.icann.org [6] > ALAC Working Wiki: > https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(AL > AC[7]) > > > > Links: > ------ > [1] > http://webmail.topnet.tn/parse.php?redirect=https://atlarge-lists.icann.org > /mailman/listinfo/alac[2] > http://webmail.topnet.tn/parse.php?redirect=http://www.atlarge.icann.org > [3] > http://webmail.topnet.tn/parse.php?redirect=https://community.icann.org/dis > play/atlarge/At-Large%2BAdvisory%2BCommittee%2B%28ALAC[4] > http://webmail.topnet.tn/parse.php?redirect=http://www.gih.com/ocl.html > [5] > http://webmail.topnet.tn/parse.php?redirect=https://atlarge-lists.icann.org > /mailman/listinfo/alac[6] > http://webmail.topnet.tn/parse.php?redirect=http://www.atlarge.icann.org > [7] > http://webmail.topnet.tn/parse.php?redirect=https://community.icann.org/dis > play/atlarge/At-Large%2BAdvisory%2BCommittee%2B%28ALAC >

3 2

RE : Re: Board seat electorate
by jjs Nov. 13, 2013

Nov. 13, 2013

I support this list. JJ. -------- Message d'origine -------- De : Olivier MJ Crepin-Leblond <ocl(a)gih.com> Date : 13/11/2013 5:55 (GMT+02:00) A : alac(a)atlarge-lists.icann.org Objet : Re: [ALAC] Board seat electorate Dear Alan, thank you for proposing a potential solution. Everyone - please be so kind to indicate support or make alternative proposals. Many thanks, Olivier On 12/11/2013 19:49, Alan Greenberg wrote: > It appears that we have an issue that was not thought about when the > new ALAC RoP were contemplated. Specifically, we have a person who > will be both a RALO Chair and an ALAC member (for APRALO), thus > holding two votes in the Board member election. From my point of view, > this is not a great situation. > > We can either leave things as they are, or approve an additional rule > allowing the Chair vote to be cast by someone else. That is similar to > rules we already have for potential voters who cannot vote due a > conflict. Since the RoP are silent on this issue, the under RoP > 10.1.3, the ALAC is empowered to approve an additional rule without > formally modifying the RoP. I would suggest the following. The second > sentence also covers another case we forgot, specifically if an ALAC > member is sick or otherwise unavailable to participate. > >> If A RALO Chair is not currently filled, or unavailable to >> participate as an elector, or should the RALO Chair also hold a vote >> as an ALAC member, the RALO for his/her region will name a >> replacement for the purposes of the vote. This replacement must be >> approved by vote of the RALO according to its rules. If an ALAC >> member is unavailable to participate as an elector, the RALO for >> his/her region will name a replacement for the purposes of the vote. >> This replacement must be approved by vote of the RALO according to >> its rules. > > If we want to make such a change, it should really be done in BA. > > Alan > > _______________________________________________ > ALAC mailing list > ALAC(a)atlarge-lists.icann.org > https://atlarge-lists.icann.org/mailman/listinfo/alac > > At-Large Online: http://www.atlarge.icann.org > ALAC Working Wiki: > https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(AL… > -- Olivier MJ Crépin-Leblond, PhD http://www.gih.com/ocl.html _______________________________________________ ALAC mailing list ALAC(a)atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/alac At-Large Online: http://www.atlarge.icann.org ALAC Working Wiki: https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(AL…

1 0

Fwd: NOW OPEN: 2013 ALAC ALT and Liaison Nominations
by Alan Greenberg Nov. 12, 2013

Nov. 12, 2013

I note that this call for nominations inadvertently did not go to the ALAC list. Alan >From: ICANN At-Large Staff <staff(a)atlarge.icann.org> >To: <alac-announce(a)atlarge-lists.icann.org>, ><afri-discuss(a)atlarge-lists.icann.org>, ><apac-discuss(a)atlarge-lists.icann.org>, ><euro-discuss(a)atlarge-lists.icann.org>, ><lac-discuss-en(a)atlarge-lists.icann.org>, <na-discuss(a)atlarge-lists.icann.org> >Date: Mon, 11 Nov 2013 13:22:40 -0800 >CC: ICANN At-Large Staff <staff(a)atlarge.icann.org> >Subject: [lac-discuss-en] NOW OPEN: 2013 ALAC ALT and Liaison Nominations > >Dear All, > >On behalf of Olivier Crépin-Leblond, Chair of >the ALAC, the 2013 call for nomination of ALAC >Leadership Team (ALT) members and ALAC Liaisons is now open. > >ALT: > >The available positions are for the following ALT Members: > >· Vice-President (2 positions) > >· Rapporteur (1 position) > >· Regional Representative (1 position) > >Proposed ALT Schedule: > >· Call for Nominees: 11 November - 18 November > >· Nominees acceptance period: 18 November - 20 November > >· ALAC votes by consensus: 21 November > >All terms run from the end of the 2013 AGM to the end of the 2014 AGM. > >Please see the 2013 ALAC Leadership Team and >Liaison Selection >Workspace<https://community.icann.org/display/atlarge/2013+ALAC+Leadership+Team+and+L…> >for important information on the ALT requirements and responsibility > >Nominations, including self-nominations may be >made directly on the 2013 ALAC Leadership Team >and Liaison Selection >Workspace<https://community.icann.org/display/atlarge/2013+ALAC+Leadership+Team+and+L…> >or by sending a note to At-Large >staff<mailto:staff@atlarge.icann.org>. Only >members of the ALAC after the close of the 2013 >AGM are eligible for these positions. Only >sitting ALAC Members are eligible and entitled to vote. > >Terms run from the end of the 2013 AGM to the end of the 2014 AGM. > >Please see the 2013 ALAC Leadership Team and >Liaison Selection >Workspace<https://community.icann.org/display/atlarge/2013+ALAC+Leadership+Team+and+L…> >for important information on the ALT requirements and responsibilities. > >Nominations, including self-nominations may be >made directly on the 2013 ALAC Leadership Team >and Liaison Selection >Workspace<https://community.icann.org/display/atlarge/2013+ALAC+Leadership+Team+and+L…> >or by sending a note to At-Large staff<mailto:staff@atlarge.icann.org>. > >Liaisons: > >The available positions are for the following liaisons: >* ALAC Liaison to the GNSO >* ALAC Liaison to the ccNSO >* ALAC Liaison to .MOBI >* ALAC Liaison to the SSAC > >Proposed Liaison Schedule: >Call for Nominees: 11 November - 18 November >ALAC votes by consensus: 21 November > >All terms run from the end of the 2013 AGM to the end of the 2014 AGM. > >Please see the 2013 ALAC Leadership Team and >Liaison Selection >Workspace<https://community.icann.org/display/atlarge/2013+ALAC+Leadership+Team+and+L…> >for important information on the ALAC Liaisons >requirements and responsibilities. > >Nominations, including self-nominations may be >made directly on the 2013 ALAC Leadership Team >and Liaison Selection >Workspace<https://community.icann.org/display/atlarge/2013+ALAC+Leadership+Team+and+L…> >or by sending a note to At-Large staff<mailto:staff@atlarge.icann.org>. > >Regards, > >Heidi Ullrich, Silvia Vivanco, Matt Ashtiani, >Gisella Gruber, Nathalie Peregrine and Julia >Charvolen ICANN Policy Staff in support of ALAC >E-mail: >staff(a)atlarge.icann.org<mailto:staff@atlarge.icann.org<mailto:staff@atlarge.icann.org%3cmailto:staff@atlarge.icann.org>> > >_______________________________________________ >lac-discuss-en mailing list >lac-discuss-en(a)atlarge-lists.icann.org >https://atlarge-lists.icann.org/mailman/listinfo/lac-discuss-en

1 0

Fwd: Invitation to an ICANN Advice kick-off workshop, Sunday, November 17 in Buenos Aires
by Olivier MJ Crepin-Leblond Nov. 12, 2013

Nov. 12, 2013

Dear All, Please be so kind to find a message from Steve Crocker, Chair of the ICANN Board, regarding a workshop to take place at the beginning of the ICANN meeting in Buenos Aires. I am aware that the ALAC is already meeting on Sunday morning. We may need to nominate someone to sit on that workshop on behalf of the ALAC. Kind regards, Olivier MJ Crépin-Leblond ALAC Chair -------- Original Message -------- Subject: Invitation to an ICANN Advice kick-off workshop, Sunday, November 17 in Buenos Aires Date: Sun, 10 Nov 2013 00:51:06 -0500 From: Steve Crocker <steve(a)shinkuro.com> CC: Steve Crocker <steve(a)shinkuro.com>, Karine Perset <karine.perset(a)icann.org> SO and AC chairs, TLG members, ISOC, senior ICANN staff, and ICANN Board, As many -- perhaps all -- of you have heard, we are revamping our process of asking for, receiving, acknowledging and processing technical advice. Toward that end, we are having an informal workshop session Sunday morning, Nov 17, from 10:30 to noon in the Martin Fierro room at the ICANN meeting in Buenos Aires to kick-off this revised advice process. You are invited to send technical people from each of your organizations. (Many of you have already been alerted to this meeting and have already made plans to come. This message is intended to share the same information with everyone.) Here's a bit of background. Our bylaws specify the existence of two technical Advisory Committees, RSSAC and SSAC, and the existence of a Technical Liaison Group (TLG), whose members, ETSI, ITU-T, W3C and IETF, each provide advice when asked. There is also considerable expertise within the other Advisory Committees and within the Supporting Organizations. Until now, our process for asking for and receiving technical advice has been a patchwork. For example, SSAC regularly sends the Board reports with advice. ALAC has begun doing the same. Three of the TLG members have shared one seat on the Board but have not otherwise provided specific advice. Our next step is to develop a regular dialog for technical advice, starting with the workshop on Nov 17. The workshop will focus on two primary questions: * What are the areas you think need technical advice? This applies to both those who need advice and those who have the expertise to give us advice. * Do you prefer to be asked for specific advice, prefer to offer advice on topics of your choice, or both? Please RSVP to Karine Perset, Director of Board Support, karine.perset(a)icann.org <mailto:karine.perset@icann.org>, and please come with suggestions for both specific technical issues and how to make the process work best from your point of view. Thanks! Steve Crocker Chair, ICANN Board of Directors

5 4

SAC062 and SAC063 Posted
by Julie Hammer Nov. 12, 2013

Nov. 12, 2013

Dear Colleagues, Please note that two new SSAC Reports: SAC062 SSAC Advisory Concerning the Mitigation of Name Collision Risk and SAC063 SSAC Advisory on DNSSEC Key Rollover in the Root Zone have been posted on the SSAC documents page at: http://www.icann.org/en/groups/ssac/documents. See the links at: SAC062 SSAC Advisory Concerning the Mitigation of Name Collision Risk http://www.icann.org/en/groups/ssac/documents/sac-062-en.pdf and SAC063 SSAC Advisory on DNSSEC Key Rollover in the Root Zone http://www.icann.org/en/groups/ssac/documents/sac-063-en.pdf. Cheers, Julie

2 1

New Procedure for the DNS Root Zone Affecting Linguistic Diversity at the Top Level
by Rinalia Abdul Rahim Nov. 11, 2013

Nov. 11, 2013

Dear Colleagues, At the recent Internet Governance Forum in Bali, a workshop was held to share information and discuss implications of a new procedure that will affect the DNS root zone and allow the delegation of IDN variants at the top level. Variants are considered important for many languages used by the global population. Attached is the full report and I paste below the summary of the issues discussed for your information. Best regards, Rinalia ----- Note: · The process of implementing the procedure is currently underway with the most immediate need being the establishment of Generation Panels for 17 scripts that have IDN TLDs requested under two TLD programs - the country code Top Level Domain (ccTLD) Fast Track program and the New generic Top Level Domain (gTLD) program. Prioritization of the 17 scripts does not exclude other script communities from moving forward to form Generation Panels. The 17 scripts that have IDN TLDs requested are: Arabic, Bengali, Chinese, Cyrillic, Devanagari, Georgian, Greek, Gujerati and Gurmukhi, Hebrew, Japanese, Korean, Latin, Sinhala, Tamil, Telugu and Thai. A significant proportion of the scripts are Asian language scripts. *Main Issues Raised * *Spillover benefits of the Root Zone Label Generation Rules (LGR) development * · The development of the Root Zone LGR, though focused on the top level of the Root system, has applicability at the second and third levels in terms of guidance for dealing with variants. · The ICANN rights protection mechanism for trademark owners in the new gTLD program is currently not addressing variants in an integrated way due to the legacy mentality of only thinking in terms of Latin script and ASCII for solutions. · The Root Zone LGR is expected to guide ICANN’s implementation of key TLD initiatives involving variants in the future. *The complexity of variant management * · Variants are complex and what is defined as variants tends to differ from language to language. · Visual similarity is a major concern that is shared across languages and scripts. Complex scripts with characters that change shapes depending on adjoining characters require a rendering engine at the Operating System and browser level for accurate visual representation. · Challenges in grappling with variants include achieving consistency across and within TLDs, dealing with the innumerability of variants, having the right tools to deal with the technical challenges of managing IDNs and ensuring that IDNs are usable in applications used by users. · Variant management at the Registry level requires deciding whether variants should resolve or point to the same IP address. There is no one size fits all solution. The decision is dependent on three variables: locale, registry and user community. Variations may be needed across registries to achieve consistency of variants. · Language communities have recommended to ICANN that variants should be allocated to the same TLD applicants and not to different applicants to avoid confusion and ensure consistency of user experience. *The challenge of universal acceptance of IDNs* · With the implementation of the Root Zone LGR procedure, the most important concern for the user community is the universal acceptance of IDNs and IDN variants. Software intended for end users such as web browsers, email clients and operating system needs to support IDN and IDN variants to ensure a positive user experience. · The introduction of IDN TLD and IDN Variant TLD to Internet users will realistically not be smooth and is likely to encounter some barriers and difficulties. Historically it has been extremely challenging to ensure universal acceptance - some of the labels introduced with the new TLD expansion in 2001 still do not work consistently everywhere. There are various points of potential failures in enabling universal acceptance. The problem lies not with the DNS, but with applications. · ICANN has highlighted the issues of universal acceptance in its Report on “Examining the User Experience Implications of Active Variant TLDs” ( http://www.icann.org/en/resources/idn/variant-tlds/active-ux-21mar13-en.pdf ). The Joint ccNSO-GNSO Internationalized Domain Names Working Group (JIG) at ICANN believes that industry-wide collaboration involving the technical and user communities is essential to address the problem of universal acceptance effectively. · Concrete policy recommendations to address the problem of universal acceptance include: (1) Discourage systems that do not accommodate IDN and IDN Variants; (2) Develop ways of identifying what is a legitimate IDN TLD label; (3) Encourage IDN TLD Operators and Accredited Registrars to ensure that they support universal acceptance of IDN TLDs in their own systems; (4) Advocate for universal acceptance, raise awareness and provide reference/learning materials. *Language community engagement and mobilization issues* · The Root Zone LGR procedure puts in place an open process that is welcoming and embracing of all languages that have been encoded in Unicode. Engagement in the process requires that language communities be aware of the initiative, be interested to engage and be ready to mobilize their respective communities to fulfill the requirements for forming Generation Panels. · The Arabic, Brahmi/Devanagari and Han script communities are already mobilizing to form Generation Panels. They comprise large language communities that are prepared for engagement because of their previous engagements with ICANN via case studies that led to the development of the Root Zone LGR procedure. Securing the involvement of smaller language communities that have not engaged with ICANN before is a challenge without dedicated or targeted outreach, which is essential to nurture interest and support readiness. · The disadvantage to late entrants or language communities that are not able to engage can potentially be addressed by the Integration Panel, which can produce Label Generation Rules for certain languages without waiting for proposals from Generation Panels, provided that the languages are in active use and are encoded in Unicode. · The Chinese language community experience in making the first proposal for IDN Variant management in 2000 offers the following principles to guide the implementation of the Root Zone LGR procedure: (1) Adopt an open language community concept (i.e., if you speak the language, you are part of the language community irrespective of territorial/country jurisdiction); (2) Adopt a bottom up and consensus-based decision-making and dispute resolution model for the language communities; (3) Ensure that permissible code points are those that are acceptable to the user community. *Importance of the ICANN Public Comments for the Root Zone LGR procedure* · The Root Zone LGR procedure specifies the ICANN Public Comments as the only governance oversight and appeals mechanism for the decisions of the Integration Panel. Generation Panels will essentially engage in a public negotiation process with the Integration Panel through the Public Comments process. The openness of the process allows for input from other stakeholders/interested parties for the Integration Panel’s consideration. · Via the Public Comments process, the Integration Panel is required to defend its decisions in an open and transparent way and in a sufficiently rigorous manner (i.e., provide defensible rationale for its decisions against high standards of scrutiny/challenge). Should the Integration Panel fail in this respect, ICANN is empowered to act to have the Panel replaced. · The Public Comments process still has certain weaknesses such as impediments to the effective participation/input of relevant stakeholders in a timely manner. The ICANN Accountability and Transparency Review Team 2 is currently addressing issues related to improvements of the Public Comments process. END

2 1