Subject: [Ieprep] a little homily

From: Fred Baker <[email-masked]>
Date: Fri, 29 Mar 2002 17:39:17 -0800

I feel like I'm being a broken record here, and I'm getting as tired of 
writing it as everyone else is probably getting with reading it. But we are 
here, first and foremost, to make emergency services work well on the 
Internet. The point is not to promote solutions as much as it is to 
identify problems and solve them.

Let's imagine you have a sink backed up in your house. You call the 
plumber, who comes over to look at it. S/he walks in and starts singing the 
praises of three inch lines, plastic pipe, and pointing out the fact that 
hot air rises towards your ceiling and your house could be heated more 
efficiently if there were a fan up there blowing the air down to the floor. 
Your probable reaction? "Yes, but I called you to unclog my sink. Could I 
trouble you to pull out the snake and address the problem at hand?"

As with any engineering exercise, there are a lot of pet solutions out 
there that people want to see employed - my favorites du jour include 
explicit congestion notification for TCP/SCTP QoS, and certain extensions 
to OSPF V3 for routing in certain classes of mobile ad hoc networks. But if 
you can't tell me "this happened in a past emergency or there is a good 
rationale supported by the following data and argument that it could happen 
in the next one, and that would affect the effectiveness of emergency 
services", or "there is a service in the telephone world that needs to be 
able to signal across an Internet island to support emergency services, 
whether it is an issue in the Internet or not", you haven't got a problem 
that the ieprep working group needs to solve. In such a case, I 
fundamentally don't need to hear about your favorite solution - even if I 
agree (as I do in the case of multicast) that it is a great solution which 
I would like to see more use of.

Brass tacks. We need to get down to brass tacks. Show me a problem, a 
problem that affects emergency services, or affects telephone networks of 
different technologies when they cross an Internet island and so affects 
emergency services using those telephone networks. A problem is, by 
definition, not "my pet solution has not been adopted", but "X breaks when 
bad things happen, and as a result emergency services are less effectively 
deployed and used" or "If X were adopted, emergency services would be 
enhanced in this readily demonstrable way." *Then*, lets discuss potential 
solutions, and talk about whether or not they fix the problems before the 
house. Lets adopt the solution if and only if it actually fixes the problem. 

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: "Stuart (Stu) Goldman" <[email-masked]>
Date: Sun, 31 Mar 2002 09:32:02 -0700

Fred,

Is it possible that the trouble is that we all are just asking the wrong
question? It seems to me that we are asking. "if we should work on known
problems, or if we should work on adding more tools to the toolbox available for
use in emergency situations?"

Perhaps we instead could ask how we can accomplish both.

I have heard no argument at all against fixing known problems that would
adversely affect emergency calls during a disaster. So, I think the speakers are
in full agreement on this point.

The remaining portion of the question revolves around adding additional tools to
the tool box, just in case.

I have to admit that the first picture that came to my mind when the argument
was made that "proof of a problem" is needed, was that of the debate on global
warming. By the time the proof becomes indisputable, it will simply be too late
to apply the remedy to save the planet.  (Since global warming is not within the
charter, I hope not to have started a new thread here.)

Since we can not predict what parameters the next disaster will have, the more
tools we have in the box for our disposal, the better. Not only do we have the
traditional natural disasters, but we also now have significant man-made acts of
terror that hold "unexpectedness" as a valuable component.

Having said all that, I realize that just adding tools costs money and there is
no unlimited budget here.

Perhaps a reasonable path forward would be to include investigation of new tools
that can at least show some logical basis that they might possibly be of some
help in a disaster, even if no complete, definitive proof can be offered that
guaranty they will be needed.

I would much rather error on the side of having an unused tool in the box, than
finding I needed a tool I didn't have in the event of a disaster. The stakes in
this exercise are just too big to allow such a failure.