Re: [earlywarning] (no subject)

Henning Schulzrinne <hgs@cs.columbia.edu> Fri, 26 March 2010 01:42 UTC

Return-Path: <hgs@cs.columbia.edu>
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 855EF3A684D for <earlywarning@core3.amsl.com>; Thu, 25 Mar 2010 18:42:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[AWL=-0.429, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001]
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 Ibrz98IeWb6B for <earlywarning@core3.amsl.com>; Thu, 25 Mar 2010 18:42:53 -0700 (PDT)
Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by core3.amsl.com (Postfix) with ESMTP id AB1D43A67AF for <earlywarning@ietf.org>; Thu, 25 Mar 2010 18:42:44 -0700 (PDT)
Received: from dhcp-wireless-open-abg-26-78.meeting.ietf.org (dhcp-wireless-open-abg-26-78.meeting.ietf.org [130.129.26.78]) (user=hgs10 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o2Q1gbc1026508 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 25 Mar 2010 21:42:57 -0400 (EDT)
References: <FDFC6E6B2064844FBEB9045DF1E3FBBC093CB9@BD01MSXMB016.US.Cingular.Net>
In-Reply-To: <FDFC6E6B2064844FBEB9045DF1E3FBBC093CB9@BD01MSXMB016.US.Cingular.Net>
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: multipart/alternative; boundary="Apple-Mail-10--797220255"
Message-Id: <31EE3F21-17E9-467E-A33C-5CECF2054B33@cs.columbia.edu>
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Date: Thu, 25 Mar 2010 21:42:35 -0400
To: "DALY, BRIAN K (ATTCINW)" <BD2985@att.com>
X-Mailer: Apple Mail (2.1077)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7
Cc: "SENNETT, DEWAYNE A (ATTCINW)" <DS2225@att.com>, James.Winterbottom@andrew.com, earlywarning@ietf.org, keith.drage@alcatel-lucent.com
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 01:42:55 -0000

May I suggest you read my comments about out-of-area notifications? For what it's worth, I disagree with your suggestion.

Henning

On Mar 25, 2010, at 9:31 PM, DALY, BRIAN K (ATTCINW) wrote:

> We need to recognize that devices connected to 3G networks will receive alerts via PWS/CMAS and this work is not applicable to those devices, and may result in degrading the "layer 2" networks. This needs to be part of the charter. That is the proposed modification.
> 
> Brian 
> Brian K. Daly 
> ------- 
> Sent from my Blackberry
> 
> From: Winterbottom, James <James.Winterbottom@andrew.com> 
> To: DALY, BRIAN K (ATTCINW); br@brianrosen.net <br@brianrosen.net>; SENNETT, DEWAYNE A (ATTCINW); keith.drage@alcatel-lucent.com <keith.drage@alcatel-lucent.com>; earlywarning@ietf.org <earlywarning@ietf.org> 
> Sent: Thu Mar 25 18:25:00 2010
> Subject: RE: [earlywarning] (no subject) 
> 
> I am not so sure that we can just 802.11 and be done with it.
> We also have a lot of broadband deployments out there that still run PPP over ATM, where an 802.11 solution is not going to work.
> My preference would be to see a solution that works regardless of how the device is connected to the Internet.
>  
> Cheers
> James
>  
>  
>  
> From: DALY, BRIAN K (ATTCINW) [mailto:BD2985@att.com] 
> Sent: Friday, 26 March 2010 12:21 PM
> To: Winterbottom, James; br@brianrosen.net; SENNETT, DEWAYNE A (ATTCINW); keith.drage@alcatel-lucent.com; earlywarning@ietf.org
> Subject: Re: [earlywarning] (no subject)
>  
> James
> 
> Good point and I think this is an area for discussion along with the dot11 issue. I see these as part of the work that this effort should evaluate.
> 
> This is different from where the end device obtains service directly from the 3GPP network.
> 
> Brian
> Brian K. Daly
> -------
> Sent from my Blackberry
>  
> From: Winterbottom, James <James.Winterbottom@andrew.com>
> To: DALY, BRIAN K (ATTCINW); br@brianrosen.net <br@brianrosen.net>; SENNETT, DEWAYNE A (ATTCINW); keith.drage@alcatel-lucent.com <keith.drage@alcatel-lucent.com>; earlywarning@ietf.org <earlywarning@ietf.org>
> Sent: Thu Mar 25 18:14:35 2010
> Subject: RE: [earlywarning] (no subject)
> 
> Brian D,
>  
> We are increasingly seeing 3G hotspot devices, aka MiFi type devices. In this mode the devices using 3G as a backhaul are connected to the Internet and almost certainly do not have access to the underlying IMS services. Any solution needs to work in that environment too. I am interested to hear what you are proposing here.
>  
> Cheers
> James
>  
>  
>  
> From: earlywarning-bounces@ietf.org [mailto:earlywarning-bounces@ietf.org] On Behalf Of DALY, BRIAN K (ATTCINW)
> Sent: Friday, 26 March 2010 12:07 PM
> To: br@brianrosen.net; SENNETT, DEWAYNE A (ATTCINW); keith.drage@alcatel-lucent.com; earlywarning@ietf.org
> Subject: Re: [earlywarning] (no subject)
>  
> This is NOT silly Brian but serious when you consider the consequences to the networks.
> 
> We have a solution in place for devices connected to a 3GPP network - we are asking that this work exclude devices that support 3GPP PWS/CMAS (EPC and IMS) as those solutions as designed and optimized for the "layer 2" networks. We even have mobile device behavior specifications.
> 
> I propose we adopt the language in the charter.
> 
> Brian
> Brian K. Daly
> -------
> Sent from my Blackberry
>  
> From: Brian Rosen <br@brianrosen.net>
> To: SENNETT, DEWAYNE A (ATTCINW); DALY, BRIAN K (ATTCINW); keith.drage@alcatel-lucent.com <keith.drage@alcatel-lucent.com>; earlywarning@ietf.org <earlywarning@ietf.org>
> Sent: Thu Mar 25 17:59:21 2010
> Subject: Re: [earlywarning] (no subject)
> 
> I think this is silly.
> 
> No one is working on alert mechanisms that apply to the Internet.
> 
> The Internet is global, ubiquitous and independent of L2.  The proposed work applies to any kind of device connected to the Internet.  Whatever scale problems exist apply to all L2s one way or another.  They must be faced and solved for the work to be useful.  To exclude wireless IMS systems based on the notion that someone else is working on a system limited to cell broadcast is, in my opinion, not a good idea.
> 
> I do well understand that vendors and carriers don’t like multiple answers to the same problem.  I get that.  However, the IETF is the proper place to do work on alerts on the Internet, and should not exclude parts of the Internet.
> 
> Brian
> 
> 
> On 3/25/10 8:50 PM, "SENNETT, DEWAYNE A (ATTCINW)" <DS2225@att.com> wrote:
> 
> I propose that the following sentence be added to the ATOCA charter:
> 
> The ATOCA RFC's are not applicable to wireless devices which receive their connectivity via 3GPP EPC/IMS.
> 
> 
> 
> <---------------------------> 
> DeWayne Sennett, AT&T Services, Inc. 
> Sent from my BlackBerry
> 
> From: earlywarning-bounces@ietf.org <earlywarning-bounces@ietf.org> 
> To: keith.drage@alcatel-lucent.com <keith.drage@alcatel-lucent.com>; br@brianrosen.net <br@brianrosen.net>; earlywarning@ietf.org <earlywarning@ietf.org> 
> Sent: Thu Mar 25 17:43:10 2010
> Subject: Re: [earlywarning] (no subject) 
> 
> Keith
> 
> You bring up a good point - we don't want to design a solution that will result in failure of the network, therefore I second DeWayne's proposal to exclude from the charter devices that support PWS (and CMAS under that umbrella) and to acknowledge this solution may result in network problems (e.g. Congestion).
> 
> Brian Daly 
> Brian K. Daly 
> ------- 
> Sent from my Blackberry
> 
> From: DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com> 
> To: Brian Rosen <br@brianrosen.net>; DALY, BRIAN K (ATTCINW); earlywarning@ietf.org <earlywarning@ietf.org> 
> Sent: Thu Mar 25 17:35:30 2010
> Subject: RE: [earlywarning] (no subject) 
> 
> Yes those cellphones could well be connected to the internet.
> 
> But cell broadcast service exists on 3GPP phones. For alerts that are intended to hit a large proportion of the phones in any cell, it makes best use of the bandwidth.
> 
> You bring up an IP connection to all cellphones in that cell, and then broadcast warnings to all those cells, and the net result will be inappropriate loading of cells specifically for this traffic. Given that such warnings may otherwise create network stress as a result of the public warning being made in the first place, the first point of call for getting such warnings to cellphone uses has to be cell broadcast.
> 
> It appears that many governmental organisations have accepted cell broadcast as the desired means of delivering public warnings to cellphones.
> 
> Therefore any IETF activity has to acknowledge that solution exists for cellphones. 
> 
> Further I believe that any IETF solution has to specifically NOT convey the impression that for cellphones, the IETF solution is a good way forward for the warning itself. Users could well find the warnings from the IETF solution to an IP endpoint delivered well after the cell broadcast warning. And certainly the IETF solution should not expect priority over other types of traffic at that point, because at cell broadcast channel already exists to give that priority for the appropriate type of traffic.
> 
> regards
> 
> Keith
> 
> 
>  
> From: earlywarning-bounces@ietf.org  [mailto:earlywarning-bounces@ietf.org] On Behalf Of Brian  Rosen
> Sent: Friday, March 26, 2010 12:00 AM
> To: DALY,  BRIAN K (ATTCINW); earlywarning@ietf.org
> Subject: Re: [earlywarning]  (no subject)
> 
>  
> Are they connected to the Internet?
> 
> If they  are, it would apply.  If they aren’t, then it wouldn’t  apply.
> 
> Brian
> 
> 
> On 3/25/10 7:51 PM, "DALY, BRIAN K (ATTCINW)"  <BD2985@att.com>  wrote:
> 
>  
> That will not apply to devices  connected to wireless cellular  networks.
>  
> 
> From: Brian Rosen [mailto:br@brianrosen.net]  
> Sent: Thursday, March 25, 2010 4:50 PM
> To: DALY, BRIAN  K (ATTCINW); earlywarning@ietf.org
> Subject:  Re: [earlywarning] (no subject)
> 
> 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.com>
>       
> 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