February 2013 - ALAC - lists.icann.org

New gTLD Program Committee resolution on "closed generic" strings
by Alan Greenberg Feb. 6, 2013

Feb. 6, 2013

Note that the Public Comment closes on March 7 and does not seem to have a reply period. Alan http://www.icann.org/en/news/public-comment/closed-generic-05feb13-en.htm ICANN is seeking public comment on the subject of "closed generic" gTLD applications and whether specific requirements should be adopted corresponding to this type of application. Stakeholder views are invited to help define and consider this issue. In particular, comments would be helpful in regard to proposed objective criteria for: - classifying certain applications as "closed generic" TLDs, i.e., how to determine whether a string is generic, and - determining the circumstances under which a particular TLD operator should be permitted to adopt "open" or "closed" registration policies. The New gTLD Program Committee of the ICANN Board of Directors has discussed this issue and has also directed completion of a set of focused research and analysis items to inform any possible action to be taken. At its 2 February 2013 meeting, the Committee passed the following resolution: Whereas, the New gTLD Program Committee has received correspondence from the community addressing "closed generic" TLDs and understands that members of the community term a "closed generic" TLD as a TLD string that is a generic term and is proposed to be operated by a participant exclusively for its own benefit. Whereas, ICANN implemented the Generic Names Supporting Organization (GNSO) policy recommendations on the "Introduction of New Generic Top-Level Domains", and within those policy recommendations there is no specific policy regarding "closed generic" top-level domains (TLDs). Whereas, members of the community have expressed concerns regarding applications for "closed generic" TLDs. Whereas, the New gTLD Program Committee considers that it is important to understand all views and potential ramifications relating to 'closed generic' TLDs. Resolved (2013.02.02.NG01), the New gTLD Program Committee directs the President and CEO to open a 30-day public comment forum on this topic, which should include a call for identification of proposed objective criteria to classify applied-for TLDs as "closed generic" TLDs. Resolved (2013.02.02.NG02), the New gTLD Program Committee directs the President and CEO to, concurrently with the opening of the public comment forum, request the GNSO to provide guidance on the issue of "closed generic" TLDs if the GNSO wishes to provide such guidance. Guidance on this issue is requested to be provided by the close of the public comment forum. Resolved (2013.02.02.NG03), the New gTLD Program Committee directs the President and CEO to: - Summarize and analyze all comments submitted in the public comment forum. - Review materials supporting the policy development process resulting in the GNSO policy recommendations on the Introduction of New Generic Top-Level Domains and provide analysis of any discussions relating to the limitations on potential new gTLDs. - Analyze the feasibility of objectively classifying applied for TLDs as "closed generic" TLDs. - Provide an analysis as to whether the public interest and principles of international law are served by adopting a clear approach regarding 'closed generic' gTLDs. - Provide a report to the New gTLD Program Committee informed by the comments received and analysis conducted, including alternatives to addressing this issue.

1 0

Re: [ALAC] Preliminary report the Meeting of the New gTLD Program Committee, which took place on 10 January 2013.
by Evan Leibovitch Feb. 5, 2013

Feb. 5, 2013

Yes, interesting. On closed generics, isn't their discussion like, maybe, five years too late? Sure the AG indicates the process can be changed after-the-fact, but this (the private registrability od generic words) is a MAJOR point of philosophy, and both IMO too late to change and massively subject to lawsuits if it's attempted. And then there's this gem: *"Many of the Board members will be uncomfortable approving TLDs that are seen as a land grab, as opposed to expansion of the DNS"* The suggestion that a distinction ought to (or even can) be drawn between the two concepts, at this time, is ... charming. - Evan

1 0

Preliminary report the Meeting of the New gTLD Program Committee, which took place on 10 January 2013.
by Alan Greenberg Feb. 5, 2013

Feb. 5, 2013

From Bruce Tonkin to GNSO COuncil - very interesting. Alan >The full minutes for the 10 Jan 2013 meeting are now available at: > >http://www.icann.org/en/groups/board/documents/minutes-new-gtld-10jan13-en.… > >I have also attached the briefing documents used at that meeting. > >Note that the new gTLD committee also met during the Board workshop >on 1-2 Feb, so expect a preliminary report soon.

2 1

Re: [ALAC] Voting infrastructure rules
by Alan Greenberg Feb. 1, 2013

Feb. 1, 2013

Thanks everyone. My sense if that there is a strong inclination to leave the rules exactly as they were. That has the benefit of us not actually having to do anything, which is always a plus. I must admit I was a bit surprised by the level of contributions on something that I saw as a matter of making information available as soon as possible unless there was a strong reason for withholding (as we expect of others in ICANN). But disagreement and debate is healthy, and I have no problem with the outcome. I do support Evan's dream of seeing this level of debate on the policy issues that we are here to address. Alan At 01/02/2013 10:09 AM, Evan Leibovitch wrote: >My latest (and hopefully final) observations: > > > - I am swayed by those who prefer the original wording of #4. > > - The "independence" rationale against changing #4 is without merit (and > insulting to the integrity of the voters), though other valid > reasons exist > > - In a "votes are visible throughout the poll" scheme, more weight of > influence may be unduly given to those who vote fastest with an intent to > sway. Mid-poll is not the time to be trying to influence one's peers, that > should be done in pre-vote debate. Indeed the most compelling argument > against changing #4 is that it would further reduce the motivation for > pre-vote discussion and issue awareness. As it is, we already are > challenged in this regard > > - If I feel weak on an issue and want to know the opinion of trusted > colleagues, I can do that privately and/or before the vote starts. I don't > need to see how they vote during the poll. Better still, there should be > open debate where I can hear from everyone on not just how they intend to > vote, but why. > > - Transparency and accountability requirements are sufficiently > fulfilled by posting who-voted-how after the results are final (which is > what the original #4 already mandates) > > - In a weak moment, I dream that the level and quality of debate given > to this process issue matter might perhaps extend to our policy issues. > > >Cheers, > >- Evan >_______________________________________________ >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

Re: [ALAC] Voting infrastructure rules
by Evan Leibovitch Feb. 1, 2013

Feb. 1, 2013

My latest (and hopefully final) observations: - I am swayed by those who prefer the original wording of #4. - The "independence" rationale against changing #4 is without merit (and insulting to the integrity of the voters), though other valid reasons exist - In a "votes are visible throughout the poll" scheme, more weight of influence may be unduly given to those who vote fastest with an intent to sway. Mid-poll is not the time to be trying to influence one's peers, that should be done in pre-vote debate. Indeed the most compelling argument against changing #4 is that it would further reduce the motivation for pre-vote discussion and issue awareness. As it is, we already are challenged in this regard - If I feel weak on an issue and want to know the opinion of trusted colleagues, I can do that privately and/or before the vote starts. I don't need to see how they vote during the poll. Better still, there should be open debate where I can hear from everyone on not just how they intend to vote, but why. - Transparency and accountability requirements are sufficiently fulfilled by posting who-voted-how after the results are final (which is what the original #4 already mandates) - In a weak moment, I dream that the level and quality of debate given to this process issue matter might perhaps extend to our policy issues. Cheers, - Evan

1 0

Re: [ALAC] Voting infrastructure rules
by Alan Greenberg Feb. 1, 2013

Feb. 1, 2013

In my mind, it is essential that we see who has voted and who has not. That allows regional people to make sure their ALAC members vote. If we are so worried about people who have no clue how to vote on an issue and will be easily pressured, I really think that we have selected the wrong ALAC members. As Evan said, all of us occasionally find that on a specific topic, we don't have strong positions, but are glad to take a hint from someone we respect. The alternative, as I have mentioned is to not vote at all, or vote randomly, or blindly say yes to every such poll. All of which I find far more distasteful than having a colleague you respect point you in a direction. Remember, these votes are being taken electronically because we do not have a meeting scheduled at a convenient time. If we did have such a meeting, it would all be out in the open. Why hide the details in this situation. In fact, although I had not thought about it earlier, seeing that a colleague that you respect voted in the opposite direction to your inclination is a really healthy thing. You may well call them up and ask why - what do they know that you don't - and maybe should. If we did not use BigPulse, we would probably do what so many other organizations do in this kind of situation, simply send your vote to the mailing list. And it is all in the open, and people who don't vote can be urged on by their colleagues. Or maybe we want to go to secret ballots for everything. Alan At 31/01/2013 02:26 PM, Dev Anand Teelucksingh wrote: >Dear Alan, > >My preference is to keep 4 as is. (Only when the vote is ended, do we >(and observers) see how each person has voted.) > >I wonder what is the need of rules 1 to 3 for ALAC votes conducted >online. The duration of such votes is typically several days. > >Consider a scenario when an online ALAC vote is ongoing and the vote >is split with no clear outcome. Observers and ALAC members can see 6 >persons voted no, 6 persons voted yes and by a process of elimination, >know which 3 ALAC members have yet to vote. > >Doesn't the potential exist where the 3 ALAC members yet to vote can >be contacted by other ALAC members or observers to influence their >vote? > >Perhaps to ensure the integrity of the voting process, rules 1 to 3 >should be removed. This would mean no information during the voting >period is shown to ALAC members and observers. > > >Kind Regards, > >Dev Anand Teelucksingh > > > >On Thu, Jan 31, 2013 at 12:42 AM, Alan Greenberg ><alan.greenberg(a)mcgill.ca> wrote: > > Currently we have in place a set of rules (approved by the ALAC in > > June 2009) on how votes are to be conducted (that is votes that are > > not in reference to named individuals). > > > > Those rules are: > > > > 1. As the vote is proceeding, we can see how many people have voted. > > 2. As the vote is proceeding, we can see who has voted. > > 3. As the vote is proceeding, we can see a tally of how the votes > > have been cast. > > 4. When the vote is ended, we can see how each person has voted. > > 5. The order of the options should not change as the vote proceeds. > > 6. Outsiders who cannot vote can look at all of the above interim results. > > > > Rule 4 was there because previously, we had on some occasions used a > > BigPulse option to order the options so that the winning one was > > first. The rules were debated and approved because at the time, we > > seemd to used a semi-random set of voting parameters for each vote. > > > > Based on the last few votes, we seem to be back at the state of > > semi-random variations in each vote (the current ALS approval vote > > does not allow a voter to see who has already voted, the recent votes > > on ALAC statements on Thickwhois and IGO/INGO questions did allow > > viewing the list of those who had voted). > > > > Since we are in the process of cleaning up the overall ALAC rules, it > > makes sense to revisit this one prior to having staff adjust > > procedures to ensure that our rules are being met. > > > > So I ask whether these are the rules we want or if changes need to be made. > > > > I would suggest one change. Since these rules were created to have a > > similar effect as a face-to-face vote with all parties and observers > > in the same room, I would suggest the replacement of 4 with: > > > > 4. As the vote is proceeding, we can see how voted have voted. > > > > This was considered last time, but was not used due to a fear that > > seeing how people vote could influence later votes. My thoughts are > > that this is exactly what happens in a face-to-face vote and should > > not change because we are voting electronically. > > > > Does anyone have any thoughts on this. Specifically: > > > > A) Should we keep the current rules? > > B) Should we replace 4. as suggested? > > C) Any other changes you believe we should make? > > > > We regularly demand transparency of other parts of ICANN and > > particularly the Board. I think that we should use the same standard > > for ourselves. > > > > 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…

4 3

Re: [ALAC] Voting infrastructure rules
by Alan Greenberg Feb. 1, 2013

Feb. 1, 2013

At 31/01/2013 06:14 PM, Dev Anand Teelucksingh wrote: >Comments inline > >On Thu, Jan 31, 2013 at 3:50 PM, Alan Greenberg ><alan.greenberg(a)mcgill.ca> wrote: > > In my mind, it is essential that we see who has voted and who has not. That > > allows regional people to make sure their ALAC members vote. > >It *is* essential. Absolutely. And that information is (and should be) >published AFTER the voting period has concluded. Not during the vote. You missed my point. This gives ALAC members an incentive to vote, and more important, it allows their regional colleagues to remind them when they have not done so. And when the vote is being proposed by someone (as many have by me), it allows that person to nudge ALAC members to ensure that the vote is as complete as possible, and the result gives a strong message from the ALAC. Alan

2 1