Fwd: Re: [emergency-comment] Add "Avoid" to code values for theelement "ResponseType"

[Rex Brooks <rexb@starbourne.com>]

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