Re: [earlywarning] Final Charter Text. Thanks!

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

Resending, as apparently failed to be delivered to the list due to mail list problems over weekend.



See below. 

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Hannes Tschofenig
> Sent: Wednesday, June 02, 2010 6:25 PM
> To: DRAGE, Keith (Keith); [e-mail]
> Subject: Re: [earlywarning] Final Charter Text. Thanks!
> 
> 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)" <[e-mail]>
> > An: Hannes Tschofenig <[e-mail]>, 
> > "[e-mail]" <[e-mail]>
> > 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).
> 
In that case can we find some other word. We may never get to phase 2.

> 
> > 
> > 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. 
> 
So now having the dates, I do not understand how:

Sep 2010  Submit "Conveying alerts in SIP" document as initial 
          WG item. 
          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.
> > 
> > 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.
> 
I would still prefer these not to be in the milestones.

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