Re: [earlywarning] New Charter Text Proposal

I think this version of the charter is fine.
--Richard

On May 10, 2010, at 3:40 PM, Hannes Tschofenig wrote:

> Please provide your feedback at latest by 28th May 2010.
> Thanks.
>
> Ciao
> Hannes
>
> Hannes Tschofenig wrote:
>> Hi all,
>> as you all have seen it is a bit difficult to come up with a text  
>> that makes everyone happy. Please find an updated proposal below  
>> based on the recent discussions on the list.
>> Ciao
>> Hannes
>>
>>
>> Authority to Citizen Alert (ATOCA)
>> ==================================
>>
>> There are a variety of mechanisms that authorities have available to
>> notify citizens and visitors of emergency events. Traditionally, they
>> have done so with broadcast networks (radio and television). For  
>> commercial mobile devices, broadcasting services such as the Public  
>> Warning System (PWS), the Earthquake and Tsunami Warning System  
>> (ETWS), and the Commercial Mobile Alert System (CMAS) are  
>> standardized and are in the process of being deployed.  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 without impacting the  
>> layer
>> 2 networks (e.g. causing congestion or denial of service). The goal  
>> of
>> this group is not to specify how originators of alerts obtain
>> authorization, but rather how an ATOCA system can verify that
>> authorization and deliver messages to the intended recipients. A
>> critical element of the work are the mechanisms that assure that only
>> those pre-authorized agents can send alerts via ATOCA, through an
>> interface to authorized alert distribution networks (e.g., iPAWS/DM- 
>> Open
>> in the U.S.).
>>
>> This work is differentiated from and is not intended to replace other
>> alerting mechanisms (e.g., PWS, CMAS, ETWS), as the recipients of  
>> these
>> ATOCA 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 (defined by alert originator policy) 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 identified by the alert originator to be affected by the  
>> alert.  In
>> many jurisdictions, there are regulations that define whether
>> recipients/devices 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 and/or  
>> device
>> behavior.
>> Another class of recipients that are in scope of the work are  
>> explicit
>> opt-in subscriptions which ask for alerts for a specified location,  
>> not
>> necessarily the physical location of the device itself. An example of
>> such a subscription would be 'send me alerts for location  
>> x' (previously
>> determined as the location of interest). This work may build 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 and also to avoid unintentional negative  
>> impacts
>> on the layer 2 networks. 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. In addition, the potential
>> performance and congestion impacts to networks resulting from sending
>> alert information to billions of devices must be considered and  
>> solved
>> if such a service is implementable.
>>
>> 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.         A  
>> starting point for this work is draft-rosen-sipping-cap
>> TBD      Initial document for conveying alerts through point to
>> multipoint methods.
>> 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.
>> TBD      Initial document addressing security, performance and  
>> congestion issues for alert distribution.
>> TBD      Initial document for interfacing existing alert
>> distribution systems.
>>
>>
>> _______________________________________________
>> 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