One document matched: draft-alvestrand-subpoena-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 01:33:19 |