I would be very hesitant to tie the EDXL-DE specification to any particular
implementation platform. I think you are saying the same thing. Would be best to
keep EDXL (or any payload) transport agnostic. Better to define best practices
for particular implementation and deployment platforms.
----- Original Message -----
Sent: Wednesday, June 30, 2010 1:29
PM
Subject: [emergency-if] Federating OASIS
EDXL-DE routing capability with goal of supporting SOIS
Jeff, Hans, EM TC
Infrastructure subcommittee;
I am trying to position the
OASIS EDXL-DE standard as one of the capabilities for
supporting the
Strategic Operations Information Sharing (Google for current public info). This
will support federal agencies sharing all types of
information sharing use
to support Commanders
Critical Information Requirements (CCIRs) and Essential Elements of
Information (EEIs) in times of emergencies. Since most of the Federal
planning scenarios began locally, the discussions of how to federate various
information collection and sharing capabilities is becoming more
critical.
I represent USNORTHCOM as a
Subject Matter Expert supporting creating SOIS planning and capability
development. This requires me to examine the trends of emerging
Standards development and attempt to create understanding within these
bodies about
SOIS requirements to
federate federal, state, local and tribal information sharing resources.
This is why I have such an interest in federating
capability from all OASIS
EDXL-DE distribution capabilities and strive to ensure OASIS EDXL-DE messages
met sensitivity and repudiation requirements for consolidation and up channel
reporting to federal agencies.
Sandia National Laboratories
has been working on this for over ten years. This began for DTRA before
9/11 and DHS/USNORTHCOM were formed. We have been using a commercial
product for over seven years to prototype TSG and SPOR
technology which use the
OASIS EDXL-DE. This
was used in developing the First OASIS EDXL-DE specification. During
this time we have interfaced with DMIS, DTRA HPAC/Ensco, and all of the CWID
2005 participants. Later we supported IPAWS development and interfaced
MyStateUSA, Warning Systems, and many other information injection and
subscriber capability. Currently we are supporting operation deployment
of DNDO AIR and other DoD programs. The current Sandia deployments of
OASIS EDXL-DE routing capabilities do not have requirements to share
information with many capabilities like IPAWS Open, EAS and CMAS systems, HPAC
etc. Therefore; in our systems, if we would receive an OASIS EDXL-DE
message with an IPAWS profile or IPAWS OPEN COGS, our system would check
for EDXL-DE schema
compliance using
CAM and ignore attempting to
process elements.
The bottom line is even if you
receive a valid OASIS EDXL-DE message there should be no immediate requirement
to execute deliver specified by
these elements for this
message to some EDXL-DE routing capability which can process it. That
said, ultimately it would be ideal to have a federation of EDXL-DE routing
systems which could support an ever increasing set of capabilities. The
Internet took years to build and continues to evolve (e.g. IP V6, secure
DNS). Therefore, we need to focus on the practices and/or methods of
building capability which will migrate to ubiquitous information sharing
interoperability.
Every constituency should be
encouraged to choose the type of OASIS EDXL-DE capability which meets their operational needs.
David E. Ellis
(505)
844-6697