From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>,
 "earlywarning@ietf.org" <earlywarning@ietf.org>
Date: Tue, 1 Jun 2010 17:38:24 +0200
Thread-Topic: [earlywarning] Final Charter Text. Thanks!
Thread-Index: AcsBBiHYNfwSxI7CSkG0hpMx3XNR1wAmZwWA
Message-ID: <EDC0A1AE77C57744B664A310A0B23AE213C6C964@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
References: <20100531211316.310600@gmx.net>
In-Reply-To: <20100531211316.310600@gmx.net>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [earlywarning] Final Charter Text. Thanks!
Precedence: list

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 propos=
ed 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 - whic=
h will not appear in the final charter.=20

regards

Keith

> -----Original Message-----
> From: earlywarning-bounces@ietf.org=20
> [mailto:earlywarning-bounces@ietf.org] On Behalf Of Hannes Tschofenig
> Sent: Monday, May 31, 2010 10:13 PM
> To: earlywarning@ietf.org
> Subject: [earlywarning] Final Charter Text. Thanks!
>=20
> Thank you all for participating in this charter discussion. I=20
> plan to submit the following charter text to the RAI ADs=20
> within the next 24 hours. I included a few minor wording=20
> changes based on the very recent feedback on the list.=20
>=20
> Brian D., James P. + Martin T.: Please browse through the=20
> text to see whether you are happy with it.
>=20
> Ciao
> Hannes
>=20
> ----------------------------------------------
>=20
>=20
> Authority to Citizen Alert (ATOCA)
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> There are a variety of mechanisms that authorities have=20
> available to notify citizens and visitors during emergency=20
> events. Traditionally, theyhave done so with broadcast=20
> networks (radio and television). For commercial mobile=20
> devices, broadcasting services such as the Public Warning=20
> System (PWS), the Earthquake and Tsunami Warning System=20
> (ETWS), and the Commercial Mobile Alert System (CMAS) are=20
> standardized and are in various stages of deployment.  The=20
> Internet provides another way for authority-to-citizen alerts=20
> to be sent, but it also presents new challenges. While there=20
> are some existing layer 2 mechanisms for delivering alerts,=20
> the work in this group focuses on delivering alerts to IP=20
> endpoints only.
>=20
> The general message pattern that this group is intended to=20
> address is the sending of alerts from a set of pre-authorized=20
> agents (e.g., governmental agencies) to a large population=20
> without impacting layer 2 networks (e.g. causing congestion=20
> or denial of service).=20
> =20
> The goal of this group is not to specify how originators of=20
> alerts obtain authorization, but rather how an ATOCA system=20
> can verify authorization and deliver messages to the intended=20
> recipients. A critical element of the work are the mechanisms=20
> that assure that onlythose pre-authorized agents can send=20
> alerts via ATOCA, through an interface to authorized alert=20
> distribution networks (e.g., iPAWS/DM-Open in the U.S.).
>=20
> The ATOCA effort is differentiated from and is not intended=20
> to replace other alerting mechanisms (e.g., PWS, CMAS, ETWS),=20
> as the recipients of ATOCA alerts are the wide range of=20
> devices connected to the Internet and various private IP=20
> networks, which humans may have "at hand" to get such events,=20
> as well as automatons who may take action based on the=20
> alerts. This implies that the content of the alert contains=20
> some information, which is intended to be consumed by humans,=20
> and some which is intended to be consumed by automatons. =20
>=20
> Ideally, the alerts would contain, or refer to media other=20
> than text media (e.g., audio and/or video). The initial work=20
> in the group is focused on small messages, which may be=20
> mechanically rendered by the device in other forms (text to=20
> speech for example). Future work in the group may investigate=20
> rich media.
>=20
> In situations of a major emergency there could be scenarios=20
> where there are multiple alerts generated that may require=20
> that a priority mechanism (defined by alert originator=20
> policy) has to be used. The work on a resource priority=20
> mechanism is out of scope of the initial charter, but may be=20
> revisited at a later date.
>=20
> Which devices should get alerts is primarily driven by location. =20
> The first set of recipients that must be catered for are=20
> those within the area identified by the alert originator to=20
> be affected by the emergency event.  In many jurisdictions,=20
> there are regulations that define whether recipients/devices=20
> within the affected area have opt-in or opt-out capability,=20
> but the protocols ATOCA will define will include both opt-in=20
> and opt-out mechanisms. The group will explore how to support=20
> both opt-in and opt-out at the level of communication=20
> protocols and/or device behavior.
>=20
> Another class of recipients that are in scope of the work are=20
> explicit opt-in subscriptions which ask for alerts for a=20
> specified location, not necessarily the physical location of=20
> the device itself.=20
> An example of such a subscription would be 'send me alerts=20
> for location x' (previously determined as the location of interest).=20
> This work may build on existing IETF GEOPRIV location work.
>=20
> There are efforts in other fora on early warning, which will=20
> be considered in this effort.  For example, we expect to make=20
> use of the OASIS Common Alerting Protocol (CAP) for the=20
> encoding of alerts.  OGC, ATIS, TIA, ITU-T, ETSI and 3GPP=20
> also have alert efforts underway, and consultation with these=20
> efforts will be undertaken to avoid unnecessary duplication=20
> of effort and also to avoid unintentional negative impacts on=20
> the networks. Of course, existing protocols for delivering=20
> messages (e.g., SIP) will be the basis for the message=20
> delivery system of this working group.
>=20
> The security implications of mechanisms that can send alerts=20
> to billions of devices are profound, but the utility of the=20
> mechanism encourages us to face the problems and solve them.=20
> In addition, the potential performance and congestion impacts=20
> to networks resulting from sending alert information to=20
> billions of devices must be considered and solved if such a=20
> service is implementable. To avoid manual configuration of=20
> servers distributing alerts a discovery mechanism will be specified.
>=20
> Milestones
>=20
>=20
> TBD Initial document for "Terminology and Framework" document.=20
> A starting point for this work is
> draft-norreys-ecrit-authority2individuals-requirements.
>=20
> TBD Initial document for conveying alerts in SIP.=20
> A starting point for this work is draft-rosen-sipping-cap
>=20
> TBD	  Initial document for conveying alerts through point to
> multipoint methods.
>=20
> TBD      Initial document for locating the alerting server for a
> geographic region. A starting point for this work is=20
> draft-rosen-ecrit-lost-early-warning.
>=20
> TBD	  Initial document addressing security, performance and=20
> congestion issues for alert distribution.
>=20
> TBD	  Initial document for interfacing existing alert
> distribution systems.
> _______________________________________________
> earlywarning mailing list
> earlywarning@ietf.org
> https://www.ietf.org/mailman/listinfo/earlywarning
> =