[NA-Discuss] Inclusion of Individual Internet Users within the City-TLD Multistakeholder Governance Environment

[Alan Greenberg]

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.

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.  ;-)

On to substance.

.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.

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.

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.

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.

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.

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.

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.


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.

.us was historically operated by Verisign and was 
redelegated to NeuStar in 2001 
(https://www.icann.org/news/announcement-2001-11-19-en). 
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 
https://community.icann.org/x/RgV1Aw to sign up.

Regards, Alan











At 08/05/2016 12:04 AM, Thomas Lowenhaupt wrote:

>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 ICANN's website 
><<https://www.icann.org/resources/agreement/nyc-2014-01-23-en>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) 
> <<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> 
>
>    * Letter/Letter Two-Character ASCII Labels 
> (26 May 2015) 
> <<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> 
>
>    * Letter/Letter Two-Character ASCII Labels 
> (14 March 2016) 
> <<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> 
>
>
>The fourth was listed under "Amendment No.1 (31 March 2016)":
>    * PDF 
> <<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> 
> 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 law.” However...
>
>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 .us TLD.
>
>The .us TLD is currently governed with the 
>assistance of a .usTLD Stakeholder Council: 
><http://www.neustar.us/ustld-stakeholder-council/structure-and-history/>http://www.neustar.us/ustld-stakeholder-council/structure-and-history/. 
>The council has a 
><http://www.neustar.us/ustld-stakeholder-council/charter/>charter, 
><http://www.neustar.us/ustld-stakeholder-council/ustld-stakeholder-council-operating-procedures/>operating 
>procedures, 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.
>
>Sincerely,
>
>Thomas Lowenhaupt
>
>
>----------
>
>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 
> <http://atlarge-lists.icann.org/pipermail/alac-announce/2014q3/001875.html>http://atlarge-lists.icann.org/pipermail/alac-announce/2014q3/001875.html. 
> 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-summary>https://atlarge.icann.org/policy-summary 
> and 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>http://www.ownit.nyc/policies/nyc_nexus_policy.php). 
> The request by the registry can be viewed at 
> <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. 
> Such Registry Service Evaluation Process (RSEP) 
> requests can be viewed at 
> <https://www.icann.org/resources/pages/rsep-2014-02-19-en>https://www.icann.org/resources/pages/rsep-2014-02-19-en. 
> The overall process followed in RSEP can be 
> seen 
> at 
> <https://www.icann.org/resources/pages/workflow-2012-02-25-en>https://www.icann.org/resources/pages/workflow-2012-02-25-en. 
> 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).
>    * The RSEP is the result of one of the early 
> GNSO Consensus Policy Development Processes - 
> <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. 
> That process was of course subject to public 
> comments and the resultant policy was widely supported.
>
>
>
>
>
>Content-Type: image/png;
> 
>name="CqUBoKoO57Ys6mRwGOc4PEv_FsQwDJoMfH-n9skqModIU8zCCOi6h1jfJBAz7q8BmxymzToDervRbdXUQh5zhTbRlftGScN3qDUjOu8jfRhDoTClAOnVZH3h_tq-xxsoeYWeO1bt"
>Content-ID: <part9.A530C394.8ADF4F98 at communisphere.com>
>Content-Disposition: inline;
> 
>filename*0="CqUBoKoO57Ys6mRwGOc4PEv_FsQwDJoMfH-n9skqModIU8zCCOi6h1jfJBAz";
> 
>filename*1="7q8BmxymzToDervRbdXUQh5zhTbRlftGScN3qDUjOu8jfRhDoTClAOnVZH3h";
>         filename*2="_tq-xxsoeYWeO1bt"
>X-Microsoft-Exchange-Diagnostics:
> 
>1;SN1PR0301MB2030;9:Ug/DpD5yV4BmxIyugixxRGSsv3hRKWl1cx4WR/W9B/DtnY/xrrrktnmxdbgHeoZ4NIEHvpIejuwurBKdd3ijsjFutMqZelfdip/H2/H9RXrkf/LjbaAg6dB8KKAqfPLzGJlR8Rg2C/NGCrUollB4EckY1E4jXhEip+BsLLKwU1c=
>
>
>Content-Type: text/plain; charset="us-ascii"
>Content-Transfer-Encoding: 7bit
>Content-Disposition: inline
>X-Microsoft-Exchange-Diagnostics:
> 
>1;SN1PR0301MB2030;9:Ug/DpD5yV4BmxIyugixxRGSsv3hRKWl1cx4WR/W9B/DtnY/xrrrktnmxdbgHeoZ4NIEHvpIejuwurBKdd3ijsjFutMqZelfdip/H2/H9RXrkf/LjbaAg6dB8KKAqfPLzGJlR8Rg2C/NGCrUollB4EckY1E4jXhEip+BsLLKwU1c=
>
>------
>NA-Discuss mailing list
>NA-Discuss at atlarge-lists.icann.org
>https://atlarge-lists.icann.org/mailman/listinfo/na-discuss
>
>Visit the NARALO online at http://www.naralo.org
>------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://atlarge-lists.icann.org/pipermail/na-discuss/attachments/20160511/55f97c77/attachment-0001.html>