From alexandru.petrescu@gmail.com Wed Jul 24 09:03:06 2013 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 1804C21F94DC for ; Wed, 24 Jul 2013 09:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] 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 4sZhNfWOD-hM for ; Wed, 24 Jul 2013 09:03:00 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 0074E11E80DF for ; Wed, 24 Jul 2013 09:02:55 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r6OG2rhI010213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 24 Jul 2013 18:02:53 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r6OG2r6r014336 for ; Wed, 24 Jul 2013 18:02:53 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r6OG2lB0003889 for ; Wed, 24 Jul 2013 18:02:53 +0200 Message-ID: <51EFFAA7.3000607@gmail.com> Date: Wed, 24 Jul 2013 18:02:47 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: atoca@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [atoca] ATOCA status at time of closing X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 16:03:06 -0000 Thanks for the summary! I was wondering whether in the course of action competitors to new ATOCA technology were identified? Something along the lines 'don't do ATOCA because X already does it', or similar? I am aware of the following other technologies, according simply to povs of Citizen and Generator (although there are more actors involved). From citizen point of view: - one subscribes her mobile phone number to a City Hall administration and selects the type of alerts to receive by SMS. - one bookmarks the URL of Weather (or other type) Alert web pages. From alert generator point of view: - securely contact the Authority to inform of Alert. - privately contact peer alert generators to confirm hypothesis. (this could be done by citizen as well). (I am asking this after having been pointed to the ATOCA WG coming from an effort in Intelligent Transportation Systems - ITS, where 'alerts' may be sent between vehicles indicating approach avoid collision). Alex Le 14/11/2012 00:20, Martin Thomson a écrit : > In addition to reaching rough consensus on closing the group, the > working group also concluded that it is important to record, for > posterity, what course was followed to reach this point. > > The working group initially performed some exploration of the > problem space as part of a requirements analysis process. The > history of draf-ietf-atoca-requirements reveals some of the > conclusions that were made during this process. > > Broadly speaking the following problems were identified: > > - point-to-point delivery of alerts publish/subscribe architectures > were considered likely solutions; a candidate solution was proposed > for SIP (draft-rosen-atoca-sip-cap); XMPP (XEP-0127) was also > identified > > - point-to-multipoint delivery of alerts draft-barnes-atoca-delivery > was proposed for this purpose > > - secure identification of alert originators a candidate solution > was proposed for the alert envelope (draft-barnes-atoca-escape) > > - discovery of (or delegation of identification for) trusted alert > originators - discovery of alert distribution channels these were > not considered necessary for some classes of alerting > draft-barnes-atoca-meta was proposed to address both aspects of > discovery > > The work in the group concluded primarily due to a lack of > engagement. It was not clear that there was sufficiently widespread > support for the work that the group was conducting. The small > number of technical contributions did not attract adequate feedback > or implementation. > > During the course of the work it became apparent that there are some > problems here that could benefit from the expertise that is available > in the IETF. However, with the problem so loosely scoped, this group > was considered unlikely to achieve consensus behind a solution at the > present. > > > > > > > _______________________________________________ atoca mailing list > atoca@ietf.org https://www.ietf.org/mailman/listinfo/atoca > From martin.thomson@gmail.com Wed Jul 24 20:22:43 2013 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 0AB6221F89D8 for ; Wed, 24 Jul 2013 20:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 R7COFBAi6N3D for ; Wed, 24 Jul 2013 20:22:36 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8CE21F9A4C for ; Wed, 24 Jul 2013 20:22:28 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id ey16so5909268wid.1 for ; Wed, 24 Jul 2013 20:22:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qnOBjIjkrBQwOAZOfGAXQY6upEYeO8M4by9RzDk+5qE=; b=t/zMVDj5dQA+/DXOodn6N9KjsIVqdLuCF795UkHIxGgVNyNuqqmEdcMm77wwqDq9S5 GrOx0MHqanK07TIE+TZFUxE99tAEBtgG97O/hvBCSv/n6jQqYg9vlXHFUjS5G2we+xna SRVHMo5o2Pb1rDKjzrq94pHxmvNkjxvKKMtdUXL4E9WCMjmLepiN+5VtcPab//fZYFgi Xey6QBGGBSIVCC6iQ52orvupWXfBLo8Az5FJ/Zb77ocbOTyYRxRKIzsRe8pSaqScfJxa age3qMCAAzCQI8QV4KEws4mzcwwxV/pgbp3uEaCo9OHIQv+RQbmoujyyVXakSI38k0IC en7w== MIME-Version: 1.0 X-Received: by 10.180.187.235 with SMTP id fv11mr377955wic.65.1374722547681; Wed, 24 Jul 2013 20:22:27 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Wed, 24 Jul 2013 20:22:27 -0700 (PDT) In-Reply-To: <51EFFAA7.3000607@gmail.com> References: <51EFFAA7.3000607@gmail.com> Date: Wed, 24 Jul 2013 20:22:27 -0700 Message-ID: From: Martin Thomson To: Alexandru Petrescu Content-Type: text/plain; charset=UTF-8 Cc: atoca@ietf.org Subject: Re: [atoca] ATOCA status at time of closing 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, 25 Jul 2013 03:22:43 -0000 On 24 July 2013 09:02, Alexandru Petrescu wrote: > I was wondering whether in the course of action competitors to new ATOCA > technology were identified? Something along the lines 'don't do ATOCA > because X already does it', or similar? There were no alternative technologies that were roughly comparable. 3GPP defines cell broadcast technologies that have a wide reach, but only within their networks. Those would be the closest. In many respects, that is part of why this work took so long to close. There is a big gap to fill.