Database File The Servicer will provide the Successor Servicer with a magnetic tape (in a format reasonably acceptable to the Indenture Trustee and the Servicer) containing the database file for each Contract (i) as of the Initial Cutoff Date, (ii) the Subsequent Cutoff Date, (iii) thereafter, as of the last day of the preceding Due Period on each Determination Date prior to a Service Transfer and (iv) on and as of the Business Day before the actual commencement of servicing functions by the Successor Servicer following the occurrence of a Service Transfer.
Receivable Files Complete There exists a Receivable File pertaining to each Receivable. Related documentation concerning the Receivable, including any documentation regarding modifications of the Contract, will be maintained electronically by the Servicer in accordance with customary policies and procedures. With respect to any Receivables that are tangible chattel paper, the complete Receivable File for each Receivable currently is in the possession of the Custodian.
Zone File Access Agreement Registry Operator will enter into an agreement with any Internet user, which will allow such user to access an Internet host server or servers designated by Registry Operator and download zone file data. The agreement will be standardized, facilitated and administered by a Centralized Zone Data Access Provider, which may be ICANN or an ICANN designee (the “CZDA Provider”). Registry Operator (optionally through the CZDA Provider) will provide access to zone file data per Section 2.1.3 of this Specification and do so using the file format described in Section 2.1.4 of this Specification. Notwithstanding the foregoing, (a) the CZDA Provider may reject the request for access of any user that does not satisfy the credentialing requirements in Section 2.1.2 below; (b) Registry Operator may reject the request for access of any user that does not provide correct or legitimate credentials under Section 2.1.2 below or where Registry Operator reasonably believes will violate the terms of Section 2.1.5. below; and, (c) Registry Operator may revoke access of any user if Registry Operator has evidence to support that the user has violated the terms of Section 2.1.5 below.
Workstation/Laptop encryption All workstations and laptops that process and/or store DHCS PHI or PI must be encrypted using a FIPS 140-2 certified algorithm which is 128bit or higher, such as Advanced Encryption Standard (AES). The encryption solution must be full disk unless approved by the DHCS Information Security Office.
Separate Grievance File All documents, communications and records dealing with the processing of a grievance shall be filed in a separate grievance file and shall not be kept in the personnel file of any of the participants.
Line Information Database (LIDB 9.1 BellSouth will store in its Line Information Database (LIDB) records relating to service only in the BellSouth region. The LIDB Storage Agreement is included in this Attachment as Exhibit C. 9.2 BellSouth will provide LIDB Storage upon written request to <<customer_name>>’s Account Manager stating a requested activation date.
Originating Switched Access Detail Usage Data A category 1101XX record as defined in the EMI Telcordia Practice BR-010-200- 010.
Line Information Database LIDB is a transaction-oriented database accessible through Common Channel Signaling (CCS) networks. For access to LIDB, ONS must purchase appropriate signaling links pursuant to Section 10 of this Attachment. LIDB contains records associated with End User Line Numbers and Special Billing Numbers. LIDB accepts queries from other Network Elements and provides appropriate responses. The query originator need not be the owner of LIDB data. LIDB queries include functions such as screening billed numbers that provides the ability to accept Collect or Third Number Billing calls and validation of Telephone Line Number based non-proprietary calling cards. The interface for the LIDB functionality is the interface between BellSouth’s CCS network and other CCS networks. LIDB also interfaces to administrative systems.
Inspection Checklist (Check one)
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).