>And if I don't really own the door, do they really own the money I paid for it with?
Actually, I was reading somewhere... was it a major periodical? One of my dad's lawyer magazines? Slashdot? Anyway, I was reading that the United States Government actually owns all money, and thus taxes of all sorts can be justified as a fee for letting you use the government's economic invention, "the dollar bill". The same article mentioned the guy who invented a major stock exchange, and charges a microscopic commission on transactions involving shares of stock.
Re:Linux, BSD, and everything need one thing....
on
Ark Linux
·
· Score: 1
This will undoubtedly arrive too late to be modded in either direction, but I just had to say it. Let me know if you ever see it, let me know what you think. Anyway: I beg to differ. Last time I fixed something on my parents' computer (isn't the Holy Grail of Linux on the desktop "accessible for older people?") they had several impressions. The first was that they were blinded by the speed of my clicking. I laugh at this, and maybe you do too, but my Grandmother told me the same thing when I was working on her computer. The second thing my parents wistfully observed was that they had been entirely lost ever since this newfangled Windows-thing came along. They (I say they-- each of them did it on separate occasions) said "I was pretty good at this stuff back when it was all DOS; but this Windows came along and I've never been the same since. My mom took computer classes in college and learned all about punch cards; my dad was copy-conning batch files before I knew what a C: prompt was. Lady and Gentlemen, I submit for your consideration that the rant everyone gives is flat-out wrong. Joe Sixpack and your grandmother can learn the command line and like it. Graphical so-called ease-of-use is not all it's cracked up to be.
No, the wings have a constant thickness, so weight will also increase as the square of the wing size. You're right about the motor-scaling bit, though.
Just look at my parents: They complain that they did just great at computers back when it was all DOS, CLI and stuff... ever since this newfangled Windows crap came along, they've just been kind of lost...
That's nothing. When I saw the single, capital letter H (in a slashdot context) I immediately interpolated as though it were an initial on an update at the bottom, reading thus: Sewage To Be Turned Into Hemos !
Now that the destruction of 4/1 is over, can we move on with our lives? We must all continue in our routine. If anything is disrupted, THEY have won. Help stomp out editorial terrorism.
I'm getting pretty sick of a lot of these complaints. Everybody still thinking about complaining, or even modding up a complainer-- Stand up for a second, step away from the keyboard, and ask yourself if this isn't going to be humonguously redundant-- more so than beatings with bad april-fool jokes. Then (still standing up) carefully step outside, (outside? you know, the "blue room" with a zillion polygons and rockin antialiasing?) and get (for one small day) a life of some sort. Seriously. Stop complaining about slashdot, and do something else for just a little while. If you think you're going to miss something, you can come back in a week and check it. But there's really no point in just complaining that you miss your usual tech&linux news fare. Because slashdot really turns into a different sort of place on april 1.
This document describes the Binary Lexical Octet Ad-hoc Transport
(BLOAT): a reformulation of a widely-deployed network-layer protocol
(IP [RFC791]), and two associated transport layer protocols (TCP
[RFC793] and UDP [RFC768]) as XML [XML] applications. It also
describes methods for transporting BLOAT over Ethernet and IEEE 802
networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
across the public Internet.
1.2. Motivation
The wild popularity of XML as a basis for application-level protocols
such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
Object Access Protocol [SOAP], and Jabber [JABBER] prompted
investigation into the possibility of extending the use of XML in the
protocol stack. Using XML at both the transport and network layer in
addition to the application layer would provide for an amazing amount
of power and flexibility while removing dependencies on proprietary
and hard-to-understand binary protocols. This protocol unification
would also allow applications to use a single XML parser for all
aspects of their operation, eliminating developer time spent figuring
out the intricacies of each new protocol, and moving the hard work of
parsing to the XML toolset. The use of XML also mitigates concerns
over "network vs. host" byte ordering which is at the root of many
network application bugs.
1.3. Relation to Existing Protocols
The reformulations specified in this RFC follow as closely as
possible the spirit of the RFCs on which they are based, and so MAY
contain elements or attributes that would not be needed in a pure
reworking (e.g. length attributes, which are implicit in XML.)
The layering of network and transport protocols are maintained in
this RFC despite the optimizations that could be made if the line
were somewhat blurred (i.e. merging TCP and IP into a single, larger
element in the DTD) in order to foster future use of this protocol as
a basis for reformulating other protocols (such as ICMP.)
Other than the encoding, the behavioral aspects of each of the
existing protocols remain unchanged. Routing, address spaces, TCP
congestion control, etc. behave as specified in the extant standards.
Adapting to new standards and experimental algorithm heuristics for
improving performance will become much easier once the move to BLOAT
has been completed.
1.4. Requirement Levels
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 BCP 14, RFC 2119
[RFC2119].
2. IPoXML
This protocol MUST be implemented to be compliant with this RFC.
IPoXML is the root protocol REQUIRED for effective use of TCPoXML
(section 3.) and higher-level application protocols.
The DTD for this document type can be found in section 7.1.
The routing of IPoXML can be easily implemented on hosts with an XML
parser, as the regular structure lends itself handily to parsing and
validation of the document/datagram and then processing the
destination address, TTL, and checksum before sending it on to its
next-hop.
The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
wider deployment of IPv4 and the fact that implementing IPv6 as XML
would have exceeded the 1500 byte Ethernet MTU.
All BLOAT implementations MUST use - and specify - the UTF-8 encoding
of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well-
formed and include the XMLDecl.
2.1. IP Description
A number of items have changed (for the better) from the original IP
specification. Bit-masks, where present have been converted into
human-readable values. IP addresses are listed in their dotted-
decimal notation [RFC1123]. Length and checksum values are present
as decimal integers.
To calculate the length and checksum fields of the IP element, a
canonicalized form of the element MUST be used. The canonical form
SHALL have no whitespace (including newline characters) between
elements and only one space character between attributes. There
SHALL NOT be a space following the last attribute in an element.
An iterative method SHOULD be used to calculate checksums, as the
length field will vary based on the size of the checksum.
The payload element bears special attention. Due to the character
set restrictions of XML, the payload of IP datagrams (which MAY
contain arbitrary data) MUST be encoded for transport. This RFC
REQUIRES the contents of the payload to be encoded in the base-64
encoding of RFC 2045 [RFC2045], but removes the requirement that the
encoded output MUST be wrapped on 76-character lines.
2.2. Example Datagram
The following is an example IPoXML datagram with an empty payload:
3. TCPoXML
This protocol MUST be implemented to be compliant with this RFC. The
DTD for this document type can be found in section 7.2.
3.1. TCP Description
A number of items have changed from the original TCP specification.
Bit-masks, where present have been converted into human-readable
values. Length and checksum and port values are present as decimal
integers.
To calculate the length and checksum fields of the TCP element, a
canonicalized form of the element MUST be used as in section 2.1.
An iterative method SHOULD be used to calculate checksums as in
section 2.1.
The payload element MUST be encoded as in section 2.1.
The TCP offset element was expanded to a maximum of 255 from 16 to
allow for the increased size of the header in XML.
TCPoXML datagrams encapsulated by IPoXML MAY omit the header
as well as the declaration.
3.2. Example Datagram
The following is an example TCPoXML datagram with an empty payload:
4. UDPoXML
This protocol MUST be implemented to be compliant with this RFC. The
DTD for this document type can be found in section 7.3.
4.1. UDP Description
A number of items have changed from the original UDP specification.
Bit-masks, where present have been converted into human-readable
values. Length and checksum and port values are present as decimal
integers.
To calculate the length and checksum fields of the UDP element, a
canonicalized form of the element MUST be used as in section 2.1. An
iterative method SHOULD be used to calculate checksums as in section
2.1.
The payload element MUST be encoded as in section 2.1.
UDPoXML datagrams encapsulated by IPoXML MAY omit the header
as well as the declaration.
4.2. Example Datagram
The following is an example UDPoXML datagram with an empty payload:
5. Network Transport
This document provides for the transmission of BLOAT datagrams over
two common families of physical layer transport. Future RFCs will
address additional transports as routing vendors catch up to the
specification, and we begin to see BLOAT routed across the Internet
backbone.
5.1. Ethernet
BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
exception that the type field of the Ethernet frame MUST contain the
value 0xBEEF. The first 5 octets of the Ethernet frame payload will
be 0x3c 3f 78 6d 6c ("
-->
7.2. TCPoXML DTD
-->
7.3. UDPoXML DTD
-->
8. Security Considerations
XML, as a subset of SGML, has the same security considerations as
specified in SGML Media Types [RFC1874]. Security considerations
that apply to IP, TCP and UDP also likely apply to BLOAT as it does
not attempt to correct for issues not related to message format.
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 (2002). All Rights Reserved.
Abstract
Mostly Pointless Lamp Switching (MPLampS) is an architecture for
carrying electricity over IP (with an MPLS control plane). According
to our marketing department, MPLampS has the potential to
dramatically lower the price, ease the distribution and usage, and
improve the manageability of delivering electricity. This document
is motivated by such work as SONET/SDH over IP/MPLS (with apologies
to the authors). Readers of the previous work have been observed
scratching their heads and muttering, "What next?". This document
answers that question.
This document has also been written as a public service. The "Sub-
IP" area has been formed to give equal opportunity to those working
on technologies outside of traditional IP networking to write
complicated IETF documents. There are possibly many who are
wondering how to exploit this opportunity and attain high visibility.
Towards this goal, we see the topics of "foo-over-MPLS" (or MPLS
control for random technologies) as highly amenable for producing a
countless number of unimplementable documents. This document
illustrates the key ingredients that go into producing any "foo-
over-MPLS" document and may be used as a template for all such work.
1. Conventions used in this document
The key words "MUST", "MUST NOT", "DO", "DON'T", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "MAY BE"
and "OPTIONAL" in this document do not mean anything.
Rajagopalan Informational [Page 1]
RFC 3251 Electricity over IP 1 April 2002
2. Pre-requisite for reading this document
While reading this document, at various points the readers may have
the urge to ask questions like, "does this make sense?", "is this
feasible?," and "is the author sane?". The readers must have the
ability to suppress such questions and read on. Other than this, no
specific technical background is required to read this document. In
certain cases (present document included), it may be REQUIRED that
readers have no specific technical background.
3. Introduction
It was recently brought to our attention that the distribution
network for electricity is not an IP network! After absorbing the
shock that was delivered by this news, the following thoughts
occurred to us:
1. Electricity distribution must be based on some outdated technology
(called "Legacy Distribution System" or LDS in the rest of the
document).
2. An LDS not based on the Internet technology means that two
different networks (electricity and IP) must be administered and
managed. This leads to inefficiencies, higher cost and
bureaucratic foul-ups (which possibly lead to blackouts in
California. We are in the process of verifying this using
simulations as part of a student's MS thesis).
3. The above means that a single network technology (i.e., IP) must
be used to carry both electricity and Internet traffic.
4. An internet draft must be written to start work in this area,
before someone else does.
5. Such a draft can be used to generate further drafts, ensuring that
we (and CCAMP, MPLS or another responsible working group) will be
busy for another year.
6. The draft can also be posted in the "white papers" section of our
company web page, proclaiming us as revolutionary pioneers.
Hence the present document.
4. Terminology
MPLampS: Mostly Pointless Lamp Switching - the architecture
introduced in this document.
Lamp: An end-system in the MPLampS architecture (clashes with the
IETF notion of end-system but of course, we DON'T care).
LER: Low-voltage Electricity Receptor - fancy name for "Lamp".
Rajagopalan Informational [Page 2]
RFC 3251 Electricity over IP 1 April 2002
ES: Electricity source - a generator.
LSR: Load-Switching Router - an MPLampS device used in the core
electricity distribution network.
LDS: Legacy Distribution System - an inferior electricity
distribution technology that MPLampS intends to replace.
RSVP: Rather Screwed-up, but router Vendors Push it - an IP signaling
protocol.
RSVP-TE: RSVP with Tariff Extensions - RSVP adaptation for MPLampS,
to be used in the new deregulated utilities environment.
CRLDP: for CRying out Loud, Don't do rsvP - another IP signaling
protocol.
OSPF: Often Seizes-up in multiPle area conFigurations - a
hierarchical IP routing protocol.
ISIS: It's not oSpf, yet It somehow Survives - another routing
protocol.
OSPF-TE, ISIS-TE: OSPF and ISIS with Tariff Extensions.
COPS: Policemen. Folks who scour all places for possibilities to
slip in the Common Open Policy Service protocol.
VPN: Voltage Protected Network - allows a customer with multiple
sites to receive electricity with negligible voltage fluctuation due
to interference from other customers.
SUB-IP: SUBstitute IP everywhere - an effort in the IETF to get
involved in technical areas outside of traditional IP networking
(such as MPLampS).
ITU: International Tariffed Utilities association - a utilities trade
group whose work is often ignored by the IETF.
5. Background
We dug into the electricity distribution technology area to get some
background. What we found stunned us, say, with the potency of a
bare 230V A/C lead dropped into our bathtub while we were still in
it. To put it simply, electricity is generated and distributed along
a vast LDS which does not have a single router in it (LSR or
otherwise)! Furthermore, the control of devices in this network is
mostly manual, done by folks driving around in trucks. After
Rajagopalan Informational [Page 3]
RFC 3251 Electricity over IP 1 April 2002
wondering momentarily about how such a network can exist in the 21st
century, we took a pencil and paper and sketched out a scenario for
integrating the LDS network with the proven Internet technology. The
fundamental points we came up with are:
1. IP packets carry electricity in discrete, digitized form.
2. Each packet would deliver electricity to its destination (e.g., a
device with an IP address) on-demand.
3. MPLS control will be used to switch packets within the core LDS,
and in the edge premises. The architecture for this is referred
to as Mostly-Pointless Lamp Switching (MPLampS).
4. The MPLampS architectural model will accommodate both the overlay
model, where the electricity consuming devices (referred to as
"lamps") are operated over a distinct control plane, and the peer
model, in which the lamps and the distribution network use a
single control plane.
5. RSVP-TE (RSVP with Tariff Extensions) will be used for
establishing paths for electricity flow in a de-regulated
environment.
6. COPS will be used to support accounting and policy.
After jotting these points down, we felt better. We then noted the
following immediate advantages of the proposed scheme:
1. Switches and transformers in the LDS can be replaced by LSRs,
thereby opening up a new market for routers.
2. Electricity can be routed over the Internet to reach remote places
which presently do not have electricity connections but have only
Internet kiosks (e.g., rural India).
3. Electrical technicians can be replaced by highly paid IP network
administrators, and
4. The IETF can get involved in another unrelated technology area.
In the following, we describe the technical issues in a vague manner.
6. Electricity Encoding
The Discrete Voltage Encoding (DVE) scheme has been specified in ITU
standard G.110/230V [2] to digitize electrical voltages. In essence,
an Electricity Source (ES) such as a generator is connected to a DV
encoder that encodes the voltage and current, and produces a bit
stream. This bit stream can be carried in IP packets to various
destinations (referred to as LERs - Low-voltage Electricity
Receptors) on-demand. At the destination, a DV decoder produces the
right voltage and current based on the received bit stream. It is to
be determined whether the Real-time Transport Protocol (RTP) can be
Rajagopalan Informational [Page 4]
RFC 3251 Electricity over IP 1 April 2002
used for achieving synchronization and end-to-end control. We leave
draft writing opportunities in the RTP area to our friends and
colleagues.
7. MPLampS Architecture
7.1 Overview
In an LDS, the long-haul transmission of electricity is at high
voltages. The voltage is stepped down progressively as electricity
flows into local distribution networks and is finally delivered to
LERs at a standard voltage (e.g., 110V). Thus, the LDS is a
hierarchical network. This immediately opens up the possibility of
OSPF and ISIS extensions for routing electricity in a transmission
network, but we'll contain the urge to delve into these productive
internet draft areas until later. For the present, we limit our
discussion merely to controlling the flow of electricity in an IP-
based distribution network using MPLampS.
Under MPLampS, a voltage is equated to a label. In the distribution
network, each switching element and transformer is viewed as a load-
switching router (LSR). Each IP packet carrying an electricity flow
is assigned a label corresponding to the voltage. Electricity
distribution can then be trivially reduced to the task of label
(voltage) switching as electricity flows through the distribution
network. The configuration of switching elements in the distribution
network is done through RSVP-TE to provide electricity on demand.
We admit that the above description is vague and sounds crazy. The
example below tries to add more (useless) details, without removing
any doubts the reader might have about the feasibility of this
proposal:
Example: Turning on a Lamp
It is assumed that the lamp is controlled by an intelligent device
(e.g, a (light) switch with an MPLampS control plane). Turning the
lamp on causes the switch to issue an RSVP-TE request (a PATH message
with new objects) for the electricity flow. This PATH message
traverses across the network to the ES. The RESV message issued in
return sets up the label mappings in LSRs. Finally, electricity
starts flowing along the path established. It is expected that the
entire process will be completed within a few seconds, thereby giving
the MPLampS architecture a distinct advantage over lighting a candle
with a damp match stick.
Rajagopalan Informational [Page 5]
RFC 3251 Electricity over IP 1 April 2002
7.2 Overlay vs Peer Models
As noted before, there are two control plane models to be considered.
Under the overlay model, the lamps and the distribution network
utilize distinct control planes. Under the peer model, a single
control plane is used. A number of arguments can be made for one
model versus the other, and these will be covered in the upcoming
framework document. We merely observe here that it is the lamp
vendors who prefer the peer model against the better judgement of the
LSR vendors. We, however, want to please both camps regardless of
the usefulness of either model. We therefore note here that MPLampS
supports both models and also migration scenarios from overlay to
peer.
7.3 Routing in the Core Network
The above description of the hierarchical distribution system
immediately opens up the possibility of applying OSPF and ISIS with
suitable extensions. The readers may rest assured that we are
already working on such concepts as voltage bundling, multi-area
tariff extensions, insulated LSAs, etc. Future documents will
describe the details.
7.4 Voltage Protected Networks (VPNs)
VPNs allow a customer with multiple sites to get guaranteed
electricity supply with negligible voltage fluctuations due to
interference from other customers. Indeed, some may argue that the
entire MPLampS architecture may be trashed if not for the possibility
of doing VPNs. Whatever be the case, VPNs are a hot topic today and
the readers are forewarned that we have every intention of writing
several documents on this. Specifically, BGP-support for VPNs is an
area we're presently eyeing with interest.
8. Multicast
It has been observed that there is a strong spatial and temporal
locality in electricity demand. ITU Study Group 55 has studied this
phenomenon for over a decade and has issued a preliminary report.
This report states that when a lamp is turned on in one house, it is
usually the case that lamps are turned on in neighboring houses at
around the same time (usually at dusk) [3]. This observation has a
serious implication on the scalability of the signaling mechanism.
Specifically, the distribution network must be able to handle tens of
thousands of requests all at once. The signaling load can be reduced
if multicast delivery is used. Briefly, a request for electricity is
not sent from the lamp all the way to an ES, but is handled by the
first LSR that is already in the path to another lamp.
Rajagopalan Informational [Page 6]
RFC 3251 Electricity over IP 1 April 2002
Support for this requires the application of multicast routing
protocols together with RSVP-TE shared reservation styles and the
development of MPLampS multicast forwarding mode. We are currently
studying the following multicast routing protocol:
o DVMRP: Discrete Voltage Multicast Routing Protocol - this protocol
works over existing voltage routing protocols but the danger here is
that electricity is delivered to all lamps when any one lamp is
turned on. Indeed, the switching semantics gets annoying - all lamps
get turned on periodically and those not needed must be switched off
each time manually.
Other protocols we will eventually consider are Current-Based Tree
(CBT) and Practically Irrelevant Multicast (PIM). An issue we are
greatly interested in is multicast scope: we would like support for
distributing electricity with varying scope, from lamps within a
single Christmas tree to those in entire cities. Needless to say, we
will write many detailed documents on these topics as time
progresses.
9. Security Considerations
This document MUST be secured in a locked cabinet to prevent it from
being disposed off with the trash.
10. Summary
This document described the motivation and high level concepts behind
Mostly Pointless Lamp Switching (MPLampS), an architecture for
electricity distribution over IP. MPLampS utilizes DVE (discrete
voltage encoding), and an MPLS control plane in the distribution
network. Since the aim of this document is to be a high-visibility
place-holder, we did not get into many details of MPLampS. Numerous
future documents, unfortunately, will attempt to provide these
details.
Gadzooks! You are correct. I see now what happened, thank you sir. Service temporarily unavailable should fix up nicely as soon as I get around to covering my DSL router with aluminum foil and canadian pennies.
Theft Plain and Simple? Certainly not. But while we're at it, let's call it piracy. Maybe we can transfer some of the negative image associated with those who duplicate software and pillage on the high seas to the spammers. Arrgh! Shiver me timbers!
` The new rules include a long list of banned content prohibiting
writings that reveal state secrets, hurt China's reputation or
advocate the overthrow of communism, ethnic separatism or "evil
cults."'
Surely, the government wouldn't want anyone to overthrow ethnic separatism or evil cults...
So I was at seminary, just leaving for my house to go to school.
Derrick informs me that the wtc has been hit by planes or some such,
which he heard just before showing up at 6:30 local time. (15 mins after
the incidents.) I get home and hear from my mom that the Pentagon and
what-all else have been hit and bombed and evacuated.
I proceed at this time to my school, where the only topic of conversation
is --you guessed it-- the "incident.
I hang out in Mr. Sanders' room (coolest teacher around), and we poke the
internet for updates. He has no luck with the NY Times and such, and I quickly
suggest slashdot. I am mildly amused that CmdrTaco seems to be in the same
trouble. Well, I read some comments on the first article, and we remember
that Mr. Sanders has a radio in his office. As we turn it on, the bell rings
and I proceed to my first hour.
The 'Announcements Lady' comes on the intercom, and gives a brief,
pseudocoherent synopsis to those, if any, who are still clueless. She also
declares the school to be 'on code yellow'. (We got this hilariously
melodramatic nomenclature just after Columbine.)
Trust stupid people to pick today of all days to make a bomb threat to the
high school. Sheesh. Last time we got one, they searched us all with metal
detectors and junk. Anyway, they spend the time that we are locked into our
first classes thoroughly searching the Gymnasium and A-building. No bombs
there, so they herd us class-by-class into the gym. Of course, they forget
all about the band room for ten minutes after everyone is already there.
Figures. (Incidentally, the librarian used the last few minutes in our
classroom to play the beginning of 'channel one'-- a current events
program used by our homeroom classes. Their top story was something about
the Oldsmobile being discontinued or something. Hilarious.)
So they crowd us all into the gym, and conduct a quick, thorough, and
efficient search of the premises and lockers. They dismiss us by building
to our second hour classes. Mine is Calculus. Absolutely uneducational.
The teacher sensed that it was a lost cause. The school wired up ABC news
to the TV system (which we were hoping for when we caught channel one),
and most classes had that playing most of the time. Physics and English
got halfway back into the swing of things, but after that are all of my
soft classes. I fell asleep in homeroom, and didn't make it to my
library-aide period until a few minutes late.
Anyway, that's my story.
Slashdot Mirror
Wow, I congratulate you for having the moral fortitude to tell the entire internet community, not just your best customers... or something. :-)
>And if I don't really own the door, do they really own the money I paid for it with?
Actually, I was reading somewhere... was it a major periodical? One of my dad's lawyer magazines? Slashdot?
Anyway, I was reading that the United States Government actually owns all money, and thus taxes of all sorts can be justified as a fee for letting you use the government's economic invention, "the dollar bill".
The same article mentioned the guy who invented a major stock exchange, and charges a microscopic commission on transactions involving shares of stock.
This will undoubtedly arrive too late to be modded in either direction, but I just had to say it. Let me know if you ever see it, let me know what you think. Anyway:
I beg to differ. Last time I fixed something on my parents' computer (isn't the Holy Grail of Linux on the desktop "accessible for older people?") they had several impressions.
The first was that they were blinded by the speed of my clicking. I laugh at this, and maybe you do too, but my Grandmother told me the same thing when I was working on her computer.
The second thing my parents wistfully observed was that they had been entirely lost ever since this newfangled Windows-thing came along. They (I say they-- each of them did it on separate occasions) said "I was pretty good at this stuff back when it was all DOS; but this Windows came along and I've never been the same since.
My mom took computer classes in college and learned all about punch cards; my dad was copy-conning batch files before I knew what a C: prompt was.
Lady and Gentlemen, I submit for your consideration that the rant everyone gives is flat-out wrong. Joe Sixpack and your grandmother can learn the command line and like it. Graphical so-called ease-of-use is not all it's cracked up to be.
No, the wings have a constant thickness, so weight will also increase as the square of the wing size.
You're right about the motor-scaling bit, though.
My University insists on using massive amounts of JavaScript throughout their web-pages-- doing the job of links, redirects, and form-submit buttons.
What can I do to get them to change their ways?
Just look at my parents:
They complain that they did just great at computers back when it was all DOS, CLI and stuff... ever since this newfangled Windows crap came along, they've just been kind of lost...
Not like they care to learn Linux at all...
That's nothing. When I saw the single, capital letter H (in a slashdot context) I immediately interpolated as though it were an initial on an update at the bottom, reading thus:
Sewage To Be Turned Into Hemos
!
Now that the destruction of 4/1 is over, can we move on with our lives?
We must all continue in our routine. If anything is disrupted, THEY have won.
Help stomp out editorial terrorism.
I'm getting pretty sick of a lot of these complaints. Everybody still thinking about complaining, or even modding up a complainer-- Stand up for a second, step away from the keyboard, and ask yourself if this isn't going to be humonguously redundant-- more so than beatings with bad april-fool jokes. Then (still standing up) carefully step outside, (outside? you know, the "blue room" with a zillion polygons and rockin antialiasing?) and get (for one small day) a life of some sort. Seriously. Stop complaining about slashdot, and do something else for just a little while. If you think you're going to miss something, you can come back in a week and check it. But there's really no point in just complaining that you miss your usual tech&linux news fare. Because slashdot really turns into a different sort of place on april 1.
Well, maybe not THAT different
The lameness filter sucks.
1. Introduction
1.1. Overview
This document describes the Binary Lexical Octet Ad-hoc Transport
(BLOAT): a reformulation of a widely-deployed network-layer protocol
(IP [RFC791]), and two associated transport layer protocols (TCP
[RFC793] and UDP [RFC768]) as XML [XML] applications. It also
describes methods for transporting BLOAT over Ethernet and IEEE 802
networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
across the public Internet.
1.2. Motivation
The wild popularity of XML as a basis for application-level protocols
such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
Object Access Protocol [SOAP], and Jabber [JABBER] prompted
investigation into the possibility of extending the use of XML in the
protocol stack. Using XML at both the transport and network layer in
addition to the application layer would provide for an amazing amount
of power and flexibility while removing dependencies on proprietary
and hard-to-understand binary protocols. This protocol unification
would also allow applications to use a single XML parser for all
aspects of their operation, eliminating developer time spent figuring
out the intricacies of each new protocol, and moving the hard work of
parsing to the XML toolset. The use of XML also mitigates concerns
over "network vs. host" byte ordering which is at the root of many
network application bugs.
1.3. Relation to Existing Protocols
The reformulations specified in this RFC follow as closely as
possible the spirit of the RFCs on which they are based, and so MAY
contain elements or attributes that would not be needed in a pure
reworking (e.g. length attributes, which are implicit in XML.)
The layering of network and transport protocols are maintained in
this RFC despite the optimizations that could be made if the line
were somewhat blurred (i.e. merging TCP and IP into a single, larger
element in the DTD) in order to foster future use of this protocol as
a basis for reformulating other protocols (such as ICMP.)
Other than the encoding, the behavioral aspects of each of the
existing protocols remain unchanged. Routing, address spaces, TCP
congestion control, etc. behave as specified in the extant standards.
Adapting to new standards and experimental algorithm heuristics for
improving performance will become much easier once the move to BLOAT
has been completed.
1.4. Requirement Levels
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 BCP 14, RFC 2119
[RFC2119].
2. IPoXML
This protocol MUST be implemented to be compliant with this RFC.
IPoXML is the root protocol REQUIRED for effective use of TCPoXML
(section 3.) and higher-level application protocols.
The DTD for this document type can be found in section 7.1.
The routing of IPoXML can be easily implemented on hosts with an XML
parser, as the regular structure lends itself handily to parsing and
validation of the document/datagram and then processing the
destination address, TTL, and checksum before sending it on to its
next-hop.
The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
wider deployment of IPv4 and the fact that implementing IPv6 as XML
would have exceeded the 1500 byte Ethernet MTU.
All BLOAT implementations MUST use - and specify - the UTF-8 encoding
of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well-
formed and include the XMLDecl.
2.1. IP Description
A number of items have changed (for the better) from the original IP
specification. Bit-masks, where present have been converted into
human-readable values. IP addresses are listed in their dotted-
decimal notation [RFC1123]. Length and checksum values are present
as decimal integers.
To calculate the length and checksum fields of the IP element, a
canonicalized form of the element MUST be used. The canonical form
SHALL have no whitespace (including newline characters) between
elements and only one space character between attributes. There
SHALL NOT be a space following the last attribute in an element.
An iterative method SHOULD be used to calculate checksums, as the
length field will vary based on the size of the checksum.
The payload element bears special attention. Due to the character
set restrictions of XML, the payload of IP datagrams (which MAY
contain arbitrary data) MUST be encoded for transport. This RFC
REQUIRES the contents of the payload to be encoded in the base-64
encoding of RFC 2045 [RFC2045], but removes the requirement that the
encoded output MUST be wrapped on 76-character lines.
2.2. Example Datagram
The following is an example IPoXML datagram with an empty payload:
3. TCPoXML
This protocol MUST be implemented to be compliant with this RFC. The
DTD for this document type can be found in section 7.2.
3.1. TCP Description
A number of items have changed from the original TCP specification.
Bit-masks, where present have been converted into human-readable
values. Length and checksum and port values are present as decimal
integers.
To calculate the length and checksum fields of the TCP element, a
canonicalized form of the element MUST be used as in section 2.1.
An iterative method SHOULD be used to calculate checksums as in
section 2.1.
The payload element MUST be encoded as in section 2.1.
The TCP offset element was expanded to a maximum of 255 from 16 to
allow for the increased size of the header in XML.
TCPoXML datagrams encapsulated by IPoXML MAY omit the header
as well as the declaration.
3.2. Example Datagram
The following is an example TCPoXML datagram with an empty payload:
4. UDPoXML
This protocol MUST be implemented to be compliant with this RFC. The
DTD for this document type can be found in section 7.3.
4.1. UDP Description
A number of items have changed from the original UDP specification.
Bit-masks, where present have been converted into human-readable
values. Length and checksum and port values are present as decimal
integers.
To calculate the length and checksum fields of the UDP element, a
canonicalized form of the element MUST be used as in section 2.1. An
iterative method SHOULD be used to calculate checksums as in section
2.1.
The payload element MUST be encoded as in section 2.1.
UDPoXML datagrams encapsulated by IPoXML MAY omit the header
as well as the declaration.
4.2. Example Datagram
The following is an example UDPoXML datagram with an empty payload:
5. Network Transport
This document provides for the transmission of BLOAT datagrams over
two common families of physical layer transport. Future RFCs will
address additional transports as routing vendors catch up to the
specification, and we begin to see BLOAT routed across the Internet
backbone.
5.1. Ethernet
BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
exception that the type field of the Ethernet frame MUST contain the
value 0xBEEF. The first 5 octets of the Ethernet frame payload will
be 0x3c 3f 78 6d 6c ("
-->
7.2. TCPoXML DTD
-->
7.3. UDPoXML DTD
-->
8. Security Considerations
XML, as a subset of SGML, has the same security considerations as
specified in SGML Media Types [RFC1874]. Security considerations
that apply to IP, TCP and UDP also likely apply to BLOAT as it does
not attempt to correct for issues not related to message format.
Slashdot effect hits hard. :-)
Fetch hits harder
Electricity over IP
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 (2002). All Rights Reserved.
Abstract
Mostly Pointless Lamp Switching (MPLampS) is an architecture for
carrying electricity over IP (with an MPLS control plane). According
to our marketing department, MPLampS has the potential to
dramatically lower the price, ease the distribution and usage, and
improve the manageability of delivering electricity. This document
is motivated by such work as SONET/SDH over IP/MPLS (with apologies
to the authors). Readers of the previous work have been observed
scratching their heads and muttering, "What next?". This document
answers that question.
This document has also been written as a public service. The "Sub-
IP" area has been formed to give equal opportunity to those working
on technologies outside of traditional IP networking to write
complicated IETF documents. There are possibly many who are
wondering how to exploit this opportunity and attain high visibility.
Towards this goal, we see the topics of "foo-over-MPLS" (or MPLS
control for random technologies) as highly amenable for producing a
countless number of unimplementable documents. This document
illustrates the key ingredients that go into producing any "foo-
over-MPLS" document and may be used as a template for all such work.
1. Conventions used in this document
The key words "MUST", "MUST NOT", "DO", "DON'T", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "MAY BE"
and "OPTIONAL" in this document do not mean anything.
Rajagopalan Informational [Page 1]
RFC 3251 Electricity over IP 1 April 2002
2. Pre-requisite for reading this document
While reading this document, at various points the readers may have
the urge to ask questions like, "does this make sense?", "is this
feasible?," and "is the author sane?". The readers must have the
ability to suppress such questions and read on. Other than this, no
specific technical background is required to read this document. In
certain cases (present document included), it may be REQUIRED that
readers have no specific technical background.
3. Introduction
It was recently brought to our attention that the distribution
network for electricity is not an IP network! After absorbing the
shock that was delivered by this news, the following thoughts
occurred to us:
1. Electricity distribution must be based on some outdated technology
(called "Legacy Distribution System" or LDS in the rest of the
document).
2. An LDS not based on the Internet technology means that two
different networks (electricity and IP) must be administered and
managed. This leads to inefficiencies, higher cost and
bureaucratic foul-ups (which possibly lead to blackouts in
California. We are in the process of verifying this using
simulations as part of a student's MS thesis).
3. The above means that a single network technology (i.e., IP) must
be used to carry both electricity and Internet traffic.
4. An internet draft must be written to start work in this area,
before someone else does.
5. Such a draft can be used to generate further drafts, ensuring that
we (and CCAMP, MPLS or another responsible working group) will be
busy for another year.
6. The draft can also be posted in the "white papers" section of our
company web page, proclaiming us as revolutionary pioneers.
Hence the present document.
4. Terminology
MPLampS: Mostly Pointless Lamp Switching - the architecture
introduced in this document.
Lamp: An end-system in the MPLampS architecture (clashes with the
IETF notion of end-system but of course, we DON'T care).
LER: Low-voltage Electricity Receptor - fancy name for "Lamp".
Rajagopalan Informational [Page 2]
RFC 3251 Electricity over IP 1 April 2002
ES: Electricity source - a generator.
LSR: Load-Switching Router - an MPLampS device used in the core
electricity distribution network.
LDS: Legacy Distribution System - an inferior electricity
distribution technology that MPLampS intends to replace.
RSVP: Rather Screwed-up, but router Vendors Push it - an IP signaling
protocol.
RSVP-TE: RSVP with Tariff Extensions - RSVP adaptation for MPLampS,
to be used in the new deregulated utilities environment.
CRLDP: for CRying out Loud, Don't do rsvP - another IP signaling
protocol.
OSPF: Often Seizes-up in multiPle area conFigurations - a
hierarchical IP routing protocol.
ISIS: It's not oSpf, yet It somehow Survives - another routing
protocol.
OSPF-TE, ISIS-TE: OSPF and ISIS with Tariff Extensions.
COPS: Policemen. Folks who scour all places for possibilities to
slip in the Common Open Policy Service protocol.
VPN: Voltage Protected Network - allows a customer with multiple
sites to receive electricity with negligible voltage fluctuation due
to interference from other customers.
SUB-IP: SUBstitute IP everywhere - an effort in the IETF to get
involved in technical areas outside of traditional IP networking
(such as MPLampS).
ITU: International Tariffed Utilities association - a utilities trade
group whose work is often ignored by the IETF.
5. Background
We dug into the electricity distribution technology area to get some
background. What we found stunned us, say, with the potency of a
bare 230V A/C lead dropped into our bathtub while we were still in
it. To put it simply, electricity is generated and distributed along
a vast LDS which does not have a single router in it (LSR or
otherwise)! Furthermore, the control of devices in this network is
mostly manual, done by folks driving around in trucks. After
Rajagopalan Informational [Page 3]
RFC 3251 Electricity over IP 1 April 2002
wondering momentarily about how such a network can exist in the 21st
century, we took a pencil and paper and sketched out a scenario for
integrating the LDS network with the proven Internet technology. The
fundamental points we came up with are:
1. IP packets carry electricity in discrete, digitized form.
2. Each packet would deliver electricity to its destination (e.g., a
device with an IP address) on-demand.
3. MPLS control will be used to switch packets within the core LDS,
and in the edge premises. The architecture for this is referred
to as Mostly-Pointless Lamp Switching (MPLampS).
4. The MPLampS architectural model will accommodate both the overlay
model, where the electricity consuming devices (referred to as
"lamps") are operated over a distinct control plane, and the peer
model, in which the lamps and the distribution network use a
single control plane.
5. RSVP-TE (RSVP with Tariff Extensions) will be used for
establishing paths for electricity flow in a de-regulated
environment.
6. COPS will be used to support accounting and policy.
After jotting these points down, we felt better. We then noted the
following immediate advantages of the proposed scheme:
1. Switches and transformers in the LDS can be replaced by LSRs,
thereby opening up a new market for routers.
2. Electricity can be routed over the Internet to reach remote places
which presently do not have electricity connections but have only
Internet kiosks (e.g., rural India).
3. Electrical technicians can be replaced by highly paid IP network
administrators, and
4. The IETF can get involved in another unrelated technology area.
In the following, we describe the technical issues in a vague manner.
6. Electricity Encoding
The Discrete Voltage Encoding (DVE) scheme has been specified in ITU
standard G.110/230V [2] to digitize electrical voltages. In essence,
an Electricity Source (ES) such as a generator is connected to a DV
encoder that encodes the voltage and current, and produces a bit
stream. This bit stream can be carried in IP packets to various
destinations (referred to as LERs - Low-voltage Electricity
Receptors) on-demand. At the destination, a DV decoder produces the
right voltage and current based on the received bit stream. It is to
be determined whether the Real-time Transport Protocol (RTP) can be
Rajagopalan Informational [Page 4]
RFC 3251 Electricity over IP 1 April 2002
used for achieving synchronization and end-to-end control. We leave
draft writing opportunities in the RTP area to our friends and
colleagues.
7. MPLampS Architecture
7.1 Overview
In an LDS, the long-haul transmission of electricity is at high
voltages. The voltage is stepped down progressively as electricity
flows into local distribution networks and is finally delivered to
LERs at a standard voltage (e.g., 110V). Thus, the LDS is a
hierarchical network. This immediately opens up the possibility of
OSPF and ISIS extensions for routing electricity in a transmission
network, but we'll contain the urge to delve into these productive
internet draft areas until later. For the present, we limit our
discussion merely to controlling the flow of electricity in an IP-
based distribution network using MPLampS.
Under MPLampS, a voltage is equated to a label. In the distribution
network, each switching element and transformer is viewed as a load-
switching router (LSR). Each IP packet carrying an electricity flow
is assigned a label corresponding to the voltage. Electricity
distribution can then be trivially reduced to the task of label
(voltage) switching as electricity flows through the distribution
network. The configuration of switching elements in the distribution
network is done through RSVP-TE to provide electricity on demand.
We admit that the above description is vague and sounds crazy. The
example below tries to add more (useless) details, without removing
any doubts the reader might have about the feasibility of this
proposal:
Example: Turning on a Lamp
It is assumed that the lamp is controlled by an intelligent device
(e.g, a (light) switch with an MPLampS control plane). Turning the
lamp on causes the switch to issue an RSVP-TE request (a PATH message
with new objects) for the electricity flow. This PATH message
traverses across the network to the ES. The RESV message issued in
return sets up the label mappings in LSRs. Finally, electricity
starts flowing along the path established. It is expected that the
entire process will be completed within a few seconds, thereby giving
the MPLampS architecture a distinct advantage over lighting a candle
with a damp match stick.
Rajagopalan Informational [Page 5]
RFC 3251 Electricity over IP 1 April 2002
7.2 Overlay vs Peer Models
As noted before, there are two control plane models to be considered.
Under the overlay model, the lamps and the distribution network
utilize distinct control planes. Under the peer model, a single
control plane is used. A number of arguments can be made for one
model versus the other, and these will be covered in the upcoming
framework document. We merely observe here that it is the lamp
vendors who prefer the peer model against the better judgement of the
LSR vendors. We, however, want to please both camps regardless of
the usefulness of either model. We therefore note here that MPLampS
supports both models and also migration scenarios from overlay to
peer.
7.3 Routing in the Core Network
The above description of the hierarchical distribution system
immediately opens up the possibility of applying OSPF and ISIS with
suitable extensions. The readers may rest assured that we are
already working on such concepts as voltage bundling, multi-area
tariff extensions, insulated LSAs, etc. Future documents will
describe the details.
7.4 Voltage Protected Networks (VPNs)
VPNs allow a customer with multiple sites to get guaranteed
electricity supply with negligible voltage fluctuations due to
interference from other customers. Indeed, some may argue that the
entire MPLampS architecture may be trashed if not for the possibility
of doing VPNs. Whatever be the case, VPNs are a hot topic today and
the readers are forewarned that we have every intention of writing
several documents on this. Specifically, BGP-support for VPNs is an
area we're presently eyeing with interest.
8. Multicast
It has been observed that there is a strong spatial and temporal
locality in electricity demand. ITU Study Group 55 has studied this
phenomenon for over a decade and has issued a preliminary report.
This report states that when a lamp is turned on in one house, it is
usually the case that lamps are turned on in neighboring houses at
around the same time (usually at dusk) [3]. This observation has a
serious implication on the scalability of the signaling mechanism.
Specifically, the distribution network must be able to handle tens of
thousands of requests all at once. The signaling load can be reduced
if multicast delivery is used. Briefly, a request for electricity is
not sent from the lamp all the way to an ES, but is handled by the
first LSR that is already in the path to another lamp.
Rajagopalan Informational [Page 6]
RFC 3251 Electricity over IP 1 April 2002
Support for this requires the application of multicast routing
protocols together with RSVP-TE shared reservation styles and the
development of MPLampS multicast forwarding mode. We are currently
studying the following multicast routing protocol:
o DVMRP: Discrete Voltage Multicast Routing Protocol - this protocol
works over existing voltage routing protocols but the danger here is
that electricity is delivered to all lamps when any one lamp is
turned on. Indeed, the switching semantics gets annoying - all lamps
get turned on periodically and those not needed must be switched off
each time manually.
Other protocols we will eventually consider are Current-Based Tree
(CBT) and Practically Irrelevant Multicast (PIM). An issue we are
greatly interested in is multicast scope: we would like support for
distributing electricity with varying scope, from lamps within a
single Christmas tree to those in entire cities. Needless to say, we
will write many detailed documents on these topics as time
progresses.
9. Security Considerations
This document MUST be secured in a locked cabinet to prevent it from
being disposed off with the trash.
10. Summary
This document described the motivation and high level concepts behind
Mostly Pointless Lamp Switching (MPLampS), an architecture for
electricity distribution over IP. MPLampS utilizes DVE (discrete
voltage encoding), and an MPLS control plane in the distribution
network. Since the aim of this document is to be a high-visibility
place-holder, we did not get into many details of MPLampS. Numerous
future documents, unfortunately, will attempt to provide these
details.
Corewar (Core Wars, CoreWar, whatever)
lives on, though it's rather difficult
to track down. I suggest www.koth.org.
>>This will probably get modded down as flamebait
>>or troll, but whatever.
>I need to turn this into my signature, because
>you f***ing no that any time someone writes
>this, they get +5.
You wouldn't be the first to think of it.
Gadzooks! You are correct.
I see now what happened, thank you sir.
Service temporarily unavailable should fix up nicely as soon as I get around to covering my DSL router with aluminum foil and canadian pennies.
Speaking of Tinfoil Hats, the coolest comprehensive Tinfoil Hat site (More properly, Aluminum Foil Deflector Beanie) is here.
Also, it may be sampling error or psychosomatic effects, but I have never lost a chess game while wearing my Aluminum Foil Deflector Beanie.
Theft Plain and Simple?
Certainly not. But while we're at it, let's call it piracy. Maybe we can transfer some of the negative image associated with those who duplicate software and pillage on the high seas to the spammers.
Arrgh! Shiver me timbers!
This is obviously extremely different.
You see, he's taunting "cool" kids.
Getting sendmail to route mail is the tricky part. Getting it to rout mail is absolutely cake. :-)
> be just as revelutionary if somebody would make a flatscreen with a
:-)
> real colour pixels, instead of the RGB dots.
That would be a revolution indeed! All my monitors have colOR pixels
Good to see the patches, mirror list, and changelog linked to, not just the full kernel. We knew you could do it! Keep it up, guys!
Sure glad *MY* webpad never exploded...:-)
` The new rules include a long list of banned content prohibiting
writings that reveal state secrets, hurt China's reputation or
advocate the overthrow of communism, ethnic separatism or "evil
cults."'
Surely, the government wouldn't want anyone to overthrow ethnic separatism or evil cults...
Oh, wait.
Does Telnet to port 80 count?
It rejects that out of hand.
Who VOTED for them?
Better yet...
Which watery tart threw THEM a sword?
So I was at seminary, just leaving for my house to go to school.
Derrick informs me that the wtc has been hit by planes or some such,
which he heard just before showing up at 6:30 local time. (15 mins after
the incidents.) I get home and hear from my mom that the Pentagon and
what-all else have been hit and bombed and evacuated.
I proceed at this time to my school, where the only topic of conversation
is --you guessed it-- the "incident.
I hang out in Mr. Sanders' room (coolest teacher around), and we poke the
internet for updates. He has no luck with the NY Times and such, and I quickly
suggest slashdot. I am mildly amused that CmdrTaco seems to be in the same
trouble. Well, I read some comments on the first article, and we remember
that Mr. Sanders has a radio in his office. As we turn it on, the bell rings
and I proceed to my first hour.
The 'Announcements Lady' comes on the intercom, and gives a brief,
pseudocoherent synopsis to those, if any, who are still clueless. She also
declares the school to be 'on code yellow'. (We got this hilariously
melodramatic nomenclature just after Columbine.)
Trust stupid people to pick today of all days to make a bomb threat to the
high school. Sheesh. Last time we got one, they searched us all with metal
detectors and junk. Anyway, they spend the time that we are locked into our
first classes thoroughly searching the Gymnasium and A-building. No bombs
there, so they herd us class-by-class into the gym. Of course, they forget
all about the band room for ten minutes after everyone is already there.
Figures. (Incidentally, the librarian used the last few minutes in our
classroom to play the beginning of 'channel one'-- a current events
program used by our homeroom classes. Their top story was something about
the Oldsmobile being discontinued or something. Hilarious.)
So they crowd us all into the gym, and conduct a quick, thorough, and
efficient search of the premises and lockers. They dismiss us by building
to our second hour classes. Mine is Calculus. Absolutely uneducational.
The teacher sensed that it was a lost cause. The school wired up ABC news
to the TV system (which we were hoping for when we caught channel one),
and most classes had that playing most of the time. Physics and English
got halfway back into the swing of things, but after that are all of my
soft classes. I fell asleep in homeroom, and didn't make it to my
library-aide period until a few minutes late.
Anyway, that's my story.