From Martin.Thomson@commscope.com Mon Aug 1 16:33:42 2011 Return-Path: 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 9FAF011E8077 for ; Mon, 1 Aug 2011 16:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbed6vb5vzMy for ; Mon, 1 Aug 2011 16:33:42 -0700 (PDT) Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id DEFD411E8150 for ; Mon, 1 Aug 2011 16:33:38 -0700 (PDT) X-AuditID: 0a0404e9-b7c09ae000007724-e8-4e3737e2e2f1 Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id EF.63.30500.2E7373E4; Mon, 1 Aug 2011 18:33:55 -0500 (CDT) Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 1 Aug 2011 18:33:45 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 2 Aug 2011 07:33:40 +0800 From: "Thomson, Martin" To: "atoca@ietf.org" Date: Tue, 2 Aug 2011 07:33:40 +0800 Thread-Topic: ATOCA draft minutes Thread-Index: AcxO/Ekigbtrrs29Swu2InuAFc3Jyw== Message-ID: <8B0A9FCBB9832F43971E38010638454F040D45B4AA@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [atoca] ATOCA draft minutes 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 23:33:42 -0000 I put together these notes on the plane home. Let me know if I missed anyt= hing obvious. --Martin ~~ ATOCA, IETF 81, Quebec 1. Chairs presented working group status. Working group has been dormant s= ince the last meeting. 2. Chairs presented a plan for working group progress. Work on requirement= s and architecture will be delegated to a small group of volunteers who wil= l produce a draft. This draft, plus some progress on the solution, will be= presented at a virtual interim in September. Initial drafts for each of t= he pieces of the solution will be prepared for the November meeting in Taip= ei. The team will include Brian Rosen; Hannes Tschofenig; Richard Barnes; James= Polk; Matt Miller and Dave CROCKER 3. Brian Rosen led a discussion on architecture. Some better understanding= of the issues was reached. Discussion focused on the separation between "distribution" and "broadcast"= concept - or author to N-1 and "last mile". (Some skepticism was expresse= d on whether these are the best choice of terms.) For the "last mile/broadcast" mention was made of using network native mech= anisms. Cell broadcast in 3GPP networks was the most obvious example, but = Gabor Bajko gave a brief description of the work that IEEE has done on WiFi= alert distribution, which is near completion. Martin Thomson observed tha= t heterogeneous networks will mean that alert distribution using native mec= hanisms might face some challenges. Mention was made of the absence of any security requirements in the current= requirements draft and Hannes noted that the threat model was not document= ed. Hannes agreed to work on improving the thread model. ~~ Thanks to Keping Li and Linyi Tian for their assistance in taking notes. K= eping's notes follow. ~~ Here is the brief minutes: =20 ATOCA, IETF 81 Administrivia Chairs 5 =20 Status Chairs 10 Requirement: Architecture: Requirement document and architecture document can be combined together.=20 =20 Distribution: Distribution needs to be changed to a better name. There are no clean case for "school closure". =20 Broadcast: ISP is location constrained. =20 Security: It is a difficult problem. =20 Conclusion: Plan to have a vritual interim meeting Middle in Sep, 2011. Will use poll t= o set up this meeting. Have Hennes, David, Brian, Richard, James Polk in the design team. Work on = the three or four drafts by the interim. Get something more concerete for the next F2F meeting to discuss. =20 Requirements Discussion: draft-ietf-atoca-requirements, Hannes 30 Not discussed due to the lack of time. =20 Spare 15 From Martin.Thomson@commscope.com Mon Aug 8 19:59:25 2011 Return-Path: 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 4F81D21F8AF1 for ; Mon, 8 Aug 2011 19:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] 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 jg+y8J8uABUH for ; Mon, 8 Aug 2011 19:59:24 -0700 (PDT) Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id 812D921F8AE9 for ; Mon, 8 Aug 2011 19:59:21 -0700 (PDT) X-AuditID: 0a0404e9-b7b99ae000002f72-92-4e40a2ade279 Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id FE.A5.12146.DA2A04E4; Mon, 8 Aug 2011 21:59:58 -0500 (CDT) Received: from CDCE10HC2.commscope.com (10.86.28.22) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 8 Aug 2011 21:59:48 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by CDCE10HC2.commscope.com (10.86.28.22) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 8 Aug 2011 21:59:48 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Tue, 9 Aug 2011 10:59:43 +0800 From: "Thomson, Martin" To: "atoca@ietf.org" Date: Tue, 9 Aug 2011 10:59:41 +0800 Thread-Topic: Virtual Interim: Poll Thread-Index: AcxOwBCqvE4fEO3+S8ieXdw/QflOzQHgAsoQ Message-ID: <8B0A9FCBB9832F43971E38010638454F040D45BCCA@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F040D2C3AC7@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F040D2C3AC7@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [atoca] Virtual Interim: Poll 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 02:59:25 -0000 Last call. I'm going to close this poll tomorrow. =20 Right now, the call is most likely to be at 20:00 GMT on the 13th or 15th. On 2011-07-30 at 23:53:30, Thomson, Martin wrote: > As discussed in the meeting, we're planning to have a virtual interim=20 > meeting [*] in September. >=20 > If you would like to attend, please indicate your availability. >=20 > http://www.doodle.com/bsa88787q3rhzd6e From Martin.Thomson@commscope.com Mon Aug 8 20:31:19 2011 Return-Path: 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 543C111E808F for ; Mon, 8 Aug 2011 20:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] 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 gaigB6ieO7KI for ; Mon, 8 Aug 2011 20:31:18 -0700 (PDT) Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id 277D311E8081 for ; Mon, 8 Aug 2011 20:31:18 -0700 (PDT) X-AuditID: 0a0404e9-b7b99ae000002f72-f7-4e40aa2a4929 Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id D1.16.12146.A2AA04E4; Mon, 8 Aug 2011 22:31:54 -0500 (CDT) Received: from CDCE10HC1.commscope.com (10.86.28.21) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 8 Aug 2011 22:31:45 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by CDCE10HC1.commscope.com (10.86.28.21) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 8 Aug 2011 22:31:44 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 9 Aug 2011 11:31:42 +0800 From: "Thomson, Martin" To: "trutkowski@netmagic.com" Date: Tue, 9 Aug 2011 11:31:40 +0800 Thread-Topic: [atoca] geo-specificity. Thread-Index: AcxNRMmLhnEOyVyjSa6u9ZtsMwAi6gI/ZlUA Message-ID: <8B0A9FCBB9832F43971E38010638454F040D45BCD4@SISPE7MB1.commscope.com> References: <20110728155350.E56A121F8C5A@ietfa.amsl.com> <4E319069.7050908@netmagic.com> In-Reply-To: <4E319069.7050908@netmagic.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "atoca@ietf.org" Subject: Re: [atoca] geo-specificity. 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 03:31:19 -0000 Thanks Tony, The Beidou slide set was particularly interesting. I'm now going to have t= o see if a similar capability is likely to be possible for GPS (though not = in L1) and Galileo. Also of interest to this group. Atom + CAP is being deployed: http://www.ga.gov.au/earthquakes/staticPageController.do?page=3Deq-notifica= tion-service --Martin On 2011-07-29 at 02:38:01, Tony Rutkowski wrote: > A good overview of geolocation tagging needs and mechanisms can be=20 > gleaned from the April global CAP implementers workshop hosted by the=20 > WMO http://www.wmo.int/pages/prog/www/ISS/Meetings/WIS- > CAP_Geneva2011/DocPlan.html >=20 > At the event, clever geo-tagging implementations by both Beidou and=20 > Google were described. >=20 > The use of OIDs for some of these purposes in the allotted alerting=20 > arc > 2.49 and in conjunction with the DNS based OID resolution system was=20 > also described there. Because OIDs are also embedded in digital certs=20 > and network elements, they can be further exploited for needed=20 > geotagging. >=20 > --tony >=20 > On 7/28/2011 11:53 AM, Mark wrote: > > The more geo specific a message is, the more utility is has,=20 > > especially down to very local jurisdictional levels where, which=20 > > side > of the street matters. > > Since a CAP message has a polygon with it, there is not much problem=20 > > in using that as a very specific geo location parameter. > > >=20 > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From randy@qualcomm.com Mon Aug 8 22:22:46 2011 Return-Path: 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 1A2FF21F8AF3 for ; Mon, 8 Aug 2011 22:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.553 X-Spam-Level: X-Spam-Status: No, score=-106.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 zUdKvkK2ohu4 for ; Mon, 8 Aug 2011 22:22:45 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 7724721F8AF1 for ; Mon, 8 Aug 2011 22:22:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1312867393; x=1344403393; h=message-id:in-reply-to:references:x-mailer:date:to:from: subject:mime-version:content-type:x-random-sig-tag: x-originating-ip; z=Message-ID:=20 |In-Reply-To:=20<8B0A9FCBB9832F43971E38010638454F040D45BC CA@SISPE7MB1.commscope.com>|References:=20<8B0A9FCBB9832F 43971E38010638454F040D2C3AC7@SISPE7MB1.commscope.com>=0D =0A=20<8B0A9FCBB9832F43971E38010638454F040D45BCCA@SISPE7M B1.commscope.com>|X-Mailer:=20Eudora=20for=20Mac=20OS=20X |Date:=20Mon,=208=20Aug=202011=2022:18:57=20-0700|To:=20" Thomson,=20Martin"=20,=20"a toca@ietf.org"=0D=0A=09|From:=20Randall =20Gellens=20|Subject:=20Re:=20[atoca ]=20Virtual=20Interim:=20Poll|MIME-Version:=201.0 |Content-Type:=20text/plain=3B=20charset=3D"us-ascii"=3B =20format=3Dflowed|X-Random-Sig-Tag:=201.0b28 |X-Originating-IP:=20[172.30.48.1]; bh=obO13I6n+D3BOUmsBWjVhdUl0nWPe42xQ3ViTdRuBUc=; b=OXmckNdC1Z+vTrtDJl2hg/wKIs6MMpmZyYXwMwV3Bt6iDRdJot30vlZ4 O0QCYVXnqwc6JWqFySmxY98Dt5VjrZqrTHGJtnf5klvhxlavENM5vLl7G m36VbRO3wdT8QtRn/JSZHSs9Ll/Kw8KqeYpOvG/Z8ubxuxaJzeFubkC11 k=; X-IronPort-AV: E=McAfee;i="5400,1158,6432"; a="108769946" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP; 08 Aug 2011 22:23:12 -0700 X-IronPort-AV: E=Sophos;i="4.67,340,1309762800"; d="scan'208";a="97056082" Received: from nasanexhc05.na.qualcomm.com ([172.30.48.2]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 08 Aug 2011 22:23:12 -0700 Received: from loud.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.1.323.0; Mon, 8 Aug 2011 22:23:11 -0700 Message-ID: In-Reply-To: <8B0A9FCBB9832F43971E38010638454F040D45BCCA@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F040D2C3AC7@SISPE7MB1.commscope.com> <8B0A9FCBB9832F43971E38010638454F040D45BCCA@SISPE7MB1.commscope.com> X-Mailer: Eudora for Mac OS X Date: Mon, 8 Aug 2011 22:18:57 -0700 To: "Thomson, Martin" , "atoca@ietf.org" From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.48.1] Subject: Re: [atoca] Virtual Interim: Poll 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 05:22:46 -0000 At 10:59 AM +0800 8/9/11, Martin Thomson wrote: > Last call. I'm going to close this poll tomorrow. > > Right now, the call is most likely to be at 20:00 GMT on the 13th or 15th. It would be nice to offer a few more options, such as September 19th. Also, other time slots, such as 6:00 PM UTC. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The fewer episodes of a TV show one has seen, the greater the chance that one has already viewed the episode one is watching. --Randall Gellens From Martin.Thomson@commscope.com Mon Aug 8 22:31:59 2011 Return-Path: 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 C24FB21F873A for ; Mon, 8 Aug 2011 22:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] 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 lPDUgK--gAFZ for ; Mon, 8 Aug 2011 22:31:59 -0700 (PDT) Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id DA3CF21F8726 for ; Mon, 8 Aug 2011 22:31:58 -0700 (PDT) X-AuditID: 0a0404e9-b7b99ae000002f72-70-4e40c67398ed Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id 08.77.12146.376C04E4; Tue, 9 Aug 2011 00:32:35 -0500 (CDT) Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.159.2; Tue, 9 Aug 2011 00:32:25 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Tue, 9 Aug 2011 13:32:21 +0800 From: "Thomson, Martin" To: Randall Gellens , "atoca@ietf.org" Date: Tue, 9 Aug 2011 13:32:19 +0800 Thread-Topic: [atoca] Virtual Interim: Poll Thread-Index: AcxWVHCef0tuNfb6S3C8DLoy7V7rjAAABwQw Message-ID: <8B0A9FCBB9832F43971E38010638454F040D45BD0F@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F040D2C3AC7@SISPE7MB1.commscope.com> <8B0A9FCBB9832F43971E38010638454F040D45BCCA@SISPE7MB1.commscope.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [atoca] Virtual Interim: Poll 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 05:31:59 -0000 On 2011-08-09 at 15:18:57, Randall Gellens wrote: > At 10:59 AM +0800 8/9/11, Martin Thomson wrote: >=20 > > Last call. I'm going to close this poll tomorrow. > > It would be nice to offer a few more options, such as September 19th. > Also, other time slots, such as 6:00 PM UTC. I'll keep that in mind for next time. It's a bit late for this time 'round= . --Martin From Martin.Thomson@commscope.com Wed Aug 10 18:06:19 2011 Return-Path: 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 CDCE711E8092 for ; Wed, 10 Aug 2011 18:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] 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 cix5WWikEIzj for ; Wed, 10 Aug 2011 18:06:19 -0700 (PDT) Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id F2A7D11E8094 for ; Wed, 10 Aug 2011 18:06:18 -0700 (PDT) X-AuditID: 0a0404e8-b7cb4ae000004e51-8b-4e432b38d126 Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id 90.BB.20049.83B234E4; Wed, 10 Aug 2011 20:07:04 -0500 (CDT) Received: from CDCE10HC1.commscope.com (10.86.28.21) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.159.2; Wed, 10 Aug 2011 20:06:51 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by CDCE10HC1.commscope.com (10.86.28.21) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 10 Aug 2011 20:06:51 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Thu, 11 Aug 2011 09:06:47 +0800 From: "Thomson, Martin" To: "atoca@ietf.org" Date: Thu, 11 Aug 2011 09:06:45 +0800 Thread-Topic: Virtual Interim: Poll Thread-Index: AcxOwBCqvE4fEO3+S8ieXdw/QflOzQHgAsoQAGCCuOA= Message-ID: <8B0A9FCBB9832F43971E38010638454F040D45BF11@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F040D2C3AC7@SISPE7MB1.commscope.com> <8B0A9FCBB9832F43971E38010638454F040D45BCCA@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F040D45BCCA@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [atoca] Virtual Interim: Poll 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 01:06:19 -0000 The poll is closed. I'm going to request that the secretariat schedule a call for 1 hour on the= 13th of September at 20:00 UTC. Expect a formal announcement in due cours= e. Apologies to those for whom this time is inconvenient or impossible. On 2011-08-09 at 12:59:41, Thomson, Martin wrote: > Last call. I'm going to close this poll tomorrow. >=20 > Right now, the call is most likely to be at 20:00 GMT on the 13th or=20 > 15th. >=20 > On 2011-07-30 at 23:53:30, Thomson, Martin wrote: > > As discussed in the meeting, we're planning to have a virtual=20 > > interim meeting [*] in September. > > > > If you would like to attend, please indicate your availability. > > > > http://www.doodle.com/bsa88787q3rhzd6e >=20 >=20 > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From Martin.Thomson@commscope.com Thu Aug 11 16:13:50 2011 Return-Path: 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 D3BD021F8A71 for ; Thu, 11 Aug 2011 16:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] 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 6OpEe9N0OYAU for ; Thu, 11 Aug 2011 16:13:50 -0700 (PDT) Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id 3E59521F8A6C for ; Thu, 11 Aug 2011 16:13:50 -0700 (PDT) X-AuditID: 0a0404e9-b7b99ae000002f72-38-4e44625ac8d2 Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id 9F.30.12146.A52644E4; Thu, 11 Aug 2011 18:14:35 -0500 (CDT) Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 11 Aug 2011 18:14:25 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Fri, 12 Aug 2011 07:14:20 +0800 From: "Thomson, Martin" To: "atoca@ietf.org" Date: Fri, 12 Aug 2011 07:14:18 +0800 Thread-Topic: [Atoca] ATOCA WG Virtual Interim Meeting: September 13, 2011 Thread-Index: AcxYbFQtoDYcyYtfSqGnaGBPFBbZIwAEAkzA Message-ID: <8B0A9FCBB9832F43971E38010638454F040D45C06E@SISPE7MB1.commscope.com> References: <20110811211825.365D421F8B23@ietfa.amsl.com> In-Reply-To: <20110811211825.365D421F8B23@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [atoca] [Atoca] ATOCA WG Virtual Interim Meeting: September 13, 2011 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 23:13:51 -0000 FYI. This went to the wrong list. On 2011-08-12 at 07:18:25, IESG Secretary wrote: > The ATOCA WG will hold an interim virtual meeting on: > 2011-09-13 at 20:00 UTC (1pm US west coast). >=20 > Agenda and details will be announced on the ATOCA mailing list > (http://www.ietf.org/mail-archive/web/earlywarning) in due course. >=20 > _______________________________________________ > earlywarning mailing list > earlywarning@ietf.org > https://www.ietf.org/mailman/listinfo/earlywarning From wwwrun@ietfa.amsl.com Fri Aug 12 08:44:48 2011 Return-Path: X-Original-To: atoca@ietf.org Delivered-To: atoca@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id BA81221F880C; Fri, 12 Aug 2011 08:44:43 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110812154448.BA81221F880C@ietfa.amsl.com> Date: Fri, 12 Aug 2011 08:44:43 -0700 (PDT) Cc: atoca@ietf.org Subject: [atoca] UPDATED ATOCA WG Virtual Interim Meeting: September 13, 2011 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 15:44:48 -0000 The ATOCA WG will hold an interim virtual meeting on: 2011-09-13 at 20:00 UTC (1pm US west coast). Agenda and details will be announced on the ATOCA mailing list (http://www.ietf.org/mail-archive/web/atoca/current/maillist.html) in due course. From dhc2@dcrocker.net Fri Aug 12 10:21:07 2011 Return-Path: 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 5D8FE21F874F for ; Fri, 12 Aug 2011 10:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.705 X-Spam-Level: X-Spam-Status: No, score=-5.705 tagged_above=-999 required=5 tests=[AWL=0.894, 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 LfcnL1jSWa1B for ; Fri, 12 Aug 2011 10:21:06 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id A470221F8745 for ; Fri, 12 Aug 2011 10:21:06 -0700 (PDT) Received: from [192.168.1.156] (adsl-68-122-69-114.dsl.pltn13.pacbell.net [68.122.69.114]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p7CHLbnL022311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 12 Aug 2011 10:21:44 -0700 Message-ID: <4E456120.1020903@dcrocker.net> Date: Fri, 12 Aug 2011 10:21:36 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: atoca@ietf.org References: <20110812154448.BA81221F880C@ietfa.amsl.com> In-Reply-To: <20110812154448.BA81221F880C@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 12 Aug 2011 10:21:44 -0700 (PDT) Subject: Re: [atoca] UPDATED ATOCA WG Virtual Interim Meeting: September 13, 2011 X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 17:21:07 -0000 On 8/12/2011 8:44 AM, IESG Secretary wrote: > The ATOCA WG will hold an interim virtual meeting on: > 2011-09-13 at 20:00 UTC (1pm US west coast). This timing seems to preclude participation from Asia. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From rbarnes@bbn.com Fri Aug 12 10:26:22 2011 Return-Path: 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 D7A7511E8088 for ; Fri, 12 Aug 2011 10:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.541 X-Spam-Level: X-Spam-Status: No, score=-106.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 ecHRMhnuLivc for ; Fri, 12 Aug 2011 10:26:22 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id BFA8B11E8083 for ; Fri, 12 Aug 2011 10:26:19 -0700 (PDT) Received: from [192.1.255.224] (port=51898 helo=col-dhcp-192-1-255-224.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QrvVY-000DXK-8f; Fri, 12 Aug 2011 13:26:56 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <4E456120.1020903@dcrocker.net> Date: Fri, 12 Aug 2011 13:26:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <68FF9FD6-A398-40DD-AAF5-EBEA9C3FB4EA@bbn.com> References: <20110812154448.BA81221F880C@ietfa.amsl.com> <4E456120.1020903@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1082) Cc: atoca@ietf.org Subject: Re: [atoca] UPDATED ATOCA WG Virtual Interim Meeting: September 13, 2011 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 17:26:23 -0000 Doesn't preclude, just means they have to stay up late. Do you have a = time in mind that isn't inconvenient on some continent? I don't think = the Pacific ocean is quite wide enough for that. --Richard On Aug 12, 2011, at 1:21 PM, Dave CROCKER wrote: >=20 >=20 > On 8/12/2011 8:44 AM, IESG Secretary wrote: >> The ATOCA WG will hold an interim virtual meeting on: >> 2011-09-13 at 20:00 UTC (1pm US west coast). >=20 >=20 > This timing seems to preclude participation from Asia. >=20 > d/ >=20 > --=20 >=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From rbarnes@bbn.com Fri Aug 12 11:29:59 2011 Return-Path: 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 0F18F11E808F for ; Fri, 12 Aug 2011 11:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.545 X-Spam-Level: X-Spam-Status: No, score=-106.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 0-d7PBOeVaPz for ; Fri, 12 Aug 2011 11:29:58 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 691B211E808B for ; Fri, 12 Aug 2011 11:29:58 -0700 (PDT) Received: from [192.1.255.224] (port=52198 helo=col-dhcp-192-1-255-224.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QrwV9-000ERm-SF; Fri, 12 Aug 2011 14:30:35 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <4E4563C1.1080509@bbiw.net> Date: Fri, 12 Aug 2011 14:30:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <73453140-3BA5-45CA-A885-0AA6DF0857EB@bbn.com> References: <20110812154448.BA81221F880C@ietfa.amsl.com> <4E456120.1020903@dcrocker.net> <68FF9FD6-A398-40DD-AAF5-EBEA9C3FB4EA@bbn.com> <4E4563C1.1080509@bbiw.net> To: Dave CROCKER X-Mailer: Apple Mail (2.1082) Cc: atoca@ietf.org Subject: Re: [atoca] UPDATED ATOCA WG Virtual Interim Meeting: September 13, 2011 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 18:29:59 -0000 Given that our esteemed chair is based on the east coast of Australia, I = guess we're out of luck :) --Richard On Aug 12, 2011, at 1:32 PM, Dave CROCKER wrote: >=20 >=20 > On 8/12/2011 10:26 AM, Richard L. Barnes wrote: >> Doesn't preclude, just means they have to stay up late. Do you have = a time >> in mind that isn't inconvenient on some continent? I don't think the = Pacific >> ocean is quite wide enough for that. >=20 >=20 > Participation by anyone in Australia or Hawaii destroys any reasonable = model. >=20 > Short of that, a start time of roughly 7am pacific is more typical, so = that East Asia participants get start time of around 11pm. >=20 > I'm on pacific time, so I'm making a suggestion against my own = self-interest, of course. >=20 > If indeed, there's no atoca participation from Asia, this is an = academic point, which is why I posted my note as a question. >=20 > d/ >=20 > --=20 >=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net From dcrocker@bbiw.net Fri Aug 12 10:32:23 2011 Return-Path: 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 A2BD321F84FC for ; Fri, 12 Aug 2011 10:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.342 X-Spam-Level: X-Spam-Status: No, score=-5.342 tagged_above=-999 required=5 tests=[AWL=1.257, 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 gWj21jWFYv6c for ; Fri, 12 Aug 2011 10:32:23 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id F263721F851A for ; Fri, 12 Aug 2011 10:32:22 -0700 (PDT) Received: from [192.168.1.156] (adsl-68-122-69-114.dsl.pltn13.pacbell.net [68.122.69.114]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p7CHWoJd022553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Aug 2011 10:32:55 -0700 Message-ID: <4E4563C1.1080509@bbiw.net> Date: Fri, 12 Aug 2011 10:32:49 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Richard L. Barnes" References: <20110812154448.BA81221F880C@ietfa.amsl.com> <4E456120.1020903@dcrocker.net> <68FF9FD6-A398-40DD-AAF5-EBEA9C3FB4EA@bbn.com> In-Reply-To: <68FF9FD6-A398-40DD-AAF5-EBEA9C3FB4EA@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 12 Aug 2011 10:32:55 -0700 (PDT) X-Mailman-Approved-At: Sun, 14 Aug 2011 16:37:09 -0700 Cc: atoca@ietf.org Subject: Re: [atoca] UPDATED ATOCA WG Virtual Interim Meeting: September 13, 2011 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 17:32:23 -0000 On 8/12/2011 10:26 AM, Richard L. Barnes wrote: > Doesn't preclude, just means they have to stay up late. Do you have a time > in mind that isn't inconvenient on some continent? I don't think the Pacific > ocean is quite wide enough for that. Participation by anyone in Australia or Hawaii destroys any reasonable model. Short of that, a start time of roughly 7am pacific is more typical, so that East Asia participants get start time of around 11pm. I'm on pacific time, so I'm making a suggestion against my own self-interest, of course. If indeed, there's no atoca participation from Asia, this is an academic point, which is why I posted my note as a question. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From rjsparks@nostrum.com Mon Aug 15 12:14:12 2011 Return-Path: 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 15E7F11E80E2 for ; Mon, 15 Aug 2011 12:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 MVTdg641PUN9 for ; Mon, 15 Aug 2011 12:14:11 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6720911E80D7 for ; Mon, 15 Aug 2011 12:14:11 -0700 (PDT) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p7FJEfvh014506 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 15 Aug 2011 14:14:44 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Robert Sparks In-Reply-To: <73453140-3BA5-45CA-A885-0AA6DF0857EB@bbn.com> Date: Mon, 15 Aug 2011 14:14:40 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7040A19B-FD11-4103-8333-84AF83E2E16B@nostrum.com> References: <20110812154448.BA81221F880C@ietfa.amsl.com> <4E456120.1020903@dcrocker.net> <68FF9FD6-A398-40DD-AAF5-EBEA9C3FB4EA@bbn.com> <4E4563C1.1080509@bbiw.net> <73453140-3BA5-45CA-A885-0AA6DF0857EB@bbn.com> To: "Richard L. Barnes" X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: atoca@ietf.org, Dave CROCKER Subject: Re: [atoca] UPDATED ATOCA WG Virtual Interim Meeting: September 13, 2011 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 19:14:12 -0000 What's the expected duration of this call? RjS On Aug 12, 2011, at 1:30 PM, Richard L. Barnes wrote: > Given that our esteemed chair is based on the east coast of Australia, = I guess we're out of luck :) >=20 > --Richard >=20 >=20 > On Aug 12, 2011, at 1:32 PM, Dave CROCKER wrote: >=20 >>=20 >>=20 >> On 8/12/2011 10:26 AM, Richard L. Barnes wrote: >>> Doesn't preclude, just means they have to stay up late. Do you have = a time >>> in mind that isn't inconvenient on some continent? I don't think = the Pacific >>> ocean is quite wide enough for that. >>=20 >>=20 >> Participation by anyone in Australia or Hawaii destroys any = reasonable model. >>=20 >> Short of that, a start time of roughly 7am pacific is more typical, = so that East Asia participants get start time of around 11pm. >>=20 >> I'm on pacific time, so I'm making a suggestion against my own = self-interest, of course. >>=20 >> If indeed, there's no atoca participation from Asia, this is an = academic point, which is why I posted my note as a question. >>=20 >> d/ >>=20 >> --=20 >>=20 >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >=20 > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From Martin.Thomson@commscope.com Mon Aug 15 16:03:44 2011 Return-Path: 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 5238411E8089 for ; Mon, 15 Aug 2011 16:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] 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 MKU8uyBTTJ2b for ; Mon, 15 Aug 2011 16:03:43 -0700 (PDT) Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id 995B711E8086 for ; Mon, 15 Aug 2011 16:03:43 -0700 (PDT) X-AuditID: 0a0404e8-b7cb4ae000004e51-47-4e49a607be84 Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id AF.75.20049.706A94E4; Mon, 15 Aug 2011 18:04:39 -0500 (CDT) Received: from CDCE10HC2.commscope.com (10.86.28.22) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 15 Aug 2011 18:04:26 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by CDCE10HC2.commscope.com (10.86.28.22) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 15 Aug 2011 18:04:25 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 16 Aug 2011 07:04:22 +0800 From: "Thomson, Martin" To: Robert Sparks , "Richard L. Barnes" Date: Tue, 16 Aug 2011 07:04:20 +0800 Thread-Topic: [atoca] UPDATED ATOCA WG Virtual Interim Meeting: September 13, 2011 Thread-Index: Acxbf6PtY8lSLgf0RR6u3UW7tThhUQAH/VAA Message-ID: <8B0A9FCBB9832F43971E38010638454F040D45C32B@SISPE7MB1.commscope.com> References: <20110812154448.BA81221F880C@ietfa.amsl.com> <4E456120.1020903@dcrocker.net> <68FF9FD6-A398-40DD-AAF5-EBEA9C3FB4EA@bbn.com> <4E4563C1.1080509@bbiw.net> <73453140-3BA5-45CA-A885-0AA6DF0857EB@bbn.com> <7040A19B-FD11-4103-8333-84AF83E2E16B@nostrum.com> In-Reply-To: <7040A19B-FD11-4103-8333-84AF83E2E16B@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "atoca@ietf.org" , Dave CROCKER Subject: Re: [atoca] UPDATED ATOCA WG Virtual Interim Meeting: September 13, 2011 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 23:03:44 -0000 Apologies, I forgot to add that to my request of the secretariat. The plan= was to take no more than an hour. --Martin On 2011-08-16 at 05:14:40, Robert Sparks wrote: > What's the expected duration of this call? >=20 > RjS >=20 > On Aug 12, 2011, at 1:30 PM, Richard L. Barnes wrote: >=20 > > Given that our esteemed chair is based on the east coast of > Australia, > > I guess we're out of luck :) > > > > --Richard > > > > > > On Aug 12, 2011, at 1:32 PM, Dave CROCKER wrote: > > > >> > >> > >> On 8/12/2011 10:26 AM, Richard L. Barnes wrote: > >>> Doesn't preclude, just means they have to stay up late. Do you > have > >>> a time in mind that isn't inconvenient on some continent? I don't=20 > >>> think the Pacific ocean is quite wide enough for that. > >> > >> > >> Participation by anyone in Australia or Hawaii destroys any > reasonable model. > >> > >> Short of that, a start time of roughly 7am pacific is more typical, > so that East Asia participants get start time of around 11pm. > >> > >> I'm on pacific time, so I'm making a suggestion against my own=20 > >> self- > interest, of course. > >> > >> If indeed, there's no atoca participation from Asia, this is an > academic point, which is why I posted my note as a question. > >> > >> d/ > >> > >> -- > >> > >> Dave Crocker > >> Brandenburg InternetWorking > >> bbiw.net > > > > _______________________________________________ > > atoca mailing list > > atoca@ietf.org > > https://www.ietf.org/mailman/listinfo/atoca >=20 > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From rbarnes@bbn.com Mon Aug 22 08:54:10 2011 Return-Path: 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 DDC0E21F8BB0 for ; Mon, 22 Aug 2011 08:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.359 X-Spam-Level: X-Spam-Status: No, score=-105.359 tagged_above=-999 required=5 tests=[AWL=-1.174, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 opf9Agn7fN-0 for ; Mon, 22 Aug 2011 08:54:09 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id B59D521F8BAE for ; Mon, 22 Aug 2011 08:54:06 -0700 (PDT) Received: from dhcp89-089-029.bbn.com ([128.89.89.29]:62258) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QvWqF-0000Ej-KD for atoca@ietf.org; Mon, 22 Aug 2011 11:55:11 -0400 From: "Richard L. Barnes" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Aug 2011 11:55:11 -0400 Message-Id: <3E657A6F-E37D-4F71-9F81-AE99D987F1C6@bbn.com> To: atoca@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [atoca] iOS 5 tied into Japanese early warning system 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 15:54:11 -0000 Apparently the new version of iOS 5 is capable of receiving alerts from = the Japanese earthquake alert system. It also comes with a warning that = maintaining a connection to the alert system will reduce battery life. = Anyone know any details of how this works? = = From bd2985@att.com Mon Aug 22 08:55:30 2011 Return-Path: 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 E186621F85B9 for ; Mon, 22 Aug 2011 08:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 gJPrRo9gCg-y for ; Mon, 22 Aug 2011 08:55:30 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 606FC21F85B5 for ; Mon, 22 Aug 2011 08:55:30 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: bd2985@att.com X-Msg-Ref: server-6.tower-120.messagelabs.com!1314028594!26255649!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [144.160.112.25] Received: (qmail 29563 invoked from network); 22 Aug 2011 15:56:34 -0000 Received: from sbcsmtp3.sbc.com (HELO tlph064.enaf.dadc.sbc.com) (144.160.112.25) by server-6.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Aug 2011 15:56:34 -0000 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by tlph064.enaf.dadc.sbc.com (8.14.4/8.14.4) with ESMTP id p7MFuXl8000885; Mon, 22 Aug 2011 10:56:34 -0500 Received: from WABOTH9MSGHUB8D.ITServices.sbc.com (waboth9msghub8d.itservices.sbc.com [135.163.35.93]) by tlph064.enaf.dadc.sbc.com (8.14.4/8.14.4) with ESMTP id p7MFuQIi032737 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Aug 2011 10:56:27 -0500 Received: from WABOTH9MSGUSR8B.ITServices.sbc.com ([169.254.2.17]) by WABOTH9MSGHUB8D.ITServices.sbc.com ([135.163.35.93]) with mapi id 14.01.0289.001; Mon, 22 Aug 2011 08:56:12 -0700 From: "DALY, BRIAN K (ATTSI)" To: "Richard L. Barnes" , "atoca@ietf.org" Thread-Topic: [atoca] iOS 5 tied into Japanese early warning system Thread-Index: AQHMYOPf1yIfviBd6EKxcUMKfRxZBpUpBhuw Date: Mon, 22 Aug 2011 15:56:11 +0000 Message-ID: <95C5C7A891135E4685CCFAE997351F961F51EE@WABOTH9MSGUSR8B.ITServices.sbc.com> References: <3E657A6F-E37D-4F71-9F81-AE99D987F1C6@bbn.com> In-Reply-To: <3E657A6F-E37D-4F71-9F81-AE99D987F1C6@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.163.34.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [atoca] iOS 5 tied into Japanese early warning system 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 15:55:31 -0000 It is standard GSM cell broadcast. ETWS is standardized as part of the 3GPP= PWS feature. -------- Brian K. Daly Director, Core Network & Govn't/Regulatory Standards AT&T Services, Inc. +1.425.580.6873 brian.k.daly@att.com Rethink Possible -----Original Message----- From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of R= ichard L. Barnes Sent: Monday, August 22, 2011 8:55 AM To: atoca@ietf.org Subject: [atoca] iOS 5 tied into Japanese early warning system Apparently the new version of iOS 5 is capable of receiving alerts from the= Japanese earthquake alert system. It also comes with a warning that maint= aining a connection to the alert system will reduce battery life. Anyone k= now any details of how this works? _______________________________________________ atoca mailing list atoca@ietf.org https://www.ietf.org/mailman/listinfo/atoca From keith.drage@alcatel-lucent.com Mon Aug 22 08:57:34 2011 Return-Path: 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 39D6021F85EC for ; Mon, 22 Aug 2011 08:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.863 X-Spam-Level: X-Spam-Status: No, score=-103.863 tagged_above=-999 required=5 tests=[AWL=-1.614, BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] 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 ZO3cRvIqTaoJ for ; Mon, 22 Aug 2011 08:57:33 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 64F0B21F85C4 for ; Mon, 22 Aug 2011 08:57:33 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p7MFwSIi004059 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 22 Aug 2011 17:58:28 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Mon, 22 Aug 2011 17:58:28 +0200 From: "DRAGE, Keith (Keith)" To: "DALY, BRIAN K (ATTSI)" , "Richard L. Barnes" , "atoca@ietf.org" Date: Mon, 22 Aug 2011 17:58:25 +0200 Thread-Topic: [atoca] iOS 5 tied into Japanese early warning system Thread-Index: AQHMYOPf1yIfviBd6EKxcUMKfRxZBpUpBhuwgAAAkcA= Message-ID: References: <3E657A6F-E37D-4F71-9F81-AE99D987F1C6@bbn.com> <95C5C7A891135E4685CCFAE997351F961F51EE@WABOTH9MSGUSR8B.ITServices.sbc.com> In-Reply-To: <95C5C7A891135E4685CCFAE997351F961F51EE@WABOTH9MSGUSR8B.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Subject: Re: [atoca] iOS 5 tied into Japanese early warning system 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 15:57:34 -0000 As Brian says. 3GPP TS 23.041. Look for the message identifiers that are MMI settable. Keith > -----Original Message----- > From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of > DALY, BRIAN K (ATTSI) > Sent: 22 August 2011 16:56 > To: Richard L. Barnes; atoca@ietf.org > Subject: Re: [atoca] iOS 5 tied into Japanese early warning system >=20 > It is standard GSM cell broadcast. ETWS is standardized as part of the > 3GPP PWS feature. >=20 > -------- > Brian K. Daly > Director, Core Network & Govn't/Regulatory Standards > AT&T Services, Inc. > +1.425.580.6873 > brian.k.daly@att.com >=20 > Rethink Possible >=20 > -----Original Message----- > From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of > Richard L. Barnes > Sent: Monday, August 22, 2011 8:55 AM > To: atoca@ietf.org > Subject: [atoca] iOS 5 tied into Japanese early warning system >=20 > Apparently the new version of iOS 5 is capable of receiving alerts from > the Japanese earthquake alert system. It also comes with a warning that > maintaining a connection to the alert system will reduce battery life. > Anyone know any details of how this works? >=20 > notifications-for-japanese-iphone-users/> > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From rbarnes@bbn.com Mon Aug 22 09:00:57 2011 Return-Path: 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 5B04F21F89CC for ; Mon, 22 Aug 2011 09:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.541 X-Spam-Level: X-Spam-Status: No, score=-106.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 JXN9jlOnn6mW for ; Mon, 22 Aug 2011 09:00:56 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id A407F21F8A30 for ; Mon, 22 Aug 2011 09:00:56 -0700 (PDT) Received: from dhcp89-089-029.bbn.com ([128.89.89.29]:62318) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QvWwq-0000NW-KL; Mon, 22 Aug 2011 12:02:00 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Mon, 22 Aug 2011 12:01:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <81CD5A6E-06E5-4854-8F0A-D34C46A3BFD2@bbn.com> References: <3E657A6F-E37D-4F71-9F81-AE99D987F1C6@bbn.com> <95C5C7A891135E4685CCFAE997351F961F51EE@WABOTH9MSGUSR8B.ITServices.sbc.com> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1082) Cc: "atoca@ietf.org" Subject: Re: [atoca] iOS 5 tied into Japanese early warning system 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 16:00:57 -0000 Thanks Keith and Brian. I guess this is just the iOS operating system = reading and rendering the ETWS broadcast message. I suppose the interesting question for this group would then be how = interworking might work with these things. Suppose an iPhone receives = one of these alerts while it's in tethering/hotspot mode. How could it = relay the alert to other endpoints connected over WiFi? --Richard On Aug 22, 2011, at 11:58 AM, DRAGE, Keith (Keith) wrote: > As Brian says. >=20 > 3GPP TS 23.041. Look for the message identifiers that are MMI = settable. >=20 > Keith >=20 >> -----Original Message----- >> From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On = Behalf Of >> DALY, BRIAN K (ATTSI) >> Sent: 22 August 2011 16:56 >> To: Richard L. Barnes; atoca@ietf.org >> Subject: Re: [atoca] iOS 5 tied into Japanese early warning system >>=20 >> It is standard GSM cell broadcast. ETWS is standardized as part of = the >> 3GPP PWS feature. >>=20 >> -------- >> Brian K. Daly >> Director, Core Network & Govn't/Regulatory Standards >> AT&T Services, Inc. >> +1.425.580.6873 >> brian.k.daly@att.com >>=20 >> Rethink Possible >>=20 >> -----Original Message----- >> From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On = Behalf Of >> Richard L. Barnes >> Sent: Monday, August 22, 2011 8:55 AM >> To: atoca@ietf.org >> Subject: [atoca] iOS 5 tied into Japanese early warning system >>=20 >> Apparently the new version of iOS 5 is capable of receiving alerts = from >> the Japanese earthquake alert system. It also comes with a warning = that >> maintaining a connection to the alert system will reduce battery = life. >> Anyone know any details of how this works? >>=20 >> = > notifications-for-japanese-iphone-users/> >> _______________________________________________ >> atoca mailing list >> atoca@ietf.org >> https://www.ietf.org/mailman/listinfo/atoca >> _______________________________________________ >> atoca mailing list >> atoca@ietf.org >> https://www.ietf.org/mailman/listinfo/atoca From arnoud.vanwijk@realtimetext.org Tue Aug 23 03:13:45 2011 Return-Path: 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 9F66D21F8AF1 for ; Tue, 23 Aug 2011 03:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 cXm8eBhJ-ExM for ; Tue, 23 Aug 2011 03:13:44 -0700 (PDT) Received: from mx-in01.nouzelle.com (mx-in01.nouzelle.com [87.119.194.132]) by ietfa.amsl.com (Postfix) with ESMTP id 8976A21F8AF0 for ; Tue, 23 Aug 2011 03:13:43 -0700 (PDT) Received: from internal02.nouzelle.com (internal02.nouzelle.local [172.29.32.13]) by mx-in01.nouzelle.com (Postfix) with ESMTP id 712FC125B0A; Tue, 23 Aug 2011 12:10:14 +0200 (CEST) Received: from mailscan.nouzelle.com (unknown [172.29.32.10]) by internal02.nouzelle.com (Postfix) with ESMTP id 1B3D910219B2C; Tue, 23 Aug 2011 12:14:48 +0200 (CEST) X-Virus-Scanned: by amavisd-new at nouzelle.com Received: from internal02.nouzelle.com ([172.29.32.13]) by mailscan.nouzelle.com (mailscan.nouzelle.com [172.29.32.10]) (amavisd-new, port 10026) with ESMTP id Z5fXhG664eOI; Tue, 23 Aug 2011 12:14:45 +0200 (CEST) Received: from arnoud-van-wijks-macbook-pro.local (541BD3CF.cm-5-4d.dynamic.ziggo.nl [84.27.211.207]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by internal02.nouzelle.com (Postfix) with ESMTPSA id 14CC210219B2B; Tue, 23 Aug 2011 12:14:45 +0200 (CEST) Message-ID: <4E537D94.8050203@realtimetext.org> Date: Tue, 23 Aug 2011 12:14:44 +0200 From: Arnoud van Wijk Organization: R3TF User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "Richard L. Barnes" References: <3E657A6F-E37D-4F71-9F81-AE99D987F1C6@bbn.com> <95C5C7A891135E4685CCFAE997351F961F51EE@WABOTH9MSGUSR8B.ITServices.sbc.com> <81CD5A6E-06E5-4854-8F0A-D34C46A3BFD2@bbn.com> In-Reply-To: <81CD5A6E-06E5-4854-8F0A-D34C46A3BFD2@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "atoca@ietf.org" Subject: Re: [atoca] iOS 5 tied into Japanese early warning system X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: arnoud.vanwijk@realtimetext.org List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 10:13:45 -0000 Another question is what if you are deaf or hard of hearing? Will it vibrate? How long? How strong? Will it blend? (oh that is something else :-)) But cell broadcast is a good thing that is essential for people who have no or low ability to receive audio alerts like sirens for Tsunami, Earthquakes, Tornadoes or any other disaster like a chemical spill. /Arnoud On 22-08-11 18:01, Richard L. Barnes wrote: > Thanks Keith and Brian. I guess this is just the iOS operating system reading and rendering the ETWS broadcast message. > > I suppose the interesting question for this group would then be how interworking might work with these things. Suppose an iPhone receives one of these alerts while it's in tethering/hotspot mode. How could it relay the alert to other endpoints connected over WiFi? > > --Richard > > > > > On Aug 22, 2011, at 11:58 AM, DRAGE, Keith (Keith) wrote: > >> As Brian says. >> >> 3GPP TS 23.041. Look for the message identifiers that are MMI settable. >> >> Keith >> >>> -----Original Message----- >>> From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of >>> DALY, BRIAN K (ATTSI) >>> Sent: 22 August 2011 16:56 >>> To: Richard L. Barnes; atoca@ietf.org >>> Subject: Re: [atoca] iOS 5 tied into Japanese early warning system >>> >>> It is standard GSM cell broadcast. ETWS is standardized as part of the >>> 3GPP PWS feature. >>> >>> -------- >>> Brian K. Daly >>> Director, Core Network& Govn't/Regulatory Standards >>> AT&T Services, Inc. >>> +1.425.580.6873 >>> brian.k.daly@att.com >>> >>> Rethink Possible >>> >>> -----Original Message----- >>> From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of >>> Richard L. Barnes >>> Sent: Monday, August 22, 2011 8:55 AM >>> To: atoca@ietf.org >>> Subject: [atoca] iOS 5 tied into Japanese early warning system >>> >>> Apparently the new version of iOS 5 is capable of receiving alerts from >>> the Japanese earthquake alert system. It also comes with a warning that >>> maintaining a connection to the alert system will reduce battery life. >>> Anyone know any details of how this works? >>> >>> >> notifications-for-japanese-iphone-users/> >>> _______________________________________________ >>> atoca mailing list >>> atoca@ietf.org >>> https://www.ietf.org/mailman/listinfo/atoca >>> _______________________________________________ >>> atoca mailing list >>> atoca@ietf.org >>> https://www.ietf.org/mailman/listinfo/atoca > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca > From mark.wood@drcf.net Tue Aug 23 05:18:31 2011 Return-Path: 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 8CB3721F8AB8 for ; Tue, 23 Aug 2011 05:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 nsA3bGnp6Rpl for ; Tue, 23 Aug 2011 05:18:31 -0700 (PDT) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by ietfa.amsl.com (Postfix) with ESMTP id B569221F8A97 for ; Tue, 23 Aug 2011 05:18:30 -0700 (PDT) X-Trace: 356388337/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/81.86.43.86/None/mark.wood@drcf.net X-SBRS: None X-RemoteIP: 81.86.43.86 X-IP-MAIL-FROM: mark.wood@drcf.net X-SMTP-AUTH: X-Originating-Country: GB/UNITED KINGDOM X-MUA: Microsoft Office Outlook, Build 11.0.5510Produced By Microsoft MimeOLE V6.1.7601.17609 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkEGAIeaU05RVitW/2dsb2JhbABBmQ6PDXiBQAEBBQgyHC8BBAEGFAQBAQoeIBoGDQkJAQQTC4domF2mIIEEBJgXh2CEHQ X-IronPort-AV: E=Sophos;i="4.68,269,1312153200"; d="scan'208";a="356388337" X-IP-Direction: IN Received: from 81-86-43-86.dsl.pipex.com (HELO number15) ([81.86.43.86]) by smtp.pipex.tiscali.co.uk with ESMTP; 23 Aug 2011 13:19:22 +0100 From: Sender: "Mark" To: Date: Tue, 23 Aug 2011 13:19:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609 Thread-Index: AcxhfYb2ZVLV6KxFS7ussC5IKFAp7AACOdGAAAIK5JA= Message-Id: <20110823121830.B569221F8A97@ietfa.amsl.com> Subject: [atoca] Terminal Behaviour 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 12:18:31 -0000 -----Original Message----- From: Mark [mailto:mark.wood@drcf.net] Sent: 23 August 2011 12:37 To: 'arnoud.vanwijk@realtimetext.org'; 'Richard L. Barnes' Cc: 'atoca@ietf.org' Subject: RE: [atoca] iOS 5 tied into Japanese early warning system Hi Arnoud; Yes, you are right, The Japanese ETWS, European EU-ALERT and US CMAS, are indeed, as Brian says, implemented by regular vanilla flavoured standard Cell Broadcast. (Though I think Japan has an additional method over the paging channel also, which is more rapid but only delivers a special tone indication). The main new feature required in addition to normal cell broadcast is a special more intrusive 'alert tone' (which has already been defined in the USA) and 'attention getting' behaviour such as pop ups and flashing, from the terminal in case of an alert message. The behaviour of the terminal decides what happens when you receive a cell broadcast message. It is perfectly possible for the terminal to have vibration and flashing to get attention on receipt of a cell broadcast message, just the same as receiving a SMS message. This is set by the user from the MMI menu system. I understand that there is a move at the 3GPP to include new flags in unused bits of the 'serial number' of the 023.041 standard so that pop-up and special alert tone can be demanded. But in the mean time, the terminal can deduce this from the MI number. This is why there has been sustained effort for many years to define a range of addresses for which more intrusive behaviour is required, so that terminal vendors can use this in the interim. In fact one driving reason why the Netherlands chose to use cell broadcast is exactly so that the deaf are not disadvantaged by its use (over the more traditional sirens), I think the University of Delft (Netherlands) made a detailed study about this. I think Wim Van Setten and Dick Gerbrands of SPMM were involved in that study. Perhaps one of our Netherlands colleagues can point you to that study. I wonder if Mr Daley can tell us what the status is of the proposed flags for setting this behaviour. Was it included in the standard yet? Warm regards, Mark Wood. -----Original Message----- From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of Arnoud van Wijk Sent: 23 August 2011 11:15 To: Richard L. Barnes Cc: atoca@ietf.org Subject: Re: [atoca] iOS 5 tied into Japanese early warning system Another question is what if you are deaf or hard of hearing? Will it vibrate? How long? How strong? Will it blend? (oh that is something else :-)) But cell broadcast is a good thing that is essential for people who have no or low ability to receive audio alerts like sirens for Tsunami, Earthquakes, Tornadoes or any other disaster like a chemical spill. /Arnoud From bd2985@att.com Tue Aug 23 09:21:15 2011 Return-Path: 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 1366321F86EC for ; Tue, 23 Aug 2011 09:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 RlQ1GobJ64tr for ; Tue, 23 Aug 2011 09:21:13 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 19D7121F8620 for ; Tue, 23 Aug 2011 09:21:12 -0700 (PDT) X-Env-Sender: bd2985@att.com X-Msg-Ref: server-13.tower-119.messagelabs.com!1314116538!35453416!1 X-Originating-IP: [144.160.112.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22593 invoked from network); 23 Aug 2011 16:22:18 -0000 Received: from sbcsmtp3.sbc.com (HELO tlpi048.enaf.dadc.sbc.com) (144.160.112.28) by server-13.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Aug 2011 16:22:18 -0000 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by tlpi048.enaf.dadc.sbc.com (8.14.4/8.14.4) with ESMTP id p7NGMHea018289; Tue, 23 Aug 2011 11:22:18 -0500 Received: from WABOTH9MSGHUB8A.ITServices.sbc.com (waboth9msghub8a.itservices.sbc.com [135.163.35.61]) by tlpi048.enaf.dadc.sbc.com (8.14.4/8.14.4) with ESMTP id p7NGMGCf018276; Tue, 23 Aug 2011 11:22:16 -0500 Received: from WABOTH9MSGUSR8B.ITServices.sbc.com ([169.254.2.17]) by WABOTH9MSGHUB8A.ITServices.sbc.com ([135.163.35.61]) with mapi id 14.01.0289.001; Tue, 23 Aug 2011 09:22:01 -0700 From: "DALY, BRIAN K (ATTSI)" To: "mark.wood@engineer.com" , "atoca@ietf.org" Thread-Topic: [atoca] Terminal Behaviour Thread-Index: AcxhfYb2ZVLV6KxFS7ussC5IKFAp7AACOdGAAAIK5JAACBBWsA== Date: Tue, 23 Aug 2011 16:22:00 +0000 Message-ID: <95C5C7A891135E4685CCFAE997351F961F8570@WABOTH9MSGUSR8B.ITServices.sbc.com> References: <20110823121830.B569221F8A97@ietfa.amsl.com> In-Reply-To: <20110823121830.B569221F8A97@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.163.34.6] Content-Type: multipart/alternative; boundary="_000_95C5C7A891135E4685CCFAE997351F961F8570WABOTH9MSGUSR8BIT_" MIME-Version: 1.0 Subject: Re: [atoca] Terminal Behaviour 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 16:21:15 -0000 --_000_95C5C7A891135E4685CCFAE997351F961F8570WABOTH9MSGUSR8BIT_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Mark - It is already in 3GPP 23.041 Release 11: In the case of transmitting CBS messages for ETWS, i.e. the Message Identif= ier has a value for ETWS (see subclause 9.4.1.2.2), a part of Message Code = can be used to command mobile terminals to activate emergency user alert an= d message popup in order to alert the users. Message Code format for this p= urpose is as follows: 5 4 3 2 1 0 7 6 5 4 Emergency User Alert Popup NOTE 1: The exact behaviour of the UE is specified in 3GPP TS 22.268 [28]= . Whether the UE setting is overridden is subject to regulatory requirement= s. NOTE 2: Emergency user alert includes alerting tone and other user alerti= ng means such as vibration, according to the UE=1B$B!G=1B(Bs capability. Th= e types of alert (e.g. the kind of tone, vibration, etc) are implementation= =1B$B!!=1B(Bdependent and may be subject to regulatory requirements. NOTE 3: The popup indication shall take precedence over the setting of th= e DCS Message class (see 3GPP TS 23.038 [3]), and the Geographical Scope wi= th regard to Display Mode 'immediate'. The codings of the Emergency User Alert and Popup fields are shown be= low: Field Code Instruction to Terminal Emergency User Alert 0 No instruction as to emergency user alert. 1 Activate emergency user alert. Popup 0 No instruction as to popup. 1 Activate popup on the display. -------- Brian K. Daly Director, Core Network & Govn't/Regulatory Standards AT&T Services, Inc. +1.425.580.6873 brian.k.daly@att.com Rethink Possible -----Original Message----- From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of m= ark.wood@engineer.com Sent: Tuesday, August 23, 2011 5:19 AM To: atoca@ietf.org Subject: [atoca] Terminal Behaviour -----Original Message----- From: Mark [mailto:mark.wood@drcf.net] Sent: 23 August 2011 12:37 To: 'arnoud.vanwijk@realtimetext.org'; 'Richard L. Barnes' Cc: 'atoca@ietf.org' Subject: RE: [atoca] iOS 5 tied into Japanese early warning system Hi Arnoud; Yes, you are right, The Japanese ETWS, European EU-ALERT and US CMAS, are indeed, as Brian says= , implemented by regular vanilla flavoured standard Cell Broadcast. (Though I think Japan has an additional method over the paging channel also, which is more rapid but only delivers a special tone indication). The main new feature required in addition to normal cell broadcast is a special more intrusive 'alert tone' (which has already been defined in the USA) and 'attention getting' behaviour such as pop ups and flashing, from the terminal in case of an alert message. The behaviour of the terminal decides what happens when you receive a cell broadcast message. It is perfectly possible for the terminal to have vibration and flashing to get attention on receipt of a cell broadcast message, just the same as receiving a SMS message. This is set by the user from the MMI menu system. I understand that there is a move at the 3GPP to include new flags in unuse= d bits of the 'serial number' of the 023.041 standard so that pop-up and special alert tone can be demanded. But in the mean time, the terminal can deduce this from the MI number. This is why there has been sustained effort for many years to define a rang= e of addresses for which more intrusive behaviour is required, so that terminal vendors can use this in the interim. In fact one driving reason why the Netherlands chose to use cell broadcast is exactly so that the deaf are not disadvantaged by its use (over the more traditional sirens), I think the University of Delft (Netherlands) made a detailed study about this. I think Wim Van Setten and Dick Gerbrands of SPM= M were involved in that study. Perhaps one of our Netherlands colleagues can point you to that study. I wonder if Mr Daley can tell us what the status is of the proposed flags for setting this behaviour. Was it included in the standard yet? Warm regards, Mark Wood. -----Original Message----- From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of Arnoud van Wijk Sent: 23 August 2011 11:15 To: Richard L. Barnes Cc: atoca@ietf.org Subject: Re: [atoca] iOS 5 tied into Japanese early warning system Another question is what if you are deaf or hard of hearing? Will it vibrate? How long? How strong? Will it blend? (oh that is something else :-)) But cell broadcast is a good thing that is essential for people who have no or low ability to receive audio alerts like sirens for Tsunami, Earthquakes, Tornadoes or any other disaster like a chemical spill. /Arnoud _______________________________________________ atoca mailing list atoca@ietf.org https://www.ietf.org/mailman/listinfo/atoca --_000_95C5C7A891135E4685CCFAE997351F961F8570WABOTH9MSGUSR8BIT_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

Mark -

 

It is already in 3GPP 23.041 Release 11:

 

In the case of transmitting CBS messag= es for ETWS, i.e. t= he Message Identifier has a value for ETWS (see subclause 9.4.1.2.2), = a part of Message Code can be used to command mobile terminals to activate emergency user alert and message popup in ord= er to alert the users. Message Code format for this purpose is as follows:<= o:p>

5

4

3

2

1

0

7

6

5

4

Emergency User Alert

Popup

 

 

NOTE 1:   The exact behaviour of the UE is= specified in 3GPP TS 22.268 [28]. Whether the UE setting is= overridden is subject to regulatory requirements.

NOTE 2:   Emergency user alert includes al= erting tone and other user alerting means such as vibration, according to t= he UE=1B$B!G=1B(Bs capability. The types of alert (e.g. the kind of tone, vibration, etc) are implementation=1B$B!!=1B(B= dependent and may be subject to regulatory requirements.<= /p>

NOTE 3:   The popup indication shall take = precedence over the setting of the DCS Message class (see 3GPP TS = ;23.038 [3]), and the Geographical Scope with regard to Display Mode 'immediate'.

      The cod= ings of the Emergency User Alert and Popup fields are shown below:

Field<= o:p>

Code

Instru= ction to Terminal

Emerge= ncy User Alert

0

No ins= truction as to emergency user alert.

1

Activa= te emergency user alert.

Popup<= /span>

0

No ins= truction as to popup.

1

Activa= te popup on the display.

 

 

 

--------

Brian K. Daly

Director, Core Network & Govn't/Regulatory St= andards

AT&T Services, Inc.

+1.425.580.6873

brian.k.daly@att.com

 

Rethink Possible

 

 

-----Original Message-----
From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of m= ark.wood@engineer.com
Sent: Tuesday, August 23, 2011 5:19 AM
To: atoca@ietf.org
Subject: [atoca] Terminal Behaviour

 

 

 

-----Original Message-----

From: Mark [mailto:mark.wood@drcf.net]

Sent: 23 August 2011 12:37

To: 'arnoud.vanwijk@realtimetext.org'; 'Richard L= . Barnes'

Cc: 'atoca@ietf.org'

Subject: RE: [atoca] iOS 5 tied into Japanese ear= ly warning system

 

 

 

 

 

Hi Arnoud;

 

 

Yes, you are right,

 

The Japanese ETWS, European EU-ALERT and US CMAS,= are indeed, as Brian says,

implemented by regular vanilla flavoured standard= Cell Broadcast. (Though I

think Japan has an additional method over the pag= ing channel also, which is

more rapid but only delivers a special tone indic= ation).

 

The main new feature required in addition to norm= al cell broadcast is a

special more intrusive 'alert tone' (which has al= ready been defined in the

USA) and 'attention getting' behaviour such as po= p ups and flashing, from

the terminal in case of an alert message.  <= o:p>

 

The behaviour of the terminal decides what happen= s when you receive a cell

broadcast message. It is perfectly possible for t= he terminal to have

vibration and flashing to get attention on receip= t of a cell broadcast

message, just the same as receiving a SMS message= . This is set by the user

from the MMI menu system.   =

 

I understand that there is a move at the 3GPP to = include new flags in unused

bits of the 'serial number' of the 023.041 standa= rd so that pop-up and

special alert tone can be demanded. But in the me= an time, the terminal can

deduce this from the MI number.

 

 

This is why there has been sustained effort for m= any years to define a range

of addresses for which more intrusive behaviour i= s required, so that

terminal vendors can use this in the interim.

 

In fact one driving reason why the Netherlands ch= ose to use cell broadcast

is exactly so that the deaf are not disadvantaged= by its use (over the more

traditional sirens), I think the University of De= lft (Netherlands) made a

detailed study about this. I think Wim Van Setten= and Dick Gerbrands of SPMM

were involved in that study.  Perhaps one of= our Netherlands colleagues can

point you to that study.

 

I wonder if Mr Daley can tell us what the status = is of the proposed flags

for setting this behaviour.  Was it included= in the standard yet?

 

Warm regards, Mark Wood.

 

 

 

 

 

-----Original Message-----

From: atoca-bounces@ietf.org [mailto:atoca-bounce= s@ietf.org] On Behalf Of

Arnoud van Wijk

Sent: 23 August 2011 11:15

To: Richard L. Barnes

Cc: atoca@ietf.org

Subject: Re: [atoca] iOS 5 tied into Japanese ear= ly warning system

 

Another question is what if you are deaf or hard = of hearing?

Will it vibrate? How long? How strong?=

Will it blend? (oh that is something else :-))

 

But cell broadcast is a good thing that is essent= ial for people who have

no or low ability to receive audio alerts like si= rens for Tsunami,

Earthquakes, Tornadoes or any other disaster like= a chemical spill.

 

/Arnoud

 

 

_______________________________________________

atoca mailing list

atoca@ietf.org

https://www.ietf.org/mailman/listinfo/atoca<= /o:p>

--_000_95C5C7A891135E4685CCFAE997351F961F8570WABOTH9MSGUSR8BIT_-- From mark.wood@drcf.net Tue Aug 23 09:44:05 2011 Return-Path: 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 D50E221F8B28 for ; Tue, 23 Aug 2011 09:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 VTBL2aHWZBhk for ; Tue, 23 Aug 2011 09:44:05 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6EF21F8B27 for ; Tue, 23 Aug 2011 09:44:04 -0700 (PDT) X-Trace: 505902837/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/81.86.43.86/None/mark.wood@drcf.net X-SBRS: None X-RemoteIP: 81.86.43.86 X-IP-MAIL-FROM: mark.wood@drcf.net X-SMTP-AUTH: X-Originating-Country: GB/UNITED KINGDOM X-MUA: Microsoft Office Outlook, Build 11.0.5510Produced By Microsoft MimeOLE V6.1.7601.17609 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAL/YU05RVitW/2dsb2JhbABCgk2lU3iBQAEBBQglKTAEAQYDEQQBAQoeIBoGDQkIAQEEARILh2jBeIEEBIwpi26HYIQd X-IronPort-AV: E=Sophos;i="4.68,270,1312153200"; d="scan'208,217";a="505902837" X-IP-Direction: IN Received: from 81-86-43-86.dsl.pipex.com (HELO number15) ([81.86.43.86]) by smtp.pipex.tiscali.co.uk with ESMTP; 23 Aug 2011 17:45:07 +0100 From: "Mark" Sender: "Mark" To: "'DALY, BRIAN K \(ATTSI\)'" , , In-Reply-To: <95C5C7A891135E4685CCFAE997351F961F8570@WABOTH9MSGUSR8B.ITServices.sbc.com> Date: Tue, 23 Aug 2011 17:45:07 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0075_01CC61BC.65C5F5C0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609 Thread-Index: AcxhfYb2ZVLV6KxFS7ussC5IKFAp7AACOdGAAAIK5JAACBBWsAABARNw Message-Id: <20110823164404.3D6EF21F8B27@ietfa.amsl.com> Subject: Re: [atoca] Terminal Behaviour 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 16:44:05 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0075_01CC61BC.65C5F5C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Oh excellent! Thank you Brian; Can I indulge your kindness to explain to us how the Japanese ETWS 'primary' alert system works? I think that it uses the paging channel in some way, as it only triggers a tone and does not send any text (as I understand it) but I would appreciate some clarity on how it works and if it will become part of the general standard or just adopted in Japan. Anyone Know? Mark _____ From: DALY, BRIAN K (ATTSI) [mailto:bd2985@att.com] Sent: 23 August 2011 17:22 To: mark.wood@engineer.com; atoca@ietf.org Subject: RE: [atoca] Terminal Behaviour Mark - It is already in 3GPP 23.041 Release 11: ------=_NextPart_000_0075_01CC61BC.65C5F5C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Oh = excellent!

 

Thank you = Brian;

 

Can I indulge your kindness to = explain to us how the Japanese ETWS ‘primary’ alert system works? I = think that it uses the paging channel in some way, as it only triggers a tone and does not send = any text (as I understand it) but I would appreciate some clarity on how it = works and if it will become part of the general standard or just adopted in = Japan.

 

 

Anyone = Know?

 

Mark

 

 

 

 

 

From: DALY, BRIAN K (ATTSI) [mailto:bd2985@att.com]
Sent: 23 August 2011 = 17:22
To: = mark.wood@engineer.com; atoca@ietf.org
Subject: RE: [atoca] = Terminal Behaviour

 

Mark -

 

It is already in 3GPP 23.041 Release = 11:

 =

 =

------=_NextPart_000_0075_01CC61BC.65C5F5C0-- From mark.wood@drcf.net Tue Aug 23 04:35:58 2011 Return-Path: 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 C283F21F85E3 for ; Tue, 23 Aug 2011 04:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74] 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 T6oTs2SL-ovS for ; Tue, 23 Aug 2011 04:35:58 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by ietfa.amsl.com (Postfix) with ESMTP id D5A5521F8591 for ; Tue, 23 Aug 2011 04:35:57 -0700 (PDT) X-Trace: 505761771/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/81.86.43.86/None/mark.wood@drcf.net X-SBRS: None X-RemoteIP: 81.86.43.86 X-IP-MAIL-FROM: mark.wood@drcf.net X-SMTP-AUTH: X-Originating-Country: GB/UNITED KINGDOM X-MUA: Microsoft Office Outlook, Build 11.0.5510Produced By Microsoft MimeOLE V6.1.7601.17609 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABKQU05RVitW/2dsb2JhbABBqBt4gUABAQUIMhwjDAEFBgMRBAEBCh4gGgYNCQgBAQQBEguHaL50gQQEjCmLbodghB0 X-IronPort-AV: E=Sophos;i="4.68,269,1312153200"; d="scan'208";a="505761771" X-IP-Direction: IN Received: from 81-86-43-86.dsl.pipex.com (HELO number15) ([81.86.43.86]) by smtp.pipex.tiscali.co.uk with ESMTP; 23 Aug 2011 12:37:02 +0100 From: "Mark" To: , "'Richard L. Barnes'" In-Reply-To: <4E537D94.8050203@realtimetext.org> Date: Tue, 23 Aug 2011 12:37:03 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609 Thread-Index: AcxhfYb2ZVLV6KxFS7ussC5IKFAp7AACOdGA Message-Id: <20110823113557.D5A5521F8591@ietfa.amsl.com> X-Mailman-Approved-At: Tue, 23 Aug 2011 13:53:25 -0700 Cc: atoca@ietf.org Subject: Re: [atoca] iOS 5 tied into Japanese early warning system 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 11:35:59 -0000 Hi Arnoud; Yes, you are right, The Japanese ETWS, European EU-ALERT and US CMAS, are indeed, as Brian says, implemented by regular vanilla flavoured standard Cell Broadcast. (Though I think Japan has an additional method over the paging channel also, which is more rapid but only delivers a special tone indication). The main new feature required in addition to normal cell broadcast is a special more intrusive 'alert tone' (which has already been defined in the USA) and 'attention getting' behaviour such as pop ups and flashing, from the terminal in case of an alert message. The behaviour of the terminal decides what happens when you receive a cell broadcast message. It is perfectly possible for the terminal to have vibration and flashing to get attention on receipt of a cell broadcast message, just the same as receiving a SMS message. This is set by the user from the MMI menu system. I understand that there is a move at the 3GPP to include new flags in unused bits of the 'serial number' of the 023.041 standard so that pop-up and special alert tone can be demanded. But in the mean time, the terminal can deduce this from the MI number. This is why there has been sustained effort for many years to define a range of addresses for which more intrusive behaviour is required, so that terminal vendors can use this in the interim. In fact one driving reason why the Netherlands chose to use cell broadcast is exactly so that the deaf are not disadvantaged by its use (over the more traditional sirens), I think the University of Delft (Netherlands) made a detailed study about this. I think Wim Van Setten and Dick Gerbrands of SPMM were involved in that study. Perhaps one of our Netherlands colleagues can point you to that study. I wonder if Mr Daley can tell us what the status is of the proposed flags for setting this behaviour. Was it included in the standard yet? Warm regards, Mark Wood. -----Original Message----- From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of Arnoud van Wijk Sent: 23 August 2011 11:15 To: Richard L. Barnes Cc: atoca@ietf.org Subject: Re: [atoca] iOS 5 tied into Japanese early warning system Another question is what if you are deaf or hard of hearing? Will it vibrate? How long? How strong? Will it blend? (oh that is something else :-)) But cell broadcast is a good thing that is essential for people who have no or low ability to receive audio alerts like sirens for Tsunami, Earthquakes, Tornadoes or any other disaster like a chemical spill. /Arnoud From peter.sanders@one2many.eu Tue Aug 23 15:03:52 2011 Return-Path: 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 98BB521F8D51 for ; Tue, 23 Aug 2011 15:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MSGID_MULTIPLE_AT=1.449] 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 zl83KuTWDYm7 for ; Tue, 23 Aug 2011 15:03:52 -0700 (PDT) Received: from smtp.byte.nl (mailgw3.c1.byte.nl [82.94.214.67]) by ietfa.amsl.com (Postfix) with ESMTP id CD83021F8D37 for ; Tue, 23 Aug 2011 15:03:50 -0700 (PDT) Received: from peters (5249686E.cm-4-2b.dynamic.ziggo.nl [82.73.104.110]) (Authenticated sender: onema004) by smtp.byte.nl (Postfix) with ESMTPA id 5B5A1905B; Wed, 24 Aug 2011 00:04:58 +0200 (CEST) From: "Peter Sanders" To: "'Mark'" References: <4E537D94.8050203@realtimetext.org> <20110823113557.D5A5521F8591@ietfa.amsl.com> In-Reply-To: <20110823113557.D5A5521F8591@ietfa.amsl.com> Date: Wed, 24 Aug 2011 00:04:58 +0200 Organization: one2many Message-ID: <003201cc61e0$b2b8dd10$182a9730$@sanders@one2many.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxhfYb2ZVLV6KxFS7ussC5IKFAp7AACOdGAABZEISA= Content-Language: nl Cc: atoca@ietf.org Subject: Re: [atoca] iOS 5 tied into Japanese early warning system 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 22:03:52 -0000 Hi Mark, CMAS does not use the flags for pop-up and alert-tone and neither does EU-Alert. The two bits in the serial number (which are by the way not unused bits!) that are used for pop-up and alert-tone are exclusively for ETWS use. There is also no effort ongoing to assign the use of those bits to anything other than ETWS. The more intrusive ring tone you are referring to in your mail below is also required in EU-Alert. Since the ring-tone itself is not specified in the EU-Alert specification, the mobile device vendors will select one that is different than the standard ring-tone and your safest bet would be that the CMAS ring-tone will also be used for EU-Alert. Best regards, Peter -----Original Message----- From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of Mark Sent: dinsdag 23 augustus 2011 13:37 To: arnoud.vanwijk@realtimetext.org; 'Richard L. Barnes' Cc: atoca@ietf.org Subject: Re: [atoca] iOS 5 tied into Japanese early warning system Hi Arnoud; Yes, you are right, The Japanese ETWS, European EU-ALERT and US CMAS, are indeed, as Brian says, implemented by regular vanilla flavoured standard Cell Broadcast. (Though I think Japan has an additional method over the paging channel also, which is more rapid but only delivers a special tone indication). The main new feature required in addition to normal cell broadcast is a special more intrusive 'alert tone' (which has already been defined in the USA) and 'attention getting' behaviour such as pop ups and flashing, from the terminal in case of an alert message. The behaviour of the terminal decides what happens when you receive a cell broadcast message. It is perfectly possible for the terminal to have vibration and flashing to get attention on receipt of a cell broadcast message, just the same as receiving a SMS message. This is set by the user from the MMI menu system. I understand that there is a move at the 3GPP to include new flags in unused bits of the 'serial number' of the 023.041 standard so that pop-up and special alert tone can be demanded. But in the mean time, the terminal can deduce this from the MI number. This is why there has been sustained effort for many years to define a range of addresses for which more intrusive behaviour is required, so that terminal vendors can use this in the interim. In fact one driving reason why the Netherlands chose to use cell broadcast is exactly so that the deaf are not disadvantaged by its use (over the more traditional sirens), I think the University of Delft (Netherlands) made a detailed study about this. I think Wim Van Setten and Dick Gerbrands of SPMM were involved in that study. Perhaps one of our Netherlands colleagues can point you to that study. I wonder if Mr Daley can tell us what the status is of the proposed flags for setting this behaviour. Was it included in the standard yet? Warm regards, Mark Wood. -----Original Message----- From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of Arnoud van Wijk Sent: 23 August 2011 11:15 To: Richard L. Barnes Cc: atoca@ietf.org Subject: Re: [atoca] iOS 5 tied into Japanese early warning system Another question is what if you are deaf or hard of hearing? Will it vibrate? How long? How strong? Will it blend? (oh that is something else :-)) But cell broadcast is a good thing that is essential for people who have no or low ability to receive audio alerts like sirens for Tsunami, Earthquakes, Tornadoes or any other disaster like a chemical spill. /Arnoud _______________________________________________ atoca mailing list atoca@ietf.org https://www.ietf.org/mailman/listinfo/atoca From bd2985@att.com Tue Aug 23 21:39:29 2011 Return-Path: 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 5165521F8B1A for ; Tue, 23 Aug 2011 21:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 zQeNU4vtTUs0 for ; Tue, 23 Aug 2011 21:39:28 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9F521F8B02 for ; Tue, 23 Aug 2011 21:39:28 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: bd2985@att.com X-Msg-Ref: server-5.tower-120.messagelabs.com!1314160836!34370724!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [144.160.112.28] Received: (qmail 16997 invoked from network); 24 Aug 2011 04:40:36 -0000 Received: from sbcsmtp3.sbc.com (HELO tlpi048.enaf.dadc.sbc.com) (144.160.112.28) by server-5.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 Aug 2011 04:40:36 -0000 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by tlpi048.enaf.dadc.sbc.com (8.14.4/8.14.4) with ESMTP id p7O4eabH004984; Tue, 23 Aug 2011 23:40:36 -0500 Received: from WABOTH9MSGHUB8B.ITServices.sbc.com (waboth9msghub8b.itservices.sbc.com [135.163.35.101]) by tlpi048.enaf.dadc.sbc.com (8.14.4/8.14.4) with ESMTP id p7O4eR3m004948; Tue, 23 Aug 2011 23:40:30 -0500 Received: from WABOTH9MSGUSR8B.ITServices.sbc.com ([169.254.2.17]) by WABOTH9MSGHUB8B.ITServices.sbc.com ([135.163.35.101]) with mapi id 14.01.0289.001; Tue, 23 Aug 2011 21:40:12 -0700 From: "DALY, BRIAN K (ATTSI)" To: Peter Sanders , "'Mark'" Thread-Topic: [atoca] iOS 5 tied into Japanese early warning system Thread-Index: AcxhfYb21yIfviBd6EKxcUMKfRxZBgACOdGAABZEISAADhAggA== Date: Wed, 24 Aug 2011 04:40:11 +0000 Message-ID: <95C5C7A891135E4685CCFAE997351F961F95D2@WABOTH9MSGUSR8B.ITServices.sbc.com> References: <4E537D94.8050203@realtimetext.org> <20110823113557.D5A5521F8591@ietfa.amsl.com> <003201cc61e0$b2b8dd10$182a9730$@sanders@one2many.eu> In-Reply-To: <003201cc61e0$b2b8dd10$182a9730$@sanders@one2many.eu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.163.34.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "atoca@ietf.org" Subject: Re: [atoca] iOS 5 tied into Japanese early warning system 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 04:39:29 -0000 Thanks for that clarification Peter. CMAS also has FCC-defined alert tones and vibration cadences that are trigg= ered by the cell broadcast message identifier. -------- Brian K. Daly Director, Core Network & Govn't/Regulatory Standards AT&T Services, Inc. +1.425.580.6873 brian.k.daly@att.com Rethink Possible -----Original Message----- From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of P= eter Sanders Sent: Tuesday, August 23, 2011 3:05 PM To: 'Mark' Cc: atoca@ietf.org Subject: Re: [atoca] iOS 5 tied into Japanese early warning system Hi Mark, CMAS does not use the flags for pop-up and alert-tone and neither does EU-Alert. The two bits in the serial number (which are by the way not unuse= d bits!) that are used for pop-up and alert-tone are exclusively for ETWS use= . There is also no effort ongoing to assign the use of those bits to anything other than ETWS. The more intrusive ring tone you are referring to in your mail below is als= o required in EU-Alert. Since the ring-tone itself is not specified in the EU-Alert specification, the mobile device vendors will select one that is different than the standard ring-tone and your safest bet would be that the CMAS ring-tone will also be used for EU-Alert. Best regards, Peter -----Original Message----- From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of Mark Sent: dinsdag 23 augustus 2011 13:37 To: arnoud.vanwijk@realtimetext.org; 'Richard L. Barnes' Cc: atoca@ietf.org Subject: Re: [atoca] iOS 5 tied into Japanese early warning system Hi Arnoud; Yes, you are right,=20 The Japanese ETWS, European EU-ALERT and US CMAS, are indeed, as Brian says= , implemented by regular vanilla flavoured standard Cell Broadcast. (Though I think Japan has an additional method over the paging channel also, which is more rapid but only delivers a special tone indication). The main new feature required in addition to normal cell broadcast is a special more intrusive 'alert tone' (which has already been defined in the USA) and 'attention getting' behaviour such as pop ups and flashing, from the terminal in case of an alert message. =20 The behaviour of the terminal decides what happens when you receive a cell broadcast message. It is perfectly possible for the terminal to have vibration and flashing to get attention on receipt of a cell broadcast message, just the same as receiving a SMS message. This is set by the user from the MMI menu system. =20 I understand that there is a move at the 3GPP to include new flags in unuse= d bits of the 'serial number' of the 023.041 standard so that pop-up and special alert tone can be demanded. But in the mean time, the terminal can deduce this from the MI number.=20 This is why there has been sustained effort for many years to define a rang= e of addresses for which more intrusive behaviour is required, so that terminal vendors can use this in the interim. In fact one driving reason why the Netherlands chose to use cell broadcast is exactly so that the deaf are not disadvantaged by its use (over the more traditional sirens), I think the University of Delft (Netherlands) made a detailed study about this. I think Wim Van Setten and Dick Gerbrands of SPM= M were involved in that study. Perhaps one of our Netherlands colleagues can point you to that study. I wonder if Mr Daley can tell us what the status is of the proposed flags for setting this behaviour. Was it included in the standard yet? Warm regards, Mark Wood. =20 -----Original Message----- From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of Arnoud van Wijk Sent: 23 August 2011 11:15 To: Richard L. Barnes Cc: atoca@ietf.org Subject: Re: [atoca] iOS 5 tied into Japanese early warning system Another question is what if you are deaf or hard of hearing? Will it vibrate? How long? How strong? Will it blend? (oh that is something else :-)) But cell broadcast is a good thing that is essential for people who have=20 no or low ability to receive audio alerts like sirens for Tsunami,=20 Earthquakes, Tornadoes or any other disaster like a chemical spill. /Arnoud _______________________________________________ atoca mailing list atoca@ietf.org https://www.ietf.org/mailman/listinfo/atoca _______________________________________________ atoca mailing list atoca@ietf.org https://www.ietf.org/mailman/listinfo/atoca From mark.wood@drcf.net Wed Aug 24 04:36:19 2011 Return-Path: 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 8282321F8AF7 for ; Wed, 24 Aug 2011 04:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 1I87p-x5BZJE for ; Wed, 24 Aug 2011 04:36:19 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by ietfa.amsl.com (Postfix) with ESMTP id ADF9D21F8B03 for ; Wed, 24 Aug 2011 04:36:18 -0700 (PDT) X-Trace: 506215442/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/81.86.43.86/None/mark.wood@drcf.net X-SBRS: None X-RemoteIP: 81.86.43.86 X-IP-MAIL-FROM: mark.wood@drcf.net X-SMTP-AUTH: X-Originating-Country: GB/UNITED KINGDOM X-MUA: Microsoft Office Outlook, Build 11.0.5510Produced By Microsoft MimeOLE V6.1.7601.17609 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnEHAIXhVE5RVitW/2dsb2JhbABCmGKPFHiBQAEBBQgyHC8BBAEGFAQBAQoeIBoGDQkDBQEBBBMLEIdYmn2QO5VjgQQEmBeHYYQd X-IronPort-AV: E=Sophos;i="4.68,274,1312153200"; d="scan'208";a="506215442" X-IP-Direction: IN Received: from 81-86-43-86.dsl.pipex.com (HELO number15) ([81.86.43.86]) by smtp.pipex.tiscali.co.uk with ESMTP; 24 Aug 2011 12:37:23 +0100 From: Sender: "Mark" To: In-Reply-To: <95C5C7A891135E4685CCFAE997351F961F95D2@WABOTH9MSGUSR8B.ITServices.sbc.com> Date: Wed, 24 Aug 2011 12:37:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609 Thread-Index: AcxhfYb21yIfviBd6EKxcUMKfRxZBgACOdGAABZEISAADhAggAAM9CLA Message-Id: <20110824113618.ADF9D21F8B03@ietfa.amsl.com> Subject: [atoca] Alert flags versus MI range. 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 11:36:19 -0000 Hmm... :-) Thanks Peter, (With apologies to ATOCA members, I want to explore this question because, I promise, it does impact the matter in question). I wonder why the two bits that Brian kindly mentioned are not used by CMAS or EU-ALERT? I can't think of any specific reason why they should not, as the only real difference between them is the MI space used. So far as I can tell, those bits are not blocked when the MI range changes? If we used these bits, then we would be released from the "tyranny" of a fixed MI range for alerting; that may be valuable in the future especially in enterprise wireless networks where various private address ranges are typically deployed. Is there some reason why it is not being done, am I missing something? It seems to be so, that the alert requirement is 'deduced' by the terminal due to the MI. In that case (IMHO) we need to do some work to standardise the MI ranges used for 'alerts' so that terminal vendors can preset a whole range of them to Alert, just in case the user is roaming to a country which does not use either EU-ALERT, CMAS or ETWS. I suggest that if there were a 'well known' range of MIs exclusively for alerting, then member states could choose one to their liking (if they choose not to use one of the existing standards), and the special alert tone would work even for roamers. [Member states sometimes have their own reasons for needing a national solution]. Such a scheme is still being proposed at the ITU-T SG2 but has so far found no consensus. I am still concerned about this, because if any network operator chooses to use IP multicast as one means of alerting hosts, then referencing the framework used for CB may make some sense, at least for discussion. It is for others to propose the solution but we could at least have a suggestion that has a really good roadmap. Warm regards, Mark. -----Original Message----- From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of DALY, BRIAN K (ATTSI) Sent: 24 August 2011 05:40 To: Peter Sanders; 'Mark' Cc: atoca@ietf.org Subject: Re: [atoca] iOS 5 tied into Japanese early warning system Thanks for that clarification Peter. CMAS also has FCC-defined alert tones and vibration cadences that are triggered by the cell broadcast message identifier. From bd2985@att.com Wed Aug 24 06:34:40 2011 Return-Path: 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 9ED2621F8B87 for ; Wed, 24 Aug 2011 06:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 Fi6cs4bYsnsz for ; Wed, 24 Aug 2011 06:34:40 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id EBE8621F8B5E for ; Wed, 24 Aug 2011 06:34:39 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: bd2985@att.com X-Msg-Ref: server-5.tower-120.messagelabs.com!1314192949!34434762!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [144.160.112.28] Received: (qmail 26464 invoked from network); 24 Aug 2011 13:35:49 -0000 Received: from sbcsmtp3.sbc.com (HELO tlpi048.enaf.dadc.sbc.com) (144.160.112.28) by server-5.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 Aug 2011 13:35:49 -0000 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by tlpi048.enaf.dadc.sbc.com (8.14.4/8.14.4) with ESMTP id p7ODZmJv009582; Wed, 24 Aug 2011 08:35:48 -0500 Received: from WABOTH9MSGHUB8B.ITServices.sbc.com (waboth9msghub8b.itservices.sbc.com [135.163.35.101]) by tlpi048.enaf.dadc.sbc.com (8.14.4/8.14.4) with ESMTP id p7ODZgKY009503; Wed, 24 Aug 2011 08:35:42 -0500 Received: from WABOTH9MSGUSR8B.ITServices.sbc.com ([169.254.2.17]) by WABOTH9MSGHUB8B.ITServices.sbc.com ([135.163.35.101]) with mapi id 14.01.0289.001; Wed, 24 Aug 2011 06:35:26 -0700 From: "DALY, BRIAN K (ATTSI)" To: "mark.wood@engineer.com" , "atoca@ietf.org" Thread-Topic: [atoca] Alert flags versus MI range. Thread-Index: AQHMYmKuIuERSmRQlkSLxab2JeWonQ== Date: Wed, 24 Aug 2011 13:35:25 +0000 Message-ID: <95C5C7A891135E4685CCFAE997351F961FA62F@WABOTH9MSGUSR8B.ITServices.sbc.com> References: <95C5C7A891135E4685CCFAE997351F961F95D2@WABOTH9MSGUSR8B.ITServices.sbc.com> <20110824113618.ADF9D21F8B03@ietfa.amsl.com> In-Reply-To: <20110824113618.ADF9D21F8B03@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.163.34.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [atoca] Alert flags versus MI range. 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 13:34:40 -0000 Mark - I think this is a discussion outside ATOCA and would be happy to explore fu= rther. -------- Brian K. Daly Director, Core Network & Govn't/Regulatory Standards AT&T Services, Inc. +1.425.580.6873 brian.k.daly@att.com Rethink Possible -----Original Message----- From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of m= ark.wood@engineer.com Sent: Wednesday, August 24, 2011 4:37 AM To: atoca@ietf.org Subject: [atoca] Alert flags versus MI range. Hmm... :-) Thanks Peter, (With apologies to ATOCA members, I want to explore this question because, = I promise, it does impact the matter in question).=20 I wonder why the two bits that Brian kindly mentioned are not used by CMAS or EU-ALERT? I can't think of any specific reason why they should not, as the only real difference between them is the MI space used. So far as I can tell, those bits are not blocked when the MI range changes? If we used these bits, then we would be released from the "tyranny" of a fixed MI range for alerting; that may be valuable in the future especially in enterprise wireless networks where various private address ranges are typically deployed.=20 Is there some reason why it is not being done, am I missing something?=20 It seems to be so, that the alert requirement is 'deduced' by the terminal due to the MI.=20 In that case (IMHO) we need to do some work to standardise the MI ranges used for 'alerts' so that terminal vendors can preset a whole range of them to Alert, just in case the user is roaming to a country which does not use either EU-ALERT, CMAS or ETWS.=20 I suggest that if there were a 'well known' range of MIs exclusively for alerting, then member states could choose one to their liking (if they choose not to use one of the existing standards), and the special alert ton= e would work even for roamers. [Member states sometimes have their own reason= s for needing a national solution].=20 Such a scheme is still being proposed at the ITU-T SG2 but has so far found no consensus.=20 I am still concerned about this, because if any network operator chooses to use IP multicast as one means of alerting hosts, then referencing the framework used for CB may make some sense, at least for discussion. It is for others to propose the solution but we could at least have a suggestion that has a really good roadmap. Warm regards, Mark. =20 -----Original Message----- From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of DALY, BRIAN K (ATTSI) Sent: 24 August 2011 05:40 To: Peter Sanders; 'Mark' Cc: atoca@ietf.org Subject: Re: [atoca] iOS 5 tied into Japanese early warning system Thanks for that clarification Peter. CMAS also has FCC-defined alert tones and vibration cadences that are triggered by the cell broadcast message identifier. _______________________________________________ atoca mailing list atoca@ietf.org https://www.ietf.org/mailman/listinfo/atoca From keith.drage@alcatel-lucent.com Wed Aug 24 08:20:56 2011 Return-Path: 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 5C4C421F86C1 for ; Wed, 24 Aug 2011 08:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.82 X-Spam-Level: X-Spam-Status: No, score=-105.82 tagged_above=-999 required=5 tests=[AWL=0.429, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 NHxikfelO5qN for ; Wed, 24 Aug 2011 08:20:55 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0469E21F8770 for ; Wed, 24 Aug 2011 08:20:53 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p7OFLTLf003543 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 24 Aug 2011 17:21:57 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 24 Aug 2011 17:21:54 +0200 From: "DRAGE, Keith (Keith)" To: "mark.wood@engineer.com" , "atoca@ietf.org" Date: Wed, 24 Aug 2011 17:21:52 +0200 Thread-Topic: [atoca] Alert flags versus MI range. Thread-Index: AcxhfYb21yIfviBd6EKxcUMKfRxZBgACOdGAABZEISAADhAggAAM9CLAAAf1AQA= Message-ID: References: <95C5C7A891135E4685CCFAE997351F961F95D2@WABOTH9MSGUSR8B.ITServices.sbc.com> <20110824113618.ADF9D21F8B03@ietfa.amsl.com> In-Reply-To: <20110824113618.ADF9D21F8B03@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [atoca] Alert flags versus MI range. 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 15:20:56 -0000 For 3GPP public warning systems, the list of allocated message identifiers = for alerts is managed by 3GPP. What is happening is that while there are various national or regional aler= ting schemes for alerting, values of similar importance in different nation= al or regional areas are allocated the same message identifier, to allow ro= aming terminals with alerts turned on to receive alerts pertaining to the c= ountry they are visiting. A Korean one is currently under discussion. If you need to register (create) a new national scheme, talk to 3GPP - they= will appropriately update the specifications after discussion. Keith > -----Original Message----- > From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of > mark.wood@engineer.com > Sent: 24 August 2011 12:37 > To: atoca@ietf.org > Subject: [atoca] Alert flags versus MI range. >=20 >=20 > Hmm... :-) >=20 > Thanks Peter, >=20 > (With apologies to ATOCA members, I want to explore this question because= , > I > promise, it does impact the matter in question). >=20 > I wonder why the two bits that Brian kindly mentioned are not used by CMA= S > or EU-ALERT? I can't think of any specific reason why they should not, as > the only real difference between them is the MI space used. So far as I > can > tell, those bits are not blocked when the MI range changes? >=20 > If we used these bits, then we would be released from the "tyranny" of a > fixed MI range for alerting; that may be valuable in the future especiall= y > in enterprise wireless networks where various private address ranges are > typically deployed. >=20 > Is there some reason why it is not being done, am I missing something? >=20 >=20 > It seems to be so, that the alert requirement is 'deduced' by the termina= l > due to the MI. >=20 > In that case (IMHO) we need to do some work to standardise the MI ranges > used for 'alerts' so that terminal vendors can preset a whole range of > them > to Alert, just in case the user is roaming to a country which does not us= e > either EU-ALERT, CMAS or ETWS. >=20 > I suggest that if there were a 'well known' range of MIs exclusively for > alerting, then member states could choose one to their liking (if they > choose not to use one of the existing standards), and the special alert > tone > would work even for roamers. [Member states sometimes have their own > reasons > for needing a national solution]. >=20 > Such a scheme is still being proposed at the ITU-T SG2 but has so far > found > no consensus. >=20 > I am still concerned about this, because if any network operator chooses > to > use IP multicast as one means of alerting hosts, then referencing the > framework used for CB may make some sense, at least for discussion. It is > for others to propose the solution but we could at least have a suggestio= n > that has a really good roadmap. >=20 > Warm regards, Mark. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of > DALY, BRIAN K (ATTSI) > Sent: 24 August 2011 05:40 > To: Peter Sanders; 'Mark' > Cc: atoca@ietf.org > Subject: Re: [atoca] iOS 5 tied into Japanese early warning system >=20 > Thanks for that clarification Peter. >=20 > CMAS also has FCC-defined alert tones and vibration cadences that are > triggered by the cell broadcast message identifier. >=20 > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From peter.sanders@one2many.eu Wed Aug 24 08:21:38 2011 Return-Path: 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 833E721F8BDC for ; Wed, 24 Aug 2011 08:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MSGID_MULTIPLE_AT=1.449] 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 v+Z3UzK80noY for ; Wed, 24 Aug 2011 08:21:38 -0700 (PDT) Received: from smtp.byte.nl (mailgw3.c1.byte.nl [82.94.214.67]) by ietfa.amsl.com (Postfix) with ESMTP id B266C21F8839 for ; Wed, 24 Aug 2011 08:21:37 -0700 (PDT) Received: from peters (5249686E.cm-4-2b.dynamic.ziggo.nl [82.73.104.110]) (Authenticated sender: onema004) by smtp.byte.nl (Postfix) with ESMTPA id C75948352; Wed, 24 Aug 2011 17:22:45 +0200 (CEST) From: "Peter Sanders" To: References: <95C5C7A891135E4685CCFAE997351F961F95D2@WABOTH9MSGUSR8B.ITServices.sbc.com> <20110824113618.ADF9D21F8B03@ietfa.amsl.com> In-Reply-To: <20110824113618.ADF9D21F8B03@ietfa.amsl.com> Date: Wed, 24 Aug 2011 17:22:45 +0200 Organization: one2many Message-ID: <002801cc6271$ad14f4c0$073ede40$@sanders@one2many.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxhfYb21yIfviBd6EKxcUMKfRxZBgACOdGAABZEISAADhAggAAM9CLAAAjjhqA= Content-Language: nl Cc: atoca@ietf.org Subject: Re: [atoca] Alert flags versus MI range. 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 15:21:38 -0000 A more logical method than (mis)using the serial number to trigger the special alert tone would have been to use the Data Coding Scheme for that. After all, the DCS tells the mobile device how the message is to be decoded and subsequently displayed. However, 3GPP has chosen to link the special alert tone to the range of PWS MI range. The MI range for PWS is quite large: from 4360 - 6399, and the special alert tone should be triggered by any MI in this range. Since 3GPP has chosen to link the alerting tone to this MI range, changing that can only happen if there is no backwards compatibility problem, and there are compelling reasons to do so. Otherwise.... Best regards, Peter -----Original Message----- From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of mark.wood@engineer.com Sent: woensdag 24 augustus 2011 13:37 To: atoca@ietf.org Subject: [atoca] Alert flags versus MI range. Hmm... :-) Thanks Peter, (With apologies to ATOCA members, I want to explore this question because, I promise, it does impact the matter in question). I wonder why the two bits that Brian kindly mentioned are not used by CMAS or EU-ALERT? I can't think of any specific reason why they should not, as the only real difference between them is the MI space used. So far as I can tell, those bits are not blocked when the MI range changes? If we used these bits, then we would be released from the "tyranny" of a fixed MI range for alerting; that may be valuable in the future especially in enterprise wireless networks where various private address ranges are typically deployed. Is there some reason why it is not being done, am I missing something? It seems to be so, that the alert requirement is 'deduced' by the terminal due to the MI. In that case (IMHO) we need to do some work to standardise the MI ranges used for 'alerts' so that terminal vendors can preset a whole range of them to Alert, just in case the user is roaming to a country which does not use either EU-ALERT, CMAS or ETWS. I suggest that if there were a 'well known' range of MIs exclusively for alerting, then member states could choose one to their liking (if they choose not to use one of the existing standards), and the special alert tone would work even for roamers. [Member states sometimes have their own reasons for needing a national solution]. Such a scheme is still being proposed at the ITU-T SG2 but has so far found no consensus. I am still concerned about this, because if any network operator chooses to use IP multicast as one means of alerting hosts, then referencing the framework used for CB may make some sense, at least for discussion. It is for others to propose the solution but we could at least have a suggestion that has a really good roadmap. Warm regards, Mark. -----Original Message----- From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of DALY, BRIAN K (ATTSI) Sent: 24 August 2011 05:40 To: Peter Sanders; 'Mark' Cc: atoca@ietf.org Subject: Re: [atoca] iOS 5 tied into Japanese early warning system Thanks for that clarification Peter. CMAS also has FCC-defined alert tones and vibration cadences that are triggered by the cell broadcast message identifier. _______________________________________________ atoca mailing list atoca@ietf.org https://www.ietf.org/mailman/listinfo/atoca