[NA-Discuss] Inclusion of Individual Internet Users within the City-TLD Multistakeholder Governance Environment
toml at communisphere.com
Sun May 8 04:04:33 UTC 2016
Fellow NARALO Members,
ICANN granted the city of New York the right to issue domain names using
the .nyc TLD in January 2014. As of May 1, 2016, 76,682 names had been
issued to individuals and organizations.
Connecting.nyc Inc. is an At-Large Structure associated with the ICANN
and an active participant in its multistakeholder governance process.
With our focus on the development of the .nyc TLD as a public interest
resource, I recently reviewed the .nyc Registry Agreement page on
<https://www.icann.org/resources/agreement/nyc-2014-01-23-en>, and noted
that four changes to the original agreement had been recorded there.
Three were under the heading "Authorization(s) for Release of Reserved
Names," as follows:
All Digit/Digit, Letter/Digit, and Digit/Letter Two-Character ASCII
Labels at the Second Level (01 December 2014)
Letter/Letter Two-Character ASCII Labels (26 May 2015)
Letter/Letter Two-Character ASCII Labels (14 March 2016)
The fourth was listed under "Amendment No.1 (31 March 2016)":
This PDF amendment deals with the addition of 14 new data fields to
the Registration Data Directory.
The existence of these changes came as a complete surprise to me. As
Chair of Connecting.nyc Inc., a NYS nonprofit created in 2007 to engage
and educate New Yorkers about the use of the .nyc TLD, and as an active
participant in ICANN's governance processes through our association as
an At-Large Structure, I had presumed we would have been consulted about
changes to the registry agreement.
My desire for inclusion of individual Internet users in consultations
about future registry changes provides the basis for this message.
Note: An earlier email on this general subject led some to think I was
challenging the 4 registry changes as being out of compliance with
approved ICANN procedures. This is not the case. And based on my perusal
of precedent references kindly provided by a fellow ALSer (see them
below), I’d say that ICANN and the city followed the “letter of the
However, I do question the efficacy of a process that allows changes to
a registry agreement without taking full advantage of the existing
machinery of governance, i.e., the multistakeholder model and the extant
At-Large Structures (ISOC-NY is also a NYC based ALS). With the Internet
community having settled on a multistakeholder governance model, one
would imagine that our ALS would be involved in changing the basic
agreement that guides the operation of the .nyc TLD.
But perhaps we were excluded from the review process for good reason,
for example, that the city’s governance structure more effectively
represents the needs of the various stakeholders than the Internet’s
multistakeholder model. After all, New York City does have a democratic
governance system, and a general election was held in November 2013.
Perhaps it's thought the people thereby approved or acquiesced to the
registry agreement, and thus, in the eyes of ICANN, a city-based ALS
should not have a formal role. If this is the situation, I would
appreciate someone pointing me to the relevant guidelines. For indeed...
At this point, the city is acting as if there is no role for its
residents in a traditional multistakeholder model. While there was a 20
month period during which the city acknowledged the role of the
residents and users through a .NYC Community Advisory Board (May 2013 -
December 2014), the city unilaterally decided that entity should cease
to exist on January 1, 2015. And to my dismay, it followed this decision
by eliminating all reference to the .NYC Community Advisory Board’s very
existence from the city’s website.
NOTE: To my knowledge city government has not been provided with any
requirement or guideline about the operation of an inclusive,
multistakeholder governance process for the .nyc TLD. So I’m not
faulting the city administration for the current state of affairs. To do
so would be to assume greater awareness and concomitant responsibility
about this new resource than is seemingly warranted.
What’s to be done?
This email seeks the assistance or NARALO in learning if Connecting.nyc
Inc. should be provided with an opportunity to consult and consent to
future registry agreement changes. We see precedent for this with the
The .us TLD is currently governed with the assistance of a .usTLD
The council has a charter
a membership (which is appointed by the contractor!), and operational
parameters (see usTLD Administrative Component graphic below).
If it is the consensus that we are inappropriately outside the extant
"consultation loop" I suggest that NARALO initiate a review to determine
if the current process should be changed to more closely align with the
tenets of the multistakeholder governance system that underpins the
operation of ICANN and the Internet.
Basis for ICANN approval of 4 .nyc TLD registry agreement changes
The release of 2-character names at the second level has been the
subject of extensive public consultation. The ALAC did comment on
these and explicitly said we did not see any problems with that.
This was a result of discussion and consultation within-At-Large.
The call for comments on our first such statement can be seen at
The net result was that we supported the release of such names. Note
that the approval to release such names does not compel a registry
to release them, it only allows them to make such a decision.
You can see the history of our full process on this by going to
https://atlarge.icann.org/policy-summaryand doing a search on
statement titles including the words TWO CHARACTER DOMAIN.
The contract amendment to include additional RDDS fields was made at
the explicit request of the registry to allow .nyc to satisfy the
nexus requirements of the registry (that is, to allow verification
that the registrant does have a connection with New York City
(http://www.ownit.nyc/policies/nyc_nexus_policy.php). The request by
the registry can be viewed at
Such Registry Service Evaluation Process (RSEP) requests can be
The overall process followed in RSEP can be seen at
process requires a formal public comment only if there is the
possibility (based on a "quick look" review) of a security or
stability issue (which it did not in this case).
The RSEP is the result of one of the early GNSO Consensus Policy
Development Processes -
That process was of course subject to public comments and the
resultant policy was widely supported.
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 100414 bytes
Desc: not available
More information about the NA-Discuss