Common use of Standards Compliance Clause in Contracts

Standards Compliance. Registry Operator shall implement and comply with relevant existing RFCs and those published in the future by the Internet Engineering Task Force (IETF) including all successor standards, modifications or additions thereto relating to (i) the DNS and name server operations including without limitation RFCs 1034, 1035, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 3901, 4343, 4472, and 5966; and (ii) provisioning and management of domain names using the Extensible Provisioning Protocol (EPP) in conformance with RFCs 3735, 5910, 5730, 5731, 5732, 5733 and 5734. If Registry Operator implements Registry Grace Period (RGP), it will comply with RFC 3915 and its successors. If Registry Operator requires the use of functionality outside the base EPP RFCs, Registry Operator must document EPP extensions in Internet- Draft format following the guidelines described in RFC 3735. Registry Operator will provide and update the relevant documentation of all the EPP Objects and Extensions supported to ICANN prior to deployment. Registry Operator shall sign its TLD zone files implementing Domain Name System Security Extensions (“DNSSEC”). During the Term, Registry Operator shall comply with RFCs 4033, 4034, 4035, 4509 and their successors, and follow the best practices described in RFC 4641 and its successors. If Registry Operator implements Hashed Authenticated Denial of Existence for DNS Security Extensions, it shall comply with RFC 5155 and its successors. Registry Operator shall accept public-key material from child domain names in a secure manner according to industry best practices. Registry shall also publish in its website the DNSSEC Practice Statements (DPS) describing critical security controls and procedures for key material storage, access and usage for its own keys and secure acceptance of registrants’ public-key material. If the Registry Operator offers Internationalized Domain Names (“IDNs”), it shall comply with RFCs 5890, 5891, 5892, 5893 and their successors. Registry Operator shall comply with the ICANN IDN Guidelines at <xxxx://xxx.xxxxx.xxx/en/topics/idn/implementation-guidelines.htm>, as they may be amended, modified, or superseded from time to time. Registry Operator shall publish and keep updated its IDN Tables and IDN Registration Rules in the IANA Repository of IDN Practices as specified in the ICANN IDN Guidelines. Registry Operator shall be able to accept IPv6 addresses as glue records in its Registry System and publish them in the DNS. Registry Operator shall offer public IPv6 transport for, at least, two of the Registry’s name servers listed in the root zone with the corresponding IPv6 addresses registered with IANA. Registry Operator should follow “DNS IPv6 Transport Operational Guidelines” as described in BCP 91. Registry Operator shall offer public IPv6 transport for its Registration Data Publication Services as defined in Specification 4 of this Agreement; e.g. Whois (RFC 3912), Web based Whois. Registry Operator shall offer public IPv6 transport for its Shared Registration System (SRS) to any Registrar, no later than six months after receiving the first request in writing from a gTLD accredited Registrar willing to operate the SRS over IPv6.

Standards Compliance. Registry Operator shall implement and comply with relevant existing RFCs and those published in the future by the Internet Engineering Task Force (IETF) including all successor standards, modifications or additions thereto relating to (i) the DNS and name server operations including without limitation RFCs 1034, 1035, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 3901, 4343, and 4472, and 5966; and (ii) provisioning and management of domain names using the Extensible Provisioning Protocol (EPP) in conformance with RFCs 3735, 5910, 3915, 5730, 5731, 5732, 5733 and 5734. If Registry Operator implements Registry Grace Period (RGP), it will comply with RFC 3915 and its successors. If Registry Operator requires the use of functionality outside the base EPP RFCs, Registry Operator must document EPP extensions in Internet- Internet-Draft format following the guidelines described in RFC 3735. Registry Operator will provide and update the relevant documentation of all the EPP Objects and Extensions supported to ICANN prior to deployment. Registry Operator shall sign implementsign its TLD zone files implementing Domain Name System Security Extensions (“DNSSEC”). During the Term, Registry Operator shall comply with RFCs 4033, 4034, 4035, 4509 and 4310 and their successors, and follow the best practices described in RFC 4641 and its successors. If Registry Operator implements Hashed Authenticated Denial of Existence for DNS Security Extensions, it shall comply with RFC 5155 and its successors. Registry Operator shall accept public-key material from child domain names in a secure manner according to industry best practices. Registry shall also publish in its website the practice and policy document (also known as the DNSSEC Policy Statement orDNSSEC Practice Statements (DPS) describing critical security controls and procedures for key material storage, access and usage for its own keys and secure thesecure acceptance of registrants’ publictrust anchorpublic-key material. If the Registry Operator offers Internationalized Domain Names (“IDNs”), it shall comply with RFCs 58903490, 58913491, 5892, 5893 and 3492 and their successors. Registry Operator shall comply with successors and the ICANN IDN Guidelines at <xxxx://xxx.xxxxx.xxx/en/topics/idn/implementation-guidelines.htm>, as they may be amended, modified, or superseded from time to time. Registry Operator shall publish and keep updated its IDN Tables and IDN Registration Rules in the IANA Repository of IDN Practices as specified in the ICANN IDN Guidelines. Registry Operator shall be able to accept IPv6 addresses as glue records in its Registry System and publish them in the DNS. Registry Operator shall offer public IPv6 transport for, at least, two of the Registry’s name servers listed in the root zone with the corresponding IPv6 addresses registered with IANA. Registry Operator should follow “DNS IPv6 Transport Operational Guidelines” as described in BCP 91. Registry Operator shall offer public IPv6 transport for its Registration Data Publication Services as defined in Specification 4 of this Agreement; e.g. Whois (RFC 3912), Web based Whois. Registry Operator shall offer public IPv6 transport for its Shared Registration System (SRS) to any Registrar, no later than six months after receiving the first request in writing from a gTLD accredited Registrar willing to operate the SRS over IPv6.

Standards Compliance. Registry Operator shall implement and comply with relevant existing RFCs and those published in the future by the Internet Engineering Task Force (IETF) including all successor standards, modifications or additions thereto relating to (i) the DNS and name server operations including without limitation RFCs 1034, 1035, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 3901, 4343, and 4472, and 5966; and (ii) provisioning and management of domain names using the Extensible Provisioning Protocol (EPP) in conformance with RFCs 3735, 5910, 3915, 5730, 5731, 5732, 5733 and 5734. If Registry Operator implements Registry Grace Period (RGP), it will comply with RFC 3915 and its successors. If Registry Operator requires the use of functionality outside the base EPP RFCs, Registry Operator must document EPP extensions in Internet- Internet-Draft format following the guidelines described in RFC 3735. Registry Operator will provide and update the relevant documentation of all the EPP Objects and Extensions supported to ICANN prior to deployment. Registry Operator shall sign its TLD zone files implementing Domain Name System Security Extensions (“DNSSEC”). During the Term, Registry Operator shall comply with RFCs 4033, 4034, 4035, 4509 and their successors, and follow the best practices described in RFC 4641 and its successors. If Registry Operator implements Hashed Authenticated Denial of Existence for DNS Security Extensions, it shall comply with RFC 5155 and its successors. Registry Operator shall accept public-key material from child domain names in a secure manner according to industry best practices. Registry shall also publish in its website the DNSSEC Practice Statements (DPS) describing critical security controls and procedures for key material storage, access and usage for its own keys and secure acceptance of registrants’ public-key material. If the Registry Operator offers Internationalized Domain Names (“IDNs”), it shall comply with RFCs 589034905890, 589134915891, 5892and 34925892, 5893 and their successorssuccessors and. Registry Operator shall comply with the ICANN IDN Guidelines at <xxxx://xxx.xxxxx.xxx/en/topics/idn/implementation-guidelines.htm>, as they may be amended, modified, or superseded from time to time. Registry Operator shall publish and keep updated its IDN Tables and IDN Registration Rules in the IANA Repository of IDN Practices as specified in the ICANN IDN Guidelines. Registry Operator shall be able to accept IPv6 addresses as glue records in its Registry System and publish them in the DNS. Registry Operator shall offer public IPv6 transport for, at least, two of the Registry’s name servers listed in the root zone with the corresponding IPv6 addresses registered with IANA. Registry Operator should follow “DNS IPv6 Transport Operational Guidelines” as described in BCP 91. Registry Operator shall offer public IPv6 transport for its Registration Data Publication Services as defined in Specification 4 of this Agreement; e.g. Whois (RFC 3912), Web based Whois. Registry Operator shall offer public IPv6 transport for its Shared Registration System (SRS) to any Registrar, no later than six months after receiving the first request in writing from a gTLD TLDgTLD accredited Registrar willing to operate the SRS over IPv6.

Standards Compliance. Registry Operator shall implement and comply with relevant existing RFCs and those published in the future by the Internet Engineering Task Force (IETF) including all successor standards, modifications or additions thereto relating to (i) the DNS and name server operations including without limitation RFCs 1034, 1035, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 3901, 4343, and 4472, and 5966; and (ii) provisioning and management of domain names using the Extensible Provisioning Protocol (EPP) in conformance with RFCs 3735, 59103915, 5730, 5731, 5732, 5733 and 5734. If Registry Operator implements Registry Grace Period (RGP), it will comply with RFC 3915 and its successors. If Registry Operator requires the use of functionality outside the base EPP RFCs, Registry Operator must document EPP extensions in Internet- Draft format following the guidelines described in RFC 3735. Registry Operator will provide and update the relevant documentation of all the EPP Objects and Extensions supported to ICANN prior to deployment. Registry Operator shall sign its TLD zone files implementing implement Domain Name System Security Extensions (“DNSSEC”). During the Term, Registry Operator shall comply with RFCs 4033, 4034, 4035, 4509 and 4310 and their successors, and follow the best practices described in RFC 4641 and its successors. If Registry Operator implements Hashed Authenticated Denial of Existence for DNS Security Extensions, it shall comply with RFC 5155 and its successors. Registry Operator shall accept public-key material from child domain names in a secure manner according to industry best practices. Registry shall also publish in its website the practice and policy document (also known as the DNSSEC Practice Statements (Policy Statement or DPS) describing critical security controls and procedures for key material storage, access and usage for its own keys and secure acceptance of the registrants’ public-key trust anchor material. If the Registry Operator offers Internationalized Domain Names (“IDNs”), it shall comply with RFCs 58903490, 58913491, 5892, 5893 and 3492 and their successors. Registry Operator shall comply with successors and the ICANN IDN Guidelines at <xxxx://xxx.xxxxx.xxx/en/topics/idn/implementation-guidelines.htm>, as they may be amended, modified, or superseded from time to time. Registry Operator shall publish and keep updated its IDN Tables and IDN Registration Rules in the IANA Repository of IDN Practices as specified in the ICANN IDN Guidelines. Registry Operator shall be able to accept IPv6 addresses as glue records in its Registry System and publish them in the DNS. Registry Operator shall offer public IPv6 transport for, at least, two of the Registry’s name servers listed in the root zone with the corresponding IPv6 addresses registered with IANA. Registry Operator should follow “DNS IPv6 Transport Operational Guidelines” as described in BCP 91. Registry Operator shall offer public IPv6 transport for its Registration Data Publication Services as defined in Specification 4 of this Agreement; e.g. Whois (RFC 3912), Web based Whois. Registry Operator shall offer public IPv6 transport for its Shared Registration System (SRS) to any Registrar, no later than six months after receiving the first request in writing from a gTLD accredited Registrar willing to operate the SRS over IPv6.

Standards Compliance. Registry Operator shall implement and comply with relevant existing RFCs and those published in the future by the Internet Engineering Task Force (IETF) including all successor standards, modifications or additions thereto relating to (i) Internet protocol (including Extensible Provisioning Protocol), the DNS and name nameservername server operations including without limitation RFCs 103437351034, 10353915, and 4390-43941035, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 3901, 4343, and 4472, and 5966; and (ii) provisioning registration data publication operations for top-level domain registriesprovisioning and management of domain names using the Extensible Provisioning Protocol (EPP) in conformance with RFCs 373510333735, 591010343915, 573010355730, 5731, 5732, 5733 and 573421825734. If Registry Operator implements Registry Grace Period (RGP), it will comply with RFC 3915 and its successors. If Registry Operator requires the use of functionality outside the base EPP RFCs, Registry Operator must document EPP extensions in Internet- Draft format following the guidelines described in RFC 3735. Registry Operator will provide and update the relevant documentation of all the EPP Objects and Extensions supported to ICANN prior to deployment. Registry Operator shall sign its TLD zone files implementing implementsshall implement Domain Name System Security Extensions (“DNSSEC”), it. During the Term, Registry Operator shall comply with RFCs 4033, 4034, and 4035, 4509 and 4310 and their successors;, and should follow the best practices described in RFC 4641 and its successors. If Registry Operator implements Hashed Authenticated Denial of Existence for DNS Security Extensions, it shall comply with RFC 5155 and its successors. Registry Operator shall accept public-key material from child domain names in a secure manner according to industry best practices. Registry shall also publish in its website the practice and policy document (also known as the DNSSEC Practice Statements (Policy Statement or DPS) describing critical security controls and procedures for key material storage, access and usage for its own keys and secure acceptance of the registrants’ public-key trust anchor material. If the Registry Operator offers Internationalized Domain Names (“IDNs”), it shall comply with RFCs 58903490, 58913491, 5892, 5893 and 3492 and their successors. Registry Operator shall comply with successors and the ICANN IDN Guidelines at <xxxx://xxx.xxxxx.xxx/en/topics/idn/implementation-guidelines.htm>, as they may be amended, modified, or superseded from time to time. Registry Operator shall publish and keep updated its IDN Tables and IDN Registration Rules in the IANA Repository of IDN Practices as specified in the ICANN IDN Guidelines. Registry Operator shall be able to accept IPv6 addresses as glue records in its Registry System and publish them in the DNS. Registry Operator shall offer public IPv6 transport for, at least, two of the Registry’s name servers listed in the root zone with the corresponding IPv6 addresses registered with IANA. Registry Operator should follow “DNS IPv6 Transport Operational Guidelines” as described in BCP 91. Registry Operator shall offer public IPv6 transport for its Registration Data Publication Services as defined in Specification 4 of this Agreement; e.g. Whois (RFC 3912), Web based Whois. Registry Operator shall offer public IPv6 transport for its Shared Registration System (SRS) to any Registrar, no later than six months after receiving the first request in writing from a gTLD accredited Registrar willing to operate the SRS over IPv6.

Standards Compliance. Registry Operator shall implement and comply with relevant existing RFCs and those published in the future by the Internet Engineering Task Force (IETF) including all successor standards, modifications or additions thereto relating to (i) the DNS and name server operations including without limitation RFCs 1034, 1035, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 3901, 4343, and 4472, and 5966; and (ii) provisioning and management of domain names using the Extensible Provisioning Protocol (EPP) in conformance with RFCs 3735, 5910, 3915, 5730, 5731, 5732, 5733 and 5734. If Registry Operator implements Registry Grace Period (RGP), it will comply with RFC 3915 and its successors. If Registry Operator requires the use of functionality outside the base EPP RFCs, Registry Operator must document EPP extensions in Internet- Draft format following the guidelines described in RFC 3735. Registry Operator will provide and update the relevant documentation of all the EPP Objects and Extensions supported to ICANN prior to deployment. Registry Operator shall sign its TLD zone files implementing Domain Name System Security Extensions (“DNSSEC”). During the Term, Registry Operator shall comply with RFCs 4033, 4034, 4035, 4509 and their successors, and follow the best practices described in RFC 4641 and its successors. If Registry Operator implements Hashed Authenticated Denial of Existence for DNS Security Extensions, it shall comply with RFC 5155 and its successors. Registry Operator shall accept public-key material from child domain names in a secure manner according to industry best practices. Registry shall also publish in its website the DNSSEC Practice Statements (DPS) describing critical security controls and procedures for key material storage, access and usage for its own keys and secure acceptance of registrants’ public-key material. If the Registry Operator offers Internationalized Domain Names (“IDNs”), it shall comply with RFCs 58903490, 58913491, 5892, 5893 and 3492 and their successors. Registry Operator shall comply with successors and the ICANN IDN Guidelines at <xxxx://xxx.xxxxx.xxx/en/topics/idn/implementation-guidelines.htm>, as they may be amended, modified, or superseded from time to time. Registry Operator shall publish and keep updated its IDN Tables and IDN Registration Rules in the IANA Repository of IDN Practices as specified in the ICANN IDN Guidelines. Registry Operator shall be able to accept IPv6 addresses as glue records in its Registry System and publish them in the DNS. Registry Operator shall offer public IPv6 transport for, at least, two of the Registry’s name servers listed in the root zone with the corresponding IPv6 addresses registered with IANA. Registry Operator should follow “DNS IPv6 Transport Operational Guidelines” as described in BCP 91. Registry Operator shall offer public IPv6 transport for its Registration Data Publication Services as defined in Specification 4 of this Agreement; e.g. Whois (RFC 3912), Web based Whois. Registry Operator shall offer public IPv6 transport for its Shared Registration System (SRS) to any Registrar, no later than six months after receiving the first request in writing from a gTLD TLD accredited Registrar willing to operate the SRS over IPv6.