RFC 1882! The 12-Days of Technology Before Christmas!

.
What follows is another in a series of Requests For Comment that the TELNET NEWS/LAND LINE LID THIS WEEK has unearthed at various information repositories. RFCs are documents composed and written detailing certain standards or operational protocols for use within the Internet community. Some of these otherwise dry commentaries may actually make for some unusual, if not interesting reading.
.
RFC 1882 - The 12-Days of Technology Before Christmas
.
Network Working Group B. Hancock
Request for Comments: 1882 Network-1 Software and Technology, Inc.
Category: Informational December 1995
.
The 12-Days of Technology Before Christmas
.
Status of this Memo
.
This memo provides information for the Internet community. This memo does not
specify an Internet standard of any kind. Distribution of this memo is
unlimited.
.
Discussion
.
On the first day of Christmas, technology gave to me:
A database with a broken b-tree (what the hell is a b-tree anyway?)
.
On the second day of Christmas, technology gave to me:
Two transceiver failures (CRC errors? Collisions? What is going on?)
And a database with a broken b-tree (Rebuild WHAT? It's a 10GB database!)
.
On the third day of Christmas, technology gave to me:
Three French users (who, of course, think they know everything)
Two transceiver failures (which are now spewing packets all over the net)
And a database with a broken b-tree (Backup? What backup?)
.
On the fourth day of Christmas, technology gave to me:
Four calls for support (playing the same Christmas song over and over)
Three French users (Why do they like to argue so much over trivial things?)
Two transceiver failures (How the hell do I know which ones they are?)
And a database with a broken b-tree (Pointer error? What's a pointer error?)
.
On the fifth day of Christmas, technology gave to me:
Five golden SCSI contacts (Of course they're better than silver!)
Four support calls (Ever notice how time stands still when on hold?
Three French users (No, we don't have footpedals on PC's. Why do you ask?)
Two transceiver failures (If I knew which ones were bad, I would know which ones to fix!)
And a database with a broken b-tree (Not till next week? Are you nuts?!?!)
.
On the sixth day of Christmas, technology gave to me:
Six games a-playing (On the production network, of course!)
Five golden SCSI contacts (What do you mean "not terminated!")
Four support calls (No, don't transfer me again - do you HEAR? Damn!)
Three French users (No, you cannot scan in by putting the page to the screen...)
Two transceiver failures (I can't look at the LEDs - they're in the ceiling!)
And a database with a broken b-tree (Norway? That's where this was written?)
.
On the seventh day of Christmas, technology gave to me:
Seven license failures (Expired? When?)
Six games a-playing (Please stop tying up the PBX to talk to each other!)
Five golden SCSI contacts (What do you mean I need "wide" SCSI?)
Four support calls (At least the Muzak is different this time...)
Three French Users (Well, monsieur, there really isn't an "any" key, but...)
Two transceiver failures (SQE? What is that? If I knew I would set it myself!)
And a database with a broken b-tree (No, I really need to talk to Lars - NOW!)
.
On the eighth day of Christmas, technology gave to me:
Eight MODEMs dialing (Who bought these? They're a security violation!)
Seven license failures (How many WEEKS to get a license?)
Six games a-playing (What do you mean one pixel per packet on updates?!?)
Five golden SCSI contacts (Fast SCSI? It's supposed to be fast, isn't it?)
Four support calls (I already told them that! Don't transfer me back - DAMN!)
Three French users (No, CTL-ALT-DEL is not the proper way to end a program)
Two transceiver failures (What do you mean "babbling transceiver"?)
And a database with a broken b-tree (Does anyone speak English in Oslo?)
.
On the ninth day of Christmas, technology gave to me:
Nine lady executives with attitude (She said do WHAT with the servers?)
Eight MODEMs dialing (You've been downloading WHAT?)
Seven license failures (We sent the P.O. two months ago!)
Six games a-playing (HOW many people are doing this to the network?)
Five golden SCSI contacts (What do you mean two have the same ID?)
Four support calls (No, I am not at the console - I tried that already.)
Three French users (No, only one floppy fits at a time? Why do you ask?)
Two transceiver failures (Spare? What spare?)
And a database with a broken b-tree (No, I am trying to find Lars! L-A-R-S!)
.
On the tenth day of Christmas, technology gave to me:
Ten SNMP alerts flashing (What is that Godawful beeping?)
Nine lady executives with attitude (No, it used to be a mens room? Why?)
Eight MODEMs dialing (What Internet provider? We don't allow Internet here!)
Seven license failures (SPA? Why are they calling us?)
Six games a-playing (No, you don't need a graphics accelerator for Lotus!)
Five golden SCSI contacts (You mean I need ANOTHER cable?)
Four support calls (No, I never needed an account number before...)
Three French users (When the PC sounds like a cat, it's a head crash!)
Two transceiver failures (Power connection? What power connection?)
And a database with a broken b-tree (Restore what index pointers?)
.
On the eleventh day of Christmas, technology gave to me:
Eleven boards a-frying (What is that terrible smell?)
Ten SNMP alerts flashing (What's a MIB, anyway? What's an extension?)
Nine lady executives with attitude (Mauve? Our computer room tiles in mauve?)
Eight MODEMs dialing (What do you mean you let your roommate dial-in?)
Seven license failures (How many other illegal copies do we have?!?!)
Six games a-playing (I told you - AFTER HOURS!)
Five golden SCSI contacts (If I knew what was wrong, I wouldn't be calling!)
Four support calls (Put me on hold again and I will slash your credit rating!)
Three French users (Don't hang your floppies with a magnet again!)
Two transceiver failures (How should I know if the connector is bad?)
And a database with a broken b-tree (I already did all of that!)
.
On the twelfth day of Christmas, technology gave to me:
Twelve virtual pipe connections (There's only supposed to be two!)
Eleven boards a-frying (What a surge suppressor supposed to do, anyway?)
Ten SNMP alerts flashing (From a distance, it does kinda look like XMas lights.)
Nine lady executives with attitude (What do you mean aerobics before backups?)
Eight MODEMs dialing (No, we never use them to connect during business hours.)
Seven license failures (We're all going to jail, I just know it.)
Six games a-playing (No, no - my turn, my turn!)
Five golden SCSI contacts (Great, just great! Now it won't even boot!)
Four support calls (I don't have that package! How did I end up with you!)
Three French users (I don't care if it is sexy, no more nude screen backgrounds!)
Two transceiver failures (Maybe we should switch to token ring...)
And a database with a broken b-tree (No, operator - Oslo, Norway. We were just
talking and were cut off...)
.
Security Considerations
.
Security issues are not discussed in this memo.
.
Author's Address
.
Bill Hancock, Ph.D.
Network-1 Software & Technology, Inc.
DFW Research Center
878 Greenview Dr.
Grand Prairie, TX 75050
EMail: hancock@network-1.com
Phone: (214) 606-8200
Fax: (214) 606-8220
.
Comment on RFC 1882
.
Previous: RFC 1881 - IPv6 Address Allocation Management Next: RFC 1883 -
Internet Protocol, Version 6 (IPv6) Specification

RFC 1925! The Twelve Networking Truths!

What follows is another in a series of "Requests For Comment" that the TELNET NEWS/LAND LINE LID THIS WEEK has unearthed at various information repositories. RFCs are documents composed and written detailing certain standards or operational protocols for use within the Internet community. Some of these otherwise dry commentaries may actually make for some unusual if not interesting reading.

.

.
RFC 1925 - The Twelve Networking Truths
Network Working Group R. Callon, Editor
Request for Comments: 1925 IOOF
Category: Informational 1 April 1996
The Twelve Networking Truths

.
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

.
Abstract
This memo documents the fundamental truths of networking for the
Internet community. This memo does not specify a standard, except in
the sense that all standards must implicitly follow the fundamental
truths.

.
Acknowledgements
The truths described in this memo result from extensive study over an
extended period of time by many people, some of whom did not intend
to contribute to this work. The editor merely has collected these
truths, and would like to thank the networking community for
originally illuminating these truths.

.
1. Introduction
This Request for Comments (RFC) provides information about the
fundamental truths underlying all networking. These truths apply to
networking in general, and are not limited to TCP/IP, the Internet,
or any other subset of the networking community.

.
2. The Fundamental Truths
(1) It Has To Work.

.
(2) No matter how hard you push and no matter what the priority,
you can't increase the speed of light.
(2a) (corollary). No matter how hard you try, you can't make a
baby in much less than 9 months. Trying to speed this up
*might* make it slower, but it won't make it happen any
quicker.

.
(3) With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they
are going to land, and it could be dangerous sitting under them
as they fly overhead.

.
(4) Some things in life can never be fully appreciated nor
understood unless experienced firsthand. Some things in
networking can never be fully understood by someone who neither
builds commercial networking equipment nor runs an operational
network.

.
(5) It is always possible to aglutenate multiple separate problems
into a single complex interdependent solution. In most cases
this is a bad idea.

.
(6) It is easier to move a problem around (for example, by moving
the problem to a different part of the overall network
architecture) than it is to solve it.
(6a) (corollary). It is always possible to add another level of
indirection.

.

(7) It is always something
(7a) (corollary). Good, Fast, Cheap: Pick any two (you can't
have all three).

.
(8) It is more complicated than you think.

.
(9) For all resources, whatever it is, you need more.

(9a) (corollary) Every networking problem always takes longer to
solve than it seems like it should.

.
(10) One size never fits all.

.
(11) Every old idea will be proposed again with a different name and
a different presentation, regardless of whether it works.
(11a) (corollary). See rule 6a.

.
(12) In protocol design, perfection has been reached not when there
is nothing left to add, but when there is nothing left to take
away.

.
Security Considerations
This RFC raises no security issues. However, security protocols are
subject to the fundamental networking truths.

.
References
The references have been deleted in order to protect the guilty and
avoid enriching the lawyers.

.
Author's Address
Ross Callon
Internet Order of Old Farts
c/o Bay Networks
3 Federal Street
Billerica, MA 01821
Phone: 508-436-3936
EMail: rcallon@baynetworks.com
.
Comment on RFC 1925
Comments about this RFC:
RFC 1925: Rule #1 of being pedantic: If you are going to use overly
large words to... by Jen (7/15/2003)
.
Previous: RFC 1924 - A Compact Representation of IPv6 Addresses Next: RFC
1926 - An Experimental Encapsulation of IP Datagrams on Top of ATM

RFC 1097 - Telnet Subliminal-Message Option!

What follows is the first in a series of "Requests For Comment" that the TELNET NEWS/LAND LINE LID THIS WEEK has unearthed at various information repositories. RFCs are documents composed and written detailing certain standards or operational protocols for use within the Internet community.Some of these otherwise dry commentaries may actually make for some unusual if not interesting reading.

RFC 1097 (rfc1097) - Telnet subliminal-message option
RFC 1097 (RFC1097)

Internet RFC/STD/FYI/BCP Archives
[ RFC Index RFC Search Usenet FAQs Web FAQs Documents Cities ]
Alternate Formats: rfc1097.txt rfc1097.txt.pdf
Comment on RFC 1097
RFC 1097 - Telnet subliminal-message option
Network Working Group B. Miller
Request for Comments: 1097 CMU-NetDev
1 April 1989
TELNET SUBLIMINAL-MESSAGE Option

Status of this Memo
This RFC specifies a standard for the Internet community. Hosts on
the Internet that display subliminal messages within the Telnet
protocol are expected to adopt and implement this standard.
Distribution of this memo is unlimited.

1. Command name and code.
SUBLIMINAL-MESSAGE 257

2. Command meanings.

IAC WILL SUBLIMINAL-MESSAGE
The sender of this command REQUESTS permission to, or confirms
that it will, display subliminal messages.
IAC WONT SUBLIMINAL-MESSAGE
The sender of this command REFUSES to display subliminal messages.
IAC DO SUBLIMINAL-MESSAGE
The sender of this command REQUESTS that the receiver, or grants
the receiver permission to, display subliminal messages.
IAC DONT SUBLIMINAL-MESSAGE
The sender of this command DEMANDS that the receiver not

display subliminal messages.
IAC SB SUBLIMINAL-MESSAGE <16-bit> <16-bit> IA SE
The sender specifies a message to be subliminally displayed by the
remote host. If the client has agreed (via the standard WILL WONT
DO DONT mechanism) to display subliminal messages, it must accept
this subnegotiation and attempt to display the message string on
the users console for the specified duration and continue to do so
at fixed intervals until another SUBLIMINAL-MESSAGE subnegotiation
is received. The position and rendering of the message of
implementation dependent.

The first 16-bit value specifies the duration of the message in
milliseconds. It is sent MSB first. The second 16-bit value
specifies the frequency with which the message is displayed. It
represents the number of seconds between displays and is also sent
MSB first. The final parameter is the message itself.

The syntax for this subnegotiation is:
IAC SB SUBLIMINAL-MESSAGE
DURATION[1] DURATION[0]
FREQUENCY[1] FREQUENCY[0]
MESSAGE_STRING
IAC SE
As required by the Telnet protocol, any occurrence of 255 in the
subnegotiation must be doubled to distinguish it from the IAC
character (which has a value of 255).

3. Default.
WONT SUBLIMINAL-MESSAGE
DONT SUBLIMINAL-MESSAGE
i.e., subliminal messages will not be displayed.

4. Motivation for the option
Frequently the use of "Message of the day" banners and newsletters is
insufficient to convince stubborn users to upgrade to the latest
version of telnet. Some users will use the same outdated version for
years. I ran across this problem trying to convince people to use
the REMOTE-FLOW-CONTROL Telnet option. These users need to be gently
"persuaded".

5. Description and implementation notes.
The quality of the client implementation will depend on it's ability
to display and erase text strings in a small amount of time. The
current implementation at CMU takes into account terminal line speed,
advanced video capabilities, and screen phosphor persistence when
calculating how long to wait before erasing a message.
While it is permitted for the client to display the message text
"in-line", best results at obtained by printing the message at the
top or side of console screen where it will just catch the corner of
the user's visual field.

A version is currently under development at CMU to display the
message using Morse-code over the keyboard caps-lock LED.

6. Examples
In the following example all numbers are in decimal notation.

1. Server suggests and client agrees to use SUBLIMINAL-MESSAGE.
(Server sends) IAC DO SUBLIMINAL-MESSAGE
(Client sends) IAC WILL SUBLIMINAL-MESSAGE
(Server sends) IAC SB SUBLIMINAL-MESSAGE 0 5 0 20 "Use VMS" IAC SE
[The server is "suggesting" that the user employ a stable
operating system, not an unreasonable request...]
The client should immediately begin displaying the message and
should continue to do so at regular intervals.

2. Server preempts previous subliminal message.
(Server sends) IAC SB SUBLIMINAL-MESSAGE 0 5 0 20 "Go home" IAC SE
The client should now no longer display the previous message and
should immediately begin displaying the new one.

3. Server has messed with user enough for one day.
(Server sends) IAC SB SUBLIMINAL-MESSAGE 0 0 0 0 "" IAC SE
The client must cease display of any subliminal messages.

7. Acknowledgements.
We do things just a little sneakier here at CMU.

Comment on RFC 1097
Previous: RFC 1096 - Telnet X display location option Next: RFC 1098
Simple Network Management Protocol (SNMP)