[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fwd: [emergency-comment] Add "Avoid" to code values for theelement "ResponseType"
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 >emergency-comment-help@lists.oasis-open.org; run >by ezmlm >List-Post: <mailto:emergency-comment@lists.oasis-open.org> >List-Help: <mailto:emergency-comment-help@lists.oasis-open.org> >List-Unsubscribe: <mailto:emergency-comment-unsubscribe@lists.oasis-open.org> >List-Subscribe: <mailto:emergency-comment-subscribe@lists.oasis-open.org> >Delivered-To: mailing list emergency-comment@lists.oasis-open.org >To: emergency-comment@lists.oasis-open.org >From: Billy Pitts <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 flexibilityŠto 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]