• Appendix C - Scope of Work

last modified May 6, 2015 by tomlowenhaupt

The Scope of Work details the activities to be undertaken by the contractor, Neustar Inc. and the city of New York.

  1. NOTE: The section numbering and formatting are in need of adjustment, they were put into disarray in the conversion from .pdf to HTML. See the original .pdf here. 
  2. A more detailed presentation of the project's Launch [section (4)(h)] is presented on this page


































































































































Premium Names

(iv) (i) "with the objective of optimizing revenues:"



































  See Founders in: ICDR Case No. 50 117 T 00812 11


















































































































































































































































































































































  1. Responsibility for Application. Neustar shall be responsible for all aspects of the City’s application to ICANN to become the Registry Operator of .NYC (“Application”). Toward that goal, Neustar shall perform the following tasks:

(a) drafting the Application in consultation with the City;
(b) providing all documentation and information requested by DoITT and/or ICANN or otherwise necessary in connection with the Application; provided that DoITT acknowledges that certain information and documentation requested by ICANN must be provided by DoITT to Neustar in order for Neustar to complete the Application;
(c) clarifying and educating the City on the new gTLD application process, including all policy, legal, and other related developments as necessary;
(d) filing the Application in such a way that ICANN does not reject it for a technical, non-substantive reason (such as filing the Application via ICANN’s TLD Application System in an improper manner or making payment for the Application in an improper format); and
(e) assisting DoITT during all ICANN evaluation and post-evaluation activities and requirements to enable the City to:
  1. timely and properly respond to any objections filed against the Application (including but not limited to all dispute resolution procedures);

  1. provide information to resolve any string contentions;

  1. transition to delegation, including, but not limited to, any required per-delegation technical test(s);

  1. provide information and documentation to enable the City to apply for .NYC in any subsequent application evaluation round; and

           v. comply with any other type of extended evaluation requested by ICANN.

  1. No Compensation via-a-vis the Application. There shall be no compensation to Neustar for fulfilling its obligations under Section 1 above.

  1. Application and Other Fees.

To the extent allowable by ICANN, Neustar will timely remit to ICANN one hundred eighty- five thousand dollars ($185,000) for the Application fee (“Application Fee”) in accordance with the payment schedule required by ICANN and submit proof of each payment to DoITT within twenty-four (24) hours thereafter. The Application Fee will be separate from and may not be credited against any other payments that are due or may become due from Neustar to DoITT under this Agreement, in the event that payment must be received directly from the City, the parties shall mutually agree on an alternative mechanism for payment; provided that Neustar shall ultimately be responsible for the payment of the Application Fee.


This portion of the Scope of Work shall not apply unless and until the City becomes the Registry Operator for .NYC.

4. Events Leading to General Registration. The following events shall take place in the following order (although some may overlap):

   (a) The City enters into the ICANN Agreement.

   (b) The City provides a copy of the ICANN Agreement to Neustar.

   (c) ICANN delegates .NYC to the City.

   (d) Neustar shall delegate the appropriate name servers with the Internet Assigned Numbers Authority (“IANA”).

   (e) Neustar begins signing up ICANN-Accredited Registrars (“Registrars”).

   (f) Neustar shall conduct all necessary testing, which will include but need not be limited to:

  1. Detailed analysis and requirements development exercises, culminating in a detailed deployment plan.

  1. The .NYC specific provisioning system and environment will be deployed, configured, and tested. This includes the production and operational-test-and-evaluation environments for the shared registration system, WHOIS, and DNS.

iii. Neustar shall conduct connectivity testing. This testing will provide Registrars with an opportunity to connect to the production environment and perform limited transactions. These transactions will include logging in, creating contacts, and querying objects. The purpose of this is to provide both the Registrars and the Registry with confirmation that the Registrar has been properly configured in the database, firewall, and packet shaper, and that the Registrar is using the proper credentials and certificates.

(g) Initial Rights Protection Mechanisms.

Neustar shall oversee and administer the ICANN-required initial rights protection mechanisms, including both a sunrise service and a trademark claims service in accordance with ICANN’s requirements for the operation of gTLDs at Neustar’s cost.

(h) Launch Phases. Neustar shall implement the launch of .NYC through a three-phased process as described below:

(i) Phase 1.

A. Neustar shall commence Phase 1 within sixty (60) days after delegation of the .NYC domain by IANA to Neustar as described in Section 4(d) above.

B. In terms of eligible registrants purchasing second-level .NYC domain names, Phase 1 shall last forty-five (45) days.

C. During the period of time set forth in Section 4(h)(i)(B) above, the following categories of registrants shall be eligible to register second-level .NYC domain names:

  1. Government (City, State and Federal offices providing services in the City);

  1. City-Based Non-Profits (entities that provide services within the City and that are registered with the State of New York as not-for-profit corporations);

  1. City Concessionaires (private entities using City-owned property under contract with a City agency)

  1. City Franchisees (private entities using inalienable City-owned property to provide a public service under contract with a City agency);

  1. Retail Service Licensees (private retail establishments licensed by a City agency to conduct such business);

  1. Food Service Licensees (private establishments licensed by the City's Department of Health and Mental Hygiene to provide food service);

  1. NYC & Co. Members (members of NYC & Company (a not-for-profit membership organization that serves as the City's promotional arm and which operates under a concession agreement with the City));

  1. Business Improvement Districts (a/k/a BIDS) (entities formed by local property owners and tenants to promote business development and quality of life and which operate pursuant to the General Municipal Law and local laws authorizing private not-for-profit corporations to provide supplemental services to particular geographic areas of the City and which operate under contract with the City's Department of Small Business Services for such purpose);

  1. City Digital Startups (private entities satisfying the following criteria: (a) their primary business objective is to bring to market products or services that are built from or whose functionalities are fulfilled using digital technology; (b) they have a physical presence in the City; and (c) they have registered with NYC Digital as a New York City digital company); and

10. City Vendors (private entities from whom the City procures goods and/or services and ARE registered with the Mayor's Office of Contract Services).

      (D) All registrations during Phase 1 shall be conducted on a first-come-first-served basis.

      (E) The City shall be responsible for the authentication of each registrant in each of the categories set forth in Section 4(h)(i)(C) above as well as the validation of the domain names selected by such registrants.

      (F) Only after the registrant is authenticated by the City and the associated domain name is validated, shall Neustar complete the registration process for such registrant.

      (G) Phase 1 domain names shall be active upon registration in accordance with industry standards.

     (ii)  Phase 2.

      (A) Neustar shall commence Phase 2 within six (6) months after delegation of the .NYC domain by IANA to Neustar as described in Section 4(d) above.

      (B) The only categories of prospective registrants that shall be eligible to register second-level .NYC domain names during Phase 2 are businesses, organizations or legal entities collectively (“Phase 2 Entities”) that:

      1. have a physical address in the City; and
      2. have paid City taxes within its most recent fiscal year.

      (C)  Neustar shall not be required to authenticate any of the registrants during Phase 2, but shall rely on self-certifications of eligibility and enforcement through the Nexus Policy described in Section 6 of the Agreement.

      D) Phase 2 shall begin with a sunrise period for Phase 2 Entities that hold a trademark registered in the Trademark Clearinghouse in accordance with the final ICANN Applicant Guidebook (“Sunrise Period”).

      1. The Sunrise Period shall last a minimum of thirty (30) days.

      1. The Sunrise Period shall be limited to second-level .NYC domain names that are the same as the applicable trademark registration.

      1. In the event that there are multiple applicants for the same domain name during the Sunrise Period, Neustar may conduct directly, or through a third party, an auction to determine the registrant of such domain name. Such auction(s) will be at no cost to the City and Neustar will not be permitted to set off any auction costs against monies owed the City.

      E) Following the Sunrise Period, Neustar shall accept domain name registrations from any NYC-Based Business, Organization or Legal Entity through a “Landrush Process.”

      1. During the Landrush Process, Neustar may charge higher wholesale fees to Registrars than it will during Phase 3 (as described in Section 4(h)(iii) below).
      2. Domain names shall be active upon registration during the Landrush Process.
      3. Neustar' shall promote the Landrush Process in a manner that creates awareness and encourages participation among the .NYC internet community. Promotional activities will include creating and distributing marketing materials for sales channels including Registrars and through marketing and promotional activities.
      4. It is currently anticipated that Neustar shall administer the Landrush Process in the manner set forth below; provided that such process may be amended from time to time with the written consent of the City, such consent to not be unreasonably withheld or delayed and at no cost to the City:

      (a) Applications for domain names will be received from Registrar s and channels.

      (b) If only one application is received for a specific domain name, at the conclusion of the Landrush Process, such name shall be allocated to the associated registrant through their designated Registrar.

      (c ) If more than one application is received for a specific domain name, an auction shall be conducted, and the highest qualified bidder shall be allocated the domain name upon payment of the applicable fees to the auction provider. Such names shall be allocated to the associated registrant through then designated Registrar.

      (d) Neustar shall provide reporting of all Landrush Process activities, as specified in Section 22 herein.

      (iii) Phase 3.

      (A) Phase 3 (to be referred to as “General Registration”) will be final launch phase that commences normal first-come, first-serve operations for all prospective registrants who fulfill the applicable Nexus Policy.

      (B) All ICANN-required core functionality of .NYC must be in place when general registration begins, including WHOIS, DNS Resolution, standard business rales and billing, and any other core Registry Service

      (C) Neustar shall commence Phase 3 within one (1) year after delegation of the .NYC domain by IANA to Neustar as described in Section 4(d) above.

      (D) All ICANN-required core functionality of .NYC must be in place when general registration begins, including WHOIS, DNS Resolution, standard business rules and billing, and any other core Registry Service.

      (E) Domain names shall be active upon registration during General Registration in accordance with industry standards.

      (F) General Registration shall run through the remainder of the Term and through any renewals of the Term.

      (G) All registrations during Phase 3 shall be conducted on a first-come-first-served basis.

      (iv) Premium Names.

        (i) At no cost to the City, Neustar shall prepare and implement a Premium Name strategy that includes one or more of the following activities conducted during the term of the Agreement, with the objective of optimizing revenues: [Ed: See comment in sidebar.]

      (A) Live or online auctions conducted directly by Neustar or through third party auction service providers selected by Neustar.

      (B) Business development activities that result in the allocation of Premium Names to registrants in exchange for a negotiated payment, or in exchange for use of the Premium Names in a manner that that raises awareness of the .NYC gTLD such as advertising and marketing related activities.

      (ii) Premium Name Auctions may take place either prior to, or after, the launch of General Registration.

      (iii) Unallocated Premium Names may only be released upon mutual agreement of the Parties.

      1. Domain Name Scanning.

        (a) At least once per month, Neustar shall scan all domain names in .NYC to determine whether they contain any of the “Seven Words” (see Appendix H).

        (b) Should Neustar locate any such domain names, Neustar shall take the site offline and prevent the domain from being registered again in the future.

      1. Characters. Neustar will only be required to register and maintain domain names in .NYC in ASCn characters, but may register and maintain domain names in any other Internationalized Domain Name (“IDN”) language and/or script as mutually agreed by Neustar and the City. Should Neustar register and maintain any IDN language and/or script, it shall continue to do so for the length of the Term and through all renewals at no cost to the City.

      1. Transfer Between Registrars. Neustar shall follow ICANN’s Inter-Registrar Transfer Policy (currently located at <http://www.icann.org/en/transfers/policy-en.htm>) for the implementation of all domain transfers.

      8. WHOIS.

      (a) Neustar shall maintain an accurate and up-to-date registration database (a/k/a WHOIS) for all .NYC registrations in accordance with the ICANN Agreement, but in all cases, this database shall be accessible to all .NYC registrants and must allow for multiple string and field searching through a free, public, web-based interface, and consist of the elements required by ICANN, as such elements and requirements may be modified by ICANN from time to time.
      (b) Once .NYC domain names become available through the end of the Term, Neustar shall maintain a website whereby users can perform a WHOIS search for the .NYC gTLD (“WHOIS Website”).

        9. NYC Informational Website. Separate from and in addition to the WHOIS Website, Neustar shall create and maintain a public-facing website with up-to-date policy and registration information for .NYC. The site will be for City residents and businesses to find information regarding .NYC, purchase a .NYC domain name (via a Registrar or Neustar) and find links to Registrar and reseller resources. Neustar shall publish the website in English and the top six non-English languages spoken by City residents, as set forth by Executive Order 120 (dated July 22, 2008) (“E.O. 120”). This website shall, at a minimum, include the following information:

        (a) a description of .NYC;

        (b) the launch process;

        (c) the Benefits of a NYC domain name;

        (d) FAQs, such as “What about my existing domain name?”;

        (e) a listing of URLs for participating Registrars and resellers;

        (f) .NYC gTLD news and press activity;

        (g) the Nexus Policy;

        (h) a statement of the prohibition against the “Seven Words” in domain names;

        (i) reserved name lists (when finalized);

        (j) a list of upcoming domain deletions;

        (k) information for those wishes to become a distribution channel for .NYC;

        (l) information about the Founders Program; [Ed: See comment in sidebar.]

        (m) Neustar contact information including customer service;

        (n) a link to <www.nyc.gov> and, when it comes online, to the WHOIS Website; and

        (o) contact information for complaints related to non-compliance with the Nexus policy.

        10. Domain Name System.

        (a) Neustar shall operate and maintain the primary, authoritative nameserver for .NYC in compliance with the domain name system (“DNS”) protocol specifications defined in the ICANN Agreement and any updates, revisions, modifications to such protocols.

        (b) Neustar shall operate and maintain a global constellation of secondary nameservers for .NYC in compliance with the DNS Protocol Specifications RFCs. The secondary nameservers shall use TSIG, over IPsec VPNs, and AXFR/IXFR to pull zone- provisioning data from the primary nameservers.

        11. Infrastructure

          (a) EPP Templates and Schemas.

            (i) Neustar shall use Extensible Provisioning Protocol (“EPP”) standard version 1.0 in maintaining .NYC.

            (ii) Neustar' shall use the standard schemas and templates found in the IANA repository (currently located at <http://www.iaiia.org/assignments/xml-registrv/schema.html>) and as described in RFCs 5730, 5731, 5732, 5733, 5734, and 4310.

            (iii) Neustar shall use the following schemas:

              (A) EPP 1.0;

              (B) Contact 1.0;

              (C) Domain 1.0;

              (D) Host 1.0;

              (E) and secDNS 1.0.

          (b) Neustar shall comply with the ICANN requirements for performance measurements as set forth in that portion of the ICANN Agreement that corresponds to Specifications 6 and 10 of the ICANN Agreement and any amendments, revisions or modifications.

        12. Security and Stability.

        (a) Neustar shall employ a layered security approach including perimeter security controls on routers, firewalls and virtual local area networks to protect from threats and maintain security for systems and applications.

        (b) Access to the network shall be controlled through access control lists (“ACLs”) and firewalls. Registrars will be granted access only to that section of the Neustar network relevant to the application/service they are authorized to access.

        (c) Online transactions will be communicated from the Registrar to Neustar over a seemed and encrypted SSL/TLS channel using TCP for transport. The transactions will use the EPP protocol as currently defined in RFCs 5730-5734, as they may be amended from time to time.

        (d) Remote diagnostic and configuration ports will be by default disabled on Neustar routers and firewalls. When enabled, all communications will be encrypted and restricted by IP and user authentication.

        (e) Neustar's private networks are segmented and domains will be created based on lines of business and classification of information residing on those networks. Domains will be logically segregated through a combination of firewalls, routers, switches and ACLs.

        (f) Neustar's Shared Registration System (“SRS”), WHOIS, and nameserver infrastructure shall be operated and maintained on a full-time basis by Neustar personnel only.

        (g) Monitoring. Neustar shall monitor all production systems, including firewalls. The following currently represents Neustar’s operating procedures with respect to monitoring. Such process may be amended by Neustar at its sole discretion from time to time; provide that such modifications do not materially adversely impact the performance of Registry Services for .NYC.

        1. Operating system audit logs shall be generated and exported to Neustar log servers, where they will be retained and backed up to tapes. The generated audit logs shall capture relevant details including User ID. time, and location.

        1. Modification to operating system configurations and application code shall be monitored using special applications, which report object property changes including SHA-1, permissions, and size. Change reports are generated periodically and reviewed by appropriate management. Customer transactions will be logged both at the protocol layer (epp) and business rules layer (app) in an audit log. Newer logs are kept online while older logs are put in tape. Neustar currently keeps 1 year ’s worth of logs online, and then archive the logs on tape.

        2. Neustar shall maintain alarms in all facilities for specific log events that are considered high risk, including unauthorized access to facilities and systems. Alarms are subject to 24/7 monitoring by Neustar’s centralized Network Operations Center (“NOC”). Those incidents that lead to significant service impact or security risk are reviewed as part of a monthly meeting of Neustar’s Root-Cause Analysis (“RCA”) team.

        1. To protect against tampering and unauthorized access, system logs will be exported to a central log server, and access to central log server will be restricted to authorized Neustar personnel.

        1. Activity, including login and logout and unsuccessful attempts, will be captured in LDAP logs and syslogs, which will be subject to review by Neustar’s Information Security. Any activity that resulted in modification of critical files and configurations will be captured within monitoring logs, which are formally reviewed and signed off on.

        1. Fault logs are generated and subject to monitoring by the Neustar NOC. Each alert with high seventy is viewed by NOC operators. A trouble ticket is generated for every critical alert, which captures: alert details; NOC troubleshooting procedures and results; additional notifications generated to support groups. A priority/risk classification of all such incidents is applied and determines the action that will be taken to resolve the issue and the level of involvement from various Operations teams. Upon resolution of the incident and confirmation that normal operation has been restored, the tickets are closed.

        1. System clocks are synchronized using Network Time Protocol (NTP) servers. Neustar will utilize Greenwich Mean Time (GMT) as the standard time on production systems to ensure accuracy of audit logs.

        1. All changes affecting production systems will go through a standard change management process for authorization, testing and approval prior to production migration. Additionally, all servers systems have a change-auditing software that detects and exposes unintended changes, circumvention of change management processes, and compromises of security.

        1. Access to quality assurance (“QA”) test environments is limited to members of Neustar’s QA group assigned to the particular application. Test QA environments use production database schema and non-customer data.

          x. Program source libraries shall be protected and version controlled through the use of Neustar’s concurrent versioning system (“CVS”). Access to the CVS server shall be limited to Neustar’s dedicated development group. Code is checked out and checked in through CVS, which keeps detailed version history. The risk of unintentional and/or unauthorized changes to application logic and functionality is further addressed through peer code review and unit testing, QA and user acceptance testing.

        h. SRS and WHOIS System Security.

          (i) The SRS and WHOIS systems will be protected on the front end and the backend by multiple layers of diverse high availability firewalls and boundary devices (switches and routers) that make use of detailed ACLs. The systems themselves are hardened as per best practices for a bastion server. The health of the WHOIS and SRS environment is monitored 7x24x365 by Neustar’s NOC.

          (ii) Boundary devices pass WHOIS traffic to the front-end firewall. The firewall tests the traffic against a set of rules to ensiue that only good traffic gets to the next level of the environment. Traffic approved by the firewall is passed to load balancers that manage the allocation of traffic to the WHOIS server farm. The response to the WHOIS transaction is returned via the reverse of the route.

          (iii) Boundary devices pass SRS traffic to the front-end firewall. The firewall tests the traffic against a set of rules to ensure that only good traffic gets to the next level of the environment. Traffic approved by the firewall is passed to load balancers that manage the allocation of traffic to the SRS application servers. The SRS application servers communicate with a router via the firewall module. The firewall passes APP requests to the APP servers via the Load balancer module. SRS transactions return via the reverse of the path.

        (i) Live Site Tracking/Monitoririg. Neustar shall monitor, graph and report on the health of the overall registry solution.

        (j) DNS/Directory Platform. Due to the distributed nature of the Neustar platform, and the complexities of monitoring an anycast-based solution, Neustar has advanced monitoring and reporting capabilities from numerous (and sufficient) locations around the world which allows Neustar to detect when a particular geographic region around the world has performance delay or packet loss, allowing the Operations staff to quickly diagnose and resolve the issue.

        (k) Mitigating Risk of Denial-of-Seivice and Distributed-Denial-of-Seivice Attacks. Neustar will employ a holistic approach to mitigating such attacks, including the following (which may be amended by Neustar from time to time; provided, that the amended approach will be: (y) of comparable characteristics as the previous version of the approach; and (z) of at least the same level of effectiveness as the previous version):

        1. maintaining massive spare network and host bandwidth at vulnerable perimeter points;

        1. maintaining an extensive, multi-layered monitoring infrastructure utilizing both industry standard 3rd party tools as well as multiple overlapping monitors developed in-house. The monitoring infrastructure is designed to be fault-tolerant (Neustar has no single points of failure in the overall monitoring system), and as with most security systems assumes that any one single layer could be defeated. The monitoring is continually tested by 3rd patties to ensure that we are finding problems before our customers find them;

        1. running regularly scheduled problem simulations (multiple times per month) and keeping educated on the latest threats;

        1. upon identifying an attack and its signature, immediately starting the mitigation process using both 3rd party tools as well as internally developed tools and techniques. When needed, Neustar will also activate carrier based mitigation; and

        v. working with law enforcement and recognized Internet authorities during the mitigation (if necessary) and after the mitigation.

        (I) Minimizing Risk of Unauthorized Physical Access and Registry Data Tampering.

        (i) Neustar shall operate out of highly secure redundant data centers to provide the highest levels of security and service availability. Physical security mechanisms will include all those listed in Neustar’s RFP response (which may be amended by Neustar from time to time; provided, that the amended approach will be: (y) of comparable characteristics as the previous version of the approach; and (z) of at least the same level of effectiveness as the previous version). Neustar’s security team shall monitor access to all locations on a 24/7/365 basis.

        (ii) At all data center locations, employees must present badges to gain entrance, and must wear their badges at all times while in the facility. All visitors must register to gain entrance to any facility. Visitors must display visitor badges at all times while they are in the facility, and must be escorted.

        (m) Procedures for Problem Protection.

        (i) Neustar will monitor the network hosting .NYC on a 24/7/365 basis.

        (ii) If an issue arises, Neustar shall assign it a priority level and respond accordingly. The priority level and responses are currently as follows (which Neustar may amend from time to time; provided, that the amended response approach will be of at least the same level of effectiveness as the previous version):

        (A) PI (Priority 1) - Critical Business Impact—complete loss of service to all or some Registrars, nameserver sites, or WHOIS out of service. Response - Tier 2 (application support) and Tier 3 (engineering support) involved immediately, 24/7 coverage of the issue until resolution, fix applied as emergency patch if necessary.
        (1) An attack on a nameserver is a PI alarm.
        (2) Key actions hi a priority one event include, but may not be limited to:
        (a) opening an internal conference bridge with all relevant on-call personnel from system/network operations and service management;

        (b) sending notification to all necessary Neustar Technical Support, Service Management, & Technical Management personnel;

        (c) opening an internal trouble ticket;

        (d) sending out internal status page every 30 minutes;

        (e) updating internal ticket every 30 minutes;

        (f) maintaining internal ticket & event timeline information;

        (g) engaging vendors as required;

        (h) verifying that service has been restored;

        (i) resolving ticket; and

        (j) providing an event timeline for Neustar’s root-cause analysis team.

          B) P2 - Significant Business Impact - partial outage affecting some Registrars, multiple nameservers, or WHOIS servers, but " size="1">110 sites. Response - Tier 2 support involved immediately, 24/7 coverage of the issue until resolution, workaround solutions evaluated.

          C) P3 - Minimal Business Impact- Issue can be circumvented, service can be used with only slight inconvenience may include 1 or 2 nameservers or WHOIS servers if overall DNS/WHOIS service is fine. Response - Tier 1 (customer support) refers problem to Tier 2, fix applied next maintenance window.

          D) P4 - Little Business Impact - Feature request, documentation enhancement, cosmetic issue. Response - Fix implemented as needed.

                  1. The support tiers are as follows:

                  1. (A) Tier 1: Receives customer inquiries, answers majority of questions, resolves standard issues.

                    (B) Tier 2: Provides infrastructure and application support, resolves necessary escalations from Tier 1.

                    (C) Tier 3: Provides software-troubleshooting support, resolves necessary escalations from Tier 2.

              1. 13. Uniform Domain-Name Dispute-Resolution Policy. Neustar shall comply with the dispute resolution mechanisms set forth in that portion of the ICANN Agreement that corresponds to Specification 7 of the ICANN Agreement and any updates, revisions, modifications or amendments thereto issued by ICANN.

              1. 14. Minimizing Abusive Registrations and Related Activities. Neustar shall take the following actions to combat phishing, bot-nets, malware and other abusive behaviors that leverage the DNS and to curb or eliminate the abuse of the add-grace period, if one is to be implemented for .NYC.
                  1. (a) Neustar shall maintain an internal Information Security group that, 011 its own initiative, seeks out abusive practices in .NYC.

                    (b) At no cost to the City, Neustar shall maintain an active membership in the following DNS abuse and security organizations: Anti-Phishing Working Group, Castle Cops, NSP-SEC, the Registration Infrastructure Safety Group or other groups of comparable utility.

                    (c) Neustar- shall utilize its internal processes (either “lightweight” or “full” process (whichever is appropriate) as described in its RFP Response) to enable it to remove a domain from the zone when its presence in the zone poses a threat to the security and stability of the infrastructure of the Internet or .NYC. Neustar’s internal processes may be amended by Neustar from time to time; provided, that the amended approach will be of at least the same level of effectiveness as the previous version.

            1. 15.Data Escrow.

                  1. (a) Neustar shall enter into a data escrow agreement (in adherence to all applicable ICANN conditions) naming The City of New York and ICANN as additional beneficiaries.

                    (b) Neustar' shall prepare and submit deposits in accordance with all ICANN requirements, including full and incremental deposits as required by ICANN.

                    (c) The data to be held in escrow shall be in the format specified by ICANN.

                    (d) Neustar' shall revise its data escrow format as necessary to remain in full compliance with ICANN requirements as they may be modified from time to time.

              1. 16. IPv6 Connectivity. Neustar shall maintain IPv6 connectivity wherever necessary, including but not limited to:

                  1. (a) allowing entry of IPv6 addresses in all relevant address fields;

                    (b) the SRS supporting the communication of IPv6 addresses; and

                    (c) the ability to have nameservers be provisioned with IPv6 addresses.

              1. 17. System and Network Architecture. Neustar shall leverage its existing platform, including component facilities, equipment, software, hardware, and related technology to support .NYC. Neustar’s network and system architecture, as more frilly described below, may be modified by Neustar from time to time; provided, that the modifications will be of at least the same level of effectiveness as the previous version.

                  1. (a) Neustar' shall maintain the EPP registry mode and architecture via its SRS. SRS is a standards-based, high-performance domain name registration and management system that will exceed the applicable ICANN requirements for .NYC.">

                    (i) Neustar’s SRS shall include at a minimum:

            (A) architecture based upon a proven design;

            (B) fully redundant architecture at two sites;

            1. Support for current and future versions of EPP;

              (D) current inclusion of multiple IDNs that are compliant with all IDN standards;

              (E) current usage of IPv6 name server information

              (F) performance being measured using 100% of all production transactions (not sampling); and

              (G) robust DNS including support for DNSSEC.

              (ii) The SRS database will provide a data thick model and store at least the following data:

            1. domain names;

            1. attributes (status);

            1. contact details (address, phone, email) for all contacts (registrant, administrative, billing, and technical)

            1. authorization information;

            1. sponsoring Registrar;

            1. nameserver information including IP addresses (if applicable);

            1. Registrar contact details;

            1. Registrar URL (home page);

            1. Registrar WHOIS URL (Web Port 80);

            1. Registrar WHOIS URL (Port 43 - if applicable); and

            1. Registrar attributes (status).

              (iii) Access to the SRS database shall be limited to transactions from authenticated Registrars, trusted application-server processes, and highly restricted access by the registry database administrators.

            (A) Neustar will dynamically update the DNS zone file in near real-time in compliance with the ICANN Agreement and other industry standards.

            18. Notifications Concerning the SRS Database.

            1. All operations to the SRS database are processed by an application server, which will return an appropriate response code indicating that the transaction was either successful or unsuccessful.

            1. The primary means by which Neustar shall notify a Registrar of changes to the SRS database is via an EPP response code. Additionally, the contents of the response to an EPP Poll command will notify the Registrar of a pending domain transfer request or the result of a previously submitted domain transfer request.

            1. Some other notification methods that may be used are:

            1. daily transaction reports made available to Registrars provide data on all domain creations, renewals, transfers, deletions and modifications performed by that Registrar; and

            1. billing notices will inform a Registrar when it has reached its low-water mark.

            1. Planned Event Notifications.

            1. Neustar shall maintain a change management process to manage changes in all production environments, both primary and backup sites, production-equivalent test environments, hardware and software for new products or services, and IT infrastructure.

            1. Neustar shall implement change management best practices to include:

            1. providing one central repository for technical operations work;

            1. creating an audit trail to track all Operational technical activities;

            1. facilitating preparation and planning for technical operations activities;

            1. providing timely communications with both our internal and external customers; and.

            1. improving service quality to both internal users and external customers.

            1. Notices of Planned Maintenance.

            1. Neustar shall provide written notice to the City of New York at least 7 days in advance of all planned maintenances that operationally impact any of the core seivices of the registry, including the SRS, WHOIS, and DNS

            1. Neustar shall provide written notice to all Registrars at least 7 days in advance of all planned maintenances that operational impact any of the core seivices of the registry, including the SRS, WHOIS, and DNS.

            21. Marketing .NYC.

            (a) Neustar shall execute a descriptive plan of action for marketing activities related to this Agreement for each Calendar Year as defined in Section 10 of the Agreement (each an “Annual Marketing Plan”). The Annual Marketing Plan for each Calendar Year will be mutually agreed to by the parties in writing within a reasonable period of time prior to the start of each Calendar Year. Such Annual Marketing Plan may be amended by Neustar provided that:

            (i) any material change to the Annual Marketing Plan; and/or

            (ii) any items or details that are specified in Annual Marketing Plan as requiring the City’s prior approval, shall have the consent of the City, which consent shall not be unreasonably withheld or delayed. Neustar shall conduct the marketing activities as agreed to by the parties. In addition, the parties agree to meet quarterly to discuss the status of the Annual Marketing Plan for future years and any updates or revisions that need to be made. The City shall have final approval of the Annual Marketing Plan(s), which approval shall not be unreasonably withheld or delayed. All marketing activities and materials associated with this Agreement shall be consistent with the approved Annual Marketing Plan(s).

            (b) Neustar shall maintain an informational registry website to provide information to educate prospective Registrars and Registrants about the benefits, procedures and restrictions of .NYC. Neustar shall publish this website in English and the top six non- English languages spoken by City residents, as set forth by E.O. 120; provided, however, that although Neustar is committing to publish the registry website in all of the above languages, the parties understand that the initial information registry website as well as subsequent modifications to the registry website may have to be published in multiple phases and may not be published in all languages simultaneously.

            (c) As between the City and Neustar, the marketing shall be at Neustar’s sole expense (and may not be credited against any payment due from Neustar to the City).

            (d) Pursuant to Section 8 of this Agreement, any new marks, logos, names, designs, websites or marketing materials created pursuant to this Agreement shall be solely owned by the City. The parties shall work together to clear and/or register any such marks. The City shall be responsible for such clearances and/or registrations; however, it is understood and agreed that Neustar will provide the City with reasonable advance notice of any new marks, logos, names and materials prior to their use and assist in the review, clearance and registration process. Neustar shall follow the process set forth by the City and NYC & Company for approvals. The City and/or NYC & Company will keep Neustar informed regarding any such requirements for approvals.

            (e) In addition, as set forth in Section 22 below, Neustar shall submit: (1) quarterly reports to the City relating to its marketing activities; and (2) an annual report to the City demonstrating Neustar’s performance of its obligations under each Annual Marketing Plan, including, but not limited to, the amount of money spent by Neustar on marketing- related activities. For any deliverable that does not have a readily ascertainable value measured in terms of the actual dollars spent by Neustar, the value assigned to such deliverable shall be mutually agreed to by the parties, fairly and equitably taking into account the criteria and all other applicable elements (including, but not limitedto, industry standards and nouns and prior used valuations).

            (f) In addition to any other cost responsibilities of Neustar set forth in this Agreement, it is understood and agreed that Neustar is solely responsible for the costs of any and all activities as set forth in Annual Marketing Plan(s) and any agreed upon amendments or changes thereto.

            (g) Neustar shall be responsible for the payment of any and all commission fees paid to auction providers pursuant to this Agreement for conducting auctions of premium names. The City shall not be responsible for such fees and such fees may not be set off against any monies owed by Neustar to the City.

            (h) The marketing budget for each twelve month period of the Agreement is as set forth below in this Section 21(h). For the purposes of this section, a “Marketing Year” shall be measured from the date of the IANA Notice to Proceed (or anniversary thereof as applicable) until the subsequent anniversary of the Notice to Proceed.

              (i) Marketing Year 1 - $312,500

              (ii) Marketing Year 2 - $312,500

              (iii) Marketing Year 3 - $125,000

              (iv) Marketing Year 4 - $125,000

              (v) Marketing Year 5 - $125,000

            Notwithstanding the aforementioned in this Section 21(h), marketing funds expended pursuant to the initial Annual Marketing Plan prior to Marketing Year 1 shall be applied toward the Marketing Year 1 commitment.

            22. Reports

            (a) Neustar shall provide the following reports to Registrars at no cost:

            1. Daily Transaction Report (XML format);

            1. Weekly Escrow Report (XML format);

            1. Daily Transaction Report - (text format) (this report shall contain registry transactions);

            1. Weekly Auction Report containing any registry transactions as a result of auctions (if any);

            1. Daily Billable Transaction Report;

            1. Daily Transfer Report – Gaming;

            1. Daily Transfer Report – Losing;

            1. Daily Auto-renewals Report;

            1. Weekly Nameserver Report; and

            1. Daily Expiring Domains Report.

                (b) Neustar shall provide the following reports to DoITT at no cost:

              1. Monthly ICANN Performance and Transaction Report which shall contain all of the elements required by ICANN in the ICANN Agreement;

              1. Monthly Revenue Transaction Report which shall contain a detailed breakdown of all registry transactions, including the fees per such transaction;

              1. Weekly Sales Activity Report which shall contain a breakdown of registry transactions processed during the preceding week;

              1. Quarterly Reports to City of New York describing developments, policies and changes implemented in the NYC TLD during the previous quarter;

              1. Quarterly and Annual Billing Statement Summary which provides a summary of the total transaction fees collected during the quarter and/or year, including the fees to be paid to the City, and variance between forty percent (40%) of gross annual revenues and minimum fees to be received no later than fifteen (15) days after the end of a quarter or thirty (30) days after the end of a Calendar Year (as used in Section 10 of the main body of this Agreement);

              1. Quarterly and Annual Billing Statement Detail which provides the detailed transactions to support the Quarterly/Annual Billing Statement Summary, and variance between forty percent (40%) of gross annual revenues and minimum fees to be received no later than fifteen (15) days after the end of a quarter or thirty (30) days after the end of a Calendar Year;

              1. Quarterly Marketing Report which shall contain a description of the marketing activities conducted during the previous quarter, associated results, and plans for the upcoming quarter;

              1. Annual Marketing Report as set forth in Section 21(e) above; and

              1. upon request by the City, but no more often than quarterly, the WHOIS information of all registrants of .NYC.

              23. Registry Continuity.

              1. Should this Agreement be terminated and/or not be renewed and/or Neustar become unable to fulfill its obligations under this Agreement, the City may require Neustar to transfer .NYC to another entity to operate, administer, manage, maintain and market .NYC.

              1. Neustar shall then comply with ICANN’s gTLD Registry Continuity Plan, i.e. that portion of the ICANN Agreement that corresponds to Specification 6 of [a current ICANN Agreement],

              1. Neustar shall also provide the following elements as part of the transition plan at its then- current professional services rates:

                1. providing feedback to the successor contractor and feedback to the City regarding the viability and quality of the successor contractor’s transition plan and suggestions on improving the same;

                1. assigning a project manager to interface with successor contractor;

                1. providing periodic, current copies of escrowed data to allow successor contractor to test conversion/import programs;

                1. participating in transition status meetings;

                1. providing required contact information for various entities (e.g., Registrars);

                1. providing a detailed plan to sustain DNS resolution during successor’s DNS ramp-up period;

                1. providing a plan to transition Registrar debit accounts to Neustar’s successor;

                1. providing a communications plan for keeping the community apprised of our transition activities;

                1. providing a plan for Neustar to resume services should the transition not be successful and permitted by this Agreement; and risk analysis.

                d. This Section shall survive termination or expiration of this Agreement.

                [END OF APPENDIX C]


                Key .nyc Pages