OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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


From: Carl Reed OGC Account [mailto:creed@opengeospatial.org]
Sent: Mon 3/20/2006 4:20 PM
To: Ellis, David; SIA Pilot-6; emergency@lists.oasis-open.org
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" <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

-----Original Message-----
From: sia-pilot6-bounces@humanml.cim3.net
[mailto:sia-pilot6-bounces@humanml.cim3.net] On Behalf Of Elysa Jones
Sent: Saturday, February 25, 2006 11:23 AM
To: Rex Brooks
Cc: sia-pilot6@humanml.cim3.net
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
>>>>>tgrapes@evotecinc.com
>>>>>tim.grapes@associates.dhs.gov
>>>>>
>>>>>-----Original Message-----
>>>>>From: Elysa Jones [mailto:ejones@warningsystems.com]
>>>>>Sent: Wednesday, February 22, 2006 1:06 PM
>>>>>To: emergency@lists.oasis-open.org
>>>>>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:sia-pilot6@humanml.cim3.net
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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]