[Ecrit] ATOCA BOF Request Text

"Rosen, Brian" <Brian.Rosen@neustar.biz> Tue, 14 October 2008 18:47 UTC

Return-Path: <ecrit-bounces@ietf.org>
X-Original-To: ecrit-archive@megatron.ietf.org
Delivered-To: ietfarch-ecrit-archive@core3.amsl.com
Received: from [] (localhost []) by core3.amsl.com (Postfix) with ESMTP id 59F393A686E; Tue, 14 Oct 2008 11:47:41 -0700 (PDT)
X-Original-To: ecrit@core3.amsl.com
Delivered-To: ecrit@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 0A79E3A6849 for <ecrit@core3.amsl.com>; Tue, 14 Oct 2008 11:47:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.284
X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id JQuT7dA5LP6p for <ecrit@core3.amsl.com>; Tue, 14 Oct 2008 11:47:40 -0700 (PDT)
Received: from neustar.com (ns7.neustar.com []) by core3.amsl.com (Postfix) with ESMTP id 7BAF13A67F8 for <ecrit@ietf.org>; Tue, 14 Oct 2008 11:47:38 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; d=neustar.biz; s=neustarbiz; c=simple/simple; q=dns; t=1224010078; x=1224096478; h=From:Date:Subject:Message-ID:Content-class:Content-Type:Content-Transfer-Encod ing; b=e/HzMpq/5oSJK+Dbsu2nsKjMKIF+ynLA1fqudLkt1I/P6jcJRGwTpmt8XPjskyt7i0CgjjfzUK49Qq sKJKI2aA==
Received: from ([]) by chihiron2.nc.neustar.com with ESMTP id 5202415.8859537; Tue, 14 Oct 2008 14:47:34 -0400
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 14 Oct 2008 14:46:38 -0400
Message-ID: <C80ADC57CB3BB64B94A9954A816306C5AA6E24@STNTEXCH11.cis.neustar.com>
Thread-Topic: ATOCA BOF Request Text
Thread-Index: AckuLTBcAW5j2MyKQ9u7o+tRVlTalA==
From: "Rosen, Brian" <Brian.Rosen@neustar.biz>
To: "ECRIT" <ecrit@ietf.org>
Subject: [Ecrit] ATOCA BOF Request Text
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ecrit-bounces@ietf.org
Errors-To: ecrit-bounces@ietf.org


Authority-to-Citizen Alert 

Mailing Lists: earlywarn@ietf.org

BOF chairs:

Brian Rosen [brian.rosen at neustar.biz]

Steve Norreys [steve.norreys@bt.com]

Temporary Area Directorate: Real Time Applications (RAI)

Ultimate Area Directorate: TBD

BOF Purpose.

ecrit is working on citizen-to-authority calls.  Alerts that are sent
from "authorities"
(which we define broadly to any level of authority, including, for
example, a school
administrator) to "citizen" (which we also define broadly to include
visitors and other
individuals and groups) are of great interest.  Many efforts are
underway in other fora,
but all of them are stovepipes: limited by which authorities can invoke
alerts as well as
which networks they can be distributed on.  What is needed is a more
flexible way to 
deliver alerts from any notifier to any interested or affected
individual, via any device
connected to the Internet. 

This is a large problem: some alerts must be delivered to an enormous
number of endpoints; 
a Tsunami warning may involve millions of devices eventually.  A system
which can deliver 
messages to billions of endpoints with one notification are obviously
attractive attack
targets.  This is further complicated by the desire to accept
notifications from a wide
variety of notifiers, complicating authentication mechanisms that might
be employed.  
The security implications of any solutions must be addressed as a
intergral part of the 
solution from the very start of the work.   

Classic alert systems typically use layer 2 broadcast mechanisms and
often use some kind
of location as a criteria for who gets the alert.  On the Internet,
multicast mechanisms may
be helpful, but the paucity of multicast deployment must be considered.
Besides broadcast, 
which certainly is very appropriate, it is very useful to be able to
subscribe to events 
for individuals who may not normally meet criteria for being included in
a broadcast.  
For example, parents may wish to receive alerts that affect their
children.  An alert 
directed to anyone in the path of a hurricane may be broadcast, but the
parent may need 
a subscription to get the same alert when they are not in the affected

The content of an alert is also a significant challenge to Internet
scale alerts.  The alert
must be rendered on a wide variety of devices with different user
interface capabilities.
Multiple languages have to be accomodated.  Networks with limited
bandwidth must be

Alert work is being done in many fora, and some is directly applicable
to this work. For
example, OASIS work on Common Alerting Protocol is likely part of the
solution. It should also 
be recognised that this is an area of work that will be highly regulated
and as such close work
with the fora where regulators operate (e.g. ATIS, ETSI and ITU-T) may
help with the deployment of 
any solutions.  

The purpose of the BOF is to determine the need and scope for authority
to citizen alerts, 
what existing protocols and mechansims need to be adapted to meet those
and the appropriate representation for alerts should be.

This work could be accomplished within an expanded charter of ecrit, or
a new work group
could be formed.  This work will leverage geopriv work on location.

Proposed Deliverables:

1) Requirements for ATOCA .
2) An ATOCA Framework.
3) Various protocol and mechanism enhancements to meet the requirements

Input Documents:

1) Requirements

Ecrit mailing list