no,it's quite a bit more than that.
So let's take the canonical hypothetical case. Nuclear-tipped pointy-
end-of-the-spear things are coming over the horizon and one of a very
small number of people (the president, a theatre commander, etc)
needs to send a message to a larger-but-well-defined group of people
(the set that wear 3-or-more stars perhaps plus certain civil
authorities) that says "execute plan Z". This is the kind of thing
that needs to be delivered within a few minutes to all concerned, and
"I didn't get the email" and "but POP3 only polls every 15 minutes"
aren't very good responses. A system used to exist that did this
using some combination of telex machines and privates whose entire
job in the military was to watch said machines for action, rip the
message off, and put it in front of the intended recipient instantly
regardless of what it took to do so. I'm told that it is now done
using a certain commonly-deployed SMTP mail system.
Stepping a bit away from apocalyptic scenarios, there are other
groups of people and far less dramatic scenarios to consider.
Now ask yourself how you would solve this. First, there has to be
some form of trust system in which when an authorized person wants to
send one of these messages all of the systems along the way are going
to recognize that authority. In the military, that's easy - everyone
knows what a "commander in chief" is. In the civilian sector, it
becomes a matter of transitive trust - "I think so-and-so is
authorized and you should too" across an administrative boundary of
some sort. It requires some way to say in the email that the person
is authorized to assert the status, assert the status, and provide
appropriate credentials to allow the recipient MTA (because each MTA
will have to do something about this) to verify the identity and
apply the relevant policy. As with any email system, the big delays
are the queues in the MTAs - what happens if a SYN is lost? we resend
in an hour, four hours, tomorrow, and the next day, right? We need to
resend in 30 seconds, perhaps, and if mumble time units elapse
without successful delivery we need to initiate a response to the
sender indicating that s/he should try another communication channel
while we continue to retry this one. And oh by the way, there might
be network bandwidth available to traffic of this category that we
need to appropriately take advantage of.
Who do you want doing all of this? Not me, I'll betcha. I could
contribute to the architecture, but there are security issues, SMTP
issues, system-engineering (as in "use SMTP on the last hop" or "set
POP/IMAP to poll every ten seconds") issues to address, and so on
that you really want the experts in those areas addressing.
Those experts aren't in the ITU, and the ITU at this point doesn't
have the expertise to even say what was said in my long paragraph
above. Hand ieprep off to the ITU and one of two things will happen:
(a) they will try to analyze the problem and get it wrong, or (b)
they will send us a liaison saying "please go think about this". Good
grief. We need to collectively go think about this. Let's not bury
our heads in the sand and pretend we're the wrong people for the job.
I do believe that having a requirements-generating working group is a
good thing. A point of frustration has been that in trying to discuss
the matter around the IETF, we have our meetings and then have to not
only convince other working groups to go solve them but convince each
individual person in each individual working group that it has to be
addressed. In tsvwg, for example, I developed solutions that were
discussed in ieprep for over a year, moved to tsvwg and discussed
there for over a year, ieprep in November 2003 formally told its ADs
that they should accept the INFORMATIONAL DRAFT that described them,
that waited for over another year, and was finally last called - and
published as an RFC just a few months ago. When the only way to get
anything accomplished is to threaten an appeal over management
incompetence or obstinacy (neither of which I would like to believe
were actually the case, but yes the appeal was threatened and only
subsequently did glacial action start to happen). Excuse me, but that
is not a good example of "rough consensus and running code". We need
a means by which we can do something about these problems that
includes the right community of experts and doesn't involve waiting
to see who gets exhausted last.
On Nov 5, 2006, at 2:38 PM, Pete Resnick wrote:
On 11/4/06 at 4:04 PM -0800, Fred Baker wrote:
Questions abound around the mechanisms for sending an email and
ensuring that it is delivered in a stated time interval on the
order of minutes or that an indication of failure is returned to
the sender...
That, in particular, seems like a relatively easy extension to RFC
3461 (by adding some sort of additional parameter value to DELAY).
Not exactly rocket science. Not exactly requiring spinning up a WG.
pr
--
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)
651-1102
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf