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: [sia-pilot6] [emergency] EDXL-DE routing and valueListUrn

I do believe we need to develop some use cases with representative 
distribution that can be published in an implementation guide.  This 
concept will take a bit to catch on and examples seem to be the best 
approach.  I would favor the start of an SC specifically focused on 
implementation.  This would give a home for new members of the TC that will 
need a bit of guidance as they learn the process. I plan to put this on the 
agenda for our meeting tomorrow.


At 06:33 PM 3/20/2006, Rex Brooks wrote:
>I don't think Carl misunderstood that different valueListUrns are
>possible. Of course, I could be wrong, but I doubt it. I think Carl's
>concern is that some people may think that Dave's proposal was for a
>single valueListUrn. I do not think Dave is doing that. I think Dave
>is responding to the call for various groups to start producing,
>publishing and maintaining these necessary valueListUrns so that we
>can start using them in EDXL_DE routed messages.
>All of the international groups and constituencies mentioned need to
>be informed that it is now incumbent upon them to provide these
>semantic resources so that their systems, be they SensorNets or
>weatherAlerts, can be properly connected through our Emergency
>Response Networks.
>At 5:00 PM -0700 3/20/06, Ellis, David wrote:
> >Content-class: urn:content-classes:message
> >Content-Type: multipart/alternative;
> >       boundary="----_=_NextPart_001_01C64C7A.707355BB"
> >
> >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>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>mailto:sia-pilot6-bounces@hu 
> manml.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
> >>>>>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
> >>>>>>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>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> 
> 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 
>  >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/>http://humanml.cim3.net/forum/ 
> sia-pilot6/
> >To Post:
> ><mailto:sia-pilot6@humanml.cim3.net>mailto:sia-pilot6@humanml.cim3.net
> >Shared Files:
> ><http://humanml.cim3.net/file/work/project/sia-pilot6/>http://humanml.cim 
> 3.net/file/work/project/sia-pilot6/
> >CWE Portal: <http://humanml.cim3.net/>http://humanml.cim3.net/
> >Community Wiki: <http://humanml.cim3.net/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> 
> 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>h 
> ttps://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups..php
> >
> >
> >  _________________________________________________________________
> >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/
>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/

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