Re: [atoca] The future of atoca

Henning Schulzrinne <hgs@cs.columbia.edu> Mon, 30 July 2012 21:46 UTC

Return-Path: <hgs@cs.columbia.edu>
X-Original-To: atoca@ietfa.amsl.com
Delivered-To: atoca@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B792211E81AE for <atoca@ietfa.amsl.com>; Mon, 30 Jul 2012 14:46:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mJGxSH4VF04 for <atoca@ietfa.amsl.com>; Mon, 30 Jul 2012 14:46:29 -0700 (PDT)
Received: from salak.cc.columbia.edu (salak.cc.columbia.edu [128.59.29.6]) by ietfa.amsl.com (Postfix) with ESMTP id 23B5E11E81AD for <atoca@ietf.org>; Mon, 30 Jul 2012 14:46:29 -0700 (PDT)
Received: from [172.20.22.63] ([208.23.64.30]) (user=hgs10 mech=PLAIN bits=0) by salak.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id q6ULkKDB002720 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 30 Jul 2012 17:46:21 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\))
From: Henning Schulzrinne <hgs@cs.columbia.edu>
In-Reply-To: <266595E9-AB52-4269-BF78-C239DE25FC94@gmx.net>
Date: Mon, 30 Jul 2012 17:46:20 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <4CDBD8FD-69D2-466D-8557-BC60F117D1B6@cs.columbia.edu>
References: <20120721131113.7B35C21F8646@ietfa.amsl.com> <B1C4C394-1E40-48FF-AE06-7B3871EEAA08@incident.com> <EDC0A1AE77C57744B664A310A0B23AE240AE89B6@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <AFDE3396-F0AC-41FD-886C-A8CC64009CD6@brianrosen.net> <266595E9-AB52-4269-BF78-C239DE25FC94@gmx.net>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
X-Mailer: Apple Mail (2.1485)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.68 on 128.59.29.6
Cc: atoca@ietf.org
Subject: Re: [atoca] The future of atoca
X-BeenThere: atoca@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." <atoca.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/atoca>, <mailto:atoca-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/atoca>
List-Post: <mailto:atoca@ietf.org>
List-Help: <mailto:atoca-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/atoca>, <mailto:atoca-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Jul 2012 21:46:29 -0000

There is significant regulatory interest in exploring IP-based options, so I would encourage taking stock and looking at a variety of options. Even a summary of the options and why they do NOT work is useful. Some initial questions that push beyond the SIP message space:

One of the bigger problems with CMAS (cellular alerts) is the short message size, which provides only very limited actionable information.

Can we leverage IP-TV style multicast for scalable distribution? How would the equivalent of EAS work in an IP video environment?

Can we separate the common problem of in-area alerting (subscribers in a particular area) from the less-common problem of out-of-area alerting ("elderly relative")?

Do we have any real experience with the realistic limits of web-based flash crowds? If every household is watching entertainment (or Olympic) video at night, the additional load of adding reasonably-detailed information may not be all that large and CDNs are used to large crowds.

Henning

On Jul 30, 2012, at 5:36 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

> The problem I see is that we actually don't have a proposal that actually works.
> Abstract discussions about potential solutions don't help to make progress. 
> 
> 
> 
> _______________________________________________
> atoca mailing list
> atoca@ietf.org
> https://www.ietf.org/mailman/listinfo/atoca
>