[atoca] ATOCA status at time of closing

[Martin Thomson <[e-mail]>]

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.