[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fwd: Re: [emergency-comment] Add "Avoid" to code values for theelement "ResponseType"
Hi again Everyone, I am forwarding this in case the message did not get through to the TC list. Cheers, Rex >Cc: emergency@lists.oasis-open.org >From: Billy Pitts <bpitts5@mac.com> >Subject: Re: [emergency-comment] Add "Avoid" to code values for the element > "ResponseType" >Date: Tue, 25 Nov 2008 10:09:53 -0500 >To: Rex Brooks <rexb@starbourne.com> >X-Nonspam: Statistical 58% > >An important aspect of the "Avoid" recommendation did not convey in >my earlier communication, >and that was that the 3.2.2 "info" Element and Sub-elements chart >would read as follows, >(in the same fashion as the other 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 > >On Nov 25, 2008, at 9:39 AM, Rex Brooks wrote: > >>Hi Folks, >> >>I thought I should forward this to the TC list because it is >>germane to one agenda item in today's TC meeting. The EM-Msg SC >>will be making its recommendation with regard to the next work to >>be done on CAP. >> >>Cheers, >>Rex >> >>>Mailing-List: contact >>><mailto:emergency-comment-help@lists.oasis-open.org>emergency-comment-help@lists.oasis-open.org; >>>run by ezmlm >>>List-Post: >>><<mailto:emergency-comment@lists.oasis-open.org>mailto:emergency-comment@lists.oasis-open.org> >>>List-Help: >>><<mailto:emergency-comment-help@lists.oasis-open.org>mailto:emergency-comment-help@lists.oasis-open.org> >>>List-Unsubscribe: >>><<mailto:emergency-comment-unsubscribe@lists.oasis-open.org>mailto:emergency-comment-unsubscribe@lists.oasis-open.org> >>>List-Subscribe: >>><<mailto:emergency-comment-subscribe@lists.oasis-open.org>mailto:emergency-comment-subscribe@lists.oasis-open.org> >>>Delivered-To: mailing list >>><mailto:emergency-comment@lists.oasis-open.org>emergency-comment@lists.oasis-open.org >>>To: >>><mailto:emergency-comment@lists.oasis-open.org>emergency-comment@lists.oasis-open.org >>>From: Billy Pitts <<mailto:bpitts5@mac.com>bpitts5@mac.com> >>>Date: Tue, 25 Nov 2008 01:26:57 -0500 >>>Subject: [emergency-comment] Add "Avoid" to code values for the >>>element "ResponseType" >>>X-Nonspam: Statistical 62% >>> >>>OASIS Emergency Management Technical Committee (EM TC) >>> >>>November 25, 2008 >>> >>>Dear Committee Members: >>> >>>This letter is to assure that the appropriate entity of OASIS >>>overseeing the development of the Common Alerting Protocol >>>standard is aware 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.) >>>We urge quick action to include this addition to the CAP standard >>>and register it as part of the standard going forward. >>>I was privileged to have served 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. Our 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 is to use CAP as the basic alerting protocol >>>which would then be sent to an alert gateway/aggregator who 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 our 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 will then create and issue a text based >>>CMA to warn the CMSP subscribers within the indicated alerting >>>area." >>>In section 5.3.2 we laid out the procedure for generating a CMAM >>>from CAP fields: >>>"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." >>>We recommended that the alert's recommended action to be taken or >>>the response description 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 flexibilitySto tailor the CMAM content to a specific alert >>>event," and that the CMAM "may not be very meaningful to the end >>>user." >>>We noted at the time of the recommendation that 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. >>>We were concerned about not addressing adequately in the current >>>CAP standard enough recommended actions that might be proposed to >>>respond 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 a change to add >>>"Avoid" to the current code values for the element "ResponseType" >>>of the CAP 1.1 standard. This proposed change was supported >>>without opposition, by the Commercial Mobile Alert Advisory >>>Committee, including several participants who have played an >>>integral part in the development of CAP. The Advisory Committee >>>with this new code value recognized, at the time of its adoption, >>>that neither we, nor the FCC had the authority to change the CAP >>>standard. >>>We, therefore, are urging that, as soon as possible, the >>>appropriate standards entity adopt this proposal as part of the >>>CAP standard. >>> >>>Sincerely, >>> >>>Billy Pitts >>> >>>Senior Vice President, Government Affairs >>> >>>Blackboard Inc. >>> >>>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 eluded 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. >>> >> >> >>-- >>Rex Brooks >>President, CEO >>Starbourne Communications Design >>GeoAddress: 1361-A Addison >>Berkeley, CA 94702 >>Tel: 510-898-0670 -- Rex Brooks President, CEO Starbourne Communications Design GeoAddress: 1361-A Addison Berkeley, CA 94702 Tel: 510-898-0670
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]