The Third Edition of the Sedona Conference Principles

The final pre-publication version of the Third Edition of the Sedona Conference Principles was released this week. The third edition is the first new one since 2007. The introduction to the new edition provides an overview of the changes made to the principles.

The second edition was released in 2007, the same year the iPhone became available. 10 years later there is no longer debate about whether or not meta data must be produced, and restoring data from back-up tapes is no longer a key concern.

The amendments to the Federal Rules of Civil Procedure in 2015 are reflected in the new edition of the Sedona principles with the increased emphasis on cooperation and proportionality. The principles continue to stress the importance of cooperation in the discovery process, announced in the Sedona Cooperation Proclamation of 2008.

The new edition uses the term ESI throughout rather than using the various references to data, evidence, documents and information in the previous edition.

Principle 2 now uses the term 'balance' in referring how to apply the proportionality factors. Proportionality is now applicable to all steps in the discovery process, including preservation.

Principle 4 now uses the word 'specific' instead of 'clear' with respect to tailoring discovery requests under Rule 26(g).

Principle 5 has been altered to state that preservation should pertain to information relevant to claims and defenses, and that the preservation duty is trigger when litigation is reasonably anticipated.

Principle 8 was revised to reflect the blurring of the line between active and inactive data, and shift away from analyzing what is reasonably accessible to considering what is most readily accessible.

Principle 10 was updated to reflect that all parties have obligations to privileged and protected information, and that non-disclosure agreements may restrict the use of private data.

Principle 12 was modified to move the focus away from the use of metadata to access, display and search the same information as the producing party, and towards its production in the form in which it is ordinarily maintained.

Principle 13 was changed so, "that the costs of 'preserving and producing' (rather than 'retrieving and reviewing') 'relevant and proportionate' ESI should be borne by the responding party."

Browning Marean’s ESI Cost Budget

The Tip of the Night for September 24, 2015 noted that the EDRM makes several different budget calculators available on its site. Browning Marean was a partner at DLA Piper who focused on electronic discovery and information governance. He developed a calculator that estimated costs for the standard phases in electronic discovery (collection, processing, review, production) as well as providing projections for the cost of Early Data Assessment, privilege review and data hosting.

Marean's calculator uses an Excel spreadsheet to arrive at total costs based on several values entered by the user.

In the collection phase, you enter the number of custodians data is being collected from; the average number of GB per custodian; and the estimated number of files per GB. A fixed dollar figure is to be given for how much it costs to collect data from each custodian, and hourly charges for network data collection, to then arrive at the total collection cost.

Other parameters given as useful guidelines subject to change include a 30% reduction for de-NISTing and de-duplication; and 90% responsive rate after an effective EDA tool is used.

- Processing fees are charged on a per GB basis.

- A flat fee is entered for an EDA tool, and the cost of attorney time spent learning the EDA tool is considered as well.

- Review for responsiveness and privilege documents are based on the number of documents an attorney can review in an hour and their hourly fees, but different rates are assumed for each task. Separate figures are to be entered for the review of opposing productions.

- Production costs are assessed on a fee per file.

- Hosting costs are based on how much is charged for setting up a database; individual user accounts; monthly maintenance; image storage; and an hourly fee for project management.

- Paper document collection and processing is taken into account as well.

The spreadsheet not only generates a grand total for all of the electronic discovery tasks, it also calculates the cost per individual file.

Outline of Craig Ball's Electronic Discovery Workbook - Native Production of Email

Here's a continuation of my outline of the 2016 edition of Craig Ball's Electronic Discovery Workbook which I last posted about on September 29, 2017.

XI. Native Production of Email A. Databases a. MS Exchange is an email server application that’s a database. b. MS Outlook- an email client application is a database. c. Gmail – SaaS webmail application is a database. d. Lotus Domino, Lotus Notes, Novell Groupwise, Hotmail – all databases. B. Text per a Protocol a. Request for Comment – specifies the form an email should adhere to in order to be compatible with email systems. b. Latest protocol revision is RFC 5322 c. RFC 2045-47, 2049 and 4288-89 – are Multipurpose Internet Mail Extensions (MIMEs) that allow for the exchange of multimedia and foreign languages. d. .eml format often plain text adhering to RFC 5322 and MIME. e. Can convert .eml to .mht extension to open in web browser. f. Mbox - established format for storing multiple RFC 5322 messages in a container format. g. Email in transit format may include the full header information but it lacks metadata acquired upon receipt, such as: i. Folder in which it resides ii. Read / flagged status iii. Time of receipt C. Outlook a. Outlook and Exchange communicate using MAPI, Messaging Application Programming Interface. b. Outlook can serve as the front end for Exchange, Lotus Domino, and webmail services. c. Outlook functions by taking messages apart and using info to populate fields in a database. d. An Outlook email message is actually a report from a database. e. Messages between Outlook and Exchange contain MAPI metadata not present in 5322 messaging. f. No better form of production for Exchange/Outlook messaging than a .pst file. g. No clear native format for Outlook messages. i. .msg contains complete RFC 5322 content and additional metadata, but lacks data saved in a .pst. D. Exchange a. .edb is the format for an Exchange database. i. Holds account data for everyone in a domain. b. Ball has never seen EDB that only contains data for select custodians and was used in discovery. c. One can produce Exchange data in non-native format if attachments produced in native form. E. Gmail a. Keaton v. Hannum, (S.D. Ind. 2013) – court cited Ball noting that Gmail can be downloaded to Outlook and saved as .eml or .msg files, or generated as PDF portfolio. b. Gmail native file format not disclosed by Google. c. IMAP capture to a PST format is a practical alternative. F. Native format of an email a. TIFF format can be sufficient but it costs more to extract text and convert to images than to use near native in production, and TIFF files will be much larger b. Because e-mails and attachments have the unique ability to be encoded entirely in plain text, a load file can carry the complete contents of a message and its contents as RFC 5322-compliant text accompanied by MAPI metadata fields. It’s one of the few instances where it’s possible to furnish a load file that simply and genuinely compensates for most of the shortcomings of TIFF productions. Yet, it’s not done.