ICANN/GNSO GNSO Email List Archives

[ga]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [ga] PLEASE COMMENT: Suggested ALAC response to sTLD RFP

  • To: Kristy McKee <k@xxxxxxxxxxxx>, Don Evans <DEvans@xxxxxxx>, "Nancy J. Victory" <nvictory@xxxxxxxxxxxx>, Kathy Smith <KSMITH@xxxxxxxxxxxx>, Robin Layton <RLayton@xxxxxxxxxxxx>
  • Subject: Re: [ga] PLEASE COMMENT: Suggested ALAC response to sTLD RFP
  • From: Jeff Williams <jwkckid1@xxxxxxxxxxxxx>
  • Date: Thu, 28 Aug 2003 19:18:57 -0700
  • Cc: Thomas Roessler <roessler@xxxxxxxxxxxxxxxxxx>, ga@xxxxxxxx, denise michel <denisemichel@xxxxxxxxxxxxx>
  • Organization: INEGroup Spokesman
  • References: <20030828142018.GL7314@voyager.does-not-exist.org> <5.2.1.1.2.20030828112450.02343300@pop.ies.net>
  • Sender: owner-ga@xxxxxxxxxxxxxx

Kristy and all former DNSO GA members,

  Good comment and/or question here Kristy.  Indeed Thomas,
pray tell?  As far as I can tell, I along with hundreds of thousands
of stakeholders/users are not even able to actively participate
openly still within the seemingly skewed ALAC structure, or
should I say de-structure...  ????

  So one at the very least has to wonder if such is by design and
therefore foolish, or if such is an accident that has yet to be
properly corrected?  It would be best if this was the latter
and not the former, IMHO....

Kristy McKee wrote:

> Additionally, Thomas,
>
> Please explain how you (ALAC) intend to incorporate people's comments into
> your position.
>
> Thanks,
>
> ~k
>
> At 09:15 AM 8/28/2003 -0700, Rick Wesson wrote:
>
> >Thomas,
> >
> >where is the charter for the ALAC? (see [1]) Why is the ALAC making
> >recomendations that are not within the scope of the group? It appears that
> >the ALAC is using its position as a "soap box" so its participiants can
> >speak on issues of personal concern.
> >
> >    a. The role of the At-Large Advisory Committee ("ALAC") shall be to
> >       consider and provide advice on the activities of ICANN, insofar as
> >       they relate to the interests of individual Internet users.
> >
> >PLEASE, go back and work on why ICANN has no membership, or ponder
> >the question of how the "At-Large" can participate insted of using your
> >"soap box" for personal comment.
> >
> >If you feel that I have incorrectly assessed your position you may
> >provide to this list, documentation of your outreach efforts and
> >methodology for determining the position that you conclude in your paper
> >below.
> >
> >If you have the voice of the people of the "at-large" prove it.
> >
> >
> >
> >-rick
> >
> >[1] http://www.icann.org/minutes/minutes-appa-31oct02.htm#XI-2.4
> >
> >On Thu, 28 Aug 2003, Thomas Roessler wrote:
> >
> > > The ALAC is soliciting comments on this until September 7.  Feel
> > > free to comment either to this list or to forum@xxxxxxxxxxxxxxx
> > >
> > > Regards,
> > > --
> > > Thomas Roessler                             <roessler@xxxxxxxxxxxxxxxxxx>
> > >
> > >
> > >
> > >
> > >
> > >
> > > ----- Forwarded message from Wendy Seltzer <wendy@xxxxxxxxxxx> -----
> > >
> > > From: Wendy Seltzer <wendy@xxxxxxxxxxx>
> > > To: Interim ALAC <alac@xxxxxxxxx>
> > > Date: Sun, 24 Aug 2003 10:35:02 -0700
> > > Subject: [alac] Suggested response to sTLD RFP
> > > X-Spam-Level:
> > >
> > > is attached (RTF) and below.  This is meant to reflect ALAC
> > > conversations and discussions on our conference calls and on-list.
> > > Thoughts?
> > >
> > > Thanks.
> > > --Wendy
> > >
> > >
> > > ALAC Responses to the Proposed sTLD RFP
> > > and Suggested Principles for New TLD Processes
> > >
> > > The At Large Advisory Committee welcomes the opportunity to provide
> > > comments on ICANN's proposed "Establishment of new sTLDs: Request for
> > > Proposals" ("sTLD RFP"
> > > <http://www.icann.org/tlds/new-stld-rfp/new-stld-rfp-24jun03.htm>).
> > >
> > > As we have previously indicated,
> > > <http://alac.icann.org/gtld/comments-06may03.htm>, ALAC supports an
> > > expansion of the gTLD namespace that allows both sponsored and
> > > unsponsored names.  We understand that the current proposed RFP
> > > limited to sponsored TLDs, is suggested as a continuation of the
> > > "Proof of Concept" testbed.  First, therefore, we offer suggestions
> > > for making this limited expansion more equitable.  We further urge
> > > ICANN to move quickly beyond "testing" to more open addition of a
> > > full range of new gTLDs in the near future, and offer some general
> > > principles to guide that expansion.
> > >
> > >
> > > Concerns regarding the sTLD RFP:
> > >
> > > The proposed sTLD RFP is not an equitable way to address even its
> > > limited goals.  It errs in unduly restricting the class of potential
> > > applicants and in imposing substantial fees for re-submission.
> > >
> > >
> > > Anyone Should Be Eligible to Apply for a New TLD in the Upcoming Round.
> > >
> > > The proposed sTLD RFP calls for "revised applications" only from
> > > unsuccessful applicants for sponsored TLDs from the Fall 2000 round.
> > > This limitation of the applicant pool is unfair -- both to those who
> > > might wish to submit new proposals and even to those who participated
> > > in the ICANN process in 2000 by submitting applications for
> > > unsponsored TLDs.  Moreover, limitation of the applicant pool to a
> > > narrow class of prior applicants is unrelated to any reasonable
> > > objective.
> > >
> > >
> > > Restricting eligible new TLD proposals to year 2000 applicants
> > > submitting proposals closely following their old applications
> > > mandates ignorance.  ICANN would be ignoring the economic development
> > > of the past three years, and would be forcing applicants to ignore
> > > the collective experience of the Internet community in the past three
> > > years, willfully blind to ignore today's market environment.  TLD
> > > proposals that may have looked promising during the dot-com boom may
> > > look uninteresting now; while new ideas for TLD proposals may have
> > > arisen since then.  ICANN's restrictive proposed RFP would deprive
> > > the community of the opportunity to hear new, innovative, and viable
> > > sTLD proposals suitable for the post-.com Internet.  It would be
> > > little surprise if this outdated "test" failed.
> > >
> > > Instead, several characteristics of the new TLD program in 2000 make
> > > it appropriate to expand current consideration beyond the
> > > applications (and a mere subset of those) for the "proof-of-concept"
> > > then:
> > >
> > > ? Although Fall 2000 new TLD applicants were asked to classify their
> > > proposals as "sponsored" or "unsponsored," and to submit additional
> > > materials if choosing "sponsored,"  the distinction did not carry
> > > nearly so much weight then as it is now being made to bear.
> > > Sponsorship was merely one of several characteristics among which
> > > applicants could choose.  Clearly applicants could not have known
> > > that they were foreclosing themselves from later consideration by
> > > choosing "unsponsored" in 2000.
> > >
> > > ? Nothing in the criteria announced in August 2000, prior to
> > > submission of applications, indicated that sponsored TLDs would be
> > > given any special priority, such that applicants would be encouraged
> > > to choose sponsored over unsponsored where either type of operation
> > > would fit their needs.  "The evaluation of delegation of
> > > policy-formulation functions for special-purpose TLDs to appropriate
> > > organizations" was only the seventh of nine criteria for evaluation.
> > > <http://www.icann.org/tlds/tld-criteria-15aug00.htm>
> > >
> > > ? Further, ICANN's evaluation of the 2000 new TLD proposals did not
> > > distinguish between sponsored and unsponsored as a major category in
> > > its report, instead looking at general/specific purpose,
> > > restricted/unrestricted use, and new services.  The report suggests
> > > that even after reviewing all applications submitted in 2000, the
> > > evaluators did not believe the distinction was significant.
> > > <http://www.icann.org/tlds/report/>
> > >
> > > ? Finally, nothing in the lead-up to the 2003 process has ever
> > > indicated that preference would be given to past applicants for
> > > sponsored TLDs.  This decision frustrates those who expected to be
> > > able to apply for future TLDs even if they had not previously applied
> > > or planned to change the nature of a previous application based on
> > > interim experience.
> > >
> > > ? A likely effect of limiting the pool of possible applicants in the
> > > proposed RFP would be to create a secondary market for failed sTLD
> > > applications, without improving the quality of those in this round.
> > >
> > > ICANN is presumably continuing the "proof-of-concept" because it
> > > believes it is learning something from the testbed process, yet
> > > limiting applications to a narrow selection of those unsuccessful
> > > three years ago deprives the Internet community of a meaningful
> > > chance to use the experience of those years.   Moreover, at the slow
> > > pace of ICANN's new TLD roll-out, missing the opportunity to apply in
> > > the continuing "proof-of-concept" phase imposes a significant
> > > hardship on would-be sponsors.  If ICANN is committed to making the
> > > testbed a representative evaluation of new TLD policies, it must open
> > > the application process to all who fit its substantive criteria.
> > >
> > > High Application Fees Discourage Non-Profit and Less-Established
> > Applicants.
> > >
> > > The proposed sTLD RFP would require applicants to pay $25,000 along
> > > with their revised applications, on top of the $50,000 they paid for
> > > consideration in the first round.  While we understand that it may be
> > > costly to review application proposals, a lower fee would suffice to
> > > discourage frivolous applications, while the high one also deters
> > > bottom-up and low-cost organization of legitimate non-commercial
> > > proposals.
> > >
> > > In the current plan, accepting only revisions to existing
> > > applications, the high fee seems particularly disproportionate to the
> > > likely additional review needed.  Yet even if ICANN opens up the
> > > process to all applicants, as we recommend, it should ask only fees
> > > sufficient to compensate for evaluation of the proposal, an easier
> > > task if the application conditions themselves are minimal.  ICANN can
> > > streamline and reduce the cost of its approval process by approving
> > > applications conditionally, provided they continue to meet
> > > implementation benchmarks (e.g., you must go live by one year from
> > > now, and before going live you need to show us an escrow contract, a
> > > technical architecture plan, etc.) as their operators move forward.
> > > Incidentally, a conditional approval reduces the front-loading of
> > > costs for the applicant as well, enabling smaller businesses to
> > > participate more easily.
> > >
> > > We reiterate our recommendation to ask lower fees from non-profits,
> > > and to consider taking a portion of the fee only from the winning
> > > applicant, rather than making all applicants subsidize the later
> > > negotiation and implementation costs of the eventual winner.
> > >
> > > Moving Forward:
> > >
> > > It is time for ICANN to regularize the process of examination and
> > > approval of new TLD proposals.  Testbeds are fine, but after 5 years
> > > of operation, ICANN needs to move beyond evaluations to permit those
> > > proposing new TLDs to put their plans into effect.
> > > Approving a few new sponsored TLDs chosen from a list of applicants
> > > that was narrowed arbitrarily cannot replace the creation of a quick,
> > > effective and uncontroversial process for the creation of any kind
> > > and number of new TLDs.  ICANN must focus and act swiftly with
> > > respect to this issue, which can be called the holy grail of ICANN's
> > > mission.
> > >
> > > Further, ICANN must make more meaningful evaluations when it does
> > > conduct reviews.  In presentations heard at the Rio di Janiero
> > > meeting, ICANN Paper
> > > <http://www.icann.org/riodejaneiro/stld-rfp-topic.htm>, and Report on
> > > Compliance by Sponsored gTLDs with the Registration Requirements of
> > > Their Charters
> > >
> > <http://www.icann.org/committees/ntepptf/stld-compliance-report-25feb03.htm>,
> > > on existing sponsored TLDs, both err in focusing primarily on
> > > exclusion: Do the sponsored gTLDs represent a limited community and
> > > adhere to their charters by permitting registrants only from within
> > > that community? The question more important to the public's
> > > communicative goals, however, is the flip side: Are there people or
> > > organizations who are left without logical places to register domain
> > > names, or who are denied registration in a sponsored TLD whose
> > > charter they fit? That is, are communities of prospective registrants
> > > most effectively served by a single TLD, operated by a sponsor that
> > > purports to represent them, or by multiple commercial players that
> > > perceive them as a market for registrations in a number of competing
> > > top level domains?
> > >
> > > It is easy to make the error rate arbitrarily low by asking questions
> > > that examine only one kind of error -- gTLDs could block all
> > > cybersquatters simply by refusing any registrations, but that would
> > > hardly serve the point of adding new gTLDs.
> > >
> > > Suggested Principles for Addition of New TLDs:
> > >
> > > ? Competition. Prospective registrants of a domain name in a gTLD
> > > should have a choice -- between competing TLD strings, between
> > > competing policies, between competing business models.  ICANN should
> > > foster, not impede competition among different registries that access
> > > identical or overlapping market segments. Mutual substitutability of
> > > different gTLDs fosters competition.
> > >
> > > ? Fairness and objectivity. The processes used by ICANN in allocating
> > > new gTLDs to registries must be well-documented at the outset, fair,
> > > and predictable.  Criteria must be applied in an objective and
> > > non-arbitrary fashion, and without undue influence from policy-making
> > > bodies or advocacy groups on any side of the issues.
> > >
> > > ? Market operation. An open, competitive market, not a beauty
> > > contest, should determine what names get into the root.  The only
> > > standard applied to new Top Level Domains should be a simple no-harm
> > > evaluation which avoids confusingly similar TLD strings, according to
> > > some well-defined standard such as that of  consumer confusion in
> > > trademark law.
> > >
> > > ? Rapid resolution of conflicts among applicants. When multiple
> > > parties propose the same domain string, ICANN needs a mechanical way
> > > of resolving conflicts.
> > >
> > > ? Technical evaluation / accreditation. ICANN's past practice of
> > > substantive and technical evaluation is both costly and inefficient.
> > > Even after passing these a priori evaluations, the .pro TLD has yet
> > > to become operational.  ICANN should consider paring this requirement
> > > down to a minimum "competence," perhaps leaving open the possibility
> > > of terminating gTLD contracts with registries that failed to achieve
> > > minimum performance standards within a reasonable time.
> > >
> > > ? Business continuity.  Once a contract is approved, ICANN should ask
> > > for data escrow and/or business continuity insurance to reduce the
> > > risk of registry failure, but should not try to guarantee that a
> > > registry or TLD string will live forever.  Customers can include risk
> > > evaluation in their choice of TLDs to use; ICANN need not make this a
> > > criterion of approving an application.
> > >
> > > ? Geographical and linguistic diversity:  As an international
> > > organization, ICANN should ultimately work to allow applications in
> > > major non-English languages, and should encourage a wider
> > > geographical distribution of TLD registries."
> > >
> > >
> > >
> > > --
> > > --
> > > Wendy Seltzer -- wendy@xxxxxxxxxxx || wendy@xxxxxxx
> > > Staff Attorney, Electronic Frontier Foundation
> > > Fellow, Berkman Center for Internet & Society at Harvard Law School
> > > http://cyber.law.harvard.edu/seltzer.html
> > >
> > >
> > >
> > > ----- End forwarded message -----
> > >

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 131k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard
===============================================================
CEO/DIR. Internet Network Eng. SR. Eng. Network data security
Information Network Eng. Group. INEG. INC.
E-Mail jwkckid1@xxxxxxxxxxxxx
Contact Number: 214-244-4827 or 214-244-3801





<<< Chronological Index >>>    <<< Thread Index >>>