Re: [earlywarning] Final Charter Text. Thanks!

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

Firstly a question:

What does "initial" mean in the milestones?

Secondly can you put some dates in the milestones, even if they are things like "Charter date plus 9 months". I at least need to understand the proposed document sequence.

I assume the approved milestones will not contain text such as:

"A starting point for this work is draft-rosen-ecrit-lost-early-warning."

so can you move this text to some sort of editorial gloss at the end - which will not appear in the final charter. 

regards

Keith

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Hannes Tschofenig
> Sent: Monday, May 31, 2010 10:13 PM
> To: [e-mail]
> Subject: [earlywarning] Final Charter Text. Thanks!
> 
> Thank you all for participating in this charter discussion. I 
> plan to submit the following charter text to the RAI ADs 
> within the next 24 hours. I included a few minor wording 
> changes based on the very recent feedback on the list. 
> 
> Brian D., James P. + Martin T.: Please browse through the 
> text to see whether you are happy with it.
> 
> Ciao
> Hannes
> 
> ----------------------------------------------
> 
> 
> Authority to Citizen Alert (ATOCA)
> ==================================
> 
> There are a variety of mechanisms that authorities have 
> available to notify citizens and visitors during emergency 
> events. Traditionally, theyhave 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 various stages of deployment.  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 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 authorization and deliver messages to the intended 
> recipients. A critical element of the work are the mechanisms 
> that assure that onlythose 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.).
> 
> 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.  
> 
> Ideally, the alerts would contain, or refer to media other 
> than text media (e.g., audio and/or video). 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). Future work in the group may investigate 
> rich media.
> 
> 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 emergency event.  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 ATOCA 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 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. To avoid manual configuration of 
> servers distributing alerts a discovery mechanism will be specified.
> 
> 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
>