Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B071F28C0F3 for ; Wed, 9 Jun 2010 03:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbA-2FZlYyuH for ; Wed, 9 Jun 2010 03:44:57 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id D352428C0E7 for ; Wed, 9 Jun 2010 03:44:56 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o59AXxc8024556 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 9 Jun 2010 12:44:51 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 9 Jun 2010 12:43:44 +0200 From: "DRAGE, Keith (Keith)" To: Hannes Tschofenig , "earlywarning@ietf.org" Date: Wed, 9 Jun 2010 12:43:43 +0200 Thread-Topic: RE: [earlywarning] Final Charter Text. Thanks! Thread-Index: AcsHthGYmB6Y632aSQy6Q35bcmAlhA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Subject: Re: [earlywarning] Final Charter Text. Thanks! X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 10:45:11 -0000 Resending, as apparently failed to be delivered to the list due to mail lis= t problems over weekend. See below.=20 > -----Original Message----- > From: earlywarning-bounces@ietf.org > [mailto:earlywarning-bounces@ietf.org] On Behalf Of Hannes Tschofenig > Sent: Wednesday, June 02, 2010 6:25 PM > To: DRAGE, Keith (Keith); earlywarning@ietf.org > Subject: Re: [earlywarning] Final Charter Text. Thanks! >=20 > Hi Keith, >=20 > thanks for your comment. A few notes inside.=20 >=20 > -------- Original-Nachricht -------- > > Datum: Tue, 1 Jun 2010 17:38:24 +0200 > > Von: "DRAGE, Keith (Keith)" > > An: Hannes Tschofenig ,=20 > > "earlywarning@ietf.org" > > Betreff: Re: [earlywarning] Final Charter Text. Thanks! >=20 > > Firstly a question: > >=20 > > What does "initial" mean in the milestones? >=20 > In context of the sentences it means that it is not covered by this=20 > version of the charter (which is the first, initial charter). >=20 In that case can we find some other word. We may never get to phase 2. >=20 > >=20 > > Secondly can you put some dates in the milestones, even if they are=20 > > things like "Charter date plus 9 months". >=20 > Good point. I forgot that.=20 > Done.=20 >=20 So now having the dates, I do not understand how: Sep 2010 Submit "Conveying alerts in SIP" document as initial=20 WG item.=20 A starting point for this work is draft-rosen-sipping-cap. can precede the security review. > > I at least need to understand the > > proposed document sequence. > >=20 > > I assume the approved milestones will not contain text such as: > >=20 > > "A starting point for this work is > draft-rosen-ecrit-lost-early-warning." > >=20 > > so can you move this text to some sort of editorial gloss > at the end - > > which will not appear in the final charter. > >=20 >=20 > It is actually quite common to indicate the starting point, which does=20 > not mean that the work will actually be used as a WG item. >=20 I would still prefer these not to be in the milestones. >=20 > Ciao > Hannes >=20 >=20 > > regards > >=20 > > Keith > >=20 > > > -----Original Message----- > > > From: earlywarning-bounces@ietf.org=20 > > > [mailto:earlywarning-bounces@ietf.org] On Behalf Of Hannes=20 > > > 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 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. > > >=20 > > > Brian D., James P. + Martin T.: Please browse through the text to=20 > > > see whether you are happy with it. > > >=20 > > > Ciao > > > Hannes > > >=20 > > > ---------------------------------------------- > > >=20 > > >=20 > > > Authority to Citizen Alert (ATOCA)=20 > > > =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 > available to > > > notify citizens and visitors during emergency events.=20 > 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=20 > > > (ETWS), and the Commercial Mobile Alert System (CMAS) are=20 > > > 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. > > >=20 > > > 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). > > > =20 > > > The goal of this group is not to specify how originators > of alerts > > > obtain authorization, but rather how an ATOCA system can verify=20 > > > authorization and deliver messages to the intended recipients. A=20 > > > critical element of the work are the mechanisms that assure that=20 > > > onlythose pre-authorized agents can send alerts via > ATOCA, through > > > an interface to authorized alert distribution networks (e.g.,=20 > > > iPAWS/DM-Open in the U.S.). > > >=20 > > > The ATOCA effort is differentiated from and is not intended to=20 > > > replace other alerting mechanisms (e.g., PWS, CMAS, ETWS), as the=20 > > > recipients of ATOCA alerts are the wide range of devices > connected > > > to the Internet and various private IP networks, which humans may=20 > > > have "at hand" to get such events, as well as automatons who may=20 > > > take action based on the alerts. This implies that the content of=20 > > > the alert contains some information, which is intended to be=20 > > > consumed by humans, and some which is intended to be consumed by=20 > > > automatons. > > >=20 > > > 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).=20 > Future work in > > > the group may investigate rich media. > > >=20 > > > In situations of a major emergency there could be scenarios where=20 > > > 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. > > >=20 > > > Which devices should get alerts is primarily driven by location. =20 > > > The first set of recipients that must be catered for are those=20 > > > 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=20 > > > will include both opt-in and opt-out mechanisms. The group will=20 > > > explore how to support both opt-in and opt-out at the level of=20 > > > communication 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 > specified > > > location, not necessarily the physical location of the device=20 > > > itself. > > > An example of such a subscription would be 'send me alerts for=20 > > > location x' (previously determined as the location of interest). > > > This work may build on existing IETF GEOPRIV location work. > > >=20 > > > There are efforts in other fora on early warning, which will be=20 > > > considered in this effort. For example, we expect to make use of=20 > > > the OASIS Common Alerting Protocol (CAP) for the encoding > of alerts. =20 > > > OGC, ATIS, TIA, ITU-T, ETSI and 3GPP also have alert efforts=20 > > > underway, and consultation with these efforts will be > undertaken to > > > avoid unnecessary duplication of effort and also to avoid=20 > > > 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. > > >=20 > > > The security implications of mechanisms that can send alerts to=20 > > > 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=20 > > > networks resulting from sending alert information to billions of=20 > > > devices must be considered and solved if such a service is=20 > > > implementable. To avoid manual configuration of 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 > > >=20 > > _______________________________________________ > > 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 > = Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD4C128C0E1 for ; Wed, 2 Jun 2010 10:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.251 X-Spam-Level: X-Spam-Status: No, score=0.251 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qyDhPDxd2YI for ; Wed, 2 Jun 2010 10:29:05 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 189063A6837 for ; Wed, 2 Jun 2010 10:29:04 -0700 (PDT) Received: (qmail 23175 invoked by uid 0); 2 Jun 2010 17:28:51 -0000 Received: from 88.115.222.204 by www113.gmx.net with HTTP; Wed, 02 Jun 2010 19:28:50 +0200 (CEST) Content-Type: text/plain; charset="utf-8" Date: Wed, 02 Jun 2010 19:28:50 +0200 From: "Hannes Tschofenig" Message-ID: <20100602172850.269380@gmx.net> MIME-Version: 1.0 To: Gonzalo.Camarillo@ericsson.com, rjsparks@nostrum.com X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX19/5xNJWZh/50sNzJcTrIqBqbDohDtxupQ5Fx7uCr MhUOrkO0J6LnSR9+n7QDLVjDbIRglvRAR4jw== Content-Transfer-Encoding: 8bit X-GMX-UID: 5aI1eFghTXsuJIAHo2U5ec5CRzdyMoM4 X-FuHaFi: 0.60999999999999999 Cc: earlywarning@ietf.org Subject: [earlywarning] ATOCA Charter Discussion Finished X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2010 17:29:07 -0000 Hi Gonzalo, Hi Robert, we have finally finished the charter discussions for the Authority to Citizen Alert (ATOCA) group. 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, 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 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 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.). 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. Goals and Milestones Aug 2010 Submit "Terminology and Framework" document as initial WG item. A starting point for this work is draft-norreys-ecrit-authority2individuals-requirements. Sep 2010 Submit "Conveying alerts in SIP" document as initial WG item. A starting point for this work is draft-rosen-sipping-cap. Dec 2010 Submit "Conveying alerts through point-to-multipoint methods" document as initial WG item. Oct 2010 Submit "Discovering alerting servers" document as initial WG item. A starting point for this work is draft-rosen-ecrit-lost-early-warning. Dec 2010 Submit "Addressing security, performance and congestion issues for alert distribution" document as initial WG item. Jan 2011 Submit "Interfacing existing alert distribution systems" document as initial WG item. Jan 2011 Submit "Terminology and Framework" to the IESG for consideration as an Informational RFC. Mar 2011 Submit "Conveying alerts in SIP" to the IESG for consideration as a Standards Track RFC. May 2011 Submit "Conveying alerts through point-to-multipoint methods" to the IESG for consideration as an Informational RFC. Apr 2011 Submit "Discovering alerting servers" to the IESG for consideration as a Standards Track RFC. Jun 2011 Submit "Addressing security, performance and congestion issues for alert distribution" to the IESG for consideration as an Informational RFC. Aug 2011 Submit "Interfacing existing alert distribution systems" to the IESG for consideration as an Informational RFC. Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5DF528C0E1 for ; Wed, 2 Jun 2010 10:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.5 X-Spam-Level: X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p83S12UdFhOn for ; Wed, 2 Jun 2010 10:25:44 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id C1B853A6804 for ; Wed, 2 Jun 2010 10:25:43 -0700 (PDT) Received: (qmail 10314 invoked by uid 0); 2 Jun 2010 17:25:29 -0000 Received: from 88.115.222.204 by www113.gmx.net with HTTP; Wed, 02 Jun 2010 19:25:28 +0200 (CEST) Content-Type: text/plain; charset="utf-8" Date: Wed, 02 Jun 2010 19:25:28 +0200 From: "Hannes Tschofenig" In-Reply-To: Message-ID: <20100602172528.269400@gmx.net> MIME-Version: 1.0 References: <20100531211316.310600@gmx.net> To: "DRAGE, Keith (Keith)" , earlywarning@ietf.org X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX19IrHJhh7FIhIYdugq3U/GLpw3J4ExuF+MK0cPREU zygI4LouugEWQUy0cgHOa5CncpvaG9EabwNA== Content-Transfer-Encoding: 8bit X-GMX-UID: P6wwfQ5aYmYBBcVUp3Y3/N9CWkZTQVRw X-FuHaFi: 0.56999999999999995 Subject: Re: [earlywarning] Final Charter Text. Thanks! X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2010 17:25:45 -0000 Hi Keith, thanks for your comment. A few notes inside. -------- Original-Nachricht -------- > Datum: Tue, 1 Jun 2010 17:38:24 +0200 > Von: "DRAGE, Keith (Keith)" > An: Hannes Tschofenig , "earlywarning@ietf.org" > Betreff: Re: [earlywarning] Final Charter Text. Thanks! > Firstly a question: > > What does "initial" mean in the milestones? In context of the sentences it means that it is not covered by this version of the charter (which is the first, initial charter). > > Secondly can you put some dates in the milestones, even if they are things > like "Charter date plus 9 months". Good point. I forgot that. Done. > 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. > It is actually quite common to indicate the starting point, which does not mean that the work will actually be used as a WG item. Ciao Hannes > regards > > Keith > > > -----Original Message----- > > From: earlywarning-bounces@ietf.org > > [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! > > > > 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 > > earlywarning@ietf.org > > https://www.ietf.org/mailman/listinfo/earlywarning > > > _______________________________________________ > earlywarning mailing list > earlywarning@ietf.org > https://www.ietf.org/mailman/listinfo/earlywarning Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C95673A6908 for ; Tue, 1 Jun 2010 15:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.999 X-Spam-Level: X-Spam-Status: No, score=-103.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZGEaQMCFMGO for ; Tue, 1 Jun 2010 15:53:54 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 674623A689B for ; Tue, 1 Jun 2010 15:53:54 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: BD2985@att.com X-Msg-Ref: server-12.tower-120.messagelabs.com!1275432821!57325146!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.112.25] Received: (qmail 2854 invoked from network); 1 Jun 2010 22:53:41 -0000 Received: from sbcsmtp3.sbc.com (HELO tlph064.enaf.dadc.sbc.com) (144.160.112.25) by server-12.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Jun 2010 22:53:41 -0000 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by tlph064.enaf.dadc.sbc.com (8.14.3/8.14.3) with ESMTP id o51MrenJ015960; Tue, 1 Jun 2010 17:53:41 -0500 Received: from td03xsmtp005.US.Cingular.Net (td03xspare20-new.us.cingular.net [135.179.64.44] (may be forged)) by tlph064.enaf.dadc.sbc.com (8.14.3/8.14.3) with ESMTP id o51MrccH015936; Tue, 1 Jun 2010 17:53:38 -0500 Received: from bd01xsmtp004.US.Cingular.Net ([135.163.18.45]) by td03xsmtp005.US.Cingular.Net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Jun 2010 17:53:38 -0500 Received: from BD01MSXMB016.US.Cingular.Net ([135.214.27.50]) by bd01xsmtp004.US.Cingular.Net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Jun 2010 15:53:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Jun 2010 15:53:32 -0700 Message-ID: In-Reply-To: <20100531211316.310600@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [earlywarning] Final Charter Text. Thanks! Thread-Index: AcsBBiTRUYSNxZGvR1mmH/snNOkpUAA1xLVA References: <20100531211316.310600@gmx.net> From: "DALY, BRIAN K (ATTCINW)" To: "Hannes Tschofenig" , X-OriginalArrivalTime: 01 Jun 2010 22:53:34.0716 (UTC) FILETIME=[43CDEBC0:01CB01DD] Subject: Re: [earlywarning] Final Charter Text. Thanks! X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 22:53:55 -0000 The current text addresses our concerns. Regards, Brian K. Daly AT&T Mobility Services, LLC Rethink Possible -----Original Message----- From: earlywarning-bounces@ietf.org [mailto:earlywarning-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Monday, May 31, 2010 2:13 PM To: earlywarning@ietf.org 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.=20 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) =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 There are a variety of mechanisms that authorities have available to notify citizens and visitors during emergency events. Traditionally,=20 theyhave done so with broadcast networks (radio and television). For=20 commercial mobile devices, broadcasting services such as the Public=20 Warning 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 Internet=20 provides another way for authority-to-citizen alerts to be sent, but=20 it also presents new challenges. While there are some existing=20 layer 2 mechanisms for delivering alerts, the work in this group=20 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=20 layer 2 networks (e.g. causing congestion or denial of service).=20 =20 The goal of this group is not to specify how originators of alerts=20 obtain authorization, but rather how an ATOCA system can verify=20 authorization and deliver messages to the intended recipients. A critical element of the work are the mechanisms that assure that=20 onlythose pre-authorized agents can send alerts via ATOCA, through=20 an interface to authorized alert distribution networks=20 (e.g., iPAWS/DM-Open in the U.S.). The ATOCA effort is differentiated from and is not intended to=20 replace other alerting mechanisms (e.g., PWS, CMAS, ETWS), as the=20 recipients of ATOCA alerts are the wide range of devices connected to=20 the Internet and various private IP networks, which humans may have=20 "at hand" to get such events, as well as automatons who may take=20 action based on the alerts. This implies that the content of the=20 alert contains some information, which is intended to be consumed=20 by humans, and some which is intended to be consumed by automatons. =20 Ideally, the alerts would contain, or refer to media other than text=20 media (e.g., audio and/or video). The initial work in the group is=20 focused on small messages, which may be mechanically rendered by the=20 device in other forms (text to speech for example). Future work in=20 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=20 used. The work on a resource priority mechanism is out of scope of=20 the initial charter, but may be revisited at a later date. Which devices should get alerts is primarily driven by location. =20 The first set of recipients that must be catered for are those=20 within the area identified by the alert originator to be affected=20 by the emergency event. In many jurisdictions, there are regulations=20 that define whether recipients/devices within the affected area have=20 opt-in or opt-out capability, but the protocols ATOCA will define=20 will include both opt-in and opt-out mechanisms. The group will=20 explore how to support both opt-in and opt-out at the level of=20 communication protocols and/or device behavior. Another class of recipients that are in scope of the work are=20 explicit opt-in subscriptions which ask for alerts for a specified=20 location, not necessarily the physical location of the device itself.=20 An example of such a subscription would be 'send me alerts for=20 location x' (previously determined as the location of interest).=20 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=20 of the OASIS Common Alerting Protocol (CAP) for the encoding of=20 alerts. OGC, ATIS, TIA, ITU-T, ETSI and 3GPP also have alert=20 efforts underway, and consultation with these efforts will be=20 undertaken to avoid unnecessary duplication of effort and also=20 to avoid unintentional negative impacts on the networks. Of course,=20 existing protocols for delivering messages (e.g., SIP) will be the=20 basis for the message delivery system of this working group. The security implications of mechanisms that can send alerts to=20 billions of devices are profound, but the utility of the mechanism=20 encourages us to face the problems and solve them. In addition, the=20 potential performance and congestion impacts to networks resulting=20 from sending alert information to billions of devices must be=20 considered and solved if such a service is implementable. To avoid=20 manual configuration of servers distributing alerts a discovery=20 mechanism will be specified. Milestones TBD Initial document for "Terminology and Framework" document.=20 A starting point for this work is=20 draft-norreys-ecrit-authority2individuals-requirements. TBD Initial document for conveying alerts in SIP.=20 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=20 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 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D35F28C165 for ; Tue, 1 Jun 2010 08:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.966 X-Spam-Level: X-Spam-Status: No, score=-3.966 tagged_above=-999 required=5 tests=[AWL=-0.317, BAYES_50=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0W2IWRWub0h for ; Tue, 1 Jun 2010 08:38:53 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id BF13528C156 for ; Tue, 1 Jun 2010 08:38:52 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o51FcLbo014338 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 1 Jun 2010 17:38:38 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 1 Jun 2010 17:38:25 +0200 From: "DRAGE, Keith (Keith)" To: Hannes Tschofenig , "earlywarning@ietf.org" Date: Tue, 1 Jun 2010 17:38:24 +0200 Thread-Topic: [earlywarning] Final Charter Text. Thanks! Thread-Index: AcsBBiHYNfwSxI7CSkG0hpMx3XNR1wAmZwWA Message-ID: References: <20100531211316.310600@gmx.net> In-Reply-To: <20100531211316.310600@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Subject: Re: [earlywarning] Final Charter Text. Thanks! X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 15:38:55 -0000 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 > =