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
From: Carl Reed OGC Account
[mailto:]
Sent: Mon 3/20/2006 4:20
PM
To: Ellis, David; SIA Pilot-6;
Cc: Harry Haury; Haleftiras, Pericles;
Glaser, Ronald
Subject: Re: [emergency] EDXL-DE routing and
valueListUrn
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" <>
To: "SIA
Pilot-6"
<>;
<>
Cc:
"Harry Haury" <>; "Haleftiras,
Pericles"
<>; "Glaser, Ronald"
<>
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
-----Original Message-----
From:
[mailto:]
On Behalf Of Elysa Jones
Sent: Saturday, February 25, 2006 11:23 AM
To:
Rex Brooks
Cc:
Subject: Re: [sia-pilot6]
[emergency] EDXL-DE Committee Draft
Yes, that is a good point. I
too want us to start coming up with these
"managed lists" knowing full well
that NIEM wont be providing us
anything
in the near term. I had
thought too that we could use the event list,
incident type, etc. that were
provided in the original draft hand off as
a
starting place. Maybe
we should put these in examples and put them in
the
cookbook? I too
think the Govt agencies will not step up to this for
some
time and I am
glad the registry is being developed in the pilot. We do
need another
company though that can sign up for the "use" for the
committee specification
phase. I seem to be focused most these days on
jumping through the
hoops for ratification. Regards, Elysa
At 10:07 AM 2/25/2006, Rex
Brooks wrote:
>Just to clarify, it isn't DMIS or IEM that needs to have a
keyword/list
in
>place, but they do need to be using some values in
those fields that
can
>be recognized and used by all of us, or by
others that need and have
>permissions to do so. We didn't address that
level of permissions, and
I
>doubt that anyone will start restricting
these initial efforts, but it
IS
>another place where security measures
can be imposed if appropriate,
and
>since our pilot is building a
registry where these pointers or the
actual
>resources can reside, I
wanted to mention it. While I want to be fair
to
>gov agencies, I
suspect they will have a more difficult time getting
the
>funding
resources, considering the Congress' recent actions with
regard
to
>"any" already approved E-Gov program movement of monies
preparatory to
>actual spending, the chances are good that what the
organizations in
this
>TC actually produce will be the default system
for quite some time to
>come, so I want to suggest to everyone that they
bear that in mind and
>approach work going forward in the next six months
or so as if this
will
>be all the system there will be for the next
year. Once what we build
>shows that it works, then I suspect there will
quickly be a wealth of
>resources
available.
>
>Regards,
>Rex
>
>At 4:12 AM -0600
2/25/06, Elysa Jones wrote:
>>Hey Rex, Welcome back. I hope your
trip went well. As for the 3
"users"
>>of the EDXL-DE, I think
Sandia, IEM and DMIS volunteered to make the
>>statement about
"use." We wont be able to use Sandia though since
Dave
>>has
an individual membership. I'll put a note out to the list
shortly
to
>>ask who will be our third and if there is any keywords
they must have
in
>>place. Elysa
>>
>>At
10:15 PM 2/24/2006, Rex Brooks wrote:
>>>Yes, this is all
true,
>>>
>>>However, we still need 3 member
organizations to vouch that they
"use"
>>>it as part of the move
to an OASIS-wide vote, so we need to be
implmenting
it.
>>>
>>>Regards,
>>>Rex
>>>
>>>P.S.
This means that we need to get an EventType Keyword/List
and
>>>Sender/Recipient Keybord/List, etc, published by the
appropriate
groups.
>>>
>>>>Hey
Tim,
>>>>Yes, the next TC call is 3/9. Whether we pull it
now and make a
change
>>>>or wait until another round we could
still not get it to a final
OASIS
>>>>vote until May given the
calendar process requirements. The
Committee
>>>>Draft has to
be to OASIS for 5 business days before going to 15 day
>>>>review
and must be back from 15 day review, comments
addressed,
voted
>>>>Committee Specification and back to OASIS
by the 15th of the month
>>>>prior to the ratification
vote. We are on a tight schedule for a
vote
>>>>the last
2 weeks of April even if we receive no
substantive
comments.
>>>>Thanks for your
input,
>>>>Elysa
>>>>
>>>>At 12:31
PM 2/22/2006, Tim Grapes
wrote:
>>>>>All,
>>>>>Do I correctly recall
that our next TC meeting won't be
conducted
until
>>>>>March 9? If so, I recommend we
lay out our cards now in case
anyone feels
>>>>>the option
to pull back and re-publish is
warranted.
>>>>>
>>>>>My input is that this
is simply a typo that can be corrected
after
this
>>>>>15-day review. However, if
others feel the error truly is
substantive, I
>>>>>feel we
should pull it back, make the correction, and
republish
ASAP
>>>>>rather
>>>>>than
incurring an additional 15-day public
comment.
>>>>>
>>>>>Regards,
>>>>>
>>>>>Tim
Grapes
>>>>>Evolution Technologies,
Inc.
>>>>>Disaster Management egov
Initiative
>>>>>Science and Technology
Directorate/OIC
>>>>>Department of Homeland
Security
>>>>>Office: (703)
654-6075
>>>>>Mobile: (703)
304-4829
>>>>>
>>>>>
>>>>>
>>>>>-----Original
Message-----
>>>>>From: Elysa Jones [mailto:]
>>>>>Sent:
Wednesday, February 22, 2006 1:06 PM
>>>>>To:
>>>>>Subject: [emergency]
EDXL-DE Committee Draft
>>>>>
>>>>>TC
Members,
>>>>>
>>>>>As discussed on our call
yesterday, there are a couple of issues
with
the
>>>>>EDXL-DE that have been brought to light from within
the TC. We are
not
>>>>>able to make any changes to
the posted documents until after the
15
day
>>>>>review. That review is schedule to end
March 4. The only comments
so far
>>>>>have come from
within the TC although I fully expect some comments
as
the
>>>>>end draws near. The most significant comment is
the problem with
the
>>>>>schema not matching the
DOM. The DOM is correct and the place
most
folks
>>>>>look for understanding of what is
presented.
>>>>>
>>>>>I have discussed our
situation with Mary McRae, our OASIS staff
contact
to
>>>>>determine our most efficient method to proceed.
She said that if
in the
>>>>>mind of the TC, the schema
would be considered non-normative, it
could be
>>>>>changed
as any other typo or correction that is non-substantive
after
the
>>>>>15-day review is
complete.
>>>>>
>>>>>If we do feel that the
correction of the schema is
substantive,
another
>>>>>15-day comment period would be
required. In that case, we could
pull
the
>>>>>current 15-day review, make the change and
re-publish. Or we could
wait
>>>>>until this period
is over, make our corrections and re-post
for
another
>>>>>15-day review. In either case, the
document has to go to OASIS
by
the
>>>>>15th
>>>>>of the month prior
to the month of the vote. With a
successful
15-day
>>>>>review in this round, we will be
able to submit to OASIS by the
15th of
>>>>>March and thus
an OASIS wide vote the last 2 weeks of April.
A
second
>>>>>15-day review no matter how it happens will
postpone the OASIS wide
vote
>>>>>until the last 2 weeks of
May.
>>>>>
>>>>>That is where we stand now
and there is no real need for a
decision
at
>>>>>this
>>>>>point.
Please consider whether you feel the incorrect schema
is
>>>>>substantive or not and let me know the will of the TC
as to how
we
>>>>>proceed.
>>>>>
>>>>>Regards,
>>>>>Elysa
Jones
>>>>>Chair, OASIS
EM-TC
>>>>>Engineering PRogram
Manager
>>>>>Warning Systems,
Inc.
>>>>>
>>>>>
>>>>>
>>>>>-------------------------------------------------------------------
--
>>>>>To
unsubscribe from this mail list, you must leave the OASIS
TC
that
>>>>>generates this mail. You may a link to
this group and all your
TCs
in
>>>>>OASIS
>>>>>at:
>>>>>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.
php
>>>>>
>>>>>--
>>>>>No
virus found in this incoming message.
>>>>>Checked by AVG Free
Edition.
>>>>>Version: 7.1.375 / Virus Database: 268.0.0/266 -
Release
Date:
2/21/2006
>>>>>
>>>>>
>>>>>--
>>>>>No
virus found in this outgoing message.
>>>>>Checked by AVG Free
Edition.
>>>>>Version: 7.1.375 / Virus Database: 268.0.0/266 -
Release
Date:
2/21/2006
>>>>
>>>>
>>>>
>>>>
>>>>--------------------------------------------------------------------
-
>>>>To
unsubscribe from this mail list, you must leave the OASIS TC
that
>>>>generates this mail. You may a link to this group
and all your
TCs
in
>>>>OASIS
>>>>at:
>>>>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.p
hp
>>>
>>>
>>>--
>>>Rex
Brooks
>>>President, CEO
>>>Starbourne Communications
Design
>>>GeoAddress: 1361-A Addison
>>>Berkeley, CA
94702
>>>Tel: 510-849-2309
>
>
>--
>Rex
Brooks
>President, CEO
>Starbourne Communications
Design
>GeoAddress: 1361-A Addison
>Berkeley, CA 94702
>Tel:
510-849-2309
>
_________________________________________________________________
Message
Archives: http://humanml.cim3.net/forum/sia-pilot6/
To
Post: mailto:
Shared
Files: http://humanml.cim3.net/file/work/project/sia-pilot6/
CWE
Portal: http://humanml.cim3.net/
Community Wiki:
http://humanml.cim3.net/wiki/
--------------------------------------------------------------------------------
>
---------------------------------------------------------------------
> To
unsubscribe from this mail list, you must leave the OASIS TC that
>
generates this mail. You may a link to this group and all your TCs
in
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To
unsubscribe from this mail list, you must leave the OASIS TC that
generates
this mail. You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
