RE: [Ieprep] IAA charter item query

Rex Buddenberg <budden@nps.navy.mil> Thu, 06 October 2005 17:31 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENZaf-0005sb-In; Thu, 06 Oct 2005 13:31:33 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENZad-0005rO-5b for ieprep@megatron.ietf.org; Thu, 06 Oct 2005 13:31:31 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16702 for <Ieprep@ietf.org>; Thu, 6 Oct 2005 13:31:27 -0400 (EDT)
Received: from ellis.ad.nps.navy.mil ([131.120.18.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENZjk-0001Vq-QV for Ieprep@ietf.org; Thu, 06 Oct 2005 13:40:57 -0400
Received: from antony ([131.120.179.249]) by ellis.ad.nps.navy.mil with Microsoft SMTPSVC(5.0.2195.6713); Thu, 6 Oct 2005 10:31:13 -0700
Subject: RE: [Ieprep] IAA charter item query
From: Rex Buddenberg <budden@nps.navy.mil>
To: "GOLDMAN, STUART O (STUART)" <sgoldman@lucent.com>
In-Reply-To: <17D8724A2A8D9542B2B8AE546B9E5BBC05350815@az4315exch001u.phx.lucent.com>
References: <17D8724A2A8D9542B2B8AE546B9E5BBC05350815@az4315exch001u.phx.lucent.com>
Content-Type: text/plain
Date: Thu, 06 Oct 2005 10:31:13 -0700
Message-Id: <1128619873.5402.693.camel@antony>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-6)
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 06 Oct 2005 17:31:13.0658 (UTC) FILETIME=[BFCD6DA0:01C5CA9B]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c
Content-Transfer-Encoding: 7bit
Cc: Ieprep@ietf.org
X-BeenThere: ieprep@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet Emergency Preparedness Working Group <ieprep.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ieprep@ietf.org>
List-Help: <mailto:ieprep-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=subscribe>
Sender: ieprep-bounces@ietf.org
Errors-To: ieprep-bounces@ietf.org

Eric, Stu, and ...

One of my colleagues has generated the nasty habit of raiding my lab and
heading off to disasters.  First the tsunami (Phuket, Thailand to be
specific) and most recently Katrina (Hancock County, Ms).  There's a
distinct pattern that shows here:

1.  In all cases, there's a multi-agency government/quasi government
command and control operation.  Often with ad hoc players that just sort
of appear on scene.  These need
	- instant internet to replace the wiped-out infrastructure
	- an interoperable set of applications (e-mail, instant messaging,
common operational picture, ...).  Your comment is right -- authenticity
is a core requirement that is lacking in may of the off-shelf apps and
certainly in the off-shelf configurations out there.  
	

2.  In some cases, there's a big family reunification problem.  It
didn't occur in, say, Northridge earthquake because the quake had the
manners to arrive at o-dark-thirty when the kids weren't in school, etc.
But there were hundreds of Europeans vacationing in Thailand when the
tsunami arrived -- a very large family reunification problem.
Northridge would have had this problem if it had happened at 1000
instead of middle of night.  Katrina had the family reunification
problem layered on top of 1. above; Rita tended not to because the
warnings were heeded much more seriously.
	In Thailand, my colleague set up an 802.16 backbone with a satellite
backhaul to the Internet and populated the fringes of the .16 network
with 802.11 APs.  The primary penetrations were into a refugee camp and
a Buddhist monastery that had been appropriated as a morgue (DNA
sampling for victim ID -- surprisingly data intensive).  When the crew
got the system up and running, they simply turned it on.  And got about
50 customers in the first couple of hours (no advertising).  
	Both the morgue workers and a lot of the refugee camp population had
laptops. 

In such situations, the Internet panoply of applications is not
essential.  E-mail and www access is.  Voice service .... is not.  One
of the things our crew found in Mississippi was some aid crews showing
up with things like video cameras to document what they were doing.
That's fine, but don't build a local web site and put all the videos up
here!  (Church groups are notorious for this).   KISS is essential.  The
crews are hooking up ad hoc configurations with players that have never
worked together before -- nature of the beast.  The deployment crew may
be novices.  Fancy configurations self-defeat.  Focus on the main event
(there's a circuit-switch cellphone vs packet switch holy war that has
to be resolved here).  


Abstracting from the experiences, tells us that things like QoS control
are not terribly valuable (beyond policing the fringe users not to be
spendthrift and a few firewall configs to enforce).  Authenticity, as
Stu mentioned, is critical -- spoofing data anywhere along this chain is
bad news.  Confidentiality is also a requirement (note the medical data
above).  Stu's again right in observing that e-mail and www access to
databases are pretty kind to packet switch plumbing and any QoS cures
are likely to be worse than the disease.   
	Distributed electrical power (a few 10s of watts in several locations
rather than kwatts in one) is an issue -- no convenient technology for
that.    There's an endless list of things that belong in the packout
kits (e.g. mosquito netting) that we could get unproductively wound up
on.  
	There is a sizable issue in high Ao engineering (to pre-empt some of
the recovery problems).  

The Katrina crew did install some VOIP capabilities.  A naive judgement
of their experiences was that QoS Control was not the problem, just
getting them configured to work _at all_ was the headache.  

Anywhere near what you were looking for?





On Thu, 2005-10-06 at 11:14 -0500, GOLDMAN, STUART O (STUART) wrote:
> Eric,
> 
> Like everyone else on the planet, I was glued to the TV during the resent disaster in New Orleans.
> 
> There were a number of occasions where the victim being interviewed said they had lost touch with family members and used the TV broadcast as an opportunity to send a message saying where they were now and how they could be contacted by the missing family members. As I watched this exchange a number of times, each time I was reminded of the ""I Am Alive" capability database that still is not in existence  in the US.
> 
> Having said that, it is my understanding that such a capability would entail the ability to post location/status type of data about individuals on a database that could be queried by the public. Perhaps the posting might need to be done by an agency such as the Red Cross in the US, to avoid malicious postings. (Mickey Mouse is OK, or worse, fraudulent information).
> 
> If that understanding is basically correct, then it would seem to me that neither the posting nor the querying of the database, while important to the participants, is of a nature that it would need preference over other traffic, such as the communications from First Responders require.  If it sufficient to support this capability with the same level of service as provided for ordinary communications, does the effort then fall on just developing the capability, which may not need any special accommodations in the IP space, or am I missing something?
> 
> 
> Stu Goldman
> Lucent Technologies
> 5531 E. Kelton LN
> Scottsdale,AZ 85254
> 602 493 8438 home office
> 623-582-7136 voicemail  
> 
> 
> -----Original Message-----
> From: ieprep-bounces@ietf.org [mailto:ieprep-bounces@ietf.org]On Behalf
> Of Eric Brunner-Williams at a VSAT somewhere
> Sent: Tuesday, October 04, 2005 7:39 PM
> To: Ieprep@ietf.org
> Subject: [Ieprep] IAA charter item query
> 
> 
> Oki all,
> 
> I've grovelled through the archives abck to the first charter and I haven't
> found a satisfactory discussion of the IAA requirement, or non-requirement,
> or operational experience(s) with any IAA specificiation or reference
> implementation.
> 
> If anyone has some clue to throw my way, I'd appreciate it. The data is
> anecdotal, but in the Katrina outage area IAA-like query and response
> attempts (absent an actual IAA mechanism other than voice-to-voice w/o
> any call routing or forwarding or logging, other than that incidental to
> voice service, contributed to network load, responder tasking, dispatch
> failure, and of course, end user stress, and no governmental or quango
> involved in Katrina response operates a "missing persons" database, though
> one quango has made an attempt in that area.
> 
> Cheers,
> Eric
> 
> _______________________________________________
> Ieprep mailing list
> Ieprep@ietf.org
> https://www1.ietf.org/mailman/listinfo/ieprep
> 
> _______________________________________________
> Ieprep mailing list
> Ieprep@ietf.org
> https://www1.ietf.org/mailman/listinfo/ieprep
-- 
b


_______________________________________________
Ieprep mailing list
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep