Re: [council] RE: [Correspondence] Letter from Steve Crocker to James Bladel, Chair, GNSO Council
- To: WUKnoben <wolf-ulrich.knoben@xxxxxxxxxxx>, GNSO Council List <council@xxxxxxxxxxxxxx>
- Subject: Re: [council] RE: [Correspondence] Letter from Steve Crocker to James Bladel, Chair, GNSO Council
- From: Johan Helsingius <julf@xxxxxxxx>
- Date: Wed, 21 Sep 2016 19:48:16 +0200
- In-reply-to: <84602057272D45388A395EE4F665460A@WUKPC>
- List-id: council@xxxxxxxxxxxxxx
- References: <1C6DEE17-CEFE-4E19-A068-BEAEAEBF4491@icann.org> <D3D11D4D.CFCF8email@example.com> <8E84A14FB84B8141B0E4713BAFF5B84E21209198@Exchange.sierracorporation.com> <84602057272D45388A395EE4F665460A@WUKPC>
- Sender: owner-council@xxxxxxxxxxxxxx
- User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
> 1. Both the letter from the Board and the letter from the GNSO
> Council seem to start with the assumption that there will necessarily be
> a subsequent round of the new gTLD program. The ISPCP constituency hopes
> that a full discussion about whether or not to have a further round is
> had by the community long before work is done on building a new
> application process. It seems essential that the marketplace and
> technical reviews are complete and considered by the community. These
> need to be part of the foundation of any discussion of whether or not to
> proceed with subsequent rounds of new gTLD applications.
Indeed. I am concerned about the way a lot of people seem to
assume a subsequent round will happen. I feel we have to
wait for the results of the reviews before making up our minds.
> 2. In the event that a new gTLD application window is opened, no
> particular type of gTLD should be allowed to determine the timing of the
> window. In particular, all strings should have equal status as far as
> the timing of a subsequent window. For example, a set of strings for a
> particular use or function, should not be allowed to proceed early.
> 3. In the event that a new gTLD application window is opened, the
> policy work in support of the new round should be complete prior to the
> application process being developed. The ISPCP constituency finds the
> idea of iterative development of application process to be impossible in
> the context of such a complex procedure. An iterative approach fails to
> take into account the interconnectedness of the application process –
> the development of a policy on geographic names, for example, might have
> implications on what strings are available and even the prohibition of
> certain names. The possibility of policy development in one area having
> a knock-on effect in another area is something we witnessed in the 2012
> round. It would likely be a feature of subsequent rounds and makes the
> iterative development of an application process unlikely to succeed.
Again, I really have to agree. Strongly.
> 5. Another technical aspect that must be addressed prior to a new
> round beginning is the relationship between the Internet’s underlying
> architecture and the new gTLD program. Specifically, ICANN must improve
> its relationship with the IETF to identify meaningful ways to cooperate
> in the reservation of certain strings in the root. This relationship
> must also provide some reliable, predictable, scalable and usable
> mechanism for reserving strings for special use or because those
> strings, if allowed in the root, would affect the security and stability
> of the DNS and tools built upon the DNS.