1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
|
Network Working Group P. Hoffman
Request for Comments: 3233 Internet Mail Consortium
BCP: 58 S. Bradner
Category: Best Current Practice Harvard University
February 2002
Defining the IETF
Status of this Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document gives a more concrete definition of "the IETF" as it
understood today. Many RFCs refer to "the IETF". Many important
IETF documents speak of the IETF as if it were an already-defined
entity. However, no IETF document correctly defines what the IETF
is.
1. Introduction
Many RFCs refer to "the IETF". Many important IETF documents speak
of the IETF as if it were an already-defined entity. However, no
IETF document correctly defines what the IETF is. This document
gives a more concrete definition of "the IETF" as it understood
today.
2. Defining the IETF
BCP 9 ("The Internet Standards Process -- Revision 3") [BCP 9], the
primary document that describes the Internet standards process, never
defines the IETF. As described in BCP 11 ("The Organizations
Involved in the IETF Standards Process") [BCP 11], the Internet
Engineering Task Force (IETF) is an open global community of network
designers, operators, vendors, and researchers producing technical
specifications for the evolution of the Internet architecture and the
smooth operation of the Internet.
Hoffman & Bradner Best Current Practice [Page 1]
^L
RFC 3233 Defining the IETF February 2002
It is important to note that the IETF is not a corporation: it is an
unincorporated, freestanding organization. The IETF is partially
supported by the Internet Society (ISOC). ISOC is an international
non-profit organization incorporated in the US with thousands of
individual and corporate members throughout the world who pay
membership fees to join. The Internet Society provides many services
to the IETF, including insurance and some financial and logistical
support.
As described in BCP 11, Internet standardization is an organized
activity of the ISOC, with the ISOC Board of Trustees being
responsible for ratifying the procedures and rules of the Internet
standards process. However, the IETF is not a formal subset of ISOC;
for example, one does not have to join ISOC to be a member of the
IETF.
There is no board of directors for the IETF, no formally signed
bylaws, no treasurer, and so on. The structure of the IETF (its
leadership, its working groups, the definition of IETF membership,
and so on) are described in detail in BCP 11. Procedures for
choosing leadership are described in detail in BCP 10.
Thus, when RFCs say "the IETF", they are describing the group that
acts in accordance with BCP 9, BCP 10, and BCP 11.
3. Security Considerations
All IETF protocols must describe the security aspects of the
environment in which they will be used. Also, the IETF has a
Security Area which discusses the security aspects of IETF protocols.
However, descriptive documents such as this one do not affect the
security of the Internet.
Hoffman & Bradner Best Current Practice [Page 2]
^L
RFC 3233 Defining the IETF February 2002
A. References
[BCP 9] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.
[BCP 10] Galvin, J., "IAB and IESG Selection, Confirmation, and
Recall Process: Operation of the Nominating and Recall
Committees", BCP 10, RFC 2727, February 2000.
[BCP 11] Hovey, R. and S. Bradner, "The Organizations Involved in the
IETF Standards Process", BCP 11, RFC 2028, October 1996.
B. Editors' Addresses
Paul Hoffman
Internet Mail Consortium
127 Segre Place
Santa Cruz, CA 95060 USA
EMail: phoffman@imc.org
Scott Bradner
Harvard University
29 Oxford St
Cambridge MA 02138
EMail: sob@harvard.edu
Hoffman & Bradner Best Current Practice [Page 3]
^L
RFC 3233 Defining the IETF February 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Hoffman & Bradner Best Current Practice [Page 4]
^L
|
