- ALAC - lists.icann.org

Re: [ALAC] Something we didn't think about.
by h.raiche＠internode.on.net Aug. 21, 2013

Aug. 21, 2013

I tend to agree with Evan and Hong (and JJS). Is this really an issue for us? Or is there a larger issue here that we can draw attention to, to make what are probably serious flaws in the whole gTLD provess at least a bit better? Maybe at least draw attention to the lack of consistency of decisions resulting from poor processes? I'm happy to be convinced there is a role for ALAC, I don't see a role so far. Holly On Wed 21/08/13 5:26 PM , JJS jjs.global(a)gmail.com sent: *Hong +1.* 2013/8/21 Hong Xue > The problem of inconsistency of the decisions lies largely in the case > procedural management, rather than the AGK or the rules. If all 3 > objections were filed roughly at the same time, there is no reason for the > IDRC to appoint 2 different panels. > > Hong > > > On Wed, Aug 21, 2013 at 12:38 PM, Evan Leibovitch wrote: > > > I'm not overly concerned about this from an end users perspective. > > > > This is a matter between warring parties within ICANN's commercial > sectors > > and IMO well beyond ALAC's sphere of concern. As soon as any application > > for the string was judged to be non-confusing, what little interest > > At-Large had in this matter vanished. > > > > From an end-users PoV on confusing strings, the domain name system is > > already well-poisoned. ICANN has already been seen to be silent when > > registrars deliberately use the confusion between .COM and .CO as a > selling > > point. (That CC names are beyond ICANN's ability to manage -- even when > > being used as generics -- is a subtlety lost on the public.) And If > nobody > > cares about the confusion between .COM and .CO, then it's hard to get > > suddenly concerned about confusion between .CAM and .COM (and also .CA or > > .CAT, for that matter) and even harder to want to get involved in the > > associated infighting. > > > > The only product that I have extracted from this event is entertainment. > I > > find the variety in rulings (two applications for a string non-confusing, > > but a third application for the exactly same string judged to be > confusing) > > to be highly amusing in its inconsistency. As Alan has said, the AGB > rules > > don't anticipate this, so a few more lawyers will be blessing ICANN's > > existence to pay for their Range Rovers. > > > > Certainly there are those who won't find this funny, But to someone like > me > > who believes the current gTLD expansion is a stupendous mistake, this > event > > is just Business as Usual. It's one more demonstration of the many > > unintended consequences that such a botched effort was sure to produce. > > Many have been revealed so far and there sill surely be more to come, > > including some that will be far more severe than this. And given its > scale, > > its complexity, and the sheer greed that motivated much of it, > anticipating > > all consequences of the expansion was simply impossible. > > > > IMO, one of ALAC's ongoing roles in this is to track and filter these > > consequences, focused on minimizing harm from those after-effects that > will > > affect end-users. This is not one of them, from what I can tell. > > > > - Evan > > > > > > > > On 20 August 2013 12:57, Alan Greenberg > wrote: > > > > > At 20/08/2013 11:53 AM, Olivier MJ Crepin-Leblond wrote: > > > > > > On 20/08/2013 17:20, Alan Greenberg wrote: > > >> > Hindsight says that we should have insisted that all string > similarity > > >> > objections be groups together, suing the sum-total of the arguments > > >> > for and against. But in our collective wisdom, we didn't. > > >> Substitute /we/ with /ICANN/ > > >> > > > > > > Not really, that was a real WE. Plenty of opportunities for all of us > to > > > have caught this earlier... > > > > > > > > > > > > Also, nice Freudian slip of suing -> using. > > >> > > > Oops > > > > > > > > > > > > > > > ______________________________**_________________ > > > ALAC mailing list > > > ALAC(a)atlarge-lists.icann.org > > > https://atlarge-lists.icann.**org/mailman/listinfo/alac > https://atlarge-lists.icann.org/mailman/listinfo/alac> [2]; > > > > > > At-Large Online: http://www.atlarge.icann.org [3] > > > ALAC Working Wiki: > > https://community.icann.org/**display/atlarge/At-Large [4]+ > > > **Advisory+Committee+(ALAC) > > https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(AL… [5]) > > > > > > > > > > > > > > -- > > Evan Leibovitch > > Toronto Canada > > > > Em: evan at telly dot org > > Sk: evanleibovitch > > Tw: el56 > > _______________________________________________ > > ALAC mailing list > > ALAC(a)atlarge-lists.icann.org > > https://atlarge-lists.icann.org/mailman/listinfo/alac [6] > > > > At-Large Online: http://www.atlarge.icann.org [7] > > ALAC Working Wiki: > > > https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(AL… [8]) > > > > > > -- > Professor Dr. Hong Xue > Director of Institute for the Internet Policy ">> Beijing Normal University > http://www.iipl.org.cn/ [9] > 19 Xin Jie Kou Wai Street > Beijing 100875 China > _______________________________________________ > ALAC mailing list > ALAC(a)atlarge-lists.icann.org > https://atlarge-lists.icann.org/mailman/listinfo/alac [10] > > At-Large Online: http://www.atlarge.icann.org [11] > ALAC Working Wiki: > https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(AL… [12]) > _______________________________________________ ALAC mailing list ALAC(a)atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/alac [13] At-Large Online: http://www.atlarge.icann.org [14] ALAC Working Wiki: https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(AL… [15]) Links: ------ [1] http://webmail-old.internode.on.net/parse.php?redirect=https%3A%2F%2Fatlarg… [2] http://webmail-old.internode.on.net/parse.php?redirect=https%3A%2F%2Fatlarg… [3] http://webmail-old.internode.on.net/parse.php?redirect=http%3A%2F%2Fwww.atl… [4] http://webmail-old.internode.on.net/parse.php?redirect=https%3A%2F%2Fcommun… [5] http://webmail-old.internode.on.net/parse.php?redirect=https%3A%2F%2Fcommun… [6] http://webmail-old.internode.on.net/parse.php?redirect=https%3A%2F%2Fatlarg… [7] http://webmail-old.internode.on.net/parse.php?redirect=http%3A%2F%2Fwww.atl… [8] http://webmail-old.internode.on.net/parse.php?redirect=https%3A%2F%2Fcommun… [9] http://webmail-old.internode.on.net/parse.php?redirect=http%3A%2F%2Fwww.iip… [10] http://webmail-old.internode.on.net/parse.php?redirect=https%3A%2F%2Fatlarg… [11] http://webmail-old.internode.on.net/parse.php?redirect=http%3A%2F%2Fwww.atl… [12] http://webmail-old.internode.on.net/parse.php?redirect=https%3A%2F%2Fcommun… [13] http://webmail-old.internode.on.net/parse.php?redirect=https%3A%2F%2Fatlarg… [14] http://webmail-old.internode.on.net/parse.php?redirect=http%3A%2F%2Fwww.atl… [15] http://webmail-old.internode.on.net/parse.php?redirect=https%3A%2F%2Fcommun…

1 0

Something we didn't think about.
by Alan Greenberg Aug. 20, 2013

Aug. 20, 2013

Verisign filed string-similarity objections against the three applications for .CAM. Two were decided last week (by the same panelist) against Verisign. The third, hear by a different panelist, decided for Verisign. A string similarity decision is supposed to be based on the strings themselves and not the usage, but the AG does not contemplate this occurrence. http://unitedtld.com/icann-must-now-decide-string-similarity-question/ Alan

2 1

Rights versus benefits
by Evan Leibovitch Aug. 14, 2013

Aug. 14, 2013

Hello all, One of the things that I noticed in the last Registrar Accreditation Agreement -- snuck in at the last moment, so I didn't notice it before it was presented at Durban -- was the replacement of the term "Registrant Rights and Responsibilities" with "Registrant Benefits and Responsibilities" in some but not all cases. Indeed, it looked like a very sloppy search-and-replace effort because the word "rights" was removed in some places but not others in what appears as random fashion. Given that the ALAC did not have an opportunity to discuss this during the Durban meeting, I raised it in an individual capacity during the Durban Public Forum (see page 97 of the Forum transcript<http://durban47.icann.org/meetings/durban2013/transcript-public-forum-18jul…> ). When asked, Fadi spent what seemed quite a long time (not reflected in the transcript) conferring silently with his staff (including legal staff), after which he promised to "look into it". I would like to ask Olivier and/or At-Large staff to please follow up on this. I think that the community is owed an explanation of how the term "registrant benefits and responsibilities" ever crept into ICANN lingo; I don't ever recall it ever being used in a policy context. Thank you, -- Evan Leibovitch Toronto Canada Em: evan at telly dot org Sk: evanleibovitch Tw: el56

3 2

Re: [ALAC] Rights versus benefits
by h.raiche＠internode.on.net Aug. 13, 2013

Aug. 13, 2013

Hi Evan (and everyone) Actually, that document was on my list of issues that still need addressing. We were not consulted about it, and I have not had a chance to go through to see in detail what is there - and what should be there. My impression is that all that was done was to take the obligations registrars have under the RAA and turn them into the one page document called Rights - or Benefits. In fact, since that is all the document is, it really is a light of what a registrant has a right to expect. Holly On Wed 14/08/13 5:07 AM , Evan Leibovitch evan(a)telly.org sent: Hello all, One of the things that I noticed in the last Registrar Accreditation Agreement -- snuck in at the last moment, so I didn't notice it before it was presented at Durban -- was the replacement of the term "Registrant Rights and Responsibilities" with "Registrant Benefits and Responsibilities" in some but not all cases. Indeed, it looked like a very sloppy search-and-replace effort because the word "rights" was removed in some places but not others in what appears as random fashion. Given that the ALAC did not have an opportunity to discuss this during the Durban meeting, I raised it in an individual capacity during the Durban Public Forum (see page 97 of the Forum transcript [1]; ). When asked, Fadi spent what seemed quite a long time (not reflected in the transcript) conferring silently with his staff (including legal staff), after which he promised to "look into it". I would like to ask Olivier and/or At-Large staff to please follow up on this. I think that the community is owed an explanation of how the term "registrant benefits and responsibilities" ever crept into ICANN lingo; I don't ever recall it ever being used in a policy context. Thank you, -- Evan Leibovitch Toronto Canada Em: evan at telly dot org Sk: evanleibovitch Tw: el56 _______________________________________________ ALAC mailing list ALAC(a)atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/alac [2] At-Large Online: http://www.atlarge.icann.org [3] ALAC Working Wiki: https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(AL… [4]) Links: ------ [1] http://webmail-old.internode.on.net/parse.php?redirect=http%3A%2F%2Fdurban4… [2] http://webmail-old.internode.on.net/parse.php?redirect=https%3A%2F%2Fatlarg… [3] http://webmail-old.internode.on.net/parse.php?redirect=http%3A%2F%2Fwww.atl… [4] http://webmail-old.internode.on.net/parse.php?redirect=https%3A%2F%2Fcommun…

1 0

Revised RPM Requirements include At-large Proposals to handle IDN variants issues
by Hong Xue Aug. 8, 2013

Aug. 8, 2013

Dear All, ICANN just published the Revised RPM Requirements. http://www.icann.org/en/news/public-comment/rpm-requirements-06aug13-en.htm It is impressive that ICANN finally responded to the at-large community's persistent requests on handling IDN variants involved in the RPMs, both for implementation of the Sunrise and Trademark Claims processes in new gTLDs, Many things were clarified and communicated efficiently through the direct dialogue between ICANN Board, SSAC and effected IDN user community, before and at Durban, under the leadership of ALAC. Although there is still room for improvement regarding these revisions, I believe the positive move deserves our support to make sure they could be finally adopted after the public comments. Please advise whether ALAC would wish to submit a comment, before August 27. Best, Hong -- Professor Dr. Hong Xue Director of Institute for the Internet Policy & Law (IIPL) Beijing Normal University http://www.iipl.org.cn/ 19 Xin Jie Kou Wai Street Beijing 100875 China

4 4

Open Call for Participation in the Task Force on Arabic Script IDNs
by Rinalia Abdul Rahim Aug. 6, 2013

Aug. 6, 2013

Dear Colleagues, Please find attached an Open Call for Participation in the Task Force on Arabic Script IDNs. The Task Force is an initiative of the Middle East Strategy Working Group (MESWG). Those interested are encouraged to apply especially if your community uses the Arabic script. Best regards, Rinalia *Extract from the attachment (please view the document for more information) * The Task Force will focus on technical issues and solutions related to Arabic script IDNs to promote Arabic IDNs definition, secure deployment and ease of use for the community. *Scope of Work * • Arabic Script Label Generation Ruleset (LGR) for the Root Zone • Second level LGRs for the Arabic script • Arabic script Internationalized Registration Data Protocol and Practice • Universal acceptability of Arabic script IDNs and variants • Technical challenges around registration of Arabic IDNs and variants • Operational software for Arabic script IDN registry and registrar operations • DNS security matters specifically related to Arabic IDNs and variants • Technical training material around Arabic script IDNs *Task Force Membership* The task force will consist of a diverse set of interested individuals from a diverse set of interests, e.g. Registries, Registrars, Community, Academia, DNS experts, IDNA experts, Unicode, Law enforcement, DNS security, Policy makers, etc. All the materials prepared through the task force will be openly available for use by the community. *Interested individuals are invited to join the task force on voluntary basis by emailing their CV and Statement of Interest (SOI) to tf-aidn-admin(a)meswg.org, which will be publicly archived for information purposes, and then signing up at http://lists.meswg.org/mailman/listinfo/tf-aidn.* *Initial Timelines* 5th August, 2013: Open Call for Task Force Members 20th August, 2013: MESWG to announce Task Force of Arabic Script IDNs (TF-AIDN) 1st Sept, 2013: Initiate Work Item(s) END

1 0

Urgent - ALAC Statements on Community Applications
by Rinalia Abdul Rahim Aug. 6, 2013

Aug. 6, 2013

Dear ALAC Colleagues, There are urgent emerging issues related to the new gTLD string contention that the EXCOMM believes warrant an ALAC intervention. With the support of Evan, I have taken the liberty of drafting an ALAC response for your immediate input. We need to submit the statements by the second week of August (latest) to have the possibility of an ICANN response before community priority evaluation begins. Please do try your best to provide comments for improvements or endorsements if you like the text/intent via the wiki page indicated by Thursday (8 August 2013). Policy Development wiki page links and statement text pasted below for your quick review. If the wiki link is not active, kindly copy and paste the URL for activation. Thank you! Best regards, Rinalia *1. ALAC Statement on Preferential Treatment for Community Applications in String Contention* WIKI page for your comments: https://community.icann.org/display/alacpolicydev/ALAC+STATEMENT+ON+PREFERE… *DRAFT ALAC STATEMENT ON PREFERENTIAL TREATMENT FOR COMMUNITY APPLICATIONS IN STRING CONTENTION* The ALAC notes that due to strict eligibility criteria, some of the new gTLD applications intended for communities and with wide public/grassroots support were not submitted as community applications. These applications are currently in contention with those that are fully commercial (i.e., driven purely by financial gain). We firmly believe that applications with demonstrable support, appropriate safeguards and emphasis on community service over revenue maximization should be accorded preferential treatment in the new gTLD string contention resolution process. We thus support the position of the Governmental Advisory Committee (GAC) as per the GAC Communiqué dated 18 July 2013 and call on ICANN to review all 688 applications currently in contention and provide preferential treatment to applications that meet the specification described above. END *2. ALAC Statement on Community Expertise in Community Priority Evaluation* WIKI page for your comments: https://community.icann.org/display/alacpolicydev/ALAC+STATEMENT+ON+COMMUNI… *DRAFT ALAC STATEMENT ON COMMUNITY EXPERTISE IN COMMUNITY PRIORITY EVALUATION* The ALAC has concerns about the sufficiency of community expertise in panels that evaluate new gTLD community applications in string contention processes. We believe that the evaluations have significant implications for community applications and require sufficient and relevant community-related expertise in panels that evaluate the applications. In providing this advice we draw from the learning provided by the failure of the new gTLD Applicant Support Program. *Community Priority Evaluation * Module 4 of the Applicant Guidebook specifies that the Community Priority Evaluation is applicable only for community-based applicants. The evaluation is an independent analysis (i.e., not dependent on prior applicant review results) and that any community application that passes the Evaluation will “eliminate all directly contending standard applications, regardless of how well qualified the latter may be.” Furthermore, community applications that fail the Evaluation will proceed into auction involving all contending parties where they may be at a disadvantage against fully commercial applications. As per the new gTLD Program Timeline indicated at http://newgtlds.icann.org/en/program-status/timelines, we note that the string contention resolution process will begin in September 2013. We also note that the Economist Intelligence Unit and InterConnect Communications have been appointed as service providers for the Community Priority Evaluation Panel (see new gTLD Program Update at the ICANN Dakar Meeting in 2011). We have concerns that these entities may have a natural familiarity and pre-disposition toward business that may discriminate against applications emphasizing community service over revenue-maximization. The ALAC thus calls for community-related expertise in the Community Priority Evaluation Panel and stands ready to offer appropriate and un-conflicted ICANN community volunteers to serve as panel members or advisors. END

3 3

Re: [ALAC] Urgent - ALAC Statements on Community Applications
by Rinalia Abdul Rahim Aug. 5, 2013

Aug. 5, 2013

Hi, Tijani. I agree that the criteria would be crucial for the first statement to avoid gaming. We can certainly flag the importance of having appropriate criteria in place. There are options in terms of how to handle or rank community-related applications. It will involve some value judgement on what is important or valued where communities are concerned and it won't please everyone. But let's go into that when ICANN demonstrates that it is ready and willing to give preferential treatment to applications related to communities. On the language of the second statement, Olivier usually vets all ALAC statements. I trust that his mastery of English will improve whatever it is that needs improving. Best regards, Rinalia On Aug 5, 2013 12:53 PM, "Tijani BENJEMAA" <tijani.benjemaa(a)topnet.tn> wrote: > Good morning Rinalia,**** > > ** ** > > For the first statement, I fully support it in principle. But as I said in > a previous discussion on this issue, I’m a little bit concerned about > gaming. It’s true that the AGB criteria for the community application are > very tight, but who will decide if the application that doesn’t fit the > community criteria has a community support??? Where you will put the limit? > **** > > During the elaboration of the JAS recommendations, some told me that > Verisign (for example) can bring the proof of community support for its > application, and yet, it is purely commercial.**** > > ** ** > > So, I support the concept assuming there are clear criteria for any > prioritized application on the basis of community support.**** > > ** ** > > You will tell me this statement doesn’t go to the details; I agree, but we > can add a word of reserve (pending definition of clear criteria).**** > > ** ** > > As for the second statement regarding the panels, I support it. I’m not an > English speaker, but I find that the language needs to be improved. **** > > ** ** > > ** ** > > > -------------------------------------------------------------------------------- > **** > > *Tijani BEN JEMAA* > > Executive Director**** > > Mediterranean Federation of Internet Associations (*FMAI*)**** > > Phone: + 216 41 649 605**** > > Mobile: + 216 98 330 114**** > > Fax: + 216 70 853 376**** > > > -------------------------------------------------------------------------------- > **** > > **** > > ** ** > > **** > > ** ** > > -----Message d'origine----- > De : alac-bounces(a)atlarge-lists.icann.org [mailto: > alac-bounces(a)atlarge-lists.icann.org] De la part de Rinalia Abdul Rahim > Envoyé : dimanche 4 août 2013 16:16 > À : ALAC Working List > Cc : ICANN At-Large Staff > Objet : [ALAC] Urgent - ALAC Statements on Community Applications > > ** ** > > Dear ALAC Colleagues,**** > > ** ** > > There are urgent emerging issues related to the new gTLD string contention > **** > > that the EXCOMM believes warrant an ALAC intervention. With the support of > **** > > Evan, I have taken the liberty of drafting an ALAC response for your**** > > immediate input. We need to submit the statements by the second week of** > ** > > August (latest) to have the possibility of an ICANN response before**** > > community priority evaluation begins. Please do try your best to provide* > *** > > comments for improvements or endorsements if you like the text/intent via* > *** > > the wiki page indicated by Thursday (8 August 2013).**** > > ** ** > > Policy Development wiki page links and statement text pasted below for your > **** > > quick review. If the wiki link is not active, kindly copy and paste the** > ** > > URL for activation.**** > > ** ** > > Thank you!**** > > ** ** > > Best regards,**** > > ** ** > > Rinalia**** > > ** ** > > *1. ALAC Statement on Preferential Treatment for Community Applications in > **** > > String Contention***** > > ** ** > > WIKI page for your comments:**** > > > https://community.icann.org/display/alacpolicydev/ALAC+STATEMENT+ON+PREFERE… > **** > > ** ** > > *DRAFT ALAC STATEMENT ON PREFERENTIAL TREATMENT FOR COMMUNITY APPLICATIONS > **** > > IN STRING CONTENTION***** > > ** ** > > The ALAC notes that due to strict eligibility criteria, some of the new*** > * > > gTLD applications intended for communities and with wide public/grassroots > **** > > support were not submitted as community applications. These applications* > *** > > are currently in contention with those that are fully commercial (i.e.,*** > * > > driven purely by financial gain).**** > > ** ** > > We firmly believe that applications with demonstrable support, appropriate > **** > > safeguards and emphasis on community service over revenue maximization**** > > should be accorded preferential treatment in the new gTLD string contention > **** > > resolution process. We thus support the position of the Governmental**** > > Advisory Committee (GAC) as per the GAC Communiqué dated 18 July 2013 and* > *** > > call on ICANN to review all 688 applications currently in contention and** > ** > > provide preferential treatment to applications that meet the specification > **** > > described above.**** > > ** ** > > END**** > > ** ** > > *2. ALAC Statement on Community Expertise in Community Priority Evaluation* > **** > > ** ** > > WIKI page for your comments:**** > > > https://community.icann.org/display/alacpolicydev/ALAC+STATEMENT+ON+COMMUNI… > **** > > ** ** > > *DRAFT ALAC STATEMENT ON COMMUNITY EXPERTISE IN COMMUNITY PRIORITY**** > > EVALUATION***** > > ** ** > > The ALAC has concerns about the sufficiency of community expertise in**** > > panels that evaluate new gTLD community applications in string contention* > *** > > processes.**** > > ** ** > > We believe that the evaluations have significant implications for community > **** > > applications and require sufficient and relevant community-related**** > > expertise in panels that evaluate the applications. In providing this**** > > advice we draw from the learning provided by the failure of the new gTLD** > ** > > Applicant Support Program.**** > > ** ** > > *Community Priority Evaluation ***** > > ** ** > > Module 4 of the Applicant Guidebook specifies that the Community Priority* > *** > > Evaluation is applicable only for community-based applicants. The**** > > evaluation is an independent analysis (i.e., not dependent on prior**** > > applicant review results) and that any community application that passes** > ** > > the Evaluation will “eliminate all directly contending standard**** > > applications, regardless of how well qualified the latter may be.”**** > > Furthermore, community applications that fail the Evaluation will proceed* > *** > > into auction involving all contending parties where they may be at a**** > > disadvantage against fully commercial applications.**** > > ** ** > > As per the new gTLD Program Timeline indicated at**** > > http://newgtlds.icann.org/en/program-status/timelines, we note that the*** > * > > string contention resolution process will begin in September 2013. We also > **** > > note that the Economist Intelligence Unit and InterConnect Communications* > *** > > have been appointed as service providers for the Community Priority**** > > Evaluation Panel (see new gTLD Program Update at the ICANN Dakar Meeting in > **** > > 2011).**** > > ** ** > > We have concerns that these entities may have a natural familiarity and*** > * > > pre-disposition toward business that may discriminate against applications > **** > > emphasizing community service over revenue-maximization.**** > > ** ** > > The ALAC thus calls for community-related expertise in the Community**** > > Priority Evaluation Panel and stands ready to offer appropriate and**** > > un-conflicted ICANN community volunteers to serve as panel members or**** > > advisors.**** > > ** ** > > END**** > > _______________________________________________**** > > 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

Re: [ALAC] ALAC E-mail Guide - for review
by Alan Greenberg July 27, 2013

July 27, 2013

At 24/07/2013 05:05 PM, Evan Leibovitch wrote: >My feedback. And mine, with the reminder that this guide is documenting what we have now, not what we may want to morph them into. Does anyone else have any comments? > * There IMO needs to be more distinction between the functions > and scope of the At-Large list vis. the ALAC list. Not sure what the issue is confusing those two lists. > * At very least, the At-Large list needs to be re-ordered near > the top. Where it is it seems out-of-place and almost as an afterthought. The order in this document has no real meaning. I ordered them based on the progression of ALAC -> RALO -> At-Large, but have not real stake in what order they are in. > * No mention in the Announce list of how unaffiliated members > (in regions that allow this) are accommodated. Do they have to self-subscribe? That is the way it is now. I suppose the Unaffiliated NARALO member should be subscribed by staff. Unaffiliated members could be as well, but that is not a thing that we have done in the past or now. Since they do not have an "ALS" list of their own, certainly something that we could do (but we in NARALO need to clean up that entire unaffiliated process, so I will presume it will wait for that to happen). > * The change from ExCom to "Leadership Team" is new, and needs > to be announced (and perhaps discussed) separately The list is still called ExCom and that is how it is documented. The comment notes that it will likely change at some point after the new RoP are in place. Presumably once the new RoP goes into effect and we start using the new name, appropriate announcements will be made. > * The regional lists' info don't say much about the treatment of > RALO non-members. Does everyone have the same privileges, including > possibly the overpowering by outsiders of discussions amongst RALO members? I have never heard of any such rules in any of the RALO lists (perhaps ignorance on my part) but presume if there were any, they would be RALO-initiated. In light of recent experiences, we probably should add something regarding the what level of Authority the RALO Chair has over list. > * Does a single code of conduct govern all lists, or are there > different codes for each list? The RoP talks about a Code of Conduct for all At-Large electronic communications platforms including e-mail. I presume that a RALO could add additional rules, but I have never heard of such an occurrence. Alan >- Evan > > >On 24 July 2013 16:28, Alan Greenberg ><<mailto:alan.greenberg@mcgill.ca>alan.greenberg(a)mcgill.ca> wrote: >Forgot to add, the draft Guide is also on the wiki at ><https://community.icann.org/x/kIYi>https://community.icann.org/x/kIYi. Alan > >At 24/07/2013 11:21 AM, Alan Greenberg wrote: >You will recall that one of the documents referred to by our new >Rules of Procedure is the ALAC E-mail Guide. This documents >describes our basic e-mail lists and also says which lists (or other >means of communications) are to be used in relation to selection >processes as well as removal/recall processes. >Please review the attached document. My intent was, like the various >Adjunct Documents, to have it mirror our current practices. Changes >may well be needed, but that can be done once we have all of the >documents and the new Rules of Procedure in place. > >In our earlier discussions, the intent was to not include the RALO >Discuss lists here, but since staff must subscribe people to them at >critical times, I would suggest that we include them here to allow >us to capture all mandatory subscription rules in one place. >Once any errors are corrected, I will move that it be adopted. >Alan > >_______________________________________________ >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… > > >_______________________________________________ >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… > > > > >-- >Evan Leibovitch >Toronto Canada >Em: evan at telly dot org >Sk: evanleibovitch >Tw: el56

2 1

Re: [ALAC] ALAC E-mail Guide - for review
by Alan Greenberg July 24, 2013

July 24, 2013

Forgot to add, the draft Guide is also on the wiki at https://community.icann.org/x/kIYi. Alan At 24/07/2013 11:21 AM, Alan Greenberg wrote: >You will recall that one of the documents referred to by our new >Rules of Procedure is the ALAC E-mail Guide. This documents >describes our basic e-mail lists and also says which lists (or other >means of communications) are to be used in relation to selection >processes as well as removal/recall processes. > >Please review the attached document. My intent was, like the various >Adjunct Documents, to have it mirror our current practices. Changes >may well be needed, but that can be done once we have all of the >documents and the new Rules of Procedure in place. > >In our earlier discussions, the intent was to not include the RALO >Discuss lists here, but since staff must subscribe people to them at >critical times, I would suggest that we include them here to allow >us to capture all mandatory subscription rules in one place. > >Once any errors are corrected, I will move that it be adopted. > >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…

2 1