OASIS Emergency Management TC

 View Only

RE: [emergency] EDXL-DE routing and valueListUrn

  • 1.  RE: [emergency] EDXL-DE routing and valueListUrn

    Posted 03-20-2006 23:58
     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


    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]