From werner at axone.ch Tue Jul 31 07:44:01 2012 From: werner at axone.ch (Werner Staub) Date: Tue, 31 Jul 2012 00:44:01 -0700 Subject: Lack of a publication URL in input request announcement Message-ID: Dear New gTLD Team, The announcement inviting public input does not mention the publication. It should contain a URL where the input will be posted, as in a public comment phase. This is a basic requirement for transparency and accountability. Secretive interactions with the public are better than none, but still violate ICANN's principles and its very purpose. Apart from principles, there are many practical reasons to announce that input will be published immediately upon receipt: - Avoid the suspicion that someone might be filtering or distorting inputs. - Ideas submitted by one commentator enable others to elaborate, improve or correct. - Commentators can be on record officially. Please update the announcement by adding the publication URL. Yours truly, Werner Staub From alexandr.kollinger at gmail.com Tue Jul 31 03:10:50 2012 From: alexandr.kollinger at gmail.com (Alexandr Kollinger) Date: Mon, 30 Jul 2012 20:10:50 -0700 Subject: Order Message-ID: APPLICATION FOR REGISTRATION, ACCREDITATION AND GENERATION OF DOMAIN http://www.sex Hello today I started with the Industrial Property Office in Prague ??dsti management for international registration of a trade mark. I am sending a copy of correspondence to and enroll www.upv.cz this request for this domain. thank you Alexander Kollinger Postbox 26 Viktorinov? 1 14000 Prague 4 Czech Republic Materials from www.upv.cz will be send to, please tell me the reference nummber. Best regards Hello Mrs. Mgr J?rov? Hano, I ask you this term in the IPO in the matter of the application for international registration of a trade mark http://www.sex As a foundation would be in the list of goods and services - 9/po??ta?ov? programs, software, Internet, electronic media files 38 / Communications - transmission of information, news and images via computers and the Internet 42 / software engineering, web pages on social networks To discuss the items that I ask you the date and time of our meeting. thank you Yours Alexander Kollinger Tel-722-613600 Mgr Hano J?rov?, ??d?m V?s t?mto o term?n na ?PV ve v?ci pod?n? ??dosti o mezin?rodn? z?pis ochran? zn?mky? http://www.sex Jako z?klad by, m?l b?t v seznamu v?robk? a slu?eb - 9/po??ta?ov? programy, software,internet,soubory v elektronick?ch medi?ch 38/ komunikace - p?enos informac?, zpr?v a obr?zk? pomoc? po??ta?? a internetu 42/ tvorba software, tvorba webov?ch str?nek na soci?ln?ch s?t?ch Abychom mohli projednat jednotliv? body ??d?m V?s t?mto o datum a ?as na?? sch?zky. D?kuji S p??telsk?m pozdravem Alexandr Kollinger Tel-722-613600 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mm.icann.org/pipermail/newgtld-input/attachments/20120730/a8ae80ed/attachment.html From krosette at cov.com Mon Jul 30 14:38:07 2012 From: krosette at cov.com (Rosette, Kristina) Date: Mon, 30 Jul 2012 07:38:07 -0700 Subject: Input on batching - viewable comments? Message-ID: Greetings! The new announcement does not appear on the public comments page and doesn?t contain any links to allow you to view comments posted. Will comments submitted be viewable by others and, if so, where? Many thanks! Sincerely yours, Kristina Kristina Rosette Covington & Burling LLP 1201 Pennsylvania Avenue, N.W. Washington, DC 20004-2401 voice: 202-662-5173 direct fax: 202-778-5173 main fax: 202-662-6291 e-mail: krosette at cov.com www.cov.com/krosette This message is from a law firm and may contain information that is confidential or legally privileged. If you are not the intended recipient, please immediately advise the sender by reply e-mail that this message has been inadvertently transmitted to you and delete this e-mail from your system. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mm.icann.org/pipermail/newgtld-input/attachments/20120730/b4ad0422/attachment.html From jm at domaindiction.com Tue Jul 31 21:44:03 2012 From: jm at domaindiction.com (Jennie-Marie Larsen) Date: Tue, 31 Jul 2012 14:44:03 -0700 Subject: Batching, Metering, etc process... Message-ID: Poor dear ICANN, how this community must wear you out with all the ever-so-clever debating on all possible detail. Elisa Cooper from Mark Monitor wrote a great blog post yesterday recommending there is no need for any batching or metered process. I would agree. As the uncontested are first, the simple process of negotiating contracts will act as the natural metering process. People all act at their own pace and some businesses are not treating their new gTLD as their primary daily focus.? That process would, however, require you to do a random ordering of the uncontested group - and have them sign a waiver that by accepting their spot in the queue to negotiate contracts, they waive their right to object in any way later. Then you have no whining that a TLD failed because it was put too far back in the queue. And delegation happens in the order of the signed contracts. I am a neutral bystander without any applications associated with our business, but very supportive of the ENORMOUS program the new gTLDs is proving to be, and indeed, how ICANN is handling it so far.? Kind regards, -- Jennie-Marie Larsen, CEO DomainDiction Mob: +33 64059 1119 skype: jennie-marie www.DomainDiction.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mm.icann.org/pipermail/newgtld-input/attachments/20120731/99438628/attachment.html From info at domaven.com Mon Jul 30 01:31:26 2012 From: info at domaven.com (info at domaven.com) Date: Sun, 29 Jul 2012 18:31:26 -0700 Subject: batching suggestion Message-ID: We would make a strong recommendation for an alternative form of "digital archery." What started as s brilliant and effective system lead to unpredictable glitches. Iron out the glitches and relaunch the process. Otherwise the competitive extensions are going to be caught in court battles for years.You might consider utilizing the digital archery providers who werent in existance when the digital archery process was developed and announced. There are several digital archers providers who are prepared to assist with the process (as contractors) to assure that the process is consistent and uniform. Best Regards, Duane Higgins, ceo Domain Ventures -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mm.icann.org/pipermail/newgtld-input/attachments/20120729/79914800/attachment.html From james at webplots.com Mon Jul 30 10:21:46 2012 From: james at webplots.com (james at webplots.com) Date: Mon, 30 Jul 2012 03:21:46 -0700 Subject: Batching suggestion Message-ID: Good morning, May I suggest that the unopposed .IDN TLDs be pushed through so as to expedite international internet usage. It makes sense to reduce the overall numbers by first processing the unopposed gTLDs. Millions of people and businesses around the world will benefit straight away from the introduction of the .IDN extensions - these people have already been waiting for years for this...since before the new gTLD program was even thought about. I cannot think of a single reason why they should be made to wait any longer. This action will benefit the most people / businesses; ought to be the easiest to implement, and will be a huge boost to the overall new gTLD program. Best, James James Donoghue Web Plots Never underestimate the power of a good domain name -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mm.icann.org/pipermail/newgtld-input/attachments/20120730/71ecc4da/attachment.html From chp at isc.org.cn Wed Aug 1 06:38:53 2012 From: chp at isc.org.cn (=?UTF-8?B?5pu55Y2O5bmz?=) Date: Wed, 1 Aug 2012 14:38:53 +0800 (CST) Subject: [Newgtld-input] =?utf-8?q?ISC-Followers_of_ICANN_batching_policy_?= =?utf-8?q?shall_be_given_priority_in_batching=28final=29?= Message-ID: <1120898725.2708343.1343803133204.JavaMail.root@bj-e2-newwm7> An HTML attachment was scrubbed... URL: http://mm.icann.org/pipermail/newgtld-input/attachments/20120801/7a606c67/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: ISC-Followers of ICANN batching policy shall be given priority in batching(final).pdf Type: application/pdf Size: 289881 bytes Desc: not available Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120801/7a606c67/UTF-8BSVNDLUZvbGxvd2VycyBvZiBJQ0FOTiBiYXRjaGluZyBwb2xpY3kgc2hhbGwgYmUgZ2l2ZW4gcHJpb3JpdHkgaW4gYmF0Y2hpbmcoZmluYWwpLnBkZg.pdf From markus.stahlberg at phenomena.com Thu Aug 2 11:46:01 2012 From: markus.stahlberg at phenomena.com (=?iso-8859-1?Q?Markus_St=E5hlberg?=) Date: Thu, 2 Aug 2012 14:46:01 +0300 Subject: [Newgtld-input] Comments for processing new gTLD applications Message-ID: <0DBC67E1-201D-4056-8317-055D01A0C009@phenomena.com> Dear Sirs, On behalf of Phenomena Group (Applicant of the new gTLD .PROMO), I would like to submit the following comments as suggestions to the questions posed: We propose that ICANN should implement the following measures to hasten the evaluation of applications and to support a single batch (in order of importance): 1. Consolidating applications which use the same back end registry services provider: the 1930 applicants shared just 40 registry service providers. It is unnecessary to evaluate all applications in great detail if their technical plans are identical. 2. Allowing each applicant to submit one application to go forward first (with the owners of multiple applications through different bodies being restricted to just one with everyone else) 3. Removing from the batch all applications in contention ? so there is some urgency in publishing String Contention sets. 4. Allowing applicants who are happy to wait to opt out and to be processed alongside those in Contention Sets 5. Consolidating applications by type: it will be easier for the evaluators to focus, for example, on a sub-set of applications such as all city or closed brand registries etc. 6. Giving a financial incentive to those who are prepared to wait: eg. A refund of $25k I hope these comments help ICANN in making sure the given schedule can be kept. I would kindly request a confirmation of receipt of this message. Thank you very much in advance! Kind Regards, Markus Stahlberg --- Markus St?hlberg Group Managing Director markus.stahlberg at phenomena.com GSM +358 40 565 1099 Phenomena Group Ltd. The Shopper Marketing Company #1 IN SHOPPER PROMOTIONS -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mm.icann.org/pipermail/newgtld-input/attachments/20120802/523dc172/attachment.html From e.wolf at amsterdam.nl Thu Aug 2 12:56:57 2012 From: e.wolf at amsterdam.nl (Wolf, Egbert) Date: Thu, 2 Aug 2012 14:56:57 +0200 Subject: [Newgtld-input] ICANN Seeks input on gTLD Batching In-Reply-To: References: Message-ID: Dear sir, madam, Thank you for the opportunity to comment on the possible ways of processing the New GTLD applications. As applicant for the geographical TLD .Amsterdam we would like to suggest the following. ICANN itself has made a division between geographical and non-geographical applications. Geographical applications needed a letter of support from the national government and a letter of support from the geographical entity itself. Because of this, geographical applications are easier to evaluate and can be transferred for release in the first phase. Apart from that ICANN can make a division between applications against which an objection has been filed and applications without objections. If there are less than 1000 non-objected applications, they can all be released in 2013. We wish you good luck in the the decision making process. Thank you for considering our opinion, Kind regards Egbert Wolf Senior Communicatieadviseur - Design manager Directie Communicatie - Communications Department Gemeente Amsterdam - City of Amsterdam T 020 552 3262 e.wolf at amsterdam.nl Amstel 1, 1011PN Amsterdam amsterdam.nl stijlweb.amsterdam.nl iamsterdam.com ________________________________ Van: newgtld-input [mailto:newgtld-input at icann.org] Verzonden: maandag 30 juli 2012 0:05 Onderwerp: ICANN Seeks input on gTLD Batching Dear Applicant: Opportunity for Community Input: Processing of New gTLD Applications At the Prague ICANN meeting, the new gTLD Program Committee decided to terminate Digital Archery, and instructed ICANN staff to proceedwith the initial evaluation of applications as quickly as possible. This evaluation is in progress based on a tentative project plan that foresees the processing of applications in a single batch, and simultaneous release of results. ICANN believes this approach is consistent with the constraints that various parts of the community have in performing their respective roles in the evaluation process, and with the feedback received from the community at the Prague meeting. This comment opportunity seeks input on requirements for an evaluation and delegation process consistent with previous root zone scaling discussions of smooth delegations, adding no more than 1,000 new gTLDs per year. This outcome can be achieved by the: 1. timing of the release of evaluation results to applicants, 2. timing of the release of applications into the pre-delegation steps of contract execution and pre-delegation testing, 3. metering of delegations of new gTLDs into the root zone. ICANN is committed to executing the evaluation and delegation process in a way that is equitable and meets ICANN's commitment to ensuring the security and stability of the DNS, consistent with previously established root zone scaling goals. Please write to newgtld-input@icann.org with your input. Comments received by 19 August 2012 (UTC 00:00) will be considered. Background The concept of batching has been a part of the Applicant Guidebook since its first draft. Batching accomplishes three goals: 1. Better management of the evaluation process by placing an upper bound on the number of evaluators necessary and the number of parallel evaluations occurring at any one time. 2. Release of evaluation results to applicants according to a predictable schedule. 3. Delegation of TLDs at a rate acceptable to the technical community, consistent with the root zone scaling discussion. Based on the definitive information that ICANN now has about the pool of applications, and work on the evaluations to date, this commentprocess seeks input to meet requirements for goals #2 and #3. Leading up to and during ICANN's meeting in Prague, the applicant and community positions on requirements for batching schemes thatwould control the evaluation, communication and delegation of applications were reported to be: 1. The batching solution has to be equitable. 2. The evaluation results have to be announced at the same time. 3. Successful applications should proceed to delegation phase without undue delays. 4. Delegation to the root must be at a smooth rate and must not exceed 1,000 per year. 5. The GAC is planning to issue early warnings shortly after the Toronto ICANN meeting in October 2012. 6. Consideration by the GAC of issues concerning GAC advice on contentious applications is not expected to be finalized before the Beijing meeting in April 2013. During the root scaling discussion, it was agreed that ICANN would not delegate TLDs at a rate greater than 1,000 per year. This is because the primary challenge with maintaining root zone stability is controlling the rate of change to the root zone system and not the size of the root zone itself, meaning delegation should not occur at a rate of 1,000 delegations on a single day. In Prague, the batching and prioritization method known as Digital Archery was terminated and eliminated from further consideration. Recent Developments Initial evaluation of new gTLD applications is underway. Applications are being distributed to evaluators in a way that enables efficient processing. ICANN has conducted pilot evaluations and had discussions with evaluators to accelerate the evaluation schedule. As a result of thesediscussions, the evaluation teams have committed to accelerate the evaluations substantially, while processing them in a single batch. In Prague, a methodology was discussed where the smooth delegation of applications could occur by first releasing applications that passed initial evaluation without the need for clarifying questions, then releasing applications in order of the number of clarifying questions required, from fewest to highest. After analysis, this methodology proved unworkable because 80% to 90% of the total evaluation time is required to form and ask clarifying questions, so little smoothing would result. The current plan indicates that initial evaluation of all applications, processed in a "single batch", can be completed in 11-12 months, possibly less - resulting in publication of results in June-July 2013. Note: It is planned that regular updates to applicants during the evaluation period will be provided. In addition to written reports, ICANN is looking into the use of a webinar / conference call format to deliver updates. For applicants, releasing results in a single batch would mean that the first delegations would occur in late third quarter of 2013, six months later than originally expected. Implications of GAC timing: The GAC plans to "issue any Early Warnings shortly after the Toronto ICANN meeting, in October 2012," meaning that Early Warnings would be received within the currently planned single evaluation period. Also, the GAC "is considering the implications of providing any GAC advice on gTLD applications. These considerations are not expected to be finalized before the Beijing meeting in April 2013." This is shortly before the currently planned announcement of initial evaluation results (i.e., the schedule without additional accelerations beyond those stated above). Statement of the Issue While there will be some natural smoothing as applications take different paths through objections and contention resolution processes, there will still be a requirement for some method of metering applications into the delegation process. This is due to the relatively high number of applications that mayreach pre-delegation steps at essentially the same time. A metering method has not yet been determined and will need to be developed. Questions to be answered by comments Submitted comments should specifically answer each of the following questions: 1. Should the metering or smoothing consider releasing evaluation results, and transitioning applications into the contract execution and pre-delegation testing phases, at different times? o How can applications be allocated to particular release times in a fair and equitable way? o Would this approach provide sufficient smoothing of the delegation rate? o Provide reasoning for selecting this approach. 2. Should the metering or smoothing be accomplished by downstream metering of application processing (i.e., in the contract execution, pre-delegation testing or delegation phases)? o How can applications be allocated to a particular timing in contract execution, pre-delegation testing, or delegation in a fair and equitable way? o Provide reasoning for selecting this approach. o Include a statement describing the level of importance that the order of evaluation and delegation has for your application. Please write to newgtld-input@icann.org with your input. Comments received by 19 August 2012 (UTC 00:00) will be considered. Regards, New gTLD Team ________________________________ Op dit bericht is een disclaimer van toepassing. Ga naar www.amsterdam.nl/algemene_onderdelen/overige/disclaimer_e-mail voor meer informatie. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mm.icann.org/pipermail/newgtld-input/attachments/20120802/a1f35302/attachment.html From kelly.salter at dada.eu Thu Aug 2 15:32:18 2012 From: kelly.salter at dada.eu (Kelly Salter) Date: Thu, 2 Aug 2012 16:32:18 +0100 Subject: [Newgtld-input] ICANN Seeks Input on gTLD Batching Message-ID: Good afternoon, To ensure "Successful applications should proceed to delegation phase without undue delays", at it's simplest level can i please suggest the first question to all new gTLD applicants should be "Do you want to be in the first phase of delegation into the root zone?" It is realistic to assume that some of the new gTLD applicants will want additional time after finding out they have passed evaluation, to finalise their domain strategy / customer experience or plan their outreach programme, before proceeding through contract execution and pre-delegation testing. Many applicants will wait until they actually get their new gTLD before investing more time and money into this part of their business plan. By allowing the applicants to indicate whether they wish to move immediately into contract execution and pre-delegation testing, or delay the next steps by a timeframe (determined by ICANN), there may be a natural selection by the applicants themselves of delegation timings. Kind regards Kelly Salter -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mm.icann.org/pipermail/newgtld-input/attachments/20120802/f1cd4da0/attachment.html From bourne.hz at fairwindspartners.com Thu Aug 2 21:21:36 2012 From: bourne.hz at fairwindspartners.com (HZ, Bourne) Date: Thu, 2 Aug 2012 21:21:36 +0000 Subject: [Newgtld-input] ICANN Seeks input on gTLD Batching In-Reply-To: Message-ID: Hello, Will any of these comments/responses be made public? If so, will they be made public when they are submitted, as in the forum, or after the close of the comment window? Thank you. From: newgtld-input > Date: Sunday, July 29, 2012 6:01 PM Subject: ICANN Seeks input on gTLD Batching Dear Applicant: Opportunity for Community Input: Processing of New gTLD Applications At the Prague ICANN meeting, the new gTLD Program Committee decided to terminate Digital Archery, and instructed ICANN staff to proceedwith the initial evaluation of applications as quickly as possible. This evaluation is in progress based on a tentative project plan that foresees the processing of applications in a single batch, and simultaneous release of results. ICANN believes this approach is consistent with the constraints that various parts of the community have in performing their respective roles in the evaluation process, and with the feedback received from the community at the Prague meeting. This comment opportunity seeks input on requirements for an evaluation and delegation process consistent with previous root zone scaling discussions of smooth delegations, adding no more than 1,000 new gTLDs per year. This outcome can be achieved by the: 1. timing of the release of evaluation results to applicants, 2. timing of the release of applications into the pre-delegation steps of contract execution and pre-delegation testing, 3. metering of delegations of new gTLDs into the root zone. ICANN is committed to executing the evaluation and delegation process in a way that is equitable and meets ICANN?s commitment to ensuring the security and stability of the DNS, consistent with previously established root zone scaling goals. Please write to newgtld-input@icann.org with your input. Comments received by 19 August 2012 (UTC 00:00) will be considered. Background The concept of batching has been a part of the Applicant Guidebook since its first draft. Batching accomplishes three goals: 1. Better management of the evaluation process by placing an upper bound on the number of evaluators necessary and the number of parallel evaluations occurring at any one time. 2. Release of evaluation results to applicants according to a predictable schedule. 3. Delegation of TLDs at a rate acceptable to the technical community, consistent with the root zone scaling discussion. Based on the definitive information that ICANN now has about the pool of applications, and work on the evaluations to date, this commentprocess seeks input to meet requirements for goals #2 and #3. Leading up to and during ICANN?s meeting in Prague, the applicant and community positions on requirements for batching schemes thatwould control the evaluation, communication and delegation of applications were reported to be: 1. The batching solution has to be equitable. 2. The evaluation results have to be announced at the same time. 3. Successful applications should proceed to delegation phase without undue delays. 4. Delegation to the root must be at a smooth rate and must not exceed 1,000 per year. 5. The GAC is planning to issue early warnings shortly after the Toronto ICANN meeting in October 2012. 6. Consideration by the GAC of issues concerning GAC advice on contentious applications is not expected to be finalized before the Beijing meeting in April 2013. During the root scaling discussion, it was agreed that ICANN would not delegate TLDs at a rate greater than 1,000 per year. This is because the primary challenge with maintaining root zone stability is controlling the rate of change to the root zone system and not the size of the root zone itself, meaning delegation should not occur at a rate of 1,000 delegations on a single day. In Prague, the batching and prioritization method known as Digital Archery was terminated and eliminated from further consideration. Recent Developments Initial evaluation of new gTLD applications is underway. Applications are being distributed to evaluators in a way that enables efficient processing. ICANN has conducted pilot evaluations and had discussions with evaluators to accelerate the evaluation schedule. As a result of thesediscussions, the evaluation teams have committed to accelerate the evaluations substantially, while processing them in a single batch. In Prague, a methodology was discussed where the smooth delegation of applications could occur by first releasing applications that passed initial evaluation without the need for clarifying questions, then releasing applications in order of the number of clarifying questions required, from fewest to highest. After analysis, this methodology proved unworkable because 80% to 90% of the total evaluation time is required to form and ask clarifying questions, so little smoothing would result. The current plan indicates that initial evaluation of all applications, processed in a ?single batch?, can be completed in 11-12 months, possibly less ? resulting in publication of results in June-July 2013. Note: It is planned that regular updates to applicants during the evaluation period will be provided. In addition to written reports, ICANN is looking into the use of a webinar / conference call format to deliver updates. For applicants, releasing results in a single batch would mean that the first delegations would occur in late third quarter of 2013, six months later than originally expected. Implications of GAC timing: The GAC plans to ?issue any Early Warnings shortly after the Toronto ICANN meeting, in October 2012,? meaning that Early Warnings would be received within the currently planned single evaluation period. Also, the GAC ?is considering the implications of providing any GAC advice on gTLD applications. These considerations are not expected to be finalized before the Beijing meeting in April 2013.? This is shortly before the currently planned announcement of initial evaluation results (i.e., the schedule without additional accelerations beyond those stated above). Statement of the Issue While there will be some natural smoothing as applications take different paths through objections and contention resolution processes, there will still be a requirement for some method of metering applications into the delegation process. This is due to the relatively high number of applications that mayreach pre-delegation steps at essentially the same time. A metering method has not yet been determined and will need to be developed. Questions to be answered by comments Submitted comments should specifically answer each of the following questions: 1. Should the metering or smoothing consider releasing evaluation results, and transitioning applications into the contract execution and pre-delegation testing phases, at different times? * How can applications be allocated to particular release times in a fair and equitable way? * Would this approach provide sufficient smoothing of the delegation rate? * Provide reasoning for selecting this approach. 2. Should the metering or smoothing be accomplished by downstream metering of application processing (i.e., in the contract execution, pre-delegation testing or delegation phases)? * How can applications be allocated to a particular timing in contract execution, pre-delegation testing, or delegation in a fair and equitable way? * Provide reasoning for selecting this approach. * Include a statement describing the level of importance that the order of evaluation and delegation has for your application. Please write to newgtld-input@icann.org with your input. Comments received by 19 August 2012 (UTC 00:00) will be considered. Regards, New gTLD Team -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mm.icann.org/pipermail/newgtld-input/attachments/20120802/a3f51c64/attachment.html From jim at galwaystrategygroup.com Fri Aug 3 11:33:19 2012 From: jim at galwaystrategygroup.com (Jim Prendergast) Date: Fri, 3 Aug 2012 07:33:19 -0400 Subject: [Newgtld-input] Input on gTLD Batching Message-ID: <104553CC1ECEF5468033E231DF6A0B1B66280BDF@mse21be1.mse21.exchange.ms> Sending to two emails just to ensure I reach the right destination. In reading the announcement for input on gTLD Batching, I see that the process for submitting comments is different than how a traditional ICANN public comment period might operate. For example - no public digest of comments submitted, no reply period, etc. Can you confirm that this is actually the case? Thanks Jim Prendergast The Galway Strategy Group jim at galwaysg.com Twitter @jimpren 202-285-3699 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mm.icann.org/pipermail/newgtld-input/attachments/20120803/2f5d7b61/attachment.html From tyler at xmission.com Mon Aug 6 22:52:19 2012 From: tyler at xmission.com (Tyler Morgan) Date: Mon, 06 Aug 2012 15:52:19 -0700 Subject: [Newgtld-input] The only thing I care about Message-ID: <50204AA3.6070500@xmission.com> Large companies should not be allowed to control generic domains. Amazon can have .amazon; they don't need or deserve ".(e)book(s)" and it would be unfair to let them have it. Generic TLDs should be reserved for non-profit groups (like ICANN itself is). As to what a "generic" TLD is, good luck! From jslascary at coefficient.ca Tue Aug 7 18:21:34 2012 From: jslascary at coefficient.ca (=?ISO-8859-1?Q?Jean-S=E9bastien_Lascary?=) Date: Tue, 07 Aug 2012 14:21:34 -0400 Subject: [Newgtld-input] Input on gTLD Batching Message-ID: <50215CAE.3090109@coefficient.ca> I support the ALAC Statement on the IDN Prioritization in the New gTLD Program Targeted at the ICANN Board published at the following url : http://atlarge-lists.icann.org/pipermail/idn-wg/attachments/20120731/ec8764c7/ALACStatementontheIDNPrioritizationintheNewgTLDProgramTargetedattheICANNBoard-0001.pdf Regards, Jean-S?bastien Lascary Montreal, Qc, Canada From stbmax2002 at yahoo.com Tue Aug 7 19:26:08 2012 From: stbmax2002 at yahoo.com (Steve Clarke) Date: Tue, 7 Aug 2012 12:26:08 -0700 (PDT) Subject: [Newgtld-input] Input on gTLD Batching Message-ID: <1344367568.96459.YahooMailClassic@web31804.mail.mud.yahoo.com> To: newgtld-input at icann.org Subject : Input on gTLD Batching I support the ALAC Statement on the IDN Prioritization in the New gTLD Program Targeted at the ICANN Board published at the following url : http:// atlarge-lists.icann.org/pipermail/idn-wg/attachments/20120731/ec8764c7/ALACStatementontheIDNPrioritizationintheNewgTLDProgramTargetedattheICANNBoard-0001.pdf Regards, Full Name City, State, Country To Whom It May Concern. I support the ALAC Statement on the IDN Prioritization in the New gTLD Program Targeted at the ICANN Board published at the following url : http:// atlarge-lists.icann.org/pipermail/idn-wg/attachments/20120731/ec8764c7/ALACStatementontheIDNPrioritizationintheNewgTLDProgramTargetedattheICANNBoard-0001.pdf Regards, Steve Clarke, Ajax, Ontario, Canada. From artiques at otenet.gr Tue Aug 7 20:45:39 2012 From: artiques at otenet.gr (yanni) Date: Tue, 07 Aug 2012 23:45:39 +0300 Subject: [Newgtld-input] Input on gTLD Batching Message-ID: <50217E73.6080403@otenet.gr> I support the ALAC Statement on the IDN Prioritization in the New gTLD Program Targeted at the ICANN Board published at the following url : http:// atlarge-lists.icann.org/pipermail/idn-wg/attachments/20120731/ec8764c7/ALACStatementontheIDNPrioritizationintheNewgTLDProgramTargetedattheICANNBoard-0001.pdf I feel it's imperative that the IDN gtlds be given priority in the batching process, given the fact that the International Community has endured enough waiting to partake in the Internet infrastructure. Regards, John Tziviskos Andros, Cyclades, Greece artiques at otenet.gr From chrisofmel at gmail.com Tue Aug 7 22:45:20 2012 From: chrisofmel at gmail.com (Chris Rossi) Date: Tue, 7 Aug 2012 18:45:20 -0400 Subject: [Newgtld-input] Input on gTLD Batching Message-ID: I support the ALAC Statement on the IDN Prioritization in the New gTLD Program Targeted at the ICANN Board published at the following url : http:// atlarge-lists.icann.org/pipermail/idn-wg/attachments/20120731/ec8764c7/ALACStatementontheIDNPrioritizationintheNewgTLDProgramTargetedattheICANNBoard-0001.pdf Regards, terry chris rossi melbourne florida USA From romankagan at live.com Tue Aug 7 23:08:23 2012 From: romankagan at live.com (Roman Kagan) Date: Tue, 7 Aug 2012 19:08:23 -0400 Subject: [Newgtld-input] Input on gTLD Batching Message-ID: I support the ALAC Statement on the IDN Prioritization in the New gTLD Program Targeted at the ICANN Board published at the following url : http:// atlarge-lists.icann.org/pipermail/idn-wg/attachments/20120731/ec8764c7/ALACStatementontheIDNPrioritizationintheNewgTLDProgramTargetedattheICANNBoard-0001.pdf Regards, Roman Kagan Toronto, ON, CANADA From ocl at gih.com Wed Aug 8 16:06:18 2012 From: ocl at gih.com (Olivier MJ Crepin-Leblond) Date: Wed, 08 Aug 2012 18:06:18 +0200 Subject: [Newgtld-input] Fwd: ALAC Statement on the IDN Prioritization in the New gTLD Program In-Reply-To: <5017EBA7.4010708@gih.com> References: <5017EBA7.4010708@gih.com> Message-ID: <50228E7A.9060505@gih.com> Dear Sir/Madam, please be so kind to find below and attached, a copy of the email which the ALAC has sent to Steve Crocker, Board Chair, regarding IDN Prioritization in the New gTLD Program. The present forum posting is meant to alert the community of the ALAC's position. Warm regards, Olivier MJ Cr?pin-Leblond ALAC Chair -------- Original Message -------- Subject: ALAC Statement on the IDN Prioritization in the New gTLD Program Date: Tue, 31 Jul 2012 16:28:55 +0200 From: Olivier MJ Crepin-Leblond To: Steve Crocker CC: ICANN AtLarge Staff , secretary@*.org, Olivier MJ Crepin-Leblond Dear Steve, please be so kind to find attached, the /ALAC Statement on the IDN Prioritization in the New gTLD Program Targeted at the ICANN Board/. On 30 July 2012, Staff confirmed that the online vote resulted in the ALAC endorsing the Statement with 14 votes in favor, 0 votes against, and 1 abstention. You may review the result independently under: https://www.bigpulse.com/pollresults?code=2531CIXGA3KxY5DTwZiT26Ie In line with prior ALAC advice extrinsecus the usual Public Comment process, my colleagues and I would appreciate a response from the Board when the matter has been discussed and a response has been formulated regarding our comment. Kind regards, Olivier MJ Cr?pin-Leblond ALAC Chair -------------- next part -------------- A non-text attachment was scrubbed... Name: ALAC Statement on the IDN Prioritization in the New gTLD Program Targeted at the ICANN Board.pdf Type: application/pdf Size: 99228 bytes Desc: not available Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120808/534ec6f3/ALACStatementontheIDNPrioritizationintheNewgTLDProgramTargetedattheICANNBoard.pdf From emil.m.babayev at gmail.com Wed Aug 8 17:00:59 2012 From: emil.m.babayev at gmail.com (Emil Babayev) Date: Wed, 8 Aug 2012 13:00:59 -0400 Subject: [Newgtld-input] Input on gTLD Batching Message-ID: I support the ALAC Statement on the IDN Prioritization in the New gTLD Program Targeted at the ICANN Board published at the following url : http:// atlarge-lists.icann.org/pipermail/idn-wg/attachments/20120731/ec8764c7/ALACStatementontheIDNPrioritizationintheNewgTLDProgramTargetedattheICANNBoard-0001.pdf Regards, Emil M Babayev New York, NY, USA Sent from my iPhone From dtricot at yahoo.com Wed Aug 8 23:04:07 2012 From: dtricot at yahoo.com (dory tricot) Date: Wed, 8 Aug 2012 16:04:07 -0700 (PDT) Subject: [Newgtld-input] Input on gTLD Batching Message-ID: <1344467047.14731.YahooMailNeo@web163403.mail.gq1.yahoo.com> I support the ALAC Statement on the IDN Prioritization in the New gTLD Program Targeted at the ICANN Board published at the following url : http:// atlarge-lists.icann.org/pipermail/idn-wg/attachments/20120731/ec8764c7/ALACStatementontheIDNPrioritizationintheNewgTLDProgramTargetedattheICANNBoard-0001.pdf Regards, Dory Tricot Montreal, Quebec, Canada From keith at taynton.org Wed Aug 8 23:28:17 2012 From: keith at taynton.org (keith taynton) Date: Thu, 9 Aug 2012 08:28:17 +0900 Subject: [Newgtld-input] Input on gTLD Batching Message-ID: I support the ALAC Statement on the IDN Prioritization in the New gTLD Program Targeted at the ICANN Board published at the following url : http:// atlarge-lists.icann.org/pipermail/idn-wg/attachments/20120731/ec8764c7/ALACStatementontheIDNPrioritizationintheNewgTLDProgramTargetedattheICANNBoard-0001.pdf Regards, keith taynton ibaraki shi, osaka, Japan From usgurjeewan at gmail.com Thu Aug 9 01:24:30 2012 From: usgurjeewan at gmail.com (Gurjeewan Sachavirawongse) Date: Wed, 8 Aug 2012 18:24:30 -0700 Subject: [Newgtld-input] Input on gTLD Batching Message-ID: Hi there, I support the ALAC Statement on the IDN Prioritization in the New gTLD Program Targeted at the ICANN Board published at the following url : http:// atlarge-lists.icann.org/pipermail/idn-wg/attachments/20120731/ec8764c7/ALACStatementontheIDNPrioritizationintheNewgTLDProgramTargetedattheICANNBoard-0001.pdf Regards, Gurjeewan S. Sachavirawongse Bangkok, Thailand From shaunmarquardt at gmail.com Thu Aug 9 06:45:23 2012 From: shaunmarquardt at gmail.com (Shaun Marquardt) Date: Thu, 9 Aug 2012 00:45:23 -0600 Subject: [Newgtld-input] Input on gTLD Batching Message-ID: To whom it may concern: I support the ALAC Statement on the IDN Prioritization in the New gTLD Program Targeted at the ICANN Board published at the following url: http://atlarge-lists.icann.org/pipermail/idn-wg/attachments/20120731/ec8764c7/ALACStatementontheIDNPrioritizationintheNewgTLDProgramTargetedattheICANNBoard-0001.pdf Kind Regards, Shaun Marquardt Calgary, Alberta, Canada From fka200 at hotmail.com Thu Aug 9 17:29:04 2012 From: fka200 at hotmail.com (Sammy Ashouri) Date: Thu, 9 Aug 2012 10:29:04 -0700 Subject: [Newgtld-input] Input on gTLD Batching Message-ID: I support the ALAC Statement on the IDN Prioritization in the New gTLD Program Targeted at the ICANN Board published at the following url: http:// atlarge-lists.icann.org/pipermail/idn-wg/attachments/20120731/ec8764c7/ALACStatementontheIDNPrioritizationintheNewgTLDProgramTargetedattheICANNBoard-0001.pdf I also hope that the rights of current IDN gTLD holders (.com/.net/.org) are protected in respects to owning geo/single character/keyword domains/etc. Some of these domains have been registered and held onto since 2000. Regards,Sammy AshouriLos Angeles, California, United States From secura at domainregistry.de Fri Aug 10 08:39:36 2012 From: secura at domainregistry.de (ICANN Registrar Secura) Date: Fri, 10 Aug 2012 10:39:36 +0200 Subject: [Newgtld-input] Batch-Problem Message-ID: My proposal: 1.Sponsors, who fulfill certain criterias like e.g.: a)working Registry System b)working DNS c)signed contracts with ICANN d)signed contracts with interested ICANN Registrars, if applicable till 1. Sept. 2012, can go live at the End of 2012. All others must wail till the End of 2013. Mit freundlichen Gr??en/ with kind regards, Hans Peter Oswald Gesch?ftsf?hrer/CEO SECURA GMBH Frohnhofweg 18 Tel +49 (0)221 257 12 13 D-50858 K?ln Fax +49 (0)221 925 22 72 secura at domainregistry.de Tel (US/CA toll-free) +1 866 782 18 59 www.domainregistry.de Fax (USA) +1 734 486 18 75 Gesch?ftsf?hrer/CEO Amtsgericht K?ln HRB 31240 Hans Peter Oswald Ust.-IdNr/VATID DE196859556 ICANN accredited registrar of top-level-domains + registrar of country code domains From sales at nativescripts.com Fri Aug 10 13:07:24 2012 From: sales at nativescripts.com (Falko Neuhaus) Date: Fri, 10 Aug 2012 15:07:24 +0200 Subject: [Newgtld-input] Input on gTLD Batching Message-ID: <5025078C.3000500@nativescripts.com> I support the ALAC Statement on the IDN Prioritization in the New gTLD Program Targeted at the ICANN Board published at the following url : http:// atlarge-lists.icann.org/pipermail/idn-wg/attachments/20120731/ec8764c7/ALACStatementontheIDNPrioritizationintheNewgTLDProgramTargetedattheICANNBoard-0001.pdf Kind regards, Falko Neuhaus Duelmen, NRW, Germany From info at booktale.com Fri Aug 10 14:12:33 2012 From: info at booktale.com (Jasem Al-Shamlan) Date: Fri, 10 Aug 2012 17:12:33 +0300 Subject: [Newgtld-input] Input on gTLD Batching Message-ID: <009001cd7702$3223cf60$966b6e20$@i.com.kw> Hello I support the ALAC Statement on the IDN Prioritization in the New gTLD Program Targeted at the ICANN Board. The statement published at the following url : http://atlarge-lists.icann.org/pipermail/idn-wg/attachments/20120731/ec8764c 7/ALACStatementontheIDNPrioritizationintheNewgTLDProgramTargetedattheICANNBo ard-0001.pdf Regards, Jasem Y. Al-Shamlan (BsEE, BsMath) Professional .NET Applications Programmer/Consultant ( http://i.com.kw) Phone: (965) 66925732; Email: info at i.com.kw From steve.epstein at gmail.com Fri Aug 10 19:23:20 2012 From: steve.epstein at gmail.com (Steve Epstein) Date: Fri, 10 Aug 2012 12:23:20 -0700 Subject: [Newgtld-input] new gtld batching Message-ID: I support the ALAC Statement on the IDN Prioritization in the New gTLD Program Targeted at the ICANN Board published at the following url : http:// atlarge-lists.icann.org/pipermail/idn-wg/attachments/20120731/ec8764c7/ALACStatementontheIDNPrioritizationintheNewgTLDProgramTargetedattheICANNBoard-0001.pdf Regards, -- Steve Epstein steve.epstein at gmail.com twitter: @sbepstein 602 790 0540 phoenix az, usa From teeraphong.mahatham at scb.co.th Mon Aug 13 06:21:10 2012 From: teeraphong.mahatham at scb.co.th (Teeraphong March Mahatham) Date: Mon, 13 Aug 2012 13:21:10 +0700 Subject: [Newgtld-input] ICANN Seeks input on gTLD Batching In-Reply-To: References: Message-ID: <00b801cd791b$d4dd4040$7e97c0c0$@scb.co.th> Dear ICANN, With us, the applicant for .SCB, we prefer to be evaluated and delegated as soon as possible. Please see our comments: 1. Should the metering or smoothing consider releasing evaluation results, and transitioning applications into the contract execution and pre-delegation testing phases, at different times? o How can applications be allocated to particular release times in a fair and equitable way? 1. Please categorize the applied names and the nature of the business - similar ones should be considered at the same time. Branding TLD might be considered first. o Would this approach provide sufficient smoothing of the delegation rate? 1. Yes, you can control the rate o Provide reasoning for selecting this approach. 1. Some applicants would be able to use the names early - benefiting the overall usage of internet users. 2. Should the metering or smoothing be accomplished by downstream metering of application processing (i.e., in the contract execution, pre-delegation testing or delegation phases)? o How can applications be allocated to a particular timing in contract execution, pre-delegation testing, or delegation in a fair and equitable way? o Provide reasoning for selecting this approach. o Include a statement describing the level of importance that the order of evaluation and delegation has for your application. 1. The order of evaluation and delegation is very important to us as we are very serious in using the applied TLD. We are the largest market-cap bank in Thailand and the applied TLD has been considered for various downstream strategies, processes and, activities for us and for Thai people & other people in the world. We hence would request you please proceed the evaluation as soon as possible. The Brand TLD (like us, .SCB) should be easier one for you to evaluate. 2. We would suggest you can set up some rules to evaluate the delegated TLD every year - if they break the rules then ICANN has right to negotiate to take it back. This way, you can loosen your evaluation period this time - just quickly evaluate and delegate to applicants. Best Regards, Teeraphong March Mahatham VP, Change Program - Project Manager | SCB | T: +66-2-544-7290 | teeraphong.mahatham at scb.co.th From: newgtld-input [mailto:newgtld-input at icann.org] Sent: Monday, July 30, 2012 5:21 AM To: undisclosed-recipients: Subject: ICANN Seeks input on gTLD Batching Dear Applicant: Opportunity for Community Input: Processing of New gTLD Applications At the Prague ICANN meeting, the new gTLD Program Committee decided to terminate Digital Archery, and instructed ICANN staff to proceedwith the initial evaluation of applications as quickly as possible. This evaluation is in progress based on a tentative project plan that foresees the processing of applications in a single batch, and simultaneous release of results. ICANN believes this approach is consistent with the constraints that various parts of the community have in performing their respective roles in the evaluation process, and with the feedback received from the community at the Prague meeting. This comment opportunity seeks input on requirements for an evaluation and delegation process consistent with previous root zone scaling discussions of smooth delegations, adding no more than 1,000 new gTLDs per year. This outcome can be achieved by the: 1. timing of the release of evaluation results to applicants, 2. timing of the release of applications into the pre-delegation steps of contract execution and pre-delegation testing, 3. metering of delegations of new gTLDs into the root zone. ICANN is committed to executing the evaluation and delegation process in a way that is equitable and meets ICANN's commitment to ensuring the security and stability of the DNS, consistent with previously established root zone scaling goals. Please write to new gtld - input @ icann . org with your input. Comments received by 19 August 2012 (UTC 00:00) will be considered. Background The concept of batching has been a part of the Applicant Guidebook since its first draft. Batching accomplishes three goals: 1. Better management of the evaluation process by placing an upper bound on the number of evaluators necessary and the number of parallel evaluations occurring at any one time. 2. Release of evaluation results to applicants according to a predictable schedule. 3. Delegation of TLDs at a rate acceptable to the technical community, consistent with the root zone scaling discussion. Based on the definitive information that ICANN now has about the pool of applications, and work on the evaluations to date, this commentprocess seeks input to meet requirements for goals #2 and #3. Leading up to and during ICANN's meeting in Prague, the applicant and community positions on requirements for batching schemes thatwould control the evaluation, communication and delegation of applications were reported to be: 1. The batching solution has to be equitable. 2. The evaluation results have to be announced at the same time. 3. Successful applications should proceed to delegation phase without undue delays. 4. Delegation to the root must be at a smooth rate and must not exceed 1,000 per year. 5. The GAC is planning to issue early warnings shortly after the Toronto ICANN meeting in October 2012. 6. Consideration by the GAC of issues concerning GAC advice on contentious applications is not expected to be finalized before the Beijing meeting in April 2013. During the root scaling discussion, it was agreed that ICANN would not delegate TLDs at a rate greater than 1,000 per year. This is because the primary challenge with maintaining root zone stability is controlling the rate of change to the root zone system and not the size of the root zone itself, meaning delegation should not occur at a rate of 1,000 delegations on a single day. In Prague, the batching and prioritization method known as Digital Archery was terminated and eliminated from further consideration. Recent Developments Initial evaluation of new gTLD applications is underway. Applications are being distributed to evaluators in a way that enables efficient processing. ICANN has conducted pilot evaluations and had discussions with evaluators to accelerate the evaluation schedule. As a result of thesediscussions, the evaluation teams have committed to accelerate the evaluations substantially, while processing them in a single batch. In Prague, a methodology was discussed where the smooth delegation of applications could occur by first releasing applications that passed initial evaluation without the need for clarifying questions, then releasing applications in order of the number of clarifying questions required, from fewest to highest. After analysis, this methodology proved unworkable because 80% to 90% of the total evaluation time is required to form and ask clarifying questions, so little smoothing would result. The current plan indicates that initial evaluation of all applications, processed in a "single batch", can be completed in 11-12 months, possibly less - resulting in publication of results in June-July 2013. Note: It is planned that regular updates to applicants during the evaluation period will be provided. In addition to written reports, ICANN is looking into the use of a webinar / conference call format to deliver updates. For applicants, releasing results in a single batch would mean that the first delegations would occur in late third quarter of 2013, six months later than originally expected. Implications of GAC timing: The GAC plans to "issue any Early Warnings shortly after the Toronto ICANN meeting, in October 2012," meaning that Early Warnings would be received within the currently planned single evaluation period. Also, the GAC "is considering the implications of providing any GAC advice on gTLD applications. These considerations are not expected to be finalized before the Beijing meeting in April 2013." This is shortly before the currently planned announcement of initial evaluation results (i.e., the schedule without additional accelerations beyond those stated above). Statement of the Issue While there will be some natural smoothing as applications take different paths through objections and contention resolution processes, there will still be a requirement for some method of metering applications into the delegation process. This is due to the relatively high number of applications that mayreach pre-delegation steps at essentially the same time. A metering method has not yet been determined and will need to be developed. Questions to be answered by comments Submitted comments should specifically answer each of the following questions: 1. Should the metering or smoothing consider releasing evaluation results, and transitioning applications into the contract execution and pre-delegation testing phases, at different times? o How can applications be allocated to particular release times in a fair and equitable way? o Would this approach provide sufficient smoothing of the delegation rate? o Provide reasoning for selecting this approach. 2. Should the metering or smoothing be accomplished by downstream metering of application processing (i.e., in the contract execution, pre-delegation testing or delegation phases)? o How can applications be allocated to a particular timing in contract execution, pre-delegation testing, or delegation in a fair and equitable way? o Provide reasoning for selecting this approach. o Include a statement describing the level of importance that the order of evaluation and delegation has for your application. Please write to newgtld - input @ icann . org with your input. Comments received by 19 August 2012 (UTC 00:00) will be considered. Regards, New gTLD Team DISCLAIMER: This e-mail is intended solely for the recipient(s) name above. If you are not the intended recipient, any type of your use is prohibited. Any information, comment or statement contained in this e-mail, including any attachments (if any) are those of the author and are not necessarily endorsed by the Bank. The Bank shall, therefore, not be liable or responsible for any of such contents, including damages resulting from any virus transmitted by this e-mail. From candidate at puntogal.org Mon Aug 13 14:15:00 2012 From: candidate at puntogal.org (=?UTF-8?B?QXNvY2lhY2nDs24gUHVudG9nYWw=?=) Date: Mon, 13 Aug 2012 16:15:00 +0200 Subject: [Newgtld-input] ICANN Seeks Input on gTLD Batching Message-ID: <50290BE4.9050103@puntogal.org> Dear Sirs, Please find below Asociaci?n puntoGAL, new gTLD applicant, regarding how to process the applications. Best regards, Manuel Vilas /Should the metering or smoothing consider releasing evaluation results, and transitioning applications into the contract execution and pre-delegation testing phases, at different times? / 1. / How can applications be allocated to particular release times in a fair and equitable way?/ 2. / Would this approach provide sufficient smoothing of the delegation rate?/ 3. / Provide reasoning for selecting this approach./ All the results of the Initial Evaluation should be published at the same time, as long as it is not beyond the period of June-July, announced by the ICANN three weeks after the meeting in Prague. Bearing in mind the June-July deadline, publication of all the results at the same time minimizes potential damage to the candidates. It also helps to develop a more fair process, if the technical impossibility of incorporating all the candidates that pass the Initial Evaluation in the same year occurs. Even if not all the candidates that pass the Initial Evaluation can be incorporated during the same year, the fact that everyone knows at the same time if they have passed the Initial Evaluation allows the candidates to be able to inform the communities that support them and/or investors that finance them also at the same time. The other possible scenario, publishing results of the Initial Evaluation on different dates, is much more negative. If any candidates start the formalities to be added to the DNS while others still do not know if they have passed the Initial Evaluation, and if this happens without any objective criteria to classify the candidates, the communities that give support to relegated proposals will lose their confidence in ICANN?s ability to organize an equitable process. The damage to the process will be especially severe in the case of the community candidates, whose main resource it is the support of their respective communities, and these are communities that have been maintaining their support despite all the delays to the process. In addition, bearing in mind that promoting cultural diversity is one of the goals of the process, ICANN must not relegate any of the following: 1- Applications that serve a public interest, that is, they have a letter of support from the competent public authority in the jurisdiction of the candidate. The 'public' proposals must have priority over those that only are fueled by private interests. It is logically more important to give support to candidates that will bring benefits to the whole of the society than those that will only benefit private investors. If not all the candidates can be added at the same time, those that benefit the community must not be the ones damaged for the benefit of 'dot brands', who are the majority amongst the candidates. 2.- Applications that are community candidates, that is, those who submitted their application on behalf of and with the support of a great number of bodies, institutions and/or people. These proposals have already been obliged to demonstrate that they have popular support, thus at the end of the day they will benefit more users that other applications. 3.- Applications that promote the cultural and linguistic diversity on the Internet. Promoting cultural and linguistic diversity on the internet is one of the basic objectives of the process. Therefore, the IDNs candidates and the proposals of linguistic communities must never be relegated, for they are those that will bring cultural diversity to the DNS. ICANN should ask itself "Which generic domain until today helped the linguistic diversity of the Net more?" and act accordingly. 4.- Applications that are not contested candidates; that is, there are no other candidates for the same string. ICANN will facilitate the agreement among contested candidates if these are allowed to have more time to negotiate. All these criteria must be subordinated to the rapid and prompt publication of the evaluation. In any case, ICANN should organize the process in such a way tat the first delegations take place later tan in the final period of 2014. ICANN must take into account that the current calendar already has a six month delay regarding the initial calendar. New delays would put the businesses plans of many applications in danger, especially those which are counting on generating admissions from the next year, and this could be fatal for the process. / Should the metering or smoothing be accomplished by downstream metering of application processing (i.e., in the contract execution, pre-delegation testing or delegation phases)? / 1. / How can applications be allocated to a particular timing in contract execution, pre-delegation testing, or delegation in a fair and equitable way?/ 2. / Provide reasoning for selecting this approach./ As the process advances after the Initial Evaluation, there will be more differences in the pace of the steps previous to the Delegation among different candidates. These different paces will not be caused by ICANN itself, but by the capacity of each candidate to pass each step of the process. Therefore, once the batching is carried out, it is only logical to think that candidates should keep advancing in the process as soon as they meet the different requirements. This approach awards the administrative efficiency of each application makes the process fairer and more equitable, and limits ICANN's need to take decisions in favor of some candidates. Another two criteria that ICANN can implement without damaging anyone are: ?a mechanism to allow candidates to declare that they are not interested in being at the beginning of the queue. ?a mechanism to allow candidates to establish priority among its different proposals. / Include a statement describing the level of importance that the order of evaluation and delegation has for your application./ Being in the first groups both of evaluation and delegation is basic for this application. ICANN must take into account that this process was delayed several years before finally being started. Unlike other domain proposals, namely commercial ones, .gal is supported by a huge amount of citizens and entities. The frustration on this community (more than 110 entities of every type and more than 13.000 people) has kept increasing as ICANN proved incapable of meeting its own deadlines. This year hope and excitement returned with the process being started, but if ICANN relegates .gal to the end of queue of the evaluation or of the delegation the community will not understand it, especially if other domains of similar type (for example for other linguistic and cultural communities or for geographical places) are evaluated and implemented on the DNS while .gal continues waiting for Initial Evaluation results. There is no any other application for the Galician language and culture, so .gal does not have any direct competitor on its market. However, if .gal is approved years after other new similar domains are live on the net, this will mean that the Galician linguistic and cultural community will perceive ICANN as an entity that discriminates the Galician cultural community without objective reasons. In this sense, ICANN must take into account that one of the goals of the process is to promote the cultural diversity of the net, opening it up to new users and promoting contents on the net. Relegating cultural and linguistic domains would be a direct move against these goals. -------- Original Message -------- Subject: ICANN News Alert -- ICANN Seeks Input on gTLD Batching Date: Sun, 29 Jul 2012 19:45:06 -0400 From: ICANN News Alert To: ICANN News Alert http://www.icann.org/en/news/announcements/announcement-29jul12-en.htm ------------------------------------------------------------------------ ICANN Seeks Input on gTLD Batching 29 July 2012 Opportunity for Community Input: Processing of New gTLD Applications At the Prague ICANN meeting, the new gTLD Program Committee decided to terminate Digital Archery, and instructed ICANN staff to proceed with the initial evaluation of applications as quickly as possible. This evaluation is in progress based on a tentative project plan that foresees the processing of applications in a single batch, and simultaneous release of results. ICANN believes this approach is consistent with the constraints that various parts of the community have in performing their respective roles in the evaluation process, and with the feedback received from the community at the Prague meeting. This comment opportunity seeks input on requirements for an evaluation and delegation process consistent with previous root zone scaling discussions of smooth delegations, adding no more than 1,000 new gTLDs per year. This outcome can be achieved by the: 1. timing of the release of evaluation results to applicants, 2. timing of the release of applications into the pre-delegation steps of contract execution and pre-delegation testing, 3. metering of delegations of new gTLDs into the root zone. ICANN is committed to executing the evaluation and delegation process in a way that is equitable and meets ICANN's commitment to ensuring the security and stability of the DNS, consistent with previously established root zone scaling goals. Please write to newgtld-input at icann.org with your input. Comments received by 19 August 2012 (UTC 00:00) will be considered. Background The concept of batching has been a part of the Applicant Guidebook since its first draft. Batching accomplishes three goals: 1. Better management of the evaluation process by placing an upper bound on the number of evaluators necessary and the number of parallel evaluations occurring at any one time. 2. Release of evaluation results to applicants according to a predictable schedule. 3. Delegation of TLDs at a rate acceptable to the technical community, consistent with the root zone scaling discussion. Based on the definitive information that ICANN now has about the pool of applications, and work on the evaluations to date, this comment process seeks input to meet requirements for goals #2 and #3. Leading up to and during ICANN's meeting in Prague, the applicant and community positions on requirements for batching schemes that would control the evaluation, communication and delegation of applications were reported to be: 1. The batching solution has to be equitable. 2. The evaluation results have to be announced at the same time. 3. Successful applications should proceed to delegation phase without undue delays. 4. Delegation to the root must be at a smooth rate and must not exceed 1,000 per year. 5. The GAC is planning to issue early warnings shortly after the Toronto ICANN meeting in October 2012. 6. Consideration by the GAC of issues concerning GAC advice on contentious applications is not expected to be finalized before the Beijing meeting in April 2013. During the root scaling discussion, it was agreed that ICANN would not delegate TLDs at a rate greater than 1,000 per year. This is because the primary challenge with maintaining root zone stability is controlling the rate of change to the root zone system and not the size of the root zone itself, meaning delegation should not occur at a rate of 1,000 delegations on a single day. In Prague, the batching and prioritization method known as Digital Archery was terminated and eliminated from further consideration. Recent Developments Initial evaluation of new gTLD applications is underway. Applications are being distributed to evaluators in a way that enables efficient processing. ICANN has conducted pilot evaluations and had discussions with evaluators to accelerate the evaluation schedule. As a result of these discussions, the evaluation teams have committed to accelerate the evaluations substantially, while processing them in a single batch. In Prague, a methodology was discussed where the smooth delegation of applications could occur by first releasing applications that passed initial evaluation without the need for clarifying questions, then releasing applications in order of the number of clarifying questions required, from fewest to highest. After analysis, this methodology proved unworkable because 80% to 90% of the total evaluation time is required to form and ask clarifying questions, so little smoothing would result. The current plan indicates that initial evaluation of all applications, processed in a "single batch", can be completed in 11-12 months, possibly less ? resulting in publication of results in June-July 2013. /Note: It is planned that regular updates to applicants during the evaluation period will be provided. In addition to written reports, ICANN is looking into the use of a webinar / conference call format to deliver updates./ For applicants, releasing results in a single batch would mean that the first delegations would occur in late third quarter of 2013, six months later than originally expected. Implications of GAC timing: The GAC plans to "issue any Early Warnings shortly after the Toronto ICANN meeting, in October 2012," meaning that Early Warnings would be received within the currently planned single evaluation period. Also, the GAC "is considering the implications of providing any GAC advice on gTLD applications. These considerations are not expected to be finalized before the Beijing meeting in April 2013." This is shortly before the currently planned announcement of initial evaluation results (i.e., the schedule without additional accelerations beyond those stated above). Statement of the Issue While there will be some natural smoothing as applications take different paths through objections and contention resolution processes, there will still be a requirement for some method of metering applications into the delegation process. This is due to the relatively high number of applications that may reach pre-delegation steps at essentially the same time. A metering method has not yet been determined and will need to be developed. Questions to be answered by comments Submitted comments should specifically answer each of the following questions: 1. Should the metering or smoothing consider releasing evaluation results, and transitioning applications into the contract execution and pre-delegation testing phases, at different times? 1. How can applications be allocated to particular release times in a fair and equitable way? 2. Would this approach provide sufficient smoothing of the delegation rate? 3. Provide reasoning for selecting this approach. 2. Should the metering or smoothing be accomplished by downstream metering of application processing (i.e., in the contract execution, pre-delegation testing or delegation phases)? 1. How can applications be allocated to a particular timing in contract execution, pre-delegation testing, or delegation in a fair and equitable way? 2. Provide reasoning for selecting this approach. 3. Include a statement describing the level of importance that the order of evaluation and delegation has for your application. Please write to newgtld-input at icann.org with your input. Comments received by 19 August 2012 (UTC 00:00) will be considered. This message was sent to manuel.vilas at puntogal.org from: ICANN | 4676 Admiralty Way Suite 330 | Marina del Rey, CA 90292-6601 Email Marketing by iContact - Try It Free! Manage Your Subscription From tee1and2 at comcast.net Sun Aug 12 20:40:17 2012 From: tee1and2 at comcast.net (Tim Greer) Date: Sun, 12 Aug 2012 15:40:17 -0500 Subject: [Newgtld-input] Input on gTLD Batching Message-ID: <008b01cd78ca$afb2f400$0f18dc00$@comcast.net> I support the ALAC Statement on the IDN Prioritization in the New gTLD Program Targeted at the ICANN Board published at the following url : http:// atlarge-lists.icann.org/pipermail/idn-wg/attachments/20120731/ec8764c7/ALACS tatementontheIDNPrioritizationintheNewgTLDProgramTargetedattheICANNBoard-000 1.pdf Regards Tim Greer Murfreesboro, TN 37130 USA From TomDB at combellgroup.com Mon Aug 13 16:57:21 2012 From: TomDB at combellgroup.com (Tom De Bast) Date: Mon, 13 Aug 2012 16:57:21 +0000 Subject: [Newgtld-input] new gTLD input Message-ID: <552872F2FE5BBF4887FBA0D206A012930102A0D832@EXCOM01> Please find our comments/new gTLD input in attachment (PDF). Regards Tom De Bast Combell Group NV/SA Applicant for the .GENT TLD [Beschrijving: Combell logo] Tom De Bast Business Development Manager - permanent representative of NERUS VOF E-mail: tom.debast at combellgroup.com Mobile: +32 (0) 474 813 823 Combell Group NV - Skaldenstraat 121 - 9042 Gent - Belgium http://www.combell.com This e-mail may contain information which is privileged or confidential. If you received this e-mail in error, please notify us immediately by e-mail or telephone and delete the e-mail without copying or disclosing its contents to any other person. -------------- next part -------------- Please find our comments/new gTLD input in attachment (PDF). Regards Tom De Bast Combell Group NV/SA Applicant for the .GENT TLD [1]Beschrijving: Combell logo Tom De Bast Business Development Manager - permanent representative of NERUS VOF E-mail: [2]tom.debast at combellgroup.com Mobile: +32 (0) 474 813 823 Combell Group NV - Skaldenstraat 121 - 9042 Gent - Belgium [3]http://www.combell.com This e-mail may contain information which is privileged or confidential. If you received this e-mail in error, please notify us immediately by e-mail or telephone and delete the e-mail without copying or disclosing its contents to any other person. References 1. http://www.combell.com/ 2. mailto:tom.debast at combellgroup.com 3. http://www.combell.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 5719 bytes Desc: image001.png Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120813/3bb9a40a/image001.png -------------- next part -------------- A non-text attachment was scrubbed... Name: ICANN comments.pdf Type: application/pdf Size: 106034 bytes Desc: ICANN comments.pdf Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120813/3bb9a40a/ICANNcomments.pdf From teeraphong.mahatham at scb.co.th Wed Aug 15 03:04:25 2012 From: teeraphong.mahatham at scb.co.th (Teeraphong March Mahatham) Date: Wed, 15 Aug 2012 10:04:25 +0700 Subject: [Newgtld-input] ICANN Seeks input on gTLD Batching References: Message-ID: <006901cd7a92$ad302580$07907080$@scb.co.th> Dear ICANN, We appreciate the opportunity to voice our comment regarding the application process. We actually have one more comment: one way to achieve the fair and equitable way, perhaps we can do the round-robin of either the continents or the countries of the applicant - similar to the previously-cancelled batching process. This way applications around the world would be considered in a well distributed way and hence would benefit the world's internet user more effectively. Best Regards, Teeraphong March Mahatham VP, Change Program - Project Manager | SCB | T: +66-2-544-7290 | teeraphong.mahatham at scb.co.th From: Teeraphong March Mahatham [mailto:teeraphong.mahatham at scb.co.th] Sent: Monday, August 13, 2012 1:21 PM To: 'newgtld-input' Subject: RE: ICANN Seeks input on gTLD Batching Dear ICANN, With us, the applicant for .SCB, we prefer to be evaluated and delegated as soon as possible. Please see our comments: 1. Should the metering or smoothing consider releasing evaluation results, and transitioning applications into the contract execution and pre-delegation testing phases, at different times? o How can applications be allocated to particular release times in a fair and equitable way? 1. Please categorize the applied names and the nature of the business - similar ones should be considered at the same time. Branding TLD might be considered first. o Would this approach provide sufficient smoothing of the delegation rate? 1. Yes, you can control the rate o Provide reasoning for selecting this approach. 1. Some applicants would be able to use the names early - benefiting the overall usage of internet users. 2. Should the metering or smoothing be accomplished by downstream metering of application processing (i.e., in the contract execution, pre-delegation testing or delegation phases)? o How can applications be allocated to a particular timing in contract execution, pre-delegation testing, or delegation in a fair and equitable way? o Provide reasoning for selecting this approach. o Include a statement describing the level of importance that the order of evaluation and delegation has for your application. 1. The order of evaluation and delegation is very important to us as we are very serious in using the applied TLD. We are the largest market-cap bank in Thailand and the applied TLD has been considered for various downstream strategies, processes and, activities for us and for Thai people & other people in the world. We hence would request you please proceed the evaluation as soon as possible. The Brand TLD (like us, .SCB) should be easier one for you to evaluate. 2. We would suggest you can set up some rules to evaluate the delegated TLD every year - if they break the rules then ICANN has right to negotiate to take it back. This way, you can loosen your evaluation period this time - just quickly evaluate and delegate to applicants. Best Regards, Teeraphong March Mahatham VP, Change Program - Project Manager | SCB | T: +66-2-544-7290 | teeraphong.mahatham at scb.co.th From: newgtld-input [mailto:newgtld-input at icann.org] Sent: Monday, July 30, 2012 5:21 AM To: undisclosed-recipients: Subject: ICANN Seeks input on gTLD Batching Dear Applicant: Opportunity for Community Input: Processing of New gTLD Applications At the Prague ICANN meeting, the new gTLD Program Committee decided to terminate Digital Archery, and instructed ICANN staff to proceedwith the initial evaluation of applications as quickly as possible. This evaluation is in progress based on a tentative project plan that foresees the processing of applications in a single batch, and simultaneous release of results. ICANN believes this approach is consistent with the constraints that various parts of the community have in performing their respective roles in the evaluation process, and with the feedback received from the community at the Prague meeting. This comment opportunity seeks input on requirements for an evaluation and delegation process consistent with previous root zone scaling discussions of smooth delegations, adding no more than 1,000 new gTLDs per year. This outcome can be achieved by the: 1. timing of the release of evaluation results to applicants, 2. timing of the release of applications into the pre-delegation steps of contract execution and pre-delegation testing, 3. metering of delegations of new gTLDs into the root zone. ICANN is committed to executing the evaluation and delegation process in a way that is equitable and meets ICANN's commitment to ensuring the security and stability of the DNS, consistent with previously established root zone scaling goals. Please write to new gtld - input @ icann . org with your input. Comments received by 19 August 2012 (UTC 00:00) will be considered. Background The concept of batching has been a part of the Applicant Guidebook since its first draft. Batching accomplishes three goals: 1. Better management of the evaluation process by placing an upper bound on the number of evaluators necessary and the number of parallel evaluations occurring at any one time. 2. Release of evaluation results to applicants according to a predictable schedule. 3. Delegation of TLDs at a rate acceptable to the technical community, consistent with the root zone scaling discussion. Based on the definitive information that ICANN now has about the pool of applications, and work on the evaluations to date, this commentprocess seeks input to meet requirements for goals #2 and #3. Leading up to and during ICANN's meeting in Prague, the applicant and community positions on requirements for batching schemes thatwould control the evaluation, communication and delegation of applications were reported to be: 1. The batching solution has to be equitable. 2. The evaluation results have to be announced at the same time. 3. Successful applications should proceed to delegation phase without undue delays. 4. Delegation to the root must be at a smooth rate and must not exceed 1,000 per year. 5. The GAC is planning to issue early warnings shortly after the Toronto ICANN meeting in October 2012. 6. Consideration by the GAC of issues concerning GAC advice on contentious applications is not expected to be finalized before the Beijing meeting in April 2013. During the root scaling discussion, it was agreed that ICANN would not delegate TLDs at a rate greater than 1,000 per year. This is because the primary challenge with maintaining root zone stability is controlling the rate of change to the root zone system and not the size of the root zone itself, meaning delegation should not occur at a rate of 1,000 delegations on a single day. In Prague, the batching and prioritization method known as Digital Archery was terminated and eliminated from further consideration. Recent Developments Initial evaluation of new gTLD applications is underway. Applications are being distributed to evaluators in a way that enables efficient processing. ICANN has conducted pilot evaluations and had discussions with evaluators to accelerate the evaluation schedule. As a result of thesediscussions, the evaluation teams have committed to accelerate the evaluations substantially, while processing them in a single batch. In Prague, a methodology was discussed where the smooth delegation of applications could occur by first releasing applications that passed initial evaluation without the need for clarifying questions, then releasing applications in order of the number of clarifying questions required, from fewest to highest. After analysis, this methodology proved unworkable because 80% to 90% of the total evaluation time is required to form and ask clarifying questions, so little smoothing would result. The current plan indicates that initial evaluation of all applications, processed in a "single batch", can be completed in 11-12 months, possibly less - resulting in publication of results in June-July 2013. Note: It is planned that regular updates to applicants during the evaluation period will be provided. In addition to written reports, ICANN is looking into the use of a webinar / conference call format to deliver updates. For applicants, releasing results in a single batch would mean that the first delegations would occur in late third quarter of 2013, six months later than originally expected. Implications of GAC timing: The GAC plans to "issue any Early Warnings shortly after the Toronto ICANN meeting, in October 2012," meaning that Early Warnings would be received within the currently planned single evaluation period. Also, the GAC "is considering the implications of providing any GAC advice on gTLD applications. These considerations are not expected to be finalized before the Beijing meeting in April 2013." This is shortly before the currently planned announcement of initial evaluation results (i.e., the schedule without additional accelerations beyond those stated above). Statement of the Issue While there will be some natural smoothing as applications take different paths through objections and contention resolution processes, there will still be a requirement for some method of metering applications into the delegation process. This is due to the relatively high number of applications that mayreach pre-delegation steps at essentially the same time. A metering method has not yet been determined and will need to be developed. Questions to be answered by comments Submitted comments should specifically answer each of the following questions: 1. Should the metering or smoothing consider releasing evaluation results, and transitioning applications into the contract execution and pre-delegation testing phases, at different times? o How can applications be allocated to particular release times in a fair and equitable way? o Would this approach provide sufficient smoothing of the delegation rate? o Provide reasoning for selecting this approach. 2. Should the metering or smoothing be accomplished by downstream metering of application processing (i.e., in the contract execution, pre-delegation testing or delegation phases)? o How can applications be allocated to a particular timing in contract execution, pre-delegation testing, or delegation in a fair and equitable way? o Provide reasoning for selecting this approach. o Include a statement describing the level of importance that the order of evaluation and delegation has for your application. Please write to newgtld - input @ icann . org with your input. Comments received by 19 August 2012 (UTC 00:00) will be considered. Regards, New gTLD Team DISCLAIMER: This e-mail is intended solely for the recipient(s) name above. If you are not the intended recipient, any type of your use is prohibited. Any information, comment or statement contained in this e-mail, including any attachments (if any) are those of the author and are not necessarily endorsed by the Bank. The Bank shall, therefore, not be liable or responsible for any of such contents, including damages resulting from any virus transmitted by this e-mail. From obi.obiora.jeffrey at gmail.com Wed Aug 15 08:34:33 2012 From: obi.obiora.jeffrey at gmail.com (Obi Jeffrey) Date: Wed, 15 Aug 2012 01:34:33 -0700 Subject: [Newgtld-input] New gTLD order Suggestions Message-ID: The order of submission should count. The time stanp (of submissions of applications) should help ease that. If that's insufficient, an online vote/poll could suffice, but that would only favour those individuals/firms with existing heavy internet presence like Apple, Google, etc. Also, to avoid any disorder, so to say, not all domain names should be registered. Some seem serious and necessary, in my opinion. Names such as .book, .music, .art, .news, .blog, .app and so on, seem to me, very applicable and somewhat exciting. Also, names that may not exactly apply do any section of the demography (age groups) or the wide range of known personality types may be considered less important (or not important depending on your judgement based on the applications) as their applications could be reviewed and a priority list (so to say) may be developed from them. This would help in the creation of an acceptable and understandable order of the release of domain names. Thank you. -Obi Obiora Jeffrey (Lagos, Nigeria) -- prOversE' 47 From avri at acm.org Wed Aug 15 08:39:51 2012 From: avri at acm.org (Avri Doria) Date: Wed, 15 Aug 2012 09:39:51 +0100 Subject: [Newgtld-input] A simple and fair method for metering Message-ID: Dear ICANN, I wish to offer the following relatively simple method/algorithm for metering. - After initial evaluation is competed for all applicants, all successful applicants are grouped, in the sense of hash code chunking, according to the birth day-of-year of the primary applicant (1-367; i.e. including Feb 29). That means there will be an ordering of the applications into 367 different groups. Those born Jan1 get into the root first, those on Dec 31 last. (An alternate ordering would be that that the day the announcement is made on the full set of initial evaluation represents the first to be processed and then continue, coming back to day 1 after day 367.) As this is information that is already set and already in the application, there is no chance, drawing or process used other than information ICANN already has. Also no one had an opportunity to set their birth day-of-year so as to gain undue advantage. - as each extended evaluation, community priority or objection processed applicant is successful, they are added to the group corresponding to their birth day-of-year. - Modulo the initial day-of-year based group, if Jan 1 is not used as the initial point in the ordering, the ready applications in the earliest group are put into the root. - If a second ordering is required within a group because there are too many in one day-of-year based group for a smooth process, the year of birth is used to order the group - oldest primary applicant gets their TLD into the root before others in the group. The second and third rules in this process are meant to keep those applications who have to got through extended evaluation, community priority or objection processing and who are successful from having to wait until the end of the process. Especially in the case of community priority evaluations, to force communities to wait until all others have already been deployed is unfair. Note: there are possibly other numbers that are part of the application and its meta-data that could be used in a similar hashing process if day-of-year is somehow problematic. Te most important elements are that it be a fair process that does not penalize applicants for a requirements for further processing. thanks Avri Doria submitted as an individual contributor to the process From Elisa.Cooper at markmonitor.com Wed Aug 15 16:45:48 2012 From: Elisa.Cooper at markmonitor.com (Elisa Cooper) Date: Wed, 15 Aug 2012 16:45:48 +0000 Subject: [Newgtld-input] MarkMonitor Comments on the Processing of New gTLD Applications Message-ID: MarkMonitor requests that the Initial Evaluation results for all applications be released at one time, which is now expected to be in June / July 2013. ? If all applications pass Initial Evaluation, allow all 1179 uncontested applications to move through contract negotiations. It should be noted that the number of uncontested applications may?actually decrease as examiners identify additional contested strings and applications are withdrawn. ? Continue processing these uncontested applications on a first-come, first-served basis, so that if no changes to the contract are negotiated, uncontested applicants may continue through the process. We request that additional legal resources be identified to alleviate any potential bottlenecks. This could be accomplished by either adding additional staff or relying on the services of outside legal counsel. ? If contracts for all 1179 applications are quickly signed, it is possible that more than 1000 extensions could be added to the root in?a year, although based on recent guidance from the SSAC, this does?not seem to pose a threat to Stability or Security but rather a risk to current service levels which could likely be addressed by increasing the necessary resources. Again, we recommend that additional technical resources are identified to alleviate any bottlenecks that might occur as a result of pre-delegation testing or the delegation of the gTLD into the root zone database. ? The remaining 751 contested applications will need to move through the contention process, which will take up to another 6 months post Initial Evaluation results, according the Guidebook. ? MarkMonitor opposes the arbitrary metering of applications. And while we appreciate that processing 1930 applications represents complexities that are new to ICANN, we urge ICANN to add additional headcount or supplement staff with outside resources where necessary to ensure that bottlenecks do not ensue at any stage of the process. ? We believe that this is the only equitable solution. Regards, Elisa Elisa Cooper Director of Product Marketing MarkMonitor From avri at acm.org Wed Aug 15 16:58:44 2012 From: avri at acm.org (Avri Doria) Date: Wed, 15 Aug 2012 17:58:44 +0100 Subject: [Newgtld-input] Another hashing function for simple metering Message-ID: <70048675-7DCD-4D34-AFC1-81B1745838FD@acm.org> It occurred to me that there might be objections to the birthday as the hash key. Another possible key: Use a technique based on the time of day when the submitt key was pressed, no matter which day and create your hashing function based on time of day modulo the number of separate buckets, that would be as good as the day-of-birth method. Suppose: N = number of buckets, e.g. 100 buckets for 100 months of 20 applications per month Modulo N(seconds or minutes since midnight UTC button was pressed) As I indicated, I am sure there are all sorts of numbers already attached to each application, so the general notion is pick a good number and use it modulo the number of buckets that work best for the metering process. Avri Doria From masha at cctld.ru Thu Aug 16 09:10:05 2012 From: masha at cctld.ru (Maria Kolesnikova) Date: Thu, 16 Aug 2012 13:10:05 +0400 Subject: [Newgtld-input] (no subject) Message-ID: On behalf of Andrei Kolesnikov, CEO, Coordination Center for TLD RU: 1. As ICANN received 1,930 applications for new gTLDs, while the annual number of to be delegated ones is set at a level of 1,000, all the applications should be classified into two batches with the gap between their term of delegation being 1 year. According to preliminary estimates, the applied-for gTLDs from the first batch might be delegated in late 2013, and, subsequently, the second batch might be delegated within 2014. 2. Yes, we believe it is possible to grant the applicants with extra time between the publication of application evaluation results and the launch of the Transition to Delegation stage. That would enable them to complete complementary organizational activities to get their websites, SRSs, set of policies, etc. for the start of fully functional operations in the capacity of Registry Operator of the applied-for new gTLD, if needed. 3. We propose a simultaneous publication of all the application evaluation results (at the end of Initial Evaluation). This is the most critical matter for the applicants. The applications should be broken into two groups: 1) the ones included in the Contention sets and 2) non-competing applications. 4. As concerns non-competing applications, we believe it is imperative to consider in the first batch the following ones: 1) community-based applications, as they exhibit an emerged need of a strictly identified community in such a gTLD; 2) geoTLDs, as they display an official support and keenness to have such a domain by the respective Government and the geographic community; 3) gTLDs whose mission statements explicitly hold they are socially significant open projects. While such domains may fall short of representing a clearly identified community, they appear critical for boosting the diversity of ways the Internet is used by various social groups (e.g. .???? etc.) That said, we think that where gTLDs matching the above criteria prove to be IDNs, this should be considered an extra plus, for IDNs are particularly important to developing nations and countries where English is not widely spoken. That is to say, where there have been submitted applications with equal potential, in the course of their processing priority should be given to IDNs. 5. It is applications for ?close-end? gTLDs that are set to service corporate needs or brands which should be granted the lowest priority and be delegated in the second batch. Such gTLDs include those wherein registration of the 2nd - and 3rd-level domains is narrowed to a very selected array of users and/or where the Registry Operator (which concurrently exercises the Registrar?s functions) is going to register domains solely for its own needs. As well, the second batch should also include all competing applications (Contention sets) and those opted-out by applicants ready to postpone their delegation for a year. 6. We believe the contract execution, pre-delegation testing or delegation phases should not be used to classify the applications into batches. Rather, these phases should be implemented per the description in AGB, RA and IANA procedure. Since the moment of signing Registry Agreement, the new gTLD Registry Operator should be fully ready, both organizationally and technically, to exercise its functions and interact with its customers. So, it seems inappropriate to split these phases in a special way. From henry.chan at hkirc.hk Thu Aug 16 09:39:28 2012 From: henry.chan at hkirc.hk (Henry Chan) Date: Thu, 16 Aug 2012 17:39:28 +0800 Subject: [Newgtld-input] Comments on Processing of New gTLD Applications Message-ID: <007501cd7b93$0813d9a0$183b8ce0$@hkirc.hk> Dear new gTLD Program Committee, Hong Kong Internet Registration Corporation Limited (HKIRC), the registry of the .hk and .??ccTLDs, submits the following comments on the processing of new gTLD applications on behalf of the .MTR new gTLD application, in HKIRC's capacity as the application's consultant. We also attached a PDF version of the same comment for your use. Overall comment: HKIRC would like to commend ICANN on continuously seeking and addressing to inputs from the community, especially from the applicants, regarding the application process. HKIRC also appreciates the termination of the batching process in the form of "Digital Archery", in response to the negative feedback shared by majority of the applicant community. HKIRC supports the idea of evaluating all the applications in a single batch and announcing all the Initial Evaluation results simultaneously, as suggested by the community during the Prague ICANN meeting. We acknowledge the fact that the time required for the Initial Evaluation might be lengthened, yet, we regard the likely delay in conclusion of the Initial Evaluation process a justifiable sacrifice for the sake of fairness to all applicants. HKIRC acknowledges that the Governmental Advisory Committee (GAC) will only be able to finalise the considerations for providing any GAC advice on gTLD applications by April 2013 and that the clearance from GAC advice is a component of the gTLD application process. HKIRC appreciates that ICANN is not planning to delegate TLDs at a rate greater than 1,000 per year, due to the challenge with maintaining root zone stability by controlling the rate of change to the root zone system. However, HKIRC is of the view that there shall be a natural smoothing of applications ready to enter the stages of pre-delegation testing and delegation. There are currently 751 contended applications out of the total of 1,927 (with deduction of the three application withdrawals as of 10 August 2012). Potentially, there shall be less than 1,176 applications ready to enter the next stages right after Initial Evaluation concluded and the number is very close to the 1,000 per year delegation rate mentioned above. ICANN should be able to delegate all of these TLDs within a one-year time frame. By replying to the three questions ICANN posted for this comment opportunity, HKIRC shall propose below a metering method for delegating the TLDs within the one-year time frame. Reply to the specific questions: 1. Should the metering or smoothing consider releasing evaluation results, and transitioning applications into the contract execution and pre-delegation testing phases, at different times? a. How can applications be allocated to particular release times in a fair and equitable way? b. Would this approach provide sufficient smoothing of the delegation rate? c. Provide reasoning for selecting this approach. HKIRC is of the view that the release of Initial Evaluation results for all applications should be simultaneous. As mentioned before, there shall be a natural smoothing of the 1,927 applications where at least 751 of them will be taking different paths through objections and contention resolution processes. The approximate 1,000 applications should all be transitioned into the contract execution and pre-delegation testing phases at the same time and handled within the one year time frame. This arrangement shall ensure that the release time of the applications is fair and equitable (it is in fact equal). 2. Should the metering or smoothing be accomplished by downstream metering of application processing (i.e., in the contract execution, pre-delegation testing or delegation phases)? a. How can applications be allocated to a particular timing in contract execution, pre-delegation testing, or delegation in a fair and equitable way? b. Provide reasoning for selecting this approach. HKIRC would suggest that all ?brand?, or specifically, trademark TLD applications that will be reserved for internal use and will not be open for registration (i.e. as closed registry) shall be handled first in contract execution, pre-delegation testing or delegation phases on a first-come, first-served basis. This arrangement is in fact a common and proven practice in the domain name industry, where trademark holders are usually given the highest priority when a new TLD is introduced via a "sunrise" registration period. The reason behind such arrangement is that the protection of trademarks and intellectual property has always been considered the most important priority to the community, and that the ICANN new gTLD process has incorporated and should continue maintaining elements that protect the interests of trademark and intellectual property owners. Moreover, we expect that the work required for executing the contracts and testing for delegation should not be controversial and should be straightforward with the ?brand? and closed TLD registries. ICANN would be given a good chance to process these TLDs in a relatively short period of time and learn from the experience, so that when it moves forward to process the ?commercial? TLD delegations after this phase, it can ramp up the speed easily and smoothly. Processing the ?brand? TLD delegation also posts minimal to zero impact to the ?commercial? TLDs offering registration services, where they are more likely to be impacted by the launch time of their peers. Our proposed priority should not be given to closed registries with generic and non-trademarked applied-for strings. As their TLDs are not trademarks, they have no good reason to be considered eligible for the priority as proposed above. After all the ?brand? TLDs are delegated, or when resource is available for ICANN to start taking up the work for other ?types? of applications, other applications shall be handled on a first-come, first-served basis. 3. Include a statement describing the level of importance that the order of evaluation and delegation has for your application. We are of the view that it is of utmost importance for our application to be evaluated simultaneously with others and to have the Initial Evaluation results released also at the same time with others. As ?MTR? is an established, rightful and well recognised trademark of MTR Corporation Limited, we consider that it is important and equitable for .MTR to be delegated at the first phase of the one-year time frame after the release of the Initial Evaluation results. Regards, Henry CHAN Manager, Business Development Hong Kong Internet Registration Corporation Limited (HKIRC) Tel: +852 2319 3830 Mobile: +852 9034 0174 Fax: +852 2319 2626 https://www.hkirc.hk -------------- next part -------------- A non-text attachment was scrubbed... Name: Comments on Processing of New gTLD.pdf Type: application/pdf Size: 39434 bytes Desc: not available Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120816/98283330/CommentsonProcessingofNewgTLD.pdf From andrei at cctld.ru Thu Aug 16 09:41:42 2012 From: andrei at cctld.ru (Andrei Kolesnikov) Date: Thu, 16 Aug 2012 13:41:42 +0400 Subject: [Newgtld-input] input on gTLD batching from Russia Message-ID: <003001cd7b93$5b940a50$12bc1ef0$@ru> 1. As ICANN received 1,930 applications for new gTLDs, while the annual number of to be delegated ones is set at a level of 1,000, all the applications should be classified into two batches with the gap between their term of delegation being 1 year. According to preliminary estimates, the applied-for gTLDs from the first batch might be delegated in late 2013, and, subsequently, the second batch might be delegated within 2014. 2. Yes, we believe it is possible to grant the applicants with extra time between the publication of application evaluation results and the launch of the Transition to Delegation stage. That would enable them to complete complementary organizational activities to get their websites, SRSs, set of policies, etc. for the start of fully functional operations in the capacity of Registry Operator of the applied-for new gTLD, if needed. 3. We propose a simultaneous publication of all the application evaluation results (at the end of Initial Evaluation). This is the most critical matter for the applicants. The applications should be broken into two groups: (a) the ones included in the Contention sets and (b) non-competing applications. 4. As concerns non-competing applications, we believe it is imperative to consider in the first batch the following ones: (a) community-based applications, as they exhibit an emerged need of a strictly identified community in such a gTLD; (b) geoTLDs, as they display an official support and keenness to have such a domain by the respective Government and the geographic community; (c) gTLDs whose mission statements explicitly hold they are socially significant open projects. While such domains may fall short of representing a clearly identified community, they appear critical for boosting the diversity of ways the Internet is used by various social groups (e.g. .???? etc.) That said, we think that where gTLDs matching the above criteria prove to be IDNs, this should be considered an extra plus, for IDNs are particularly important to developing nations and countries where English is not widely spoken. That is to say, where there have been submitted applications with equal potential, in the course of their processing priority should be given to IDNs. 5. It is applications for "close-end" gTLDs that are set to service corporate needs or brands which should be granted the lowest priority and be delegated in the second batch. Such gTLDs include those wherein registration of the 2nd - and 3rd-level domains is narrowed to a very selected array of users and/or where the Registry Operator (which concurrently exercises the Registrar's functions) is going to register domains solely for its own needs. As well, the second batch should also include all competing applications (Contention sets) and those opted-out by applicants ready to postpone their delegation for a year. 6. We believe the contract execution, pre-delegation testing or delegation phases should not be used to classify the applications into batches. Rather, these phases should be implemented per the description in AGB, RA and IANA procedure. Since the moment of signing Registry Agreement, the new gTLD Registry Operator should be fully ready, both organizationally and technically, to exercise its functions and interact with its customers. So, it seems inappropriate to split these phases in a special way. Regards, Andrei Kolesnikov Director, Coordination Center for TLD RU From Ronald.Schwaerzler at punktwien.at Thu Aug 16 09:54:38 2012 From: Ronald.Schwaerzler at punktwien.at (=?Windows-1252?Q?Ronald_Schw=E4rzler?=) Date: Thu, 16 Aug 2012 09:54:38 +0000 Subject: [Newgtld-input] Comments of Geographical Names gTLD Applicants Message-ID: Ladies and Gentlemen, Being CEO of punkt.wien GmbH, the company that applied for ".wien" gTLD I (in brief) encourage you to transfer any applications to next stages as soon as possible! Best regards DI Ronald Schw?rzler Gesch?ftsf?hrer [cid:AD5061F9-C0C2-4E00-86AE-7CC556DA5B57] punkt.wien GmbH ronald.schwaerzler at punktwien.at A-1141 Wien, Matznergasse 17, Tel. +43 1 98116-101, Mobile +43 681 20895522, Fax +43 1 98116-118 Sitz der Gesellschaft: Wien; Firmenbuchgericht: Handelsgericht Wien, FN 367498p Diese E-Mail inklusive aller Anh?nge ist vertraulich und k?nnte bevorrechtigtem Schutz unterliegen. Wenn Sie nicht der beabsichtigte Adressat sind, informieren Sie bitte den Absender unverz?glich, l?schen Sie alle Kopien von Ihrem System und ver?ffentlichen Sie oder nutzen Sie die Information keinesfalls, gleich zu welchem Zweck Notice: This e-mail and any attachments are confidential and may be privileged. If you are not the intended recipient, notify the sender immediately, destroy all copies from your system and do not disclose or use the information for any purpose. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The following comment is a joint comment of the signing applicants who applied for a New gTLD that is a Geographical Name. Introduction Geographical Name gTLDs have Governmental Support Geographical Names as gTLDs are clearly defined by the gTLD Applicant Guidebook, paragraph 2.2.1.4.2 Geographic Names Requiring Government Support. Geographical Name gTLDs (Geo-TLDs in the following) have in common that the string is a meaningful representation or abbreviation of a geographical name that is protected by national laws. Geo-TLDs have also in common that the respective operator for the string is or is being supported by the relevant sovereign local and national government(s). By these least common denominators the Geo-TLDs are in the Public Interest. 66 Applicants claimed the ?Geographical Name? status As of 13 June 2012 66 applications that claimed the Geographical Name Top-Level Domains status have been published. The Geo-TLD applications range from TLDs for large cities and regions to small cultural and language TLDs. The applicants and respective gTLD operators range from governments to non-for-profit entities and commercial companies. The business models range from a single registrant regime (only for use by the government) via restricted registrations (only for individuals of the community) to free domain name registrations for everyone. Geo-TLDs have already expressed their opinion to ICANN At least a dozen City and Regional Governments have written to ICANN during the last months to support a preferred processing of Geo-TLDs but ICANN neither published these letters nor gave a feedback. In order to follow ICANN?s request to answer specific questions on processing applications we would like to comment as follows: Should the metering or smoothing consider releasing evaluation results, and transitioning applications into the contract execution and pre-delegation testing phases, at differenttimes? In order to facilitate a smooth implementation of new gTLDs into the root, uncontested applications that have been successfully evaluated should immediately be directed to ?Transition to Delegation? including publication of the evaluation results for the publicly available part of the applications. A simultaneous release of evaluation results of all applications is unnecessary and contraproductive since it creates further delays for applicants. How can applications be allocated to particular release times in a fair and equitable way? A fair and equitable way would be to delegate applications in an order that serves the public interest. Such an order should prioritize uncontested applications that have a special public interest status such as a) Geographical Name, b) Community or c) IDN. The sequencing for delegation should follow a round-robin process per ICANN region. As a second step an ICANN region based round-robin should be conducted with uncontested applications from single applicants and portfolio applicants who can choose one string as their preferred one, assuming this string has neither objections nor contention. The round-robin will be continued as long as necessary. Applications in extended evaluation, objection, contention and with GAC interaction will be added to the round-robin pool as soon as their objection and/or contention has been completed. Would this approach provide sufficient smoothing of the delegation rate? Our described approach would not only serve the public interest and take the interests of all applicants into respect, it would also allow creating new gTLD success stories for ICANN. Such events are desperately needed to reinforce public interest, trust and reliability in ICANN and are according to ICANN?s mission. Should the metering or smoothing be accomplished by downstream metering of application processing (i.e., in the contract execution, pre-delegation testing or delegation phases)? With the proposed public interest priorization and followed by a round-robin method we do not expect any necessity to downstream delegation rates. Additionally all applicants should be asked if they want to ?opt out? with the consequence of being initially evaluated at a later stage. This could significantly decrease the number of applications to be reviewed in the first instance. How can applications be allocated to a particular timing in contract execution, pre-delegation testing, or delegation in a fair and equitable way? ICANN should forward applications in the ?transition to delegation? status as soon as possible after they have been reviewed successfully in order to facilitate a smooth introduction of new TLDs into the root. Provide reasoning for selecting this approach. The questions should be asked the other way around. Are there any valid reasons why the publication of evaluation results should be withheld to a certain ?reveal date?? Therefore ICANN should process gTLDs down the path as they are ready for the next step. Include a statement describing the level of importance that the order of evaluation and delegation has for your application. Geo-TLDs are very well accepted and popular new gTLD strings, this is common opinion within the ICANN community including GAC. In terms of business planning an early approval of Geo-TLDs is likely to contribute to a maximum economic and political success of the New gTLD program and ICANN?s reputation as well. -------------- next part -------------- Ladies and Gentlemen, Being CEO of punkt.wien GmbH, the company that applied for ".wien" gTLD I (in brief) encourage you to transfer any applications to next stages as soon as possible! Best regards DI Ronald Schw??rzler Gesch??ftsf??hrer [cid:AD5061F9-C0C2-4E00-86AE-7CC556DA5B57] punkt.wien GmbH ronald.schwaerzler at punktwien.at A-1141 Wien, Matznergasse 17, Tel. +43 1 98116-101, Mobile +43 681 20895522, Fax +43 1 98116-118 Sitz der Gesellschaft: Wien; Firmenbuchgericht: Handelsgericht Wien, FN 367498p Diese E-Mail inklusive aller Anh??nge ist vertraulich und k??nnte bevorrechtigtem Schutz unterliegen. Wenn Sie nicht der beabsichtigte Adressat sind, informieren Sie bitte den Absender unverz??glich, l??schen Sie alle Kopien von Ihrem System und ver??ffentlichen Sie oder nutzen Sie die Information keinesfalls, gleich zu welchem Zweck Notice: This e-mail and any attachments are confidential and may be privileged. If you are not the intended recipient, notify the sender immediately, destroy all copies from your system and do not disclose or use the information for any purpose. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The following comment is a joint comment of the signing applicants who applied for a New gTLD that is a Geographical Name. Introduction Geographical Name gTLDs have Governmental Support Geographical Names as gTLDs are clearly defined by the gTLD Applicant Guidebook, paragraph 2.2.1.4.2 Geographic Names Requiring Government Support. Geographical Name gTLDs (Geo-TLDs in the following) have in common that the string is a meaningful representation or abbreviation of a geographical name that is protected by national laws. Geo-TLDs have also in common that the respective operator for the string is or is being supported by the relevant sovereign local and national government(s). By these least common denominators the Geo-TLDs are in the Public Interest. 66 Applicants claimed the ???Geographical Name??? status As of 13 June 2012 66 applications that claimed the Geographical Name Top-Level Domains status have been published. The Geo-TLD applications range from TLDs for large cities and regions to small cultural and language TLDs. The applicants and respective gTLD operators range from governments to non-for-profit entities and commercial companies. The business models range from a single registrant regime (only for use by the government) via restricted registrations (only for individuals of the community) to free domain name registrations for everyone. Geo-TLDs have already expressed their opinion to ICANN At least a dozen City and Regional Governments have written to ICANN during the last months to support a preferred processing of Geo-TLDs but ICANN neither published these letters nor gave a feedback. In order to follow ICANN???s request to answer specific questions on processing applications we would like to comment as follows: Should the metering or smoothing consider releasing evaluation results, and transitioning applications into the contract execution and pre-delegation testing phases, at differenttimes? In order to facilitate a smooth implementation of new gTLDs into the root, uncontested applications that have been successfully evaluated should immediately be directed to ???Transition to Delegation??? including publication of the evaluation results for the publicly available part of the applications. A simultaneous release of evaluation results of all applications is unnecessary and contraproductive since it creates further delays for applicants. How can applications be allocated to particular release times in a fair and equitable way? A fair and equitable way would be to delegate applications in an order that serves the public interest. Such an order should prioritize uncontested applications that have a special public interest status such as a) Geographical Name, b) Community or c) IDN. The sequencing for delegation should follow a round-robin process per ICANN region. As a second step an ICANN region based round-robin should be conducted with uncontested applications from single applicants and portfolio applicants who can choose one string as their preferred one, assuming this string has neither objections nor contention. The round-robin will be continued as long as necessary. Applications in extended evaluation, objection, contention and with GAC interaction will be added to the round-robin pool as soon as their objection and/or contention has been completed. Would this approach provide sufficient smoothing of the delegation rate? Our described approach would not only serve the public interest and take the interests of all applicants into respect, it would also allow creating new gTLD success stories for ICANN. Such events are desperately needed to reinforce public interest, trust and reliability in ICANN and are according to ICANN???s mission. Should the metering or smoothing be accomplished by downstream metering of application processing (i.e., in the contract execution, pre-delegation testing or delegation phases)? With the proposed public interest priorization and followed by a round-robin method we do not expect any necessity to downstream delegation rates. Additionally all applicants should be asked if they want to ???opt out??? with the consequence of being initially evaluated at a later stage. This could significantly decrease the number of applications to be reviewed in the first instance. How can applications be allocated to a particular timing in contract execution, pre-delegation testing, or delegation in a fair and equitable way? ICANN should forward applications in the ???transition to delegation??? status as soon as possible after they have been reviewed successfully in order to facilitate a smooth introduction of new TLDs into the root. Provide reasoning for selecting this approach. The questions should be asked the other way around. Are there any valid reasons why the publication of evaluation results should be withheld to a certain ???reveal date???? Therefore ICANN should process gTLDs down the path as they are ready for the next step. Include a statement describing the level of importance that the order of evaluation and delegation has for your application. Geo-TLDs are very well accepted and popular new gTLD strings, this is common opinion within the ICANN community including GAC. In terms of business planning an early approval of Geo-TLDs is likely to contribute to a maximum economic and political success of the New gTLD program and ICANN???s reputation as well. -------------- next part -------------- A non-text attachment was scrubbed... Name: punktwien klein.png Type: image/png Size: 10520 bytes Desc: punktwien klein.png Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120816/fb926dd7/punktwienklein.png -------------- next part -------------- A non-text attachment was scrubbed... Name: Comments 19 August 2012 GeoTLDs[2].docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 27008 bytes Desc: Comments 19 August 2012 GeoTLDs[2].docx Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120816/fb926dd7/Comments19August2012GeoTLDs2.docx From cigdem.algun at ibb.gov.tr Thu Aug 16 10:29:21 2012 From: cigdem.algun at ibb.gov.tr (=?iso-8859-9?B?x2nwZGVtIEFsZ/xu?=) Date: Thu, 16 Aug 2012 13:29:21 +0300 Subject: [Newgtld-input] ON BEHALF OF DOT ISTANBUL& DOT IST APPLICATIONS... Message-ID: <001701cd7b99$ffce5f20$ff6b1d60$@algun@ibb.gov.tr> Dear New GTld Team, You can find our comments (a joint comment of the signing applicants who applied for a New gTLD that is a Geographical Name) attached for the evaluation process . Best Regards, ?i?dem Alg?n Project Manager of .istanbul& .ist 0090 535 819 30 20 -------------- next part -------------- A non-text attachment was scrubbed... Name: Comments 19 August 2012 GeoTLDs.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 22421 bytes Desc: not available Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120816/24092e5f/Comments19August2012GeoTLDs.docx From harris at cabase.org.ar Thu Aug 16 16:46:48 2012 From: harris at cabase.org.ar (Anthony Harris) Date: Thu, 16 Aug 2012 13:46:48 -0300 Subject: [Newgtld-input] [liaison6c] Progress Report on new gTLD issues raised in Prague Message-ID: <7B63D62900774F61AB6469D2A21FEAEF@harrys> Dear Kurt, Akram and all working in the new gTLD program. We thank ICANN for giving us the opportunity to offer our insights on the issue of the processing of the new gTLD applications It is very important to keep in mind, the enormous amount of resources put in place by all participants of the new gTLD program. Even though most of the applications have been presented by large firms or major-league investors, there are also proposals made by small companies or small communities that took major risk and effort to build a viable business plan and comply with the technical and financial requirements. We think that contracted evaluation firms should put up more resources to the task of evaluating proposals in order to shorten the evaluation time. We are talking of really big firms that are going to get paid by the hour with the participant's money. On the other hand, ICANN should keep promoting the geographic diversity of critical DNS infrastructure as it has been doing with the root servers, not only for technical improvement but also for political reasons. As of today, all gTLD registries are located in developed countries only, and this reinforces the notion that ICANN only works with countries with economic power. If it is true that ICANN cannot lower the standard on technical requirements for proposals from developing countries, it is also true that it can prioritize in favor of such proposals. Regards AnthonyHarris Executive Director ECOM-LAC - Applicant for '.lat' www.ecomlac.org From aaron at 2012.mx Sat Aug 18 19:43:02 2012 From: aaron at 2012.mx (Aaron Grego) Date: Sat, 18 Aug 2012 14:43:02 -0500 Subject: [Newgtld-input] ICANN BATCHING COMMENT Message-ID: To whom it may concern, I am attaching the following letter in a PDF format with PUNTO 2012 SA de CV comments on the batching process for new gTLD?s I recently sent the same letter form a different e-mail account in a word format, I am sending this additional e-mail so that you receive whichever format is more convenient. Thank you for your attention given to the present document, Please contact me if you need any further information, Sincerely, * Aaron Grego* aaron at 2012.mx Punto 2012 S.A. de C.V. -------------- next part -------------- A non-text attachment was scrubbed... Name: Punto 2012 Letter to ICANN RE Batching - final.pdf Type: application/pdf Size: 222321 bytes Desc: not available Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120818/228bba72/Punto2012LettertoICANNREBatching-final.pdf From adrian at ausregistry.com.au Mon Aug 20 11:32:14 2012 From: adrian at ausregistry.com.au (Adrian Kinderis) Date: Mon, 20 Aug 2012 21:32:14 +1000 Subject: [Newgtld-input] New TLD Program - Batching In-Reply-To: References: <8CEF048B9EC83748B1517DC64EA130FB72BCF6D071@off-win2003-01.ausregistrygroup.local> Message-ID: <8CEF048B9EC83748B1517DC64EA130FB72BCF6D37A@off-win2003-01.ausregistrygroup.local> Further to my email below, please find attached a letter dated 1 June 2012 outlining the recommendations of ARI Registry Services in relation to new gTLD application batching. Regards, [cid:image002.png at 01CD7F1B.440D2890] ADRIAN KINDERIS Chief Executive Officer ARI REGISTRY SERVICES Melbourne | Los Angeles P +61 3 9866 3710 T @AdrianKinderis E Adrian.Kinderis at ariservices.com W www.ariservices.com ARI Registry Services is an evolution of AusRegistry International. Follow us on Twitter The information contained in this communication is intended for the named recipients only. It is subject to copyright and may contain legally privileged and confidential information and if you are not an intended recipient you must not use, copy, distribute or take any action in reliance on it. If you have received this communication in error, please delete all copies from your system and notify us immediately. From: Adrian Kinderis [mailto:adrian at ausregistry.com.au] Sent: Friday, June 01, 2012 3:26 AM To: steve.crocker at icann.org Cc: Rod Beckstrom; Kurt Pritz; John Jeffrey; Chris Disspain (ceo at auda.org.au); Theo Hnarakis (Theo.Hnarakis at melbourneit.com.au) Subject: New TLD Program - Batching Dear Sirs, Attached please find a letter outlining the recommendations of ARI Registry Services in relation to new gTLD application batching. Regards, [cid:image003.png at 01CD7E2E.8A7BD8A0] ADRIAN KINDERIS Chief Executive Officer ARI REGISTRY SERVICES Melbourne|Los Angeles P +61 3 9866 3710 T @AdrianKinderis E Adrian.Kinderis at ariservices.com W www.ariservices.com ARI Registry Services is an evolution of AusRegistry International. Follow us on Twitter The information contained in this communication is intended for the named recipients only. It is subject to copyright and may contain legally privileged and confidential information and if you are not an intended recipient you must not use, copy, distribute or take any action in reliance on it. If you have received this communication in error, please delete all copies from your system and notify us immediately. -------------- next part -------------- Further to my email below, please find attached a letter dated 1 June 2012 outlining the recommendations of ARI Registry Services in relation to new gTLD application batching. Regards, Description: Description: Description: Description: Description: Description: ARI Logo ADRIAN KINDERIS Chief Executive Officer ARI REGISTRY SERVICES Melbourne | Los Angeles P +61 3 9866 3710 T @AdrianKinderis E [1]Adrian.Kinderis at ariservices.com W [2]www.ariservices.com ARI Registry Services is an evolution of AusRegistry International. Follow us on [3]Twitter The information contained in this communication is intended for the named recipients only. It is subject to copyright and may contain legally privileged and confidential information and if you are not an intended recipient you must not use, copy, distribute or take any action in reliance on it. If you have received this communication in error, please delete all copies from your system and notify us immediately. From: Adrian Kinderis [4][mailto:adrian at ausregistry.com.au] Sent: Friday, June 01, 2012 3:26 AM To: [5]steve.crocker at icann.org Cc: Rod Beckstrom; Kurt Pritz; John Jeffrey; Chris Disspain ([6]ceo at auda.org.au); Theo Hnarakis ([7]Theo.Hnarakis at melbourneit.com.au) Subject: New TLD Program - Batching Dear Sirs, Attached please find a letter outlining the recommendations of ARI Registry Services in relation to new gTLD application batching. Regards, Description: Description: Description: Description: Description: Description: ARI Logo ADRIAN KINDERIS Chief Executive Officer ARI REGISTRY SERVICES Melbourne|Los Angeles P +61 3 9866 3710 T @AdrianKinderis E [8]Adrian.Kinderis at ariservices.com W [9]www.ariservices.com ARI Registry Services is an evolution of AusRegistry International. Follow us on [10]Twitter The information contained in this communication is intended for the named recipients only. It is subject to copyright and may contain legally privileged and confidential information and if you are not an intended recipient you must not use, copy, distribute or take any action in reliance on it. If you have received this communication in error, please delete all copies from your system and notify us immediately. References 1. mailto:Adrian.Kinderis at ariservices.com 2. http://www.ariservices.com/ 3. http://twitter.com/#!/ausregistryint 4. mailto:[mailto:adrian at ausregistry.com.au] 5. mailto:steve.crocker at icann.org 6. mailto:ceo at auda.org.au 7. mailto:Theo.Hnarakis at melbourneit.com.au 8. mailto:Adrian.Kinderis at ariservices.com 9. http://www.ariservices.com/ 10. http://twitter.com/#!/ausregistryint -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 3765 bytes Desc: image001.png Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120820/0cd66774/image001.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 5465 bytes Desc: image002.png Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120820/0cd66774/image002.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 5486 bytes Desc: image003.png Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120820/0cd66774/image003.png -------------- next part -------------- A non-text attachment was scrubbed... Name: ARI - Letter to ICANN Board - New gTLD Program - 2012-06-01[2].pdf Type: application/pdf Size: 419812 bytes Desc: ARI - Letter to ICANN Board - New gTLD Program - 2012-06-01[2].pdf Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120820/0cd66774/ARI-LettertoICANNBoard-NewgTLDProgram-2012-06-012.pdf From cyou-icann at hichina.com Fri Aug 17 14:44:20 2012 From: cyou-icann at hichina.com (cyou-icann at hichina.com) Date: Fri, 17 Aug 2012 22:44:20 +0800 Subject: [Newgtld-input] =?utf-8?q?ICANN_Seeks_input_on_gTLD_Batching?= In-Reply-To: CC3B017F.25572%newgtld-input@icann.org References: CC3B017F.25572%newgtld-input@icann.org Message-ID: <0f658e81-d045-47f6-8773-65a9cf052ace@hichina.com> Dear ICANN, HiChina is supportive of ICANN?s efforts to implement an equitable solution which allows for the orderly allocation of completed gTLD applications into the root. In connection with this initiative, HiChina believes that it is important to reaffirm an important aspect previously articulated by the ICANN Board regarding geographical diversity. Specifically, ICANN needs to ensure that in any final implementation there are adequate safeguards to ensure that applications from no geographic region(s) are unfairly benefitted in being placed into the root. ICANN must ensure that the allocation of these global resources are done in a manner that benefit all global stakeholders, and not just those from a specific geographic region. Best regards, HiChina Team ------------------------------------------------------------------ Sender:newgtld-input Date2012-07-30 06:04 To:[Nothing] Subject:ICANN Seeks input on gTLD Batching Dear Applicant: Opportunity for Community Input: Processing of New gTLD Applications At the Prague ICANN meeting, the new gTLD Program Committee decided to terminate Digital Archery, and instructed ICANN staff to proceedwith the initial evaluation of applications as quickly as possible. This evaluation is in progress based on a tentative project plan that foresees the processing of applications in a single batch, and simultaneous release of results. ICANN believes this approach is consistent with the constraints that various parts of the community have in performing their respective roles in the evaluation process, and with the feedback received from the community at the Prague meeting. This comment opportunity seeks input on requirements for an evaluation and delegation process consistent with previous root zone scaling discussions of smooth delegations, adding no more than 1,000 new gTLDs per year. This outcome can be achieved by the: timing of the release of evaluation results to applicants, timing of the release of applications into the pre-delegation steps of contract execution and pre-delegation testing, metering of delegations of new gTLDs into the root zone. ICANN is committed to executing the evaluation and delegation process in a way that is equitable and meets ICANN?s commitment to ensuring the security and stability of the DNS, consistent with previously established root zone scaling goals. Please write to newgtld-input at icann.org with your input. Comments received by 19 August 2012 (UTC 00:00) will be considered. Background The concept of batching has been a part of the Applicant Guidebook since its first draft. Batching accomplishes three goals: Better management of the evaluation process by placing an upper bound on the number of evaluators necessary and the number of parallel evaluations occurring at any one time. Release of evaluation results to applicants according to a predictable schedule. Delegation of TLDs at a rate acceptable to the technical community, consistent with the root zone scaling discussion. Based on the definitive information that ICANN now has about the pool of applications, and work on the evaluations to date, this commentprocess seeks input to meet requirements for goals #2 and #3. Leading up to and during ICANN?s meeting in Prague, the applicant and community positions on requirements for batching schemes thatwould control the evaluation, communication and delegation of applications were reported to be: The batching solution has to be equitable. The evaluation results have to be announced at the same time. Successful applications should proceed to delegation phase without undue delays. Delegation to the root must be at a smooth rate and must not exceed 1,000 per year. The GAC is planning to issue early warnings shortly after the Toronto ICANN meeting in October 2012. Consideration by the GAC of issues concerning GAC advice on contentious applications is not expected to be finalized before the Beijing meeting in April 2013. During the root scaling discussion, it was agreed that ICANN would not delegate TLDs at a rate greater than 1,000 per year. This is because the primary challenge with maintaining root zone stability is controlling the rate of change to the root zone system and not the size of the root zone itself, meaning delegation should not occur at a rate of 1,000 delegations on a single day. In Prague, the batching and prioritization method known as Digital Archery was terminated and eliminated from further consideration. Recent Developments Initial evaluation of new gTLD applications is underway. Applications are being distributed to evaluators in a way that enables efficient processing. ICANN has conducted pilot evaluations and had discussions with evaluators to accelerate the evaluation schedule. As a result of thesediscussions, the evaluation teams have committed to accelerate the evaluations substantially, while processing them in a single batch. In Prague, a methodology was discussed where the smooth delegation of applications could occur by first releasing applications that passed initial evaluation without the need for clarifying questions, then releasing applications in order of the number of clarifying questions required, from fewest to highest. After analysis, this methodology proved unworkable because 80% to 90% of the total evaluation time is required to form and ask clarifying questions, so little smoothing would result. The current plan indicates that initial evaluation of all applications, processed in a ?single batch?, can be completed in 11-12 months, possibly less ? resulting in publication of results in June-July 2013. Note: It is planned that regular updates to applicants during the evaluation period will be provided. In addition to written reports, ICANN is looking into the use of a webinar / conference call format to deliver updates. For applicants, releasing results in a single batch would mean that the first delegations would occur in late third quarter of 2013, six months later than originally expected. Implications of GAC timing: The GAC plans to ?issue any Early Warnings shortly after the Toronto ICANN meeting, in October 2012,? meaning that Early Warnings would be received within the currently planned single evaluation period. Also, the GAC ?is considering the implications of providing any GAC advice on gTLD applications. These considerations are not expected to be finalized before the Beijing meeting in April 2013.? This is shortly before the currently planned announcement of initial evaluation results (i.e., the schedule without additional accelerations beyond those stated above). Statement of the Issue While there will be some natural smoothing as applications take different paths through objections and contention resolution processes, there will still be a requirement for some method of metering applications into the delegation process. This is due to the relatively high number of applications that mayreach pre-delegation steps at essentially the same time. A metering method has not yet been determined and will need to be developed. Questions to be answered by comments Submitted comments should specifically answer each of the following questions: Should the metering or smoothing consider releasing evaluation results, and transitioning applications into the contract execution and pre-delegation testing phases, at different times? How can applications be allocated to particular release times in a fair and equitable way? Would this approach provide sufficient smoothing of the delegation rate? Provide reasoning for selecting this approach. Should the metering or smoothing be accomplished by downstream metering of application processing (i.e., in the contract execution, pre-delegation testing or delegation phases)? How can applications be allocated to a particular timing in contract execution, pre-delegation testing, or delegation in a fair and equitable way? Provide reasoning for selecting this approach. Include a statement describing the level of importance that the order of evaluation and delegation has for your application. Please write to newgtld-input at icann.org with your input. Comments received by 19 August 2012 (UTC 00:00) will be considered. Regards, New gTLD Team From aigo-icann at hichina.com Fri Aug 17 14:49:56 2012 From: aigo-icann at hichina.com (aigo-icann at hichina.com) Date: Fri, 17 Aug 2012 22:49:56 +0800 Subject: [Newgtld-input] =?utf-8?q?ICANN_Seeks_input_on_gTLD_Batching?= In-Reply-To: CC3AFFEB.25557%newgtld-input@icann.org References: CC3AFFEB.25557%newgtld-input@icann.org Message-ID: <26516ff9-3871-4884-b893-5d1c67bcd00a@hichina.com> Dear ICANN, HiChina is supportive of ICANN?s efforts to implement an equitable solution which allows for the orderly allocation of completed gTLD applications into the root. In connection with this initiative, HiChina believes that it is important to reaffirm an important aspect previously articulated by the ICANN Board regarding geographical diversity. Specifically, ICANN needs to ensure that in any final implementation there are adequate safeguards to ensure that applications from no geographic region(s) are unfairly benefitted in being placed into the root. ICANN must ensure that the allocation of these global resources are done in a manner that benefit all global stakeholders, and not just those from a specific geographic region. Best regards, HiChina Team ------------------------------------------------------------------ Sender:newgtld-input Date2012-07-30 05:57 To:[Nothing] Subject:ICANN Seeks input on gTLD Batching Dear Applicant: Opportunity for Community Input: Processing of New gTLD Applications At the Prague ICANN meeting, the new gTLD Program Committee decided to terminate Digital Archery, and instructed ICANN staff to proceedwith the initial evaluation of applications as quickly as possible. This evaluation is in progress based on a tentative project plan that foresees the processing of applications in a single batch, and simultaneous release of results. ICANN believes this approach is consistent with the constraints that various parts of the community have in performing their respective roles in the evaluation process, and with the feedback received from the community at the Prague meeting. This comment opportunity seeks input on requirements for an evaluation and delegation process consistent with previous root zone scaling discussions of smooth delegations, adding no more than 1,000 new gTLDs per year. This outcome can be achieved by the: timing of the release of evaluation results to applicants, timing of the release of applications into the pre-delegation steps of contract execution and pre-delegation testing, metering of delegations of new gTLDs into the root zone. ICANN is committed to executing the evaluation and delegation process in a way that is equitable and meets ICANN?s commitment to ensuring the security and stability of the DNS, consistent with previously established root zone scaling goals. Please write to newgtld-input at icann.org with your input. Comments received by 19 August 2012 (UTC 00:00) will be considered. Background The concept of batching has been a part of the Applicant Guidebook since its first draft. Batching accomplishes three goals: Better management of the evaluation process by placing an upper bound on the number of evaluators necessary and the number of parallel evaluations occurring at any one time. Release of evaluation results to applicants according to a predictable schedule. Delegation of TLDs at a rate acceptable to the technical community, consistent with the root zone scaling discussion. Based on the definitive information that ICANN now has about the pool of applications, and work on the evaluations to date, this commentprocess seeks input to meet requirements for goals #2 and #3. Leading up to and during ICANN?s meeting in Prague, the applicant and community positions on requirements for batching schemes thatwould control the evaluation, communication and delegation of applications were reported to be: The batching solution has to be equitable. The evaluation results have to be announced at the same time. Successful applications should proceed to delegation phase without undue delays. Delegation to the root must be at a smooth rate and must not exceed 1,000 per year. The GAC is planning to issue early warnings shortly after the Toronto ICANN meeting in October 2012. Consideration by the GAC of issues concerning GAC advice on contentious applications is not expected to be finalized before the Beijing meeting in April 2013. During the root scaling discussion, it was agreed that ICANN would not delegate TLDs at a rate greater than 1,000 per year. This is because the primary challenge with maintaining root zone stability is controlling the rate of change to the root zone system and not the size of the root zone itself, meaning delegation should not occur at a rate of 1,000 delegations on a single day. In Prague, the batching and prioritization method known as Digital Archery was terminated and eliminated from further consideration. Recent Developments Initial evaluation of new gTLD applications is underway. Applications are being distributed to evaluators in a way that enables efficient processing. ICANN has conducted pilot evaluations and had discussions with evaluators to accelerate the evaluation schedule. As a result of thesediscussions, the evaluation teams have committed to accelerate the evaluations substantially, while processing them in a single batch. In Prague, a methodology was discussed where the smooth delegation of applications could occur by first releasing applications that passed initial evaluation without the need for clarifying questions, then releasing applications in order of the number of clarifying questions required, from fewest to highest. After analysis, this methodology proved unworkable because 80% to 90% of the total evaluation time is required to form and ask clarifying questions, so little smoothing would result. The current plan indicates that initial evaluation of all applications, processed in a ?single batch?, can be completed in 11-12 months, possibly less ? resulting in publication of results in June-July 2013. Note: It is planned that regular updates to applicants during the evaluation period will be provided. In addition to written reports, ICANN is looking into the use of a webinar / conference call format to deliver updates. For applicants, releasing results in a single batch would mean that the first delegations would occur in late third quarter of 2013, six months later than originally expected. Implications of GAC timing: The GAC plans to ?issue any Early Warnings shortly after the Toronto ICANN meeting, in October 2012,? meaning that Early Warnings would be received within the currently planned single evaluation period. Also, the GAC ?is considering the implications of providing any GAC advice on gTLD applications. These considerations are not expected to be finalized before the Beijing meeting in April 2013.? This is shortly before the currently planned announcement of initial evaluation results (i.e., the schedule without additional accelerations beyond those stated above). Statement of the Issue While there will be some natural smoothing as applications take different paths through objections and contention resolution processes, there will still be a requirement for some method of metering applications into the delegation process. This is due to the relatively high number of applications that mayreach pre-delegation steps at essentially the same time. A metering method has not yet been determined and will need to be developed. Questions to be answered by comments Submitted comments should specifically answer each of the following questions: Should the metering or smoothing consider releasing evaluation results, and transitioning applications into the contract execution and pre-delegation testing phases, at different times? How can applications be allocated to particular release times in a fair and equitable way? Would this approach provide sufficient smoothing of the delegation rate? Provide reasoning for selecting this approach. Should the metering or smoothing be accomplished by downstream metering of application processing (i.e., in the contract execution, pre-delegation testing or delegation phases)? How can applications be allocated to a particular timing in contract execution, pre-delegation testing, or delegation in a fair and equitable way? Provide reasoning for selecting this approach. Include a statement describing the level of importance that the order of evaluation and delegation has for your application. Please write to newgtld-input at icann.org with your input. Comments received by 19 August 2012 (UTC 00:00) will be considered. Regards, New gTLD Team From CCioffe at media.nyc.gov Fri Aug 17 16:31:23 2012 From: CCioffe at media.nyc.gov (Cioffe, Christina) Date: Fri, 17 Aug 2012 16:31:23 +0000 Subject: [Newgtld-input] Processing of New gTLD Applications Message-ID: <3C42803E9EC97D4DB65C07C49F92527F030EEEC4@MSPWPA-DITDG1B.doitt.nycnet> August 17, 2012 ICANN Suite 330, 4676 Admiralty Way Marina del Rey, CA 90292 Attention: New gTLD Evaluation Process Dear ICANN Representative: This letter provides The City of New York comments on the processing of new gTLD applications. I am submitting these comments as the Chief Digital Officer for the New York City Mayor's Office of Media and Entertainment (MOME). The New York City Mayor's Office of Media and Entertainment (MOME), is responsible for streamlining government communications by making more information accessible, leveraging technology to aid in the transparency of government, and by supporting relevant industries in New York City. In support of these objectives an application for .NYC was submitted to ICANN by the New York City Department of Information Technology & Telecommunications in the New gTLD Program. The gTLD will be used to offer government, organizations, businesses and residents who meet the Nexus policy in the Application, and who comply with other associated policies, to register .NYC domain names. The City believes ICANN should publish evaluation results as soon as they are available for each contention set, and expeditiously move forward with Transition to Delegation of all applications that have successfully passed evaluation, entered into contracts with ICANN and completed pre-delegation testing. Requiring all applications to wait for all applications to complete every step of the process unnecessarily delays the innovation and other benefits associated with the new gTLD program. Allowing gTLD contention sets to proceed when ready should effectively "meter" and "smooth" delegation. However, if the number of gTLDs ready for delegation in a given month exceeds 83 (1000/12), priority should be given to Internationalized Domain Names (IDNs), Geographic and Community gTLDs. The need for these gTLD types (those that pass evaluation) are well documented and supported by their respective communities. ICANN should also monitor the delegation of new gTLDs in the early months with an eye towards increasing the number of gTLDs delegated each month (but not exceeding 1000 in a given twelve month period). Thank you for the opportunity to comment concerning this important process. Sincerely, Rachel Sterne Chief Digital Officer of the City of New York -------------- next part -------------- A non-text attachment was scrubbed... Name: ICANN_Comments_NYC.pdf Type: application/pdf Size: 91333 bytes Desc: ICANN_Comments_NYC.pdf Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120817/752fadc0/ICANN_Comments_NYC.pdf From crescent.ezekwu at valideus.com Fri Aug 17 17:01:31 2012 From: crescent.ezekwu at valideus.com (Crescent Ezekwu) Date: Fri, 17 Aug 2012 18:01:31 +0100 Subject: [Newgtld-input] ICANN Seeks input on gTLD Batching In-Reply-To: References: Message-ID: <007401cd7c99$f4255420$dc6ffc60$@valideus.com> Dear ICANN We at Valideus have submitted 121 applications on the behalf of our gTLD clients and welcome the opportunity to contribute towards this discussion. In response to your request for input on gTLD Batching we would like to provide the following comments: 1. We are encouraged to see that efficiencies are being sought by the evaluators - evaluating applications which have responses from the same technical provider together, or are from the same applicant. This should be extended as much as possible to include further efficiencies such as evaluating all city or community registries together. 2. All applications which we know will be in contention should be removed from the batch. It is fair and equitable to evaluate these applications after those which are uncontested. It will also lead to more urgency in publishing String Contention sets. 3. In addition, ICANN should give applicants who are happy to wait an opt-out so that they are processed alongside those in Contention sets. 4. Applicants could be given a financial incentive to wait and have their gTLD(s) delegated later: e.g. a refund of $25,000 per gTLD. 5. Finally, a self-designated priority system could be used to smooth out applications that are ready to transition to delegation from June/July 2013. Of the total 1930 applications (including the 3 unknown withdrawals), 1179 are for unique strings. This means that - subject to objections and the announcement of contention sets - about 1000 gTLDs will be ready for transition to delegation in June/July 2013. Looking at these 1179 uncontested strings, there are approximately 594 unique applicants (including portfolio applicants). Utilising a self-designated priority system, ICANN could - once results are posted in June/July 2013 - ask these unique applicants to submit one priority uncontested gTLD for early transition to delegation. Starting from a random applicant in this group, ICANN could then allow each of these approximately 594 uncontested gTLDs to begin transition to delegation. Where the applicant has applied for other gTLDs that are similar to its priority application, ICANN could then enter into contractual negotiations for these alongside negotiations for the priority application. This would ensure efficiencies in contracting are maximised, without causing bottlenecks at IANA. This self-designated priority system would be subject to ICANN defining its capacities beforehand. One way to do this would be to set out a clear target delegation number for 2013, in light of staffing limits within its legal department and capacity at IANA. Regards Crescent Ezekwu Client Project Manager Valideus From: newgtld-input [mailto:newgtld-input at icann.org] Sent: 29 July 2012 23:16 To: Undisclosed recipients: Subject: ICANN Seeks input on gTLD Batching Dear Applicant: Opportunity for Community Input: Processing of New gTLD Applications At the Prague ICANN meeting, the new gTLD Program Committee decided to terminate Digital Archery, and instructed ICANN staff to proceedwith the initial evaluation of applications as quickly as possible. This evaluation is in progress based on a tentative project plan that foresees the processing of applications in a single batch, and simultaneous release of results. ICANN believes this approach is consistent with the constraints that various parts of the community have in performing their respective roles in the evaluation process, and with the feedback received from the community at the Prague meeting. This comment opportunity seeks input on requirements for an evaluation and delegation process consistent with previous root zone scaling discussions of smooth delegations, adding no more than 1,000 new gTLDs per year. This outcome can be achieved by the: 1. timing of the release of evaluation results to applicants, 2. timing of the release of applications into the pre-delegation steps of contract execution and pre-delegation testing, 3. metering of delegations of new gTLDs into the root zone. ICANN is committed to executing the evaluation and delegation process in a way that is equitable and meets ICANN's commitment to ensuring the security and stability of the DNS, consistent with previously established root zone scaling goals. Please write to new gtld - input @ icann . org with your input. Comments received by 19 August 2012 (UTC 00:00) will be considered. Background The concept of batching has been a part of the Applicant Guidebook since its first draft. Batching accomplishes three goals: 1. Better management of the evaluation process by placing an upper bound on the number of evaluators necessary and the number of parallel evaluations occurring at any one time. 2. Release of evaluation results to applicants according to a predictable schedule. 3. Delegation of TLDs at a rate acceptable to the technical community, consistent with the root zone scaling discussion. Based on the definitive information that ICANN now has about the pool of applications, and work on the evaluations to date, this commentprocess seeks input to meet requirements for goals #2 and #3. Leading up to and during ICANN's meeting in Prague, the applicant and community positions on requirements for batching schemes thatwould control the evaluation, communication and delegation of applications were reported to be: 1. The batching solution has to be equitable. 2. The evaluation results have to be announced at the same time. 3. Successful applications should proceed to delegation phase without undue delays. 4. Delegation to the root must be at a smooth rate and must not exceed 1,000 per year. 5. The GAC is planning to issue early warnings shortly after the Toronto ICANN meeting in October 2012. 6. Consideration by the GAC of issues concerning GAC advice on contentious applications is not expected to be finalized before the Beijing meeting in April 2013. During the root scaling discussion, it was agreed that ICANN would not delegate TLDs at a rate greater than 1,000 per year. This is because the primary challenge with maintaining root zone stability is controlling the rate of change to the root zone system and not the size of the root zone itself, meaning delegation should not occur at a rate of 1,000 delegations on a single day. In Prague, the batching and prioritization method known as Digital Archery was terminated and eliminated from further consideration. Recent Developments Initial evaluation of new gTLD applications is underway. Applications are being distributed to evaluators in a way that enables efficient processing. ICANN has conducted pilot evaluations and had discussions with evaluators to accelerate the evaluation schedule. As a result of thesediscussions, the evaluation teams have committed to accelerate the evaluations substantially, while processing them in a single batch. In Prague, a methodology was discussed where the smooth delegation of applications could occur by first releasing applications that passed initial evaluation without the need for clarifying questions, then releasing applications in order of the number of clarifying questions required, from fewest to highest. After analysis, this methodology proved unworkable because 80% to 90% of the total evaluation time is required to form and ask clarifying questions, so little smoothing would result. The current plan indicates that initial evaluation of all applications, processed in a "single batch", can be completed in 11-12 months, possibly less - resulting in publication of results in June-July 2013. Note: It is planned that regular updates to applicants during the evaluation period will be provided. In addition to written reports, ICANN is looking into the use of a webinar / conference call format to deliver updates. For applicants, releasing results in a single batch would mean that the first delegations would occur in late third quarter of 2013, six months later than originally expected. Implications of GAC timing: The GAC plans to "issue any Early Warnings shortly after the Toronto ICANN meeting, in October 2012," meaning that Early Warnings would be received within the currently planned single evaluation period. Also, the GAC "is considering the implications of providing any GAC advice on gTLD applications. These considerations are not expected to be finalized before the Beijing meeting in April 2013." This is shortly before the currently planned announcement of initial evaluation results (i.e., the schedule without additional accelerations beyond those stated above). Statement of the Issue While there will be some natural smoothing as applications take different paths through objections and contention resolution processes, there will still be a requirement for some method of metering applications into the delegation process. This is due to the relatively high number of applications that mayreach pre-delegation steps at essentially the same time. A metering method has not yet been determined and will need to be developed. Questions to be answered by comments Submitted comments should specifically answer each of the following questions: 1. Should the metering or smoothing consider releasing evaluation results, and transitioning applications into the contract execution and pre-delegation testing phases, at different times? o How can applications be allocated to particular release times in a fair and equitable way? o Would this approach provide sufficient smoothing of the delegation rate? o Provide reasoning for selecting this approach. 2. Should the metering or smoothing be accomplished by downstream metering of application processing (i.e., in the contract execution, pre-delegation testing or delegation phases)? o How can applications be allocated to a particular timing in contract execution, pre-delegation testing, or delegation in a fair and equitable way? o Provide reasoning for selecting this approach. o Include a statement describing the level of importance that the order of evaluation and delegation has for your application. Please write to newgtld - input @ icann . org with your input. Comments received by 19 August 2012 (UTC 00:00) will be considered. Regards, New gTLD Team From avc at tldh.org Sat Aug 18 18:55:08 2012 From: avc at tldh.org (Antony Van Couvering) Date: Sat, 18 Aug 2012 11:55:08 -0700 Subject: [Newgtld-input] The case against batching Message-ID: <3A86C1D4-C151-43DE-8795-EA407CF2FEF8@mindsandmachines.com> I forward this letter and article, originally sent June 11, 2012 to the ICANN Board and staff, regarding digital archery and batching. It may helpful for the record, even though the debate has progressed since then. Antony ---- Antony Van Couvering CEO, Minds + Machines -------------- next part -------------- A non-text attachment was scrubbed... Name: 2012-06-11 Letter to ICANN Board.pdf Type: application/pdf Size: 81310 bytes Desc: not available Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120818/da1b6873/2012-06-11LettertoICANNBoard.pdf -------------- next part -------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: The Biggest Glitch of All.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 670805 bytes Desc: not available Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120818/da1b6873/TheBiggestGlitchofAll.docx -------------- next part -------------- From carlos at grego.com.mx Sat Aug 18 19:25:30 2012 From: carlos at grego.com.mx (c.p.c Carlos Grego) Date: Sat, 18 Aug 2012 14:25:30 -0500 Subject: [Newgtld-input] Batching Message-ID: <000601cd7d77$3bcf6440$b36e2cc0$@grego.com.mx> To whom it may concern: Please find enclosed our comments re: Batching. Please confirm the reception of this email. Thank you, C.P. Aaron Grego PUNTO 2012, S.A. DE C.V. Juan Escutia No. 29 Col. Condesa 06140 Mexico, D.F. Tel. +(55) 9628-2100 ext. 104 Fax. +(55) 5250-5187 US (720) 240-4770 -------------- next part -------------- A non-text attachment was scrubbed... Name: Punto 2012 Letter to ICANN RE Batching - final.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 205267 bytes Desc: not available Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120818/426e0c5e/Punto2012LettertoICANNREBatching-final.docx From candidature at pointquebec.org Sat Aug 18 19:32:55 2012 From: candidature at pointquebec.org (Candidature) Date: Sat, 18 Aug 2012 15:32:55 -0400 Subject: [Newgtld-input] .QUEBEC Batching Suggestions Message-ID: Prague, June 27th 2012 To : newgtld-input at icann.org >From : PointQu?bec Inc. (.QUEBEC) Prague ICANN meeting 2012 The ?new gTLD program is the result of seven years of international consultation and debate among a wide variety of Internet stakeholders?. Nonetheless, since 2008, PointQu?bec has witnessed several questionable decisions concerning the new gTLD program, recriminations from various stakeholders to modify it and different points of view in order to ensure a more appropriate governance mechanism in compliance with the goal pursued with the program. PointQu?bec applaudes ICANN's recent decision to suspend the digital archery process and urges ICANN to reject this inequitable approach. The archery process is a flawed lotery game that would penalize PointQu?bec and other new TLD applicants. It generates costs, with no guarantee of success. For instance, PointQu?bec has only 10 to 15% chances of success for a gTLD in 2013 simply because of the important volume of applicants based in North America, while applicants from other regions may have a 100% success rate possible because the number of applications submitted to ICANN has fewer brandnames. The geographical distribution proposed by ICANN unduly penalizes PointQuebec. PointQu?bec is not competing with anyone and we do not have to play this unfair game. For example, such a process would never be tolerated in our governments to discriminate service providers on the grounds that they failed a test of archery, regardless of the quality of the proposal, its admissibility, eligibility, or the filing of a bid guarantee. Morover, ICANN will suffer in many ways from such an unethical decision, in terms of reputation and capability to undertake this process in a way that better meets the core values of ICANN. [i] Make allocation and assignment decisions by applying documented policies neutrally and objectively. [j] Act with a speed that is responsive to the needs of the Internet but obtain informed input from those most affected as part of the decision-making process. [k] Remain accountable to the forward Internet community through mechanisms that enhance ICANN's effectiveness. Secondly, how can we mix applicants who apply for 50 or more trademark TLDs with applicants proposing a single new geographic or linguistic TLD unrelated to trade names? How can one seriously compare a trademark with the promotion of a language or a culture? How can we make such a shortcut that would at the end benefit the richest applicants, when the purpose of ICANN is ?to ensure that the decisions of ICANN are made in the interest of the global Internet community?? What we propose: three groups in a one batch process Following monday's open discussion on new TLDs, Point-Quebec wants to propose to ICANN the following sequence as criterias to introduce new TLDs on the rooting system. 1- There is first a limited number of linguistic, cultural, geographical and municipal applications accounting for just over a hundred applications, such as Point-Quebec. These applications are intended to serve real people living within a defined community. On a technological point of view, the consequences of a failure with one member of this group would be confined to a region, which minimizes the overall network impact. 2 - Then we have the true generic names like dot-sport, dot-family, dot-film or dot-home, etc., that meet a common need and will create new communities or groups to promote their cause. 3 - Then come the trade names like Amazon, Orange, Toyota, Apple, Airbus or Allstate that will operate a public or private TLD. We propose to follow this simple sequence in the allocation of new gTLDs to ensure compliance with ICANN's guidelines since its inception until today, Some observers mentioned that the clTLDs and gTLDs applications requires more time to evaluate. We don't agree with that point of view since the same technology is proposed for many of the applications of the two first groups. To better serve the Internet global community, enhance ICANN's image and keeping in mind that updates are made on a day-to-day basis on the global system, we propose the following : that ICANN establish a batching process that will simply add TLDs to the root as the applications are accepted, in a daily, weekly, monthly process to be determined by ICANN. Such a process would help ICANN to promote the rise of the Internet for all. Normand Fortier PointQu?bec Inc. From Amadeu.Abril at corenic.org Sun Aug 19 10:18:04 2012 From: Amadeu.Abril at corenic.org (Amadeu Abril I Abril) Date: Sun, 19 Aug 2012 12:18:04 +0200 Subject: [Newgtld-input] COMMENTS FROM CORE Internet Council of Registrars Message-ID: <7A0DDD55-F7FE-421D-BE65-9555759D9D35@corenic.org> PLease find hereby attached both as text and PDf format our comments and proposals. We also attache an erleir version on "Amedning Digital Archery" in PDF, prepared and circulated prior to the Prague meeting, as it contains some background for our poposal. Amadeu Abril i Abril Cief Policy Advisor CORE Internet Council of Registrars http.//corenic.org Amadeu.Abril at corenic.org / Amadeu at abril.cat ***************** 1Comments from CORE Internet Council of Registrars We thank ICANN for the opportunity provided by this Public Comment Forum. We already provided a proposal last June, forwarded to staff, Board Committee and GAC, on how to handle this issues, as a reaction to the now abandoned ?Digital Archery? mechanism. We attach that proposal to this comment, as the logic and reasons for some priority criteria are the same, but we will answer the questions as made by the new gTLDs Committee for the benefit of structure as well (and, indeed, most the reasoning in that document specifically related to Digital Archery is no longer relevant). As a summary of our proposal, the following points can be made: A) The intermediate steps (Initial Evaluation; Contract Execution; Pee-Delegation Test) should not be used for throttling, but instead should focus on efficiency and speed (and quality of evaluation, indeed). B) Artificial bottlenecks should be avoided, though, as they would result in unnecessary delays for the whole process. In this regard, delaying the move into the next step for all applications until them all have completed the previous one is both inefficient and unfair. C) We provide some hierarchical criteria for prioritization in order to solve those bottlenecks according to principles of the global public interest which includes fairness and competitive considerations among applicants, but also the global interests of the Internet community. These includes some groups with specific reasons for priority (IDNs; GeoTLDs and other TLDs backed by public authorities; community-based TLDs; TLDs located and aimed at underrepresented areas) plus equally objective and non-discriminatory rules for the rest of applicants (percentages, for portfolio applicants, based on their stated order of preference; Exclusive Use TLDs grouped by industry or competitive concerns as expressed by the applicants themselves; etc). D) These criteria, applied at each stage if necessary (but perhaps only needed for the delegation step, if all goes well) coupled with the natural throttling of applications will most likely solve the question ICANN faces (by natural throttling we mean delays suffered by applications subject to objections; contention resolution; GAC Advice; failing Initial Evaluation or suffering delays in the contractual execution or pre-delegation test phases). Responses to enumerated questions: --------- 1. Should the metering or soothing consider releasing evaluation results, and transitioning applications into the contract execution and pre-delegation testing phases, at different times? The evaluation itself should not be used for throttling as a goal in itself. In this regard, CORE would have no objections (we rather believe it would be beneficial) to ICANN publishing the Initial Evaluation Reports as they get completed. At very least, the GOAL for these phase should be to publish the Initial Evaluations as soon as GAC provides its Advice to the Board. The roadmap as published by ICANN staff seems to be close to that goal. We propose below some additional measures to foster efficiency to attain that goal. But no delays should artificially arise from these phase. As not all and every TLD can be added to the root the very same day, nor can CIANN perform all Pre-Delegation Tests, or sign all contracts, in the very same date, it would be unacceptable to artificially add delays by forcing each and every application to wait until the very last Initial evaluation has been completed. Below we provide some ideas on a) how to further increase efficiency in order to meet the goal (publishing *all* initial evaluation reports immediately after GAC advice, ie, without causing any delay for the following step) and b) criteria as to how to prioritize applications if ICANN staff sees at any point that the said goal is not attainable and a delay will occur (more complete under answer to question 2 below). 1.1 Measures to Increase Evaluation Efficiency 1.1.1 Evaluation Productivity In order to achieve evaluation productivity, ICANN must analyze the applications globally by similar content. For any given question, many TLDs have absolutely identical responses (after allowing for changes in TLD string and Applicant name). ICANN must use available technology to identify similarity and identical content. The data shown on http://gtld-similarity.info demonstrates that the number of response models per question field is so low that all content can comfortably be reviewed in a few months on a per-question-per-model basis. A second pass can then take into account relationships between model responses as used in a given application. ICANN should use similarity testing for the non-public responses and publish statistics. ICANN could also ask the applicants (and though them, to the providers helping them in drafting the applications) to identify both the similarly-drafted portions in other applications and the differences in the models. 1.1.2 Simplified Evaluation of Exclusive-Use TLDs Furthermore, evaluators should avoid losing time with responses that have no practical bearing. That is especially true for exclusive-use TLD applications. There are at least 600 of them. Most applicants for brand TLDs will never allow third parties to register in their TLD. They will therefore apply for exemption of Specification 9 (Registry Code of Conduct) of the Registry Agreement, declaring that the TLD is for exclusive use by the registry operator. This means that the bulk of the evaluation questions for those TLDs are devoid of any practical significance. It would be a huge waste of time for ICANN to evaluate the financial stability or business plan of an exclusive-use TLD applicant. The same is true for the technical plan and most policy-related questions in these TLDs. It would be far more efficient for the Evaluators, these concrete applicants, the rest of aplicants and the users that those applicants committing to this model (and committing to apply for the exception ex Specification 9 of the Draft Agreement) undergo a simplified evaluation at this point, and, at the time they decide to open their TLD to third-party use and/or registration (for which they will necessarily need to go back to ICANN and modify some minor points of the TLD Agreement, such as giving up the Exemption ex Specification 9; provide a Code of Conduct and a RRA, etc...) at that time, not now, the complete evaluation should be performed. For most of them,this will never occur. For all of the applicants, this would mean a significant improvement of evaluation productivity; and for the registries changing their mind as to the exclusive use, and for the DnS users in general, the evaluation would be more meaningful at that moment, not years before this occurs. And it would be faster s ICANN would not be overloaded as it is now with 1927 complete applications ICANN must therefore allow applicants to use TAS to declare that they apply for exemption under Specification 9. For the applications flagged as exclusive-use, the evaluation is reduced to the aspects that matter. Furthermore, if a TLD application is flagged as exclusive-use in TAS by the applicant, then the applicant should be allowed to use TAS to identify same-industry competitor applications which should not enjoy a time advantage over the declaring applicant. This is an additional incentive for an early declaration of exclusive-use. 1.1.3 Allowing Objections to Be Handled Early While the objection period ends now prior to the Evaluation Period, ICANN has not clarified if the objections will be handled early, or only after publication of the Initial Evaluation. We strongly encourage the former. Early resolution means less applications, more clarity, and less work overall. 1.1.4 Allowing Joint Conditional Withdrawals as a Way to Early Reduce the Number of Applications in Contention We know that some 200+ strings count for some 750 applications. ICANN explicitly encourages private and early resolution of those contentions sets. Unfortunately, this is not practical in most cases. As the rules are set, resolution, wherever it implies, must result in all but one application in the contention set being withdrawn. But this is difficult to manage for contention sets with more than 2 applications, where multiple applicants must withdraw. The problem is that no matter how or why, multiple applicant in a contention set reach an agreement, it is difficult to enforce. As the system is now, each individual applicant should sent the withdrawal request to ICAN who would individually very each one with the applicant. Fair enough. But what happens if, say, five applicants agree to withdraw a given TLD application each, for the benefit a sixth one, and all sign the relevant documents and send the withdrawal request to ICANN, but one of them changes its mind and does not confirm it to ICANN? As it is now, ICANN will proceed to withdraw four of those applications, and leave both the one that has not send any request, and the one who started the process but changed mind. Bringing all participants in the contention-resolution process facing a new, unsolvable situation. Irreparable damage has been caused to all parties, and no remedy is available (sure, contracts can provide for all kind of penalties and guarantees, but in a scenario where applicants are in disparate jurisdictions this become unrealistic, and prohibitively expensive at best). ICANN cannot be forced to comply with a private agreement among third-parties. Nobody (short of a out-of-this-process timing Court) can force the non-complying applicant. We certainly don?t propose ICANN to enforce such private Agreements. But to publicly explain that it would accept Joint Conditional Withdrawals. In this scenario, when multiple parties jointly withdraw, ICANN would proceed with the usual and necessary checks. But if one or more of the withdrawals are not confirmed, then it would notify the other parts in the Joint Withdrawal and allow them to choose between moving forward or staying in the process, as the intended resolution has failed. If this is allowed we foresee a fair number of those 100+ contention sets with more than two applications (accounting for some 500 applications in total) with a real chance of early resolution, and hence, providing for a significant reduction of the names subject to Evaluation and subsequent steps. 1.2 Global Public Interest Priority Evaluation As stated above, CORE firmly believes that the goal of completing and publishing all Initial Evaluations immediately after the GAC advice is perfectly attainable, and we have provided some further ideas under 1.1 in order to make that goal even more realistic. But let?s imagine that at a certain point ICANN staff and the Evaluators are convinced that this goal is t risk. In this case (and only in this case) ICANN should make extra resources available for applications where public interest plays a special role. In a nutshell, ICANN should make sure that by the time of GAC Advice being published, at very least the following applications are ready to be immediately published and move into the next step (contractual execution): ?uncontested IDN, public-authority backed applications, applications coming from underrepresented areas and community-based TLDs?. We explain what each of these categories means in more detail in our response to Question 2 below, where we also provide for a methodology to handle metering or smoothing for the whole set of applications. ----------- 2. How can applications be allocated to particular release times in a fair and equitable way? Given the structure and language of the other questions, we are not completely sure if ?release? here means release of Initial Evaluation Reports, or release of TLDs in the rot (delegation), i.e., the final step. Just in case, we answer both. As for Initial Evaluation Reports, we have already said that: a) they could be released as soon as possible, as they get completed b) In any case, they should all be released immediately after the publication of the GAC Advice; c) In the worst case scenario in which c) is not possible, at least a series of public-interest qualified groups of applications should be published at that time, so as not to delay the process d) In this particular scenario those categories should move immediately into the next step, even if not all Initial Evaluation reports are complete and published. e) No step should be used to create artificial delays by preventing the start of the next steo until each and every application has completed the previous one. As it regards how to move forward from Initial Evaluation to Delegation, we submit the following criteria, based on public interest considerations. 2.1 Global Public Interest Considerations A lot has been said about *fairness* in handling the applications. But farness reduced to its over-simplistic concept of ?treating everything in the same way, as if it was all the same?. And also in the sole perspective of fairness towards the applicants: why this or that application should go or not before that other one, from the perspective of the itnerests of the applicants. These interests, our (CORE?s) own interests, are indeed very relevant. But not the only one. Interests of potential users, and the global community as such are also very relevant, if not more so. Shouldn?t we also ask what ?s important for the users? And, also, for certain users, comparatively underserved and underrepresented in the current DNS landscape? Take the case of IDNs. No such IDN gTLD was allowed in the prior two rounds of 2000 and 2004. No IDN gTLD exists today. For those users unfamiliar, or uncomfortable, with English/Western writing systems this is not a minor point (even not for those actually able to handle those ?foreign? systems, in fact). And we are not talking about any small number of individuals, by the way. In general, we encourage (and ask) ICANN to prioritize applications aimed at population and areas where wide cultural and linguistic differences exist between the environment of the applicant (and intended users) and the mainstream Western/English-speaking environment. Failure to do so would be an implicit discrimination against applicants whose language is not English and not similar to English. ICANN must take into account that the difficulty of writing an application increases exponentially with cultural and linguistic differences. It is easy for an American company to write an application and be understood by ICANN evaluators. It is a bit more difficult for French or German-speaking applicants, and it is much more difficult for Chinese-speaking ones. The Chinese-speaking applicant already had to bridge a considerable cultural spectrum. Imagine what it would be like if Western applicants had to send their gTLD applications in Chinese. The cultural differences cause misunderstandings which must be corrected. Beyond this point, ICANN has as a mandate to encourage diversity in the DNS, including cultural diversity and global reach of services. In this regard, we also propose that under-represented areas, such as Africa, Latin America or most of Asia (outside the Pacific Rim and Oceania, probably) should also benefit from some sort of priority. Ina different level, public interest is a guiding principle in how ICANN must manage the DNS. And we have long agreed that the different, local incarnations of public interest are defined by the relevant, local, authorities. In this regard we propose that those applications submitted by public authorities or backed by explicit endorsements of public authorities expressing that such TLDs would benefit the public interest they are competent to represent, would also benefit from a priority. This includes all geographic names as defined by ICANN, but not only those. We also believe that community-based applications, when submitted by representative entities providing for an adequate accountability framework with regard to the community itself, should also benefit from a high level of priority. Finally we propose some methods to handle the rest of applications. 2.2 Priority Criteria 2.2.1 Negative Priority: Contested Applications For any of the categories below, we mean ?uncontested? applications within such group. There are a series of facts that contribute to the natural throttling of applications, and this should be taken into account, We use this term broadly, covering applications affected by: - Contention sets - Objection Procedures - GAC Early Warnings and GAC Advice While those issues are unresolved, those applications should not be prioritized, as they would be affected by a delaying factor. We certainly don?t mean the they should be penalized, or even put lst in the queue for each step. we only claim that if, for instance, ICANN foresees at a given time that not all Initial Evaluations will be ready at the expected time, these ones should **not** concentrate the efforts, as they would in any case be unable to move to the next step yet. As soon as the delaying factor disappears, they should reintegrate their priority group. This also applies in later stages to applications: being sent into Extended Evaluation experiencing delays in contractual execution failing or facing delays in pre-delegation test 2.2.2 Priority for reasons of Public Interest Overall, ICANN should give priority to a) IDN applications b) Geographic TLDs with the explicit support (or letter of non-objection) of the relevant public authorities, as well as any other TLD application with that explicit suport even if not geographic in the Guidebook terms. c) Community-based TLDs for communities with clear community accountability and support. d) TLDs from under-represented areas, such as Africa, Latin America and most of Asia (Middle East; Central Asia; Southern Asia; Southeast Asia; excluding Oceania and the most developed economies of the Pacific area). 2.2.3 Priority by Applicant Choice (Voluntary Application Groups) Ideally, the timing of TLD delegation should match the wishes of the applicants. Some applicants may actually prefer their application to be added to the DNS root at a later stage. Applicants with multiple applications will naturally have preferences as to which of their applications they want to go first. Applicants should be allowed jointly set the preferred order of priority within a group of applications. For this purpose, TAS should allow each application to propose a group, to join a proposed group or not to join any group. For processing purposes, this process can be conducted over a period of 3-4 months. Those who joined a group can give their application and intra-group priority score agreed upon with the group?s proposer. The priority score can be updated and an application can leave a group and join another until the end of the grouping period. 2.2.4 Competition safeguards for exclusive-use TLDs In the current environment, a brand owner having applied for a one or several exclusive-use TLDs is unlikely to be under time pressure. The only time-sensitive aspect is competition between brand TLDs in the same industry sector. So long all TLD applicants in the same sector transition to delegation at the same time, a typical brand applicant has no problems waiting 2 or three years, let alone some extra months (while we know this dos not apply to all applications, a significant number of those we consulted expressed that ?not being clearly later than a competitor? was much more important than ?when? their TLD would be delegated). In other words, ICANN must be able to reassure them if their direct competitors will not be favoured. For instance, one can reasonably assume that a bank will not like its TLD to be introduced much later than another local bank, and that German car manufacturer will not like it if rival French, Japanese or US car manufacturers get their TLDs introduced one year before. That can easily be addressed. As pointed out under the responses to Question 1 above, there is a lot of value in formalizing the question of exclusive-use (Exemption from Specification 9) as early as possible. Applicant must be allowed to use TAS to declare they will use the TLD exclusively and therefore request exemption from Specification 9. If they do so, they should also be allowed to identify any gTLD application that they think is a same-industry competitor. Under normal circumstances, it should be easy to check plausibility: real competitors with exclusive-use TLD applications will symmetrically identify one another as competitors. From a processing standpoint, it is easiest is if TAS allows exclusive-use TLD applications to add a ?same-industry-competitor? pointer towards any other application, whether or not that application already carries the exclusive-use pointer. The result must be published online. ICANN can then make delegation batches of exclusive use TLDs that are naturally linked as competitors. -------------- Would this approach provide sufficient smoothing of the delegation rate? Yes if applied according to its two basic principles: The process should not create artificial bottlenecks at each stage by stopping everyone from moving to the next phase until everyone has completed the previous one; and, If at any given moment, but most notably at the delegation step, there is a need for throttling, metering or smoothing into the next phase, the same public-policy oriented criteria should be used in order to establish priority. In general terms, all the categories granted priority for public-interest reasons in this model amount to less than 300 applications, given the overlaps. This fails short of the intended batch size in the previous proposal, and represents just above a quarter of root delegation capabilities, if we understand that part correctly. Which means that there is still room for handling in early stages a fair number of applications from portfolio applicants, groups of competitive exclusive-use TLDs, and applications from other single-TLD applicants not in any other category. ------------------ 4. Should the metering or smoothing be accomplished by downstream metering of application processing (i.e., in the contract execution, pre-delegation testing or delegation phases)? Yes. As explained above, the process should focus on efficiency, and whenever the number of available applications for a given phase or step is bigger than the available resources for parallel handling, the criteria should apply as explained. --------------- 5. How can applications be allocated to a particular timing in contract execution, pre-delegation testing, or delegation in a fair and equitable way? ICANN staff is in a better position to establish the available bandwidth for each given phase. We all know of the published apparent constraints in the delegation phase, but the applicants know very little of how ICANN wants to manage both contractual execution and pre-delegation testing, so precise estimates are impossible. We urge ICANN to use an idea similar to the airport?s ?takeoff window?. Allocate a time window for each applicant (or groups or applicants) for both contractual execution and pre-delegation tests (we guess that for the latter, ICANN should establish concrete dates, though). The takeoff windows should not be necessarily the same. We might imagine that, for instance, community-based TLDs and Exclusive-Use TLDs might need a longer window, as they have to negotiate, on top of the standard contract, the policy commitments registrations restrictions, on one side, and the exception contained in Specification 9 (which includes some public-interest evaluation on ICANN?s side) on the other. If an applicant misses its window, or allocated date, it jumps its turn into the next allocation group. However, we all need to keep in mind that the only really relevant step is ?delegation?. This is ?it?. And here we have the annual constraints (1000 per year, apparently, even this is more a target figure than an absolute figure set in tone). Plus the daily, weekly, monthly rates that have never been clarified. But we all assume that it is certainly not ?let?s add all those 1000 for this year in a single morning?. Again, ICANN staff is in a better position to get and provide further clarification on workable weekly or monthly rates. At this critical stage, it is where the application of the priority criteria expressed above takes most importance. ------------ 6. Provide reasoning for selecting this approach. Our main goal in drafting this proposal is to prevent unnecessary delays though artificial bottlenecks at each of the four steps (Initial Evaluation; Contract Execution; Pre-Delegation Test, and Delegation). An over-simplistic view of ?fairness? could lead to a solution that forces everyone to to everything at the same time. In other words, everybody should wait for the last applicant to pass Step 1 before everybody moves to Step 2. This is not fair, it is simply inefficient, and unfair to the whole group. Let?s imagine ICANN invites 1927 people to a lunch. There is a self-service buffet. Nobody would pretend that the 1927 guests have the bread and the butter before anyone moves to the salad. And then nobody can start serving entr?es until the 1927 have all got their serve of salads, and so on. The result of such process would be that everybody would start eating much later than with a ?normal? self-service line. Being fair in the line but unfair in the lunch is not fairness, is inefficient unfairness to every guest. What we really need is a fast moving line that gets everybody, including the last guests as soon as possible to the table. What counts is not when you get the meal, but when you can eat it, so the *fairness* principle must be applied precisely then: when people can start eating. Which in our situation means: when TLDs get delegated. As, contrary to a normal lunch, we know that not everybody can be delegated at the exact same time, it is better to organize the line from the beginning in a way that, logically, would lead to some groups of TLDs getting to the table (into delegation phase) not later than others. As for the logic of applying priority in the context of processing constraints, the overall principle is the use priority of effort rather than priority of result as long as possible. This minimizes knock-on effects of delays. ------------- 7. Include a statement describing the level of importance that the order of evaluation and delegation has for your application. CORE is not submitting these comments only on its own behalf, but after consultation and discussions with both its customers and other unrelated applicants. As general comments we would like stating that the order of evaluation, and, most notably, the prior decision to publish the evaluations in randomly-selected ?batches? affected mostly *fairness among applicants* more than any other financial, operational or other long-term consideration. Evaluation is just one step on the process of becoming operational, and it is the point at which the TLD can start operations what counts. That is, the delegation point is the critical one. On the Initial Evaluation side, we consider that a) ICANN should proceed as quickly as possible; b) should avoid artificial delays, such as holding for too long evaluated applications for too long and c) if the preceding point advises early publication of a part of the Evaluation Reports, follow the criteria explained above. On the contrary, the moment at which delegation happens is relevant to all applicants. With some distinctions. For a number, but not certainly not all, so-called Exclusive Use TLDs (or Brand TLDs or any other term referring to TLDs not open to third party registrations) the critical point seems to be fairness, in competitive terms: most of the applicants falling within this category we have consulted firmly express that not being significantly delayed with regard to other TLDs in the same industry, sector, area etc., is much more relevant than the concrete moment. On the contrary, for most open-to-third-party-registrations TLDs time is of the essence. And while we acknowledge that this is the for most (perhaps with the partial exception of portfolio applicants), it is specially relevant to community-based TLDs. Most of them have been relying for years upon the work of volunteers, and due to its structure cannot have access to external funding. Both clarity and celerity as to when they will be able to start the registry operations is critical for this subgroup. But not adding further delays, after all these years, is of the utmost importance to most of the applicants. -------------- next part -------------- A non-text attachment was scrubbed... Name: CORE-Comments-Batching-2012-08-18.pdf Type: application/pdf Size: 110856 bytes Desc: not available Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120819/12e1b2e1/CORE-Comments-Batching-2012-08-18.pdf -------------- next part -------------- From Amadeu.Abril at corenic.org Sun Aug 19 10:22:50 2012 From: Amadeu.Abril at corenic.org (Amadeu Abril I Abril) Date: Sun, 19 Aug 2012 12:22:50 +0200 Subject: [Newgtld-input] Comments from CORE- OLd version (based on the Digital Archery proposal) In-Reply-To: <7A0DDD55-F7FE-421D-BE65-9555759D9D35@corenic.org> References: <7A0DDD55-F7FE-421D-BE65-9555759D9D35@corenic.org> Message-ID: <18B78F9E-CCED-4F97-A8A0-43E846A98435@corenic.org> As explained in our previous post, we are also sending the proposal for amending Digital Archery that CORE prepared and circulated prior to the Prague Meeting. As there was no public comment forum available at that time, we submit it now, even if our current proposal is more compete. Amadeu Abril i Abril Chief Policy Advisor CORE Internet Council of Registrars http://corenic.org -------------- next part -------------- A non-text attachment was scrubbed... Name: OLD VERSION - CORE-AmendingDigitalArchery c?pia 2.pdf Type: application/pdf Size: 90127 bytes Desc: not available Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120819/e3eb4fc4/OLDVERSION-CORE-AmendingDigitalArcherycpia2.pdf From davepanos at gmail.com Sun Aug 19 20:24:18 2012 From: davepanos at gmail.com (Dave Panos) Date: Sun, 19 Aug 2012 15:24:18 -0500 Subject: [Newgtld-input] United TLD's response to ICANN"s request for community input on batching / metering Message-ID: Thank you for the opportunity to provide input into gTLD batching. We value ICANN?s approach to openly soliciting feedback about this critical element of the new gTLD process. United TLD Holdco Ltd has submitted 26 applications for the new gTLD program. We participate in the Registry Stakeholder Group as an Observer and also as an active member of the New gTLD Applicant Group (NTAG). We are firmly in support of NTAG?s nine-point document to ICANN on this topic and voted in favor of it. The points made about initial evaluation timing, metering/sequencing, contention sets, objection period, GAC feedback, pre-delegation testing, contracts, root scaling and transparency are really critical to getting the process moving and restoring credibility to ICANN's new gTLD program. In addition to the consensus view of NTAG, United TLD provided input and feedback to the extensive document on sequencing and metering that was submitted by Google and other community members. We want to go on record with ICANN that we are strongly in support of the philosophy, principles and approach of that document, with just one exception. We do not agree that special categories or buckets of applicants should be created and used to weight the sequencing order. We believe that any attempt to bucket applications, beyond the geographic distribution that ICANN initially selected for digital archery, needlessly and unfairly attempts to assign higher merit to certain types of TLDs. This is a very slippery slope, and ICANN should not be in the business of categorizing or assigning merit to applicants on any basis. In response to question #3 of your request for community input on batching, regarding the level of importance that the order of evaluation and delegation has for our applications -- we assert that the order of application evaluation and gTLD delegation is of critical importance to each of our 26 TLDs. Each of our applications specifies our intention to operate the associated gTLD as an open name space with the expectation of broad usage by many different registrants. Therefore our gTLDs will be subject to the broadest range of competitive pressure from existing and new gTLDs. Time-to-market, sequencing relative to competitive gTLDs and visibility into timing are paramount to the successful launch and development of our gTLDs. ICANN has both the capability and the responsibility to do much, much better than the timetable published on August 17th. It is our belief that ICANN significantly misread the sentiment behind "one large batch" in Prague. It was far from a consensus point of view, and where it was espoused, it was with a strong expectation that ICANN would realize massive efficiencies from a far more homogenous applicant pool than anyone expected. Nobody dreamed that a timetable would come back where initial evaluation results wouldn't be published until more than a year after the application window closed. The community is shocked by your timetable. It is our great hope and expectation that ICANN will challenge itself to rebound from the series of missteps that have characterized the past five months. Now is the time to rise to the occasion and opportunity presented by the new gTLD program. The community has worked diligently over the past few weeks to arrive at substantive postions and approaches with broad participation and support -- this is visible in both the NTAG and Google submitted documents. You have received the community input needed to reorganize the program and get it back onto a winning path. It's time to adopt that input and get serious about operational excellence again. Respectfully yours, Dave Panos Director United TLD Holdco, Inc. From dustin at bfc.cc Sat Aug 18 18:28:38 2012 From: dustin at bfc.cc (dustin at bfc.cc) Date: Sat, 18 Aug 2012 11:28:38 -0700 Subject: [Newgtld-input] Comments on gTLD batching Message-ID: <20120818112838.bc01d2a74975330090196ebba1b09c97.6e6008268b.wbe@email05.secureserver.net> Please see attached our comments/input on gTLD batching. Thank You Dustin Trevino DotVegas, Inc -------------- next part -------------- A non-text attachment was scrubbed... Name: ICANN Comments on Batching Metering Process.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 20026 bytes Desc: not available Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120818/4245783b/ICANNCommentsonBatchingMeteringProcess.docx From game-icann at hichina.com Fri Aug 17 14:45:47 2012 From: game-icann at hichina.com (game-icann at hichina.com) Date: Fri, 17 Aug 2012 22:45:47 +0800 Subject: [Newgtld-input] =?utf-8?q?ICANN_Seeks_input_on_gTLD_Batching?= In-Reply-To: CC3B02AC.2557D%newgtld-input@icann.org References: CC3B02AC.2557D%newgtld-input@icann.org Message-ID: <389cd68f-ee40-4b76-820b-9736a103096d@hichina.com> Dear ICANN, HiChina is supportive of ICANN?s efforts to implement an equitable solution which allows for the orderly allocation of completed gTLD applications into the root. In connection with this initiative, HiChina believes that it is important to reaffirm an important aspect previously articulated by the ICANN Board regarding geographical diversity. Specifically, ICANN needs to ensure that in any final implementation there are adequate safeguards to ensure that applications from no geographic region(s) are unfairly benefitted in being placed into the root. ICANN must ensure that the allocation of these global resources are done in a manner that benefit all global stakeholders, and not just those from a specific geographic region. Best regards, HiChina Team ------------------------------------------------------------------ Sender:newgtld-input Date2012-07-30 06:09 To:[Nothing] Subject:ICANN Seeks input on gTLD Batching Dear Applicant: Opportunity for Community Input: Processing of New gTLD Applications At the Prague ICANN meeting, the new gTLD Program Committee decided to terminate Digital Archery, and instructed ICANN staff to proceedwith the initial evaluation of applications as quickly as possible. This evaluation is in progress based on a tentative project plan that foresees the processing of applications in a single batch, and simultaneous release of results. ICANN believes this approach is consistent with the constraints that various parts of the community have in performing their respective roles in the evaluation process, and with the feedback received from the community at the Prague meeting. This comment opportunity seeks input on requirements for an evaluation and delegation process consistent with previous root zone scaling discussions of smooth delegations, adding no more than 1,000 new gTLDs per year. This outcome can be achieved by the: timing of the release of evaluation results to applicants, timing of the release of applications into the pre-delegation steps of contract execution and pre-delegation testing, metering of delegations of new gTLDs into the root zone. ICANN is committed to executing the evaluation and delegation process in a way that is equitable and meets ICANN?s commitment to ensuring the security and stability of the DNS, consistent with previously established root zone scaling goals. Please write to newgtld-input at icann.org with your input. Comments received by 19 August 2012 (UTC 00:00) will be considered. Background The concept of batching has been a part of the Applicant Guidebook since its first draft. Batching accomplishes three goals: Better management of the evaluation process by placing an upper bound on the number of evaluators necessary and the number of parallel evaluations occurring at any one time. Release of evaluation results to applicants according to a predictable schedule. Delegation of TLDs at a rate acceptable to the technical community, consistent with the root zone scaling discussion. Based on the definitive information that ICANN now has about the pool of applications, and work on the evaluations to date, this commentprocess seeks input to meet requirements for goals #2 and #3. Leading up to and during ICANN?s meeting in Prague, the applicant and community positions on requirements for batching schemes thatwould control the evaluation, communication and delegation of applications were reported to be: The batching solution has to be equitable. The evaluation results have to be announced at the same time. Successful applications should proceed to delegation phase without undue delays. Delegation to the root must be at a smooth rate and must not exceed 1,000 per year. The GAC is planning to issue early warnings shortly after the Toronto ICANN meeting in October 2012. Consideration by the GAC of issues concerning GAC advice on contentious applications is not expected to be finalized before the Beijing meeting in April 2013. During the root scaling discussion, it was agreed that ICANN would not delegate TLDs at a rate greater than 1,000 per year. This is because the primary challenge with maintaining root zone stability is controlling the rate of change to the root zone system and not the size of the root zone itself, meaning delegation should not occur at a rate of 1,000 delegations on a single day. In Prague, the batching and prioritization method known as Digital Archery was terminated and eliminated from further consideration. Recent Developments Initial evaluation of new gTLD applications is underway. Applications are being distributed to evaluators in a way that enables efficient processing. ICANN has conducted pilot evaluations and had discussions with evaluators to accelerate the evaluation schedule. As a result of thesediscussions, the evaluation teams have committed to accelerate the evaluations substantially, while processing them in a single batch. In Prague, a methodology was discussed where the smooth delegation of applications could occur by first releasing applications that passed initial evaluation without the need for clarifying questions, then releasing applications in order of the number of clarifying questions required, from fewest to highest. After analysis, this methodology proved unworkable because 80% to 90% of the total evaluation time is required to form and ask clarifying questions, so little smoothing would result. The current plan indicates that initial evaluation of all applications, processed in a ?single batch?, can be completed in 11-12 months, possibly less ? resulting in publication of results in June-July 2013. Note: It is planned that regular updates to applicants during the evaluation period will be provided. In addition to written reports, ICANN is looking into the use of a webinar / conference call format to deliver updates. For applicants, releasing results in a single batch would mean that the first delegations would occur in late third quarter of 2013, six months later than originally expected. Implications of GAC timing: The GAC plans to ?issue any Early Warnings shortly after the Toronto ICANN meeting, in October 2012,? meaning that Early Warnings would be received within the currently planned single evaluation period. Also, the GAC ?is considering the implications of providing any GAC advice on gTLD applications. These considerations are not expected to be finalized before the Beijing meeting in April 2013.? This is shortly before the currently planned announcement of initial evaluation results (i.e., the schedule without additional accelerations beyond those stated above). Statement of the Issue While there will be some natural smoothing as applications take different paths through objections and contention resolution processes, there will still be a requirement for some method of metering applications into the delegation process. This is due to the relatively high number of applications that mayreach pre-delegation steps at essentially the same time. A metering method has not yet been determined and will need to be developed. Questions to be answered by comments Submitted comments should specifically answer each of the following questions: Should the metering or smoothing consider releasing evaluation results, and transitioning applications into the contract execution and pre-delegation testing phases, at different times? How can applications be allocated to particular release times in a fair and equitable way? Would this approach provide sufficient smoothing of the delegation rate? Provide reasoning for selecting this approach. Should the metering or smoothing be accomplished by downstream metering of application processing (i.e., in the contract execution, pre-delegation testing or delegation phases)? How can applications be allocated to a particular timing in contract execution, pre-delegation testing, or delegation in a fair and equitable way? Provide reasoning for selecting this approach. Include a statement describing the level of importance that the order of evaluation and delegation has for your application. Please write to newgtld-input at icann.org with your input. Comments received by 19 August 2012 (UTC 00:00) will be considered. Regards, New gTLD Team From dmarx at key-systems.net Fri Aug 17 17:41:53 2012 From: dmarx at key-systems.net (dmarx at key-systems.net) Date: Fri, 17 Aug 2012 19:41:53 +0200 Subject: [Newgtld-input] Comment on new gTLD evaluation process Message-ID: <84abe36a1f8c237e49f6c2c083e39b60@key-systems.net> Dear Sir or Madam, Please find below the comment of dotSaarland GmbH on the further new gTLD evaluation process. dotSaarland GmbH (applicant for the string .SAARLAND) We would suggest to release the new TLDs as follows: ICANN should prefer the geoTLDs of public interest (regions, cities, IDNs) in a first batch for the subsequent evaluation. Most (if not all) of those TLDs should not be contested as they require a letter of support by the governing authority. Furthermore, these TLDs are connected to a longtime, tightened sense of community with a pre-defined demand for domains. A second batch should include all other undisputed single applications. Strings with contentions should be placed in a third round if the applicants do not find a way to solve the situation within a given time slot. All applicants should be given the right to opt-out of the first and second batch, as some of them may have plans for a later TLD launch. Should you have any further questions, please do not hesitate to contact us. Best regards, Dorothea Marx Head of Communications dotSaarland GmbH Im Oberen Werk 1 DE-66386 St. Ingbert Phone: +49 (0) 68 94 - 93 96 246 Fax: +49 (0) 68 94 - 93 96 247 E-mail: dmarx at nic-saarland.de Web: www.nic-saarland.de CEO: Alexander Siffrin Registration No.: HR B 19630 - Saarbruecken This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone. From dirk at krischenowski.de Sun Aug 19 14:07:17 2012 From: dirk at krischenowski.de (Dirk Krischenowski) Date: Sun, 19 Aug 2012 16:07:17 +0200 Subject: [Newgtld-input] GeoTLDs' Comment Message-ID: <003201cd7e13$f18499d0$d48dcd70$@krischenowski.de> Dear ICANN, please find attached a joint proposal of 22 applicants for a geographical name gTLD (GeoTLD). The signees are: .?? .?? .?? .?? .ALSACE .AFRICA (DotConnectAfrica Trust) .BERLIN .BOSTON .GENT .HAMBURG .IST .ISTANBUL .MADRID .MOSCOW .MOCKBA .QUEBEC .RIO .RUHR .STOCKHOLM .TIROL .WIEN .VEGAS -------------- next part -------------- A non-text attachment was scrubbed... Name: Comments 19 August 2012 GeoTLDs final.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 28678 bytes Desc: not available Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120819/b1f9f046/Comments19August2012GeoTLDsfinal.docx From dk at dotgmbh.de Sun Aug 19 16:28:01 2012 From: dk at dotgmbh.de (.GmbH | Dirk Krischenowski) Date: Sun, 19 Aug 2012 18:28:01 +0200 Subject: [Newgtld-input] TLDDOT Comment (.GMBH) Message-ID: <006101cd7e27$9a8600b0$cf920210$@dotgmbh.de> Dear ICANN, please find attached our comments for the .GmbH top-level-domain. Kind regards, Dirk Krischenowski Managing Director TLDDOT GmbH (.GmbH Top-Level-Domain) Akazienstra?e 2 10823 Berlin Tel: +49 30 49782354 Fax: +49 30 49782356 Mobile: +49 173 2339156 krischenowski at dotgmbh.de www.dotgmbh.de Registergericht: Handelsregister am Amtsgericht Berlin-Charlottenburg, HRA 124498 B; Gesch?ftsf?hrer: Dirk Krischenowski; Steuernummer 30/035/03469 -------------- next part -------------- A non-text attachment was scrubbed... Name: Comments 19 August 2012 GMBH.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 19995 bytes Desc: not available Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120819/f3ec6759/Comments19August2012GMBH.docx From icbc-icann at hichina.com Fri Aug 17 14:42:04 2012 From: icbc-icann at hichina.com (icbc-icann at hichina.com) Date: Fri, 17 Aug 2012 22:42:04 +0800 Subject: [Newgtld-input] =?utf-8?q?ICANN_Seeks_input_on_gTLD_Batching?= In-Reply-To: CC3B0353.25585%newgtld-input@icann.org References: CC3B0353.25585%newgtld-input@icann.org Message-ID: Dear ICANN, HiChina is supportive of ICANN?s efforts to implement an equitable solution which allows for the orderly allocation of completed gTLD applications into the root. In connection with this initiative, HiChina believes that it is important to reaffirm an important aspect previously articulated by the ICANN Board regarding geographical diversity. Specifically, ICANN needs to ensure that in any final implementation there are adequate safeguards to ensure that applications from no geographic region(s) are unfairly benefitted in being placed into the root. ICANN must ensure that the allocation of these global resources are done in a manner that benefit all global stakeholders, and not just those from a specific geographic region. Best regards, HiChina Team ------------------------------------------------------------------ Sender:newgtld-input Date2012-07-30 06:12 To:[Nothing] Subject:ICANN Seeks input on gTLD Batching Dear Applicant: Opportunity for Community Input: Processing of New gTLD Applications At the Prague ICANN meeting, the new gTLD Program Committee decided to terminate Digital Archery, and instructed ICANN staff to proceedwith the initial evaluation of applications as quickly as possible. This evaluation is in progress based on a tentative project plan that foresees the processing of applications in a single batch, and simultaneous release of results. ICANN believes this approach is consistent with the constraints that various parts of the community have in performing their respective roles in the evaluation process, and with the feedback received from the community at the Prague meeting. This comment opportunity seeks input on requirements for an evaluation and delegation process consistent with previous root zone scaling discussions of smooth delegations, adding no more than 1,000 new gTLDs per year. This outcome can be achieved by the: timing of the release of evaluation results to applicants, timing of the release of applications into the pre-delegation steps of contract execution and pre-delegation testing, metering of delegations of new gTLDs into the root zone. ICANN is committed to executing the evaluation and delegation process in a way that is equitable and meets ICANN?s commitment to ensuring the security and stability of the DNS, consistent with previously established root zone scaling goals. Please write to newgtld-input at icann.org with your input. Comments received by 19 August 2012 (UTC 00:00) will be considered. Background The concept of batching has been a part of the Applicant Guidebook since its first draft. Batching accomplishes three goals: Better management of the evaluation process by placing an upper bound on the number of evaluators necessary and the number of parallel evaluations occurring at any one time. Release of evaluation results to applicants according to a predictable schedule. Delegation of TLDs at a rate acceptable to the technical community, consistent with the root zone scaling discussion. Based on the definitive information that ICANN now has about the pool of applications, and work on the evaluations to date, this commentprocess seeks input to meet requirements for goals #2 and #3. Leading up to and during ICANN?s meeting in Prague, the applicant and community positions on requirements for batching schemes thatwould control the evaluation, communication and delegation of applications were reported to be: The batching solution has to be equitable. The evaluation results have to be announced at the same time. Successful applications should proceed to delegation phase without undue delays. Delegation to the root must be at a smooth rate and must not exceed 1,000 per year. The GAC is planning to issue early warnings shortly after the Toronto ICANN meeting in October 2012. Consideration by the GAC of issues concerning GAC advice on contentious applications is not expected to be finalized before the Beijing meeting in April 2013. During the root scaling discussion, it was agreed that ICANN would not delegate TLDs at a rate greater than 1,000 per year. This is because the primary challenge with maintaining root zone stability is controlling the rate of change to the root zone system and not the size of the root zone itself, meaning delegation should not occur at a rate of 1,000 delegations on a single day. In Prague, the batching and prioritization method known as Digital Archery was terminated and eliminated from further consideration. Recent Developments Initial evaluation of new gTLD applications is underway. Applications are being distributed to evaluators in a way that enables efficient processing. ICANN has conducted pilot evaluations and had discussions with evaluators to accelerate the evaluation schedule. As a result of thesediscussions, the evaluation teams have committed to accelerate the evaluations substantially, while processing them in a single batch. In Prague, a methodology was discussed where the smooth delegation of applications could occur by first releasing applications that passed initial evaluation without the need for clarifying questions, then releasing applications in order of the number of clarifying questions required, from fewest to highest. After analysis, this methodology proved unworkable because 80% to 90% of the total evaluation time is required to form and ask clarifying questions, so little smoothing would result. The current plan indicates that initial evaluation of all applications, processed in a ?single batch?, can be completed in 11-12 months, possibly less ? resulting in publication of results in June-July 2013. Note: It is planned that regular updates to applicants during the evaluation period will be provided. In addition to written reports, ICANN is looking into the use of a webinar / conference call format to deliver updates. For applicants, releasing results in a single batch would mean that the first delegations would occur in late third quarter of 2013, six months later than originally expected. Implications of GAC timing: The GAC plans to ?issue any Early Warnings shortly after the Toronto ICANN meeting, in October 2012,? meaning that Early Warnings would be received within the currently planned single evaluation period. Also, the GAC ?is considering the implications of providing any GAC advice on gTLD applications. These considerations are not expected to be finalized before the Beijing meeting in April 2013.? This is shortly before the currently planned announcement of initial evaluation results (i.e., the schedule without additional accelerations beyond those stated above). Statement of the Issue While there will be some natural smoothing as applications take different paths through objections and contention resolution processes, there will still be a requirement for some method of metering applications into the delegation process. This is due to the relatively high number of applications that mayreach pre-delegation steps at essentially the same time. A metering method has not yet been determined and will need to be developed. Questions to be answered by comments Submitted comments should specifically answer each of the following questions: Should the metering or smoothing consider releasing evaluation results, and transitioning applications into the contract execution and pre-delegation testing phases, at different times? How can applications be allocated to particular release times in a fair and equitable way? Would this approach provide sufficient smoothing of the delegation rate? Provide reasoning for selecting this approach. Should the metering or smoothing be accomplished by downstream metering of application processing (i.e., in the contract execution, pre-delegation testing or delegation phases)? How can applications be allocated to a particular timing in contract execution, pre-delegation testing, or delegation in a fair and equitable way? Provide reasoning for selecting this approach. Include a statement describing the level of importance that the order of evaluation and delegation has for your application. Please write to newgtld-input at icann.org with your input. Comments received by 19 August 2012 (UTC 00:00) will be considered. Regards, New gTLD Team From icbcidn-icann at hichina.com Fri Aug 17 14:43:17 2012 From: icbcidn-icann at hichina.com (icbcidn-icann at hichina.com) Date: Fri, 17 Aug 2012 22:43:17 +0800 Subject: [Newgtld-input] =?utf-8?q?ICANN_Seeks_input_on_gTLD_Batching?= In-Reply-To: CC3B0353.25585%newgtld-input@icann.org References: CC3B0353.25585%newgtld-input@icann.org Message-ID: <9b030cd8-0901-411a-9506-b6b87f6b6167@hichina.com> Dear ICANN, HiChina is supportive of ICANN?s efforts to implement an equitable solution which allows for the orderly allocation of completed gTLD applications into the root. In connection with this initiative, HiChina believes that it is important to reaffirm an important aspect previously articulated by the ICANN Board regarding geographical diversity. Specifically, ICANN needs to ensure that in any final implementation there are adequate safeguards to ensure that applications from no geographic region(s) are unfairly benefitted in being placed into the root. ICANN must ensure that the allocation of these global resources are done in a manner that benefit all global stakeholders, and not just those from a specific geographic region. Best regards, HiChina Team ------------------------------------------------------------------ Sender:newgtld-input Date2012-07-30 06:12 To:[Nothing] Subject:ICANN Seeks input on gTLD Batching Dear Applicant: Opportunity for Community Input: Processing of New gTLD Applications At the Prague ICANN meeting, the new gTLD Program Committee decided to terminate Digital Archery, and instructed ICANN staff to proceedwith the initial evaluation of applications as quickly as possible. This evaluation is in progress based on a tentative project plan that foresees the processing of applications in a single batch, and simultaneous release of results. ICANN believes this approach is consistent with the constraints that various parts of the community have in performing their respective roles in the evaluation process, and with the feedback received from the community at the Prague meeting. This comment opportunity seeks input on requirements for an evaluation and delegation process consistent with previous root zone scaling discussions of smooth delegations, adding no more than 1,000 new gTLDs per year. This outcome can be achieved by the: timing of the release of evaluation results to applicants, timing of the release of applications into the pre-delegation steps of contract execution and pre-delegation testing, metering of delegations of new gTLDs into the root zone. ICANN is committed to executing the evaluation and delegation process in a way that is equitable and meets ICANN?s commitment to ensuring the security and stability of the DNS, consistent with previously established root zone scaling goals. Please write to newgtld-input at icann.org with your input. Comments received by 19 August 2012 (UTC 00:00) will be considered. Background The concept of batching has been a part of the Applicant Guidebook since its first draft. Batching accomplishes three goals: Better management of the evaluation process by placing an upper bound on the number of evaluators necessary and the number of parallel evaluations occurring at any one time. Release of evaluation results to applicants according to a predictable schedule. Delegation of TLDs at a rate acceptable to the technical community, consistent with the root zone scaling discussion. Based on the definitive information that ICANN now has about the pool of applications, and work on the evaluations to date, this commentprocess seeks input to meet requirements for goals #2 and #3. Leading up to and during ICANN?s meeting in Prague, the applicant and community positions on requirements for batching schemes thatwould control the evaluation, communication and delegation of applications were reported to be: The batching solution has to be equitable. The evaluation results have to be announced at the same time. Successful applications should proceed to delegation phase without undue delays. Delegation to the root must be at a smooth rate and must not exceed 1,000 per year. The GAC is planning to issue early warnings shortly after the Toronto ICANN meeting in October 2012. Consideration by the GAC of issues concerning GAC advice on contentious applications is not expected to be finalized before the Beijing meeting in April 2013. During the root scaling discussion, it was agreed that ICANN would not delegate TLDs at a rate greater than 1,000 per year. This is because the primary challenge with maintaining root zone stability is controlling the rate of change to the root zone system and not the size of the root zone itself, meaning delegation should not occur at a rate of 1,000 delegations on a single day. In Prague, the batching and prioritization method known as Digital Archery was terminated and eliminated from further consideration. Recent Developments Initial evaluation of new gTLD applications is underway. Applications are being distributed to evaluators in a way that enables efficient processing. ICANN has conducted pilot evaluations and had discussions with evaluators to accelerate the evaluation schedule. As a result of thesediscussions, the evaluation teams have committed to accelerate the evaluations substantially, while processing them in a single batch. In Prague, a methodology was discussed where the smooth delegation of applications could occur by first releasing applications that passed initial evaluation without the need for clarifying questions, then releasing applications in order of the number of clarifying questions required, from fewest to highest. After analysis, this methodology proved unworkable because 80% to 90% of the total evaluation time is required to form and ask clarifying questions, so little smoothing would result. The current plan indicates that initial evaluation of all applications, processed in a ?single batch?, can be completed in 11-12 months, possibly less ? resulting in publication of results in June-July 2013. Note: It is planned that regular updates to applicants during the evaluation period will be provided. In addition to written reports, ICANN is looking into the use of a webinar / conference call format to deliver updates. For applicants, releasing results in a single batch would mean that the first delegations would occur in late third quarter of 2013, six months later than originally expected. Implications of GAC timing: The GAC plans to ?issue any Early Warnings shortly after the Toronto ICANN meeting, in October 2012,? meaning that Early Warnings would be received within the currently planned single evaluation period. Also, the GAC ?is considering the implications of providing any GAC advice on gTLD applications. These considerations are not expected to be finalized before the Beijing meeting in April 2013.? This is shortly before the currently planned announcement of initial evaluation results (i.e., the schedule without additional accelerations beyond those stated above). Statement of the Issue While there will be some natural smoothing as applications take different paths through objections and contention resolution processes, there will still be a requirement for some method of metering applications into the delegation process. This is due to the relatively high number of applications that mayreach pre-delegation steps at essentially the same time. A metering method has not yet been determined and will need to be developed. Questions to be answered by comments Submitted comments should specifically answer each of the following questions: Should the metering or smoothing consider releasing evaluation results, and transitioning applications into the contract execution and pre-delegation testing phases, at different times? How can applications be allocated to particular release times in a fair and equitable way? Would this approach provide sufficient smoothing of the delegation rate? Provide reasoning for selecting this approach. Should the metering or smoothing be accomplished by downstream metering of application processing (i.e., in the contract execution, pre-delegation testing or delegation phases)? How can applications be allocated to a particular timing in contract execution, pre-delegation testing, or delegation in a fair and equitable way? Provide reasoning for selecting this approach. Include a statement describing the level of importance that the order of evaluation and delegation has for your application. Please write to newgtld-input at icann.org with your input. Comments received by 19 August 2012 (UTC 00:00) will be considered. Regards, New gTLD Team From pdiaz at pir.org Fri Aug 17 16:08:21 2012 From: pdiaz at pir.org (Paul Diaz) Date: Fri, 17 Aug 2012 12:08:21 -0400 Subject: [Newgtld-input] PIR comments on Processing of New gTLD Applications Message-ID: <9B54C34E-0978-470D-A22C-8BADEA2B188F@pir.org> Public Interest Registry (PIR) appreciates the opportunity to respond to ICANN?s call for input on gTLD batching. PIR agrees with the staff assessment that ?there will be some natural smoothing as applications take different paths through objections and contention resolution processes.? Applications that take the optimal path (i.e., high scoring, no objections, no contention) should be considered for the first batch. PIR also believes that applications serving a public interest purpose should be a key goal of any batching prioritization process. Round robin sequencing per ICANN region could also be considered, but details of such a plan would have to be fully disclosed allowing for comments, prior to implementation. Best regards, Paul Diaz Director of Policy Public Interest Registry From karenlaw at hk.alibaba-inc.com Fri Aug 17 16:51:06 2012 From: karenlaw at hk.alibaba-inc.com (Karen Law) Date: Sat, 18 Aug 2012 00:51:06 +0800 Subject: [Newgtld-input] FW: ICANN Seeks input on gTLD Batching Message-ID: <004f01cd7c98$7ef9b660$7ced2320$@alibaba-inc.com> Dear Sirs I am writing on behalf of Alibaba Group Holding Limited, the applicant for the new gTLDs: .alibaba, .alipay, .taobao and .tmall. and I set out our comments to the batching issue: The ICANN should evaluate all 1930 applications in a single batch. The Initial Evaluation results should be released at one time which is now expected to be in June / July 2013. If all applications pass the Initial Evaluation, the ICANN should allow all 1179 uncontested applications to move through contract negotiations. It should be noted that the number of uncontested applications may decrease as examiners identify additional contended strings. The ICANN should continue processing these uncontested applications on a first-come, first-served basis, so that if no changes to the contract are negotiated, uncontested applicants may continue through the process in a straightforward manner. If contracts for all 1179 uncontested applications are quickly signed, it is possible that more than 1000 extensions could be added to the root in a year. Based on recent guidance from the Security and Stability Advisory Committee (SSAC) of the ICANN, this does not seem to pose a threat to stability or security but rather a risk to current service levels which could likely be addressed by increasing the necessary resources. The ICANN should allow the remaining 751 contested applications will need to move through the contention process, which will take up to another 6 months post Initial Evaluation results, according the Guidebook. The above comments are provided so as to ensure that all applications can be examined in a fair manner, and that the uncontested applications can proceed to contract negotiation and execution, and all technology related pre-delegation testing can proceed in a straightforward manner and the applicant would be able to exert more control and certainty over the timing when the gTLD can be launched instead of passively waiting for the grant according to different batches. Please let me know if you have any questions or comments. Thank you for your attention. Best regards For and on behalf of Alibaba Group Holding Limited Karen Law Legal Counsel Alibaba Group 26th Floor, Tower One Times Square, 1 Matheson Street Causeway Bay, Hong Kong Direct line: (852) 2215 5345 Facsimile: (852) 2215 5211 General line: (852) 2215 5100 Email: karenlaw at hk.alibaba-inc.com Notice: This email (including any attachments) is sent by the Alibaba Group legal department and is confidential and may be legally privileged. If you received this email in error, please notify us by reply e-mail, delete this message from your system and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you. ???? : ??????(????????????)???????????????????????????????????????????????? ???????????????????????????????????????????????????????????????????????????? ??????????????????????????????????????????????????????????????????????! From: newgtld-input [mailto:newgtld-input at icann.org] Sent: Sunday, July 29, 2012 4:05 PM Subject: ICANN Seeks input on gTLD Batching Dear Applicant: Opportunity for Community Input: Processing of New gTLD Applications At the Prague ICANN meeting, the new gTLD Program Committee decided to terminate Digital Archery, and instructed ICANN staff to proceedwith the initial evaluation of applications as quickly as possible. This evaluation is in progress based on a tentative project plan that foresees the processing of applications in a single batch, and simultaneous release of results. ICANN believes this approach is consistent with the constraints that various parts of the community have in performing their respective roles in the evaluation process, and with the feedback received from the community at the Prague meeting. This comment opportunity seeks input on requirements for an evaluation and delegation process consistent with previous root zone scaling discussions of smooth delegations, adding no more than 1,000 new gTLDs per year. This outcome can be achieved by the: 1. timing of the release of evaluation results to applicants, 2. timing of the release of applications into the pre-delegation steps of contract execution and pre-delegation testing, 3. metering of delegations of new gTLDs into the root zone. ICANN is committed to executing the evaluation and delegation process in a way that is equitable and meets ICANN??s commitment to ensuring the security and stability of the DNS, consistent with previously established root zone scaling goals. Please write to new gtld - input @ icann . org with your input. Comments received by 19 August 2012 (UTC 00:00) will be considered. Background The concept of batching has been a part of the Applicant Guidebook since its first draft. Batching accomplishes three goals: 1. Better management of the evaluation process by placing an upper bound on the number of evaluators necessary and the number of parallel evaluations occurring at any one time. 2. Release of evaluation results to applicants according to a predictable schedule. 3. Delegation of TLDs at a rate acceptable to the technical community, consistent with the root zone scaling discussion. Based on the definitive information that ICANN now has about the pool of applications, and work on the evaluations to date, this commentprocess seeks input to meet requirements for goals #2 and #3. Leading up to and during ICANN??s meeting in Prague, the applicant and community positions on requirements for batching schemes thatwould control the evaluation, communication and delegation of applications were reported to be: 1. The batching solution has to be equitable. 2. The evaluation results have to be announced at the same time. 3. Successful applications should proceed to delegation phase without undue delays. 4. Delegation to the root must be at a smooth rate and must not exceed 1,000 per year. 5. The GAC is planning to issue early warnings shortly after the Toronto ICANN meeting in October 2012. 6. Consideration by the GAC of issues concerning GAC advice on contentious applications is not expected to be finalized before the Beijing meeting in April 2013. During the root scaling discussion, it was agreed that ICANN would not delegate TLDs at a rate greater than 1,000 per year. This is because the primary challenge with maintaining root zone stability is controlling the rate of change to the root zone system and not the size of the root zone itself, meaning delegation should not occur at a rate of 1,000 delegations on a single day. In Prague, the batching and prioritization method known as Digital Archery was terminated and eliminated from further consideration. Recent Developments Initial evaluation of new gTLD applications is underway. Applications are being distributed to evaluators in a way that enables efficient processing. ICANN has conducted pilot evaluations and had discussions with evaluators to accelerate the evaluation schedule. As a result of thesediscussions, the evaluation teams have committed to accelerate the evaluations substantially, while processing them in a single batch. In Prague, a methodology was discussed where the smooth delegation of applications could occur by first releasing applications that passed initial evaluation without the need for clarifying questions, then releasing applications in order of the number of clarifying questions required, from fewest to highest. After analysis, this methodology proved unworkable because 80% to 90% of the total evaluation time is required to form and ask clarifying questions, so little smoothing would result. The current plan indicates that initial evaluation of all applications, processed in a ??single batch??, can be completed in 11-12 months, possibly less ?C resulting in publication of results in June-July 2013. Note: It is planned that regular updates to applicants during the evaluation period will be provided. In addition to written reports, ICANN is looking into the use of a webinar / conference call format to deliver updates. For applicants, releasing results in a single batch would mean that the first delegations would occur in late third quarter of 2013, six months later than originally expected. Implications of GAC timing: The GAC plans to ??issue any Early Warnings shortly after the Toronto ICANN meeting, in October 2012,?? meaning that Early Warnings would be received within the currently planned single evaluation period. Also, the GAC ??is considering the implications of providing any GAC advice on gTLD applications. These considerations are not expected to be finalized before the Beijing meeting in April 2013.?? This is shortly before the currently planned announcement of initial evaluation results (i.e., the schedule without additional accelerations beyond those stated above). Statement of the Issue While there will be some natural smoothing as applications take different paths through objections and contention resolution processes, there will still be a requirement for some method of metering applications into the delegation process. This is due to the relatively high number of applications that mayreach pre-delegation steps at essentially the same time. A metering method has not yet been determined and will need to be developed. Questions to be answered by comments Submitted comments should specifically answer each of the following questions: 1. Should the metering or smoothing consider releasing evaluation results, and transitioning applications into the contract execution and pre-delegation testing phases, at different times? o How can applications be allocated to particular release times in a fair and equitable way? o Would this approach provide sufficient smoothing of the delegation rate? o Provide reasoning for selecting this approach. 2. Should the metering or smoothing be accomplished by downstream metering of application processing (i.e., in the contract execution, pre-delegation testing or delegation phases)? o How can applications be allocated to a particular timing in contract execution, pre-delegation testing, or delegation in a fair and equitable way? o Provide reasoning for selecting this approach. o Include a statement describing the level of importance that the order of evaluation and delegation has for your application. Please write to newgtld - input @ icann . org with your input. Comments received by 19 August 2012 (UTC 00:00) will be considered. Regards, New gTLD Team From jtarabay at key-systems.net Fri Aug 17 18:06:54 2012 From: jtarabay at key-systems.net (Key-Systems GmbH) Date: Fri, 17 Aug 2012 18:06:54 +0000 Subject: [Newgtld-input] Comment on new gTLD evaluation process Message-ID: Dear Sir or Madam, Please find below Key-Systems' comment on the further new gTLD evaluation process. Key-Systems GmbH (parent company of KSregistry GmbH and operator of the corporate domain service BrandShelter) We have consulted with our clients and partners and would suggest to release the new TLDs as follows: ICANN should sort the applications according to the chosen backend provider. This could save a lot of effort and time during the initial registry evaluation round, as applications using the same backend provider will include similar technical specifications. The first batch should consist of: - geoTLDs of public interest (regions, cities, IDNs) => Most (if not all) of those TLDs should not be contested as they require a unique letter of support by the governing authority. The clearly defined communities the TLDs are meant for would benefit from this procedure. Furthermore this definition of a first batch would strengthen ICANN's international approach. - undisputed single applications => This includes applicants who have filed for a string which does not have any contention set. Strings with contentions should be placed in a second round if the applicants do not find a way to solve the situation within a given two week window. All applicants should be given the right to opt-out of the first batch, as some of them may have plans to schedule a later TLD launch. Should you have any further questions, please do not hesitate to contact us. Best regards, Jamile Tarabay Marketing & Event Manager Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Germany Tel.: +49 (0) 6894 - 9396 873 Fax.: +49 (0) 6894 - 9396 851 Email: jtarabay at key-systems.net Web: www.key-systems.net / www.rrpproxy.net www.domaindiscount24.com / www.brandshelter.com www.skyway-datacenter.de / www.dnworker.de http://preorderyourdomain.com Follow us on Twitter or join our fan community on Facebook and stay updated: www.key-systems.net/facebook www.twitter.com/key_systems www.twitter.com/brandshelter www.twitter.com/dd24 www.twitter.com/RRPproxy CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone. From jodyswann at gmail.com Sat Aug 18 17:30:15 2012 From: jodyswann at gmail.com (Jody Swann) Date: Sat, 18 Aug 2012 13:30:15 -0400 Subject: [Newgtld-input] Equitable Delegation Message-ID: Just as ICANN must group strings for evaluation based on string contention, so must it group strings for delegation based on similar competitive interests. An equitable process requires that applicants have the opportunity to declare competitive threats from other strings. As string contentions are resolved according to established rules, there will be a single .green and a single .eco (for example). It is possible that these two applicants will have strongly competing interests. Delegation can only proceed with equity if both are delegated on the same day. This competitive circumstance will undoubtedly exist for many other pairs, as well as groups, of strings. The *relative* timing for disclosing application results and subsequent delegation is more important than *absolute* timing. While plans and business interests may be frustrated by delay, they could be devastated by arbitrary delegation whereby a competing string gets a head start. Many of the other comments submitted are self-promoting, or promote only a single interest. ICANN must promote the interests of the community by making choices among competing applicants. To be equitable, there must be a non-arbitrary basis for these choices. There currently exist logical divisions for grouping strings to achieve consistency of application results disclosure, and equitable delegation. The following four Tiers represent an ordered system based on community interests, practicality and relative equity among applicants. Application results may be publically disclosed sequentially by Tier. This would allow for more resources to focus on quality of results on a Tier by Tier basis. Alternatively, all application results could be disclosed at once. However, consideration should be given to the resource cost of evaluating later Tier applications early. That is to say, actual delegation may begin sooner if resources are concentrated by Tier. * * *Tier 1*: Allocate all necessary resources to act on what may be considered ?common good? strings and move these strings to delegation as soon as possible. The delegation process is a dependent line of events. It is important that the line starts moving as soon as possible. Get the water boiling or dinner will be late. Three types of strings are likely to meet the ?common good,? absent negative public comments: 1. Community strings 2. Geographic strings (sponsored by sovereign bodies) Note: Should later Tier applicants be allowed to identify community and geographic strings as competitive threats? Is this even likely? 3. IDN?s, In spite of the presence of commercial interests here, the case for IDN?s as an important and overdue addition to the world appears to have been made. However, if an IDN represents a direct competitive threat to a later Tier string, then delegation of the IDN in Tier 1 may be inequitable. For Tier 1 strings with contention issues, objections or GAC warnings, these resolution processes should begin as soon as possible. * * *Tier 2*: Any string that: 1. Has not been identified by another applicant as a competitive threat 2. Has not receive significant (or possibly not any) negative public comments 3. Has not been implicated by GAC For Tier 2 strings with contention issues or that are the target of objections, these resolution processes should begin as soon as possible, but secondary to Tier 1 resolutions from a resource standpoint. * * *Tier 3*: All strings in this Tier will be one of a pair or group that have been mutually or unilaterally identified as competitive threats of one another. This Tier represents the greatest challenge for avoiding arbitrary delegation. Meaningful factors must be discovered, disclosed and evaluated for ordering delegation. Some of the factors that were to be considered in the original batching plan may still be meaningful. Potential criteria for ordering delegation may include the following: - First Ready, First Delegated ? there has been frequent speculation that the administrative processes of application review, dispute resolution and pre-delegation requirements will proceed at different speeds for different applicants and thus smooth itself. In fact this may be the only practical way to order delegation. There will be a two-step process here. First, each string group must clear application review, string contention and possible dispute resolution. These processes are largely beyond the applicant?s control. Second, successful applications must complete pre-delegation requirements. Once both strings in a pair, or all strings in a group, are cleared for pre-delegation, time requirements may need to be implemented to prevent strategic delay by a particular applicant. Once the first applicant of a string pair or group completes requirements, the others must follow within a reasonable time or risk being left behind. Note a difficulty with the following criteria: all strings within a pair or group must meet the conditions. This is necessary, for otherwise there is a risk that applicants would identify favorable strings as competitive threats in order to achieve priority for themselves. - Global distribution ? give priority to underrepresented regions. - Open v. closed registries - there may be a policy consideration consistent with ICANN?s mission to prioritize those competitive string sets that allow for unrestricted public domain registration. - Quasi community purpose ? does a set of competing strings serve a community, social, humanitarian or similar altruistic interest. Keep in mind that pairs and groups of strings that have been declared as competitive threats must still be delegated on the same day regardless of the above factors. * * *Tier 4*: Any strings of applicants that voluntarily agree to be delegated last. Finally, with respect to the identification of competitive threats, ICANN should establish a process to evaluate the legitimacy of unilaterally declared threats. My name is Jerre Swann, Jr. I am a trademark lawyer in Atlanta, Georgia. From josemiguel.moreno.rico at madrid.org Sat Aug 18 18:34:31 2012 From: josemiguel.moreno.rico at madrid.org (MORENO RICO, JOSE MIGUEL) Date: Sat, 18 Aug 2012 20:34:31 +0200 Subject: [Newgtld-input] input to new gTLDs batching process from .MADRID Application Message-ID: <0778391D8079654F8D9EC4B6D776BBB175EEBC0D9B@EX07CL01EVS.madrid.org> Dear all, Please take into account the following considerations from the .MADRID application team regarding de new gTLDs batching process: ? The .MADRID application team has knowledge of the proposal jointly submitted by the .BERLIN and other Geographical Name gTLDs (GeoTLDs) candidatures. We also know the document submitted by CORE some weeks ago. ? We assume a significant part of the prioritization criteria included in both proposals, emphasizing the GeoTLDs interests in a rapid and clear batching process for these applications. ? GeoTLDs are clearly defined by the gTLD Applicant Guidebook, having in common that the string is a meaningful representation or abbreviation of a geographical name that is generally protected by national laws. GeoTLDs have also in common that the respective operator for the string is or is being supported by the relevant sovereign local and national government(s) as well as by social and cultural public institutions. By these least common denominators the GeoTLDs are clearly "Public Interest oriented". ? In our view, uncontested applications that have special public interest status such as GeoTLDs, Other Community gTLDs, or IDNs, must be prioritized, avoiding as much as possible unnecessary delays: ICANN should forward these applications in the "transition to delegation" status after they have been reviewed successfully in order to facilitate a smooth introduction of new TLDs into the root. ? The simultaneous release of evaluation for all the applications in a unique reveal date is unnecessary and counterproductive in our opinion: The new gTLDs "Public Interest oriented" should be very well accepted and contribute to generate positive reputation within the ICANN community including GAC. In terms of business planning, the early approval of GeoTLDs and other Public Interest new gTLDs is likely to contribute to a maximum economic and political success of the New gTLD program and ICANN's reputation as well. Jos? M. Moreno Director Econ?mico-Financiero y de Control de Gesti?n (CFO) Secretar?a General Agencia de Inform?tica y Comunicaciones de la Comunidad de Madrid c/ Embajadores, 181 28045 Madrid ' +34 91 580 49 20 - 91 580 50 00 ' +34 638 21 23 36 6 +34 91 580 11 50 @ josemiguel.moreno.rico at madrid.org From katrin at dotzon.com Sun Aug 19 15:23:00 2012 From: katrin at dotzon.com (Katrin Ohlmer) Date: Sun, 19 Aug 2012 17:23:00 +0200 Subject: [Newgtld-input] ICANN Seeks input on gTLD Batching Message-ID: <04ba01cd7e1e$8575c920$90615b60$@dotzon.com> Dear Sirs, please find below the comment from STADA Arzneimittel AG, applicant for .stada, regarding how to process the applications. Best regards, Katrin Ohlmer ICANN should act responsible ICANN received fees of about 357 Mio USD from applicants around the world to handle the application process professionally and smoothly and according to the guidelines the community developed during many years. We would like to remind ICANN of this fact and request that ICANN acts according to these rules in the future to meet its global commitments. ICANN should increase efficiencies 1. We expect that ICANN increases efficiencies during evaluation: a. Offer an Opt-Out process for applicants which want to be delegated as late as possible. b. Support the GAC to deliver their Early Warning and Advice as soon as possible; i.e. by facilitating an Interim GAC meeting early 2013. 2. We expect that ICANN increases efficiencies during delegation: a. Increase staff for contract execution to release as many applicants per month as possible. b. Define process with IANA for smooth root zone entry. ICANN should take a balanced approach for delegation We expect ICANN to release applicants to delegation in a fair and transparent way. This should include publishing all application results once initial evaluation has been completed. To increase a more balanced approach of delegating TLDs between applicants for single and multiple TLDs we propose that applications from portfolio applicants shall be to put on the same level with all other applications. For this purpose, we define portfolio applicants as entities, which have either directly or indirectly a common ownership. Applications which are not objected, contested or subject to an extended evaluation should be delegated in a round-robin mechanism using six pools - five with the ICANN regions and one with portfolio applicants. Since not all pools will have the same amount of applications, once all applications are delegated from one pool, the round-robin will skip this pool and proceed with applications from the remaining pools. As soon as an application which has been objected, contested or subject to an extended evaluation is resolved, it will be added to the respective pool. ICANN should refund application fees after initial evaluation ICANN has repeatedly stated that application fees are constituted from cost recovery of the gTLD program, costs for auctions/objections and a reserve. According to ICANN the costs associated with the gTLD program and according to ICANN's financial plan were 25,000,000 USD. Dividing these costs through the 1930 applications, each applicant would have to pay 12,953 USD instead of USD 50,000 to achieve cost recovery for ICANN. Therefore we expect to receive a refund which would according to our calculation amount to 37,046 USD per application. From sarahfalvey at google.com Sun Aug 19 19:37:22 2012 From: sarahfalvey at google.com (Sarah Falvey) Date: Sun, 19 Aug 2012 15:37:22 -0400 Subject: [Newgtld-input] Input: Processing of New gTLD Applications Message-ID: *Dear Sir/Madam: Attached please find formal comment to ICANN's request for input in the processing of new gTLD applications. In this letter, we propose a new approach to the rate and sequence at which batches are processed through evaluation and delegation. We are not asking that ICANN re-examine the policies underlying the batching process. The concept of progressively evaluating applications is a policy issue upon which the community debated and agreed. Rather, what we are proposing is a metering mechanism to ensure the most efficient path through the process as possible. Although laid out in more detail in the attached letter, a brief summary of our proposal follows: - Rather than processing applications in large batches, ICANN should treat applications individually and move them to the next stage of the evaluation and delegation process as soon as is feasible. - Due to various bottlenecks in the process, applications will need to be sequenced. We propose an approach of promoting a diversity of application types by dividing the application pool into ?buckets?, reflecting various types of applications, using an arbitrary (but not random) mechanism to sequence applications within each bucket, and creating an initial global sequence of applications by round-robining through the series of buckets. - Because the arbitrary approach to sequencing may not always result in the most efficient allocation of priorities, we propose that applicants may swap slots in the overall sequence by mutual consent. - We believe it should still be possible for ICANN to begin delegating new gTLDs into the root in the first quarter of 2013, and that it is important for both applicants and the credibility of the program that ICANN does so. * *Sincerely, Caspar von Veltheim Bayern Connect, application for .bayer Jacob Malthouse Big Room, applicant for .eco Neal Freeman Celebrate Broadway, applicant for .broadway Sarah Falvey Charleston Road Registry Inc., applicant for .google and others Carolin Silbernagl dotHIV gemeinnuetziger e.V., applicant for .hiv Tim Johnson Dot Kiwi Limited, applicant for .kiwi Mark Dranse GCCIX WLL, applicant for .gcc Rami Schwartz Latin American Telecom, applicant for .tube Julie Chappell London & Partners, applicant for .london Rob Hall Momentous Corp., applicant for .design and others Robert Bolchoz Republican State Leadership Committee, applicant for .gop Gil Hoover, Shubert Organization Inc., applicant for .tickets Antony Van Couvering Top Level Domain Holdings Limited, applicant for .abogado and others James Seng Zodiac Holdings Limited, applicant for .?? and others* -------------- next part -------------- A non-text attachment was scrubbed... Name: gTLDSequencingProposal_final.pdf Type: application/pdf Size: 541261 bytes Desc: not available Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120819/1f260dbf/gTLDSequencingProposal_final.pdf From lesley at nominet.org.uk Sun Aug 19 21:23:14 2012 From: lesley at nominet.org.uk (Lesley Cowley) Date: Sun, 19 Aug 2012 21:23:14 +0000 Subject: [Newgtld-input] Digital Archery Process for Batching new gTLD Applications In-Reply-To: Message-ID: Hi, Please see attached. Regards, Lesley Lesley Cowley, OBE CEO Nominet Minerva House Edmund Halley Road Oxford Science Park Oxford, OX4 4DQ UK Tel: +44-(0)-1865-332211 http://www.nominet.org.uk/ -------------- next part -------------- A non-text attachment was scrubbed... Name: ICANN Board new gTLD Programme Committee - 22.6.12.pdf Type: application/pdf Size: 90367 bytes Desc: ICANN Board new gTLD Programme Committee - 22.6.12.pdf Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120819/e19f3753/ICANNBoardnewgTLDProgrammeCommittee-22.6.12.pdf From philip.du.bois at dns.be Fri Aug 17 13:10:02 2012 From: philip.du.bois at dns.be (Philip Du Bois) Date: Fri, 17 Aug 2012 15:10:02 +0200 (CEST) Subject: [Newgtld-input] Input for applications ".vlaanderen" and ".brussels" with regard to "input on gTLD Batching" Message-ID: <012301cd7c79$9dbe3db0$d93ab910$@staff.dns.be> Dear Sir and/or Madam Please find below the point of view of DNS Belgium the applicant for .brussels and .vlaanderen. 1. Should the metering or smoothing consider releasing evaluation results, and transitioning applications into the contract execution and pre-delegation testing phases, at different times? We consider the release of the evaluation results at different times to be a good approach. There is no valid reason why the publication of the evaluation results should be extended till all applications have been evaluated. This would mean that applications that are not contested and that are successfully evaluated would be held back by those applications that are more problematic. Regardless of the timeline for further processing of the applications after the initial evaluation, it would be detrimental to keep applicants unaware of the fact that their application was successfully evaluated just because not all applications have been evaluated. We also think that the next stages for the handling of the applications can start once they have past the evaluation. This would help smoothing the whole process towards delegation. Starting the following stages only after all evaluations have been concluded and published would create unnecessary and further delays for applicants that have an uncontested string and managed to introduce a complete application file. We would however keep the processing timeline identical for applications (as long as they are not contested or don't need extended evaluation etc.) that have been filed by the same applicant. It would be hard to explain from a legal point of view that the application for .xyz is treated differently from the application for .abc if both applications were introduced by the same applicant and are nearly identical (scope, financial framework and technical setup). a. How can applications be allocated to particular release times in a fair and equitable way? ICANN should consider a simultaneous delegation process that allows applications from the different regions to be added to the root zone within the same timeframe. While this is perhaps more advantageous for those regions that have introduced fewer applications, it is certainly not disadvantageous for the American and European regions. It would certainly add a picture that the new gTLD program truly is global and international in nature. At the same time, we think that applications that can demonstrate a public interest (geographical applications, community based applications and IDN applications) should be handled prior to more generic applications. The first mentioned type of applications can demonstrate by their nature that they serve an already clearly defined community while this is less evident for generic applications. We also think that the risk for objection or string contention is less likely for those applications than for the more generic ones. b. Would this approach provide sufficient smoothing of the delegation rate? While we cannot predict whether our proposed approach would be enough to eliminate all potential timeline issues, we are convinced that it will help smotthing the whole process and is a far better alternative than just releasing one single batch of result after the initial evaluation of all applications. c. Provide reasoning for selecting this approach. We think that ICANN should maximize its efforts to achieve an efficient handling and continuous processing stream of applications while preserving global diversity and particular attention for public interest. In that way future registrants across the globe will see the benefit of the existence of new gTLD's to its fullest potential. 2. Should the metering or smoothing be accomplished by downstream metering of application processing (i.e., in the contract execution, pre-delegation testing or delegation phases)? We believe that the proposed approach as described above would seriously limit the risk of having a congestion in the post evaluation stages. Certainly for applications with public interest there would not be a need for downstream metering. It could be possible that a downstream metering is appropriate for the more generic applications. As the applicant for two geographical names, we feel it would be inappropriate to express ourselves concerning the downstream metering of generic applications. However as a general principle we refer to ICANN's global mission and would advise to what we stated above concerning the fair and equitable processing of applications from the different regions. a. How can applications be allocated to a particular timing in contract execution, pre-delegation testing, or delegation in a fair and equitable way? As the applicant for two geographical names, we feel it would be inappropriate to express ourselves concerning the downstream metering of generic applications. However as a general principle we refer to ICANN's global mission and would advise to what we stated above concerning the fair and equitable processing of applications from the different regions. b. Provide reasoning for selecting this approach. See answer provided previously to similar question. 3. Include a statement describing the level of importance that the order of evaluation and delegation has for your application. We think that a lot of valuable time already has been lost and would like to see that ICANN puts a particular focus on not creating any further delays with the delegation process for new gTLD's. For both our applications (.vlaanderen and .brussels) time is becoming a crucial element. The order of evaluation is important but less critical than the ultimate timing for delegation of the extensions. Both the Flemish and Brussels Governments have already indicated that the start of the registrations (or at least the sunrise phase) should begin before the end of Q1 2014. For further clarifications or questions. Kind regards Philip Du Bois General Manager +32 16 28 49 70 +32 497 51 40 31 DNS Belgium vzw/asbl Ubicenter . Philipssite 5, bus 13 . B-3001 Leuven www.dns.be Description: Beschrijving: cid:5682F95C-155D-41DA-BB84-DF0FE48CD348 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 2328 bytes Desc: not available Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120817/e29699d3/attachment.jpe From krischenowski at dotberlin.de Sun Aug 19 19:22:08 2012 From: krischenowski at dotberlin.de (.berlin | Dirk Krischenowski) Date: Sun, 19 Aug 2012 21:22:08 +0200 Subject: [Newgtld-input] .BERLIN Comment Message-ID: <009501cd7e3f$f09c7fc0$d1d57f40$@dotberlin.de> Dear ICANN, please find attached our comment. Best regards, Dirk Krischenowski Founder and CEO _______________________ dotBERLIN GmbH & Co. KG Akazienstrasse 2 10823 Berlin Germany Tel +49 30 49782354 Fax +49 30 49782356 Mobile +49 173 2339156 E-Mail krischenowski at dotberlin.de Skype "krischenowski" Web www.dotberlin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: Comments 19 August 2012 BERLIN.pdf Type: application/pdf Size: 481425 bytes Desc: not available Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120819/87de2cd9/Comments19August2012BERLIN.pdf From Rebecca.Berkich at xerox.com Sat Aug 18 19:50:55 2012 From: Rebecca.Berkich at xerox.com (Berkich, Rebecca) Date: Sat, 18 Aug 2012 12:50:55 -0700 Subject: [Newgtld-input] Input on gTLD Batching Message-ID: <4E12A65254F67A4B9D2E2305B47C833C0D2E0149@USA7061MS04.na.xerox.net> To Whom It May Concern: I am giving input on behalf of Xerox Corporation to address the batching process for the new gTLDs. Transparency should be fundamental to each step of the process. Response to question #1 and #2. Initial evaluation results should be posted for all applications at the same time. All applicants should be notified at once whether or not they passed Initial Evaluation, so they can immediately made decisions. * Before the initial evaluation results are posted, ICANN should hold a comment forum focused on generating feedback around the already proposed registry agreement. These comments should be considered and incorporated into a new and final registry agreement that will be published along with initial evaluation results. This is an opportunity for corporate attorneys to give feedback that could make finalizing agreements more streamlined for everyone. * Applications that must proceed to Extended Evaluation, are in contention, or have received an objection should proceed through those channels to resolve the roadblock. * Those that are allowed to move on to the registry agreement process should be given the Registry Agreement with feedback incorporated. Then, as the applicants return the Registry Agreement to ICANN (either edited, or not edited), ICANN should process the agreements and, once the agreement is finalized, proceed with pre-delegation testing on a First-In-First-Out (FIFO) basis through using a time-stamp mechanism to process requests. Note that most gTLD applications were made by large companies. The attorneys of those corporations may likely cause some natural staggering during the agreement phase. * When applications have passed all tests, they should be inserted into a launch queue, again, on a FIFO basis. * As applications move through the pre-delegation and launch queue process, ICANN should provide complete transparency on where each application stands through a publicly available online portal. Xerox believes that following the above steps would allow transparent processing of all applications and create a natural cadence that will keep delegation below the 1,000 yearly limit and not cause upset and unfairness through metering or other artificial prioritization. In effect, ICANN would facilitate the batching process by allowing the applicants themselves to control their placement. Proper batching, metering, and smoothing can be achieved through the application process already outlined within the Applicant Guidebook - namely, the process of evaluation itself, the objection process, contention set procedures, the actual registry agreement negotiation process and, ultimately, transition to delegation. These existing elements, in conjunction with a revised registry agreement, a FIFO policy will allow the program to move towards the release of new gTLDs in a consistent, predictable, fair, and transparent manner. Response to question #3. Xerox applied for .xerox and .fujixerox and believes a neutral, transparent, FIFO process levels the field between brand owners and those companies who applied for new gTLDs purely for profit. Our gTLDs were an investment in the future of Xerox and Fuji Xerox, and like many companies, we want to leverage the advantages of our new gTLDs as soon as possible. But since not all applications can get out of the gate first, Xerox wants the entire batching process to be fair and transparent for all applicants. Thank you for opening up comments to the new gTLD batching process. Best regards, Rebecca Berkich Manager, Search Marketing & Domains Xerox Interactive Marketing 26600 SW Parkway, Mailstop 7060-630 Wilsonville, OR 97070 Tel: 503.685.4399 | 8*875.4399 rebecca.berkich at xerox.com From liulm at conac.cn Fri Aug 17 12:30:41 2012 From: liulm at conac.cn (Limei Liu) Date: Fri, 17 Aug 2012 20:30:41 +0800 Subject: [Newgtld-input] CONAC's Comment on Batching Issue- 17 Aug. Message-ID: <000c01cd7c74$1d419420$57c4bc60$@cn> Dear ICANN Staff, In response to ICANN new questions on batching on July 29, China Organizational Name Administration Center (CONAC) would like to add the comment (August 17), in addition to comments made on June 27 and July 13. Previous comments may be found in attachment 1 and attachment 2. Thank you in advance for your consideration. Best Regards, Limei Liu Department of Legal Affairs and International Relations China Organizational Name Adminstration Center (CONAC) Tel:8610 5203 5263 Fax:8610 5203 5001 -------------- next part -------------- A non-text attachment was scrubbed... Name: CONAC's Comment on Batching Issue- 17 Aug..pdf Type: application/pdf Size: 405310 bytes Desc: not available Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120817/f57b0c57/CONACsCommentonBatchingIssue-17Aug..pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: Attachment 1-CONAC-to-Chairman of new gTLD Committee-batching policy.pdf Type: application/pdf Size: 285210 bytes Desc: not available Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120817/f57b0c57/Attachment1-CONAC-to-ChairmanofnewgTLDCommittee-batchingpolicy.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: Attachment 2-Batching Issue.pdf Type: application/pdf Size: 48447 bytes Desc: not available Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120817/f57b0c57/Attachment2-BatchingIssue.pdf From michael at palage.com Sat Aug 18 16:43:12 2012 From: michael at palage.com (Michael D. Palage) Date: Sat, 18 Aug 2012 12:43:12 -0400 Subject: [Newgtld-input] Pharos Global's Batching/Metering Comments Message-ID: <01f001cd7d60$94b47800$be1d6800$@palage.com> Dear ICANN, I submit these comments in my individual capacity as President/CEO of Pharos Global, and not on behalf of any current, previous or future client. In the interest of openness and transparency Pharos Global was involved with over 150 new gTLD applications. While ICANN has asked commenters to respond to a specific list of enumerated questions, I believe that ICANN staff's approach toward this issue is systemic of a much larger problem which hinders ICANN's operational effectiveness. Specifically, this consultative process, either by design or happenstance, is destined to fail. Instead of this process resulting in a bottom up consultative process based on facts and taking into account the full diversity of stakeholder views, the likely result will be a top down staff authored proposal/solution prepared to meet the pending deadline for briefing materials in connection with next month's ICANN Board retreat. Hopefully, this public comment will cause the ICANN Board and the new CEO to pause and ask themselves the following question: are we taking the time to make a decision based on facts and true community consultation, or are we making a decision based on an artificial deadline, with limited facts just to tick a box and claim that we are moving forward? Before you answer that question please consider the following facts. 1. Delay in initiating consultative process and deviation from existing public comment protocol Despite representations by ICANN in June during the Prague meeting that a consultative process would be happening, it was not until the end of July that a formal process was initiated. However, when ICANN staff finally launched this public comment forum, it did so by deviating from the existing ICANN public comment protocol. Specifically, this important consultation was not listed on the global ICANN Public Comment portal webpage, http://www.icann.org/en/news/public-comment. While it was posted in the announcement sections of the ICANN main website and the new gTLD portal, this deviation from existing protocol resulted in confusion within the ICANN community as evidenced by a number of comments received through the public comment forum. It appears that the only reason ICANN staff deviated from posting this important community consultation on the normal Public Comment portal webpage was to break from existing public comment protocol which allows for a 21 day response period. Simply put, because of the delay in launching the public consultation process, ICANN staff did not have sufficient time to allow for a 21 day response period while still meeting ICANN staff's internal deadlines for briefing material in connection with the upcoming ICANN Board retreat (September 12th -13th). 2. Asking for proposals from the community without providing the community the necessary metrics to make informed proposals The first step in effective organizational management would have been to identify potential bottlenecks in the delegation process and seek data points of these potential rate limiting factors BEFORE proceeding with the current consultative phase. It is respectfully submitted that ICANN's current consultative process is premature and should not be undertaken until the following questions are properly answered and the results shared with the global stakeholder community. A) In light of the new IANA contract which will require ICANN to provide "specific documentation demonstrating how the process provided the opportunity for input from relevant stakeholders and was supportive of the global public interest" has ICANN obtained from the GAC any global public interest concerns which it believes needs to be advanced/protected in connection with any batching/metering proposal? For example, the ICANN Board had previously indicated a preference in Digital Archery for a geographical distribution of applications from each of the five ICANN geographical regions. Does the GAC support this, does the ICANN Board still support this. Answers to this and other important public policy questions are important drivers in any final implementation proposals. B) How many delegations into the root can the United States Government (USG) handle on a weekly basis. Although this is perhaps the last step in the delegation process, has ICANN consulted/received a response from the USG with regard to how many new delegations it can process in connection with its existing workload. If so where/when will this response be posted. While the USG has not formally objected to the 1000 new gTLDs per year, does this silence equate to the USG being able to process no more than 19 new gTLDs per week, e.g. 1,000 new gTLDs divided by 52 weeks. It is difficult to engage in a constructive dialog on batching/metering without this important variable. C) With regard to pre-delegation testing, will ICANN require every standard application (e.g. no deviating from existing EPP or technical standards) to undergo complete pre-delegation testing or will there be some type of expedited testing for established backend providers which have already satisfactorily completed this testing or will ICANN require certain applicants and backend registry operators to undergo the same testing hundreds of times? D) How many delegations per week can the more popular backend registry operators handle? While most backend registry operators are unlikely to disclose this information publicly for fear that it will be used against them by a competitor, there is a finite number of gTLDs than even the established and well-funded backend registry operators can handle. While some commenters have claimed that the contracting phase will result in a natural throttling of applications being entered into the root, it is respectfully submitted that these commenters are missing the fact that a large portion of applicants that pass initial evaluation and are not involved in contention sets will sign ICANN's standard registry contract without amendments for the sole purpose of being first to market. Therefore there will likely be large influx of applicants seeking immediate delegation after passing the initial evaluation and being permitted to sign a contract with ICANN. 3. ICANN's wiliness to consider proposals calling for increased efficiencies in the application process The New TLD Applicant Group (NTAG), an Interest Group of the Registry Stakeholder Group, has proposed a number of constructive ideas to increase the efficiencies of processing applications. Without commenting on the merits of each recommendation, ICANN's decision to adopt some or all of these proposals (e.g. pre-delegation testing, pre-approval contractual negotiations, etc.) would have a direct impact on the above discussed rate limiting considerations. Conclusion Hopefully these data points will provide the ICANN Board with the necessary information to engage in some thought leadership discussions during its upcoming ICANN Board retreat instead of feeling pressured to rubber stamp some ICANN staff generated proposal in which the community will be left scratching our heads trying to decipher some highly redacted briefing document circulated a month or more after the Board passes a resolution. Hopefully the ICANN Board will not forget the lessons learned from Digital Archery, that taking one step forward only to have to take three steps back shortly thereafter is not the type of thought leadership that the community and the 1900 plus applicants are looking for at this critical juncture. Respectfully submitted, Michael D. Palage From liulm at conac.cn Mon Aug 20 00:59:14 2012 From: liulm at conac.cn (Limei Liu) Date: Mon, 20 Aug 2012 08:59:14 +0800 Subject: [Newgtld-input] =?utf-8?q?CONAC=E2=80=99s_Comment_on_Batching/Met?= =?utf-8?q?ering_Issue?= Message-ID: <000001cd7e6f$04c5bd70$0e513850$@cn> Dear ICANN Staff, In response to ICANN new questions on batching on July 29, China Organizational Name Administration Center (CONAC) would like to add the following comments. It seems obvious that metering or smoothing is inevitable. It was agreed that ICANN would not delegate TLDs at a rate greater than 1,000 per year. But it is very likely that more than 1000 strings among 1927 applications will pass the evaluation in the same year, even though there may be natural slowdown due to objections and contentions. Thus, downstream metering of the application processing is necessary. In this sense, it is impossible to achieve absolute fairness and equitability. To be relatively equitable, CONAC proposes the following approaches echoing what are mentioned in the previous letters. First, the applicants who have participated secondary timestamp (or the digital archery) project, should be given priority. CONAC noticed that ICANN mentioned the new gTLD batching process in section 1.1.2.5 of Applicant Guidebook: ?If the volume of applications received significantly exceeds 500, applications will be processed in batches and the 5-month timeline will not be met??If batching is required, a secondary time-stamp process will be employed to establish the batches.??? On March 28, 2012, ICANN introduced digital archery and till June 23, 20% of the applicants have already registered their timestamps. But the policy was cancelled after ICANN Prague Meeting. While ICANN canceled the secondary timestamp policy, we appeal ICANN to take consideration of the interest of those applicants who keenly follow ICANN?s rule and policies in respect to digital archery. We strongly believe that the interest of those who have already practiced digital archery should be protected by prioritizing their application in evaluation or contract execution. These applicants highly trust ICANN, which motivate them to actively respond to ICANN policies. If ICANN impair their interest, their trust to ICANN may be affected. At the same time, while the applicants follow the batching policy, they pay high cost by investing in human and financial resources. If they are compensated, it will be unfair to them. Secondly, IDN applications, especially those from developing countries and regions shall be prioritized. The delegation process shall comply with the goals of New gTLD program. According to the introduction of new gTLD program in ICANN website, ?The program's goals include enhancing competition and consumer choice, and enabling the benefits of innovation via the introduction of new gTLDs, including both new ASCII and internationalized domain name (IDN) top-level domains.? CONAC believes that the introduction of new gTLD batching process should be highly consistent with the goals of promoting competition and consumer choice, and enabling the benefits of innovation via the introduction of new gTLDs. It has been proved that the introduction of IDNs is a big innovation and success of the Internet. For instance, according to the 30th Statistical Reports on the Internet Development in China (released by CNNIC in July 2012), the registration number of ?.??? TLD reached 311,399, which is ranked as No.4 in the Chinese TLD Market. Chinese IDN is gaining more popularity among Chinese Internet users. Finally, CONAC would like to express our gratitude to ICANN for providing an opportunity to comment on this issue, as well as ICANN? s continuous effort to move the new gTLD program forward. CONAC values ICANN?s bottom-up policy making process, and wish ICANN take serious consideration of our suggestions. Best Regards, Qing Song CEO China Organizational Name Administration Center ? About CONAC China Organizational Name Administration Center (CONAC) is a non-profit organization affiliated to China State Commission Office for Public Sector Reform (SCOPSR). SCOPSR is an executive organ of the State Commission for Public Sector Reform, which is led by the Premier of the State Council. CONAC, as a stakeholder of ICANN community has participated in ICANN meeting for 4 year, and has sponsored ICANN meeting for 4 times, 2 times as silver sponsor and 2 times as golden sponsor. Right now, CONAC is participating in ICANN new gTLD program to apply for two Chinese TLDs ?.??? (government and government affairs) and ?.??? (public interest). The mission of CONAC is to promote and regulate the development of E-government and online public interest undertakings, and protect the interests of government organizations and public interest organizations. Approved as one of the two registries in China by Ministry of Industry and Information Technology (MIIT), the Chinese Internet industry regulator, CONAC has been operating ?.??.cn? and ?.??.cn? since July15, 2008. From richard at donuts.co Sat Aug 18 23:36:55 2012 From: richard at donuts.co (Tindal Richard) Date: Sat, 18 Aug 2012 16:36:55 -0700 Subject: [Newgtld-input] Donuts' comments on gTLD application processing Message-ID: Please find our comments attached. Regards Richard Tindal COO Donuts -------------- next part -------------- A non-text attachment was scrubbed... Name: Donuts Inc. Comments on Sequencing.pdf Type: application/pdf Size: 122246 bytes Desc: not available Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120818/ee9d0ba7/DonutsInc.CommentsonSequencing.pdf From rcastillo at nic.mx Sat Aug 18 23:38:03 2012 From: rcastillo at nic.mx (Roger Francisco Castillo Cortazar) Date: Sat, 18 Aug 2012 23:38:03 +0000 Subject: [Newgtld-input] Comments on batching Message-ID: <646E78088D2A9F4D9F94512C78674EEE0A74AB51@EXCHANGE-AX.nic.com.mx> Please find attached the comments on batching for the processing of newgtld applications on behalf of eCOM-LAC as applicant of the .LAT TLD Best regards ---------- Este mensaje contiene informacion confidencial y se entiende dirigido y para uso exclusivo del destinatario. Si recibes este mensaje y no eres el destinatario por favor eliminalo, ya que difundir, revelar, copiar o tomar cualquier accion basada en el contenido esta estrictamente prohibido. Network Information Center Mexico, S.C., ubicado en Ave. Eugenio Garza Sada 427 L4-6 Col. Altavista, Monterrey, Mexico, C.P. 64840 recaba tus datos personales necesarios para: la prestacion, estudio, analisis y mejora del servicio, la realizacion de comunicaciones y notificaciones; la transferencia y publicacion en los casos aplicables; el cumplimiento de la relacion existente; asi como para la prevencion o denuncia en la comision de ilicitos. Si eres colaborador o candidato a colaborador de NIC Mexico, tus datos seran utilizados para: la creacion y administracion de tu perfil como profesionista; el otorgamiento de herramientas de trabajo; la realizacion de estudios; el otorgamiento de programas y beneficios para mejorar tu desarrollo profesional; la gestion y administracion de servicios de pago y/o nomina; asi como para contacto y/o notificaciones. Si participas en promociones o en estudios podras dejar de participar. Para mayor informacion revisa el Aviso de Privacidad [https://www.nic.mx/static/content/Politica_de_Proteccion_de_Datos.pdf] This message contains confidential information and is intended only for the individual named. If you are not the named addressee please delete it, since the dissemination, distribuition, copy or taking any action in reliance on the contents is strictly prohibited. Network Information Center Mexico, S.C., located on Av. Eugenio Garza Sada 427 Col. Altavista L4-6, Monterrey, Mexico, CP 64840 collects your personal data which is necessary to: provide, research, analyze and improve the service; send communications and notices; transfer and publish your personal data when applicable; fulfill the existing relationship; prevent or inform in the commission of unlawful acts or events. If the data is processed in your quality of candidate or collaborator of NIC Mexico, the purpose of treatment is to: create and manage your profile as a professional; provide you with working tools; conduct studies; grant benefits and programs to enhance your professional development; manage and administrate payment services and/or payroll; as well as to contact you. If you participate in promotions or surveys you may stop or quit your participation at any time. For more information read the Privacy Note [https://www.nic.mx/static/content/Politica_de_Proteccion_de_Datos.pdf] -------------- next part -------------- A non-text attachment was scrubbed... Name: AAA-ECOM-LAC-DOTLAT-COMMENTS v 3 (2).doc Type: application/msword Size: 40960 bytes Desc: ATT94351.doc Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120818/3e8f167a/AAA-ECOM-LAC-DOTLAT-COMMENTSv32.doc From yzbtliu at gmail.com Fri Aug 17 12:26:14 2012 From: yzbtliu at gmail.com (Amanda Liu) Date: Fri, 17 Aug 2012 20:26:14 +0800 Subject: [Newgtld-input] Inputs on Batching Policy of ICANN Message-ID: Dear ICANN Staff, In response to ICANN?s call on inputs on the batching policy I hereby humbly contribute my opinions. Firstly, I strongly recommend ICANN to think twice before totally deserting the Digital Archery result along with the abolition of Digital Archery process. According to the initial plan, all applicants should participate in the Digital Archery process and then be appointed into evaluation process based on the results. However, due to the widespread contention on the feasibility of the Digital Archery solution, many applicants did not take any action. On the one hand, therefore, the termination of the Digital Archery scheme meets the best interests of applicants of this kind. On the other hand, for those who respected ICANN?s resolution despite all doubts and disagreements and spent significant amount of time, effort and money on implementing Digital Archery, they deserve some kind of compensation fair and square. The most practical compensation they would like to get would be to have support in retaining the Digital Archery result to some extent if ICANN has no other form of compensation at all. It should not be deemed as unreasonable to demand priority of certain degree in both evaluation process and delegation process for those who took action to execute the Digital Archery solution before ICANN?s formal termination was announced. Otherwise, if those who respect ICANN?s resolution could not be fully respected and duly protected, we are safe to say that ICANN?s fame and credibility as a responsible and accountable organization would surely be damaged and future work would be jeopardized. Secondly, community-based IDNs which seek to serve the interest of the general public should receive priority status. Despite the smaller number of IDNs in comparison to other forms of new gTLDs, they actually represent the most special feature of this round of application. Within the IDN group, those community-based and public-interest-oriented gTLDs should be given further priority. IDN and community-based TLDs are different from brand TLDs and should receive additional protection. The general public has to trust that these are run to the benefit of the Internet users and not to the benefit of commercial investors. Wang Rui, Beijing, China From philip.stadtmann at antwerpes.de Mon Aug 20 07:37:26 2012 From: philip.stadtmann at antwerpes.de (Philip Stadtmann) Date: Mon, 20 Aug 2012 09:37:26 +0200 Subject: [Newgtld-input] Input on gTLD Batching Message-ID: <00ed01cd7ea6$a53d95c0$efb8c140$@antwerpes.de> Dear Sirs, We would like to declare our support for the proposal of TLDDOT GmbH (.GmbH Top-Level-Domain): Quote start: Bethink of the Global Public Interest When it comes to a batching procedure ICANN needs to bethink on its mission, core values and the global public interest and not fall for the portfolio applicants line. It is highly inconsistent to value all applications the same through the batching/sequencing process. ICANN has already valued Geographical Names, Communities (except of strings which have been applied for to use as brand or company name) and IDNs differently by attributing a higher weight to them than Standard gTLDs, giving them special categories within the Applicant Guidebook, while also adding restrictions and other requirements to them. This valuation has been agreed upon by a multi-stakeholder consensus within the global Internet Community and cannot been annulled by portfolio latest sequencing ideas. The goals were to give Internet users more choice, support their language and to protect communities' of high semantic meaning on the Internet. The achievements of the new gTLD program will be also measured against these goals. Sequencing all gTLD applications in the same manner would compromise these achievements and differences by valuing generic gTLDs such as .BET, .CLICK or .CASINO in the same way as supported public interest gTLDs such as .PARIS, .IEEE or .ORG in Chinese characters. It is unfair to single applicants, especially the ones without a portfolio of gTLD strings to swap slots (rich applicants pay poor applicants to step back towards a later evaluation/approval date). This mechanism favors the interest of portfolio applicants, who have a greater chance of gaining advantage from this mechanism on average than single applicants. This would compromise what ICANN should represent, especially if it does not take diversity into consideration or take smaller single applicants more seriously or into account. We are strictly against any mechanism which involves money for swapping slots. Withholding applications for Geographical Name, Community and IDN gTLDs until all other applications have been processed might appear to some stakeholders that ICANN does not work in the global public interest, an important and critical part of its mission. The Geographical Name, Community and IDN gTLDs are mostly supported by governments and large communities and are truly in the global public interest. In order to follow ICANN's request to answer specific questions we would like to comment as follows: Should the metering or smoothing consider releasing evaluation results, and transitioning applications into the contract execution and pre-delegation testing phases, at different times? No, since according to the timeline all applications will be released in May/June 2013, which is app. one month after the GAC Advice, we do not see the necessity to establish a new process. How can applications be allocated to particular release times in a fair and equitable way? A fair and equitable way would be to delegate applications in an order that serves the public interest. Such an order should prioritize uncontested applications that have a special public interest status such as a) Geographical Name, b) Community or c) IDN (all together only 242 gTLDs). The sequencing for delegation should follow a round-robin process per ICANN region. An advantage of processing these categories first is that the adherent direct contention sets (at least 107 applications = 1 Geographical Name, 1 IDN, 105 community) are likely to be solved early in the process. As a second step an ICANN region based round-robin should be conducted with uncontested applications from single applicants and portfolio applicants who can choose one string as their preferred one, assuming this string has neither objections nor contention. The round-robin will be continued as long as necessary. Applications in extended evaluation, objection, contention and with GAC interaction will be added to the round-robin pool as soon as their objection and/or contention has been completed. Would this approach provide sufficient smoothing of the delegation rate? Our described approach would not only serve the public interest and take the interests of all applicants into respect, it would also allow creating new gTLD success stories for ICANN. Such events are needed to reinforce public interest, trust and reliability in ICANN and are according to ICANN's mission. Should the metering or smoothing be accomplished by downstream metering of application processing (i.e., in the contract execution, pre-delegation testing or delegation phases)? This is a question of facilitating efficiencies in the applications process. The RySG/NTAG group provided guidance on the efficiencies issue which we do not want to echo in detail here. However, with the proposed public interest prioritization and followed by a round-robin method we do not expect any further necessity to downstream delegation rates. Keeping the said above in mind all applicants should be asked if they want to "opt out" with the consequence of being initially evaluated at a later stage. This could significantly decrease the number of applications to be reviewed ASAP. Include a statement describing the level of importance that the order of evaluation and delegation has for your application. Most Community-based gTLD strings are very well accepted and popular new gTLD strings, this is common opinion within the ICANN community including GAC. In terms of business planning an early approval of Community-based gTLD strings is likely to contribute to a maximum economical and political success of the New gTLD program and ICANN's reputation as well. Quote end. When it comes to these two points we have a slightly different view: How can applications be allocated to a particular timing in contract execution, pre-delegation testing, or delegation in a fair and equitable way? ICANN should release competing TLDs at the same time to ensure equal time-to-market. Non competing TLDs can be released at will, whenever they are ready to be delegated. Provide reasoning for selecting this approach. ICANN should try to avoid discrimination of TLD in the delegation process. This would be the case when one TLD is released while another one with the same target audience is not released for no good reason. eom With best regards, DocCheck AG Philip Stadtmann Head of Finance & Controlling Vogelsanger Str. 66 50823 Cologne Germany fon: +49.221.92053-149 fax: +49.221.92053-133 mailto: philip.stadtmann at doccheck.com home: www.doccheck.ag Trade Register Cologne HRB 32420 Executive Board: Dr. Frank Antwerpes (Chairman), Helmut Rieger Chairman of the supervisory board: Michael Thiess Please note our Disclaimer. From rysg at dotversicherung.de Sun Aug 19 11:05:43 2012 From: rysg at dotversicherung.de (Matthias Pfeifer) Date: Sun, 19 Aug 2012 13:05:43 +0200 Subject: [Newgtld-input] Statement .versicherung to gTLD Batching Message-ID: This is our comment comment on behalf of the applications for .versicherung, .reise and .immo: ** Public Interest TLDs first, then round-robin ** A fair and equitable way would be to delegate applications in an order that first serves both the public interest and a multi-stakeholder approach and is based on community outreach, followed by a fair and transparent process for all other applicants. Such an order should prioritize uncontested applications that support the Global Public Interest and outreach such as a) Geographical Names, b) Communities or c) IDNs. After this a round-robin process per ICANN region would be as fair as possible to applicants to release applications. ** Delegation mechanism of TLDs ** We propose a two-phase delegation mechanism: 1. Phase: Delegation of TLD which are in the Global Public Interest and represent multi-stakeholder interests: Community, Geo and IDN TLDs (app. 240 TLDs). 2. Phase: Delegation of all TLDs which are unobjected, uncontested and not in an extended evaluation (app. 950 TLDs). As soon as other TLDs resolve their contention, objection or extended evaluation, they will be added to the TLDs from Phase 2. The delegation of TLDs during each of these phases should be done on a round-robin mechanism based on ICANN regions. Example: The first 20 TLDs will consist of 4 from the US (.ieee, .nyc, .ngo, .quebec), 4 from Europe (.??????, .gal, .paris, .sport), 4 from Africa (.capetown,. ???, .arab, .durban), 4 from AsiaPac (.kyoto, .taipeh, .cpa,.??) and 2 from Latin America (.lat, .rio). Since there are just 2 GeoTLDs in Latin America and no IDN or Community applicants, the remaining 2 seats will be allocated via round-robin among the other regions. As soon as all TLDs from one region are delegated, the round-robin will be executed among the remaining regions. Once TLDs from Phase 1 are delegated, the round-robin continues with TLDs from Phase 2. Applicants who qualify for Phase 1 criteria (Geo, Community, IDN) and resolved contention, objection or extended evaluation, are awarded priority in the round-robin of Phase 2. ** Efficiencies during evaluation ** Applicants wishing to opt-out should be able to express their wish. This could be executed right after the ICANN meeting in Toronto via TAS or CSC. ** Requesting an interim GAC meeting to facilitate GAC efficiencies ** To increase efficiencies with regards to GAC Advice we are requesting ICANN to organize an interim GAC meeting early in 2013. If necessary we are willing to discuss if funding for such a meeting could come out of the application fee funds. ** Refund of application fees after initial evaluation ** ICANN has repeatedly stated that application fees are constituted from cost recovery of the gTLD program, costs for auctions/objections and a reserve. According to ICANN the costs associated with the gTLD program and according to ICANN's financial plan were 25.000.000 USD. Dividing these costs through the 1930 applications, each applicant would have to pay 12.953 USD instead of USD 50.000 to achieve cost recovery for ICANN. Therefore we expect to receive a refund which would according to our calculation amount to 37.046 USD per application. ** Review limitation to delegation rate ** ICANN has received the recommendation from SSAC, that the delegating of 1.000 TLDs per year will do no harm to the DNS. However there are no grounds which prove that delegating more than 1.000 TLDs annually will do harm to the DNS. Therefore we urge ICANN to consult with SSAC again on the maximum delegation rate of TLDs per year. Beste Gr??e! -------------------------------------------------------------- Matthias Pfeifer dotversicherung-registry GmbH Itzenb?ttler M?hlenweg 35a 21227 Bendestorf Tel. 04183-77489-15 // Fax. 04183-77489-19 HRB 202490 // AG Tostedt Gesch?ftsf?hrer: Axel Schwiersch From xin-icann at hichina.com Fri Aug 17 14:40:09 2012 From: xin-icann at hichina.com (xin-icann at hichina.com) Date: Fri, 17 Aug 2012 22:40:09 +0800 Subject: [Newgtld-input] =?utf-8?q?ICANN_Seeks_input_on_gTLD_Batching?= In-Reply-To: CC3B05C6.255BA%newgtld-input@icann.org References: CC3B05C6.255BA%newgtld-input@icann.org Message-ID: <84178908-6823-46bf-948a-731c2c64a030@hichina.com> Dear ICANN, HiChina is supportive of ICANN?s efforts to implement an equitable solution which allows for the orderly allocation of completed gTLD applications into the root. In connection with this initiative, HiChina believes that it is important to reaffirm an important aspect previously articulated by the ICANN Board regarding geographical diversity. Specifically, ICANN needs to ensure that in any final implementation there are adequate safeguards to ensure that applications from no geographic region(s) are unfairly benefitted in being placed into the root. ICANN must ensure that the allocation of these global resources are done in a manner that benefit all global stakeholders, and not just those from a specific geographic region. Best regards, HiChina Team ------------------------------------------------------------------ Sender:newgtld-input Date2012-07-30 06:22 To:[Nothing] Subject:ICANN Seeks input on gTLD Batching Dear Applicant: Opportunity for Community Input: Processing of New gTLD Applications At the Prague ICANN meeting, the new gTLD Program Committee decided to terminate Digital Archery, and instructed ICANN staff to proceedwith the initial evaluation of applications as quickly as possible. This evaluation is in progress based on a tentative project plan that foresees the processing of applications in a single batch, and simultaneous release of results. ICANN believes this approach is consistent with the constraints that various parts of the community have in performing their respective roles in the evaluation process, and with the feedback received from the community at the Prague meeting. This comment opportunity seeks input on requirements for an evaluation and delegation process consistent with previous root zone scaling discussions of smooth delegations, adding no more than 1,000 new gTLDs per year. This outcome can be achieved by the: timing of the release of evaluation results to applicants, timing of the release of applications into the pre-delegation steps of contract execution and pre-delegation testing, metering of delegations of new gTLDs into the root zone. ICANN is committed to executing the evaluation and delegation process in a way that is equitable and meets ICANN?s commitment to ensuring the security and stability of the DNS, consistent with previously established root zone scaling goals. Please write to newgtld-input at icann.org with your input. Comments received by 19 August 2012 (UTC 00:00) will be considered. Background The concept of batching has been a part of the Applicant Guidebook since its first draft. Batching accomplishes three goals: Better management of the evaluation process by placing an upper bound on the number of evaluators necessary and the number of parallel evaluations occurring at any one time. Release of evaluation results to applicants according to a predictable schedule. Delegation of TLDs at a rate acceptable to the technical community, consistent with the root zone scaling discussion. Based on the definitive information that ICANN now has about the pool of applications, and work on the evaluations to date, this commentprocess seeks input to meet requirements for goals #2 and #3. Leading up to and during ICANN?s meeting in Prague, the applicant and community positions on requirements for batching schemes thatwould control the evaluation, communication and delegation of applications were reported to be: The batching solution has to be equitable. The evaluation results have to be announced at the same time. Successful applications should proceed to delegation phase without undue delays. Delegation to the root must be at a smooth rate and must not exceed 1,000 per year. The GAC is planning to issue early warnings shortly after the Toronto ICANN meeting in October 2012. Consideration by the GAC of issues concerning GAC advice on contentious applications is not expected to be finalized before the Beijing meeting in April 2013. During the root scaling discussion, it was agreed that ICANN would not delegate TLDs at a rate greater than 1,000 per year. This is because the primary challenge with maintaining root zone stability is controlling the rate of change to the root zone system and not the size of the root zone itself, meaning delegation should not occur at a rate of 1,000 delegations on a single day. In Prague, the batching and prioritization method known as Digital Archery was terminated and eliminated from further consideration. Recent Developments Initial evaluation of new gTLD applications is underway. Applications are being distributed to evaluators in a way that enables efficient processing. ICANN has conducted pilot evaluations and had discussions with evaluators to accelerate the evaluation schedule. As a result of thesediscussions, the evaluation teams have committed to accelerate the evaluations substantially, while processing them in a single batch. In Prague, a methodology was discussed where the smooth delegation of applications could occur by first releasing applications that passed initial evaluation without the need for clarifying questions, then releasing applications in order of the number of clarifying questions required, from fewest to highest. After analysis, this methodology proved unworkable because 80% to 90% of the total evaluation time is required to form and ask clarifying questions, so little smoothing would result. The current plan indicates that initial evaluation of all applications, processed in a ?single batch?, can be completed in 11-12 months, possibly less ? resulting in publication of results in June-July 2013. Note: It is planned that regular updates to applicants during the evaluation period will be provided. In addition to written reports, ICANN is looking into the use of a webinar / conference call format to deliver updates. For applicants, releasing results in a single batch would mean that the first delegations would occur in late third quarter of 2013, six months later than originally expected. Implications of GAC timing: The GAC plans to ?issue any Early Warnings shortly after the Toronto ICANN meeting, in October 2012,? meaning that Early Warnings would be received within the currently planned single evaluation period. Also, the GAC ?is considering the implications of providing any GAC advice on gTLD applications. These considerations are not expected to be finalized before the Beijing meeting in April 2013.? This is shortly before the currently planned announcement of initial evaluation results (i.e., the schedule without additional accelerations beyond those stated above). Statement of the Issue While there will be some natural smoothing as applications take different paths through objections and contention resolution processes, there will still be a requirement for some method of metering applications into the delegation process. This is due to the relatively high number of applications that mayreach pre-delegation steps at essentially the same time. A metering method has not yet been determined and will need to be developed. Questions to be answered by comments Submitted comments should specifically answer each of the following questions: Should the metering or smoothing consider releasing evaluation results, and transitioning applications into the contract execution and pre-delegation testing phases, at different times? How can applications be allocated to particular release times in a fair and equitable way? Would this approach provide sufficient smoothing of the delegation rate? Provide reasoning for selecting this approach. Should the metering or smoothing be accomplished by downstream metering of application processing (i.e., in the contract execution, pre-delegation testing or delegation phases)? How can applications be allocated to a particular timing in contract execution, pre-delegation testing, or delegation in a fair and equitable way? Provide reasoning for selecting this approach. Include a statement describing the level of importance that the order of evaluation and delegation has for your application. Please write to newgtld-input at icann.org with your input. Comments received by 19 August 2012 (UTC 00:00) will be considered. Regards, New gTLD Team From tbrackey at freundandbrackey.com Fri Aug 17 15:20:34 2012 From: tbrackey at freundandbrackey.com (Thomas Brackey II) Date: Fri, 17 Aug 2012 08:20:34 -0700 Subject: [Newgtld-input] New gTLD Application Process -- Batching and the Digital Archery Process Message-ID: <72FA9FC8-BAB3-4AB0-A09F-448024415124@freundandbrackey.com> To whom it may concern: Please post the attached correspondence. Feel fee to contact me with any questions or concerns. Thank you. TAB Thomas A. Brackey II FREUND & BRACKEY LLP 427 North Camden Drive Beverly Hills, CA 90210 USA tel: 310-247-2165, ext. 26 fax: 310-247-2190 tbrackey at freundandbrackey.com From rubensk at nic.br Fri Aug 17 18:23:31 2012 From: rubensk at nic.br (Rubens Kuhl) Date: Fri, 17 Aug 2012 15:23:31 -0300 Subject: [Newgtld-input] New gTLD metering input from NIC.br Message-ID: "1. Should the metering or smoothing consider releasing evaluation results, and transitioning applications into the contract execution and pre-delegation testing phases, at different times?" Different types of applications can be grouped so when every application in that group finishes initial evaluation, their results can be published. These types should be the ones defined in the guidebook: Community Applications, Geographic Applications, Standard Applications, not market-based determinations like brand/open/closed/single-registrant. Community applications will only be given such status if they elect to have a Community Priority Evaluation and pass it. Because of this possibility, community applications will be asked to elect to go or not go through Community Priority Evaluation even if they are not part of a contention set. If the application elects not to go thru Community Priority Evaluation or fails it, it will be considered standard application for the purposes of metering, although keeping the community restrictions on its contract. Geographic applications without government support would be either rejected or moved to the standard status through the metering process, depending on panel determination. However, grouping of evaluation results wouldn't be a factor on determining which applications to send to evaluators. Order of evaluation should still target maximum efficiency measured as the time it takes for the last application to finish evaluation. As GAC Advice is the likely throttle of applications, all successful applications that are not part of a contention set and have not received GAC Early Warning should proceed to pre-delegation testing before publishing of results. It's not assumed that no GAC EW means no GAC Advice, just that it's less likely. Early pre-delegation testing activities cannot be disclosed by applicants as ICANN approval or endorsement as applications are still subject of GAC and ICANN board determinations. Pre-delegation testing should be done for each back-end provider, defined by the same criteria used to optimize technical part evaluations. " 2. Should the metering or smoothing be accomplished by downstream metering of application processing (i.e., in the contract execution, pre-delegation testing or delegation phases)?" At every processing stage, these guidelines should be observed, in this order: 1) First-In-First-Out : Until every application that entered a stage at the same date starts being processed, no other applications that have since arrived should enter processing. 2) Geographic diversity: From every set of applications that enter a processing stage at the same date containing more than one ICANN region, one from each region should be picked from the queue, the same mechanism that would be in place with secondary timestamps. 3) Community priority: From every set of applications that enter a processing stage at the same date, community applications and geographic applications (both community-oriented, each in their own sense) would go first. For contract executions, besides those 3 base guidelines(FIFO, Geographic diversity, Community priority ), these guidelines should be observed: 4-Contract) Applications that have completed early pre-delegation testing should be picked first for contract execution than applications that will still need to go thru pre-delegation testing 5-Contract) Applicants with more than one application in this phase should wait until all applicants with a single application have contracts in place. For each stage, applicants would provide ICANN with a prioritized list of what strings they prefer to prioritize. For this guideline companies that are part of the same group would be treated as a single applicant. For pre-delegation testing, we think the base guidelines are enough, as early pre-delegation testing as suggested in part 1 would leave few applications to this stage at this time. For delegations, besides those 3 base guidelines(FIFO, Geographic diversity, Community priority), these guidelines should be observed: 4-Delegation) IDNs: From every set of TLDs that are ready to be delegated at the same date, IDN TLDs (regardless of being an IDN new gTLD or an IDN ccTLD) should be picked first. 5-Delegation) For TLDs entering delegation stage at the same date, they should be ordered by the A-Label (excluding "xn--" from IDNs) . To achieve fairness, for each set of TLDs being metered, the criteria would be reversed, and the first set would have one criteria or another based on the week number being odd or even. After ordering they would be batched considering the at that time in effect delegation rate (assumed to be of 20 per week approximately). Uppercase or lowercase (IDNs) would be treated equally. This approach would provide priority for important topics (Community applications, IDNs), metering and a process that has variability without being random. The alternating criteria provides fairness (for instance, a string beginning with Z can be either the best thing or the worst thing at a single step, but on average all strings are alike). Smoothing would be by design achieved. " Include a statement describing the level of importance that the order of evaluation and delegation has for your application." We and our clients are not sensitive to the order of evaluation and delegation, so regardless of other TLDs being delegated earlier or later than ours, what we value is delegation at the earliest point in time. To clarify, between a scenario where other TLDs are delegated in February and ours in July, and a scenario where ours are delegated in October and others in December, we prefer the former. Rubens Kuhl NIC.br From taylor.frank at fairwindspartners.com Sat Aug 18 23:07:09 2012 From: taylor.frank at fairwindspartners.com (Taylor.Frank@fairwindspartners.com) Date: Sat, 18 Aug 2012 23:07:09 +0000 Subject: [Newgtld-input] FairWinds' Input on the Processing of New gTLD Applications Message-ID: ICANN, Attached is a document that outlines and describes our position and feedback regarding your request for input form the community on the processing of new gTLD applications. Best regards, Taylor _____________ Taylor L. Frank Vice President FairWinds Partners, LLC 1000 Potomac St., Suite 350 Washington, D.C. 20007 Office: +1 202 223 5232 Email: taylor.frank at fairwindspartners.com This message is intended only for the use of the addressee and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please notify us immediately by return e-mail and delete this e-mail and all attachments from your system. -------------- next part -------------- A non-text attachment was scrubbed... Name: New gTLD Application Processing & Batching Feedback - FairWinds Partners.pdf Type: application/pdf Size: 530553 bytes Desc: New gTLD Application Processing & Batching Feedback - FairWinds Partners.pdf Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120818/1f6431fa/NewgTLDApplicationProcessingBatchingFeedback-FairWindsPartners.pdf From tanyaling at zodiac-corp.com Sun Aug 19 03:44:43 2012 From: tanyaling at zodiac-corp.com (Alan Tan) Date: Sun, 19 Aug 2012 11:44:43 +0800 Subject: [Newgtld-input] Zodiac Comment on Metering Message-ID: Q1. Answer: Zodiac supports the metering should be applied due to the conflict between the number of applications and the capability of ICANN to process the applications. However, Zodiac don't think it's necessary to tie all applications together since different timeframe is needed for different applications. Zodiac would like to propose a prioritization order for applications to begin the next step after announcing the initial evaluation results. Once the initial processing order is determined, nature course will sooner or later lead the applications to its final delegation. To ensure the applications being processed in a fair and equitable manner, prioritization of the applications must have to be considered. As have been discussed by the community, Zodiac supports that the prioritization be given to applications from the developing countries and IDN applications, then community-based applications, geographical names applications and other standard application. the applications with extended evaluation or contention will have to finish up their respective issues before entering into the transition to delegation stage. At any given time, applications which need metering will be addressed in line with this principle so that the fairness and equity been kept all the time. The reasoning for picking up this order of prioritization is because the mission of ICANN is to bolster the development of Internet of the world and to boost the competition in the domain name market. And given the fact that legacy TLDs and the first two rounds of gTLD expansions have all benefited ASCII TLDs and developed countries. In this third round, Zodiac think that ICANN should use the proposed prioritization order to help other countries and other languages. Q.2 Answer: please refer to the abovementioned principles. Q.3 Zodiac has applied for multiple applications, including several Chinese IDN strings and ASCII strings. Hence Zodiac is totally aware of the effect of the approach will have on its applications. As an applicant deeply rooted in Asia, Zodiac has seen the Internet users in the region have been served properly in terms of the usage of the domain names in their own languages. As an IDN expert, the founder of Zodiac, Mr. James Seng have been devoted in the IDN technology and its adoption of IDN for over a decade. After ten years of waiting and two rounds of missed opportunity for IDNs in the ICANN community, Zodiac strongly believes that it is high time IDN be given the priority to go ahead in the round and Zodiac would like to propose abovementioned approach to process for the sake of the IDN and its missed decade. From tanyaling at zodiac-corp.com Sun Aug 19 03:48:07 2012 From: tanyaling at zodiac-corp.com (Alan Tan) Date: Sun, 19 Aug 2012 11:48:07 +0800 Subject: [Newgtld-input] Yuwei's Comments on Metering Message-ID: This comments is sent on behalf of Yuwei, the applicant for 4 Chinese geographical names TLDs. Q.1 Answer: as a geographic name TLDs applicant, Yuwei would like to echo the comments made by other geo-TLD applicant on the metering of the geographic TLDs. Further, Yuwei would like to stress the importance and value of positioning geo-TLDs and IDN in the priority of the metering method. A fair and equitable way would be to delegate applications in an order that serves the public interest and supporting the development of Internet in the under-development countries. Such an order should prioritize uncontested applications that have a special public interest status such as Geographical Nam, IDNs. As a second step an ICANN region based round-robin should be conducted with uncontested applications from five geographic regions, the round-robin will be continued as long as necessary. Applications in extended evaluation, objection, contention and with GAC interaction will be added to the round-robin pool as soon as their objection and/or contention has been completed. Q.2 Q.3 Answer:Yuwei is the applicant for four Chinese geographical TLDs and a new entrant in ICANN community. Yuwei will benefit from abovementioned approach by given the priority to entering the processes. In terms of business planning an early approval of Geo-TLDs is likely to contribute to a maximum economic and political success of the New gTLD program and ICANN?s reputation as well. And Yuwei is convinced that putting IDNs and geographic names in a preferential position will not only substantially support the Internet development in developing countries, but also manifest the true value of ICANN. From rickert at anwaelte.de Sun Aug 19 13:39:50 2012 From: rickert at anwaelte.de (Thomas Rickert) Date: Sun, 19 Aug 2012 15:39:50 +0200 Subject: [Newgtld-input] Comment from eco Association of the German Internet Industry Message-ID: <35D3F219-6AE6-4AFF-A78B-42751D3D8F28@anwaelte.de> The below comments are made on behalf of eco, the Association of the German Internet Industry (www.eco.de). eco is the German Internet Industry Association with about 600 members from different Internet industry sectors. The association represents over 200 ISPs and Registrars as well as Registries. First of all, ICANN should take all reasonable steps to increase the speed of evaluating all applications. There are synergies arising from the limited number of Registry Service Providers, which lead to partially congruent responses to the technical questions. Applicants that have applied for multiple strings may have used partially congruent information in business plans etc. Hence, the evaluation process can be streamlined without any loss of quality by identifying the variations and determining their impact on the overall assessment. Where possible, applications should be assigned to evaluators in a manner that allows for the common evaluation of substantially similar applications. We also believe that there will be a natural sequencing after the publication of the results of the initial evaluation for all applications due to objections, withdrawals, GAC Advice and contentions, but also due to factors beyond ICANN's control since applicants need to return signed contracts and also apply for the delegation, which provides for additional sequencing. Additionally, all applicants should be given the opportunity to opt for their TLD being delegated at a later stage. ICANN should consider to offer financial incentives for those who opt out. Secondly, the ICANN Community has been advised that the effects of delegating new TLDs into the root zone will be monitored and analyzed. ICANN should seek more information on how this process is envisaged by the technical experts. How many TLDs will they allow to be delegated at first? Will there be a pause for analysis afterwards? How long might such pause be? What will be the sequence of delegations afterwards? ICANN should synchronize its metering with the plans of the technical experts, if possible. Should additional metering be needed, the sequence should be as follows: The absolute majority of eco members that have contributed to this comment are in favor of giving preference to geoTLDs, IDNs and community TLDs.. All applicants will be sent the contracts for execution at the same time, unless their application requires an extended evaluation. Natural sequencing in contract negotiation and execution as well as applying for delegation will provide for natural sequencing. Afterwards, non objected TLDs will be handled in the same manner, unless there is GAC Advice, extended evaluation or a contention. After that, those who opted out will be handled in the same manner, unless there is GAC Advice, extended evaluation or a contention. For cases where there is GAC Advice, an extended evaluation or a contention, the handling will occur as the cases are resolved. ___________________________________________________________ Thomas Rickert, Attorney at Law Director Names & Numbers ------------------------------------- eco - Verband der deutschen Internetwirtschaft e.V. / Association of the German Internet Industry Lichtstra?e 43h 50825 K?ln Fon: +49 (0) 221 - 70 00 48 - 0 Fax: +49 (0) 221 - 70 00 48 - 111 E-Mail: thomas.rickert at eco.de Web: http://www.eco.de --------------------------------------------------- eco - Verband der deutschen Internetwirtschaft e.V. Gesch?ftsf?hrer: Harald A. Summa Vorstand: Prof. Michael Rotert (Vorsitzender), Oliver S?me (stv. Vorsitzender), Klaus Landefeld, Thomas von B?low, Felix H?ger Vereinsregister: Amtsgericht K?ln, VR 14478 Sitz des Vereins: K?ln From Tony.Smith at melbourneit.com.au Sun Aug 19 23:31:27 2012 From: Tony.Smith at melbourneit.com.au (Tony Smith) Date: Sun, 19 Aug 2012 23:31:27 +0000 Subject: [Newgtld-input] Melbourne IT response to call for Input on gTLD Batching Message-ID: <06B34D3ABD1C584BA3B567D977F2A3950589B2FF@bne3-0001mitmbx.corp.mit> Melbourne IT response to call for Input on gTLD Batching ============================================ Melbourne IT welcomes the opportunity to provide a response to ICANN's call for input on gTLD batching, posted on 29 July 2012. (1) Should the metering or smoothing consider releasing evaluation results, and transitioning applications into the contract execution and pre-delegation testing phases, at different times? a. How can applications be allocated to particular release times in a fair and equitable way? b. Would this approach provide sufficient smoothing of the delegation rate? c. Provide reasoning for selecting this approach. In response to question 1: ==================== Please refer to the attached diagram of the evaluation process. Melbourne IT believes that ICANN will be creating an artificial bunching of applications by attempting to release all Initial Reports at the same time, which in turn will lead to bottlenecks in the delegation process. Melbourne IT recommends that initial evaluation reports be released as soon as possible after the evaluations are complete for each application. This allows applicants and the general public to take these initial evaluation reports into account when planning whether to object to an application, as well as planning the allocation of resources to launch a new gTLD. As Melbourne IT previously noted in its letters of 30 May 2012 and 25 June 2012 (http://www.icann.org/en/news/correspondence/hnarakis-to-chalaby-25jun12-en.pdf), there is a high degree of correlation amongst the applications. 72% of the applications are supported by 5 registry operators, while the 5 largest single applicants account for a third of the total applications submitted. By taking advantage of these correlations, it should be possible to complete some initial evaluations either by the end of the year in 2012, or before the ICANN meeting in Beijing in April 2012. Note that the Initial evaluation reports can be released prior to either GAC early warning or GAC advice, as GAC advice ultimately is taken into account by the ICANN staff and Board rather than the external evaluators, which are only evaluating applications against the criteria in the guidebook. If the Initial reports are available at least one month prior to the Beijing meeting (7-12 April 2013), the GAC will be able to take the reports into account when finalizing their advice. Given that some applications have no need for clarifying questions, some will have a few clarifying questions, and others may have many clarifying questions, there should be a natural spread over time for how these questions are dealt with. Given the correlation between applications, there will also be a correlation in receiving and responding to clarifying questions. For example if there is a clarifying question related to the technical operations of an application with a particular registry back-end operator, the same question and response would be required for other applicants using the same registry operator. In response to question 1(a): How can applications be allocated to particular release times in a fair and equitable way? =========================================================================================== With reference to the diagram attached, a fair method of scheduling release times for initial reports would be to consider releasing results in proportion to the number of clarifying questions and the speed to which the responses are provided. For example: - release initial reports for those applications where there were no need for clarifying questions (e.g. 10% of applications as estimated by ICANN) - release initial reports for those applications where there are less than 5 clarifying questions, where answers that have satisfied the evaluators are provided within 14 days - release initial reports for those applications where there are more than 5 clarifying questions, where answers that have satisfied the evaluators are provided within 14 days - release initial reports for those applications where there are less than 5 clarifying questions, where further clarifying questions were required - release initial reports for those applications where there are more than 5 clarifying questions, where further clarifying questions were required The exact sequencing will be determined by the actual spread of clarifying questions and the degree to which the responses have satisfied the examiners. ICANN may choose to use different numbers of clarifying questions to break up the release of initial reports - e.g. less than 2 clarifying questions, less than 3 clarifying questions etc. The sequencing method is fair because those that have provided the most complete answers should have their initial evaluation reports released first. In response to question 1(b): Would this approach provide sufficient smoothing of the delegation rate? ================================================================================ As discussed in response to question 1(a) above, using the amount of clarifying questions, and the degree to which responses have satisfied the evaluators, is one method of smoothing the rate at which initial evaluation reports are released. There are other areas where there will also be a natural smoothing effect. With reference to the attached diagram of the evaluation process: - some applications will receive a GAC Early Warning soon after the Toronto meeting in October 2012, and applicants will want to address the concerns raised by the GAC to avoid getting GAC advice in the transition to delegation phase. - some applications will be subject to one or more formal objection processes - including string confusion objection, legal rights objection, limited public interest objection, or community objection. These applications will not be able to proceed to the delegation phase until the objection process is completed. The timing for when these objection processes complete will also vary, providing more spread over time for when applications are ready to enter the transition to delegation phase. - some applications will fail initial evaluation, and go into extended evaluation. Extended evaluation itself could go through cycles of additional clarifying questions as shown in the attached diagram. - once applications have passed all evaluation and objection processes, there may still be situations where string contention still exists. Applicants have the option to work to resolve string contention while initial evaluation and objection processes are underway. Where string contention still exists, applicants can be given additional time to reach a resolution amongst themselves. Where applicants cannot resolve contention amongst themselves then either community evaluations or an auction process will necessary. The process of resolving string contention will also provide more spread over time for when applications are ready to enter the transition to delegation phase. - once applications enter the transition to delegation phase there are several steps within that phase that may introduce a further spread in timing. Some applications will be able to sign the standard gTLD registry agreement, and others may require changes to conform with their local laws, or to take into account any agreements reached with Governments in response to GAC early warning. Changes will need to be posted for public comment before they could be approved by ICANN. Once an applicant signs a registry agreement, the date and time of receiving the signed application should be noted for use in final scheduling of delegation. - once a gTLD registry agreement has been agreed, a final check will need to be made to see if any GAC advice has been received. The applicant may have the option of resolving the issue for which GAC advice is received . Once the staff prepare a report for the Board, the Board could decide to send an application back for further changes in response to GAC advice, reject the application, or approve the application following the bylaws process for rejecting GAC advice. Each of these steps has its own level of time variation. - once a gTLD agreement has been approved by the Board and sent to IANA for processing, IANA will need to run pre-delegation technical tests. It is likely that the time taken to satisfy the technical tests will vary by applicant, although there will be correlation amongst registry back-end operators that will be able to streamline their processes. As described above, Melbourne IT believes that the combination of spreading the release of initial reports, along with the significant level of variation in the evaluation process as described above, and shown in the attached diagram, should introduce a significant smoothing of the rate at which new gTLDs are ready to be delegated into the root. Should that level of smoothing not be sufficient, Melbourne IT proposes some additional techniques below to meter the flow of new gTLDs into the root. In response to question 1(c): Provide reasoning for selecting this approach. ========================================================= Melbourne IT recommends that ICANN take advantage of the natural smoothing available in the full evaluation process as shown in the attached diagram. A key part of the smoothing available is to avoid artificially bunching applications up at the end of the initial evaluation phase. The fairest approach to evaluation is to take into account the number of clarifying questions, and publish initial reports early for those with no or few clarifying questions. This rewards those applicants that have provided sufficient answers to the questions in the application. Delegation of applications that have passed initial evaluation in the least time, with no objections and no contention, should also naturally proceed to delegation first. ========================================================================================= ========================================================================================= 2. Should the metering or smoothing be accomplished by downstream metering of application processing (i.e., in the contract execution, pre-delegation testing or delegation phases)? a. How can applications be allocated to a particular timing in contract execution, pre-delegation testing, or delegation in a fair and equitable way? b. Provide reasoning for selecting this approach. Response to question 2: =================== Melbourne IT believes that the chances are low that more than 1000 applications will be ready to delegate in a given year. However there may need to be a method to ensure that applications are gradually released into the top level zone. For example it may be desirable not to release more than 100 gTLDs in a given week, or it may be desirable to start with a smaller number in the first few weeks and months, and ramp up to higher numbers as system stability is demonstrated e.g. starting with 10 names a week, and then gradually increasing. Melbourne IT assumes that the ICANN Board is likely to approve gTLDs on a monthly basis once the gTLD registry agreements are signed, and any GAC advice is resolved. The Board can take advantage of the natural variability of the process described in the responses to questions 1 (a) and 1 (b) above, to approve gTLDs in batches. After the Board has approved a batch of applications to be delegated, the staff could schedule the technical testing and delegation of the approved applications on a weekly basis, as described in response to question 2 (a) below. Response to question 2(a): How can applications be allocated to a particular timing in contract execution, pre-delegation testing, or delegation in a fair and equitable way? ===================================================== Once the Board has approved a batch of gTLDs for delegation, the IANA staff could assign gTLDs to weekly delegation slots by using the following prioritisation approach: - allow applicants to request a later slot in the delegation process (or put delegation on hold for up to a year). Depending on the degree to which the applicant choses to delay delegation, ICANN could provide an exemption for the Registry Fees (US$6,250 per quarter) for one or more calendar quarters. - date of receiving a signed gTLD registry agreement - geographic region of the applicant - allocate gTLDs in a weekly slot fairly across the five ICANN geographic regions: North America, Latin America/Caribbean Islands, Asia/Australia/Pacific, Europe and Africa - applications with the highest score in the evaluation process - gTLDs based on IDNs - alphabetical (as a last resort) Response to question 2 (b): Provide reasoning for selecting this approach. ========================================================= It is likely that some metering of applications will be needed to ensure the smooth delegation of gTLDs that have been approved in a batch by the ICANN Board. Applicants should be given the chance to decide themselves whether they are ready for immediate delegation, or whether they would like more time to plan the launch of their gTLD. ICANN could provide exemption from the Registry Fee on a quarterly basis as an incentive for applications to spread their delegations over time. If Applicants don't volunteer for a later delegation slot, ICANN should attempt to even out the delegation rate by taking into account the date of signing of the gTLD agreement and the ICANN Geographic region to ensure an even spread of gTLDs globally. This is likely to ensure that those from regions such as Africa and South America are likely to be able to be delegated when they are ready, as these regions have fewer applications in comparison with USA and Europe. Within a particular geographic region, ICANN should reward those applications that have the highest evaluation score by allowing them to be delegated first. Finally if the above method doesn't result in a sufficient spread of gTLDs across weekly delegation slots, then ICANN could use a last resort method like alphabetical assignment. IDNs would be treated as at the beginning of any alphabetic order. ICANN could alternate between "a" to "z" or "z" to "a" order for each batch approved by the ICANN Board. 3. Include a statement describing the level of importance that the order of evaluation and delegation has for your application. =============================================================================================== Melbourne IT is not an applicant for a new gTLD, but has provided consulting advice for 146 applications. The level of importance of evaluation order and delegation varies by customer. Some customers wish to gain a competitive advantage in the market by launching their new gTLDs as early as possible, while other customers may be happy to take their time to prepare their launch plans by evaluating the approaches successfully used by other gTLD operators and their level of commercial success. A priority for most customers will be certainty that their application has been accepted, but there is likely to be more variability with respect to when customers want to go live with their new gTLD. Thus customers will want to secure a signed registry agreement with ICANN as soon as possible. ----- Tony Smith | General Manager - Corporate Communications | Melbourne IT | Brisbane, Australia | ph +61 7 3230 7525 | fax +61 7 3249 2533 | mob +61 412 879 360 | www.melbourneit.info Melbourne IT Group (ASX: MLB) The information contained in this email message may be confidential. If you are not the intended recipient any use, distribution, disclosure or copying of this information is prohibited. If you receive this email in error, please tell us by return email and delete it and any attachments from your system. P Please consider the environment before printing this e-mail -------------- next part -------------- A non-text attachment was scrubbed... Name: evaluation-process.pdf Type: application/pdf Size: 117576 bytes Desc: evaluation-process.pdf Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120819/a60546b0/evaluation-process.pdf From amy.repp at centralnic.com Fri Aug 17 10:26:10 2012 From: amy.repp at centralnic.com (Amy Repp) Date: Fri, 17 Aug 2012 11:26:10 +0100 Subject: [Newgtld-input] Letter from Etisalat Message-ID: Dear gTLD Evaluation Team, Kindly note the attached letter from Etisalat re: batching, and do not hesitate to contact me with any questions you may have. Thanks and best regards, Amy -- Amy Repp Strategy and Investment www.centralnic.com -------------- next part -------------- A non-text attachment was scrubbed... Name: memo to ICANN.PDF Type: application/pdf Size: 163175 bytes Desc: not available Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120817/9b83cf93/memotoICANN.PDF From George at minardosgroup.com Fri Aug 17 16:48:24 2012 From: George at minardosgroup.com (George Minardos) Date: Fri, 17 Aug 2012 09:48:24 -0700 Subject: [Newgtld-input] Senate and House Judiciary Committee correspondence Message-ID: <415067ADD92AEA4390DD114AE9447386014B92DE@MIN-SRV-01.Minardos.local> To Whom it May Concern, Please post the attached correspondence. Feel free to contact me directly if you have any questions or concerns. Sincerely, George Minardos gTLD applicant George Minardos CEO Minardos Group 2800 28th Street, Suite 170 Santa Monica, CA 90405 Phone 310.450.6900x232 Fax 310.450.6988 george at minardosgroup.com www.minardosgroup.com -------------- next part -------------- To Whom it May Concern, Please post the attached correspondence. Feel free to contact me directly if you have any questions or concerns. Sincerely, George Minardos gTLD applicant [cid:image001.gif at 01CD7C5D.718CFB80] George Minardos CEO Minardos Group 2800 28th Street, Suite 170 Santa Monica, CA 90405 Phone 310.450.6900x232 Fax 310.450.6988 [1]george at minardosgroup.com [2]www.minardosgroup.com References 1. mailto:george at minardosgroup.com 2. http://www.minardosgroup.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2858 bytes Desc: image001.gif Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120817/11541d33/attachment.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: Crocker_Support for ICANN_121708.pdf Type: application/octet-stream Size: 50623 bytes Desc: Crocker_Support for ICANN_121708.pdf Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120817/11541d33/Crocker_SupportforICANN_121708.pdf From Krista.Papac at ausregistry.com Sat Aug 18 23:46:04 2012 From: Krista.Papac at ausregistry.com (Krista Papac) Date: Sun, 19 Aug 2012 09:46:04 +1000 Subject: [Newgtld-input] (no subject) Message-ID: <8CEF048B9EC83748B1517DC64EA130FB72BCF6D04B@off-win2003-01.ausregistrygroup.local> Dear ICANN, Attached please find a letter from the New gTLD Applicant Group (NTAG) in response to ICANNs request for Community Input on the Processing of New gTLD Applications. The NTAG is an Interest Group as described in Article III.D. of the RySG Charter. Interest Groups of the RySG are formed for the purpose of collaborating on issues of common interest and this particular Interest Group is focused on ICANN's New gTLD Program and moving it forward in a responsible but efficient fashion. The attached statement has broad support of the NTAG. The attached letter will be amended and resubmitted in the coming days to include the final vote count. Kind regards, Krista Papac Secretary, New gTLD Applicant Group An Interest Group of the Registry Stakeholder Group On behalf of Jon Nevett, Chairman, New gTLD Applicant Group -------------- next part -------------- A non-text attachment was scrubbed... Name: NTAG Comments Final.pdf Type: application/pdf Size: 60537 bytes Desc: NTAG Comments Final.pdf Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120819/03022195/NTAGCommentsFinal.pdf From kerstin.hoefer at stadt-koeln.de Fri Aug 17 09:54:08 2012 From: kerstin.hoefer at stadt-koeln.de (kerstin.hoefer at stadt-koeln.de) Date: Fri, 17 Aug 2012 11:54:08 +0200 Subject: [Newgtld-input] letter icann Message-ID: <20B8A143512A40459B799362A23E799304661AE4@K00272V01.verbund.kdn.de> A non-text attachment was scrubbed... Name: Dokument2.doc Type: application/msword Size: 70656 bytes Desc: Dokument2.doc Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120817/3d700e09/Dokument2.doc From cs at dothiv.org Mon Aug 20 19:26:02 2012 From: cs at dothiv.org (Carolin Silbernagl) Date: Mon, 20 Aug 2012 21:26:02 +0200 Subject: [Newgtld-input] New gTLD input from dotHIV Message-ID: Dear Chairman Chalaby and Members of the Program Committee, as applicant for the .hiv Top-Level Domain, we support the Proposal on Sequencing submitted by Sarah Falvey, as sent to you on August 19th. With this email we want to highlight some specific elements of the proposal which seem essential to us. dotHIV is a single string applicant operating in favor of the international AIDS response. As a charitable association, we are founded and bound to serve the public interest. With this, dotHIV is one representative of the divers set of new gTLDs. We understand the initial intention of the new gTLD program to enhance competition and consumer choice, and enable the benefits if innovation on the Top Level. Hence we believe that diversity is one of the core values which all actors involved in the New gTLD program embrace. While this diversity is not fully captured by the application categories of IDN, community and geoTLDs alone, we believe that the proposed classes of buckets can get close to it, and kindly ask the program committee to consider this solution. We support that a sequencing of applications is favorable over a batching approach. As a small economic entity, transparency in the process and a clear outline which steps have been accomplished and what lies ahead is very important to us. We are working with partnering organizations which provide generous pro bono support - and being able to tell them on a constant basis how the process is evolving, is essential to manage the network. We assume this to be true for many smaller applicants which are integrated in cooperative structures and/or supported by public actors. Finally, we want to underline the worth we see in a process guided by dialogue - and want to thank the Program Committee for the opportunity to provide input. Kind regards Carolin Silbernagl --- Carolin Silbernagl dotHIV gemeinnuetziger e. V. Lehmbruckstr. 3 10245 Berlin Germany dotHIV gemeinn?tziger e. V. (Incorporated Nonprofit Association) Management Board: Carolin SIlbernagl, Tobias M?lder, Philipp Kafkoulas Commercial Register: Amtsgericht Berlin (Charlottenburg) VR 31092, Registered Office: Berlin From cs at dothiv.org Mon Aug 20 19:32:13 2012 From: cs at dothiv.org (Carolin Silbernagl) Date: Mon, 20 Aug 2012 21:32:13 +0200 Subject: [Newgtld-input] Fwd: Mail delivery failed: returning message to sender References: Message-ID: <1BAEF292-4FDC-4C25-8575-68738B954D69@dothiv.org> Dear New- gTLD Team, with my apologies for the delay and inconvenience: we've sent our comment to the new gTLD metering process yesterday, with delivery failed. As this came to our knowledge just recently, we would appreciate a lot if our comment sent in belatedly (today, Monday, August 20th) could still be taken into consideration. Thank you for your understanding. Kind regards Carolin Silbernagl --- Carolin Silbernagl dotHIV gemeinnuetziger e. V. Lehmbruckstr. 3 10245 Berlin Germany dotHIV gemeinn?tziger e. V. (Incorporated Nonprofit Association) Management Board: Carolin SIlbernagl, Tobias M?lder, Philipp Kafkoulas Commercial Register: Amtsgericht Berlin (Charlottenburg) VR 31092, Registered Office: Berlin > Von: Mail Delivery System > Datum: 19. August 2012 23:20:33 MESZ > An: cs at dothiv.org > Betreff: Mail delivery failed: returning message to sender > > This message was created automatically by mail delivery software. > > A message that you sent could not be delivered to one or more of its > recipients. This is a permanent error. The following address(es) failed: > > newgtld-input at icann.org > SMTP error from remote mail server after RCPT TO:: > host pechora3.icann.org [192.0.33.73]: 550 5.1.1 ... User unknown From bret at internet.pro Tue Aug 21 00:08:38 2012 From: bret at internet.pro (Bret Fausett) Date: Mon, 20 Aug 2012 19:08:38 -0500 Subject: [Newgtld-input] Comments on July 29 Solicitation In-Reply-To: Message-ID: Dear ICANN New gTLD Program Committee: This comment is submitted on behalf of Uniregistry, Corp., a Cayman-based applicant (ICANN Region: Europe) for fifty-four (54) top-level domains, in response to ICANN's applicant solicitation of 29 July 2012. According to the Roadmap published on Friday, we understand that the window for comments is open through the end of today. In response to the issues raised by ICANN, Uniregistry wishes to make the following points: * We believe that the most efficient process flow would allow reviewed and approved applications to move forward along whatever path they would take post-evaluation as soon as they were adjudged as "passed." Once ICANN has reviewed enough applications to establish its baselines for passing and quality control, it should inform the applicants of the results and release the results to the public. * We favor of an ungated process that allows passed applications to move forward beyond the evaluation stage as soon as their evaluation is complete. * Batching has long been a core component of the application process, and we do not believe consensus existed for single batch. To the extent the Board believed that such consensus existed in Prague, we do not believe it took account of the view of Uniregistry or other proponents of an ungated or batched release process. Based on our discussions with other applicants, we believe that applicants representing a majority of submitted applications favor a continuous release over a single batch. * We believe that the order in which ICANN reviews applications should not favor any type of applicant or business model. * Random selection of applications for review should not present legal issues now, after the application window has closed. While the window was still open, random selection for batches would have given applicants an incentive to file multiple redundant applications, withdrawing all but the application that placed earliest in the random queue and creating a kind of lottery for early slots. Now that no one can file an additional application, that lottery problem is gone. * Applicants who applied for multiple strings, including Uniregistry, should have the ability to prioritize their own applications for ICANN. * Pre-delegation testing for registry back-ends should begin as soon as possible. Pre-delegation registry testing should not be dependent on an application passing evaluation. We believe that ICANN should take as many of the pre-delegation testing steps as possible now, pre-accrediting the registry back-ends, so that when an applicant passes, the bulk of this work is complete. Allowing this process to move forward early is especially important if ICANN holds to the concept of a single batch. * Applicants should be able to tender to ICANN's legal department the form of the registry agreement they wish to sign as soon as possible, so ICANN legal can begin the process of pre-approving the form so it is ready for execution as soon as possible following the release of evaluation results. Allowing this process to move forward early is especially important if ICANN holds to the concept of a single batch. We believe that these principles will allow for a timely, efficient and fair evaluation of all applications. Thank you for considering our input into the issues raised. Bret Fausett On behalf of Uniregistry, Corp. -- Bret Fausett, Esq. Internet Pro APC 4640 Admiralty Way, 5th Floor Marina del Rey, California 90292 (310) 496-5755 (Office) | (310) 985-1351 (Mobile) bret at internet.pro | www.internet.pro PGP Key Published at https://keyserver.pgp.com S/MIME Encryption Upon Request CONFIDENTIAL AND PRIVILEGED INFORMATION This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use distribution or disclosure by others is strictly prohibited. If you are not the intended recipient, please email sender and delete all copies of this message. IRS Circular 230 Disclosure: To insure compliance with requirements by the IRS, we inform you that any U.S. tax advice contained in this communication (including any attachments) is not intended or written to be used, and cannot be used, for the purpose of (i) avoiding penalties under the Internal Revenue Code or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein. From harris at cabase.org.ar Tue Aug 21 17:31:09 2012 From: harris at cabase.org.ar (Anthony Harris) Date: Tue, 21 Aug 2012 14:31:09 -0300 Subject: [Newgtld-input] Metering/Batching Comments Message-ID: <8E748D59B1244EE28FEE2A0BCF5B6D87@harrys> Dear Sirs, Please find the attached comments. Was unable to send them yesterday. Kind regards Tony Harris -------------- next part -------------- A non-text attachment was scrubbed... Name: AAA-ECOM-LAC-DOTLAT-COMMENTS v 3 (2).doc Type: application/msword Size: 24576 bytes Desc: not available Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120821/4f482d99/AAA-ECOM-LAC-DOTLAT-COMMENTSv32.doc From liulm at conac.cn Thu Aug 23 08:57:26 2012 From: liulm at conac.cn (Limei Liu) Date: Thu, 23 Aug 2012 16:57:26 +0800 Subject: [Newgtld-input] =?gb2312?b?16q3ojogQ09OQUMncyBDb21tZW50IG9uIEJh?= =?gb2312?b?dGNoaW5nIElzc3VlLSAxNyBBdWcu?= Message-ID: <002801cd810d$515b7a80$f4126f80$@cn> Dear ICANN Staff, We sent our comment on batching on Aug. 17, well before the input deadline of Aug. 19. Pls see the previous letter below and attachment for detail. But we did not find our comment on ICANN comment website http://mm.icann.org/pipermail/newgtld-input/2012-August/thread.html. We are wondering why is that and will our comment be considered? Looking forward to your reply. Best Regards, Limei Liu ???: Limei Liu [mailto:liulm at conac.cn] ????: 2012?8?17???? 20:31 ???: 'newgtld-input at icann.org' ??: 'Steve Crocker (steve at shinkuro.com)'; 'cherine.chalaby at icann.org'; 'Akram Atallah'; 'Kurt Pritz'; 'songqing at conac.cn' ??: CONAC's Comment on Batching Issue- 17 Aug. Dear ICANN Staff, In response to ICANN new questions on batching on July 29, China Organizational Name Administration Center (CONAC) would like to add the comment (August 17), in addition to comments made on June 27 and July 13. Previous comments may be found in attachment 1 and attachment 2. Thank you in advance for your consideration. Best Regards, Limei Liu Department of Legal Affairs and International Relations China Organizational Name Adminstration Center (CONAC) Tel:8610 5203 5263 Fax:8610 5203 5001 -------------- next part -------------- A non-text attachment was scrubbed... Name: CONAC's Comment on Batching Issue- 17 Aug..pdf Type: application/pdf Size: 405310 bytes Desc: not available Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120823/e532f57e/CONACsCommentonBatchingIssue-17Aug..pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: Attachment 1-CONAC-to-Chairman of new gTLD Committee-batching policy.pdf Type: application/pdf Size: 285210 bytes Desc: not available Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120823/e532f57e/Attachment1-CONAC-to-ChairmanofnewgTLDCommittee-batchingpolicy.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: Attachment 2-Batching Issue.pdf Type: application/pdf Size: 48447 bytes Desc: not available Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120823/e532f57e/Attachment2-BatchingIssue.pdf From kpapac at gmail.com Fri Aug 24 19:09:57 2012 From: kpapac at gmail.com (Krista Papac) Date: Fri, 24 Aug 2012 12:09:57 -0700 Subject: [Newgtld-input] NTAG Input on New gTLD Batching, Metering and Initial Evaluation Message-ID: Dear ICANN, As noted in the NTAG's previous submission, the attached is an updated statement which includes the final vote of the NTAG. NTAG members expressed unanimous support of the statement. Please replace the NTAG's previous submission with this updated statement. Kind regards, Krista Papac Secretary, New gTLD Applicant Group An Interest Group of the Registry Stakeholder Group -------------- next part -------------- A non-text attachment was scrubbed... Name: NTAG Comments Final Votes.pdf Type: application/pdf Size: 61017 bytes Desc: not available Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120824/ae39ca6e/NTAGCommentsFinalVotes.pdf From kpapac at gmail.com Fri Aug 24 22:45:50 2012 From: kpapac at gmail.com (Krista Papac) Date: Fri, 24 Aug 2012 15:45:50 -0700 Subject: [Newgtld-input] NTAG Input on New gTLD Batching, Metering and Initial Evaluation In-Reply-To: References: Message-ID: Dear ICANN, Please delete the email I sent earlier today (see below). The NTAG has received a last minute vote and want it to be included in its updated statement which contains member votes. The NTAG represents all Applicants and it is important to the Group that all member views be included. Please note: The NTAG now supports the statement with a 95.5% majority of those voting. Kind regards, -- Krista Papac kpapac at gmail.com o: +1 714 846 8780 m: +1 714 756 0201 ---------- Forwarded message ---------- From: Krista Papac Date: Fri, Aug 24, 2012 at 12:09 PM Subject: NTAG Input on New gTLD Batching, Metering and Initial Evaluation To: newgtld-input at icann.org Cc: Krista Papac , Jon Nevett Dear ICANN, As noted in the NTAG's previous submission, the attached is an updated statement which includes the final vote of the NTAG. Of the NTAG members who voted expressed unanimous support of the statement. Please replace the NTAG's previous submission with this updated statement. Kind regards, Krista Papac Secretary, New gTLD Applicant Group An Interest Group of the Registry Stakeholder Group -- Krista Papac kpapac at gmail.com o: +1 714 846 8780 m: +1 714 756 0201 -------------- next part -------------- A non-text attachment was scrubbed... Name: NTAG Comments Final Votes Amended.pdf Type: application/pdf Size: 86662 bytes Desc: not available Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120824/a3baade4/NTAGCommentsFinalVotesAmended.pdf From newgtld at icann.org Wed Sep 12 13:59:53 2012 From: newgtld at icann.org (CRM-NewGTLD) Date: Wed, 12 Sep 2012 13:59:53 +0000 Subject: [Newgtld-input] FW: [CASE:37147] Written version of my suggestion in today's webinar Message-ID:   > From: Chuck <cgomes at verisign.com> > Date Sent: 12/09/2012 15:34 > To: newgtld at icann.org > Cc: > Subject: [CASE:37147] Written version of my suggestion in today's webinar >   Here is a written version of the suggestion I made today on the New gTLD Metering Update Webinar.       Chuck Gomes Vice President cgomes at verisign.com t: +1 530 676-1754  m: +1 703 362-8753 VerisignInc.com           -------------- next part -------------- A non-text attachment was scrubbed... Name: New gTLD Metering Plan Development Suggestion 12 Sep 12.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 14751 bytes Desc: not available Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120912/bc72c57c/NewgTLDMeteringPlanDevelopmentSuggestion12Sep12.docx From rubensk at nic.br Wed Sep 12 21:04:45 2012 From: rubensk at nic.br (Rubens Kuhl) Date: Wed, 12 Sep 2012 18:04:45 -0300 Subject: [Newgtld-input] New gTLD Batching by string contention Message-ID: (Cc'ed to newgtld-input at icann.org in order to post this message into public record) At the Sep 12 webinar on batching and metering ICANN made clear that although a metering solution is also required, batching has a limited time window to be decided so I'm focusing on batching. I realized that the selection of the applied-for string qualifies for an skill-based determination; in this case, knowledge of the domain industry. In the string selection, applicants were aware of contention set rules and the higher likelihood of some strings to end up in contention sets. This way, each contention set can be seen as its own batch, and as soon as contention sets are finalized, initial results could then be published. That could occur starting the end of the objection period for strings with no objections on any member of the contention set, and the initial evaluation results that were available could be published alongside the contention sets with final formation. If chained contention sets occur (A is in contention with B, B is in contention with C), then the larger set containing all linked contention sets would have to wait all its members to finish evaluation. Evaluation should still target maximum efficiency and not the release of more results, but as a contention set would always have to wait to its members to come to a determination, they are not being penalized for it. This batching criteria doesn't rely on categories, one of the observations in today's consultation, and this idea in different wording has been already proposed during the comment period; only the reasoning for it is believed to be new. Best Regards, Rubens K?hl NIC.br rubensk at nic.br From kpapac at gmail.com Sat Sep 29 16:16:50 2012 From: kpapac at gmail.com (Krista Papac) Date: Sat, 29 Sep 2012 09:16:50 -0700 Subject: [Newgtld-input] NTAG Input on New gTLD Batching, Metering and Initial Evaluation In-Reply-To: References: Message-ID: Dear ICANN, Following on the below email, on August 24 I sent a follow up email stating: "Dear ICANN, Please delete the email I sent earlier today (see below). The NTAG has received a last minute vote and want it to be included in its updated statement which contains member votes. The NTAG represents all Applicants and it is important to the Group that all member views be included. Please note: The NTAG now supports the statement with a 95.5% majority of those voting." The follow up message contained an updated attachment. In looking at the follow message in the publicly posted comments (link: http://mm.icann.org/pipermail/newgtld-input/2012/000100.html) on ICANN's website, when I click on the link for the updated NTAG comments - all I get is jibberish. I've reattached the document to this message. Is it possible to please fix the attachment on your website? Thank you, Krista On Fri, Aug 24, 2012 at 12:09 PM, Krista Papac wrote: > Dear ICANN, > > As noted in the NTAG's previous submission, the attached is an updated > statement which includes the final vote of the NTAG. NTAG members expressed > unanimous support of the statement. Please replace the NTAG's previous > submission with this updated statement. > > Kind regards, > Krista Papac > Secretary, New gTLD Applicant Group > An Interest Group of the Registry Stakeholder Group > > -- Krista Papac kpapac at gmail.com o: +1 714 846 8780 m: +1 714 756 0201 -------------- next part -------------- A non-text attachment was scrubbed... Name: NTAG Comments Final Votes Amended.pdf Type: application/pdf Size: 86662 bytes Desc: not available Url : http://mm.icann.org/pipermail/newgtld-input/attachments/20120929/ac6655f8/NTAGCommentsFinalVotesAmended-0001.pdf