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
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
|
<pre>Internet Research Task Force (IRTF) S. Dawkins, Ed.
Request for Comments: 7418 Huawei
Category: Informational December 2014
ISSN: 2070-1721
<span class="h1">An IRTF Primer for IETF Participants</span>
Abstract
This document provides a high-level description of things for
Internet Engineering Task Force (IETF) participants to consider when
bringing proposals for new research groups (RGs) into the Internet
Research Task Force (IRTF). This document emphasizes differences in
expectations between the two organizations.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Research Task Force
(IRTF). The IRTF publishes the results of Internet-related research
and development activities. These results might not be suitable for
deployment. This RFC represents the individual opinion(s) of one or
more members of the IRSG Research Group of the Internet Research Task
Force (IRTF). Documents approved for publication by the IRSG are not
a candidate for any level of Internet Standard; see Section 2 of <a href="./rfc5741">RFC</a>
<a href="./rfc5741">5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc7418">http://www.rfc-editor.org/info/rfc7418</a>.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
<span class="grey">Dawkins Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7418">RFC 7418</a> IRTF Primer for IETF December 2014</span>
Table of Contents
<a href="#section-1">1</a>. Introduction and Scope . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-2">2</a>. The IRTF Is Not the IETF . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-2.1">2.1</a>. Research and Engineering . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2.2">2.2</a>. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2.3">2.3</a>. Time Frames . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2.4">2.4</a>. Alternatives . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2.5">2.5</a>. Process . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2.6">2.6</a>. Charters . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2.7">2.7</a>. Deliverables . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-2.8">2.8</a>. Completion . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3">3</a>. Now That You Know What Not to Do . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4">4</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5">5</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5.1">5.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5.2">5.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction and Scope</span>
This document provides a high-level description of things for
Internet Engineering Task Force (IETF) participants to consider when
bringing proposals for new research groups (RGs) into the Internet
Research Task Force (IRTF). This document emphasizes differences in
expectations between the two organizations.
IRTF RG guidelines and procedures are described in <a href="https://www.rfc-editor.org/bcp/bcp8">BCP 8</a> [<a href="./rfc2014" title=""IRTF Research Group Guidelines and Procedures"">RFC2014</a>],
and this document does not change those guidelines and procedures in
any way.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. The IRTF Is Not the IETF</span>
A number of proposals from experienced IETF participants for new IRTF
RGs have encountered problems because the IETF participants were
making proposals appropriate for the IETF, but not for the IRTF.
[<a href="./rfc2014" title=""IRTF Research Group Guidelines and Procedures"">RFC2014</a>] describes the origin of IRTF RGs but doesn't provide much
detail about the process, which is intended to be flexible and
accommodate new types of RGs. Lacking that detail, experienced IETF
participants fall back on what they know, assume that chartering an
IRTF RG will be similar to chartering an IETF working group (WG),
follow the suggestions in [<a href="./rfc6771" title=""Considerations for Having a Successful "">RFC6771</a>] to gather a group of interested
parties, and then follow the suggestions in [<a href="./rfc5434" title=""Considerations for Having a Successful Birds- of-a-Feather (BOF) Session"">RFC5434</a>] to prepare for
a successful BOF and eventually, a chartered WG.
<span class="grey">Dawkins Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7418">RFC 7418</a> IRTF Primer for IETF December 2014</span>
Both of these documents are excellent references for proposals in the
IETF, but their suggestions may result in a proposal that is almost
the opposite of what the IRTF Chair is looking for in a proposal for
an IRTF RG. The mismatches fall into some consistent categories, and
this document lists the ones that come up repeatedly.
The target audience of this document is IETF participants bringing
proposals to the IRTF.
It's worth noting that the IRTF Chair has substantial autonomy on
what RGs are chartered and how they reach that stage. The IRTF Chair
at the time of writing is Lars Eggert.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Research and Engineering</span>
"To me, the fundamental outcome of research is understanding, and
the fundamental outcome of engineering is a product." - Fred Baker
In some ways, research is about a journey, and engineering is about a
destination. If a researcher answers a question in a way that opens
another question, that can be success. If an engineer keeps working
on a product without finishing it, that is usually a failure.
Research can be open-ended, while engineering can come to a stopping
point when the result is "good enough" -- good enough to ship.
"If it has to work when you're finished, it wasn't research, it
was engineering." - attributed to Dave Clark
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Scope</span>
IRTF RGs have a scope large enough to interest researchers, attract
them to the IRTF, and keep them busy doing significant work. Their
charters are therefore usually much broader than IETF WG charters,
and RGs often discuss different topics underneath the charter
umbrella at different times, based on current research interests in
the field.
IETF WGs are chartered with a limited scope and specific
deliverables. If deliverables and milestones are known, the proposal
is likely too limited for the IRTF.
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. Time Frames</span>
IRTF RGs bring researchers together to work on significant problems.
That takes time. The effort required by a RG is likely to take at
least three to five years, significantly longer than IETF WGs
envision when they are chartered.
<span class="grey">Dawkins Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7418">RFC 7418</a> IRTF Primer for IETF December 2014</span>
<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>. Alternatives</span>
IRTF RGs are encouraged to explore more than one alternative approach
to the chartered problem area. There is no expectation that the RG
will "come to consensus" on one approach. The RG may publish
multiple competing proposals as research produces results.
IETF WGs normally use the IETF consensus process (as described in
[<a href="./rfc7282" title=""On Consensus and Humming in the IETF"">RFC7282</a>]) to drive interoperable solutions into the market place.
That often includes reducing the number of approaches to something
manageable for an implementer, preferably one, whether that means
starting with an approach the WG participants agree on, or
considering alternatives with a view to picking one rather than
spending significant effort on alternatives that won't go forward.
The IRTF, as an organization, may also charter multiple RGs with
somewhat overlapping areas of interest, which the IETF tries very
hard to avoid.
<span class="h3"><a class="selflink" id="section-2.5" href="#section-2.5">2.5</a>. Process</span>
All IRTF participants have the obligation to disclose IPR and
otherwise follow the IRTF's IPR policies, which closely mirror the
IETF's IPR policies; in all other aspects, IRTF RG operation is much
less constrained than IETF WG operation.
Each IRTF RG is permitted (and encouraged) to agree on a way of
working together that best supports the specific needs of the group.
This freedom allows IRTF RGs to bypass fundamental IETF ways of
working, such as the need to reach at least rough consensus, which
IRTF RGs need not do. Therefore, the mode of operation of IRTF RGs
can also change over time, for example, perhaps becoming more like
IETF WG operation as the research the group has been progressing
matures.
<span class="h3"><a class="selflink" id="section-2.6" href="#section-2.6">2.6</a>. Charters</span>
The purpose of charters in the IRTF is to broadly sketch the field of
research that a group is interested in pursuing and to serve as an
advertisement to other researchers who may be wondering if the group
is the right place to participate.
IETF WG charters tend to be very narrow. They are intended to
constrain the work that the working group will be doing, and they may
contain considerable text about what the working group will not be
working on.
<span class="grey">Dawkins Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7418">RFC 7418</a> IRTF Primer for IETF December 2014</span>
<span class="h3"><a class="selflink" id="section-2.7" href="#section-2.7">2.7</a>. Deliverables</span>
There is no expectation that IRTF RGs publish RFCs, although many do.
Some IRTF research groups produce IRTF-stream RFCs, while others
produce Internet-Drafts that form the basis of IETF-stream RFCs, and
still others may deliver reports, white papers, academic journal
articles, or even carry out relevant high-level discussions that
aren't ever published but influence other research. IRTF RGs are
successful when they stimulate discussion, produce relevant outputs,
and impact the research community.
IETF WG deliverables tend to be specific protocol, deployment, and
operational specifications, along with problem statements, use cases,
requirements, and architectures that inform those specifications.
Almost all IETF working groups are chartered to deliver Internet
standards, which isn't an option for IRTF RGs.
<span class="h3"><a class="selflink" id="section-2.8" href="#section-2.8">2.8</a>. Completion</span>
IRTF RGs may produce the outputs they expected to produce when they
were chartered, but it also happens that researchers consider what
they've learned and start work on better solutions. This can happen
whether or not the research underway has been completed, and the
process can continue until the RG itself decides that it is time to
conclude or when the IRTF Chair determines that there is no more
energy in the group to do research.
IETF WGs will typically conclude when they meet their chartered
milestones, allowing participants to focus on implementation and
deployment, although the WG mailing list may remain open for a time.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Now That You Know What Not to Do</span>
The current IRTF Chair, Lars Eggert, is fond of saying, "Just act
like an IRTF research group for a year, and we'll see if you are
one."
There are many ways to "act like an IRTF research group". [<a href="./rfc4440" title=""IAB Thoughts on the Role of the Internet Research Task Force (IRTF)"">RFC4440</a>]
contains a number of points to consider when proposing a new RG.
Some possibilities include:
1. Identify and recruit a critical mass of researchers who can
review and build off each other's work.
2. Identify other venues that may overlap the proposed RG, and
understand what value the proposed RG provides beyond what's
already underway elsewhere.
<span class="grey">Dawkins Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7418">RFC 7418</a> IRTF Primer for IETF December 2014</span>
3. Hold a workshop to survey work that might set the stage for a RG
on questions of interest, perhaps in concert with existing
academic events.
4. If the proposed RG expects to have outputs that will ultimately
be standardized in the IETF, identify and recruit engineers who
can review and provide feedback on intermediate results.
But every proposed RG is different, so e-mailing the IRTF Chair to
start the conversation is a perfectly reasonable strategy.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Security Considerations</span>
This document provides guidance about the IRTF chartering process to
IETF participants and has no direct Internet security implications.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. References</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Normative References</span>
[<a id="ref-RFC2014">RFC2014</a>] Weinrib, A. and J. Postel, "IRTF Research Group Guidelines
and Procedures", <a href="https://www.rfc-editor.org/bcp/bcp8">BCP 8</a>, <a href="./rfc2014">RFC 2014</a>, October 1996,
<<a href="http://www.rfc-editor.org/info/rfc2014">http://www.rfc-editor.org/info/rfc2014</a>>.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Informative References</span>
[<a id="ref-RFC4440">RFC4440</a>] Floyd, S., Paxson, V., Falk, A., and IAB, "IAB Thoughts on
the Role of the Internet Research Task Force (IRTF)", <a href="./rfc4440">RFC</a>
<a href="./rfc4440">4440</a>, March 2006,
<<a href="http://www.rfc-editor.org/info/rfc4440">http://www.rfc-editor.org/info/rfc4440</a>>.
[<a id="ref-RFC5434">RFC5434</a>] Narten, T., "Considerations for Having a Successful Birds-
of-a-Feather (BOF) Session", <a href="./rfc5434">RFC 5434</a>, February 2009,
<<a href="http://www.rfc-editor.org/info/rfc5434">http://www.rfc-editor.org/info/rfc5434</a>>.
[<a id="ref-RFC6771">RFC6771</a>] Eggert, L. and G. Camarillo, "Considerations for Having a
Successful "Bar BOF" Side Meeting", <a href="./rfc6771">RFC 6771</a>, October
2012, <<a href="http://www.rfc-editor.org/info/rfc6771">http://www.rfc-editor.org/info/rfc6771</a>>.
[<a id="ref-RFC7282">RFC7282</a>] Resnick, P., "On Consensus and Humming in the IETF", <a href="./rfc7282">RFC</a>
<a href="./rfc7282">7282</a>, June 2014, <<a href="http://www.rfc-editor.org/info/rfc7282">http://www.rfc-editor.org/info/rfc7282</a>>.
<span class="grey">Dawkins Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7418">RFC 7418</a> IRTF Primer for IETF December 2014</span>
Acknowledgements
Thanks go to Lars Eggert, who became IRTF Chair in 2011 and has been
carrying this information around in his head ever since. Lars also
provided helpful comments on early versions of this document.
Thanks especially to Fred Baker for sharing thoughts about the
motivations of research and engineering that resulted in a complete
rewrite of <a href="#section-2.1">Section 2.1</a>.
Thanks also to Scott Brim, Kevin Fall, Eliot Lear, David Meyer, and
Stephen Farrell for providing helpful review comments, and to Denis
Ovsienko for careful proofreading.
Author's Address
Spencer Dawkins (editor)
Huawei Technologies
EMail: spencerdawkins.ietf@gmail.com
Dawkins Informational [Page 7]
</pre>
|
