• Cyber Land Use Plan

last modified March 19, 2014 by tomlowenhaupt

Here we present a plan for the allocation of .nyc domain names. We gratefully acknowledge the Council of European Registrars which shared its Name Space Reserves plan providing the genesis of this effort. 


Planning Tools / Concepts
  • Comprehensive Planning

  • Community Based Planning
  • Eminent Domain

  • Landmarking
  • LULU
  • Mixed Use Zoning
  • Name Banking
  • No Indiscriminate Auctions
  • Public Spaces
  • Specialized Zoning Districts
  • ULURP
  • Velvet Rope
  • Zoning
Name Sets
  • boroughs.nyc
  • neighborhoods.nyc
  • transportation stations.nyc
  • streets.nyc

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

     

 

 

 

New York City Cyber Land-Use Plan

DRAFT v.2

(Draft  v.3 to incorporate Land-Use Concepts/Policies: Comprehensive Planning; Eminent Domain; Landmarking; LULU; Mixed Use Zoning; Name Banking; Auctions; Specialized Zoning Districts; ULURP; Velvet Rope; Public Spaces and the Domain Name Allocation Plan)

Background

When planning a city's future growth, a common practice is to create a comprehensive plan or visioning. This Cyber Land-Use Plan was created as a planning guide for the allocation and management of the .nyc TLD.

Contrary to the traditional first-come, first-served domain name registration paradigm, our Cyber Land Use Plan:

  • conveys exclusivity for entire zones of the name-space,
  • involves a large number of active domains and,
  • imposes policy obligations upon the zone name holder.
These policy obligations may cover:
  • compulsory content provision on the entire name zone
  • attached services
  • guidelines and or restrictions on advertising
  • security and privacy standards.

Name-Space Zones are a foundation element of our Cyber Land Use Plan. Just as the role of the mayor, city planning department, city council, and community boards involves land-use planning and zoning to manage development, a necessary role for city-TLD oversight involves managing the city’s name-space zones (NSZs). The management of a given zone of the name-space can be delegated to a government entity, a for-profit, or not-for-profit institution. Managed spaces for the .nyc TLD include name zones for the following:

  • Streets 
  • Monuments
  • Buildings / Property
  • Neighborhoods
  • Professional Categories
  • Public Transportation
  • Community/Public Services
  • Government
  • Voters/Civic
  • Tourism
  • Business

The Cyber Land Use Plan plays a key role from the policy-oriented and service perspectives.

  • Without the aggregate effect of the block of names in a Zone, many policy choices would be ineffective, and many services would be impractical.
  • The Zones also play a key role from a funding perspective, most notably for those choosing a public/private management model. Coherent name spaces have significant advertising potential that grows with the TLD. Potential zone overseers could therefore participate in the initial funding of the TLD. They could also be allowed to participate with other stakeholders in the design of the TLD policies.
  • A thoughtfully developed NSZ plan contributes to a successful launch of the .nyc TLD. With such, .nyc can go live with a large number of meaningful domains carrying useful content.
  • The creation of name space zones can facilitate the issuance of names on a first-come, first-served basis outside the NSZ blocks. A city-TLD can be "put on the map" by thanks to the early availability of coherent content. This promotes the TLD and encourages individual registrations as well.

What is a Name-Space Zone?

A Name-Space Zone (NSZ) is a combined adjudication of a coherent set of domain names in a community-oriented TLD to a trustee. The trustee must provide services on those names as specified in the preserve, and may provide additional services not specifically barred. Names cannot be transferred to individual users. As a funding mechanism, the advertising income from the names in the NSZ accrues to the trustee who in turn pays a combined delegation fee to the TLD registry. The NSZ has a term of several years and the initial allocation and/or the renewal may require a RFP with the objective of maximizing its value to the TLD community. The trustee must build end-user goodwill within the NSZ and related NSZs. To that effect, the trustee must commit coding web links and search results in such a way as to point to names belonging to the NSZ or to related NSZs (see examples below).

An NSZ is not a bulk registration, as the trustee has service obligations and may have to give up certain names based on TLD policy decisions. The objective of an NSZ is to entrust the management of names to the party making the best use of it in the interest of the underlying community. For this reason, the preservation may contain provisions requiring the transfer of names or groups of names to a party better suited to provide the underlying services. Some of the individual names of the NSZ block could spontaneously generate such services, but the advantage is the guarantee of a name space-wide service, and hence the increased awareness of the users resulting in a real visibility of the service. As such the NSZ is well adapted to develop public acceptance of a new TLD: rather than having to wait for people to register individual names, the TLD registry can ensure that certain name spaces are active from Day 1. As and when parties emerge who are better suited to provide content for a given subset of names, these can be transferred without deterioration of service to the public. In a city-TLD, the trustee of an NSZ may be a public entity. For certain NSZs (involving directly-managed public services), this might be the simplest solution. The trustee may outsource the technical management to a specialized agency or a publishing company. Another alternative is to directly delegate a given NSZ to a given private trustee.

Types of Name Space Zones for city-TLDs

The following is description of a name space preserve for NYC. It is of course important that the registry be open to additional initiatives from local community organizations, local authorities, or companies.

Streets Zone

Structure

This zone involves names of streets, squares, avenues etc. (the nomenclature). It is primarily intended for web pages, but derived services could involve other applications, current and future.

Examples: 42nd-street.nyc – Astoria-boulevard.nyc – Washington-street.nyc - charles-street.nyc – east-73rd-street.nyc – Garibaldi-avenue.nyc - Madison-avenue.nyc – kigns-highway.nyc – queens.boulevard.nyc – beaver-street.nyc – beacon-place.nyc – east-19-street.nyc – vandam-street.nyc

Content

The primary purpose of the Streets Zone is to provide contextually coherent information including maps. Thanks to the fact that addresses used by the public are application independent, the Zone trustee can freely change the source of the information without affecting the look and feel. For instance, the Streets Zone can be bootstrapped with data from Google, OpenStreet Maps, or with a mix of sources, such as the Wikimapia which, in addition to is own data, relies on Google Maps. If the Zone trustee can obtain data directly from the city's geomatic services (current and future), the service can be further improved for the benefit of local users and tourists. As some streets are related to historic people, events or achievements, the content for each street includes interesting facts and tourist information about the street. Businesses and public resources located on the street can obtain basic listing free of charge; in addition to the free listing, the Zone trustee may sell contextual advertising to them. In addition to geographic information the Streets Zone can carry more granular information, either in the form of domain names or in the form of parameters in an URI. An important part of the value of the Streets Zone is the contextual linking to other domains in the same preserve. This is possible because all the names are handled by the same trustee, or by a small number of trustees, all of whom are bound by a coherent policy and specific content publishing obligations. For instance, in addition to contextual click zones on an interactive map, a web page of a given street name domain will offer explicit links to intersecting streets, as well as to domains for train, bus or other public transport stations.

Size

A Streets Zone in for New York City should be expected to contain over 100,000 domains, including variants (e.g., Broadway ~ Bdway and Street ~ St).

Funding

A Streets Zone in a city-TLD has a substantial advertising potential, even if stringent content, services, and context restrictions apply. It can therefore contribute to fund the TLD itself and become an incubator of additional Zone.

Adjudication and Bootstrapping

The Streets trustee could be the local government, which in turn could outsource the service's operations. On the other hand, a prospective third-party trustee for the Streets Zone could be identified through a Request for Proposals or designated as part of the TLD launch group and could be expected to make financial contributions to the TLD launch project. In exchange for the funding contribution, the trustee can be awarded the Streets & Monuments Zone preserve for a period of 3 to 4 years. Conditions will include the readiness of the applications by TLD launch. Prior to the end of the term of the initial preserve, the TLD registry organizes an RFP to identify the trustee that will best serve the city’s interest. The initial trustee should be allowed to bid in this tender; subsequent preserve periods can be made longer (such as 10 years).

Monuments Zone

A Monuments Zone can be integrated into the Streets & Monuments NSZ or be run separately. Keeping in mind that NSZs will benefit carrying contextual links to one another. Monuments are singular places that might also include tourist attractions. The Monuments Zone is strongly integrated with the Streets Zone, especially by way of links to resources in the Streets Zone. For instance:

Saint-Patricks.nyc

carries information about the cathedral, and links to related streets and places, such as:

Saint-Patricks.nyc -> fifth-avenue.nyc Saint-Patricks.nyc -> madison-avenue.nyc Saint-Patricks.nyc -> e-51-street.nyc Saint-Patricks.nyc -> e-52-street.nyc Saint-Patricks.nyc -> Rockefeller-Center.nyc Etc.

Compared to streets, the Monuments Zone might carry a higher share of tourist information. In other aspects, it is similar to the Streets Zone.

The Public Transportation Zone

The Public Transportation Zone includes names for train and subway stations, bus stops, cab stands, park-and-ride facilities, etc. This zone has a close relationship with the Streets, Monuments, and Tourist zones (as discussed below). Examples include: Grand-Central.nyc Penn-Station.nyc Cristopher-Street-Station.nyc Wall-Street-Station.nyc

Professional Category Zones

The Professional Categories NSZ comprises names reflecting businesses, professions, and professional services. As such, it is similar to the Yellow Pages. (The local Yellow Pages might be considered as a trustee of the Professional Categories NSZ.) Suggestions have been made that the categories provide opportunities for entrepreneurs to start small business based on names such as restaurants.nyc. Examples of names in a Professional Categories NSZ include:

  • lawyers.nyc
  • plumbers.nyc
  • florists.nyc
  • bars.nyc
  • architects.nyc
  • programmers.nyc
  • catering.nyc
  • psychologists.nyc
  • hospitals.nyc
  • doctors.nyc etc.

In some cases, names may be allocated that are friendly to foreign visitors, e.g. Rechtsanwälte.nyc (lawyers) Klempner.nyc (plumbers) Floristen.nyc (florists) Spitäler.nyc (hospitals.nyc) Architekten.nyc (architects.nyc).

The Professional Categories NSZ has a high advertising potential. The trustee should therefore be expected to contribute financially to the launch and the operation of the TLD. Certain high usage names have a natural potential to stand alone and do not need to be included in the NSZ. Examples include: restaurant.nyc restaurants.nyc taxi.nyc taxis.nyc hotel.nyc hotels.nyc We are exploring whether certain professional categories organized as (often mandatory) local guilds, such as lawyers, doctors, etc., could or should have their corresponding domains treated in a case-by-case approach. It would also be worth checking the public or private nature of some of those professional services (yellow taxis, for instance, run as a public service by private professionals though a system very close to a public concession).

Government and Community/Public Services Zone

The Government and Community/Public Services NSZ includes a large number of names for governmental services and departments, schools, etc. as well as services offered by these organizations. It carries information on what to find there as well as search tools to find services. Examples include: bicycling.nyc hospitals.nyc police.nyc cemeteries.nyc council.nyc mayor.nyc Names related to the services directly or indirectly run by City Government would be registered by the relevant authority instead of forming part of a NSZ. Therefore, special delegation rules (Sunrise-based or otherwise) could be designed if the local administration prefers this solution. But the relevant authorities might consider that they do not have a special role in managing such names, or that the name space would benefit from a shared or similar management as the other NSZs. We advise to carefully check each name (service) included in this category.

Relationships between NSZs and Other Name Spaces

Delimitation by Linguistic Means: Natural Names instead of Cryptic Syntax

Name-Space Zones require distinct perception by the user. The user must understand, for instance, that streets.nyc or times-square.nyc or central-park.nyc are not individually registered domain names, but part of a system. This must be clear even before visiting the web site. Experience has shown that users do not come easily to grips with expressions like ".co.uk" or ".com.br" or .airport.aero". At best, for a given TLD like .uk or .br, they remember .co.uk or .com.br, but hardly realize that there are any others (like .or.uk or .org.br). The same humans who have problems with cryptic syntax have no problem relying on extensive and complex knowledge. It would therefore be a mistake to rely on dots (subdomains) to delimit name spaces. For instance, it is a bad idea to preserve the exclusive use of names like: penn.station.nyc staten-island.zoo.nyc whereas it is a good idea to systematically propose domains like (showing name clouds) grand-central-station.nyc ~ grandcentralstation.nyc, columbuscircle.nyc ~ Columbus-circle.nyc, centralparkzoo.nyc ~ central-park-zoo.nyc.

Managed overlap of related name spaces

Managed overlap is not new, even coded name spaces (such as IATA airline codes) rely on it. In the case of .nyc, many natural name spaces present overlap for certain names. For instance, times-square.nyc and christopherstreet.nyc can be part of both the Streets/Monuments name space and the Public Transportation name space, provided that the overlap is managed by way of agreements between the respective preserve holders. In these cases, it can be useful to treat the overlapping name as a part of special "overlap" preserve and add preserve-specific (albeit less memorable) names where there is no overlap. The preserves can then run links to the overlap names depending as follows: examples...

Interaction with delegated name spaces

The doted names spaces (described above as not recommended for the TLD registry itself) do have a valuable role when run by key institutions (or when run by specialized a content provider on behalf of that key institution). For city-TLDs, a typical case are the various transport organizations. These 3rd-level domains can provide a one-to-one mapping of domains to nodes in the respective public transport network. Whenever applicable, they can be the origin or the target of links Times-square.nyc Times-square.station.nyc

Name Clouds or Domain variants (including special characters)

There is no intrinsic incremental cost for any domain. Variants should therefore be created whenever the user could reasonably use it. In a name space preserve, it is easy to enable virtually all necessary variants. As the registry creates these names ex-nihilo, there is not cost. For instance, the .nyc user could type: grand-central-station.nyc grandcentralstation.nyc grandcentral-station.nyc grand-central.nyc grandcentral.nyc etc., where the web servers will then rewrite the name depending on the policy. etc. to which common spelling errors may be added, such as: grand-centrale.nyc grand-centrl.nyc all of which of course will be restituted in the standardized version once the web server responds. Interaction with delegated name spaces The doted names spaces (described above as not recommended for the TLD registry itself) do have a valuable role when run by key institutions (or when run by specialized a content provider on behalf of that key institution). For city-TLDs, a typical case are the various transport organizations. These 3rd-level domains can provide a one-to-one mapping of domains to nodes in the respective public transport network. Whenever applicable, they can be the origin or the target of links sagrada-família.bcn sagrada-família.metro.bcn catalunya.ferrocarrils.bcn plaça-catalunya.bcn catalunya.metro.bcn catalunya.renfe.bcn plaça-catalunya.bcn catalunya.metro.bcn etoile.rer.paris etoile.paris charles-de-gaulle-etoile.paris chatelet.rer.paris chatelet.paris chatelet-les-halles.paris chatelet.metro.paris chatelet.paris chatelet-les-halles.paris

Managed overlap of related name spaces

Managed overlap is not new, even coded name spaces (such as IATA airline codes) rely on it. In the case of city-TLDs, many natural name spaces present overlap for certain names. For instance, sagrada-família.bcn alexanderplatz.berlin, etoile.paris can be part of both the Streets/Monuments name space and the Public Transportation name space, provided that the overlap is managed by way of agreements between the respective mandate holders. In these cases, it can be useful to treat the overlapping name as a part of special "overlap" mandate and add mandate-specific (albeit less memorable) names where there is no overlap. The mandates can then run links to the overlap names as follows: montjuïc.bcn, sants-estació.bcn, sants.bcn, barcelona-sants.bcn, etoile.paris, charles-de-gaulle-etoile.paris, etoile.paris, arc-du-triomphe.paris, and New York City Protection of a Name Space.

It is not always possible to identify from the start all names or all variants of names that belong to a given name space. For this reason, a new TLD registry could refer to the NSZs in its standard registration agreement. The agreement would inform registrants of a special dispute-resolution procedure in case an individually-registered name is found to interfere with an NSZ. For manifest cases of deliberate abuse, the procedure can be built to be economical enough to discourage such behavior altogether. Conversely, the definition of a Name Space Preserve can involve circumscription in addition to a list of names. For instance, the Streets NSZ can refer to the city's street database (the content of which changes in time). To avoid accidental collisions, the TLD registry's individual registration process can be built to contain filters based on regular expressions. Any attempted individual domain registration matching the regular expression would them fail unless associated with a specific authorization code.

Background: NSZs and "portal" sites

The word "portal" was commonly used in the late 1990s to describe a phenomenon that proceeded the "Google" era: web-based initiatives created a single brand under which users were supposed to find everything that related to the purported objective of the site. This concept was widely taken over by cities and public authorities in order to offer on-line resources often referred to as "one-stop window." While centralized databases do permit more effective content management in many cases, the centralization of display and customer goodwill might be counterproductive.

With the Google phenomenon of easy online advertising, pay-per-click and domain monetization sites became pervasive. As a result, public authorities' portal sites became less visible. An NSZ can be regarded as similar to a portal site, but instead of one "brand"-like domain name, many context-specific names are used. The user directly remembers the specific name - as do the users’ browsers, by the way. Most browsers have URL auto-complete functions - these are useful if the domain is specific and if the URL does not contain too long a path or query string after the domain name. From an advertising perspective, an immediate gain is made: by selecting the specific domain name (e.g."grand-central-station.nyc", "bronx-zoo.nyc"), the user voluntarily indicates an area of interest. Advertising can then be made specific to that context (e.g. for a flower shop at Bronx Zoo, a restaurant close to Grand Central Station). From a public policy perspective, this development has even higher importance than just on the level of a specific TLD: search engines and social-networking sites currently compete heavily in a highly questionable direction: typical advertising engines have to gather personal information about the user using cookies and analyzing the user's past search behavior. NSZs, on the other hand, create an alternative. NSZs supply advertising information that has voluntarily been submitted by the user. This is possible because the NSZs have highly granular domain names where each domain name typed by the user reflects the user's momentary objective.

TLD Launch and Financing Considerations

NSZs are critical for the launch of new city-TLDs for two reasons:

  • First, a new TLD needs to gain public attention and get into the habits of users. Unless NSZs are used making a large name space active on day 1, lack of public attention is a vicious circle: in the absence of widely used names in the TLD, few people learn about the TLD, therefore few registrars offer it and few people register names. If NSZs are used, on the other hand, the public learns about a reliable name space by using it on a daily basis (threshold effect and trust effect).
  • Thanks to their coherent name spaces, many NSZ may have a significant financial potential. In order to develop the content, NSZ trustees need to make investments. In line with the value of their investment, they are in a position to contribute financially to the TLD launch project and in particular to the development of the regulatory framework of the TLD (and thus the NSZs as a whole). A publicly desirable side effect of NSZ is to prevent the kind of massive speculation on attractive coherent sets of domains that has affected recent TLD launches. The launch of a city-TLD in this respect is similar to an urban development project: project managers collaborate with developers, investors, community organizations, governmental authorities and specialized agencies. The objective is to combine the resources and balance the interests in order create a valuable space for the community. ICANN Considerations

ICANN Fees

ICANN currently requires TLD registries to pay an annual "transaction-based" fee per domain. In the latest gTLD contracts, this fee was $0.12 per domain. Moreover, ICANN requires registrations to be made exclusively via ICANN accredited registrar. These registrars are in turn required to pay ICANN a fee that is currently in the order of USD 0.20 per domain. As a result, each domain could at least "cost" $ .32 (up to $ 2.32 if we look at the recent sTLD contracts) in ICANN fees unless ICANN rules evolve. In the current context, it is best to make budget calculations based on a potential liability in this order of magnitude towards ICANN. (N.B. CORE, the European Registry, has already explored the principle of a "fixed fee per name space block" with ICANN staff, with encouraging results.) Registries using NSZs need to jointly communicate the merits of the NSZ paradigm and obtain adequately differentiated treatment in the long run.

Contractual Status of NSZs

An NSZ will be regarded as a registry service subject to ICANN's procedures, unless our efforts to carve out a sphere for public interest city-TLDs succeeds. ICANN has the power to reject a new registry service if it is determined to endanger security and stability of the Internet, and it should be presumed to have the power to refer the service to a competent governmental competition supervisory agency if it feels that the service violates competition legislation. NSZs in themselves neither endanger security and stability nor do they present any concerns for competition, but seeking advice from the relevant ICANN bodies (RSSAC; DG Competition) will be beneficial.

Server Location

In development.

Key .nyc Pages