From hannes.tschofenig@gmx.net Mon Jul 11 13:38:21 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 6B2E521F8654 for ; Mon, 11 Jul 2011 13:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 zreoBIdlALln for ; Mon, 11 Jul 2011 13:38:21 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 886ED11E80AB for ; Mon, 11 Jul 2011 13:38:17 -0700 (PDT) Received: (qmail invoked by alias); 11 Jul 2011 20:38:16 -0000 Received: from letku101.adsl.netsonic.fi (EHLO [10.0.0.6]) [194.29.195.101] by mail.gmx.net (mp060) with SMTP; 11 Jul 2011 22:38:16 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+jNKdfd5qjeGy+uui0H3KWhMEIzdZZ4Vz5T3mJw7 7FYBrx2BdFbpCl From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Jul 2011 23:38:14 +0300 Message-Id: <474098FE-520F-4A0E-BBEA-7546638F4A95@gmx.net> To: atoca@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [atoca] Audio Recording of the Prague ATOCA Session? 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, 11 Jul 2011 20:38:21 -0000 Hi all,=20 I was trying to find the audio recording of the Prague ATOCA = face-to-face meeting and I was unsuccessful.=20 The audio archive is here http://www.ietf.org/audio/ietf80/ and the = session was (according to the agenda) on Thursday afternoon but I = couldn't locate the session in any of the recordings.=20 Did someone by chance listen to the recording and knows where it is?=20 Ciao Hannes From hannes.tschofenig@gmx.net Mon Jul 11 14:44: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 3079011E82CC for ; Mon, 11 Jul 2011 14:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 ea2lOQIEWASy for ; Mon, 11 Jul 2011 14:44:18 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 016BF11E8098 for ; Mon, 11 Jul 2011 14:44:17 -0700 (PDT) Received: (qmail invoked by alias); 11 Jul 2011 21:44:16 -0000 Received: from letku214.adsl.netsonic.fi (EHLO [10.0.0.6]) [194.29.195.214] by mail.gmx.net (mp032) with SMTP; 11 Jul 2011 23:44:16 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+iSXQYT6qiEVOC2iOHjUdBnvLU/8fv0AI3fp1UW2 ACw45uujvvzHw/ Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Tue, 12 Jul 2011 00:44:14 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Art Botterell X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: atoca@ietf.org Subject: Re: [atoca] [Atoca] Remarks on the security discussion today 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, 11 Jul 2011 21:44:19 -0000 Hi Art,=20 I was trying to find the audio recording to tell you precisely what was = said but unfortunately I failed to spot them.=20 Reconstructing from my memory we had a fair amount of disagreement on = how the security mechanisms would look like. I tried to document that in = my summary mail and there were basically two different scenarios:=20 a) the school closed warning=20 This is essentially sending a message to a relatively small and closed = group of people where authorization is relatively simple since the = receivers have a relationship with the author. While it is possible to = use end-to-end security mechanisms there I am not sure it be done in = practice.=20 b) the Tsunami warning=20 Here the receivers are less likely going to have a relationship with the = author of the alert message. While end-to-end security would make sense = (for the purposes you listed below) it is difficult to say how they are = going to be enforced. What would the authorization policy for accepting = authors and originators look like? A challenge also seems that the XML = encoding of the message makes mass delivery a bit challenging and then = there is the XML digital signature on top of it. Brian discussed this = issue in his presentation = http://www.ietf.org/proceedings/80/slides/atoca-1.pdf but I am not = entirely sure I understand how he thinks this is going to work. If the = alert is distributed using IP multicast then the message better has to = fit into a UDP packet. The same is likely to be true if some layer 2 = mechanism is used.=20 To the point of your question: I was in my presentation = http://www.ietf.org/proceedings/80/slides/atoca-2.pdf a bit skeptical = whether existing deployments are going to invest in end-to-end security = infrastructure (which would be the case for security at the alert level) = when they have not done so for all the other things either. Folks in the = audience had a different view and said that there definitely has to be = an end-to-end security story for the alert distribution but the XML = digital signature mechanism was essentially a no-go for them.=20 Hope that helps! Ciao Hannes PS: What do you mean by " certification of an alert" in your remark = below?=20 On Mar 31, 2011, at 10:44 PM, Art Botterell wrote: >=20 > On Mar 31, 2011, at 12:35 PM, Hannes Tschofenig wrote: >=20 >> In the area of end-to-end security it was noticed that the deployment = reality of SIP (and XMPP) with regard to e2e security is rather weak. = Security at the alert level was seen as OK but XMLDSIG was not = acceptable.=20 >=20 > Hannes, could please you say a bit more about that? In particular, = what was meant by "OK" and "not acceptable"? >=20 > On a related note, I'd suggest that digital signatures may sometimes = be useful even in transitive trust regimes in order to make the = certification of an alert, wherever it occurred, provably persistent = over time for auditing and forensic purposes. >=20 > - Art >=20 > _______________________________________________ > earlywarning mailing list > earlywarning@ietf.org > https://www.ietf.org/mailman/listinfo/earlywarning From Martin.Thomson@commscope.com Wed Jul 27 08:20:21 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 EC25221F8A7E for ; Wed, 27 Jul 2011 08:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 WKIfgbft86Ek for ; Wed, 27 Jul 2011 08:20:20 -0700 (PDT) Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id 592C721F8A69 for ; Wed, 27 Jul 2011 08:20:17 -0700 (PDT) X-AuditID: 0a0404e9-b7cc4ae00000074e-64-4e302cb9b920 Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id 20.73.01870.9BC203E4; Wed, 27 Jul 2011 10:20:25 -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; Wed, 27 Jul 2011 10:20:16 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 27 Jul 2011 23:20:13 +0800 From: "Thomson, Martin" To: "atoca@ietf.org" Date: Wed, 27 Jul 2011 23:20:12 +0800 Thread-Topic: WG Direction Thread-Index: AcxMbsWIR7d76FFZRjeIyLnfzW56jw== Message-ID: <8B0A9FCBB9832F43971E38010638454F040D2C37A9@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] WG Direction 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, 27 Jul 2011 15:20:21 -0000 One of the topics that I want to discuss at the meeting on Friday is the fu= ture direction of the working group. This group has been very quiet. That= 's not good. I've spoken to a number of people about a plan for getting some work comple= ted. A rough sketch of that plan is in the chair slides that I've uploaded to th= e agenda. There are five parts to the plan: - Requirements - Architecture - Distribution - Broadcast - Security I would like to see progress on the first two soon. We can discuss times o= n Friday. Discuss. From hannes.tschofenig@gmx.net Wed Jul 27 09:21:16 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 F2F3311E80E0 for ; Wed, 27 Jul 2011 09:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 e7iNkBFyChAl for ; Wed, 27 Jul 2011 09:21:15 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id CEF7911E80D7 for ; Wed, 27 Jul 2011 09:21:14 -0700 (PDT) Received: (qmail invoked by alias); 27 Jul 2011 16:21:12 -0000 Received: from dhcp-172b.meeting.ietf.org (EHLO dhcp-172b.meeting.ietf.org) [130.129.23.43] by mail.gmx.net (mp051) with SMTP; 27 Jul 2011 18:21:12 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+DNQgFN/mDJd9aP9D96hKWejMpWSnIzS/+mIcdXB 8Z8AkTtqcAg2Ne Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <8B0A9FCBB9832F43971E38010638454F040D2C37A9@SISPE7MB1.commscope.com> Date: Wed, 27 Jul 2011 12:21:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1B84E9D9-6211-433D-A14F-F042CC6895C8@gmx.net> References: <8B0A9FCBB9832F43971E38010638454F040D2C37A9@SISPE7MB1.commscope.com> To: "Thomson, Martin" X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "atoca@ietf.org" Subject: Re: [atoca] WG Direction 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, 27 Jul 2011 16:21:16 -0000 Hi Martin,=20 thank you for getting the discussion started again.=20 I believe a problem with the progress is that we still don't fully = understand how the envisioned communication architecture is going to = look like (despite the discussion we had at the last IETF meeting in = Prague).=20 =46rom the discussed scenarios I see two extreme scenarios:=20 (1) the "school is closed" scenario where notifications are being sent = point-to-point to a pre-defined list of devices (and users) using a = pub-sub mechanism.=20 Many of the security mechanisms are being dealt with at the time of = subscription.=20 I believe we can very easily support this scenario with the mechanisms = we have available today.=20 (2) The "tsunami warning" scenario where a point-to-multipoint / = broadcasting mechanism is envisioned. Here there are two communication legs that are relevant: =20 a) from the originator to some relay, and=20 b) from the relay to all the receivers.=20 There are lots of solutions for (a) and I don't think that further work = is needed there. For (b) we do not yet know how this is supposed to = work... We should use the meeting time to figure out how the bigger picture is = supposed to work and then we can capture those aspects in the = architecture work.=20 Ciao Hannes On Jul 27, 2011, at 11:20 AM, Thomson, Martin wrote: > One of the topics that I want to discuss at the meeting on Friday is = the future direction of the working group. This group has been very = quiet. That's not good. >=20 > I've spoken to a number of people about a plan for getting some work = completed. >=20 > A rough sketch of that plan is in the chair slides that I've uploaded = to the agenda. There are five parts to the plan: >=20 > - Requirements > - Architecture > - Distribution > - Broadcast > - Security >=20 > I would like to see progress on the first two soon. We can discuss = times on Friday. >=20 > Discuss. > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From Martin.Thomson@commscope.com Wed Jul 27 09:41: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 1493021F88DC for ; Wed, 27 Jul 2011 09:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 Y0ntEnENrHuJ for ; Wed, 27 Jul 2011 09:41:14 -0700 (PDT) Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id 4971B21F88B7 for ; Wed, 27 Jul 2011 09:41:14 -0700 (PDT) X-AuditID: 0a0404e9-b7cc4ae00000074e-d9-4e303fb2b632 Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id B8.B6.01870.2BF303E4; Wed, 27 Jul 2011 11:41:23 -0500 (CDT) Received: from CDCE10HC1.commscope.com (10.86.20.21) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.159.2; Wed, 27 Jul 2011 11:41:13 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by CDCE10HC1.commscope.com (10.86.20.21) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 27 Jul 2011 11:41:07 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Thu, 28 Jul 2011 00:41:04 +0800 From: "Thomson, Martin" To: Hannes Tschofenig Date: Thu, 28 Jul 2011 00:41:02 +0800 Thread-Topic: [atoca] WG Direction Thread-Index: AcxMeTZ02DD/y4AXSxmQc04IMhUKRwAASUyA Message-ID: <8B0A9FCBB9832F43971E38010638454F040D2C37AB@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F040D2C37A9@SISPE7MB1.commscope.com> <1B84E9D9-6211-433D-A14F-F042CC6895C8@gmx.net> In-Reply-To: <1B84E9D9-6211-433D-A14F-F042CC6895C8@gmx.net> 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] WG Direction 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, 27 Jul 2011 16:41:15 -0000 You have it right. The problem is that we don't have any of the pieces that we understand writ= ten down. The model in the requirements document doesn't include a descrip= tion of these cases and how those fit together. Brian has promised to corr= ect that. We need to discuss the bits where we don't have a common understanding. Se= eing some proposals should help coalesce opinions. Without text - accurate= , consensus or otherwise - as a baseline, we simply aren't making progress. --Martin On 2011-07-27 at 12:21:09, Hannes Tschofenig wrote: > Hi Martin, >=20 > thank you for getting the discussion started again. >=20 > I believe a problem with the progress is that we still don't fully=20 > understand how the envisioned communication architecture is going to=20 > look like (despite the discussion we had at the last IETF meeting in=20 > Prague). >=20 > From the discussed scenarios I see two extreme scenarios: >=20 > (1) the "school is closed" scenario where notifications are being sent=20 > point-to-point to a pre-defined list of devices (and users) using a=20 > pub-sub mechanism. > Many of the security mechanisms are being dealt with at the time of=20 > subscription. >=20 > I believe we can very easily support this scenario with the mechanisms=20 > we have available today. >=20 > (2) The "tsunami warning" scenario where a point-to-multipoint /=20 > broadcasting mechanism is envisioned. > Here there are two communication legs that are relevant: > a) from the originator to some relay, and > b) from the relay to all the receivers. >=20 > There are lots of solutions for (a) and I don't think that further=20 > work is needed there. For (b) we do not yet know how this is supposed=20 > to work... >=20 > We should use the meeting time to figure out how the bigger picture is=20 > supposed to work and then we can capture those aspects in the=20 > architecture work. >=20 > Ciao > Hannes >=20 >=20 > On Jul 27, 2011, at 11:20 AM, Thomson, Martin wrote: >=20 > > One of the topics that I want to discuss at the meeting on Friday is > the future direction of the working group. This group has been very=20 > quiet. That's not good. > > > > I've spoken to a number of people about a plan for getting some work > completed. > > > > A rough sketch of that plan is in the chair slides that I've=20 > > uploaded > to the agenda. There are five parts to the plan: > > > > - Requirements > > - Architecture > > - Distribution > > - Broadcast > > - Security > > > > I would like to see progress on the first two soon. We can discuss > times on Friday. > > > > Discuss. > > _______________________________________________ > > atoca mailing list > > atoca@ietf.org > > https://www.ietf.org/mailman/listinfo/atoca From creed@opengeospatial.org Wed Jul 27 11:56: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 C988D11E8145 for ; Wed, 27 Jul 2011 11:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, STOX_REPLY_TYPE=0.001] 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 NpV+-N3qjVWb for ; Wed, 27 Jul 2011 11:56:41 -0700 (PDT) Received: from mail.opengeospatial.org (scale.ogcinc.net [66.244.86.102]) by ietfa.amsl.com (Postfix) with ESMTP id 3B07111E8141 for ; Wed, 27 Jul 2011 11:56:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.opengeospatial.org (Postfix) with ESMTP id 5C6B25A19D; Wed, 27 Jul 2011 14:56:40 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at mail.ogcinc.net Received: from mail.opengeospatial.org ([127.0.0.1]) by localhost (mail.opengeospatial.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXkIsWrViOeq; Wed, 27 Jul 2011 14:56:39 -0400 (EDT) Received: from CarlandSusieOf (c-98-245-174-99.hsd1.co.comcast.net [98.245.174.99]) by mail.opengeospatial.org (Postfix) with ESMTPSA id A28C45A195; Wed, 27 Jul 2011 14:56:39 -0400 (EDT) Message-ID: <2C4B498C33BC4A46A6D88FE1BDB855E6@CarlandSusieOf> From: "Carl Reed" To: "Hannes Tschofenig" , "Thomson, Martin" References: <8B0A9FCBB9832F43971E38010638454F040D2C37A9@SISPE7MB1.commscope.com> <1B84E9D9-6211-433D-A14F-F042CC6895C8@gmx.net> In-Reply-To: <1B84E9D9-6211-433D-A14F-F042CC6895C8@gmx.net> Date: Wed, 27 Jul 2011 12:54:08 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18416 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18645 Cc: atoca@ietf.org Subject: Re: [atoca] WG Direction 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, 27 Jul 2011 18:56:42 -0000 There may be some useful use case and requirements information related to deployed, operational debris flow and tsunami warning systems. There is also, I suspect, considerable technical information. Both examples are from the Asia community and are quite mature operational systems - and standards based! I can provide more information if desired. Cheers Carl ----- Original Message ----- From: "Hannes Tschofenig" To: "Thomson, Martin" Cc: Sent: Wednesday, July 27, 2011 10:21 AM Subject: Re: [atoca] WG Direction > Hi Martin, > > thank you for getting the discussion started again. > > I believe a problem with the progress is that we still don't fully > understand how the envisioned communication architecture is going to look > like (despite the discussion we had at the last IETF meeting in Prague). > > From the discussed scenarios I see two extreme scenarios: > > (1) the "school is closed" scenario where notifications are being sent > point-to-point to a pre-defined list of devices (and users) using a > pub-sub mechanism. > Many of the security mechanisms are being dealt with at the time of > subscription. > > I believe we can very easily support this scenario with the mechanisms we > have available today. > > (2) The "tsunami warning" scenario where a point-to-multipoint / > broadcasting mechanism is envisioned. > Here there are two communication legs that are relevant: > a) from the originator to some relay, and > b) from the relay to all the receivers. > > There are lots of solutions for (a) and I don't think that further work is > needed there. For (b) we do not yet know how this is supposed to work... > > We should use the meeting time to figure out how the bigger picture is > supposed to work and then we can capture those aspects in the architecture > work. > > Ciao > Hannes > > > On Jul 27, 2011, at 11:20 AM, Thomson, Martin wrote: > >> One of the topics that I want to discuss at the meeting on Friday is the >> future direction of the working group. This group has been very quiet. >> That's not good. >> >> I've spoken to a number of people about a plan for getting some work >> completed. >> >> A rough sketch of that plan is in the chair slides that I've uploaded to >> the agenda. There are five parts to the plan: >> >> - Requirements >> - Architecture >> - Distribution >> - Broadcast >> - Security >> >> I would like to see progress on the first two soon. We can discuss times >> on Friday. >> >> Discuss. >> _______________________________________________ >> 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 hgs@cs.columbia.edu Wed Jul 27 19:05:06 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 E42C511E80FD for ; Wed, 27 Jul 2011 19:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7Fv8PIBkLtm for ; Wed, 27 Jul 2011 19:05:06 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by ietfa.amsl.com (Postfix) with ESMTP id F0C8F11E808E for ; Wed, 27 Jul 2011 19:05:05 -0700 (PDT) Received: from new-host-2.home (pool-173-54-225-113.nwrknj.fios.verizon.net [173.54.225.113]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id p6S251bQ009360 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 Jul 2011 22:05:02 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: <1B84E9D9-6211-433D-A14F-F042CC6895C8@gmx.net> Date: Wed, 27 Jul 2011 22:05:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <52BA2E4F-2048-4A79-BB47-34BC178C476D@cs.columbia.edu> References: <8B0A9FCBB9832F43971E38010638454F040D2C37A9@SISPE7MB1.commscope.com> <1B84E9D9-6211-433D-A14F-F042CC6895C8@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1244.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.8 Cc: "atoca@ietf.org" Subject: Re: [atoca] WG Direction 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, 28 Jul 2011 02:05:07 -0000 If the relay is close to the base station and on the same subnet as all = mobiles, normal IP multicast would work ("all hosts"). For example, this = could work on campus, although some campus WiFi systems have, from what = I've heard, disabled multicast to deal with mDNS flooding. Yes, this = does require carrier/operator cooperation, but some countries already = mandate CMAS support, which also requires carrier participation. Henning On Jul 27, 2011, at 12:21 PM, Hannes Tschofenig wrote: > Hi Martin,=20 >=20 > thank you for getting the discussion started again.=20 >=20 > I believe a problem with the progress is that we still don't fully = understand how the envisioned communication architecture is going to = look like (despite the discussion we had at the last IETF meeting in = Prague).=20 >=20 > =46rom the discussed scenarios I see two extreme scenarios:=20 >=20 > (1) the "school is closed" scenario where notifications are being sent = point-to-point to a pre-defined list of devices (and users) using a = pub-sub mechanism.=20 > Many of the security mechanisms are being dealt with at the time of = subscription.=20 >=20 > I believe we can very easily support this scenario with the mechanisms = we have available today.=20 >=20 > (2) The "tsunami warning" scenario where a point-to-multipoint / = broadcasting mechanism is envisioned. > Here there are two communication legs that are relevant: =20 > a) from the originator to some relay, and=20 > b) from the relay to all the receivers.=20 >=20 > There are lots of solutions for (a) and I don't think that further = work is needed there. For (b) we do not yet know how this is supposed to = work... >=20 > We should use the meeting time to figure out how the bigger picture is = supposed to work and then we can capture those aspects in the = architecture work.=20 >=20 > Ciao > Hannes >=20 >=20 > On Jul 27, 2011, at 11:20 AM, Thomson, Martin wrote: >=20 >> One of the topics that I want to discuss at the meeting on Friday is = the future direction of the working group. This group has been very = quiet. That's not good. >>=20 >> I've spoken to a number of people about a plan for getting some work = completed. >>=20 >> A rough sketch of that plan is in the chair slides that I've uploaded = to the agenda. There are five parts to the plan: >>=20 >> - Requirements >> - Architecture >> - Distribution >> - Broadcast >> - Security >>=20 >> I would like to see progress on the first two soon. We can discuss = times on Friday. >>=20 >> Discuss. >> _______________________________________________ >> 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 >=20 From Martin.Thomson@commscope.com Thu Jul 28 06:23: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 6952C21F8BC1 for ; Thu, 28 Jul 2011 06:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 ogvj46BthU9T for ; Thu, 28 Jul 2011 06:23:14 -0700 (PDT) Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id C351721F8C44 for ; Thu, 28 Jul 2011 06:23:14 -0700 (PDT) X-AuditID: 0a0404e8-b7c24ae000002adb-cb-4e3162cea7eb Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id E8.10.10971.EC2613E4; Thu, 28 Jul 2011 08:23:26 -0500 (CDT) Received: from CDCE10HC2.commscope.com (10.86.20.22) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 28 Jul 2011 08:23:14 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by CDCE10HC2.commscope.com (10.86.20.22) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 28 Jul 2011 08:23:13 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Thu, 28 Jul 2011 21:23:10 +0800 From: "Thomson, Martin" To: Henning Schulzrinne , Hannes Tschofenig Date: Thu, 28 Jul 2011 21:23:09 +0800 Thread-Topic: [atoca] WG Direction Thread-Index: AcxMysRduS2+mpQ4QOaqZwZkUG6x7AAXkx1A Message-ID: <8B0A9FCBB9832F43971E38010638454F040D2C391D@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F040D2C37A9@SISPE7MB1.commscope.com> <1B84E9D9-6211-433D-A14F-F042CC6895C8@gmx.net> <52BA2E4F-2048-4A79-BB47-34BC178C476D@cs.columbia.edu> In-Reply-To: <52BA2E4F-2048-4A79-BB47-34BC178C476D@cs.columbia.edu> 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] WG Direction 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, 28 Jul 2011 13:23:15 -0000 On 2011-07-27 at 22:05:01, Henning Schulzrinne wrote: > Yes, this does require carrier/operator cooperation, but=20 > some countries already mandate CMAS support, which also requires=20 > carrier participation. An important point to keep in mind. There is very little an authority can = do without support from the local network. From mark.wood@drcf.net Thu Jul 28 05:49:11 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 664C821F8BD6 for ; Thu, 28 Jul 2011 05:49:11 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vLX16OteEa0 for ; Thu, 28 Jul 2011 05:49:10 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by ietfa.amsl.com (Postfix) with ESMTP id 07B8721F8C7A for ; Thu, 28 Jul 2011 05:49:09 -0700 (PDT) X-Trace: 459664867/mk-outboundfilter-2.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.17514 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFACxaMU5RVitW/2dsb2JhbAA0AQEBAQIBAQEBBTggEwQCAQsFBwEGBwMOAwEDAQEBCQQPFxsGEgwHEAMLCAEBAwIBFg8RpzV4iHwCAsUUgg6BBASXcYdXg144 X-IronPort-AV: E=Sophos;i="4.67,282,1309734000"; d="scan'208";a="459664867" 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; 28 Jul 2011 13:49:05 +0100 From: "Mark" To: "'Henning Schulzrinne'" , "'Hannes Tschofenig'" In-Reply-To: <52BA2E4F-2048-4A79-BB47-34BC178C476D@cs.columbia.edu> Date: Thu, 28 Jul 2011 13:49:06 +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.17514 Thread-Index: AcxMys/ILrwUgU+STY2+9VQUcKbqigAVL6Lg Message-Id: <20110728124910.07B8721F8C7A@ietfa.amsl.com> X-Mailman-Approved-At: Thu, 28 Jul 2011 06:28:02 -0700 Cc: atoca@ietf.org Subject: Re: [atoca] WG Direction 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, 28 Jul 2011 12:49:11 -0000 Hi Guys, Mark Wood DRCF. My apologies for missing Prague, I assure you that I am deeply engaged, but not always available for travel :-) I think we should all consider that at some point any PUBLIC mobile system, whether it is GSM LTE or any other form of wireless technology, will have to have some or other point-to-multipoint geo specific bearer service, (like Cell Broadcast in mobile systems), in order to meet national requirements regarding public warning systems (PWS). It is likely to be mandatory in many countries. Private Enterprise systems are another matter, but the technological implications are just the same imho. I feel that the use of multicast is the obvious way to do that, and that it can be easily managed if we have a pre defined multicast address space for this purpose, so that administrators can admit this traffic without any fear of flooding their networks. We can pick a handy range of 255 addresses in V4 and a matching set in V6, The existing IGMP and PIM protocols seem to be able to handle this, but we clearly need an expert to investigate the matter further. (BTW this will be the subject of my Masters thesis next year). After all, the amount of traffic sent by PWS is no more than 80 bytes per minute or so, just a line of plain text, and then only during the disaster! In normal times it is almost nil (apart from hourly 80 byte heartbeat messages) so its really trivial amounts of traffic we are talking about here, worries about multicast causing flooding are not justified in this application. The traffic worry is, from people, on learning of the problem, then watching steaming Unicast video streams from CNN, so the warning system contribution is trivially small in comparison. However due to the above concern, we need really bullet proof QoS priority for multicast within this specific address range. Since the CAP X1303 protocol and the aggregator/gateway systems are taking shape now, (its all being successfully tested on live systems) it should not be hard to find an authentic source for the traffic and the authorised polygons to be sent to the multicast RPs, so imho it does not look as if we have an urgent need to re invent that wheel. But we DO need to look at how to make IP multicast *passively* geo specific. By comparison, the geo-specificity of a Cell Broadcast system is down to a single cell, which as you know is typically about 5Km radius or so. We don't really need geo specificity to resolutions any better than 'post code' level by the present requirements, which should be well within the ability of any campus administrator to handle, even manually. Cellular base stations have an entry in a 'Cell Data Base', which 'knows' the lat/long of the antenna for each logical cell and its azimuth. Its this data that is cached by the cell broadcast centre, and used to find antennas under the polygon of the cap message. Copies of the text are then sent to each cell that was a match in the cell data base table. There is no PIM or IGMP in Cellular Broadcast systems, though the Cell Broadcast Centre (CBC) serves as the Rendezvous point (RP). We urgently need to know how to mimic this passive geo-specificity in IP multicast systems. There are plenty of ways to do it, but we do need to start a discussion on what they are and how we can use them. However as Hannes says, I don't think that this has been fully explored yet. Warm regards, Mark Wood, on behalf of DRCF. (and CellCast). -----Original Message----- From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: 28 July 2011 03:05 To: Hannes Tschofenig Cc: atoca@ietf.org Subject: Re: [atoca] WG Direction If the relay is close to the base station and on the same subnet as all mobiles, normal IP multicast would work ("all hosts"). For example, this could work on campus, although some campus WiFi systems have, from what I've heard, disabled multicast to deal with mDNS flooding. Yes, this does require carrier/operator cooperation, but some countries already mandate CMAS support, which also requires carrier participation. Henning On Jul 27, 2011, at 12:21 PM, Hannes Tschofenig wrote: > Hi Martin, > > thank you for getting the discussion started again. > > I believe a problem with the progress is that we still don't fully understand how the envisioned communication architecture is going to look like (despite the discussion we had at the last IETF meeting in Prague). > > From the discussed scenarios I see two extreme scenarios: > > (1) the "school is closed" scenario where notifications are being sent point-to-point to a pre-defined list of devices (and users) using a pub-sub mechanism. > Many of the security mechanisms are being dealt with at the time of subscription. > > I believe we can very easily support this scenario with the mechanisms we have available today. > > (2) The "tsunami warning" scenario where a point-to-multipoint / broadcasting mechanism is envisioned. > Here there are two communication legs that are relevant: > a) from the originator to some relay, and > b) from the relay to all the receivers. > > There are lots of solutions for (a) and I don't think that further work is needed there. For (b) we do not yet know how this is supposed to work... > > We should use the meeting time to figure out how the bigger picture is supposed to work and then we can capture those aspects in the architecture work. > > Ciao > Hannes > > > On Jul 27, 2011, at 11:20 AM, Thomson, Martin wrote: > >> One of the topics that I want to discuss at the meeting on Friday is the future direction of the working group. This group has been very quiet. That's not good. >> >> I've spoken to a number of people about a plan for getting some work completed. >> >> A rough sketch of that plan is in the chair slides that I've uploaded to the agenda. There are five parts to the plan: >> >> - Requirements >> - Architecture >> - Distribution >> - Broadcast >> - Security >> >> I would like to see progress on the first two soon. We can discuss times on Friday. >> >> Discuss. >> _______________________________________________ >> 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 carlberg@g11.org.uk Thu Jul 28 06:35:48 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 811EF21F8B3D for ; Thu, 28 Jul 2011 06:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001] 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 MOiSYcFOE2kF for ; Thu, 28 Jul 2011 06:35:48 -0700 (PDT) Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by ietfa.amsl.com (Postfix) with ESMTP id C8D8821F8B34 for ; Thu, 28 Jul 2011 06:35:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=g11.org.uk; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To:MIME-Version:Content-Type:Content-Disposition:Content-Transfer-Encoding:User-Agent:X-Source:X-Source-Args:X-Source-Dir; b=Vhde7HFWtqZFxvGzOZuUk9Wy7zbsZwbtO7iKu041+/omC5AwpGgSAqa2OXSIas2x23D0chwOt/tN10fhzYMvaj+GdmwhPbFuhVZhkPfX4PQqIDbGFWhh0tc3uf9mafFH; Received: from localhost ([127.0.0.1]:31169) by portland.eukhosting.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QmQkT-0005V2-NN; Thu, 28 Jul 2011 13:35:37 +0000 Received: from 130.129.37.56 ([130.129.37.56]) by portland.eukhosting.net (Horde Framework) with HTTP; Thu, 28 Jul 2011 13:35:37 +0000 Message-ID: <20110728133537.18614wtgm71td3sw@portland.eukhosting.net> Date: Thu, 28 Jul 2011 13:35:37 +0000 From: carlberg@g11.org.uk To: "Thomson, Martin" References: <8B0A9FCBB9832F43971E38010638454F040D2C37A9@SISPE7MB1.commscope.com> <1B84E9D9-6211-433D-A14F-F042CC6895C8@gmx.net> <52BA2E4F-2048-4A79-BB47-34BC178C476D@cs.columbia.edu> <8B0A9FCBB9832F43971E38010638454F040D2C391D@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F040D2C391D@SISPE7MB1.commscope.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.9) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk X-Source: X-Source-Args: X-Source-Dir: Cc: "atoca@ietf.org" Subject: Re: [atoca] WG Direction 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, 28 Jul 2011 13:35:48 -0000 > On 2011-07-27 at 22:05:01, Henning Schulzrinne wrote: >> Yes, this does require carrier/operator cooperation, but >> some countries already mandate CMAS support, which also requires >> carrier participation. > > An important point to keep in mind. There is very little an > authority can do without support from the local network. this is in the context of expectations of additional services from the network. In the end, there is always unicast back to the host. I'd also observe that the thread has focused on variations of push models. there is also the pulled poll model from the end-user/consumer that can be constructive to leverage -- eg, being that some events like hurricanes span days in advance, and initially polling in the order of hour(s) provides sufficient information that can be later complemented by subsequent pushed information. -ken From artbotterell@gmail.com Thu Jul 28 07:48:21 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 5314521F8CBB for ; Thu, 28 Jul 2011 07:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 NWLHwt1G8scv for ; Thu, 28 Jul 2011 07:48:20 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id B43F021F8CAE for ; Thu, 28 Jul 2011 07:48:20 -0700 (PDT) Received: by mail-gx0-f172.google.com with SMTP id 19so2264858gxk.31 for ; Thu, 28 Jul 2011 07:48:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=aYsl5aFFTmbzf+MMQtx7B9AV18OUXM0exvMmxpyuwT4=; b=si5APOLBvsvPsmT4j7mfbzyP16bph6INWl/TcXXBVnU5x81WO9SZftwdexeSp3E/bZ qWSHCqDDL+HD1goJma6NHjIYdJaUJXvE6kVQaJWG9BGC7QWPyfZxivJRjFBFDYYlFsmc DDPtL5HEE+mmrx8oKFuPp9hjOJSrLEIzZ2wjI= Received: by 10.68.39.166 with SMTP id q6mr309865pbk.437.1311864499720; Thu, 28 Jul 2011 07:48:19 -0700 (PDT) Received: from [192.168.1.14] (99-182-125-96.lightspeed.frokca.sbcglobal.net [99.182.125.96]) by mx.google.com with ESMTPS id v2sm847333pbi.19.2011.07.28.07.48.17 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jul 2011 07:48:18 -0700 (PDT) Sender: Art Botterell Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Art Botterell In-Reply-To: <20110728124910.07B8721F8C7A@ietfa.amsl.com> Date: Thu, 28 Jul 2011 07:48:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110728124910.07B8721F8C7A@ietfa.amsl.com> To: atoca@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [atoca] WG Direction 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, 28 Jul 2011 14:48:21 -0000 On Jul 28, 2011, at 5:49 AM, Mark wrote: > By comparison, the geo-specificity of a Cell Broadcast system is down = to a > single cell, which as you know is typically about 5Km radius or so. We = don't > really need geo specificity to resolutions any better than 'post code' = level > by the present requirements, which should be well within the ability = of any > campus administrator to handle, even manually. Not sure how those "present requirements" were determined, but I'd be = cautious about confusing technical capabilities with functional = requirements. =20 Having run a community warning system for a number of years I can report = that we very frequently used the more precise geotargeting capability of = wireline systems to target messages down to areas of a square km or so, = and not infrequently down to a few city blocks. =20 In fact I'd go so far as to say that the utility of a warning technology = is proportional to the granularity of the geotargeting... there are lots = of cases where a warning might be issued except for the fear of = operational and/or political fallout from including too many recipients = for whom the warning is not actually relevant. =20 - Art From brian.rosen@neustar.biz Thu Jul 28 08:09: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 E691521F8C06 for ; Thu, 28 Jul 2011 08:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.019 X-Spam-Level: X-Spam-Status: No, score=-6.019 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] 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 FwFMrII2RowF for ; Thu, 28 Jul 2011 08:09:12 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id EFBB821F8B96 for ; Thu, 28 Jul 2011 08:09:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1311865735; x=1627214943; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=yuPo8W39E/Kj54gZ2s0j7 ffzfUEtWzSdRsRdoI+KPnE=; b=ETXjyz9Fn7vodIgB1kQk7LkzrYvGIYeJbn/a/ PrelOGulahLQ579oy+7i0IZaIaY0Zzi6Trwi8YiGvUH05/Y7A== Received: from ([10.31.13.242]) by stihiron2.va.neustar.com with ESMTP with TLS id 5202732.47892035; Thu, 28 Jul 2011 11:08:54 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Thu, 28 Jul 2011 11:08:53 -0400 From: "Rosen, Brian" To: "atoca@ietf.org" Date: Thu, 28 Jul 2011 11:08:53 -0400 Thread-Topic: How I think ATOCA works Thread-Index: AcxNOEOs8y3oAiSfSbGYOG0JsN2oPg== Message-ID: <739E47FD-9CA6-4E5B-BEE6-55EDB4832ED7@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: ALMxPLqkwKp+4l1SaejYOQ== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 28 Jul 2011 08:15:51 -0700 Subject: [atoca] How I think ATOCA works 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, 28 Jul 2011 15:09:13 -0000 How I think ATOCA works There is a nominal tree of distributors. It isn't really necessary for it = to be a tree, but that will be a common organization. The bottom ("root") = end of the tree corresponds roughly to the lower A levels of a PIDF (nation= , state/province, county). There is a forest guide between nations. The = top of the tree is nominally ISPs of various forms including enterprises, b= ut don't have to be. It is acceptable for some short circuiting of the tre= e. For example, a national ISP can connect to the national distributor and= not have to get national alerts from the state/province distributor. Dist= ributors can get alerts from any notifiers they know they need to. There is a discovery mechanism for clients to find its local distributor. = In addition to the ISPs, Subscription services are connected to the bottom = of the tree. These services are listed in the LoST server: you can query L= oST with a location, and obtain a list of the subscription servers that ser= ve that location. A Notifier is authorized by one of the bottom level distributors. An alert= is sent to a distributor via a CAP message, probably with SIP Sub/Not. It= is propagated up (not down) through the tree, with filtering for location = at every step. Aggregation of alerts may happen in other ways (because the= organization of distributors doesn't have to be a tree). The top level (ISP) distributors may use any available L2 broadcast mechani= sm for alerts that are location limited. Filtering is considered imperfect= , biased towards inclusion. This means any level may get alerts that may n= ot apply to them, and will have to filter. This includes the endpoints. Clients receive alerts from the top level distributors and subscription ser= vices. They are CAP messages probably just sent in UDP packets (fragmentat= ion has to work) on a dedicated port; Alerts with high importance are repl= icated - the more importance, the more replication. There is no acknowledge= ment. Subscriptions are accomplished with a web service subscribe transac= tion. It has a expiration time. There are no keep alives. Notifications = are indistinguishable from the broadcast mechanism (no acknowledgement). The LoST query also returns public keys of the A2 distributor. As alerts a= re propagated up, they are signed. This means the recipient has the key of= the entity that signed it. This is the ultimate security mechanism. Ther= e is a discovery mechanism for the broadcast distributor IP address which i= s secure. There is also a hash mechanism that is based on information retr= ieved from the LoST server. Security is multifaceted. The client only accepts alerts on the port. It = only accepts alerts from the IP addresses it learns are used by the distrib= utors. It checks the hash. It then checks the signature. We'll have to = secure the LoST data better, but we can spend some more cycles doing that, = because it's before the alert. = From brian.rosen@neustar.biz Thu Jul 28 08:11: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 DB56B21F886E for ; Thu, 28 Jul 2011 08:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.019 X-Spam-Level: X-Spam-Status: No, score=-6.019 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] 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 4gh2Cz-cO0vO for ; Thu, 28 Jul 2011 08:11:05 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 55BF021F8C0B for ; Thu, 28 Jul 2011 08:11:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1311865859; x=1627214943; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=yuPo8W39E/Kj54gZ2s0j7 ffzfUEtWzSdRsRdoI+KPnE=; b=JRKeWg37Afm8FRqVRKBo7VPTLWOg+hjyWDcnb SOqbXVpfRdMH5JUH/wOzE2Gqdx3CrUbydAD/ExbSPvt4O5I3w== Received: from ([10.31.13.242]) by stihiron2.va.neustar.com with ESMTP with TLS id 5202732.47892119; Thu, 28 Jul 2011 11:10:57 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Thu, 28 Jul 2011 11:10:56 -0400 From: "Rosen, Brian" To: "atoca@ietf.org" Date: Thu, 28 Jul 2011 11:10:56 -0400 Thread-Topic: How I think ATOCA works Thread-Index: AcxNOIzbrwcsOz1XS1e+QW1F57M94A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: tpchAFB9rHCtEmMgdwiM5Q== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 28 Jul 2011 08:15:52 -0700 Subject: [atoca] How I think ATOCA works 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, 28 Jul 2011 15:11:06 -0000 How I think ATOCA works There is a nominal tree of distributors. It isn't really necessary for it = to be a tree, but that will be a common organization. The bottom ("root") = end of the tree corresponds roughly to the lower A levels of a PIDF (nation= , state/province, county). There is a forest guide between nations. The = top of the tree is nominally ISPs of various forms including enterprises, b= ut don't have to be. It is acceptable for some short circuiting of the tre= e. For example, a national ISP can connect to the national distributor and= not have to get national alerts from the state/province distributor. Dist= ributors can get alerts from any notifiers they know they need to. There is a discovery mechanism for clients to find its local distributor. = In addition to the ISPs, Subscription services are connected to the bottom = of the tree. These services are listed in the LoST server: you can query L= oST with a location, and obtain a list of the subscription servers that ser= ve that location. A Notifier is authorized by one of the bottom level distributors. An alert= is sent to a distributor via a CAP message, probably with SIP Sub/Not. It= is propagated up (not down) through the tree, with filtering for location = at every step. Aggregation of alerts may happen in other ways (because the= organization of distributors doesn't have to be a tree). The top level (ISP) distributors may use any available L2 broadcast mechani= sm for alerts that are location limited. Filtering is considered imperfect= , biased towards inclusion. This means any level may get alerts that may n= ot apply to them, and will have to filter. This includes the endpoints. Clients receive alerts from the top level distributors and subscription ser= vices. They are CAP messages probably just sent in UDP packets (fragmentat= ion has to work) on a dedicated port; Alerts with high importance are repl= icated - the more importance, the more replication. There is no acknowledge= ment. Subscriptions are accomplished with a web service subscribe transac= tion. It has a expiration time. There are no keep alives. Notifications = are indistinguishable from the broadcast mechanism (no acknowledgement). The LoST query also returns public keys of the A2 distributor. As alerts a= re propagated up, they are signed. This means the recipient has the key of= the entity that signed it. This is the ultimate security mechanism. Ther= e is a discovery mechanism for the broadcast distributor IP address which i= s secure. There is also a hash mechanism that is based on information retr= ieved from the LoST server. Security is multifaceted. The client only accepts alerts on the port. It = only accepts alerts from the IP addresses it learns are used by the distrib= utors. It checks the hash. It then checks the signature. We'll have to = secure the LoST data better, but we can spend some more cycles doing that, = because it's before the alert. = From mark.wood@drcf.net Thu Jul 28 08:53: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 1ECAC21F8C66 for ; Thu, 28 Jul 2011 08:53:52 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTseLoJQ9NfU for ; Thu, 28 Jul 2011 08:53:51 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by ietfa.amsl.com (Postfix) with ESMTP id E56A121F8C5A for ; Thu, 28 Jul 2011 08:53:50 -0700 (PDT) X-Trace: 459731600/mk-outboundfilter-2.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.17514 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuoIAGmFMU5RVitW/2dsb2JhbAA7CDggMgUBByRFBh4HJgEBBSYRmDWPCniIfqMHpTmBBASXcYdXhBY X-IronPort-AV: E=Sophos;i="4.67,282,1309734000"; d="scan'208";a="459731600" 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; 28 Jul 2011 16:53:48 +0100 From: "Mark" Sender: "Mark" To: In-Reply-To: Date: Thu, 28 Jul 2011 16:53:50 +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.17514 Thread-Index: AcxNNXsNYYMUeGi6QBiAgdBv8EfKUQABIiwQ Message-Id: <20110728155350.E56A121F8C5A@ietfa.amsl.com> Subject: [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: Thu, 28 Jul 2011 15:53:52 -0000 Friends; Yes, Art is correct (as usual) :-) The more geo specific a message is, the more utility is has, especially down to very local jurisdictional levels where, which side of the street matters. Since a CAP message has a polygon with it, there is not much problem in using that as a very specific geo location parameter. ** I should declare at once, that I believe that all methods of warning should be used, the fact that I have been associated with the development of cell broadcast for many years does not mean that I have any resistance to other distribution methods as well, far from it; I actively work to include them all! ** My point was a different one; *Passive* Cell Broadcast can only target one individual cell. Every enabled device in the cell will receive the message. If you were using a larger 'cell' such as a 500kHz NAVTEX transmitter, you would have to assume that the receiving device has some method to filer out messages based on its location and the polygon sent in the message (as is done at sea). In cell broadcast we make the preliminary assumption that the mobile phone has no GPS system and is not a 'smart phone'. In that case the geo-specificity is implied if it gets the message or not (i.e. if it is anywhere in the cell), and the mobile needs have no knowledge of its position. But in the future, as GPS enabled smart phones become more common, we will be able to transmit the polygon along with the content and thus have 1M resolution without changing the technology that much, while still keeping it back compatible with the older legacy phones. This is the sort of thing we are working on now and rightly should be the goal. In IETF's interest, regarding distribution layer networks, wired, 802.11 or 802.16 cells, the same applies, if the host does not have any geo awareness, then it will have to imply it by the fact that the router or base station was commanded to multicast the message (or Unicast it). In some cases this may be a bit of a 'blunt instrument' at first, but in time, pinpoint specificity should be the goal, and it's do-able given the transmission of the CAP polygon to the router or base station along with the content. Transmitting to any base station that has any coverage under the polygon, then letting the hosts ignore information outside its position, means that the whole solution is passive, which matters when you are doing very massive scale alerting during overload events. Of course, using 'dial down' phone or fax, the location of the end of the line is known so the phone location can be implied by that, so the problem does not arise. Thanks art, good point. Mark From artbotterell@gmail.com Thu Jul 28 09:05:21 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 DF97E11E808D for ; Thu, 28 Jul 2011 09:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 luu77F6eWzwc for ; Thu, 28 Jul 2011 09:05:21 -0700 (PDT) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id E2B0311E8080 for ; Thu, 28 Jul 2011 09:05:20 -0700 (PDT) Received: by pzk6 with SMTP id 6so4462991pzk.26 for ; Thu, 28 Jul 2011 09:05:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=QJEJOs3XCMd34nnsUmvpO0wCHzBtzl6V0Y/FgfmVnJ0=; b=Li0zD1p3h9HWfPKbjNMnjLrpbODu0F7TBBX5+9qBTN6yeRM9r8rmPGshnFZs25VcD7 Qf2f+Q29KmCPPhUBQl8QYsMFCyvn9JIQEc0uKceRMDIY9yogNhwuX/ucLb8W/X3UBtS6 zo68wr870GEqhOvsFL+qTEKRzUtyoDa9jWZ4M= Received: by 10.68.51.231 with SMTP id n7mr486838pbo.115.1311869120058; Thu, 28 Jul 2011 09:05:20 -0700 (PDT) Received: from [192.168.1.14] (99-182-125-96.lightspeed.frokca.sbcglobal.net [99.182.125.96]) by mx.google.com with ESMTPS id b4sm1125661pba.75.2011.07.28.09.05.17 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jul 2011 09:05:18 -0700 (PDT) Sender: Art Botterell Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Art Botterell In-Reply-To: <20110728155350.E56A121F8C5A@ietfa.amsl.com> Date: Thu, 28 Jul 2011 09:05:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3CF55612-24DD-4C7E-8212-899909ABDA9E@incident.com> References: <20110728155350.E56A121F8C5A@ietfa.amsl.com> To: atoca@ietf.org X-Mailer: Apple Mail (2.1084) 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: Thu, 28 Jul 2011 16:05:22 -0000 And as usual Mark and I are in agreement! This does, however, point to = another interesting question... the extent to which routing decisions, = including but not limited to geographic ones, should be made toward the = center of the functional network or toward the edge... or perhaps = both/neither as in the case of content-centric networking. At Carnegie Mellon Silicon Valley we're working with Xerox PARC on = potential applications of CCN in disaster management. While I'm = sensitive to the fact that CCN remains controversial in some corners, = I'm wondering whether a CCN overlay might be useful as a framework for = alerting. - Art On Jul 28, 2011, at 8:53 AM, Mark wrote: >=20 > Friends; >=20 > Yes, Art is correct (as usual) :-) >=20 > The more geo specific a message is, the more utility is has, = especially down > to very local jurisdictional levels where, which side of the street = matters. > Since a CAP message has a polygon with it, there is not much problem = in > using that as a very specific geo location parameter. >=20 > ** > I should declare at once, that I believe that all methods of warning = should > be used, the fact that I have been associated with the development of = cell > broadcast for many years does not mean that I have any resistance to = other > distribution methods as well, far from it; I actively work to include = them > all! > ** >=20 > My point was a different one; >=20 > *Passive* Cell Broadcast can only target one individual cell. Every = enabled > device in the cell will receive the message. If you were using a = larger > 'cell' such as a 500kHz NAVTEX transmitter, you would have to assume = that > the receiving device has some method to filer out messages based on = its > location and the polygon sent in the message (as is done at sea).=20 >=20 > In cell broadcast we make the preliminary assumption that the mobile = phone > has no GPS system and is not a 'smart phone'. In that case the > geo-specificity is implied if it gets the message or not (i.e. if it = is > anywhere in the cell), and the mobile needs have no knowledge of its > position.=20 >=20 > But in the future, as GPS enabled smart phones become more common, we = will > be able to transmit the polygon along with the content and thus have = 1M > resolution without changing the technology that much, while still = keeping it > back compatible with the older legacy phones. This is the sort of = thing we > are working on now and rightly should be the goal. =20 >=20 > In IETF's interest, regarding distribution layer networks, wired, = 802.11 or > 802.16 cells, the same applies, if the host does not have any geo = awareness, > then it will have to imply it by the fact that the router or base = station > was commanded to multicast the message (or Unicast it).=20 >=20 > In some cases this may be a bit of a 'blunt instrument' at first, but = in > time, pinpoint specificity should be the goal, and it's do-able given = the > transmission of the CAP polygon to the router or base station along = with the > content.=20 >=20 > Transmitting to any base station that has any coverage under the = polygon, > then letting the hosts ignore information outside its position, means = that > the whole solution is passive, which matters when you are doing very = massive > scale alerting during overload events. >=20 > Of course, using 'dial down' phone or fax, the location of the end of = the > line is known so the phone location can be implied by that, so the = problem > does not arise. =20 >=20 > Thanks art, good point. >=20 > Mark >=20 >=20 > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From trutkowski@netmagic.com Thu Jul 28 09:38:27 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 3878321F8C6F for ; Thu, 28 Jul 2011 09:38:27 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kANNlTlVGcpm for ; Thu, 28 Jul 2011 09:38:26 -0700 (PDT) Received: from vms173007pub.verizon.net (vms173007pub.verizon.net [206.46.173.7]) by ietfa.amsl.com (Postfix) with ESMTP id E868321F8C65 for ; Thu, 28 Jul 2011 09:38:25 -0700 (PDT) Received: from [192.168.0.4] ([unknown] [173.72.136.146]) by vms173007.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0LP100ML5Y7DIF20@vms173007.mailsrvcs.net> for atoca@ietf.org; Thu, 28 Jul 2011 11:38:05 -0500 (CDT) Message-id: <4E319069.7050908@netmagic.com> Date: Thu, 28 Jul 2011 12:38:01 -0400 From: Tony Rutkowski Organization: NetMagic Associates User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:5.0) Gecko/20110701 Thunderbird/5.0 MIME-version: 1.0 To: Mark References: <20110728155350.E56A121F8C5A@ietfa.amsl.com> In-reply-to: <20110728155350.E56A121F8C5A@ietfa.amsl.com> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit Cc: atoca@ietf.org Subject: Re: [atoca] geo-specificity. X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: trutkowski@netmagic.com 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, 28 Jul 2011 16:38:27 -0000 A good overview of geolocation tagging needs and mechanisms can be gleaned from the April global CAP implementers workshop hosted by the WMO http://www.wmo.int/pages/prog/www/ISS/Meetings/WIS-CAP_Geneva2011/DocPlan.html At the event, clever geo-tagging implementations by both Beidou and Google were described. The use of OIDs for some of these purposes in the allotted alerting arc 2.49 and in conjunction with the DNS based OID resolution system was also described there. Because OIDs are also embedded in digital certs and network elements, they can be further exploited for needed geotagging. --tony On 7/28/2011 11:53 AM, Mark wrote: > The more geo specific a message is, the more utility is has, especially down > to very local jurisdictional levels where, which side of the street matters. > Since a CAP message has a polygon with it, there is not much problem in > using that as a very specific geo location parameter. > From Martin.Thomson@commscope.com Sat Jul 30 06:53: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 709A721F8A30 for ; Sat, 30 Jul 2011 06:53:46 -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 EIk5f5wU6I7J for ; Sat, 30 Jul 2011 06:53:45 -0700 (PDT) Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id CC01921F8892 for ; Sat, 30 Jul 2011 06:53:42 -0700 (PDT) X-AuditID: 0a0404e8-b7c24ae000002adb-78-4e340cf361f5 Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id 85.42.10971.3FC043E4; Sat, 30 Jul 2011 08:53:56 -0500 (CDT) Received: from CDCE10HC1.commscope.com (10.86.20.21) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.159.2; Sat, 30 Jul 2011 08:53:43 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by CDCE10HC1.commscope.com (10.86.20.21) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sat, 30 Jul 2011 08:53:36 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Sat, 30 Jul 2011 21:53:34 +0800 From: "Thomson, Martin" To: "atoca@ietf.org" Date: Sat, 30 Jul 2011 21:53:30 +0800 Thread-Topic: Virtual Interim: Poll Thread-Index: AcxOwBCqvE4fEO3+S8ieXdw/QflOzQ== Message-ID: <8B0A9FCBB9832F43971E38010638454F040D2C3AC7@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {202007AF-8DE2-4D02-8753-17C16CBA6F18} x-cr-hashedpuzzle: AHka BZR9 B/mb CIoX CVvk CgQI ClSm DaW7 Fblm GNvA Gc1j HVyn I4iW I6h9 JXJH KRlZ; 1; YQB0AG8AYwBhAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {202007AF-8DE2-4D02-8753-17C16CBA6F18}; bQBhAHIAdABpAG4ALgB0AGgAbwBtAHMAbwBuAEAAYwBvAG0AbQBzAGMAbwBwAGUALgBjAG8AbQA=; Sat, 30 Jul 2011 13:53:30 GMT;VgBpAHIAdAB1AGEAbAAgAEkAbgB0AGUAcgBpAG0AOgAgAFAAbwBsAGwA 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] 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: Sat, 30 Jul 2011 13:53:46 -0000 As discussed in the meeting, we're planning to have a virtual interim meeti= ng [*] in September. If you would like to attend, please indicate your availability. http://www.doodle.com/bsa88787q3rhzd6e Martin [*] Phone call