Subject: [Ieprep] "BCP" for emergency app designers

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 27 Nov 2002 14:03:35 -0500

Given all the discussion we've had along the way about who can do what, 
I wonder if one productive output of the WG might be a set of guidelines 
for designers of emergency communications applications. I'm not sure yet 
whether this will turn out to be more than motherhood/apple-pie/turkey 
statements ("use a robust codec"), but there might be some principles 
that are more in the zero-conf domain. For example, it is probably a 
good idea to design applications so that they remain useful in network 
islands. (As one simple example, one might be a bit more generous with 
DNS timeouts and rather use some old data for an A record rather than 
just giving up.) Basically, things should work even if the DHCP server, 
DNS server and maybe part of the routing infrastructure are 
dysfunctional. (See the application-overlay-routing work that's been 
done at MIT, I believe.)

Maybe this is just zeroconf, but this is kind of an "involuntary" zeroconf.

Henning

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

---

From: Rex Buddenberg <[email-masked]>
Date: 29 Nov 2002 12:02:09 -0800

On Wed, 2002-11-27 at 11:03, Henning Schulzrinne wrote:
> for designers of emergency communications applications. 

You've gotten to the conclusion that I started with.  Most of the
emergency services plus-ups we need have nothing to do with protocols
(at least ones we don't already have).  They have to do with
provisioning, business practices and network operations.

For organizing your thoughts ... I've been teaching plowshares -->
swords networking for some time now and we've found through observation
that most of the issues fall into four categories consistently.

1.  Higher availability.  There are three principles of high
availability engineering: 
	- eliminate single points of failure.  So provision altroutes and
especially diverse altroutes.  Backup power and such all fall in this
category
	- reliable crossover.  Stateless routers running IP do this, so no
problems
	- detect failures as they occur -- net management.  SNMP already exists
so the issue is business practices.

2.  Security.  Falls into three categories:
	7 - object level security to protect authenticity (critically
important) and confidentiality (close behind).  Non-repudiation and
integrity fall in this bin as well.  (End-to-end and off-line crypto are
synonyms to object level security here).  
	3 - enclave protection.  Firewalls, intrusion detection, password
protection, gate guards -- all deal with perimeter control.  Less
important for emergency services, listed here for completeness.
	1 - link protection.  Link crypto, spread spectrum etc all fall in this
category.  Again, for completeness ... not usually important for EMS,
but important to understand since we keep trying to use these solutions
for the Layer 7 problems above -- bad fit.

3.  QoS control.  I won't fan these flames any further here. Except that
some of the Layer 3 security controls can help (your qos experience will
be better without spam than with).

4.  Reach to mobile platforms.  
	- loosely coupled applications work best because qos isn't as good here
as in wired -- interactivity may be very low (e.g. if there's a satcom
link involved).  (Interactive voice is like telnet -- tightly coupled
and guaranteed to degrade).  I claim that the protocols here are
inadequate -- 802.11 has a lot of bandaids -- but doubt that we want to
suck them into scope of ieprep.  Note that a lot of the real issue here
is provisioning.