Re: WG Review: Recharter of Internet Emergency Preparedness (ieprep)

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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf