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?

Thanks Elysa,

Every bit of information is helpful in this situation. My primary 
concern follows Art's to the extent that a large constituency of 
possible developers may inadvertently elect not to implement the 
instructions field because NOAA doesn't and NOAA may be as far as 
they look for guidance. This is particularly inappropriate for 
HazCollect. Organizational and social procedures aside, we still have 
to accept and deal with human nature, and short of an overriding 
necessity to supply information, the maxim 'when in doubt, leave it 
out,' is especially true for software built to standards in an age 
where codebloat is ubiquitous.


At 10:26 AM -0500 6/2/06, Elysa Jones wrote:
>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 receive.
>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
>>>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
>>>CAP-list mailing 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
>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

Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309

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