<<<
Chronological Index
>>> <<<
Thread Index
>>>
Re: [registrars] Fw: [nc-org] Revised draft - reflecting teleconference
it would appear that we are talking all the way from board member thru
operational senior mgt. here (which is why i am so concerned)
i have no problems with a policy council or committee but when we get down
to operational level mgt it gets very disconcerting !!
ken stubbs
----- Original Message -----
From: "Ross Wm. Rader" <ross@tucows.com>
To: "Ken Stubbs" <kstubbs@digitel.net>
Sent: Friday, January 04, 2002 4:25 PM
Subject: Re: [registrars] Fw: [nc-org] Revised draft - reflecting
teleconference
> Thanks for the note - what about the registry management election
> requirements? It strikes me that this isn't such a terrible thing a la
> Auda/CIRA, but could be disastrous if moved any further down the chain
(ie -
> into the technical management area....) Just thinking out loud here of
> course...
>
> -rwr
>
> ----- Original Message -----
> From: "Ken Stubbs" <kstubbs@digitel.net>
> To: "Ross Wm. Rader" <ross@tucows.com>
> Sent: Friday, January 04, 2002 4:13 PM
> Subject: Re: [registrars] Fw: [nc-org] Revised draft - reflecting
> teleconference
>
>
> > the original wording which was as follows:
> >
> > "Applicants should meet the current performance specifications from the
> > Verisign .org agreement. The new .org registry should either use the
> > existing .org registry/registrar protocol (RRP), or be compliant with
the
> > EPP protocol of the IETF "provreg" working group."
> >
> > it was changed in the last draft for reasons unknown to me. i have
> requested
> > a clarification as to why this was changed and will request that this be
> > changed back. (we have had some requests from other registrars that RRP
be
> > allowed in the proposed specs as well.)
> >
> > ken stubbs
> >
> > ----- Original Message -----
> > From: "Ross Wm. Rader" <ross@tucows.com>
> > To: "Ken Stubbs" <kstubbs@digitel.net>
> > Sent: Friday, January 04, 2002 3:52 PM
> > Subject: Re: [registrars] Fw: [nc-org] Revised draft - reflecting
> > teleconference
> >
> >
> > > Ken -
> > >
> > > It wasn't clear whether the proposal was indicating the the management
> > body
> > > should be elected by members a la CIRA/auda or the registry operator
and
> > > management body a la Nominet. Can you clarify?
> > >
> > > Also below, we should, if its not too late, try and push for an
explicit
> > > statement indicating that EPP is preferred...
> > >
> > > "Protocols used by the new registry should minimize transitional
> expenses
> > > for registrars."
> > >
> > > Should ideally be reworded to state
> > >
> > > "The new registry must use EPP as defined by the IETF in order to
> minimize
> > > transitional expenses for registrars."
> > >
> > > -rwr
> > >
> > > ----- Original Message -----
> > > From: "Ken Stubbs" <kstubbs@digitel.net>
> > > To: <Registrars@dnso.org>
> > > Sent: Friday, January 04, 2002 2:17 PM
> > > Subject: [registrars] Fw: [nc-org] Revised draft - reflecting
> > teleconference
> > >
> > >
> > > > Fellow registrars...
> > > >
> > > > here is the latest draft of the "dot org" task force.
> > > >
> > > > I have expressed serious concerns about the concept (outlined in
> section
> > > 1c)
> > > > of registrants electing officers of the registry management company.
> > > >
> > > > To me, registrants "electing" registry senior operating management
> makes
> > > > little sense..
> > > >
> > > > This policy could easily dissuade the overwhelming majority of
> > > > "qualified", experienced entities from submitting proposals (if
they
> > knew
> > > > that once they were successful their senior management could then be
> > > > arbitrarily replace by a vote of the registrants.)
> > > >
> > > > Discussions with other registrars indicate that they are deeply
> > concerned
> > > > that whatever entity assumes responsibility for future management of
> the
> > > > registry be professionally managed by people with extensive
experience
> > and
> > > > knowledge of the industry.... not just people who may be popular
with
> > > > registrants.
> > > >
> > > > Registry mgt. is a business and needs a continuity of Experienced ,
> > > > knowledgable management along with an assured consistency of
> application
> > > of
> > > > policies. This could not necessarily be assured if the managers were
> > > > selected by "popular vote" of the registrants.
> > > >
> > > > registrars need to have confidence that the entity they are doing
> > business
> > > > with has this top quality professional management with an in-depth
> > > > knowledge of this business.
> > > >
> > > > I look forward to your comments on the draft below and would like to
> > thank
> > > > Bruce Tonkin, Elana Broitman, Scott Hemphill, & Brian Evans for
their
> > > > previous contributions and comments .
> > > >
> > > > best wishes
> > > >
> > > > ken stubbs
> > > >
> > > >
> > > >
> > > >
> > > > ----- Original Message -----
> > > > From: "Milton Mueller" <Mueller@syr.edu>
> > > > To: <nc-org@dnso.org>
> > > > Sent: Thursday, January 03, 2002 5:48 PM
> > > > Subject: [nc-org] Revised draft - reflecting teleconference
> > > >
> > > >
> > > > >
> > > > > NAMES COUNCIL .ORG DIVESTITURE TASK FORCE
> > > > > v 5.2 (January 4, 2002)
> > > > >
> > > > > The .org registry should be operated for the benefit of the
> worldwide
> > > > community of organizations, groups, and individuals engaged in
> > > noncommercial
> > > > communication via the Internet. Responsibility for .org
administration
> > > > should be delegated to a non-profit organization that has widespread
> > > support
> > > > from and acts on behalf of that community.
> > > > >
> > > > > The notions of sponsorship and restriction, as applied elsewhere
in
> > the
> > > > gTLD process, do not provide an adequate framework for the .org
> > > divestiture.
> > > > Some clear statement of administrative and marketing practices will
be
> > > > necessary but this must not result in an exclusive boundary being
set
> > > around
> > > > the community of eligible registrants. The manner in which the
> normative
> > > > guidelines are labeled is not a primary consideration, but the
> framework
> > > > should include all the points below.
> > > > >
> > > > > 1. Characteristics of the Organization
> > > > >
> > > > > 1a. The initial delegation of the .org TLD should be to a
non-profit
> > > > organization that is controlled by noncommercial .org registrants.
We
> > > > recognize that noncommercial registrants do not have uniform views
> about
> > > > policy and management, and that no single organization can fully
> > encompass
> > > > the diversity of global civil society. Nevertheless, applicant
> > > organizations
> > > > should be able to demonstrate support and participation from a
> > significant
> > > > number of international noncommercial .org registrants. The
> > organization's
> > > > policies and practices should strive to be responsive to and
> supportive
> > of
> > > > the noncommercial Internet user community, and reflect as much of
its
> > > > diversity as possible.
> > > > >
> > > > > 1b. Applicants for operation of the .org registry should be
> recognized
> > > > non-profit entities (understood to include corporations,
associations,
> > > > partnerships or cooperatives as those terms are defined in the legal
> > > > jurisdiction in which the organization is established).
Subcontracting
> > of
> > > > operational functions to for-profit providers is permitted.
> > > > >
> > > > > 1c. Applicants should propose governance structures for the .org
TLD
> > > that
> > > > provide all .org registrants with the opportunity to directly
> > participate
> > > in
> > > > the selection of officers and/or policy-making council members. The
> > bylaws
> > > > should provide explicitly for an open, transparent and participatory
> > > process
> > > > by which .org operating policies are initiated, reviewed and revised
> in
> > a
> > > > manner which reflects the interests of .org domain name holders and
is
> > > > consistent with the terms of its registry agreement with ICANN.
> > > > >
> > > > > 1d. In order to permit the largest number of qualified non-profit
> > > > organizations to compete for award of the .org TLD contract, the
Board
> > > > should require no more than the equivalent of USD$200,000 in
> > demonstrated
> > > > financial resources from applicants.
> > > > >
> > > > > 2. Policy Guidelines for Applicants
> > > > >
> > > > > 2a. Definition of the .org community
> > > > > Each applicant organization should include in its application a
> > > definition
> > > > of the relevant community for which names in the .org TLD are
> intended,
> > > > detailing the types of registrants who constitute the target market
> for
> > > > .org, and proposing marketing and branding practices oriented toward
> > that
> > > > community.
> > > > >
> > > > > The definition of the relevant community should be much broader
than
> > > > simply formal non-profit organizations. It must also include
> individuals
> > > and
> > > > groups seeking an outlet for noncommercial expression and
information
> > > > exchange, unincorporated cultural, educational and political
> > > organizations,
> > > > and business partnerships with non-profits and community groups for
> > social
> > > > initiatives.
> > > > >
> > > > > 2b. No eligibility requirements
> > > > > Dot org will continue to be operated without eligibility
> requirements.
> > > > With a definition of the served community and appropriate marketing
> > > > practices in place, the organization and the registrars should rely
> > > entirely
> > > > on end-user choice to determine who registers in .org.
> > > > >
> > > > > Specifically, applicants:
> > > > > * Must not propose to evict existing registrants who do not
conform
> to
> > > its
> > > > target community. Current registrants must not have their
> registrations
> > > > cancelled nor should they be denied the opportunity to renew their
> names
> > > or
> > > > transfer them to others.
> > > > >
> > > > > * Must not attempt to impose any new prior restrictions on people
or
> > > > organizations attempting to register names, or propose any new
dispute
> > > > initiation procedures that could result in the cancellation of
domain
> > > > delegations. The UDRP would apply as per section 5 below, however.
> > > > >
> > > > > 2c. Surplus funds
> > > > > Applicants should specify how they plan to disburse any surplus
> funds.
> > > Use
> > > > of surplus funds for purposes not directly related to dot org
registry
> > > > operation is permitted, provided that the registry operation itself
is
> > > > adequately sustained and that the additional purposes bear some
> > > relationship
> > > > to Internet use, administration and policy. For example, applicants
> are
> > > > encouraged to propose methods of supporting and assisting
> non-commercial
> > > > participants in the ICANN process. Uses intended only to subsidize
> other
> > > > activities of the organization or its subsidiaries, activities that
> are
> > > not
> > > > subject to oversight and management by the .org governance
> arrangements,
> > > > should not be considered.
> > > > >
> > > > > 2d. Registrars
> > > > > All ICANN-accredited registrars should be eligible to register
names
> > in
> > > > .org. However, applicants are encouraged to propose methods of
> managing
> > > the
> > > > relationship between the registry and registrars that encourage
> > > > differentiation of the domain.
> > > > >
> > > > > 2e. Definition of marketing practices
> > > > > Differentiation of the domain is a key policy objective in the
> > > transition,
> > > > and new marketing practices are the primary tool for achieving that
> > > > objective. Applicants should propose specific marketing policies and
> > > > practices designed to differentiate the domain, promote and attract
> > > > registrations from the defined community, and minimize defensive and
> > > > duplicative registrations.
> > > > >
> > > > > 3. The Verisign endowment
> > > > >
> > > > > Applicants should meet all requirements needed to qualify for the
$5
> > > > million endowment from Verisign. Applications should describe how
they
> > > > propose to utilize the endowment and the timing of its use.
> > > > >
> > > > > 4. The Registry Operator
> > > > >
> > > > > Any entity chosen by the TLD delegee to operate the .org registry
> must
> > > > function efficiently and reliably and show its commitment to a high
> > > quality
> > > > of service for all .org users worldwide, including a commitment to
> > making
> > > > registration, assistance and other services available in different
> time
> > > > zones and different languages. The price of registration proposed by
> the
> > > new
> > > > entity should be as low as feasible consistent with the maintenance
of
> > > good
> > > > quality service. Protocols used by the new registry should minimize
> > > > transitional expenses for registrars.
> > > > >
> > > > > 5. ICANN Policies
> > > > >
> > > > > The .org administration must adhere to policies defined through
> ICANN
> > > > processes, such as policies regarding registrar accreditation,
shared
> > > > registry access, the uniform dispute resolution policy, and access
to
> > > > registration contact data via WHOIS.
> > > > >
> > > > > 6. Follow up
> > > > >
> > > > > ICANN should invite applications from qualifying non-profit
> > > organizations
> > > > to assume responsibility for operation of the .org registry with a
> > > deadline
> > > > no later than 30 June 2002, so that an evaluation, selection and
> > agreement
> > > > process may be completed well in advance of the 31 December
expiration
> > of
> > > > the current agreement with Verisign.
> > > > >
> > > > > ICANN will provide an opportunity for the Names Council to review
> the
> > > > request for proposals (RFP) prepared by the ICANN staff prior to its
> > > public
> > > > dissemination, and will adjust the RFP as needed in consultation
with
> > the
> > > > Task Force to ensure compliance with the policy. Application fees
> should
> > > be
> > > > as low as possible consistent with the objective of discouraging
> > frivolous
> > > > applications.
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|