<html>
<body>
Tom, you have also addressed this as a question to the candidates for the
NARALO ALAC Member selection and in that capacity I will be glad to
address this issue at the meeting tomorrow. However, since you have sent
this to the entire NARALO list, the answer has far more to it than can be
addressed on our candidate teleconference, and many of the recipients
will not likely be at that meeting, I thought it appropriate to reply
here as well.<br><br>
In the name of transparency I will note that you had already addressed a
similar question to the NARALO ALAC Members about two weeks ago, and I
did address what I understood to be the issues at that time. I see that
you copied the majority of my reply to you below under the title
"Basis for ICANN approval of 4 .nyc TLD registry agreement
changes". This was presented as my personal understanding and not
necessarily the "basis" for the changes. And for the record, I
am proudly an Unaffiliated Member of NARALO and not a fellow ALSer.
;-)<br><br>
On to substance.<br><br>
.nyc is Generic Top Level Domain granted under the 2010 round of New
gTLDs. It is under the sole control of the applicant and now registry
operator, The City of New York through its Department of Information
Technology & Telecommunications. It is of course subject to all of
the ICANN policy associated with gTLDs.<br><br>
When I say "sole control", that is of course subject to the
terms of its contract and and other
organization'
s restrictions. Many city TLDs chose to also be "community"
TLDs (examples are .berlin, .madrid, .paris and .osaka), and in that
case, they would also be responsible to the community that supported the
application, and that responsibility might include some of the user
connections that you desire, But even in those cases, it would depend on
the specifics of the contracts and relationships. Regardless of the
details, the Registry Agreement is a legal contract between ICANN and the
Registry Operator, and its amendment is governed by a host of ICANN
policies.<br><br>
At-Large through the ALAC, and with the RALOs and ALSes has a significant
ability to influence many issues. That was not always the case, and we
certainly do not implicitly overrule others in the multistakeholder
community, but we are heard. That being said, one of the prime purposes
of ICANN is to establish policy in the gTLD arena. And we do. But of
course, once that policy is established, we have to follow it.<br><br>
To look at one of the perhaps less onerous examples you gave, the
contract amendment to add several new data fields to the Registration
Data Directory (formerly WHOIS). These fields allow the registry to
request that all registrants provide information indicating that they are
indeed eligible to have a .nyc domain name. Despite the seeming
simplicity of the change, how a registry is granted the right to do this
is through making a request to establish a new Registry Service (Registry
Services is a specifically defined term). The Registry Services
Evaluation Policy (RSEP) governs such changes. The RSEP is one of the
earlier Consensus Policies establish within ICANN through MS Model
deliberations. RSEP evaluates the change for potential security,
stability or competition issues. If it has any of these a consultative
process is started which ultimately might result in a the ALAC submitted
a comment on the proposed registry service (we have done this a number of
times). If it has no security, stability or competition issues, then the
request is approved, and in this case, required a contract amendment
(since the RDS fields are explicitly listed in the Registry
Agreement.<br><br>
Now, on to your question, can At-Large change this process to allow for
more and explicit consultation. Yes, we can. (Whether we want to or not
is a different question - with the New gTLDs, there were about 90 such
requests in 2015.) We can cause the policy to be reviewed and potentially
changed. I can speak with some authority on the process because I have
initiated it twice, and in both cases, the end result was a new gTLD
policy that, in my mind and those of many others, significantly improved
the gTLD namespace. If you think that this issue is one worthy of the
effort it will take to effect the change you want, I encourage you to
learn more about the process. I will say (and I have the scars to prove
it), you will need to convince a lot of other people that there is a
problem and that it is worth addressing.<br><br>
The other amendments are related to 2-character 2nd-level names. As I
have mentioned in my earlier reply, this subject has been the topic of a
number of formal Public Comments and the ALAC did contribute. I do not
recall how much ALS input there was into these processes, but there was
surely the opportunity for input at many level. <br><br>
You ask whether your ALS, which clearly has a great interest in the .nyc
TLD, should be consulted before the .nyc agreement is modified. I see no
way that we can make a specific link between your ALS and the TLD unless
the registry chooses to do so. The more general question is whether the
wider community should be notified of potential contractual amendments
and have an opportunity to comment. That is certainly an issue that could
be raised, as with changing RSEP, we would need to make a strong case
that there is a problem and that is is worth of community time to
address. <br><br>
<br>
Regarding the use .us as a model. .us is a ccTLD which operates under a
completely different set of rules and constraints. At some level
(certainly for a redelegation or transfer of a ccTLD to a new operator),
there must be some demonstration that the interested parties within the
country/territory support the registry operator and their policies. Of
course, the form this takes, and the actual level of real support, varies
greatly from country to country.<br><br>
.us was historically operated by Verisign and was redelegated to NeuStar
in 2001
(<a href="https://www.icann.org/news/announcement-2001-11-19-en" eudora="autourl">
https://www.icann.org/news/announcement-2001-11-19-en</a>). I don't know
if the .usTLD Stakeholder Council was put in place out of a sense of
public interest, or whether they had to commit to it in order to satisfy
the US Government's procurement process. It is certainly a model that can
be used for how .nyc should be operated, but perhaps unfortunately,
there is nothing in the current policies that could compel .nyc, as
a delegated TLD, to adopt such a policy other than voluntarily. On the
other hand, if your aim is to make sure that this type of problem does
not happen again, a GNSO PDP on setting the policies for any future gTLD
rounds (or other methods of release) has just started. It is doing a full
review of all policies, and you (and anyone else) are welcome to take an
active part in it. See
<a href="https://community.icann.org/x/RgV1Aw" eudora="autourl">
https://community.icann.org/x/RgV1Aw</a> to sign up.<br><br>
Regards, Alan<br><br>
<br><br>
<br><br>
<br><br>
<br>
<br><br>
<br>
At 08/05/2016 12:04 AM, Thomas Lowenhaupt wrote:<br><br>
<blockquote type=cite class=cite cite="">Fellow NARALO Members,<br><br>
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.<br><br>
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 ICANN's
website
<<a href="https://www.icann.org/resources/agreement/nyc-2014-01-23-en">
https://www.icann.org/resources/agreement/nyc-2014-01-23-en</a>>, 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:
<ul>
<li>All Digit/Digit, Letter/Digit, and Digit/Letter Two-Character ASCII
Labels at the Second Level (01 December 2014)
<<a href="https://www.icann.org/en/system/files/files/spec5-amend-two-char-01dec14-en.pdf">
https://www.icann.org/en/system/files/files/spec5-amend-two-char-01dec14-en.pdf</a>
>
<li>Letter/Letter Two-Character ASCII Labels (26 May 2015)
<<a href="https://www.icann.org/sites/default/files/tlds/nyc/nyc-auth-ltr-ltr-26may15-en.pdf">
https://www.icann.org/sites/default/files/tlds/nyc/nyc-auth-ltr-ltr-26may15-en.pdf</a>
>
<li>Letter/Letter Two-Character ASCII Labels (14 March 2016)
<<a href="https://www.icann.org/sites/default/files/tlds/nyc/nyc-auth-ltr-ltr-14mar16-en.pdf">
https://www.icann.org/sites/default/files/tlds/nyc/nyc-auth-ltr-ltr-14mar16-en.pdf</a>
>
</ul><br>
The fourth was listed under "Amendment No.1 (31 March 2016)":
<ul>
<li>PDF
<<a href="https://www.icann.org/sites/default/files/tlds/nyc/nyc-amend-1-pdf-31mar16-en.pdf">
https://www.icann.org/sites/default/files/tlds/nyc/nyc-amend-1-pdf-31mar16-en.pdf</a>
> This PDF amendment deals with the addition of 14 new data fields to
the Registration Data Directory.
</ul><br>
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. <br><br>
My desire for inclusion of individual Internet users in consultations
about future registry changes provides the basis for this
message.<br><br>
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
law.” However...<br><br>
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. <br><br>
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...<br><br>
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. <br><br>
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. <br><br>
What’s to be done?<br><br>
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 .us
TLD.<br><br>
The .us TLD is currently governed with the assistance of a .usTLD
Stakeholder Council:
<a href="http://www.neustar.us/ustld-stakeholder-council/structure-and-history/">
http://www.neustar.us/ustld-stakeholder-council/structure-and-history/</a>
. The council has a
<a href="http://www.neustar.us/ustld-stakeholder-council/charter/">
charter</a>,
<a href="http://www.neustar.us/ustld-stakeholder-council/ustld-stakeholder-council-operating-procedures/">
operating procedures</a>, a membership (which is appointed by the
contractor!), and operational parameters (see usTLD Administrative
Component graphic below).<br><br>
<br><br>
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.<br><br>
Sincerely,<br><br>
Thomas Lowenhaupt<br><br>
<hr>
<br>
Basis for ICANN approval of 4 .nyc TLD registry agreement
changes<br><br>
<ul>
<li>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
<a href="http://atlarge-lists.icann.org/pipermail/alac-announce/2014q3/001875.html">
http://atlarge-lists.icann.org/pipermail/alac-announce/2014q3/001875.html</a>
. 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.
<li>You can see the history of our full process on this by going to
<a href="https://atlarge.icann.org/policy-summary">
https://atlarge.icann.org/policy-summary</a> and doing a search on
statement titles including the words TWO CHARACTER DOMAIN.
<li>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
(<a href="http://www.ownit.nyc/policies/nyc_nexus_policy.php">
http://www.ownit.nyc/policies/nyc_nexus_policy.php</a>). The request by
the registry can be viewed at
<a href="https://www.icann.org/en/system/files/files/rsep-2016002-nyc-request-04jan16-en.pdf">
https://www.icann.org/en/system/files/files/rsep-2016002-nyc-request-04jan16-en.pdf</a>
. Such Registry Service Evaluation Process (RSEP) requests can be viewed
at
<a href="https://www.icann.org/resources/pages/rsep-2014-02-19-en">
https://www.icann.org/resources/pages/rsep-2014-02-19-en</a>. The overall
process followed in RSEP can be seen at
<a href="https://www.icann.org/resources/pages/workflow-2012-02-25-en">
https://www.icann.org/resources/pages/workflow-2012-02-25-en</a>. The
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).
<li>The RSEP is the result of one of the early GNSO Consensus Policy
Development Processes -
<a href="http://gnso.icann.org/en/issues/registry-services/final-rpt-registry-approval-10july05.htm">
http://gnso.icann.org/en/issues/registry-services/final-rpt-registry-approval-10july05.htm</a>
. That process was of course subject to public comments and the resultant
policy was widely supported.
</ul><br>
<br><br>
<br><br>
Content-Type: image/png;<br>
<x-tab> </x-tab>
name="CqUBoKoO57Ys6mRwGOc4PEv_FsQwDJoMfH-n9skqModIU8zCCOi6h1jfJBAz7q8BmxymzToDervRbdXUQh5zhTbRlftGScN3qDUjOu8jfRhDoTClAOnVZH3h_tq-xxsoeYWeO1bt"<br>
Content-ID: <part9.A530C394.8ADF4F98@communisphere.com><br>
Content-Disposition: inline;<br>
<x-tab> </x-tab>
filename*0="CqUBoKoO57Ys6mRwGOc4PEv_FsQwDJoMfH-n9skqModIU8zCCOi6h1jfJBAz";<br>
<x-tab> </x-tab>
filename*1="7q8BmxymzToDervRbdXUQh5zhTbRlftGScN3qDUjOu8jfRhDoTClAOnVZH3h";<br>
<x-tab> </x-tab>
filename*2="_tq-xxsoeYWeO1bt"<br>
X-Microsoft-Exchange-Diagnostics:<br>
<x-tab> </x-tab>
1;SN1PR0301MB2030;9:Ug/DpD5yV4BmxIyugixxRGSsv3hRKWl1cx4WR/W9B/DtnY/xrrrktnmxdbgHeoZ4NIEHvpIejuwurBKdd3ijsjFutMqZelfdip/H2/H9RXrkf/LjbaAg6dB8KKAqfPLzGJlR8Rg2C/NGCrUollB4EckY1E4jXhEip+BsLLKwU1c=<br>
<br>
<br>
Content-Type: text/plain; charset="us-ascii"<br>
Content-Transfer-Encoding: 7bit<br>
Content-Disposition: inline<br>
X-Microsoft-Exchange-Diagnostics:<br>
<x-tab> </x-tab>
1;SN1PR0301MB2030;9:Ug/DpD5yV4BmxIyugixxRGSsv3hRKWl1cx4WR/W9B/DtnY/xrrrktnmxdbgHeoZ4NIEHvpIejuwurBKdd3ijsjFutMqZelfdip/H2/H9RXrkf/LjbaAg6dB8KKAqfPLzGJlR8Rg2C/NGCrUollB4EckY1E4jXhEip+BsLLKwU1c=<br>
<br>
------<br>
NA-Discuss mailing list<br>
NA-Discuss@atlarge-lists.icann.org<br>
<a href="https://atlarge-lists.icann.org/mailman/listinfo/na-discuss" eudora="autourl">
https://atlarge-lists.icann.org/mailman/listinfo/na-discuss</a><br><br>
Visit the NARALO online at
<a href="http://www.naralo.org/" eudora="autourl">
http://www.naralo.org</a><br>
------</blockquote></body>
</html>