Network Working Group H. Alvestrand Internet-Draft February 14, 2004 Expires: August 17, 2004 Subpoenas in the IETF: Procedures draft-alvestrand-subpoena-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 17, 2004. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document describes a proposal for the IETF's procedures for handling subpoenas served on the IETF. This is an adaptation of the ad-hoc procedures that the IESG has applied for the last two such events. Alvestrand Expires August 17, 2004 [Page 1] Internet-Draft Subpoena handling February 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Open issues . . . . . . . . . . . . . . . . . . . . . . . 3 2. Legal basis for subpoena . . . . . . . . . . . . . . . . . . . 3 3. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Normal procedure . . . . . . . . . . . . . . . . . . . . . . . 5 5. Strategies for Responding to Subpoenas . . . . . . . . . . . . 5 6. Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1 Normative references . . . . . . . . . . . . . . . . . . . 7 9.2 Informative references . . . . . . . . . . . . . . . . . . 7 A. Changes from version -01 to -02 . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . 8 Alvestrand Expires August 17, 2004 [Page 2] Internet-Draft Subpoena handling February 2004 1. Introduction Sometimes, people engaged in lawsuits write subpoena letters to the IETF requesting information. The IETF has good reason to come up with that information when it happens. This document describes how the IETF deals with providing that information. This procedure deals with subpoenas brought in US courts, because that's the only type the IETF so far has to deal with. If the IETF ever has to deal with similar issues in other jurisdictions, this document will have to be updated. 1.1 Open issues o This procedure is not adapted for the introduction of the IASA. The terminology may have to be adjusted to say "clerk's office" or "archivist" rather than "secretariat". I am not sure what role the IAD should play, but he/she does not replace the IETF chair. o Both the secretariat and the lawyer ask "who's in charge". I've tried to make the lawyer (or his assignee) be in charge, but that may not be the right answer in all cases. 2. Legal basis for subpoena Sometimes when companies are engaged in U.S. litigation relating to technologies that use or incorporate IETF standards, one or more of the litigants will wish to obtain information directly from the IETF. This is likely to occur when the litigant believes that some activity that occurred within the IETF process, or some intellectual property relating to an IETF standard, is directly related to the case. To obtain this information, the litigant will request that a state or federal court issue a "third party" subpoena to IETF seeking this information, either in the form of existing documents or witness testimony. A "third party" subpoena should be distinguished from a "direct" subpoena, which would be issued if IETF were involved in litigation directly, as a party to the litigation rather than as a witness. Subpoenas may also be issued by the government in matters in which the prosecutor or agency official believes that an IETF activity or standard may have relevance to a criminal prosecution or agency investigation. Subpoenas carry the authority of the court that issued them, and failure to comply with any type of subpoena could subject the IETF to charges of contempt of court and other civil and/or criminal penalties. Thus, no matter what type of subpoena is issued to IETF, all should be addressed seriously and in accordance with the procedures outlined in this document. Alvestrand Expires August 17, 2004 [Page 3] Internet-Draft Subpoena handling February 2004 In order to be effective, a subpoena must be "served" on the party to which it is directed. "Service of process" is a somewhat arcane legal doctrine that requires legal papers to be delivered in person by an authorized "process server" to an authorized representative of the subpoenaed party. Because the IETF operates in a distributed, decentralized manner, the preferred recipient of all subpoenas is the IETF's current legal counsel, who would be authorized to accept service on behalf of the IETF. If a subpoena intended for the IETF is received by any member of the IETF community, it should be provided as quickly as possible to the IETF legal counsel, currently: Wilmer Cutler Pickering Hale and Dorr LLP 1899 Pennsylvania Ave. N.W. Washington, D.C. 20006 USA Fax: 202-663-6712 Attention: Jorge L. Contreras E-mail: jorge.contreras@wilmerhale.com This contact information should be visible on the IETF web pages (at the time of this writing, it is not), and also be provided to any person who inquires where an IETF subpoena should be issued. 3. Procedure Dealing with a subpoena is complex, because you require multiple fields of knowledge - you need legal assistance, you need someone who knows the technology in question (so that you can figure out what the hell is being asked about), and you need someone who knows how the IETF works, and where information is likely to be found. The IETF lawyer (currently Jorge Contreras) is the proper recipient of the subpoena. He will contact the IETF Chair to get the identification of the technology area. They will together supervise the formation of the team. The procedure here creates a team for every subpoena, consisting of: o A legal advisor, picked by the IETF lawyer o A technology expert, picked by the AD responsible for the technology for which information is being sought. It may be the AD. o A procedure expert, picked by the IETF chair (or, if the IETF chair is somehow involved in the case, by the IAB chair) o A secretariat contact person, to do searches in IETF data that is not publicly available The legal advisor will be the leader of the team, and tell the other Alvestrand Expires August 17, 2004 [Page 4] Internet-Draft Subpoena handling February 2004 members when the material required to satisfy the subpoena is complete. The procedure expert (this role has been filled in the past by Scott Bradner) will help identify records that are kept by the IETF, either publicly or privately, that may satisfy the material. This is likely to be an AD or ex-AD. The technology expert will help identify from the identifiers in the subpoena what documents, working groups and mailing lists the information is likely to be found in. 4. Normal procedure The section above identifies the actors, and what they are responsible for. This section describes an example set of actions that are taken while dealing with the subpoena. o The subpoena is sent to the IETF Lawyer by the Questioner.. o The IETF Lawyer informs the IETF chair that it has arrived, and transfers a copy. o The IETF Lawyer and the IETF Chair determine what the technology area is, the IETF Lawyer send a request for extended time to the Questioner, and they start selecting the team - this includes informing the secretariat that the subpoena has arrived. o The Legal Advisor gathers the team for a teleconference to go through the material requested, and, with the assistance of the team, sorts it into 4 types: Available from public sources, available from the IETF archives, not easily accessible, and is not available. o The Legal Advisor informs the Questioner about the existence of the publicly available material, sends a list to the secretariat asking them to produce the available archival material, questions whether requesting the not-easily-available material is appropriate, and denies the existence of the unavailable material. o The list provided to the secretariat will give the identity, the requested format and the deadline for the material requested. o The Legal Advisor will negotiate extended deadlines and reductions in the requested information as appropriate. o Once the full collection of non-public material is collected, the Legal Advisor will forward this to the Questioner. 5. Strategies for Responding to Subpoenas The responsibility of the IETF in responding to a subpoena issued to it is limited to producing those paper or electronic documents in its possession, custody or control. It is under no duty to make a request to others for documents not subject to IETF's control at the Alvestrand Expires August 17, 2004 [Page 5] Internet-Draft Subpoena handling February 2004 time it received the subpoena. The strategy for responding to a subpoena will be developed by the team with the guidance of the legal advisor. Many subpoenas are initially drafted broadly and request information that may be unnecessary or beyond the scope of the litigation, or the production of which would cause undue hardship on IETF. If this occurs (as it often does), the legal advisor will work with the team to narrow the scope of the request, either through informal discussions with the litigants' counsel or through service of formal objections and eventual motion practice in court. The legal advisor will also work with the team to identify which documents and types of documents should be provided in response to a subpoena. If documents are generally available from public online sources, a pointer to the archive may be a sufficient response. If, however, there is correspondence between IETF officers and counsel, or which has been prepared by IETF's counsel in anticipation of litigation, these documents may be covered by a formal legal privilege, and should not be disclosed. Also, any documents that are eventually produced must be numbered and marked for confidentiality. Thus, it is critical that no documents or information be provided to any third party in response to a subpoena without the guidance and approval of the legal advisor. Subpoenas sometimes request that IETF make witnesses available for depositions or direct testimony in court. Such requests may place a burden on the persons requested to appear, and the legal advisor will work with the team to determine whether and to what extent such requests should be opposed or limited. 6. Costs This procedure assumes that the procedure and technology experts will volunteer their time as IETF participants, unless they are required to appear at witnesses and incur travel or other expenses, the reimbursement of which will be discussed with the IESG prior to being incurred. The secretariat will participate in this process as part of its duties, without additional remuneration. The legal advisor will agree in advance with the IETF Chair whether any charges will be required, or whether the work required can be handled on a pro-bono basis. 7. Security Considerations The process described in this memo has no direct bearing on the security of the Internet. Alvestrand Expires August 17, 2004 [Page 6] Internet-Draft Subpoena handling February 2004 8. Acknowledgements Jorge Contreras and Barbara Fuller gave extensive comments on an earlier, internal version of this draft, and in particular Jorge Contreras contributed significant text to this memo. All errors are, of course, the author's responsibility. 9. References 9.1 Normative references [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 9.2 Informative references [2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Author's Address Harald Alvestrand Email: harald@alvestrand.no Appendix A. Changes from version -01 to -02 This section should be removed by the RFC Editor. This is the first public version. Alvestrand Expires August 17, 2004 [Page 7] Internet-Draft Subpoena handling February 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Alvestrand Expires August 17, 2004 [Page 8]