Subject: Re: [earlywarning] WG Review: Authority to Citizen Alert (ATOCA)
From: "DRAGE, Keith (Keith)" <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Mon, 26 Jul 2010 08:23:02 +0200
List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " <earlywarning.ietf.org>

I notice it says SIP is one of the candidates for this.

Surely if SIP is to be used, I assume that criteria for selection of a mechanims applies as has already been detailed for instant messaging.

Has someone already evaluated the criteria for warnings, and therefore verfied that they are appropriate for transport in SIP messages, as opposed to using MRCP.

I know the ETWS / CMA alerts all fit into 170 odd characters by definition, because that is the maximum length of the transport, but even the alert identity information I have seen discussed elsewhere, and proposed for use in this protocol, seems to be an OID and could be many 10s of characters in its own right. 

So all I am asking is whether the messaging criteria have already been evaluated and been found suitable for SIP transport, as opposed to a separate media stream using MRCP.

regards

Keith

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of IESG Secretary
> Sent: Tuesday, July 20, 2010 6:00 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [earlywarning] WG Review: Authority to Citizen Alert (ATOCA)
> 
> A new IETF working group has been proposed in the Real-time 
> Applications and Infrastructure Area.  The IESG has not made 
> any determination as yet.
> The following draft charter was submitted, and is provided 
> for informational purposes only. Please send your comments to 
> the IESG mailing
> list ([email-masked]) by Tuesday, July 27, 2010.               
>            
>                 
> 
> Authority to Citizen Alert (ATOCA)
> ----------------------------------
> Current Status: Proposed Working Group
> 
> Last Modified: 2010-07-15
> 
> Chairs(s)
> TBD
> 
> Real-time Applications and Infrastructure Area Directors:
>    Gonzalo Camarillo <[email-masked]>
>    Robert Sparks <[email-masked]>
> 
> Real-time Applications and Infrastructure Area Advisor:
>    Robert Sparks <[email-masked]>
> 
> Mailing Lists:
>   General Discussion: [email-masked]
>   To Subscribe: <https://www.ietf.org/mailman/listinfo/earlywarning>
>   Archive: <http://www.ietf.org/mail-archive/web/earlywarning>
> 
> Real-time Applications and Infrastructure Area Advisor:
>    Robert Sparks <[email-masked]>
> 
> Description of Working Group:
> 
> There are a variety of mechanisms that authorities have 
> available to notify citizens and visitors during emergency 
> events. Traditionally, they have done so with broadcast 
> networks (radio and television). For commercial mobile 
> devices, broadcasting services such as the Public Warning 
> System (PWS), the Earthquake and Tsunami Warning System 
> (ETWS), and the Commercial Mobile Alert System (CMAS) are 
> standardized and are in various stages of deployment.  The 
> Internet provides another way for authority-to-citizen alerts 
> to be sent, but it also presents new challenges. While there 
> are some existing layer 2 mechanisms for delivering alerts, 
> the work in this group focuses on delivering alerts to IP 
> endpoints only.
> 
> The general message pattern that this group is intended to 
> address is the sending of alerts from a set of pre-authorized 
> agents (e.g., governmental agencies) to a large population 
> without impacting layer 2 networks (e.g. causing congestion 
> or denial of service).
> 
> The goal of this group is not to specify how originators of 
> alerts obtain authorization, but rather how an ATOCA system 
> can verify authorization and deliver messages to the intended 
> recipients. A critical element of the work are the mechanisms 
> that assure that only those pre-authorized agents can send 
> alerts via ATOCA, through an interface to authorized alert 
> distribution networks (e.g., iPAWS/DM-Open in the U.S.).
> 
> The ATOCA effort is differentiated from and is not intended 
> to replace other alerting mechanisms (e.g., PWS, CMAS, ETWS), 
> as the recipients of ATOCA alerts are the wide range of 
> devices connected to the Internet and various private IP 
> networks, which humans may have "at hand" to get such events, 
> as well as automatons who may take action based on the 
> alerts. This implies that the content of the alert contains 
> some information, which is intended to be consumed by humans, 
> and some which is intended to be consumed by automatons.  
> 
> Ideally, the alerts would contain, or refer to media other 
> than text media (e.g., audio and/or video). The initial work 
> in the group is focused on small messages, which may be 
> mechanically rendered by the device in other forms (text to 
> speech for example). Future work in the group may investigate 
> rich media.
> 
> In situations of a major emergency there could be scenarios 
> where there are multiple alerts generated that may require 
> that a priority mechanism (defined by alert originator 
> policy) has to be used. The work on a resource priority 
> mechanism is out of scope of the initial charter, but may be 
> revisited at a later date.
> 
> Which devices should get alerts is primarily driven by location.  
> The first set of recipients that must be catered for are 
> those within the area identified by the alert originator to 
> be affected by the emergency event.  In many jurisdictions, 
> there are regulations that define whether recipients/devices 
> within the affected area have opt-in or opt-out capability, 
> but the protocols ATOCA will define will include both opt-in 
> and opt-out mechanisms. The group will explore how to support 
> both opt-in and opt-out at the level of communication 
> protocols and/or device behavior.
> 
> Another class of recipients that are in scope of the work are 
> explicit opt-in subscriptions which ask for alerts for a 
> specified location, not necessarily the physical location of 
> the device itself.
> An example of such a subscription would be 'send me alerts 
> for location x' (previously determined as the location of interest).
> This work may build on existing IETF GEOPRIV location work.
> 
> There are efforts in other fora on early warning, which will 
> be considered in this effort.  For example, we expect to make 
> use of the OASIS Common Alerting Protocol (CAP) for the 
> encoding of alerts. OGC, ATIS, TIA, ITU-T, ETSI and 3GPP also 
> have alert efforts underway, and consultation with these 
> efforts will be undertaken to avoid unnecessary duplication 
> of effort and also to avoid unintentional negative impacts on 
> the networks. Of course, existing protocols for delivering 
> messages (e.g., SIP, XMPP, or SMTP) will be the basis for the 
> message delivery system of this working group.
> Any service discovery mechanisms defined by the group are 
> expected to reuse existing discovery frameworks.
> 
> The security implications of mechanisms that can send alerts 
> to billions of devices are profound, but the utility of the 
> mechanism encourages us to face the problems and solve them. 
> In addition, the potential performance and congestion impacts 
> to networks resulting from sending alert information to 
> billions of devices must be considered and solved if such a 
> service is implementable. To avoid manual configuration of 
> servers distributing alerts a discovery mechanism will be specified.
> 
> NOTE FOR CHARTER REVIEW (this section to be removed before charter
> approval): Some early drafts related to this proposed work are
> * draft-norreys-ecrit-authority2individuals-requirements
> * draft-rosen-ecrit-lost-early-warning
> * draft-rosen-atoca-server-discovery
> * draft-rosen-atoca-cap
> * draft-schulzrinne-atoca-requirements
> 
> Goals and Milestones
> 		  
> Jan 2011  Submit "Terminology and Framework" to the IESG for 
>          publication as Informational 
> 		  
> Apr 2011  Submit "Addressing security, performance and
>          congestion issues for alert distribution" to the 
>          IESG for publication as Informational 
> 
> Apr 2011 Submit conveying point-to-point Authority to Citizen Alerts
>         to the IESG for publication as Proposed Standard
> 
> May 2011  Submit "Discovering alerting servers" to the IESG for 
>          publication as Proposed Standard
> 		  
> Jun 2011 Submit conveying point-to-multipoint Authority to Citizen 
>         Alerts to the IESG for publication as Proposed Standard
> 		  
> Aug 2011 Submit "Considerations for interworking with currently 
>         deployed alert distribution systems" to the IESG for 
>         publication as Informational
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning
> 
From: Brian Rosen <[email-masked]>
Date: Thu, 22 Jul 2010 08:59:01 -0400
To: "Thomson, Martin" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Hannes Tschofenig <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [earlywarning] Comments	on	draft-schulzrinne-atoca-requirements-00

My problem with this is that it shifts the burden to the endpoints, and that is how you get incompatibilities.

I understand it is hard to get a decent taxonomy.

Having none means endpoints either miss alerts they wanted, or get alerts they don't, because there is no standard for alert taxonomy.

Brian

On Jul 21, 2010, at 8:40 PM, Thomson, Martin wrote:

>> I suspect that there will never be an agreement on the categories and
>> the only way to go with this is to
>> * just define a top level service
>> * pick a few sub-level services
>> * provide extension points.
> 
> I'm starting to think that avoiding taxonomies should be a goal.  Let's see if we can't avoid it first.
> 
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

From: "Thomson, Martin" <[email-masked]>
To: Hannes Tschofenig <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 22 Jul 2010 08:40:47 +0800
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [earlywarning] Comments	on	draft-schulzrinne-atoca-requirements-00

PiBJIHN1c3BlY3QgdGhhdCB0aGVyZSB3aWxsIG5ldmVyIGJlIGFuIGFncmVlbWVudCBvbiB0aGUg
Y2F0ZWdvcmllcyBhbmQNCj4gdGhlIG9ubHkgd2F5IHRvIGdvIHdpdGggdGhpcyBpcyB0bw0KPiAq
IGp1c3QgZGVmaW5lIGEgdG9wIGxldmVsIHNlcnZpY2UNCj4gKiBwaWNrIGEgZmV3IHN1Yi1sZXZl
bCBzZXJ2aWNlcw0KPiAqIHByb3ZpZGUgZXh0ZW5zaW9uIHBvaW50cy4NCg0KSSdtIHN0YXJ0aW5n
IHRvIHRoaW5rIHRoYXQgYXZvaWRpbmcgdGF4b25vbWllcyBzaG91bGQgYmUgYSBnb2FsLiAgTGV0
J3Mgc2VlIGlmIHdlIGNhbid0IGF2b2lkIGl0IGZpcnN0Lg0KDQo

From: "Thomson, Martin" <[email-masked]>
To: Hannes Tschofenig <[email-masked]>
Date: Thu, 22 Jul 2010 08:32:12 +0800
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [earlywarning] Review of draft-rosen-atoca-cap

From: "Thomson, Martin" <[email-masked]>
To: Hannes Tschofenig <[email-masked]>
Date: Thu, 22 Jul 2010 08:28:16 +0800
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [earlywarning] comment on draft-rosen-atoca-server-discovery

From: "Carl Reed" <[email-masked]>
To: "Hannes Tschofenig" <[email-masked]>, <[email-masked]>
Date: Wed, 21 Jul 2010 15:23:55 -0600
Cc: [email-masked], [email-masked]
Subject: Re: [earlywarning] Commentson	draft-schulzrinne-atoca-requirements-00

This is a multi-part message in MIME format.

------=_NextPart_000_03F6_01CB28E8.BBD91180
Content-Type: text/plain;
	format=flowed;
	charset="utf-8";
	reply-type=original
Content-Transfer-Encoding: 7bit

The requirements document is attached.

Regards

Carl

----- Original Message ----- 
From: "Hannes Tschofenig" <[email-masked]>
To: "Carl Reed" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, July 20, 2010 2:38 PM
Subject: Re: [earlywarning] Commentson 
draft-schulzrinne-atoca-requirements-00

> Good to hear that CAP 2.0 will include a GML profile.
> What location shapes are going to be supported? We ran into this issue in 
> ECRIT.
>
> -------- Original-Nachricht --------
>> Datum: Tue, 20 Jul 2010 14:33:05 -0600
>> Von: "Carl Reed" <[email-masked]>
>> An: "Hannes Tschofenig" <[email-masked]>, 
>> [email-masked]
>> CC: "Tschofenig, Hannes \\(NSN - FI/Espoo\\)" 
>> <[email-masked]>, [email-masked]
>> Betreff: Re: [earlywarning] Commentson 
>> draft-schulzrinne-atoca-requirements-00
>
>> Correct -
>>
>> CAP is a payload and is (theoretically) transport agnostic. FYI, CAP 2.0
>> will incorporate a GML profile that will include the same geometry types
>> (plus additional ones) as the LO GML Geoshape Application Schema.  The 
>> only
>> issue is that the OASIS GML "where" profile will use GML 3.2.1 to be
>> consistent with the ISO version of GML and the LO Geoshape schema uses 
>> GML 3.1.1.
>>
>> Cheers
>>
>> Carl
>> an OASIS CAP contributor
>>   ----- Original Message ----- 
>>   From: Hannes Tschofenig
>>   To: [email-masked]
>>   Cc: [email-masked] ; Tschofenig,Hannes (NSN - FI/Espoo)
>>   Sent: Tuesday, July 20, 2010 12:33 PM
>>   Subject: Re: [earlywarning] Commentson
>> draft-schulzrinne-atoca-requirements-00
>>
>>
>>   Hi Tony,
>>
>>   thanks for pointing to the CAP Implementer's workshop and in particular
>> the "Draft Implementors Note on Harmonizing Certain Identifiers in CAP
>> Implementations"
>> http://www.wmo.int/pages/prog/www/ISS/Meetings/WIS-CAP_Geneva2009/DraftNote.doc.
>>
>>   My understanding of that document (and my participation at an earlier
>> workshop) is there is room for improvement in the CAP specification from 
>> an
>> interoperability point of view.
>>
>>   Since the work in this group only focuses on the transport of alerts
>> rather than the actual content of the alerts we should not be impacted.
>>
>>   Ciao
>>   Hannes
>>
>>   On 16.07.2010 13:05, Tony Rutkowski wrote:
>>      Hi Martin,
>>
>>     You might also consider the concepts on architecture
>>     and identity constructs that emerged from last year's
>>     global gathering of emergency messaging authorities
>>     convened at the World Meteorological Organization.
>>
>> http://www.wmo.int/pages/prog/www/ISS/Meetings/WIS-CAP_Geneva2009/DocPlan.html
>>
>>     See especially the Draft Implementors Note.
>>
>>     best,
>>     tony
>>
>>
>>       I'm currently unsure about the value of this document.  The
>> different components of the document are somewhat disjointed: problem 
>> statement,
>> architectural model, and requirements don't support each other 
>> particularly
>> well.
>>
>>       General Comments:
>>
>>       This model presented in this document is highly abstract.  Without 
>> a
>> more concrete relationship with the requirements, it's hard to understand
>> the value of the model.  Section 3 looks too much like a copy-and-paste
>> from the email architecture.
>>
>>       A simpler model might be a better starting point:
>>          author [1..*] ->  [1] aggregator [1] ->  [1..*] recipient
>>
>>       Such a model can be evolved to involve relays or mediators by
>> overlapping and chaining roles, just as we do for the GEOPRIV model. 
>> Nothing
>> wrong with giving these entities names and descriptions, but they can 
>> form
>> part of a second architectural layer.
>>
>>
>>
>>     _______________________________________________
>>     earlywarning mailing list
>>     [email-masked]
>>     https://www.ietf.org/mailman/listinfo/earlywarning
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
>>   _______________________________________________
>>   earlywarning mailing list
>>   [email-masked]
>>   https://www.ietf.org/mailman/listinfo/earlywarning
> 

------=_NextPart_000_03F6_01CB28E8.BBD91180
Content-Type: application/msword;
	name="2009 September OASIS where GML profile requirements v 2.doc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="2009 September OASIS where GML profile requirements v 2.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAXQAAAAAAAAAA
EAAAXwAAAAEAAAD+////AAAAAFwAAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////

------=_NextPart_000_03F6_01CB28E8.BBD91180--

Date: Wed, 21 Jul 2010 11:30:08 +0200
From: "Hannes Tschofenig" <[email-masked]>
To: "Thomson, Martin" <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [earlywarning] Comments	on	draft-schulzrinne-atoca-requirements-00

Hi Martin, 

I searched around a bit and found this document:
http://www.adrc.asia/publications/TDRM2003Dec/19_MR.%20SATORU%20NISHIKAWA.pdf

That document introduced another classification, which I believe is different from what can be found in the CAP document. 

I wonder how the two relate to each other. 

I suspect that there will never be an agreement on the categories and the only way to go with this is to
* just define a top level service 
* pick a few sub-level services
* provide extension points. 

Ciao
Hannes

-------- Original-Nachricht --------
> Datum: Wed, 21 Jul 2010 07:22:21 +0800
> Von: "Thomson, Martin" <[email-masked]>
> An: Hannes Tschofenig <[email-masked]>, "[email-masked]" <[email-masked]>
> CC: "[email-masked]" <[email-masked]>, "Tschofenig, 	Hannes \\(NSN - FI/Espoo\\)" <[email-masked]>
> Betreff: Re: [earlywarning] Comments	on	draft-schulzrinne-atoca-requirements-00

> For me, the GLIDE number was of interest, particularly in the design of
> the service URN space.  It might be worth looking into a comparison of the
> two taxonomies.
> 
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Wednesday, 21 July 2010 4:33 AM
> To: [email-masked]
> Cc: Thomson, Martin; Tschofenig, Hannes (NSN - FI/Espoo);
> [email-masked]
> Subject: Re: [earlywarning] Comments on
> draft-schulzrinne-atoca-requirements-00
> 
> Hi Tony,
> 
> thanks for pointing to the CAP Implementer's workshop and in particular
> the "Draft Implementors Note on Harmonizing Certain Identifiers in CAP
> Implementations"
> http://www.wmo.int/pages/prog/www/ISS/Meetings/WIS-CAP_Geneva2009/DraftNote.doc.
> 
> My understanding of that document (and my participation at an earlier
> workshop) is there is room for improvement in the CAP specification from an
> interoperability point of view.
> 
> Since the work in this group only focuses on the transport of alerts
> rather than the actual content of the alerts we should not be impacted.
> 
> Ciao
> Hannes
> 
> On 16.07.2010 13:05, Tony Rutkowski wrote:
>  Hi Martin,
> 
> You might also consider the concepts on architecture
> and identity constructs that emerged from last year's
> global gathering of emergency messaging authorities
> convened at the World Meteorological Organization.
> http://www.wmo.int/pages/prog/www/ISS/Meetings/WIS-CAP_Geneva2009/DocPlan.html
> 
> See especially the Draft Implementors Note.
> 
> best,
> tony
> 
> 
> I'm currently unsure about the value of this document.  The different
> components of the document are somewhat disjointed: problem statement,
> architectural model, and requirements don't support each other particularly well.
> 
> General Comments:
> 
> This model presented in this document is highly abstract.  Without a more
> concrete relationship with the requirements, it's hard to understand the
> value of the model.  Section 3 looks too much like a copy-and-paste from the
> email architecture.
> 
> A simpler model might be a better starting point:
>    author [1..*] ->  [1] aggregator [1] ->  [1..*] recipient
> 
> Such a model can be evolved to involve relays or mediators by overlapping
> and chaining roles, just as we do for the GEOPRIV model.  Nothing wrong
> with giving these entities names and descriptions, but they can form part of a
> second architectural layer.
> 
> _______________________________________________
> earlywarning mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/earlywarning
> 

Date: Wed, 21 Jul 2010 11:22:49 +0200
From: "Hannes Tschofenig" <[email-masked]>
To: "Thomson, Martin" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [earlywarning] Comments on draft-schulzrinne-atoca-requirements-00

Hi Martin, 

a quick reply to your comment below. 

-------- Original-Nachricht --------
> Datum: Wed, 21 Jul 2010 08:25:31 +0800
> Von: "Thomson, Martin" <[email-masked]>
> An: Hannes Tschofenig <[email-masked]>
> CC: "Tschofenig, Hannes \\(NSN - FI/Espoo\\)" <[email-masked]>, "[email-masked]" <[email-masked]>
> Betreff: Re: [earlywarning] Comments on draft-schulzrinne-atoca-requirements-00

> Hi Hannes,
> 
> Good terminology and a consistently applied architectural model help
> greatly.  My concern is that the email architecture has been appropriated a
> little too liberally.
> 
> For an end-to-end model, such as you have selected, then a simpler
> introduction might make it easier to understand.  This application has far less
> baggage than email, and far less accumulated knowledge.

I like the step-wise refinement approach you are suggesting. 

> 
> Highest layer: Basic goal:
> 
>    Author --> Recipient
> 
> Next layer: Actors use devices:
> 
>  Author --> Originator => Receiver --> Recipient
> 
> Next layer: Recognize deployment constraints:
> 
>   Author --> Originator => Relay(s) => Receiver --> Recipient 
> 
> and
> 
>   Author --> Originator => Relay(s) => Gateway [--> Recipient]
> 
> > The only entity I was not quite sure about is the "return handler".
> 
> The mediator role also seems redundant in this architecture, so unless you
> have a strong use case, I'd advocate for its removal:
> 
>   Author --> Recipient = Author --> Recipient
>                 \            /
>                  `-Mediator-’
> 

The mediator is essentially another name for an aggregator. I believe that the role of an aggregator is going to be very common in these types of alert distribution services (from a security point of view in particular). 

While I see lots of "end-to-end" mechanisms being used for weather alert I have my doubt that the same type of approach is used for other, more governmental focuses alerts. 

I initially used the term "aggregator" but with the email terminology I did not want to step away from what has been suggested there.

One example for an aggregator is the work Google is doing with their Kipendo, see http://www.wmo.int/pages/prog/www/ISS/Meetings/WIS-CAP_Geneva2008/Google.ppt. 

(I am fine with dropping the return handler.)

> 
> > A few more notes inline:
> > 
> > Currently, we have the following models in the draft that try to
> > classify the technological mechanisms being used:
> > 
> >     1.  Alerts may be addressed to all individuals within a certain
> >         geographic area.  Today, this is often realized with the help
> > of
> >         dedicated functionality provided by link layer technology
> > (e.g.,
> >         multicast, broadcast).
> > 
> > 
> > The work in other SDOs has focused on this topic. In fact many of the
> > alerts are rather sent to a specific network topology (such as specific
> > set of base stations) than with a specific location focus. The
> > assumption obviously is that a specific BS covers a specific location.
> > 
> > 2.  Alerts need to be delivered to dedicated end points via unicast
> >         messaging.
> > 
> > 
> > This is still push communication but clearly different from #1. It is
> > different from #3 since there is an implicit subscription.
> 
> The prior existence (or not) of mechanisms seems like poor justification
> for the sorts of classification you are describing.  The implicit
> subscription concept seems like a more compelling categorization.
> 
> However, it's not clear to me that a subscription is not possible in at
> least some of these cases.  We probably need more input on that aspect.
> 
I am looking forward to hear other classifications. 
When looking at the charter text and the deliverables I believe the current classification makes some sense. 

Item #3 refers to the event package, item #2 refers to conveyance of CAP, and item #1 refers to the interworking and lower layer considerations. 

Ciao
Hannes

> ..
> --Martin
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

Date: Wed, 21 Jul 2010 11:15:22 +0200
From: "Hannes Tschofenig" <[email-masked]>
To: "Thomson, Martin" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [earlywarning] Review of draft-rosen-atoca-cap

Hi Martin, 

> Thanks for taking the time Hannes,
> 
> I really wanted to highlight what I thought needed work.  We're obviously
> still at a very early stage in this work.
> 
> > The first challenge we ran into was the lack of a definition of alerts.
> > We tried to put a list of alert types in
> > http://tools.ietf.org/html/draft-rosen-atoca-server-discovery-00 (see
> > Section 6.1) but faced a lot of resistance on the mailing list (see
> > http://www.ietf.org/mail-
> > archive/web/earlywarning/current/msg00130.html).
> > 
> > Before this aspect is addressed it is a bit difficult to say whether
> > filters, service URNs, resource lists, etc. are the right approach.
> 
> The alternative is tougher, but potentially more robust.  You have a
> single service with no associated taxonomy: urn:service:warning
> 
> The results of a query on this service returns all applicable services for
> the area.  Each contains a description.  The user chooses the warning
> services based on these descriptions.
> 
> There are costs, but it avoids the sticky taxonomy problem.

Interesting idea. Would be worthwhile to check how many different warning alert one would get with such an approach (in a specific geographical area). 

> 
> Another approach is to allow for services to be identified with
> proprietary URI identifiers.  These generic identifiers could be discovered using
> out-of-band means (side of bus, web search).  Then LoST doesn't come into it
> at all, SIP routing (possibly location-based) does all the hard work.  It's
> probably not-cool if we don't use LoST though.  

Probably the right way is often somewhere in the middle. Currently the ITU-T tries to establish a registry of organizations distributing alerts. One can obviously retrieve the list of organizations from there. A user would not want to do that, however. Instead, they would more likely opt for two approaches: (a) use a preconfigured list of organizations, or (b) use an aggregator that does these types of things for them. 

Ciao
Hannes

> 
> --Martin
> 
> ...snipped...
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

Date: Wed, 21 Jul 2010 11:00:46 +0200
From: "Hannes Tschofenig" <[email-masked]>
To: "Thomson, Martin" <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] comment on draft-rosen-atoca-server-discovery

Hi Martin, 

I agree that it would be desirable to have a single format for alerts only. I do, however, not expect this to happen. 

Additionally, there will be a number of ways to convey alerts (the transport aspect, like we have it with other protocols as well). 

Hence, in the context with this specific document I was expecting that LoST would allow us to discover the format/transport mechanism through which a client can obtain these alerts. This would be very much in line with the way how we designed LoST to work for regular emergency services as well. 

Do you think that this makes sense?

Ciao
Hannes

-------- Original-Nachricht --------
> Datum: Wed, 21 Jul 2010 06:40:09 +0800
> Von: "Thomson, Martin" <[email-masked]>
> An: Hannes Tschofenig <[email-masked]>
> CC: "[email-masked]" <[email-masked]>
> Betreff: RE: [earlywarning] comment on draft-rosen-atoca-server-discovery

> 
> 
> > -----Original Message-----
> > From: Hannes Tschofenig [mailto:[email-masked]]
> > Sent: Tuesday, 20 July 2010 10:05 PM
> > 
> > Hi Martin,
> > 
> > please expand a bit on what you meant with the GeoRSS comment.
> > 
> > The reason for having GeoRSS mentioned in there is that GeoRSS is quite
> > widely used for distributing alerts and there will always be different
> > ways to distribute alerts.
> > 
> > Are you suggesting not to use GeoRSS?
> 
> Not at all, though I am pointing out that GeoRSS provides some of the same
> capabilities that CAP does: it includes parameters for time, author, and
> location.  Having duplicated functions might result in an interoperability
> mismatch - one implementation expects location in CAP, another omits it in
> favour of the GeoRSS.  Any specification will have to deal with this.  If
> there is already experience in the matter, then looking at existing behaviour
> will certainly help.
> 
> > 
> > Ciao
> > Hannes
> > 

Date: Wed, 21 Jul 2010 10:38:52 +0200
From: Gonzalo Camarillo <[email-masked]>
To: Peter Saint-Andre <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [earlywarning] WG Review: Authority to Citizen Alert (ATOCA)

Hi,

yes, the process is not clear for many people. There is a thread about
this in the RAI list:

http://www.ietf.org/mail-archive/web/rai/current/msg00889.html

Cheers,

Gonzalo

On 21/07/2010 12:29 AM, Peter Saint-Andre wrote:
> The process is:
> 
> 1. Internal IESG review
> 
> 2. Send it out for external review
> 
> 3. Final determination (based on external review)
> 
> We're at Step 2. :)
> 
> On 7/20/10 4:25 PM, ken carlberg wrote:
>> Hmmmm,  I thought that there were more concerns than that stated by
>> Robert given the comment in the announcement stating "The IESG has
>> not made any determination as yet", which seemed to run contrary to
>> Robert's statement that "the ATOCA charter was approved".
>>
>> If I mis-read things, then I'll subscribe to those famous words of
>> Rosana Rosana Dana....."never mind" :-)
>>
>> cheers,
>>
>> -ken
>>
>>
>> On Jul 20, 2010, at 6:16 PM, Marc Linsner wrote:
>>
>>> Ken,
>>>
>>> Did you see Robert's email:
>>>
>>> http://www.ietf.org/mail-archive/web/earlywarning/current/msg00323.html
>>>
>>>
>>>
> -Marc-
>>>
>>>
>>> On 7/20/10 5:56 PM, "ken carlberg" <[email-masked]> wrote:
>>>
>>>> Hi,
>>>>
>>>>> A new IETF working group has been proposed in the Real-time
>>>>> Applications and Infrastructure Area.  The IESG has not made
>>>>> any determination as yet. The following draft charter was
>>>>> submitted, and is provided for informational purposes only.
>>>>> Please send your comments to the IESG mailing list
>>>>> ([email-masked]) by Tuesday, July 27, 2010.
>>>>
>>>> given the wording of the above, the proposed working group was at
>>>> least discussed internally within the IESG.  Would it be possible
>>>> to get a summary of the issues/concerns expressed by the IESG?
>>>> It would be helpful to have a perspective to focus comments from
>>>> the masses, and avoid the generic and uninformative "I support
>>>> this effort becoming a working group" statement
>>>>
>>>> kindest regards,
>>>>
>>>> -ken
>>>>
>>>> _______________________________________________ earlywarning
>>>> mailing list [email-masked] 
>>>> https://www.ietf.org/mailman/listinfo/earlywarning
>>>
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning
> 

From: "Thomson, Martin" <[email-masked]>
To: Hannes Tschofenig <[email-masked]>
Date: Wed, 21 Jul 2010 08:55:57 +0800
Accept-Language: en-US
acceptlanguage: en-US
Cc: "Rosen, Brian" <[email-masked]>, "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [earlywarning] Review of draft-rosen-atoca-cap

From: "Thomson, Martin" <[email-masked]>
To: Hannes Tschofenig <[email-masked]>
Date: Wed, 21 Jul 2010 08:25:31 +0800
Accept-Language: en-US
acceptlanguage: en-US
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [earlywarning] Comments on draft-schulzrinne-atoca-requirements-00

From: "Thomson, Martin" <[email-masked]>
To: Hannes Tschofenig <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 21 Jul 2010 07:22:21 +0800
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>, "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>
Subject: Re: [earlywarning] Comments on	draft-schulzrinne-atoca-requirements-00

--_000_8B0A9FCBB9832F43971E38010638454F03EB77314ASISPE7MB1comm_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

--_000_8B0A9FCBB9832F43971E38010638454F03EB77314ASISPE7MB1comm_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

--_000_8B0A9FCBB9832F43971E38010638454F03EB77314ASISPE7MB1comm_--

From: "Thomson, Martin" <[email-masked]>
To: Hannes Tschofenig <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 21 Jul 2010 07:20:30 +0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [earlywarning] Regarding your comments about requirements

From: "Thomson, Martin" <[email-masked]>
To: Hannes Tschofenig <[email-masked]>
Date: Wed, 21 Jul 2010 06:40:09 +0800
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [earlywarning] comment on draft-rosen-atoca-server-discovery

From: Robert Sparks <[email-masked]>
Date: Tue, 20 Jul 2010 17:35:52 -0500
To: ken carlberg <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [earlywarning] WG Review: Authority to Citizen Alert (ATOCA)

Hi Ken -

Sorry if I introduced confusion - I indicated that the charter was approved for external review - the IETF as a whole
and any other bodies watching the new-work mailing list are asked to review and comment. The actual formation
of the group is still under consideration.

RjS

On Jul 20, 2010, at 5:25 PM, ken carlberg wrote:

> Hmmmm,  I thought that there were more concerns than that stated by Robert given the comment in the announcement stating "The IESG has not made any determination as yet", which seemed to run contrary to Robert's statement that "the ATOCA charter was approved".  
> 
> If I mis-read things, then I'll subscribe to those famous words of Rosana Rosana Dana....."never mind" :-)
> 
> cheers,
> 
> -ken
> 
> 
> On Jul 20, 2010, at 6:16 PM, Marc Linsner wrote:
> 
>> Ken,
>> 
>> Did you see Robert's email:
>> 
>> http://www.ietf.org/mail-archive/web/earlywarning/current/msg00323.html
>> 
>> -Marc-
>> 
>> 
>> On 7/20/10 5:56 PM, "ken carlberg" <[email-masked]> wrote:
>> 
>>> Hi,
>>> 
>>>> A new IETF working group has been proposed in the Real-time Applications
>>>> and Infrastructure Area.  The IESG has not made any determination as yet.
>>>> The following draft charter was submitted, and is provided for
>>>> informational purposes only. Please send your comments to the IESG mailing
>>>> list ([email-masked]) by Tuesday, July 27, 2010.
>>> 
>>> given the wording of the above, the proposed working group was at least
>>> discussed internally within the IESG.  Would it be possible to get a summary
>>> of the issues/concerns expressed by the IESG?  It would be helpful to have a
>>> perspective to focus comments from the masses, and avoid the generic and
>>> uninformative "I support this effort becoming a working group" statement
>>> 
>>> kindest regards,
>>> 
>>> -ken
>>> 
>>> _______________________________________________
>>> earlywarning mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/earlywarning
>> 
>> 
> 

Date: Tue, 20 Jul 2010 16:29:53 -0600
From: Peter Saint-Andre <[email-masked]>
To: [email-masked]
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Subject: Re: [earlywarning] WG Review: Authority to Citizen Alert (ATOCA)

The process is:

1. Internal IESG review

2. Send it out for external review

3. Final determination (based on external review)

We're at Step 2. :)

On 7/20/10 4:25 PM, ken carlberg wrote:
> Hmmmm,  I thought that there were more concerns than that stated by
> Robert given the comment in the announcement stating "The IESG has
> not made any determination as yet", which seemed to run contrary to
> Robert's statement that "the ATOCA charter was approved".
> 
> If I mis-read things, then I'll subscribe to those famous words of
> Rosana Rosana Dana....."never mind" :-)
> 
> cheers,
> 
> -ken
> 
> 
> On Jul 20, 2010, at 6:16 PM, Marc Linsner wrote:
> 
>> Ken,
>> 
>> Did you see Robert's email:
>> 
>> http://www.ietf.org/mail-archive/web/earlywarning/current/msg00323.html
>>
>>
>> 
-Marc-
>> 
>> 
>> On 7/20/10 5:56 PM, "ken carlberg" <[email-masked]> wrote:
>> 
>>> Hi,
>>> 
>>>> A new IETF working group has been proposed in the Real-time
>>>> Applications and Infrastructure Area.  The IESG has not made
>>>> any determination as yet. The following draft charter was
>>>> submitted, and is provided for informational purposes only.
>>>> Please send your comments to the IESG mailing list
>>>> ([email-masked]) by Tuesday, July 27, 2010.
>>> 
>>> given the wording of the above, the proposed working group was at
>>> least discussed internally within the IESG.  Would it be possible
>>> to get a summary of the issues/concerns expressed by the IESG?
>>> It would be helpful to have a perspective to focus comments from
>>> the masses, and avoid the generic and uninformative "I support
>>> this effort becoming a working group" statement
>>> 
>>> kindest regards,
>>> 
>>> -ken
>>> 
>>> _______________________________________________ earlywarning
>>> mailing list [email-masked] 
>>> https://www.ietf.org/mailman/listinfo/earlywarning
>> 

From: ken carlberg <[email-masked]>
Date: Tue, 20 Jul 2010 18:25:09 -0400
To: Marc Linsner <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [earlywarning] WG Review: Authority to Citizen Alert (ATOCA)

Hmmmm,  I thought that there were more concerns than that stated by Robert given the comment in the announcement stating "The IESG has not made any determination as yet", which seemed to run contrary to Robert's statement that "the ATOCA charter was approved".  

If I mis-read things, then I'll subscribe to those famous words of Rosana Rosana Dana....."never mind" :-)

cheers,

-ken

On Jul 20, 2010, at 6:16 PM, Marc Linsner wrote:

> Ken,
> 
> Did you see Robert's email:
> 
> http://www.ietf.org/mail-archive/web/earlywarning/current/msg00323.html
> 
> -Marc-
> 
> 
> On 7/20/10 5:56 PM, "ken carlberg" <[email-masked]> wrote:
> 
>> Hi,
>> 
>>> A new IETF working group has been proposed in the Real-time Applications
>>> and Infrastructure Area.  The IESG has not made any determination as yet.
>>> The following draft charter was submitted, and is provided for
>>> informational purposes only. Please send your comments to the IESG mailing
>>> list ([email-masked]) by Tuesday, July 27, 2010.
>> 
>> given the wording of the above, the proposed working group was at least
>> discussed internally within the IESG.  Would it be possible to get a summary
>> of the issues/concerns expressed by the IESG?  It would be helpful to have a
>> perspective to focus comments from the masses, and avoid the generic and
>> uninformative "I support this effort becoming a working group" statement
>> 
>> kindest regards,
>> 
>> -ken
>> 
>> _______________________________________________
>> earlywarning mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/earlywarning
> 
> 

Date: Tue, 20 Jul 2010 18:16:00 -0400
From: Marc Linsner <[email-masked]>
To: ken carlberg <[email-masked]>, <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] WG Review: Authority to Citizen Alert (ATOCA)

Ken,

Did you see Robert's email:

http://www.ietf.org/mail-archive/web/earlywarning/current/msg00323.html

-Marc-

On 7/20/10 5:56 PM, "ken carlberg" <[email-masked]> wrote:

> Hi,
> 
>> A new IETF working group has been proposed in the Real-time Applications
>> and Infrastructure Area.  The IESG has not made any determination as yet.
>> The following draft charter was submitted, and is provided for
>> informational purposes only. Please send your comments to the IESG mailing
>> list ([email-masked]) by Tuesday, July 27, 2010.
> 
> given the wording of the above, the proposed working group was at least
> discussed internally within the IESG.  Would it be possible to get a summary
> of the issues/concerns expressed by the IESG?  It would be helpful to have a
> perspective to focus comments from the masses, and avoid the generic and
> uninformative "I support this effort becoming a working group" statement
> 
> kindest regards,
> 
> -ken
> 
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

From: ken carlberg <[email-masked]>
Date: Tue, 20 Jul 2010 17:56:57 -0400
To: [email-masked]
Cc: [email-masked]
Subject: Re: [earlywarning] WG Review: Authority to Citizen Alert (ATOCA)

Hi,

> A new IETF working group has been proposed in the Real-time Applications
> and Infrastructure Area.  The IESG has not made any determination as yet.
> The following draft charter was submitted, and is provided for
> informational purposes only. Please send your comments to the IESG mailing
> list ([email-masked]) by Tuesday, July 27, 2010.                

given the wording of the above, the proposed working group was at least discussed internally within the IESG.  Would it be possible to get a summary of the issues/concerns expressed by the IESG?  It would be helpful to have a perspective to focus comments from the masses, and avoid the generic and uninformative "I support this effort becoming a working group" statement

kindest regards,

-ken

Date: Tue, 20 Jul 2010 22:38:18 +0200
From: "Hannes Tschofenig" <[email-masked]>
To: "Carl Reed" <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [earlywarning] Commentson	draft-schulzrinne-atoca-requirements-00

Good to hear that CAP 2.0 will include a GML profile. 
What location shapes are going to be supported? We ran into this issue in ECRIT. 

-------- Original-Nachricht --------
> Datum: Tue, 20 Jul 2010 14:33:05 -0600
> Von: "Carl Reed" <[email-masked]>
> An: "Hannes Tschofenig" <[email-masked]>, [email-masked]
> CC: "Tschofenig, Hannes \\(NSN - FI/Espoo\\)" <[email-masked]>, [email-masked]
> Betreff: Re: [earlywarning]	Commentson	draft-schulzrinne-atoca-requirements-00

> Correct -
> 
> CAP is a payload and is (theoretically) transport agnostic. FYI, CAP 2.0
> will incorporate a GML profile that will include the same geometry types
> (plus additional ones) as the LO GML Geoshape Application Schema.  The only
> issue is that the OASIS GML "where" profile will use GML 3.2.1 to be
> consistent with the ISO version of GML and the LO Geoshape schema uses GML 3.1.1.
> 
> Cheers
> 
> Carl
> an OASIS CAP contributor
>   ----- Original Message ----- 
>   From: Hannes Tschofenig 
>   To: [email-masked] 
>   Cc: [email-masked] ; Tschofenig,Hannes (NSN - FI/Espoo) 
>   Sent: Tuesday, July 20, 2010 12:33 PM
>   Subject: Re: [earlywarning] Commentson
> draft-schulzrinne-atoca-requirements-00
> 
> 
>   Hi Tony, 
> 
>   thanks for pointing to the CAP Implementer's workshop and in particular
> the "Draft Implementors Note on Harmonizing Certain Identifiers in CAP
> Implementations"
> http://www.wmo.int/pages/prog/www/ISS/Meetings/WIS-CAP_Geneva2009/DraftNote.doc. 
> 
>   My understanding of that document (and my participation at an earlier
> workshop) is there is room for improvement in the CAP specification from an
> interoperability point of view.
> 
>   Since the work in this group only focuses on the transport of alerts
> rather than the actual content of the alerts we should not be impacted. 
> 
>   Ciao
>   Hannes
> 
>   On 16.07.2010 13:05, Tony Rutkowski wrote: 
>      Hi Martin, 
> 
>     You might also consider the concepts on architecture 
>     and identity constructs that emerged from last year's 
>     global gathering of emergency messaging authorities 
>     convened at the World Meteorological Organization. 
>    
> http://www.wmo.int/pages/prog/www/ISS/Meetings/WIS-CAP_Geneva2009/DocPlan.html 
> 
>     See especially the Draft Implementors Note. 
> 
>     best, 
>     tony 
> 
> 
>       I'm currently unsure about the value of this document.  The
> different components of the document are somewhat disjointed: problem statement,
> architectural model, and requirements don't support each other particularly
> well. 
> 
>       General Comments: 
> 
>       This model presented in this document is highly abstract.  Without a
> more concrete relationship with the requirements, it's hard to understand
> the value of the model.  Section 3 looks too much like a copy-and-paste
> from the email architecture. 
> 
>       A simpler model might be a better starting point: 
>          author [1..*] ->  [1] aggregator [1] ->  [1..*] recipient 
> 
>       Such a model can be evolved to involve relays or mediators by
> overlapping and chaining roles, just as we do for the GEOPRIV model.  Nothing
> wrong with giving these entities names and descriptions, but they can form
> part of a second architectural layer. 
> 
> 
> 
>     _______________________________________________ 
>     earlywarning mailing list 
>     [email-masked] 
>     https://www.ietf.org/mailman/listinfo/earlywarning 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> 
> 
>   _______________________________________________
>   earlywarning mailing list
>   [email-masked]
>   https://www.ietf.org/mailman/listinfo/earlywarning

From: "Carl Reed" <[email-masked]>
To: "Hannes Tschofenig" <[email-masked]>, <[email-masked]>
Date: Tue, 20 Jul 2010 14:33:05 -0600
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, [email-masked]
Subject: Re: [earlywarning] Commentson	draft-schulzrinne-atoca-requirements-00

This is a multi-part message in MIME format.

------=_NextPart_000_014D_01CB2818.77673610
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Correct -

CAP is a payload and is (theoretically) transport agnostic. FYI, CAP 2.0 will incorporate a GML profile that will include the same geometry types (plus additional ones) as the LO GML Geoshape Application Schema.  The only issue is that the OASIS GML "where" profile will use GML 3.2.1 to be consistent with the ISO version of GML and the LO Geoshape schema uses GML 3.1.1.

Cheers

Carl
an OASIS CAP contributor
  ----- Original Message ----- 
  From: Hannes Tschofenig 
  To: [email-masked] 
  Cc: [email-masked] ; Tschofenig,Hannes (NSN - FI/Espoo) 
  Sent: Tuesday, July 20, 2010 12:33 PM
  Subject: Re: [earlywarning] Commentson draft-schulzrinne-atoca-requirements-00

  Hi Tony, 

  thanks for pointing to the CAP Implementer's workshop and in particular the "Draft Implementors Note on Harmonizing Certain Identifiers in CAP Implementations" http://www.wmo.int/pages/prog/www/ISS/Meetings/WIS-CAP_Geneva2009/DraftNote.doc. 

  My understanding of that document (and my participation at an earlier workshop) is there is room for improvement in the CAP specification from an interoperability point of view.

  Since the work in this group only focuses on the transport of alerts rather than the actual content of the alerts we should not be impacted. 

  Ciao
  Hannes

  On 16.07.2010 13:05, Tony Rutkowski wrote: 
     Hi Martin, 

    You might also consider the concepts on architecture 
    and identity constructs that emerged from last year's 
    global gathering of emergency messaging authorities 
    convened at the World Meteorological Organization. 
    http://www.wmo.int/pages/prog/www/ISS/Meetings/WIS-CAP_Geneva2009/DocPlan.html 

    See especially the Draft Implementors Note. 

    best, 
    tony 

      I'm currently unsure about the value of this document.  The different components of the document are somewhat disjointed: problem statement, architectural model, and requirements don't support each other particularly well. 

      General Comments: 

      This model presented in this document is highly abstract.  Without a more concrete relationship with the requirements, it's hard to understand the value of the model.  Section 3 looks too much like a copy-and-paste from the email architecture. 

      A simpler model might be a better starting point: 
         author [1..*] ->  [1] aggregator [1] ->  [1..*] recipient 

      Such a model can be evolved to involve relays or mediators by overlapping and chaining roles, just as we do for the GEOPRIV model.  Nothing wrong with giving these entities names and descriptions, but they can form part of a second architectural layer. 

    _______________________________________________ 
    earlywarning mailing list 
    [email-masked] 
    https://www.ietf.org/mailman/listinfo/earlywarning 

------------------------------------------------------------------------------

  _______________________________________________
  earlywarning mailing list
  [email-masked]
  https://www.ietf.org/mailman/listinfo/earlywarning

------=_NextPart_000_014D_01CB2818.77673610
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=Content-Type content="text/html; charset=ISO-8859-1">
<META content="MSHTML 6.00.6000.17037" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY text=#000000 bgColor=#ffffff>
<DIV>Correct -</DIV>
<DIV>&nbsp;</DIV>
<DIV>CAP is a payload and is (theoretically) transport agnostic. FYI, CAP 2.0 
will incorporate&nbsp;a GML profile that will include the same geometry types 
(plus additional ones) as the LO GML Geoshape Application Schema.&nbsp; The only 
issue is that the OASIS GML "where" profile will use GML 3.2.1 to be consistent 
with the ISO version of GML and the LO Geoshape schema uses GML 3.1.1.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Cheers</DIV>
<DIV><BR>Carl</DIV>
<DIV>an OASIS CAP contributor</DIV>
<BLOCKQUOTE 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV 
  style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B> 
  <A title=[email-masked] 
  href="mailto:[email-masked]">Hannes Tschofenig</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>To:</B> <A title=[email-masked] 
  href="mailto:[email-masked]">[email-masked]</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Cc:</B> <A title=[email-masked] 
  href="mailto:[email-masked]">[email-masked]</A> ; <A 
  title=[email-masked] 
  href="mailto:[email-masked]">Tschofenig,Hannes (NSN - FI/Espoo)</A> 
  </DIV>
  <DIV style="FONT: 10pt arial"><B>Sent:</B> Tuesday, July 20, 2010 12:33 
  PM</DIV>
  <DIV style="FONT: 10pt arial"><B>Subject:</B> Re: [earlywarning] Commentson 
  draft-schulzrinne-atoca-requirements-00</DIV>
  <DIV><BR></DIV>Hi Tony, <BR><BR>thanks for pointing to the CAP Implementer's 
  workshop and in particular the "Draft Implementors Note on Harmonizing Certain 
  Identifiers in CAP Implementations" <A class=moz-txt-link-freetext 
  href="http://www.wmo.int/pages/prog/www/ISS/Meetings/WIS-CAP_Geneva2009/DraftNote.doc">http://www.wmo.int/pages/prog/www/ISS/Meetings/WIS-CAP_Geneva2009/DraftNote.doc</A>. 
  <BR><BR>My understanding of that document (and my participation at an earlier 
  workshop) is there is room for improvement in the CAP specification from an 
  interoperability point of view.<BR><BR>Since the work in this group only 
  focuses on the transport of alerts rather than the actual content of the 
  alerts we should not be impacted. <BR><BR>Ciao<BR>Hannes<BR><BR><SPAN 
  lang=EN-GB style="FONT-SIZE: 14pt"></SPAN><SPAN 
  style="FONT-SIZE: 14pt"><O:P></O:P></SPAN>On 16.07.2010 13:05, Tony Rutkowski 
  wrote: 
  <BLOCKQUOTE cite=mid:[email-masked] type="cite">&nbsp;Hi 
    Martin, <BR><BR>You might also consider the concepts on architecture <BR>and 
    identity constructs that emerged from last year's <BR>global gathering of 
    emergency messaging authorities <BR>convened at the World Meteorological 
    Organization. <BR><A class=moz-txt-link-freetext 
    href="http://www.wmo.int/pages/prog/www/ISS/Meetings/WIS-CAP_Geneva2009/DocPlan.html">http://www.wmo.int/pages/prog/www/ISS/Meetings/WIS-CAP_Geneva2009/DocPlan.html</A> 
    <BR><BR>See especially the Draft Implementors Note. <BR><BR>best, <BR>tony 
    <BR><BR>
    <BLOCKQUOTE type="cite">I'm currently unsure about the value of this 
      document.&nbsp; The different components of the document are somewhat 
      disjointed: problem statement, architectural model, and requirements don't 
      support each other particularly well. <BR><BR>General Comments: 
      <BR><BR>This model presented in this document is highly abstract.&nbsp; 
      Without a more concrete relationship with the requirements, it's hard to 
      understand the value of the model.&nbsp; Section 3 looks too much like a 
      copy-and-paste from the email architecture. <BR><BR>A simpler model might 
      be a better starting point: <BR>&nbsp;&nbsp; author [1..*] -&gt;&nbsp; [1] 
      aggregator [1] -&gt;&nbsp; [1..*] recipient <BR><BR>Such a model can be 
      evolved to involve relays or mediators by overlapping and chaining roles, 
      just as we do for the GEOPRIV model.&nbsp; Nothing wrong with giving these 
      entities names and descriptions, but they can form part of a second 
      architectural layer. 
    <BR><BR></BLOCKQUOTE><BR>_______________________________________________ 
    <BR>earlywarning mailing list <BR><A class=moz-txt-link-abbreviated 
    href="mailto:[email-masked]">[email-masked]</A> <BR><A 
    class=moz-txt-link-freetext 
    href="https://www.ietf.org/mailman/listinfo/earlywarning">https://www.ietf.org/mailman/listinfo/earlywarning</A> 
    <BR></BLOCKQUOTE><BR>
  <P>
  <HR>

  <P></P>_______________________________________________<BR>earlywarning mailing 
  list<BR>[email-masked]<BR>https://www.ietf.org/mailman/listinfo/earlywarning<BR></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_014D_01CB2818.77673610--

Date: Tue, 20 Jul 2010 21:21:45 +0200
From: "Hannes Tschofenig" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [earlywarning] Comments on	draft-schulzrinne-atoca-requirements-00

Hi Tony, 

When I look at the available sites that offer CAP alerts then I see email alike identifiers (rather than OIDs). 

I wonder whether using OID was a deployment friendly choice. 

Anyway, someone will have to figure out how these OIDs in the CAP alerts relate to signatures protecting CAP alerts. 

Still, this has nothing to do with the transport since the identity in the cert, the content of the sender element of the CAP alert, and the identity in the SIP messages (From field) are less like to all match...

Ciao
Hannes

>   On 7/20/2010 2:33 PM, Hannes Tschofenig wrote:
> >
> > Since the work in this group only focuses on the transport 
> > of alerts rather than the actual content of the alerts we 
> > should not be impacted.
> 
> Dear Hannes,
> 
> Probably...except note that the conceptualization of
> the early warning OID namespace includes tagging for
> all objects, including messages as well as organization
> entities.  There is also an ongoing discussion about
> the desirability of binding the identifiers to EVcerts.
> So components of this work could affect transport
> layers/protocols.
> 
> --tony

Date: Tue, 20 Jul 2010 14:41:06 -0400
From: Tony Rutkowski <[email-masked]>
Organization: Netmagic Associates
To: Hannes Tschofenig <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>
Subject: Re: [earlywarning] Comments on	draft-schulzrinne-atoca-requirements-00
Reply-To: [email-masked]

  On 7/20/2010 2:33 PM, Hannes Tschofenig wrote:
>
> Since the work in this group only focuses on the transport 
> of alerts rather than the actual content of the alerts we 
> should not be impacted.

Dear Hannes,

Probably...except note that the conceptualization of
the early warning OID namespace includes tagging for
all objects, including messages as well as organization
entities.  There is also an ongoing discussion about
the desirability of binding the identifiers to EVcerts.
So components of this work could affect transport
layers/protocols.

--tony

Date: Tue, 20 Jul 2010 20:33:18 +0200
From: Hannes Tschofenig <[email-masked]>
To: [email-masked]
Cc: "[email-masked]" <[email-masked]>, "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>
Subject: Re: [earlywarning] Comments on	draft-schulzrinne-atoca-requirements-00

This is a multi-part message in MIME format.
--------------050703080507000605010309
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Tony,

thanks for pointing to the CAP Implementer's workshop and in particular 
the "Draft Implementors Note on Harmonizing Certain Identifiers in CAP 
Implementations" 
http://www.wmo.int/pages/prog/www/ISS/Meetings/WIS-CAP_Geneva2009/DraftNote.doc. 

My understanding of that document (and my participation at an earlier 
workshop) is there is room for improvement in the CAP specification from 
an interoperability point of view.

Since the work in this group only focuses on the transport of alerts 
rather than the actual content of the alerts we should not be impacted.

Ciao
Hannes

On 16.07.2010 13:05, Tony Rutkowski wrote:
>  Hi Martin,
>
> You might also consider the concepts on architecture
> and identity constructs that emerged from last year's
> global gathering of emergency messaging authorities
> convened at the World Meteorological Organization.
> http://www.wmo.int/pages/prog/www/ISS/Meetings/WIS-CAP_Geneva2009/DocPlan.html 
>
>
> See especially the Draft Implementors Note.
>
> best,
> tony
>
>> I'm currently unsure about the value of this document.  The different 
>> components of the document are somewhat disjointed: problem 
>> statement, architectural model, and requirements don't support each 
>> other particularly well.
>>
>> General Comments:
>>
>> This model presented in this document is highly abstract.  Without a 
>> more concrete relationship with the requirements, it's hard to 
>> understand the value of the model.  Section 3 looks too much like a 
>> copy-and-paste from the email architecture.
>>
>> A simpler model might be a better starting point:
>>    author [1..*] ->  [1] aggregator [1] ->  [1..*] recipient
>>
>> Such a model can be evolved to involve relays or mediators by 
>> overlapping and chaining roles, just as we do for the GEOPRIV model.  
>> Nothing wrong with giving these entities names and descriptions, but 
>> they can form part of a second architectural layer.
>>
>
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

--------------050703080507000605010309
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=ISO-8859-1"
 http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Tony, <br>
<br>
thanks for pointing to the CAP Implementer's workshop and in particular
the "Draft Implementors Note on Harmonizing Certain Identifiers in CAP
Implementations"
<a class="moz-txt-link-freetext" href="http://www.wmo.int/pages/prog/www/ISS/Meetings/WIS-CAP_Geneva2009/DraftNote.doc">http://www.wmo.int/pages/prog/www/ISS/Meetings/WIS-CAP_Geneva2009/DraftNote.doc</a>.
<br>
<br>
My understanding of that document (and my participation at an earlier
workshop) is there is room for improvement in the CAP specification
from an interoperability point of view.<br>
<br>
Since the work in this group only focuses on the transport of alerts
rather than the actual content of the alerts we should not be impacted.
<br>
<br>
Ciao<br>
Hannes<br>
<br>
<span style="font-size: 14pt;" lang="EN-GB"></span><span
 style="font-size: 14pt;"><o:p></o:p></span> On 16.07.2010 13:05, Tony
Rutkowski wrote:
<blockquote cite="mid:[email-masked]" type="cite">&nbsp;Hi
Martin,
  <br>
  <br>
You might also consider the concepts on architecture
  <br>
and identity constructs that emerged from last year's
  <br>
global gathering of emergency messaging authorities
  <br>
convened at the World Meteorological Organization.
  <br>
<a class="moz-txt-link-freetext" href="http://www.wmo.int/pages/prog/www/ISS/Meetings/WIS-CAP_Geneva2009/DocPlan.html">http://www.wmo.int/pages/prog/www/ISS/Meetings/WIS-CAP_Geneva2009/DocPlan.html</a>
  <br>
  <br>
See especially the Draft Implementors Note.
  <br>
  <br>
best,
  <br>
tony
  <br>
  <br>
  <blockquote type="cite">I'm currently unsure about the value of this
document.&nbsp; The different components of the document are somewhat
disjointed: problem statement, architectural model, and requirements
don't support each other particularly well.
    <br>
    <br>
General Comments:
    <br>
    <br>
This model presented in this document is highly abstract.&nbsp; Without a
more concrete relationship with the requirements, it's hard to
understand the value of the model.&nbsp; Section 3 looks too much like a
copy-and-paste from the email architecture.
    <br>
    <br>
A simpler model might be a better starting point:
    <br>
&nbsp;&nbsp; author [1..*] -&gt;&nbsp; [1] aggregator [1] -&gt;&nbsp; [1..*] recipient
    <br>
    <br>
Such a model can be evolved to involve relays or mediators by
overlapping and chaining roles, just as we do for the GEOPRIV model.&nbsp;
Nothing wrong with giving these entities names and descriptions, but
they can form part of a second architectural layer.
    <br>
    <br>
  </blockquote>
  <br>
_______________________________________________
  <br>
earlywarning mailing list
  <br>
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
  <br>
<a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/earlywarning">https://www.ietf.org/mailman/listinfo/earlywarning</a>
  <br>
</blockquote>
<br>
</body>
</html>

--------------050703080507000605010309--

From: IESG Secretary <[email-masked]>
To: [email-masked]
Date: Tue, 20 Jul 2010 10:00:01 -0700 (PDT)
Cc: [email-masked]
Subject: [earlywarning] WG Review: Authority to Citizen Alert (ATOCA)
Reply-To: [email-masked]

A new IETF working group has been proposed in the Real-time Applications
and Infrastructure Area.  The IESG has not made any determination as yet.
The following draft charter was submitted, and is provided for
informational purposes only. Please send your comments to the IESG mailing
list ([email-masked]) by Tuesday, July 27, 2010.                          

Authority to Citizen Alert (ATOCA)
----------------------------------
Current Status: Proposed Working Group

Last Modified: 2010-07-15

Chairs(s)
TBD

Real-time Applications and Infrastructure Area Directors:
   Gonzalo Camarillo <[email-masked]>
   Robert Sparks <[email-masked]>

Real-time Applications and Infrastructure Area Advisor:
   Robert Sparks <[email-masked]>

Mailing Lists:
  General Discussion: [email-masked]
  To Subscribe: <https://www.ietf.org/mailman/listinfo/earlywarning>
  Archive: <http://www.ietf.org/mail-archive/web/earlywarning>

Real-time Applications and Infrastructure Area Advisor:
   Robert Sparks <[email-masked]>

Description of Working Group:

There are a variety of mechanisms that authorities have available to
notify citizens and visitors during emergency events. Traditionally,
they have done so with broadcast networks (radio and television). For
commercial mobile devices, broadcasting services such as the Public
Warning System (PWS), the Earthquake and Tsunami Warning System
(ETWS), and the Commercial Mobile Alert System (CMAS) are
standardized and are in various stages of deployment.  The Internet
provides another way for authority-to-citizen alerts to be sent, but
it also presents new challenges. While there are some existing
layer 2 mechanisms for delivering alerts, the work in this group
focuses on delivering alerts to IP endpoints only.

The general message pattern that this group is intended to address is
the sending of alerts from a set of pre-authorized agents (e.g.,
governmental agencies) to a large population without impacting
layer 2 networks (e.g. causing congestion or denial of service).

The goal of this group is not to specify how originators of alerts
obtain authorization, but rather how an ATOCA system can verify
authorization and deliver messages to the intended recipients. A
critical element of the work are the mechanisms that assure that
only those pre-authorized agents can send alerts via ATOCA, through
an interface to authorized alert distribution networks
(e.g., iPAWS/DM-Open in the U.S.).

The ATOCA effort is differentiated from and is not intended to
replace other alerting mechanisms (e.g., PWS, CMAS, ETWS), as the
recipients of ATOCA alerts are the wide range of devices connected to
the Internet and various private IP networks, which humans may have
"at hand" to get such events, as well as automatons who may take
action based on the alerts. This implies that the content of the
alert contains some information, which is intended to be consumed
by humans, and some which is intended to be consumed by automatons.  

Ideally, the alerts would contain, or refer to media other than text
media (e.g., audio and/or video). The initial work in the group is
focused on small messages, which may be mechanically rendered by the
device in other forms (text to speech for example). Future work in
the group may investigate rich media.

In situations of a major emergency there could be scenarios
where there are multiple alerts generated that may require that a
priority mechanism (defined by alert originator policy) has to be
used. The work on a resource priority mechanism is out of scope of
the initial charter, but may be revisited at a later date.

Which devices should get alerts is primarily driven by location.  
The first set of recipients that must be catered for are those
within the area identified by the alert originator to be affected
by the emergency event.  In many jurisdictions, there are regulations
that define whether recipients/devices within the affected area have
opt-in or opt-out capability, but the protocols ATOCA will define
will include both opt-in and opt-out mechanisms. The group will
explore how to support both opt-in and opt-out at the level of
communication protocols and/or device behavior.

Another class of recipients that are in scope of the work are
explicit opt-in subscriptions which ask for alerts for a specified
location, not necessarily the physical location of the device itself.
An example of such a subscription would be 'send me alerts for
location x' (previously determined as the location of interest).
This work may build on existing IETF GEOPRIV location work.

There are efforts in other fora on early warning, which will be
considered in this effort.  For example, we expect to make use
of the OASIS Common Alerting Protocol (CAP) for the encoding of
alerts. OGC, ATIS, TIA, ITU-T, ETSI and 3GPP also have alert
efforts underway, and consultation with these efforts will be
undertaken to avoid unnecessary duplication of effort and also
to avoid unintentional negative impacts on the networks. Of course,
existing protocols for delivering messages (e.g., SIP, XMPP, or SMTP) 
will be the basis for the message delivery system of this working group.
Any service discovery mechanisms defined by the group are expected
to reuse existing discovery frameworks.

The security implications of mechanisms that can send alerts to
billions of devices are profound, but the utility of the mechanism
encourages us to face the problems and solve them. In addition, the
potential performance and congestion impacts to networks resulting
from sending alert information to billions of devices must be
considered and solved if such a service is implementable. To avoid
manual configuration of servers distributing alerts a discovery
mechanism will be specified.

NOTE FOR CHARTER REVIEW (this section to be removed before charter
approval): Some early drafts related to this proposed work are
* draft-norreys-ecrit-authority2individuals-requirements
* draft-rosen-ecrit-lost-early-warning
* draft-rosen-atoca-server-discovery
* draft-rosen-atoca-cap
* draft-schulzrinne-atoca-requirements

Goals and Milestones
		  
Jan 2011  Submit "Terminology and Framework" to the IESG for 
         publication as Informational 
		  
Apr 2011  Submit "Addressing security, performance and
         congestion issues for alert distribution" to the 
         IESG for publication as Informational 

Apr 2011 Submit conveying point-to-point Authority to Citizen Alerts
        to the IESG for publication as Proposed Standard

May 2011  Submit "Discovering alerting servers" to the IESG for 
         publication as Proposed Standard
		  
Jun 2011 Submit conveying point-to-multipoint Authority to Citizen 
        Alerts to the IESG for publication as Proposed Standard
		  
Aug 2011 Submit "Considerations for interworking with currently 
        deployed alert distribution systems" to the IESG for 
        publication as Informational

Date: Tue, 20 Jul 2010 15:57:49 +0200
From: Hannes Tschofenig <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [earlywarning] Regarding your comments about requirements

Hi Martin,

I copied your comments regarding the requirements into a separate mail:

Section 4:  Some of the requirements are a little hard to assess.  The model is quite abstract and the requirements are quite disjoint from it.  Try to be more specific, and so will I ;)

Req-G3:  This is too broad a requirement.  What security aspects are we concerned with?  It's possible that we are concerned with a large number of things: integrity, authentication of the source of a message, authorization of sources.

    Req-G3:

       The protocol solution MUST offer the typical communication
       security mechanisms.  Additional security mechanisms applied to
       the alert message itself are outside the scope of the
       communication protocol and therefore outside the scope of this
       document.

I agree with your statement about the security requirement. The security consideration section already covers the aspects you worry about.

Req-G5:  This is a difficult requirement for me to assess.  If the purpose of the system is to deliver messages, what does the author (?) gain by having the recipient (?) acknowledge receipt?

    Req-G5:

       The protocol solution MAY provide an option to return a receipt on
       reading message.

I don't recall where this requirement came from anymore. I would suggest to delete it and wait till somone screams.

For something that is required to scale in the fashion that we have imagined, forms of feedback might be vastly different from what we imagine from email return receipts.

[hannes] This requirement did not come from the email world.

  For instance, if an alert to evacuate a city is sent, the author doesn't want to hear from each of the million recipients that they got the message.  Some form of aggregated data is probably going to be most useful.  I'm not sure about the smaller scale, maybe a fully closed-loop feedback system is needed for some use cases.

Req-S2 and Req-S3: These don't indicate the direction that this information flows in: i.e., location flows from recipient to the subscription service.

    Req-S2:

       The protocol solution MUST allow an indication about the
       geographical area the potential Recipient is interested in.

    Req-S3:

       The protocol solution MUST allow an indication about the type of
       alert the potential Recipient is interested in.

The subscriber indicates this preference when it sends a subscribe message. You are right that this should be indicated.

Ciao
Hannes

From: Brian Rosen <[email-masked]>
Date: Tue, 20 Jul 2010 09:22:25 -0400
To: Hannes Tschofenig <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>
Subject: Re: [earlywarning] Comments on draft-schulzrinne-atoca-requirements-00

One note on return handlers.  The sender doesn't need an acknowledgement of receipt from each recipient.  The recipient however needs  very high reliability in getting the alert, which may involve some kind of handshake in some mechanisms.

Brian
On Jul 20, 2010, at 9:14 AM, Hannes Tschofenig wrote:

> Hi Martin,
> 
> a little bit of background on this document as well.
> 
> Initially the document started out as a requirements document (see http://tools.ietf.org/html/draft-norreys-ecrit-authority2individuals-requirements-00) and also looked quite a bit to the work done at other SDOs in that area. Other SDOs do, however, not really focus on the Internet landscape and hence the requirements were very specific to their access network technology, focused on user interface issues, the alert content, or were rather obvious.
> 
> We tried to restructure the requirements but it became clear that the absence of an architectural description makes it really difficult to produce anything meaningful.
> 
> Finally, the lack of uniform terminology was noticed.
> 
> Version -02 of the draft then had some architectural pieces in there:
> http://tools.ietf.org/html/draft-norreys-ecrit-authority2individuals-requirements-02
> 
> However, at that time we were still looking for terminology and we couldn't find anything useful. Then, the email architecture document was flying around and the terminology and architecture description seemed to be a good match. We were also able to abstract the problem space a bit. We then re-used the email terminology in version -03: http://tools.ietf.org/html/draft-norreys-ecrit-authority2individuals-requirements-03
> 
> Now, with the latest version the document focuses on the terminology, and the architectural description. It does not really  include a problem statement. The number of requirements are considerably smaller than in the -00 version but there are still too many of the obvious onces. There is at least the separation into the different models (subscription model vs. push communication).
> 
> I agree that the model is quite sophisticated but we are clearly building on top of an existing infrastructure and hence I believe it makes sense. Let's have a look at it:
> 
> 
>       ++==========++                        ++===========++
>       ||  Author  ||                        || Recipient ||
>       ++====++====++   +--------+           ++===========++
>             ||         | Return |                  /\
>             ||         +-+------+                  ||
>             \/           .    ^                    ||
>        +----------+      .    .                +---++----+
>        |          |      .    .                |         |
>      /-+----------+----------------------------+---------+---\
>      | |          |      .    .      MHS       |         |   |
>      | |Originator+<...........................+Receiver |   |
>      | |          |           ^                |         |   |
>      | +---++-----+           .                +---------+   |
>      |     ||                 .                    /\        |
>      |     ||  ...............+..................  ||        |
>      |     \/  .              .                 .  ||        |
>      | +-------+-+         +--+------+        +-+--++---+    |
>      | |  Relay  +======-=>|  Relay  +=======>|  Relay  |    |
>      | +---------+         +----++---+        +---------+    |
>      |                          ||                           |
>      |                          ||                           |
>      |                          \/                           |
>      |                     +---------+                       |
>      |                     | Gateway +-->...                 |
>      |                     +---------+                       |
>      \-------------------------------------------------------/
> 
> 
> I believe it is important to source and the sink from the rest. Here the Author and the Recipient are sources and sinks, respectively.
> In many cases the Author is a human who has to write alerts and prepare them for distribution.
> 
> Then, the actual message handling service consists of a few very reasonable entities, namely the originator, relay, gateway, and receiver.
> We have these entities in the SIP, and the XMPP context.
> 
> The only entity I was not quite sure about is the "return handler".
> 
> 
> I am not saying that there is no room for improving the description but I saw a lot of value in re-using an existing description than coming
> up with something entirely new.
> 
> 
> 
> A few more notes inline:
> 
> 
> 
> 
> On 16.07.2010 06:38, Thomson, Martin wrote:
>> I'm currently unsure about the value of this document.  The different components of the document are somewhat disjointed: problem statement, architectural model, and requirements don't support each other particularly well.
>> 
>> General Comments:
>> 
>> This model presented in this document is highly abstract.  Without a more concrete relationship with the requirements, it's hard to understand the value of the model.  Section 3 looks too much like a copy-and-paste from the email architecture.
>> 
>> A simpler model might be a better starting point:
>>   author [1..*] ->  [1] aggregator [1] ->  [1..*] recipient
>> 
>> Such a model can be evolved to involve relays or mediators by overlapping and chaining roles, just as we do for the GEOPRIV model.  Nothing wrong with giving these entities names and descriptions, but they can form part of a second architectural layer.
>> 
>> Specific Comments:
>> 
>> Section 1: Can we not simplify the three modes?
>> 
>>   1. Broadcast to devices based on their physical location.
>>   2. Broadcast to devices based on some defining characteristic (they might be a siren or ventilation control system, they might be owned by an emergency medicine practitioner or fireman, and so on).
>>   3. Broadcast to devices based on some criteria that has been arranged prior to the event (i.e., subscription).
>> 
>>   When characterized in this fashion, it's not obvious to me that the location case is special enough to warrant a separate category.  After all, I can imagine that warning criteria might be a union of two.  For example, deliver this alert to all emergency medicine practitioners in a this area.
>> 
>> On the topic of legacy devices, can we not abstract them out by having a conversion device act as a proxy for those.  Legacy interactions probably needs more analysis, separate to this preliminary section.  This includes legacy devices as well as existing warning systems, like cell broadcast.
>> 
>>   
> 
> Currently, we have the following models in the draft that try to classify the technological mechanisms being used:
> 
>   1.  Alerts may be addressed to all individuals within a certain
>       geographic area.  Today, this is often realized with the help of
>       dedicated functionality provided by link layer technology (e.g.,
>       multicast, broadcast).
> 
> 
> The work in other SDOs has focused on this topic. In fact many of the alerts are rather sent to a specific network topology (such as specific set of base stations) than with a specific location focus. The assumption obviously is that a specific BS covers a specific location.
> 
> 2.  Alerts need to be delivered to dedicated end points via unicast
>       messaging.
> 
> 
> This is still push communication but clearly different from #1. It is different from #3 since there is an implicit subscription.
> 
> 3. Subscription Model
> 
> 
> 
>> Section 3.1.3:  Is a return handler really a necessary part of the architecture?  Examining the sorts of feedback that the system is likely to generate might lead to an entirely different conclusion.
>>   
> 
> No, it is not necessary I believe.
> 
> 
> ~snip~
> 
> 
> Ciao
> Hannes
> 
>> _______________________________________________
>> earlywarning mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/earlywarning
>>   
> 
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

Date: Tue, 20 Jul 2010 15:14:27 +0200
From: Hannes Tschofenig <[email-masked]>
To: "Thomson, Martin" <[email-masked]>
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [earlywarning] Comments on draft-schulzrinne-atoca-requirements-00

Hi Martin,

a little bit of background on this document as well.

Initially the document started out as a requirements document (see 
http://tools.ietf.org/html/draft-norreys-ecrit-authority2individuals-requirements-00) 
and also looked quite a bit to the work done at other SDOs in that area. 
Other SDOs do, however, not really focus on the Internet landscape and 
hence the requirements were very specific to their access network 
technology, focused on user interface issues, the alert content, or were 
rather obvious.

We tried to restructure the requirements but it became clear that the 
absence of an architectural description makes it really difficult to 
produce anything meaningful.

Finally, the lack of uniform terminology was noticed.

Version -02 of the draft then had some architectural pieces in there:
http://tools.ietf.org/html/draft-norreys-ecrit-authority2individuals-requirements-02

However, at that time we were still looking for terminology and we 
couldn't find anything useful. Then, the email architecture document was 
flying around and the terminology and architecture description seemed to 
be a good match. We were also able to abstract the problem space a bit. 
We then re-used the email terminology in version -03: 
http://tools.ietf.org/html/draft-norreys-ecrit-authority2individuals-requirements-03

Now, with the latest version the document focuses on the terminology, 
and the architectural description. It does not really  include a problem 
statement. The number of requirements are considerably smaller than in 
the -00 version but there are still too many of the obvious onces. There 
is at least the separation into the different models (subscription model 
vs. push communication).

I agree that the model is quite sophisticated but we are clearly 
building on top of an existing infrastructure and hence I believe it 
makes sense. Let's have a look at it:

        ++=====++                        ++======++
        ||  Author  ||                        || Recipient ||
        ++==++==++   +--------+           ++======++
              ||         | Return |                  /\
              ||         +-+------+                  ||
              \/           .    ^                    ||
         +----------+      .    .                +---++----+
         |          |      .    .                |         |
       /-+----------+----------------------------+---------+---\
       | |          |      .    .      MHS       |         |   |
       | |Originator+<...........................+Receiver |   |
       | |          |           ^                |         |   |
       | +---++-----+           .                +---------+   |
       |     ||                 .                    /\        |
       |     ||  ...............+..................  ||        |
       |     \/  .              .                 .  ||        |
       | +-------+-+         +--+------+        +-+--++---+    |
       | |  Relay  +===-=>|  Relay  +====>|  Relay  |    |
       | +---------+         +----++---+        +---------+    |
       |                          ||                           |
       |                          ||                           |
       |                          \/                           |
       |                     +---------+                       |
       |                     | Gateway +-->...                 |
       |                     +---------+                       |
       \-------------------------------------------------------/

I believe it is important to source and the sink from the rest. Here the Author and the Recipient are sources and sinks, respectively.
In many cases the Author is a human who has to write alerts and prepare them for distribution.

Then, the actual message handling service consists of a few very reasonable entities, namely the originator, relay, gateway, and receiver.
We have these entities in the SIP, and the XMPP context.

The only entity I was not quite sure about is the "return handler".

I am not saying that there is no room for improving the description but I saw a lot of value in re-using an existing description than coming
up with something entirely new.

A few more notes inline:

On 16.07.2010 06:38, Thomson, Martin wrote:
> I'm currently unsure about the value of this document.  The different components of the document are somewhat disjointed: problem statement, architectural model, and requirements don't support each other particularly well.
>
> General Comments:
>
> This model presented in this document is highly abstract.  Without a more concrete relationship with the requirements, it's hard to understand the value of the model.  Section 3 looks too much like a copy-and-paste from the email architecture.
>
> A simpler model might be a better starting point:
>    author [1..*] ->  [1] aggregator [1] ->  [1..*] recipient
>
> Such a model can be evolved to involve relays or mediators by overlapping and chaining roles, just as we do for the GEOPRIV model.  Nothing wrong with giving these entities names and descriptions, but they can form part of a second architectural layer.
>
> Specific Comments:
>
> Section 1: Can we not simplify the three modes?
>
>    1. Broadcast to devices based on their physical location.
>    2. Broadcast to devices based on some defining characteristic (they might be a siren or ventilation control system, they might be owned by an emergency medicine practitioner or fireman, and so on).
>    3. Broadcast to devices based on some criteria that has been arranged prior to the event (i.e., subscription).
>
>    
> When characterized in this fashion, it's not obvious to me that the location case is special enough to warrant a separate category.  After all, I can imagine that warning criteria might be a union of two.  For example, deliver this alert to all emergency medicine practitioners in a this area.
>
> On the topic of legacy devices, can we not abstract them out by having a conversion device act as a proxy for those.  Legacy interactions probably needs more analysis, separate to this preliminary section.  This includes legacy devices as well as existing warning systems, like cell broadcast.
>
>    

Currently, we have the following models in the draft that try to 
classify the technological mechanisms being used:

    1.  Alerts may be addressed to all individuals within a certain
        geographic area.  Today, this is often realized with the help of
        dedicated functionality provided by link layer technology (e.g.,
        multicast, broadcast).

The work in other SDOs has focused on this topic. In fact many of the 
alerts are rather sent to a specific network topology (such as specific 
set of base stations) than with a specific location focus. The 
assumption obviously is that a specific BS covers a specific location.

2.  Alerts need to be delivered to dedicated end points via unicast
        messaging.

This is still push communication but clearly different from #1. It is 
different from #3 since there is an implicit subscription.

3. Subscription Model

> Section 3.1.3:  Is a return handler really a necessary part of the architecture?  Examining the sorts of feedback that the system is likely to generate might lead to an entirely different conclusion.
>    

No, it is not necessary I believe.

~snip~

Ciao
Hannes

> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning
>    

Date: Tue, 20 Jul 2010 14:22:37 +0200
From: Hannes Tschofenig <[email-masked]>
To: "Thomson, Martin" <[email-masked]>
Cc: "Rosen, Brian" <[email-masked]>, "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [earlywarning] Review of draft-rosen-atoca-cap

Hi Martin,

this is a fairly extensive review. Let me try to provide a bit of 
background.

The first challenge we ran into was the lack of a definition of alerts. 
We tried to put a list of alert types in 
http://tools.ietf.org/html/draft-rosen-atoca-server-discovery-00 (see 
Section 6.1) but faced a lot of resistance on the mailing list (see 
http://www.ietf.org/mail-archive/web/earlywarning/current/msg00130.html).

Before this aspect is addressed it is a bit difficult to say whether 
filters, service URNs, resource lists, etc. are the right approach.

The current version of the document hints to the need to provide some 
additional information in the body of the SUBSCRIBE to specify the type 
of alert in more detail but the proposal clearly is a placeholder.  
Nevertheless, I like the idea of using filters even though I was already 
wondering with the location-filter work in GEOPRIV whether there is a 
more elegant and more sophistcated way to deal with it.

As you noticed there are some aspects not well enough described, such as 
the operational aspects. Forking is a copy-and-paste error from the 
event package this document was created from.

On the security aspects: There are really only 2 types of trust models, 
namely end-to-end and hop-by-hop (with transitive trust). I would hope 
for an end-to-end model knowing that it will not be provided in almost 
all deployment environments. When I look at the way how alerts are 
distributed today then I doubt that even a hop-by-hop model with 
cryptographic protection is super realistic to assume either.

The described threats focus a lot on the distribution rather the 
publication. I believe we can probably re-use text from the email world 
regarding the threats. Will search for it.

Ciao
Hannes

On 14.07.2010 08:40, Thomson, Martin wrote:
> This is my first read of a SIP-CAP document in any detail.  On the whole, the draft is well-written and structured, but it needs a lot of work.
>
> There's plenty of meat in here for a working group effort.
>
> Comments:
>
> Why does this proposal not use RFC 4660 and RFC 4661?  The<warning-registration>  looks very much like a trigger extension.  The<service>  looks much like a what extension, or...
>
> Why does this proposal not use resource lists (RFC 4662)?  Each service could be considered as a different target.  (Drawback: creation of a resource list is not specified in RFC 4662).  (Drawback: complexity.)
>
> How do you propose to address the problem of multiple alerts?  Based on the mechanism that you propose, it is possible for multiple alerts to be active.  The alert element at the root of a CAP message contains information for a single event.  Are these to be combined with multipart MIME (multipart/mixed?).
>
> Why not allow forking for this package?  It seems that this event package is particularly well suited to forking.  It's also evident that merging of state is trivial for this sort of data.  Given that a single SUBSCRIBE might include multiple services and locations, it seems equally logical to allow multiple sources to provide alerts, with the initial target serving an aggregation function.
>
> The PUBLISH mechanism needs further thought - depending on what the architecture looks like.  As I understand, it's possible that there are multiple EPAs for a given ESC.  The one logical resource (SIP entity) might collate state for many different services (or not, see above).  A PUBLISH to this resource should not require that the EPA provide complete state - instead, a PUBLISH containing a single CAP document should suffice.  The behaviour of the ESC should be to add the CAP document to the set of alerts that it maintains.
>
> There is zero discussion of the operational impacts.  It seems that there is a need to understand the implications of creating an alert - how many people it might be forwarded to, etc...
>
> The security section needs a lot of work.
>
> Identify the threat model: from what I read, this basically reduces to forgery of alerts.  A discussion on how a single PUBLISH request turns into potentially millions of NOTIFY requests would have seemed appropriate.
>
> Replay attacks reduce to forgery due to the time and serial number parameters in the alerts.
>
> It seems that there are two mechanisms proposed for countering forgery: using digital signatures or channel security (TLS).  The first goes all the way back to the source; the second looks at the last hop and relies on a transitive chain of trust.
>
> The structure of the section is such that these messages are obfuscated with a lot of noise.  The MITM attack is especially poorly defined.  Most of the countermeasures are useless.  The signature mechanism smells of hope, but fails to identify any practical solution.
>
> I'd also like to provide some comments on CAP.  With a few minor tweaks, it could fit a lot better with existing IETF work.
>
> Nits:
>
> Section 1: The idea considerations section seems obvious when you know RFC 3903 well, but it's actually pretty confusing if you don’t.
>
>    "... any event
>     package intended to be used in conjunction with the SIP PUBLISH
>     method has to include a considerations section."
>
> My first reaction was: considerations about what?  This could be clarified, but what I'd prefer is that you simply provided the requested content.  No need to explain that you do this because RFC 3903 told you to.
>
> The same sort of (unnecessary) appeal to authority is used extensively.  A lot of text could be safely cut.
>
> Section 3.5: The default for the header should also include a charset=utf-8 parameter, as recommended by RFC 3023.
>
> Section 3.6:  This statement seems out of place.  There needs to be more rigorous discussion of architecture than this:
>
>     Notifiers will typically act as Event State Compositors (ESC) and
>     thus will learn the 'common-alerting-protocol' event state via
>     PUBLISH requests sent from authorized [EPAs].
>
> The word "typically" is a problem here.  Why not just say that the ESC and Notifier roles are the same.  A Notifier might also be an EPA, or they might accept PUBLISH requests from authorized EPAs.
>
> Section 3.7:  This seems like a copy-paste type error:
>
>     In the case of a pending subscription, when final authorization is
>     determined, a NOTIFY can be sent.  If the result of the authorization
>     decision was success, a NOTIFY SHOULD be sent and SHOULD contain a
>     complete CAP document.
>
> As the draft describes, it's unlikely that there will be state at the time that the subscription is created.  This statement should also reflect that.
>
> Section 3.11:  RFC 3265 requests more detail than what is provided, especially since state agents are being permitted.
>
> Section 3.13: CAP documents can be large - if they contain a<derefUri>  element.  Should this be prohibited or recommended against?
>
> Section 3.14: Should the PUBLISH "considerations" be split into their own section separate to the SUB/NOT stuff?
>
> Section 3.15: This section doesn't make sense: what does the PUBLISH response contain?  An empty body seems like a reasonable option.
>
> The example in Section 4 shows a CAP document, not a complete example SUBSCRIBE/PUBLISH/NOTIFY.
>
> Section 6.3: This would be clearer if the services were described as complete URNs, e.g. urn:service:warning.cbrne (btw, that's a painful acronym to remember).
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning
>    

Date: Tue, 20 Jul 2010 14:04:36 +0200
From: Hannes Tschofenig <[email-masked]>
To: "Thomson, Martin" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [earlywarning] comment on draft-rosen-atoca-server-discovery

Hi Martin,

please expand a bit on what you meant with the GeoRSS comment.

The reason for having GeoRSS mentioned in there is that GeoRSS is quite 
widely used for distributing alerts and there will always be different 
ways to distribute alerts.

Are you suggesting not to use GeoRSS?

Ciao
Hannes

On 15.07.2010 05:18, Thomson, Martin wrote:
> I like this.  It's simple enough that it could just work.
>
> GeoRSS seems like a doubling up.  You can already stuff a CAP alert into Atom.  That should suffice, since the CAP alert already contains information on location.
>
> Even using Atom leads to a double up on a number of parameters, like the originator (author) of the alert.  Both Atom and CAP provide fields for this.
>
> Care will be needed (specification) to ensure that this doesn't lead to un-interoperable implementations.
>
> The draft doesn't identify what aspects of the LoST extensions are useful.  I couldn't work it out either.  As far as I can tell, the extensions will at best be marginally useful.  Either way, this needs expansion.
>
> --Martin
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning
>    

Date: Fri, 16 Jul 2010 07:05:34 -0400
From: Tony Rutkowski <[email-masked]>
Organization: Netmagic Associates
To: "Thomson, Martin" <[email-masked]>
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [earlywarning] Comments on draft-schulzrinne-atoca-requirements-00
Reply-To: [email-masked]

  Hi Martin,

You might also consider the concepts on architecture
and identity constructs that emerged from last year's
global gathering of emergency messaging authorities
convened at the World Meteorological Organization.
http://www.wmo.int/pages/prog/www/ISS/Meetings/WIS-CAP_Geneva2009/DocPlan.html

See especially the Draft Implementors Note.

best,
tony

> I'm currently unsure about the value of this document.  The different components of the document are somewhat disjointed: problem statement, architectural model, and requirements don't support each other particularly well.
>
> General Comments:
>
> This model presented in this document is highly abstract.  Without a more concrete relationship with the requirements, it's hard to understand the value of the model.  Section 3 looks too much like a copy-and-paste from the email architecture.
>
> A simpler model might be a better starting point:
>    author [1..*] ->  [1] aggregator [1] ->  [1..*] recipient
>
> Such a model can be evolved to involve relays or mediators by overlapping and chaining roles, just as we do for the GEOPRIV model.  Nothing wrong with giving these entities names and descriptions, but they can form part of a second architectural layer.
>

From: "Thomson, Martin" <[email-masked]>
To: "[email-masked]" <[email-masked]>, Henning Schulzrinne <[email-masked]>, "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 16 Jul 2010 12:38:22 +0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: [earlywarning] Comments on draft-schulzrinne-atoca-requirements-00

From: Robert Sparks <[email-masked]>
Date: Thu, 15 Jul 2010 14:59:34 -0500
To: [email-masked]
Subject: [earlywarning] ATOCA proposed charter should appear for external review soon

On today's IESG call, the ATOCA charter was approved (with a few edits) for external review.
Watch ietf-announce for an announcement of the review.

The edits to the charter text were minor - the IESG requested clarification that the group was
not being restricted to only producing solutions using the SIP protocol and that it was not the
intent to create a new discovery protocol from scratch.

The milestones got a stronger touch - it was not clear how the point-to-multipoint milestone
related to the previous milestones and the IESG requested clarification on the scope of the
"interfacing existing alert distribution systems" milestone.

Below is what should appear for external review. Please comment on the external review thread
when it appears.

Thanks,

RjS

---------------------------------------------------------

Authority to Citizen Alert (ATOCA)
----------------------------------
Current Status: Proposed Working Group

Last Modified: 2010-07-15

Chairs(s)
TBD

Real-time Applications and Infrastructure Area Directors:
    Gonzalo Camarillo <[email-masked]>
    Robert Sparks <[email-masked]>

Real-time Applications and Infrastructure Area Advisor:
    Robert Sparks <[email-masked]>

Mailing Lists:
   General Discussion: [email-masked]
   To Subscribe: <https://www.ietf.org/mailman/listinfo/earlywarning>
   Archive: <http://www.ietf.org/mail-archive/web/earlywarning>

Real-time Applications and Infrastructure Area Advisor:
    Robert Sparks <[email-masked]>

Description of Working Group:

There are a variety of mechanisms that authorities have available to
notify citizens and visitors during emergency events. Traditionally,
they have done so with broadcast networks (radio and television). For
commercial mobile devices, broadcasting services such as the Public
Warning System (PWS), the Earthquake and Tsunami Warning System
(ETWS), and the Commercial Mobile Alert System (CMAS) are
standardized and are in various stages of deployment.  The Internet
provides another way for authority-to-citizen alerts to be sent, but
it also presents new challenges. While there are some existing
layer 2 mechanisms for delivering alerts, the work in this group
focuses on delivering alerts to IP endpoints only.

The general message pattern that this group is intended to address is
the sending of alerts from a set of pre-authorized agents (e.g.,
governmental agencies) to a large population without impacting
layer 2 networks (e.g. causing congestion or denial of service).
 
The goal of this group is not to specify how originators of alerts
obtain authorization, but rather how an ATOCA system can verify
authorization and deliver messages to the intended recipients. A
critical element of the work are the mechanisms that assure that
only those pre-authorized agents can send alerts via ATOCA, through
an interface to authorized alert distribution networks
(e.g., iPAWS/DM-Open in the U.S.).

The ATOCA effort is differentiated from and is not intended to
replace other alerting mechanisms (e.g., PWS, CMAS, ETWS), as the
recipients of ATOCA alerts are the wide range of devices connected to
the Internet and various private IP networks, which humans may have
"at hand" to get such events, as well as automatons who may take
action based on the alerts. This implies that the content of the
alert contains some information, which is intended to be consumed
by humans, and some which is intended to be consumed by automatons.  

Ideally, the alerts would contain, or refer to media other than text
media (e.g., audio and/or video). The initial work in the group is
focused on small messages, which may be mechanically rendered by the
device in other forms (text to speech for example). Future work in
the group may investigate rich media.

In situations of a major emergency there could be scenarios
where there are multiple alerts generated that may require that a
priority mechanism (defined by alert originator policy) has to be
used. The work on a resource priority mechanism is out of scope of
the initial charter, but may be revisited at a later date.

Which devices should get alerts is primarily driven by location.  
The first set of recipients that must be catered for are those
within the area identified by the alert originator to be affected
by the emergency event.  In many jurisdictions, there are regulations
that define whether recipients/devices within the affected area have
opt-in or opt-out capability, but the protocols ATOCA will define
will include both opt-in and opt-out mechanisms. The group will
explore how to support both opt-in and opt-out at the level of
communication protocols and/or device behavior.

Another class of recipients that are in scope of the work are
explicit opt-in subscriptions which ask for alerts for a specified
location, not necessarily the physical location of the device itself.
An example of such a subscription would be 'send me alerts for
location x' (previously determined as the location of interest).
This work may build on existing IETF GEOPRIV location work.

There are efforts in other fora on early warning, which will be
considered in this effort.  For example, we expect to make use
of the OASIS Common Alerting Protocol (CAP) for the encoding of
alerts. OGC, ATIS, TIA, ITU-T, ETSI and 3GPP also have alert
efforts underway, and consultation with these efforts will be
undertaken to avoid unnecessary duplication of effort and also
to avoid unintentional negative impacts on the networks. Of course,
existing protocols for delivering messages (e.g., SIP, XMPP, or SMTP) 
will be the basis for the message delivery system of this working group.
Any service discovery mechanisms defined by the group are expected
to reuse existing discovery frameworks.

The security implications of mechanisms that can send alerts to
billions of devices are profound, but the utility of the mechanism
encourages us to face the problems and solve them. In addition, the
potential performance and congestion impacts to networks resulting
from sending alert information to billions of devices must be
considered and solved if such a service is implementable. To avoid
manual configuration of servers distributing alerts a discovery
mechanism will be specified.

NOTE FOR CHARTER REVIEW (this section to be removed before charter
approval): Some early drafts related to this proposed work are
 * draft-norreys-ecrit-authority2individuals-requirements
 * draft-rosen-ecrit-lost-early-warning
 * draft-rosen-atoca-server-discovery
 * draft-rosen-atoca-cap
 * draft-schulzrinne-atoca-requirements

Goals and Milestones
		  
Jan 2011  Submit "Terminology and Framework" to the IESG for 
          publication as Informational 
		  
Apr 2011  Submit "Addressing security, performance and
          congestion issues for alert distribution" to the 
          IESG for publication as Informational 

Apr 2011 Submit conveying point-to-point Authority to Citizen Alerts
         to the IESG for publication as Proposed Standard

May 2011  Submit "Discovering alerting servers" to the IESG for 
          publication as Proposed Standard
		  
Jun 2011 Submit conveying point-to-multipoint Authority to Citizen Alerts
         to the IESG for publication as Proposed Standard
		  
Aug 2011 Submit "Considerations for interworking with currently 
         deployed alert distribution systems" to the IESG for 
         publication as Informational

From: "Thomson, Martin" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 15 Jul 2010 11:18:39 +0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: [earlywarning] comment on draft-rosen-atoca-server-discovery

From: "Thomson, Martin" <[email-masked]>
To: "[email-masked]" <[email-masked]>, "Rosen, Brian" <[email-masked]>, "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>, Henning Schulzrinne <[email-masked]>
Date: Wed, 14 Jul 2010 14:40:23 +0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: [earlywarning] Review of draft-rosen-atoca-cap

From: "Richard L. Barnes" <[email-masked]>
To: James M. Polk <[email-masked]>
Date: Thu, 1 Jul 2010 22:49:51 -0400
Cc: Robert Sparks <[email-masked]>, [email-masked]
Subject: Re: [earlywarning] status?

Even if we can't be on the agenda, I'd be glad to have an ad-hoc  
meeting, especially if we have some drafts!

On Jul 1, 2010, at 5:08 PM, James M. Polk wrote:

> Robert
>
> Thanks for putting in the effort on this, and updating us. That  
> said, is there any way this pre-WG can meet in Maastricht, or do we  
> have to wait until Beijing?
>
> James
>
> At 01:50 PM 7/1/2010, Robert Sparks wrote:
>
>> I don't believe we need another BoF and am working on getting the  
>> working group chartered.
>> I am taking this to the IESG. Unless I encounter something  
>> unexpected, it will go out for external review before Maastricht.
>>
>> RjS
>>
>> On Jul 1, 2010, at 12:06 PM, Richard L. Barnes wrote:
>>
>>> I think the charter has been submitted to the IESG, and is waiting  
>>> on action from the ADs.
>>>
>>>
>>> On Jul 1, 2010, at 1:05 PM, ken carlberg wrote:
>>>
>>>> Hi,
>>>>
>>>> given the latest charter that was circulated around, does anyone  
>>>> know if there was an attempt for another BoF, or to establish a  
>>>> WG for this effort?
>>>>
>>>> -ken
>>>>
>>>> _______________________________________________
>>>> earlywarning mailing list
>>>> <mailto:[email-masked]>[email-masked]
>>>> https://www.ietf.org/mailman/listinfo/earlywarning
>>
>> _______________________________________________
>> earlywarning mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/earlywarning
>
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

Date: Thu, 01 Jul 2010 16:08:56 -0500
To: Robert Sparks <[email-masked]>, [email-masked]
From: "James M. Polk" <[email-masked]>
Subject: Re: [earlywarning] status?

Robert

Thanks for putting in the effort on this, and updating us. That said, 
is there any way this pre-WG can meet in Maastricht, or do we have to 
wait until Beijing?

James

At 01:50 PM 7/1/2010, Robert Sparks wrote:

>I don't believe we need another BoF and am working on getting the 
>working group chartered.
>I am taking this to the IESG. Unless I encounter something 
>unexpected, it will go out for external review before Maastricht.
>
>RjS
>
>On Jul 1, 2010, at 12:06 PM, Richard L. Barnes wrote:
>
>>I think the charter has been submitted to the IESG, and is waiting 
>>on action from the ADs.
>>
>>
>>On Jul 1, 2010, at 1:05 PM, ken carlberg wrote:
>>
>>>Hi,
>>>
>>>given the latest charter that was circulated around, does anyone 
>>>know if there was an attempt for another BoF, or to establish a WG 
>>>for this effort?
>>>
>>>-ken
>>>
>>>_______________________________________________
>>>earlywarning mailing list
>>><mailto:[email-masked]>[email-masked]
>>>https://www.ietf.org/mailman/listinfo/earlywarning
>
>_______________________________________________
>earlywarning mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/earlywarning

From: Robert Sparks <[email-masked]>
Date: Thu, 1 Jul 2010 13:50:45 -0500
To: [email-masked]
Subject: Re: [earlywarning] status?

--Apple-Mail-16--944664648
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I don't believe we need another BoF and am working on getting the working group chartered.
I am taking this to the IESG. Unless I encounter something unexpected, it will go out for external review before Maastricht.

RjS

On Jul 1, 2010, at 12:06 PM, Richard L. Barnes wrote:

> I think the charter has been submitted to the IESG, and is waiting on action from the ADs.
> 
> 
> On Jul 1, 2010, at 1:05 PM, ken carlberg wrote:
> 
>> Hi,
>> 
>> given the latest charter that was circulated around, does anyone know if there was an attempt for another BoF, or to establish a WG for this effort?
>> 
>> -ken
>> 
>> _______________________________________________
>> earlywarning mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/earlywarning

--Apple-Mail-16--944664648
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br class="Apple-interchange-newline"><blockquote type="cite"></blockquote>I don't believe we need another BoF and am working on getting the working group chartered.<br><blockquote type="cite"></blockquote>I am taking this to the IESG. Unless I encounter something unexpected, it will go out for external review before Maastricht.<br><blockquote type="cite"></blockquote><font class="Apple-style-span" color="#144FAE"><br></font><blockquote type="cite"></blockquote>RjS<br><blockquote type="cite"></blockquote><font class="Apple-style-span" color="#144FAE"><br></font><blockquote type="cite"></blockquote>On Jul 1, 2010, at 12:06 PM, Richard L. Barnes wrote:<br><blockquote type="cite"></blockquote><font class="Apple-style-span" color="#144FAE"><br></font><blockquote type="cite"><div>I think the charter has been submitted to the IESG, and is waiting on action from the ADs.<br><br><br>On Jul 1, 2010, at 1:05 PM, ken carlberg wrote:<br><br><blockquote type="cite">Hi,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">given the latest charter that was circulated around, does anyone know if there was an attempt for another BoF, or to establish a WG for this effort?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">-ken<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">earlywarning mailing list<br></blockquote><blockquote type="cite"><a href="mailto:[email-masked]">[email-masked]</a><br></blockquote><blockquote type="cite"><a href="https://www.ietf.org/mailman/listinfo/earlywarning">https://www.ietf.org/mailman/listinfo/earlywarning</a><br></blockquote></div></blockquote></div><br></body></html>
--Apple-Mail-16--944664648--

From: Robert Sparks <[email-masked]>
Date: Thu, 1 Jul 2010 12:18:46 -0500
To: "Richard L. Barnes" <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] status?

I don't believe we need another BoF and am working on getting the working group chartered.
I am taking this to the IESG. Unless I encounter something unexpected, it will go out for external review before Maastricht.

RjS

On Jul 1, 2010, at 12:06 PM, Richard L. Barnes wrote:

> I think the charter has been submitted to the IESG, and is waiting on action from the ADs.
> 
> 
> On Jul 1, 2010, at 1:05 PM, ken carlberg wrote:
> 
>> Hi,
>> 
>> given the latest charter that was circulated around, does anyone know if there was an attempt for another BoF, or to establish a WG for this effort?
>> 
>> -ken
>> 
>> _______________________________________________
>> earlywarning mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/earlywarning
> 
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

From: "Richard L. Barnes" <[email-masked]>
To: ken carlberg <[email-masked]>
Date: Thu, 1 Jul 2010 13:06:40 -0400
Cc: [email-masked]
Subject: Re: [earlywarning] status?

I think the charter has been submitted to the IESG, and is waiting on  
action from the ADs.

On Jul 1, 2010, at 1:05 PM, ken carlberg wrote:

> Hi,
>
> given the latest charter that was circulated around, does anyone  
> know if there was an attempt for another BoF, or to establish a WG  
> for this effort?
>
> -ken
>
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

From: ken carlberg <[email-masked]>
Date: Thu, 1 Jul 2010 13:05:56 -0400
To: [email-masked]
Subject: [earlywarning] status?

Hi,

given the latest charter that was circulated around, does anyone know if there was an attempt for another BoF, or to establish a WG for this effort?

-ken