STIPULATION AND ORDER REGARDING DISCOVERY
ALLISON CLAIRE, Magistrate Judge.
This Stipulation and Proposed Order Regarding Discovery of Electronically Stored Information shall be the governing document by which the parties and the Court manage the production of documents and data, including electronically stored information ("ESI") in this action, although nothing in this Order is intended to be an exhaustive list of the rights or obligations of any party or non-party producing or receiving documents or data, including ESI, pursuant to this Order. This Stipulation and Proposed Order shall govern all parties to these proceedings, whether they are currently involved or become involved in the future, and all parties shall be under an obligation to take reasonable steps to comply herewith. The parties and the Court recognize that this Stipulation and Proposed Order is based on facts and circumstances as they are currently known to each party, that the discovery process is iterative, and that additions and modifications to this Stipulation and Proposed Order may become necessary as more information becomes known to the parties. Nothing in this Stipulation and Proposed Order will be interpreted to require disclosure of documents or information protected from disclosure by the attorney-client privilege, work-product doctrine or any other applicable privilege or immunity. All parties preserve such privileges and there is no intent through either this Stipulation and Proposed Order or the production of documents or information hereunder to waive or weaken such privileges.
I. DEFINITIONS
A. "Document" or "documents" is defined to be synonymous in meaning and equal in scope to the usage of that term in Federal Rule of Civil Procedure 34.
B. "Email" (Electronic mail) means an electronic means for sending, receiving, and managing communications via a multitude of different structured data applications (email client software), including, but not limited to, Outlook, Lotus Notes, or those often known as "webmail," including Google Gmail or Yahoo mail.
C. "ESI" is an abbreviation of "electronically stored information" and is defined to be synonymous in meaning and equal in scope to the usage of that term in Federal Rule of Civil Procedure 34.
D. "Extracted Text" means the text extracted from a Native Format file and includes all header, footer and document body information.
E. "Load file" means an electronic file containing information identifying a set of paper-scanned images or processed ESI and indicating where individual pages or files belong together as documents, including attachments, and where each document begins and ends. A Load file may also contain data relevant to the individual Documents, including user or software created Metadata.
F. "Metadata" means structured information regarding an information resource that describes, explains, locates, or otherwise makes it easier to retrieve, use, or manage that information resource.
G. "Native Format" means the format of ESI in the application in which such ESI was originally created.
H. "OCR" means the optical character recognition file which is created by software used in conjunction with a scanner that is capable of reading text-based documents and making such documents searchable using appropriate software.
I. "Tagged Image File Format" or "TIFF" refers to the CCITT Group IV graphic file format for storing bit-mapped images, with multiple compression formats and resolutions.
II. GENERAL PROVISIONS
A. The parties will prepare their production documents in accordance with the agreed-upon specifications set forth below, but will not process them through a common vendor.
B. The default assumption under this protocol is that until the resolution of this action, each party will agree to bear its own reasonable costs in producing documents in conformity with this agreement. Each party reserves the right to request cost-shifting for documents it has been requested to produce in appropriate circumstances (and all parties reserve the right to oppose any such request on any applicable grounds). Nothing herein constitutes an acknowledgement (implicit or otherwise) by any party that ESI-related costs are allowed or not allowed after the resolution of this action under Federal Rule of Civil Procedure 54, or otherwise.
C. To the extent a party is unable to produce ESI in the manner or format required by this agreement, it shall alert the other party, and the parties shall meet and confer in good faith to reach a mutually agreeable resolution of that issue, which may include production of ESI in a manner or format inconsistent with the terms of this agreement. If the parties are unable to resolve the issue through good faith meet and confer efforts, they may present the issue to the Court for resolution, which again may result in the production of ESI in a manner or format inconsistent with the terms of this agreement.
III. PRODUCTION PROTOCOL FOR SPECIFIED CATEGORIES OF DOCUMENTS
Hard-copy Documents
1. The parties shall produce non-duplicative (as defined below) responsive hard copy documents in single-page black and white TIFF format (300 DPI resolution, Group IV compression); the documents should be properly unitized (i.e., contain, to the extent reasonable and practicable, correct logical document breaks and capture logical document attachment ranges). A producing party may produce color hard-copy documents as black-and-white images; where color is material to the interpretation of the document and upon reasonable request, the receiving party may request that the document be produced in color (color documents will be produced as single page JPG images). The producing party shall also provide document level OCR text files to accompany the TIFF format production. Any documents that present imaging or formatting problems will be promptly identified and the parties will meet and confer in an attempt to resolve the problems. Hard copy documents should contain the following fields in an ASCII delimited data file (.txt, .dat, or .csv) that can be loaded into commercially acceptable database software (e.g., Concordance, Relativity). The first line of each text file must contain a header identifying each data field name (i.e., header row). Each document within the database load file must contain the same number of fields as defined in the header row. Additionally, a cross-reference image file registration file that can be loaded into commercially acceptable production software (e.g., Opticon, Ipro) should be provided. Each TIFF in a product must be referenced in the corresponding image load file. The data load file should contain the following fields:
a) Custodian (name of custodian where the document originated)
b) Bates Begin (beginning production number)
c) Bates End (ending production number)
d) Page count
e) Confidential Properties (populated with the confidentiality status)
f) Redaction Properties. Populated with the redaction status. For documents that are produced with redactions, each redaction will contain a box with the word "Redacted" for any documents that contain privileged redactions, additionally the load file will be populated with "Redacted." For any documents that contain confidential information that is redacted (e.g., personally identifiable information), the load file will be populated with "Confidential Redact" and the redaction will contain a box with the words "Confidential Redact."
g) CDVol. Or ProdVol (the Name of media on which the data was produced)
Non-electronic mail ESI (excluding structured data)
2. The parties shall produce non-electronic mail ESI originally maintained as ESI in single-page black and white TIFF format (300 DPI resolution, Group IV Compression) along with corresponding document-level extracted text format, except that Excel spreadsheets (.xls, .xlsx), comma delimited text files (.csv), presentation files (e.g., MSPowerPoint and Google Presently), Access databases, and media files (e.g., video and audio files) collected from custodians from Agreed ESI Sources shall be produced in native format. The parties agree that when producing a native file, they will include a TIFF image as a placeholder for the file to represent the file in the production set. The TIFF image placeholder for a native file should be branded with a unique Bates number, any applicable confidentiality legend and state "See Native Document" on the TIFF image. The native file should then be renamed to match the Bates number assigned to the document with its original file extension. The filename field produced in the production load file that reflects the original metadata should maintain the original file name. The parties further agree to meet and confer concerning the production of additional file types or specific files in native format as discovery progresses, should a reasonable need for the production of such files in native format arise. The parties shall produce an ASCII delimited data file (.txt, .dat, or .csv) that can be loaded into commercially acceptable database software (e.g., Concordance). The first line of each text file must contain a header identifying each data field name (i.e., header row). Each document within the database load file must contain the same number of fields as defined in the header row. Additionally, a cross-reference image file registration file that can be loaded into commercially acceptable production software (e.g., Opticon, Ipro) should be provided. Each TIFF in a production must be referenced in the corresponding image load file. The load files should contain the following fields (to the extent the data is able to be automatically extracted from the file and/or is available without manual input).
a. Custodian (name of custodian where the document originated)
b. All Custodians (names of all custodians that had electronic files that were removed due to de-duplication).
c. Created Date (date the file was created)
d. Created Time (time the file was created)
e. Last Modified Date (date the file was last modified)
f. Last Modified Time (time the file was last modified)
g. Last Saved By (name of user who last saved the file)
h. File Name* (original name of the file)
i. Subject* (any value populated in the Subject filed of the document properties)
j. Title* (any value populated in the Title field of the document properties (if any))
k. File Ext (extension for the file)
l. MD5 Hash (or equivalent)
m. Bates Begin (beginning production number)
n. Bates End (ending production number)
o. A field populated with the Bates number of the first page of the family group of documents (BEGBATESATT)
p. A field populated with the Bates number of the last page of the family group of documents (ENDBATESATT)
q. Attachment Name* (original file name or Bates numbers of all attachments to a parent document)
r. Page count
s. Native link (path to the native file as included in the production e.g., d:\PROD001\natives\ABC00015.xls) for all files produced in native format
t. Confidential Properties (populated with the confidentiality status)
u. Redaction Properties (populated with the redaction type(s)). For documents that are produced with redactions (privilege redactions or otherwise), each redaction will contain a black box with the word "Redacted". Additionally, the load file will be populated with "Redacted." All files that are redacted will be provided in TIFF format only and the only text provided is that which is OCRed. If a large spreadsheet includes information requiring redaction, a party may redact the spreadsheet in its native format instead of producing it in TIFF format with redacted OCR text. The parties agree that all fields with an asterisk* will not be required to be produced if the files require redaction.
v. The Full Path* (full path location to where the file originally resided) need not be included in the load file, but should be preserved, if available, for potential provision upon reasonable request.
w. CDVol or ProdVol (the Name of media on which the data was produced)
x. TimeZone. Three letter reference to time zone that data was processed in, as agreed between parties.
3. All non-electronic mail ESI (excluding structured data) shall be processed with a single time zone and a date and time setting that is consistent across all parties' productions. The Parties agree to the use of Greenwich Mean Time (GMT).
Electronic mail
4. The parties shall produce electronic mail in single-page black and white TIFF format (300 DPI resolution, Group IV compression) along with the corresponding document-level extracted text, except that Excel spreadsheet attachments (.xls, .xlsx), comma delimited text files (.csv), presentation files (e.g. MSPowerPoint and Google Presently), Access databases, and media files (e.g., video and audio files) collected from custodians from Agreed ESI Sources, shall be produced in native format. The parties agree that when producing a native file, they will include a TIFF image as a placeholder for the file to represent the file in the production set. The TIFF image placeholder for a native file should be branded with a unique Bates number, and confidentiality legend, and state "See Native Document" on the TIFF image. The native file should then be renamed to match the Bates number assigned to the document with its original file extension. The filename field produced in the production load file that reflects the original metadata should maintain the original file name. The parties further agree to meet and confer concerning the production of additional file types or specific files in native format as discovery progresses, should a reasonable need for the production of such files in native format arise. The parties shall produce an ASCII delimited data file (.txt, .dat, or.csv) that can be loaded into commercially acceptable database software (e.g., Concordance). The first line of each text file must contain a header identifying each data field name (i.e., header row). Each document within the database load file must contain the same number of fields as defined in the header row. Additionally, a cross-reference image file registration file that can be loaded into commercially acceptable production software (e.g., Opticon, Ipro) should be provided. Each TIFF in a production must be referenced in the corresponding image load file. The load files should contain the following fields (to the extent the data is able to be automatically extracted from the file and/or is available without manual input):
a. Custodian (name of custodian where the document originated)
b. All Custodians (names of all custodians that had electronic files that were removed due to de-duplication)
c. Author (From field)*
d. CC*
e. BCC*
f. Recipient (To field)*
g. Subject* (subject line of the email)
h. MD5 Hash (or equivalent)
i. Date Sent (date the email was sent)
j. Time Sent (time the email was sent)
k. Date Received (date the email was received)
l. Time Received (time the email was received)
m. Parent Date (the date of the parent email should be applied to the parent email and all of the email attachments)
n. File Ext (extension for the file)
o. Bates Begin (beginning production number)
p. Bates End (ending production number)
q. Attachment Bates Begin (beginning production number of all attachments to a parent document)
r. A field populated with the Bates number of the first page of the family group of documents (BEGBATESATT).
s. A field populated with the Bates number of the last page of the family group of documents (ENDBATESATT).
t. Page count
u. Confidential Properties (populated with the confidentiality status)
v. Redaction Properties. For documents that are produced with redactions, each redaction will contain a box with the word "Redacted" such that OCR text of the document will enable searching for "redacted" and locating the precise places where the redaction was done. For any documents that contain privileged redactions, additionally the load file will be populated with Redacted. The parties agree that all fields with an asterisk* will not be required to be produced if the files require redaction.
w. Native link (path to the native file as included in the production e.g., d:\PROD001\natives\ABC00015.xls) for all files produced in native format.
x. CDVol or ProdVol (the Name of media on which the data was produced)
y. TimeZone (three letter reference to reflect the time zone that the data was processed in, as agreed between parties)
z. CID/Thread Index (e.g., email thread index available in MS Exchange)
5. In addition to the foregoing fields, electronic mail shall be produced along with all relevant attachments in sequential order as part of a family, maintaining the parent-child relationship, to the extent the message or any attachment is responsive and not privileged. Any emails or attachments to emails withheld on privilege grounds will be included on a privilege log to be provided within a reasonable time period with control numbers assigned by the producing party. Privilege logs are to conform to the requirements below; this paragraph imposes no additional obligations on the parties with respect to the content and format of privilege logs. This procedure is without prejudice to any challenges brought regarding documents withheld by the producing party.
6. All compressed or zipped ESI shall be unzipped or decompressed during processing. To the extent an electronic file contains embedded files, such files shall be produced as attachments in sequential order as part of a family, maintaining the parent-child relationship. Parties should negotiate to limit extraction or production of embedded objects to non-image based types to restrict extraction of images within emails or presentations (e.g., signature blocks).
7. Each page of a produced document, except those documents that are produced in native format, shall have a legible, unique page identifier ("Bates Number") electronically "burned" (stamped) onto the image at a location that does not obliterate, conceal, or interfere with any information from the source document. No other legend or stamp will be placed on the document image other than a confidentiality legend or redactions (where applicable). The confidential legend shall be "burned" (stamped) into the documents image at a location that does not obliterate or obscure any information from the source document. Any confidentiality designation or Bates Number range for a natively-produced document will be provided in a separate field and burned into the placeholder image.
8. Each page image file shall be named with the unique Bates Number of the page of the document in the case of single-page TIFFs, followed by the extension ".TIF." Any native documents shall be named with the Beginning Bates number of the document.
9. A document level text file will be provided containing the extracted text (or OCR for documents where no extracted text exists). The file will be named after the Beginning Bates number of each document. Where a document contains redactions, only OCR text will be provided.
10. A placeholder should be inserted for exception documents (i.e., failed documents that could not be processed due to corruption or password protection) that are part of a family being produced with the legend "This document could not be imaged" and a produced field indicating "Could Not Be Imaged." Such placeholder shall include a unique Beginning Bates number of the document.
11. Electronic mail that cannot be reviewed, produced and/or imaged in their entirety because of technical issues (other than the file types that do not require processing under the terms of this Stipulation) should be identified as an exception file and included on a log that lists the file name, custodian, and reason for the exception (i.e., corruption, unavailable password protection, proprietary software, or other technical issue). The producing Party shall provide a copy of this log to the receiving Party at agreed upon intervals, and shall provide a final copy of the log upon completion of document production. If the receiving Party requests production of any files listed on the exception log, the Parties will meet and confer on a reasonable and cost-effective means for attempting to provide the requested files.
12. Files to be processed may be identified through the use of an inclusionary list of file types that typically contain meaningful user-created data. The following categories of electronic files may be specifically excluded from collection, review and production:
a. System or executable files (.exe, .dll, etc.); and
b. ESI or data with a hash value that matches a value on the list(s) of known operating system and application files provided by the National Software Reference Library ("NSRL"), based out of the National Institute of Standards in Technology ("NIST").
c. ESI or data with file extensions that typically contain no meaningful user-created data and/or cannot be reviewed in any meaningful format, including but not limited to: ani; bat; c; cab; cfg; class; dll; ex_; exe; fon; hlp; ico; icon; inf; ini; isu; java; jpa; kqp; mpe; msi; ocx; out; pcd; pcx; reg; sfw; sys; tag; ttf; and xp.
13. In order to reduce the volume of documents reviewed and produced, each party shall de-duplicate ESI using the MD5 hash value both vertically (within custodians) and horizontally (across custodians). The de-duplicated originals and their associated metadata shall be securely retained such that reports containing relevant associated metadata about the documents can be made available upon reasonable request. Nothing in this Order shall preclude the parties from further meet and confer on the scope of de-duplication.
14. Where color is material to the interpretation of ESI and upon reasonable request, the receiving party may request that the ESI be produced in color. The requesting party must identify the documents by Bates number. Single-page JPG files are preferred for Relativity. Either color JPG or TIFF files are suitable for Concordance.
15. For any productions made prior to entry of this Order, the producing party shall supply, in a reasonably prompt manner, load files that comply with the provisions of the Order.
16. All electronic mail shall be processed with a single time zone and a date and time setting that is consistent across all parties' productions. The Parties agree to the use of Greenwich Mean Time (GMT).
Structured data
17. The parties will endeavor to agree upon the manner in which structured data will be produced following service of written document request responses and objections. If agreement cannot be reached after completion of a meet and confer process, the parties may submit any issues for resolution by the Court.
18. Documents and ESI shall be produced on readily accessible computer or electronic media such as optical media (CD or DVD), external hard drives, or via an FTP site, or similar electronic media (the "Production Media"). Each piece of Production Media shall identify a production number or other unique identifying label corresponding to the Party and production with which the documents on the Production Media are associated (e.g., "[Defendant Party] 001", "[Plaintiff Party] 001"), as well as the volume of the material in that production (e.g., "- 001", "-002"). For example, if the first production from a Party comprises document images on three hard drives, the Party shall label each hard drive in the following manner: "[Party Name] 001-001", "[Party Name] 001-002", and "[Party Name] 001-003." Each piece of Production Media shall be labeled to also identify: (1) the production date; and (2) the production number or Bates Number range of the documents contained on the Production Media. Industry-standard encryption tools and practices must be used when producing documents. Passwords must be at least 8 characters with a mix of character sets and sent in a separate communication from the encrypted data. The parties agree to expeditiously provide replacement production media or provide other reasonable assistance in the event that the Receiving Party reports difficulty in accessing the media.
IV. PRIVILEGE LOGS
19. The parties agree that identification, review, redaction and logging of privileged communications can be costly and time-consuming. To limit the cost of a privilege review and make document production more efficient, the parties agree to use the protocols described below with respect to handling responsive documents that may include privileged information.
20. A party may use the following method to satisfy the need to produce a Privilege Log.
a. Rather than producing a Privilege Log that requires that a manually generated privilege description be included on a log, the parties may, for electronic documents of all types, provide instead a meta-data based Privilege Log that identifies the privileged document's beginning and ending Bates number; the document family's beginning and ending Bates number; the nature of the privilege claim; whether the document is being produced in redacted form; whether the document stands alone, has attachments (in the case of an email), or is an attachment; the custodian from whom the document was collected; the type of document; the file name or subject line (in the case of an email); the date the document was modified or sent; the document's author; and the "from", "to", "cc", and "bcc" fields if the document is an email. No additional description, narrative or information need be provided in the meta-data Privilege Log to satisfy the producing party's obligations. Both parties acknowledge that the meta-data for email and corresponding attachments will be based on and extracted from the top email in any responsive email chain and stand-alone documents will be manually populated in the absence of meta-data, and that this will satisfy all obligations pursuant to this paragraph. This provision does not apply to paper documents.
b. Upon receipt of the Privilege Log, the Receiving Party will have thirty (30) business days to identify any document designated on the privilege log for which it in good faith and for good cause requires more information in order to assess the claim of privilege. The parties will meet and confer within ten (10) business days of such identification to determine if the receiving party's questions can be resolved in a manner other than through the Producing Party providing a more detailed Privilege Log line with regard to such disputed items. If the parties cannot resolve any such disputed items, the Receiving Party must, within five (5) business days of any final "meet-and-confer" between the parties regarding the disputed items, send a written notice to the Producing Party listing the specific document(s) on the Privilege Log for which it is requesting a traditional privilege log line. Subject to the right of either party to file a motion for protective order or motion to compel at any time as appropriate under the court's rules, the Producing Party will within sixty (60) calendar days of receipt of such written notice provide traditional privilege log lines for the listed document(s). The time to produce such a log will be stayed by the filing of a motion for a protective order or motion to compel with regard to such disputed items until such time as the motion is resolved. In the event that a party determines in good faith that, because of the number of disputed items, compliance with the sixty (60) day requirement is not reasonably feasible, the parties will meet and confer to set a reasonable time period for production of the traditional privilege log entries.
c. Nothing in this stipulation changes the requirements of state or federal law as to what constitutes a document or communication protected by an applicable privilege or immunity. Moreover, nothing in this stipulation precludes a Producing Party from satisfying their Privilege Log obligations through any other means that meet the requirements of federal law.
21. The parties need not include or identify, on any privilege or work product log in response to document requests, privileged documents constituting:
a. communications between any party or parties and counsel for that party or parties that (a) were for the purposes of litigating this case, or were in anticipation of litigation regarding the allegations made in this litigation; (b) postdate the establishment of an attorney-client relationship between counsel and the party; and (c) were not disclosed to anyone who, at the time of the disclosure, was a third party to the attorney-client relationship;
b. communications between attorneys or their agents and litigation experts or consultants; and
c. documents created by then-current counsel (or by any employee or agent of then-current counsel) for the purpose of litigating this case, or in anticipation of litigation relating to allegations in this case, and not disclosed to anybody who, at the time of the disclosure, was not a client of the firm creating the document at issue, an attorney for aligned parties in this case or those attorneys' employees, or a consultant or expert for the firm or client.
22. Neither party will treat the failure to log such documents as a waiver of any privilege or protection.
23. Inadvertent production of privileged materials shall be governed by the provisions set forth in the Protective Order in this matter.
V. PRODUCTION MEDIA AND ADDITIONAL FILE PROCESSING
24. Microsoft Office files (with the exception of PowerPoint presentations and Excel), WordPerfect, and other standard documents (e.g. Google Docs and PDF documents) will be converted to single-page TIFF images and produced consistent with the specifications herein. If the document contains comments or tracked changes, the TIFF images shall be generated to include the comments or track changes contained in the file.
VI. LIMITATIONS
25. Nothing in this Stipulation and Proposed Order shall prohibit a party from seeking modification of any of its terms either by stipulation or by application to the Court. Should any party subsequently determine that it cannot in good faith proceed as required herein or without undue burden and cost, the parties will meet and confer to attempt to resolve any dispute before seeking Court intervention.
26. This Stipulation and Proposed Order relates to the general protocol of identifying and producing hard copy documents and ESI, and is not otherwise intended to alter the parties' respective rights and obligations under the Federal Rules of Civil Procedure.
IT IS SO AGREED UPON AND STIPULATED.
ATTESTATION
I, William P. Ashworth, attest that I am one of the attorneys for the Sprint Defendants, and as the ECF user and filer of this document, I attest that concurrence in the filing of this document has been obtained from its signatories.
CITY OF LOS ANGELES, ex rel. RICHARD KNUDSEN v. SPRINT SOLUTIONS, INC., U.S. District Court For The Eastern District Of California — Case No. 2:17-CV-0811-TLN-AC
ORDER
IT IS SO ORDERED.
