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
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
|
<pre>Network Working Group A. Mankin
Request for Comments: 2357 USC/ISI
Category: Informational A. Romanow
MCI
S. Bradner
Harvard University
V. Paxson
LBL
With the TSV
Area Directorate
June 1998
<span class="h1">IETF Criteria for Evaluating Reliable Multicast Transport</span>
<span class="h1">and Application Protocols</span>
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract
This memo describes the procedures and criteria for reviewing
reliable multicast protocols within the Transport Area (TSV) of the
IETF. Within today's Internet, important applications exist for a
reliable multicast service. Some examples that are driving reliable
multicast technology are collaborative workspaces (such as
whiteboard), data and software distribution, and (more speculatively)
web caching protocols. Due to the nature of the technical issues, a
single commonly accepted technical solution that solves all the
demands for reliable multicast is likely to be infeasible [RMMinutes
1997].
A number of reliable multicast protocols have already been developed
to solve a variety of problems for various types of applications.
[<a href="#ref-Floyd97" title=" L.">Floyd97</a>] describes one widely deployed example. How should these
protocols be treated within the IETF and how should the IETF guide
the development of reliable multicast in a direction beneficial for
the general Internet?
<span class="grey">Mankin, et. al. Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc2357">RFC 2357</a> Evaluating Reliable Multicast June 1998</span>
The TSV Area Directors and their Directorate have outlined a set of
review procedures that address these questions and set criteria and
processes for the publication as RFCs of Internet-Drafts on reliable
multicast transport protocols.
<span class="h3"><a class="selflink" id="section-1.0" href="#section-1.0">1.0</a> Background on IETF Processes and Procedures</span>
In the IETF, work in an area is directed and managed by the Area
Directors (ADs), who have authority over the chartering of working
groups (WGs).
In addition, ADs review individually submitted (not by WGs)
Internet-Drafts about work that is relevant to their areas prior to
publication as RFCs (Experimental, Informational or, in rare cases,
Standards Track). The review is done according to the guidelines set
out in the Internet Standards Process, <a href="./rfc2026">RFC 2026</a> [<a href="#ref-InetStdProc96" title=""The Internet Standards Process -- Revision 3"">InetStdProc96</a>].
The purpose of this document is to present the criteria that will be
used by the TSV ADs in reviewing reliable multicast Internet-Drafts
for any form of RFC publication.
For I-Ds submitted for Standards Track publication, these criteria
must be met or else the ADs will decline to support publication of
the document, which suffices to prevent publication. For I-Ds
submitted as Experimental or Informational, these criteria must be
met or else, at a minimum, the Ads will recommend publishing the I-D
with an IESG note prepended stating that the protocol fails to comply
with these criteria.
<span class="h3"><a class="selflink" id="section-2.0" href="#section-2.0">2.0</a> Introduction</span>
There is a strong application demand for reliable multicast.
Widespread use of the Internet makes the economy of multicast
transport attractive. The current Internet multicast model offers
best-effort many-to-many delivery service and offers no guarantees.
One-to-many and few-to-few services may become more important in the
future. Reliable multicast transports add delivery guarantees, not
necessarily like those of reliable unicast TCP, to the group-delivery
model of multicast. A panel of some major users of the Internet,
convened at the 38th IETF, articulated reliable bulk transfer
multicast as one of their most critical requirements [<a href="#ref-DiffServBOF97">DiffServBOF97</a>].
Examples of applications that could use reliable bulk multicast
transfer include collaborative tools, distributed virtual reality,
and software upgrade services.
To meet the growing demand for reliable multicast, there is a large
number of protocol proposals. A few were published as RFCs before
the impact of congestion from reliable multicast was fully
<span class="grey">Mankin, et. al. Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc2357">RFC 2357</a> Evaluating Reliable Multicast June 1998</span>
appreciated, and these should be deprecated [<a href="#ref-DeprRFCs" title=""Multicast Transport Protocol"">DeprRFCs</a>]. Two surveys
of other publications are [<a href="#ref-DiotCrow97" title="J.">DiotCrow97</a>], [<a href="#ref-Obraczka98" title="K.">Obraczka98</a>].
As we discuss in <a href="#section-3">Section 3</a>, the issues raised by reliable multicast
are considerably more complex than those related to reliable unicast.
In particular, in today's Internet, reliable multicast protocols
could do great damage through causing congestion disasters if they
are widely used and do not provide adequate congestion control.
Because of the complexity of the technical issues, and the abundance
of proposed solutions, we are putting in place review procedures that
are more explicit than usual. We compare this action with an IESG
action taken in 1991, <a href="./rfc1264">RFC 1264</a> [<a href="#ref-Routing91" title=""Internet Routing Protocol Standardization Criteria"">Routing91</a>], when community experience
with standard Internet dynamic routing protocols was still limited,
and extra review was deemed necessary to assure that the protocols
introduced would be effective, correct and robust.
<a href="#section-3">Section 3</a> describes in detail the nature of the particular challenges
posed by reliable multicast. <a href="#section-4">Section 4</a> describes the process for
considering reliable multicast solutions. <a href="#section-5">Section 5</a> details the
additional requirements that need to be met by proposals to be
published as Standards Track RFCs.
<span class="h3"><a class="selflink" id="section-3.0" href="#section-3.0">3.0</a> Issues in Reliable Multicast</span>
Two aspects of reliable multicast make standardization particularly
challenging. First, the meaning of reliability varies in the context
of different applications. Secondly, if special care is not taken,
reliable multicast protocols can cause a particular threat to the
operation of today's global Internet. These issues are discussed in
detail in this section.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a> One or Many Reliable Multicast Protocols or Frameworks?</span>
Unlike reliable unicast, where a single transport protocol (TCP) is
currently used to meet the reliable delivery needs of a wide range of
applications, reliable multicast does not necessarily lend itself to
a single application interface or to a single underlying set of
mechanisms. For unicast transport, the requirements for reliable,
sequenced data delivery are fairly general. TCP, the primary
transport protocol for reliable unicast, is a mature protocol with
delivery semantics that suit a wide range of applications.
In contrast, different multicast applications have widely different
requirements for reliability. For example, some applications require
that message delivery obey a total ordering while others do not.
Some applications have many or all the members sending data while
others have only one data source. Some applications have replicated
<span class="grey">Mankin, et. al. Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc2357">RFC 2357</a> Evaluating Reliable Multicast June 1998</span>
data, for example in an n-redundant file store, so that several
members are capable of transmitting a data item, while for others all
data originates at a single source. Some applications are restricted
to small fixed-membership multicast groups, while other applications
need to scale dynamically to thousands or tens of thousands of
members (or possibly more). Some applications have stringent delay
requirements, while others do not. Some applications such as file-
transfer are high-bandwidth, while other applications such as
interactive collaboration tools are more likely to be bursty but use
low bandwidth overall. Some applications will sometimes trade off
less than complete reliability for more timely delivery. These
requirements each impact the design of reliable multicast protocols
in a different way.
In addition, even for a specific application where the application's
requirements for reliable multicast are well understood, there are
many open questions about the underlying mechanisms for providing
reliable multicast. A key question concerns the robustness of the
underlying reliable multicast mechanisms as the number of senders or
the membership of the multicast group grows.
One challenge to the IETF is to end up with the right match between
applications' requirements and reliable multicast mechanisms. While
there is general agreement that a single reliable multicast protocol
or framework is not likely to meet the needs of all Internet
applications, there is less understanding and agreement about the
exact relationship between application-specific requirements and more
generic underlying reliable mutlicast protocols or mechanisms. There
are also open questions about the appropriate integration between an
application and an underlying reliable multicast framework, and the
potential generality of a single applications interface for that
framework.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a> Congestion Control</span>
A particular concern for the IETF is the impact of reliable multicast
traffic on other traffic in the Internet in times of congestion, in
particular the effect of reliable multicast traffic on competing TCP
traffic. The success of the Internet relies on the fact that best-
effort traffic responds to congestion on a link (currently as
indicated by packet drops) by reducing the load presented to the
network. Congestion collapse in today's Internet is prevented only
by the congestion control mechanisms in TCP, standardized by <a href="./rfc2001">RFC 2001</a>
[<a href="#ref-CongAvoid97" title=""TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms"">CongAvoid97</a>, Jacobson88].
There are a number of reasons to be particularly attentive to the
congestion-related issues raised by reliable multicast proposals.
Multicast applications in general have the potential to do more
<span class="grey">Mankin, et. al. Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc2357">RFC 2357</a> Evaluating Reliable Multicast June 1998</span>
congestion-related damage to the Internet than do unicast
applications. One factor is that a single multicast flow can be
distributed along a large, global multicast tree reaching throughout
the entire Internet.
Unreliable multicast applications such as audio and video are, at the
moment, usually accompanied by a person at the receiving end, and
people typically unsubscribe from a multicast group if congestion is
so heavy that the audio or video stream is unintelligible. Reliable
multicast applications such as group file transfer applications, on
the other hand, are likely to be between computers, with no humans in
attendance monitoring congestion levels.
In addition, reliable multicast applications do not necessarily have
the natural time limitations typical of current unreliable multicast
applications. For a file transfer application, for example, the data
transfer might continue until all of the data is transferred to all
of the intended receivers, resulting in a potentially-unlimited
duration for an individual flow. Reliable multicast applications
also have to contend with a potential explosion of complex patterns
of control traffic (e.g., ACKs, NACKs, status messages). The design
of congestion control mechanisms for reliable multicast for large
multicast groups is currently an area of active research.
The challenge to the IETF is to encourage research and
implementations of reliable multicast, and to enable the needs of
applications for reliable multicast to be met as expeditiously as
possible, while at the same time protecting the Internet from the
congestion disaster or collapse that could result from the widespread
use of applications with inappropriate reliable multicast mechanisms.
Because of the setbacks and costs that could result from the
widespread deployment of reliable multicast with inadequate
congestion control, the IETF must exercise care in the
standardization of a reliable multicast protocol that might see
widespread use.
The careful review and cautious acceptance procedures for proposals
submitted as Internet-Drafts reflects our concern to meet the
challenges described here.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. IETF Process for Review and Publication of Reliable Multicast</span>
<span class="h2"> Protocol Specifications</span>
In the general case of individually submitted Internet-Drafts
(proposals not produced by an IETF WG), the process of publication as
some type of RFC is described in <a href="./rfc2026">RFC 2026</a> (4.2.3) [<a href="#ref-InetStdProc96" title=""The Internet Standards Process -- Revision 3"">InetStdProc96</a>].
This specifies that if the submitted Internet-Draft is closely
related to work being done or expected to be done in the IETF, the
<span class="grey">Mankin, et. al. Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc2357">RFC 2357</a> Evaluating Reliable Multicast June 1998</span>
ADs may recommend that the document be brought within the IETF and
progressed in the IETF context. Otherwise, the ADs may recommend
that the Internet-Draft be published as an Experimental or
Informational RFC, with or without an IESG annotation of its
relationship to the IETF context.
The procedure for Reliable Multicast proposal publication will have
as its default RFC status Experimental, when the technical criteria
listed in <a href="#section-5">Section 5</a> are deemed to be fulfilled. Both the criteria and
the procedure reflect the AD's technical assessment of the current
state of reliable multicast technology. It does not reflect the
origins of the proposals, which we expect will be equally from
commercial vendors with initial products and from researchers.
Work on the development and engineering of protocols that may
eventually meet the review criteria could take place either in the
IRTF Reliable Multicast Research Group (<a href="http://www.irtf.org">http://www.irtf.org</a>) or a
focused short IETF WG with an Experimental product.
When the work in reliable multicast technology has matured enough to
be considered for standardization within the IETF, the TSV Area may
charter appropriate working groups to develop standards track
documents. The criteria for evaluation of standards track technology
will be at least as stringent as those described herein (next
section).
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Technical Criteria for Reliable Multicast</span>
The Internet-Draft must (in itself or a companion draft):
a. Analyze the behavior of the protocol.
The vulnerabilities and performance problems must be shown through
analysis. Especially the protocol behavior must be explained in
detail with respect to scalability, congestion control, error
recovery, and robustness.
For example the following questions should be answered:
How scalable is the protocol to the number of senders or
receivers in a group, the number of groups, and wide dispersion
of group members?
Identify the mechanisms which limit scalability and estimate
those limits.
How does the protocol protect the Internet from congestion? How
well does it perform? When does it fail?
<span class="grey">Mankin, et. al. Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc2357">RFC 2357</a> Evaluating Reliable Multicast June 1998</span>
Under what circumstances will the protocol fail to perform the
functions needed by the applications it serves?
Is there a congestion control mechanism? How well does it
perform? When does it fail? Note that congestion control
mechanisms that operate on the network more aggressively than
TCP will face a great burden of proof that they don't threaten
network stability.
b. Include a description of trials and/or simulations which support
the development of the protocol and the answers to the above
questions.
c. Include an analysis of whether the protocol has congestion
avoidance mechanisms strong enough to cope with deployment in the
Global Internet, and if not, clearly document the circumstances in
which congestion harm can occur. How are these circumstances to
be prevented?
d. Include a description of any mechanisms which contain the traffic
within limited network environments. If the analysis in a or c
shows that the protocol has potential to damage the Internet, then
the analysis must include a discussion of ways to limit the scope
or otherwise contain the protocol. We recognize that the
confinement of Internet applications is an open research area.
e. Reliable multicast protocols must include an analysis of how they
address a number of security and privacy concerns. If the
protocol can be used in different modes of secure operation, then
each mode must be analyzed.
The analysis must document which of the various parties --
senders, routers (more generally, data forwarders), receivers,
retransmission sources -- must be trusted in order to ensure
secure operation and privacy of the transmitted data, to what
degree, and why. (One issue to address here are "man-in-the-
middle" attacks.)
To what degree can data be manipulated so that at least a
subset of the receivers receive different copies? Does the
protocol allow a group of receivers to determine whether they
all received the same data?
What limitations are placed on the retransmission mechanism to
prevent it from being abused to flood network links with
excessive traffic? Which parties must be trusted to ensure
this, and to what degree, and why? The presumption will be that
either a congestion control mechanism will inherently limit the
volume of retransmission traffic, and that this limiting
<span class="grey">Mankin, et. al. Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc2357">RFC 2357</a> Evaluating Reliable Multicast June 1998</span>
influence is robust under concerted attack; or that
retransmission requests will be signed in a cryptographically
strong manner so that abuses of the mechanism can be traced
back to their source. Protocols that do not provide either of
these forms of protection face a great burden of proof that
they don't threaten network stability.
What sort of key management does the protocol require, and
provide for?
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
This memo specifies in <a href="#section-5">Section 5</a>.e. that reliable multicast
Internet-Drafts reviewed by the Transport Area Directors must
explicitly explore the security aspects of the proposed design.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Acknowledgments</span>
Sally Floyd, Steve McCanne, Mark Handley, Steve Bellovin and Mike
Reiter gave especially helpful comments on drafts of this document.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
[RMMinutes 1997] Minutes the Second Reliable Multicast Research
Group Meeting. September 1997. <a href="http://www.east.isi.edu/rm">http://www.east.isi.edu/rm</a>
[<a id="ref-Floyd97">Floyd97</a>] Floyd, S., Jacobson, V., Liu, C., McCanne, S., and Zhang,
L., A Reliable Multicast Framework for Light-weight Sessions and
Application Level Framing. IEEE/ACM Transactions on Networking,
December 1997 An online version of the paper is at
<a href="http://ee.lbl.gov/floyd/srm-paper.html">http://ee.lbl.gov/floyd/srm-paper.html</a>.
[<a id="ref-InetStdProc96">InetStdProc96</a>] Bradner, S., "The Internet Standards Process --
Revision 3", <a href="./rfc2026">RFC 2026</a>, October 1996.
[<a id="ref-DiffServBOF97">DiffServBOF97</a>] [6] <a href="http://www.ietf.org/proceedings/97apr">http://www.ietf.org/proceedings/97apr</a> -
Transport Area - FDDIFS BOF, April 1997.
[<a id="ref-DeprRFCs">DeprRFCs</a>] Freier, A., "Multicast Transport Protocol", <a href="./rfc1301">RFC 1301</a>,
February 1992. and Braudes, R., and S. Zabele, "Requirements for
Multicast Protocols", <a href="./rfc1458">RFC 1458</a>, May 1993.
[<a id="ref-DiotCrow97">DiotCrow97</a>] Diot, C., Crowcroft, J., Multicast Transport Survey.
Journal of Selected Areas in Communications, 1997.
[<a id="ref-Obraczka98">Obraczka98</a>] Obraczka, K., Multicast Transport Mechanisms: A Survey
and Taxonomy. To appear in IEEE Communications, 1998.
<span class="grey">Mankin, et. al. Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc2357">RFC 2357</a> Evaluating Reliable Multicast June 1998</span>
[<a id="ref-Routing91">Routing91</a>] Hinden, R., and Internet Engineering Task Force,
"Internet Routing Protocol Standardization Criteria", <a href="./rfc1264">RFC 1264</a>,
October 1991.
[<a id="ref-CongAvoid97">CongAvoid97</a>] Stevens, W., "TCP Slow Start, Congestion Avoidance,
Fast Retransmit, and Fast Recovery Algorithms", <a href="./rfc2001">RFC 2001</a>, January
1997.
[Jacobson 1988] Jacobson, V., Congestion Avoidance and Control,
Proceedings of SIGCOMM '88, August 1988, pp. 314-329. An updated
version of this paper is available at
"<a href="ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z">ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z</a>".
<span class="grey">Mankin, et. al. Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc2357">RFC 2357</a> Evaluating Reliable Multicast June 1998</span>
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Authors' Addresses</span>
Allison Mankin - Past TSV Area Director
USC/ISI East
4350 N. Fairfax Dr., Suite 620
Arlington VA 22203
USA
Phone: 703 812 3706
EMail: mankin@east.isi.edu
Allyn Romanow - Past TSV Area Director
MCI Corporation
2560 North First Street
San Jose, CA 9531
USA
Phone: 408 922 7143
EMail: allyn@mci.net
Scott Bradner - TSV Co-Area Director
Harvard University
1350 Mass. Ave., Rm. 876
Cambridge MA 02138
USA
Phone: 617 495 3864
EMail: sob@harvard.edu
Vern Paxson - TSV Co-Area Director
MS 50B/2239
Lawrence Berkeley National Laboratory
University of California
Berkeley, CA 94720
USA
Phone: 510-486-7504
EMail: vern@ee.lbl.gov
<span class="grey">Mankin, et. al. Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc2357">RFC 2357</a> Evaluating Reliable Multicast June 1998</span>
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Full Copyright Statement</span>
Copyright (C) The Internet Society (1998). 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.
Mankin, et. al. Informational [Page 11]
</pre>
|
