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

[Hannes Tschofenig <[e-mail]>]

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.

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>[e-mail]</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: [e-mail]
>> [mailto:[e-mail]] On Behalf Of
>> [e-mail]
>> Sent: Saturday, January 15, 2011 7:00 PM
>> To: [e-mail]
>> Cc: [e-mail]
>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/earlywarning
>