Re: [earlywarning] (no subject)

creed@opengeospatial.org Fri, 26 March 2010 14:44 UTC

Return-Path: <creed@opengeospatial.org>
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 66E893A69CF for <earlywarning@core3.amsl.com>; Fri, 26 Mar 2010 07:44:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.602
X-Spam-Level:
X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13]
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 Yyo13dnwfHzi for <earlywarning@core3.amsl.com>; Fri, 26 Mar 2010 07:44:55 -0700 (PDT)
Received: from mail.opengeospatial.org (mail.opengeospatial.org [66.244.86.40]) by core3.amsl.com (Postfix) with ESMTP id 8583B3A695A for <earlywarning@ietf.org>; Fri, 26 Mar 2010 07:44:52 -0700 (PDT)
Received: from mail.opengeospatial.org (localhost [127.0.0.1]) by mail.opengeospatial.org (8.13.8/8.13.8/Debian-3+etch1) with ESMTP id o2QEj7Hi005553; Fri, 26 Mar 2010 10:45:08 -0400
Received: from 198.123.49.132 (SquirrelMail authenticated user creed) by mail.opengeospatial.org with HTTP; Fri, 26 Mar 2010 10:45:08 -0400 (EDT)
Message-ID: <62302.198.123.49.132.1269614708.squirrel@mail.opengeospatial.org>
In-Reply-To: <C7D16EF9.2B4B3%br@brianrosen.net>
References: <C7D16EF9.2B4B3%br@brianrosen.net>
Date: Fri, 26 Mar 2010 10:45:08 -0400
From: creed@opengeospatial.org
To: Brian Rosen <br@brianrosen.net>
User-Agent: SquirrelMail/1.4.9a
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: ClamAV 0.92.1/10628/Fri Mar 26 09:57:50 2010 on mail.opengeospatial.org
X-Virus-Status: Clean
Cc: "DALY, BRIAN K (ATTCINW)" <bd2985@att.com>, earlywarning@ietf.org
Subject: Re: [earlywarning] (no subject)
X-BeenThere: earlywarning@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " <earlywarning.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/earlywarning>, <mailto:earlywarning-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/earlywarning>
List-Post: <mailto:earlywarning@ietf.org>
List-Help: <mailto:earlywarning-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/earlywarning>, <mailto:earlywarning-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Mar 2010 14:44:59 -0000

Absolutely!

Carl

> Once again, this is NOT about a solution limited to wireless cellular
> networks.  It is about a solution for internet connected endpoints of all
> kinds.
>
> Brian
>
>
> On 3/25/10 7:46 PM, "DALY, BRIAN K (ATTCINW)" <BD2985@att.com> wrote:
>
>> Keith ­ We agree with you, and to further the point, in wireless
>> cellular IP
>> networks a point to point solution would be problematic. Cell Broadcast
>> is
>> used for CMAS because SMS cannot be used for any real time alerting ­ it
>> was
>> not designed for that application and has serious limitations, as the
>> FCC
>> CMSAAC studied.
>>
>> When it comes to the evolved packet core and IMS, again a point to point
>> solution  will cause significant congestion on the network and a
>> broadcast/multicast solution must be used to effectively deliver alert
>> messages. Thus things like location and ³priority² are already handled
>> in the
>> delivery network.
>>
>> ATIS and 3GPP will be studying how to support multimedia alerts in the
>> future,
>> as recommended by the FCC CMSAAC. This is all beyond the scope of this
>> work
>> effort.
>>
>> Regards,
>> Brian
>>
>> Date: Thu, 25 Mar 2010 03:13:24 +0100
>> From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
>> Subject: Re: [earlywarning] Updated Charter Text for ATOCA
>> To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>,
>>       "earlywarning@ietf.org" <earlywarning@ietf.org>
>> Message-ID:
>>
>> <EDC0A1AE77C57744B664A310A0B23AE20D1639BB@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.c
>> om>
>>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> What I am not seeing here is any separation of the problem from the one
>> that
>> cell broadcast attempts to solve. Fundamentally, cell broadcast, as
>> exists on
>> all GSM, UTRAN and E-UTRAN based cell phones and is being used for
>> Tsunami
>> warning and Public Warning, exists and is not going to substantially
>> change.
>> The major limitation here is is length of message, and what does get
>> transmitted will be very much dependent on that restriction.
>>
>> Moreover I have heard from a number of governmental bodies that they are
>> happy
>> with that situation and are not envisaging further standardisation in
>> that
>> area outside of 3GPP.
>>
>> So my view at the moment is that there is no point in IETF trying to
>> address
>> the scope of what is already specified in cell broadcast (from base
>> station to
>> end mobile).
>>
>> regards
>>
>> Keith
>>
>>
>>
>>
>> _______________________________________________
>> 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
>