FYI -
For those who haven't read/seen the original paper from Prof Saltzer...
Here is the classic paper from Prof. Jerry Saltzer and others at MIT,
published in 1984, that we all hear as the "end-to-end" principles that IETF
upholds.
http://citeseer.nj.nec.com/cache/papers2/cs/4203/http:zSzzSzweb.mit.eduzSzSa
ltzerzSzwwwzSzpublicationszSzendtoendzSzendtoend.pdf/end-to-end-arguments.pd
f
Reproduced at the bottom of this e-mail are some excerpts from the paper
that I think capture the essence of it.
My 2 cents worth/interpretation:
When you read through the paper, it becomes clear that the end-to-end
principles are all about "applications" on end systems (at either end of the
network/Internet connection) being responsible for the correctness of data
transferred between the systems, with all kinds of *un-intentional*
corruptions of data that may happen in the network.
The key point is *un-intentional* (or unauthorized in the case of secure
data) corruption of data - as has been stated by Michael Condry and others,
OPES is about authorized "data modifications" and hence does NOT violate the
end-to-end principles. My additional interpretationAlso, being an
intelligent computing system capable of running "apllications" and hence
being able to correct for network or unauthorized data corruption, any OPES
device is by default an "end" system and hence, it is in agreement with the
end-to-end principles.
Cheers,
- Rama
*******
Excerpts
======
In a system that includes communications, one usually draws a modular
boundary around the
communication subsystem and defines a firm interface between it and the rest
of the system.
When doing so, it becomes apparent that there is a list of functions each of
which might be
implemented in any of several ways: by the communication subsystem, by its
client, as a joint
venture, or perhaps redundantly, each doing its own version. In reasoning
about this choice, the
requirements of the application provide the basis for a class of arguments,
which go as follows:
The function in question can completely and correctly be implemented only
with the
knowledge and help of the application standing at the end points of the
communication
system. Therefore, providing that questioned function as a feature of the
communication
system itself is not possible. (Sometimes an incomplete version of the
function provided
by the communication system may be useful as a performance enhancement.)
We call this line of reasoning against low-level function implementation the
"end-to-end
argument."
.....
For the case of the data communication system, this range includes
encryption, duplicate
message detection, message sequencing, guaranteed message delivery,
detecting host crashes,
and delivery receipts.
.....
Thus the end-to-end argument is not an absolute rule, but rather a guideline
that helps in application and protocol design analysis; one
must use some care to identify the end points to which the argument should
be applied.
....