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] Re: [CAP] [emergency] NOAA Undermining International Standards?


I have been watching this issue unfold for several years - it is not 
new.  Art and I made a request of NOAA over a year ago at the IPAWS 
conference to provide the details of how their implementation was 
different so that the OASIS Emergency Management Technical Committee 
so it could be evaluated in light of the CAP 1.1 update.  This 
information was not forthcoming nor has any method tried so far to 
discuss this in an open consensus based format.  Although Art and I 
have not talked about this recently, I assume he wanted to get this 
in the open space before the OAT because his efforts to be heard from 
a part of the team have been to no avail.

The NOAA implementation chooses not to use an optional field.  Given 
that protective action measures are commonly stored in that field, 
NOAA has no place to prescribe such actions.  I am not sure of their 
reason for this implementation detail although it is my understanding 
that it is in part due to deficiencies in the legacy equipment which 
with they must work and possibly due to their lack of familiarity 
with protective actions for NON-weather emergencies.  In any case, 
their choice to not use an optional field does not make them 
non-compliant, just not interoperable with systems built along the 
intent of the fields.

I am pursuing OASIS guidance on this issue and will pass along what I 

Elysa Jones, Chair
Engineering Program Manager
Warning Systems, Inc.
256-880-8702 x102

At 07:43 AM 6/2/2006, Lee Tincher wrote:
>Although I understand and agree with the technical aspects of Arts point I
>must respectfully disagree with the approach you outline to rectify it.  I
>am not certain that this is outside the bounds of OASIS other than to
>possibly make a statement that the proposed implementation is not truly CAP
>As I understand it HazCollect is currently in Operational Acceptance Testing
>and Art is a member of the OAT team.  Wouldn't HazCollect OAT be a more
>appropriate place to bring up this issue?
>I would like to ask Elysa to weigh in on this to see if this is an
>appropriate discussion by OASIS guidelines.
>-----Original Message-----
>From: Rex Brooks [mailto:rexb@starbourne.com]
>Sent: Friday, June 02, 2006 8:34 AM
>To: Art Botterell; Emergency Mgt XML TC
>Cc: cap-list@lists.incident.com
>Subject: [emergency] Re: [CAP] [emergency] NOAA Undermining International
>Thanks Art,
>I understand better now.
>Sorry for not responding earlier, but aside from being busy, I have
>consulted a bit to see if I can find an appropriate ear into which to
>put the message I spoke about in my first reply. That is still my
>best recommendation in terms of a non-confrontational route to a
>satisfactory conclusion. It is not sure that what little I could do
>will be useful, but that remains to be seen.
>Obviously, just having this conversation publicly also carries a
>certain impact, and because you have pinpointed the specific problem,
>we can begin to address it. My primary concern at this point, then,
>is finding a way to make it clear that this policy could be a grave
>error for any downstream systems that rely solely on HazCollect for
>instructions in life-threatening circumstances. I think the larger
>issues are significant, but for immediate clarity, we probably should
>keep to the simplest and most direct message, focusing on the
>specific point at which this policy is dangerous.
>It may be crude and open to criticism as alarmist, and I think we
>need to make it clear that we only use this tactic when it is clear,
>specific and not a case of crying "Wolf!" but in this case, with a
>narrow focus on the specific NOAA policy of dropping of the separate
>"instruction" field and the inevitable confusion engendered by a
>non-standard CAP representation putting the vital information
>intended for the "instruction" field within the "description" field,
>we need to get press to the effect: "How Many Will Die Due to NOAA
>I don't like it, and if anyone can get the message to NOAA that this
>is what will happen if they don't immediately fix this, please do,
>but this is what will get the attention that is required to prevent
>this from happening.
>Don't shoot the messenger folks! and remember, I suggest this only on
>the basis of practicality, because unless we can find a
>non-confrontational way to resolve this, we are forced as a body, in
>the TC, of putting the remainder of our own work at risk for a
>concerted effort to undermine it if we feel we have to take a
>confrontational course. Letting the press do the job keeps us from
>being immediately targeted by whomever falsely believes that they
>have a vested interest in maintaining a status quo that is already
>doomed to an eventual demise. It is only a case of what "events"
>constitute the "eventual."
>I am hoping that the folks at NOAA simply don't fully understand the
>ramifications, whatever the underlying reasons are for this
>unfortunate decision.
>At 8:11 AM -0700 6/1/06, Art Botterell wrote:
> >On Jun 1, 2006, at 6/1/06 6:12 AM, Rex Brooks wrote:
> >>  Thanks for the heads up, Art,  Can you provide the specific parts
> >>  of CAP that are not being implemented?
> >
> >Rex -
> >
> >What's really tragic here is that the problem would be trivial if it
> >didn't have such lethal potential.
> >
> >First off, let me stress that my concern is NOT with the various NOAA/
> >Battelle requirements that certain CAP-optional elements be treated
> >as mandatory.  (E.g., while one might debate the wisdom of mandating
> >use of the legacy SAME coding on such a massive scale... thus
> >perpetuating SAME's obsolescent and inflexible geographic targeting
> >and slowing the move to true geospatial/location-based alerting...
> >it's still a legitimate "profile" requirement in terms of the CAP
> >specification.)
> >
> >But where HazCollect left the fold altogether was in their unilateral
> >choice not to support the CAP <instruction> element.  Which means
> >that a well-formed CAP message, with the hazard description in
> ><description> and the safety instructions in <instruction>, would
> >lose a critical part of its meaning in transiting the HazCollect
> >network.  Remove the sender's instructions from a message and people
> >could get killed.
> >
> >The ostensible reason for this is that the existing Weather Radio and
> >EAS delivery systems are limited to two minutes of audio,
> >corresponding to something like 240 written words.  The HazCollect
> >answer has been to truncate the <description> field at 240 words and
> >to ignore the content of the <instruction> element altogether.
> >Obviously it would be a simple matter to concatenate-and-trim (or
> >trim-and-concatenate) the two fields, but for some reason NOAA has
> >chosen consistently to make excuses ("not in the original design" /
> >"no money") instead of simply writing the requisite change order.
> >
> >In delving into this with various NOAA and Battelle staff, an
> >underlying concern has surfaced... that the existing NOAA "weather
> >wire" teletype format makes no structural distinction between the
> >informational and "call to action" section of their messages.  Why
> >this would matter one way or the other is unclear to me, except
> >possibly as reflecting a desire not to allow anything into HazCollect
> >that would make pre-existing systems look bad by comparison.
> >
> >A subtle but crucial distinction is involved here, between providing
> >for compatibility with legacy systems and imposing the limits of
> >those legacy systems on future technologies.  The OASIS Emergency
> >Management Technical Committee and its predecessor, the CAP Working
> >Group, both went to great pains in designing CAP to provide for back-
> >compatibility without sacrificing the design requirements we drew
> >from the social science research on how effective warning systems work.
> >
> >But the real issue isn't a particular design choice, it's a policy
> >under which NOAA seems to be trying to rewrite the CAP specification
> >without consultation or formal process.  That goes to the credibility
> >of the entire standards effort.
> >
> >- Art
> >_______________________________________________
> >This list is for public discussion of the Common Alerting Protocol.
> >This list is NOT part of the formal record of the OASIS Emergency
> >Management TC.  Comments for the OASIS record should be posted using
> >the form at
> >http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=emergency
> >CAP-list mailing list
> >CAP-list@lists.incident.com
> >http://eastpac.incident.com/mailman/listinfo/cap-list
> >
> >This list is not for announcements, advertising or advocacy of any
> >particular program or product other than the CAP itself.
>Rex Brooks
>President, CEO
>Starbourne Communications Design
>GeoAddress: 1361-A Addison
>Berkeley, CA 94702
>Tel: 510-849-2309
>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
>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

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