From martin.thomson@gmail.com Wed Jul 11 14:36:28 2012 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 A6B0711E814B for ; Wed, 11 Jul 2012 14:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.715 X-Spam-Level: X-Spam-Status: No, score=-3.715 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 M0GzgtOD-P5E for ; Wed, 11 Jul 2012 14:36:28 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2B511E8149 for ; Wed, 11 Jul 2012 14:36:28 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so2302890obb.31 for ; Wed, 11 Jul 2012 14:36:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=rIxBsRbXjFTSGVr0IQCKwoYN0xmscdoNVAkWWAoKZ84=; b=TW/yywrBx2ri2WEfLUmt8yaqEe1Rr1GC63IOeC9e3cvfq2sn9+BheluIxqBwAb/sh5 0HL1OBS2ycmKKmbj/POc6vokQNPXbvtrBwhrQj3X6i+uLIzM0DrNi+DUf4B6DgAS+kUU ps/oVp8Nw8Kf8+CltwW+HvWN7NdgRV21ziJnNIeTtrD0pnUxFfcQbwHa+DlZV1DBCaVa XOc3hwpmk/12ajc5L07R3Hk4vAlRY1GXg1Y4k9FWQ3+xxccUT1ehFZxMI1e6aHR1n0Zh vnJlC8dskeZDK1/V4KMqBI1FM4r+6cc0klT4w4NWGgu7bYNYy8DXoVaweBVEleJm+nNj +Meg== MIME-Version: 1.0 Received: by 10.182.13.74 with SMTP id f10mr46410913obc.36.1342042619357; Wed, 11 Jul 2012 14:36:59 -0700 (PDT) Received: by 10.182.101.131 with HTTP; Wed, 11 Jul 2012 14:36:59 -0700 (PDT) Date: Wed, 11 Jul 2012 14:36:59 -0700 Message-ID: From: Martin Thomson To: atoca@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [atoca] Meeting agenda 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, 11 Jul 2012 21:36:28 -0000 As it currently stands, the ATOCA agenda is: If you wish to correct this, perhaps by suggesting additions, please let the chairs know. If we determine that there is no interest in meeting this time, we can allow the secretariat to free the slot (1730-1830 Thursday) for other working groups. From rbarnes@bbn.com Mon Jul 16 13:45:44 2012 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 A09AD11E82D6 for ; Mon, 16 Jul 2012 13:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.596 X-Spam-Level: X-Spam-Status: No, score=-106.596 tagged_above=-999 required=5 tests=[AWL=0.003, 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 PmgGKjQw1zOz for ; Mon, 16 Jul 2012 13:45:43 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id C5B9511E82D2 for ; Mon, 16 Jul 2012 13:45:43 -0700 (PDT) Received: from ros-dhcp192-1-51-20.bbn.com ([192.1.51.20]:51716) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SqsBZ-0009sR-1a for atoca@ietf.org; Mon, 16 Jul 2012 16:46:29 -0400 From: "Richard L. Barnes" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 16 Jul 2012 16:46:28 -0400 References: <20120716204451.4424.15543.idtracker@ietfa.amsl.com> To: atoca@ietf.org Message-Id: <0B31114B-D3FB-4557-B15D-CD1C4D241A32@bbn.com> Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [atoca] Fwd: New Version Notification for draft-barnes-atoca-meta-03.txt 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, 16 Jul 2012 20:45:44 -0000 Dear ATOCA WG, We've posted a new version of AMP, the discovery / metadata protocol = that we discussed at the last IETF. Comments welcome. --Richard Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-barnes-atoca-meta-03.txt > Date: July 16, 2012 4:44:51 PM EDT > To: rbarnes@bbn.com > Cc: kseo@bbn.com, mlepinski@bbn.com >=20 >=20 > A new version of I-D, draft-barnes-atoca-meta-03.txt > has been successfully submitted by Richard Barnes and posted to the > IETF repository. >=20 > Filename: draft-barnes-atoca-meta > Revision: 03 > Title: Alert Metadata Protocol (AMP) > Creation date: 2012-07-15 > WG ID: Individual Submission > Number of pages: 15 > URL: = http://www.ietf.org/internet-drafts/draft-barnes-atoca-meta-03.txt > Status: = http://datatracker.ietf.org/doc/draft-barnes-atoca-meta > Htmlized: http://tools.ietf.org/html/draft-barnes-atoca-meta-03 > Diff: = http://tools.ietf.org/rfcdiff?url2=3Ddraft-barnes-atoca-meta-03 >=20 > Abstract: > This document specifies a set of mechanisms that devices on an IP > network can use to discover an alert metadata server able to provide > information about local emergency alert services. Additionally, = this > document provides a protocol that devices on an IP network can use = to > retrieve local information from an alert metadata server about > sources of emergency alerts and register contact information for > receipt of alerts. >=20 > Please send feedback to the atoca@ietf.org mailing list. >=20 >=20 >=20 >=20 > The IETF Secretariat From rbarnes@bbn.com Tue Jul 17 15:41:07 2012 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 CF1B311E80D9 for ; Tue, 17 Jul 2012 15:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.61 X-Spam-Level: X-Spam-Status: No, score=-106.61 tagged_above=-999 required=5 tests=[AWL=-0.011, 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 t+op5mvLrUTK for ; Tue, 17 Jul 2012 15:41:06 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id E834911E80D7 for ; Tue, 17 Jul 2012 15:41:05 -0700 (PDT) Received: from [128.89.253.137] (port=57859) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SrGSl-000355-AW; Tue, 17 Jul 2012 18:41:51 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Tue, 17 Jul 2012 18:41:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Martin Thomson X-Mailer: Apple Mail (2.1278) Cc: atoca@ietf.org Subject: Re: [atoca] Meeting agenda 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, 17 Jul 2012 22:41:08 -0000 Hey Martin, Matt and I did do a revision of draft-barnes-atoca-meta, if there's any = interest in discussing it. --Richard On Jul 11, 2012, at 5:36 PM, Martin Thomson wrote: > As it currently stands, the ATOCA agenda is: >=20 >=20 > If you wish to correct this, perhaps by suggesting additions, please > let the chairs know. If we determine that there is no interest in > meeting this time, we can allow the secretariat to free the slot > (1730-1830 Thursday) for other working groups. > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From martin.thomson@gmail.com Thu Jul 19 17:44:18 2012 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 33E8A11E80B6 for ; Thu, 19 Jul 2012 17:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.948 X-Spam-Level: X-Spam-Status: No, score=-3.948 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 B11mR159o2pE for ; Thu, 19 Jul 2012 17:44:17 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 65F9911E80A6 for ; Thu, 19 Jul 2012 17:44:17 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so4736091lbb.31 for ; Thu, 19 Jul 2012 17:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=FHP0gRMa0qKT1yyjjnQQsioWV7pzKY/vREdR+veNNak=; b=VCvbwS4N+CNjU2VrvIhuJKxJaFV1Au9GFUhfaBF+Fdv30Qx8P6TjBj3u53o9xEGcRf CVEOwsWekHVHqCYnQqMSLxM8vH4QXA2KdIqZreMADUFv9EeWHIeXM0YfZnqpxljKVyQt p5Lf8W6rUbVuSqASsHuhPoal3XXdajL4HlzG5f4mCOKQnzJwEbMQ/GSqFsy21GKOq+W4 jJG5i8tUyv8KLOiQOzB+UvD/wROG+dtPGNIncgGo6U5jkN/J266moyU3hCGfijOJ2Nby KusqgE7G6xysZ1bmRpYf2u6mlg/t6ylqp2RmeZmWC3z6rpnfcGt7T63Nyaa3jBia7oWx iFhA== MIME-Version: 1.0 Received: by 10.152.132.40 with SMTP id or8mr4163252lab.24.1342745110846; Thu, 19 Jul 2012 17:45:10 -0700 (PDT) Received: by 10.112.44.3 with HTTP; Thu, 19 Jul 2012 17:45:10 -0700 (PDT) Date: Thu, 19 Jul 2012 17:45:10 -0700 Message-ID: From: Martin Thomson To: atoca@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [atoca] The future of atoca X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 00:44:18 -0000 This working group has been quiet for extended periods for a long time now. The chairs are concerned that there are too few participants who are interested in furthering the work of the group for the group to be viable. For the Vancouver IETF we would like to address the question of closing the working group. If we are to keep the working group open, a number of people would have to come forward between now and the scheduled meeting time. These people would not only express interest, but also demonstrate a firm commitment to contribute to the goals of the group. On the other hand, if we conclude that closing the working group is preferable, we then need to decide what to do with the products of this working group, such as they are. The working group has one adopted draft, but there have also been several individual submissions. Then, in either case - for the continued success of the group, or merely for posterity - thoughts on whether this effort would have succeeded and the conditions under which it might have succeeded/could succeed would be of great interest. Would a tighter focus in a particular area have made this more feasible? To that end, the chairs propose that we address this issue in Vancouver. A draft agenda containing this item has been posted. --atoca Chairs From mark.wood@engineer.com Fri Jul 20 03:36:28 2012 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 6587621F85A4 for ; Fri, 20 Jul 2012 03:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 UIX6amO17ahN for ; Fri, 20 Jul 2012 03:36:27 -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 7DF1521F858D for ; Fri, 20 Jul 2012 03:36:27 -0700 (PDT) X-Trace: 486758966/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$ON_NET_AUTH_ACCEPTED/pipex-customers/81.86.43.86/None/mark.wood@engineer.com X-SBRS: None X-RemoteIP: 81.86.43.86 X-IP-MAIL-FROM: mark.wood@engineer.com 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: AgwKAD40CVBRVitW/2dsb2JhbABFuBgDgSKBCIInCDIcMAQBBiQ+GgYeAQEEHhATh2OdM60vgQuDMoEGgQUDJgKaYohpgVqCYIFgCA X-IronPort-AV: E=Sophos;i="4.77,622,1336345200"; d="scan'208";a="486758966" 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; 20 Jul 2012 11:37:17 +0100 From: "'Mark Wood'" Sender: "Mark" To: In-Reply-To: Date: Fri, 20 Jul 2012 11:37:20 +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 Thread-Index: Ac1mEPFzoB4FC1O9RBCQNKiSBj9U/wATejUg X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609 Message-Id: <20120720103627.7DF1521F858D@ietfa.amsl.com> Subject: [atoca] ATOCA certainly still needed. 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, 20 Jul 2012 10:36:28 -0000 Friends, I would like to say that the work of ATOCA is very much needed. This is absolutely NOT the time to put it on the back burner. I have not been intervening in the matters at hand because the members have been doing the job well enough that I am satisfied with what is being done. My sponsors DRCF have small resources so I don't travel to a conf on their buck unless there is a good reason for me to be there in physical person, and I have been well satisfied so far. Meantime, in the cellular world, the Multicast Address Harmonisation recommendation at ITU-T SG2 and has stopped without any agreement on further work at the ITU other than a possible 'Supplement', so we don't need to wait for any recommendations to appear from them. However the 3GPP HAS done all that is needed, and the 3GPP has published its latest revision of the standard affecting public warning (3GPP 023.041 V11.1.0) (section 9) for GSM, UMTS and LTE, and this work is moving on very rapidly and to the satisfaction of nearly everyone. Harmonisation has been achieved between the USA CMAS/WEA system, the South Korean system and the international ETSI 102-900 system EU-ALERT, so I am very satisfied with the work that 3GPP has done and I don' plan to replicate any of it elsewhere. Member states also seem satisfied with the options that 3GPP have presented them with, I don't see anyone trying to re invent a different wheel, in fact nations are building chariots now. Now that the matter is settled in the cellular world and the wheels are being put up on the wagons, its time to look at the IP world so that we have complementary offering. My MSc thesis project for this coming year (I am 'bogged down' with the London Olympics logistics at the moment) is to study the matter of provision of Public Warning systems over multicast technology in IP4 and IP6. Is it an appropriate solution at all? If so we need to see if there are any gaps in the technology, that need addressing, or if it is OK as is. My current feeling is that there are three ways of dealing with this issue. 1 Emulate a 'PWS like' system rather similar to 3GPP solution, (simplest, much of this work is already 'running code'). 2 Have a completely different philosophy more applicable to IP networks. 3 A hybrid solution cherry picking the best of both. I am keeping an open mind on the matter at the moment, but I hope to have it very clearly crystallised by this time next year. So, I would implore the ATOCA to keep open while we further discuss what more research and recommendations will be needed going forward, I don't think we have looked at all of these matters just yet and the starting gun has only just fired on this important matter. If we find that we don't need any more recommendations, then we can close the matter for now. As soon as the Olympics are done with, I will be focusing on this matter and I assure you that I will be providing a lot of quality input to this group from now on. Please, keep this focus group going, and there is a noble and worthy reward at the end of the line, we will all have reason to be proud of this work if we see it through. Mark Wood DRCF. From keith.drage@alcatel-lucent.com Fri Jul 20 03:39:33 2012 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 9EFAC21F85F2 for ; Fri, 20 Jul 2012 03:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.732 X-Spam-Level: X-Spam-Status: No, score=-109.732 tagged_above=-999 required=5 tests=[AWL=0.517, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, 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 3DkErvEarWKJ for ; Fri, 20 Jul 2012 03:39:33 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id AA24E21F8599 for ; Fri, 20 Jul 2012 03:39:31 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q6KAeNtN007671 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 20 Jul 2012 12:40:25 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 20 Jul 2012 12:40:23 +0200 From: "DRAGE, Keith (Keith)" To: Martin Thomson , "atoca@ietf.org" Date: Fri, 20 Jul 2012 12:40:21 +0200 Thread-Topic: [atoca] The future of atoca Thread-Index: Ac1mEO8ZKB+1GjQBReu47vQfsfHXswAUkAZA Message-ID: References: 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-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Subject: Re: [atoca] The future of atoca X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 10:39:33 -0000 As yet again, I cannot get to the ATOCA session because I am chairing a ses= sion at the same time, I'll comment on list. I don't see enough momentum to have a working group on this subject. The id= ea of a working group is to gain a certain amount of consensus round a subj= ect before submitting a document to the IETF last call process. So there is= no point writing drafts which essentially only the authors comment on in t= he WG. The WG has had more than adequate time to gather that momentum if it= existed. Given that, if the authors of documents really want to proceed, they might = as well put the documents straight into the individual submission process (= or else abandon them). There is no point in continuing with the working group as it is adding noth= ing to the process of gaining IETF consensus. Keith > -----Original Message----- > From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of > Martin Thomson > Sent: 20 July 2012 01:45 > To: atoca@ietf.org > Subject: [atoca] The future of atoca >=20 > This working group has been quiet for extended periods for a long time > now. The chairs are concerned that there are too few participants who > are interested in furthering the work of the group for the group to be > viable. >=20 > For the Vancouver IETF we would like to address the question of > closing the working group. >=20 > If we are to keep the working group open, a number of people would > have to come forward between now and the scheduled meeting time. > These people would not only express interest, but also demonstrate a > firm commitment to contribute to the goals of the group. >=20 > On the other hand, if we conclude that closing the working group is > preferable, we then need to decide what to do with the products of > this working group, such as they are. The working group has one > adopted draft, but there have also been several individual > submissions. >=20 > Then, in either case - for the continued success of the group, or > merely for posterity - thoughts on whether this effort would have > succeeded and the conditions under which it might have succeeded/could > succeed would be of great interest. Would a tighter focus in a > particular area have made this more feasible? >=20 > To that end, the chairs propose that we address this issue in > Vancouver. A draft agenda containing this item has been posted. >=20 > --atoca Chairs > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From mark.wood@engineer.com Sat Jul 21 06:11:14 2012 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 50CFA21F865A for ; Sat, 21 Jul 2012 06:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 OMT8YczQZZmV for ; Sat, 21 Jul 2012 06:11:13 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B35C21F8646 for ; Sat, 21 Jul 2012 06:11:13 -0700 (PDT) X-Trace: 545431372/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$ON_NET_AUTH_ACCEPTED/pipex-customers/81.86.43.86/None/mark.wood@engineer.com X-SBRS: None X-RemoteIP: 81.86.43.86 X-IP-MAIL-FROM: mark.wood@engineer.com 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: Av0EAC+oClBRVitW/2dsb2JhbABFuV2BCIInCDIcMAQBBgMhPhoGHgEBBAEdiAbKF4VOgQUDmw6Ia4FagmA X-IronPort-AV: E=Sophos;i="4.77,629,1336345200"; d="scan'208";a="545431372" 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; 21 Jul 2012 14:12:06 +0100 From: "'Mark Wood'" Sender: "Mark" To: "'DRAGE, Keith \(Keith\)'" , "'Martin Thomson'" , In-Reply-To: Date: Sat, 21 Jul 2012 14:12:09 +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 Thread-Index: Ac1mEO8ZKB+1GjQBReu47vQfsfHXswAUkAZAADd0HZA= X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609 Message-Id: <20120721131113.7B35C21F8646@ietfa.amsl.com> Subject: Re: [atoca] The future of atoca X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2012 13:11:14 -0000 I Repeat; The matter of using public networks for authority to citizen communication is only just now becoming a mainstream topic. We just did not have a model for such before the deployment of ETWS in Japan and now CMAS in the USA in 2012. Now that we do have such systems is the time to address the matter. I deduce that anyone wanting to obtain a licence for a public mobile network will have to have some sort of method of realising the same burdens that are now placed on the cellular network providers. The wording of the requirements will probably be non technology dependent, so the same burdens will be a requirement for all system technologies. We have not had this conversation yet, and we need to have it now that CMAS/ETSI has finally just arrived (after a long gestation period). It will probably take at least another year to understand what the issues are before we can make any submissions to the IETF. Mark wood DRCF. From stpeter@stpeter.im Sat Jul 21 09:00:16 2012 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 BB15821F867A for ; Sat, 21 Jul 2012 09:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.036 X-Spam-Level: X-Spam-Status: No, score=-103.036 tagged_above=-999 required=5 tests=[AWL=-0.437, BAYES_00=-2.599, 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 59+77N44P3PW for ; Sat, 21 Jul 2012 09:00:12 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE4321F866A for ; Sat, 21 Jul 2012 09:00:11 -0700 (PDT) Received: from [192.168.0.3] (unknown [216.17.179.227]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6E38C40075; Sat, 21 Jul 2012 10:20:22 -0600 (MDT) Message-ID: <500AD247.5010201@stpeter.im> Date: Sat, 21 Jul 2012 10:01:11 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: 'Mark Wood' References: <20120721131113.7B35C21F8646@ietfa.amsl.com> In-Reply-To: <20120721131113.7B35C21F8646@ietfa.amsl.com> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: atoca@ietf.org Subject: Re: [atoca] The future of atoca X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2012 16:00:16 -0000 On 7/21/12 7:12 AM, 'Mark Wood' wrote: > It will probably take at least another year to understand what the issues > are before we can make any submissions to the IETF. In which case perhaps it's appropriate to close the WG and pursue this work, if it emerges at all, through individual Internet-Drafts. Peter -- Peter Saint-Andre https://stpeter.im/ From artbotterell@gmail.com Sat Jul 21 10:40:34 2012 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 69CE721F8585 for ; Sat, 21 Jul 2012 10:40:34 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Qu7F-uGGmLD for ; Sat, 21 Jul 2012 10:40:33 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id CB11721F857D for ; Sat, 21 Jul 2012 10:40:33 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so8475567pbc.31 for ; Sat, 21 Jul 2012 10:41:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=GgCfR372wpKv/SuVsqkwwUjDznk4osxtq5tg1uS55UM=; b=IGTpBAetTeHLciuf3I8b5SjuUdy2Ijum/nhOOT08QJUhgYs/Wdm7VZHVtgBIR4r4Mh ZC4Y17i7AZK+ZK4IzV28ue2mrG5Emma4bF+xnw+v3qhXEk0SCKbQ0Z+QD7wj7wWojkn+ gCsn2spYLhMndPlAoS02PZWdmeyr0t4F5HSxJEpX2JxwPHotrzYjR++6oLwMkwTy5XHE 0WzYqbYKnustp2kCugWN02BywDgoFLBXM/q1vRAulLxfeABfndK9/W/yNKLWGSCM+Iq2 os8ww+3pYhB7OKUmhu4SS/x5BheL/EyQw8jb0MjXHfUOLaHmFxPvmzdcXE6DIYcP9Dcz kyBg== Received: by 10.68.221.10 with SMTP id qa10mr22957740pbc.154.1342892493051; Sat, 21 Jul 2012 10:41:33 -0700 (PDT) Received: from [192.168.1.69] (99-182-125-96.lightspeed.frokca.sbcglobal.net. [99.182.125.96]) by mx.google.com with ESMTPS id wa14sm6385315pbc.10.2012.07.21.10.41.30 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 21 Jul 2012 10:41:32 -0700 (PDT) Sender: Art Botterell Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1278) From: Art Botterell In-Reply-To: <20120721131113.7B35C21F8646@ietfa.amsl.com> Date: Sat, 21 Jul 2012 10:41:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120721131113.7B35C21F8646@ietfa.amsl.com> To: atoca@ietf.org X-Mailer: Apple Mail (2.1278) Subject: Re: [atoca] The future of atoca X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2012 17:40:34 -0000 Mark makes the essential point, IMHO. This working group may simply = have been ahead of its time. So if the WG format isn't appropriate... I = don't really have an opinion on that... I hope we can find some way to = keep a less formal conversation going among folks who are interested, in = anticipation that relevant issues may come clear over the next few = years. - Art On Jul 21, 2012, at 6:12 AM, Mark Wood wrote: >=20 > I Repeat; >=20 > The matter of using public networks for authority to citizen = communication > is only just now becoming a mainstream topic. We just did not have a = model > for such before the deployment of ETWS in Japan and now CMAS in the = USA in > 2012. >=20 > Now that we do have such systems is the time to address the matter. >=20 > I deduce that anyone wanting to obtain a licence for a public mobile = network > will have to have some sort of method of realising the same burdens = that are > now placed on the cellular network providers. The wording of the > requirements will probably be non technology dependent, so the same = burdens > will be a requirement for all system technologies.=20 >=20 > We have not had this conversation yet, and we need to have it now that > CMAS/ETSI has finally just arrived (after a long gestation period). >=20 > It will probably take at least another year to understand what the = issues > are before we can make any submissions to the IETF. >=20 > Mark wood DRCF. >=20 >=20 >=20 >=20 > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From trutkowski@netmagic.com Sat Jul 21 13:29:09 2012 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 BA1D921F8533 for ; Sat, 21 Jul 2012 13:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 5q8ttWVu8omD for ; Sat, 21 Jul 2012 13:29:09 -0700 (PDT) Received: from vms173011pub.verizon.net (vms173011pub.verizon.net [206.46.173.11]) by ietfa.amsl.com (Postfix) with ESMTP id 256FE21F8532 for ; Sat, 21 Jul 2012 13:29:08 -0700 (PDT) Received: from [192.168.0.4] ([unknown] [173.72.150.118]) by vms173011.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0M7J00E7W2A3XYB5@vms173011.mailsrvcs.net> for atoca@ietf.org; Sat, 21 Jul 2012 15:30:08 -0500 (CDT) Message-id: <500B114B.4090209@netmagic.com> Date: Sat, 21 Jul 2012 16:30:03 -0400 From: Tony Rutkowski Organization: NetMagic Associates User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120717 Thunderbird/15.0 MIME-version: 1.0 To: Art Botterell References: <20120721131113.7B35C21F8646@ietfa.amsl.com> In-reply-to: Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit Cc: "kathleen.moriarty@emc.com" , atoca@ietf.org Subject: Re: [atoca] The future of atoca 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: Sat, 21 Jul 2012 20:29:09 -0000 Hi Art, Good admonitions. As someone who participates significantly in the MILE group (ironically dealing with incidents), I'm curious if anyone has contemplated treating an emergency warning message as simply a specialized instance of incident messages, and potentially using IODEF SCI to move CAP messages under that aegis? There is a certain irony in Q4/17 (from which I'm about to depart), that they are both within that same group. best, tony On 7/21/2012 1:41 PM, Art Botterell wrote: > Mark makes the essential point, IMHO. This working group may simply have been ahead of its time. So if the WG format isn't appropriate... I don't really have an opinion on that... I hope we can find some way to keep a less formal conversation going among folks who are interested, in anticipation that relevant issues may come clear over the next few years. > From artbotterell@gmail.com Sat Jul 21 14:01:29 2012 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 1767521F8566 for ; Sat, 21 Jul 2012 14:01:29 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6JSb1-gQz4Y for ; Sat, 21 Jul 2012 14:01:28 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8397D21F855F for ; Sat, 21 Jul 2012 14:01:28 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so8663756pbc.31 for ; Sat, 21 Jul 2012 14:02:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=sZ5meEjA3c6bdJuhZL10UsSLiskpWOH9fImhNP/ctFQ=; b=drRYe8kRyUiHzYtC/WNIipTLGFwqSpV/x+8RuTQTuE4hy9tYjTSMOwh5WkBeFm1vch z0inbZJiUlVan+cJLGmdt+IWLacnVdMsjD7heLYC6mvHAyaxacu0xg5FNwXvz1UzkeFF f6QoVzj03NR+yrk9ucKBAUn4uPNOjl3iL5ouTDdGWlag1xsbk6x01igMjFZjc920u21O vDUq3UudVWTXY/v6qbDjXameNUoxwT5GIHSec3r2jU/InAI8nWztqG81EmoMr7M/UTRQ Ph+kwAO5XEqfbCmb2u1Y5kU1D0er4N9v+K+fwih0hsYGt2MxHcTsTCG6FUZixJzKbko+ h8BA== Received: by 10.68.232.229 with SMTP id tr5mr23837120pbc.101.1342904548292; Sat, 21 Jul 2012 14:02:28 -0700 (PDT) Received: from [192.168.1.69] (99-182-125-96.lightspeed.frokca.sbcglobal.net. [99.182.125.96]) by mx.google.com with ESMTPS id ny4sm6615191pbb.57.2012.07.21.14.02.25 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 21 Jul 2012 14:02:27 -0700 (PDT) Sender: Art Botterell Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1278) From: Art Botterell In-Reply-To: <500B114B.4090209@netmagic.com> Date: Sat, 21 Jul 2012 14:02:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <73A1E052-400A-41E3-9F5C-0AD06B02ABBD@incident.com> References: <20120721131113.7B35C21F8646@ietfa.amsl.com> <500B114B.4090209@netmagic.com> To: atoca@ietf.org X-Mailer: Apple Mail (2.1278) Subject: Re: [atoca] The future of atoca X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2012 21:01:29 -0000 Tony, I've always thought of CAP as an instance of an event message, as = distinguished from a state message (e.g., a SITREP). Can't say I've = belabored the distinction, but in general I think an event message is = mainly meaningful in terms of when it arrives, while a state message is = more meaningful as a snapshot from the time it was sent. (Rare, of = course, is the pure example of either class.) I'll leave it to smarter folks to draw that line more clearly, but I've = seen a number of instances where system-level conversations got confused = because some folks were using an eventing model and other folks were = thinking in terms of a representation of system state. Anyway, seems like we're getting a lot of topical silos that are all = trying to either, a) trigger activity somewhere else (frequently with = some situational context), or b) offer information about some state of = affairs (perhaps implying a particular call-to-action, but more often = not.) - Art On Jul 21, 2012, at 1:30 PM, Tony Rutkowski wrote: > Hi Art, >=20 > Good admonitions. >=20 > As someone who participates significantly in the > MILE group (ironically dealing with incidents), > I'm curious if anyone has contemplated treating > an emergency warning message as simply a > specialized instance of incident messages, > and potentially using IODEF SCI to move > CAP messages under that aegis? >=20 > There is a certain irony in Q4/17 (from which > I'm about to depart), that they are both within > that same group. >=20 > best, > tony >=20 >=20 > On 7/21/2012 1:41 PM, Art Botterell wrote: >> Mark makes the essential point, IMHO. This working group may simply = have been ahead of its time. So if the WG format isn't appropriate... I = don't really have an opinion on that... I hope we can find some way to = keep a less formal conversation going among folks who are interested, in = anticipation that relevant issues may come clear over the next few = years. >>=20 >=20 From mark.wood@engineer.com Sat Jul 21 14:06:12 2012 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 4078B21F8530 for ; Sat, 21 Jul 2012 14:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_MILLIONSOF=0.315] 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 F3JrNoJX9kzr for ; Sat, 21 Jul 2012 14:06:11 -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 2929121F852D for ; Sat, 21 Jul 2012 14:06:11 -0700 (PDT) X-Trace: 602275040/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$ON_NET_AUTH_ACCEPTED/pipex-customers/81.86.43.86/None/mark.wood@engineer.com X-SBRS: None X-RemoteIP: 81.86.43.86 X-IP-MAIL-FROM: mark.wood@engineer.com 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: AjoaAAgZC1BRVitW/2dsb2JhbABEqWsBj26BCIIGAQEfCDIcEQsHDQUGJD4aBh4BAQQBHYdyAROZYoNAllAHmzcCgQUDjXGNIIhrgVqCYA X-IronPort-AV: E=Sophos;i="4.77,630,1336345200"; d="scan'208";a="602275040" 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; 21 Jul 2012 22:07:03 +0100 From: "Mark" To: , "'Art Botterell'" In-Reply-To: <500B114B.4090209@netmagic.com> Date: Sat, 21 Jul 2012 22:07:05 +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 Thread-Index: Ac1nf6FmF0mraYlzTdm+zbTLkbK4LQAAcn0Q X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609 Message-Id: <20120721210611.2929121F852D@ietfa.amsl.com> Cc: atoca@ietf.org, kathleen.moriarty@emc.com Subject: [atoca] what needs to be done yet. 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, 21 Jul 2012 21:06:12 -0000 Hi Guys, The features that make an emergency Public Warning Messaging special are; 1 the super-massive scale of the broadcast (Maybe to 10s of millions of hosts) 2 in a handful of seconds (CMAS takes only 7 seconds to deliver them all), 3 during extreme overload, (CMAS uses out of band signalling) 4 without any foreknowledge of their addresses, (No data base needed by CMAS) 5 and in a completely stateless passive way, (No TCP session exhaustion possible) 6 which is geo specific, (CMAS is selective down to one cell, about 1 mile) 7 Must be highly resistant to Slashdot or DOS events. (Disasters are always without exception accompanies by Tsunami waves of load). Very extensive studies carried out by both government and industry showed that the most appropriate way of dealing with these very extreme events is to use passive point-to-multipoint bearer services. For example in the cellular networks, Cell Broadcast and multi media Broadcast multicast are such bearers. This is why they had to be deployed for this special situation. The studies were very thorough, and completely conclusive. The closest equivalent to cell broadcast in IP is IPMulticast. These situations are not at all the same as the situation where CAP messages are being signalled between relatively small numbers of well known systems which are in a trusted relationship with each other, and there is 'stateful' handshake relationship between hosts. This is why IMHO a completely different philosophy is needed, and one which I don't think ATOCA have looked at in depth yet. However the title of the WG clearly indicates that we should, and so as Art says, the reality on the ground has only just this year caught up with the subject. Well we WERE ahead of the subject, but not now! IMHO there is work to do and we have not done it yet :-) Mark Wood DRCF. From keith.drage@alcatel-lucent.com Sun Jul 22 18:34:10 2012 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 72EB421F864B for ; Sun, 22 Jul 2012 18:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.756 X-Spam-Level: X-Spam-Status: No, score=-109.756 tagged_above=-999 required=5 tests=[AWL=0.493, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, 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 P7DUVLBq9kRu for ; Sun, 22 Jul 2012 18:34:09 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 8E41621F8646 for ; Sun, 22 Jul 2012 18:34:05 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q6N1Y25P002930 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 23 Jul 2012 03:34:04 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Mon, 23 Jul 2012 03:34:02 +0200 From: "DRAGE, Keith (Keith)" To: Art Botterell , "atoca@ietf.org" Date: Mon, 23 Jul 2012 03:34:01 +0200 Thread-Topic: [atoca] The future of atoca Thread-Index: Ac1naBb5zdRNBgj1T76mexnDaJ5bQgBBMHlQ Message-ID: References: <20120721131113.7B35C21F8646@ietfa.amsl.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-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Subject: Re: [atoca] The future of atoca X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 01:34:10 -0000 I'd note that closing the working group and closing the mailing list are no= t one and the same thing.=20 Mailing lists can exist without the continuation of the working group. So as and when interest does arise, and activity on the mailing list identi= fies this, either drafts can be discussed and prepared for individual submi= ssion, or a new working group can be chartered and the work resumed as char= tered activity. Keith > -----Original Message----- > From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of > Art Botterell > Sent: 21 July 2012 18:41 > To: atoca@ietf.org > Subject: Re: [atoca] The future of atoca >=20 > Mark makes the essential point, IMHO. This working group may simply have > been ahead of its time. So if the WG format isn't appropriate... I don't > really have an opinion on that... I hope we can find some way to keep a > less formal conversation going among folks who are interested, in > anticipation that relevant issues may come clear over the next few years. >=20 > - Art >=20 >=20 > On Jul 21, 2012, at 6:12 AM, Mark Wood wrote: >=20 > > > > I Repeat; > > > > The matter of using public networks for authority to citizen > communication > > is only just now becoming a mainstream topic. We just did not have a > model > > for such before the deployment of ETWS in Japan and now CMAS in the USA > in > > 2012. > > > > Now that we do have such systems is the time to address the matter. > > > > I deduce that anyone wanting to obtain a licence for a public mobile > network > > will have to have some sort of method of realising the same burdens tha= t > are > > now placed on the cellular network providers. The wording of the > > requirements will probably be non technology dependent, so the same > burdens > > will be a requirement for all system technologies. > > > > We have not had this conversation yet, and we need to have it now that > > CMAS/ETSI has finally just arrived (after a long gestation period). > > > > It will probably take at least another year to understand what the > issues > > are before we can make any submissions to the IETF. > > > > Mark wood DRCF. > > > > > > > > > > _______________________________________________ > > 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 br@brianrosen.net Mon Jul 30 14:26:22 2012 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 EE72421F85F9 for ; Mon, 30 Jul 2012 14:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.273 X-Spam-Level: X-Spam-Status: No, score=-102.273 tagged_above=-999 required=5 tests=[AWL=-1.274, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1, 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 nZJNu6BQGYbM for ; Mon, 30 Jul 2012 14:26:21 -0700 (PDT) Received: from barmail4.idig.net (barmail4.idig.net [64.34.111.235]) by ietfa.amsl.com (Postfix) with ESMTP id BCE1B21F8602 for ; Mon, 30 Jul 2012 14:26:21 -0700 (PDT) X-ASG-Debug-ID: 1343683580-04d03510722b39a0001-FTS53d Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail4.idig.net with ESMTP id f9ABMmzTwC5Yj30q; Mon, 30 Jul 2012 14:26:20 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233]:16756 helo=[192.168.133.55]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1SvxTo-002j87-RR; Mon, 30 Jul 2012 14:26:21 -0700 Mime-Version: 1.0 (Apple Message framework v1278) X-ASG-Orig-Subj: Re: [atoca] The future of atoca Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: Date: Mon, 30 Jul 2012 17:26:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120721131113.7B35C21F8646@ietfa.amsl.com> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1278) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1343683580 X-Barracuda-URL: http://64.34.111.235:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.104214 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Cc: atoca@ietf.org Subject: Re: [atoca] The future of atoca X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 21:26:23 -0000 I have hesitated to respond to this because I'm part of the problem. = However, here goes: I think the work of atoca is important. I think it's VERY important. = We need better tools for authority to citizen alerts. =20 We have been unable to muster enough effort. We need to fix that to be = viable. It may be too late. So, I will make a pledge: a) I will contribute a draft in this next cycle b) I will respond to threads on the list aggressively c) I will start threads to try to reach consensus on requirements and = mechanisms I ask for others to take the same pledge. I understand that I, and others, should have already done all of that. = Guilty. I will understand if it is decided that we had our chance and = lost it by inactivity. But I will ask for another chance to get good = work done. Brian On Jul 22, 2012, at 9:34 PM, DRAGE, Keith (Keith) wrote: > I'd note that closing the working group and closing the mailing list = are not one and the same thing.=20 >=20 > Mailing lists can exist without the continuation of the working group. >=20 > So as and when interest does arise, and activity on the mailing list = identifies this, either drafts can be discussed and prepared for = individual submission, or a new working group can be chartered and the = work resumed as chartered activity. >=20 > Keith >=20 >> -----Original Message----- >> From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On = Behalf Of >> Art Botterell >> Sent: 21 July 2012 18:41 >> To: atoca@ietf.org >> Subject: Re: [atoca] The future of atoca >>=20 >> Mark makes the essential point, IMHO. This working group may simply = have >> been ahead of its time. So if the WG format isn't appropriate... I = don't >> really have an opinion on that... I hope we can find some way to keep = a >> less formal conversation going among folks who are interested, in >> anticipation that relevant issues may come clear over the next few = years. >>=20 >> - Art >>=20 >>=20 >> On Jul 21, 2012, at 6:12 AM, Mark Wood wrote: >>=20 >>>=20 >>> I Repeat; >>>=20 >>> The matter of using public networks for authority to citizen >> communication >>> is only just now becoming a mainstream topic. We just did not have a >> model >>> for such before the deployment of ETWS in Japan and now CMAS in the = USA >> in >>> 2012. >>>=20 >>> Now that we do have such systems is the time to address the matter. >>>=20 >>> I deduce that anyone wanting to obtain a licence for a public mobile >> network >>> will have to have some sort of method of realising the same burdens = that >> are >>> now placed on the cellular network providers. The wording of the >>> requirements will probably be non technology dependent, so the same >> burdens >>> will be a requirement for all system technologies. >>>=20 >>> We have not had this conversation yet, and we need to have it now = that >>> CMAS/ETSI has finally just arrived (after a long gestation period). >>>=20 >>> It will probably take at least another year to understand what the >> issues >>> are before we can make any submissions to the IETF. >>>=20 >>> Mark wood DRCF. >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> 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 > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From hannes.tschofenig@gmx.net Mon Jul 30 14:36:51 2012 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 7512F11E813E for ; Mon, 30 Jul 2012 14:36:51 -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=[AWL=0.000, BAYES_00=-2.599, 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 ex-pgq10rMNB for ; Mon, 30 Jul 2012 14:36:51 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 83FE411E812C for ; Mon, 30 Jul 2012 14:36:50 -0700 (PDT) Received: (qmail invoked by alias); 30 Jul 2012 21:36:49 -0000 Received: from dhcp-172b.meeting.ietf.org (EHLO dhcp-172b.meeting.ietf.org) [130.129.23.43] by mail.gmx.net (mp019) with SMTP; 30 Jul 2012 23:36:49 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19Oc297xAlO5342JrKh1BqavnwcBtlALntL0Is31D eLovNv+I7gLM3k Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Mon, 30 Jul 2012 14:36:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <266595E9-AB52-4269-BF78-C239DE25FC94@gmx.net> References: <20120721131113.7B35C21F8646@ietfa.amsl.com> To: Brian Rosen X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: atoca@ietf.org Subject: Re: [atoca] The future of atoca X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 21:36:51 -0000 The problem I see is that we actually don't have a proposal that = actually works. Abstract discussions about potential solutions don't help to make = progress.=20 From br@brianrosen.net Mon Jul 30 14:43:35 2012 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 591EF11E8191 for ; Mon, 30 Jul 2012 14:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.457 X-Spam-Level: X-Spam-Status: No, score=-103.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 oK3GxkliIsSq for ; Mon, 30 Jul 2012 14:43:34 -0700 (PDT) Received: from barmail4.idig.net (barmail4.idig.net [64.34.111.235]) by ietfa.amsl.com (Postfix) with ESMTP id DA8ED11E8101 for ; Mon, 30 Jul 2012 14:43:34 -0700 (PDT) X-ASG-Debug-ID: 1343684614-04d03510732b42a0001-FTS53d Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail4.idig.net with ESMTP id AKU2tyAOo9qVIWFp; Mon, 30 Jul 2012 14:43:34 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233]:16916 helo=[192.168.133.55]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1SvxkU-002kgE-5s; Mon, 30 Jul 2012 14:43:34 -0700 Mime-Version: 1.0 (Apple Message framework v1278) X-ASG-Orig-Subj: Re: [atoca] The future of atoca Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: <266595E9-AB52-4269-BF78-C239DE25FC94@gmx.net> Date: Mon, 30 Jul 2012 17:43:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120721131113.7B35C21F8646@ietfa.amsl.com> <266595E9-AB52-4269-BF78-C239DE25FC94@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1278) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1343684614 X-Barracuda-URL: http://64.34.111.235:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.104216 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: atoca@ietf.org Subject: Re: [atoca] The future of atoca X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 21:43:35 -0000 I don't agree. I think a lot of what Richard has proposed works. I = think some things could be improved (a draft I will write). =20 Brian On Jul 30, 2012, at 5:36 PM, Hannes Tschofenig wrote: > The problem I see is that we actually don't have a proposal that = actually works. > Abstract discussions about potential solutions don't help to make = progress.=20 >=20 >=20 >=20 From hgs@cs.columbia.edu Mon Jul 30 14:46:29 2012 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 B792211E81AE for ; Mon, 30 Jul 2012 14:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mJGxSH4VF04 for ; Mon, 30 Jul 2012 14:46:29 -0700 (PDT) Received: from salak.cc.columbia.edu (salak.cc.columbia.edu [128.59.29.6]) by ietfa.amsl.com (Postfix) with ESMTP id 23B5E11E81AD for ; Mon, 30 Jul 2012 14:46:29 -0700 (PDT) Received: from [172.20.22.63] ([208.23.64.30]) (user=hgs10 mech=PLAIN bits=0) by salak.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id q6ULkKDB002720 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 30 Jul 2012 17:46:21 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Henning Schulzrinne In-Reply-To: <266595E9-AB52-4269-BF78-C239DE25FC94@gmx.net> Date: Mon, 30 Jul 2012 17:46:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4CDBD8FD-69D2-466D-8557-BC60F117D1B6@cs.columbia.edu> References: <20120721131113.7B35C21F8646@ietfa.amsl.com> <266595E9-AB52-4269-BF78-C239DE25FC94@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1485) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.6 Cc: atoca@ietf.org Subject: Re: [atoca] The future of atoca X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 21:46:29 -0000 There is significant regulatory interest in exploring IP-based options, = so I would encourage taking stock and looking at a variety of options. = Even a summary of the options and why they do NOT work is useful. Some = initial questions that push beyond the SIP message space: One of the bigger problems with CMAS (cellular alerts) is the short = message size, which provides only very limited actionable information. Can we leverage IP-TV style multicast for scalable distribution? How = would the equivalent of EAS work in an IP video environment? Can we separate the common problem of in-area alerting (subscribers in a = particular area) from the less-common problem of out-of-area alerting = ("elderly relative")? Do we have any real experience with the realistic limits of web-based = flash crowds? If every household is watching entertainment (or Olympic) = video at night, the additional load of adding reasonably-detailed = information may not be all that large and CDNs are used to large crowds. Henning On Jul 30, 2012, at 5:36 PM, Hannes Tschofenig = wrote: > The problem I see is that we actually don't have a proposal that = actually works. > Abstract discussions about potential solutions don't help to make = progress.=20 >=20 >=20 >=20 > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca >=20 From sob@harvard.edu Mon Jul 30 14:51:45 2012 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 1D0D411E81C2 for ; Mon, 30 Jul 2012 14:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 mt8LPpFHQL+g for ; Mon, 30 Jul 2012 14:51:44 -0700 (PDT) Received: from ackroyd.harvard.edu (ackroyd.harvard.edu [128.103.208.29]) by ietfa.amsl.com (Postfix) with ESMTP id 04CA511E81BD for ; Mon, 30 Jul 2012 14:51:43 -0700 (PDT) Received: from exchange.university.harvard.edu (entwedge0000001.university.harvard.edu [10.35.2.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ackroyd.harvard.edu (Postfix) with ESMTP id 8084AE8904; Mon, 30 Jul 2012 17:51:42 -0400 (EDT) Received: from ENTWHUBT0000002.university.harvard.edu (192.168.36.23) by ENTWEDGE0000001.university.harvard.edu (10.35.2.152) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 30 Jul 2012 17:51:11 -0400 Received: from ENTWEXMB0000008.university.harvard.edu ([169.254.1.84]) by entwhubt0000002.university.harvard.edu ([192.168.36.46]) with mapi id 14.01.0355.002; Mon, 30 Jul 2012 17:51:01 -0400 From: "Bradner, Scott" To: Brian Rosen Thread-Topic: [atoca] The future of atoca Thread-Index: AQHNbp2B/Bt7pSXP9k21yF1x35bDLQ== Date: Mon, 30 Jul 2012 21:51:42 +0000 Message-ID: <130B9A5F-0809-4B5D-9EFC-63CB6B61DFE3@harvard.edu> References: <20120721131113.7B35C21F8646@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [136.248.127.172] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [atoca] The future of atoca X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 21:51:45 -0000 I also think the is very important=20 but we need to actually have text in front of us to discuss & progress as a chair, I am willing to keep trying but there is a limit Scott On Jul 30, 2012, at 5:26 PM, Brian Rosen wrote: > I have hesitated to respond to this because I'm part of the problem. How= ever, here goes: >=20 > I think the work of atoca is important. I think it's VERY important. We= need better tools for authority to citizen alerts. =20 >=20 > We have been unable to muster enough effort. We need to fix that to be v= iable. It may be too late. >=20 > So, I will make a pledge: > a) I will contribute a draft in this next cycle > b) I will respond to threads on the list aggressively > c) I will start threads to try to reach consensus on requirements and mec= hanisms >=20 > I ask for others to take the same pledge. >=20 > I understand that I, and others, should have already done all of that. G= uilty. I will understand if it is decided that we had our chance and lost = it by inactivity. But I will ask for another chance to get good work done. >=20 > Brian >=20 > On Jul 22, 2012, at 9:34 PM, DRAGE, Keith (Keith) wrote: >=20 >> I'd note that closing the working group and closing the mailing list are= not one and the same thing.=20 >>=20 >> Mailing lists can exist without the continuation of the working group. >>=20 >> So as and when interest does arise, and activity on the mailing list ide= ntifies this, either drafts can be discussed and prepared for individual su= bmission, or a new working group can be chartered and the work resumed as c= hartered activity. >>=20 >> Keith >>=20 >>> -----Original Message----- >>> From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf = Of >>> Art Botterell >>> Sent: 21 July 2012 18:41 >>> To: atoca@ietf.org >>> Subject: Re: [atoca] The future of atoca >>>=20 >>> Mark makes the essential point, IMHO. This working group may simply ha= ve >>> been ahead of its time. So if the WG format isn't appropriate... I don= 't >>> really have an opinion on that... I hope we can find some way to keep a >>> less formal conversation going among folks who are interested, in >>> anticipation that relevant issues may come clear over the next few year= s. >>>=20 >>> - Art >>>=20 >>>=20 >>> On Jul 21, 2012, at 6:12 AM, Mark Wood wrote: >>>=20 >>>>=20 >>>> I Repeat; >>>>=20 >>>> The matter of using public networks for authority to citizen >>> communication >>>> is only just now becoming a mainstream topic. We just did not have a >>> model >>>> for such before the deployment of ETWS in Japan and now CMAS in the US= A >>> in >>>> 2012. >>>>=20 >>>> Now that we do have such systems is the time to address the matter. >>>>=20 >>>> I deduce that anyone wanting to obtain a licence for a public mobile >>> network >>>> will have to have some sort of method of realising the same burdens th= at >>> are >>>> now placed on the cellular network providers. The wording of the >>>> requirements will probably be non technology dependent, so the same >>> burdens >>>> will be a requirement for all system technologies. >>>>=20 >>>> We have not had this conversation yet, and we need to have it now that >>>> CMAS/ETSI has finally just arrived (after a long gestation period). >>>>=20 >>>> It will probably take at least another year to understand what the >>> issues >>>> are before we can make any submissions to the IETF. >>>>=20 >>>> Mark wood DRCF. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> 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 hannes.tschofenig@gmx.net Mon Jul 30 16:13:14 2012 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 906F611E80BA for ; Mon, 30 Jul 2012 16:13:14 -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=[AWL=0.000, BAYES_00=-2.599, 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 P8J4dafUGA3C for ; Mon, 30 Jul 2012 16:13:14 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 967F911E80AE for ; Mon, 30 Jul 2012 16:13:13 -0700 (PDT) Received: (qmail invoked by alias); 30 Jul 2012 23:13:11 -0000 Received: from dhcp-172b.meeting.ietf.org (EHLO dhcp-172b.meeting.ietf.org) [130.129.23.43] by mail.gmx.net (mp017) with SMTP; 31 Jul 2012 01:13:11 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18yn2FK0iky/yjUsX2T7b13MnckiCvPBBZHpxqtbh k98A4b3k/FH8vG Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Mon, 30 Jul 2012 16:13:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120721131113.7B35C21F8646@ietfa.amsl.com> <266595E9-AB52-4269-BF78-C239DE25FC94@gmx.net> To: Brian Rosen X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: atoca@ietf.org Subject: Re: [atoca] The future of atoca X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 23:13:14 -0000 As expressed in earlier ATOCA meetings I do not have the same view.=20 In earlier meetings I was told that a subscribe - notify mechanism does = not work for scalability reason and for that reason =20 http://tools.ietf.org/html/draft-rosen-sipping-cap-04 was rejected.=20 Then, Richard defined a protocol that was supposed to describe an = alternative: http://tools.ietf.org/html/draft-barnes-atoca-meta-02 http://tools.ietf.org/html/draft-barnes-atoca-delivery-01 A client has to register with the alerting server and most likely has to = keep that subscription alive (with frequent retransmissions) to deal = with NATs and firewalls. The client can indicate certain language = features and other stuff in the request. Then, it seems that unicast UDP messages are sent to those who have = registered.=20 Since CAP messages (with S/MIME based signatures) are fairly large (see = http://tools.ietf.org/html/draft-barnes-atoca-escape-00) a fragmentation = is also added.=20 On Jul 30, 2012, at 2:43 PM, Brian Rosen wrote: > I don't agree. I think a lot of what Richard has proposed works. I = think some things could be improved (a draft I will write). =20 >=20 > Brian >=20 > On Jul 30, 2012, at 5:36 PM, Hannes Tschofenig wrote: >=20 >> The problem I see is that we actually don't have a proposal that = actually works. >> Abstract discussions about potential solutions don't help to make = progress.=20 >>=20 >>=20 >>=20 >=20 From mark.wood@engineer.com Tue Jul 31 07:13:30 2012 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 996C221F86D8 for ; Tue, 31 Jul 2012 07:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_50=0.001, 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 CDf+KdqrvChg for ; Tue, 31 Jul 2012 07:13:24 -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 926F521F86D7 for ; Tue, 31 Jul 2012 07:13:23 -0700 (PDT) X-Trace: 489517483/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$ON_NET_AUTH_ACCEPTED/pipex-customers/81.86.43.86/None/mark.wood@engineer.com X-SBRS: None X-RemoteIP: 81.86.43.86 X-IP-MAIL-FROM: mark.wood@engineer.com 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: Av8EAFLnF1BRVitW/2dsb2JhbABFgkq3KoEIgicIJSkVAhkEAQYkAxQnGgYfAQQeCQeFdoIAmj+zaYEFA5sPiGuBWoJggV4 X-IronPort-AV: E=Sophos;i="4.77,687,1336345200"; d="scan'208,217";a="489517483" 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; 31 Jul 2012 15:13:16 +0100 From: "'Mark Wood'" Sender: "Mark" To: Date: Tue, 31 Jul 2012 15:13:17 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002D_01CD6F2F.03B9B2A0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Ac1vJqFuTtyXRPpMRnmCMU/M2RUnfQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609 Message-Id: <20120731141323.926F521F86D7@ietfa.amsl.com> Subject: [atoca] Proposal for gap analysis. 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, 31 Jul 2012 14:13:30 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_002D_01CD6F2F.03B9B2A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Friends, There are some similarities and some differences between EU-ALERT/CMAS, (now known as WEA) and IP multicasting. IP multicast has some strengths that Cell Broadcast does not have, and some apparent weaknesses that may be either solvable or at least we can mitigate them. I have an expert knowledge of cellular multicast but am new to IP technologies, but learning fast. I am humble enough to accept correction as needed. But fist, there is a step we need to take as soon as practical. After a lot of 'too-ing' and 'fro-ing', its now widely agreed that any multicast based system would be greatly simplified by having a standard block of addresses dedicated to the function of public warning. Now the latest version of the 3GPP standard on 023.041 V11.1, does indeed reserve a generous block of addresses for this purpose. This would make it very easy for administrated system (AS) administrators to open a specific block of multicast addresses on distribution routers by default, without any worry about torrents of broadcast data flooding his network nor worry about if the message were truly authentic (as the government gateway guaranties this). And yet this does not preclude the administrator from opening other non governmental gateways at the policy of the AS if she wants to. Proposal 1 I believe that a good place to start would be to reserve a block of 255 multicast addresses, both in IP4 and IP6, for future development for multicast based public warning systems, and other civic purposes at the discretion of the member state. Then we can take a look at two alternative protocols, and look for a good way to emulate the geo-specificity feature of CB. 1. Should we create a sort of 'Cell Broadcast over IP Encapsulation protocol' in which cell broadcast messaging is wrapped up in a package format suitable for transmission by IP networks, and then rely on an app at the host to present the result to the user? There are two advantages to this approach. Information presently created at the originator system has been created in such a way as to respect the limitations that the mobile networks have placed upon the emergency management community, that the message must have less than 90 characters (80 bytes). Therefore a separate message origination systems, separate gateways and separate trust protocol rule set in the aggregator gateway system is not needed. Furthermore the user will see the same message exactly and in the same format no matter what device he looks at. All of this helps in a confused and panicky situation. The university of Delft noted that people like to see three different confirmations of something before they believe it. Furthermore such a small message payload will not raise any broadcast storm worries. 2. Or should we create a separate format and protocol designed to exploit the fact that IP networks do not have the restraints that 2G cell broadcast systems have, and can send megabytes of data in very rich multi media formats? The advantage would be much more functionality for the solution, but at the cost of complexity at the message originator side because message inputs would now become a lot more involved with many more functions to choose from. Nevertheless I think in the future this should be the goal, a sort of EU-ALERT V2. Maybe we should work on both, as they are not incompatible with each other; there is no problem in running them both side by side. Clearly it will be a few years down the road before the emergency management profession are sufficiently familiar with EU-ALERT/WEA to be confident enough with something much more demanding. Proposal 2 I believe we should look at how we should create a CB over IP encapsulation protocol. Proposal 3 We should look at how a more flexible public messaging multicast format would need to be framed. Geo specificity One area of significance is that of geo specificity. CB is attractive also because it is natively and passively geo specific (well, bluntly, but good enough). In the present IPAWS OPEN system, the originators signal their proposals to a gateway unit, which analyses the polygon and distributes it to networks which have service area under the polygon. Within the networks, a Cell Broadcast Centre (CBC) analyses the polygon and send the message only to cells which have service area under the polygon. Since a cell is typically about a few KM across, we have resolution down to about a neighbourhood. *However this is normally good enough*. All this is done passively without any position reporting, polling, data base interrogation, paging, SS7 signalling or any network signalling at all. We need to find a way to passively emulate this. I think it may not be as tough as all that, here is what I propose. The administrator of any system knows the physical location of access level switches and access wireless access points. Typically the distribution layer of routers in located on one campus and subnets rarely cover more than one building (at least subnets go with LANs which are normally in one building due to Ethernet limitations). Since Protocol Independent Multicast protocol (PIM) requires the setting up of RV points at which administrators control access to subsequent multicast addresses and their distribution, it should be fairly easy for an administrator to associate all of the public warning range of multicast addresses with a collective location, such as a ZIP code provided by a CUG at that Gateway. A development of PIM would automate this if we know something of the location of the distribution router. Yes, it's not rocket science, but it is way good enough for this application as it matches the geo specificity of Cell Broadcast really quite well (in fact is normally better). It's optional for us to use Internet Gateway Multicast Protocol IGMP, because you can subscribe a subnet to a multicast address by informing the Ethernet port on the distributing router that it has subscribed this subnet to this range of addresses. So therefore IGMP may not be as big a problem as anyone thinks. Remember that civic messages are very short (80 bytes) and quite rare, (one every 20 minutes for maybe a few days a year). This is trivial amounts of data so an administrator is not opening himself up to broadcast storms by doing this as they sometimes fear, (BPDU's are much more but no one thinks of switching spanning tree off). If someone would like to tell me what text is needed to make this an official suggestion, I am quite ready to oblige. We could not have done this before the 3GPP finished its work (this march), but they have, so It is time to do this now. Warm regards Mark Wood DRCF. PS A FRIEND OF MINE RECENTLY GOT HIS VERY FIRST GENUINE REAL CMAS MESSAGE ON HIS BLACKBERY, SO IT IS RUNNING CODE!! ------=_NextPart_000_002D_01CD6F2F.03B9B2A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Friends,

 

There are some similarities and some differences = between EU-ALERT/CMAS, (now known as WEA) and IP multicasting. IP multicast has some strengths = that Cell Broadcast does not have, and some apparent weaknesses that may be = either solvable or at least we can mitigate them. I have an expert knowledge of cellular multicast but am new to IP technologies, but learning fast. I am humble = enough to accept correction as needed.

 

But fist, there is a step we need to take as soon as practical.

 

After a lot of ‘too-ing’ and = ‘fro-ing’, its now widely agreed that any multicast based system would be greatly simplified by having a standard block of addresses dedicated to the = function of public warning.

 

Now the latest version of the 3GPP standard on = 023.041 V11.1, does indeed reserve a generous block of addresses for this purpose. =

 

This would make it very easy for administrated system = (AS) administrators to open a specific block of multicast addresses on = distribution routers by default, without any worry about torrents of broadcast data = flooding his network nor worry about if the message were truly authentic (as the = government gateway guaranties this). And yet this does not preclude the = administrator from opening other non governmental gateways at the policy of the AS if she = wants to.

 

 

Proposal 1

 

I believe that a good place to start would be to = reserve a block of 255 multicast addresses, both in IP4 and IP6, for future = development for multicast based public warning systems, and other civic purposes at = the discretion of the member state.

 

 

 

Then we can take a look at two alternative protocols, = and look for a good way to emulate the geo-specificity feature of = CB.

 

  1. Should we create a = sort of ‘Cell Broadcast over IP Encapsulation protocol’ in which cell = broadcast messaging is wrapped up in a package format suitable for = transmission by IP networks, and then rely on an app at the host to present the = result to the user? There are two advantages to this approach. Information = presently created at the originator system has been created in such a way as = to respect the limitations that the mobile networks have placed upon = the emergency management community, that the message must have less = than 90 characters (80 bytes). Therefore a separate message origination systems, = separate gateways and separate trust protocol rule set in the aggregator gateway = system is not needed. Furthermore the user will see the same message exactly = and in the same format no matter what device he looks at. All of this = helps in a confused and panicky situation. The university of Delft noted that people like to see three different confirmations of = something before they believe it. Furthermore such a small message payload = will not raise any broadcast storm worries.

 

  1. Or should we create a = separate format and protocol designed to exploit the fact that IP networks do not = have the restraints that 2G cell broadcast systems have, and can send = megabytes of data in very rich multi media formats? The advantage would be much = more functionality for the solution, but at the cost of complexity at = the message originator side because message inputs would now become a = lot more involved with many more functions to choose from. Nevertheless I = think in the future this should be the goal, a sort of EU-ALERT = V2.

 

Maybe we should work on both, as they are not = incompatible with each other; there is no problem in running them both side by side. = Clearly it will be a few years down the road before the emergency management = profession are sufficiently familiar with EU-ALERT/WEA to be confident enough with = something much more demanding.  

 

Proposal 2

 

I believe we should look at how we should create a CB = over IP encapsulation protocol.

 

Proposal 3

 

We should look at how a more flexible public = messaging multicast format would need to be framed.

 

 

Geo specificity

 

One area of significance is that of geo specificity. = CB is attractive also because it is natively and passively geo specific (well, bluntly, but good enough). In the present IPAWS OPEN system, the = originators signal their proposals to a gateway unit, which analyses the polygon and = distributes it to networks which have service area under the polygon. Within the = networks, a Cell Broadcast Centre (CBC) analyses the polygon and send the message = only to cells which have service area under the polygon. Since a cell is = typically about a few KM across, we have resolution down to about a neighbourhood. = *However this is normally good = enough*. All this is done passively without any position reporting, polling, data = base interrogation, paging, SS7 signalling or any network signalling at all. =  

 

We need to find a way to passively emulate this. =  I think it may not be as tough as all that, here is what I propose. =

 

The administrator of any system knows the physical = location of access level switches and access wireless access points. Typically = the distribution layer of routers in located on one campus and subnets = rarely cover more than one building (at least subnets go with LANs which are normally = in one building due to Ethernet limitations). Since Protocol Independent = Multicast protocol (PIM) requires the setting up of RV points at which administrators = control access to subsequent multicast addresses and their distribution, it = should be fairly easy for an administrator to associate all of the public warning = range of multicast addresses with a collective location, such as a ZIP code = provided by a CUG at that Gateway. A development of PIM would automate this if we = know something of the location of the distribution router. Yes, it’s = not rocket science, but it is way good enough for this application as it matches = the geo specificity of Cell Broadcast really quite well (in fact is normally = better).

 

It’s optional for us to use Internet Gateway = Multicast Protocol IGMP, because you can subscribe a subnet to a multicast address = by informing the Ethernet port on the distributing router that it has = subscribed this subnet to this range of addresses. So therefore IGMP may not be as = big a problem as anyone thinks. Remember that civic messages are very short = (80 bytes) and quite rare, (one every 20 minutes for maybe a few days a = year). This is trivial amounts of data so an administrator is not opening himself up = to broadcast storms by doing this as they sometimes fear, (BPDU’s are = much more but no one thinks of switching spanning tree off). =

 

If someone would like to tell me what text is needed = to make this an official suggestion, I am quite ready to = oblige.

 

We could not have done this before the 3GPP finished = its work (this march), but they have, so It is time to do this now. =

 

Warm regards Mark Wood = DRCF.

 

PS

 

A FRIEND OF MINE RECENTLY GOT HIS VERY FIRST GENUINE = REAL CMAS MESSAGE ON HIS BLACKBERY, SO IT IS RUNNING = CODE!!

 

 

 

 

 

 

------=_NextPart_000_002D_01CD6F2F.03B9B2A0--