Re: [Atoca] I-D Action:draft-ietf-atoca-requirements-01.txt

"James M. Polk" <> Tue, 18 January 2011 22:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5095328C15B for <>; Tue, 18 Jan 2011 14:52:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.517
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qH4HSXSu-by0 for <>; Tue, 18 Jan 2011 14:52:45 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id ABB3428C163 for <>; Tue, 18 Jan 2011 14:52:44 -0800 (PST)
Authentication-Results:; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEABKpNU2rR7Ht/2dsb2JhbACkQnOoJ5o3hVAEhG8
Received: from ([]) by with ESMTP; 18 Jan 2011 22:55:23 +0000
Received: from ( []) by (8.13.8/8.14.3) with ESMTP id p0IMtMO5006819; Tue, 18 Jan 2011 22:55:22 GMT
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Tue, 18 Jan 2011 16:55:21 -0600
To: Hannes Tschofenig <>, "DRAGE, Keith (Keith)" <>
From: "James M. Polk" <>
In-Reply-To: <>
References: <20110115190001.18610.17937.idtracker@localhost> <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: "" <>
Subject: Re: [Atoca] I-D Action:draft-ietf-atoca-requirements-01.txt
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


>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...
>                OR ABOUT 18 MILES SOUTHEAST OF
>                ARE LIKELY WITH THIS STORM </description>
>            <instruction> TAKE COVER IN A SUBSTANTIAL SHELTER
>                UNTIL THE STORM PASSES </instruction>
>            <contact>BARUFFALDI/JUSKIE</contact>
>            <area>
>                    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.
>>>-----Original Message-----
>>>[] On Behalf Of
>>>Sent: Saturday, January 15, 2011 7:00 PM
>>>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:
>>>Internet-Drafts are also available by anonymous FTP at:
>>>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 mailing list