Re: [atoca] ATOCA status at time of closing

Alexandru Petrescu <> Wed, 24 July 2013 16:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1804C21F94DC for <>; Wed, 24 Jul 2013 09:03:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.249
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4sZhNfWOD-hM for <>; Wed, 24 Jul 2013 09:03:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0074E11E80DF for <>; Wed, 24 Jul 2013 09:02:55 -0700 (PDT)
Received: from ( []) by (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 ( []) by (8.14.4/8.14.4) with ESMTP id r6OG2r6r014336 for <>; Wed, 24 Jul 2013 18:02:53 +0200 (envelope-from
Received: from [] ( []) by (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: <>
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
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-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).


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