Re: [earlywarning] New Charter Text Proposal

[ken carlberg <[e-mail]>]

works for me as well.

-ken


On May 10, 2010, at 8:49 PM, Richard Barnes wrote:

> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/earlywarning
>> 
>> _______________________________________________
>> earlywarning mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/earlywarning
> 
> _______________________________________________
> earlywarning mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/earlywarning