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).
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
Pricing for Registry Services (a) With respect to initial domain name registrations, Registry Operator shall provide ICANN and each ICANN accredited registrar that has executed the registry-‐registrar agreement for the TLD advance written notice of any price increase (including as a result of the elimination of any refunds, rebates, discounts, product tying or other programs which had the effect of reducing the price charged to registrars, unless such refunds, rebates, discounts, product tying or other programs are of a limited duration that is clearly and conspicuously disclosed to the registrar when offered) of no less than thirty (30) calendar days. Registry Operator shall offer registrars the option to obtain initial domain name registrations for periods of one (1) to ten (10) years at the discretion of the registrar, but no greater than ten (10) years.
(b) With respect to renewal of domain name registrations, Registry Operator shall provide ICANN and each ICANN accredited registrar that has executed the registry-‐registrar agreement for the TLD advance written notice of any price increase (including as a result of the elimination of any refunds, rebates, discounts, product tying, Qualified Marketing Programs or other programs which had the effect of reducing the price charged to registrars) of no less than one hundred eighty (180) calendar days. Notwithstanding the foregoing sentence, with respect to renewal of domain name registrations: (i) Registry Operator need only provide thirty (30) calendar days notice of any price increase if the resulting price is less than or equal to (A) for the period beginning on the Effective Date and ending twelve (12) months following the Effective Date, the initial price charged for registrations in the TLD, or (B) for subsequent periods, a price for which Registry Operator provided a notice pursuant to the first sentence of this Section 2.10(b) within the twelve (12) month period preceding the effective date of the proposed price increase; and (ii) Registry Operator need not provide notice of any price increase for the imposition of the Variable Registry-‐Level Fee set forth in Section 6.3. Registry Operator shall offer registrars the option to obtain domain name registration renewals at the current price (i.e., the price in place prior to any noticed increase) for periods of one (1) to ten (10) years at the discretion of the registrar, but no greater than ten (10) years.
(c) In addition, Registry Operator must have uniform pricing for renewals of domain name registrations (“Renewal Pricing”). For the purposes of determining Renewal Pricing, the price for each domain registration renewal must be identical to the price of all other domain name registration renewals in place at the time of such renewal, and such price must take into account universal application of any refunds, rebates, discounts, product tying or other programs in place at the time of renewal. The foregoing requirements of this Section 2.10(c) shall not apply for (i) purposes of determining Renewal Pricing if the registrar has provided Registry Operator with documentation that demonstrates that the applicable registrant expressly agreed in its registration agreement with registrar to higher Renewal Pricing at the time of the initial registration of the domain name following clear and conspicuous disclosure of such Renewal Pricing to such registrant, and (ii) discounted Renewal Pricing pursuant to a Qualified Marketing Program (as defined below). The parties acknowledge that the purpose of this Section 2.10(c) is to prohibit abusive and/or discriminatory Renewal Pricing practices imposed by Registry Operator without the written consent of the applicable registrant at the time of the initial registration of the domain and this Section 2.10(c) will be interpreted broadly to prohibit such practices. For purposes of this Section 2.10(c), a “Qualified Marketing Program” is a marketing program pursuant to which Registry Operator offers discounted Renewal Pricing, provided that each of the following criteria is satisfied: (i) the program and related discounts are offered for a period of time not to exceed one hundred eighty (180) calendar days (with consecutive substantially similar programs aggregated for purposes of determining the number of calendar days of the program), (ii) all ICANN accredited registrars are provided the same opportunity to qualify for such discounted Renewal Pricing; and (iii) the intent or effect of the program is not to exclude any particular class(es) of registrations (e.g., registrations held by large corporations) or increase the renewal price of any particular class(es) of registrations. Nothing in this Section 2.10(c) shall limit Registry Operator’s obligations pursuant to Section 2.10(b).
(d) Registry Operator shall provide public query-‐based DNS lookup service for the TLD (that is, operate the Registry TLD zone servers) at its sole expense.
AGREED FACTS Registration History 7. Since June 2006, the Respondent has been registered in Ontario as a mutual fund salesperson (now known as a dealing representative)1 with WFG Securities Inc. (the “Member”), a Member of the MFDA.
8. At all material times, the Respondent conducted business in the Vaughan, Ontario area.
9. At all material times, the Member’s policies and procedures prohibited Approved Persons from signing a client’s name to a document.
10. Between January 2018 and September 2018, while the Respondent was an Approved Person of the Member, the Respondent signed the initials of clients on 8 trade tickets next to alterations he made to information on the trade tickets, and submitted them to the Member for processing.
11. The alterations made by the Respondent on the trade tickets included alterations to: trade instructions, client signature dates and special instructions.
12. At all material times, the Member’s policies and procedures prohibited Approved Persons from altering information on a signed document without the client initialing the document to show that the changes were approved.
13. In May 2018, while the Respondent was an Approved Person of the Member, he altered 1 account form in respect of 1 client by altering information on a trade ticket without having the client initial the alterations, and used this altered form to process a transaction. 1 In September 2009, the registration category mutual fund salesperson was changed to “dealing representative” when National Instrument 31-103 came into force.
14. The Respondent altered the trading instructions, special instructions and representative commission percentage on the trade ticket without having the client initial these alterations.
15. At all material times, the Member’s policies and procedures prohibited Approved Persons from holding an account form which was signed by a client and was blank or only partially completed.
16. Between January 2015 and October 2018, while the Respondent was an Approved Person of the Member, he obtained, possessed and used to process transactions, 30 pre-signed account forms in respect of 21 clients.
17. The pre-signed account forms consisted of: 25 Trade Tickets, 3 New Account Application Forms and 2 Non Financial Information Update Forms.
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.
Registry Services “Registry Services” are, for purposes of the Agreement, defined as the following: (a) those services that are operations of the registry critical to the following tasks: the receipt of data from registrars concerning registrations of domain names and name servers; provision to registrars of status information relating to the zone servers for the TLD; dissemination of TLD zone files; operation of the registry DNS servers; and dissemination of contact and other information concerning domain name server registrations in the TLD as required by this Agreement; (b) other products or services that the Registry Operator is required to provide because of the establishment of a Consensus Policy as defined in Specification 1; (c) any other products or services that only a registry operator is capable of providing, by reason of its designation as the registry operator; and (d) material changes to any Registry Service within the scope of (a), (b) or (c) above.
Per-‐Registrar Transactions Report This report shall be compiled in a comma separated-‐value formatted file as specified in RFC 4180. The file shall be named “gTLD-‐transactions-‐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 per registrar: Field # Field name Description 01 registrar-‐name Registrar’s full corporate name as registered with IANA 02 iana-‐id For cases where the registry operator acts as registrar (i.e., without the use of an ICANN accredited registrar) 9999 should be used, otherwise the sponsoring Registrar IANA id should be used as specified in xxxx://xxx.xxxx.xxx/assignments/registrar-‐ids 03 total-‐domains total domain names under sponsorship in any EPP status but pendingCreate that have not been purged 04 total-‐nameservers total name servers (either host objects or name server hosts as domain name attributes) associated with domain names registered for the TLD in any EPP status but pendingCreate that have not been purged 05 net-‐adds-‐1-‐yr number of domains successfully registered (i.e., not in EPP pendingCreate status) with an initial term of one (1) year (and not deleted within the add grace period). A transaction must be reported in the month the add grace period ends.
Registry Operator has (i) ceased to conduct its business in the ordinary course; or (ii) filed for bankruptcy, become insolvent or anything analogous to any of the foregoing under the laws of any jurisdiction anywhere in the world; or
Public Posting of Approved Users’ Research Use Statement The PI agrees that information about themselves and the approved research use will be posted publicly on the dbGaP website. The information includes the PI’s name and Requester, project name, Research Use Statement, and a Non-Technical Summary of the Research Use Statement. In addition, and if applicable, this information may include the Cloud Computing Use Statement and name of the CSP or PCS. Citations of publications resulting from the use of controlled-access datasets obtained through this DAR may also be posted on the dbGaP website.
DRUG ABUSE DETECTION AND DETERRENCE 2.18.1 It is the policy of the City to achieve a drug-free workforce and workplace. The manufacture, distribution, dispensation, possession, sale, or use of illegal drugs or alcohol by contractors while on City Premises is prohibited. Contractor shall comply with all the requirements and procedures set forth in the Mayor’s Drug Abuse Detection and Deterrence Procedures for Contractors, Executive Order No. 1-31 (the “Executive Order”), which is incorporated into this Agreement and is on file in the City Secretary’s Office.
2.18.2 Before the City signs this Agreement, Contractor shall file with the Contract Compliance Officer for Drug Testing (“CCODT”):
2.18.2.1 a copy of its drug-free workplace policy;
2.18.2.2 the Drug Policy Compliance Agreement substantially in the form set forth in Exhibit “C”, together with a written designation of all safety impact positions; and
2.18.2.3 if applicable (e.g., no safety impact positions), the Certification of No Safety Impact Positions, substantially in the form set forth in Exhibit “D”.
2.18.3 If Contractor files a written designation of safety impact positions with its Drug Policy Compliance Agreement, it also shall file every 6 months during the performance of this Agreement or on completion of this Agreement if performance is less than 6 months, a Drug Policy Compliance Declaration in a form substantially similar to Exhibit “E”. Contractor shall submit the Drug Policy Compliance Declaration to the CCODT within 30 days of the expiration of each 6-month period of performance and within 30 days of completion of this Agreement. The first 6- month period begins to run on the date the City issues its Notice to Proceed or, if no Notice to Proceed is issued, on the first day Contractor begins work under this Agreement.
2.18.4 Contractor also shall file updated designations of safety impact positions with the CCODT if additional safety impact positions are added to Contractor’s employee work force.
2.18.5 Contractor shall require that its subcontractors comply with the Executive Order, and Contractor shall secure and maintain the required documents for City inspection.
