- At-Large - lists.icann.org

Re: [At-Large] .CO user confusion?
by Beau Brendler July 30, 2010

July 30, 2010

The front-end of Netcom.cm: https://www.netcom.cm/login.jsp Nice. Certificate's invalid, too. Yo, RBN! Pitch a tent! and are we shocked by: http://newsroom.mcafee.com/article_display.cfm?article_id=3600 Also, as for .co, what about consumers who might think it represents a variation on the .co(.uk) second-level domain? -----Original Message----- >From: Evan Leibovitch <evan(a)telly.org> >Sent: Jul 30, 2010 3:29 PM >To: At-Large Worldwide <at-large(a)atlarge-lists.icann.org> >Subject: Re: [At-Large] .CO user confusion? > >On 30 July 2010 15:00, Christopher Wilkinson <cw(a)christopherwilkinson.eu>wrote: > >> Oh! So we have passed without comment on .tv, .la, .to, .nu, no doubt among >> a few others, >> then why are we piling in on .co, now? >> >> >There are two quite distinct issues mentioned in this thread: > >The issue of .co being more confused with .com than other TLDs doesn't >concern me. > >The other topic raised concerns ccTLDs acting like gTLDs without bearing the >obligations of gTLDs (and more generally, my observation that the CCs appear >to exist in a parallel universe, being involved with ICANN when it suits >them and thumbing their nose at ICANN when there's the least irritation). >This has been a constant source of concern to me, and is no stronger or >weaker because of the action of .CO (and less recently, .ME, and other >others before it). > >The seeds of today's situation were planted long before the start of my >involvement with ICANN, and I can't speak of why the public advocates of the >day didn't press the issue back then. To me, this particular point of real >unfairness seems like one of the nastier of ICANN's many unspoken issues. >And indeed, here is Christopher objecting to the very discussion of the >issue -- I consider that truly offensive. > >The fact that a poor state of affairs was allowed to happen in the past does >not make the situation less poor now. And it certainly does not give anyone >the right to object to the mere discussion of the how bad it is, simply >because it wasn't discussed before. > >- Evan >_______________________________________________ >At-Large mailing list >At-Large(a)atlarge-lists.icann.org >http://atlarge-lists.icann.org/mailman/listinfo/at-large_atlarge-lists.ican… > >At-Large Official Site: http://atlarge.icann.org

1 0

Weekly posting summary for at-large@atlarge-lists.icann.org
by Thomas Narten July 30, 2010

July 30, 2010

Total of 39 messages in the last 7 days. script run at: Fri Jul 30 00:53:03 EDT 2010 Messages | Bytes | Who --------+------+--------+----------+------------------------ 20.51% | 8 | 27.37% | 91670 | alan.greenberg at mcgill.ca 15.38% | 6 | 10.11% | 33850 | johnl at iecc.com 10.26% | 4 | 10.91% | 36540 | carlton.samuels at gmail.com 7.69% | 3 | 12.68% | 42481 | jam at jacquelinemorris.com 7.69% | 3 | 5.86% | 19638 | karl at cavebear.com 7.69% | 3 | 5.35% | 17927 | icann-list at sorehands.com 2.56% | 1 | 6.24% | 20898 | carlosaguirre62 at hotmail.com 5.13% | 2 | 3.22% | 10787 | narten at us.ibm.com 2.56% | 1 | 2.80% | 9366 | sebastien at bachollet.com 2.56% | 1 | 2.44% | 8171 | langdonorr at gmail.com 2.56% | 1 | 2.06% | 6893 | evan at telly.org 2.56% | 1 | 2.00% | 6713 | michele at blacknight.ie 2.56% | 1 | 2.00% | 6696 | ymshana2003 at hotmail.com 2.56% | 1 | 1.82% | 6086 | jmamodio at gmail.com 2.56% | 1 | 1.76% | 5912 | ocl at gih.com 2.56% | 1 | 1.74% | 5830 | roberto at icann.org 2.56% | 1 | 1.65% | 5518 | manuel.schneider at wikimedia.ch --------+------+--------+----------+------------------------ 100.00% | 39 |100.00% | 334976 | Total

1 0

Re: [At-Large] Post-Expiration Domain Name Recovery
by Alan Greenberg July 27, 2010

July 27, 2010

Not disagreeing with any of that, but I think that we are starting to get into the business model of various registrars. Mark Monitor, that handles corporate registrations, will take quite different actions to ensure that .IBM (or whatever) does not expire compared to a reseller who gives away domain names free with a $5.95 per month web hosting agreement. GoDaddy has about 25,000,000 .com domains. Assuming even 15,000,000 are renewed annually, that means there are 40,000 expirations per day. Even if only a small percentage are not renewed on time, I am guessing that they are not likely to make phone calls for too many of them. Unless of course there is an added fee for that. Alan At 27/07/2010 01:03 PM, Jacqueline Morris wrote: >Maybe a lowest common denominator - at least 60 days, 45 days, 30 >days etc to the registration email. For business, they MAY choose to >follow up with registered mail or a notification phone call, and/or >send email to the contact info on the website if there is a website on >the domain? > >Jacqueline A. Morris >Technology should be like oxygen: Ubiquitous, Necessary, Invisible. > > > > >On Tue, Jul 27, 2010 at 12:09 PM, Alan Greenberg ><alan.greenberg(a)mcgill.ca> wrote: > > At 27/07/2010 11:41 AM, Carlton Samuels wrote: > >> > >> Jacqueline has fingered one - and only one - real reason for PEDNR snafus > >> and even suggest a response to mitigate. > >> > >> The location of the 'parked page' is the critical issue since it is not > >> so > >> much the message but delivery of the message; whether the registrant 'see' > >> the message about imminent expiration. > >> > >> And even with assured delivery, we cannot assume action. What I would > >> like > >> to see is some mechanism for assured delivery of the expiry message. > > > > Problem is, today the registrar is not even obliged to tell you how they > > will notify you. That is the meaning of the request for clarity with regard > > to delivery methods. It is probably not practical that the RAA specify the > > exact form of communications, since that may change over time and may vary > > based on the registrar business model. > > > > Alan > > > > > >> Carlton > >> > >> ============================== > >> Carlton A Samuels > >> Mobile: 876-818-1799 > >> Strategy, Planning, Governance, Assessment & Turnaround > >> ============================= > >> > >> > >> On Tue, Jul 27, 2010 at 10:24 AM, Jacqueline Morris < > >> jam(a)jacquelinemorris.com> wrote: > >> > >> > Maybe the parked page should indicate that the domain has expired and > >> > give information to the registrant as to how to renew. > >> > One thing that I have experienced often is that small businesses in > >> > particular hire fly-by-night web developers to set up their domain, > >> > email etc., and often the developer moves on, thecontract ends, or > >> > s/he disappears. The client has no idea what is going on, and the > >> > notifications go to the developer's email, and are not forwarded to > >> > the business. > >> > One day the whole thing shuts down. If the parking page indicates > >> > what is going on, the client has an opportunity (if the domain is > >> > actually registered in their name, and not the developer's) to renew, > >> > or try to get in touch with the developer or even register a new > >> > domain and transfer their services (but a lot wiser than the first > >> > time...) > >> > Otherwise they have no idea what is going on... unless they find a > >> > consultant who can help them. > >> > > >> > Jacqueline A. Morris > >> > Technology should be like oxygen: Ubiquitous, Necessary, Invisible. > >> > > >> > > >> > > >> > > >> > On Tue, Jul 27, 2010 at 8:57 AM, Alan Greenberg > >> > <alan.greenberg(a)mcgill.ca> wrote: > >> > > At 27/07/2010 08:28 AM, Jacqueline Morris wrote: > >> > >> > >> > >> Hi > >> > >> Re Sebastien's points - > >> > >> 1) If there have been many notifications via email, phone or letter > >> > >> at > >> > >> least 60 days IN ADVANCE, then it's fine to shut down port 80 on > >> > >> expiration > >> > > > >> > > Note that this is what virtually every registrar does not - to put up > >> > their > >> > > own parked page. > >> > > > >> > >> 2) I agree with shutting down all services including email IF there > >> > >> is > >> > >> a requirement for an alternative email address (not at the domain > >> > >> that > >> > >> is being registered) at registration time, and that email address > >> > >> needs to be kept current by the registrant. It certainly would not > >> > >> make sense to send notices or information on expiry to an email > >> > >> address at a domain that has expired! > >> > > > >> > > I think that this is a good recommendation, but to make it an absolute > >> > > requirement is not likely possible. It would be mind-bogling to a > >> > innocent > >> > > first time user who is just trying to get a blogging/web site up and > >> > chances > >> > > are that if they go out and et a hotmail account for the purposes they > >> > will > >> > > never look at it. > >> > > > >> > > > >> > >> Jacqueline A. Morris > >> > >> Technology should be like oxygen: Ubiquitous, Necessary, Invisible. > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> On Tue, Jul 27, 2010 at 2:50 AM, Sébastien Bachollet > >> > >> <sebastien(a)bachollet.com> wrote: > >> > >> > Thanks Alan, Hello all, > >> > >> > Please find my ideas on the propose text bellow. > >> > >> > All the best > >> > >> > > >> > >> > Sébastien Bachollet > >> > >> > sebastien(a)bachollet.com > >> > >> > +33 6 07 66 89 33 > >> > >> > > >> > >> > > >> > >> >> -----Message d'origine----- > >> > >> >> De : at-large-bounces(a)atlarge-lists.icann.org [mailto:at-large- > >> > >> >> bounces(a)atlarge-lists.icann.org] De la part de Alan Greenberg > >> > >> >> Envoyé : lundi 26 juillet 2010 21:12 > >> > >> >> À : At-Large Worldwide > >> > >> >> Objet : [At-Large] Post-Expiration Domain Name Recovery > >> > >> >> Importance : Haute > >> > >> >> > >> > >> >> The Post-Expiration Domain Name Recovery PDP has posted their > >> > >> >> Initial > >> > >> >> Report. You will recall that the PDP was initiated by an ALAC > >> > >> >> Request > >> > >> >> for Issues Report. The Public Comment Period is open at > >> > >> >> http://icann.org/en/public-comment/#pednr-initial-report. It is > >> > >> >> scheduled to close on August 1, but hopefully it will be extended. > >> > >> >> > >> > >> >> An ALAC comment on this report has been drafted. It can be found > >> > >> >> at > >> > >> >> https://st.icann.org/gnso- > >> > >> >> liaison/index.cgi?at_large_gnso_liaison#pednr. > >> > >> >> It is also reproduced below for your convenience. The comment will > >> > >> >> be > >> > >> >> discussed and possibly endorsed at the 27 July ALAC meeting. The > >> > >> >> comment follows the expected outcomes outlined in the initial > >> > >> >> Request > >> > >> >> for Issues Report and also is in line with the views of the > >> > >> >> majority > >> > >> >> of At-Large participants in the Working Group. > >> > >> >> > >> > >> >> For PEDNR, the Public Comment process features an easy-to-complete > >> > >> >> survey. Since this policy development process was initiated by > >> > >> >> At-Large, it is REALLY important that as many At-Large people as > >> > >> >> possible complete the survey. > >> > >> >> > >> > >> >> PLEASE: > >> > >> >> > >> > >> >> - Review the comments below to see the At-Large position; > >> > >> >> - If you have the time, review the Initial Report; > >> > >> >> - Complete the short survey (it can be done without reading the > >> > >> >> full > >> > >> >> report). The survey is at > >> > >> >> <http://www.zoomerang.com/Survey/WEB22AUYRGHCV4> > >> > http://www.zoomerang.co > >> > >> >> m/Survey/WEB22AUYRGHCV4. > >> > >> >> > >> > >> >> Alan > >> > >> >> > >> > >> >> -------------------------------------- > >> > >> >> > >> > >> >> The At-Large Advisory Committee (ALAC) requested the Issues Report > >> > >> >> which resulted in the Post-Expiration Domain Name Recovery PDP, > >> > >> >> and > >> > >> >> it strongly supports the activities of the Working Group. > >> > >> >> > >> > >> >> It is essential that the post-expiration "safety net" that existed > >> > >> >> several years ago be restored. Moreover, the domain industry is > >> > >> >> sufficiently robust and mature that it can and must provide a > >> > >> >> level > >> > >> >> of predictability and security to gTLD domain name holders. > >> > >> >> > >> > >> >> In line with the desired outcomes stated in the original Issue > >> > >> >> Report > >> > >> >> request, the ALAC supports: > >> > >> >> > >> > >> >> 1. Consensus policy requiring that all registrars must allow > >> > >> >> renewal of domain names for a reasonable amount of time after > >> > >> >> expiration. > >> > >> >> 2. Consensus policy explicitly stating the minimum > >> > >> >> requirements > >> > >> >> for pre-expiration notices. > >> > >> >> 3. Consensus policy requiring clarity of how messages will be > >> > >> >> sent. > >> > >> >> 4. Consensus policy requiring that WHOIS contents to make it > >> > >> >> clear that a domain name has expired and has not yet been renewed > >> > >> >> by > >> > >> >> the registrant. > >> > >> > [SBT] Here I am questioning how this can be gamed. The risk is that > >> > the > >> > >> > end-user will received proposal for other (registrars, > >> > >> > resellers...) > >> > and > >> > >> > put > >> > >> > more question than solution to him. > >> > >> >> 5. Consensus policy requiring that notice(s) be sent after > >> > >> >> expiration. > >> > >> >> 6. Consensus policy requiring that web sites (port 80) no > >> > >> >> longer > >> > >> >> can resolve to the original web site after expiration. > >> > >> > [SBT] I don't think it is the best way to re-inform an end-user > >> > >> > that > >> > the > >> > >> > DN > >> > >> > has expired. It will create more problem than solution. I am in > >> > >> > favor > >> > of > >> > >> > using all the other possibilities (e-mail, postal mail, phone) but > >> > >> > not > >> > >> > to > >> > >> > stop any service. > >> > >> >> 7. Consensus policy requiring that other uses of the domain > >> > >> >> name > >> > >> >> (e-mail, FTP, etc.) no longer function after expiration. > >> > >> > [SBT] Idem than 6 - for e-mail more specifically, because we are > >> > >> > sure > >> > >> > then > >> > >> > that he will not be able to received update from the registrar and > >> > >> > the > >> > >> > registry and will not be able to interact with them. > >> > >> >> 8. Consensus policy requiring clarity in the expiration terms > >> > >> >> and fees offered by registrars. > >> > >> >> 9. Consensus policy requiring that the Redemption Grace > >> > >> >> Period > >> > >> >> be offered by all registries (including future gTLDs) and by all > >> > >> >> registrars. > >> > >> >> > >> > >> >> It is understood that there may be unusual cases where the > >> > >> >> business > >> > >> >> models of some registrars may require exceptions to some of these > >> > >> >> policies. However, the need for such exceptions should not deny > >> > >> >> the > >> > >> >> vast majority of registrants a predictable and safe gTLD > >> > >> >> eco-system. > >> > >> >> > >> > >> >> Over and above these minimum requirements, the ALAC supports a > >> > >> >> move > >> > >> >> within the registrar community to establish the meaningful and > >> > >> >> transparent concept of "best practices". > >> > >> >> _______________________________________________ > >> > >> >> At-Large mailing list > >> > >> >> At-Large(a)atlarge-lists.icann.org > >> > >> >> http://atlarge-lists.icann.org/mailman/listinfo/at-large_atlarge- > >> > >> >> lists.icann.org > >> > >> >> > >> > >> >> At-Large Official Site: http://atlarge.icann.org > >> > >> > > >> > >> > > >> > >> > _______________________________________________ > >> > >> > At-Large mailing list > >> > >> > At-Large(a)atlarge-lists.icann.org > >> > >> > > >> > >> > > >> > > >> > > http://atlarge-lists.icann.org/mailman/listinfo/at-large_atlarge-lists.ican… > >> > >> > > >> > >> > At-Large Official Site: http://atlarge.icann.org > >> > >> > > >> > >> > >> > >> _______________________________________________ > >> > >> At-Large mailing list > >> > >> At-Large(a)atlarge-lists.icann.org > >> > >> > >> > >> > >> > > >> > > http://atlarge-lists.icann.org/mailman/listinfo/at-large_atlarge-lists.ican… > >> > >> > >> > >> At-Large Official Site: http://atlarge.icann.org > >> > > > >> > > > >> > > _______________________________________________ > >> > > At-Large mailing list > >> > > At-Large(a)atlarge-lists.icann.org > >> > > > >> > > >> > > http://atlarge-lists.icann.org/mailman/listinfo/at-large_atlarge-lists.ican… > >> > > > >> > > At-Large Official Site: http://atlarge.icann.org > >> > > > >> > > >> > _______________________________________________ > >> > At-Large mailing list > >> > At-Large(a)atlarge-lists.icann.org > >> > > >> > > >> > > http://atlarge-lists.icann.org/mailman/listinfo/at-large_atlarge-lists.ican… > >> > > >> > At-Large Official Site: http://atlarge.icann.org > >> > > >> _______________________________________________ > >> At-Large mailing list > >> At-Large(a)atlarge-lists.icann.org > >> > >> > http://atlarge-lists.icann.org/mailman/listinfo/at-large_atlarge-lists.ican… > >> > >> At-Large Official Site: http://atlarge.icann.org > > > > > > _______________________________________________ > > At-Large mailing list > > At-Large(a)atlarge-lists.icann.org > > > http://atlarge-lists.icann.org/mailman/listinfo/at-large_atlarge-lists.ican… > > > > At-Large Official Site: http://atlarge.icann.org > > > >_______________________________________________ >At-Large mailing list >At-Large(a)atlarge-lists.icann.org >http://atlarge-lists.icann.org/mailman/listinfo/at-large_atlarge-lists.ican… > >At-Large Official Site: http://atlarge.icann.org

1 0

Re: [At-Large] Post-Expiration Domain Name Recovery
by Alan Greenberg July 27, 2010

July 27, 2010

At 27/07/2010 11:41 AM, Carlton Samuels wrote: >Jacqueline has fingered one - and only one - real reason for PEDNR snafus >and even suggest a response to mitigate. > > The location of the 'parked page' is the critical issue since it is not so >much the message but delivery of the message; whether the registrant 'see' >the message about imminent expiration. > >And even with assured delivery, we cannot assume action. What I would like >to see is some mechanism for assured delivery of the expiry message. Problem is, today the registrar is not even obliged to tell you how they will notify you. That is the meaning of the request for clarity with regard to delivery methods. It is probably not practical that the RAA specify the exact form of communications, since that may change over time and may vary based on the registrar business model. Alan >Carlton > >============================== >Carlton A Samuels >Mobile: 876-818-1799 >Strategy, Planning, Governance, Assessment & Turnaround >============================= > > >On Tue, Jul 27, 2010 at 10:24 AM, Jacqueline Morris < >jam(a)jacquelinemorris.com> wrote: > > > Maybe the parked page should indicate that the domain has expired and > > give information to the registrant as to how to renew. > > One thing that I have experienced often is that small businesses in > > particular hire fly-by-night web developers to set up their domain, > > email etc., and often the developer moves on, thecontract ends, or > > s/he disappears. The client has no idea what is going on, and the > > notifications go to the developer's email, and are not forwarded to > > the business. > > One day the whole thing shuts down. If the parking page indicates > > what is going on, the client has an opportunity (if the domain is > > actually registered in their name, and not the developer's) to renew, > > or try to get in touch with the developer or even register a new > > domain and transfer their services (but a lot wiser than the first > > time...) > > Otherwise they have no idea what is going on... unless they find a > > consultant who can help them. > > > > Jacqueline A. Morris > > Technology should be like oxygen: Ubiquitous, Necessary, Invisible. > > > > > > > > > > On Tue, Jul 27, 2010 at 8:57 AM, Alan Greenberg > > <alan.greenberg(a)mcgill.ca> wrote: > > > At 27/07/2010 08:28 AM, Jacqueline Morris wrote: > > >> > > >> Hi > > >> Re Sebastien's points - > > >> 1) If there have been many notifications via email, phone or letter at > > >> least 60 days IN ADVANCE, then it's fine to shut down port 80 on > > >> expiration > > > > > > Note that this is what virtually every registrar does not - to put up > > their > > > own parked page. > > > > > >> 2) I agree with shutting down all services including email IF there is > > >> a requirement for an alternative email address (not at the domain that > > >> is being registered) at registration time, and that email address > > >> needs to be kept current by the registrant. It certainly would not > > >> make sense to send notices or information on expiry to an email > > >> address at a domain that has expired! > > > > > > I think that this is a good recommendation, but to make it an absolute > > > requirement is not likely possible. It would be mind-bogling to a > > innocent > > > first time user who is just trying to get a blogging/web site up and > > chances > > > are that if they go out and et a hotmail account for the purposes they > > will > > > never look at it. > > > > > > > > >> Jacqueline A. Morris > > >> Technology should be like oxygen: Ubiquitous, Necessary, Invisible. > > >> > > >> > > >> > > >> > > >> On Tue, Jul 27, 2010 at 2:50 AM, Sébastien Bachollet > > >> <sebastien(a)bachollet.com> wrote: > > >> > Thanks Alan, Hello all, > > >> > Please find my ideas on the propose text bellow. > > >> > All the best > > >> > > > >> > Sébastien Bachollet > > >> > sebastien(a)bachollet.com > > >> > +33 6 07 66 89 33 > > >> > > > >> > > > >> >> -----Message d'origine----- > > >> >> De : at-large-bounces(a)atlarge-lists.icann.org [mailto:at-large- > > >> >> bounces(a)atlarge-lists.icann.org] De la part de Alan Greenberg > > >> >> Envoyé : lundi 26 juillet 2010 21:12 > > >> >> À : At-Large Worldwide > > >> >> Objet : [At-Large] Post-Expiration Domain Name Recovery > > >> >> Importance : Haute > > >> >> > > >> >> The Post-Expiration Domain Name Recovery PDP has posted their Initial > > >> >> Report. You will recall that the PDP was initiated by an ALAC Request > > >> >> for Issues Report. The Public Comment Period is open at > > >> >> http://icann.org/en/public-comment/#pednr-initial-report. It is > > >> >> scheduled to close on August 1, but hopefully it will be extended. > > >> >> > > >> >> An ALAC comment on this report has been drafted. It can be found at > > >> >> https://st.icann.org/gnso- > > >> >> liaison/index.cgi?at_large_gnso_liaison#pednr. > > >> >> It is also reproduced below for your convenience. The comment will be > > >> >> discussed and possibly endorsed at the 27 July ALAC meeting. The > > >> >> comment follows the expected outcomes outlined in the initial Request > > >> >> for Issues Report and also is in line with the views of the majority > > >> >> of At-Large participants in the Working Group. > > >> >> > > >> >> For PEDNR, the Public Comment process features an easy-to-complete > > >> >> survey. Since this policy development process was initiated by > > >> >> At-Large, it is REALLY important that as many At-Large people as > > >> >> possible complete the survey. > > >> >> > > >> >> PLEASE: > > >> >> > > >> >> - Review the comments below to see the At-Large position; > > >> >> - If you have the time, review the Initial Report; > > >> >> - Complete the short survey (it can be done without reading the full > > >> >> report). The survey is at > > >> >> <http://www.zoomerang.com/Survey/WEB22AUYRGHCV4> > > http://www.zoomerang.co > > >> >> m/Survey/WEB22AUYRGHCV4. > > >> >> > > >> >> Alan > > >> >> > > >> >> -------------------------------------- > > >> >> > > >> >> The At-Large Advisory Committee (ALAC) requested the Issues Report > > >> >> which resulted in the Post-Expiration Domain Name Recovery PDP, and > > >> >> it strongly supports the activities of the Working Group. > > >> >> > > >> >> It is essential that the post-expiration "safety net" that existed > > >> >> several years ago be restored. Moreover, the domain industry is > > >> >> sufficiently robust and mature that it can and must provide a level > > >> >> of predictability and security to gTLD domain name holders. > > >> >> > > >> >> In line with the desired outcomes stated in the original Issue Report > > >> >> request, the ALAC supports: > > >> >> > > >> >> 1. Consensus policy requiring that all registrars must allow > > >> >> renewal of domain names for a reasonable amount of time after > > >> >> expiration. > > >> >> 2. Consensus policy explicitly stating the minimum requirements > > >> >> for pre-expiration notices. > > >> >> 3. Consensus policy requiring clarity of how messages will be > > >> >> sent. > > >> >> 4. Consensus policy requiring that WHOIS contents to make it > > >> >> clear that a domain name has expired and has not yet been renewed by > > >> >> the registrant. > > >> > [SBT] Here I am questioning how this can be gamed. The risk is that > > the > > >> > end-user will received proposal for other (registrars, resellers...) > > and > > >> > put > > >> > more question than solution to him. > > >> >> 5. Consensus policy requiring that notice(s) be sent after > > >> >> expiration. > > >> >> 6. Consensus policy requiring that web sites (port 80) no longer > > >> >> can resolve to the original web site after expiration. > > >> > [SBT] I don't think it is the best way to re-inform an end-user that > > the > > >> > DN > > >> > has expired. It will create more problem than solution. I am in favor > > of > > >> > using all the other possibilities (e-mail, postal mail, phone) but not > > >> > to > > >> > stop any service. > > >> >> 7. Consensus policy requiring that other uses of the domain name > > >> >> (e-mail, FTP, etc.) no longer function after expiration. > > >> > [SBT] Idem than 6 - for e-mail more specifically, because we are sure > > >> > then > > >> > that he will not be able to received update from the registrar and the > > >> > registry and will not be able to interact with them. > > >> >> 8. Consensus policy requiring clarity in the expiration terms > > >> >> and fees offered by registrars. > > >> >> 9. Consensus policy requiring that the Redemption Grace Period > > >> >> be offered by all registries (including future gTLDs) and by all > > >> >> registrars. > > >> >> > > >> >> It is understood that there may be unusual cases where the business > > >> >> models of some registrars may require exceptions to some of these > > >> >> policies. However, the need for such exceptions should not deny the > > >> >> vast majority of registrants a predictable and safe gTLD eco-system. > > >> >> > > >> >> Over and above these minimum requirements, the ALAC supports a move > > >> >> within the registrar community to establish the meaningful and > > >> >> transparent concept of "best practices". > > >> >> _______________________________________________ > > >> >> At-Large mailing list > > >> >> At-Large(a)atlarge-lists.icann.org > > >> >> http://atlarge-lists.icann.org/mailman/listinfo/at-large_atlarge- > > >> >> lists.icann.org > > >> >> > > >> >> At-Large Official Site: http://atlarge.icann.org > > >> > > > >> > > > >> > _______________________________________________ > > >> > At-Large mailing list > > >> > At-Large(a)atlarge-lists.icann.org > > >> > > > >> > > > > http://atlarge-lists.icann.org/mailman/listinfo/at-large_atlarge-lists.ican… > > >> > > > >> > At-Large Official Site: http://atlarge.icann.org > > >> > > > >> > > >> _______________________________________________ > > >> At-Large mailing list > > >> At-Large(a)atlarge-lists.icann.org > > >> > > >> > > > http://atlarge-lists.icann.org/mailman/listinfo/at-large_atlarge-lists.ican… > > >> > > >> At-Large Official Site: http://atlarge.icann.org > > > > > > > > > _______________________________________________ > > > At-Large mailing list > > > At-Large(a)atlarge-lists.icann.org > > > > > > http://atlarge-lists.icann.org/mailman/listinfo/at-large_atlarge-lists.ican… > > > > > > At-Large Official Site: http://atlarge.icann.org > > > > > > > _______________________________________________ > > At-Large mailing list > > At-Large(a)atlarge-lists.icann.org > > > > > http://atlarge-lists.icann.org/mailman/listinfo/at-large_atlarge-lists.ican… > > > > At-Large Official Site: http://atlarge.icann.org > > >_______________________________________________ >At-Large mailing list >At-Large(a)atlarge-lists.icann.org >http://atlarge-lists.icann.org/mailman/listinfo/at-large_atlarge-lists.ican… > >At-Large Official Site: http://atlarge.icann.org

2 1

Re: [At-Large] Post-Expiration Domain Name Recovery
by Alan Greenberg July 27, 2010

July 27, 2010

At 27/07/2010 11:24 AM, Jacqueline Morris wrote: >Maybe the parked page should indicate that the domain has expired and >give information to the registrant as to how to renew. Completely agree. That is one of the prime recommendations. Many but not all registrars already do this. >One thing that I have experienced often is that small businesses in >particular hire fly-by-night web developers to set up their domain, >email etc., and often the developer moves on, thecontract ends, or >s/he disappears. The client has no idea what is going on, and the >notifications go to the developer's email, and are not forwarded to >the business. > One day the whole thing shuts down. If the parking page indicates >what is going on, the client has an opportunity (if the domain is >actually registered in their name, and not the developer's) to renew, >or try to get in touch with the developer or even register a new >domain and transfer their services (but a lot wiser than the first >time...) >Otherwise they have no idea what is going on... unless they find a >consultant who can help them. Good example. And that is the type of case where shutting down is the ONLY way to get the registrant's attention. So it is important to do it while there is still an opportunity to get the name renewed or redeemed. Of course, if the domain is still in the name of the developer or web host (as is often the case), there will not be much that the users of the domain name can do. But we cannot address all of the ills in the world. Alan >Jacqueline A. Morris >Technology should be like oxygen: Ubiquitous, Necessary, Invisible. > > > > >On Tue, Jul 27, 2010 at 8:57 AM, Alan Greenberg ><alan.greenberg(a)mcgill.ca> wrote: > > At 27/07/2010 08:28 AM, Jacqueline Morris wrote: > >> > >> Hi > >> Re Sebastien's points - > >> 1) If there have been many notifications via email, phone or letter at > >> least 60 days IN ADVANCE, then it's fine to shut down port 80 on > >> expiration > > > > Note that this is what virtually every registrar does not - to put up their > > own parked page. > > > >> 2) I agree with shutting down all services including email IF there is > >> a requirement for an alternative email address (not at the domain that > >> is being registered) at registration time, and that email address > >> needs to be kept current by the registrant. It certainly would not > >> make sense to send notices or information on expiry to an email > >> address at a domain that has expired! > > > > I think that this is a good recommendation, but to make it an absolute > > requirement is not likely possible. It would be mind-bogling to a innocent > > first time user who is just trying to get a > blogging/web site up and chances > > are that if they go out and et a hotmail account for the purposes they will > > never look at it. > > > > > >> Jacqueline A. Morris > >> Technology should be like oxygen: Ubiquitous, Necessary, Invisible. > >> > >> > >> > >> > >> On Tue, Jul 27, 2010 at 2:50 AM, Sébastien Bachollet > >> <sebastien(a)bachollet.com> wrote: > >> > Thanks Alan, Hello all, > >> > Please find my ideas on the propose text bellow. > >> > All the best > >> > > >> > Sébastien Bachollet > >> > sebastien(a)bachollet.com > >> > +33 6 07 66 89 33 > >> > > >> > > >> >> -----Message d'origine----- > >> >> De : at-large-bounces(a)atlarge-lists.icann.org [mailto:at-large- > >> >> bounces(a)atlarge-lists.icann.org] De la part de Alan Greenberg > >> >> Envoyé : lundi 26 juillet 2010 21:12 > >> >> À : At-Large Worldwide > >> >> Objet : [At-Large] Post-Expiration Domain Name Recovery > >> >> Importance : Haute > >> >> > >> >> The Post-Expiration Domain Name Recovery PDP has posted their Initial > >> >> Report. You will recall that the PDP was initiated by an ALAC Request > >> >> for Issues Report. The Public Comment Period is open at > >> >> http://icann.org/en/public-comment/#pednr-initial-report. It is > >> >> scheduled to close on August 1, but hopefully it will be extended. > >> >> > >> >> An ALAC comment on this report has been drafted. It can be found at > >> >> https://st.icann.org/gnso- > >> >> liaison/index.cgi?at_large_gnso_liaison#pednr. > >> >> It is also reproduced below for your convenience. The comment will be > >> >> discussed and possibly endorsed at the 27 July ALAC meeting. The > >> >> comment follows the expected outcomes outlined in the initial Request > >> >> for Issues Report and also is in line with the views of the majority > >> >> of At-Large participants in the Working Group. > >> >> > >> >> For PEDNR, the Public Comment process features an easy-to-complete > >> >> survey. Since this policy development process was initiated by > >> >> At-Large, it is REALLY important that as many At-Large people as > >> >> possible complete the survey. > >> >> > >> >> PLEASE: > >> >> > >> >> - Review the comments below to see the At-Large position; > >> >> - If you have the time, review the Initial Report; > >> >> - Complete the short survey (it can be done without reading the full > >> >> report). The survey is at > >> >> <http://www.zoomerang.com/Survey/WEB22AUYRGHCV4>http://www.zoomerang.co > >> >> m/Survey/WEB22AUYRGHCV4. > >> >> > >> >> Alan > >> >> > >> >> -------------------------------------- > >> >> > >> >> The At-Large Advisory Committee (ALAC) requested the Issues Report > >> >> which resulted in the Post-Expiration Domain Name Recovery PDP, and > >> >> it strongly supports the activities of the Working Group. > >> >> > >> >> It is essential that the post-expiration "safety net" that existed > >> >> several years ago be restored. Moreover, the domain industry is > >> >> sufficiently robust and mature that it can and must provide a level > >> >> of predictability and security to gTLD domain name holders. > >> >> > >> >> In line with the desired outcomes stated in the original Issue Report > >> >> request, the ALAC supports: > >> >> > >> >> 1. Consensus policy requiring that all registrars must allow > >> >> renewal of domain names for a reasonable amount of time after > >> >> expiration. > >> >> 2. Consensus policy explicitly stating the minimum requirements > >> >> for pre-expiration notices. > >> >> 3. Consensus policy requiring clarity of how messages will be > >> >> sent. > >> >> 4. Consensus policy requiring that WHOIS contents to make it > >> >> clear that a domain name has expired and has not yet been renewed by > >> >> the registrant. > >> > [SBT] Here I am questioning how this can be gamed. The risk is that the > >> > end-user will received proposal for other (registrars, resellers...) and > >> > put > >> > more question than solution to him. > >> >> 5. Consensus policy requiring that notice(s) be sent after > >> >> expiration. > >> >> 6. Consensus policy requiring that web sites (port 80) no longer > >> >> can resolve to the original web site after expiration. > >> > [SBT] I don't think it is the best way to re-inform an end-user that the > >> > DN > >> > has expired. It will create more problem than solution. I am in favor of > >> > using all the other possibilities (e-mail, postal mail, phone) but not > >> > to > >> > stop any service. > >> >> 7. Consensus policy requiring that other uses of the domain name > >> >> (e-mail, FTP, etc.) no longer function after expiration. > >> > [SBT] Idem than 6 - for e-mail more specifically, because we are sure > >> > then > >> > that he will not be able to received update from the registrar and the > >> > registry and will not be able to interact with them. > >> >> 8. Consensus policy requiring clarity in the expiration terms > >> >> and fees offered by registrars. > >> >> 9. Consensus policy requiring that the Redemption Grace Period > >> >> be offered by all registries (including future gTLDs) and by all > >> >> registrars. > >> >> > >> >> It is understood that there may be unusual cases where the business > >> >> models of some registrars may require exceptions to some of these > >> >> policies. However, the need for such exceptions should not deny the > >> >> vast majority of registrants a predictable and safe gTLD eco-system. > >> >> > >> >> Over and above these minimum requirements, the ALAC supports a move > >> >> within the registrar community to establish the meaningful and > >> >> transparent concept of "best practices". > >> >> _______________________________________________ > >> >> At-Large mailing list > >> >> At-Large(a)atlarge-lists.icann.org > >> >> http://atlarge-lists.icann.org/mailman/listinfo/at-large_atlarge- > >> >> lists.icann.org > >> >> > >> >> At-Large Official Site: http://atlarge.icann.org > >> > > >> > > >> > _______________________________________________ > >> > At-Large mailing list > >> > At-Large(a)atlarge-lists.icann.org > >> > > >> > > http://atlarge-lists.icann.org/mailman/listinfo/at-large_atlarge-lists.ican… > >> > > >> > At-Large Official Site: http://atlarge.icann.org > >> > > >> > >> _______________________________________________ > >> At-Large mailing list > >> At-Large(a)atlarge-lists.icann.org > >> > >> > http://atlarge-lists.icann.org/mailman/listinfo/at-large_atlarge-lists.ican… > >> > >> At-Large Official Site: http://atlarge.icann.org > > > > > > _______________________________________________ > > At-Large mailing list > > At-Large(a)atlarge-lists.icann.org > > > http://atlarge-lists.icann.org/mailman/listinfo/at-large_atlarge-lists.ican… > > > > At-Large Official Site: http://atlarge.icann.org > > > >_______________________________________________ >At-Large mailing list >At-Large(a)atlarge-lists.icann.org >http://atlarge-lists.icann.org/mailman/listinfo/at-large_atlarge-lists.ican… > >At-Large Official Site: http://atlarge.icann.org

1 0

Re: [At-Large] Post-Expiration Domain Name Recovery
by Alan Greenberg July 27, 2010

July 27, 2010

At 27/07/2010 08:28 AM, Jacqueline Morris wrote: >Hi >Re Sebastien's points - >1) If there have been many notifications via email, phone or letter at >least 60 days IN ADVANCE, then it's fine to shut down port 80 on >expiration Note that this is what virtually every registrar does not - to put up their own parked page. >2) I agree with shutting down all services including email IF there is >a requirement for an alternative email address (not at the domain that >is being registered) at registration time, and that email address >needs to be kept current by the registrant. It certainly would not >make sense to send notices or information on expiry to an email >address at a domain that has expired! I think that this is a good recommendation, but to make it an absolute requirement is not likely possible. It would be mind-bogling to a innocent first time user who is just trying to get a blogging/web site up and chances are that if they go out and et a hotmail account for the purposes they will never look at it. >Jacqueline A. Morris >Technology should be like oxygen: Ubiquitous, Necessary, Invisible. > > > > >On Tue, Jul 27, 2010 at 2:50 AM, Sébastien Bachollet ><sebastien(a)bachollet.com> wrote: > > Thanks Alan, Hello all, > > Please find my ideas on the propose text bellow. > > All the best > > > > Sébastien Bachollet > > sebastien(a)bachollet.com > > +33 6 07 66 89 33 > > > > > >> -----Message d'origine----- > >> De : at-large-bounces(a)atlarge-lists.icann.org [mailto:at-large- > >> bounces(a)atlarge-lists.icann.org] De la part de Alan Greenberg > >> Envoyé : lundi 26 juillet 2010 21:12 > >> À : At-Large Worldwide > >> Objet : [At-Large] Post-Expiration Domain Name Recovery > >> Importance : Haute > >> > >> The Post-Expiration Domain Name Recovery PDP has posted their Initial > >> Report. You will recall that the PDP was initiated by an ALAC Request > >> for Issues Report. The Public Comment Period is open at > >> http://icann.org/en/public-comment/#pednr-initial-report. It is > >> scheduled to close on August 1, but hopefully it will be extended. > >> > >> An ALAC comment on this report has been drafted. It can be found at > >> https://st.icann.org/gnso- > >> liaison/index.cgi?at_large_gnso_liaison#pednr. > >> It is also reproduced below for your convenience. The comment will be > >> discussed and possibly endorsed at the 27 July ALAC meeting. The > >> comment follows the expected outcomes outlined in the initial Request > >> for Issues Report and also is in line with the views of the majority > >> of At-Large participants in the Working Group. > >> > >> For PEDNR, the Public Comment process features an easy-to-complete > >> survey. Since this policy development process was initiated by > >> At-Large, it is REALLY important that as many At-Large people as > >> possible complete the survey. > >> > >> PLEASE: > >> > >> - Review the comments below to see the At-Large position; > >> - If you have the time, review the Initial Report; > >> - Complete the short survey (it can be done without reading the full > >> report). The survey is at > >> <http://www.zoomerang.com/Survey/WEB22AUYRGHCV4>http://www.zoomerang.co > >> m/Survey/WEB22AUYRGHCV4. > >> > >> Alan > >> > >> -------------------------------------- > >> > >> The At-Large Advisory Committee (ALAC) requested the Issues Report > >> which resulted in the Post-Expiration Domain Name Recovery PDP, and > >> it strongly supports the activities of the Working Group. > >> > >> It is essential that the post-expiration "safety net" that existed > >> several years ago be restored. Moreover, the domain industry is > >> sufficiently robust and mature that it can and must provide a level > >> of predictability and security to gTLD domain name holders. > >> > >> In line with the desired outcomes stated in the original Issue Report > >> request, the ALAC supports: > >> > >> 1. Consensus policy requiring that all registrars must allow > >> renewal of domain names for a reasonable amount of time after > >> expiration. > >> 2. Consensus policy explicitly stating the minimum requirements > >> for pre-expiration notices. > >> 3. Consensus policy requiring clarity of how messages will be > >> sent. > >> 4. Consensus policy requiring that WHOIS contents to make it > >> clear that a domain name has expired and has not yet been renewed by > >> the registrant. > > [SBT] Here I am questioning how this can be gamed. The risk is that the > > end-user will received proposal for other > (registrars, resellers...) and put > > more question than solution to him. > >> 5. Consensus policy requiring that notice(s) be sent after > >> expiration. > >> 6. Consensus policy requiring that web sites (port 80) no longer > >> can resolve to the original web site after expiration. > > [SBT] I don't think it is the best way to re-inform an end-user that the DN > > has expired. It will create more problem than solution. I am in favor of > > using all the other possibilities (e-mail, postal mail, phone) but not to > > stop any service. > >> 7. Consensus policy requiring that other uses of the domain name > >> (e-mail, FTP, etc.) no longer function after expiration. > > [SBT] Idem than 6 - for e-mail more specifically, because we are sure then > > that he will not be able to received update from the registrar and the > > registry and will not be able to interact with them. > >> 8. Consensus policy requiring clarity in the expiration terms > >> and fees offered by registrars. > >> 9. Consensus policy requiring that the Redemption Grace Period > >> be offered by all registries (including future gTLDs) and by all > >> registrars. > >> > >> It is understood that there may be unusual cases where the business > >> models of some registrars may require exceptions to some of these > >> policies. However, the need for such exceptions should not deny the > >> vast majority of registrants a predictable and safe gTLD eco-system. > >> > >> Over and above these minimum requirements, the ALAC supports a move > >> within the registrar community to establish the meaningful and > >> transparent concept of "best practices". > >> _______________________________________________ > >> At-Large mailing list > >> At-Large(a)atlarge-lists.icann.org > >> http://atlarge-lists.icann.org/mailman/listinfo/at-large_atlarge- > >> lists.icann.org > >> > >> At-Large Official Site: http://atlarge.icann.org > > > > > > _______________________________________________ > > At-Large mailing list > > At-Large(a)atlarge-lists.icann.org > > > http://atlarge-lists.icann.org/mailman/listinfo/at-large_atlarge-lists.ican… > > > > At-Large Official Site: http://atlarge.icann.org > > > >_______________________________________________ >At-Large mailing list >At-Large(a)atlarge-lists.icann.org >http://atlarge-lists.icann.org/mailman/listinfo/at-large_atlarge-lists.ican… > >At-Large Official Site: http://atlarge.icann.org

3 2

Call for comments JAS WG
by carlos aguirre July 24, 2010

July 24, 2010

Dear At Large Community: As you know, many of ALAC and GNSO members are working hard in an issue very sensitive: New gTLD applicants support. (JAS) Working Group Carlos Dionisio Aguirre - ALAC Sébastien Bachollet - ALAC Tijani Ben Jemaa - At Large Fabien Betremieux - Individual - AFNIC Olga Cavalli - Nominating Committee Appointee Rafik Dammak - Non Commercial Stakeholder group Avri Doria - Non Commercial Stakeholder group William Drake - Non Commercial Stakeholder group Alex Gakuru - Non Commercial Stakeholder group Dr. Govind - GAC - India Alan Greenberg - ALAC Anthony Harris - Internet Service and Connectivity Providers Constituency Dave Kissoondoyal - At Large Evan Leibovitch - ALAC co-chair Andrew Mack - CBUC Michele Neylon - Registrar Stakeholder Group Cheryl Landon-Orr - ALAC Elaine Pruis - Individual Vanda Scartezini - Individual Baudouin Schombe - AFRALO - At large Alioune Traore - Individual Richard Tindal - Individual the idea born in Nairobi with the ICANN board resolution nº 20 http://www.icann.org/en/minutes/resolutions-12mar10-en.htm#20, and continue with the formation of the "Joint SO/AC New gTLD applicant support WG". Since last April we work in elaborate some recomendations in relation to this subject, and we presented our preliminaries views in Brussels (ppt in attachment), and we need in this moment your inputs, comment , impresions about our work in order to achieve a better result. I copy to you: JAS WG Charter (Approved by ALAC) and then, the recomendations made by the WT formed to make your comments. Thanks Carlos Dionisio Aguirre JAS WG ALAC Liaison ----------------------------------------- JAS WG Charter Chartered objectives for the Working Group: Preamble: The Joint SO/AC Working Group on New gTLD Applicant Support shall evaluate and propose recommendations regarding specific support to new gTLD applicants in justified cases. The working group expects to identify suitable criteria for provision of such support, to identify suitable support forms and to identify potential providers of such support. However, there is no presumption that the outcome will imply any particular governing structure. Accordingly, if the recommendations indicate that the preferred solutions are of a voluntary nature, the criteria and other provisions arrived at in line with the objectives below will solely serve as advice to the parties concerned. The objectives are not listed in any priority order. An overall consideration is that the outcomes of the WG should not lead to delays of the New gTLD process. Objective 1: To identify suitable criteria that new gTLD applicants must fulfill to qualify for dedicated support. The criteria may be different for different types of support identified in line with Objective 2 and 3 below. Objective 2: To identify how the application fee can be reduced and/or subsidized to accommodate applicants that fulfill appropriate criteria to qualify for this benefit, in keeping with the principle of full cost recovery of the application process costs. Objective 3: To identify what kinds of support (e.g. technical assistance, organizational assistance, financial assistance, fee reduction) and support timelines (e.g. support for the application period only, continuous support) are appropriate for new gTLD applicants fulfilling identified criteria. Objective 4: To identify potential providers of the identified kinds of support as well as appropriate mechanisms to enable support provisioning. (Objective 5: To identify conditions and mechanisms required to minimize the risk of inappropriate access to support. Agreed within WG) ---------------------------------------------- JAS Recommendations Brussels 6/10 Working Team 1 – Pricing Background Working Team 1 is tasked with meeting the Working Group's Charter Objective 2: To identify how the net cost to applicants that fulfill appropriate criteria can be reduced, in keeping with the principle of cost recovery. Process WT1 examined how the application fee has been constructed and explained/justified in the cost consideration documents (1) and the DAG4 in order to determine if there is any potential for requesting the fees be revisited for applicants that meet the established criteria. The WT suggests several options for financial support of applicants. The first two proposals appear to have consensus; the remaining proposals are still under discussion. The fee for applying for a new gTLD is US$185,000. The fee structure is divided as: 1. New gTLD Program Development Costs US$ 26,000 2. Fixed and variable Application evaluation costs - Predictable US$100,000 3. Risk/Contingency costs US$60,000 WT1 notes that the document New gTLD Program Explanatory Memorandum New gTLD Budget (2) indicates an expected net profit for the new gTLD program. Proposals The following suggestions have been formulated by WT1. 1. Waive the cost of Program Development (US$26K) for selected entities qualifying for financial assistance. especially since the development cost was designated for return to the ICANN reserve. It is common ICANN practice to reduce return to reserves in light of extenuating financial circumstances. We expect very few applicants (relative to the total number applying) to meet the criteria for assistance, so the financial burden of waiving these fees should be minimal. 2. Staggered Fees. Instead of paying the entire fee upon acceptance of the applications, applicants meeting the criteria established for support could pay the fees incrementally (perhaps following the refund schedule in reverse). Allowing an applicant to have a staggered fee payment schedule gives the applicant more time to raise money, and investors will be more likely to back an application that passes the initial evaluation. If the applicant does not proceed through the entire process, they are not "costing" ICANN the full projected amount, therefore cost recovery remains intact. 3. Auction Proceeds. Qualified applicants receive a partial refund from any auction proceeds (3 ) —for which they can repay any loans or invest into their registry, or the auction proceeds could be used to refill a disadvantaged applicant’s foundation fund. 4. Lower the Registry fixed fees due to ICANN. In lieu of the Registry-Level fixed fee of US$25,000 per calendar year (4 ), instead only charge the Registry-Level Transaction Fee of US$0.25 per initial or renewal domain name registration. An annual fee of US$25k to ICANN is a barrier to sustainability for an applicant representing a small community. Many TLDs pay much less to ICANN (if anything). If a minimum is absolutely required, then consider lowering this fee by 50% for qualified applicants. 5. Reconsider the Risk/Contingency cost per applicant (US$60k). The WT questions if ICANN really expects a total of US$30,000,000 (US$60k x 500 applications) in unknown or variable costs to surface. This fee could be reduced/excused for the applicants that meet the criteria established by the WG. 6. The Fixed/Variable cost of US$100,000 is based on the total cost of the previous round of applications, which the cost considerations document quantifies as US$1.8MM for all ten applications. This fee possibly includes costs associated with the conflict that arose from the rejection of the ".XXX" application, which remains unresolved. The fee of US$180,000 may have been significantly skewed by the long-term work required for .XXX. The actual evaluation and administrative costs for the other nine applications may have been considerably less than US$180,000 per piece. If this is the case, the US$100,000 fixed cost fee could be reduced for the applicants that meet the criteria established by the WG. WT1 is working with WT2 on identifying sources of funding for subsidizing the fees for qualified applicants. The WG suggests that an independent foundation be established, outside of ICANN structures, to assist applicants with funding. Working Team 2 – The Who and What of offering Assistance 1. Who should receive support? Key to making a support program work is the choice of recipients who might receive support . The Team agreed that this initial round would serve as a learning experience for the community, as a number of issues – demand, the amount and type of support resources available, and other issues – became apparent. However, given the desire to get the program working quickly as part of this next gTLD round which may start soon, Working Team 2 recommended that the initial focus in this first round of new applicants should be on finding a relatively limited, easily identifiable, and non-controversial set of potential applicants. This approach, described as a “walk before we try to run” approach, is not designed to include policy for every potential applicant, but only to help move the community forward as we learn. Based on these criteria, the Working Team recommended the following: a. Q: Who should be first in line for support? A: For the initial/pilot phase, the Working Team recommends targeting support to ethnic and linguistic communities (e.g. the Hausa community, Quechua speakers, Tamil speakers). These potential applicants have the benefits of being relatively well defined as groups, and pass the test of being generally non-controversial. Such communities already have a history of recognition at ICANN and facilitating community on the web is one of ICANN’s core values. However, this does not mean that ONLY ethnic and linguistic groups would be eligible, but rather that these groups should be considered first if there is adequate interest given that they are considered a positive good for the internet community and most closely fit the criteria above: § Limited in scope § Easily identifiable § Generally non-controversial b. Q: Can only applicants structured as NGOs receive support? A: No. While many groups receiving support might be structured as NGOs, applicants would not need to be non-profits, and could change their status over time in keeping with changing business and sustainability models. Some might start as non-profits but morph into hybrids or for-profits and others might be appropriate for-profit or hybrid applicants. It was agreed that the key issues in determining support such as contribution to the community, need, sustainability and the ability to reach underserved groups could potentially be achieved by applicants in a number of different organizational and juridical forms. c. Q: Should there be a regional preference for support? A: While there are groups in most regions that might merit support, given limited resources and the particular challenges faced in Emerging Markets, the Working Team recommended giving some preference to applicants geographically located in Emerging Markets/Developing countries and in languages whose presence on the web is limited, with some extra preference given to historically disadvantaged areas such as Africa where the new gTLD process is believed to be the most challenging. d. Q: Are there some groups for whom support was deemed inappropriate at this time? A: Yes. The Working Team agreed that some groups are not recommended for support at this point, specifically : · Applicants that don’t need the support/have ample financing · Applicants that are brands/groups that should be self-supporting companies · Applicants that are geographic names (such as .Paris and others) · Purely Government/parastatal applicants (though applicants with some Government support might be eligible) · Applicants whose business model doesn’t demonstrate sustainability 2. What kinds of support might be offered? The group recommended a number of different kinds of support that could be valuable for potential applicants, support which falls relatively neatly into three categories: a. Logistical, outreach and fee Support in the Application Process · Translation of relevant documents – a major concern noted by non-English speaking group members, who noted the extra time and effort needed to work in English · Logistical and technical help with the application process – including legal and filing support that are expensive and in short supply in most Emerging Markets nations · Awareness/outreach efforts – to make more people in underserved markets are aware of the gTLD process and what they can do to participate in the gTLD process · Fee reduction/subsidization and/or some sort of phased-in payment for deserving applicants – this discussion builds off of the work of Working Team 1, and includes two key ideas: o That deserving applicants might receive some reduced pricing in general o That some sort of phasing for payment might be appropriate, enabling selected applicants to effectively “pay as they go” for the application process rather than having all funds assembled up front b. Technical Support for Applicants in operating or qualifying to operate a gTLD · Infrastructure – providing IPv6 compatible hardware and networks as needed · Education/consulting – to help with DNSSEC implementation · Possible technical waivers or “step ups” – allowing applicants to build their capabilities rather than needing to demonstrate full capacity before applying (as appropriate) · Lower cost and/or shared back end registry services c. Support for Build-out in Underserved Languages and IDNs for new gTLDs · Price discounts to incentivize gTLD build-out in scripts which currently have a limited presence on the web, as a way to bolster multilingual, multi-script content and limit the digital divide · Incentivizing an expansion of IDN content through “Bundled pricing” – enabling applicants willing to build out in numerous scripts at once to get a “bundled price”, making it economically viable to get more scripts on the web · Clear tests to prevent gaming and ensure that support reaches its targets 3. Other recommendations? The Working Team also discussed a series of “principles” that are recommended to guide the community as the support process is finalized, namely: a. Self-Financing responsibility – ICANN/community support should comprise not significantly more than 50% of the total cost of an application. The WG saw this as a good way to encourage accountability and sustainability. b. Sunset period – Support should have an agreed cut-off/sunset point, perhaps 5 years, after which no further support would be offered. This was recommended as another measure to promote sustainability and as a way to help limited resources reach more applicants. c. Transparency – Support requests and levels should be made public to encourage transparency. d. Limited Government support – The receipt of some support from government(s) should not disqualify a community applicant from receiving gTLD support. However, the process is not designed to subsidize government-led initiatives. e. Repayment in success cases – In cases where supported gTLDs make money significantly above and beyond the level support received through this process, recipients would agree to re-pay/rebate application subsidies into a revolving fund to support future applications. Additional Questions and Possible Responses: Q: Can we offer standardized plans of support? A: This will become clear over time, but standardizing packages of support should help reduce support costs. Q: Is there a minimum number of people in a community needed to create “critical mass” for viability? A: There was extensive discussion around this, but no consensus. It is hoped that new business models will emerge specifically for work with smaller communities. Notes 1. http://www.icann.org/en/topics/new-gtlds/cost-considerations-04oct09-en.pdf 2. http://www.icann.org/en/topics/new-gtlds/new-gtld-budget-28may10-en.pdf 3. http://www.icann.org/en/topics/new-gtlds/Draft-rfp-clean-28may10-en.pdf page 4-18 4. Draft-rfp-clean-28may10-en.pdf Registry Agreement 6.1 Carlos Dionisio Aguirre Abogado - Especialista en Derecho de los Negocios Sarmiento 71 - 4to. 18 Cordoba - Argentina - *54-351-424-2123 / 423-5423 http://ar.ageiadensi.org _________________________________________________________________ Preparate para un nuevo Hotmail con mucho más de lo que tu vida necesita. Ver más http://www.nuevohotmail.com

1 0

Weekly posting summary for at-large@atlarge-lists.icann.org
by Thomas Narten July 23, 2010

July 23, 2010

Total of 4 messages in the last 7 days. script run at: Fri Jul 23 08:13:29 EDT 2010 Messages | Bytes | Who --------+------+--------+----------+------------------------ 25.00% | 1 | 78.57% | 116141 | staff at atlarge.icann.org 25.00% | 1 | 8.87% | 13117 | langdonorr at gmail.com 25.00% | 1 | 8.85% | 13078 | joette.youkhanna at icann.org 25.00% | 1 | 3.71% | 5488 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 4 |100.00% | 147824 | Total

1 0

Re: [At-Large] DRAFT - 'Nominations Open -Election Call Message' - for ALAC Appointment of Nominating Committee Members for NomCom 2011.
by Cheryl Langdon-Orr July 23, 2010

July 23, 2010

Further to my previous email dated July 17th confirming the request from NomCom 2011 for appointments to be made by the ALAC and proposing the following time table and methods for Regional input / advice on candidates for ALAC appointment to the 2011 NomCom as regional representative voting members. In preparation for these ALAC Appointments I am now formally calling for Regional Input / Advice, and ask you to note that as only minor modifications (to point 5 marked *5) to the time table now below, were proposed and none effected the starting date, can all Regional Leaders please begin what processes they deem suitable between timetable point 1. 'Nominations Open' and point 6. 'ALAC Voting begins', to ensure that their advice to the ALAC on proposed candidates for this important role in ICANN is conducted as outlined. Proposed Time line and process for ALAC appointed NomCom members (1 from each Region) to serve on the 2011 Nominating Committee (to be completed by end August and *candidates must be willing and able to attend the Cartagena Meeting no. 39 in December this year. (see http://cartagena39.icann.org/) *NomCom positions* for 2011 committee (note term will begin in December 2010) Current Regional ALAC Appointed NomCom voting Members are: *ALAC-1 / AfRALO => Yaovi Atohoun ALAC-2 / APRALO => Hong Xue* has served 2 consecutive terms and therefore must be replaced for 2011. ALAC-3 / EURALO => Olivier M. J. Crepin-Leblond ALAC-4 / NARALO => Eduardo Diaz ALAC-5 / LACRALO => Jose Ovidio Salgueiro* * * *Current NomCom Members in seats 1,3,4 & 5 are able to serve a second consecutive term on the 2011 NomCom, but would need to be re affirmed as a preferred choice or sole candidate from their RALO's in keeping with the timetable below.* *Election Timetable* 1. Nominations Open: No later than 2359 UTC 23 July 2010 2. Nominations Close: on or before 2359 UTC 6 August 2010 3. Nomination Acceptance Deadline: on or before 2359 UTC 10 August 2010 4. Period for any select preferred RALO candidate: 11 August 2010 to 2359 UTC 15 August 2010 *5. ALAC Notification: RALOs to transmit all accepted nominations, with a recommendation of a preferred candidate if the RALO wishes to provide one: by 2359 UTC 16 August 2010 6. ALAC Voting Begins: 18 August 2010 7. ALAC Voting Ends: 2359 UTC 24 August 2010 8. Notification to NomCom of Appointees: No Later than 31 August 2010 *Requirements and Obligations:* Please click here<https://st.icann.org/alac-docs/index.cgi?obligations_and_requirements_of_no…> for an overview on the general obligations and requirements for NomCom Delegates as specified by ICANN's organising instruments. *Received Nominations will be listed in a Table Form placed on a wiki page here https://st.icann.org/alac-docs/index.cgi?alac_nomcom_delegates_2011 and list as we did in 2009 all candidates put forward by the RALO's along with any comments such as preferred status and any links to bio or candidate statements background materials etc., and then election results will also be recorded on this page. * Cheryl Langdon-Orr (CLO) ALAC Chair 2007-2010

1 0

Weekly posting summary for at-large@atlarge-lists.icann.org
by Thomas Narten July 23, 2010

July 23, 2010

Total of messages in the last 7 days. script run at: Fri Jul 23 00:53:02 EDT 2010 Messages | Bytes | Who --------+------+--------+----------+------------------------ --------+------+--------+----------+------------------------

1 0