Re: [ga] PLEASE COMMENT: Suggested ALAC response to sTLD RFP
This whole concept is violently wrong.
ALAC is a closed group yet it's initials stand for at-large.
It is like calling a pig a dog and so it becomes one.
This is just plain stupid.
Eric
> 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