MHonArc v2.5.0b2 -->
emergency message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [emergency] EDXL-DE routing and valueListUrn
Title: Re: [emergency] EDXL-DE routing and valueListUrn
Carl
All of scenarios you have proposed could
use seperate valueListUrn to control distribution of data
within defined Area of Responsiblities. If transfer of data is needed
between these AORs, methods for exchanging messages are avaiable. When can
we talk about this. I believe all of your domain issues are potential
misunderstandings how routing is accomplished.
David E. Ellis
Information Management Architect
(505) 844-6697
David -
While I understand the urgency and while I do not
necessarily disagree with
the contents of your slides on a National Effort
for Emergency Data
Distribution, I would like to add a few words of
caution.
First, what you have outlined are uses cases and requirements
for one domain
of use - alerts as related to secure US DoD sensor nets. I
deal with folks
doing sensor systems and networks in a number of other
countries - all
civilian. Any of these applications using sensors can create
alerts. For
example, a new water portal in Canada that will send alerts based
on stream
flow gauges, traffic alerts being generated by the new generation
of ITS
capabilities, weather alerts, and systems function alerts being
generated by
transducers, and so forth. We cannot loose sight of all the
other potential
use cases that drives the requirements for EDXL - now and in
the future.
Second, and related to the first, is the fact that OASIS is
an international
standards organization. As such, we cannot ignore
requirements for using
EDXL that may be extremely viable in other countries.
It is unfortunate that
we have had little input from organizations in other
countries that have
requirements similar to the US DoD. That is why I am very
pleased with the
progress of the Sensor Standards Harmonization work that
NIST is
spearheading.
Third, we would be remiss in ignoring the
potential for alerts coming from
the emerging sensor nets being designed,
built, and fairly recently deployed
for home systems and office buildings
(office sensor networks are much more
mature). See http://www.usipv6.com/CES_Presentations/CES_Itaru_Mimura.pdf
as
well as all the work being done at UCLA (SOS) and Sun (SUN SPOT).
These
systems are envisioned as being able to automatically generate alerts
(fire,
carbon monoxide, health, etc).
Finally, and anyone (someone)
correct me if I am wrong, but perhaps the
COMCARE EPAD system would be a
repository/registry solution.
So, I agree that current DHS and DoD
requirements are very valid and those
requirements must be answered by EDXL.
But let's make sure we remain
balanced in our approach so that other
communities outside DoD and DHS are
also fairly represented at that CAP and
EDXL have used well beyond.
Cheers
Carl
----- Original
Message -----
From: "Ellis, David" <dellis@sandia.gov>
To: "SIA
Pilot-6"
<sia-pilot6@humanml.cim3.net>;
<emergency@lists.oasis-open.org>
Cc:
"Harry Haury" <hhaury@nuparadigm.com>; "Haleftiras,
Pericles"
<phaleftiras@systechnologies.com>; "Glaser, Ronald"
<rfglase@sandia.gov>
Sent: Saturday, March 18, 2006 10:11
AM
Subject: [emergency] EDXL-DE routing and
valueListUrn
ALL
I have a reasonably mature strategy for
creating valueListUrn lists and
how they can be used to deploy a national
architecture for Alerting and
Warning. I have been trying to develop
this to support Chips Disaster
Management efforts (e.g. EDXL-RM) and to allow
for national sensor
capabilities (e.g. DNDO) to have the EDXL-DE routing
system (execution
context) which provides the following
capabilities:
1. Allow for establishment of Communities of Interest
(COIs) where
appropriate authority can establish roles of entities,
information
routing rules between them and issue certificate to
ensure
authentication and authorization.
2. Permit interaction between
COIs to instantiate robust MOUs enforced
by execution context allowing
creation of national information grid.
3. Permit secure delivery of multiple
levels of sensitive information
via signing, encryption and labeling within
the EDXL-DE.
4. Allow abstraction of the implementation details (what) so
national
planners can implement various operational concepts (documented
in
DoDAF, FEA etc.) with minimal confusion on "how" it is
accomplished.
I have tried to engage NIEM for over one year to explain
these concepts
without success. There is finally understanding between
the various
standards organization on how important this is to major
government
implementations. On the other hand, major information
providers are
claim our capabilities either don't exist or have never
been
demonstrated. Both are not true and in fact the EDXL-DE is being
used
in an operational system within the DoD. Unfortunately, it is
not
branded as EDXL-DE since we have not issued the EDXL-DE OASIS
standard
yet.
I need as many of the organization implementing EDXL-DE
to attempt
sending outputs from your applications to the developing EDXL-DE
routing
capability at NuParadigm in Saint Louis or our capability at
Sandia
National Laboratories. Also, a generic ability to wrap CAP
messages in
EDXL has been created and we need to discuss the security
implications
of doing this from local applications or by the "execution
context" for
legacy/warning-only CAP applications.
I need to be able
to list all the capabilities of your applications even
if they use explicated
routing (e.g. DMIS COGs) and have no security
capability. The design of
our governments emerging national
capabilities is moving at lighting speed
and EDXL-DE capabilities needs
to be a substantial portion of it.
Attached are two briefings present
this past week on sensor
routing.
David E. Ellis
Information Management Architect
(505)
844-6697