Subject: Re: [earlywarning] Updated Charter Text for ATOCA

From: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
Date: Thu, 25 Mar 2010 17:46:11 -0700

The distribution architecture is being developed in the US under the FEMA iPAWS program and DMOpen. This applies to ALL alerting sources and distribution streams, including CMAS, EAS, radio/TV, NOAA, IP etc.

That end is already being handled.

Brian
Brian K. Daly
-------
Sent from my Blackberry

----- Original Message -----
From: [email-masked] <[email-masked]>
To: Richard Barnes <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>; [email-masked] <[email-masked]>
Sent: Thu Mar 25 17:40:59 2010
Subject: Re: [earlywarning] Updated Charter Text for ATOCA

No I have not said that.

I am saying that it is not the solution for cellphone users using 3GPP technology.

Keith 

> -----Original Message-----
> From: Richard Barnes [mailto:[email-masked]] 
> Sent: Thursday, March 25, 2010 2:16 AM
> To: DRAGE, Keith (Keith)
> Cc: Hannes Tschofenig; [email-masked]
> Subject: Re: [earlywarning] Updated Charter Text for ATOCA
> 
> So Keith, do you think that emergency notifications should 
> not be available on any other network?
> 
> Even if you use cell broadcast, there's a need for a 
> distribution architecture, as the US CMAS demonstrates.
> 
> --Richard
> 
> 
> 
> On Mar 24, 2010, at 7:13 PM, DRAGE, Keith (Keith) wrote:
> 
> > What I am not seeing here is any separation of the problem from the 
> > one that cell broadcast attempts to solve. Fundamentally, cell 
> > broadcast, as exists on all GSM, UTRAN and E-UTRAN based 
> cell phones 
> > and is being used for Tsunami warning and Public Warning, 
> exists and 
> > is not going to substantially change. The major limitation 
> here is is 
> > length of message, and what does get transmitted will be very much 
> > dependent on that restriction.
> >
> > Moreover I have heard from a number of governmental bodies 
> that they 
> > are happy with that situation and are not envisaging further 
> > standardisation in that area outside of 3GPP.
> >
> > So my view at the moment is that there is no point in IETF 
> trying to 
> > address the scope of what is already specified in cell 
> broadcast (from 
> > base station to end mobile).
> >
> > regards
> >
> > Keith
> >
> >
> >
> >> -----Original Message-----
> >> From: [email-masked]
> >> [mailto:[email-masked]] On Behalf Of Hannes 
> Tschofenig
> >> Sent: Wednesday, March 24, 2010 9:37 PM
> >> To: [email-masked]
> >> Subject: [earlywarning] Updated Charter Text for ATOCA
> >>
> >> .... a minor update
> >>
> >> Authority to Citizen Alert (ATOCA)
> >> ==================================
> >>
> >> Authorities need mechanisms to notify citizens and visitors of 
> >> emergency
> >> events.   Traditionally, they have done so with broadcast
> >> networks (radio
> >> and television).  The Internet provides another way for 
> authority to 
> >> citizen alerts to be sent, but it also presents new 
> challenges. While 
> >> there are some existing layer 2 mechanisms for delivering 
> alerts the 
> >> work in this group focuses on delivering alerts to IP 
> endpoints only.
> >>
> >> The general message pattern that this group is intended to 
> address is 
> >> the sending of alerts from a set of pre-authorized agents (e.g., 
> >> governmental
> >> agencies) to a large population. The goal of this group is not to 
> >> specify how originators of alerts obtain authorization, but rather 
> >> how a messaging system can verify authorization and 
> deliver message 
> >> to the intended recipients.
> >> A critical element of the work arethe mechanisms that assure that 
> >> only authorized agents can send alerts.
> >>
> >> The recipients of these alerts are the wide range of devices 
> >> connected to the Internet and 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.
> >> Ideally, the alerts would contain, or refer to media other 
> than text 
> >> media (e.g., audio and/or video), but the initial work in 
> the group 
> >> is focused on small messages, which may be mechanically 
> rendered by 
> >> thedevice in other forms (text to speech for example).  In 
> situations 
> >> of a major emergency there could be scenarios where there are 
> >> multiple alerts generated that may require that a priority 
> mechanism 
> >> has to be implemented, and this mechanism is out of scope at his 
> >> time.
> >>
> >> 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 affected by the alert.  In many jurisdictions, there are 
> >> regulations that define whether recipients within the 
> affected area 
> >> have opt-in or opt-out capability, but the protocols we 
> will define 
> >> will include both opt-in and opt-out mechanisms. The group will 
> >> explore how to support both opt-in and opt-out at the level of 
> >> communication protocols.
> >>
> >> Another class of recipients that are in scope of the work are 
> >> explicit opt-in subscriptions which ask for alerts for a specified 
> >> location.
> >> An example of such a subscription would be 'send me alerts for 
> >> location x' (previously determined as the location of interest).
> >> This work builds on existing IETF geopriv location work.
> >>
> >> There are other efforts in other fora on alerts, which will be 
> >> considered in this effort.  For example, we expect to make 
> use of the 
> >> OASIS Common Alerting Protocol (CAP) for the encoding of alerts.  
> >> ATIS, TIA, ITU-T, ETSI and 3GPP also have alert efforts 
> underway, and 
> >> consultation with these efforts will be undertaken to avoid 
> >> unnecessary duplication of effort.
> >> Of course, existing protocols for delivering messages (e.g.,
> >> SIP) will be the basis for the message delivery system of this 
> >> working group.
> >>
> >> The security implications of mechanisms that can send alerts to 
> >> billions of devices are profound, but the utility of the mechanism 
> >> encourages us to face the problems and solve them.
> >>
> >> Milestones
> >>
> >> TBD      Initial document for "Terminology and Framework" document.
> >>         A starting point for this work is
> >>         draft-norreys-ecrit-authority2individuals-requirements.
> >> TBD      Initial document for conveying alerts in SIP
> >> TBD      Initial document for subscribing to alerts using SIP
> >>         A starting point for this work is draft-rosen-sipping-cap
> >> TBD      Initial document for locating the alerting server
> >> for a geographic
> >>         region. A starting point for this work is
> >>         draft-rosen-ecrit-lost-early-warning.
> >>
> >> _______________________________________________
> >> earlywarning mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/earlywarning
> >>
> > _______________________________________________
> > earlywarning mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/earlywarning
> 
> 
_______________________________________________
earlywarning mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/earlywarning

---

From: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
Date: Fri, 26 Mar 2010 13:29:31 -0700

Pressin a key could be the worst thing you can do. Depending on the network the device is attached to, having the ability to press a key encourages use of the already taxed network, increasing congestion further.
Brian K. Daly
-------
Sent from my Blackberry

----- Original Message -----
From: [email-masked] <[email-masked]>
To: Spencer Dawkins <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>; [email-masked] <[email-masked]>
Sent: Fri Mar 26 13:23:27 2010
Subject: Re: [earlywarning] Updated Charter Text for ATOCA

Yes that is true.
What about if you wanted more information and then press a key for that 
info?
The RTT would work as the IVR system but then only text.
But I can imagine this is out of scope.

On 25-3-2010 7:52, Spencer Dawkins wrote:
>>> Also if interactivity is required or offered as an extra service, 
>>> RTT can be useful.
>>>
>> I have so far never heard that interactivity would be desired.
>
> FWIW, my understanding is that this is not even possible (you just 
> told the entire city of Yokohama that a tsunami is two hours out - 
> who's supposed to handle the questions from the entire city of Yokohama?)
>
> Spencer
>