Subject: [earlywarning] Some further scoping issues

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 2 May 2009 12:49:54 +0300

For the future work in this group I furthermore suggest that 

* we do not focus our efforts on defining an architecture used for
distributing of alert messages (like we did it in ECRIT with the
PhoneBCP/Framework document). Instead, we develop building blocks (like
conveying CAP in SIP). I believe we will run into lots of problems with the
different usages, different solutions that have been specified elsewhere
already, etc. 

* we do not pick a single alert document format (as a
mandatory-to-implement), like CAP or GeoRSS, but instead give those who
deploy these mechanisms freedom. 

* we do not define our own alert document format (because there are other
formats available already). 

We can always decide later to document ways how people use our stuff. 

Ciao
Hannes

---

From: Tony Rutkowski <[email-masked]>
Date: Sat, 02 May 2009 08:08:39 -0400

These seem like good admonitions.  The broader scope will provide
greater value to work, rather than attempting to deal a specific kind
of implementation that gets into an already well-established regulatory
domain.

For those of you unfamiliar with the new FCC Part 10 rules specifying
Commercial Mobile Alert System (CMAS) implementations, they are available at
http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfr&rgn=div5&view=text&node=47:1.0.1.1.10&idno=47
For U.S. implementations, note that 47 CFR Sec. 10.410 requires that
"Presidential
Alerts preempt all other Alert Messages."

ciao,
--tony

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 04 May 2009 13:00:19 -0500

>Alerts preempt all other Alert Messages."

Again, Tony, can you explain to many of us (if not to all of us) why 
a *message* needs to preempt (i.e., delete) another *message*, and 
not merely delay the non-presidential *message* until the 
presidential message is sent (i.e., hold in memory until there is no 
message of higher priority)?

I'm thinking we're talking past each other.

James

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

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 9 May 2009 12:29:11 +0300

Hi all, 

I did not receive a lot of feedback on the important aspect of scoping the
work in this upcoming group. 

Please take a briefly look at it. 

Based on the mailing list discussion in a different thread I would also like
to add: 

* Are we really interested in focusing on a particular security deployment
model? I don't think so. 
For example, alerts that are sent from a particular entity, such as a
government, only. Technically this does not make a lot of sense and is too
far into the deployment choices of certain entities.

* We also do not make specific restrictions regarding the type of alerts
(e.g., alerts about a tornado vs. early school closing) as the semantic
largely comes from the content of the alert -- something we will not define
anyway. There may be some technical requirements that some folks might want
to discuss, such as delivery mechanisms to deal with potential congestion
and so on. That's fine for me. 

* Excluding discussions about the type of device and the available user
interface also seems to make sense to me. This appears to be more issues
with a specific architecture that, as stated below, would not be in our
scope. 
 
Ciao
Hannes 

PS: Another pragmatic way to scope the work is to focus on the things that
have actually been proposed already rather than speculating about things.
>From what I can tell there isn't a huge amount of work being proposed in
terms of documents. When new proposals come along then one can make a
judgement again to determine whether this is something the group is
interested in. 

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Hannes Tschofenig
>Sent: 02 May, 2009 12:50
>To: [email-masked]
>Subject: [earlywarning] Some further scoping issues
>
>* we do not focus our efforts on defining an architecture used 
>for distributing of alert messages (like we did it in ECRIT 
>with the PhoneBCP/Framework document). Instead, we develop 
>building blocks (like conveying CAP in SIP). I believe we will 
>run into lots of problems with the different usages, different 
>solutions that have been specified elsewhere already, etc. 
>
>mandatory-to-implement), like CAP or GeoRSS, but instead give 
>those who deploy these mechanisms freedom. 
>
>* we do not define our own alert document format (because 
>there are other formats available already). 
>

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 11 May 2009 08:55:27 -0400

I don't think we can do this.

The biggest problem in this whole effort is the security.  This mechanism
could, in theory, send alerts to billions of devices.  That's a VERY
tempting target.  This means that security model is perhaps the single most
important aspect of the task.  I think if you limit the notifiers, the
security is more tractable.

I agree that the kind of alert doesn't really matter for our work.

I think the rendering issues are big, and will occupy a significant part of
our time.  The range of devices is large, but the size of the message is,
hopefully, small.  How we design the system so that it is feasible to render
on a wide variety of devices in a wide variety of locations (language issues
for example), is a hard problem.  In some prior efforts, this was deemed to
hard, and too much liability, and the solution was to require the notifier
(or an agent operated by a government agency) to cast the notification in a
single simple text string of limited length, thus not requiring the devices
or downstream networks to do any rendering.  While I would assume we would
not choose such a solution, it indicates that the problem is pretty big, and
needs some imagination on our part to make sure that what we send is simply
renderable on the devices.

Brian

> From: [email-masked] [mailto:earlywarning-
> [email-masked]] On Behalf Of Hannes Tschofenig
> Sent: Saturday, May 09, 2009 5:29 AM
> To: 'Hannes Tschofenig'; [email-masked]
> Subject: Re: [earlywarning] Some further scoping issues
> 
> Hi all,
>

---

From: Art Botterell <[email-masked]>
Date: Mon, 11 May 2009 07:39:56 -0700

On May 11, 2009, at 5/11/09 5:55 AM, Brian Rosen wrote:
> I think if you limit the notifiers, the security is more tractable.

Seems like the challenge here may be more attribution than  
authorization.  If folks can know with confidence who sent a message,  
they can decide for themselves who they trust.  If they can't, the  
door is open to spam.

Reliable identity is a prerequisite to access control anyway, but it  
might actually make "prior restraint" mechanisms unnecessary... thus  
allowing the technology to sidestep the complex political question of  
"authority."

- Art