[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emergency] Re: [CAP] [emergency] NOAA UnderminingInternational Standards?
Hi Lee, Procedurally, I agree with you, and I think that would be the best way to handle it. I wasn't aware of that special program when I last I wrote, but what I outlined may still need to be considered later on, if an OAT issue report doesn't serve to alert the program to a grave problem. I am sure they don't quite see the situation the way we do, or else the reasons given that Art recounted would not have been sufficient to warrant dropping the "instructions" field. I doubt that this is a concerted effort to preserve proprietary systems. I suspect it is far more likely just a case of shortsightedness along the lines of "why should we make more work out of this particular functionality." However, that's exactly the sort of thing that accumulates within systems as large as the one under construction, of which I understand HazCollect is a subset. So, some corners cut here to make implementation easier could end up making the larger system more vulnerable to breakdowns that could cost lives. Thanks for the new information, Lee, I appreciate it. Regards, Rex At 8:43 AM -0400 6/2/06, Lee Tincher wrote: >Rex, > >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 >compliant. > >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. > >Thanks, >Lee > >-----Original Message----- >From: Rex Brooks [mailto:email@example.com] >Sent: Friday, June 02, 2006 8:34 AM >To: Art Botterell; Emergency Mgt XML TC >Cc: firstname.lastname@example.org >Subject: [emergency] Re: [CAP] [emergency] NOAA Undermining International >Standards? > >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 >Policy?" > >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. > >Regards, >Rex > >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 >>CAPemail@example.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 >at: >https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php -- Rex Brooks President, CEO Starbourne Communications Design GeoAddress: 1361-A Addison Berkeley, CA 94702 Tel: 510-849-2309