Re: [earlywarning] Finishing the Charter Text Discussions

["DRAGE, Keith (Keith)" <[e-mail]>]

A couple of minor comments in this message:

> for location x' (previously determined as the location of interest). 
> This work builds on existing IETF geopriv location work. 

This sentence left me wondering, as the key aspect of the GEOPRIV work, rather than location, was privacy. There is therefore no point in my view in mentioning geopriv unless there is some explained privacy aspect. At the moment I do not see that explained.	
 
> encoding of alerts.  OGC, 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. 

There have been two agreed sets of 3GPP work, both of which ARE COMPLETE. These are ETWS which completed with the freeze of release 8 and PWS which completed with the freeze of release 9. When Europe makes a final decision as to what they require from 3GPP networks, then there may well be some more work initiated, but there is no active work at the moment that can be contributed to. So it is incorrect to say "... 3GPP also have alert efforts underway...". I suspect the same applies to ATIS and TIA, at least where that work corresponds to the cell broadcast mechanisms. This of course does not preclude liaison, but do not assume that 3GPP can change a frozen specification because of that liaison.

regards

Keith


> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Hannes Tschofenig
> Sent: Tuesday, April 06, 2010 12:18 PM
> To: [e-mail]
> Subject: [earlywarning] Finishing the Charter Text Discussions
> 
> Hi all, 
> 
> we had some discussions in response to the charter text I 
> distributed. I made some minor changes based on the received 
> comments but most of the discussions seemed (at least to me) 
> not related to the charter text itself. 
> 
> Is the charter text OK for everyone? 
> 
> Ciao
> Hannes
> 
> ----------------
> 
> 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 are the 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 the device 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 used. 
> The work on a resource priority mechanism is out of scope of 
> the initial charter, but may be revisited at a later date.
> 
> 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 efforts in other fora on early warning, 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.  OGC, 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/earlywarning
>