Re: [Atoca] I-D Action:draft-ietf-atoca-requirements-01.txt
"James M. Polk" <jmpolk@cisco.com> Tue, 18 January 2011 22:52 UTC
Return-Path: <jmpolk@cisco.com>
X-Original-To: earlywarning@core3.amsl.com
Delivered-To: earlywarning@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5095328C15B for <earlywarning@core3.amsl.com>; Tue, 18 Jan 2011 14:52:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.517
X-Spam-Level:
X-Spam-Status: No, score=-110.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qH4HSXSu-by0 for <earlywarning@core3.amsl.com>; Tue, 18 Jan 2011 14:52:45 -0800 (PST)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id ABB3428C163 for <earlywarning@ietf.org>; Tue, 18 Jan 2011 14:52:44 -0800 (PST)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEABKpNU2rR7Ht/2dsb2JhbACkQnOoJ5o3hVAEhG8
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 18 Jan 2011 22:55:23 +0000
Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8716.cisco.com [10.99.80.23]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0IMtMO5006819; Tue, 18 Jan 2011 22:55:22 GMT
Message-Id: <201101182255.p0IMtMO5006819@sj-core-1.cisco.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 18 Jan 2011 16:55:21 -0600
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>, "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
From: "James M. Polk" <jmpolk@cisco.com>
In-Reply-To: <4D35D26E.5070809@gmx.net>
References: <20110115190001.18610.17937.idtracker@localhost> <EDC0A1AE77C57744B664A310A0B23AE21E643095@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <4D35D26E.5070809@gmx.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: "earlywarning@ietf.org" <earlywarning@ietf.org>
Subject: Re: [Atoca] I-D Action:draft-ietf-atoca-requirements-01.txt
X-BeenThere: earlywarning@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." <earlywarning.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/earlywarning>, <mailto:earlywarning-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/earlywarning>
List-Post: <mailto:earlywarning@ietf.org>
List-Help: <mailto:earlywarning-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/earlywarning>, <mailto:earlywarning-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Jan 2011 22:52:48 -0000
At 11:48 AM 1/18/2011, Hannes Tschofenig wrote: >Hey Keith, > >thanks for your comments! Please find my comments below: > >On 1/17/2011 7:50 PM, DRAGE, Keith (Keith) wrote: >>I was scanning the charter to see if we had requirements for all >>items mentioned in the charter. >> >>For the following text: >> >>"Which devices should get alerts is primarily driven by location. >>The first set of recipients that must be catered for are those >>within the area identified by the alert originator to be affected >>by the emergency event. " >> >>I could see the requiremnet for recipient control of this: >> >> Req-S2: >> >> The protocol solution MUST allow a potential Recipient to express >> the geographical area it wants to receive alerts about. >> >>But I could see no corresponding require for the sender to be able >>to indicate which geographic locations it wants its alerts to go to. > >Good catch. > >A question I have in return is whether this isn't implicitly covered >by the fact that the alert message itself may contain location >information about the relevant area. I agree with Hannes here, as this may be a case of slight oversight of those of us a little too familiar with what CAP provides to not articular each requirement that we may have seen as implicit within CAP itself. James >For example, take a look at the following alert message: > >--------------------- > > > <?xml version="1.0" encoding="UTF-8"?> > > <alert xmlns="urn:oasis:names:tc:emergency:cap:1.1"> > <identifier>KSTO1055887203</identifier> > <sender>KSTO@NWS.NOAA.GOV</sender> > <sent>2003-06-17T14:57:00-07:00</sent> > <status>Actual</status> > <msgType>Alert</msgType> > <scope>Public</scope> > <info> > <category>Met</category> > <event>SEVERE THUNDERSTORM</event> > <urgency>Severe</urgency> > <certainty>Likely</certainty> > <senderName>NATIONAL WEATHER SERVICE SACRAMENTO</senderName> > <headline>SEVERE THUNDERSTORM WARNING</headline> > <description> AT 254 PM PDT... > NATIONAL WEATHER SERVICE > DOPPLER RADAR INDICATED A SEVERE > THUNDERSTORM OVER SOUTH CENTRAL ALPINE COUNTY... > OR ABOUT 18 MILES SOUTHEAST OF > KIRKWOOD... MOVING SOUTHWEST AT 5 MPH. HAIL... > INTENSE RAIN AND STRONG DAMAGING WINDS > ARE LIKELY WITH THIS STORM </description> > <instruction> TAKE COVER IN A SUBSTANTIAL SHELTER > UNTIL THE STORM PASSES </instruction> > <contact>BARUFFALDI/JUSKIE</contact> > <area> > <areaDesc> EXTREME NORTH CENTRAL TUOLUMNE COUNTY > IN CALIFORNIA, EXTREME NORTHEASTERN > CALAVERAS COUNTY IN CALIFORNIA, SOUTHWESTERN > ALPINE COUNTY IN CALIFORNIA </areaDesc> > <polygon> 38.47,-120.14 38.34,-119.95 38.52,-119.74 > 38.62,-119.89 38.47,-120.14 </polygon> > </area> > </info> > </alert> > >----------- > >So, are you asking to have it stated explicitly that this >information has to be there or do you want to have the area >description additionally available in SIP itself. > >Both requests would be useful. The latter one is also relevant given >the discussions we had in ECRIT on the data-only emergency calls. > >> >>I also looked at the following charter text: >> >>"The ATOCA effort is differentiated from and is not intended to >>replace other alerting mechanisms (e.g., PWS, CMAS, ETWS), as the >>recipients of ATOCA alerts are the wide range of devices connected to >>the Internet and various private IP networks, which humans may have >>"at hand" to get such events, as well as automatons who may take >>action based on the alerts. This implies that the content of the >>alert contains some information, which is intended to be consumed >>by humans, and some which is intended to be consumed by automatons. >>" >> >>I could see nothing in the i-d that even mentioned this, let alone >>discussed it. > >I think that is an important point we need to capture. We added text >to the architectural description but we have not captured this in >the requirements section and I believe it makes a bit difference >from an interoperability and security point of view whether there is >a human there that has to interpret the message or not. > >What about the following text in the requirements document: > >" > Req-D6: > > The protocol solution MUST consider cases where alerts are > processed by Recipients (who are human) as well as cases where > there is no human present (i.e. the Recipient role coincides with > the Receiver role). An implication of the latter case is that the > Receiver, a software component, needs to make a decision about the > validity of the message (for example about the alert message > Author). Cases where no human is present can, for example, be found > with remote controlled vents, sirens or other warning systems in > commercial buildings. >" > > > > Rather the text: >> >> "This problem has been illustrated by the London underground bombing >> on July 7, 2006, as described in a government report [July2005]. The >> UK authorities could only use broadcast media and could not, for >> example, easily announce to the "walking wounded" where to assemble." >> >>Could be be taken to imply that they intend to do exactly that, as >>I understand the UK initiative as a result of that was directed to >>mobile phone solutions, as identified above. >Maybe Mark or Steve could comment on what the UK is currently >planning to do in this area. > >Ciao >Hannes > >> >>regards >> >> >>Keith >> >>>-----Original Message----- >>>From: earlywarning-bounces@ietf.org >>>[mailto:earlywarning-bounces@ietf.org] On Behalf Of >>>Internet-Drafts@ietf.org >>>Sent: Saturday, January 15, 2011 7:00 PM >>>To: i-d-announce@ietf.org >>>Cc: earlywarning@ietf.org >>>Subject: [Atoca] I-D Action:draft-ietf-atoca-requirements-01.txt >>> >>>A New Internet-Draft is available from the on-line >>>Internet-Drafts directories. >>>This draft is a work item of the Authority-to-Citizen Alert >>>Working Group of the IETF. >>> >>> >>> Title : Requirements, Terminology and >>>Framework for Exigent Communications >>> Author(s) : H. Schulzrinne, et al. >>> Filename : draft-ietf-atoca-requirements-01.txt >>> Pages : 14 >>> Date : 2011-01-15 >>> >>>Before, during and after emergency situations various >>>agencies need to provide information to a group of persons or >>>to the public within a geographical area. While many aspects >>>of such systems are specific to national or local >>>jurisdictions, emergencies span such boundaries and >>>notifications need to reach visitors from other jurisdictions. >>> >>>This document provides terminology, requirements and an >>>architectural description for protocols exchanging alerts >>>between IP-based end points. >>> >>>A URL for this Internet-Draft is: >>>http://www.ietf.org/internet-drafts/draft-ietf-atoca-requireme >>>nts-01.txt >>> >>>Internet-Drafts are also available by anonymous FTP at: >>>ftp://ftp.ietf.org/internet-drafts/ >>> >>>Below is the data which will enable a MIME compliant mail >>>reader implementation to automatically retrieve the ASCII >>>version of the Internet-Draft. >>_______________________________________________ >>earlywarning mailing list >>earlywarning@ietf.org >>https://www.ietf.org/mailman/listinfo/earlywarning > >_______________________________________________ >earlywarning mailing list >earlywarning@ietf.org >https://www.ietf.org/mailman/listinfo/earlywarning
- [Atoca] I-D Action:draft-ietf-atoca-requirements-… Internet-Drafts
- Re: [Atoca] I-D Action:draft-ietf-atoca-requireme… DRAGE, Keith (Keith)
- Re: [Atoca] I-D Action:draft-ietf-atoca-requireme… Hannes Tschofenig
- Re: [Atoca] I-D Action:draft-ietf-atoca-requireme… James M. Polk