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