[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [emergency-comment] RESEND-Add "Avoid" in "responseType"
I just want to chime in again in support of this as a necessary and non-disruptive addition. - Art Art Botterell, Manager Community Warning System Contra Costa County Office of the Sheriff 50 Glacier Drive Martinez, California 94553 (925) 313-9603 fax (925) 646-1120 >>> Billy Pitts <bpitts5@mac.com> 12/2/2008 8:46 AM >>> I am resending the letter in its entirely, as the original didn't have the chart attached. I have also made some some minor edits. I wanted to be sure the "archive" contained the entire proposal. (Thanks to Rex Brooks for forwarding the material.) 650 Massachusetts Ave, N.W. 6th Floor Washington, DC 20001 November 25, 2008 OASIS Emergency Management Technical Committee (EM TC) Organization for the Advancement of Structured Information Standards Dear Committee Members: This letter is to inform you, as the appropriate entity of OASIS overseeing the development of the Common Alerting Protocol standard, of a proposal adopted by the Commercial Mobile Alert Advisory Committee to add “Avoid” to the current code values for the element “ResponseType” for the purpose of creating text messages under the Commercial Mobile Alert System. (A copy of the relevant portion of the meeting transcript is attached.) I would encourage you to take action to include this change to the CAP standard and register it as part of the standard going forward. I was privileged to serve as a member of the Commercial Mobile Alert Advisory Committee established by the FCC, pursuant to section 603 of the Warning, Alert and Response Network Act (WARN Act). The purpose of the Advisory Committee was to advise the FCC on technical standards and protocols to enable commercial mobile service providers to voluntarily transmit emergency alerts to their subscribers when an incident occurs. The committee, and the “User Needs” subgroup, on which I served, spent considerable time and effort analyzing what would constitute an effective text alert. The Advisory Committee recommended and the FCC ultimately embraced a proposed architecture and standards for delivering alerts to the public using Common Alerting Protocol (CAP). Any alert initiator must use CAP as the basic alerting protocol that would be sent to an alert gateway/aggregator. The alert gateway would then create text messages, which, at least initially, would have a technical limit of 90 characters of text. The scenario for nominal text in a CMAS Alert was in section 4.1.1 of the Advisory Committee’s recommendation: When an event occurs, the local alert initiator would use CAP to create an alert, which would then be sent to an alert gateway/ aggregator. The appropriate government entity performing that role will be FEMA who would then create and issue a text based CMA to warn the CMSP subscribers within the indicated alerting area.” The procedure for generating a CMAM from CAP fields is in section 5.3.2 of the Committee’s report: “For initial CMAS system deployment and until Alert Initiators are trained in the generation of CMAM, in order to create consistent and accurate CMAMs, the CMSAAC recommends that the Alert Gateway ‘construct’ the CMAM using selected required and optional fields in the CAP message.” The Committee recommended that the alert’s recommended action to be taken be constructed from the optional “ResponseType” CAP field. The Committee further recommended, “that a process be developed by which new ResponseType Codes can be developed and registered.” We recognized that “generating CMAM using CAP fields may not provide flexibility*to tailor the CMAM content to a specific alert event,” and that the CMAM “may not be very meaningful to the end user.” The Committee’s report points to the “recent steam pipe explosion in New York City” as an example where a CMAM automatically generated CMAM under the current CAP standard would not have provided enough meaningful information. The Committee was concerned about not addressing adequately in the current CAP standard enough recommended actions that might be proposed to elicit an appropriate response to potential hazards. Members of our subgroup, and ultimately the full advisory group, wanted to assure that the constructed text stream options could more fully address incidents like the steam pipe explosions or the terrorist attacks of 9-11 in New York City. To better respond to such situations we proposed to add, “Avoid” to the current code values for the element “ResponseType” of the CAP 1.1 standard. The Commercial Mobile Alert Advisory Committee supported this change without opposition. While the Advisory Committee decided that this new code value should be added, we recognized, that neither we, nor the FCC had the authority to change the CAP standard. During the adoption of this proposal by the Advisory Group, an amendment was offered to better clarify the text stream that would be constructed as a result of “Avoid” filling the optional “responseType” field. The amendment proposed was to add the word “hazard” making the potential text “avoid hazard” which was consistent with our effort to address all hazard alerting. As with the other values, there remained the option to include additional recommendations in the <instruction> field, for example, if the alert was warning about dangerous food products the alert might recommend to “avoid consuming.” If this recommendation were incorporated into the CAP standard the 3.2.2 "info" Element and Sub-elements chart would read as follows, (in the same fashion as the other existing code values): Element Name - responsetype Context. Class. Attribute. Representation - cap. alertinfo. responseType. code Definition and (Optionality) - The code denoting the type of action recommended for the target audience. (OPTIONAL) Notes or Value Domain - (1) Code Values: "Shelter" - Take shelter in place or per <instruction> "Evacuate" - Relocate as instructed in the <instruction> "Avoid" - Avoid hazard or per <instruction> "Prepare" - Make preparations per the <instruction> "Execute" - Execute a pre-planned activity identified in <instruction> "Monitor" - Attend to information sources as described in <instruction> "Assess" - Evaluate the information in this message. (This value SHOULD NOT be used in public warning applications.) "None" - No action recommended It is our hope that the appropriate standards entity will adopt this proposal as part of the CAP standard. Sincerely, Billy Pitts Senior Vice President, Government Affairs Blackboard Inc. <ATTACHMENT> TRANSCRIPT OF FINAL MEETING (Abridged) The Commercial Mobile Service Alert Advisory Committee October 3, 2007 Next on my list is, Mr. Pitts, I have an amendment from you. MR. PITTS: Yes, sir, Mr. Chairman. It should be fairly straightforward. This one is only essentially five letters. It's adding the word avoid in the fields from which we would create the automatic computer generated messages. As Art alluded to, we had endless discussions about concerns about the limitations and character length of text messages, but we all tried to live with it and tried to get these messages to fit within that profile. There was also concern over some messages being computer generated where others were free text, free form text. The Presidential alerts will be free form text. The amber alerts will be free form text, although I haven't really seen examples of either one of them, but initially at least as a default all other messages would be computer generated from the existing CAP fields. I think that there is a deficiency in the response types to fill in the message from the fields that are available to us. The current fields are Shelter, Evacuate, Prepare, Execute or Monitor. There is another one called Assess, but we've decided not to include that. My experience in some of the states with evacuation, actually in some states the governor doesn't even have the authority to do that so there's some question about who would be able to do evacuate. The problem though that I think that we found was if there is an area that you want people to stay away from, to avoid, that we needed to include that in the message. Again, this is not free form text. This is computer generated so that a message may say radiological hazard warning in your area. Avoid. Or a nuclear power plant warning in your area. Avoid. We had had some discussion earlier about whether or not the text string should say avoid area, avoid incidence or avoid hazard. Personally I like avoid hazard, but I was trying to keep the number of characters down to a minimum, and I was concerned about adding area in since in these computer generated text messages we already say in this area, and I did not want to say then avoid area. So the purpose of the amendment is to highlight the need to add an additional value, particularly in light of the all hazard warnings that I anticipate coming, the word avoid, and to include that in the computer generated text string. MR. MORAN: Thank you. Do we have a second on that? MALE VOICE: Second. MR. MORAN: Second? Okay. Any discussion on Mr. Pitts' proposed amendment? Yes, Dave? MR. WEBB: Yes, sir, Mr. Chairman. I do believe, and I will have to defer to Mr. Botterell on this for the exact thing, but these values are all fields that are established within the CAP standard. FEMALE VOICE: Yes. MR. WEBB: And by doing this amendment we would in effect be modifying an OASIS standard that is published for the whole world to use, and I'm not sure that this -- while I agree that avoid is a useful thing to have, I'm not sure we can modify an international standard in this body. MR. PITTS: Mr. Chairman, Billy Pitts. If I might address that? I'd like to hear from Art. I understand, and this is no way trying to change the OASIS standard. This is an effort by us as the committee advising the FCC that something needs to be done here, that we need to be a little more explicit in our responses, and my hope would be that both the OASIS CAP Standards Setting Group would look at this as well as the FCC, but I think as a recommendation we would be deficient in not pointing out the need here. MR. MORAN: Thank you. Any other comments? Discussion? MR. PREST: Yes. This is Art Prest. I totally agree with what Billy just said. MR. MORAN: Okay. Any other discussion on the bridge? MR. RUTKOWSKI: Mr. Chairman, Tony Rutkowski. MR. MORAN: Yes? MR. RUTKOWSKI: I was actually the acting rapporteur for what is actually the international standard, which is the IQT version of CAP, and I tend to agree with the amendment, but I would have one admonition that's generally applicable to all of these is that in the continuing international process for exchanging information on these fields in going forward that this information be shared with other administrations. There's a standard mechanism for doing that. MR. MORAN: Okay. Thank you. Any other discussion? MR. BOTTERELL: Mr. Chairman? MR. MORAN: Yes? MR. BOTTERELL: Art Botterell. In Section 5.3.2 of the draft recommendation there is a provision for the alert gateway adding event codes over and above those specified either in the CAP or in the older same event-coding scheme. I think it was on this principle that the attempt was being made to go ahead and add what I think everyone agrees is a needed field. The small difficulty that arises is that here we are actually proposing an addition to the response type enumeration rather than the event code, and we have not really addressed that prior. I'd like to offer what I hope will be accepted as a friendly amendment in two parts. The first would be that the text string associated with this new response type value of avoid would be avoid hazard, and this is really just for clarity when you construct the whole string. We don't want to say avoid area because then everybody who gets the message in this area thinks it applies to them. That's the best wording we could come up with. The second bit is that we add -- I guess there's actually three bits. The second bit would be that we add a footnote acknowledging that this particular value is not currently supported in the CAP specification, but that it will be added for CMAS purposes until such time as OASIS can rule on that as a change since we don't really have a mechanism in the response field. And then the third thing would just be to note, and this is more of a process note. I think since we already have just adopted an updated tabulation provided by Brian that this would really just be a one line change in the table as most recently amended, the table for response type, not an amendment of that entire table, so that's a little complicated, but we can parse it. MR. MORAN: Yes, Mr. Jones? MR. JONES: Thank you. Gary Jones. I'd like to support the change that Art is proposing in the text string in changing it from avoid to avoid hazard. The committee laid out a structure for the canned message and the order of the elements of the message. Having the words avoid hazard seems to fit better in the ordering of the message so that it would have the event, the recommended action -- excuse me. The event and then the words in this area and then the recommended action. For instance, it might say a HAZMAT warning in this area. Avoid hazard. The English seems to flow a little bit better. Thank you. MR. BOTTERELL: If I may add just one final aside for the benefit of Mr. Rutkowski? Tony, I think we'll have to discuss off-line whether this would be something that OASIS should take first and then take to ITU or exactly how that harmonization would occur. MR. RUTKOWSKI: I agree, but I think the point is too this is for global interoperability purposes. We need to exchange these field values to allow global interoperability. MR. BOTTERELL: Exactly. So I guess I would ask Mr. Pitts if he would accept that as a friendly amendment. MR. PITTS: Yes, sir. I think they're very constructive and worthwhile, and I would accept it. FEMALE VOICE: Thank you. MR. MORAN: Mr. Botterell, your first of your three suggestions is very clear. The second one I'm not sure I caught it all and exactly what you do. MR. BOTTERELL: Yes. Let me see if I can dictate it. This would be a footnote or an asterisk or a note of some sort, whatever editorially works, that would say: This value is recommended for CMAS use only pending action by the responsible standards body. MR. WILLIAMS: Modification of CAP? MR. BOTTERELL: Yes. Yes. The pending modification of CAP. I don't want to posit that they're going to do it, even though I'm fairly confident they will. MR. MORAN: Let me make sure I got your whole sentence there. MR. BOTTERELL: Yes. MR. MORAN: This value is recommended for CMAS use only pending action -- MR. WILLIAMS: Modification of the CAP value. MR. BOTTERELL: Pending inclusion into the CAP standard. How is that? MR. MORAN: Pending inclusion into the CAP standard? MR. BOTTERELL: Yes. Period. MR. MORAN: Okay. And your third suggestion? MR. BOTTERELL: Was really just that the scope of this is really just adding one line to one section in the table. It's not a replacement of the entire table because we just amended the order of the table before and I don't want to blow that up, so that's more an editorial note than an amendment really. MR. MORAN: Okay. Do we have a second on Mr. Botterell's proposed -- MALE VOICE: Second. MR. BOTTERELL: I think it's been accepted as a friendly amendment, so do we have to -- MR. MORAN: Okay. So it's been accepted. Okay. Any more discussion on this proposed amendment? MR. WEBB: Mr. Chairman, I would like to say while we have just added this and it's a good thing, I don't think the alert originator software industry will build to this immediately until -- I mean, this is something that would be likely included in the gateway function, but as far as an industry building to a standard it's not yet a standard, so it may not come out in originator software and be available for their use. MR. MORAN: Okay. MR. BOTTERELL: I think that's right. The good news is that it's entirely possible that OASIS could deal with this in the time it's going to take the FCC to deal with its part of the rulemaking, but that's not a certainty by any means. MR. MORAN: Okay. Any further discussion here in the room on this issue? (No response.) MR. MORAN: Any further discussion on the bridge? (No response.) MR. MORAN: Okay. Let's vote on this. So we're voting on the amendment with the friendly amendment change to the amendment, so it's the amendment as presented by Mr. Pitts. On the second page under What Action Should Be Taken under Text Stream next to avoid it will say “avoid hazard” on the text stream, and we would put a footnote somewhere that says: This value is recommended for CMAS use only pending inclusion into the CAP standard. Okay. Let's have a vote here in the room. All who favor this amendment raise your hand. (Whereupon, a showing of hands.) MR. MORAN: We have that. Thank you. All who are opposed, raise your hand. (No response.) MR. MORAN: Any abstentions? (Whereupon, a showing of hands.) MR. MORAN: Okay. Sue, what is the count for the bridge? MS. GILGENBACH: Thirty yes, zero no, one abstain. MR. MORAN: Thank you. Okay. We'll go to the bridge here. Mr. Ban? MR. BAN: Yes. MR. MORAN: Ms. Brooks? MS. BROOKS: Yes. MR. MORAN: Ms. Dunn-Tutor? MS. DUNN-TUTOR: Yes. MR. MORAN: Mr. Lyon? MR. LYON: Yes. MR. MORAN: Mr. McGinnis? MR. McGINNIS: Yes. MR. MORAN: Mr. Prest? MR. PREST: Yes. MR. MORAN: Mr. Roberts? MR. ROBERTS: Yes. MR. MORAN: Mr. Rutkowski? MR. RUTKOWSKI: Yes. MR. MORAN: Mr. Wilcock? MR. WILCOCK: Yes. MR. MORAN: Mr. Gehman? MR. GEHMAN: Yes. MR. MORAN: Okay. That amendment passes.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]