March 2013 - ALAC - lists.icann.org

Re: [ALAC] RAA 3.7.8
by Alan Greenberg March 27, 2013

March 27, 2013

At 27/03/2013 11:47 AM, Garth Bruen at KnujOn wrote: >Thanks Alan. In terms of "words that in your mind would make the needed >link, please propose them.", yes I will submit. > >The important piece is connecting reports from the public to obligations >of compliance in an clear and explicit way, this what is missing. > >My recommendations are to > >Change the WHOIS Accuracy Specification #5 from: > >Upon the occurrence of a Registered Name Holder's willful provision >of inaccurate or unreliable WHOIS information > >To: > >Upon the REPORT OR DISCOVERY of a Registered Name Holder's willful >provision of inaccurate or unreliable WHOIS information Although when I first saw this mentioned in Holly's wiki post, I liked it, but on reflection it does not quite work. I can report that Knujon is obviously a made up name and is a willful attempt to mask your true identity. Or that "Garth" is clearly a fabrication. If the registrar knows that these are both legitimate, should you still be required to provide documentation of their validity to the registrar within 15 days or loose your domains? I still like the idea, but that language cannot work. Would you accept "Upon a validated report or discovert..."? >AND modify the contract language of 3.7.8 from: > >"...Registrar shall, upon notification by any person of an inaccuracy in >the contact information associated with a Registered Name sponsored by >Registrar, take reasonable steps to investigate that claimed inaccuracy. >In the event Registrar learns of inaccurate contact information >associated with a Registered Name it sponsors, it shall take reasonable >steps to correct that inaccuracy." > >To: > >"...Registrar shall, upon notification by any person of an inaccuracy in >the contact information associated with a Registered Name sponsored by >Registrar, take reasonable steps to investigate that claimed inaccuracy. >In the event Registrar learns of inaccurate contact information >associated with a Registered Name it sponsors, it shall take reasonable >steps to correct that inaccuracy AND IF NEEDED CANCEL OR SUSPEND THE >DOMAIN IN ACCORDANCE WITH THE ACCURACY SPECIFICATION." Why is this needed when 3.7.8 starts with "Registrar shall comply with the obligations specified in the Whois Accuracy Program Specification"? Alan

1 0

Re: [ALAC] RAA 3.7.8
by Garth Bruen at KnujOn March 27, 2013

March 27, 2013

Thanks Evan, I'm good with the addition as long as the public report is directly tied to a contractual obligation > -------- Original Message -------- > Subject: Re: [ALAC] RAA 3.7.8 > From: Evan Leibovitch <evan(a)telly.org> > Date: Wed, March 27, 2013 12:20 pm > To: Garth Bruen at KnujOn <gbruen(a)knujon.com> > Cc: Alan Greenberg <alan.greenberg(a)mcgill.ca>, ALAC Working List > <alac(a)atlarge-lists.icann.org> > > > On 27 March 2013 11:47, Garth Bruen at KnujOn <gbruen(a)knujon.com> wrote: > > Change the WHOIS Accuracy Specification #5 from: > > > > “Upon the occurrence of a Registered Name Holder's willful provision > > of inaccurate or unreliable WHOIS information…” > > > > To: > > > > “Upon the REPORT OR DISCOVERY of a Registered Name Holder's willful > > provision of inaccurate or unreliable WHOIS information…” > > > > > Agreed, though I think that "report" is sufficient. A discovery that is > unreported can't be of much help. > > > > > AND modify the contract language of 3.7.8 from: > > > > "...Registrar shall, upon notification by any person of an inaccuracy in > > the contact information associated with a Registered Name sponsored by > > Registrar, take reasonable steps to investigate that claimed inaccuracy. > > In the event Registrar learns of inaccurate contact information > > associated with a Registered Name it sponsors, it shall take reasonable > > steps to correct that inaccuracy." > > > > To: > > > > "...Registrar shall, upon notification by any person of an inaccuracy in > > the contact information associated with a Registered Name sponsored by > > Registrar, take reasonable steps to investigate that claimed inaccuracy. > > In the event Registrar learns of inaccurate contact information > > associated with a Registered Name it sponsors, it shall take reasonable > > steps to correct that inaccuracy AND IF NEEDED CANCEL OR SUSPEND THE > > DOMAIN IN ACCORDANCE WITH THE ACCURACY SPECIFICATION." > > > > I'm OK with the intent, but would suggest something more explicit, that > allows for a period of time to make corrections. > > > "...Registrar shall, upon notification by any person of an inaccuracy > in the contact information associated with a Registered Name sponsored > by Registrar, take reasonable steps to investigate that claimed > inaccuracy. In the event Registrar learns of inaccurate contact > information associated with a Registered Name it sponsors, it shall take > reasonable steps to correct that inaccuracy. Domains that maintain > inaccurate information, after given reasonable time to be corrected upon > notification, shall be cancelled or suspended by the Registrar in > accordance with the accuracy specification. > > Is this any more palatable? > > - Evan

1 0

Re: [ALAC] RAA 3.7.8
by Garth Bruen at KnujOn March 27, 2013

March 27, 2013

Thanks Alan. In terms of "words that in your mind would make the needed link, please propose them.", yes I will submit. The important piece is connecting reports from the public to obligations of compliance in an clear and explicit way, this what is missing. My recommendations are to Change the WHOIS Accuracy Specification #5 from: “Upon the occurrence of a Registered Name Holder's willful provision of inaccurate or unreliable WHOIS information…” To: “Upon the REPORT OR DISCOVERY of a Registered Name Holder's willful provision of inaccurate or unreliable WHOIS information…” AND modify the contract language of 3.7.8 from: "...Registrar shall, upon notification by any person of an inaccuracy in the contact information associated with a Registered Name sponsored by Registrar, take reasonable steps to investigate that claimed inaccuracy. In the event Registrar learns of inaccurate contact information associated with a Registered Name it sponsors, it shall take reasonable steps to correct that inaccuracy." To: "...Registrar shall, upon notification by any person of an inaccuracy in the contact information associated with a Registered Name sponsored by Registrar, take reasonable steps to investigate that claimed inaccuracy. In the event Registrar learns of inaccurate contact information associated with a Registered Name it sponsors, it shall take reasonable steps to correct that inaccuracy AND IF NEEDED CANCEL OR SUSPEND THE DOMAIN IN ACCORDANCE WITH THE ACCURACY SPECIFICATION." ------------------------------------- Garth Bruen gbruen(a)knujon.com 617-947-3805 http://www.knujon.com http://www.linkedin.com/pub/4/149/724 Linkedin Group: http://www.linkedin.com/groups?gid=1870205 Blog: http://www.circleid.com/members/3296/ Twitter: @Knujon Shop: http://www.cafepress.com/knujon Bookstore: http://astore.amazon.com/knujocom-20 > -------- Original Message -------- > Subject: RE: [ALAC] RAA 3.7.8 > From: Alan Greenberg <alan.greenberg(a)mcgill.ca> > Date: Tue, March 26, 2013 10:35 pm > To: Garth Bruen <gbruen(a)knujon.com>, 'ALAC Working List' > <alac(a)atlarge-lists.icann.org> > > > See my comments below. Alan > > At 22/03/2013 04:59 PM, Garth Bruen wrote: > >Alan, > > > >Thanks for the question. > > > >My first concern is that the contract and the specifications are not the > >same thing, I would argue it is worth putting this within the contract to > >make it clear if it is worth putting in at all. > > The Whois specification is explicitly invoked in 3.7.8 is for all > intents and purposes an integral part of the RAA. They are using the > Specifications in much the same way that the draft ALAC Rules of > Procedure use Adjunct Documents to take a lt of the details out of > the mainstream set of rules. > > >My second concern is a logical disconnect between the language of the > >specification and the language of the second clause of 3.7.8. Let me > >explain. > > > >The major problem with 3.7.8 is in this wording: "Registrar shall, upon > >notification by any person of an inaccuracy in the contact information > >associated with a Registered Name sponsored by Registrar, take reasonable > >steps to investigate that claimed inaccuracy. In the event Registrar learns > >of inaccurate contact information associated with a Registered Name it > >sponsors, it shall take reasonable steps to correct that inaccuracy." > > > >This allows non-contracted parties to the RAA to file complaints about false > >registrations but it does NOT contain any enforcement measures. It does not > >compel the registrar to do anything, does not define "reasonableness", and > >therefore gives ICANN no method for addressing it. > > I grant that "reasonable" is not defined, but this is absolutely > standard contract language (clauses such as "this contract may not be > transfered with the explicit permission of party A, such permission > shall not unreasonably be withheld"). Yes, it is at times not honours > properly and at times goes to court or arbitration, but these are > terms that are very difficult to define fully, and when you try, the > definition often comes back to bite you. That being said, if you do > have a definition that you think would work, by all means propose it. > > > >The specification #5 states: "Upon the occurrence of a Registered Name > >Holder's willful provision of inaccurate or unreliable WHOIS information, > >its willful failure promptly to update information provided to Registrar, or > >its failure to respond for over fifteen (15) calendar days to inquiries by > >Registrar > >concerning the accuracy of contact details associated with the Registered > >Name Holder's registration " > > > >There is no specific or implied connection between inaccuracies reported by > >the public and "the occurrence of a ... provision of inaccurate or > >unreliable WHOIS information." The assumption that "notification by any > >person" translates to an "occurrence" is just an assumption. How a report > >from the public becomes an issue requiring process is not defined. > > Again, if you have some words that in your mind would make the needed > link, please propose them. > > > >Furthermore there is muddling of the obligations of the registrant versus > >the obligation of the registrar. 3.7.8 ONLY refers to obligations by the > >registrar, with the second clause ONLY referring to registrar obligations in > >response to public reports. The specification document refers to registrar > >verification and validation. Only specification #4 provides for ANY eternal > >inaccuracy report data and this ONLY refers to contact email addresses, no > >other data elements such as phone numbers, mailing addresses or entity > >names. > > > >The overarching point is that 3.7.8 is one of the few (if only) contract > >sections which opens the door to community oversight or grievance but it is > >artfully hobbled. This new specification as written does NOT fix the > >problem. It still completely leaves domain cancelation at the discretion of > >the registrar, still leaves the definitions of "inaccuracy" and > >"reasonableness" up to the registrar. > > > >We are dealing in an area of vast gray paint which needs to be clear for all > >to see. > > > >-Garth > > > > > >-----Original Message----- > >From: alac-bounces(a)atlarge-lists.icann.org > >[mailto:alac-bounces@atlarge-lists.icann.org] On Behalf Of Alan Greenberg > >Sent: Friday, March 22, 2013 2:57 PM > >To: ALAC Working List > >Subject: [ALAC] RAA 3.7.8 > >Importance: High > > > >Garth, on the recent teleconference on the RAA you raised the issue of RAA > >3.7.8 and said the problem of its being unenforceable by ICANN was still not > >resolved. > > > >As I read it, 3.7.8 (and associated specifications) now says: > > > >- verification of contact information at time of registration required > >- periodic re-verification > >- upon notification of inaccuracy > >- if inaccurate information is found and not corrected within 15 days, > >registrar must terminate or suspend registration, or place it on clientHold. > > > >If the registrar does not do this, they have violated the terms of the RAA. > > > >What more is it that you are looking for? > > > >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+(ALA > >C)

2 1

Re: [ALAC] [Registrants-rights] Fwd: OPEN PUBLIC COMMENT: Proposed 2013 RAA Posted for Comment
by Alan Greenberg March 27, 2013

March 27, 2013

Holly, I do not see a "link below" so do not know exactly what you are referring to. The gist of the statement that I am thinking of is pretty much what you imply and as I implied today: - We are very happy with the overall changes, this is a MUCH better contract from the point of view of ICANN and registrants. - Although we would prefer to have an RAA which both ICANN and registrars have fully endorsed, we support ICANN's implied position that it has the right to put a new RAA in place even if registrars have not agreed to all provision. - We have some concern with the unilateral right to amend, but at the same time appreciate that ICANN needs some way to implement changes quicker that though the regular amendment process and then waiting up to five years for the new provision to take effect. - ICANN has been silent on exactly how the RAA will be put into effect, and in the 2008/9 version, it was deemed necessary for the GNSO to ratify the new RAA before the Board could approve it. The ALAC is taking this silence to mean that GNSO ratification will not be required this time, a position that ALAC supports. - ... The ... needs to include: - things that we feel need to be changed in the agreed to language. - places where there is not closure but we strongly support ICANN's provision - places where there is not closure but we strongly support the registrar's provision - preferably for all places whete there is still a difference, we should come down on one side or another. This is one of the main reasons this RAA is out for comment now. It is in these last areas that we QUICKLY need very specific input. Alan At 26/03/2013 06:25 PM, Holly Raiche wrote: >Folks > >There is not a lot of time for this. But please have a look (link >below) - from whatever perspective. > >There are many positives in what has been negotiated in the RAA >itself and in the accompanying documents. There are still some >outstanding issues as well. There was an all-too-brief look at the >issues in the ALAC call today - noting that Whois issues are part of the mix. > >Some of today's discussion did mention that the discussion of issues >are overlapping - and this is a classic case. But we still must >develop comments on the RAA - particularly on those issues that are >still the subject of negotiation, but also to say we are happy with >the changes (in most cases we are but maybe not for everything?). > >It you don't have time to go through all the documents, concentrate >on one or two and provide feedback. Alan holds the pen for this - >and it's too big a task for him to do without all of your help. > >Holly

1 0

RAA 3.7.8
by Alan Greenberg March 27, 2013

March 27, 2013

Garth, on the recent teleconference on the RAA you raised the issue of RAA 3.7.8 and said the problem of its being unenforceable by ICANN was still not resolved. As I read it, 3.7.8 (and associated specifications) now says: - verification of contact information at time of registration required - periodic re-verification - upon notification of inaccuracy - if inaccurate information is found and not corrected within 15 days, registrar must terminate or suspend registration, or place it on clientHold. If the registrar does not do this, they have violated the terms of the RAA. What more is it that you are looking for? Alan

2 4

Re: [ALAC] RAA 3.7.8
by Garth Bruen March 27, 2013

March 27, 2013

Alan, Thanks for the question. My first concern is that the contract and the specifications are not the same thing, I would argue it is worth putting this within the contract to make it clear if it is worth putting in at all. My second concern is a logical disconnect between the language of the specification and the language of the second clause of 3.7.8. Let me explain. The major problem with 3.7.8 is in this wording: "Registrar shall, upon notification by any person of an inaccuracy in the contact information associated with a Registered Name sponsored by Registrar, take reasonable steps to investigate that claimed inaccuracy. In the event Registrar learns of inaccurate contact information associated with a Registered Name it sponsors, it shall take reasonable steps to correct that inaccuracy." This allows non-contracted parties to the RAA to file complaints about false registrations but it does NOT contain any enforcement measures. It does not compel the registrar to do anything, does not define "reasonableness", and therefore gives ICANN no method for addressing it. The specification #5 states: "Upon the occurrence of a Registered Name Holder's willful provision of inaccurate or unreliable WHOIS information, its willful failure promptly to update information provided to Registrar, or its failure to respond for over fifteen (15) calendar days to inquiries by Registrar concerning the accuracy of contact details associated with the Registered Name Holder's registration " There is no specific or implied connection between inaccuracies reported by the public and "the occurrence of a ... provision of inaccurate or unreliable WHOIS information." The assumption that "notification by any person" translates to an "occurrence" is just an assumption. How a report from the public becomes an issue requiring process is not defined. Furthermore there is muddling of the obligations of the registrant versus the obligation of the registrar. 3.7.8 ONLY refers to obligations by the registrar, with the second clause ONLY referring to registrar obligations in response to public reports. The specification document refers to registrar verification and validation. Only specification #4 provides for ANY eternal inaccuracy report data and this ONLY refers to contact email addresses, no other data elements such as phone numbers, mailing addresses or entity names. The overarching point is that 3.7.8 is one of the few (if only) contract sections which opens the door to community oversight or grievance but it is artfully hobbled. This new specification as written does NOT fix the problem. It still completely leaves domain cancelation at the discretion of the registrar, still leaves the definitions of "inaccuracy" and "reasonableness" up to the registrar. We are dealing in an area of vast gray paint which needs to be clear for all to see. -Garth -----Original Message----- From: alac-bounces(a)atlarge-lists.icann.org [mailto:alac-bounces@atlarge-lists.icann.org] On Behalf Of Alan Greenberg Sent: Friday, March 22, 2013 2:57 PM To: ALAC Working List Subject: [ALAC] RAA 3.7.8 Importance: High Garth, on the recent teleconference on the RAA you raised the issue of RAA 3.7.8 and said the problem of its being unenforceable by ICANN was still not resolved. As I read it, 3.7.8 (and associated specifications) now says: - verification of contact information at time of registration required - periodic re-verification - upon notification of inaccuracy - if inaccurate information is found and not corrected within 15 days, registrar must terminate or suspend registration, or place it on clientHold. If the registrar does not do this, they have violated the terms of the RAA. What more is it that you are looking for? 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+(ALA C)

2 1

Outcome of new gTLDs, "Strawman" proposal
by Alan Greenberg March 27, 2013

March 27, 2013

ICANN has announced the outcome of the new gTPD trademark protection discussion. http://newgtlds.icann.org/en/about/trademark-clearinghouse/strawman-solutio… Although the outcomes were not exactly as the ALAC advised (in terms of what required policy development), all of the IP protections that ICANN will be moving ahead with were supported by the ALAC, and the one additional protection that the ALAC explicitly did not support will not be implemented. Also a vlog from the CEO - http://blog.icann.org/2013/03/new-gtld-milestones-and-deadlines/. Alan

3 3

Motion for the adoption of the new Rules of Procedure
by Alan Greenberg March 26, 2013

March 26, 2013

I would like to make the following motion to be voted on electronically as soon as practical after the completion of the 26 March 2013 ALAC meeting. The wording in square brackets will be replaced by a pointer to the final proposed Rules of Procedure. Is there another ALAC member who would be willing to second this motion? Alan ========================== Whereas the current ALAC Rules of Procedure dates back to 2007, at the very start of the formation of the current RALO-based At-Large Community; Whereas experiences of the ensuing six years had shown that an overall review was required; Whereas a project to review and re-write the Rules of Procedure has been underway since April 2012, and that this project has involved extensive study, discussion and drafting by ALAC members and others from all ICANN regions; Resolved that the [current draft version the ALAC Rules of Procedure (v71), as modified during the ALAC meeting of 26 March 2013] be adopted to replace the current ALAC Rules of Procedure (Document number AL/2007/1/1.Rev 11). The new Rules will take effect as soon as Adjunct Documents RoP-Adjunct-01, RoP-Adjunct-03 and RoP-Adjunct-04 referenced by the proposed Rules of Procedure have been approved by the ALAC.

2 1

Re: [ALAC] Rules of Procedure - Draft for discussion at 26 March ALAC meeting
by Alan Greenberg March 26, 2013

March 26, 2013

The "deemed present" means that all ALAC members had an opportunity to vote, not that they voted. It ensures that the requirement that all regions be represented during the vote is met and that the overall quorum rule (more than 50%) is met. However, you are correct in that today, we must record a "quorums worth of vote", that is >50%, for the vote to be considered quorate and we lost that when this provision was added. Good catch. I would suggest (a combination of your options): 11.4.2 For votes taken electronically or over a period of time, all ALAC Members are deemed to have been present. To be considered a valid decision, more than 50% of sitting ALAC members must record a vote (including abstain if available). Alan At 25/03/2013 02:27 PM, Evan Leibovitch wrote: >Thanks for this work. I approve of the changes and believe they do improve >clarity. > >I have one question (and apologize for the tardiness, I haven't really been >contributing much): > >*11.4.2 For votes taken electronically or over a period of time, all ALAC >Members are deemed to have been present* > >I wonder if this may be problematic, in cases where an online vote >(nominally now done by BigPulse) is held, but does not have many >participants. If a BigPulse vote is held but does not have at least a >quorum's worth of votes, does it still count? > >I would suggest choosing either of two paths: > >either > >* 11.4.2 For votes taken electronically or over a period of time, all ALAC >Members are deemed to have been present. Members who do not participate in >the vote will be deemed to have abstained. >* > >or > >* 11.4.2 For votes taken electronically or over a period of time, at least >50% of sitting ALAC members must record a vote in order for the result to >be a valid decision* > > >My preference is for the second choice but I can live with either. > >- Evan

3 2

Re: [ALAC] Rules of Procedure - Draft for discussion at 26 March ALAC meeting
by Alan Greenberg March 25, 2013

March 25, 2013

Yup. Pretty much what I suggested (although it took a while to get out to the list). Alan At 25/03/2013 05:52 PM, Eduardo Diaz wrote: >True. Maybe we can state it as follows: > >11.4.2 For votes taken electronically or over a period of time, all ALAC >Members are deemed to have been present. More than 50% of the ALAC Members >have to vote to be considered valid. >-ed >On Mon, Mar 25, 2013 at 3:30 PM, Evan Leibovitch <evan(a)telly.org> wrote: > > > On 25 March 2013 15:03, Eduardo Diaz <eduardodiazrivera(a)gmail.com> wrote: > > > >> Evan: > >> > >> 11.4.2 establishes quorum by indicating that "...all members are deemed > >> to have been present". If a member does not want to participate in the > >> electronic vote, his/her vote will not have any balance in the final > >> result. For whatever reason people just do not vote sometimes. > >> > > > > Well, if a Member is deemed to be present their "non vote" still needs to > > be counted in a final tally. If it's to be counted as an abstention that > > needs to be made explicity (ie, my first option). Preferably, a poll that > > cannot attract a majority of ALAC members to cast a vote -- even an > > explicit abstention -- should IMO not be considered any more valid than an > > in-person show of hands in which a majority of Members are out of the room. > > It looks awful as a matter of acccountability, and is subject to > > manipulation. > > > > Cheers, > > > > - Evan > > > > > > > > > > > > > > > > > > > >> > >> -ed > >> > >> On Mon, Mar 25, 2013 at 2:27 PM, Evan Leibovitch <evan(a)telly.org> wrote: > >> > >>> Thanks for this work. I approve of the changes and believe they do > >>> improve > >>> clarity. > >>> > >>> I have one question (and apologize for the tardiness, I haven't really > >>> been > >>> contributing much): > >>> > >>> *11.4.2 For votes taken electronically or over a period of time, all ALAC > >>> Members are deemed to have been present* > >>> > >>> > >>> I wonder if this may be problematic, in cases where an online vote > >>> (nominally now done by BigPulse) is held, but does not have many > >>> participants. If a BigPulse vote is held but does not have at least a > >>> quorum's worth of votes, does it still count? > >>> > >>> I would suggest choosing either of two paths: > >>> > >>> either > >>> > >>> * 11.4.2 For votes taken electronically or over a period of time, all > >>> ALAC > >>> > >>> Members are deemed to have been present. Members who do not participate > >>> in > >>> the vote will be deemed to have abstained. > >>> * > >>> > >>> or > >>> > >>> * 11.4.2 For votes taken electronically or over a period of time, at > >>> least > >>> > >>> 50% of sitting ALAC members must record a vote in order for the result to > >>> be a valid decision* > >>> > >>> > >>> > >>> My preference is for the second choice but I can live with either. > >>> > >>> - Evan > >>> > >>> > >>> > >>> > >>> > >>> > >>> On 25 March 2013 03:52, Yaovi Atohoun <yaovito(a)yahoo.fr> wrote: > >>> > >>> > > >>> > > >>> > Dear Alan, > >>> > > >>> > Thank you again for the hard work. > >>> > > >>> > > >>> > A/ comments/questions > >>> > > >>> > 1) Does "recall" of an ALT member means that this member is no more > >>> > member of ALT but remains an ALAC member? > >>> > 2) For BCEC it is mentioned: A new BCEC will be convened for each > >>> Board > >>> > Seat Selection Process in 19.3. Please don't we need such precision > >>> for > >>> > BMSPC too? > >>> > > >>> > > >>> > B/ Comment > >>> > > >>> > 1) I would prefer to see also included in 12.1.15 the removal of an > >>> ALAC > >>> > member. I note that 21.2 is saying "should a vote be necessary > >>> ......" > >>> > > >>> > C/ One thought > >>> > > >>> > Could we have a situation where a chair decide to become a regular ALT > >>> or > >>> > ALAC member in a situation where he thinks that he could not more > >>> carry the > >>> > work load? > >>> > > >>> > > >>> > Thank you > >>> > Yaovi > >>> > > >>> > > >>> > ________________________________ > >>> > De : Alan Greenberg <alan.greenberg(a)mcgill.ca> > >>> > À : ALAC Working List <alac(a)atlarge-lists.icann.org> > >>> > Envoyé le : Lundi 25 mars 2013 6h23 > >>> > Objet : [ALAC] Rules of Procedure - Draft for discussion at 26 March > >>> ALAC > >>> > meeting > >>> > > >>> > Attached please find the Draft Rules of Procedure for discussion at > >>> the 26 > >>> > March 2013 ALAC meeting. Also attached is a redline version showing > >>> most of > >>> > the changes from the RoP discussed at the 19 March 2013 meeting. > >>> > > >>> > In addition to the changes detailed below, there are two sets of > >>> changes > >>> > what do not show in the redline: > >>> > > >>> > - A number of corrections to cross-references within the document. > >>> > - The movement of what was "10.3 Meeting Rules" to "10. Rules of the > >>> > ALAC". This change was not shown in the redline version since the move > >>> > caused all of the following paragraph numbers to be changed, making the > >>> > document quite confusing. > >>> > > >>> > Changes showing in the redline version: > >>> > > >>> > 1. Clarifying the status of individual members within At-large. > >>> > 1.2 clarification of rules used. > >>> > 2. Add definition of Super-majority and capitalize it where used within > >>> > the document. > >>> > 5.2 and other places: Define AAGM on first usage, and us it instead of > >>> AGM > >>> > within the document (some occurrences previously said AGM). > >>> > 5.6 Made reference to privileges associated only with the "ALAC Chair" > >>> > clearer. > >>> > 5.13 Replaced reference to Ombudsman with an alternative phrase taken > >>> from > >>> > the ICANN Bylaws. > >>> > 5.14 Added condition that only those who have at least one other ALAC > >>> > member supporting them can be named Chair. > >>> > 10.1 The section on rules was moved because it did not apply only to > >>> > meetings. The addition of "or activities" acknowledges this. > >>> > 11.4.2 Add a word that had inadvertently been omitted. > >>> > 11.4.4 Removal of a redundant phrase. > >>> > 11.2.3 Addition of rule to allow more stringent rules for motion > >>> adoption. > >>> > > >>> > The draft RoP can also be found at https://community.icann.org/x/VoYi. > >>> > > >>> > 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… > >>> > _______________________________________________ > >>> > 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… > >>> > > >>> > >>> > >>> > >>> -- > >>> 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 > >>> > >>> At-Large Online: http://www.atlarge.icann.org > >>> ALAC Working Wiki: > >>> > https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(AL… > >>> > >> > >> > >> > >> -- > >> *NOTICE:* This email may contain information which is confidential > >> and/or subject to legal privilege, and is > intended for the use of the named > >> addressee only. If you are not the intended recipient, you must not use, > >> disclose or copy any part of this email. If > you have received this email by > >> mistake, please notify the sender and delete this message immediately. > >> > >> > > > > -- > > Evan Leibovitch > > Toronto Canada > > > > Em: evan at telly dot org > > Sk: evanleibovitch > > Tw: el56 > > > > > > >-- >*NOTICE:* This email may contain information which is confidential and/or >subject to legal privilege, and is intended for the use of the named >addressee only. If you are not the intended recipient, you must not use, >disclose or copy any part of this email. If you have received this email by >mistake, please notify the sender and delete this message immediately. >_______________________________________________ >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