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
|
<pre>Network Working Group A. Farrel
Request for Comments: 4041 Old Dog Consulting
Category: Informational 1 April 2005
<span class="h1">Requirements for Morality Sections in Routing Area Drafts</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 (2005).
Abstract
It has often been the case that morality has not been given proper
consideration in the design and specification of protocols produced
within the Routing Area. This has led to a decline in the moral
values within the Internet and attempts to retrofit a suitable moral
code to implemented and deployed protocols has been shown to be
sub-optimal.
This document specifies a requirement for all new Routing Area
Internet-Drafts to include a "Morality Considerations" section, and
gives guidance on what that section should contain.
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
It is well accepted by popular opinion and other reliable metrics
that moral values are declining and that degeneracy is increasing.
Young people are particularly at risk from the rising depravity in
society and much of the blame can be squarely placed at the door of
the Internet. If you do not feel safe on the streets at night, what
do you think it is like on the Information Superhighway?
When new protocols or protocol extensions are developed within the
Routing Area, it is often the case that not enough consideration is
given to the impact of the protocol on the moral fiber of the
Internet. The result is that moral consequences are only understood
once the protocols have been implemented, and sometimes not until
after they have been deployed.
<span class="grey">Farrel Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4041">RFC 4041</a> Routing Morality Section Requirements 1 April 2005</span>
The resultant attempts to restore appropriate behavior and purge the
community of improper activities are not always easy or
architecturally pleasant. Further, it is possible that certain
protocol designs make morality particularly hard to achieve.
Recognising that moral issues are fundamental to the utility and
success of protocols designed within the IETF, and that simply making
a wishy-washy liberal-minded statement does not necessarily provide
adequate guarantees of a correct and proper outcome for society, this
document defines requirements for the inclusion of Morality
Considerations sections in all Internet-Drafts produced within the
Routing Area. Meeting these requirements will ensure that proper
consideration is given to moral issues at all stages of the protocol
development process, from Requirements and Architecture, through
Specification and Applicability.
The remainder of this document describes the necessary subsections of
the Morality Considerations sections, and gives guidance about what
information should be contained in those subsections.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Conventions Used in This Document</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <a href="./rfc2119">RFC 2119</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
The key words "SHALT", "SHALT NOT", "SMITE", and "PILLAR OF SALT" in
this document are to be interpreted as expected.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Presence and Placement of Morality Considerations Sections</span>
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Null Morality Considerations Sections</span>
It may be the case that the authors of Internet-Drafts have no or few
morals. This does not relieve them of their duty to understand the
consequences of their actions.
The more likely an author is to say that a null Morality
Considerations section is acceptable, the more pressure must be
exerted on him by the Area and the appropriate Working Group to
ensure that he gives full consideration to his actions, and reflects
long and hard on the consequences of his writing and the value of his
life.
On the other hand, some authors are well known to have the highest
moral pedigree: a fact that is plainly obvious from the company they
keep, the Working Groups they attend, and their eligibility for
NomCom. It is clearly unnecessary for such esteemed persons to waste
<span class="grey">Farrel Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4041">RFC 4041</a> Routing Morality Section Requirements 1 April 2005</span>
effort on Morality Considerations sections. It is inconceivable that
anything that they write would have anything other than a beneficial
effect on the Routing Area and the Internet in general.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Mandatory Subsections</span>
If the Morality Considerations section is present, it MUST contain at
least the following subsections. The content of these subsections is
surely self-evident to any right-thinking person. Further guidance
can be obtained from your moral guardian, your household gods, or
from any member of the IMM (Internet Moral Majority).
- Likelihood of misuse by depraved or sick individuals. This
subsection must fully address the possibility that the proposed
protocols or protocol extensions might be used for the
distribution of blue, smutty, or plain disgusting images.
- Likelihood of misuse by misguided individuals. There is an
obvious need to protect minors and people with misguided thought
processes from utilising the protocols or protocol extensions for
purposes that would inevitably do them harm.
- Likelihood of misuse by large, multi-national corporations. Such
a thought is, of course, unthinkable.
- Availability of oversight facilities. There are those who would
corrupt our morals motivated as they are by a hatred of the
freedom of Internet access with which we are graced. We place a
significant burden of responsibility on those who guard our
community from these evil-doers and it is only fitting that we
give them as much support as is possible. Therefore, all
encryption and obfuscation techniques MUST be excluded -
individuals who have nothing to hide need to fear the oversight of
those whose morals are beyond doubt.
- Inter-SDO impact. We must allow for other moral frameworks and
fully respect other people's right to subscribe to other belief
systems. Such people are, however, wrong and doomed to spend
eternity in a dark corner with only dial-up access. So it has
been written.
- Care and concern for avian carriers. A duck may be somebody's
mother.
Even if one or more of these subsections are considered irrelevant,
they MUST all still be present, and MUST contain a full rebuttal of
this deviant thought.
<span class="grey">Farrel Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4041">RFC 4041</a> Routing Morality Section Requirements 1 April 2005</span>
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. Optional Subsections</span>
Additional subsections may be added to accommodate zealots.
<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>. Placement of Morality Considerations Sections</span>
The Morality Considerations section MUST be given full prominence in
each Internet Draft.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Applicability Scenarios</span>
This section outlines, by way of example, some particular areas that
are in dire need of reform and where a short, sharp shock could make
a really big difference.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Provision of Services</span>
We must do our utmost to ensure that services are delivered in a
timely and reliable way. Emphasis should be placed on Quality of
Service (QoS) and meeting the needs of the consumer of the service.
Arrangements should be made for regular provision of services, and
sermons should be to the point and contain a strong moral message.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Political Correctness (PC)</span>
Political correctness has gone too far. This problem can be traced
way back to the 1970s when the desktop PC was invented. It is
necessary for Internet-Drafts to observe a form of political
correctness, but note that you do not always have to mean what you
say.
<span class="h4"><a class="selflink" id="section-3.2.1" href="#section-3.2.1">3.2.1</a>. Differentiated Services</span>
Segregation of packets on the grounds of color is now banned and
Internet-Drafts must not make use of this technique.
If you follow all of the recommendations in this document, you will
find that "packets of color" (as we must now refer to them) tend to
avoid your points of presence, and you will no longer be troubled by
them.
<span class="h4"><a class="selflink" id="section-3.2.2" href="#section-3.2.2">3.2.2</a>. Jumbo Packets</span>
It is no longer appropriate to refer to "jumbo packets". Please use
the term "capacitorially challenged".
<span class="grey">Farrel Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4041">RFC 4041</a> Routing Morality Section Requirements 1 April 2005</span>
<span class="h4"><a class="selflink" id="section-3.2.3" href="#section-3.2.3">3.2.3</a>. Byte Ordering</span>
Note that within Internet-Drafts, bytes (and bits) progress from the
left to the right. This is how things should be.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Protection or Abstinence</span>
Much has been made recently of the need to provide protection within
the Internet. It is the role of the IMM to determine when protection
is required, and the role of the IESG bulldogs to ensure that we are
all protected.
However, protection is only one way to prevent unplanned outages and,
as we all know, the ready availability of protection schemes such as
1:1 (one-on-one) or 1:n (orgy-mode) have lead to a belief that it is
acceptable to switch (or swing) at will. It should be noted that
protection can fail, and under no circumstances should extra traffic
be countenanced.
In reality, the only safe way to avoid passing data to your friends
is to agree to pledge to have no control plane before marriage. Join
our campaign and sign up for the SONET Ring Thing.
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Promiscuity</span>
Various disgusting protocols indulge in promiscuity. This appears to
happen most often when an operator is unwilling to select a single
partner and wants to play the field.
Promiscuous modes of operation are an abomination, exceeded only by
multicast.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Terminology</span>
Admission Control
The caring investigative arm of the IMM.
Doom
Port 666. Need we say more?
ECMP
What is this? Some kind of Communism?
Money
The root of all evil.
<span class="grey">Farrel Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4041">RFC 4041</a> Routing Morality Section Requirements 1 April 2005</span>
MPLS
What is with this "layer two-and-a-half" nonsense? The world is
flat, just accept the fact.
Packet Switching
Sounds like fraud to me.
Path
The route of all LSPs.
Policy Control
The administrative arm of the IMM.
Random Walk
Substance abuse is to be avoided.
Rendezvous Point
Poorly lit street corner. Not to be confused with the root of all
multicast.
Standard Body
What we should all strive for.
Strawberry Ice Cream
Something that wills the void between rational discussion and
all-out thermo nuclear war [<a href="#ref-SCREAM" title=""Observations on Proposing Protocol Enhancements that Address Stated Requirements but also go Further by Meeting more General Needs"">SCREAM</a>].
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Morality Considerations</span>
The moral pedigree of the author of this document places him and his
writings beyond question.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. IANA Considerations</span>
IANA should think carefully about the protection of their immortal
souls.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Security Considerations</span>
Security is of the utmost importance.
A secure Internet community will ensure the security of all of its
members.
<span class="grey">Farrel Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4041">RFC 4041</a> Routing Morality Section Requirements 1 April 2005</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Acknowledgements</span>
I would like to thank my guru Alex Dipandra-Zinin.
Jozef Wroblewski, who clearly knows promiscuous behavior when he sees
it, pointed out some of the dangers in promiscuous operation.
No avian carriers were harmed in the production of this document.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Intellectual Property Considerations</span>
Property is theft. What is yours is mine. What is mine, you keep
your hands off.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Normative References</span>
I don't need to be told how to formulate my morals.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. Informative References</span>
To be frank, I don't find many other documents informative.
[<a id="ref-SCREAM">SCREAM</a>] Farrel, A., "Observations on Proposing Protocol
Enhancements that Address Stated Requirements but also go
Further by Meeting more General Needs", Work in Progress,
June 2003.
Author's Address
Adrian Farrel
Old Dog Consulting
Phone: I'm not telling you that. Why do you ask, anyway?
EMail: adrian@olddog.co.uk
<span class="grey">Farrel Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc4041">RFC 4041</a> Routing Morality Section Requirements 1 April 2005</span>
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and at www.rfc-editor.org/copyright.html, and
except as set forth therein, the authors retain all their rights.
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.
Intellectual Property
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 <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
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
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Farrel Informational [Page 8]
</pre>
|
