We use cookies on our site to analyze traffic, enhance your experience, and provide you with tailored content.
For more information visit our privacy policy.FORMAT AND CONTENT FOR REGISTRY OPERATOR MONTHLY REPORTING Registry Operator shall provide one set of monthly reports per gTLD, using the API described in draft-‐xxxxxx-‐icann-‐registry-‐interfaces, see Specification 2, Part A, Section 9, reference 5, with the following content. ICANN may request in the future that the reports be delivered by other means and using other formats. ICANN will use reasonable commercial efforts to preserve the confidentiality of the information reported until three (3) months after the end of the month to which the reports relate. Unless set forth in this Specification 3, any reference to a specific time refers to Coordinated Universal Time (UTC). Monthly reports shall consist of data that reflects the state of the registry at the end of the month (UTC).
Registration Data Directory Services Until ICANN requires a different protocol, Registry Operator will operate a WHOIS service available via port 43 in accordance with XXX 0000, and a web-‐based Directory Service at <whois.nic.TLD> providing free public query-‐based access to at least the following elements in the following format. ICANN reserves the right to specify alternative formats and protocols, and upon such specification, the Registry Operator will implement such alternative specification as soon as reasonably practicable. Registry Operator shall implement a new standard supporting access to domain name registration data (SAC 051) no later than one hundred thirty-‐five (135) days after it is requested by ICANN if: 1) the IETF produces a standard (i.e., it is published, at least, as a Proposed Standard RFC as specified in RFC 2026); and 2) its implementation is commercially reasonable in the context of the overall operation of the registry. 1.1. The format of responses shall follow a semi-‐free text format outline below, followed by a blank line and a legal disclaimer specifying the rights of Registry Operator, and of the user querying the database. 1.2. Each data object shall be represented as a set of key/value pairs, with lines beginning with keys, followed by a colon and a space as delimiters, followed by the value. 1.3. For fields where more than one value exists, multiple key/value pairs with the same key shall be allowed (for example to list multiple name servers). The first key/value pair after a blank line should be considered the start of a new record, and should be considered as identifying that record, and is used to group data, such as hostnames and IP addresses, or a domain name and registrant information, together. 1.4. The fields specified below set forth the minimum output requirements. Registry Operator may output data fields in addition to those specified below, subject to approval by ICANN, which approval shall not be unreasonably withheld.
Escrow Format Specification Deposit’s Format. Registry objects, such as domains, contacts, name servers, registrars, etc. will be compiled into a file constructed as described in draft-xxxxx-xxxxxxx-registry-data-escrow, see Part A, Section 9, reference 1 of this Specification and draft-xxxxx-xxxxxxx-dnrd-objects-mapping, see Part A, Section 9, reference 2 of this Specification (collectively, the “DNDE Specification”). The DNDE Specification describes some elements as optional; Registry Operator will include those elements in the Deposits if they are available. If not already an RFC, Registry Operator will use the most recent draft version of the DNDE Specification available at the Effective Date. Registry Operator may at its election use newer versions of the DNDE Specification after the Effective Date. Once the DNDE Specification is published as an RFC, Registry Operator will implement that version of the DNDE Specification, no later than one hundred eighty (180) calendar days after. UTF-8 character encoding will be used.
Registry Functions Activity Report This report shall be compiled in a comma separated-value formatted file as specified in RFC 4180. The file shall be named “gTLD-activity-yyyymm.csv”, where “gTLD” is the gTLD name; in case of an IDN-TLD, the A-label shall be used; “yyyymm” is the year and month being reported. The file shall contain the following fields: 01 operational-registrars number of operational registrars at the end of the reporting period 02 ramp-up-registrars number of registrars that have received a password for access to OT&E at the end of the reporting period 03 pre-ramp-up-registrars number of registrars that have requested access, but have not yet entered the ramp-up period at the end of the reporting period 06 web-whois-queries number of Web-based Whois queries responded during the reporting period, not including searchable Whois 09 dns-udp-queries-responded number of DNS queries received over UDP transport that were responded during the reporting period 10 dns-tcp-queries-received number of DNS queries received over TCP transport during the reporting period 11 dns-tcp-queries-responded number of DNS queries received over TCP transport that were responded during the reporting period 12 srs-dom-check number of SRS (EPP and any other interface) domain name “check” requests responded during the reporting period 13 srs-dom-create number of SRS (EPP and any other interface) domain name “create” requests responded during the reporting period 14 srs-dom-delete number of SRS (EPP and any other interface) domain name “delete” requests responded during the reporting period 15 srs-dom-info number of SRS (EPP and any other interface) domain name “info” requests responded during the reporting period 16 srs-dom-renew number of SRS (EPP and any other interface) domain name “renew” requests responded during the reporting period 17 srs-dom-rgp-restore-report number of SRS (EPP and any other interface) domain name RGP “restore” requests delivering a restore report responded during the reporting period 18 srs-dom-rgp-restore-request number of SRS (EPP and any other interface) domain name RGP “restore” requests responded during the reporting period 19 srs-dom-transfer-approve number of SRS (EPP and any other interface) domain name “transfer” requests to approve transfers responded during the reporting period 20 srs-dom-transfer-cancel number of SRS (EPP and any other interface) domain name “transfer” requests to cancel transfers responded during the reporting period 21 srs-dom-transfer-query number of SRS (EPP and any other interface) domain name “transfer” requests to query about a transfer responded during the reporting period 22 srs-dom-transfer-reject number of SRS (EPP and any other interface) domain name “transfer” requests to reject transfers responded during the reporting period 23 srs-dom-transfer-request number of SRS (EPP and any other interface) domain name “transfer” requests to request transfers responded during the reporting period 24 srs-dom-update number of SRS (EPP and any other interface) domain name “update” requests (not including RGP restore requests) responded during the reporting period 25 srs-host-check number of SRS (EPP and any other interface) host “check” requests responded during the reporting period 26 srs-host-create number of SRS (EPP and any other interface) host “create” requests responded during the reporting period 27 srs-host-delete number of SRS (EPP and any other interface) host “delete” requests responded during the reporting period 28 srs-host-info number of SRS (EPP and any other interface) host “info” requests responded during the reporting period 29 srs-host-update number of SRS (EPP and any other interface) host “update” requests responded during the reporting period 30 srs-cont-check number of SRS (EPP and any other interface) contact “check” requests responded during the reporting period 32 srs-cont-delete number of SRS (EPP and any other interface) contact “delete” requests responded during the reporting period 33 srs-cont-info number of SRS (EPP and any other interface) contact “info” requests responded during the reporting period 34 srs-cont-transfer-approve number of SRS (EPP and any other interface) contact “transfer” requests to approve transfers responded during the reporting period 35 srs-cont-transfer-cancel number of SRS (EPP and any other interface) contact “transfer” requests to cancel transfers responded during the reporting period 36 srs-cont-transfer-query number of SRS (EPP and any other interface) contact “transfer” requests to query about a transfer responded during the reporting period 37 srs-cont-transfer-reject number of SRS (EPP and any other interface) contact “transfer” requests to reject transfers responded during the reporting period 38 srs-cont-transfer-request number of SRS (EPP and any other interface) contact “transfer” requests to request transfers responded during the reporting period 39 srs-cont-update number of SRS (EPP and any other interface) contact “update” requests responded during the reporting period The first line shall include the field names exactly as described in the table above as a “header line” as described in section 2 of RFC 4180. No other lines besides the ones described above shall be included. Line breaks shall be <U+000D, U+000A> as described in RFC 4180. For gTLDs that are part of a single-instance Shared Registry System, the Registry Functions Activity Report may include the total contact or host transactions for all the gTLDs in the system. REGISTRATION DATA PUBLICATION SERVICES
Bulk Registration Data Access to Icann Periodic Access to Thin Registration Data. In order to verify and ensure the operational stability of Registry Services as well as to facilitate compliance checks on accredited registrars, Registry Operator will provide ICANN on a weekly basis (the day to be designated by ICANN) with up-to-date Registration Data as specified below. Data will include data committed as of 00:00:00 UTC on the day previous to the one designated for retrieval by ICANN.
Technical Specifications The Technical Specifications furnished on the CD are intended to establish the standards for quality, performance and technical requirements for all labor, workmanship, material, methods and equipment necessary to complete the Work. When specifications and drawings are provided or referenced by the County, these are to be considered part of the Scope of Work, and to be specifically documented in the Detailed Scope of Work. For convenience, the County supplied specifications, if any, and the Technical Specifications furnished on the CD.
Research Use Reporting To assure adherence to NIH GDS Policy, the PI agrees to provide annual Progress Updates as part of the annual Project Renewal or Project Close-out processes, prior to the expiration of the one (1) year data access period. The PI who is seeking Renewal or Close-out of a project agree to complete the appropriate online forms and provide specific information such as how the data have been used, including publications or presentations that resulted from the use of the requested dataset(s), a summary of any plans for future research use (if the PI is seeking renewal), any violations of the terms of access described within this Agreement and the implemented remediation, and information on any downstream intellectual property generated from the data. The PI also may include general comments regarding suggestions for improving the data access process in general. Information provided in the progress updates helps NIH evaluate program activities and may be considered by the NIH GDS governance committees as part of NIH’s effort to provide ongoing stewardship of data sharing activities subject to the NIH GDS Policy.
Web Site Information on registration for and use of the E-Verify program can be obtained via the Internet at the Department of Homeland Security Web site: xxxx://xxx.xxx.xxx/E-Verify.
DTC DIRECT REGISTRATION SYSTEM AND PROFILE MODIFICATION SYSTEM (a) Notwithstanding the provisions of Section 2.04, the parties acknowledge that the Direct Registration System (“DRS”) and Profile Modification System (“Profile”) shall apply to uncertificated American Depositary Shares upon acceptance thereof to DRS by DTC. DRS is the system administered by DTC pursuant to which the Depositary may register the ownership of uncertificated American Depositary Shares, which ownership shall be evidenced by periodic statements issued by the Depositary to the Owners entitled thereto. Profile is a required feature of DRS which allows a DTC participant, claiming to act on behalf of an Owner of American Depositary Shares, to direct the Depositary to register a transfer of those American Depositary Shares to DTC or its nominee and to deliver those American Depositary Shares to the DTC account of that DTC participant without receipt by the Depositary of prior authorization from the Owner to register such transfer. (b) In connection with and in accordance with the arrangements and procedures relating to DRS/Profile, the parties understand that the Depositary will not verify, determine or otherwise ascertain that the DTC participant which is claiming to be acting on behalf of an Owner in requesting a registration of transfer and delivery as described in subsection (a) has the actual authority to act on behalf of the Owner (notwithstanding any requirements under the Uniform Commercial Code). For the avoidance of doubt, the provisions of Sections 5.03 and 5.08 shall apply to the matters arising from the use of the DRS. The parties agree that the Depositary’s reliance on and compliance with instructions received by the Depositary through the DRS/Profile System and in accordance with this Deposit Agreement shall not constitute negligence or bad faith on the part of the Depositary.
Drug-Free Workplace Certification As required by Executive Order No. 90-5 dated April 12, 1990, issued by the Governor of Indiana, the Company hereby covenants and agrees to make a good faith effort to provide and maintain a drug-free workplace at the Project Location. The Company will give written notice to the IEDC within ten (10) days after receiving actual notice that the Company, or an employee of the Company in the State of Indiana, has been convicted of a criminal drug violation occurring in the workplace. False certification or violation of this certification may result in sanctions including, but not limited to, suspension of payments under the Agreement, termination of the Agreement and/or debarment of contracting opportunities with the State for up to three (3) years. In addition to the provisions of the above paragraph, if the total amount set forth in the Agreement is in excess of $25,000.00, the Company agrees that it will provide a drug-free workplace by: A. Publishing and providing to all of its employees a statement notifying them that the unlawful manufacture, distribution, dispensing, possession or use of a controlled substance is prohibited in the Company’s workplace, and specifying the actions that will be taken against employees for violations of such prohibition;