October 2006 - council - lists.icann.org

REMINDER: Public comment period on the Tralliance Proposed New Registry Service
by GNSO.SECRETARIAT＠GNSO.ICANN.ORG 13 Oct '06

13 Oct '06

[To: ga[at]gnso.icann.org; announce[at]gnso.icann.org] [To: liaison6c[at]gnso.icann.org; council[at]gnso.icann.org] REMINDER: ICANN Opens Public Comment Period on the Tralliance Proposed New Registry Service The public comment period on Tralliance’s search.travel wildcard proposal runs until 18 October, 2006. The public comment forum can be found at: http://www.icann.org/announcements/announcement-1-18sep06.htm and is also linked on the Submitted Applications page at: http://www.icann.org/registries/rsep/submitted_app.html. Please take the time to post comments to: tralliance-comments(a)icann.org. Comments can be viewed at: http://forum.icann.org/lists/tralliance-comments. Thank you. -- Glen de Saint Géry GNSO Secretariat - ICANN gnso.secretariat[at]gnso.icann.org http://gnso.icann.org

1 0

Amended draft ToR for IDN policy development activities
by Olof Nordling 13 Oct '06

13 Oct '06

Dear Council members, As requested at the last Council call, please find attached a revised draft ToR for IDN policy development activities. Very best regards Olof

1 0

Draft GNSO Council Agenda for Thursday 19 October 2006
by Bruce Tonkin 12 Oct '06

12 Oct '06

Draft Agenda for Council meeting - Thursday 19 October 2006 Coordinated Universal Time UTC 12:00 (5:00am Los Angeles, 8:00am Washington DC, 9:00am Buenos Aires, 13:00 London, 14:00 Brussels, 19:00 Phnom Penh, 22:00 Melbourne, 00:00 Auckland) Item 1: Update any statements of interest Item 2: Approval of Minutes - 28 September 2006 http://www.gnso.icann.org/mailing-lists/archives/council/msg02876.html Item 3: Correspondence - Letter sent to the Board regarding biz, info, org agreements http://www.gnso.icann.org/mailing-lists/archives/council/msg02880.html - Letter sent to the chair of the GAC regarding advice on new gTLDs Item 4: Proposed bylaws amendment to improve transparency with respect to contract approvals - Jon Nevett and Alistair Dixon to provide proposed changes to the wording supplied by the General Counsel - Jon Nevett to be invited to attend Item 5: Next steps with respect to IDNs - Olof Nordling to identify issues that require resolution prior to issuing a call for new gTLDs that use IDN domains, and propose a possible new terms of reference - Consider whether to address terms of reference via a separate PDP, or initially use a working group approach Note the GNSO Council did form a working group to review the issues report in May 2006, see: http://www.gnso.icann.org/meetings/minutes-gnso-18may06.shtml and this working group could be re-formed to focus on a few issues in collaboration with the ccNSO. Item 6: Next steps for improving the GNSO structure and processes - Possible approaches for working on PDP process, versus GNSO structure Item 7: Update on planning for Sao Paulo Item 8: Any other business Regards, Bruce Tonkin

1 0

FW: Letter from the GNSO requesting GAC advice on Draft Recommendations for the Introduction of new gTLDs
by Bruce Tonkin 12 Oct '06

12 Oct '06

For information - below is a copy of the note that I have sent to the chair of the GAC with regard to seeking advice on new gTLD policy. Regards, Bruce Tonkin 11 October 2006 Mr Mohamed Sharil Tarmizi Chair - ICANN Governmental Advisory Committee Ms Suzanne Sene Chair - GAC GNSO Working Group One Dear Mr Tarmizi and Ms Sene, INTRODUCTION OF NEW TOP LEVEL DOMAINS I am writing to you to seek your further assistance with the Generic Names Supporting Organisation's Policy Development Process on the Introduction of New Top Level Domains. The GNSO new TLDs Committee would be grateful for a formal response from the Governmental Advisory Committee on both the Initial Report (http://gnso.icann.org/issues/new-gtlds/issues-report-15jun06.pdf) and the Draft Recommendations which resulted from the Committee's consideration of the Public Comments received on the recommendations in the Initial Report at the Committee's recent Amsterdam meeting. I have appended the Draft Recommendations to the end of this letter. These Draft Recommendations only have the status of a Working Document and do not yet reflect a formal vote by the GNSO Council. The GNSO Committee on new TLDs has made significant progress through the policy development process. We expect to produce a Final Report by mid November 2006 which will formalize the draft Recommendations on each of the Terms of Reference, the key areas of which are as follows: § whether to continue to introduce new gTLDs; § the selection criteria for approving applications for new gTLDs; § the allocation methods for choosing new gTLDs; and § the policies for contractual conditions for new gTLDs. Additionally, Internationalised Domain Names are foreseen as an integral part of the introduction of new top level domains, and the GNSO is continuing to discuss this issue. The GAC will be pleased to note that the Draft Recommendations have been derived from a comprehensive series of face-to-face consultations with representatives from all the GNSO's Constituencies, input from many individual stakeholders and, of course, from our series of discussions with the GAC and other groups during ICANN's regular meetings. The GNSO Committee has focused, in the preparation of its Draft Recommendations, very closely on ICANN's Mission and Core Values, particularly with respect to cultivating an environment in which competition can flourish, ensuring the stability and security of the Internet, and facilitating bottom-up policy development processes. We understand that the GAC GNSO Working Group I is discussing public policy principles around the introduction of new top level domains and work is ongoing. We are keen to maximise opportunities for timely and constructive input into the GNSO's policy development process and propose that the following ideas may be a constructive way of ensuring effective GAC input: § A formal presentation of the draft set of GAC public policy principles on the introduction of new top level domains; § An invitation for individual governments to submit their comments on each area; and § An invitation for the GAC to submit a position on the introduction of new TLDS using the Final Report as the starting point for those discussions. The GNSO is particularly interested in receiving advice from the GAC on various laws and international agreements or public policy that may impose restrictions in the strings (including possible IDN strings) which may be registered at the top level. We welcome additional suggestions to ensure GAC input and are eager to finalize these arrangements as soon as possible. Time is very much of the essence in our consultations. We look forward to discussing this with you in more detail and concluding our consultation plans. We would greatly appreciate substantive input from the GAC for discussion at the ICANN meeting in Sao Paulo to enable further consideration of the GAC's advice as the GNSO concludes this Policy Development Process, and produces a Board Report for the ICANN Board to consider. Yours sincerely, BRUCE TONKIN Chair of the GNSO Council From: http://gnso.icann.org/issues/new-gtlds/recom-summary-14sep06.htm WORKING DOCUMENT 14 September 2006 DRAFT GNSO Recommendation Summary Introduction of New Generic Top-Level Domains Table of Contents PRINCIPLES RECOMMENDATIONS 1 WHETHER TO INTRODUCE NEW TOP LEVEL DOMAINS 2 SELECTION CRITERIA 3 ALLOCATION METHODS 4 CONTRACTUAL CONDITIONS Principles ========== The following Recommendations have been derived from the work of the GNSO Committee on the introduction of new top level domains in accordance with the Terms of Reference set by the GNSO, with reference to ICANN's Mission and Core Values. a) That new generic top level domains (gTLDs) will be introduced in an orderly and predictable way. b) That some new generic top level domains will be internationalised domain names (IDNs). IDNs use characters drawn from a large repertoire (Unicode). There is a mechanism called Internationalizing Domain Names in Applications (IDNA) that allows the non-ASCII characters to be representing using only the ASCII characters already allowed in so-called host names today (see RFC3490). c) That the principal objective of the introduction of new top level domains is to permit market mechanisms to support competition and consumer choice in the technical management of the DNS. This competition will lower costs, promote innovation, and enhance user choice and satisfaction. d) That a set of "technical criteria" for a new gTLD registry applicant minimises the risk of harming the operational stability, reliability, security, and global interoperability of the Internet. f) That a set of "business capability criteria" for a new gTLD registry applicant provides an assurance that an applicant has the capability to meet its business ambitions. Recommendations =============== 1 Whether to introduce new top level domains ================================================ 1.1 Additional new generic top-level domains should be introduced and work should proceed to enable the introduction of new generic top level domains, taking into account the recommendations found in the following sections. 2 Selection Criteria ======================== 2.1 The process for introducing new top level domains will follow a pre-published application system including the levying of an application fee to recover the costs of the application process. The application process will also include probity rules and clear timelines. 2.2 Application fees will be set at the start of the process and application materials will be available prior to any application round. Some applications may cost different amounts to evaluate. Therefore, different fees may be levied depending on what stage in the process the application reaches. If applicants find the application fee a barrier to entry, ICANN could have a system of grants to assist applicants. This grant would only allow the applicant to apply, without any presumption that the application would be successful. Grant applications would go through an evaluation process. ICANN should evaluate options for funding the grants. 2.3 Technical criteria will include compliance with a minimum set of technical standards that would include IETF Requests for Comment related to the operation of the DNS and other technical standards. Standards may include RFC3730-3735, RFC2246, RFC1035, RFC2181, RFC2182, and the ICANN Guidelines for the Implementation of Internationalized Domain Names. 2.4 Applicants must comply with all ICANN consensus policies as and when they are developed. 2.5 Applicants must choose a string of characters for the new generic top level domain name that complies with the process for string checks below. 2.5.1 ICANN will use the following process for TLD string checks. ---------------------------------------------------------------- 2.5.1.1 ICANN will make a preliminary determination on whether the application complies with the string requirements and may seek expert advice in order to make its preliminary determination. 2.5.1.2 ICANN will establish public comment processes (which may include input from governments or the Governmental Advisory Committee) that are specific to the criteria for the new string. 2.5.1.3 In the event that ICANN reasonably believes that the application for a particular string may not be compliant with the string requirements, ICANN will refer the issue to a panel of experts with appropriate backgrounds. 2.5.2 String Criteria --------------------- 2.5.2.1 The gTLD string should not be confusingly similar to an existing TLD string. Confusingly similar means there is a likelihood of confusion on the part of the relevant public. 2.5.2.2 The string must not infringe the legal rights of any third party (consistent with the current requirements of Registered Name Holders - see Clause 3.7.7.9 of the gTLD Registrar Accreditation Agreement). 2.5.2.3 The string should not cause any technical issues, for example, .localhost and .exe would be unacceptable name strings. 2.5.2.4 The string should not be in conflict with national or international laws or cause conflicts with public policy [for example, controversial, political, cultural religious terms]. (Develop text related to public policy issues with GAC assistance). 2.5.2.5 The string should not be a reserved word (for example, RFC2606). 2.5.3 Dispute resolution with respect to ICANN accepting a new string. ---------------------------------------------------------------------- 2.5.3.1 ICANN must establish a dispute resolution process, using independent arbitrators, where existing registry operators could challenge a decision made by ICANN regarding whether a new gTLD string is confusingly similar to an existing gTLD string. If a string application is successfully challenged as being confusingly similar, then no other operator may subsequently apply for it. 2.5.3.2 ICANN may establish a new dispute resolution process, using independent arbitrators, where existing trademark holders could challenge an ICANN decision regarding a string. This new dispute resolution process would be modeled on use existing Uniform Domain-Name Dispute Resolution Processes (UDRP). 2.6 An applicant for a new gTLD must use ICANN accredited registrars to provide registration services to Registered Name Holders (registrants). The registry shall not act as a registrar with respect to the TLD (consistent with the current registry-registrar structural separation requirements, for example, see clause 7.1 (b) and (c) of the .jobs registry agreement). An organization wishing to become a registrar for a new gTLD would need to become accredited using ICANN's existing accreditation process. 2.7 An applicant must demonstrate that they have the capability to operate a new gTLD that meets the minimum technical criteria to preserve the operational stability, reliability, security, and global interoperability of the Internet. 2.8 The applicant must provide a financial and business plan that provides an assurance that the applicant has the capability to meets its business ambitions. 3 Allocation Methods ======================== 3.1 To ensure an orderly introduction of new TLDs, the applications should be accessed in rounds to allow issues of contention between applicants for the same string to be resolved. First come first served (FCFS) is the preferred method of assessing applications within an initial round. Subsequently, processes may be developed that would enable an "apply as you go" system. 3.1.1 The start date for the round should be at least four months after the ICANN Board has issued the Request for Applications. ICANN must promote the opening time and details of the new round of applications to the broader worldwide Internet community. 3.1.2 Applications will be date stamped as they are received and will form a queue with the ability to work on multiple applications in parallel. 3.1.3 The closing date for the first round of new applications should be at least thirty days after the start date. 3.1.4 Applications for strings are not published until after the closing date. 3.2 The following process should be used to resolve contention between multiple applicants for the same new gTLD. 3.2.1 Ensure each application for the same gTLD (or a set of gTLDs that may be considered to be confusingly similar) is compliant with the selection criteria (with some flexibility to correct minor application form errors). 3.2.2 Establish a timeframe for a mediation process amongst the applicants to identify a solution amongst competing applications. A possible solution is for the applicants to choose different TLD strings to avoid the conflict, or for the applicants to combine their resources. 3.2.3 If there is no agreement between the applicants, ICANN will evaluate the additional criteria of the level of support of the community of potential registrants within that TLD to resolve contention. Both applicants would have a timeframe (e.g 90 days) to supply this additional material for evaluation. ICANN will determine what evidence is acceptable, and the evidence must be measurable and verifiable. An applicant that is not successful will need to wait until the next application round to submit a new application. 3.2.4 If ICANN staff are unable to distinguish between the level of support for each applicant for the gTLD, then the Board will make a choice based on the ICANN Mission and Core Values which include introducing and promoting competition in the registration of domain names where practicable and beneficial in the public interest; and supporting the functional, geographic and cultural diversity of the Internet. An applicant that is not successful will need to wait until the next application round to submit a new application. 3.3 An applicant who is granted a gTLD string has an obligation to begin using it within an appropriate time-frame. 4 Contractual Conditions ============================= 4.1 There should be a frame agreement to provide some level of consistency (for example, as for the registrars accreditation agreement) amongst gTLD agreements, with the ability for staff to have delegated authority to approve. Any material alterations to the frame agreement, will be subject to public comments before approval by the ICANN Board. 4.2 The contract should strike the right balance between ensuring certainty for market players and preserving flexibility of ICANN to accommodate the rapidly changing market, technological and policy conditions. 4.3 The initial term of the new gTLD agreement should be of commercially reasonable length (for example, default 10 years, although may be changed on a case-by-case basis). 4.4 There should be renewal expectancy. A contract would be renewed provided that the license holder is not in material breach of the contract, or has not been found in repeated non-performance of the contract, and provided the license holder agrees to the any new framework contract conditions that are reasonably acceptable. Any new framework contract would take into account the consensus policies in place at that time. 4.5 There should be a clear sanctions process outlined within the frame agreement to terminate a contract if the new gTLD operator has been found in repeated non-performance of the contract. 4.6 During the term of the agreement, the registry must comply with new or changed consensus policies to one or more of the following areas: - (1) issues for which uniform or coordinated resolution is reasonably necessary to facilitate interoperability, security and/or stability of the Internet or DNS; - (2) functional and performance specifications for the provision of Registry Services (as defined in Section 3.1(d)(iii) below); - (3) security and stability of the registry database for the TLD; - (4) registry policies reasonably necessary to implement Consensus Policies relating to registry operations or registrars; - or (5) resolution of disputes regarding the registration of domain names (as opposed to the use of such domain names). 4.7 Any deviation from consensus policies should be explicitly stated and justified in the agreement. 4.8 Where a registry provides IDNs, the contract should require that the registry adhere to IDN standards, and ICANN guidelines for IDNs. 4.9 Initially rely on the appropriate external competition/anti-trust Government authorities to ensure compliance with laws relating to market power or pricing power. This can be reviewed after an initial term. 4.10 ICANN should take a consistent approach with respect to registry fees - taking into account differences in regional, economic and business models 4.11 Use of Personal Data: limit it to the purpose for which it is collected, and the registry operator must define the extent to which it is made available to third parties.

1 0

Review and Recommendations for Internationalized Domain Names (IDNs)
by GNSO.SECRETARIAT＠GNSO.ICANN.ORG 11 Oct '06

11 Oct '06

[To: ga[at]gnso.icann.org; announce[at]gnso.icann.org] [To: liaison6c[at]gnso.icann.org; council[at]gnso.icann.org] Review and Recommendations for Internationalized Domain Names (IDNs) http://www.icann.org/announcements/announcement-11oct06.htm 11 October 2006 ICANN welcomes the recently announced Request for Comments (RFC4690) from the Internet Architecture Board (IAB). The document describes issues surrounding the continued development of IDNs. ICANN recommends all interested parties in the community to review the issues described and to participate in the development of solutions. You will find the relevant materials at: http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg02988.html and http://www.rfc-editor.org/rfc/rfc4690.txt -- Glen de Saint Géry GNSO Secretariat - ICANN gnso.secretariat[at]gnso.icann.org http://gnso.icann.org

1 0

RE: [council] Re: [gtld-council] Outcome of discussion on application fees in Amsterdam
by Gomes, Chuck 10 Oct '06

10 Oct '06

Thank you very much Mawaki for the detailed response to my questions. I personally believe that you make some extremely valid points that are consistent with the RyC positions communicated in our input to the process. Chuck Gomes VeriSign Information Services > -----Original Message----- > From: owner-council(a)gnso.icann.org > [mailto:owner-council@gnso.icann.org] On Behalf Of Mawaki Chango > Sent: Monday, October 09, 2006 8:29 PM > To: Gomes, Chuck; Council GNSO > Subject: RE: [council] Re: [gtld-council] Outcome of > discussion on application fees in Amsterdam > > Hi Chuck, > > my responses in line below. > > --- "Gomes, Chuck" <cgomes(a)verisign.com> wrote: > > > > > > > > --- Bruce Tonkin <Bruce.Tonkin(a)melbourneit.com.au> wrote: > > > > > > > > > 5. It should also be noted that the possible extra-costs that may > > > result from the differences in the applicants' working languages > > as > > > well as legal systems (as opposed to a specific dominant language > > and > > > legal system) should not be held against them, and be left to the > > > expense to the concerned communities. After all, the Internet is > > and > > > must remain a global facility both from the user and demand side > > and > > > from the operation and supply side. > > > > Gomes: Mawaki - What do you mean by "should not be held against > > them"? > > If you mean that the fact that extra costs to evaluate their > > application > > because of legal and/or language issues should not be used in any > > negative way to evaluate their application, I would agree with you. > > But > > if you mean that they should not have to bear the extra costs, > > I mean both, actually. I'm glad to see we are totally in agreement on > this first part. > > > > then that > > raises an additional question: who should bear the costs? The RyC > > has > > communicated that its members do no believe that any applicants > > should > > have to subsidize application costs for other applicants. Do you > > agree > > or disagree with this position of the RyC? If you agree, > > Yes, my turn to agree with you (and the RyC) here. > > > > then are you > > suggesting that ICANN should charge the extra costs to such > > applicants > > or that ICANN should find funds elwewhere in its budget to cover > > the > > extra costs? > > > > The latter, and let me clarify again. What I'm saying is the whole > ICANN as the Internet coordination and governance (or some say > regulatory) body could try to secure resources to make these > processes as even as possible to all potential players. Or to work > harder, and with good will, towards equal real chances (as much as > possible, I know it's never perfect) of market entry for those > potential players. It clearly has a benefit as well as a cost, either > symbolic, material or both, to be the authority that everybody in the > industry looks at and often relies on, at one level or the other. We, > as ICANN, need to accept to bear that cost toward the whole > community, and it may have different flavors depending on the > specificties of the various groups of participants, the regions, > their top issues and priorities, etc. in connection with ICANN > business. > > To exemplify, let me take the case of a developing Non-English > speaking country (and there are many, so I'm virtually talking of > regions size-wise). We need to realize that it already has a cost, > rather enorm, for them that this whole business is conducted in a > language that is not theirs. For many, this will result, among other > things, in 8, 10 or more years lagging behind and even locked out of > the business. Their poor institutional and economic development > doesn't help either, of course, and that's not ICANN's fault. But the > result is that it is again those who have less who still get less, > falling deeper behind, while paying the same market price as every > one if not more because of their poor organization (access, > international bandwidth and interconnections, etc.) > > So are we going to tell them, not only they have to pay the same fees > (in absolute value) that is required from their counterparts from > markets and economies much much more developed than theirs where the > relative value of those fees are unbearable, not only that, but also > they will need to hire lawyers with international competence to > translate the legal and contractual instruments as well as prepare > their application to ICANN in English before they have one slight > chance to compete? We in fact don't need to utter or write a word; by > just choosing not to address this issue, we may be meaning that in > the eyes of people who are concerned, and in the long run (meaning > right now, already) the result is the same. > > Thanks Chuck for asking, and thank you all for your attention; sorry > for the lengthy posting... it's been some time, eh? > > Mawaki > > > > >

1 0

Fwd: The Future of WHOIS Policy Panel Discussion
by Mawaki Chango 10 Oct '06

10 Oct '06

FYI, announcement below. --- Danny Younger <dannyyounger(a)YAHOO.COM> wrote: > Date: Mon, 9 Oct 2006 05:35:39 -0700 > From: Danny Younger <dannyyounger(a)YAHOO.COM> > Subject: The Future of WHOIS Policy Panel Discussion > > Please be advised that the New York Chapter of the > Internet Society is sponsoring a panel discussion on > "the Future of WHOIS Policy". > > 8 November, 2006 > 6-8PM > Jefferson Market Public Library > 425 Avenue of the Americas (Sixth Avenue), at Tenth St > New York City, NY USA > > Panelists: > > -- Jon Nevett, Chair of the ICANN Registrars > Constituency; VP Policy & Ethics, Network Solutions > -- Wendy Seltzer, North American representative, ICANN > At-Large Advisory Committee > -- Attorney Bruce A. McDonald, Schnader Harrison Segal > & Lewis LLP > -- Jordyn Buchanan, Chair ICANN WHOIS Task Force > -- Jeff Neuman, Senior Director, Law, Advanced > Services and Business Development, NeuStar Inc. > -- Rita Rodin, ICANN Board of Directors > -- FTC representative (to be announced) > > The event is free, open to the public and the site is > fully accessible. > > Event coordinator: > Danny Younger > dannyyounger(a)yahoo.com > VP ISOC-NY > http: isoc-ny.org > > Please feel free to forward this invitation. > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com >

1 0

RE: [council] Re: [gtld-council] Outcome of discussion on application fees in Amsterdam
by Gomes, Chuck 10 Oct '06

10 Oct '06

Mawaki, I will leave it to Bruce to respond as Chair of the committee, but I do have a few questions and comments that I have inserted below regarding your suggested addition to paragraph 5. Chuck Gomes VeriSign Information Services > -----Original Message----- > From: owner-council(a)gnso.icann.org > [mailto:owner-council@gnso.icann.org] On Behalf Of Mawaki Chango > Sent: Sunday, October 08, 2006 11:47 AM > To: Council GNSO > Subject: Fwd: [council] Re: [gtld-council] Outcome of > discussion on application fees in Amsterdam > > Dear Bruce, > > My apologies for not having been able to actively participate in real > time in the Council discussions lately, and also in advance, for the > fact that this situation might last for another couple of months. > > I am not quite clear right now with the gTLD committee process as to > when would be the appropriate time to discuss my earlier suggestions > below, from Amsterdam. I tried to listen to the MP3 recording of the > call on Oct 5, but couldn't finish listening the whole thing > carefully. On the other hand, I haven't seen any transcript of that > call so that I could search it. Anyway, from the few of the recording > that I listened, I realized that could have been the opportunity for > this discussion. > > Nevertheless, as I've understood that the PDP recommendations for new > gTLD are being prepared for public comments, I wish to call your > attention to the fact I would like my fellow councilors to consider > these suggestions for discussions. I can live with that if they are > rejected after consideration, depending on the arguments put forward, > but I will not be Ok that they are simply ignored or silenced, so to > speak. > > Thank you for your attention. > Sincerely, > > Mawaki > > ==== Below message forwarded, initially posted Aug 31, 2006 ==== > > [amsterdam, about 20 hrs later, out of wifi...] > > Dear colleagues, > > I'd like to suggest below two additions (paragraphs 5 [new] and 8) > to the outcome to this discussion. I was hoping we would have the > opportunity today to review also the outcome of this part of our > yesterday discussion, but apparently we won't. I'm however hoping > that I will get a response from the committee on this - whatever that > is. Thank you for your consideration. > > > Mawaki > > N.B. Some of the language is taken from .berlin public comment. > The recommendation is not that ICANN will necessarily need to > implement all the options put forward, but that ICANN takes heed of > the issue and consider the proposed options and, possibly, explore > some others it may think of. > > > --- Bruce Tonkin <Bruce.Tonkin(a)melbourneit.com.au> wrote: > > <snip> > > > > 1. Principle - that ICANN recovers its costs of evaluation from the > > application fees > > > > 2. That the fee will be set at the start of the process. > > > > 3. Some applications may cost different amounts to evaluate. > > Therefore > > there maybe different fees depending on the type of application. > > > > 4. It is possible that applicants could pay different amounts > > depending > > on what stage in the process the application reaches. > > 5. It should also be noted that the possible extra-costs that may > result from the differences in the applicants' working languages as > well as legal systems (as opposed to a specific dominant language and > legal system) should not be held against them, and be left to the > expense to the concerned communities. After all, the Internet is and > must remain a global facility both from the user and demand side and > from the operation and supply side. Gomes: Mawaki - What do you mean by "should not be held against them"? If you mean that the fact that extra costs to evaluate their application because of legal and/or language issues should not be used in any negative way to evaluate their application, I would agree with you. But if you mean that they should not have to bear the extra costs, then that raises an additional question: who should bear the costs? The RyC has communicated that its members do no believe that any applicants should have to subsidize application costs for other applicants. Do you agree or disagree with this position of the RyC? If you agree, then are you suggesting that ICANN should charge the extra costs to such applicants or that ICANN should find funds elwewhere in its budget to cover the extra costs? > > > > 6. ICANN should have a system of grants for applicants that would > > find > > cost recovery a barrier to entry. This grant would only allow the > > applicant to apply, without any presumption that the application > > would > > be successful. Grant applications would go through an evaluation > > process. > > > > 7. ICANN should evaluate options for funding the grants. > > 8. In addition to considering the grant options, other options for > ICANN to address the same concern may include, but not limited to: > > - Organizing periodic awareness and training workshops > for interested > stakeholders on the issues of gTLD operation, with the possible > cooperation of relevant global and regional entities or fora; > - reducing avoidable indirect costs incurred by the applicant > (including shorter and more predictable approval process with fixed > and reliable timelines, standardized contracts, public pre-evaluation > hearings of applications); > - providing assistance during, and reporting with > recommendations at > the end of, the pre-evaluation hearings. > > > > > > > > Regards, > > Bruce Tonkin > > > > > > >

2 1

ICANN : Contractual Compliance Update
by GNSO.SECRETARIAT＠GNSO.ICANN.ORG 09 Oct '06

09 Oct '06

[To: ga[at]gnso.icann.org; announce[at]gnso.icann.org] [To: liaison6c[at]gnso.icann.org; council[at]gnso.icann.org] Contractual Compliance Update http://www.icann.org/announcements/announcement-06oct06.htm 6 October 2006 ICANN's Compliance Program (http://icann.org/compliance) has been published to explain ICANN's approach to enforcement of compliance with its Registry Agreements and Registrar Accreditation Agreements ("the Agreements"). Registry Compliance Update: Public Whois Specification On June 30, 2006, ICANN completed its first gTLD Registry Compliance Audit. http://www.icann.org/compliance/reports/gTLD_Registry_Audit_oct06.htmlThis audit was based on requirements contained in the Public Whois Specifications in ICANN's gTLD Registry and Sponsorship Agreements. Each registry's audit was individually tailored based on specific requirements in the relevant agreement (e.g., "thick" versus "thin" registry models). Registrar Compliance Update: Registrar Accreditation Renewal Process ICANN's Compliance Department continues to monitor registrar compliance with the Registrar Accreditation Agreement (RAA) through the accreditation renewal process and through handling of complaints filed by internet users. See http://www.icann.org/compliance/reports/registrar_update_oct06.html. These audits were the first in a series of upcoming audits, published to ensure openness and transparency of ICANN's gTLD Registry and Accredited Registrar compliance programs. -- Glen de Saint Géry GNSO Secretariat - ICANN gnso.secretariat[at]gnso.icann.org http://gnso.icann.org

1 0

Fwd: [council] Re: [gtld-council] Outcome of discussion on application fees in Amsterdam
by Mawaki Chango 08 Oct '06

08 Oct '06

Dear Bruce, My apologies for not having been able to actively participate in real time in the Council discussions lately, and also in advance, for the fact that this situation might last for another couple of months. I am not quite clear right now with the gTLD committee process as to when would be the appropriate time to discuss my earlier suggestions below, from Amsterdam. I tried to listen to the MP3 recording of the call on Oct 5, but couldn't finish listening the whole thing carefully. On the other hand, I haven't seen any transcript of that call so that I could search it. Anyway, from the few of the recording that I listened, I realized that could have been the opportunity for this discussion. Nevertheless, as I've understood that the PDP recommendations for new gTLD are being prepared for public comments, I wish to call your attention to the fact I would like my fellow councilors to consider these suggestions for discussions. I can live with that if they are rejected after consideration, depending on the arguments put forward, but I will not be Ok that they are simply ignored or silenced, so to speak. Thank you for your attention. Sincerely, Mawaki ==== Below message forwarded, initially posted Aug 31, 2006 ==== [amsterdam, about 20 hrs later, out of wifi...] Dear colleagues, I'd like to suggest below two additions (paragraphs 5 [new] and 8) to the outcome to this discussion. I was hoping we would have the opportunity today to review also the outcome of this part of our yesterday discussion, but apparently we won't. I'm however hoping that I will get a response from the committee on this - whatever that is. Thank you for your consideration. Mawaki N.B. Some of the language is taken from .berlin public comment. The recommendation is not that ICANN will necessarily need to implement all the options put forward, but that ICANN takes heed of the issue and consider the proposed options and, possibly, explore some others it may think of. --- Bruce Tonkin <Bruce.Tonkin(a)melbourneit.com.au> wrote: <snip> > > 1. Principle - that ICANN recovers its costs of evaluation from the > application fees > > 2. That the fee will be set at the start of the process. > > 3. Some applications may cost different amounts to evaluate. > Therefore > there maybe different fees depending on the type of application. > > 4. It is possible that applicants could pay different amounts > depending > on what stage in the process the application reaches. 5. It should also be noted that the possible extra-costs that may result from the differences in the applicants' working languages as well as legal systems (as opposed to a specific dominant language and legal system) should not be held against them, and be left to the expense to the concerned communities. After all, the Internet is and must remain a global facility both from the user and demand side and from the operation and supply side. > > 6. ICANN should have a system of grants for applicants that would > find > cost recovery a barrier to entry. This grant would only allow the > applicant to apply, without any presumption that the application > would > be successful. Grant applications would go through an evaluation > process. > > 7. ICANN should evaluate options for funding the grants. 8. In addition to considering the grant options, other options for ICANN to address the same concern may include, but not limited to: - Organizing periodic awareness and training workshops for interested stakeholders on the issues of gTLD operation, with the possible cooperation of relevant global and regional entities or fora; - reducing avoidable indirect costs incurred by the applicant (including shorter and more predictable approval process with fixed and reliable timelines, standardized contracts, public pre-evaluation hearings of applications); - providing assistance during, and reporting with recommendations at the end of, the pre-evaluation hearings. > > > > Regards, > Bruce Tonkin >

1 0