Subject: Re: [earlywarning] New Charter Text for ATOCA

From: [email-masked]
Date: Wed, 24 Mar 2010 17:40:49 -0400 (EDT)

Hannes -

Some additional information. In Canada, they use a Canadian Profile of CAP
for authority to authority and then transform the CAP message to GeoRSS
GML, SMS, or KML for authority to citizen. In Taiwan, there has been some
work also in the alerting world using a new draft spec called GeoSMS. In
Taiwan, they are also using a draft OGC standards called Sensor Alert
Service (SAS), but this will change based on the work described below.

That said, the OGC community is forging ahead looking at frameworks and
architectures for alerting. In the OGC Web Services 7.0 testbed:

OWS-7 is doing a lot of testing related to alert notification
capabilities.  They are currently looking at a new service tentatively
titled SES (Sensor Event Service)
http://portal.opengeospatial.org/files/?artifact_id=29576 (earlier
discussion paper) which is being enhanced to output the alert in several
different formats - CAP, ATOM, and I believe GeoRSS.  I believe the Sensor
part of the Event Service is a misnomer as this service will not be tied
to only sensors so I think the name will change eventually.  It is the
consensus of the OWS-7 group that the draft OGC Sensor Alert Service will
no longer be required.  As I understand it, the OGC Web Notification
Service is a method of delivery of the message (email, Short Message
Service (SMS), Instant Messaging (IM), automated phone calls or faxes) as
such is more of a message transport service. SAS and WNS are beng
integrated into the SES specification.

Who is supporting this work within the OGC community? OWS-7 is described
here: http://www.opengeospatial.org/standards/requests/60. There are
numerous additional OGC Member organizations working this application
area. The OWS-7 work is aligned with the GMES, ORCHESTRA, and GEOSS
requirements for alerting.

The OGC work is being done perhaps at a higher level in the applications
stack than the IETF work being envisioned.

Cheers

Carl

> Based on the discussions during the breakout session we came up with the
> following text proposal.
> Please let us know whether you are OK with the wording.
>
>
> Authority to Citizen Alert (ATOCA)
> ==================================
>
> Authorities need mechanisms to notify citizens and visitors of emergency
> events.   Traditionally, they have done so with broadcast networks (radio
> and television).  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. The goal of this group is not to specify
> how originators of alerts obtain authorization, but rather how a messaging
> system can verify authorization and deliver message to the intended
> recipients.
> A critical element of the work arethe mechanisms that assure that only
> authorized agents can send alerts.
>
> The recipients of these 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 thedevice 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 has
> to be implemented, and this mechanism is out of scope at his time.
>
> 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
> affected by the alert.  In many jurisdictions, there are regulations that
> define whether recipients 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.
>
> Another class of recipients that are in scope of the work are explicit
> opt-in subscriptions which ask for alerts that are sent to an associated
> party.  An example of such a subscription would be 'send me alerts which
> are
> sent too my daughter based on her location'. This work builds on existing
> IETF geopriv location work.
>
> There are other efforts in other fora on alerts, 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.  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.
> 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.
>
> 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
> TBD      Initial document for subscribing to alerts using SIP
>          A starting point for this work is draft-rosen-sipping-cap
> 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.
>
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 24 Mar 2010 18:22:29 -0400

Hi Carl,

thanks for the input.

How would your feedback be reflected in the charter text?

Ciao
Hannes