[NA-Discuss] Inclusion of Individual Internet Users within the City-TLD Multistakeholder Governance Environment
Alan Greenberg
alan.greenberg at mcgill.ca
Wed May 11 14:38:52 UTC 2016
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>
More information about the NA-Discuss
mailing list