Amendment to dot-ORG Registry Agreement

 

The Internet Corporation for Assigned Names and Numbers and Public Interest Registry agree, effective as of                                                                     (“Amendment Effective Date”), that the modification set forth below is now made to the 22 August 2013 .ORG Registry Agreement (“Agreement”).

 

I.        Section 3.4 of the Agreement

Modified to correctly reflect that the Code of Conduct is designated as Appendix 11 to the Agreement (rather than Appendix 12, as currently stated).

II.        Section 3.1.1 of Appendix 7

The provision for “Excess Deletes” shall be deleted in its entirety and restated as follows:

[Old Text]

An Excess Deletion Fee will be charged pursuant to Appendix 8, Exhibit A of the Registry Agreement when the number of deleted registrations within the five- day add grace period is in excess of ninety percent (90%) of the total number of initial registrations made by the registrar over a relevant time period as determined by PIR.

[New Text]

An Excess Deletion Fee will be charged pursuant to Appendix 8, Exhibit A of the Registry Agreement when the number of deleted registrations within the five- day add grace period is in excess of (i) ninety percent (90%) of the total number of initial registrations made by the registrar, or (ii) fifty (50) domain names, whichever is greater, during any one calendar month period.

III.        Exhibit A to Appendix 8

a.               In Section 1 and Section 2, the Initial Registration Fee and Domain Name Renewal Fee, respectively, shall be US$8.25 (rather than US$6.00, as currently stated).

b.              Section 6 shall be deleted in its entirety and replaced as follows:

[Old Text]

Excess Deletion Fee. PIR may charge registrars a fee (the "Excess Deletion Fee") for each Registered Name deleted within the five day add grace period (as specified in Appendix 7, Section 3.1.1 of the Registry Agreement, "Grace Period Deletes") in the event Grace Period Deletes with respect to the relevant time period as determined by PIR are in excess of ninety percent (90%) of the total number of initial registrations made by the registrar over that time period. The time period shall be one calendar month. The Excess Deletion Fee shall be US$.05 (five cents) per Grace Period Delete.


[New Text]

Excess Deletion Fee. PIR may charge registrars a fee (the "Excess Deletion Fee") for each Registered Name deleted within the five day add grace period (as specified in Appendix 7, Section 3.1.1 of the Registry Agreement, "Grace Period Deletes") in the event Grace Period Deletes with respect to any one calendar month are in excess of (i) ninety percent (90%) of the total number of initial registrations made by the registrar or (ii) fifty (50) domain names, whichever is greater, over that time period. The Excess Deletion Fee shall be US$.05 (five cents) per Grace Period Delete.”

IV.        Appendix 10 of the Agreement, Service Level Agreement (SLA), shall be deleted in its entirety and replaced with Appendix 10 in the form as attached hereto this Amendment.

V.        The Registry Operator Code of Conduct, attached hereto this Amendment, shall be incorporated therein the Agreement as a new Appendix 11.

The parties agree that, except as set forth in this Amendment, the terms of the Agreement will remain in full force and effect. All capitalized terms not defined will have the meaning given to them in the Agreement.

AGREED:

 

INTERNET CORPORATION FOR ASSIGNED NAMES AND NUMBERS

 

By:                                                  
Akram Atallah

President, Global Domains Division

 

 

PUBLIC INTEREST REGISTRY

 

By:                                                  
Elizabeth S. Finberg
General Counsel


APPENDIX 10

 

REGISTRY PERFORMANCE SPECIFICATIONS

 

 

Definitions

 

1.1.            DNS. Refers to the Domain Name System as specified in RFCs 1034, 1035, and related RFCs.

 

1.2.            DNSSEC proper resolution. There is a valid DNSSEC chain of trust from the root trust anchor to a particular domain name, e.g., a TLD, a domain name registered under a TLD, etc.

 

1.3.            EPP. Refers to the Extensible Provisioning Protocol as specified in RFC 5730 and related RFCs.

 

1.4.            IP address. Refers to IPv4 or IPv6 addresses without making any distinction between the two.  When there is need to make a distinction, IPv4 or IPv6 is used.

 

1.5.            Probes. Network hosts used to perform (DNS, EPP, etc.) tests (see below) that are located at various global locations.

 

1.6.            RDDS. Registration Data Directory Services refers to the collective of WHOIS and Web-based WHOIS services.

 

1.7.            RTT. Round-Trip Time or RTT refers to the time measured from the sending of the first bit of the first packet of the sequence of packets needed to make a request until the reception of the last bit of the last packet of the sequence needed to receive the response. If the client does not receive the whole sequence of packets needed to consider the response as received, the request will be considered unanswered.

 

1.8.            SLR. Service Level Requirement is the level of service expected for a certain parameter being measured in a Service Level Agreement (SLA).

 

2.                 Service Level Agreement Matrix

 

 

Parameter

SLR (monthly basis)

DNS

DNS service availability

0 min downtime = 100% availability

 

DNS name server availability

£ 432 min of downtime (» 99%)

 

TCP DNS resolution RTT

£ 1500 ms, for at least 95% of the queries

 

UDP DNS resolution RTT

£ 500 ms, for at least 95% of the queries

 

DNS update time

£ 60 min, for at least 95% of the probes

RDDS

RDDS availability

£ 864 min of downtime (» 98%)

 

RDDS query RTT

£ 2000 ms, for at least 95% of the queries

 

RDDS update time

£ 60 min, for at least 95% of the probes


EPP

EPP service availability

£ 864 min of downtime (» 98%)

 

EPP session-command RTT

£ 4000 ms, for at least 90% of the commands

 

EPP query-command RTT

£ 2000 ms, for at least 90% of the commands

 

EPP transform-command RTT

£ 4000 ms, for at least 90% of the commands

 

Registry Operator is encouraged to do maintenance for the different services at the times and dates of statistically lower traffic for each service. However, note that there is no provision for planned outages or similar; any downtime, be it for maintenance or due to system failures, will be noted simply as downtime and counted for SLA purposes.

 

3.                 DNS

 

3.1.             DNS service availability. Refers to the ability of the group of listed-as- authoritative name servers of a particular domain name (e.g., a TLD), to answer DNS queries from DNS probes. For the service to be considered available at a particular moment, at least, two of the delegated name servers registered in the DNS must have successful results from “DNS tests” to each of their public-DNS registered “IP addresses” to which the name server resolves. If 51% or more of the DNS testing probes see the service as unavailable during a given time, the DNS service will be considered unavailable.

 

3.2.             DNS name server availability. Refers to the ability of a public-DNS registered “IP address” of a particular name server listed as authoritative for a domain name, to answer DNS queries from an Internet user.  All the public DNS-registered “IP address” of all name servers of the domain name being monitored shall be tested individually. If 51% or more of the DNS testing probes get undefined/unanswered results from “DNS tests” to a name server “IP address” during a given time, the name server “IP address” will be considered unavailable.

 

3.3.             UDP DNS resolution RTT. Refers to the RTT of the sequence of two packets, the UDP DNS query and the corresponding UDP DNS response. If the RTT is 5 times greater than the time specified in the relevant SLR, the RTT will be considered undefined.

 

3.4.             TCP DNS resolution RTT. Refers to the RTT of the sequence of packets from the start of the TCP connection to its end, including the reception of the DNS response for only one DNS query. If the RTT is 5 times greater than the time specified in the relevant SLR, the RTT will be considered undefined.

 

3.5.             DNS resolution RTT. Refers to either “UDP DNS resolution RTT” or “TCP DNS resolution RTT”.

 

3.6.             DNS update time. Refers to the time measured from the reception of an EPP confirmation to a transform command on a domain name, until the name servers of


the parent domain name answer “DNS queries” with data consistent with the change made.  This only applies for changes to DNS information.

 

3.7.             DNS test. Means one non-recursive DNS query sent to a particular “IP address” (via UDP or TCP). If DNSSEC is offered in the queried DNS zone, for a query to be considered answered, the signatures must be positively verified against a corresponding DS record published in the parent zone or, if the parent is not signed, against a statically configured Trust Anchor.  The answer to the query must contain the corresponding information from the Registry System, otherwise the query will be considered unanswered. A query with a “DNS resolution RTT” 5 times higher than the corresponding SLR, will be considered unanswered. The possible results to a DNS test are: a number in milliseconds corresponding to the “DNS resolution RTT” or, undefined/unanswered.

 

3.8.             Measuring DNS parameters. Every minute, every DNS probe will make an UDP or TCP “DNS test” to each of the public-DNS registered “IP addresses” of the name servers of the domain name being monitored. If a “DNS test” result is undefined/unanswered, the tested IP will be considered unavailable from that probe until it is time to make a new test.

 

3.9.             Collating the results from DNS probes. The minimum number of active testing probes to consider a measurement valid is 20 at any given measurement period, otherwise the measurements will be discarded and will be considered inconclusive; during this situation no fault will be flagged against the SLRs.

 

3.10.         Distribution of UDP and TCP queries. DNS probes will send UDP or TCP “DNS test” approximating the distribution of these queries.

 

3.11.         Placement of DNS probes. Probes for measuring DNS parameters shall be placed as near as possible to the DNS resolvers on the networks with the most users across the different geographic regions; care shall be taken not to deploy probes behind high propagation-delay links, such as satellite links.

 

4.                 RDDS

 

4.1.             RDDS availability. Refers to the ability of all the RDDS services for the TLD, to respond to queries from an Internet user with appropriate data from the relevant Registry System. If 51% or more of the RDDS testing probes see any of the RDDS services as unavailable during a given time, the RDDS will be considered unavailable.

 

4.2.             WHOIS query RTT. Refers to the RTT of the sequence of packets from the start of the TCP connection to its end, including the reception of the WHOIS response. If the RTT is 5-times or more the corresponding SLR, the RTT will be considered undefined.

 

4.3.             Web-based-WHOIS query RTT. Refers to the RTT of the sequence of packets from the start of the TCP connection to its end, including the reception of the HTTP response for only one HTTP request.  If Registry Operator implements a multiple-step


process to get to the information, only the last step shall be measured. If the RTT is 5- times or more the corresponding SLR, the RTT will be considered undefined.

 

4.4.             RDDS query RTT. Refers to the collective of “WHOIS query RTT” and “Web- based- WHOIS query RTT”.

 

4.5.             RDDS update time. Refers to the time measured from the reception of an EPP confirmation to a transform command on a domain name, host or contact, up until the servers of the RDDS services reflect the changes made.

 

4.6.             RDDS test. Means one query sent to a particular “IP address” of one of the servers of one of the RDDS services. Queries shall be about existing objects in the Registry System and the responses must contain the corresponding information otherwise the query will be considered unanswered. Queries with an RTT 5 times higher than the corresponding SLR will be considered as unanswered. The possible results to an RDDS test are: a number in milliseconds corresponding to the RTT or undefined/unanswered.

 

4.7.             Measuring RDDS parameters. Every 5 minutes, RDDS probes will select one IP address from all the public-DNS registered “IP addresses” of the servers for each RDDS service of the TLD being monitored and make an “RDDS test” to each one. If an “RDDS test” result is undefined/unanswered, the corresponding RDDS service will be considered as unavailable from that probe until it is time to make a new test.

 

4.8.             Collating the results from RDDS probes. The minimum number of active testing probes to consider a measurement valid is 10 at any given measurement period, otherwise the measurements will be discarded and will be considered inconclusive; during this situation no fault will be flagged against the SLRs.

 

4.9.             Placement of RDDS probes. Probes for measuring RDDS parameters shall be placed inside the networks with the most users across the different geographic regions; care shall be taken not to deploy probes behind high propagation-delay links, such as satellite links.

 

5.                 EPP

 

5.1.             EPP service availability. Refers to the ability of the TLD EPP servers as a group, to respond to commands from the Registry accredited Registrars, who already have credentials to the servers. The response shall include appropriate data from the Registry System. An EPP command with “EPP command RTT” 5 times higher than the corresponding SLR will be considered as unanswered. If 51% or more of the EPP testing probes see the EPP service as unavailable during a given time, the EPP service will be considered unavailable.

 

5.2.             EPP session-command RTT. Refers to the RTT of the sequence of packets that includes the sending of a session command plus the reception of the EPP response for only one EPP session command. For the login command it will include packets needed for starting the TCP session.  For the logout command it will include


packets needed for closing the TCP session. EPP session commands are those described in section 2.9.1 of EPP RFC 5730. If the RTT is 5 times or more the corresponding SLR, the RTT will be considered undefined.

 

5.3.             EPP query-command RTT. Refers to the RTT of the sequence of packets that includes the sending of a query command plus the reception of the EPP response for only one EPP query command. It does not include packets needed for the start or close of either the EPP or the TCP session. EPP query commands are those described in section 2.9.2 of EPP RFC 5730. If the RTT is 5-times or more the corresponding SLR, the RTT will be considered undefined.

 

5.4.             EPP transform-command RTT. Refers to the RTT of the sequence of packets that includes the sending of a transform command plus the reception of the EPP response for only one EPP transform command. It does not include packets needed for the start or close of either the EPP or the TCP session. EPP transform commands are those described in section 2.9.3 of EPP RFC 5730.  If the RTT is 5 times or more the corresponding SLR, the RTT will be considered undefined.

 

5.5.             EPP command RTT. Refers to “EPP session-command RTT”, “EPP query- command RTT” or “EPP transform-command RTT”.

 

5.6.             EPP test. Means one EPP command sent to a particular “IP address” for one of the EPP servers. Query and transform commands, with the exception of “create”, shall be about existing objects in the Registry System. The response shall include appropriate data from the Registry System. The possible results to an EPP test are: a number in milliseconds corresponding to the “EPP command RTT” or undefined/unanswered.

 

5.7.             Measuring EPP parameters. Every 5 minutes, EPP probes will select one “IP address” of the EPP servers of the TLD being monitored and make an “EPP test”; every time they should alternate between the 3 different types of commands and between the commands inside each category. If an “EPP test” result is undefined/unanswered, the EPP service will be considered as unavailable from that probe until it is time to make a new test.

 

5.8.             Collating the results from EPP probes. The minimum number of active testing probes to consider a measurement valid is 5 at any given measurement period, otherwise the measurements will be discarded and will be considered inconclusive; during this situation no fault will be flagged against the SLRs.

 

5.9.             Placement of EPP probes. Probes for measuring EPP parameters shall be placed inside or close to Registrars points of access to the Internet across the different geographic regions; care shall be taken not to deploy probes behind high propagation- delay links, such as satellite links.

 

6.                 Emergency Thresholds


The following matrix presents the emergency thresholds that, if reached by any of the services mentioned above for the TLD, may (at ICANN’s discretion) cause the emergency transition of the TLD as specified in Section 3.6 of this Agreement.

 

Critical Function

Emergency Threshold

DNS Service (all servers)

4-hour total downtime / week

DNSSEC proper resolution

4-hour total downtime / week

EPP

24-hour total downtime / week

RDDS (WHOIS/Web-

based WHOIS)

24-hour total downtime / week

Data Escrow

Breach of the Registry Agreement caused by data escrow.

 

7.                 Emergency Escalation

 

Escalation is strictly for purposes of notifying and investigating possible or potential issues in relation to monitored services. The initiation of any escalation and the subsequent cooperative investigations do not in themselves imply that a monitored service has failed its performance requirements.

 

Escalations shall be carried out between ICANN and Registry Operators, Registrars and Registry Operator, and Registrars and ICANN. Registry Operators and ICANN must provide said emergency operations departments. Current contacts must be maintained between ICANN and Registry Operators and published to Registrars, where relevant to their role in escalations, prior to any processing of an Emergency Escalation by all related parties, and kept current at all times.

 

7.1.           Emergency Escalation initiated by ICANN

 

Upon reaching 10% of the Emergency thresholds as described in Section 6 of this Appendix, ICANN’s emergency operations will initiate an Emergency Escalation with the relevant Registry Operator. An Emergency Escalation consists of the following minimum elements: electronic (i.e., email or SMS) and/or voice contact notification to the Registry Operator’s emergency operations department with detailed information concerning the issue being escalated, including evidence of monitoring failures, cooperative trouble-shooting of the monitoring failure between ICANN staff and the Registry Operator, and the commitment to begin the process of rectifying issues with either the monitoring service or the service being monitoring.

 

7.2.           Emergency Escalation initiated by Registrars

 

Registry Operator will maintain an emergency operations department prepared to handle emergency requests from registrars. In the event that a registrar is unable to conduct EPP transactions with the registry for the TLD because of a fault with the Registry Service and is unable to either contact (through ICANN mandated methods of communication) the Registry Operator, or the Registry Operator is unable or


unwilling to address the fault, the registrar may initiate an emergency escalation to the emergency operations department of ICANN. ICANN then may initiate an emergency escalation with the Registry Operator as explained above.

 

7.3.           Notifications of Outages and Maintenance

 

In the event that a Registry Operator plans maintenance, they will provide related notice to the ICANN emergency operations department, at least, 24 hours ahead of that maintenance. ICANN’s emergency operations department will note planned maintenance times, and suspend Emergency Escalation services for the monitored services during the expected maintenance outage period.

 

If Registry Operator declares an outage, as per their contractual obligations with ICANN, on services under a service level agreement and performance requirements, it will notify the ICANN emergency operations department.  During that declared outage, ICANN’s emergency operations department will note and suspend emergency escalation services for the monitored services involved.

 

8.                 Covenants of Performance Measurement

 

8.1.             No interference. Registry Operator shall not interfere with measurement Probes, including any form of preferential treatment of the requests for the monitored services. Registry Operator shall respond to the measurement tests described in this Appendix as it would do with any other request from Internet users (for DNS and RDDS) or registrars (for EPP).

 

8.2.             ICANN testing registrar. Registry Operator agrees that ICANN will have a testing registrar used for purposes of measuring the SLRs described above. Registry Operator agrees to not provide any differentiated treatment for the testing registrar other than no billing of the transactions. ICANN shall not use the registrar for registering domain names (or other registry objects) for itself or others, except for the purposes of verifying contractual compliance with the conditions described in this Agreement.


APPENDIX 11

 

REGISTRY OPERATOR CODE OF CONDUCT

 

1.                   In connection with the operation of the registry for the TLD, Registry Operator will not, and will not allow any parent, subsidiary, Affiliate, subcontractor or other related entity, to the extent such party is engaged in the provision of Registry Services with respect to the TLD (each, a “Registry Related Party”), to:

a.                   directly or indirectly show any preference or provide any special consideration to any registrar with respect to operational access to registry systems and related registry services, unless comparable opportunities to qualify for such preferences or considerations are made available to all registrars on substantially similar terms and subject to substantially similar conditions;

b.                   other than as permitted in this Agreement, register domain names in its own right, except for names registered through an ICANN accredited registrar;

c.                   register names in the TLD or sub-domains of the TLD based upon proprietary access to information about searches or resolution requests by consumers for domain names not yet registered (commonly known as, “front-running”); or

d.                   allow any Affiliated registrar to disclose Personal Data about registrants to Registry Operator or any Registry Related Party, except as reasonably necessary for the management and operations of the TLD, unless all unrelated third parties (including other registry operators) are given equivalent access to such user data on substantially similar terms and subject to substantially similar conditions.

2.                   If Registry Operator or a Registry Related Party also operates as a provider of registrar or registrar-reseller services, Registry Operator will, or will cause such Registry Related Party to, ensure that such services are offered through a legal entity separate from Registry Operator, and maintain separate books of accounts with respect to its registrar or registrar-reseller operations.

3.                   If Registry Operator or a Registry Related Party also operates as a provider of registrar or registrar-reseller services, Registry Operator will conduct internal reviews at least once per calendar year to ensure compliance with this Code of Conduct. Within twenty (20) calendar days following the end of each calendar year, Registry Operator will provide the results of the internal review, along with a certification executed by an executive officer of Registry Operator certifying as to Registry Operator’s compliance with this Code of Conduct, via email to an address to be provided by ICANN. (ICANN may specify in the future the form and contents of such reports or that the reports be delivered by other reasonable means.) Registry Operator agrees that ICANN may publicly post such results and certification; provided, however, ICANN (the “receiving party”) shall not disclose any information that is, and the Registry Operator (the “disclosing party”) has marked as, or has


otherwise designated in writing to the receiving party as, “confidential trade secret,” “confidential commercial information” or “confidential financial information” (collectively, “Confidential Information”) contained in such results except in accordance with the following:

a.                   The confidentiality obligations under this paragraph 3 shall not apply to any Confidential Information that (i) is or hereafter becomes part of the public domain by public use, publication, general knowledge or the like through no fault of the receiving party in breach of this Agreement, (ii) can be demonstrated by documentation or other competent proof to have been in the receiving party’s possession prior to disclosure by the disclosing party without any obligation of confidentiality with respect to such information,

(iii) is subsequently received by the receiving party from a third party who is not bound by any obligation of confidentiality with respect to such information, (iv) has been published by a third party or otherwise enters the public domain through no fault of the receiving party, or (v) can be demonstrated by documentation or other competent evidence to have been independently developed by or for the receiving party without reference to the disclosing party’s Confidential Information.

b.                   The receiving party shall have the right to disclose Confidential Information to the extent that such disclosure is (i) made in response to a valid order of a court of competent jurisdiction or, if in the reasonable opinion of the receiving party’s legal counsel, such disclosure is otherwise required by applicable law; provided, however, that the receiving party shall first have given notice to the disclosing party and given the disclosing party a reasonable opportunity to quash such order or to obtain a protective order or confidential treatment order requiring that the Confidential Information that is the subject of such order or other applicable law be held in confidence by such court or other third party recipient, unless the receiving party is not permitted to provide such notice under such order or applicable law, or (ii) made by the receiving party or any of its Affiliates to its or their attorneys, auditors, advisors, consultants, contractors or other third parties for use by such person or entity as may be necessary or useful in connection with the performance of the activities under this Agreement, provided that such third party is bound by confidentiality obligations at least as stringent as those set forth herein, either by written agreement or through professional responsibility standards.

4.                   Nothing set forth herein shall: (i) limit ICANN from conducting investigations of claims of Registry Operator’s non-compliance with this Code of Conduct; or (ii) provide grounds for Registry Operator to refuse to cooperate with ICANN investigations of claims of Registry Operator’s non-compliance with this Code of Conduct.

5.                   Nothing set forth herein shall limit the ability of Registry Operator or any Registry Related Party, to enter into arms-length transactions in the ordinary course of business with a registrar or reseller with respect to products and services unrelated in all respects to the TLD.


6.                   Registry Operator may request an exemption to this Code of Conduct, and such exemption may be granted by ICANN in ICANN’s reasonable discretion, if Registry Operator demonstrates to ICANN’s reasonable satisfaction that (i) all domain name registrations in the TLD are registered to, and maintained by, Registry Operator for the exclusive use of Registry Operator or its Affiliates, (ii) Registry Operator does not sell, distribute or transfer control or use of any registrations in the TLD to any third party that is not an Affiliate of Registry Operator, and (iii) application of this Code of Conduct to the TLD is not necessary to protect the public interest.