Re: [atoca] ATOCA status at time of closing

[Alexandru Petrescu <[e-mail]>]

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
> [e-mail] https://www.ietf.org/mailman/listinfo/atoca
>