|
Re: SMTP Use Cases
2004-10-23 09:21:38
The OPES WG mailing list is *not* the place to discuss fundamental
architecture/design issues of the general Internet and how the general
Internet should evolve. While these discussions are important,
interesting and (sometimes) fun, please move them to the general IETF
mailing list.
OPES scope and architecture have been discussed a while ago and are
documented in the respective RFCs and our charter. Discussions on this
mailing list will be within these boundaries. More general and
fundamental discussions should be move to more approriate places.
Thanks,
Markus
jfcm wrote:
Alex,
I know that you do not understand. From the very beginning your vision
of an OPES is the vision of a front-end middlebox with an OCP link to a
remote server. You just explained this: the interest of that middlebox
is that it can easily be adapted to any protocol. This vision is of real
interest to patch protocols and to implement transitions. But it permits
much more if used in a proper architectural way.
Now, you are able to understand that if what you work on is to be used
in an architectural dead-end - whatever the cosmetic in describing it -
you will waste your time and efforts. So the question is of importance
to you.
Right now IETF is trying to understand if they are in such an
architectural dead-end or not. This is plainly documented in the IAB RFC
3869 published a few weeks ago. This is plainly documented in IETF RFCs
on IETF situation. This is plainly documented in the IETF debates
initiated by Harald Alvestrand. This was plainly documented through
ICANN early warning problem two years ago. This was plainly documented
in the new economy quick blundering. This is plainly documented in the
WSIS resolutions calling on Koffi Annan's experts. Always in the same
way: a partial list of problems without ever considering the
deliveries, the call for help to people they do not want (money and
Gov), the lack of understanding of what would trigger a positive
response (that deliveries would match real needs).
The IAB documents the internet problems in RFC 3869: the lack of vision,
of motivation and of funding for R&D. It also gives the reasons why:
through what is missing in their document (they do not even allude to
mutilingualism, to user or market demand). The real internet problem is
an host centric architecture which does not respond the real world
needs. The real needs and interest are usage centric. The IAB is clear
about it: it identifies global access to information (host application)
as THE internet service. This is a 1971 need (first commercial ISP bill
in Feb. 1971). There is a very long that network marketers and service
developpers know this is far more complex. Users also want services and
full control. But how IETF will know it without market study? The IETF
is producing Ford-T cars and meets some difficulties about organizing,
funding, recruiting. At the present time it tries to understand how to
best organize, get funding, motivate its members. Sometimes they will
consider producing Mustang cars.
This is why there is a drop in R&D and funding, why IETF audience and
money drop, why Stuart Lynn had to call on Govs for ICANN, why IAB now
calls on Govs for R&D, why WSIS calls on Govs for an Internet governance
review (please read RFC on IETF problems). For two centuries the world
has used Gov control/monopolies. The web has made believe that we could
use Internet's free datagram du to the lack of State protected
economical model. This has initially worked because the USG warranted
it, but its interest is not in warranting and funding the world's system
(the WSIS has two problems: world system's governance and funding).
The loss of interest comes from the fact that no one sees big return
from investing in the internet architecture. Only bandwidth value added
people who see some saving while their revenues and margins drop. This
is the reason of the new economy failure. This is the reason why no one
will fund you for developing OCP. This is the reason why the WG loses
momentum while it works on a real key issue. The searchers and investors
question is really simple "what for?".
Some have understood the solution. Many have understood how to look for
it (please reread RFC 2775).
Once again, what is concerned is not OCP, but where and how to use it.
I am not interested in documenting this to IESG. We made the diagnosis
nearly 20 years ago from our real life commercial success. We documented
the architectural reasons of such a success. At the time we were the
world leader (Tymnet) when we were poorly purchased. We quitted and
disbanded. I can tell you exactly how and when our world lost 30 years.
And the 1987 evening when we evaluated that there was no interest in
wasting time to document the young IETF because real world and academic
life, vision and budgets are so apart. The interest is that these 20
years permitted to validate and to deep our vision (through some huge
success as M$ which partly used it, or some evolution such as the drop
in bandwidth cost and ubiquity, but mostly in observing the problems met
by OSI and then by the Internet - and the way they try to patch them, as
with OPES). This is lame. Either you understand it and the opportunity
is huge, or you do not want to accept it and you waste your time and
energy.
Now, with the currently coming appliances hardware and FCC/Govs growing
communication attitude, the future internet is at hand. It may not come
from IETF nor from GPL etc. It may come from an US start-up, from a
Major's understanding of the real musical market and economical model,
it can come from an European workshop, it can come from a Chinese
manufacturers consensus, or from an Indian engineers venture. Probably
after a major collapse over a DoS, a DNS failure, a spam growth, a
brilliant physing, or a real life catastrophe as Richard Clarke foresaw
it, a big digital terrorist attack or a Govs fed-up at the ASCII
internet US nexus (please note that I invent nothing. All this is fully
documented in RFCs and in USG documents). All this will lead to
competition in solutions, hence to a balkanization of the Internet (cf.
Paul Vixie on the IETF general mailing list over IPv9 Chinese testing).
This is why the only solution IMHO is to document Govs about the real
life threats, imply them in solutions and demonstrate through real
working system solutions.
In that future Internet, a distributed ubiquity of smart stand alone
smart multi services $ 100 nodes over a continuity of various types of
bandwidths by coopeting large concentrated operators (look at FCC
policy) at a global $ 15 cost per month, the protocol will probably
progressively switch from IP to something better (but compatibility will
have to be maintained for a while) managed by a secure and versatile
simple inter-user network operating system. OCP could be a good embryo
of such an OS internal protocol.
jfc
At 05:52 23/10/2004, Alex Rousskov wrote:
Jfc,
Since I cannot understand your objections, despite multiple
serious attempts to do so, my suggestion would be for you to forward
your new-charter-makes-no-sense objections to IESG. If IESG
understands and agrees with your position, they might be able to
explain it in a way that I can comprehend in order to help with fixing
the charter. If not, we would not have to come back to this until the
next charter revision.
Alex.
On Sat, 23 Oct 2004, jfcm wrote:
I think we will never get Alex understand the problem. What he sees
is an action on a message. Not the scope of that action. It is true
that whatever the protocol a message (in one or several datagrams) is
massaged like in any middlebox. The difference is thatit is not
massage at the middlebox but at a distant server. The important
action is the massaging (filtering, protocol to the server, update).
Martin in the SMTP case see the things the same way.
I see the same thing, but in an architectural way. Either the idea is
to stop having too many middleboxes and to keep the network
intelligence at the edge, so the architectural end to end and dumb
network/smart hosts can be protected. This is the IAB idea and we
have to be very tought on the OPES definition as an "edge" service.
Or we do not mind IAB, we address the need and we extend RFC 3234
with networked middleboxes (I recall that middleboxes can be virtual,
so the filter of an OPES is a midlebox).
1. if we talk about OPES. there may be knowledge of the OPES action
by the ends, but no dialog with both. In the case of an a-synchornous
service multicast such as SMTP the only end to be informed is the
nearest end. Also, by no means OPES can be on an MTA, only on UAs
because the MTA by nature is not at the edge of the network. OPES can
only be on the edge traffic. Not on the stored nor on inner network
traffic.
2. if we talk of remote server supported middleboxes, we are totally
free to do what we want. But these are no more OPES but ONES. This
means Open Network Extended Services. We are then introducing
intelligence within the network, what I _fully_ support, but which is
far, far more complex to document. May I remind you RFC 2775: there
is no objection to change everything in the network vision (and I DO
think this necessary and urgent if we want to address the IAB
concerns on Internet future) but this is another issue and I doubt
this WG has the right people to engage a total rebuild of the Internet.
I can only repeat that the proposed examples are fine as services,
not as OPES they are not. Also, that the new charter does not make
any technical sense to me. Because OPES are at users plug and the
work you want them to provide is at the power plant.
Or we decide that the architecture is end-to-mailserver +
mailserver-to-end. The mail server is then an edge. But who is in
control? Not the receiving end but the ISP mailserver manager. And we
fall back in the situation described by Markus....
jfc
At 01:49 23/10/2004, Hilarie Orman wrote:
HTTP never had a store-and-forward protocol architecture, so all
the proxy stuff got tacked on. SMTP dealt with it from the beginning
and already addressed the problems of MITM, tracing, etc. It is,
in fact, the strawman reference model for much of our OPES discussion.
There's an odd recursive aspect to applying OPES to SMTP, and I think
it is important to clarify why SMTP will benefit from OPES, sort of
like asking why one's grandparents should buy their clothes at
Banana Republic (whatever).
Hilarie
-----Snippet of Original Message-----
From: Alex Rousskov
Sent: Friday, October 22, 2004 11:13 AM
Subject: Re: SMTP Use Cases
I may be repeating myself, but I still do not know how
store-and-forward
SMTP is different from whatever-you-want-to-call-it HTTP in the
context of
adapting content. Thus, for me, SMTP adaptation can be within OPES
scope
if HTTP adaptation is. Using your example above, exactly the same
argument
can be made for HTTP: why not forward the messages to an HTTP proxy
where
the "service enhancements" can be applied...
Alex.
|
|