<<<
Chronological Index
>>> <<<
Thread Index
>>>
Re: [soac-newgtldapsup-wg] GAC Communique on JAS
- To: Eric Brunner-Williams <ebw@xxxxxxxxxxxxxxxxxxxx>
- Subject: Re: [soac-newgtldapsup-wg] GAC Communique on JAS
- From: Elaine Pruis <elaine@xxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 15 Dec 2010 13:54:36 -0800
I think it makes more sense to consider what will probably be
(.HowOneIdentifiesOneself) rather than the obscure hypothetical.
When I speak of my Native heritage I say "my ancestors were
Chippewa." Not "my ancestors were of the Bad River Band of Lake
Superior Tribe of Chippewa Indians.
We have a lot of work to do and I'd rather not split hairs over issues
that have been "closed" by the Board.
Elaine
On Dec 15, 2010, at 12:00 PM, Eric Brunner-Williams wrote:
To follow up on the CATALAN vs CAT issue, some example communities:
Absentee Shawnee Tribe of Indians of Oklahoma
Agua Caliente Band of Cahuilla Indians
Bad River Band of Lake Superior Tribe of Chippewa Indians
Barona Group of Capitan Grande Band of Mission Indians
Bear River Band of Rohnerville Rancheria
Big Pine Band of Owens Valley Paiute Shoshone Indians
Cachil DeHe Band of Wintun Indians of the Colusa Indian Community
Central Council Tlingit & Haida Indian Tribes of Alaska
...
The registration rules the US established when it created the NSN.US
and more importantly, the -NSN.GOV namespaces, allow shorter forms
of the name, e.g., the Aroostook Band of Micmacs is allowed to use
micmac, with the -nsn.gov suffix.
Now obviously, no Tribal Government located in North America is
going to meet the Board's example, which we've adopted, that of
being an applicant from a least or lessor developed economy, but
point is that the policy of using names that are shorter than the
formal identifier of a community has been examined by the United
States and found to be workable.
Therefore there is an "errata fix" to recommend to DAGv5 which is
addressed in part by the comments of Amadeu (copied), Avri (wg
contributor) and others. One which would allow a Catalan application
to select "cat" rather than the longer "catalan" or the accented
catalán form. Of course, this ignores the possibly relevant fact
that "cat" is reserved in iso639 for Catalan, just as "nai" is for
"North American Indian".
Eric
On 12/15/10 2:02 PM, Richard Tindal wrote:
I was specifically asking if you think CAT would get 3 or 4 points
under the Registration Restriction component of scoring. My sense
is that CAT would
In terms of the 14 points, CAT possibly wouldn't get those 14
points if they applied under the new process for .CAT, but if they
applied for .CATALAN they would get 14 or more.
I think thats why the scoring is structured the way it is. If a
group representing the Catalan community applied for .CATALAN they
would beat all other possible applicants, but if that same group
applied for .CAT (a more generic term) they might not beat all
other applicants.
A problem you're noting is that if they apply for .CATALAN as
community they might be saddled with registration restriction
procedures that are too expensive for them to manage. Thats what
I'm trying to get a handle on. How costly are these procedures
currently, to say MUSEUM or CAT?
On Dec 15, 2010, at 1:16 PM, Eric Brunner-Williams wrote:
Hi Richard,
It is actually an open question if the .cat application would get
14/16 under the current guidelines.
You are correct that where the applicant thinks that their string
will not be in a contention set, and does not adopt a restrictive
registration policy, assuming their belief is correct and the
application is not eliminated through auction, it may not have
adopted binding restrictions on its registration policy.
However, if the applicant is willing to risk the application fee
with no benefit from the application being self-identified as
community-based, and with only future cost (in the form of
revenues not received due to a restrictive registration policy)
from identifying the application as community-based, a standard
application from the same applicant making the same cost-benefit
calculations is equally likely.
So the net is that we may see no needs-qualified community-based
applications, except those which have reduced viability due to the
adoption of restrictive registration policies contained in the
application, and difficult to modify subsequently.
Looking at the first of your three points, as Amadeu has pointed
out, the set of values present in scoring criterion 3 overlap,
with some degree of incoherence. This should be fixed before we
engage the 13 or 14 question. As to the second, the possibility of
two community based applicants and the consequences, which range
from none, if only one application meets the current criteria, to
blocking all, if two or more applications meets the current
criteria, is a hypothetical that should not have unintended
adverse consequences where only one application meets the current
criteria. A high score under a poorly designed scoring system
protects all communities by eliminating their applications, which
is not the usual form of protection sought. The same observation
applies to low scores and the vulnerability of community
applications. A multi-application hypothetical should not have
adverse consequences where there is only one application.
Eric
On 12/15/10 12:44 PM, Richard Tindal wrote:
Hi Eric
To clarify for all (and I know you're aware of this) getting a 14
point passing score only matters when there is another applicant for
the string. If there
is only one applicant then no scoring occurs (however as you note the
applicant is tied to their promised Registration Restrictions)
Most community strings will in my opinion, only have one application
therefore, the 14 points wont generally matter. (i understand there
are possible exceptions like .GAY)
I understand the point you're making that even if there is only one
application the Registration Restrictions commitments made by the
applicant can affect their success.
I think there are very strong reasons to keep community scoring high
(I've attached some below). It seems to me that managing Registration
Restictions could be done in a way that is not overly damaging to a
TLD. You're familiar with the .CAT methods. I think they would get 3
or 4 points for their Registration Restrictions if they were assessed
under the current rules. Could future Community operators not use
something like what CAT uses?
Thx
RT
--------------------------------
1.Lowering the Score Can Harm Registrants
An important component of the scoring method is “Criterion #3:
Registration Policies (0-4 points)”.Having defined a precise
community
the applicant must then show that through restrictive registration
policies only members of that community will be able to register
second level names.By definition then, a community TLD is not
available to everyone at the second level.You cannot have a
‘community’ that anyone can later join.If the scoring threshold is
lowered it will be easier for applicants to obtain community status
on
strings that should be available at the second level to a very wide
variety of registrants.A low score means that widely used terms could
be captured by communities of opportunity who will then be prohibited
from making second level names available to the general public.This
consequence of low community scoring is not in the public interest.
2.A High Score is the Best Way to Protect Real Communities.
Community scoring _only happens when there are two or more applicants
for the string_(i.e. if there is only one applicant for the string
there is no need for a community applicant to pass the 14 point
threshold).In a situation where there are two or more applicants
for a
community claimed string it is in the interest of that community to
have the scoring threshold at a high level.The higher the scoring
threshold the more likely the string will be awarded to the applicant
who most closely represents the community in question.If the scoring
threshold is low it will be easier for all applicants to achieve a
pass score, and this will negate the advantage of the applicant who
best represents the community.
3.A Low Score Will Allow Successful Objections to Legitimate
Communities
The standards for successful Objection to a community application are
based on the standards required to achieve the 14 point score.If the
scoring threshold is lowered it will be easier for groups, who may
not
be closely associated with the community, to successful object and
block the applicant.It is in the interest of real communities to have
a high score.
*__*
On Dec 15, 2010, at 12:11 PM, Eric Brunner-Williams wrote:
Colleagues,
Applications which are needs-qualified and "community-based" are,
due to the current string contention eligibility requirements,
either certain to fail if found to be in a contention set, if
meeting only 13 or fewer of the 16 evaluation points, and lacking
access to auction capital, or are certain to fail if meeting the
14/16 evaluation point goal due to highly restrictive registration
policies.
While the issue of community evaluation scoring and string
contention policy are outside the apparent remit of the JAS, if the
implementation in the current DAG is the final text, then we are
highly unlikely to be able to identify contention set surviving, or
economically viable community-based applicants, except where the
applicant identified the application as community-based, but made no
restriction intended to meet the 14 of 16 threshold.
I suggest that this is an issue we can usefully bring to the
attention of the Board, and others, as the elimination of
community-based applicants from the beneficiaries of the JAS effort
is unlikely to have been the Board's intended goal, nor that of the
GAC and others contributing to the issue of developing a
community-based application type which is not inherently non-viable.
Please see the comments submitted, particularly those of Amadeu,
Avri, and Elisa Cooper of Mark Monitor on the subject of scoring
community-based applications.
http://forum.icann.org/lists/5gtld-contention/msg00002.html (Amadeu)
http://forum.icann.org/lists/5gtld-contention/msg00001.html (Avri)
http://forum.icann.org/lists/5gtld-contention/msg00000.html (Elisa
Cooper of Mark Monitor)
Eric
Elaine Pruis
VP Client Services
elaine@xxxxxxxxxxxxxxxxxxxx
+1 509 899 3161
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|