Subject: Re: [earlywarning] What problem is ATOCA trying to address?
From: David R Oran <[email-masked]>
To: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
Cc: [email-masked]
Date: Fri, 26 Mar 2010 18:31:00 -0400
List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " <earlywarning.ietf.org>

On Mar 26, 2010, at 5:16 PM, DALY, BRIAN K (ATTCINW) wrote:

> Disagree - we have designed an optimized system for commercial mobile devices that will deliver alerts to devices on those networks in an efficient manner. Regardless of what IETF does CMAS will continue to be the method operators will use for delivering alerts to any device connected to the network where the operator supports CMAS. That is fact.
And TDM voice is provably a WHOLE lot more efficient than VoIP. That's a fact too. 

Nobody s arguing against using an optimized multicast/broadcast transport/underlay where such exists. We're arguing about the undesirability depending on it being there, exempting devices from requirements to handle the more general case, and limiting the architecture based on its limitations.

Imagine if we had started with SMS or Twitter instead of email as the transport architecture for applications? We'd have ATM with 140 byte cells instead of 53 byte cells.

DaveO.

(belated sarcasm alert)

> Brian K. Daly
> -------
> Sent from my Blackberry
> 
> ----- Original Message -----
> From: David R Oran <[email-masked]>
> To: DALY, BRIAN K (ATTCINW)
> Cc: Art Botterell <[email-masked]>; [email-masked] <[email-masked]>
> Sent: Fri Mar 26 13:10:11 2010
> Subject: Re: [earlywarning] What problem is ATOCA trying to address?
> 
> 
> On Mar 26, 2010, at 3:56 PM, DALY, BRIAN K (ATTCINW) wrote:
> 
>> Agree Art - Twitter is like SMS - no guarantee, unreliable, and prone to
>> congestion. While in general it is good to try to get the message out as
>> many ways as possible, at least one should be deemed "reliable".
>> 
> Sometimes reliability is the enemy of resilience. I would argue we're mostly shooting for the latter, and the former is often over-rated, especially if people start thinking it will work when needed and don't think more broadly, like maybe the cell tower just fell down.
> 
> That's why I think it's extremely short-sighted to try to "exempt" any particular device from the general IETF solution, and we should view the particular L2-specific mechanisms as optimizations to reduce load/congestion.
> 
> It also makes sense to view the cell-broadcast capability as an "underlay" for delivery of the more general Internet-generated and managed emergency alerts as opposed to some parallel and un-coordinated capability. 
> 
> Cheers, DaveO.
> 
>> Brian
>> 
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Art Botterell
>> Sent: Friday, March 26, 2010 9:37 AM
>> To: [email-masked]
>> Subject: Re: [earlywarning] What problem is ATOCA trying to address?
>> 
>> On Mar 26, 2010, at 3/26/10 9:14 AM, Henning Schulzrinne wrote:
>>> And to bore everyone again with the same thing: In many cases,
>> notifications are routinely sent to people outside a specific area or
>> beyond a single network.
>> 
>> Which is why I thought it might be useful to reflect on WHY, after all
>> these years, IP multicast has such limited scope, and on whether similar
>> constraints might apply here.
>> 
>> Meanwhile, unicast approaches like Twitter rarely try to reach everyone
>> on a particular local network, and they don't have any strict
>> constraints on latency or even reliability, so I'd be cautious about
>> assuming their suitability in emulation of a multicasting function.
>> Anyone who's ever tried to text on New Year's Eve or Mother's Day should
>> be able to relate.
>> 
>> - Art
>> _______________________________________________
>> earlywarning mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/earlywarning
>> _______________________________________________
>> earlywarning mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/earlywarning
> 

Content-class: urn:content-classes:message
Date: Fri, 26 Mar 2010 15:05:00 -0700
From: "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]>
To: "Henning Schulzrinne" <[email-masked]>, "David R Oran" <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] What problem is ATOCA trying to address?

This math does not factor into account the characteristics of the
cellular air interface.  This is a shared interface and there are no
radio resources associated with the cellular device except when the
device is in active communications (e.g., subscriber is on voice call).
Any given cell site has many more associated cellular devices than there
are radio resources to support. 

Consequently, a queuing model is required and would have to factor in at
least the following:

- How many cellular devices are registered on the cell site?

- How many cellular devices will enter or leave the coverage area of the
cell site during the time of the alert?

- What is the current utilization of air interface resources and how
many resources are available?

- What other communications from other sources including subscriber
initiated communications will also be occurring at the same time? 

- Since cellular devices have to be paged before communications can be
established, how many pages attempts will be required and how much time
is required for the paging function?

- How often is the alert message retried because of non-delivery due to
no available radio resources and what is the time interval between the
retry attempts?

REAL LIFE EXAMPLE:

The Minneapolis I-35W bridge collapse during evening rush hour on August
1st, 2007 is a good real life example of localized network congestion
for a localized environment.  The evening rush hour is one of the most
common highest network utilization times and this evening in Minneapolis
was no exception.  Immediately after the unfortunate bridge collapse all
of the cell sites for all wireless operators with coverage for the area
surrounding the bridge became congested and stayed congestion for a long
period of time.  

Network congestion conditions can occur on non-emergency events whenever
large groups of subscribers are concentrated in a small area -- e.g.,
New Years Eve at Times Square, weekend football game at your favorite
large university.

DeWayne 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Henning Schulzrinne
Sent: Friday, March 26, 2010 1:47 PM
To: David R Oran
Cc: [email-masked]
Subject: Re: [earlywarning] What problem is ATOCA trying to address?

Agreed. The scalability issue is, in my view, overrated. We're not
talking about using SMS here, but let's do a little math, with lots of
rounding:

- The average per-month iPhone data consumption is 250-300 MB, i.e., 10
MB/day.

- This translates to roughly 100 KB/hour per user (obviously more during
daytime hours, but this is back-of-the-envelope) or 27 bytes/second.

- I'd guess that an alert would be about 1 KB, i.e., it's about 1% of
the average per-hour data consumption.

Very roughly, assuming you displaced normal data traffic for a
large-scale alert, even without any multicast, you could send the alert
to everyone within 40 seconds (1000 / 27).

Clearly, there could still be congestion if you wanted to send a message
to every user in New York within a few seconds or whatever the threshold
is, but I suspect that the threshold for that will get higher and higher
as normal data volume increases.

For what it's worth
(http://blog.twitter.com/2010/02/measuring-tweets.html), Twitter handles
600 tweets per second or 50 million a day. Thus, except for the largest
metropolitan areas, even such a centralized, non-scalable infrastructure
can probably work. (It would handle my community in about 10 seconds.)
I'm not advocating that we use Twitter, just that there are different
scales and uses and that modern systems scale surprisingly well. We're
no longer talking SMS here.

We do need massively scalable and efficient distribution for the "ICBM
incoming" alerts, but it is not clear that these are appropriate or
necessary for the more mundane "traffic accident on Elm Street" events -
or that the local police department would be able to use them for those
purposes.

Henning

On Mar 26, 2010, at 4:10 PM, David R Oran wrote:

> 
> On Mar 26, 2010, at 3:56 PM, DALY, BRIAN K (ATTCINW) wrote:
> 
>> Agree Art - Twitter is like SMS - no guarantee, unreliable, and prone
to
>> congestion. While in general it is good to try to get the message out
as
>> many ways as possible, at least one should be deemed "reliable".
>> 
> Sometimes reliability is the enemy of resilience. I would argue we're
mostly shooting for the latter, and the former is often over-rated,
especially if people start thinking it will work when needed and don't
think more broadly, like maybe the cell tower just fell down.
> 
> That's why I think it's extremely short-sighted to try to "exempt" any
particular device from the general IETF solution, and we should view the
particular L2-specific mechanisms as optimizations to reduce
load/congestion.
> 
> It also makes sense to view the cell-broadcast capability as an
"underlay" for delivery of the more general Internet-generated and
managed emergency alerts as opposed to some parallel and un-coordinated
capability. 
> 
> Cheers, DaveO.
> 
>> Brian
>> 
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Art Botterell
>> Sent: Friday, March 26, 2010 9:37 AM
>> To: [email-masked]
>> Subject: Re: [earlywarning] What problem is ATOCA trying to address?
>> 
>> On Mar 26, 2010, at 3/26/10 9:14 AM, Henning Schulzrinne wrote:
>>> And to bore everyone again with the same thing: In many cases,
>> notifications are routinely sent to people outside a specific area or
>> beyond a single network.
>> 
>> Which is why I thought it might be useful to reflect on WHY, after
all
>> these years, IP multicast has such limited scope, and on whether
similar
>> constraints might apply here.
>> 
>> Meanwhile, unicast approaches like Twitter rarely try to reach
everyone
>> on a particular local network, and they don't have any strict
>> constraints on latency or even reliability, so I'd be cautious about
>> assuming their suitability in emulation of a multicasting function.
>> Anyone who's ever tried to text on New Year's Eve or Mother's Day
should
>> be able to relate.
>> 
>> - Art
>> _______________________________________________
>> earlywarning mailing list
>> [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
> 

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

Content-class: urn:content-classes:message
Date: Fri, 26 Mar 2010 14:28:02 -0700
To: <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] What problem is ATOCA trying to address?

Content-class: urn:content-classes:message
Date: Fri, 26 Mar 2010 14:16:42 -0700
From: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
To: <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] What problem is ATOCA trying to address?

From: Art Botterell <[email-masked]>
Date: Fri, 26 Mar 2010 14:15:54 -0700
To: [email-masked]
Subject: Re: [earlywarning] What problem is ATOCA trying to address?

On Mar 26, 2010, at 3/26/10 1:47 PM, Henning Schulzrinne wrote:
> Agreed. The scalability issue is, in my view, overrated. 

Whether we think scale issues are real or not isn't the point.  The point is that many network operators do.  Do we want their support in this effort or not?

- Art

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 26 Mar 2010 16:47:29 -0400
To: David R Oran <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] What problem is ATOCA trying to address?

Agreed. The scalability issue is, in my view, overrated. We're not talking about using SMS here, but let's do a little math, with lots of rounding:

- The average per-month iPhone data consumption is 250-300 MB, i.e., 10 MB/day.

- This translates to roughly 100 KB/hour per user (obviously more during daytime hours, but this is back-of-the-envelope) or 27 bytes/second.

- I'd guess that an alert would be about 1 KB, i.e., it's about 1% of the average per-hour data consumption.

Very roughly, assuming you displaced normal data traffic for a large-scale alert, even without any multicast, you could send the alert to everyone within 40 seconds (1000 / 27).

Clearly, there could still be congestion if you wanted to send a message to every user in New York within a few seconds or whatever the threshold is, but I suspect that the threshold for that will get higher and higher as normal data volume increases.

For what it's worth (http://blog.twitter.com/2010/02/measuring-tweets.html), Twitter handles 600 tweets per second or 50 million a day. Thus, except for the largest metropolitan areas, even such a centralized, non-scalable infrastructure can probably work. (It would handle my community in about 10 seconds.) I'm not advocating that we use Twitter, just that there are different scales and uses and that modern systems scale surprisingly well. We're no longer talking SMS here.

We do need massively scalable and efficient distribution for the "ICBM incoming" alerts, but it is not clear that these are appropriate or necessary for the more mundane "traffic accident on Elm Street" events - or that the local police department would be able to use them for those purposes.

Henning

On Mar 26, 2010, at 4:10 PM, David R Oran wrote:

> 
> On Mar 26, 2010, at 3:56 PM, DALY, BRIAN K (ATTCINW) wrote:
> 
>> Agree Art - Twitter is like SMS - no guarantee, unreliable, and prone to
>> congestion. While in general it is good to try to get the message out as
>> many ways as possible, at least one should be deemed "reliable".
>> 
> Sometimes reliability is the enemy of resilience. I would argue we're mostly shooting for the latter, and the former is often over-rated, especially if people start thinking it will work when needed and don't think more broadly, like maybe the cell tower just fell down.
> 
> That's why I think it's extremely short-sighted to try to "exempt" any particular device from the general IETF solution, and we should view the particular L2-specific mechanisms as optimizations to reduce load/congestion.
> 
> It also makes sense to view the cell-broadcast capability as an "underlay" for delivery of the more general Internet-generated and managed emergency alerts as opposed to some parallel and un-coordinated capability. 
> 
> Cheers, DaveO.
> 
>> Brian
>> 
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Art Botterell
>> Sent: Friday, March 26, 2010 9:37 AM
>> To: [email-masked]
>> Subject: Re: [earlywarning] What problem is ATOCA trying to address?
>> 
>> On Mar 26, 2010, at 3/26/10 9:14 AM, Henning Schulzrinne wrote:
>>> And to bore everyone again with the same thing: In many cases,
>> notifications are routinely sent to people outside a specific area or
>> beyond a single network.
>> 
>> Which is why I thought it might be useful to reflect on WHY, after all
>> these years, IP multicast has such limited scope, and on whether similar
>> constraints might apply here.
>> 
>> Meanwhile, unicast approaches like Twitter rarely try to reach everyone
>> on a particular local network, and they don't have any strict
>> constraints on latency or even reliability, so I'd be cautious about
>> assuming their suitability in emulation of a multicasting function.
>> Anyone who's ever tried to text on New Year's Eve or Mother's Day should
>> be able to relate.
>> 
>> - Art
>> _______________________________________________
>> earlywarning mailing list
>> [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
> 

Content-class: urn:content-classes:message
Date: Fri, 26 Mar 2010 13:29:31 -0700
From: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [earlywarning] Updated Charter Text for ATOCA

Date: Fri, 26 Mar 2010 13:23:27 -0700
From: Arnoud van Wijk <[email-masked]>
Organization: R3TF
To: Spencer Dawkins <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>, [email-masked]
Subject: Re: [earlywarning] Updated Charter Text for ATOCA
Reply-To: [email-masked]

Yes that is true.
What about if you wanted more information and then press a key for that 
info?
The RTT would work as the IVR system but then only text.
But I can imagine this is out of scope.

On 25-3-2010 7:52, Spencer Dawkins wrote:
>>> Also if interactivity is required or offered as an extra service, 
>>> RTT can be useful.
>>>
>> I have so far never heard that interactivity would be desired.
>
> FWIW, my understanding is that this is not even possible (you just 
> told the entire city of Yokohama that a tsunami is two hours out - 
> who's supposed to handle the questions from the entire city of Yokohama?)
>
> Spencer
>

From: David R Oran <[email-masked]>
Date: Fri, 26 Mar 2010 16:10:11 -0400
To: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] What problem is ATOCA trying to address?

On Mar 26, 2010, at 3:56 PM, DALY, BRIAN K (ATTCINW) wrote:

> Agree Art - Twitter is like SMS - no guarantee, unreliable, and prone to
> congestion. While in general it is good to try to get the message out as
> many ways as possible, at least one should be deemed "reliable".
> 
Sometimes reliability is the enemy of resilience. I would argue we're mostly shooting for the latter, and the former is often over-rated, especially if people start thinking it will work when needed and don't think more broadly, like maybe the cell tower just fell down.

That's why I think it's extremely short-sighted to try to "exempt" any particular device from the general IETF solution, and we should view the particular L2-specific mechanisms as optimizations to reduce load/congestion.

It also makes sense to view the cell-broadcast capability as an "underlay" for delivery of the more general Internet-generated and managed emergency alerts as opposed to some parallel and un-coordinated capability. 

Cheers, DaveO.

> Brian
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Art Botterell
> Sent: Friday, March 26, 2010 9:37 AM
> To: [email-masked]
> Subject: Re: [earlywarning] What problem is ATOCA trying to address?
> 
> On Mar 26, 2010, at 3/26/10 9:14 AM, Henning Schulzrinne wrote:
>> And to bore everyone again with the same thing: In many cases,
> notifications are routinely sent to people outside a specific area or
> beyond a single network.
> 
> Which is why I thought it might be useful to reflect on WHY, after all
> these years, IP multicast has such limited scope, and on whether similar
> constraints might apply here.
> 
> Meanwhile, unicast approaches like Twitter rarely try to reach everyone
> on a particular local network, and they don't have any strict
> constraints on latency or even reliability, so I'd be cautious about
> assuming their suitability in emulation of a multicasting function.
> Anyone who's ever tried to text on New Year's Eve or Mother's Day should
> be able to relate.
> 
> - Art
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

Content-class: urn:content-classes:message
Date: Fri, 26 Mar 2010 12:56:08 -0700
From: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
To: "Art Botterell" <[email-masked]>, <[email-masked]>
Subject: Re: [earlywarning] What problem is ATOCA trying to address?

Agree Art - Twitter is like SMS - no guarantee, unreliable, and prone to
congestion. While in general it is good to try to get the message out as
many ways as possible, at least one should be deemed "reliable".

Brian

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Art Botterell
Sent: Friday, March 26, 2010 9:37 AM
To: [email-masked]
Subject: Re: [earlywarning] What problem is ATOCA trying to address?

On Mar 26, 2010, at 3/26/10 9:14 AM, Henning Schulzrinne wrote:
> And to bore everyone again with the same thing: In many cases,
notifications are routinely sent to people outside a specific area or
beyond a single network.

Which is why I thought it might be useful to reflect on WHY, after all
these years, IP multicast has such limited scope, and on whether similar
constraints might apply here.

Meanwhile, unicast approaches like Twitter rarely try to reach everyone
on a particular local network, and they don't have any strict
constraints on latency or even reliability, so I'd be cautious about
assuming their suitability in emulation of a multicasting function.
Anyone who's ever tried to text on New Year's Eve or Mother's Day should
be able to relate.

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

Content-class: urn:content-classes:message
Date: Fri, 26 Mar 2010 12:49:43 -0700
From: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: [earlywarning] What problem is ATOCA trying to address?

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 26 Mar 2010 13:22:40 -0400
To: Art Botterell <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] What problem is ATOCA trying to address?

As it happens, our local police department uses Twitter for alerts: see

http://twitter.com/leoniapd

Works quite well.

On Mar 26, 2010, at 12:36 PM, Art Botterell wrote:

> On Mar 26, 2010, at 3/26/10 9:14 AM, Henning Schulzrinne wrote:
>> And to bore everyone again with the same thing: In many cases, notifications are routinely sent to people outside a specific area or beyond a single network.
> 
> Which is why I thought it might be useful to reflect on WHY, after all these years, IP multicast has such limited scope, and on whether similar constraints might apply here.
> 
> Meanwhile, unicast approaches like Twitter rarely try to reach everyone on a particular local network, and they don't have any strict constraints on latency or even reliability, so I'd be cautious about assuming their suitability in emulation of a multicasting function.  Anyone who's ever tried to text on New Year's Eve or Mother's Day should be able to relate.
> 
> - Art
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning
> 

From: ken carlberg <[email-masked]>
Date: Fri, 26 Mar 2010 12:45:38 -0400
To: Art Botterell <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] What problem is ATOCA trying to address?

so right off the top of the head, one could envision the following distribution models:

a) end-to-end unicast -- worst case scenario in terms of load concentration at a single source
b) overlay unicast segments -- retaining the the unicast only model, but pushing the distribution to a collection of nodes operating as an overlay.  Headaches include management of the overlay, but potentially higher resiliency
c) unicast/multicast servers -- can be considered an extension of (b), but in this case, include a set of nodes that take the unicast traffic and forwards it downstream via multicast to the end nodes.  There is a fair amount of work that has been done with this model, and it leverages the efficiency of multicast, where multicast is likely to only reside in access/enterprise networks

-ken

On Mar 26, 2010, at 12:26 PM, Art Botterell wrote:

> On Mar 26, 2010, at 3/26/10 8:44 AM, Brian Rosen wrote:
>> We're not at the mechanism state yet.
> 
> True, and that's not really what I meant.  My point was that the shapes of the problem and the constraints seem similar to the more general problem of multicasting, on which there's been a lot of prior work.
> 
> So perhaps it would be useful to enumerate the particular ways in which this problem ISN'T just an instance of multicasting.
> 
> - Art
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

From: Art Botterell <[email-masked]>
Date: Fri, 26 Mar 2010 09:36:32 -0700
To: [email-masked]
Subject: Re: [earlywarning] What problem is ATOCA trying to address?

On Mar 26, 2010, at 3/26/10 9:14 AM, Henning Schulzrinne wrote:
> And to bore everyone again with the same thing: In many cases, notifications are routinely sent to people outside a specific area or beyond a single network.

Which is why I thought it might be useful to reflect on WHY, after all these years, IP multicast has such limited scope, and on whether similar constraints might apply here.

Meanwhile, unicast approaches like Twitter rarely try to reach everyone on a particular local network, and they don't have any strict constraints on latency or even reliability, so I'd be cautious about assuming their suitability in emulation of a multicasting function.  Anyone who's ever tried to text on New Year's Eve or Mother's Day should be able to relate.

- Art

From: Art Botterell <[email-masked]>
Date: Fri, 26 Mar 2010 09:26:15 -0700
To: [email-masked]
Subject: Re: [earlywarning] What problem is ATOCA trying to address?

On Mar 26, 2010, at 3/26/10 8:44 AM, Brian Rosen wrote:
> We're not at the mechanism state yet.

True, and that's not really what I meant.  My point was that the shapes of the problem and the constraints seem similar to the more general problem of multicasting, on which there's been a lot of prior work.

So perhaps it would be useful to enumerate the particular ways in which this problem ISN'T just an instance of multicasting.

- Art

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 26 Mar 2010 12:14:37 -0400
To: Brian Rosen <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] What problem is ATOCA trying to address?

And to bore everyone again with the same thing: In many cases, notifications are routinely sent to people outside a specific area or beyond a single network. Simple example: The WiFi network in Panera Bread is unlikely to be reachable by single multicast along with the 3GPP network covering that same region, and may even be logically run from some corporate HQ.

Henning

On Mar 26, 2010, at 11:44 AM, Brian Rosen wrote:

> We're not at the mechanism state yet.  While I imagine that the mechanisms
> may include something that is "if you have multicast, use it", I don't think
> that would be enough because multicast is not enabled in way too many
> networks.  Sites like Twitter show us that we can get enough messages sent
> out in reasonable periods of time without multicast.
> 
> Brian
> 
> 
> On 3/26/10 11:34 AM, "Art Botterell" <[email-masked]> wrote:
> 
>> On Mar 26, 2010, at 3/26/10 6:42 AM, Marc Linsner wrote:
>>> Any IP device, any IP network, any message (not just Fed. Gov't), all under
>>> end-user control (opt-in, opt-out, additional locations, etc.).
>> 
>> So is it possible we're really just revisiting IP multicast?
>> 
>> - Art
>> _______________________________________________
>> 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: Fri, 26 Mar 2010 11:50:22 -0400
From: Marc Linsner <[email-masked]>
To: Art Botterell <[email-masked]>, <[email-masked]>
Subject: Re: [earlywarning] What problem is ATOCA trying to address?

On 3/26/10 11:34 AM, "Art Botterell" <[email-masked]> wrote:

> On Mar 26, 2010, at 3/26/10 6:42 AM, Marc Linsner wrote:
>> Any IP device, any IP network, any message (not just Fed. Gov't), all under
>> end-user control (opt-in, opt-out, additional locations, etc.).
> 
> So is it possible we're really just revisiting IP multicast?

I wouldn't draw that conclusion.

I would desire/expect more application around it such that an 'aggregator'
of messages from various entities might provide a service to my
specification.  IP multicast may or may not have a play.

-Marc-

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

Date: Fri, 26 Mar 2010 11:44:44 -0400
From: Brian Rosen <[email-masked]>
To: Art Botterell <[email-masked]>, <[email-masked]>
Subject: Re: [earlywarning] What problem is ATOCA trying to address?

We're not at the mechanism state yet.  While I imagine that the mechanisms
may include something that is "if you have multicast, use it", I don't think
that would be enough because multicast is not enabled in way too many
networks.  Sites like Twitter show us that we can get enough messages sent
out in reasonable periods of time without multicast.

Brian

On 3/26/10 11:34 AM, "Art Botterell" <[email-masked]> wrote:

> On Mar 26, 2010, at 3/26/10 6:42 AM, Marc Linsner wrote:
>> Any IP device, any IP network, any message (not just Fed. Gov't), all under
>> end-user control (opt-in, opt-out, additional locations, etc.).
> 
> So is it possible we're really just revisiting IP multicast?
> 
> - Art
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

From: Art Botterell <[email-masked]>
Date: Fri, 26 Mar 2010 08:34:52 -0700
To: [email-masked]
Subject: Re: [earlywarning] What problem is ATOCA trying to address?

On Mar 26, 2010, at 3/26/10 6:42 AM, Marc Linsner wrote:
> Any IP device, any IP network, any message (not just Fed. Gov't), all under
> end-user control (opt-in, opt-out, additional locations, etc.).

So is it possible we're really just revisiting IP multicast?

- Art

Date: Fri, 26 Mar 2010 11:25:11 -0400
From: Brian Rosen <[email-masked]>
To: <[email-masked]>, "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] What problem is ATOCA trying to address?

'course CAP should just borrow PIDF-LO and thus be able to send an alert
about the hospital at 123 Main (that is, a civic "where").

Thanks for the info, should be a useful update of CAP/EDXL.

Brian

On 3/26/10 11:15 AM, "[email-masked]" <[email-masked]>
wrote:

> Apologies for the slight digression. Not to be contentious, but CAP is
> only part of the application payload solution. Other countries are using
> other encodings instead of CAP (such as SMS) or are using additional
> application solutions in addition to CAP (such as GeoRSS or GeoSMS).
> 
> Something also to be aware of WRT CAP. The OASIS EM TC has defined a set
> of requirements for an enhanced OASIS "where" model (geographic) that will
> be encoded as a GML application schema. The plan is to be consistent with
> the PIDF-LO geodetic GML schema as well as GeoRSS GML. This work adds
> additional geometries and other elements such as multipoints. These
> requirements were provided by the CAP implementation community and will be
> incorporated (perhaps by extension) in CAP 2.0 and future revisions of
> EDXL.
> 
> Cheers
> 
> Carl
> 
>> It is not clear exactly what problem ATOCA is trying to solve.
>> 
>> The first item needed for alerting is a common alerting message. This has
>> been defined as the CAP protocol which has been adopted by ITU. The
>> current version is CAP 1.1 and version 1.2 is expected soon.
>> 
>> The second item needed is transport of CAP messages. Various techniques
>> already exist and Brian Rosen has already introduced a draft into ECRIT to
>> define how to deliver CAP via SIP.
>> 
>> The third item is distribution of the alert information. Various
>> techniques already exist such as multicast, cell broadcast, MBMS, EAS,
>> CMAS etc..
>> 
>> The fourth item is authentication and authorization of the alert
>> origination. The functionality is country specific and these countries
>> also have defined methods and procedures to address this.
>> 
>> So what item remains to be addressed by ATOCA?
>> 
>> <--------------------------->
>> DeWayne Sennett, AT&T Services, Inc.
>> Sent from my BlackBerry
>> _______________________________________________
>> 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: Fri, 26 Mar 2010 11:15:38 -0400 (EDT)
From: [email-masked]
To: "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]>
Importance: Normal
Cc: [email-masked]
Subject: Re: [earlywarning] What problem is ATOCA trying to address?

Apologies for the slight digression. Not to be contentious, but CAP is
only part of the application payload solution. Other countries are using
other encodings instead of CAP (such as SMS) or are using additional
application solutions in addition to CAP (such as GeoRSS or GeoSMS).

Something also to be aware of WRT CAP. The OASIS EM TC has defined a set
of requirements for an enhanced OASIS "where" model (geographic) that will
be encoded as a GML application schema. The plan is to be consistent with
the PIDF-LO geodetic GML schema as well as GeoRSS GML. This work adds
additional geometries and other elements such as multipoints. These
requirements were provided by the CAP implementation community and will be
incorporated (perhaps by extension) in CAP 2.0 and future revisions of
EDXL.

Cheers

Carl

> It is not clear exactly what problem ATOCA is trying to solve.
>
> The first item needed for alerting is a common alerting message. This has
> been defined as the CAP protocol which has been adopted by ITU. The
> current version is CAP 1.1 and version 1.2 is expected soon.
>
> The second item needed is transport of CAP messages. Various techniques
> already exist and Brian Rosen has already introduced a draft into ECRIT to
> define how to deliver CAP via SIP.
>
> The third item is distribution of the alert information. Various
> techniques already exist such as multicast, cell broadcast, MBMS, EAS,
> CMAS etc..
>
> The fourth item is authentication and authorization of the alert
> origination. The functionality is country specific and these countries
> also have defined methods and procedures to address this.
>
> So what item remains to be addressed by ATOCA?
>
> <--------------------------->
> DeWayne Sennett, AT&T Services, Inc.
> Sent from my BlackBerry
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning
>

Date: Fri, 26 Mar 2010 10:57:05 -0400 (EDT)
From: [email-masked]
To: "ken carlberg" <[email-masked]>
Importance: Normal
Cc: "DALY, BRIAN K \(ATTCINW\)" <[email-masked]>, [email-masked]
Subject: Re: [earlywarning] (no subject)

Absolutely agree! The OGC Members have developed and are working alerting
and warning applications in many countries. Many different
infrastructures, policies, and endpoints. FCC rules do not apply :-)

Carl

> please, let's remember not to be U.S. centric.
>
> -ken
>
>
> On Mar 25, 2010, at 8:03 PM, DALY, BRIAN K (ATTCINW) wrote:
>
>> They are connected to the wireless network and under FCC rules the CMSP
>> has responsibility for delivering emergency alerts to those devices
>> under FCC Part 10 rules and the CMSP election to provide those alerts.
>>
>> So no, this work does not apply. CMAS applies to those devices.
>>
>> Brian Daly
>>
>> From: Brian Rosen [mailto:[email-masked]]
>> Sent: Thursday, March 25, 2010 5:00 PM
>> To: DALY, BRIAN K (ATTCINW); [email-masked]
>> Subject: Re: [earlywarning] (no subject)
>>
>> Are they connected to the Internet?
>>
>> If they are, it would apply.  If they aren�t, then it wouldn�t apply.
>>
>> Brian
>>
>>
>> On 3/25/10 7:51 PM, "DALY, BRIAN K (ATTCINW)" <[email-masked]> wrote:
>>
>> That will not apply to devices connected to wireless cellular networks.
>>
>>
>> From: Brian Rosen [mailto:[email-masked]]
>> Sent: Thursday, March 25, 2010 4:50 PM
>> To: DALY, BRIAN K (ATTCINW); [email-masked]
>> Subject: Re: [earlywarning] (no subject)
>>
>> Once again, this is NOT about a solution limited to wireless cellular
>> networks.  It is about a solution for internet connected endpoints of
>> all kinds.
>>
>> Brian
>>
>>
>> On 3/25/10 7:46 PM, "DALY, BRIAN K (ATTCINW)" <[email-masked]> wrote:
>> Keith � We agree with you, and to further the point, in wireless
>> cellular IP networks a point to point solution would be problematic.
>> Cell Broadcast is used for CMAS because SMS cannot be used for any real
>> time alerting � it was not designed for that application and has serious
>> limitations, as the FCC CMSAAC studied.
>>
>> When it comes to the evolved packet core and IMS, again a point to point
>> solution  will cause significant congestion on the network and a
>> broadcast/multicast solution must be used to effectively deliver alert
>> messages. Thus things like location and �priority� are already handled
>> in the delivery network.
>>
>> ATIS and 3GPP will be studying how to support multimedia alerts in the
>> future, as recommended by the FCC CMSAAC. This is all beyond the scope
>> of this work effort.
>>
>> Regards,
>> Brian
>>
>> Date: Thu, 25 Mar 2010 03:13:24 +0100
>> From: "DRAGE, Keith (Keith)" <[email-masked]>
>> Subject: Re: [earlywarning] Updated Charter Text for ATOCA
>> To: Hannes Tschofenig <[email-masked]>,
>>       "[email-masked]" <[email-masked]>
>> Message-ID:
>>       <[email-masked]>
>>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> What I am not seeing here is any separation of the problem from the one
>> that cell broadcast attempts to solve. Fundamentally, cell broadcast, as
>> exists on all GSM, UTRAN and E-UTRAN based cell phones and is being used
>> for Tsunami warning and Public Warning, exists and is not going to
>> substantially change. The major limitation here is is length of message,
>> and what does get transmitted will be very much dependent on that
>> restriction.
>>
>> Moreover I have heard from a number of governmental bodies that they are
>> happy with that situation and are not envisaging further standardisation
>> in that area outside of 3GPP.
>>
>> So my view at the moment is that there is no point in IETF trying to
>> address the scope of what is already specified in cell broadcast (from
>> base station to end mobile).
>>
>> regards
>>
>> Keith
>>
>>
>>
>> _______________________________________________
>> earlywarning mailing list
>> [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: Fri, 26 Mar 2010 10:45:08 -0400 (EDT)
From: [email-masked]
To: "Brian Rosen" <[email-masked]>
Importance: Normal
Cc: "DALY, BRIAN K \(ATTCINW\)" <[email-masked]>, [email-masked]
Subject: Re: [earlywarning] (no subject)

Absolutely!

Carl

> Once again, this is NOT about a solution limited to wireless cellular
> networks.  It is about a solution for internet connected endpoints of all
> kinds.
>
> Brian
>
>
> On 3/25/10 7:46 PM, "DALY, BRIAN K (ATTCINW)" <[email-masked]> wrote:
>
>> Keith � We agree with you, and to further the point, in wireless
>> cellular IP
>> networks a point to point solution would be problematic. Cell Broadcast
>> is
>> used for CMAS because SMS cannot be used for any real time alerting � it
>> was
>> not designed for that application and has serious limitations, as the
>> FCC
>> CMSAAC studied.
>>
>> When it comes to the evolved packet core and IMS, again a point to point
>> solution  will cause significant congestion on the network and a
>> broadcast/multicast solution must be used to effectively deliver alert
>> messages. Thus things like location and �priority� are already handled
>> in the
>> delivery network.
>>
>> ATIS and 3GPP will be studying how to support multimedia alerts in the
>> future,
>> as recommended by the FCC CMSAAC. This is all beyond the scope of this
>> work
>> effort.
>>
>> Regards,
>> Brian
>>
>> Date: Thu, 25 Mar 2010 03:13:24 +0100
>> From: "DRAGE, Keith (Keith)" <[email-masked]>
>> Subject: Re: [earlywarning] Updated Charter Text for ATOCA
>> To: Hannes Tschofenig <[email-masked]>,
>>       "[email-masked]" <[email-masked]>
>> Message-ID:
>>
>> <[email-masked]
>> om>
>>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> What I am not seeing here is any separation of the problem from the one
>> that
>> cell broadcast attempts to solve. Fundamentally, cell broadcast, as
>> exists on
>> all GSM, UTRAN and E-UTRAN based cell phones and is being used for
>> Tsunami
>> warning and Public Warning, exists and is not going to substantially
>> change.
>> The major limitation here is is length of message, and what does get
>> transmitted will be very much dependent on that restriction.
>>
>> Moreover I have heard from a number of governmental bodies that they are
>> happy
>> with that situation and are not envisaging further standardisation in
>> that
>> area outside of 3GPP.
>>
>> So my view at the moment is that there is no point in IETF trying to
>> address
>> the scope of what is already specified in cell broadcast (from base
>> station to
>> end mobile).
>>
>> regards
>>
>> Keith
>>
>>
>>
>>
>> _______________________________________________
>> 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: ken carlberg <[email-masked]>
Date: Fri, 26 Mar 2010 09:53:01 -0400
To: Marc Linsner <[email-masked]>
Cc: "SENNETT, DEWAYNE A \(ATTCINW\)" <[email-masked]>, [email-masked]
Subject: Re: [earlywarning] What problem is ATOCA trying to address?

+1

On Mar 26, 2010, at 9:42 AM, Marc Linsner wrote:

> 
>> 
>> So what item remains to be addressed by ATOCA?
>> 
> 
> Any IP device, any IP network, any message (not just Fed. Gov't), all under
> end-user control (opt-in, opt-out, additional locations, etc.).
> 
> -Marc-
> 
> 
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

Date: Fri, 26 Mar 2010 09:42:59 -0400
From: Marc Linsner <[email-masked]>
To: "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]>, <[email-masked]>
Subject: Re: [earlywarning] What problem is ATOCA trying to address?

> 
> So what item remains to be addressed by ATOCA?
> 

Any IP device, any IP network, any message (not just Fed. Gov't), all under
end-user control (opt-in, opt-out, additional locations, etc.).

-Marc-

Date: Thu, 25 Mar 2010 19:12:29 -0700
From: Kepeng Li <[email-masked]>
To: 'Brian Rosen' <[email-masked]>, "'SENNETT, DEWAYNE A (ATTCINW)'" <[email-masked]>, "'DALY, BRIAN K (ATTCINW)'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [earlywarning] (no subject)

This is a multi-part message in MIME format.

--Boundary_(ID_WTiRfwBD0I0b3ee585L3Vw)
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: quoted-printable

I agree that we should not exclude the wireless device connected to the
Internet.

Whether or not to have a standard in IETF for internet is another issue.

Kepeng

������: [email-masked] [mailto:[email-masked]]
���� Brian Rosen
����ʱ��: 2010��3��25�� 17:59
�ռ���: SENNETT, DEWAYNE A (ATTCINW); DALY, BRIAN K (ATTCINW);
[email-masked]; [email-masked]
����: Re: [earlywarning] (no subject)

I think this is silly.

No one is working on alert mechanisms that apply to the Internet.

The Internet is global, ubiquitous and independent of L2.  The proposed work
applies to any kind of device connected to the Internet.  Whatever scale
problems exist apply to all L2s one way or another.  They must be faced and
solved for the work to be useful.  To exclude wireless IMS systems based on
the notion that someone else is working on a system limited to cell
broadcast is, in my opinion, not a good idea.

I do well understand that vendors and carriers don��t like multiple answers
to the same problem.  I get that.  However, the IETF is the proper place to
do work on alerts on the Internet, and should not exclude parts of the
Internet.

Brian

On 3/25/10 8:50 PM, "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]> wrote:

I propose that the following sentence be added to the ATOCA charter:

The ATOCA RFC's are not applicable to wireless devices which receive their
connectivity via 3GPP EPC/IMS.

<---------------------------> 
DeWayne Sennett, AT&T Services, Inc. 
Sent from my BlackBerry

  _____  

From: [email-masked] <[email-masked]> 
To: [email-masked] <[email-masked]>;
[email-masked] <[email-masked]>; [email-masked]
<[email-masked]> 
Sent: Thu Mar 25 17:43:10 2010
Subject: Re: [earlywarning] (no subject) 

Keith

You bring up a good point - we don't want to design a solution that will
result in failure of the network, therefore I second DeWayne's proposal to
exclude from the charter devices that support PWS (and CMAS under that
umbrella) and to acknowledge this solution may result in network problems
(e.g. Congestion).

Brian Daly 
Brian K. Daly 
------- 
Sent from my Blackberry

  _____  

From: DRAGE, Keith (Keith) <[email-masked]> 
To: Brian Rosen <[email-masked]>; DALY, BRIAN K (ATTCINW);
[email-masked] <[email-masked]> 
Sent: Thu Mar 25 17:35:30 2010
Subject: RE: [earlywarning] (no subject) 

Yes those cellphones could well be connected to the internet.

But cell broadcast service exists on 3GPP phones. For alerts that are
intended to hit a large proportion of the phones in any cell, it makes best
use of the bandwidth.

You bring up an IP connection to all cellphones in that cell, and then
broadcast warnings to all those cells, and the net result will be
inappropriate loading of cells specifically for this traffic. Given that
such warnings may otherwise create network stress as a result of the public
warning being made in the first place, the first point of call for getting
such warnings to cellphone uses has to be cell broadcast.

It appears that many governmental organisations have accepted cell broadcast
as the desired means of delivering public warnings to cellphones.

Therefore any IETF activity has to acknowledge that solution exists for
cellphones. 

Further I believe that any IETF solution has to specifically NOT convey the
impression that for cellphones, the IETF solution is a good way forward for
the warning itself. Users could well find the warnings from the IETF
solution to an IP endpoint delivered well after the cell broadcast warning.
And certainly the IETF solution should not expect priority over other types
of traffic at that point, because at cell broadcast channel already exists
to give that priority for the appropriate type of traffic.

regards

Keith

 

  _____  

From: [email-masked]  [mailto:[email-masked]]
On Behalf Of Brian  Rosen
Sent: Friday, March 26, 2010 12:00 AM
To: DALY,  BRIAN K (ATTCINW); [email-masked]
Subject: Re: [earlywarning]  (no subject)

Are they connected to the Internet?

If they  are, it would apply.  If they aren��t, then it wouldn��t  apply.

Brian

On 3/25/10 7:51 PM, "DALY, BRIAN K (ATTCINW)"  <[email-masked]>  wrote:

That will not apply to devices  connected to wireless cellular  networks.

From: Brian Rosen [mailto:[email-masked]]  
Sent: Thursday, March 25, 2010 4:50 PM
To: DALY, BRIAN  K (ATTCINW); [email-masked]
Subject:  Re: [earlywarning] (no subject)

Once  again, this is NOT about a solution limited to wireless cellular
networks.   It is about a solution for internet connected endpoints of all
kinds.   

Brian

On 3/25/10 7:46 PM, "DALY, BRIAN K (ATTCINW)"  <[email-masked]> wrote:
Keith �C We  agree with you, and to further the point, in wireless cellular
IP networks a  point to point solution would be problematic. Cell Broadcast
is used for  CMAS because SMS cannot be used for any real time alerting �C
it was not  designed for that application and has serious limitations, as
the FCC CMSAAC  studied.
 
When it comes to the evolved packet core and IMS,  again a point to point
solution  will cause significant congestion on  the network and a
broadcast/multicast solution must be used to effectively  deliver alert
messages. Thus things like location and ��priority�� are already  handled in
the delivery network.
 
ATIS and 3GPP will be studying  how to support multimedia alerts in the
future, as recommended by the FCC  CMSAAC. This is all beyond the scope of
this work  effort.
 
Regards,
Brian
 
Date: Thu, 25 Mar 2010 03:13:24 +0100
From:  "DRAGE, Keith (Keith)" <[email-masked]>
Subject:  Re: [earlywarning] Updated Charter Text for ATOCA
To: Hannes Tschofenig  <[email-masked]>,
      "[email-masked]" <[email-masked]>
Message-ID:
 
<[email-masked]
.com>
      
Content-Type:  text/plain; charset="us-ascii"
 
What I am not seeing here is any  separation of the problem from the one
that cell broadcast attempts to  solve. Fundamentally, cell broadcast, as
exists on all GSM, UTRAN and  E-UTRAN based cell phones and is being used
for Tsunami warning and Public  Warning, exists and is not going to
substantially change. The major  limitation here is is length of message,
and what does get transmitted will  be very much dependent on that
restriction.
 
Moreover I have  heard from a number of governmental bodies that they are
happy with that  situation and are not envisaging further standardisation in
that area  outside of 3GPP.
 
So my view at the moment is that there is no  point in IETF trying to
address the scope of what is already specified in  cell broadcast (from base
station to end  mobile).
 
regards
 
Keith

 

  _____  

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

--Boundary_(ID_WTiRfwBD0I0b3ee585L3Vw)
Content-type: text/html; charset=gb2312
Content-transfer-encoding: quoted-printable

<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=gb2312">
<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">

<head>

<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>Re: [earlywarning] (no subject)</title>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=ZH-CN link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><span lang=EN-US style='font-size:10.5pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I agree that we should not exclude the wireless device connected
to the Internet.<o:p></o:p></span></p>

<p class=MsoNormal><span lang=EN-US style='font-size:10.5pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span lang=EN-US style='font-size:10.5pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Whether or not to have a standard in IETF for internet is
another issue.<o:p></o:p></span></p>

<p class=MsoNormal><span lang=EN-US style='font-size:10.5pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span lang=EN-US style='font-size:10.5pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Kepeng<o:p></o:p></span></p>

<div>

<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'>

<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:SimSun'>������<span
lang=EN-US>:</span></span></b><span lang=EN-US style='font-size:10.0pt;
font-family:SimSun'> [email-masked] [mailto:[email-masked]]
</span><b><span style='font-size:10.0pt;font-family:SimSun'>���� </span></b><span
lang=EN-US style='font-size:10.0pt;font-family:SimSun'>Brian Rosen<br>
</span><b><span style='font-size:10.0pt;font-family:SimSun'>����ʱ��<span
lang=EN-US>:</span></span></b><span lang=EN-US style='font-size:10.0pt;
font-family:SimSun'> 2010</span><span style='font-size:10.0pt;font-family:SimSun'>��<span
lang=EN-US>3</span>��<span lang=EN-US>25</span>��<span lang=EN-US>
17:59<br>
</span><b>�ռ���<span lang=EN-US>:</span></b><span
lang=EN-US> SENNETT, DEWAYNE A (ATTCINW); DALY, BRIAN K (ATTCINW);
[email-masked]; [email-masked]<br>
</span><b>����<span lang=EN-US>:</span></b><span lang=EN-US> Re:
[earlywarning] (no subject)<o:p></o:p></span></span></p>

</div>

</div>

<p class=MsoNormal><span lang=EN-US><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal style='margin-bottom:12.0pt'><span lang=EN-US
style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>I think this is
silly.<br>
<br>
No one is working on alert mechanisms that apply to the Internet.<br>
<br>
The Internet is global, ubiquitous and independent of L2. &nbsp;The proposed
work applies to any kind of device connected to the Internet. &nbsp;Whatever
scale problems exist apply to all L2s one way or another. &nbsp;They must be
faced and solved for the work to be useful. &nbsp;To exclude wireless IMS
systems based on the notion that someone else is working on a system limited to
cell broadcast is, in my opinion, not a good idea.<br>
<br>
I do well understand that vendors and carriers don��t like multiple answers to
the same problem. &nbsp;I get that. &nbsp;However, the IETF is the proper place
to do work on alerts on the Internet, and should not exclude parts of the
Internet.<br>
<br>
Brian<br>
<br>
<br>
On 3/25/10 8:50 PM, &quot;SENNETT, DEWAYNE A (ATTCINW)&quot; &lt;<a
href="[email-masked]">[email-masked]</a>&gt; wrote:</span><span lang=EN-US><o:p></o:p></span></p>

<p class=MsoNormal style='margin-bottom:12.0pt'><span lang=EN-US
style='font-size:11.0pt;font-family:"Arial","sans-serif";color:navy'>I propose
that the following sentence be added to the ATOCA charter:<br>
<br>
The ATOCA RFC's are not applicable to wireless devices which receive their
connectivity via 3GPP EPC/IMS.<br>
<br>
<br>
<br>
&lt;---------------------------&gt; <br>
DeWayne Sennett, AT&amp;T Services, Inc. <br>
Sent from my BlackBerry</span><span lang=EN-US style='font-size:11.0pt;
font-family:"Calibri","sans-serif"'><o:p></o:p></span></p>

<div class=MsoNormal align=center style='text-align:center'><span lang=EN-US
style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>

<hr size=2 width="100%" align=center>

</span></div>

<p class=MsoNormal style='margin-bottom:12.0pt'><b><span lang=EN-US
style='font-size:11.0pt;font-family:"Tahoma","sans-serif"'>From</span></b><span
lang=EN-US style='font-size:11.0pt;font-family:"Tahoma","sans-serif"'>: <a
href="[email-masked]">[email-masked]</a> &lt;<a
href="[email-masked]">[email-masked]</a>&gt; <br>
<b>To</b>: <a href="[email-masked]">[email-masked]</a>
&lt;<a href="[email-masked]">[email-masked]</a>&gt;;
<a href="[email-masked]">[email-masked]</a> &lt;<a
href="[email-masked]">[email-masked]</a>&gt;; <a
href="[email-masked]">[email-masked]</a> &lt;<a
href="[email-masked]">[email-masked]</a>&gt; <br>
<b>Sent</b>: Thu Mar 25 17:43:10 2010<br>
<b>Subject</b>: Re: [earlywarning] (no subject) <br>
</span><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><br>
</span><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif";
color:navy'>Keith<br>
<br>
You bring up a good point - we don't want to design a solution that will result
in failure of the network, therefore I second DeWayne's proposal to exclude
from the charter devices that support PWS (and CMAS under that umbrella) and to
acknowledge this solution may result in network problems (e.g. Congestion).<br>
<br>
Brian Daly <br>
Brian K. Daly <br>
------- <br>
Sent from my Blackberry</span><span lang=EN-US style='font-size:11.0pt;
font-family:"Calibri","sans-serif"'><o:p></o:p></span></p>

<div class=MsoNormal align=center style='text-align:center'><span lang=EN-US
style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>

<hr size=2 width="100%" align=center>

</span></div>

<p class=MsoNormal style='margin-bottom:12.0pt'><b><span lang=EN-US
style='font-size:11.0pt;font-family:"Tahoma","sans-serif"'>From</span></b><span
lang=EN-US style='font-size:11.0pt;font-family:"Tahoma","sans-serif"'>: DRAGE,
Keith (Keith) &lt;<a href="[email-masked]">[email-masked]</a>&gt;
<br>
<b>To</b>: Brian Rosen &lt;<a href="[email-masked]">[email-masked]</a>&gt;;
DALY, BRIAN K (ATTCINW); <a href="[email-masked]">[email-masked]</a>
&lt;<a href="[email-masked]">[email-masked]</a>&gt; <br>
<b>Sent</b>: Thu Mar 25 17:35:30 2010<br>
<b>Subject</b>: RE: [earlywarning] (no subject) <br>
</span><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><br>
</span><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif";
color:blue'>Yes those cellphones could well be connected to the internet.<br>
</span><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><br>
</span><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif";
color:blue'>But cell broadcast service exists on 3GPP phones. For alerts that
are intended to hit a large proportion of the phones in any cell, it makes best
use of the bandwidth.<br>
</span><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><br>
</span><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif";
color:blue'>You bring up an IP connection to all cellphones in that cell, and
then broadcast warnings to all those cells, and the net result will be
inappropriate loading of cells specifically for this traffic. Given that such
warnings may otherwise create network stress as a result of the public warning
being made in the first place, the first point of call for getting such
warnings to cellphone uses has to be cell broadcast.<br>
</span><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><br>
</span><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif";
color:blue'>It appears that many governmental organisations have accepted cell
broadcast as the desired means of delivering public warnings to cellphones.<br>
</span><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><br>
</span><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif";
color:blue'>Therefore any IETF activity has to acknowledge that solution exists
for cellphones. <br>
</span><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><br>
</span><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif";
color:blue'>Further I believe that any IETF solution has to specifically NOT
convey the impression that for cellphones, the IETF solution is a good way
forward for the warning itself. Users could well find the warnings from the
IETF solution to an IP endpoint delivered well after the cell broadcast
warning. And certainly the IETF solution should not expect priority over other
types of traffic at that point, because at cell broadcast channel already
exists to give that priority for the appropriate type of traffic.<br>
</span><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><br>
</span><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif";
color:blue'>regards<br>
</span><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><br>
</span><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif";
color:blue'>Keith</span><span lang=EN-US><o:p></o:p></span></p>

<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><br>
&nbsp;<o:p></o:p></span></p>

<div class=MsoNormal align=center style='text-align:center'><span lang=EN-US
style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>

<hr size=3 width="100%" align=center>

</span></div>

<p class=MsoNormal><b><span lang=EN-US style='font-size:11.0pt;font-family:
"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:11.0pt;
font-family:"Tahoma","sans-serif"'> <a href="[email-masked]">[email-masked]</a>
&nbsp;[<a href="mailto:[email-masked]">mailto:[email-masked]</a>]
<b>On Behalf Of </b>Brian &nbsp;Rosen<br>
<b>Sent:</b> Friday, March 26, 2010 12:00 AM<br>
<b>To:</b> DALY, &nbsp;BRIAN K (ATTCINW); <a href="[email-masked]">[email-masked]</a><br>
<b>Subject:</b> Re: [earlywarning] &nbsp;(no subject)<br>
</span><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><br>
&nbsp;<br>
Are they connected to the Internet?<br>
<br>
If they &nbsp;are, it would apply. &nbsp;If they aren��t, then it wouldn��t
&nbsp;apply.<br>
<br>
Brian<br>
<br>
<br>
On 3/25/10 7:51 PM, &quot;DALY, BRIAN K (ATTCINW)&quot; &nbsp;&lt;<a
href="[email-masked]">[email-masked]</a>&gt; &nbsp;wrote:<br>
<br>
&nbsp;</span><span lang=EN-US><o:p></o:p></span></p>

<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>That will not apply to devices &nbsp;connected to wireless
cellular &nbsp;networks.<br>
&nbsp;<br>
</span><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><br>
</span><b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Brian
Rosen [<a href="mailto:[email-masked]">mailto:[email-masked]</a>] &nbsp;<br>
<b>Sent:</b> Thursday, March 25, 2010 4:50 PM<br>
<b>To:</b> DALY, BRIAN &nbsp;K (ATTCINW); <a href="[email-masked]">[email-masked]</a><br>
<b>Subject:</b> &nbsp;Re: [earlywarning] (no subject)<br>
</span><span lang=EN-US><br>
</span><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>Once
&nbsp;again, this is NOT about a solution limited to wireless cellular
networks. &nbsp;&nbsp;It is about a solution for internet connected endpoints
of all kinds. &nbsp;&nbsp;<br>
<br>
Brian<br>
<br>
<br>
On 3/25/10 7:46 PM, &quot;DALY, BRIAN K (ATTCINW)&quot; &nbsp;&lt;<a
href="[email-masked]">[email-masked]</a>&gt; wrote:<br>
Keith �C We &nbsp;agree with you, and to further the point, in wireless cellular
IP networks a &nbsp;point to point solution would be problematic. Cell
Broadcast is used for &nbsp;CMAS because SMS cannot be used for any real time
alerting �C it was not &nbsp;designed for that application and has serious
limitations, as the FCC CMSAAC &nbsp;studied.<br>
&nbsp;<br>
When it comes to the evolved packet core and IMS, &nbsp;again a point to point
solution &nbsp;will cause significant congestion on &nbsp;the network and a
broadcast/multicast solution must be used to effectively &nbsp;deliver alert
messages. Thus things like location and ��priority�� are already &nbsp;handled in
the delivery network.<br>
&nbsp;<br>
ATIS and 3GPP will be studying &nbsp;how to support multimedia alerts in the
future, as recommended by the FCC &nbsp;CMSAAC. This is all beyond the scope of
this work &nbsp;effort.<br>
&nbsp;<br>
Regards,<br>
Brian<br>
&nbsp;<br>
</span><span lang=EN-US style='font-size:10.0pt;font-family:Consolas'>Date:
Thu, 25 Mar 2010 03:13:24 +0100<br>
From: &nbsp;&quot;DRAGE, Keith (Keith)&quot; &lt;<a
href="[email-masked]">[email-masked]</a>&gt;<br>
Subject: &nbsp;Re: [earlywarning] Updated Charter Text for ATOCA<br>
To: Hannes Tschofenig &nbsp;&lt;<a href="[email-masked]">[email-masked]</a>&gt;,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&quot;<a href="[email-masked]">[email-masked]</a>&quot;
&lt;<a href="[email-masked]">[email-masked]</a>&gt;<br>
Message-ID:<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;<a
href="[email-masked]">[email-masked]</a>&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
Content-Type: &nbsp;text/plain; charset=&quot;us-ascii&quot;<br>
&nbsp;<br>
What I am not seeing here is any &nbsp;separation of the problem from the one
that cell broadcast attempts to &nbsp;solve. Fundamentally, cell broadcast, as
exists on all GSM, UTRAN and &nbsp;E-UTRAN based cell phones and is being used
for Tsunami warning and Public &nbsp;Warning, exists and is not going to
substantially change. The major &nbsp;limitation here is is length of message,
and what does get transmitted will &nbsp;be very much dependent on that
restriction.<br>
&nbsp;<br>
Moreover I have &nbsp;heard from a number of governmental bodies that they are
happy with that &nbsp;situation and are not envisaging further standardisation
in that area &nbsp;outside of 3GPP.<br>
&nbsp;<br>
So my view at the moment is that there is no &nbsp;point in IETF trying to
address the scope of what is already specified in &nbsp;cell broadcast (from base
station to end &nbsp;mobile).<br>
&nbsp;<br>
regards<br>
&nbsp;<br>
Keith<br>
</span><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><br>
&nbsp;&nbsp;&nbsp; </span><span lang=EN-US><o:p></o:p></span></p>

<p align=center style='text-align:center'><span lang=EN-US style='font-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<div class=MsoNormal align=center style='text-align:center'><span lang=EN-US
style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>

<hr size=3 width="95%" align=center>

</span></div>

<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>&nbsp;
</span><span lang=EN-US><o:p></o:p></span></p>

<p style='margin-bottom:12.0pt'><span lang=EN-US style='font-size:11.0pt;
font-family:"Calibri","sans-serif"'><br>
</span><span lang=EN-US style='font-size:10.0pt;font-family:Consolas'>_______________________________________________<br>
earlywarning &nbsp;mailing list<br>
<a href="[email-masked]">[email-masked]</a><br>
<a href="https://www.ietf.org/mailman/listinfo/earlywarning">https://www.ietf.org/mailman/listinfo/earlywarning</a></span><span
lang=EN-US><o:p></o:p></span></p>

<p class=MsoNormal><span lang=EN-US><o:p>&nbsp;</o:p></span></p>

</div>

</body>

</html>

--Boundary_(ID_WTiRfwBD0I0b3ee585L3Vw)--

From: Art Botterell <[email-masked]>
Date: Thu, 25 Mar 2010 19:01:28 -0700
To: [email-masked]
Subject: Re: [earlywarning] (no subject)

On Mar 25, 2010, at 3/25/10 6:52 PM, Winterbottom, James wrote:
> That is a nice function.
> If the device is using both mechanisms though, because it has both access technologies won't it still receive both messages, even if it only reports the first one to the user of the device?

That frequently happens in mesh systems like (on its better days) the U.S. broadcast Emergency Alert System (EAS), especially in areas where it's well integrated with the federal Weather Radio network.  One can think of it as a long-interval form of multipath.  

Which is arguably a good thing from a reliability point of view.  Perhaps a bit inefficient, but then, efficiency is frequently the enemy of resilience.

- Art

>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]
>> On Behalf Of Art Botterell
>> Sent: Friday, 26 March 2010 12:50 PM
>> To: [email-masked]
>> Subject: Re: [earlywarning] (no subject)
>> 
>> On Mar 25, 2010, at 3/25/10 6:40 PM, Winterbottom, James wrote:
>>> ...it is quite possible that alerts could be received by either or both
>> means at the same time.
>> 
>> FWIW that problem already arises in a variety of transport domains, so CAP
>> addresses it at the application level.  Alerts have unique identifiers for
>> that purpose, and also to allow the mapping of subsequent update and
>> cancellation messages.
>> 
>> - Art
>> 

From: "Winterbottom, James" <[email-masked]>
To: Art Botterell <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 26 Mar 2010 09:52:12 +0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [earlywarning] (no subject)

That is a nice function.
If the device is using both mechanisms though, because it has both access technologies won't it still receive both messages, even if it only reports the first one to the user of the device?

Cheers
James

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Art Botterell
> Sent: Friday, 26 March 2010 12:50 PM
> To: [email-masked]
> Subject: Re: [earlywarning] (no subject)
> 
> On Mar 25, 2010, at 3/25/10 6:40 PM, Winterbottom, James wrote:
> > ...it is quite possible that alerts could be received by either or both
> means at the same time.
> 
> FWIW that problem already arises in a variety of transport domains, so CAP
> addresses it at the application level.  Alerts have unique identifiers for
> that purpose, and also to allow the mapping of subsequent update and
> cancellation messages.
> 
> - Art
> 
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

From: Art Botterell <[email-masked]>
Date: Thu, 25 Mar 2010 18:49:46 -0700
To: [email-masked]
Subject: Re: [earlywarning] (no subject)

On Mar 25, 2010, at 3/25/10 6:40 PM, Winterbottom, James wrote:
> ...it is quite possible that alerts could be received by either or both means at the same time.

FWIW that problem already arises in a variety of transport domains, so CAP addresses it at the application level.  Alerts have unique identifiers for that purpose, and also to allow the mapping of subsequent update and cancellation messages.

- Art

From: "Winterbottom, James" <[email-masked]>
To: "DALY, BRIAN K (ATTCINW)" <[email-masked]>, "[email-masked]" <[email-masked]>, "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 26 Mar 2010 09:40:05 +0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [earlywarning] (no subject)

--_000_5A55A45AE77F5941B18E5457ECAC81880120DFB13541SISPE7MB1co_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I would like to qualify your statement a little more.
Devices directly connected to 3/4G networks MAY receive alerts via..., and so this work MAY not apply to them.
Devices connected to networks that use 3/4G backhaul to connected to the Internet are expected to follow this work.

This is required Brian because there are also a heck of a lot multi-mode devices out there that can be connected to both WiFi and 3G at the same time, so it is quite possible that alerts could be received by either or both means at the same time.

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of DALY, BRIAN K (ATTCINW)
Sent: Friday, 26 March 2010 12:31 PM
To: Winterbottom, James; [email-masked]; SENNETT, DEWAYNE A (ATTCINW); [email-masked]; [email-masked]
Subject: Re: [earlywarning] (no subject)

We need to recognize that devices connected to 3G networks will receive alerts via PWS/CMAS and this work is not applicable to those devices, and may result in degrading the "layer 2" networks. This needs to be part of the charter. That is the proposed modification.

Brian
Brian K. Daly
-------
Sent from my Blackberry

________________________________
From: Winterbottom, James <[email-masked]>
To: DALY, BRIAN K (ATTCINW); [email-masked] <[email-masked]>; SENNETT, DEWAYNE A (ATTCINW); [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Sent: Thu Mar 25 18:25:00 2010
Subject: RE: [earlywarning] (no subject)
I am not so sure that we can just 802.11 and be done with it.
We also have a lot of broadband deployments out there that still run PPP over ATM, where an 802.11 solution is not going to work.
My preference would be to see a solution that works regardless of how the device is connected to the Internet.

Cheers
James

________________________________
From: DALY, BRIAN K (ATTCINW) [mailto:[email-masked]]
Sent: Friday, 26 March 2010 12:21 PM
To: Winterbottom, James; [email-masked]; SENNETT, DEWAYNE A (ATTCINW); [email-masked]; [email-masked]
Subject: Re: [earlywarning] (no subject)

James

Good point and I think this is an area for discussion along with the dot11 issue. I see these as part of the work that this effort should evaluate.

This is different from where the end device obtains service directly from the 3GPP network.

Brian
Brian K. Daly
-------
Sent from my Blackberry

________________________________
From: Winterbottom, James <[email-masked]>
To: DALY, BRIAN K (ATTCINW); [email-masked] <[email-masked]>; SENNETT, DEWAYNE A (ATTCINW); [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Sent: Thu Mar 25 18:14:35 2010
Subject: RE: [earlywarning] (no subject)
Brian D,

We are increasingly seeing 3G hotspot devices, aka MiFi type devices. In this mode the devices using 3G as a backhaul are connected to the Internet and almost certainly do not have access to the underlying IMS services. Any solution needs to work in that environment too. I am interested to hear what you are proposing here.

Cheers
James

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of DALY, BRIAN K (ATTCINW)
Sent: Friday, 26 March 2010 12:07 PM
To: [email-masked]; SENNETT, DEWAYNE A (ATTCINW); [email-masked]; [email-masked]
Subject: Re: [earlywarning] (no subject)

This is NOT silly Brian but serious when you consider the consequences to the networks.

We have a solution in place for devices connected to a 3GPP network - we are asking that this work exclude devices that support 3GPP PWS/CMAS (EPC and IMS) as those solutions as designed and optimized for the "layer 2" networks. We even have mobile device behavior specifications.

I propose we adopt the language in the charter.

Brian
Brian K. Daly
-------
Sent from my Blackberry

________________________________
From: Brian Rosen <[email-masked]>
To: SENNETT, DEWAYNE A (ATTCINW); DALY, BRIAN K (ATTCINW); [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Sent: Thu Mar 25 17:59:21 2010
Subject: Re: [earlywarning] (no subject)
I think this is silly.

No one is working on alert mechanisms that apply to the Internet.

The Internet is global, ubiquitous and independent of L2.  The proposed work applies to any kind of device connected to the Internet.  Whatever scale problems exist apply to all L2s one way or another.  They must be faced and solved for the work to be useful.  To exclude wireless IMS systems based on the notion that someone else is working on a system limited to cell broadcast is, in my opinion, not a good idea.

I do well understand that vendors and carriers don't like multiple answers to the same problem.  I get that.  However, the IETF is the proper place to do work on alerts on the Internet, and should not exclude parts of the Internet.

Brian

On 3/25/10 8:50 PM, "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]> wrote:
I propose that the following sentence be added to the ATOCA charter:

The ATOCA RFC's are not applicable to wireless devices which receive their connectivity via 3GPP EPC/IMS.

<--------------------------->
DeWayne Sennett, AT&T Services, Inc.
Sent from my BlackBerry
________________________________
From: [email-masked] <[email-masked]>
To: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Sent: Thu Mar 25 17:43:10 2010
Subject: Re: [earlywarning] (no subject)

Keith

You bring up a good point - we don't want to design a solution that will result in failure of the network, therefore I second DeWayne's proposal to exclude from the charter devices that support PWS (and CMAS under that umbrella) and to acknowledge this solution may result in network problems (e.g. Congestion).

Brian Daly
Brian K. Daly
-------
Sent from my Blackberry
________________________________
From: DRAGE, Keith (Keith) <[email-masked]>
To: Brian Rosen <[email-masked]>; DALY, BRIAN K (ATTCINW); [email-masked] <[email-masked]>
Sent: Thu Mar 25 17:35:30 2010
Subject: RE: [earlywarning] (no subject)

Yes those cellphones could well be connected to the internet.

But cell broadcast service exists on 3GPP phones. For alerts that are intended to hit a large proportion of the phones in any cell, it makes best use of the bandwidth.

You bring up an IP connection to all cellphones in that cell, and then broadcast warnings to all those cells, and the net result will be inappropriate loading of cells specifically for this traffic. Given that such warnings may otherwise create network stress as a result of the public warning being made in the first place, the first point of call for getting such warnings to cellphone uses has to be cell broadcast.

It appears that many governmental organisations have accepted cell broadcast as the desired means of delivering public warnings to cellphones.

Therefore any IETF activity has to acknowledge that solution exists for cellphones.

Further I believe that any IETF solution has to specifically NOT convey the impression that for cellphones, the IETF solution is a good way forward for the warning itself. Users could well find the warnings from the IETF solution to an IP endpoint delivered well after the cell broadcast warning. And certainly the IETF solution should not expect priority over other types of traffic at that point, because at cell broadcast channel already exists to give that priority for the appropriate type of traffic.

regards

Keith

________________________________
From: [email-masked]  [mailto:[email-masked]] On Behalf Of Brian  Rosen
Sent: Friday, March 26, 2010 12:00 AM
To: DALY,  BRIAN K (ATTCINW); [email-masked]
Subject: Re: [earlywarning]  (no subject)

Are they connected to the Internet?

If they  are, it would apply.  If they aren't, then it wouldn't  apply.

Brian

On 3/25/10 7:51 PM, "DALY, BRIAN K (ATTCINW)"  <[email-masked]>  wrote:

That will not apply to devices  connected to wireless cellular  networks.

From: Brian Rosen [mailto:[email-masked]]
Sent: Thursday, March 25, 2010 4:50 PM
To: DALY, BRIAN  K (ATTCINW); [email-masked]
Subject:  Re: [earlywarning] (no subject)

Once  again, this is NOT about a solution limited to wireless cellular networks.   It is about a solution for internet connected endpoints of all kinds.

Brian

On 3/25/10 7:46 PM, "DALY, BRIAN K (ATTCINW)"  <[email-masked]> wrote:
Keith - We  agree with you, and to further the point, in wireless cellular IP networks a  point to point solution would be problematic. Cell Broadcast is used for  CMAS because SMS cannot be used for any real time alerting - it was not  designed for that application and has serious limitations, as the FCC CMSAAC  studied.

When it comes to the evolved packet core and IMS,  again a point to point solution  will cause significant congestion on  the network and a broadcast/multicast solution must be used to effectively  deliver alert messages. Thus things like location and "priority" are already  handled in the delivery network.

ATIS and 3GPP will be studying  how to support multimedia alerts in the future, as recommended by the FCC  CMSAAC. This is all beyond the scope of this work  effort.

Regards,
Brian

Date: Thu, 25 Mar 2010 03:13:24 +0100
From:  "DRAGE, Keith (Keith)" <[email-masked]>
Subject:  Re: [earlywarning] Updated Charter Text for ATOCA
To: Hannes Tschofenig  <[email-masked]>,
      "[email-masked]" <[email-masked]>
Message-ID:
      <[email-masked]>

Content-Type:  text/plain; charset="us-ascii"

What I am not seeing here is any  separation of the problem from the one that cell broadcast attempts to  solve. Fundamentally, cell broadcast, as exists on all GSM, UTRAN and  E-UTRAN based cell phones and is being used for Tsunami warning and Public  Warning, exists and is not going to substantially change. The major  limitation here is is length of message, and what does get transmitted will  be very much dependent on that restriction.

Moreover I have  heard from a number of governmental bodies that they are happy with that  situation and are not envisaging further standardisation in that area  outside of 3GPP.

So my view at the moment is that there is no  point in IETF trying to address the scope of what is already specified in  cell broadcast (from base station to end  mobile).

regards

Keith

________________________________

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

--_000_5A55A45AE77F5941B18E5457ECAC81880120DFB13541SISPE7MB1co_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:st1="urn:schemas-microsoft-com:office:smarttags" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>Re: [earlywarning] (no subject)</title>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
 name="PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
p.MsoList, li.MsoList, div.MsoList
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:14.15pt;
	margin-bottom:.0001pt;
	text-indent:-14.15pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman";}
p.Reference, li.Reference, div.Reference
	{margin-top:6.0pt;
	margin-right:0cm;
	margin-bottom:6.0pt;
	margin-left:36.85pt;
	text-indent:-19.0pt;
	mso-list:l0 level1 lfo3;
	font-size:12.0pt;
	font-family:"Times New Roman";}
p.reference0, li.reference0, div.reference0
	{margin-top:6.0pt;
	margin-right:0cm;
	margin-bottom:6.0pt;
	margin-left:36.85pt;
	text-indent:-19.0pt;
	mso-list:l0 level1 lfo5;
	font-size:12.0pt;
	font-family:"Times New Roman";}
p.reference00, li.reference00, div.reference00
	{margin-top:6.0pt;
	margin-right:0cm;
	margin-bottom:6.0pt;
	margin-left:36.85pt;
	text-indent:-19.0pt;
	mso-list:l0 level1 lfo6;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle22
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle23
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle24
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:891500023;
	mso-list-type:hybrid;
	mso-list-template-ids:172770280 1392555560 201916441 201916443 201916431 201916441 201916443 201916431 201916441 201916443;}
@list l0:level1
	{mso-level-style-link:Reference;
	mso-level-text:"\[%1\]";
	mso-level-tab-stop:36.85pt;
	mso-level-number-position:left;
	margin-left:36.85pt;
	text-indent:-19.0pt;}
@list l0:level2
	{mso-level-tab-stop:72.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level3
	{mso-level-tab-stop:108.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level4
	{mso-level-tab-stop:144.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level5
	{mso-level-tab-stop:180.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level6
	{mso-level-tab-stop:216.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level7
	{mso-level-tab-stop:252.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level8
	{mso-level-tab-stop:288.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level9
	{mso-level-tab-stop:324.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-AU link=blue vlink=blue>

<div class=Section1>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>I would like to qualify your statement a
little more.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Devices directly connected to 3/4G
networks MAY receive alerts via..., and so this work MAY not apply to them.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Devices connected to networks that use
3/4G backhaul to connected to the Internet are expected to follow this work. <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>This is required Brian because there are
also a heck of a lot multi-mode devices out there that can be connected to both
WiFi and 3G at the same time, so it is quite possible that alerts could be
received by either or both means at the same time.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'>

<div>

<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span lang=EN-US style='font-size:12.0pt'>

<hr size=2 width="100%" align=center tabindex=-1>

</span></font></div>

<p class=MsoNormal><b><font size=2 face=Tahoma><span lang=EN-US
style='font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</span></font></b><font
size=2 face=Tahoma><span lang=EN-US style='font-size:10.0pt;font-family:Tahoma'>
[email-masked] [mailto:[email-masked]] <b><span
style='font-weight:bold'>On Behalf Of </span></b>DALY, BRIAN K (ATTCINW)<br>
<b><span style='font-weight:bold'>Sent:</span></b> Friday, 26 March 2010 12:31
PM<br>
<b><span style='font-weight:bold'>To:</span></b> <st1:PersonName w:st="on">Winterbottom,
 James</st1:PersonName>; [email-masked]; SENNETT, DEWAYNE A (ATTCINW);
[email-masked]; [email-masked]<br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: [earlywarning] (no
subject)</span></font><span lang=EN-US><o:p></o:p></span></p>

</div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>We need to recognize that devices
connected to 3G networks will receive alerts via PWS/CMAS and this work is not
applicable to those devices, and may result in degrading the &quot;layer
2&quot; networks. This needs to be part of the charter. That is the proposed
modification.<br>
<br>
Brian<br>
Brian K. Daly<br>
-------<br>
Sent from my Blackberry</span></font><o:p></o:p></p>

</div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>

<hr size=2 width="100%" align=center tabindex=-1>

</span></font></div>

<p class=MsoNormal style='margin-bottom:12.0pt'><b><font size=2 face=Tahoma><span
style='font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From</span></font></b><font
size=2 face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'>: <st1:PersonName
w:st="on">Winterbottom, James</st1:PersonName>
&lt;[email-masked]&gt;<br>
<b><span style='font-weight:bold'>To</span></b>: DALY, BRIAN K (ATTCINW);
[email-masked] &lt;[email-masked]&gt;; SENNETT, DEWAYNE A (ATTCINW);
[email-masked] &lt;[email-masked]&gt;;
[email-masked] &lt;[email-masked]&gt;<br>
<b><span style='font-weight:bold'>Sent</span></b>: Thu Mar 25 18:25:00 2010<br>
<b><span style='font-weight:bold'>Subject</span></b>: RE: [earlywarning] (no
subject)</span></font><o:p></o:p></p>

</div>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>I am not so sure that we can just 802.11
and be done with it.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>We also have a lot of broadband deployments
out there that still run PPP over ATM, where an 802.11 solution is not going to
work.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>My preference would be to see a solution
that works regardless of how the device is connected to the Internet.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Cheers<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>James<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=MsoNormal><font size=3 color=navy face="Times New Roman"><span
style='font-size:12.0pt;color:navy'>&nbsp;</span></font><o:p></o:p></p>

</div>

<div style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'>

<div>

<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span lang=EN-US style='font-size:12.0pt'>

<hr size=2 width="100%" align=center tabindex=-1>

</span></font></div>

<p class=MsoNormal><b><font size=2 face=Tahoma><span lang=EN-US
style='font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</span></font></b><font
size=2 face=Tahoma><span lang=EN-US style='font-size:10.0pt;font-family:Tahoma'>
DALY, BRIAN K (ATTCINW) [mailto:[email-masked]] <br>
<b><span style='font-weight:bold'>Sent:</span></b> Friday, 26 March 2010 12:21
PM<br>
<b><span style='font-weight:bold'>To:</span></b> <st1:PersonName w:st="on">Winterbottom,
 James</st1:PersonName>; [email-masked]; SENNETT, DEWAYNE A (ATTCINW);
[email-masked]; [email-masked]<br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: [earlywarning] (no
subject)</span></font><span lang=EN-US><o:p></o:p></span></p>

</div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>James<br>
<br>
Good point and I think this is an area for discussion along with the dot11
issue. I see these as part of the work that this effort should evaluate.<br>
<br>
This is different from where the end device obtains service directly from the
3GPP network.<br>
<br>
Brian<br>
Brian K. Daly<br>
-------<br>
Sent from my Blackberry</span></font><o:p></o:p></p>

</div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>

<hr size=2 width="100%" align=center tabindex=-1>

</span></font></div>

<p class=MsoNormal style='margin-bottom:12.0pt'><b><font size=2 face=Tahoma><span
style='font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From</span></font></b><font
size=2 face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'>: <st1:PersonName
w:st="on">Winterbottom, James</st1:PersonName>
&lt;[email-masked]&gt;<br>
<b><span style='font-weight:bold'>To</span></b>: DALY, BRIAN K (ATTCINW);
[email-masked] &lt;[email-masked]&gt;; SENNETT, DEWAYNE A (ATTCINW);
[email-masked] &lt;[email-masked]&gt;;
[email-masked] &lt;[email-masked]&gt;<br>
<b><span style='font-weight:bold'>Sent</span></b>: Thu Mar 25 18:14:35 2010<br>
<b><span style='font-weight:bold'>Subject</span></b>: RE: [earlywarning] (no
subject)</span></font><o:p></o:p></p>

</div>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Brian D,<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>We are increasingly seeing 3G hotspot devices,
aka MiFi type devices. In this mode the devices using 3G as a backhaul are
connected to the Internet and almost certainly do not have access to the
underlying IMS services. Any solution needs to work in that environment too. I
am interested to hear what you are proposing here.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Cheers<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>James<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=MsoNormal><font size=3 color=navy face="Times New Roman"><span
style='font-size:12.0pt;color:navy'>&nbsp;</span></font><o:p></o:p></p>

</div>

<div style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'>

<div>

<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span lang=EN-US style='font-size:12.0pt'>

<hr size=2 width="100%" align=center tabindex=-1>

</span></font></div>

<p class=MsoNormal><b><font size=2 face=Tahoma><span lang=EN-US
style='font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</span></font></b><font
size=2 face=Tahoma><span lang=EN-US style='font-size:10.0pt;font-family:Tahoma'>
[email-masked] [mailto:[email-masked]] <b><span
style='font-weight:bold'>On Behalf Of </span></b>DALY, BRIAN K (ATTCINW)<br>
<b><span style='font-weight:bold'>Sent:</span></b> Friday, 26 March 2010 12:07
PM<br>
<b><span style='font-weight:bold'>To:</span></b> [email-masked]; SENNETT,
DEWAYNE A (ATTCINW); [email-masked]; [email-masked]<br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: [earlywarning] (no
subject)</span></font><span lang=EN-US><o:p></o:p></span></p>

</div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>This is NOT silly Brian but serious when
you consider the consequences to the networks.<br>
<br>
We have a solution in place for devices connected to a 3GPP network - we are
asking that this work exclude devices that support 3GPP PWS/CMAS (EPC and IMS)
as those solutions as designed and optimized for the &quot;layer 2&quot;
networks. We even have mobile device behavior specifications.<br>
<br>
I propose we adopt the language in the charter.<br>
<br>
Brian<br>
Brian K. Daly<br>
-------<br>
Sent from my Blackberry</span></font><o:p></o:p></p>

</div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>

<hr size=2 width="100%" align=center tabindex=-1>

</span></font></div>

<p class=MsoNormal style='margin-bottom:12.0pt'><b><font size=2 face=Tahoma><span
style='font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From</span></font></b><font
size=2 face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'>: <st1:PersonName
w:st="on">Brian Rosen</st1:PersonName> &lt;[email-masked]&gt;<br>
<b><span style='font-weight:bold'>To</span></b>: SENNETT, DEWAYNE A (ATTCINW);
DALY, BRIAN K (ATTCINW); [email-masked]
&lt;[email-masked]&gt;; [email-masked]
&lt;[email-masked]&gt;<br>
<b><span style='font-weight:bold'>Sent</span></b>: Thu Mar 25 17:59:21 2010<br>
<b><span style='font-weight:bold'>Subject</span></b>: Re: [earlywarning] (no
subject)</span></font><o:p></o:p></p>

</div>

<p class=MsoNormal style='margin-bottom:12.0pt'><font size=2 face=Calibri><span
style='font-size:11.0pt;font-family:Calibri'>I think this is silly.<br>
<br>
No one is working on alert mechanisms that apply to the Internet.<br>
<br>
The Internet is global, ubiquitous and independent of L2. &nbsp;The proposed
work applies to any kind of device connected to the Internet. &nbsp;Whatever
scale problems exist apply to all L2s one way or another. &nbsp;They must be
faced and solved for the work to be useful. &nbsp;To exclude wireless IMS
systems based on the notion that someone else is working on a system limited to
cell broadcast is, in my opinion, not a good idea.<br>
<br>
I do well understand that vendors and carriers don&#8217;t like multiple answers to
the same problem. &nbsp;I get that. &nbsp;However, the IETF is the proper place
to do work on alerts on the Internet, and should not exclude parts of the
Internet.<br>
<br>
Brian<br>
<br>
<br>
On 3/25/10 8:50 PM, &quot;SENNETT, DEWAYNE A (ATTCINW)&quot; &lt;<a
href="[email-masked]">[email-masked]</a>&gt; wrote:</span></font><o:p></o:p></p>

<p class=MsoNormal style='margin-bottom:12.0pt'><font size=2 color=navy
face=Arial><span style='font-size:11.0pt;font-family:Arial;color:navy'>I
propose that the following sentence be added to the ATOCA charter:<br>
<br>
The ATOCA RFC's are not applicable to wireless devices which receive their
connectivity via 3GPP EPC/IMS.<br>
<br>
<br>
<br>
&lt;---------------------------&gt; <br>
DeWayne Sennett, AT&amp;T Services, Inc. <br>
Sent from my BlackBerry</span></font><font size=2 face=Calibri><span
style='font-size:11.0pt;font-family:Calibri'><o:p></o:p></span></font></p>

<div class=MsoNormal align=center style='text-align:center'><font size=2
face=Calibri><span style='font-size:11.0pt;font-family:Calibri'>

<hr size=2 width="100%" align=center>

</span></font></div>

<p class=MsoNormal style='margin-bottom:12.0pt'><b><font size=2 face=Tahoma><span
style='font-size:11.0pt;font-family:Tahoma;font-weight:bold'>From</span></font></b><font
size=2 face=Tahoma><span style='font-size:11.0pt;font-family:Tahoma'>: <a
href="[email-masked]">[email-masked]</a> &lt;<a
href="[email-masked]">[email-masked]</a>&gt; <br>
<b><span style='font-weight:bold'>To</span></b>: <a
href="[email-masked]">[email-masked]</a> &lt;<a
href="[email-masked]">[email-masked]</a>&gt;; <a
href="[email-masked]">[email-masked]</a> &lt;<a href="[email-masked]">[email-masked]</a>&gt;;
<a href="[email-masked]">[email-masked]</a> &lt;<a
href="[email-masked]">[email-masked]</a>&gt; <br>
<b><span style='font-weight:bold'>Sent</span></b>: Thu Mar 25 17:43:10 2010<br>
<b><span style='font-weight:bold'>Subject</span></b>: Re: [earlywarning] (no
subject) <br>
</span></font><font size=2 face=Calibri><span style='font-size:11.0pt;
font-family:Calibri'><br>
</span></font><font size=2 color=navy face=Arial><span style='font-size:11.0pt;
font-family:Arial;color:navy'>Keith<br>
<br>
You bring up a good point - we don't want to design a solution that will result
in failure of the network, therefore I second DeWayne's proposal to exclude
from the charter devices that support PWS (and CMAS under that umbrella) and to
acknowledge this solution may result in network problems (e.g. Congestion).<br>
<br>
Brian Daly <br>
Brian K. Daly <br>
------- <br>
Sent from my Blackberry</span></font><font size=2 face=Calibri><span
style='font-size:11.0pt;font-family:Calibri'><o:p></o:p></span></font></p>

<div class=MsoNormal align=center style='text-align:center'><font size=2
face=Calibri><span style='font-size:11.0pt;font-family:Calibri'>

<hr size=2 width="100%" align=center>

</span></font></div>

<p class=MsoNormal style='margin-bottom:12.0pt'><b><font size=2 face=Tahoma><span
style='font-size:11.0pt;font-family:Tahoma;font-weight:bold'>From</span></font></b><font
size=2 face=Tahoma><span style='font-size:11.0pt;font-family:Tahoma'>: DRAGE,
Keith (Keith) &lt;<a href="[email-masked]">[email-masked]</a>&gt;
<br>
<b><span style='font-weight:bold'>To</span></b>: <st1:PersonName w:st="on">Brian
 Rosen</st1:PersonName> &lt;<a href="[email-masked]">[email-masked]</a>&gt;;
DALY, BRIAN K (ATTCINW); <a href="[email-masked]">[email-masked]</a>
&lt;<a href="[email-masked]">[email-masked]</a>&gt; <br>
<b><span style='font-weight:bold'>Sent</span></b>: Thu Mar 25 17:35:30 2010<br>
<b><span style='font-weight:bold'>Subject</span></b>: RE: [earlywarning] (no
subject) <br>
</span></font><font size=2 face=Calibri><span style='font-size:11.0pt;
font-family:Calibri'><br>
</span></font><font size=2 color=blue face=Arial><span style='font-size:11.0pt;
font-family:Arial;color:blue'>Yes those cellphones could well be connected to
the internet.<br>
</span></font><font size=2 face=Calibri><span style='font-size:11.0pt;
font-family:Calibri'><br>
</span></font><font size=2 color=blue face=Arial><span style='font-size:11.0pt;
font-family:Arial;color:blue'>But cell broadcast service exists on 3GPP phones.
For alerts that are intended to hit a large proportion of the phones in any
cell, it makes best use of the bandwidth.<br>
</span></font><font size=2 face=Calibri><span style='font-size:11.0pt;
font-family:Calibri'><br>
</span></font><font size=2 color=blue face=Arial><span style='font-size:11.0pt;
font-family:Arial;color:blue'>You bring up an IP connection to all cellphones
in that cell, and then broadcast warnings to all those cells, and the net
result will be inappropriate loading of cells specifically for this traffic.
Given that such warnings may otherwise create network stress as a result of the
public warning being made in the first place, the first point of call for
getting such warnings to cellphone uses has to be cell broadcast.<br>
</span></font><font size=2 face=Calibri><span style='font-size:11.0pt;
font-family:Calibri'><br>
</span></font><font size=2 color=blue face=Arial><span style='font-size:11.0pt;
font-family:Arial;color:blue'>It appears that many governmental organisations
have accepted cell broadcast as the desired means of delivering public warnings
to cellphones.<br>
</span></font><font size=2 face=Calibri><span style='font-size:11.0pt;
font-family:Calibri'><br>
</span></font><font size=2 color=blue face=Arial><span style='font-size:11.0pt;
font-family:Arial;color:blue'>Therefore any IETF activity has to acknowledge
that solution exists for cellphones. <br>
</span></font><font size=2 face=Calibri><span style='font-size:11.0pt;
font-family:Calibri'><br>
</span></font><font size=2 color=blue face=Arial><span style='font-size:11.0pt;
font-family:Arial;color:blue'>Further I believe that any IETF solution has to
specifically NOT convey the impression that for cellphones, the IETF solution
is a good way forward for the warning itself. Users could well find the
warnings from the IETF solution to an IP endpoint delivered well after the cell
broadcast warning. And certainly the IETF solution should not expect priority
over other types of traffic at that point, because at cell broadcast channel
already exists to give that priority for the appropriate type of traffic.<br>
</span></font><font size=2 face=Calibri><span style='font-size:11.0pt;
font-family:Calibri'><br>
</span></font><font size=2 color=blue face=Arial><span style='font-size:11.0pt;
font-family:Arial;color:blue'>regards<br>
</span></font><font size=2 face=Calibri><span style='font-size:11.0pt;
font-family:Calibri'><br>
</span></font><font size=2 color=blue face=Arial><span style='font-size:11.0pt;
font-family:Arial;color:blue'>Keith</span></font><o:p></o:p></p>

<p class=MsoNormal><font size=2 face=Calibri><span style='font-size:11.0pt;
font-family:Calibri'><br>
&nbsp;<o:p></o:p></span></font></p>

<div class=MsoNormal align=center style='text-align:center'><font size=2
face=Calibri><span style='font-size:11.0pt;font-family:Calibri'>

<hr size=3 width="100%" align=center>

</span></font></div>

<p class=MsoNormal><b><font size=2 face=Tahoma><span style='font-size:11.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=2
face=Tahoma><span style='font-size:11.0pt;font-family:Tahoma'> <a
href="[email-masked]">[email-masked]</a> &nbsp;[<a
href="mailto:[email-masked]">mailto:[email-masked]</a>]
<b><span style='font-weight:bold'>On Behalf Of </span></b>Brian &nbsp;Rosen<br>
<b><span style='font-weight:bold'>Sent:</span></b> Friday, March 26, 2010 12:00
AM<br>
<b><span style='font-weight:bold'>To:</span></b> DALY, &nbsp;BRIAN K (ATTCINW);
<a href="[email-masked]">[email-masked]</a><br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: [earlywarning]
&nbsp;(no subject)<br>
</span></font><font size=2 face=Calibri><span style='font-size:11.0pt;
font-family:Calibri'><br>
&nbsp;<br>
Are they connected to the Internet?<br>
<br>
If they &nbsp;are, it would apply. &nbsp;If they aren&#8217;t, then it wouldn&#8217;t
&nbsp;apply.<br>
<br>
Brian<br>
<br>
<br>
On 3/25/10 7:51 PM, &quot;DALY, BRIAN K (ATTCINW)&quot; &nbsp;&lt;<a
href="[email-masked]">[email-masked]</a>&gt; &nbsp;wrote:<br>
<br>
&nbsp;</span></font><o:p></o:p></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>That will not apply
to devices &nbsp;connected to wireless cellular &nbsp;networks.<br>
&nbsp;<br>
</span></font><font size=2 face=Calibri><span style='font-size:11.0pt;
font-family:Calibri'><br>
</span></font><b><font size=2 face=Tahoma><span style='font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=2
face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'> <st1:PersonName
w:st="on">Brian Rosen</st1:PersonName> [<a href="mailto:[email-masked]">mailto:[email-masked]</a>]
&nbsp;<br>
<b><span style='font-weight:bold'>Sent:</span></b> Thursday, March 25, 2010 4:50
PM<br>
<b><span style='font-weight:bold'>To:</span></b> DALY, BRIAN &nbsp;K (ATTCINW);
<a href="[email-masked]">[email-masked]</a><br>
<b><span style='font-weight:bold'>Subject:</span></b> &nbsp;Re: [earlywarning]
(no subject)<br>
</span></font><br>
<font size=2 face=Calibri><span style='font-size:11.0pt;font-family:Calibri'>Once
&nbsp;again, this is NOT about a solution limited to wireless cellular
networks. &nbsp;&nbsp;It is about a solution for internet connected endpoints
of all kinds. &nbsp;&nbsp;<br>
<br>
Brian<br>
<br>
<br>
On 3/25/10 7:46 PM, &quot;DALY, BRIAN K (ATTCINW)&quot; &nbsp;&lt;<a
href="[email-masked]">[email-masked]</a>&gt; wrote:<br>
Keith &#8211; We &nbsp;agree with you, and to further the point, in wireless cellular
IP networks a &nbsp;point to point solution would be problematic. Cell
Broadcast is used for &nbsp;CMAS because SMS cannot be used for any real time
alerting &#8211; it was not &nbsp;designed for that application and has serious
limitations, as the FCC CMSAAC &nbsp;studied.<br>
&nbsp;<br>
When it comes to the evolved packet core and IMS, &nbsp;again a point to point
solution &nbsp;will cause significant congestion on &nbsp;the network and a
broadcast/multicast solution must be used to effectively &nbsp;deliver alert
messages. Thus things like location and &#8220;priority&#8221; are already &nbsp;handled in
the delivery network.<br>
&nbsp;<br>
ATIS and 3GPP will be studying &nbsp;how to support multimedia alerts in the
future, as recommended by the FCC &nbsp;CMSAAC. This is all beyond the scope of
this work &nbsp;effort.<br>
&nbsp;<br>
Regards,<br>
Brian<br>
&nbsp;<br>
</span></font><font size=2 face=Consolas><span style='font-size:10.0pt;
font-family:Consolas'>Date: Thu, 25 Mar 2010 03:13:24 +0100<br>
From: &nbsp;&quot;DRAGE, Keith (Keith)&quot; &lt;<a
href="[email-masked]">[email-masked]</a>&gt;<br>
Subject: &nbsp;Re: [earlywarning] Updated Charter Text for ATOCA<br>
To: <st1:PersonName w:st="on">Hannes Tschofenig</st1:PersonName> &nbsp;&lt;<a
href="[email-masked]">[email-masked]</a>&gt;,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&quot;<a href="[email-masked]">[email-masked]</a>&quot;
&lt;<a href="[email-masked]">[email-masked]</a>&gt;<br>
Message-ID:<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;<a
href="[email-masked]">[email-masked]</a>&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
Content-Type: &nbsp;text/plain; charset=&quot;us-ascii&quot;<br>
&nbsp;<br>
What I am not seeing here is any &nbsp;separation of the problem from the one
that cell broadcast attempts to &nbsp;solve. Fundamentally, cell broadcast, as
exists on all GSM, UTRAN and &nbsp;E-UTRAN based cell phones and is being used
for Tsunami warning and Public &nbsp;Warning, exists and is not going to
substantially change. The major &nbsp;limitation here is is length of message,
and what does get transmitted will &nbsp;be very much dependent on that
restriction.<br>
&nbsp;<br>
Moreover I have &nbsp;heard from a number of governmental bodies that they are
happy with that &nbsp;situation and are not envisaging further standardisation
in that area &nbsp;outside of 3GPP.<br>
&nbsp;<br>
So my view at the moment is that there is no &nbsp;point in IETF trying to
address the scope of what is already specified in &nbsp;cell broadcast (from
base station to end &nbsp;mobile).<br>
&nbsp;<br>
regards<br>
&nbsp;<br>
Keith<br>
</span></font><font size=2 face=Calibri><span style='font-size:11.0pt;
font-family:Calibri'><br>
&nbsp;&nbsp;&nbsp; </span></font><o:p></o:p></p>

<p align=center style='text-align:center'><font size=2 face=Calibri><span
style='font-size:11.0pt;font-family:Calibri'><o:p>&nbsp;</o:p></span></font></p>

<div class=MsoNormal align=center style='text-align:center'><font size=2
face=Calibri><span style='font-size:11.0pt;font-family:Calibri'>

<hr size=3 width="95%" align=center>

</span></font></div>

<p class=MsoNormal><font size=2 face=Calibri><span style='font-size:11.0pt;
font-family:Calibri'>&nbsp; </span></font><o:p></o:p></p>

<p style='margin-bottom:12.0pt'><font size=2 face=Calibri><span
style='font-size:11.0pt;font-family:Calibri'><br>
</span></font><font size=2 face=Consolas><span style='font-size:10.0pt;
font-family:Consolas'>_______________________________________________<br>
earlywarning &nbsp;mailing list<br>
<a href="[email-masked]">[email-masked]</a><br>
<a href="https://www.ietf.org/mailman/listinfo/earlywarning">https://www.ietf.org/mailman/listinfo/earlywarning</a></span></font><o:p></o:p></p>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</div>

</div>

</div>

</body>

</html>

--_000_5A55A45AE77F5941B18E5457ECAC81880120DFB13541SISPE7MB1co_--

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 25 Mar 2010 21:42:35 -0400
To: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
Cc: "SENNETT, DEWAYNE A \(ATTCINW\)" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [earlywarning] (no subject)

--Apple-Mail-10--797220255
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

May I suggest you read my comments about out-of-area notifications? For what it's worth, I disagree with your suggestion.

Henning

On Mar 25, 2010, at 9:31 PM, DALY, BRIAN K (ATTCINW) wrote:

> We need to recognize that devices connected to 3G networks will receive alerts via PWS/CMAS and this work is not applicable to those devices, and may result in degrading the "layer 2" networks. This needs to be part of the charter. That is the proposed modification.
> 
> Brian 
> Brian K. Daly 
> ------- 
> Sent from my Blackberry
> 
> From: Winterbottom, James <[email-masked]> 
> To: DALY, BRIAN K (ATTCINW); [email-masked] <[email-masked]>; SENNETT, DEWAYNE A (ATTCINW); [email-masked] <[email-masked]>; [email-masked] <[email-masked]> 
> Sent: Thu Mar 25 18:25:00 2010
> Subject: RE: [earlywarning] (no subject) 
> 
> I am not so sure that we can just 802.11 and be done with it.
> We also have a lot of broadband deployments out there that still run PPP over ATM, where an 802.11 solution is not going to work.
> My preference would be to see a solution that works regardless of how the device is connected to the Internet.
>  
> Cheers
> James
>  
>  
>  
> From: DALY, BRIAN K (ATTCINW) [mailto:[email-masked]] 
> Sent: Friday, 26 March 2010 12:21 PM
> To: Winterbottom, James; [email-masked]; SENNETT, DEWAYNE A (ATTCINW); [email-masked]; [email-masked]
> Subject: Re: [earlywarning] (no subject)
>  
> James
> 
> Good point and I think this is an area for discussion along with the dot11 issue. I see these as part of the work that this effort should evaluate.
> 
> This is different from where the end device obtains service directly from the 3GPP network.
> 
> Brian
> Brian K. Daly
> -------
> Sent from my Blackberry
>  
> From: Winterbottom, James <[email-masked]>
> To: DALY, BRIAN K (ATTCINW); [email-masked] <[email-masked]>; SENNETT, DEWAYNE A (ATTCINW); [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
> Sent: Thu Mar 25 18:14:35 2010
> Subject: RE: [earlywarning] (no subject)
> 
> Brian D,
>  
> We are increasingly seeing 3G hotspot devices, aka MiFi type devices. In this mode the devices using 3G as a backhaul are connected to the Internet and almost certainly do not have access to the underlying IMS services. Any solution needs to work in that environment too. I am interested to hear what you are proposing here.
>  
> Cheers
> James
>  
>  
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of DALY, BRIAN K (ATTCINW)
> Sent: Friday, 26 March 2010 12:07 PM
> To: [email-masked]; SENNETT, DEWAYNE A (ATTCINW); [email-masked]; [email-masked]
> Subject: Re: [earlywarning] (no subject)
>  
> This is NOT silly Brian but serious when you consider the consequences to the networks.
> 
> We have a solution in place for devices connected to a 3GPP network - we are asking that this work exclude devices that support 3GPP PWS/CMAS (EPC and IMS) as those solutions as designed and optimized for the "layer 2" networks. We even have mobile device behavior specifications.
> 
> I propose we adopt the language in the charter.
> 
> Brian
> Brian K. Daly
> -------
> Sent from my Blackberry
>  
> From: Brian Rosen <[email-masked]>
> To: SENNETT, DEWAYNE A (ATTCINW); DALY, BRIAN K (ATTCINW); [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
> Sent: Thu Mar 25 17:59:21 2010
> Subject: Re: [earlywarning] (no subject)
> 
> I think this is silly.
> 
> No one is working on alert mechanisms that apply to the Internet.
> 
> The Internet is global, ubiquitous and independent of L2.  The proposed work applies to any kind of device connected to the Internet.  Whatever scale problems exist apply to all L2s one way or another.  They must be faced and solved for the work to be useful.  To exclude wireless IMS systems based on the notion that someone else is working on a system limited to cell broadcast is, in my opinion, not a good idea.
> 
> I do well understand that vendors and carriers don�t like multiple answers to the same problem.  I get that.  However, the IETF is the proper place to do work on alerts on the Internet, and should not exclude parts of the Internet.
> 
> Brian
> 
> 
> On 3/25/10 8:50 PM, "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]> wrote:
> 
> I propose that the following sentence be added to the ATOCA charter:
> 
> The ATOCA RFC's are not applicable to wireless devices which receive their connectivity via 3GPP EPC/IMS.
> 
> 
> 
> <---------------------------> 
> DeWayne Sennett, AT&T Services, Inc. 
> Sent from my BlackBerry
> 
> From: [email-masked] <[email-masked]> 
> To: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]> 
> Sent: Thu Mar 25 17:43:10 2010
> Subject: Re: [earlywarning] (no subject) 
> 
> Keith
> 
> You bring up a good point - we don't want to design a solution that will result in failure of the network, therefore I second DeWayne's proposal to exclude from the charter devices that support PWS (and CMAS under that umbrella) and to acknowledge this solution may result in network problems (e.g. Congestion).
> 
> Brian Daly 
> Brian K. Daly 
> ------- 
> Sent from my Blackberry
> 
> From: DRAGE, Keith (Keith) <[email-masked]> 
> To: Brian Rosen <[email-masked]>; DALY, BRIAN K (ATTCINW); [email-masked] <[email-masked]> 
> Sent: Thu Mar 25 17:35:30 2010
> Subject: RE: [earlywarning] (no subject) 
> 
> Yes those cellphones could well be connected to the internet.
> 
> But cell broadcast service exists on 3GPP phones. For alerts that are intended to hit a large proportion of the phones in any cell, it makes best use of the bandwidth.
> 
> You bring up an IP connection to all cellphones in that cell, and then broadcast warnings to all those cells, and the net result will be inappropriate loading of cells specifically for this traffic. Given that such warnings may otherwise create network stress as a result of the public warning being made in the first place, the first point of call for getting such warnings to cellphone uses has to be cell broadcast.
> 
> It appears that many governmental organisations have accepted cell broadcast as the desired means of delivering public warnings to cellphones.
> 
> Therefore any IETF activity has to acknowledge that solution exists for cellphones. 
> 
> Further I believe that any IETF solution has to specifically NOT convey the impression that for cellphones, the IETF solution is a good way forward for the warning itself. Users could well find the warnings from the IETF solution to an IP endpoint delivered well after the cell broadcast warning. And certainly the IETF solution should not expect priority over other types of traffic at that point, because at cell broadcast channel already exists to give that priority for the appropriate type of traffic.
> 
> regards
> 
> Keith
> 
> 
>  
> From: [email-masked]  [mailto:[email-masked]] On Behalf Of Brian  Rosen
> Sent: Friday, March 26, 2010 12:00 AM
> To: DALY,  BRIAN K (ATTCINW); [email-masked]
> Subject: Re: [earlywarning]  (no subject)
> 
>  
> Are they connected to the Internet?
> 
> If they  are, it would apply.  If they aren�t, then it wouldn�t  apply.
> 
> Brian
> 
> 
> On 3/25/10 7:51 PM, "DALY, BRIAN K (ATTCINW)"  <[email-masked]>  wrote:
> 
>  
> That will not apply to devices  connected to wireless cellular  networks.
>  
> 
> From: Brian Rosen [mailto:[email-masked]]  
> Sent: Thursday, March 25, 2010 4:50 PM
> To: DALY, BRIAN  K (ATTCINW); [email-masked]
> Subject:  Re: [earlywarning] (no subject)
> 
> Once  again, this is NOT about a solution limited to wireless cellular networks.   It is about a solution for internet connected endpoints of all kinds.   
> 
> Brian
> 
> 
> On 3/25/10 7:46 PM, "DALY, BRIAN K (ATTCINW)"  <[email-masked]> wrote:
> Keith � We  agree with you, and to further the point, in wireless cellular IP networks a  point to point solution would be problematic. Cell Broadcast is used for  CMAS because SMS cannot be used for any real time alerting � it was not  designed for that application and has serious limitations, as the FCC CMSAAC  studied.
>  
> When it comes to the evolved packet core and IMS,  again a point to point solution  will cause significant congestion on  the network and a broadcast/multicast solution must be used to effectively  deliver alert messages. Thus things like location and �priority� are already  handled in the delivery network.
>  
> ATIS and 3GPP will be studying  how to support multimedia alerts in the future, as recommended by the FCC  CMSAAC. This is all beyond the scope of this work  effort.
>  
> Regards,
> Brian
>  
> Date: Thu, 25 Mar 2010 03:13:24 +0100
> From:  "DRAGE, Keith (Keith)" <[email-masked]>
> Subject:  Re: [earlywarning] Updated Charter Text for ATOCA
> To: Hannes Tschofenig  <[email-masked]>,
>       "[email-masked]" <[email-masked]>
> Message-ID:
>       <[email-masked]>
>       
> Content-Type:  text/plain; charset="us-ascii"
>  
> What I am not seeing here is any  separation of the problem from the one that cell broadcast attempts to  solve. Fundamentally, cell broadcast, as exists on all GSM, UTRAN and  E-UTRAN based cell phones and is being used for Tsunami warning and Public  Warning, exists and is not going to substantially change. The major  limitation here is is length of message, and what does get transmitted will  be very much dependent on that restriction.
>  
> Moreover I have  heard from a number of governmental bodies that they are happy with that  situation and are not envisaging further standardisation in that area  outside of 3GPP.
>  
> So my view at the moment is that there is no  point in IETF trying to address the scope of what is already specified in  cell broadcast (from base station to end  mobile).
>  
> regards
>  
> Keith
> 
>    
>  
> 
>  
> 
> _______________________________________________
> earlywarning  mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning
> 
>  
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

--Apple-Mail-10--797220255
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>May I suggest you read my comments about out-of-area notifications? For what it's worth, I disagree with your suggestion.</div><div><br></div><div>Henning</div><br><div><div>On Mar 25, 2010, at 9:31 PM, DALY, BRIAN K (ATTCINW) wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><o:smarttagtype namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="PersonName">
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
p.MsoList, li.MsoList, div.MsoList
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:14.15pt;
	margin-bottom:.0001pt;
	text-indent:-14.15pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman";}
p.Reference, li.Reference, div.Reference
	{margin-top:6.0pt;
	margin-right:0cm;
	margin-bottom:6.0pt;
	margin-left:36.85pt;
	text-indent:-19.0pt;
	mso-list:l0 level1 lfo3;
	font-size:12.0pt;
	font-family:"Times New Roman";}
p.reference0, li.reference0, div.reference0
	{margin-top:6.0pt;
	margin-right:0cm;
	margin-bottom:6.0pt;
	margin-left:36.85pt;
	text-indent:-19.0pt;
	mso-list:l0 level1 lfo5;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle22
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:891500023;
	mso-list-type:hybrid;
	mso-list-template-ids:172770280 1392555560 201916441 201916443 201916431 201916441 201916443 201916431 201916441 201916443;}
@list l0:level1
	{mso-level-style-link:Reference;
	mso-level-text:"\[%1\]";
	mso-level-tab-stop:36.85pt;
	mso-level-number-position:left;
	margin-left:36.85pt;
	text-indent:-19.0pt;}
@list l0:level2
	{mso-level-tab-stop:72.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level3
	{mso-level-tab-stop:108.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level4
	{mso-level-tab-stop:144.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level5
	{mso-level-tab-stop:180.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level6
	{mso-level-tab-stop:216.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level7
	{mso-level-tab-stop:252.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level8
	{mso-level-tab-stop:288.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level9
	{mso-level-tab-stop:324.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->

<div lang="EN-AU" link="blue" vlink="blue"><div><font size="2" color="navy" face="Arial">
We need to recognize that devices connected to 3G networks will receive alerts via PWS/CMAS and this work is not applicable to those devices, and may result in degrading the "layer 2" networks. This needs to be part of the charter. That is the proposed modification.<br><br>Brian
<br>Brian K. Daly
<br>-------
<br>Sent from my Blackberry</font></div>
<br><div><hr size="2" width="100%" align="center" tabindex="-1">
<font face="Tahoma" size="2">
<b>From</b>: Winterbottom, James &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;
<br><b>To</b>: DALY, BRIAN K (ATTCINW); <a href="mailto:[email-masked]">[email-masked]</a> &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;; SENNETT, DEWAYNE A (ATTCINW); <a href="mailto:[email-masked]">[email-masked]</a> &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;; <a href="mailto:[email-masked]">[email-masked]</a> &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;
<br><b>Sent</b>: Thu Mar 25 18:25:00 2010<br><b>Subject</b>: RE: [earlywarning] (no subject)
<br></font><br></div>

<div class="Section1"><p class="MsoNormal"><font size="2" color="navy" face="Arial"><span style="font-size:
10.0pt;font-family:Arial;color:navy">I am not so sure that we can just 802.11 and
be done with it.<o:p></o:p></span></font></p><p class="MsoNormal"><font size="2" color="navy" face="Arial"><span style="font-size:
10.0pt;font-family:Arial;color:navy">We also have a lot of broadband
deployments out there that still run PPP over ATM, where an 802.11 solution is
not going to work.<o:p></o:p></span></font></p><p class="MsoNormal"><font size="2" color="navy" face="Arial"><span style="font-size:
10.0pt;font-family:Arial;color:navy">My preference would be to see a solution
that works regardless of how the device is connected to the Internet.<o:p></o:p></span></font></p><p class="MsoNormal"><font size="2" color="navy" face="Arial"><span style="font-size:
10.0pt;font-family:Arial;color:navy"><o:p>&nbsp;</o:p></span></font></p><p class="MsoNormal"><font size="2" color="navy" face="Arial"><span style="font-size:
10.0pt;font-family:Arial;color:navy">Cheers<o:p></o:p></span></font></p><p class="MsoNormal"><font size="2" color="navy" face="Arial"><span style="font-size:
10.0pt;font-family:Arial;color:navy">James<o:p></o:p></span></font></p><p class="MsoNormal"><font size="2" color="navy" face="Arial"><span style="font-size:
10.0pt;font-family:Arial;color:navy"><o:p>&nbsp;</o:p></span></font></p><p class="MsoNormal"><font size="2" color="navy" face="Arial"><span style="font-size:
10.0pt;font-family:Arial;color:navy"><o:p>&nbsp;</o:p></span></font></p>

<div><p class="MsoNormal"><font size="3" color="navy" face="Times New Roman"><span style="font-size:12.0pt;color:navy">&nbsp;</span></font><o:p></o:p></p>

</div>

<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">

<div>

<div class="MsoNormal" align="center" style="text-align:center"><font size="3" face="Times New Roman"><span lang="EN-US" style="font-size:12.0pt">

<hr size="2" width="100%" align="center" tabindex="-1">

</span></font></div><p class="MsoNormal"><b><font size="2" face="Tahoma"><span lang="EN-US" style="font-size:10.0pt;font-family:Tahoma;font-weight:bold">From:</span></font></b><font size="2" face="Tahoma"><span lang="EN-US" style="font-size:10.0pt;font-family:Tahoma">
DALY, BRIAN K (ATTCINW) [mailto:[email-masked]] <br>
<b><span style="font-weight:bold">Sent:</span></b> Friday, 26 March 2010 12:21
PM<br>
<b><span style="font-weight:bold">To:</span></b> <st1:personname w:st="on">Winterbottom,
 James</st1:personname>; <a href="mailto:[email-masked]">[email-masked]</a>; SENNETT, DEWAYNE A (ATTCINW);
<a href="mailto:[email-masked]">[email-masked]</a>; <a href="mailto:[email-masked]">[email-masked]</a><br>
<b><span style="font-weight:bold">Subject:</span></b> Re: [earlywarning] (no
subject)</span></font><span lang="EN-US"><o:p></o:p></span></p>

</div><p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:
12.0pt"><o:p>&nbsp;</o:p></span></font></p>

<div><p class="MsoNormal"><font size="2" color="navy" face="Arial"><span style="font-size:
10.0pt;font-family:Arial;color:navy">James<br>
<br>
Good point and I think this is an area for discussion along with the dot11
issue. I see these as part of the work that this effort should evaluate.<br>
<br>
This is different from where the end device obtains service directly from the
3GPP network.<br>
<br>
Brian<br>
Brian K. Daly<br>
-------<br>
Sent from my Blackberry</span></font><o:p></o:p></p>

</div><p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:
12.0pt"><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class="MsoNormal" align="center" style="text-align:center"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">

<hr size="2" width="100%" align="center" tabindex="-1">

</span></font></div><p class="MsoNormal" style="margin-bottom:12.0pt"><b><font size="2" face="Tahoma"><span style="font-size:10.0pt;font-family:Tahoma;font-weight:bold">From</span></font></b><font size="2" face="Tahoma"><span style="font-size:10.0pt;font-family:Tahoma">: <st1:personname w:st="on">Winterbottom, James</st1:personname>
&lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br>
<b><span style="font-weight:bold">To</span></b>: DALY, BRIAN K (ATTCINW);
<a href="mailto:[email-masked]">[email-masked]</a> &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;; SENNETT, DEWAYNE A (ATTCINW);
<a href="mailto:[email-masked]">[email-masked]</a> &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;;
<a href="mailto:[email-masked]">[email-masked]</a> &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br>
<b><span style="font-weight:bold">Sent</span></b>: Thu Mar 25 18:14:35 2010<br>
<b><span style="font-weight:bold">Subject</span></b>: RE: [earlywarning] (no
subject)</span></font><o:p></o:p></p>

</div><p class="MsoNormal"><font size="2" color="navy" face="Arial"><span style="font-size:
10.0pt;font-family:Arial;color:navy">Brian D,<o:p></o:p></span></font></p><p class="MsoNormal"><font size="2" color="navy" face="Arial"><span style="font-size:
10.0pt;font-family:Arial;color:navy"><o:p>&nbsp;</o:p></span></font></p><p class="MsoNormal"><font size="2" color="navy" face="Arial"><span style="font-size:
10.0pt;font-family:Arial;color:navy">We are increasingly seeing 3G hotspot
devices, aka MiFi type devices. In this mode the devices using 3G as a backhaul
are connected to the Internet and almost certainly do not have access to the
underlying IMS services. Any solution needs to work in that environment too. I
am interested to hear what you are proposing here.<o:p></o:p></span></font></p><p class="MsoNormal"><font size="2" color="navy" face="Arial"><span style="font-size:
10.0pt;font-family:Arial;color:navy"><o:p>&nbsp;</o:p></span></font></p><p class="MsoNormal"><font size="2" color="navy" face="Arial"><span style="font-size:
10.0pt;font-family:Arial;color:navy">Cheers<o:p></o:p></span></font></p><p class="MsoNormal"><font size="2" color="navy" face="Arial"><span style="font-size:
10.0pt;font-family:Arial;color:navy">James<o:p></o:p></span></font></p><p class="MsoNormal"><font size="2" color="navy" face="Arial"><span style="font-size:
10.0pt;font-family:Arial;color:navy"><o:p>&nbsp;</o:p></span></font></p><p class="MsoNormal"><font size="2" color="navy" face="Arial"><span style="font-size:
10.0pt;font-family:Arial;color:navy"><o:p>&nbsp;</o:p></span></font></p>

<div><p class="MsoNormal"><font size="3" color="navy" face="Times New Roman"><span style="font-size:12.0pt;color:navy">&nbsp;</span></font><o:p></o:p></p>

</div>

<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">

<div>

<div class="MsoNormal" align="center" style="text-align:center"><font size="3" face="Times New Roman"><span lang="EN-US" style="font-size:12.0pt">

<hr size="2" width="100%" align="center" tabindex="-1">

</span></font></div><p class="MsoNormal"><b><font size="2" face="Tahoma"><span lang="EN-US" style="font-size:10.0pt;font-family:Tahoma;font-weight:bold">From:</span></font></b><font size="2" face="Tahoma"><span lang="EN-US" style="font-size:10.0pt;font-family:Tahoma">
<a href="mailto:[email-masked]">[email-masked]</a> [mailto:[email-masked]] <b><span style="font-weight:bold">On Behalf Of </span></b>DALY, BRIAN K (ATTCINW)<br>
<b><span style="font-weight:bold">Sent:</span></b> Friday, 26 March 2010 12:07
PM<br>
<b><span style="font-weight:bold">To:</span></b> <a href="mailto:[email-masked]">[email-masked]</a>; SENNETT,
DEWAYNE A (ATTCINW); <a href="mailto:[email-masked]">[email-masked]</a>; <a href="mailto:[email-masked]">[email-masked]</a><br>
<b><span style="font-weight:bold">Subject:</span></b> Re: [earlywarning] (no
subject)</span></font><span lang="EN-US"><o:p></o:p></span></p>

</div><p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:
12.0pt"><o:p>&nbsp;</o:p></span></font></p>

<div><p class="MsoNormal"><font size="2" color="navy" face="Arial"><span style="font-size:
10.0pt;font-family:Arial;color:navy">This is NOT silly Brian but serious when
you consider the consequences to the networks.<br>
<br>
We have a solution in place for devices connected to a 3GPP network - we are
asking that this work exclude devices that support 3GPP PWS/CMAS (EPC and IMS)
as those solutions as designed and optimized for the "layer 2"
networks. We even have mobile device behavior specifications.<br>
<br>
I propose we adopt the language in the charter.<br>
<br>
Brian<br>
Brian K. Daly<br>
-------<br>
Sent from my Blackberry</span></font><o:p></o:p></p>

</div><p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:
12.0pt"><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class="MsoNormal" align="center" style="text-align:center"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">

<hr size="2" width="100%" align="center" tabindex="-1">

</span></font></div><p class="MsoNormal" style="margin-bottom:12.0pt"><b><font size="2" face="Tahoma"><span style="font-size:10.0pt;font-family:Tahoma;font-weight:bold">From</span></font></b><font size="2" face="Tahoma"><span style="font-size:10.0pt;font-family:Tahoma">: <st1:personname w:st="on">Brian Rosen</st1:personname> &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br>
<b><span style="font-weight:bold">To</span></b>: SENNETT, DEWAYNE A (ATTCINW);
DALY, BRIAN K (ATTCINW); <a href="mailto:[email-masked]">[email-masked]</a> &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;;
<a href="mailto:[email-masked]">[email-masked]</a> &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br>
<b><span style="font-weight:bold">Sent</span></b>: Thu Mar 25 17:59:21 2010<br>
<b><span style="font-weight:bold">Subject</span></b>: Re: [earlywarning] (no
subject)</span></font><o:p></o:p></p>

</div><p class="MsoNormal" style="margin-bottom:12.0pt"><font size="2" face="Calibri"><span style="font-size:11.0pt;font-family:Calibri">I think this is silly.<br>
<br>
No one is working on alert mechanisms that apply to the Internet.<br>
<br>
The Internet is global, ubiquitous and independent of L2. &nbsp;The proposed
work applies to any kind of device connected to the Internet. &nbsp;Whatever
scale problems exist apply to all L2s one way or another. &nbsp;They must be
faced and solved for the work to be useful. &nbsp;To exclude wireless IMS
systems based on the notion that someone else is working on a system limited to
cell broadcast is, in my opinion, not a good idea.<br>
<br>
I do well understand that vendors and carriers don�t like multiple answers to
the same problem. &nbsp;I get that. &nbsp;However, the IETF is the proper place
to do work on alerts on the Internet, and should not exclude parts of the
Internet.<br>
<br>
Brian<br>
<br>
<br>
On 3/25/10 8:50 PM, "SENNETT, DEWAYNE A (ATTCINW)" &lt;<a href="x-msg://408/[email-masked]">[email-masked]</a>&gt; wrote:</span></font><o:p></o:p></p><p class="MsoNormal" style="margin-bottom:12.0pt"><font size="2" color="navy" face="Arial"><span style="font-size:11.0pt;font-family:Arial;color:navy">I propose
that the following sentence be added to the ATOCA charter:<br>
<br>
The ATOCA RFC's are not applicable to wireless devices which receive their
connectivity via 3GPP EPC/IMS.<br>
<br>
<br>
<br>
&lt;---------------------------&gt; <br>
DeWayne Sennett, AT&amp;T Services, Inc. <br>
Sent from my BlackBerry</span></font><font size="2" face="Calibri"><span style="font-size:11.0pt;font-family:Calibri"><o:p></o:p></span></font></p>

<div class="MsoNormal" align="center" style="text-align:center"><font size="2" face="Calibri"><span style="font-size:11.0pt;font-family:Calibri">

<hr size="2" width="100%" align="center">

</span></font></div><p class="MsoNormal" style="margin-bottom:12.0pt"><b><font size="2" face="Tahoma"><span style="font-size:11.0pt;font-family:Tahoma;font-weight:bold">From</span></font></b><font size="2" face="Tahoma"><span style="font-size:11.0pt;font-family:Tahoma">: <a href="x-msg://408/[email-masked]">[email-masked]</a> &lt;<a href="x-msg://408/[email-masked]">[email-masked]</a>&gt; <br>
<b><span style="font-weight:bold">To</span></b>: <a href="x-msg://408/[email-masked]">[email-masked]</a> &lt;<a href="x-msg://408/[email-masked]">[email-masked]</a>&gt;; <a href="x-msg://408/[email-masked]">[email-masked]</a> &lt;<a href="x-msg://408/[email-masked]">[email-masked]</a>&gt;;
<a href="x-msg://408/[email-masked]">[email-masked]</a> &lt;<a href="x-msg://408/[email-masked]">[email-masked]</a>&gt; <br>
<b><span style="font-weight:bold">Sent</span></b>: Thu Mar 25 17:43:10 2010<br>
<b><span style="font-weight:bold">Subject</span></b>: Re: [earlywarning] (no
subject) <br>
</span></font><font size="2" face="Calibri"><span style="font-size:11.0pt;
font-family:Calibri"><br>
</span></font><font size="2" color="navy" face="Arial"><span style="font-size:11.0pt;
font-family:Arial;color:navy">Keith<br>
<br>
You bring up a good point - we don't want to design a solution that will result
in failure of the network, therefore I second DeWayne's proposal to exclude
from the charter devices that support PWS (and CMAS under that umbrella) and to
acknowledge this solution may result in network problems (e.g. Congestion).<br>
<br>
Brian Daly <br>
Brian K. Daly <br>
------- <br>
Sent from my Blackberry</span></font><font size="2" face="Calibri"><span style="font-size:11.0pt;font-family:Calibri"><o:p></o:p></span></font></p>

<div class="MsoNormal" align="center" style="text-align:center"><font size="2" face="Calibri"><span style="font-size:11.0pt;font-family:Calibri">

<hr size="2" width="100%" align="center">

</span></font></div><p class="MsoNormal" style="margin-bottom:12.0pt"><b><font size="2" face="Tahoma"><span style="font-size:11.0pt;font-family:Tahoma;font-weight:bold">From</span></font></b><font size="2" face="Tahoma"><span style="font-size:11.0pt;font-family:Tahoma">: DRAGE,
Keith (Keith) &lt;<a href="x-msg://408/[email-masked]">[email-masked]</a>&gt;
<br>
<b><span style="font-weight:bold">To</span></b>: <st1:personname w:st="on">Brian
 Rosen</st1:personname> &lt;<a href="x-msg://408/[email-masked]">[email-masked]</a>&gt;;
DALY, BRIAN K (ATTCINW); <a href="x-msg://408/[email-masked]">[email-masked]</a>
&lt;<a href="x-msg://408/[email-masked]">[email-masked]</a>&gt; <br>
<b><span style="font-weight:bold">Sent</span></b>: Thu Mar 25 17:35:30 2010<br>
<b><span style="font-weight:bold">Subject</span></b>: RE: [earlywarning] (no
subject) <br>
</span></font><font size="2" face="Calibri"><span style="font-size:11.0pt;
font-family:Calibri"><br>
</span></font><font size="2" color="blue" face="Arial"><span style="font-size:11.0pt;
font-family:Arial;color:blue">Yes those cellphones could well be connected to
the internet.<br>
</span></font><font size="2" face="Calibri"><span style="font-size:11.0pt;
font-family:Calibri"><br>
</span></font><font size="2" color="blue" face="Arial"><span style="font-size:11.0pt;
font-family:Arial;color:blue">But cell broadcast service exists on 3GPP phones.
For alerts that are intended to hit a large proportion of the phones in any
cell, it makes best use of the bandwidth.<br>
</span></font><font size="2" face="Calibri"><span style="font-size:11.0pt;
font-family:Calibri"><br>
</span></font><font size="2" color="blue" face="Arial"><span style="font-size:11.0pt;
font-family:Arial;color:blue">You bring up an IP connection to all cellphones
in that cell, and then broadcast warnings to all those cells, and the net
result will be inappropriate loading of cells specifically for this traffic.
Given that such warnings may otherwise create network stress as a result of the
public warning being made in the first place, the first point of call for
getting such warnings to cellphone uses has to be cell broadcast.<br>
</span></font><font size="2" face="Calibri"><span style="font-size:11.0pt;
font-family:Calibri"><br>
</span></font><font size="2" color="blue" face="Arial"><span style="font-size:11.0pt;
font-family:Arial;color:blue">It appears that many governmental organisations
have accepted cell broadcast as the desired means of delivering public warnings
to cellphones.<br>
</span></font><font size="2" face="Calibri"><span style="font-size:11.0pt;
font-family:Calibri"><br>
</span></font><font size="2" color="blue" face="Arial"><span style="font-size:11.0pt;
font-family:Arial;color:blue">Therefore any IETF activity has to acknowledge
that solution exists for cellphones. <br>
</span></font><font size="2" face="Calibri"><span style="font-size:11.0pt;
font-family:Calibri"><br>
</span></font><font size="2" color="blue" face="Arial"><span style="font-size:11.0pt;
font-family:Arial;color:blue">Further I believe that any IETF solution has to
specifically NOT convey the impression that for cellphones, the IETF solution
is a good way forward for the warning itself. Users could well find the
warnings from the IETF solution to an IP endpoint delivered well after the cell
broadcast warning. And certainly the IETF solution should not expect priority
over other types of traffic at that point, because at cell broadcast channel
already exists to give that priority for the appropriate type of traffic.<br>
</span></font><font size="2" face="Calibri"><span style="font-size:11.0pt;
font-family:Calibri"><br>
</span></font><font size="2" color="blue" face="Arial"><span style="font-size:11.0pt;
font-family:Arial;color:blue">regards<br>
</span></font><font size="2" face="Calibri"><span style="font-size:11.0pt;
font-family:Calibri"><br>
</span></font><font size="2" color="blue" face="Arial"><span style="font-size:11.0pt;
font-family:Arial;color:blue">Keith</span></font><o:p></o:p></p><p class="MsoNormal"><font size="2" face="Calibri"><span style="font-size:11.0pt;
font-family:Calibri"><br>
&nbsp;<o:p></o:p></span></font></p>

<div class="MsoNormal" align="center" style="text-align:center"><font size="2" face="Calibri"><span style="font-size:11.0pt;font-family:Calibri">

<hr size="3" width="100%" align="center">

</span></font></div><p class="MsoNormal"><b><font size="2" face="Tahoma"><span style="font-size:11.0pt;
font-family:Tahoma;font-weight:bold">From:</span></font></b><font size="2" face="Tahoma"><span style="font-size:11.0pt;font-family:Tahoma"> <a href="x-msg://408/[email-masked]">[email-masked]</a> &nbsp;[<a href="mailto:[email-masked]">mailto:[email-masked]</a>]
<b><span style="font-weight:bold">On Behalf Of </span></b>Brian &nbsp;Rosen<br>
<b><span style="font-weight:bold">Sent:</span></b> Friday, March 26, 2010 12:00
AM<br>
<b><span style="font-weight:bold">To:</span></b> DALY, &nbsp;BRIAN K (ATTCINW);
<a href="x-msg://408/[email-masked]">[email-masked]</a><br>
<b><span style="font-weight:bold">Subject:</span></b> Re: [earlywarning]
&nbsp;(no subject)<br>
</span></font><font size="2" face="Calibri"><span style="font-size:11.0pt;
font-family:Calibri"><br>
&nbsp;<br>
Are they connected to the Internet?<br>
<br>
If they &nbsp;are, it would apply. &nbsp;If they aren�t, then it wouldn�t
&nbsp;apply.<br>
<br>
Brian<br>
<br>
<br>
On 3/25/10 7:51 PM, "DALY, BRIAN K (ATTCINW)" &nbsp;&lt;<a href="x-msg://408/[email-masked]">[email-masked]</a>&gt; &nbsp;wrote:<br>
<br>
&nbsp;</span></font><o:p></o:p></p><p class="MsoNormal"><font size="2" color="#1f497d" face="Calibri"><span style="font-size:11.0pt;font-family:Calibri;color:#1F497D">That will not apply
to devices &nbsp;connected to wireless cellular &nbsp;networks.<br>
&nbsp;<br>
</span></font><font size="2" face="Calibri"><span style="font-size:11.0pt;
font-family:Calibri"><br>
</span></font><b><font size="2" face="Tahoma"><span style="font-size:10.0pt;
font-family:Tahoma;font-weight:bold">From:</span></font></b><font size="2" face="Tahoma"><span style="font-size:10.0pt;font-family:Tahoma"> <st1:personname w:st="on">Brian Rosen</st1:personname> [<a href="mailto:[email-masked]">mailto:[email-masked]</a>]
&nbsp;<br>
<b><span style="font-weight:bold">Sent:</span></b> Thursday, March 25, 2010
4:50 PM<br>
<b><span style="font-weight:bold">To:</span></b> DALY, BRIAN &nbsp;K (ATTCINW);
<a href="x-msg://408/[email-masked]">[email-masked]</a><br>
<b><span style="font-weight:bold">Subject:</span></b> &nbsp;Re: [earlywarning]
(no subject)<br>
</span></font><br>
<font size="2" face="Calibri"><span style="font-size:11.0pt;font-family:Calibri">Once
&nbsp;again, this is NOT about a solution limited to wireless cellular
networks. &nbsp;&nbsp;It is about a solution for internet connected endpoints
of all kinds. &nbsp;&nbsp;<br>
<br>
Brian<br>
<br>
<br>
On 3/25/10 7:46 PM, "DALY, BRIAN K (ATTCINW)" &nbsp;&lt;<a href="x-msg://408/[email-masked]">[email-masked]</a>&gt; wrote:<br>
Keith � We &nbsp;agree with you, and to further the point, in wireless cellular
IP networks a &nbsp;point to point solution would be problematic. Cell
Broadcast is used for &nbsp;CMAS because SMS cannot be used for any real time
alerting � it was not &nbsp;designed for that application and has serious limitations,
as the FCC CMSAAC &nbsp;studied.<br>
&nbsp;<br>
When it comes to the evolved packet core and IMS, &nbsp;again a point to point
solution &nbsp;will cause significant congestion on &nbsp;the network and a
broadcast/multicast solution must be used to effectively &nbsp;deliver alert
messages. Thus things like location and �priority� are already &nbsp;handled in
the delivery network.<br>
&nbsp;<br>
ATIS and 3GPP will be studying &nbsp;how to support multimedia alerts in the
future, as recommended by the FCC &nbsp;CMSAAC. This is all beyond the scope of
this work &nbsp;effort.<br>
&nbsp;<br>
Regards,<br>
Brian<br>
&nbsp;<br>
</span></font><font size="2" face="Consolas"><span style="font-size:10.0pt;
font-family:Consolas">Date: Thu, 25 Mar 2010 03:13:24 +0100<br>
From: &nbsp;"DRAGE, Keith (Keith)" &lt;<a href="x-msg://408/[email-masked]">[email-masked]</a>&gt;<br>
Subject: &nbsp;Re: [earlywarning] Updated Charter Text for ATOCA<br>
To: <st1:personname w:st="on">Hannes Tschofenig</st1:personname> &nbsp;&lt;<a href="x-msg://408/[email-masked]">[email-masked]</a>&gt;,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"<a href="x-msg://408/[email-masked]">[email-masked]</a>"
&lt;<a href="x-msg://408/[email-masked]">[email-masked]</a>&gt;<br>
Message-ID:<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;<a href="x-msg://408/[email-masked]">[email-masked]</a>&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
Content-Type: &nbsp;text/plain; charset="us-ascii"<br>
&nbsp;<br>
What I am not seeing here is any &nbsp;separation of the problem from the one
that cell broadcast attempts to &nbsp;solve. Fundamentally, cell broadcast, as
exists on all GSM, UTRAN and &nbsp;E-UTRAN based cell phones and is being used
for Tsunami warning and Public &nbsp;Warning, exists and is not going to
substantially change. The major &nbsp;limitation here is is length of message,
and what does get transmitted will &nbsp;be very much dependent on that
restriction.<br>
&nbsp;<br>
Moreover I have &nbsp;heard from a number of governmental bodies that they are
happy with that &nbsp;situation and are not envisaging further standardisation
in that area &nbsp;outside of 3GPP.<br>
&nbsp;<br>
So my view at the moment is that there is no &nbsp;point in IETF trying to
address the scope of what is already specified in &nbsp;cell broadcast (from
base station to end &nbsp;mobile).<br>
&nbsp;<br>
regards<br>
&nbsp;<br>
Keith<br>
</span></font><font size="2" face="Calibri"><span style="font-size:11.0pt;
font-family:Calibri"><br>
&nbsp;&nbsp;&nbsp; </span></font><o:p></o:p></p><p align="center" style="text-align:center"><font size="2" face="Calibri"><span style="font-size:11.0pt;font-family:Calibri"><o:p>&nbsp;</o:p></span></font></p>

<div class="MsoNormal" align="center" style="text-align:center"><font size="2" face="Calibri"><span style="font-size:11.0pt;font-family:Calibri">

<hr size="3" width="95%" align="center">

</span></font></div><p class="MsoNormal"><font size="2" face="Calibri"><span style="font-size:11.0pt;
font-family:Calibri">&nbsp; </span></font><o:p></o:p></p><p style="margin-bottom:12.0pt"><font size="2" face="Calibri"><span style="font-size:11.0pt;font-family:Calibri"><br>
</span></font><font size="2" face="Consolas"><span style="font-size:10.0pt;
font-family:Consolas">_______________________________________________<br>
earlywarning &nbsp;mailing list<br>
<a href="x-msg://408/[email-masked]">[email-masked]</a><br>
<a href="https://www.ietf.org/mailman/listinfo/earlywarning">https://www.ietf.org/mailman/listinfo/earlywarning</a></span></font><o:p></o:p></p><p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:
12.0pt"><o:p>&nbsp;</o:p></span></font></p>

</div>

</div>

</div>

</div>

_______________________________________________<br>earlywarning mailing list<br><a href="mailto:[email-masked]">[email-masked]</a><br>https://www.ietf.org/mailman/listinfo/earlywarning<br></o:smarttagtype></blockquote></div><br></body></html>
--Apple-Mail-10--797220255--

Content-class: urn:content-classes:message
Date: Thu, 25 Mar 2010 18:31:00 -0700
From: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: [earlywarning] (no subject)

This is a multi-part message in MIME format.

------_=_NextPart_001_01CACC83.FE118DFE
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64

------_=_NextPart_001_01CACC83.FE118DFE
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: base64

------_=_NextPart_001_01CACC83.FE118DFE--

From: "Winterbottom, James" <[email-masked]>
To: "DALY, BRIAN K (ATTCINW)" <[email-masked]>, "[email-masked]" <[email-masked]>, "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 26 Mar 2010 09:25:00 +0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [earlywarning] (no subject)

--_000_5A55A45AE77F5941B18E5457ECAC81880120DFB13539SISPE7MB1co_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I am not so sure that we can just 802.11 and be done with it.
We also have a lot of broadband deployments out there that still run PPP over ATM, where an 802.11 solution is not going to work.
My preference would be to see a solution that works regardless of how the device is connected to the Internet.

Cheers
James

________________________________
From: DALY, BRIAN K (ATTCINW) [mailto:[email-masked]]
Sent: Friday, 26 March 2010 12:21 PM
To: Winterbottom, James; [email-masked]; SENNETT, DEWAYNE A (ATTCINW); [email-masked]; [email-masked]
Subject: Re: [earlywarning] (no subject)

James

Good point and I think this is an area for discussion along with the dot11 issue. I see these as part of the work that this effort should evaluate.

This is different from where the end device obtains service directly from the 3GPP network.

Brian
Brian K. Daly
-------
Sent from my Blackberry

________________________________
From: Winterbottom, James <[email-masked]>
To: DALY, BRIAN K (ATTCINW); [email-masked] <[email-masked]>; SENNETT, DEWAYNE A (ATTCINW); [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Sent: Thu Mar 25 18:14:35 2010
Subject: RE: [earlywarning] (no subject)
Brian D,

We are increasingly seeing 3G hotspot devices, aka MiFi type devices. In this mode the devices using 3G as a backhaul are connected to the Internet and almost certainly do not have access to the underlying IMS services. Any solution needs to work in that environment too. I am interested to hear what you are proposing here.

Cheers
James

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of DALY, BRIAN K (ATTCINW)
Sent: Friday, 26 March 2010 12:07 PM
To: [email-masked]; SENNETT, DEWAYNE A (ATTCINW); [email-masked]; [email-masked]
Subject: Re: [earlywarning] (no subject)

This is NOT silly Brian but serious when you consider the consequences to the networks.

We have a solution in place for devices connected to a 3GPP network - we are asking that this work exclude devices that support 3GPP PWS/CMAS (EPC and IMS) as those solutions as designed and optimized for the "layer 2" networks. We even have mobile device behavior specifications.

I propose we adopt the language in the charter.

Brian
Brian K. Daly
-------
Sent from my Blackberry

________________________________
From: Brian Rosen <[email-masked]>
To: SENNETT, DEWAYNE A (ATTCINW); DALY, BRIAN K (ATTCINW); [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Sent: Thu Mar 25 17:59:21 2010
Subject: Re: [earlywarning] (no subject)
I think this is silly.

No one is working on alert mechanisms that apply to the Internet.

The Internet is global, ubiquitous and independent of L2.  The proposed work applies to any kind of device connected to the Internet.  Whatever scale problems exist apply to all L2s one way or another.  They must be faced and solved for the work to be useful.  To exclude wireless IMS systems based on the notion that someone else is working on a system limited to cell broadcast is, in my opinion, not a good idea.

I do well understand that vendors and carriers don't like multiple answers to the same problem.  I get that.  However, the IETF is the proper place to do work on alerts on the Internet, and should not exclude parts of the Internet.

Brian

On 3/25/10 8:50 PM, "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]> wrote:
I propose that the following sentence be added to the ATOCA charter:

The ATOCA RFC's are not applicable to wireless devices which receive their connectivity via 3GPP EPC/IMS.

<--------------------------->
DeWayne Sennett, AT&T Services, Inc.
Sent from my BlackBerry
________________________________
From: [email-masked] <[email-masked]>
To: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Sent: Thu Mar 25 17:43:10 2010
Subject: Re: [earlywarning] (no subject)

Keith

You bring up a good point - we don't want to design a solution that will result in failure of the network, therefore I second DeWayne's proposal to exclude from the charter devices that support PWS (and CMAS under that umbrella) and to acknowledge this solution may result in network problems (e.g. Congestion).

Brian Daly
Brian K. Daly
-------
Sent from my Blackberry
________________________________
From: DRAGE, Keith (Keith) <[email-masked]>
To: Brian Rosen <[email-masked]>; DALY, BRIAN K (ATTCINW); [email-masked] <[email-masked]>
Sent: Thu Mar 25 17:35:30 2010
Subject: RE: [earlywarning] (no subject)

Yes those cellphones could well be connected to the internet.

But cell broadcast service exists on 3GPP phones. For alerts that are intended to hit a large proportion of the phones in any cell, it makes best use of the bandwidth.

You bring up an IP connection to all cellphones in that cell, and then broadcast warnings to all those cells, and the net result will be inappropriate loading of cells specifically for this traffic. Given that such warnings may otherwise create network stress as a result of the public warning being made in the first place, the first point of call for getting such warnings to cellphone uses has to be cell broadcast.

It appears that many governmental organisations have accepted cell broadcast as the desired means of delivering public warnings to cellphones.

Therefore any IETF activity has to acknowledge that solution exists for cellphones.

Further I believe that any IETF solution has to specifically NOT convey the impression that for cellphones, the IETF solution is a good way forward for the warning itself. Users could well find the warnings from the IETF solution to an IP endpoint delivered well after the cell broadcast warning. And certainly the IETF solution should not expect priority over other types of traffic at that point, because at cell broadcast channel already exists to give that priority for the appropriate type of traffic.

regards

Keith

________________________________
From: [email-masked]  [mailto:[email-masked]] On Behalf Of Brian  Rosen
Sent: Friday, March 26, 2010 12:00 AM
To: DALY,  BRIAN K (ATTCINW); [email-masked]
Subject: Re: [earlywarning]  (no subject)

Are they connected to the Internet?

If they  are, it would apply.  If they aren't, then it wouldn't  apply.

Brian

On 3/25/10 7:51 PM, "DALY, BRIAN K (ATTCINW)"  <[email-masked]>  wrote:

That will not apply to devices  connected to wireless cellular  networks.

From: Brian Rosen [mailto:[email-masked]]
Sent: Thursday, March 25, 2010 4:50 PM
To: DALY, BRIAN  K (ATTCINW); [email-masked]
Subject:  Re: [earlywarning] (no subject)

Once  again, this is NOT about a solution limited to wireless cellular networks.   It is about a solution for internet connected endpoints of all kinds.

Brian

On 3/25/10 7:46 PM, "DALY, BRIAN K (ATTCINW)"  <[email-masked]> wrote:
Keith - We  agree with you, and to further the point, in wireless cellular IP networks a  point to point solution would be problematic. Cell Broadcast is used for  CMAS because SMS cannot be used for any real time alerting - it was not  designed for that application and has serious limitations, as the FCC CMSAAC  studied.

When it comes to the evolved packet core and IMS,  again a point to point solution  will cause significant congestion on  the network and a broadcast/multicast solution must be used to effectively  deliver alert messages. Thus things like location and "priority" are already  handled in the delivery network.

ATIS and 3GPP will be studying  how to support multimedia alerts in the future, as recommended by the FCC  CMSAAC. This is all beyond the scope of this work  effort.

Regards,
Brian

Date: Thu, 25 Mar 2010 03:13:24 +0100
From:  "DRAGE, Keith (Keith)" <[email-masked]>
Subject:  Re: [earlywarning] Updated Charter Text for ATOCA
To: Hannes Tschofenig  <[email-masked]>,
      "[email-masked]" <[email-masked]>
Message-ID:
      <[email-masked]>

Content-Type:  text/plain; charset="us-ascii"

What I am not seeing here is any  separation of the problem from the one that cell broadcast attempts to  solve. Fundamentally, cell broadcast, as exists on all GSM, UTRAN and  E-UTRAN based cell phones and is being used for Tsunami warning and Public  Warning, exists and is not going to substantially change. The major  limitation here is is length of message, and what does get transmitted will  be very much dependent on that restriction.

Moreover I have  heard from a number of governmental bodies that they are happy with that  situation and are not envisaging further standardisation in that area  outside of 3GPP.

So my view at the moment is that there is no  point in IETF trying to address the scope of what is already specified in  cell broadcast (from base station to end  mobile).

regards

Keith

________________________________

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

--_000_5A55A45AE77F5941B18E5457ECAC81880120DFB13539SISPE7MB1co_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:st1="urn:schemas-microsoft-com:office:smarttags" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>Re: [earlywarning] (no subject)</title>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
 name="PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
p.MsoList, li.MsoList, div.MsoList
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:14.15pt;
	margin-bottom:.0001pt;
	text-indent:-14.15pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman";}
p.Reference, li.Reference, div.Reference
	{margin-top:6.0pt;
	margin-right:0cm;
	margin-bottom:6.0pt;
	margin-left:36.85pt;
	text-indent:-19.0pt;
	mso-list:l0 level1 lfo3;
	font-size:12.0pt;
	font-family:"Times New Roman";}
p.reference0, li.reference0, div.reference0
	{margin-top:6.0pt;
	margin-right:0cm;
	margin-bottom:6.0pt;
	margin-left:36.85pt;
	text-indent:-19.0pt;
	mso-list:l0 level1 lfo5;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle22
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:891500023;
	mso-list-type:hybrid;
	mso-list-template-ids:172770280 1392555560 201916441 201916443 201916431 201916441 201916443 201916431 201916441 201916443;}
@list l0:level1
	{mso-level-style-link:Reference;
	mso-level-text:"\[%1\]";
	mso-level-tab-stop:36.85pt;
	mso-level-number-position:left;
	margin-left:36.85pt;
	text-indent:-19.0pt;}
@list l0:level2
	{mso-level-tab-stop:72.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level3
	{mso-level-tab-stop:108.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level4
	{mso-level-tab-stop:144.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level5
	{mso-level-tab-stop:180.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level6
	{mso-level-tab-stop:216.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level7
	{mso-level-tab-stop:252.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level8
	{mso-level-tab-stop:288.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level9
	{mso-level-tab-stop:324.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-AU link=blue vlink=blue>

<div class=Section1>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>I am not so sure that we can just 802.11 and
be done with it.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>We also have a lot of broadband
deployments out there that still run PPP over ATM, where an 802.11 solution is
not going to work.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>My preference would be to see a solution
that works regardless of how the device is connected to the Internet.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Cheers<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>James<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=MsoNormal><font size=3 color=navy face="Times New Roman"><span
style='font-size:12.0pt;color:navy'>&nbsp;</span></font><o:p></o:p></p>

</div>

<div style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'>

<div>

<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span lang=EN-US style='font-size:12.0pt'>

<hr size=2 width="100%" align=center tabindex=-1>

</span></font></div>

<p class=MsoNormal><b><font size=2 face=Tahoma><span lang=EN-US
style='font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</span></font></b><font
size=2 face=Tahoma><span lang=EN-US style='font-size:10.0pt;font-family:Tahoma'>
DALY, BRIAN K (ATTCINW) [mailto:[email-masked]] <br>
<b><span style='font-weight:bold'>Sent:</span></b> Friday, 26 March 2010 12:21
PM<br>
<b><span style='font-weight:bold'>To:</span></b> <st1:PersonName w:st="on">Winterbottom,
 James</st1:PersonName>; [email-masked]; SENNETT, DEWAYNE A (ATTCINW);
[email-masked]; [email-masked]<br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: [earlywarning] (no
subject)</span></font><span lang=EN-US><o:p></o:p></span></p>

</div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>James<br>
<br>
Good point and I think this is an area for discussion along with the dot11
issue. I see these as part of the work that this effort should evaluate.<br>
<br>
This is different from where the end device obtains service directly from the
3GPP network.<br>
<br>
Brian<br>
Brian K. Daly<br>
-------<br>
Sent from my Blackberry</span></font><o:p></o:p></p>

</div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>

<hr size=2 width="100%" align=center tabindex=-1>

</span></font></div>

<p class=MsoNormal style='margin-bottom:12.0pt'><b><font size=2 face=Tahoma><span
style='font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From</span></font></b><font
size=2 face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'>: <st1:PersonName
w:st="on">Winterbottom, James</st1:PersonName>
&lt;[email-masked]&gt;<br>
<b><span style='font-weight:bold'>To</span></b>: DALY, BRIAN K (ATTCINW);
[email-masked] &lt;[email-masked]&gt;; SENNETT, DEWAYNE A (ATTCINW);
[email-masked] &lt;[email-masked]&gt;;
[email-masked] &lt;[email-masked]&gt;<br>
<b><span style='font-weight:bold'>Sent</span></b>: Thu Mar 25 18:14:35 2010<br>
<b><span style='font-weight:bold'>Subject</span></b>: RE: [earlywarning] (no
subject)</span></font><o:p></o:p></p>

</div>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Brian D,<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>We are increasingly seeing 3G hotspot
devices, aka MiFi type devices. In this mode the devices using 3G as a backhaul
are connected to the Internet and almost certainly do not have access to the
underlying IMS services. Any solution needs to work in that environment too. I
am interested to hear what you are proposing here.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Cheers<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>James<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=MsoNormal><font size=3 color=navy face="Times New Roman"><span
style='font-size:12.0pt;color:navy'>&nbsp;</span></font><o:p></o:p></p>

</div>

<div style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'>

<div>

<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span lang=EN-US style='font-size:12.0pt'>

<hr size=2 width="100%" align=center tabindex=-1>

</span></font></div>

<p class=MsoNormal><b><font size=2 face=Tahoma><span lang=EN-US
style='font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</span></font></b><font
size=2 face=Tahoma><span lang=EN-US style='font-size:10.0pt;font-family:Tahoma'>
[email-masked] [mailto:[email-masked]] <b><span
style='font-weight:bold'>On Behalf Of </span></b>DALY, BRIAN K (ATTCINW)<br>
<b><span style='font-weight:bold'>Sent:</span></b> Friday, 26 March 2010 12:07
PM<br>
<b><span style='font-weight:bold'>To:</span></b> [email-masked]; SENNETT,
DEWAYNE A (ATTCINW); [email-masked]; [email-masked]<br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: [earlywarning] (no
subject)</span></font><span lang=EN-US><o:p></o:p></span></p>

</div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>This is NOT silly Brian but serious when
you consider the consequences to the networks.<br>
<br>
We have a solution in place for devices connected to a 3GPP network - we are
asking that this work exclude devices that support 3GPP PWS/CMAS (EPC and IMS)
as those solutions as designed and optimized for the &quot;layer 2&quot;
networks. We even have mobile device behavior specifications.<br>
<br>
I propose we adopt the language in the charter.<br>
<br>
Brian<br>
Brian K. Daly<br>
-------<br>
Sent from my Blackberry</span></font><o:p></o:p></p>

</div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>

<hr size=2 width="100%" align=center tabindex=-1>

</span></font></div>

<p class=MsoNormal style='margin-bottom:12.0pt'><b><font size=2 face=Tahoma><span
style='font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From</span></font></b><font
size=2 face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'>: <st1:PersonName
w:st="on">Brian Rosen</st1:PersonName> &lt;[email-masked]&gt;<br>
<b><span style='font-weight:bold'>To</span></b>: SENNETT, DEWAYNE A (ATTCINW);
DALY, BRIAN K (ATTCINW); [email-masked] &lt;[email-masked]&gt;;
[email-masked] &lt;[email-masked]&gt;<br>
<b><span style='font-weight:bold'>Sent</span></b>: Thu Mar 25 17:59:21 2010<br>
<b><span style='font-weight:bold'>Subject</span></b>: Re: [earlywarning] (no
subject)</span></font><o:p></o:p></p>

</div>

<p class=MsoNormal style='margin-bottom:12.0pt'><font size=2 face=Calibri><span
style='font-size:11.0pt;font-family:Calibri'>I think this is silly.<br>
<br>
No one is working on alert mechanisms that apply to the Internet.<br>
<br>
The Internet is global, ubiquitous and independent of L2. &nbsp;The proposed
work applies to any kind of device connected to the Internet. &nbsp;Whatever
scale problems exist apply to all L2s one way or another. &nbsp;They must be
faced and solved for the work to be useful. &nbsp;To exclude wireless IMS
systems based on the notion that someone else is working on a system limited to
cell broadcast is, in my opinion, not a good idea.<br>
<br>
I do well understand that vendors and carriers don&#8217;t like multiple answers to
the same problem. &nbsp;I get that. &nbsp;However, the IETF is the proper place
to do work on alerts on the Internet, and should not exclude parts of the
Internet.<br>
<br>
Brian<br>
<br>
<br>
On 3/25/10 8:50 PM, &quot;SENNETT, DEWAYNE A (ATTCINW)&quot; &lt;<a
href="[email-masked]">[email-masked]</a>&gt; wrote:</span></font><o:p></o:p></p>

<p class=MsoNormal style='margin-bottom:12.0pt'><font size=2 color=navy
face=Arial><span style='font-size:11.0pt;font-family:Arial;color:navy'>I propose
that the following sentence be added to the ATOCA charter:<br>
<br>
The ATOCA RFC's are not applicable to wireless devices which receive their
connectivity via 3GPP EPC/IMS.<br>
<br>
<br>
<br>
&lt;---------------------------&gt; <br>
DeWayne Sennett, AT&amp;T Services, Inc. <br>
Sent from my BlackBerry</span></font><font size=2 face=Calibri><span
style='font-size:11.0pt;font-family:Calibri'><o:p></o:p></span></font></p>

<div class=MsoNormal align=center style='text-align:center'><font size=2
face=Calibri><span style='font-size:11.0pt;font-family:Calibri'>

<hr size=2 width="100%" align=center>

</span></font></div>

<p class=MsoNormal style='margin-bottom:12.0pt'><b><font size=2 face=Tahoma><span
style='font-size:11.0pt;font-family:Tahoma;font-weight:bold'>From</span></font></b><font
size=2 face=Tahoma><span style='font-size:11.0pt;font-family:Tahoma'>: <a
href="[email-masked]">[email-masked]</a> &lt;<a
href="[email-masked]">[email-masked]</a>&gt; <br>
<b><span style='font-weight:bold'>To</span></b>: <a
href="[email-masked]">[email-masked]</a> &lt;<a
href="[email-masked]">[email-masked]</a>&gt;; <a
href="[email-masked]">[email-masked]</a> &lt;<a href="[email-masked]">[email-masked]</a>&gt;;
<a href="[email-masked]">[email-masked]</a> &lt;<a
href="[email-masked]">[email-masked]</a>&gt; <br>
<b><span style='font-weight:bold'>Sent</span></b>: Thu Mar 25 17:43:10 2010<br>
<b><span style='font-weight:bold'>Subject</span></b>: Re: [earlywarning] (no
subject) <br>
</span></font><font size=2 face=Calibri><span style='font-size:11.0pt;
font-family:Calibri'><br>
</span></font><font size=2 color=navy face=Arial><span style='font-size:11.0pt;
font-family:Arial;color:navy'>Keith<br>
<br>
You bring up a good point - we don't want to design a solution that will result
in failure of the network, therefore I second DeWayne's proposal to exclude
from the charter devices that support PWS (and CMAS under that umbrella) and to
acknowledge this solution may result in network problems (e.g. Congestion).<br>
<br>
Brian Daly <br>
Brian K. Daly <br>
------- <br>
Sent from my Blackberry</span></font><font size=2 face=Calibri><span
style='font-size:11.0pt;font-family:Calibri'><o:p></o:p></span></font></p>

<div class=MsoNormal align=center style='text-align:center'><font size=2
face=Calibri><span style='font-size:11.0pt;font-family:Calibri'>

<hr size=2 width="100%" align=center>

</span></font></div>

<p class=MsoNormal style='margin-bottom:12.0pt'><b><font size=2 face=Tahoma><span
style='font-size:11.0pt;font-family:Tahoma;font-weight:bold'>From</span></font></b><font
size=2 face=Tahoma><span style='font-size:11.0pt;font-family:Tahoma'>: DRAGE,
Keith (Keith) &lt;<a href="[email-masked]">[email-masked]</a>&gt;
<br>
<b><span style='font-weight:bold'>To</span></b>: <st1:PersonName w:st="on">Brian
 Rosen</st1:PersonName> &lt;<a href="[email-masked]">[email-masked]</a>&gt;;
DALY, BRIAN K (ATTCINW); <a href="[email-masked]">[email-masked]</a>
&lt;<a href="[email-masked]">[email-masked]</a>&gt; <br>
<b><span style='font-weight:bold'>Sent</span></b>: Thu Mar 25 17:35:30 2010<br>
<b><span style='font-weight:bold'>Subject</span></b>: RE: [earlywarning] (no
subject) <br>
</span></font><font size=2 face=Calibri><span style='font-size:11.0pt;
font-family:Calibri'><br>
</span></font><font size=2 color=blue face=Arial><span style='font-size:11.0pt;
font-family:Arial;color:blue'>Yes those cellphones could well be connected to
the internet.<br>
</span></font><font size=2 face=Calibri><span style='font-size:11.0pt;
font-family:Calibri'><br>
</span></font><font size=2 color=blue face=Arial><span style='font-size:11.0pt;
font-family:Arial;color:blue'>But cell broadcast service exists on 3GPP phones.
For alerts that are intended to hit a large proportion of the phones in any
cell, it makes best use of the bandwidth.<br>
</span></font><font size=2 face=Calibri><span style='font-size:11.0pt;
font-family:Calibri'><br>
</span></font><font size=2 color=blue face=Arial><span style='font-size:11.0pt;
font-family:Arial;color:blue'>You bring up an IP connection to all cellphones
in that cell, and then broadcast warnings to all those cells, and the net
result will be inappropriate loading of cells specifically for this traffic.
Given that such warnings may otherwise create network stress as a result of the
public warning being made in the first place, the first point of call for
getting such warnings to cellphone uses has to be cell broadcast.<br>
</span></font><font size=2 face=Calibri><span style='font-size:11.0pt;
font-family:Calibri'><br>
</span></font><font size=2 color=blue face=Arial><span style='font-size:11.0pt;
font-family:Arial;color:blue'>It appears that many governmental organisations
have accepted cell broadcast as the desired means of delivering public warnings
to cellphones.<br>
</span></font><font size=2 face=Calibri><span style='font-size:11.0pt;
font-family:Calibri'><br>
</span></font><font size=2 color=blue face=Arial><span style='font-size:11.0pt;
font-family:Arial;color:blue'>Therefore any IETF activity has to acknowledge
that solution exists for cellphones. <br>
</span></font><font size=2 face=Calibri><span style='font-size:11.0pt;
font-family:Calibri'><br>
</span></font><font size=2 color=blue face=Arial><span style='font-size:11.0pt;
font-family:Arial;color:blue'>Further I believe that any IETF solution has to
specifically NOT convey the impression that for cellphones, the IETF solution
is a good way forward for the warning itself. Users could well find the
warnings from the IETF solution to an IP endpoint delivered well after the cell
broadcast warning. And certainly the IETF solution should not expect priority
over other types of traffic at that point, because at cell broadcast channel
already exists to give that priority for the appropriate type of traffic.<br>
</span></font><font size=2 face=Calibri><span style='font-size:11.0pt;
font-family:Calibri'><br>
</span></font><font size=2 color=blue face=Arial><span style='font-size:11.0pt;
font-family:Arial;color:blue'>regards<br>
</span></font><font size=2 face=Calibri><span style='font-size:11.0pt;
font-family:Calibri'><br>
</span></font><font size=2 color=blue face=Arial><span style='font-size:11.0pt;
font-family:Arial;color:blue'>Keith</span></font><o:p></o:p></p>

<p class=MsoNormal><font size=2 face=Calibri><span style='font-size:11.0pt;
font-family:Calibri'><br>
&nbsp;<o:p></o:p></span></font></p>

<div class=MsoNormal align=center style='text-align:center'><font size=2
face=Calibri><span style='font-size:11.0pt;font-family:Calibri'>

<hr size=3 width="100%" align=center>

</span></font></div>

<p class=MsoNormal><b><font size=2 face=Tahoma><span style='font-size:11.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=2
face=Tahoma><span style='font-size:11.0pt;font-family:Tahoma'> <a
href="[email-masked]">[email-masked]</a> &nbsp;[<a
href="mailto:[email-masked]">mailto:[email-masked]</a>]
<b><span style='font-weight:bold'>On Behalf Of </span></b>Brian &nbsp;Rosen<br>
<b><span style='font-weight:bold'>Sent:</span></b> Friday, March 26, 2010 12:00
AM<br>
<b><span style='font-weight:bold'>To:</span></b> DALY, &nbsp;BRIAN K (ATTCINW);
<a href="[email-masked]">[email-masked]</a><br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: [earlywarning]
&nbsp;(no subject)<br>
</span></font><font size=2 face=Calibri><span style='font-size:11.0pt;
font-family:Calibri'><br>
&nbsp;<br>
Are they connected to the Internet?<br>
<br>
If they &nbsp;are, it would apply. &nbsp;If they aren&#8217;t, then it wouldn&#8217;t
&nbsp;apply.<br>
<br>
Brian<br>
<br>
<br>
On 3/25/10 7:51 PM, &quot;DALY, BRIAN K (ATTCINW)&quot; &nbsp;&lt;<a
href="[email-masked]">[email-masked]</a>&gt; &nbsp;wrote:<br>
<br>
&nbsp;</span></font><o:p></o:p></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>That will not apply
to devices &nbsp;connected to wireless cellular &nbsp;networks.<br>
&nbsp;<br>
</span></font><font size=2 face=Calibri><span style='font-size:11.0pt;
font-family:Calibri'><br>
</span></font><b><font size=2 face=Tahoma><span style='font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=2
face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'> <st1:PersonName
w:st="on">Brian Rosen</st1:PersonName> [<a href="mailto:[email-masked]">mailto:[email-masked]</a>]
&nbsp;<br>
<b><span style='font-weight:bold'>Sent:</span></b> Thursday, March 25, 2010
4:50 PM<br>
<b><span style='font-weight:bold'>To:</span></b> DALY, BRIAN &nbsp;K (ATTCINW);
<a href="[email-masked]">[email-masked]</a><br>
<b><span style='font-weight:bold'>Subject:</span></b> &nbsp;Re: [earlywarning]
(no subject)<br>
</span></font><br>
<font size=2 face=Calibri><span style='font-size:11.0pt;font-family:Calibri'>Once
&nbsp;again, this is NOT about a solution limited to wireless cellular
networks. &nbsp;&nbsp;It is about a solution for internet connected endpoints
of all kinds. &nbsp;&nbsp;<br>
<br>
Brian<br>
<br>
<br>
On 3/25/10 7:46 PM, &quot;DALY, BRIAN K (ATTCINW)&quot; &nbsp;&lt;<a
href="[email-masked]">[email-masked]</a>&gt; wrote:<br>
Keith &#8211; We &nbsp;agree with you, and to further the point, in wireless cellular
IP networks a &nbsp;point to point solution would be problematic. Cell
Broadcast is used for &nbsp;CMAS because SMS cannot be used for any real time
alerting &#8211; it was not &nbsp;designed for that application and has serious limitations,
as the FCC CMSAAC &nbsp;studied.<br>
&nbsp;<br>
When it comes to the evolved packet core and IMS, &nbsp;again a point to point
solution &nbsp;will cause significant congestion on &nbsp;the network and a
broadcast/multicast solution must be used to effectively &nbsp;deliver alert
messages. Thus things like location and &#8220;priority&#8221; are already &nbsp;handled in
the delivery network.<br>
&nbsp;<br>
ATIS and 3GPP will be studying &nbsp;how to support multimedia alerts in the
future, as recommended by the FCC &nbsp;CMSAAC. This is all beyond the scope of
this work &nbsp;effort.<br>
&nbsp;<br>
Regards,<br>
Brian<br>
&nbsp;<br>
</span></font><font size=2 face=Consolas><span style='font-size:10.0pt;
font-family:Consolas'>Date: Thu, 25 Mar 2010 03:13:24 +0100<br>
From: &nbsp;&quot;DRAGE, Keith (Keith)&quot; &lt;<a
href="[email-masked]">[email-masked]</a>&gt;<br>
Subject: &nbsp;Re: [earlywarning] Updated Charter Text for ATOCA<br>
To: <st1:PersonName w:st="on">Hannes Tschofenig</st1:PersonName> &nbsp;&lt;<a
href="[email-masked]">[email-masked]</a>&gt;,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&quot;<a href="[email-masked]">[email-masked]</a>&quot;
&lt;<a href="[email-masked]">[email-masked]</a>&gt;<br>
Message-ID:<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;<a
href="[email-masked]">[email-masked]</a>&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
Content-Type: &nbsp;text/plain; charset=&quot;us-ascii&quot;<br>
&nbsp;<br>
What I am not seeing here is any &nbsp;separation of the problem from the one
that cell broadcast attempts to &nbsp;solve. Fundamentally, cell broadcast, as
exists on all GSM, UTRAN and &nbsp;E-UTRAN based cell phones and is being used
for Tsunami warning and Public &nbsp;Warning, exists and is not going to
substantially change. The major &nbsp;limitation here is is length of message,
and what does get transmitted will &nbsp;be very much dependent on that
restriction.<br>
&nbsp;<br>
Moreover I have &nbsp;heard from a number of governmental bodies that they are
happy with that &nbsp;situation and are not envisaging further standardisation
in that area &nbsp;outside of 3GPP.<br>
&nbsp;<br>
So my view at the moment is that there is no &nbsp;point in IETF trying to
address the scope of what is already specified in &nbsp;cell broadcast (from
base station to end &nbsp;mobile).<br>
&nbsp;<br>
regards<br>
&nbsp;<br>
Keith<br>
</span></font><font size=2 face=Calibri><span style='font-size:11.0pt;
font-family:Calibri'><br>
&nbsp;&nbsp;&nbsp; </span></font><o:p></o:p></p>

<p align=center style='text-align:center'><font size=2 face=Calibri><span
style='font-size:11.0pt;font-family:Calibri'><o:p>&nbsp;</o:p></span></font></p>

<div class=MsoNormal align=center style='text-align:center'><font size=2
face=Calibri><span style='font-size:11.0pt;font-family:Calibri'>

<hr size=3 width="95%" align=center>

</span></font></div>

<p class=MsoNormal><font size=2 face=Calibri><span style='font-size:11.0pt;
font-family:Calibri'>&nbsp; </span></font><o:p></o:p></p>

<p style='margin-bottom:12.0pt'><font size=2 face=Calibri><span
style='font-size:11.0pt;font-family:Calibri'><br>
</span></font><font size=2 face=Consolas><span style='font-size:10.0pt;
font-family:Consolas'>_______________________________________________<br>
earlywarning &nbsp;mailing list<br>
<a href="[email-masked]">[email-masked]</a><br>
<a href="https://www.ietf.org/mailman/listinfo/earlywarning">https://www.ietf.org/mailman/listinfo/earlywarning</a></span></font><o:p></o:p></p>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</div>

</div>

</body>

</html>

--_000_5A55A45AE77F5941B18E5457ECAC81880120DFB13539SISPE7MB1co_--

Content-class: urn:content-classes:message
Date: Thu, 25 Mar 2010 18:23:18 -0700
From: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
To: <[email-masked]>
Cc: "SENNETT, DEWAYNE A \(ATTCINW\)" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [earlywarning] (no subject)

This is a multi-part message in MIME format.

------_=_NextPart_001_01CACC82.EA8E2FB8
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64

------_=_NextPart_001_01CACC82.EA8E2FB8
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: base64

------_=_NextPart_001_01CACC82.EA8E2FB8--

Content-class: urn:content-classes:message
Date: Thu, 25 Mar 2010 18:20:55 -0700
From: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: [earlywarning] (no subject)

This is a multi-part message in MIME format.

------_=_NextPart_001_01CACC82.952733E4
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64

------_=_NextPart_001_01CACC82.952733E4
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: base64

------_=_NextPart_001_01CACC82.952733E4--

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 25 Mar 2010 21:20:23 -0400
To: "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] What problem is ATOCA trying to address?

--Apple-Mail-9--798552614
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii

> 
> So what item remains to be addressed by ATOCA?

Opt-in/opt-out mechanisms, for example.
--Apple-Mail-9--798552614
Content-Transfer-Encoding: 7bit
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><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font>So what item remains to be addressed by ATOCA?<br></div></blockquote></div><br><div>Opt-in/opt-out mechanisms, for example.</div></body></html>
--Apple-Mail-9--798552614--

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 25 Mar 2010 21:18:34 -0400
To: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
Cc: "SENNETT, DEWAYNE A \(ATTCINW\)" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [earlywarning] (no subject)

--Apple-Mail-8--798661472
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

I don't see how Internet-connected devices should somehow *not* receive IP alerts just because they happen to get their Internet connectivity via 3GPP. In many cases, such as the Sprint/VZ MiFi devices, they won't even know that they are. If there's a local regulatory regime that prohibits such delivery, that's not an IETF problem. As we discussed, such alerts are often also "elsewhere" and thus not replaceable by local L2 alerts. (The 'daughter' and 'vacation home' scenarios we discussed earlier this week and before.)

Henning

On Mar 25, 2010, at 9:06 PM, DALY, BRIAN K (ATTCINW) wrote:

> This is NOT silly Brian but serious when you consider the consequences to the networks.
> 
> We have a solution in place for devices connected to a 3GPP network - we are asking that this work exclude devices that support 3GPP PWS/CMAS (EPC and IMS) as those solutions as designed and optimized for the "layer 2" networks. We even have mobile device behavior specifications.
> 
> I propose we adopt the language in the charter.
> 
> Brian 
> Brian K. Daly 
> ------- 
> Sent from my Blackberry
> 
> From: Brian Rosen <[email-masked]> 
> To: SENNETT, DEWAYNE A (ATTCINW); DALY, BRIAN K (ATTCINW); [email-masked] <[email-masked]>; [email-masked] <[email-masked]> 
> Sent: Thu Mar 25 17:59:21 2010
> Subject: Re: [earlywarning] (no subject) 
> 
> I think this is silly.
> 
> No one is working on alert mechanisms that apply to the Internet.
> 
> The Internet is global, ubiquitous and independent of L2.  The proposed work applies to any kind of device connected to the Internet.  Whatever scale problems exist apply to all L2s one way or another.  They must be faced and solved for the work to be useful.  To exclude wireless IMS systems based on the notion that someone else is working on a system limited to cell broadcast is, in my opinion, not a good idea.
> 
> I do well understand that vendors and carriers don�t like multiple answers to the same problem.  I get that.  However, the IETF is the proper place to do work on alerts on the Internet, and should not exclude parts of the Internet.
> 
> Brian
> 
> 
> On 3/25/10 8:50 PM, "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]> wrote:
> 
> I propose that the following sentence be added to the ATOCA charter:
> 
> The ATOCA RFC's are not applicable to wireless devices which receive their connectivity via 3GPP EPC/IMS.
> 
> 
> 
> <---------------------------> 
> DeWayne Sennett, AT&T Services, Inc. 
> Sent from my BlackBerry
> 
> From: [email-masked] <[email-masked]> 
> To: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]> 
> Sent: Thu Mar 25 17:43:10 2010
> Subject: Re: [earlywarning] (no subject) 
> 
> Keith
> 
> You bring up a good point - we don't want to design a solution that will result in failure of the network, therefore I second DeWayne's proposal to exclude from the charter devices that support PWS (and CMAS under that umbrella) and to acknowledge this solution may result in network problems (e.g. Congestion).
> 
> Brian Daly 
> Brian K. Daly 
> ------- 
> Sent from my Blackberry
> 
> From: DRAGE, Keith (Keith) <[email-masked]> 
> To: Brian Rosen <[email-masked]>; DALY, BRIAN K (ATTCINW); [email-masked] <[email-masked]> 
> Sent: Thu Mar 25 17:35:30 2010
> Subject: RE: [earlywarning] (no subject) 
> 
> Yes those cellphones could well be connected to the internet.
> 
> But cell broadcast service exists on 3GPP phones. For alerts that are intended to hit a large proportion of the phones in any cell, it makes best use of the bandwidth.
> 
> You bring up an IP connection to all cellphones in that cell, and then broadcast warnings to all those cells, and the net result will be inappropriate loading of cells specifically for this traffic. Given that such warnings may otherwise create network stress as a result of the public warning being made in the first place, the first point of call for getting such warnings to cellphone uses has to be cell broadcast.
> 
> It appears that many governmental organisations have accepted cell broadcast as the desired means of delivering public warnings to cellphones.
> 
> Therefore any IETF activity has to acknowledge that solution exists for cellphones. 
> 
> Further I believe that any IETF solution has to specifically NOT convey the impression that for cellphones, the IETF solution is a good way forward for the warning itself. Users could well find the warnings from the IETF solution to an IP endpoint delivered well after the cell broadcast warning. And certainly the IETF solution should not expect priority over other types of traffic at that point, because at cell broadcast channel already exists to give that priority for the appropriate type of traffic.
> 
> regards
> 
> Keith
> 
> 
>  
> From: [email-masked]  [mailto:[email-masked]] On Behalf Of Brian  Rosen
> Sent: Friday, March 26, 2010 12:00 AM
> To: DALY,  BRIAN K (ATTCINW); [email-masked]
> Subject: Re: [earlywarning]  (no subject)
> 
>  
> Are they connected to the Internet?
> 
> If they  are, it would apply.  If they aren�t, then it wouldn�t  apply.
> 
> Brian
> 
> 
> On 3/25/10 7:51 PM, "DALY, BRIAN K (ATTCINW)"  <[email-masked]>  wrote:
> 
>  
> That will not apply to devices  connected to wireless cellular  networks.
>  
> 
> From: Brian Rosen [mailto:[email-masked]]  
> Sent: Thursday, March 25, 2010 4:50 PM
> To: DALY, BRIAN  K (ATTCINW); [email-masked]
> Subject:  Re: [earlywarning] (no subject)
> 
> Once  again, this is NOT about a solution limited to wireless cellular networks.   It is about a solution for internet connected endpoints of all kinds.   
> 
> Brian
> 
> 
> On 3/25/10 7:46 PM, "DALY, BRIAN K (ATTCINW)"  <[email-masked]> wrote:
> Keith � We  agree with you, and to further the point, in wireless cellular IP networks a  point to point solution would be problematic. Cell Broadcast is used for  CMAS because SMS cannot be used for any real time alerting � it was not  designed for that application and has serious limitations, as the FCC CMSAAC  studied.
>  
> When it comes to the evolved packet core and IMS,  again a point to point solution  will cause significant congestion on  the network and a broadcast/multicast solution must be used to effectively  deliver alert messages. Thus things like location and �priority� are already  handled in the delivery network.
>  
> ATIS and 3GPP will be studying  how to support multimedia alerts in the future, as recommended by the FCC  CMSAAC. This is all beyond the scope of this work  effort.
>  
> Regards,
> Brian
>  
> Date: Thu, 25 Mar 2010 03:13:24 +0100
> From:  "DRAGE, Keith (Keith)" <[email-masked]>
> Subject:  Re: [earlywarning] Updated Charter Text for ATOCA
> To: Hannes Tschofenig  <[email-masked]>,
>       "[email-masked]" <[email-masked]>
> Message-ID:
>       <[email-masked]>
>       
> Content-Type:  text/plain; charset="us-ascii"
>  
> What I am not seeing here is any  separation of the problem from the one that cell broadcast attempts to  solve. Fundamentally, cell broadcast, as exists on all GSM, UTRAN and  E-UTRAN based cell phones and is being used for Tsunami warning and Public  Warning, exists and is not going to substantially change. The major  limitation here is is length of message, and what does get transmitted will  be very much dependent on that restriction.
>  
> Moreover I have  heard from a number of governmental bodies that they are happy with that  situation and are not envisaging further standardisation in that area  outside of 3GPP.
>  
> So my view at the moment is that there is no  point in IETF trying to address the scope of what is already specified in  cell broadcast (from base station to end  mobile).
>  
> regards
>  
> Keith
> 
>    
> 
> 
>  
> 
> _______________________________________________
> earlywarning  mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning
> 
> 
> 
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

--Apple-Mail-8--798661472
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>I don't see how Internet-connected devices should somehow *not* receive IP alerts just because they happen to get their Internet connectivity via 3GPP. In many cases, such as the Sprint/VZ MiFi devices, they won't even know that they are. If there's a local regulatory regime that prohibits such delivery, that's not an IETF problem. As we discussed, such alerts are often also "elsewhere" and thus not replaceable by local L2 alerts. (The 'daughter' and 'vacation home' scenarios we discussed earlier this week and before.)</div><div><br></div><div>Henning</div><br><div><div>On Mar 25, 2010, at 9:06 PM, DALY, BRIAN K (ATTCINW) wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><div><font size="2" color="navy" face="Arial">
This is NOT silly Brian but serious when you consider the consequences to the networks.<br><br>We have a solution in place for devices connected to a 3GPP network - we are asking that this work exclude devices that support 3GPP PWS/CMAS (EPC and IMS)  as those solutions as designed and optimized for the "layer 2" networks. We even have mobile device behavior specifications.<br><br>I propose we adopt the language in the charter.<br><br>Brian
<br>Brian K. Daly
<br>-------
<br>Sent from my Blackberry</font></div>
<br><div><hr size="2" width="100%" align="center" tabindex="-1">
<font face="Tahoma" size="2">
<b>From</b>: Brian Rosen &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;
<br><b>To</b>: SENNETT, DEWAYNE A (ATTCINW); DALY, BRIAN K (ATTCINW); <a href="mailto:[email-masked]">[email-masked]</a> &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;; <a href="mailto:[email-masked]">[email-masked]</a> &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;
<br><b>Sent</b>: Thu Mar 25 17:59:21 2010<br><b>Subject</b>: Re: [earlywarning] (no subject)
<br></font><br></div>

<font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt">I think this is silly.<br>
<br>
No one is working on alert mechanisms that apply to the Internet.<br>
<br>
The Internet is global, ubiquitous and independent of L2. &nbsp;The proposed work applies to any kind of device connected to the Internet. &nbsp;Whatever scale problems exist apply to all L2s one way or another. &nbsp;They must be faced and solved for the work to be useful. &nbsp;To exclude wireless IMS systems based on the notion that someone else is working on a system limited to cell broadcast is, in my opinion, not a good idea.<br>
<br>
I do well understand that vendors and carriers don�t like multiple answers to the same problem. &nbsp;I get that. &nbsp;However, the IETF is the proper place to do work on alerts on the Internet, and should not exclude parts of the Internet.<br>
<br>
Brian<br>
<br>
<br>
On 3/25/10 8:50 PM, "SENNETT, DEWAYNE A (ATTCINW)" &lt;<a href="x-msg://375/[email-masked]">[email-masked]</a>&gt; wrote:<br>
<br>
</span></font><blockquote><span style="font-size:11pt"><font color="#000080"><font face="Arial">I propose that the following sentence be added to the ATOCA charter:<br>
<br>
The ATOCA RFC's are not applicable to wireless devices which receive their connectivity via 3GPP EPC/IMS.<br>
<br>
<br>
<br>
&lt;---------------------------&gt; <br>
DeWayne Sennett, AT&amp;T Services, Inc. <br>
Sent from my BlackBerry<br>
</font></font><font face="Calibri, Verdana, Helvetica, Arial"><br>
<hr align="CENTER" size="2" width="100%"></font><font face="Tahoma, Verdana, Helvetica, Arial"><b>From</b>: <a href="x-msg://375/[email-masked]">[email-masked]</a> &lt;<a href="x-msg://375/[email-masked]">[email-masked]</a>&gt; <br>
<b>To</b>: <a href="x-msg://375/[email-masked]">[email-masked]</a> &lt;<a href="x-msg://375/[email-masked]">[email-masked]</a>&gt;; <a href="x-msg://375/[email-masked]">[email-masked]</a> &lt;<a href="x-msg://375/[email-masked]">[email-masked]</a>&gt;; <a href="x-msg://375/[email-masked]">[email-masked]</a> &lt;<a href="x-msg://375/[email-masked]">[email-masked]</a>&gt; <br>
<b>Sent</b>: Thu Mar 25 17:43:10 2010<br>
<b>Subject</b>: Re: [earlywarning] (no subject) <br>
</font><font face="Calibri, Verdana, Helvetica, Arial"><br>
</font><font color="#000080"><font face="Arial">Keith<br>
<br>
You bring up a good point - we don't want to design a solution that will result in failure of the network, therefore I second DeWayne's proposal to exclude from the charter devices that support PWS (and CMAS under that umbrella) and to acknowledge this solution may result in network problems (e.g. Congestion).<br>
<br>
Brian Daly <br>
Brian K. Daly <br>
------- <br>
Sent from my Blackberry<br>
</font></font><font face="Calibri, Verdana, Helvetica, Arial"><br>
<hr align="CENTER" size="2" width="100%"></font><font face="Tahoma, Verdana, Helvetica, Arial"><b>From</b>: DRAGE, Keith (Keith) &lt;<a href="x-msg://375/[email-masked]">[email-masked]</a>&gt; <br>
<b>To</b>: Brian Rosen &lt;<a href="x-msg://375/[email-masked]">[email-masked]</a>&gt;; DALY, BRIAN K (ATTCINW); <a href="x-msg://375/[email-masked]">[email-masked]</a> &lt;<a href="x-msg://375/[email-masked]">[email-masked]</a>&gt; <br>
<b>Sent</b>: Thu Mar 25 17:35:30 2010<br>
<b>Subject</b>: RE: [earlywarning] (no subject) <br>
</font><font face="Calibri, Verdana, Helvetica, Arial"><br>
</font><font color="#0000FF"><font face="Arial">Yes those cellphones could well be connected to the internet.<br>
</font></font><font face="Calibri, Verdana, Helvetica, Arial"> <br>
</font><font color="#0000FF"><font face="Arial">But cell broadcast service exists on 3GPP phones. For alerts that are intended to hit a large proportion of the phones in any cell, it makes best use of the bandwidth.<br>
</font></font><font face="Calibri, Verdana, Helvetica, Arial"> <br>
</font><font color="#0000FF"><font face="Arial">You bring up an IP connection to all cellphones in that cell, and then broadcast warnings to all those cells, and the net result will be inappropriate loading of cells specifically for this traffic. Given that such warnings may otherwise create network stress as a result of the public warning being made in the first place, the first point of call for getting such warnings to cellphone uses has to be cell broadcast.<br>
</font></font><font face="Calibri, Verdana, Helvetica, Arial"> <br>
</font><font color="#0000FF"><font face="Arial">It appears that many governmental organisations have accepted cell broadcast as the desired means of delivering public warnings to cellphones.<br>
</font></font><font face="Calibri, Verdana, Helvetica, Arial"> <br>
</font><font color="#0000FF"><font face="Arial">Therefore any IETF activity has to acknowledge that solution exists for cellphones. <br>
</font></font><font face="Calibri, Verdana, Helvetica, Arial"> <br>
</font><font color="#0000FF"><font face="Arial">Further I believe that any IETF solution has to specifically NOT convey the impression that for cellphones, the IETF solution is a good way forward for the warning itself. Users could well find the warnings from the IETF solution to an IP endpoint delivered well after the cell broadcast warning. And certainly the IETF solution should not expect priority over other types of traffic at that point, because at cell broadcast channel already exists to give that priority for the appropriate type of traffic.<br>
</font></font><font face="Calibri, Verdana, Helvetica, Arial"> <br>
</font><font color="#0000FF"><font face="Arial">regards<br>
</font></font><font face="Calibri, Verdana, Helvetica, Arial"> <br>
</font><font color="#0000FF"><font face="Arial">Keith<br>
</font></font><font face="Calibri, Verdana, Helvetica, Arial"><br>
</font></span><blockquote><span style="font-size:11pt"><font face="Calibri, Verdana, Helvetica, Arial"> <br>
&nbsp;<br>
<hr align="CENTER" size="3" width="100%"> </font><font face="Tahoma, Verdana, Helvetica, Arial"><b>From:</b> <a href="x-msg://375/[email-masked]">[email-masked]</a> &nbsp;[<a href="mailto:[email-masked]">mailto:[email-masked]</a>] <b>On Behalf Of </b>Brian &nbsp;Rosen<br>
<b>Sent:</b> Friday, March 26, 2010 12:00 AM<br>
<b>To:</b> DALY, &nbsp;BRIAN K (ATTCINW); <a href="x-msg://375/[email-masked]">[email-masked]</a><br>
<b>Subject:</b> Re: [earlywarning] &nbsp;(no subject)<br>
</font><font face="Calibri, Verdana, Helvetica, Arial"><br>
&nbsp;<br>
Are they connected to the Internet?<br>
<br>
If they &nbsp;are, it would apply. &nbsp;If they aren�t, then it wouldn�t &nbsp;apply.<br>
<br>
Brian<br>
<br>
<br>
On 3/25/10 7:51 PM, "DALY, BRIAN K (ATTCINW)" &nbsp;&lt;<a href="x-msg://375/[email-masked]">[email-masked]</a>&gt; &nbsp;wrote:<br>
<br>
&nbsp;<br>
</font></span><blockquote><span style="font-size:11pt"><font face="Calibri, Verdana, Helvetica, Arial"><font color="#1F497D">That will not apply to devices &nbsp;connected to wireless cellular &nbsp;networks.<br>
&nbsp;<br>
</font><br>
</font></span><font size="2"><font face="Tahoma, Verdana, Helvetica, Arial"><span style="font-size:10pt"><b>From:</b> Brian Rosen [<a href="mailto:[email-masked]">mailto:[email-masked]</a>] &nbsp;<br>
<b>Sent:</b> Thursday, March 25, 2010 4:50 PM<br>
<b>To:</b> DALY, BRIAN &nbsp;K (ATTCINW); <a href="x-msg://375/[email-masked]">[email-masked]</a><br>
<b>Subject:</b> &nbsp;Re: [earlywarning] (no subject)<br>
</span></font></font><font face="Times New Roman"><span style="font-size:12pt"><br>
</span></font><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt">Once &nbsp;again, this is NOT about a solution limited to wireless cellular networks. &nbsp;&nbsp;It is about a solution for internet connected endpoints of all kinds. &nbsp;&nbsp;<br>
<br>
Brian<br>
<br>
<br>
On 3/25/10 7:46 PM, "DALY, BRIAN K (ATTCINW)" &nbsp;&lt;<a href="x-msg://375/[email-masked]">[email-masked]</a>&gt; wrote:<br>
Keith � We &nbsp;agree with you, and to further the point, in wireless cellular IP networks a &nbsp;point to point solution would be problematic. Cell Broadcast is used for &nbsp;CMAS because SMS cannot be used for any real time alerting � it was not &nbsp;designed for that application and has serious limitations, as the FCC CMSAAC &nbsp;studied.<br>
&nbsp;<br>
When it comes to the evolved packet core and IMS, &nbsp;again a point to point solution &nbsp;will cause significant congestion on &nbsp;the network and a broadcast/multicast solution must be used to effectively &nbsp;deliver alert messages. Thus things like location and �priority� are already &nbsp;handled in the delivery network.<br>
&nbsp;<br>
ATIS and 3GPP will be studying &nbsp;how to support multimedia alerts in the future, as recommended by the FCC &nbsp;CMSAAC. This is all beyond the scope of this work &nbsp;effort.<br>
&nbsp;<br>
Regards,<br>
Brian<br>
&nbsp;<br>
</span></font><font size="2"><font face="Consolas, Courier New, Courier"><span style="font-size:10pt">Date: Thu, 25 Mar 2010 03:13:24 +0100<br>
From: &nbsp;"DRAGE, Keith (Keith)" &lt;<a href="x-msg://375/[email-masked]">[email-masked]</a>&gt;<br>
Subject: &nbsp;Re: [earlywarning] Updated Charter Text for ATOCA<br>
To: Hannes Tschofenig &nbsp;&lt;<a href="x-msg://375/[email-masked]">[email-masked]</a>&gt;,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"<a href="x-msg://375/[email-masked]">[email-masked]</a>" &lt;<a href="x-msg://375/[email-masked]">[email-masked]</a>&gt;<br>
Message-ID:<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;<a href="x-msg://375/[email-masked]">[email-masked]</a>&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
Content-Type: &nbsp;text/plain; charset="us-ascii"<br>
&nbsp;<br>
What I am not seeing here is any &nbsp;separation of the problem from the one that cell broadcast attempts to &nbsp;solve. Fundamentally, cell broadcast, as exists on all GSM, UTRAN and &nbsp;E-UTRAN based cell phones and is being used for Tsunami warning and Public &nbsp;Warning, exists and is not going to substantially change. The major &nbsp;limitation here is is length of message, and what does get transmitted will &nbsp;be very much dependent on that restriction.<br>
&nbsp;<br>
Moreover I have &nbsp;heard from a number of governmental bodies that they are happy with that &nbsp;situation and are not envisaging further standardisation in that area &nbsp;outside of 3GPP.<br>
&nbsp;<br>
So my view at the moment is that there is no &nbsp;point in IETF trying to address the scope of what is already specified in &nbsp;cell broadcast (from base station to end &nbsp;mobile).<br>
&nbsp;<br>
regards<br>
&nbsp;<br>
Keith<br>
</span></font></font><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt"><br>
&nbsp;&nbsp;&nbsp;
</span></font><p align="CENTER">
<font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt"> <br>
</span></font></p><font face="Calibri, Verdana, Helvetica, Arial"><hr align="CENTER" size="3" width="95%"> &nbsp;
</font><p>
<font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt"><br>
</span></font><font size="2"><font face="Consolas, Courier New, Courier"><span style="font-size:10pt">_______________________________________________<br>
earlywarning &nbsp;mailing list<br>
<a href="x-msg://375/[email-masked]">[email-masked]</a><br>
<a href="https://www.ietf.org/mailman/listinfo/earlywarning">https://www.ietf.org/mailman/listinfo/earlywarning</a><br>
</span></font></font><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt"><br>
</span></font></p></blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt"><br>
</span></font></blockquote></blockquote>
</div>

_______________________________________________<br>earlywarning mailing list<br><a href="mailto:[email-masked]">[email-masked]</a><br>https://www.ietf.org/mailman/listinfo/earlywarning<br></blockquote></div><br></body></html>
--Apple-Mail-8--798661472--

Content-class: urn:content-classes:message
Date: Thu, 25 Mar 2010 18:18:34 -0700
From: "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]>
To: <[email-masked]>
Subject: [earlywarning] What problem is ATOCA trying to address?

From: "Winterbottom, James" <[email-masked]>
To: "DALY, BRIAN K (ATTCINW)" <[email-masked]>, "[email-masked]" <[email-masked]>, "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 26 Mar 2010 09:14:35 +0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [earlywarning] (no subject)

--_000_5A55A45AE77F5941B18E5457ECAC81880120DFB13537SISPE7MB1co_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Brian D,

We are increasingly seeing 3G hotspot devices, aka MiFi type devices. In this mode the devices using 3G as a backhaul are connected to the Internet and almost certainly do not have access to the underlying IMS services. Any solution needs to work in that environment too. I am interested to hear what you are proposing here.

Cheers
James

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of DALY, BRIAN K (ATTCINW)
Sent: Friday, 26 March 2010 12:07 PM
To: [email-masked]; SENNETT, DEWAYNE A (ATTCINW); [email-masked]; [email-masked]
Subject: Re: [earlywarning] (no subject)

This is NOT silly Brian but serious when you consider the consequences to the networks.

We have a solution in place for devices connected to a 3GPP network - we are asking that this work exclude devices that support 3GPP PWS/CMAS (EPC and IMS) as those solutions as designed and optimized for the "layer 2" networks. We even have mobile device behavior specifications.

I propose we adopt the language in the charter.

Brian
Brian K. Daly
-------
Sent from my Blackberry

________________________________
From: Brian Rosen <[email-masked]>
To: SENNETT, DEWAYNE A (ATTCINW); DALY, BRIAN K (ATTCINW); [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Sent: Thu Mar 25 17:59:21 2010
Subject: Re: [earlywarning] (no subject)
I think this is silly.

No one is working on alert mechanisms that apply to the Internet.

The Internet is global, ubiquitous and independent of L2.  The proposed work applies to any kind of device connected to the Internet.  Whatever scale problems exist apply to all L2s one way or another.  They must be faced and solved for the work to be useful.  To exclude wireless IMS systems based on the notion that someone else is working on a system limited to cell broadcast is, in my opinion, not a good idea.

I do well understand that vendors and carriers don't like multiple answers to the same problem.  I get that.  However, the IETF is the proper place to do work on alerts on the Internet, and should not exclude parts of the Internet.

Brian

On 3/25/10 8:50 PM, "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]> wrote:
I propose that the following sentence be added to the ATOCA charter:

The ATOCA RFC's are not applicable to wireless devices which receive their connectivity via 3GPP EPC/IMS.

<--------------------------->
DeWayne Sennett, AT&T Services, Inc.
Sent from my BlackBerry
________________________________
From: [email-masked] <[email-masked]>
To: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Sent: Thu Mar 25 17:43:10 2010
Subject: Re: [earlywarning] (no subject)

Keith

You bring up a good point - we don't want to design a solution that will result in failure of the network, therefore I second DeWayne's proposal to exclude from the charter devices that support PWS (and CMAS under that umbrella) and to acknowledge this solution may result in network problems (e.g. Congestion).

Brian Daly
Brian K. Daly
-------
Sent from my Blackberry
________________________________
From: DRAGE, Keith (Keith) <[email-masked]>
To: Brian Rosen <[email-masked]>; DALY, BRIAN K (ATTCINW); [email-masked] <[email-masked]>
Sent: Thu Mar 25 17:35:30 2010
Subject: RE: [earlywarning] (no subject)

Yes those cellphones could well be connected to the internet.

But cell broadcast service exists on 3GPP phones. For alerts that are intended to hit a large proportion of the phones in any cell, it makes best use of the bandwidth.

You bring up an IP connection to all cellphones in that cell, and then broadcast warnings to all those cells, and the net result will be inappropriate loading of cells specifically for this traffic. Given that such warnings may otherwise create network stress as a result of the public warning being made in the first place, the first point of call for getting such warnings to cellphone uses has to be cell broadcast.

It appears that many governmental organisations have accepted cell broadcast as the desired means of delivering public warnings to cellphones.

Therefore any IETF activity has to acknowledge that solution exists for cellphones.

Further I believe that any IETF solution has to specifically NOT convey the impression that for cellphones, the IETF solution is a good way forward for the warning itself. Users could well find the warnings from the IETF solution to an IP endpoint delivered well after the cell broadcast warning. And certainly the IETF solution should not expect priority over other types of traffic at that point, because at cell broadcast channel already exists to give that priority for the appropriate type of traffic.

regards

Keith

________________________________
From: [email-masked]  [mailto:[email-masked]] On Behalf Of Brian  Rosen
Sent: Friday, March 26, 2010 12:00 AM
To: DALY,  BRIAN K (ATTCINW); [email-masked]
Subject: Re: [earlywarning]  (no subject)

Are they connected to the Internet?

If they  are, it would apply.  If they aren't, then it wouldn't  apply.

Brian

On 3/25/10 7:51 PM, "DALY, BRIAN K (ATTCINW)"  <[email-masked]>  wrote:

That will not apply to devices  connected to wireless cellular  networks.

From: Brian Rosen [mailto:[email-masked]]
Sent: Thursday, March 25, 2010 4:50 PM
To: DALY, BRIAN  K (ATTCINW); [email-masked]
Subject:  Re: [earlywarning] (no subject)

Once  again, this is NOT about a solution limited to wireless cellular networks.   It is about a solution for internet connected endpoints of all kinds.

Brian

On 3/25/10 7:46 PM, "DALY, BRIAN K (ATTCINW)"  <[email-masked]> wrote:
Keith - We  agree with you, and to further the point, in wireless cellular IP networks a  point to point solution would be problematic. Cell Broadcast is used for  CMAS because SMS cannot be used for any real time alerting - it was not  designed for that application and has serious limitations, as the FCC CMSAAC  studied.

When it comes to the evolved packet core and IMS,  again a point to point solution  will cause significant congestion on  the network and a broadcast/multicast solution must be used to effectively  deliver alert messages. Thus things like location and "priority" are already  handled in the delivery network.

ATIS and 3GPP will be studying  how to support multimedia alerts in the future, as recommended by the FCC  CMSAAC. This is all beyond the scope of this work  effort.

Regards,
Brian

Date: Thu, 25 Mar 2010 03:13:24 +0100
From:  "DRAGE, Keith (Keith)" <[email-masked]>
Subject:  Re: [earlywarning] Updated Charter Text for ATOCA
To: Hannes Tschofenig  <[email-masked]>,
      "[email-masked]" <[email-masked]>
Message-ID:
      <[email-masked]>

Content-Type:  text/plain; charset="us-ascii"

What I am not seeing here is any  separation of the problem from the one that cell broadcast attempts to  solve. Fundamentally, cell broadcast, as exists on all GSM, UTRAN and  E-UTRAN based cell phones and is being used for Tsunami warning and Public  Warning, exists and is not going to substantially change. The major  limitation here is is length of message, and what does get transmitted will  be very much dependent on that restriction.

Moreover I have  heard from a number of governmental bodies that they are happy with that  situation and are not envisaging further standardisation in that area  outside of 3GPP.

So my view at the moment is that there is no  point in IETF trying to address the scope of what is already specified in  cell broadcast (from base station to end  mobile).

regards

Keith

________________________________

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

--_000_5A55A45AE77F5941B18E5457ECAC81880120DFB13537SISPE7MB1co_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:st1="urn:schemas-microsoft-com:office:smarttags" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>Re: [earlywarning] (no subject)</title>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
 name="PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
p.MsoList, li.MsoList, div.MsoList
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:14.15pt;
	margin-bottom:.0001pt;
	text-indent:-14.15pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman";}
p.Reference, li.Reference, div.Reference
	{margin-top:6.0pt;
	margin-right:0cm;
	margin-bottom:6.0pt;
	margin-left:36.85pt;
	text-indent:-19.0pt;
	mso-list:l0 level1 lfo3;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:891500023;
	mso-list-type:hybrid;
	mso-list-template-ids:172770280 1392555560 201916441 201916443 201916431 201916441 201916443 201916431 201916441 201916443;}
@list l0:level1
	{mso-level-style-link:Reference;
	mso-level-text:"\[%1\]";
	mso-level-tab-stop:36.85pt;
	mso-level-number-position:left;
	margin-left:36.85pt;
	text-indent:-19.0pt;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-AU link=blue vlink=blue>

<div class=Section1>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Brian D,<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>We are increasingly seeing 3G hotspot
devices, aka MiFi type devices. In this mode the devices using 3G as a backhaul
are connected to the Internet and almost certainly do not have access to the
underlying IMS services. Any solution needs to work in that environment too. I
am interested to hear what you are proposing here.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Cheers<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>James<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=MsoNormal><font size=3 color=navy face="Times New Roman"><span
style='font-size:12.0pt;color:navy'>&nbsp;</span></font><o:p></o:p></p>

</div>

<div style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'>

<div>

<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span lang=EN-US style='font-size:12.0pt'>

<hr size=2 width="100%" align=center tabindex=-1>

</span></font></div>

<p class=MsoNormal><b><font size=2 face=Tahoma><span lang=EN-US
style='font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</span></font></b><font
size=2 face=Tahoma><span lang=EN-US style='font-size:10.0pt;font-family:Tahoma'>
[email-masked] [mailto:[email-masked]] <b><span
style='font-weight:bold'>On Behalf Of </span></b>DALY, BRIAN K (ATTCINW)<br>
<b><span style='font-weight:bold'>Sent:</span></b> Friday, 26 March 2010 12:07
PM<br>
<b><span style='font-weight:bold'>To:</span></b> [email-masked]; SENNETT,
DEWAYNE A (ATTCINW); [email-masked]; [email-masked]<br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: [earlywarning] (no
subject)</span></font><span lang=EN-US><o:p></o:p></span></p>

</div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>This is NOT silly Brian but serious when
you consider the consequences to the networks.<br>
<br>
We have a solution in place for devices connected to a 3GPP network - we are
asking that this work exclude devices that support 3GPP PWS/CMAS (EPC and IMS)
as those solutions as designed and optimized for the &quot;layer 2&quot;
networks. We even have mobile device behavior specifications.<br>
<br>
I propose we adopt the language in the charter.<br>
<br>
Brian<br>
Brian K. Daly<br>
-------<br>
Sent from my Blackberry</span></font><o:p></o:p></p>

</div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>

<hr size=2 width="100%" align=center tabindex=-1>

</span></font></div>

<p class=MsoNormal style='margin-bottom:12.0pt'><b><font size=2 face=Tahoma><span
style='font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From</span></font></b><font
size=2 face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'>: <st1:PersonName
w:st="on">Brian Rosen</st1:PersonName> &lt;[email-masked]&gt;<br>
<b><span style='font-weight:bold'>To</span></b>: SENNETT, DEWAYNE A (ATTCINW);
DALY, BRIAN K (ATTCINW); [email-masked]
&lt;[email-masked]&gt;; [email-masked]
&lt;[email-masked]&gt;<br>
<b><span style='font-weight:bold'>Sent</span></b>: Thu Mar 25 17:59:21 2010<br>
<b><span style='font-weight:bold'>Subject</span></b>: Re: [earlywarning] (no
subject)</span></font><o:p></o:p></p>

</div>

<p class=MsoNormal style='margin-bottom:12.0pt'><font size=2 face=Calibri><span
style='font-size:11.0pt;font-family:Calibri'>I think this is silly.<br>
<br>
No one is working on alert mechanisms that apply to the Internet.<br>
<br>
The Internet is global, ubiquitous and independent of L2. &nbsp;The proposed
work applies to any kind of device connected to the Internet. &nbsp;Whatever
scale problems exist apply to all L2s one way or another. &nbsp;They must be
faced and solved for the work to be useful. &nbsp;To exclude wireless IMS
systems based on the notion that someone else is working on a system limited to
cell broadcast is, in my opinion, not a good idea.<br>
<br>
I do well understand that vendors and carriers don&#8217;t like multiple answers to
the same problem. &nbsp;I get that. &nbsp;However, the IETF is the proper place
to do work on alerts on the Internet, and should not exclude parts of the
Internet.<br>
<br>
Brian<br>
<br>
<br>
On 3/25/10 8:50 PM, &quot;SENNETT, DEWAYNE A (ATTCINW)&quot; &lt;<a
href="[email-masked]">[email-masked]</a>&gt; wrote:</span></font><o:p></o:p></p>

<p class=MsoNormal style='margin-bottom:12.0pt'><font size=2 color=navy
face=Arial><span style='font-size:11.0pt;font-family:Arial;color:navy'>I
propose that the following sentence be added to the ATOCA charter:<br>
<br>
The ATOCA RFC's are not applicable to wireless devices which receive their
connectivity via 3GPP EPC/IMS.<br>
<br>
<br>
<br>
&lt;---------------------------&gt; <br>
DeWayne Sennett, AT&amp;T Services, Inc. <br>
Sent from my BlackBerry</span></font><font size=2 face=Calibri><span
style='font-size:11.0pt;font-family:Calibri'><o:p></o:p></span></font></p>

<div class=MsoNormal align=center style='text-align:center'><font size=2
face=Calibri><span style='font-size:11.0pt;font-family:Calibri'>

<hr size=2 width="100%" align=center>

</span></font></div>

<p class=MsoNormal style='margin-bottom:12.0pt'><b><font size=2 face=Tahoma><span
style='font-size:11.0pt;font-family:Tahoma;font-weight:bold'>From</span></font></b><font
size=2 face=Tahoma><span style='font-size:11.0pt;font-family:Tahoma'>: <a
href="[email-masked]">[email-masked]</a> &lt;<a
href="[email-masked]">[email-masked]</a>&gt; <br>
<b><span style='font-weight:bold'>To</span></b>: <a
href="[email-masked]">[email-masked]</a> &lt;<a
href="[email-masked]">[email-masked]</a>&gt;; <a
href="[email-masked]">[email-masked]</a> &lt;<a href="[email-masked]">[email-masked]</a>&gt;;
<a href="[email-masked]">[email-masked]</a> &lt;<a
href="[email-masked]">[email-masked]</a>&gt; <br>
<b><span style='font-weight:bold'>Sent</span></b>: Thu Mar 25 17:43:10 2010<br>
<b><span style='font-weight:bold'>Subject</span></b>: Re: [earlywarning] (no
subject) <br>
</span></font><font size=2 face=Calibri><span style='font-size:11.0pt;
font-family:Calibri'><br>
</span></font><font size=2 color=navy face=Arial><span style='font-size:11.0pt;
font-family:Arial;color:navy'>Keith<br>
<br>
You bring up a good point - we don't want to design a solution that will result
in failure of the network, therefore I second DeWayne's proposal to exclude
from the charter devices that support PWS (and CMAS under that umbrella) and to
acknowledge this solution may result in network problems (e.g. Congestion).<br>
<br>
Brian Daly <br>
Brian K. Daly <br>
------- <br>
Sent from my Blackberry</span></font><font size=2 face=Calibri><span
style='font-size:11.0pt;font-family:Calibri'><o:p></o:p></span></font></p>

<div class=MsoNormal align=center style='text-align:center'><font size=2
face=Calibri><span style='font-size:11.0pt;font-family:Calibri'>

<hr size=2 width="100%" align=center>

</span></font></div>

<p class=MsoNormal style='margin-bottom:12.0pt'><b><font size=2 face=Tahoma><span
style='font-size:11.0pt;font-family:Tahoma;font-weight:bold'>From</span></font></b><font
size=2 face=Tahoma><span style='font-size:11.0pt;font-family:Tahoma'>: DRAGE,
Keith (Keith) &lt;<a href="[email-masked]">[email-masked]</a>&gt;
<br>
<b><span style='font-weight:bold'>To</span></b>: <st1:PersonName w:st="on">Brian
 Rosen</st1:PersonName> &lt;<a href="[email-masked]">[email-masked]</a>&gt;;
DALY, BRIAN K (ATTCINW); <a href="[email-masked]">[email-masked]</a>
&lt;<a href="[email-masked]">[email-masked]</a>&gt; <br>
<b><span style='font-weight:bold'>Sent</span></b>: Thu Mar 25 17:35:30 2010<br>
<b><span style='font-weight:bold'>Subject</span></b>: RE: [earlywarning] (no
subject) <br>
</span></font><font size=2 face=Calibri><span style='font-size:11.0pt;
font-family:Calibri'><br>
</span></font><font size=2 color=blue face=Arial><span style='font-size:11.0pt;
font-family:Arial;color:blue'>Yes those cellphones could well be connected to
the internet.<br>
</span></font><font size=2 face=Calibri><span style='font-size:11.0pt;
font-family:Calibri'><br>
</span></font><font size=2 color=blue face=Arial><span style='font-size:11.0pt;
font-family:Arial;color:blue'>But cell broadcast service exists on 3GPP phones.
For alerts that are intended to hit a large proportion of the phones in any
cell, it makes best use of the bandwidth.<br>
</span></font><font size=2 face=Calibri><span style='font-size:11.0pt;
font-family:Calibri'><br>
</span></font><font size=2 color=blue face=Arial><span style='font-size:11.0pt;
font-family:Arial;color:blue'>You bring up an IP connection to all cellphones
in that cell, and then broadcast warnings to all those cells, and the net
result will be inappropriate loading of cells specifically for this traffic.
Given that such warnings may otherwise create network stress as a result of the
public warning being made in the first place, the first point of call for
getting such warnings to cellphone uses has to be cell broadcast.<br>
</span></font><font size=2 face=Calibri><span style='font-size:11.0pt;
font-family:Calibri'><br>
</span></font><font size=2 color=blue face=Arial><span style='font-size:11.0pt;
font-family:Arial;color:blue'>It appears that many governmental organisations
have accepted cell broadcast as the desired means of delivering public warnings
to cellphones.<br>
</span></font><font size=2 face=Calibri><span style='font-size:11.0pt;
font-family:Calibri'><br>
</span></font><font size=2 color=blue face=Arial><span style='font-size:11.0pt;
font-family:Arial;color:blue'>Therefore any IETF activity has to acknowledge
that solution exists for cellphones. <br>
</span></font><font size=2 face=Calibri><span style='font-size:11.0pt;
font-family:Calibri'><br>
</span></font><font size=2 color=blue face=Arial><span style='font-size:11.0pt;
font-family:Arial;color:blue'>Further I believe that any IETF solution has to
specifically NOT convey the impression that for cellphones, the IETF solution
is a good way forward for the warning itself. Users could well find the
warnings from the IETF solution to an IP endpoint delivered well after the cell
broadcast warning. And certainly the IETF solution should not expect priority
over other types of traffic at that point, because at cell broadcast channel
already exists to give that priority for the appropriate type of traffic.<br>
</span></font><font size=2 face=Calibri><span style='font-size:11.0pt;
font-family:Calibri'><br>
</span></font><font size=2 color=blue face=Arial><span style='font-size:11.0pt;
font-family:Arial;color:blue'>regards<br>
</span></font><font size=2 face=Calibri><span style='font-size:11.0pt;
font-family:Calibri'><br>
</span></font><font size=2 color=blue face=Arial><span style='font-size:11.0pt;
font-family:Arial;color:blue'>Keith</span></font><o:p></o:p></p>

<p class=MsoNormal><font size=2 face=Calibri><span style='font-size:11.0pt;
font-family:Calibri'><br>
&nbsp;<o:p></o:p></span></font></p>

<div class=MsoNormal align=center style='text-align:center'><font size=2
face=Calibri><span style='font-size:11.0pt;font-family:Calibri'>

<hr size=3 width="100%" align=center>

</span></font></div>

<p class=MsoNormal><b><font size=2 face=Tahoma><span style='font-size:11.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=2
face=Tahoma><span style='font-size:11.0pt;font-family:Tahoma'> <a
href="[email-masked]">[email-masked]</a> &nbsp;[<a
href="mailto:[email-masked]">mailto:[email-masked]</a>]
<b><span style='font-weight:bold'>On Behalf Of </span></b>Brian &nbsp;Rosen<br>
<b><span style='font-weight:bold'>Sent:</span></b> Friday, March 26, 2010 12:00
AM<br>
<b><span style='font-weight:bold'>To:</span></b> DALY, &nbsp;BRIAN K (ATTCINW);
<a href="[email-masked]">[email-masked]</a><br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: [earlywarning]
&nbsp;(no subject)<br>
</span></font><font size=2 face=Calibri><span style='font-size:11.0pt;
font-family:Calibri'><br>
&nbsp;<br>
Are they connected to the Internet?<br>
<br>
If they &nbsp;are, it would apply. &nbsp;If they aren&#8217;t, then it wouldn&#8217;t
&nbsp;apply.<br>
<br>
Brian<br>
<br>
<br>
On 3/25/10 7:51 PM, &quot;DALY, BRIAN K (ATTCINW)&quot; &nbsp;&lt;<a
href="[email-masked]">[email-masked]</a>&gt; &nbsp;wrote:<br>
<br>
&nbsp;</span></font><o:p></o:p></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>That will not apply
to devices &nbsp;connected to wireless cellular &nbsp;networks.<br>
&nbsp;<br>
</span></font><font size=2 face=Calibri><span style='font-size:11.0pt;
font-family:Calibri'><br>
</span></font><b><font size=2 face=Tahoma><span style='font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=2
face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'> <st1:PersonName
w:st="on">Brian Rosen</st1:PersonName> [<a href="mailto:[email-masked]">mailto:[email-masked]</a>]
&nbsp;<br>
<b><span style='font-weight:bold'>Sent:</span></b> Thursday, March 25, 2010
4:50 PM<br>
<b><span style='font-weight:bold'>To:</span></b> DALY, BRIAN &nbsp;K (ATTCINW);
<a href="[email-masked]">[email-masked]</a><br>
<b><span style='font-weight:bold'>Subject:</span></b> &nbsp;Re: [earlywarning]
(no subject)<br>
</span></font><br>
<font size=2 face=Calibri><span style='font-size:11.0pt;font-family:Calibri'>Once
&nbsp;again, this is NOT about a solution limited to wireless cellular
networks. &nbsp;&nbsp;It is about a solution for internet connected endpoints
of all kinds. &nbsp;&nbsp;<br>
<br>
Brian<br>
<br>
<br>
On 3/25/10 7:46 PM, &quot;DALY, BRIAN K (ATTCINW)&quot; &nbsp;&lt;<a
href="[email-masked]">[email-masked]</a>&gt; wrote:<br>
Keith &#8211; We &nbsp;agree with you, and to further the point, in wireless cellular
IP networks a &nbsp;point to point solution would be problematic. Cell
Broadcast is used for &nbsp;CMAS because SMS cannot be used for any real time
alerting &#8211; it was not &nbsp;designed for that application and has serious
limitations, as the FCC CMSAAC &nbsp;studied.<br>
&nbsp;<br>
When it comes to the evolved packet core and IMS, &nbsp;again a point to point
solution &nbsp;will cause significant congestion on &nbsp;the network and a
broadcast/multicast solution must be used to effectively &nbsp;deliver alert
messages. Thus things like location and &#8220;priority&#8221; are already &nbsp;handled in
the delivery network.<br>
&nbsp;<br>
ATIS and 3GPP will be studying &nbsp;how to support multimedia alerts in the
future, as recommended by the FCC &nbsp;CMSAAC. This is all beyond the scope of
this work &nbsp;effort.<br>
&nbsp;<br>
Regards,<br>
Brian<br>
&nbsp;<br>
</span></font><font size=2 face=Consolas><span style='font-size:10.0pt;
font-family:Consolas'>Date: Thu, 25 Mar 2010 03:13:24 +0100<br>
From: &nbsp;&quot;DRAGE, Keith (Keith)&quot; &lt;<a
href="[email-masked]">[email-masked]</a>&gt;<br>
Subject: &nbsp;Re: [earlywarning] Updated Charter Text for ATOCA<br>
To: <st1:PersonName w:st="on">Hannes Tschofenig</st1:PersonName> &nbsp;&lt;<a
href="[email-masked]">[email-masked]</a>&gt;,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&quot;<a href="[email-masked]">[email-masked]</a>&quot;
&lt;<a href="[email-masked]">[email-masked]</a>&gt;<br>
Message-ID:<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;<a
href="[email-masked]">[email-masked]</a>&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
Content-Type: &nbsp;text/plain; charset=&quot;us-ascii&quot;<br>
&nbsp;<br>
What I am not seeing here is any &nbsp;separation of the problem from the one
that cell broadcast attempts to &nbsp;solve. Fundamentally, cell broadcast, as
exists on all GSM, UTRAN and &nbsp;E-UTRAN based cell phones and is being used
for Tsunami warning and Public &nbsp;Warning, exists and is not going to
substantially change. The major &nbsp;limitation here is is length of message,
and what does get transmitted will &nbsp;be very much dependent on that
restriction.<br>
&nbsp;<br>
Moreover I have &nbsp;heard from a number of governmental bodies that they are
happy with that &nbsp;situation and are not envisaging further standardisation
in that area &nbsp;outside of 3GPP.<br>
&nbsp;<br>
So my view at the moment is that there is no &nbsp;point in IETF trying to
address the scope of what is already specified in &nbsp;cell broadcast (from
base station to end &nbsp;mobile).<br>
&nbsp;<br>
regards<br>
&nbsp;<br>
Keith<br>
</span></font><font size=2 face=Calibri><span style='font-size:11.0pt;
font-family:Calibri'><br>
&nbsp;&nbsp;&nbsp; </span></font><o:p></o:p></p>

<p align=center style='text-align:center'><font size=2 face=Calibri><span
style='font-size:11.0pt;font-family:Calibri'><o:p>&nbsp;</o:p></span></font></p>

<div class=MsoNormal align=center style='text-align:center'><font size=2
face=Calibri><span style='font-size:11.0pt;font-family:Calibri'>

<hr size=3 width="95%" align=center>

</span></font></div>

<p class=MsoNormal><font size=2 face=Calibri><span style='font-size:11.0pt;
font-family:Calibri'>&nbsp; </span></font><o:p></o:p></p>

<p style='margin-bottom:12.0pt'><font size=2 face=Calibri><span
style='font-size:11.0pt;font-family:Calibri'><br>
</span></font><font size=2 face=Consolas><span style='font-size:10.0pt;
font-family:Consolas'>_______________________________________________<br>
earlywarning &nbsp;mailing list<br>
<a href="[email-masked]">[email-masked]</a><br>
<a href="https://www.ietf.org/mailman/listinfo/earlywarning">https://www.ietf.org/mailman/listinfo/earlywarning</a></span></font><o:p></o:p></p>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</div>

</body>

</html>

--_000_5A55A45AE77F5941B18E5457ECAC81880120DFB13537SISPE7MB1co_--

Date: Thu, 25 Mar 2010 20:14:53 -0500
To: "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]>, "DALY, BRIAN K (ATTCINW)" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
From: "James M. Polk" <[email-masked]>
Subject: Re: [earlywarning] (no subject)

At 07:50 PM 3/25/2010, SENNETT, DEWAYNE A (ATTCINW) wrote:
>Content-class: urn:content-classes:message
>Content-Type: multipart/alternative;
>         boundary="----_=_NextPart_001_01CACC7E.4EF366B7"
>
>I propose that the following sentence be added to the ATOCA charter:
>
>The ATOCA RFC's are not applicable to wireless 
>devices which receive their connectivity via 3GPP EPC/IMS.

3GPP, CDMA and CDMA200 are a cellular technologies.

IEEE's 802.11 specifications are wireless.

Would you have ATOCA's charter prevent dot11 Internet attached endpoints too?

What about 900MHz cordless phones?  (just kidding here)

Whatever is added has to be accurate. Simply 
sweeping in a "no wireless allowed" is foolishly flawed, IMO.

BTW - Haven't we had this discussion before?

James

><--------------------------->
>DeWayne Sennett, AT&T Services, Inc.
>Sent from my BlackBerry
>
>
>----------
>From: [email-masked] <[email-masked]>
>To: [email-masked] 
><[email-masked]>; 
>[email-masked] <[email-masked]>; 
>[email-masked] <[email-masked]>
>Sent: Thu Mar 25 17:43:10 2010
>Subject: Re: [earlywarning] (no subject)
>
>Keith
>
>You bring up a good point - we don't want to 
>design a solution that will result in failure of 
>the network, therefore I second DeWayne's 
>proposal to exclude from the charter devices 
>that support PWS (and CMAS under that umbrella) 
>and to acknowledge this solution may result in 
>network problems (e.g. Congestion).
>
>Brian Daly
>Brian K. Daly
>-------
>Sent from my Blackberry
>
>
>----------
>From: DRAGE, Keith (Keith) <[email-masked]>
>To: Brian Rosen <[email-masked]>; DALY, BRIAN 
>K (ATTCINW); [email-masked] <[email-masked]>
>Sent: Thu Mar 25 17:35:30 2010
>Subject: RE: [earlywarning] (no subject)
>
>Yes those cellphones could well be connected to the internet.
>
>But cell broadcast service exists on 3GPP 
>phones. For alerts that are intended to hit a 
>large proportion of the phones in any cell, it makes best use of the bandwidth.
>
>You bring up an IP connection to all cellphones 
>in that cell, and then broadcast warnings to all 
>those cells, and the net result will be 
>inappropriate loading of cells specifically for 
>this traffic. Given that such warnings may 
>otherwise create network stress as a result of 
>the public warning being made in the first 
>place, the first point of call for getting such 
>warnings to cellphone uses has to be cell broadcast.
>
>It appears that many governmental organisations 
>have accepted cell broadcast as the desired 
>means of delivering public warnings to cellphones.
>
>Therefore any IETF activity has to acknowledge 
>that solution exists for cellphones.
>
>Further I believe that any IETF solution has to 
>specifically NOT convey the impression that for 
>cellphones, the IETF solution is a good way 
>forward for the warning itself. Users could well 
>find the warnings from the IETF solution to an 
>IP endpoint delivered well after the cell 
>broadcast warning. And certainly the IETF 
>solution should not expect priority over other 
>types of traffic at that point, because at cell 
>broadcast channel already exists to give that 
>priority for the appropriate type of traffic.
>
>regards
>
>Keith
>
>
>----------
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Brian Rosen
>Sent: Friday, March 26, 2010 12:00 AM
>To: DALY, BRIAN K (ATTCINW); [email-masked]
>Subject: Re: [earlywarning] (no subject)
>
>Are they connected to the Internet?
>
>If they are, it would apply.  If they aren’t, then it wouldn’t apply.
>
>Brian
>
>
>On 3/25/10 7:51 PM, "DALY, BRIAN K (ATTCINW)" 
><<[email-masked]>[email-masked]> wrote:
>
>That will not apply to devices connected to wireless cellular networks.
>
>
>From: Brian Rosen [<mailto:[email-masked]>mailto:[email-masked]]
>Sent: Thursday, March 25, 2010 4:50 PM
>To: DALY, BRIAN K (ATTCINW); <[email-masked]>[email-masked]
>Subject: Re: [earlywarning] (no subject)
>
>Once again, this is NOT about a solution limited 
>to wireless cellular networks.  It is about a 
>solution for internet connected endpoints of all kinds.
>
>Brian
>
>
>On 3/25/10 7:46 PM, "DALY, BRIAN K (ATTCINW)" 
><<[email-masked]>[email-masked]> wrote:
>Keith � We agree with you, and to further tthe 
>point, in wireless cellular IP networks a point 
>to point solution would be problematic. Cell 
>Broadcast is used for CMAS because SMS cannot be 
>used for any real time alerting � it was not 
>designed for that application and has serious 
>limitations, as the FCC CMSAAC studied.
>
>When it comes to the evolved packet core and 
>IMS, again a point to point solution  will cause 
>significant congestion on the network and a 
>broadcast/multicast solution must be used to 
>effectively deliver alert messages. Thus things 
>like location and “priority” are already handled in the delivery network.
>
>ATIS and 3GPP will be studying how to support 
>multimedia alerts in the future, as recommended 
>by the FCC CMSAAC. This is all beyond the scope of this work effort.
>
>Regards,
>Brian
>
>Date: Thu, 25 Mar 2010 03:13:24 +0100
>From: "DRAGE, Keith (Keith)" 
><<[email-masked]>[email-masked]>
>Subject: Re: [earlywarning] Updated Charter Text for ATOCA
>To: Hannes Tschofenig <<[email-masked]>[email-masked]>,
> 
>"<[email-masked]>[email-masked]" 
><<[email-masked]>[email-masked]>
>Message-ID:
> 
><<[email-masked]>[email-masked]>
>
>Content-Type: text/plain; charset="us-ascii"
>
>What I am not seeing here is any separation of 
>the problem from the one that cell broadcast 
>attempts to solve. Fundamentally, cell 
>broadcast, as exists on all GSM, UTRAN and 
>E-UTRAN based cell phones and is being used for 
>Tsunami warning and Public Warning, exists and 
>is not going to substantially change. The major 
>limitation here is is length of message, and 
>what does get transmitted will be very much dependent on that restriction.
>
>Moreover I have heard from a number of 
>governmental bodies that they are happy with 
>that situation and are not envisaging further 
>standardisation in that area outside of 3GPP.
>
>So my view at the moment is that there is no 
>point in IETF trying to address the scope of 
>what is already specified in cell broadcast (from base station to end mobile).
>
>regards
>
>Keith
>
>
>
>
>
>_______________________________________________
>earlywarning mailing list
><[email-masked]>[email-masked]
>https://www.ietf.org/mailman/listinfo/earlywarning
>
>_______________________________________________
>earlywarning mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/earlywarning

Content-class: urn:content-classes:message
Date: Thu, 25 Mar 2010 18:06:30 -0700
To: <[email-masked]>, "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: [earlywarning] (no subject)

This is a multi-part message in MIME format.

------_=_NextPart_001_01CACC80.91DC964A
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64

------_=_NextPart_001_01CACC80.91DC964A
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: base64

------_=_NextPart_001_01CACC80.91DC964A--

Date: Thu, 25 Mar 2010 20:59:21 -0400
From: Brian Rosen <[email-masked]>
To: "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]>, "DALY, BRIAN K (ATTCINW)" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: [earlywarning] (no subject)

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3352395565_10108088
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

I think this is silly.

No one is working on alert mechanisms that apply to the Internet.

The Internet is global, ubiquitous and independent of L2.  The proposed work
applies to any kind of device connected to the Internet.  Whatever scale
problems exist apply to all L2s one way or another.  They must be faced and
solved for the work to be useful.  To exclude wireless IMS systems based on
the notion that someone else is working on a system limited to cell
broadcast is, in my opinion, not a good idea.

I do well understand that vendors and carriers don�t like multiple answers
to the same problem.  I get that.  However, the IETF is the proper place to
do work on alerts on the Internet, and should not exclude parts of the
Internet.

Brian

On 3/25/10 8:50 PM, "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]> wrote:

> I propose that the following sentence be added to the ATOCA charter:
> 
> The ATOCA RFC's are not applicable to wireless devices which receive their
> connectivity via 3GPP EPC/IMS.
> 
> 
> 
> <--------------------------->
> DeWayne Sennett, AT&T Services, Inc.
> Sent from my BlackBerry
> 
> 
> From: [email-masked] <[email-masked]>
> To: [email-masked] <[email-masked]>;
> [email-masked] <[email-masked]>; [email-masked]
> <[email-masked]>
> Sent: Thu Mar 25 17:43:10 2010
> Subject: Re: [earlywarning] (no subject)
> 
> Keith
> 
> You bring up a good point - we don't want to design a solution that will
> result in failure of the network, therefore I second DeWayne's proposal to
> exclude from the charter devices that support PWS (and CMAS under that
> umbrella) and to acknowledge this solution may result in network problems
> (e.g. Congestion).
> 
> Brian Daly 
> Brian K. Daly 
> ------- 
> Sent from my Blackberry
> 
> 
> From: DRAGE, Keith (Keith) <[email-masked]>
> To: Brian Rosen <[email-masked]>; DALY, BRIAN K (ATTCINW);
> [email-masked] <[email-masked]>
> Sent: Thu Mar 25 17:35:30 2010
> Subject: RE: [earlywarning] (no subject)
> 
> Yes those cellphones could well be connected to the internet.
>  
> But cell broadcast service exists on 3GPP phones. For alerts that are intended
> to hit a large proportion of the phones in any cell, it makes best use of the
> bandwidth.
>  
> You bring up an IP connection to all cellphones in that cell, and then
> broadcast warnings to all those cells, and the net result will be
> inappropriate loading of cells specifically for this traffic. Given that such
> warnings may otherwise create network stress as a result of the public warning
> being made in the first place, the first point of call for getting such
> warnings to cellphone uses has to be cell broadcast.
>  
> It appears that many governmental organisations have accepted cell broadcast
> as the desired means of delivering public warnings to cellphones.
>  
> Therefore any IETF activity has to acknowledge that solution exists for
> cellphones. 
>  
> Further I believe that any IETF solution has to specifically NOT convey the
> impression that for cellphones, the IETF solution is a good way forward for
> the warning itself. Users could well find the warnings from the IETF solution
> to an IP endpoint delivered well after the cell broadcast warning. And
> certainly the IETF solution should not expect priority over other types of
> traffic at that point, because at cell broadcast channel already exists to
> give that priority for the appropriate type of traffic.
>  
> regards
>  
> Keith
> 
>>  
>>  
>> 
>>  From: [email-masked]  [mailto:[email-masked]]
>> On Behalf Of Brian  Rosen
>> Sent: Friday, March 26, 2010 12:00 AM
>> To: DALY,  BRIAN K (ATTCINW); [email-masked]
>> Subject: Re: [earlywarning]  (no subject)
>> 
>>  
>> Are they connected to the Internet?
>> 
>> If they  are, it would apply.  If they aren�t, then it wouldn�t  apply.
>> 
>> Brian
>> 
>> 
>> On 3/25/10 7:51 PM, "DALY, BRIAN K (ATTCINW)"  <[email-masked]>  wrote:
>> 
>>  
>>> That will not apply to devices  connected to wireless cellular  networks.
>>>  
>>> 
>>> From: Brian Rosen [mailto:[email-masked]]
>>> Sent: Thursday, March 25, 2010 4:50 PM
>>> To: DALY, BRIAN  K (ATTCINW); [email-masked]
>>> Subject:  Re: [earlywarning] (no subject)
>>> 
>>> Once  again, this is NOT about a solution limited to wireless cellular
>>> networks.   It is about a solution for internet connected endpoints of all
>>> kinds.   
>>> 
>>> Brian
>>> 
>>> 
>>> On 3/25/10 7:46 PM, "DALY, BRIAN K (ATTCINW)"  <[email-masked]> wrote:
>>> Keith � We  agree with you, and to further the point, in wireless cellular
>>> IP networks a  point to point solution would be problematic. Cell Broadcast
>>> is used for  CMAS because SMS cannot be used for any real time alerting � it
>>> was not  designed for that application and has serious limitations, as the
>>> FCC CMSAAC  studied.
>>>  
>>> When it comes to the evolved packet core and IMS,  again a point to point
>>> solution  will cause significant congestion on  the network and a
>>> broadcast/multicast solution must be used to effectively  deliver alert
>>> messages. Thus things like location and �priority� are already  handled in
>>> the delivery network.
>>>  
>>> ATIS and 3GPP will be studying  how to support multimedia alerts in the
>>> future, as recommended by the FCC  CMSAAC. This is all beyond the scope of
>>> this work  effort.
>>>  
>>> Regards,
>>> Brian
>>>  
>>> Date: Thu, 25 Mar 2010 03:13:24 +0100
>>> From:  "DRAGE, Keith (Keith)" <[email-masked]>
>>> Subject:  Re: [earlywarning] Updated Charter Text for ATOCA
>>> To: Hannes Tschofenig  <[email-masked]>,
>>>       "[email-masked]" <[email-masked]>
>>> Message-ID:
>>>       
>>> <[email-masked]
>>> .com>
>>>       
>>> Content-Type:  text/plain; charset="us-ascii"
>>>  
>>> What I am not seeing here is any  separation of the problem from the one
>>> that cell broadcast attempts to  solve. Fundamentally, cell broadcast, as
>>> exists on all GSM, UTRAN and  E-UTRAN based cell phones and is being used
>>> for Tsunami warning and Public  Warning, exists and is not going to
>>> substantially change. The major  limitation here is is length of message,
>>> and what does get transmitted will  be very much dependent on that
>>> restriction.
>>>  
>>> Moreover I have  heard from a number of governmental bodies that they are
>>> happy with that  situation and are not envisaging further standardisation in
>>> that area  outside of 3GPP.
>>>  
>>> So my view at the moment is that there is no  point in IETF trying to
>>> address the scope of what is already specified in  cell broadcast (from base
>>> station to end  mobile).
>>>  
>>> regards
>>>  
>>> Keith
>>> 
>>>    
>>>  
>>> 
>>>   
>>> 
>>> _______________________________________________
>>> earlywarning  mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/earlywarning
>>> 
>>> 

--B_3352395565_10108088
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [earlywarning] (no subject)</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>I think this is silly.<BR>
<BR>
No one is working on alert mechanisms that apply to the Internet.<BR>
<BR>
The Internet is global, ubiquitous and independent of L2. &nbsp;The proposed work applies to any kind of device connected to the Internet. &nbsp;Whatever scale problems exist apply to all L2s one way or another. &nbsp;They must be faced and solved for the work to be useful. &nbsp;To exclude wireless IMS systems based on the notion that someone else is working on a system limited to cell broadcast is, in my opinion, not a good idea.<BR>
<BR>
I do well understand that vendors and carriers don&#8217;t like multiple answers to the same problem. &nbsp;I get that. &nbsp;However, the IETF is the proper place to do work on alerts on the Internet, and should not exclude parts of the Internet.<BR>
<BR>
Brian<BR>
<BR>
<BR>
On 3/25/10 8:50 PM, &quot;SENNETT, DEWAYNE A (ATTCINW)&quot; &lt;<a href="[email-masked]">[email-masked]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><SPAN STYLE='font-size:11pt'><FONT COLOR="#000080"><FONT FACE="Arial">I propose that the following sentence be added to the ATOCA charter:<BR>
<BR>
The ATOCA RFC's are not applicable to wireless devices which receive their connectivity via 3GPP EPC/IMS.<BR>
<BR>
<BR>
<BR>
&lt;---------------------------&gt; <BR>
DeWayne Sennett, AT&amp;T Services, Inc. <BR>
Sent from my BlackBerry<BR>
</FONT></FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial"><BR>
<HR ALIGN=CENTER SIZE="2" WIDTH="100%"></FONT><FONT FACE="Tahoma, Verdana, Helvetica, Arial"><B>From</B>: <a href="[email-masked]">[email-masked]</a> &lt;<a href="[email-masked]">[email-masked]</a>&gt; <BR>
<B>To</B>: <a href="[email-masked]">[email-masked]</a> &lt;<a href="[email-masked]">[email-masked]</a>&gt;; <a href="[email-masked]">[email-masked]</a> &lt;<a href="[email-masked]">[email-masked]</a>&gt;; <a href="[email-masked]">[email-masked]</a> &lt;<a href="[email-masked]">[email-masked]</a>&gt; <BR>
<B>Sent</B>: Thu Mar 25 17:43:10 2010<BR>
<B>Subject</B>: Re: [earlywarning] (no subject) <BR>
</FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial"><BR>
</FONT><FONT COLOR="#000080"><FONT FACE="Arial">Keith<BR>
<BR>
You bring up a good point - we don't want to design a solution that will result in failure of the network, therefore I second DeWayne's proposal to exclude from the charter devices that support PWS (and CMAS under that umbrella) and to acknowledge this solution may result in network problems (e.g. Congestion).<BR>
<BR>
Brian Daly <BR>
Brian K. Daly <BR>
------- <BR>
Sent from my Blackberry<BR>
</FONT></FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial"><BR>
<HR ALIGN=CENTER SIZE="2" WIDTH="100%"></FONT><FONT FACE="Tahoma, Verdana, Helvetica, Arial"><B>From</B>: DRAGE, Keith (Keith) &lt;<a href="[email-masked]">[email-masked]</a>&gt; <BR>
<B>To</B>: Brian Rosen &lt;<a href="[email-masked]">[email-masked]</a>&gt;; DALY, BRIAN K (ATTCINW); <a href="[email-masked]">[email-masked]</a> &lt;<a href="[email-masked]">[email-masked]</a>&gt; <BR>
<B>Sent</B>: Thu Mar 25 17:35:30 2010<BR>
<B>Subject</B>: RE: [earlywarning] (no subject) <BR>
</FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial"><BR>
</FONT><FONT COLOR="#0000FF"><FONT FACE="Arial">Yes those cellphones could well be connected to the internet.<BR>
</FONT></FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial"> <BR>
</FONT><FONT COLOR="#0000FF"><FONT FACE="Arial">But cell broadcast service exists on 3GPP phones. For alerts that are intended to hit a large proportion of the phones in any cell, it makes best use of the bandwidth.<BR>
</FONT></FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial"> <BR>
</FONT><FONT COLOR="#0000FF"><FONT FACE="Arial">You bring up an IP connection to all cellphones in that cell, and then broadcast warnings to all those cells, and the net result will be inappropriate loading of cells specifically for this traffic. Given that such warnings may otherwise create network stress as a result of the public warning being made in the first place, the first point of call for getting such warnings to cellphone uses has to be cell broadcast.<BR>
</FONT></FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial"> <BR>
</FONT><FONT COLOR="#0000FF"><FONT FACE="Arial">It appears that many governmental organisations have accepted cell broadcast as the desired means of delivering public warnings to cellphones.<BR>
</FONT></FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial"> <BR>
</FONT><FONT COLOR="#0000FF"><FONT FACE="Arial">Therefore any IETF activity has to acknowledge that solution exists for cellphones. <BR>
</FONT></FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial"> <BR>
</FONT><FONT COLOR="#0000FF"><FONT FACE="Arial">Further I believe that any IETF solution has to specifically NOT convey the impression that for cellphones, the IETF solution is a good way forward for the warning itself. Users could well find the warnings from the IETF solution to an IP endpoint delivered well after the cell broadcast warning. And certainly the IETF solution should not expect priority over other types of traffic at that point, because at cell broadcast channel already exists to give that priority for the appropriate type of traffic.<BR>
</FONT></FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial"> <BR>
</FONT><FONT COLOR="#0000FF"><FONT FACE="Arial">regards<BR>
</FONT></FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial"> <BR>
</FONT><FONT COLOR="#0000FF"><FONT FACE="Arial">Keith<BR>
</FONT></FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial"><BR>
</FONT></SPAN><BLOCKQUOTE><SPAN STYLE='font-size:11pt'><FONT FACE="Calibri, Verdana, Helvetica, Arial"> <BR>
&nbsp;<BR>
<HR ALIGN=CENTER SIZE="3" WIDTH="100%"> </FONT><FONT FACE="Tahoma, Verdana, Helvetica, Arial"><B>From:</B> <a href="[email-masked]">[email-masked]</a> &nbsp;[<a href="mailto:[email-masked]">mailto:[email-masked]</a>] <B>On Behalf Of </B>Brian &nbsp;Rosen<BR>
<B>Sent:</B> Friday, March 26, 2010 12:00 AM<BR>
<B>To:</B> DALY, &nbsp;BRIAN K (ATTCINW); <a href="[email-masked]">[email-masked]</a><BR>
<B>Subject:</B> Re: [earlywarning] &nbsp;(no subject)<BR>
</FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial"><BR>
&nbsp;<BR>
Are they connected to the Internet?<BR>
<BR>
If they &nbsp;are, it would apply. &nbsp;If they aren&#8217;t, then it wouldn&#8217;t &nbsp;apply.<BR>
<BR>
Brian<BR>
<BR>
<BR>
On 3/25/10 7:51 PM, &quot;DALY, BRIAN K (ATTCINW)&quot; &nbsp;&lt;<a href="[email-masked]">[email-masked]</a>&gt; &nbsp;wrote:<BR>
<BR>
&nbsp;<BR>
</FONT></SPAN><BLOCKQUOTE><SPAN STYLE='font-size:11pt'><FONT FACE="Calibri, Verdana, Helvetica, Arial"><FONT COLOR="#1F497D">That will not apply to devices &nbsp;connected to wireless cellular &nbsp;networks.<BR>
&nbsp;<BR>
</FONT><BR>
</FONT></SPAN><FONT SIZE="2"><FONT FACE="Tahoma, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:10pt'><B>From:</B> Brian Rosen [<a href="mailto:[email-masked]">mailto:[email-masked]</a>] &nbsp;<BR>
<B>Sent:</B> Thursday, March 25, 2010 4:50 PM<BR>
<B>To:</B> DALY, BRIAN &nbsp;K (ATTCINW); <a href="[email-masked]">[email-masked]</a><BR>
<B>Subject:</B> &nbsp;Re: [earlywarning] (no subject)<BR>
</SPAN></FONT></FONT><FONT FACE="Times New Roman"><SPAN STYLE='font-size:12pt'><BR>
</SPAN></FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Once &nbsp;again, this is NOT about a solution limited to wireless cellular networks. &nbsp;&nbsp;It is about a solution for internet connected endpoints of all kinds. &nbsp;&nbsp;<BR>
<BR>
Brian<BR>
<BR>
<BR>
On 3/25/10 7:46 PM, &quot;DALY, BRIAN K (ATTCINW)&quot; &nbsp;&lt;<a href="[email-masked]">[email-masked]</a>&gt; wrote:<BR>
Keith &#8211; We &nbsp;agree with you, and to further the point, in wireless cellular IP networks a &nbsp;point to point solution would be problematic. Cell Broadcast is used for &nbsp;CMAS because SMS cannot be used for any real time alerting &#8211; it was not &nbsp;designed for that application and has serious limitations, as the FCC CMSAAC &nbsp;studied.<BR>
&nbsp;<BR>
When it comes to the evolved packet core and IMS, &nbsp;again a point to point solution &nbsp;will cause significant congestion on &nbsp;the network and a broadcast/multicast solution must be used to effectively &nbsp;deliver alert messages. Thus things like location and &#8220;priority&#8221; are already &nbsp;handled in the delivery network.<BR>
&nbsp;<BR>
ATIS and 3GPP will be studying &nbsp;how to support multimedia alerts in the future, as recommended by the FCC &nbsp;CMSAAC. This is all beyond the scope of this work &nbsp;effort.<BR>
&nbsp;<BR>
Regards,<BR>
Brian<BR>
&nbsp;<BR>
</SPAN></FONT><FONT SIZE="2"><FONT FACE="Consolas, Courier New, Courier"><SPAN STYLE='font-size:10pt'>Date: Thu, 25 Mar 2010 03:13:24 +0100<BR>
From: &nbsp;&quot;DRAGE, Keith (Keith)&quot; &lt;<a href="[email-masked]">[email-masked]</a>&gt;<BR>
Subject: &nbsp;Re: [earlywarning] Updated Charter Text for ATOCA<BR>
To: Hannes Tschofenig &nbsp;&lt;<a href="[email-masked]">[email-masked]</a>&gt;,<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&quot;<a href="[email-masked]">[email-masked]</a>&quot; &lt;<a href="[email-masked]">[email-masked]</a>&gt;<BR>
Message-ID:<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;<a href="[email-masked]">[email-masked]</a>&gt;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
Content-Type: &nbsp;text/plain; charset=&quot;us-ascii&quot;<BR>
&nbsp;<BR>
What I am not seeing here is any &nbsp;separation of the problem from the one that cell broadcast attempts to &nbsp;solve. Fundamentally, cell broadcast, as exists on all GSM, UTRAN and &nbsp;E-UTRAN based cell phones and is being used for Tsunami warning and Public &nbsp;Warning, exists and is not going to substantially change. The major &nbsp;limitation here is is length of message, and what does get transmitted will &nbsp;be very much dependent on that restriction.<BR>
&nbsp;<BR>
Moreover I have &nbsp;heard from a number of governmental bodies that they are happy with that &nbsp;situation and are not envisaging further standardisation in that area &nbsp;outside of 3GPP.<BR>
&nbsp;<BR>
So my view at the moment is that there is no &nbsp;point in IETF trying to address the scope of what is already specified in &nbsp;cell broadcast (from base station to end &nbsp;mobile).<BR>
&nbsp;<BR>
regards<BR>
&nbsp;<BR>
Keith<BR>
</SPAN></FONT></FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
&nbsp;&nbsp;&nbsp;
</SPAN></FONT>
<P ALIGN=CENTER>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'> <BR>
<HR ALIGN=CENTER SIZE="3" WIDTH="95%"> &nbsp;
</SPAN></FONT>
<P>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
</SPAN></FONT><FONT SIZE="2"><FONT FACE="Consolas, Courier New, Courier"><SPAN STYLE='font-size:10pt'>_______________________________________________<BR>
earlywarning &nbsp;mailing list<BR>
<a href="[email-masked]">[email-masked]</a><BR>
<a href="https://www.ietf.org/mailman/listinfo/earlywarning">https://www.ietf.org/mailman/listinfo/earlywarning</a><BR>
</SPAN></FONT></FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
</SPAN></FONT></BLOCKQUOTE></BLOCKQUOTE>
</BODY>
</HTML>

--B_3352395565_10108088--

From: "DRAGE, Keith (Keith)" <[email-masked]>
To: Marc Linsner <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 26 Mar 2010 01:56:24 +0100
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [earlywarning] Updated Charter Text for ATOCA

It is not such a simple answer as that. Cell broadcast has been available in phones from pretty much the stone age (GSM phase 2, i.e. the 1995 release). Particular values as now assigned are defined as settable by the network if appropriate, i.e. they can be turned on by the network. For unassigned values they can generally be settable by the user, up to the range of values supported on that phone. So if I have a phone where the MMI can handle message IDs above a 1000, the users themselves can be turned on for CMAS cell broadcasts. Some existing phones are able to do this, others are not.

Moreover phones conforming to release 8 and release 9 will generally tend to have much more flexibility in this area, as while message identifiers are still being assigned, the general knowledge that such message identifiers will exist and have to be handled will be well known by the phone manufacturers.

regards

Keith

> -----Original Message-----
> From: Marc Linsner [mailto:[email-masked]] 
> Sent: Thursday, March 25, 2010 6:29 AM
> To: DRAGE, Keith (Keith); [email-masked]
> Subject: Re: [earlywarning] Updated Charter Text for ATOCA
> 
> Keith,
> 
> In-line....
> 
> On 3/24/10 7:13 PM, "DRAGE, Keith (Keith)" 
> <[email-masked]>
> wrote:
> 
> > What I am not seeing here is any separation of the problem from the 
> > one that cell broadcast attempts to solve. Fundamentally, cell 
> > broadcast, as exists on all GSM, UTRAN and E-UTRAN based 
> cell phones 
> > and is being used for Tsunami warning and Public Warning, 
> exists and is not going to substantially change.
> > The major limitation here is is length of message, and what 
> does get 
> > transmitted will be very much dependent on that restriction.
> 
> I thought the US CMAS required new handsets? (cell broadcast 
> is not enabled in the handset)
> 
> > 
> > Moreover I have heard from a number of governmental bodies 
> that they 
> > are happy with that situation and are not envisaging further 
> > standardisation in that area outside of 3GPP.
> > 
> > So my view at the moment is that there is no point in IETF 
> trying to 
> > address the scope of what is already specified in cell 
> broadcast (from 
> > base station to end mobile).
> 
> That's one way to get rid of WiMAX.  Don't warn WiMAX users 
> when the next
> Tsunami is coming.   :^)
> 
> -Marc-
> 
> > 
> > regards
> > 
> > Keith
> > 
> > 
> > 
> >> -----Original Message-----
> >> From: [email-masked]
> >> [mailto:[email-masked]] On Behalf Of Hannes 
> Tschofenig
> >> Sent: Wednesday, March 24, 2010 9:37 PM
> >> To: [email-masked]
> >> Subject: [earlywarning] Updated Charter Text for ATOCA
> >> 
> >> .... a minor update
> >> 
> >> Authority to Citizen Alert (ATOCA)
> >> ==================================
> >> 
> >> Authorities need mechanisms to notify citizens and visitors of 
> >> emergency
> >> events.   Traditionally, they have done so with broadcast
> >> networks (radio
> >> and television).  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. The goal of this group is not to 
> >> specify how originators of alerts obtain authorization, but rather 
> >> how a messaging system can verify authorization and 
> deliver message 
> >> to the intended recipients.
> >> A critical element of the work arethe mechanisms that assure that 
> >> only authorized agents can send alerts.
> >> 
> >> The recipients of these alerts are the wide range of devices 
> >> connected to the Internet and 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), but the initial work in 
> the group 
> >> is focused on small messages, which may be mechanically 
> rendered by 
> >> thedevice in other forms (text to speech for example).  In 
> situations 
> >> of a major emergency there could be scenarios where there are 
> >> multiple alerts generated that may require that a priority 
> mechanism 
> >> has to be implemented, and this mechanism is out of scope at his 
> >> time.
> >> 
> >> 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 affected by the alert.  In many jurisdictions, there are 
> >> regulations that define whether recipients within the 
> affected area 
> >> have opt-in or opt-out capability, but the protocols we 
> 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.
> >> 
> >> Another class of recipients that are in scope of the work are 
> >> explicit opt-in subscriptions which ask for alerts for a specified 
> >> location.
> >> An example of such a subscription would be 'send me alerts for 
> >> location x' (previously determined as the location of interest).
> >> This work builds on existing IETF geopriv location work.
> >> 
> >> There are other efforts in other fora on alerts, 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.  
> >> 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.
> >> Of course, existing protocols for delivering messages (e.g.,
> >> SIP) will be the basis for the message delivery system of this 
> >> working group.
> >> 
> >> 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.
> >> 
> >> Milestones
> >>  
> >> TBD      Initial document for "Terminology and Framework" document.
> >>          A starting point for this work is
> >>          draft-norreys-ecrit-authority2individuals-requirements.
> >> TBD      Initial document for conveying alerts in SIP
> >> TBD      Initial document for subscribing to alerts using SIP
> >>          A starting point for this work is draft-rosen-sipping-cap
> >> TBD      Initial document for locating the alerting server
> >> for a geographic
> >>          region. A starting point for this work is
> >>          draft-rosen-ecrit-lost-early-warning.
> >> 
> >> _______________________________________________
> >> earlywarning mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/earlywarning
> >> 
> > _______________________________________________
> > earlywarning mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/earlywarning
> 
> 
> 

Content-class: urn:content-classes:message
Date: Thu, 25 Mar 2010 17:50:19 -0700
From: "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]>
To: "DALY, BRIAN K (ATTCINW)" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: [earlywarning] (no subject)

This is a multi-part message in MIME format.

------_=_NextPart_001_01CACC7E.4EF366B7
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: base64

------_=_NextPart_001_01CACC7E.4EF366B7
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: base64

------_=_NextPart_001_01CACC7E.4EF366B7--

Content-class: urn:content-classes:message
Date: Thu, 25 Mar 2010 17:46:11 -0700
To: <[email-masked]>, <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [earlywarning] Updated Charter Text for ATOCA

Content-class: urn:content-classes:message
Date: Thu, 25 Mar 2010 17:43:10 -0700
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: [earlywarning] (no subject)

This is a multi-part message in MIME format.

------_=_NextPart_001_01CACC7D.4F67ECA4
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64

------_=_NextPart_001_01CACC7D.4F67ECA4
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: base64

------_=_NextPart_001_01CACC7D.4F67ECA4--

From: "DRAGE, Keith (Keith)" <[email-masked]>
To: Richard Barnes <[email-masked]>
Date: Fri, 26 Mar 2010 01:40:59 +0100
Accept-Language: en-US
acceptlanguage: en-US
Cc: Hannes Tschofenig <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [earlywarning] Updated Charter Text for ATOCA

No I have not said that.

I am saying that it is not the solution for cellphone users using 3GPP technology.

Keith 

> -----Original Message-----
> From: Richard Barnes [mailto:[email-masked]] 
> Sent: Thursday, March 25, 2010 2:16 AM
> To: DRAGE, Keith (Keith)
> Cc: Hannes Tschofenig; [email-masked]
> Subject: Re: [earlywarning] Updated Charter Text for ATOCA
> 
> So Keith, do you think that emergency notifications should 
> not be available on any other network?
> 
> Even if you use cell broadcast, there's a need for a 
> distribution architecture, as the US CMAS demonstrates.
> 
> --Richard
> 
> 
> 
> On Mar 24, 2010, at 7:13 PM, DRAGE, Keith (Keith) wrote:
> 
> > What I am not seeing here is any separation of the problem from the 
> > one that cell broadcast attempts to solve. Fundamentally, cell 
> > broadcast, as exists on all GSM, UTRAN and E-UTRAN based 
> cell phones 
> > and is being used for Tsunami warning and Public Warning, 
> exists and 
> > is not going to substantially change. The major limitation 
> here is is 
> > length of message, and what does get transmitted will be very much 
> > dependent on that restriction.
> >
> > Moreover I have heard from a number of governmental bodies 
> that they 
> > are happy with that situation and are not envisaging further 
> > standardisation in that area outside of 3GPP.
> >
> > So my view at the moment is that there is no point in IETF 
> trying to 
> > address the scope of what is already specified in cell 
> broadcast (from 
> > base station to end mobile).
> >
> > regards
> >
> > Keith
> >
> >
> >
> >> -----Original Message-----
> >> From: [email-masked]
> >> [mailto:[email-masked]] On Behalf Of Hannes 
> Tschofenig
> >> Sent: Wednesday, March 24, 2010 9:37 PM
> >> To: [email-masked]
> >> Subject: [earlywarning] Updated Charter Text for ATOCA
> >>
> >> .... a minor update
> >>
> >> Authority to Citizen Alert (ATOCA)
> >> ==================================
> >>
> >> Authorities need mechanisms to notify citizens and visitors of 
> >> emergency
> >> events.   Traditionally, they have done so with broadcast
> >> networks (radio
> >> and television).  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. The goal of this group is not to 
> >> specify how originators of alerts obtain authorization, but rather 
> >> how a messaging system can verify authorization and 
> deliver message 
> >> to the intended recipients.
> >> A critical element of the work arethe mechanisms that assure that 
> >> only authorized agents can send alerts.
> >>
> >> The recipients of these alerts are the wide range of devices 
> >> connected to the Internet and 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), but the initial work in 
> the group 
> >> is focused on small messages, which may be mechanically 
> rendered by 
> >> thedevice in other forms (text to speech for example).  In 
> situations 
> >> of a major emergency there could be scenarios where there are 
> >> multiple alerts generated that may require that a priority 
> mechanism 
> >> has to be implemented, and this mechanism is out of scope at his 
> >> time.
> >>
> >> 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 affected by the alert.  In many jurisdictions, there are 
> >> regulations that define whether recipients within the 
> affected area 
> >> have opt-in or opt-out capability, but the protocols we 
> 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.
> >>
> >> Another class of recipients that are in scope of the work are 
> >> explicit opt-in subscriptions which ask for alerts for a specified 
> >> location.
> >> An example of such a subscription would be 'send me alerts for 
> >> location x' (previously determined as the location of interest).
> >> This work builds on existing IETF geopriv location work.
> >>
> >> There are other efforts in other fora on alerts, 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.  
> >> 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.
> >> Of course, existing protocols for delivering messages (e.g.,
> >> SIP) will be the basis for the message delivery system of this 
> >> working group.
> >>
> >> 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.
> >>
> >> Milestones
> >>
> >> TBD      Initial document for "Terminology and Framework" document.
> >>         A starting point for this work is
> >>         draft-norreys-ecrit-authority2individuals-requirements.
> >> TBD      Initial document for conveying alerts in SIP
> >> TBD      Initial document for subscribing to alerts using SIP
> >>         A starting point for this work is draft-rosen-sipping-cap
> >> TBD      Initial document for locating the alerting server
> >> for a geographic
> >>         region. A starting point for this work is
> >>         draft-rosen-ecrit-lost-early-warning.
> >>
> >> _______________________________________________
> >> earlywarning mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/earlywarning
> >>
> > _______________________________________________
> > earlywarning mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/earlywarning
> 
> 

Content-class: urn:content-classes:message
Date: Thu, 25 Mar 2010 17:37:01 -0700
From: "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]>
To: <[email-masked]>, "DALY, BRIAN K (ATTCINW)" <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] (no subject)

This is a multi-part message in MIME format.

------_=_NextPart_001_01CACC7C.7376CBB1
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: base64

------_=_NextPart_001_01CACC7C.7376CBB1
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: base64

------_=_NextPart_001_01CACC7C.7376CBB1--

From: "DRAGE, Keith (Keith)" <[email-masked]>
To: Brian Rosen <[email-masked]>, "DALY, BRIAN K (ATTCINW)" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 26 Mar 2010 01:35:30 +0100
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [earlywarning] (no subject)

--_000_EDC0A1AE77C57744B664A310A0B23AE20D163BF6FRMRSSXCHMBSC3d_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Yes those cellphones could well be connected to the internet.

But cell broadcast service exists on 3GPP phones. For alerts that are intended to hit a large proportion of the phones in any cell, it makes best use of the bandwidth.

You bring up an IP connection to all cellphones in that cell, and then broadcast warnings to all those cells, and the net result will be inappropriate loading of cells specifically for this traffic. Given that such warnings may otherwise create network stress as a result of the public warning being made in the first place, the first point of call for getting such warnings to cellphone uses has to be cell broadcast.

It appears that many governmental organisations have accepted cell broadcast as the desired means of delivering public warnings to cellphones.

Therefore any IETF activity has to acknowledge that solution exists for cellphones.

Further I believe that any IETF solution has to specifically NOT convey the impression that for cellphones, the IETF solution is a good way forward for the warning itself. Users could well find the warnings from the IETF solution to an IP endpoint delivered well after the cell broadcast warning. And certainly the IETF solution should not expect priority over other types of traffic at that point, because at cell broadcast channel already exists to give that priority for the appropriate type of traffic.

regards

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Friday, March 26, 2010 12:00 AM
To: DALY, BRIAN K (ATTCINW); [email-masked]
Subject: Re: [earlywarning] (no subject)

Are they connected to the Internet?

If they are, it would apply.  If they aren�t, then it wouldn�t apply.

Brian

On 3/25/10 7:51 PM, "DALY, BRIAN K (ATTCINW)" <[email-masked]> wrote:

That will not apply to devices connected to wireless cellular networks.

From: Brian Rosen [mailto:[email-masked]]
Sent: Thursday, March 25, 2010 4:50 PM
To: DALY, BRIAN K (ATTCINW); [email-masked]
Subject: Re: [earlywarning] (no subject)

Once again, this is NOT about a solution limited to wireless cellular networks.  It is about a solution for internet connected endpoints of all kinds.

Brian

On 3/25/10 7:46 PM, "DALY, BRIAN K (ATTCINW)" <[email-masked]> wrote:
Keith � We agree with you, and to further the point, in wireless cellular IP networks a point to point solution would be problematic. Cell Broadcast is used for CMAS because SMS cannot be used for any real time alerting � it was not designed for that application and has serious limitations, as the FCC CMSAAC studied.

When it comes to the evolved packet core and IMS, again a point to point solution  will cause significant congestion on the network and a broadcast/multicast solution must be used to effectively deliver alert messages. Thus things like location and �priority� are already handled in the delivery network.

ATIS and 3GPP will be studying how to support multimedia alerts in the future, as recommended by the FCC CMSAAC. This is all beyond the scope of this work effort.

Regards,
Brian

Date: Thu, 25 Mar 2010 03:13:24 +0100
From: "DRAGE, Keith (Keith)" <[email-masked]>
Subject: Re: [earlywarning] Updated Charter Text for ATOCA
To: Hannes Tschofenig <[email-masked]>,
      "[email-masked]" <[email-masked]>
Message-ID:
      <[email-masked]>

Content-Type: text/plain; charset="us-ascii"

What I am not seeing here is any separation of the problem from the one that cell broadcast attempts to solve. Fundamentally, cell broadcast, as exists on all GSM, UTRAN and E-UTRAN based cell phones and is being used for Tsunami warning and Public Warning, exists and is not going to substantially change. The major limitation here is is length of message, and what does get transmitted will be very much dependent on that restriction.

Moreover I have heard from a number of governmental bodies that they are happy with that situation and are not envisaging further standardisation in that area outside of 3GPP.

So my view at the moment is that there is no point in IETF trying to address the scope of what is already specified in cell broadcast (from base station to end mobile).

regards

Keith

________________________________

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

--_000_EDC0A1AE77C57744B664A310A0B23AE20D163BF6FRMRSSXCHMBSC3d_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Re: [earlywarning] (no subject)</TITLE>
<META http-equiv=Content-Type content="text/html; charset=Windows-1252">
<META content="MSHTML 6.00.2900.3660" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left>
<DIV dir=ltr align=left><SPAN class=250340000-26032010><FONT face=Arial 
color=#0000ff size=2><SPAN class=225353300-26032010>Yes those cellphones could 
well be connected to the internet.</SPAN></FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=250340000-26032010><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=250340000-26032010><FONT face=Arial><FONT 
color=#0000ff><FONT size=2><SPAN class=225353300-26032010>But c</SPAN>ell 
broadcast service exists on 3GPP phones. For alerts that are intended to hit a 
large proportion of the phones in any cell, it makes best use of the 
bandwidth.</FONT></FONT></FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=250340000-26032010><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=250340000-26032010><FONT face=Arial 
color=#0000ff size=2>You bring up an IP connection to all cellphones in that 
cell, and then broadcast warnings to all those cells, and the net result will be 
inappropriate loading of cells specifically for this traffic. Given that such 
warnings may otherwise create network stress as a result of the public warning 
being made in the first place, the first point of call&nbsp;<SPAN 
class=225353300-26032010>for </SPAN>getting such warnings to cellphone uses has 
to be cell broadcast.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=250340000-26032010><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=250340000-26032010><FONT face=Arial 
color=#0000ff size=2>It appears that many governmental organisations have 
accepted cell broadcast as the desired means of delivering public warnings to 
cellphones.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=250340000-26032010><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=250340000-26032010><FONT face=Arial 
color=#0000ff size=2>Therefore any IETF activity has to acknowledge that 
solution exists for cellphones. </FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=250340000-26032010><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=250340000-26032010><FONT face=Arial 
color=#0000ff size=2>Further I believe that any IETF solution has to&nbsp;<SPAN 
class=225353300-26032010>specifically&nbsp;</SPAN><SPAN 
class=225353300-26032010>NOT </SPAN>convey the impression that for cellphones, 
the IETF solution is a good way forward for the warning itself. Users could well 
find the warnings from the IETF solution to an IP endpoint delivered well after 
the cell broadcast warning. And certainly the IETF solution should not expect 
priority over other types of traffic at that point, because at cell broadcast 
channel already exists to give that priority<SPAN class=225353300-26032010> for 
the appropriate type of traffic</SPAN>.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=250340000-26032010><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=250340000-26032010><FONT face=Arial 
color=#0000ff size=2>regards</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=250340000-26032010><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=250340000-26032010><FONT face=Arial 
color=#0000ff size=2>Keith</FONT></SPAN></DIV></DIV><BR>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
  <HR tabIndex=-1>
  <FONT face=Tahoma size=2><B>From:</B> [email-masked] 
  [mailto:[email-masked]] <B>On Behalf Of </B>Brian 
  Rosen<BR><B>Sent:</B> Friday, March 26, 2010 12:00 AM<BR><B>To:</B> DALY, 
  BRIAN K (ATTCINW); [email-masked]<BR><B>Subject:</B> Re: [earlywarning] 
  (no subject)<BR></FONT><BR></DIV>
  <DIV></DIV><FONT face="Calibri, Verdana, Helvetica, Arial"><SPAN 
  style="FONT-SIZE: 11pt">Are they connected to the Internet?<BR><BR>If they 
  are, it would apply. &nbsp;If they aren�t, then it wouldn�t 
  apply.<BR><BR>Brian<BR><BR><BR>On 3/25/10 7:51 PM, "DALY, BRIAN K (ATTCINW)" 
  &lt;<A href="[email-masked]">[email-masked]</A>&gt; 
  wrote:<BR><BR></SPAN></FONT>
  <BLOCKQUOTE><FONT face="Calibri, Verdana, Helvetica, Arial"><SPAN 
    style="FONT-SIZE: 11pt"><FONT color=#1f497d>That will not apply to devices 
    connected to wireless cellular 
    networks.<BR>&nbsp;<BR></FONT><BR></SPAN></FONT><FONT size=2><FONT 
    face="Tahoma, Verdana, Helvetica, Arial"><SPAN 
    style="FONT-SIZE: 10pt"><B>From:</B> Brian Rosen [<A 
    href="mailto:[email-masked]">mailto:[email-masked]</A>] 
    <BR><B>Sent:</B> Thursday, March 25, 2010 4:50 PM<BR><B>To:</B> DALY, BRIAN 
    K (ATTCINW); <A 
    href="[email-masked]">[email-masked]</A><BR><B>Subject:</B> 
    Re: [earlywarning] (no subject)<BR></SPAN></FONT></FONT><FONT 
    face="Times New Roman"><SPAN style="FONT-SIZE: 12pt"><BR></SPAN></FONT><FONT 
    face="Calibri, Verdana, Helvetica, Arial"><SPAN style="FONT-SIZE: 11pt">Once 
    again, this is NOT about a solution limited to wireless cellular networks. 
    &nbsp;It is about a solution for internet connected endpoints of all kinds. 
    &nbsp;<BR><BR>Brian<BR><BR><BR>On 3/25/10 7:46 PM, "DALY, BRIAN K (ATTCINW)" 
    &lt;<A href="[email-masked]">[email-masked]</A>&gt; wrote:<BR>Keith � We 
    agree with you, and to further the point, in wireless cellular IP networks a 
    point to point solution would be problematic. Cell Broadcast is used for 
    CMAS because SMS cannot be used for any real time alerting � it was not 
    designed for that application and has serious limitations, as the FCC CMSAAC 
    studied.<BR>&nbsp;<BR>When it comes to the evolved packet core and IMS, 
    again a point to point solution &nbsp;will cause significant congestion on 
    the network and a broadcast/multicast solution must be used to effectively 
    deliver alert messages. Thus things like location and �priority� are already 
    handled in the delivery network.<BR>&nbsp;<BR>ATIS and 3GPP will be studying 
    how to support multimedia alerts in the future, as recommended by the FCC 
    CMSAAC. This is all beyond the scope of this work 
    effort.<BR>&nbsp;<BR>Regards,<BR>Brian<BR>&nbsp;<BR></SPAN></FONT><FONT 
    size=2><FONT face="Consolas, Courier New, Courier"><SPAN 
    style="FONT-SIZE: 10pt">Date: Thu, 25 Mar 2010 03:13:24 +0100<BR>From: 
    "DRAGE, Keith (Keith)" &lt;<A 
    href="[email-masked]">[email-masked]</A>&gt;<BR>Subject: 
    Re: [earlywarning] Updated Charter Text for ATOCA<BR>To: Hannes Tschofenig 
    &lt;<A 
    href="[email-masked]">[email-masked]</A>&gt;,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"<A 
    href="[email-masked]">[email-masked]</A>" &lt;<A 
    href="[email-masked]">[email-masked]</A>&gt;<BR>Message-ID:<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;<A 
    href="[email-masked]">[email-masked]</A>&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>Content-Type: 
    text/plain; charset="us-ascii"<BR>&nbsp;<BR>What I am not seeing here is any 
    separation of the problem from the one that cell broadcast attempts to 
    solve. Fundamentally, cell broadcast, as exists on all GSM, UTRAN and 
    E-UTRAN based cell phones and is being used for Tsunami warning and Public 
    Warning, exists and is not going to substantially change. The major 
    limitation here is is length of message, and what does get transmitted will 
    be very much dependent on that restriction.<BR>&nbsp;<BR>Moreover I have 
    heard from a number of governmental bodies that they are happy with that 
    situation and are not envisaging further standardisation in that area 
    outside of 3GPP.<BR>&nbsp;<BR>So my view at the moment is that there is no 
    point in IETF trying to address the scope of what is already specified in 
    cell broadcast (from base station to end 
    mobile).<BR>&nbsp;<BR>regards<BR>&nbsp;<BR>Keith<BR></SPAN></FONT></FONT><FONT 
    face="Calibri, Verdana, Helvetica, Arial"><SPAN 
    style="FONT-SIZE: 11pt"><BR>&nbsp; </SPAN></FONT>
    <P align=center><FONT face="Calibri, Verdana, Helvetica, Arial"><SPAN 
    style="FONT-SIZE: 11pt">
    <HR align=center width="95%" SIZE=3>
    </SPAN></FONT>
    <P><FONT face="Calibri, Verdana, Helvetica, Arial"><SPAN 
    style="FONT-SIZE: 11pt"><BR></SPAN></FONT><FONT size=2><FONT 
    face="Consolas, Courier New, Courier"><SPAN 
    style="FONT-SIZE: 10pt">_______________________________________________<BR>earlywarning 
    mailing list<BR><A 
    href="[email-masked]">[email-masked]</A><BR><A 
    href="https://www.ietf.org/mailman/listinfo/earlywarning">https://www.ietf.org/mailman/listinfo/earlywarning</A><BR></SPAN></FONT></FONT><FONT 
    face="Calibri, Verdana, Helvetica, Arial"><SPAN 
    style="FONT-SIZE: 11pt"><BR></SPAN></FONT></P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

--_000_EDC0A1AE77C57744B664A310A0B23AE20D163BF6FRMRSSXCHMBSC3d_--

From: ken carlberg <[email-masked]>
Date: Thu, 25 Mar 2010 20:25:26 -0400
To: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] (no subject)

--Apple-Mail-11--801848992
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

and the ITU is looking at the situation from other perspectives other than cell broadcast.  and it can be considered a question of *if* carriers migrate to full IMS versus partial.  and there is a case of one major carrier in the EU that has withdrawn from its commitment to a full IMS.  I think we have beaten this horse enough.

-ken

On Mar 25, 2010, at 8:14 PM, DALY, BRIAN K (ATTCINW) wrote:

> Further, the ITU is addressing global solutions also based on cell broadcast.
>  
> The main point here is wireless cellular networks as on the CMAS/PWS track in implementation and standards and I do not see that changing as we move to EPC/IMS deployments.
>  
> Brian Daly
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of DALY, BRIAN K (ATTCINW)
> Sent: Thursday, March 25, 2010 5:12 PM
> To: ken carlberg
> Cc: [email-masked]
> Subject: Re: [earlywarning] (no subject)
>  
> The ETWS and PWS work in 3GPP is an international standard that addresses cell broadcast based alerts and encompasses CMAS here in the U.S. That again is cell broadcast based and is closely aligned with the U.S. CMAS implementation.
>  
> Brian Daly
>  
> From: ken carlberg [mailto:[email-masked]] 
> Sent: Thursday, March 25, 2010 5:09 PM
> To: DALY, BRIAN K (ATTCINW)
> Cc: Brian Rosen; [email-masked]
> Subject: Re: [earlywarning] (no subject)
>  
> please, let's remember not to be U.S. centric.
>  
> -ken
>  
>  
> On Mar 25, 2010, at 8:03 PM, DALY, BRIAN K (ATTCINW) wrote:
>  
> 
> They are connected to the wireless network and under FCC rules the CMSP has responsibility for delivering emergency alerts to those devices under FCC Part 10 rules and the CMSP election to provide those alerts.
>  
> So no, this work does not apply. CMAS applies to those devices.
>  
> Brian Daly
>  
> From: Brian Rosen [mailto:[email-masked]] 
> Sent: Thursday, March 25, 2010 5:00 PM
> To: DALY, BRIAN K (ATTCINW); [email-masked]
> Subject: Re: [earlywarning] (no subject)
>  
> Are they connected to the Internet?
> 
> If they are, it would apply.  If they aren�t, then it wouldn�t apply.
> 
> Brian
> 
> 
> On 3/25/10 7:51 PM, "DALY, BRIAN K (ATTCINW)" <[email-masked]> wrote:
> 
> That will not apply to devices connected to wireless cellular networks.
>  
> 
> From: Brian Rosen [mailto:[email-masked]] 
> Sent: Thursday, March 25, 2010 4:50 PM
> To: DALY, BRIAN K (ATTCINW); [email-masked]
> Subject: Re: [earlywarning] (no subject)
> 
> Once again, this is NOT about a solution limited to wireless cellular networks.  It is about a solution for internet connected endpoints of all kinds.  
> 
> Brian
> 
> 
> On 3/25/10 7:46 PM, "DALY, BRIAN K (ATTCINW)" <[email-masked]> wrote:
> Keith � We agree with you, and to further the point, in wireless cellular IP networks a point to point solution would be problematic. Cell Broadcast is used for CMAS because SMS cannot be used for any real time alerting � it was not designed for that application and has serious limitations, as the FCC CMSAAC studied.
>  
> When it comes to the evolved packet core and IMS, again a point to point solution  will cause significant congestion on the network and a broadcast/multicast solution must be used to effectively deliver alert messages. Thus things like location and �priority� are already handled in the delivery network.
>  
> ATIS and 3GPP will be studying how to support multimedia alerts in the future, as recommended by the FCC CMSAAC. This is all beyond the scope of this work effort.
>  
> Regards,
> Brian
>  
> Date: Thu, 25 Mar 2010 03:13:24 +0100
> From: "DRAGE, Keith (Keith)" <[email-masked]>
> Subject: Re: [earlywarning] Updated Charter Text for ATOCA
> To: Hannes Tschofenig <[email-masked]>,
>       "[email-masked]" <[email-masked]>
> Message-ID:
>       <[email-masked]>
>       
> Content-Type: text/plain; charset="us-ascii"
>  
> What I am not seeing here is any separation of the problem from the one that cell broadcast attempts to solve. Fundamentally, cell broadcast, as exists on all GSM, UTRAN and E-UTRAN based cell phones and is being used for Tsunami warning and Public Warning, exists and is not going to substantially change. The major limitation here is is length of message, and what does get transmitted will be very much dependent on that restriction.
>  
> Moreover I have heard from a number of governmental bodies that they are happy with that situation and are not envisaging further standardisation in that area outside of 3GPP.
>  
> So my view at the moment is that there is no point in IETF trying to address the scope of what is already specified in cell broadcast (from base station to end mobile).
>  
> regards
>  
> Keith
> 
>  
> 
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning
> 
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning
>  

--Apple-Mail-11--801848992
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

<html><head><base href="x-msg://506/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">and the ITU is looking at the situation from other perspectives other than cell broadcast. &nbsp;and it can be considered a question of *if* carriers migrate to full IMS versus partial. &nbsp;and there is a case of one major carrier in the EU that has withdrawn from its commitment to a full IMS. &nbsp;I think we have beaten this horse enough.<div><br></div><div>-ken<br><div><br></div><div><br><div><div>On Mar 25, 2010, at 8:14 PM, DALY, BRIAN K (ATTCINW) wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div lang="EN-US" link="blue" vlink="purple" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div class="Section1"><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">Further, the ITU is addressing global solutions also based on cell broadcast.<o:p></o:p></span></div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">The main point here is wireless cellular networks as on the CMAS/PWS track in implementation and standards and I do not see that changing as we move to EPC/IMS deployments.<o:p></o:p></span></div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">Brian Daly<o:p></o:p></span></div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></div><div><div style="border-right-style: none; border-bottom-style: none; border-left-style: none; border-width: initial; border-color: initial; border-top-style: solid; border-top-color: rgb(181, 196, 223); border-top-width: 1pt; padding-top: 3pt; padding-right: 0in; padding-bottom: 0in; padding-left: 0in; "><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: 0.0001pt; "><b><span style="font-size: 10pt; font-family: Tahoma, sans-serif; ">From:</span></b><span style="font-size: 10pt; font-family: Tahoma, sans-serif; "><span class="Apple-converted-space">&nbsp;</span><a href="mailto:[email-masked]" style="color: blue; text-decoration: underline; ">[email-masked]</a><span class="Apple-converted-space">&nbsp;</span>[mailto:[email-masked]]<span class="Apple-converted-space">&nbsp;</span><b>On Behalf Of<span class="Apple-converted-space">&nbsp;</span></b>DALY, BRIAN K (ATTCINW)<br><b>Sent:</b><span class="Apple-converted-space">&nbsp;</span>Thursday, March 25, 2010 5:12 PM<br><b>To:</b><span class="Apple-converted-space">&nbsp;</span>ken carlberg<br><b>Cc:</b><span class="Apple-converted-space">&nbsp;</span><a href="mailto:[email-masked]" style="color: blue; text-decoration: underline; ">[email-masked]</a><br><b>Subject:</b><span class="Apple-converted-space">&nbsp;</span>Re: [earlywarning] (no subject)<o:p></o:p></span></div></div></div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: 0.0001pt; "><o:p>&nbsp;</o:p></div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">The ETWS and PWS work in 3GPP is an international standard that addresses cell broadcast based alerts and encompasses CMAS here in the U.S. That again is cell broadcast based and is closely aligned with the U.S. CMAS implementation.<o:p></o:p></span></div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">Brian Daly<o:p></o:p></span></div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></div><div><div style="border-right-style: none; border-bottom-style: none; border-left-style: none; border-width: initial; border-color: initial; border-top-style: solid; border-top-color: rgb(181, 196, 223); border-top-width: 1pt; padding-top: 3pt; padding-right: 0in; padding-bottom: 0in; padding-left: 0in; "><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: 0.0001pt; "><b><span style="font-size: 10pt; font-family: Tahoma, sans-serif; ">From:</span></b><span style="font-size: 10pt; font-family: Tahoma, sans-serif; "><span class="Apple-converted-space">&nbsp;</span>ken carlberg [mailto:[email-masked]]<span class="Apple-converted-space">&nbsp;</span><br><b>Sent:</b><span class="Apple-converted-space">&nbsp;</span>Thursday, March 25, 2010 5:09 PM<br><b>To:</b><span class="Apple-converted-space">&nbsp;</span>DALY, BRIAN K (ATTCINW)<br><b>Cc:</b><span class="Apple-converted-space">&nbsp;</span>Brian Rosen;<span class="Apple-converted-space">&nbsp;</span><a href="mailto:[email-masked]" style="color: blue; text-decoration: underline; ">[email-masked]</a><br><b>Subject:</b><span class="Apple-converted-space">&nbsp;</span>Re: [earlywarning] (no subject)<o:p></o:p></span></div></div></div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: 0.0001pt; "><o:p>&nbsp;</o:p></div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: 0.0001pt; ">please, let's remember not to be U.S. centric.<o:p></o:p></div><div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: 0.0001pt; "><o:p>&nbsp;</o:p></div></div><div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: 0.0001pt; ">-ken<o:p></o:p></div></div><div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: 0.0001pt; "><o:p>&nbsp;</o:p></div></div><div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: 0.0001pt; "><o:p>&nbsp;</o:p></div><div><div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: 0.0001pt; ">On Mar 25, 2010, at 8:03 PM, DALY, BRIAN K (ATTCINW) wrote:<o:p></o:p></div></div><p class="MsoNormal" style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: 12pt; "><o:p>&nbsp;</o:p></p><div><div><div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">They are connected to the wireless network and under FCC rules the CMSP has responsibility for delivering emergency alerts to those devices under FCC Part 10 rules and the CMSP election to provide those alerts.</span><o:p></o:p></div></div><div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">&nbsp;</span><o:p></o:p></div></div><div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">So no, this work does not apply. CMAS applies to those devices.</span><o:p></o:p></div></div><div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">&nbsp;</span><o:p></o:p></div></div><div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">Brian Daly</span><o:p></o:p></div></div><div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">&nbsp;</span><o:p></o:p></div></div><div><div style="border-right-style: none; border-bottom-style: none; border-left-style: none; border-width: initial; border-color: initial; border-top-style: solid; padding-top: 3pt; padding-right: 0in; padding-bottom: 0in; padding-left: 0in; border-width: initial; border-color: initial; "><div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: 0.0001pt; "><b><span style="font-size: 10pt; font-family: Tahoma, sans-serif; ">From:</span></b><span class="apple-converted-space"><span style="font-size: 10pt; font-family: Tahoma, sans-serif; ">&nbsp;</span></span><span style="font-size: 10pt; font-family: Tahoma, sans-serif; ">Brian Rosen [mailto:[email-masked]]<span class="apple-converted-space">&nbsp;</span><br><b>Sent:</b><span class="apple-converted-space">&nbsp;</span>Thursday, March 25, 2010 5:00 PM<br><b>To:</b><span class="apple-converted-space">&nbsp;</span>DALY, BRIAN K (ATTCINW);<span class="apple-converted-space">&nbsp;</span><a href="mailto:[email-masked]" style="color: blue; text-decoration: underline; ">[email-masked]</a><br><b>Subject:</b><span class="apple-converted-space">&nbsp;</span>Re: [earlywarning] (no subject)</span><o:p></o:p></div></div></div></div><div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: 0.0001pt; ">&nbsp;<o:p></o:p></div></div><p class="MsoNormal" style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: 12pt; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; ">Are they connected to the Internet?<br><br>If they are, it would apply. &nbsp;If they aren�t, then it wouldn�t apply.<br><br>Brian<br><br><br>On 3/25/10 7:51 PM, "DALY, BRIAN K (ATTCINW)" &lt;<a href="x-msg://506/[email-masked]" style="color: blue; text-decoration: underline; ">[email-masked]</a>&gt; wrote:</span><o:p></o:p></p><div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">That will not apply to devices connected to wireless cellular networks.<br>&nbsp;<br></span><span style="font-size: 11pt; font-family: Calibri, sans-serif; "><br></span><b><span style="font-size: 10pt; font-family: Tahoma, sans-serif; ">From:</span></b><span class="apple-converted-space"><span style="font-size: 10pt; font-family: Tahoma, sans-serif; ">&nbsp;</span></span><span style="font-size: 10pt; font-family: Tahoma, sans-serif; ">Brian Rosen [<a href="mailto:[email-masked]" style="color: blue; text-decoration: underline; ">mailto:[email-masked]</a>]<span class="apple-converted-space">&nbsp;</span><br><b>Sent:</b><span class="apple-converted-space">&nbsp;</span>Thursday, March 25, 2010 4:50 PM<br><b>To:</b><span class="apple-converted-space">&nbsp;</span>DALY, BRIAN K (ATTCINW);<span class="apple-converted-space">&nbsp;</span><a href="x-msg://506/[email-masked]" style="color: blue; text-decoration: underline; ">[email-masked]</a><br><b>Subject:</b><span class="apple-converted-space">&nbsp;</span>Re: [earlywarning] (no subject)<br></span><br><span style="font-size: 11pt; font-family: Calibri, sans-serif; ">Once again, this is NOT about a solution limited to wireless cellular networks. &nbsp;It is about a solution for internet connected endpoints of all kinds. &nbsp;<br><br>Brian<br><br><br>On 3/25/10 7:46 PM, "DALY, BRIAN K (ATTCINW)" &lt;<a href="x-msg://506/[email-masked]" style="color: blue; text-decoration: underline; ">[email-masked]</a>&gt; wrote:<br>Keith � We agree with you, and to further the point, in wireless cellular IP networks a point to point solution would be problematic. Cell Broadcast is used for CMAS because SMS cannot be used for any real time alerting � it was not designed for that application and has serious limitations, as the FCC CMSAAC studied.<br>&nbsp;<br>When it comes to the evolved packet core and IMS, again a point to point solution &nbsp;will cause significant congestion on the network and a broadcast/multicast solution must be used to effectively deliver alert messages. Thus things like location and �priority� are already handled in the delivery network.<br>&nbsp;<br>ATIS and 3GPP will be studying how to support multimedia alerts in the future, as recommended by the FCC CMSAAC. This is all beyond the scope of this work effort.<br>&nbsp;<br>Regards,<br>Brian<br>&nbsp;<br></span><span style="font-size: 10pt; font-family: Consolas; ">Date: Thu, 25 Mar 2010 03:13:24 +0100<br>From: "DRAGE, Keith (Keith)" &lt;<a href="x-msg://506/[email-masked]" style="color: blue; text-decoration: underline; ">[email-masked]</a>&gt;<br>Subject: Re: [earlywarning] Updated Charter Text for ATOCA<br>To: Hannes Tschofenig &lt;<a href="x-msg://506/[email-masked]" style="color: blue; text-decoration: underline; ">[email-masked]</a>&gt;,<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"<a href="x-msg://506/[email-masked]" style="color: blue; text-decoration: underline; ">[email-masked]</a>" &lt;<a href="x-msg://506/[email-masked]" style="color: blue; text-decoration: underline; ">[email-masked]</a>&gt;<br>Message-ID:<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;<a href="x-msg://506/[email-masked]" style="color: blue; text-decoration: underline; ">[email-masked]</a>&gt;<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>Content-Type: text/plain; charset="us-ascii"<br>&nbsp;<br>What I am not seeing here is any separation of the problem from the one that cell broadcast attempts to solve. Fundamentally, cell broadcast, as exists on all GSM, UTRAN and E-UTRAN based cell phones and is being used for Tsunami warning and Public Warning, exists and is not going to substantially change. The major limitation here is is length of message, and what does get transmitted will be very much dependent on that restriction.<br>&nbsp;<br>Moreover I have heard from a number of governmental bodies that they are happy with that situation and are not envisaging further standardisation in that area outside of 3GPP.<br>&nbsp;<br>So my view at the moment is that there is no point in IETF trying to address the scope of what is already specified in cell broadcast (from base station to end mobile).<br>&nbsp;<br>regards<br>&nbsp;<br>Keith<br></span><span style="font-size: 11pt; font-family: Calibri, sans-serif; "><br>&nbsp;</span><o:p></o:p></div></div><div class="MsoNormal" align="center" style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; text-align: center; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; "><hr size="3" width="95%" align="center"></span></div><p style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-bottom: 12pt; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; "><br></span><span style="font-size: 10pt; font-family: Consolas; ">_______________________________________________<br>earlywarning mailing list<br><a href="x-msg://506/[email-masked]" style="color: blue; text-decoration: underline; ">[email-masked]</a><br><a href="https://www.ietf.org/mailman/listinfo/earlywarning" style="color: blue; text-decoration: underline; ">https://www.ietf.org/mailman/listinfo/earlywarning</a></span><o:p></o:p></p></div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span style="font-size: 13.5pt; font-family: Helvetica, sans-serif; ">_______________________________________________<br>earlywarning mailing list<br><a href="mailto:[email-masked]" style="color: blue; text-decoration: underline; ">[email-masked]</a><br><a href="https://www.ietf.org/mailman/listinfo/earlywarning" style="color: blue; text-decoration: underline; ">https://www.ietf.org/mailman/listinfo/earlywarning</a><o:p></o:p></span></div></div></div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: 0.0001pt; "><o:p>&nbsp;</o:p></div></div></div></div></span></blockquote></div><br></div></div></body></html>
--Apple-Mail-11--801848992--

Content-class: urn:content-classes:message
Date: Thu, 25 Mar 2010 17:21:46 -0700
From: "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]>
To: "DALY, BRIAN K (ATTCINW)" <[email-masked]>, "ken carlberg" <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] (no subject)

This is a multi-part message in MIME format.

------_=_NextPart_001_01CACC7A.533A216F
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

CMAS and PWS are not only US centric.  Japan has implemented the ETWS
portion of PWS based upon cell broadcast for the ETWS work.  CMAS is
being studied for possible implementation by Canada, Sweden, and the
Netherlands.  Korea has also expressed interest in implementing CMAS.

DeWayne 

From: [email-masked]
[mailto:[email-masked]] On Behalf Of DALY, BRIAN K
(ATTCINW)
Sent: Thursday, March 25, 2010 5:15 PM
To: DALY, BRIAN K (ATTCINW); ken carlberg
Cc: [email-masked]
Subject: Re: [earlywarning] (no subject)

Further, the ITU is addressing global solutions also based on cell
broadcast.

The main point here is wireless cellular networks as on the CMAS/PWS
track in implementation and standards and I do not see that changing as
we move to EPC/IMS deployments.

Brian Daly

From: [email-masked]
[mailto:[email-masked]] On Behalf Of DALY, BRIAN K
(ATTCINW)
Sent: Thursday, March 25, 2010 5:12 PM
To: ken carlberg
Cc: [email-masked]
Subject: Re: [earlywarning] (no subject)

The ETWS and PWS work in 3GPP is an international standard that
addresses cell broadcast based alerts and encompasses CMAS here in the
U.S. That again is cell broadcast based and is closely aligned with the
U.S. CMAS implementation.

Brian Daly

From: ken carlberg [mailto:[email-masked]] 
Sent: Thursday, March 25, 2010 5:09 PM
To: DALY, BRIAN K (ATTCINW)
Cc: Brian Rosen; [email-masked]
Subject: Re: [earlywarning] (no subject)

please, let's remember not to be U.S. centric.

-ken

 

On Mar 25, 2010, at 8:03 PM, DALY, BRIAN K (ATTCINW) wrote:

They are connected to the wireless network and under FCC rules the CMSP
has responsibility for delivering emergency alerts to those devices
under FCC Part 10 rules and the CMSP election to provide those alerts.

So no, this work does not apply. CMAS applies to those devices.

Brian Daly

From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, March 25, 2010 5:00 PM
To: DALY, BRIAN K (ATTCINW); [email-masked]
Subject: Re: [earlywarning] (no subject)

Are they connected to the Internet?

If they are, it would apply.  If they aren't, then it wouldn't apply.

Brian

On 3/25/10 7:51 PM, "DALY, BRIAN K (ATTCINW)" <[email-masked]
<x-msg://506/[email-masked]> > wrote:

That will not apply to devices connected to wireless cellular networks.

From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, March 25, 2010 4:50 PM
To: DALY, BRIAN K (ATTCINW); [email-masked]
<x-msg://506/[email-masked]> 
Subject: Re: [earlywarning] (no subject)

Once again, this is NOT about a solution limited to wireless cellular
networks.  It is about a solution for internet connected endpoints of
all kinds.  

Brian

On 3/25/10 7:46 PM, "DALY, BRIAN K (ATTCINW)" <[email-masked]
<x-msg://506/[email-masked]> > wrote:
Keith - We agree with you, and to further the point, in wireless
cellular IP networks a point to point solution would be problematic.
Cell Broadcast is used for CMAS because SMS cannot be used for any real
time alerting - it was not designed for that application and has serious
limitations, as the FCC CMSAAC studied.
 
When it comes to the evolved packet core and IMS, again a point to point
solution  will cause significant congestion on the network and a
broadcast/multicast solution must be used to effectively deliver alert
messages. Thus things like location and "priority" are already handled
in the delivery network.
 
ATIS and 3GPP will be studying how to support multimedia alerts in the
future, as recommended by the FCC CMSAAC. This is all beyond the scope
of this work effort.
 
Regards,
Brian
 
Date: Thu, 25 Mar 2010 03:13:24 +0100
From: "DRAGE, Keith (Keith)" <[email-masked]
<x-msg://506/[email-masked]> >
Subject: Re: [earlywarning] Updated Charter Text for ATOCA
To: Hannes Tschofenig <[email-masked]
<x-msg://506/[email-masked]> >,
      "[email-masked] <x-msg://506/[email-masked]> "
<[email-masked] <x-msg://506/[email-masked]> >
Message-ID:
 
<[email-masked]
cent.com
<x-msg://506/[email-masked]
m.alcatel-lucent.com> >
      
Content-Type: text/plain; charset="us-ascii"
 
What I am not seeing here is any separation of the problem from the one
that cell broadcast attempts to solve. Fundamentally, cell broadcast, as
exists on all GSM, UTRAN and E-UTRAN based cell phones and is being used
for Tsunami warning and Public Warning, exists and is not going to
substantially change. The major limitation here is is length of message,
and what does get transmitted will be very much dependent on that
restriction.
 
Moreover I have heard from a number of governmental bodies that they are
happy with that situation and are not envisaging further standardisation
in that area outside of 3GPP.
 
So my view at the moment is that there is no point in IETF trying to
address the scope of what is already specified in cell broadcast (from
base station to end mobile).
 
regards
 
Keith

________________________________

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

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

------_=_NextPart_001_01CACC7A.533A216F
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<base href="x-msg://506/">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Helvetica;
	panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.apple-style-span
	{mso-style-name:apple-style-span;}
span.apple-converted-space
	{mso-style-name:apple-converted-space;}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle22
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-US link=blue vlink=purple style='word-wrap: break-word;
-webkit-nbsp-mode: space;-webkit-line-break: after-white-space'>

<div class=Section1>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>CMAS and PWS are not only US centric.&nbsp; Japan has
implemented the ETWS portion of PWS based upon cell broadcast for the ETWS
work.&nbsp; CMAS is being studied for possible implementation by Canada,
Sweden, and the Netherlands.&nbsp; Korea has also expressed interest in
implementing CMAS.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<p class=MsoNormal><b><i><span style='font-size:13.5pt;font-family:"Arial","sans-serif";
color:blue'>DeWayne </span></i></b><span style='font-size:11.0pt;font-family:
"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p>

</div>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>

<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
[email-masked] [mailto:[email-masked]] <b>On
Behalf Of </b>DALY, BRIAN K (ATTCINW)<br>
<b>Sent:</b> Thursday, March 25, 2010 5:15 PM<br>
<b>To:</b> DALY, BRIAN K (ATTCINW); ken carlberg<br>
<b>Cc:</b> [email-masked]<br>
<b>Subject:</b> Re: [earlywarning] (no subject)<o:p></o:p></span></p>

</div>

</div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Further, the ITU is addressing global solutions also based on
cell broadcast.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>The main point here is wireless cellular networks as on the
CMAS/PWS track in implementation and standards and I do not see that changing
as we move to EPC/IMS deployments.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Brian Daly<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>

<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
[email-masked] [mailto:[email-masked]] <b>On
Behalf Of </b>DALY, BRIAN K (ATTCINW)<br>
<b>Sent:</b> Thursday, March 25, 2010 5:12 PM<br>
<b>To:</b> ken carlberg<br>
<b>Cc:</b> [email-masked]<br>
<b>Subject:</b> Re: [earlywarning] (no subject)<o:p></o:p></span></p>

</div>

</div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>The ETWS and PWS work in 3GPP is an international standard that
addresses cell broadcast based alerts and encompasses CMAS here in the U.S.
That again is cell broadcast based and is closely aligned with the U.S. CMAS
implementation.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Brian Daly<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>

<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> ken carlberg
[mailto:[email-masked]] <br>
<b>Sent:</b> Thursday, March 25, 2010 5:09 PM<br>
<b>To:</b> DALY, BRIAN K (ATTCINW)<br>
<b>Cc:</b> Brian Rosen; [email-masked]<br>
<b>Subject:</b> Re: [earlywarning] (no subject)<o:p></o:p></span></p>

</div>

</div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>please, let's remember not to be U.S. centric.<o:p></o:p></p>

<div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=MsoNormal>-ken<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<div>

<div>

<p class=MsoNormal>On Mar 25, 2010, at 8:03 PM, DALY, BRIAN K (ATTCINW) wrote:<o:p></o:p></p>

</div>

<p class=MsoNormal style='margin-bottom:12.0pt'><o:p>&nbsp;</o:p></p>

<div>

<div>

<div>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>They are connected to the wireless network and under FCC rules
the CMSP has responsibility for delivering emergency alerts to those devices
under FCC Part 10 rules and the CMSP election to provide those alerts.</span><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>&nbsp;</span><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>So no, this work does not apply. CMAS applies to those devices.</span><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>&nbsp;</span><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Brian Daly</span><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>&nbsp;</span><o:p></o:p></p>

</div>

<div>

<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in;
border-width:initial;border-color:initial'>

<div>

<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
class=apple-converted-space><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>&nbsp;</span></span><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>Brian Rosen
[mailto:[email-masked]]<span class=apple-converted-space>&nbsp;</span><br>
<b>Sent:</b><span class=apple-converted-space>&nbsp;</span>Thursday, March 25,
2010 5:00 PM<br>
<b>To:</b><span class=apple-converted-space>&nbsp;</span>DALY, BRIAN K
(ATTCINW);<span class=apple-converted-space>&nbsp;</span><a
href="mailto:[email-masked]">[email-masked]</a><br>
<b>Subject:</b><span class=apple-converted-space>&nbsp;</span>Re:
[earlywarning] (no subject)</span><o:p></o:p></p>

</div>

</div>

</div>

<div>

<p class=MsoNormal>&nbsp;<o:p></o:p></p>

</div>

<p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif"'>Are they connected to the Internet?<br>
<br>
If they are, it would apply. &nbsp;If they aren&#8217;t, then it wouldn&#8217;t
apply.<br>
<br>
Brian<br>
<br>
<br>
On 3/25/10 7:51 PM, &quot;DALY, BRIAN K (ATTCINW)&quot; &lt;<a
href="x-msg://506/[email-masked]">[email-masked]</a>&gt; wrote:</span><o:p></o:p></p>

<div>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>That will not apply to devices connected to wireless cellular
networks.<br>
&nbsp;<br>
</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><br>
</span><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
class=apple-converted-space><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>&nbsp;</span></span><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>Brian Rosen [<a
href="mailto:[email-masked]">mailto:[email-masked]</a>]<span
class=apple-converted-space>&nbsp;</span><br>
<b>Sent:</b><span class=apple-converted-space>&nbsp;</span>Thursday, March 25,
2010 4:50 PM<br>
<b>To:</b><span class=apple-converted-space>&nbsp;</span>DALY, BRIAN K
(ATTCINW);<span class=apple-converted-space>&nbsp;</span><a
href="x-msg://506/[email-masked]">[email-masked]</a><br>
<b>Subject:</b><span class=apple-converted-space>&nbsp;</span>Re:
[earlywarning] (no subject)<br>
</span><br>
<span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>Once again,
this is NOT about a solution limited to wireless cellular networks. &nbsp;It is
about a solution for internet connected endpoints of all kinds. &nbsp;<br>
<br>
Brian<br>
<br>
<br>
On 3/25/10 7:46 PM, &quot;DALY, BRIAN K (ATTCINW)&quot; &lt;<a
href="x-msg://506/[email-masked]">[email-masked]</a>&gt; wrote:<br>
Keith &#8211; We agree with you, and to further the point, in wireless cellular
IP networks a point to point solution would be problematic. Cell Broadcast is
used for CMAS because SMS cannot be used for any real time alerting &#8211; it
was not designed for that application and has serious limitations, as the FCC
CMSAAC studied.<br>
&nbsp;<br>
When it comes to the evolved packet core and IMS, again a point to point
solution &nbsp;will cause significant congestion on the network and a
broadcast/multicast solution must be used to effectively deliver alert
messages. Thus things like location and &#8220;priority&#8221; are already
handled in the delivery network.<br>
&nbsp;<br>
ATIS and 3GPP will be studying how to support multimedia alerts in the future,
as recommended by the FCC CMSAAC. This is all beyond the scope of this work
effort.<br>
&nbsp;<br>
Regards,<br>
Brian<br>
&nbsp;<br>
</span><span style='font-size:10.0pt;font-family:Consolas'>Date: Thu, 25 Mar
2010 03:13:24 +0100<br>
From: &quot;DRAGE, Keith (Keith)&quot; &lt;<a
href="x-msg://506/[email-masked]">[email-masked]</a>&gt;<br>
Subject: Re: [earlywarning] Updated Charter Text for ATOCA<br>
To: Hannes Tschofenig &lt;<a href="x-msg://506/[email-masked]">[email-masked]</a>&gt;,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&quot;<a
href="x-msg://506/[email-masked]">[email-masked]</a>&quot; &lt;<a
href="x-msg://506/[email-masked]">[email-masked]</a>&gt;<br>
Message-ID:<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;<a
href="x-msg://506/[email-masked]">[email-masked]</a>&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
Content-Type: text/plain; charset=&quot;us-ascii&quot;<br>
&nbsp;<br>
What I am not seeing here is any separation of the problem from the one that
cell broadcast attempts to solve. Fundamentally, cell broadcast, as exists on
all GSM, UTRAN and E-UTRAN based cell phones and is being used for Tsunami
warning and Public Warning, exists and is not going to substantially change.
The major limitation here is is length of message, and what does get
transmitted will be very much dependent on that restriction.<br>
&nbsp;<br>
Moreover I have heard from a number of governmental bodies that they are happy
with that situation and are not envisaging further standardisation in that area
outside of 3GPP.<br>
&nbsp;<br>
So my view at the moment is that there is no point in IETF trying to address
the scope of what is already specified in cell broadcast (from base station to
end mobile).<br>
&nbsp;<br>
regards<br>
&nbsp;<br>
Keith<br>
</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><br>
&nbsp;</span><o:p></o:p></p>

</div>

<div class=MsoNormal align=center style='text-align:center'><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>

<hr size=3 width="95%" align=center>

</span></div>

<p style='margin-bottom:12.0pt'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><br>
</span><span style='font-size:10.0pt;font-family:Consolas'>_______________________________________________<br>
earlywarning mailing list<br>
<a href="x-msg://506/[email-masked]">[email-masked]</a><br>
<a href="https://www.ietf.org/mailman/listinfo/earlywarning">https://www.ietf.org/mailman/listinfo/earlywarning</a></span><o:p></o:p></p>

</div>

<p class=MsoNormal><span style='font-size:13.5pt;font-family:"Helvetica","sans-serif"'>_______________________________________________<br>
earlywarning mailing list<br>
<a href="mailto:[email-masked]">[email-masked]</a><br>
<a href="https://www.ietf.org/mailman/listinfo/earlywarning">https://www.ietf.org/mailman/listinfo/earlywarning</a><o:p></o:p></span></p>

</div>

</div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01CACC7A.533A216F--

Content-class: urn:content-classes:message
Date: Thu, 25 Mar 2010 17:14:53 -0700
From: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
To: "DALY, BRIAN K (ATTCINW)" <[email-masked]>, "ken carlberg" <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] (no subject)

This is a multi-part message in MIME format.

------_=_NextPart_001_01CACC79.5C0E096A
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Further, the ITU is addressing global solutions also based on cell
broadcast.

The main point here is wireless cellular networks as on the CMAS/PWS
track in implementation and standards and I do not see that changing as
we move to EPC/IMS deployments.

Brian Daly

From: [email-masked]
[mailto:[email-masked]] On Behalf Of DALY, BRIAN K
(ATTCINW)
Sent: Thursday, March 25, 2010 5:12 PM
To: ken carlberg
Cc: [email-masked]
Subject: Re: [earlywarning] (no subject)

The ETWS and PWS work in 3GPP is an international standard that
addresses cell broadcast based alerts and encompasses CMAS here in the
U.S. That again is cell broadcast based and is closely aligned with the
U.S. CMAS implementation.

Brian Daly

From: ken carlberg [mailto:[email-masked]] 
Sent: Thursday, March 25, 2010 5:09 PM
To: DALY, BRIAN K (ATTCINW)
Cc: Brian Rosen; [email-masked]
Subject: Re: [earlywarning] (no subject)

please, let's remember not to be U.S. centric.

-ken

 

On Mar 25, 2010, at 8:03 PM, DALY, BRIAN K (ATTCINW) wrote:

They are connected to the wireless network and under FCC rules the CMSP
has responsibility for delivering emergency alerts to those devices
under FCC Part 10 rules and the CMSP election to provide those alerts.

So no, this work does not apply. CMAS applies to those devices.

Brian Daly

From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, March 25, 2010 5:00 PM
To: DALY, BRIAN K (ATTCINW); [email-masked]
Subject: Re: [earlywarning] (no subject)

Are they connected to the Internet?

If they are, it would apply.  If they aren't, then it wouldn't apply.

Brian

On 3/25/10 7:51 PM, "DALY, BRIAN K (ATTCINW)" <[email-masked]
<x-msg://506/[email-masked]> > wrote:

That will not apply to devices connected to wireless cellular networks.

From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, March 25, 2010 4:50 PM
To: DALY, BRIAN K (ATTCINW); [email-masked]
<x-msg://506/[email-masked]> 
Subject: Re: [earlywarning] (no subject)

Once again, this is NOT about a solution limited to wireless cellular
networks.  It is about a solution for internet connected endpoints of
all kinds.  

Brian

On 3/25/10 7:46 PM, "DALY, BRIAN K (ATTCINW)" <[email-masked]
<x-msg://506/[email-masked]> > wrote:
Keith - We agree with you, and to further the point, in wireless
cellular IP networks a point to point solution would be problematic.
Cell Broadcast is used for CMAS because SMS cannot be used for any real
time alerting - it was not designed for that application and has serious
limitations, as the FCC CMSAAC studied.
 
When it comes to the evolved packet core and IMS, again a point to point
solution  will cause significant congestion on the network and a
broadcast/multicast solution must be used to effectively deliver alert
messages. Thus things like location and "priority" are already handled
in the delivery network.
 
ATIS and 3GPP will be studying how to support multimedia alerts in the
future, as recommended by the FCC CMSAAC. This is all beyond the scope
of this work effort.
 
Regards,
Brian
 
Date: Thu, 25 Mar 2010 03:13:24 +0100
From: "DRAGE, Keith (Keith)" <[email-masked]
<x-msg://506/[email-masked]> >
Subject: Re: [earlywarning] Updated Charter Text for ATOCA
To: Hannes Tschofenig <[email-masked]
<x-msg://506/[email-masked]> >,
      "[email-masked] <x-msg://506/[email-masked]> "
<[email-masked] <x-msg://506/[email-masked]> >
Message-ID:
 
<[email-masked]
cent.com
<x-msg://506/[email-masked]
m.alcatel-lucent.com> >
      
Content-Type: text/plain; charset="us-ascii"
 
What I am not seeing here is any separation of the problem from the one
that cell broadcast attempts to solve. Fundamentally, cell broadcast, as
exists on all GSM, UTRAN and E-UTRAN based cell phones and is being used
for Tsunami warning and Public Warning, exists and is not going to
substantially change. The major limitation here is is length of message,
and what does get transmitted will be very much dependent on that
restriction.
 
Moreover I have heard from a number of governmental bodies that they are
happy with that situation and are not envisaging further standardisation
in that area outside of 3GPP.
 
So my view at the moment is that there is no point in IETF trying to
address the scope of what is already specified in cell broadcast (from
base station to end mobile).
 
regards
 
Keith

________________________________

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

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

------_=_NextPart_001_01CACC79.5C0E096A
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<base href="x-msg://506/">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Helvetica;
	panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
	{font-family:Helvetica;
	panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.apple-style-span
	{mso-style-name:apple-style-span;}
span.apple-converted-space
	{mso-style-name:apple-converted-space;}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle21
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-US link=blue vlink=purple style='word-wrap: break-word;
-webkit-nbsp-mode: space;-webkit-line-break: after-white-space'>

<div class=Section1>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Further, the ITU is addressing global solutions also based on
cell broadcast.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>The main point here is wireless cellular networks as on the
CMAS/PWS track in implementation and standards and I do not see that changing
as we move to EPC/IMS deployments.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Brian Daly<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>

<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
[email-masked] [mailto:[email-masked]] <b>On
Behalf Of </b>DALY, BRIAN K (ATTCINW)<br>
<b>Sent:</b> Thursday, March 25, 2010 5:12 PM<br>
<b>To:</b> ken carlberg<br>
<b>Cc:</b> [email-masked]<br>
<b>Subject:</b> Re: [earlywarning] (no subject)<o:p></o:p></span></p>

</div>

</div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>The ETWS and PWS work in 3GPP is an international standard that
addresses cell broadcast based alerts and encompasses CMAS here in the U.S.
That again is cell broadcast based and is closely aligned with the U.S. CMAS
implementation.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Brian Daly<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>

<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> ken carlberg
[mailto:[email-masked]] <br>
<b>Sent:</b> Thursday, March 25, 2010 5:09 PM<br>
<b>To:</b> DALY, BRIAN K (ATTCINW)<br>
<b>Cc:</b> Brian Rosen; [email-masked]<br>
<b>Subject:</b> Re: [earlywarning] (no subject)<o:p></o:p></span></p>

</div>

</div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>please, let's remember not to be U.S. centric.<o:p></o:p></p>

<div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=MsoNormal>-ken<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<div>

<div>

<p class=MsoNormal>On Mar 25, 2010, at 8:03 PM, DALY, BRIAN K (ATTCINW) wrote:<o:p></o:p></p>

</div>

<p class=MsoNormal style='margin-bottom:12.0pt'><o:p>&nbsp;</o:p></p>

<div>

<div>

<div>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>They are connected to the wireless network and under FCC rules
the CMSP has responsibility for delivering emergency alerts to those devices
under FCC Part 10 rules and the CMSP election to provide those alerts.</span><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>&nbsp;</span><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>So no, this work does not apply. CMAS applies to those devices.</span><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>&nbsp;</span><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Brian Daly</span><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>&nbsp;</span><o:p></o:p></p>

</div>

<div>

<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in;
border-width:initial;border-color:initial'>

<div>

<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
class=apple-converted-space><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>&nbsp;</span></span><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>Brian Rosen
[mailto:[email-masked]]<span class=apple-converted-space>&nbsp;</span><br>
<b>Sent:</b><span class=apple-converted-space>&nbsp;</span>Thursday, March 25,
2010 5:00 PM<br>
<b>To:</b><span class=apple-converted-space>&nbsp;</span>DALY, BRIAN K
(ATTCINW);<span class=apple-converted-space>&nbsp;</span><a
href="mailto:[email-masked]">[email-masked]</a><br>
<b>Subject:</b><span class=apple-converted-space>&nbsp;</span>Re:
[earlywarning] (no subject)</span><o:p></o:p></p>

</div>

</div>

</div>

<div>

<p class=MsoNormal>&nbsp;<o:p></o:p></p>

</div>

<p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif"'>Are they connected to the Internet?<br>
<br>
If they are, it would apply. &nbsp;If they aren&#8217;t, then it wouldn&#8217;t
apply.<br>
<br>
Brian<br>
<br>
<br>
On 3/25/10 7:51 PM, &quot;DALY, BRIAN K (ATTCINW)&quot; &lt;<a
href="x-msg://506/[email-masked]">[email-masked]</a>&gt; wrote:</span><o:p></o:p></p>

<div>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>That will not apply to devices connected to wireless cellular
networks.<br>
&nbsp;<br>
</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><br>
</span><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
class=apple-converted-space><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>&nbsp;</span></span><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>Brian Rosen [<a
href="mailto:[email-masked]">mailto:[email-masked]</a>]<span
class=apple-converted-space>&nbsp;</span><br>
<b>Sent:</b><span class=apple-converted-space>&nbsp;</span>Thursday, March 25,
2010 4:50 PM<br>
<b>To:</b><span class=apple-converted-space>&nbsp;</span>DALY, BRIAN K
(ATTCINW);<span class=apple-converted-space>&nbsp;</span><a
href="x-msg://506/[email-masked]">[email-masked]</a><br>
<b>Subject:</b><span class=apple-converted-space>&nbsp;</span>Re:
[earlywarning] (no subject)<br>
</span><br>
<span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>Once again,
this is NOT about a solution limited to wireless cellular networks. &nbsp;It is
about a solution for internet connected endpoints of all kinds. &nbsp;<br>
<br>
Brian<br>
<br>
<br>
On 3/25/10 7:46 PM, &quot;DALY, BRIAN K (ATTCINW)&quot; &lt;<a
href="x-msg://506/[email-masked]">[email-masked]</a>&gt; wrote:<br>
Keith &#8211; We agree with you, and to further the point, in wireless cellular
IP networks a point to point solution would be problematic. Cell Broadcast is
used for CMAS because SMS cannot be used for any real time alerting &#8211; it
was not designed for that application and has serious limitations, as the FCC
CMSAAC studied.<br>
&nbsp;<br>
When it comes to the evolved packet core and IMS, again a point to point
solution &nbsp;will cause significant congestion on the network and a
broadcast/multicast solution must be used to effectively deliver alert
messages. Thus things like location and &#8220;priority&#8221; are already
handled in the delivery network.<br>
&nbsp;<br>
ATIS and 3GPP will be studying how to support multimedia alerts in the future,
as recommended by the FCC CMSAAC. This is all beyond the scope of this work
effort.<br>
&nbsp;<br>
Regards,<br>
Brian<br>
&nbsp;<br>
</span><span style='font-size:10.0pt;font-family:Consolas'>Date: Thu, 25 Mar
2010 03:13:24 +0100<br>
From: &quot;DRAGE, Keith (Keith)&quot; &lt;<a
href="x-msg://506/[email-masked]">[email-masked]</a>&gt;<br>
Subject: Re: [earlywarning] Updated Charter Text for ATOCA<br>
To: Hannes Tschofenig &lt;<a href="x-msg://506/[email-masked]">[email-masked]</a>&gt;,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&quot;<a
href="x-msg://506/[email-masked]">[email-masked]</a>&quot; &lt;<a
href="x-msg://506/[email-masked]">[email-masked]</a>&gt;<br>
Message-ID:<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;<a
href="x-msg://506/[email-masked]">[email-masked]</a>&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
Content-Type: text/plain; charset=&quot;us-ascii&quot;<br>
&nbsp;<br>
What I am not seeing here is any separation of the problem from the one that
cell broadcast attempts to solve. Fundamentally, cell broadcast, as exists on
all GSM, UTRAN and E-UTRAN based cell phones and is being used for Tsunami
warning and Public Warning, exists and is not going to substantially change. The
major limitation here is is length of message, and what does get transmitted
will be very much dependent on that restriction.<br>
&nbsp;<br>
Moreover I have heard from a number of governmental bodies that they are happy
with that situation and are not envisaging further standardisation in that area
outside of 3GPP.<br>
&nbsp;<br>
So my view at the moment is that there is no point in IETF trying to address
the scope of what is already specified in cell broadcast (from base station to
end mobile).<br>
&nbsp;<br>
regards<br>
&nbsp;<br>
Keith<br>
</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><br>
&nbsp;</span><o:p></o:p></p>

</div>

<div class=MsoNormal align=center style='text-align:center'><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>

<hr size=3 width="95%" align=center>

</span></div>

<p style='margin-bottom:12.0pt'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><br>
</span><span style='font-size:10.0pt;font-family:Consolas'>_______________________________________________<br>
earlywarning mailing list<br>
<a href="x-msg://506/[email-masked]">[email-masked]</a><br>
<a href="https://www.ietf.org/mailman/listinfo/earlywarning">https://www.ietf.org/mailman/listinfo/earlywarning</a></span><o:p></o:p></p>

</div>

<p class=MsoNormal><span style='font-size:13.5pt;font-family:"Helvetica","sans-serif"'>_______________________________________________<br>
earlywarning mailing list<br>
<a href="mailto:[email-masked]">[email-masked]</a><br>
<a href="https://www.ietf.org/mailman/listinfo/earlywarning">https://www.ietf.org/mailman/listinfo/earlywarning</a><o:p></o:p></span></p>

</div>

</div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01CACC79.5C0E096A--

Content-class: urn:content-classes:message
Date: Thu, 25 Mar 2010 17:11:39 -0700
From: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
To: "ken carlberg" <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] (no subject)

This is a multi-part message in MIME format.

------_=_NextPart_001_01CACC78.E8994918
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

The ETWS and PWS work in 3GPP is an international standard that
addresses cell broadcast based alerts and encompasses CMAS here in the
U.S. That again is cell broadcast based and is closely aligned with the
U.S. CMAS implementation.

Brian Daly

From: ken carlberg [mailto:[email-masked]] 
Sent: Thursday, March 25, 2010 5:09 PM
To: DALY, BRIAN K (ATTCINW)
Cc: Brian Rosen; [email-masked]
Subject: Re: [earlywarning] (no subject)

please, let's remember not to be U.S. centric.

-ken

 

On Mar 25, 2010, at 8:03 PM, DALY, BRIAN K (ATTCINW) wrote:

They are connected to the wireless network and under FCC rules the CMSP
has responsibility for delivering emergency alerts to those devices
under FCC Part 10 rules and the CMSP election to provide those alerts.

So no, this work does not apply. CMAS applies to those devices.

Brian Daly

From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, March 25, 2010 5:00 PM
To: DALY, BRIAN K (ATTCINW); [email-masked]
Subject: Re: [earlywarning] (no subject)

Are they connected to the Internet?

If they are, it would apply.  If they aren't, then it wouldn't apply.

Brian

On 3/25/10 7:51 PM, "DALY, BRIAN K (ATTCINW)" <[email-masked]
<x-msg://506/[email-masked]> > wrote:

That will not apply to devices connected to wireless cellular networks.

From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, March 25, 2010 4:50 PM
To: DALY, BRIAN K (ATTCINW); [email-masked]
<x-msg://506/[email-masked]> 
Subject: Re: [earlywarning] (no subject)

Once again, this is NOT about a solution limited to wireless cellular
networks.  It is about a solution for internet connected endpoints of
all kinds.  

Brian

On 3/25/10 7:46 PM, "DALY, BRIAN K (ATTCINW)" <[email-masked]
<x-msg://506/[email-masked]> > wrote:
Keith - We agree with you, and to further the point, in wireless
cellular IP networks a point to point solution would be problematic.
Cell Broadcast is used for CMAS because SMS cannot be used for any real
time alerting - it was not designed for that application and has serious
limitations, as the FCC CMSAAC studied.
 
When it comes to the evolved packet core and IMS, again a point to point
solution  will cause significant congestion on the network and a
broadcast/multicast solution must be used to effectively deliver alert
messages. Thus things like location and "priority" are already handled
in the delivery network.
 
ATIS and 3GPP will be studying how to support multimedia alerts in the
future, as recommended by the FCC CMSAAC. This is all beyond the scope
of this work effort.
 
Regards,
Brian
 
Date: Thu, 25 Mar 2010 03:13:24 +0100
From: "DRAGE, Keith (Keith)" <[email-masked]
<x-msg://506/[email-masked]> >
Subject: Re: [earlywarning] Updated Charter Text for ATOCA
To: Hannes Tschofenig <[email-masked]
<x-msg://506/[email-masked]> >,
      "[email-masked] <x-msg://506/[email-masked]> "
<[email-masked] <x-msg://506/[email-masked]> >
Message-ID:
 
<[email-masked]
cent.com
<x-msg://506/[email-masked]
m.alcatel-lucent.com> >
      
Content-Type: text/plain; charset="us-ascii"
 
What I am not seeing here is any separation of the problem from the one
that cell broadcast attempts to solve. Fundamentally, cell broadcast, as
exists on all GSM, UTRAN and E-UTRAN based cell phones and is being used
for Tsunami warning and Public Warning, exists and is not going to
substantially change. The major limitation here is is length of message,
and what does get transmitted will be very much dependent on that
restriction.
 
Moreover I have heard from a number of governmental bodies that they are
happy with that situation and are not envisaging further standardisation
in that area outside of 3GPP.
 
So my view at the moment is that there is no point in IETF trying to
address the scope of what is already specified in cell broadcast (from
base station to end mobile).
 
regards
 
Keith

________________________________

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

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

------_=_NextPart_001_01CACC78.E8994918
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<base href="x-msg://506/">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Helvetica;
	panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
	{font-family:Helvetica;
	panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.apple-style-span
	{mso-style-name:apple-style-span;}
span.apple-converted-space
	{mso-style-name:apple-converted-space;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-US link=blue vlink=purple style='word-wrap: break-word;
-webkit-nbsp-mode: space;-webkit-line-break: after-white-space'>

<div class=Section1>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>The ETWS and PWS work in 3GPP is an international standard that
addresses cell broadcast based alerts and encompasses CMAS here in the U.S.
That again is cell broadcast based and is closely aligned with the U.S. CMAS
implementation.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Brian Daly<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>

<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> ken carlberg
[mailto:[email-masked]] <br>
<b>Sent:</b> Thursday, March 25, 2010 5:09 PM<br>
<b>To:</b> DALY, BRIAN K (ATTCINW)<br>
<b>Cc:</b> Brian Rosen; [email-masked]<br>
<b>Subject:</b> Re: [earlywarning] (no subject)<o:p></o:p></span></p>

</div>

</div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>please, let's remember not to be U.S. centric.<o:p></o:p></p>

<div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=MsoNormal>-ken<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<div>

<div>

<p class=MsoNormal>On Mar 25, 2010, at 8:03 PM, DALY, BRIAN K (ATTCINW) wrote:<o:p></o:p></p>

</div>

<p class=MsoNormal><br>
<br>
<o:p></o:p></p>

<div>

<div>

<div>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>They are connected to the wireless network and under FCC rules
the CMSP has responsibility for delivering emergency alerts to those devices
under FCC Part 10 rules and the CMSP election to provide those alerts.</span><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>&nbsp;</span><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>So no, this work does not apply. CMAS applies to those devices.</span><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>&nbsp;</span><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Brian Daly</span><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>&nbsp;</span><o:p></o:p></p>

</div>

<div>

<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in;
border-width:initial;border-color:initial'>

<div>

<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
class=apple-converted-space><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>&nbsp;</span></span><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>Brian Rosen
[mailto:[email-masked]]<span class=apple-converted-space>&nbsp;</span><br>
<b>Sent:</b><span class=apple-converted-space>&nbsp;</span>Thursday, March 25,
2010 5:00 PM<br>
<b>To:</b><span class=apple-converted-space>&nbsp;</span>DALY, BRIAN K
(ATTCINW);<span class=apple-converted-space>&nbsp;</span><a
href="mailto:[email-masked]">[email-masked]</a><br>
<b>Subject:</b><span class=apple-converted-space>&nbsp;</span>Re:
[earlywarning] (no subject)</span><o:p></o:p></p>

</div>

</div>

</div>

<div>

<p class=MsoNormal>&nbsp;<o:p></o:p></p>

</div>

<p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif"'>Are they connected to the Internet?<br>
<br>
If they are, it would apply. &nbsp;If they aren&#8217;t, then it wouldn&#8217;t
apply.<br>
<br>
Brian<br>
<br>
<br>
On 3/25/10 7:51 PM, &quot;DALY, BRIAN K (ATTCINW)&quot; &lt;<a
href="x-msg://506/[email-masked]">[email-masked]</a>&gt; wrote:</span><o:p></o:p></p>

<div>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>That will not apply to devices connected to wireless cellular
networks.<br>
&nbsp;<br>
</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><br>
</span><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
class=apple-converted-space><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>&nbsp;</span></span><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>Brian Rosen [<a
href="mailto:[email-masked]">mailto:[email-masked]</a>]<span
class=apple-converted-space>&nbsp;</span><br>
<b>Sent:</b><span class=apple-converted-space>&nbsp;</span>Thursday, March 25,
2010 4:50 PM<br>
<b>To:</b><span class=apple-converted-space>&nbsp;</span>DALY, BRIAN K
(ATTCINW);<span class=apple-converted-space>&nbsp;</span><a
href="x-msg://506/[email-masked]">[email-masked]</a><br>
<b>Subject:</b><span class=apple-converted-space>&nbsp;</span>Re:
[earlywarning] (no subject)<br>
</span><br>
<span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>Once again,
this is NOT about a solution limited to wireless cellular networks. &nbsp;It is
about a solution for internet connected endpoints of all kinds. &nbsp;<br>
<br>
Brian<br>
<br>
<br>
On 3/25/10 7:46 PM, &quot;DALY, BRIAN K (ATTCINW)&quot; &lt;<a
href="x-msg://506/[email-masked]">[email-masked]</a>&gt; wrote:<br>
Keith &#8211; We agree with you, and to further the point, in wireless cellular
IP networks a point to point solution would be problematic. Cell Broadcast is
used for CMAS because SMS cannot be used for any real time alerting &#8211; it
was not designed for that application and has serious limitations, as the FCC
CMSAAC studied.<br>
&nbsp;<br>
When it comes to the evolved packet core and IMS, again a point to point
solution &nbsp;will cause significant congestion on the network and a
broadcast/multicast solution must be used to effectively deliver alert
messages. Thus things like location and &#8220;priority&#8221; are already
handled in the delivery network.<br>
&nbsp;<br>
ATIS and 3GPP will be studying how to support multimedia alerts in the future,
as recommended by the FCC CMSAAC. This is all beyond the scope of this work
effort.<br>
&nbsp;<br>
Regards,<br>
Brian<br>
&nbsp;<br>
</span><span style='font-size:10.0pt;font-family:Consolas'>Date: Thu, 25 Mar
2010 03:13:24 +0100<br>
From: &quot;DRAGE, Keith (Keith)&quot; &lt;<a
href="x-msg://506/[email-masked]">[email-masked]</a>&gt;<br>
Subject: Re: [earlywarning] Updated Charter Text for ATOCA<br>
To: Hannes Tschofenig &lt;<a href="x-msg://506/[email-masked]">[email-masked]</a>&gt;,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&quot;<a
href="x-msg://506/[email-masked]">[email-masked]</a>&quot; &lt;<a
href="x-msg://506/[email-masked]">[email-masked]</a>&gt;<br>
Message-ID:<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;<a
href="x-msg://506/[email-masked]">[email-masked]</a>&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
Content-Type: text/plain; charset=&quot;us-ascii&quot;<br>
&nbsp;<br>
What I am not seeing here is any separation of the problem from the one that
cell broadcast attempts to solve. Fundamentally, cell broadcast, as exists on
all GSM, UTRAN and E-UTRAN based cell phones and is being used for Tsunami
warning and Public Warning, exists and is not going to substantially change.
The major limitation here is is length of message, and what does get
transmitted will be very much dependent on that restriction.<br>
&nbsp;<br>
Moreover I have heard from a number of governmental bodies that they are happy
with that situation and are not envisaging further standardisation in that area
outside of 3GPP.<br>
&nbsp;<br>
So my view at the moment is that there is no point in IETF trying to address
the scope of what is already specified in cell broadcast (from base station to
end mobile).<br>
&nbsp;<br>
regards<br>
&nbsp;<br>
Keith<br>
</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><br>
&nbsp;</span><o:p></o:p></p>

</div>

<div class=MsoNormal align=center style='text-align:center'><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>

<hr size=3 width="95%" align=center>

</span></div>

<p style='margin-bottom:12.0pt'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><br>
</span><span style='font-size:10.0pt;font-family:Consolas'>_______________________________________________<br>
earlywarning mailing list<br>
<a href="x-msg://506/[email-masked]">[email-masked]</a><br>
<a href="https://www.ietf.org/mailman/listinfo/earlywarning">https://www.ietf.org/mailman/listinfo/earlywarning</a></span><o:p></o:p></p>

</div>

<p class=MsoNormal><span style='font-size:13.5pt;font-family:"Helvetica","sans-serif"'>_______________________________________________<br>
earlywarning mailing list<br>
<a href="mailto:[email-masked]">[email-masked]</a><br>
<a href="https://www.ietf.org/mailman/listinfo/earlywarning">https://www.ietf.org/mailman/listinfo/earlywarning</a><o:p></o:p></span></p>

</div>

</div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01CACC78.E8994918--

From: ken carlberg <[email-masked]>
Date: Thu, 25 Mar 2010 20:09:10 -0400
To: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] (no subject)

--Apple-Mail-10--802825183
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

please, let's remember not to be U.S. centric.

-ken

On Mar 25, 2010, at 8:03 PM, DALY, BRIAN K (ATTCINW) wrote:

> They are connected to the wireless network and under FCC rules the CMSP has responsibility for delivering emergency alerts to those devices under FCC Part 10 rules and the CMSP election to provide those alerts.
>  
> So no, this work does not apply. CMAS applies to those devices.
>  
> Brian Daly
>  
> From: Brian Rosen [mailto:[email-masked]] 
> Sent: Thursday, March 25, 2010 5:00 PM
> To: DALY, BRIAN K (ATTCINW); [email-masked]
> Subject: Re: [earlywarning] (no subject)
>  
> Are they connected to the Internet?
> 
> If they are, it would apply.  If they aren�t, then it wouldn�t apply.
> 
> Brian
> 
> 
> On 3/25/10 7:51 PM, "DALY, BRIAN K (ATTCINW)" <[email-masked]> wrote:
> 
> That will not apply to devices connected to wireless cellular networks.
>  
> 
> From: Brian Rosen [mailto:[email-masked]] 
> Sent: Thursday, March 25, 2010 4:50 PM
> To: DALY, BRIAN K (ATTCINW); [email-masked]
> Subject: Re: [earlywarning] (no subject)
> 
> Once again, this is NOT about a solution limited to wireless cellular networks.  It is about a solution for internet connected endpoints of all kinds.  
> 
> Brian
> 
> 
> On 3/25/10 7:46 PM, "DALY, BRIAN K (ATTCINW)" <[email-masked]> wrote:
> Keith � We agree with you, and to further the point, in wireless cellular IP networks a point to point solution would be problematic. Cell Broadcast is used for CMAS because SMS cannot be used for any real time alerting � it was not designed for that application and has serious limitations, as the FCC CMSAAC studied.
>  
> When it comes to the evolved packet core and IMS, again a point to point solution  will cause significant congestion on the network and a broadcast/multicast solution must be used to effectively deliver alert messages. Thus things like location and �priority� are already handled in the delivery network.
>  
> ATIS and 3GPP will be studying how to support multimedia alerts in the future, as recommended by the FCC CMSAAC. This is all beyond the scope of this work effort.
>  
> Regards,
> Brian
>  
> Date: Thu, 25 Mar 2010 03:13:24 +0100
> From: "DRAGE, Keith (Keith)" <[email-masked]>
> Subject: Re: [earlywarning] Updated Charter Text for ATOCA
> To: Hannes Tschofenig <[email-masked]>,
>       "[email-masked]" <[email-masked]>
> Message-ID:
>       <[email-masked]>
>       
> Content-Type: text/plain; charset="us-ascii"
>  
> What I am not seeing here is any separation of the problem from the one that cell broadcast attempts to solve. Fundamentally, cell broadcast, as exists on all GSM, UTRAN and E-UTRAN based cell phones and is being used for Tsunami warning and Public Warning, exists and is not going to substantially change. The major limitation here is is length of message, and what does get transmitted will be very much dependent on that restriction.
>  
> Moreover I have heard from a number of governmental bodies that they are happy with that situation and are not envisaging further standardisation in that area outside of 3GPP.
>  
> So my view at the moment is that there is no point in IETF trying to address the scope of what is already specified in cell broadcast (from base station to end mobile).
>  
> regards
>  
> Keith
> 
>  
> 
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning
> 
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

--Apple-Mail-10--802825183
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

<html><head><base href="x-msg://506/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">please, let's remember not to be U.S. centric.<div><br></div><div>-ken</div><div><br></div><div><br><div><div>On Mar 25, 2010, at 8:03 PM, DALY, BRIAN K (ATTCINW) wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div lang="EN-US" link="blue" vlink="purple"><div class="Section1"><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">They are connected to the wireless network and under FCC rules the CMSP has responsibility for delivering emergency alerts to those devices under FCC Part 10 rules and the CMSP election to provide those alerts.<o:p></o:p></span></div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">So no, this work does not apply. CMAS applies to those devices.<o:p></o:p></span></div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">Brian Daly<o:p></o:p></span></div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></div><div><div style="border-right-style: none; border-bottom-style: none; border-left-style: none; border-width: initial; border-color: initial; border-top-style: solid; border-top-color: rgb(181, 196, 223); border-top-width: 1pt; padding-top: 3pt; padding-right: 0in; padding-bottom: 0in; padding-left: 0in; "><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: 0.0001pt; "><b><span style="font-size: 10pt; font-family: Tahoma, sans-serif; ">From:</span></b><span style="font-size: 10pt; font-family: Tahoma, sans-serif; "><span class="Apple-converted-space">&nbsp;</span>Brian Rosen [mailto:[email-masked]]<span class="Apple-converted-space">&nbsp;</span><br><b>Sent:</b><span class="Apple-converted-space">&nbsp;</span>Thursday, March 25, 2010 5:00 PM<br><b>To:</b><span class="Apple-converted-space">&nbsp;</span>DALY, BRIAN K (ATTCINW);<span class="Apple-converted-space">&nbsp;</span><a href="mailto:[email-masked]" style="color: blue; text-decoration: underline; ">[email-masked]</a><br><b>Subject:</b><span class="Apple-converted-space">&nbsp;</span>Re: [earlywarning] (no subject)<o:p></o:p></span></div></div></div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: 0.0001pt; "><o:p>&nbsp;</o:p></div><p class="MsoNormal" style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: 12pt; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; ">Are they connected to the Internet?<br><br>If they are, it would apply. &nbsp;If they aren�t, then it wouldn�t apply.<br><br>Brian<br><br><br>On 3/25/10 7:51 PM, "DALY, BRIAN K (ATTCINW)" &lt;<a href="[email-masked]" style="color: blue; text-decoration: underline; ">[email-masked]</a>&gt; wrote:</span><o:p></o:p></p><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">That will not apply to devices connected to wireless cellular networks.<br>&nbsp;<br></span><span style="font-size: 11pt; font-family: Calibri, sans-serif; "><br></span><b><span style="font-size: 10pt; font-family: Tahoma, sans-serif; ">From:</span></b><span style="font-size: 10pt; font-family: Tahoma, sans-serif; "><span class="Apple-converted-space">&nbsp;</span>Brian Rosen [<a href="mailto:[email-masked]" style="color: blue; text-decoration: underline; ">mailto:[email-masked]</a>]<span class="Apple-converted-space">&nbsp;</span><br><b>Sent:</b><span class="Apple-converted-space">&nbsp;</span>Thursday, March 25, 2010 4:50 PM<br><b>To:</b><span class="Apple-converted-space">&nbsp;</span>DALY, BRIAN K (ATTCINW);<span class="Apple-converted-space">&nbsp;</span><a href="[email-masked]" style="color: blue; text-decoration: underline; ">[email-masked]</a><br><b>Subject:</b><span class="Apple-converted-space">&nbsp;</span>Re: [earlywarning] (no subject)<br></span><br><span style="font-size: 11pt; font-family: Calibri, sans-serif; ">Once again, this is NOT about a solution limited to wireless cellular networks. &nbsp;It is about a solution for internet connected endpoints of all kinds. &nbsp;<br><br>Brian<br><br><br>On 3/25/10 7:46 PM, "DALY, BRIAN K (ATTCINW)" &lt;<a href="[email-masked]" style="color: blue; text-decoration: underline; ">[email-masked]</a>&gt; wrote:<br>Keith � We agree with you, and to further the point, in wireless cellular IP networks a point to point solution would be problematic. Cell Broadcast is used for CMAS because SMS cannot be used for any real time alerting � it was not designed for that application and has serious limitations, as the FCC CMSAAC studied.<br>&nbsp;<br>When it comes to the evolved packet core and IMS, again a point to point solution &nbsp;will cause significant congestion on the network and a broadcast/multicast solution must be used to effectively deliver alert messages. Thus things like location and �priority� are already handled in the delivery network.<br>&nbsp;<br>ATIS and 3GPP will be studying how to support multimedia alerts in the future, as recommended by the FCC CMSAAC. This is all beyond the scope of this work effort.<br>&nbsp;<br>Regards,<br>Brian<br>&nbsp;<br></span><span style="font-size: 10pt; font-family: Consolas; ">Date: Thu, 25 Mar 2010 03:13:24 +0100<br>From: "DRAGE, Keith (Keith)" &lt;<a href="[email-masked]" style="color: blue; text-decoration: underline; ">[email-masked]</a>&gt;<br>Subject: Re: [earlywarning] Updated Charter Text for ATOCA<br>To: Hannes Tschofenig &lt;<a href="[email-masked]" style="color: blue; text-decoration: underline; ">[email-masked]</a>&gt;,<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"<a href="[email-masked]" style="color: blue; text-decoration: underline; ">[email-masked]</a>" &lt;<a href="[email-masked]" style="color: blue; text-decoration: underline; ">[email-masked]</a>&gt;<br>Message-ID:<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;<a href="[email-masked]" style="color: blue; text-decoration: underline; ">[email-masked]</a>&gt;<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>Content-Type: text/plain; charset="us-ascii"<br>&nbsp;<br>What I am not seeing here is any separation of the problem from the one that cell broadcast attempts to solve. Fundamentally, cell broadcast, as exists on all GSM, UTRAN and E-UTRAN based cell phones and is being used for Tsunami warning and Public Warning, exists and is not going to substantially change. The major limitation here is is length of message, and what does get transmitted will be very much dependent on that restriction.<br>&nbsp;<br>Moreover I have heard from a number of governmental bodies that they are happy with that situation and are not envisaging further standardisation in that area outside of 3GPP.<br>&nbsp;<br>So my view at the moment is that there is no point in IETF trying to address the scope of what is already specified in cell broadcast (from base station to end mobile).<br>&nbsp;<br>regards<br>&nbsp;<br>Keith<br></span><span style="font-size: 11pt; font-family: Calibri, sans-serif; "><br>&nbsp;</span><o:p></o:p></div><div class="MsoNormal" align="center" style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; text-align: center; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; "><hr size="3" width="95%" align="center"></span></div><p style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-bottom: 12pt; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; "><br></span><span style="font-size: 10pt; font-family: Consolas; ">_______________________________________________<br>earlywarning mailing list<br><a href="[email-masked]" style="color: blue; text-decoration: underline; ">[email-masked]</a><br><a href="https://www.ietf.org/mailman/listinfo/earlywarning" style="color: blue; text-decoration: underline; ">https://www.ietf.org/mailman/listinfo/earlywarning</a></span><o:p></o:p></p></div>_______________________________________________<br>earlywarning mailing list<br><a href="mailto:[email-masked]" style="color: blue; text-decoration: underline; ">[email-masked]</a><br><a href="https://www.ietf.org/mailman/listinfo/earlywarning" style="color: blue; text-decoration: underline; ">https://www.ietf.org/mailman/listinfo/earlywarning</a><br></div></span></blockquote></div><br></div></body></html>
--Apple-Mail-10--802825183--

From: ken carlberg <[email-masked]>
Date: Thu, 25 Mar 2010 20:07:54 -0400
To: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] (no subject)

--Apple-Mail-9--802901603
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

On Mar 25, 2010, at 7:46 PM, DALY, BRIAN K (ATTCINW) wrote:

> When it comes to the evolved packet core and IMS, again a point to point solution  will cause significant congestion on the network and a broadcast/multicast solution must be used to effectively deliver alert messages. Thus things like location and �priority� are already handled in the delivery network.

I'll echo Brian Rosen's statement that this is not limited to wireless networks.

and the notion or implication that broadcast/multicast is a solution that already satisfies the need to address "priority" is too much of a stretch.  Multicast *efficiently* (versus effectively) distributes information through a network.  On the other hand, multicast storms or an excess injection of mcast traffic compounds the problem of a contention of resources. 

Outside of that, a contention of resources not only applies to the forwarding infrastructure but also the servers/relays that may exist, hence James Polk's insistence on keeping the door open for things like RPH.  

I'll reiterate my earlier suggestion that we leave the door open in the charter text for revisiting  the topic of prioritization. 

cheers,

-ken

--Apple-Mail-9--802901603
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Mar 25, 2010, at 7:46 PM, DALY, BRIAN K (ATTCINW) wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><span class="Apple-style-span" style="font-family: Calibri, sans-serif; font-size: 15px; ">When it comes to the evolved packet core and IMS, again a point to point solution &nbsp;will cause significant congestion on the network and a broadcast/multicast solution must be used to effectively deliver alert messages. Thus things like location and �priority� are already handled in the delivery network.</span></span></blockquote></div><br><div>I'll echo Brian Rosen's statement that this is not limited to wireless networks.</div><div><br></div><div>and the notion or implication that broadcast/multicast is a solution that already satisfies the need to address "priority" is too much of a stretch. &nbsp;Multicast *efficiently* (versus effectively) distributes information through a network. &nbsp;On the other hand, multicast storms or an excess injection of mcast traffic compounds the problem of a contention of resources.&nbsp;</div><div><br></div><div>Outside of that, a contention of resources not only applies to the forwarding infrastructure but also the servers/relays that may exist, hence James Polk's insistence on keeping the door open for things like RPH. &nbsp;</div><div><br></div><div>I'll reiterate my earlier suggestion that we leave the door open in the charter text for revisiting &nbsp;the topic of prioritization.&nbsp;</div><div><br></div><div>cheers,</div><div><br></div><div>-ken</div><div><br></div></body></html>
--Apple-Mail-9--802901603--

Content-class: urn:content-classes:message
Date: Thu, 25 Mar 2010 17:03:03 -0700
From: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
To: "Brian Rosen" <[email-masked]>, <[email-masked]>
Subject: Re: [earlywarning] (no subject)

This is a multi-part message in MIME format.

------_=_NextPart_001_01CACC77.B4E62BD2
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

They are connected to the wireless network and under FCC rules the CMSP
has responsibility for delivering emergency alerts to those devices
under FCC Part 10 rules and the CMSP election to provide those alerts.

So no, this work does not apply. CMAS applies to those devices.

Brian Daly

From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, March 25, 2010 5:00 PM
To: DALY, BRIAN K (ATTCINW); [email-masked]
Subject: Re: [earlywarning] (no subject)

Are they connected to the Internet?

If they are, it would apply.  If they aren't, then it wouldn't apply.

Brian

On 3/25/10 7:51 PM, "DALY, BRIAN K (ATTCINW)" <[email-masked]> wrote:

That will not apply to devices connected to wireless cellular networks.

From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, March 25, 2010 4:50 PM
To: DALY, BRIAN K (ATTCINW); [email-masked]
Subject: Re: [earlywarning] (no subject)

Once again, this is NOT about a solution limited to wireless cellular
networks.  It is about a solution for internet connected endpoints of
all kinds.  

Brian

On 3/25/10 7:46 PM, "DALY, BRIAN K (ATTCINW)" <[email-masked]> wrote:
Keith - We agree with you, and to further the point, in wireless
cellular IP networks a point to point solution would be problematic.
Cell Broadcast is used for CMAS because SMS cannot be used for any real
time alerting - it was not designed for that application and has serious
limitations, as the FCC CMSAAC studied.
 
When it comes to the evolved packet core and IMS, again a point to point
solution  will cause significant congestion on the network and a
broadcast/multicast solution must be used to effectively deliver alert
messages. Thus things like location and "priority" are already handled
in the delivery network.
 
ATIS and 3GPP will be studying how to support multimedia alerts in the
future, as recommended by the FCC CMSAAC. This is all beyond the scope
of this work effort.
 
Regards,
Brian
 
Date: Thu, 25 Mar 2010 03:13:24 +0100
From: "DRAGE, Keith (Keith)" <[email-masked]>
Subject: Re: [earlywarning] Updated Charter Text for ATOCA
To: Hannes Tschofenig <[email-masked]>,
      "[email-masked]" <[email-masked]>
Message-ID:
 
<[email-masked]
cent.com>
      
Content-Type: text/plain; charset="us-ascii"
 
What I am not seeing here is any separation of the problem from the one
that cell broadcast attempts to solve. Fundamentally, cell broadcast, as
exists on all GSM, UTRAN and E-UTRAN based cell phones and is being used
for Tsunami warning and Public Warning, exists and is not going to
substantially change. The major limitation here is is length of message,
and what does get transmitted will be very much dependent on that
restriction.
 
Moreover I have heard from a number of governmental bodies that they are
happy with that situation and are not envisaging further standardisation
in that area outside of 3GPP.
 
So my view at the moment is that there is no point in IETF trying to
address the scope of what is already specified in cell broadcast (from
base station to end mobile).
 
regards
 
Keith

________________________________

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

------_=_NextPart_001_01CACC77.B4E62BD2
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>Re: [earlywarning] (no subject)</title>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>They are connected to the wireless network and under FCC rules
the CMSP has responsibility for delivering emergency alerts to those devices
under FCC Part 10 rules and the CMSP election to provide those alerts.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>So no, this work does not apply. CMAS applies to those devices.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Brian Daly<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>

<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Brian Rosen
[mailto:[email-masked]] <br>
<b>Sent:</b> Thursday, March 25, 2010 5:00 PM<br>
<b>To:</b> DALY, BRIAN K (ATTCINW); [email-masked]<br>
<b>Subject:</b> Re: [earlywarning] (no subject)<o:p></o:p></span></p>

</div>

</div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif"'>Are they connected to the Internet?<br>
<br>
If they are, it would apply. &nbsp;If they aren&#8217;t, then it wouldn&#8217;t
apply.<br>
<br>
Brian<br>
<br>
<br>
On 3/25/10 7:51 PM, &quot;DALY, BRIAN K (ATTCINW)&quot; &lt;<a
href="[email-masked]">[email-masked]</a>&gt; wrote:</span><o:p></o:p></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>That will not apply to devices connected to wireless cellular
networks.<br>
&nbsp;<br>
</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><br>
</span><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Brian Rosen [<a
href="mailto:[email-masked]">mailto:[email-masked]</a>] <br>
<b>Sent:</b> Thursday, March 25, 2010 4:50 PM<br>
<b>To:</b> DALY, BRIAN K (ATTCINW); <a href="[email-masked]">[email-masked]</a><br>
<b>Subject:</b> Re: [earlywarning] (no subject)<br>
</span><br>
<span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>Once again,
this is NOT about a solution limited to wireless cellular networks. &nbsp;It is
about a solution for internet connected endpoints of all kinds. &nbsp;<br>
<br>
Brian<br>
<br>
<br>
On 3/25/10 7:46 PM, &quot;DALY, BRIAN K (ATTCINW)&quot; &lt;<a
href="[email-masked]">[email-masked]</a>&gt; wrote:<br>
Keith &#8211; We agree with you, and to further the point, in wireless cellular
IP networks a point to point solution would be problematic. Cell Broadcast is
used for CMAS because SMS cannot be used for any real time alerting &#8211; it
was not designed for that application and has serious limitations, as the FCC
CMSAAC studied.<br>
&nbsp;<br>
When it comes to the evolved packet core and IMS, again a point to point
solution &nbsp;will cause significant congestion on the network and a
broadcast/multicast solution must be used to effectively deliver alert
messages. Thus things like location and &#8220;priority&#8221; are already
handled in the delivery network.<br>
&nbsp;<br>
ATIS and 3GPP will be studying how to support multimedia alerts in the future,
as recommended by the FCC CMSAAC. This is all beyond the scope of this work
effort.<br>
&nbsp;<br>
Regards,<br>
Brian<br>
&nbsp;<br>
</span><span style='font-size:10.0pt;font-family:Consolas'>Date: Thu, 25 Mar
2010 03:13:24 +0100<br>
From: &quot;DRAGE, Keith (Keith)&quot; &lt;<a
href="[email-masked]">[email-masked]</a>&gt;<br>
Subject: Re: [earlywarning] Updated Charter Text for ATOCA<br>
To: Hannes Tschofenig &lt;<a href="[email-masked]">[email-masked]</a>&gt;,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&quot;<a href="[email-masked]">[email-masked]</a>&quot;
&lt;<a href="[email-masked]">[email-masked]</a>&gt;<br>
Message-ID:<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;<a
href="[email-masked]">[email-masked]</a>&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
Content-Type: text/plain; charset=&quot;us-ascii&quot;<br>
&nbsp;<br>
What I am not seeing here is any separation of the problem from the one that
cell broadcast attempts to solve. Fundamentally, cell broadcast, as exists on
all GSM, UTRAN and E-UTRAN based cell phones and is being used for Tsunami
warning and Public Warning, exists and is not going to substantially change.
The major limitation here is is length of message, and what does get
transmitted will be very much dependent on that restriction.<br>
&nbsp;<br>
Moreover I have heard from a number of governmental bodies that they are happy
with that situation and are not envisaging further standardisation in that area
outside of 3GPP.<br>
&nbsp;<br>
So my view at the moment is that there is no point in IETF trying to address
the scope of what is already specified in cell broadcast (from base station to
end mobile).<br>
&nbsp;<br>
regards<br>
&nbsp;<br>
Keith<br>
</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><br>
&nbsp; </span><o:p></o:p></p>

<div class=MsoNormal align=center style='text-align:center'><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>

<hr size=3 width="95%" align=center>

</span></div>

<p style='margin-bottom:12.0pt'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><br>
</span><span style='font-size:10.0pt;font-family:Consolas'>_______________________________________________<br>
earlywarning mailing list<br>
<a href="[email-masked]">[email-masked]</a><br>
<a href="https://www.ietf.org/mailman/listinfo/earlywarning">https://www.ietf.org/mailman/listinfo/earlywarning</a></span><o:p></o:p></p>

</div>

</body>

</html>

------_=_NextPart_001_01CACC77.B4E62BD2--

Date: Thu, 25 Mar 2010 19:59:43 -0400
From: Brian Rosen <[email-masked]>
To: "DALY, BRIAN K (ATTCINW)" <[email-masked]>, <[email-masked]>
Subject: Re: [earlywarning] (no subject)

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3352391989_9890027
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Are they connected to the Internet?

If they are, it would apply.  If they aren�t, then it wouldn�t apply.

Brian

On 3/25/10 7:51 PM, "DALY, BRIAN K (ATTCINW)" <[email-masked]> wrote:

> That will not apply to devices connected to wireless cellular networks.
>  
> 
> From: Brian Rosen [mailto:[email-masked]]
> Sent: Thursday, March 25, 2010 4:50 PM
> To: DALY, BRIAN K (ATTCINW); [email-masked]
> Subject: Re: [earlywarning] (no subject)
>  
> Once again, this is NOT about a solution limited to wireless cellular
> networks.  It is about a solution for internet connected endpoints of all
> kinds.  
> 
> Brian
> 
> 
> On 3/25/10 7:46 PM, "DALY, BRIAN K (ATTCINW)" <[email-masked]> wrote:
> Keith � We agree with you, and to further the point, in wireless cellular IP
> networks a point to point solution would be problematic. Cell Broadcast is
> used for CMAS because SMS cannot be used for any real time alerting � it was
> not designed for that application and has serious limitations, as the FCC
> CMSAAC studied.
>  
> When it comes to the evolved packet core and IMS, again a point to point
> solution  will cause significant congestion on the network and a
> broadcast/multicast solution must be used to effectively deliver alert
> messages. Thus things like location and �priority� are already handled in the
> delivery network.
>  
> ATIS and 3GPP will be studying how to support multimedia alerts in the future,
> as recommended by the FCC CMSAAC. This is all beyond the scope of this work
> effort.
>  
> Regards,
> Brian
>  
> Date: Thu, 25 Mar 2010 03:13:24 +0100
> From: "DRAGE, Keith (Keith)" <[email-masked]>
> Subject: Re: [earlywarning] Updated Charter Text for ATOCA
> To: Hannes Tschofenig <[email-masked]>,
>       "[email-masked]" <[email-masked]>
> Message-ID:
>       
> <[email-masked]
> om>
>       
> Content-Type: text/plain; charset="us-ascii"
>  
> What I am not seeing here is any separation of the problem from the one that
> cell broadcast attempts to solve. Fundamentally, cell broadcast, as exists on
> all GSM, UTRAN and E-UTRAN based cell phones and is being used for Tsunami
> warning and Public Warning, exists and is not going to substantially change.
> The major limitation here is is length of message, and what does get
> transmitted will be very much dependent on that restriction.
>  
> Moreover I have heard from a number of governmental bodies that they are happy
> with that situation and are not envisaging further standardisation in that
> area outside of 3GPP.
>  
> So my view at the moment is that there is no point in IETF trying to address
> the scope of what is already specified in cell broadcast (from base station to
> end mobile).
>  
> regards
>  
> Keith
> 
>  
> 
> 
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning
> 

--B_3352391989_9890027
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [earlywarning] (no subject)</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Are they connected to the Internet?<BR>
<BR>
If they are, it would apply. &nbsp;If they aren&#8217;t, then it wouldn&#8217;t apply.<BR>
<BR>
Brian<BR>
<BR>
<BR>
On 3/25/10 7:51 PM, &quot;DALY, BRIAN K (ATTCINW)&quot; &lt;<a href="[email-masked]">[email-masked]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><FONT COLOR="#1F497D">That will not apply to devices connected to wireless cellular networks.<BR>
&nbsp;<BR>
</FONT><BR>
</SPAN></FONT><FONT SIZE="2"><FONT FACE="Tahoma, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:10pt'><B>From:</B> Brian Rosen [<a href="mailto:[email-masked]">mailto:[email-masked]</a>] <BR>
<B>Sent:</B> Thursday, March 25, 2010 4:50 PM<BR>
<B>To:</B> DALY, BRIAN K (ATTCINW); <a href="[email-masked]">[email-masked]</a><BR>
<B>Subject:</B> Re: [earlywarning] (no subject)<BR>
</SPAN></FONT></FONT><FONT FACE="Times New Roman"><SPAN STYLE='font-size:12pt'> <BR>
</SPAN></FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Once again, this is NOT about a solution limited to wireless cellular networks. &nbsp;It is about a solution for internet connected endpoints of all kinds. &nbsp;<BR>
<BR>
Brian<BR>
<BR>
<BR>
On 3/25/10 7:46 PM, &quot;DALY, BRIAN K (ATTCINW)&quot; &lt;<a href="[email-masked]">[email-masked]</a>&gt; wrote:<BR>
Keith &#8211; We agree with you, and to further the point, in wireless cellular IP networks a point to point solution would be problematic. Cell Broadcast is used for CMAS because SMS cannot be used for any real time alerting &#8211; it was not designed for that application and has serious limitations, as the FCC CMSAAC studied.<BR>
&nbsp;<BR>
When it comes to the evolved packet core and IMS, again a point to point solution &nbsp;will cause significant congestion on the network and a broadcast/multicast solution must be used to effectively deliver alert messages. Thus things like location and &#8220;priority&#8221; are already handled in the delivery network.<BR>
&nbsp;<BR>
ATIS and 3GPP will be studying how to support multimedia alerts in the future, as recommended by the FCC CMSAAC. This is all beyond the scope of this work effort.<BR>
&nbsp;<BR>
Regards,<BR>
Brian<BR>
&nbsp;<BR>
</SPAN></FONT><FONT SIZE="2"><FONT FACE="Consolas, Courier New, Courier"><SPAN STYLE='font-size:10pt'>Date: Thu, 25 Mar 2010 03:13:24 +0100<BR>
From: &quot;DRAGE, Keith (Keith)&quot; &lt;<a href="[email-masked]">[email-masked]</a>&gt;<BR>
Subject: Re: [earlywarning] Updated Charter Text for ATOCA<BR>
To: Hannes Tschofenig &lt;<a href="[email-masked]">[email-masked]</a>&gt;,<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&quot;<a href="[email-masked]">[email-masked]</a>&quot; &lt;<a href="[email-masked]">[email-masked]</a>&gt;<BR>
Message-ID:<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;<a href="[email-masked]">[email-masked]</a>&gt;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
Content-Type: text/plain; charset=&quot;us-ascii&quot;<BR>
&nbsp;<BR>
What I am not seeing here is any separation of the problem from the one that cell broadcast attempts to solve. Fundamentally, cell broadcast, as exists on all GSM, UTRAN and E-UTRAN based cell phones and is being used for Tsunami warning and Public Warning, exists and is not going to substantially change. The major limitation here is is length of message, and what does get transmitted will be very much dependent on that restriction.<BR>
&nbsp;<BR>
Moreover I have heard from a number of governmental bodies that they are happy with that situation and are not envisaging further standardisation in that area outside of 3GPP.<BR>
&nbsp;<BR>
So my view at the moment is that there is no point in IETF trying to address the scope of what is already specified in cell broadcast (from base station to end mobile).<BR>
&nbsp;<BR>
regards<BR>
&nbsp;<BR>
Keith<BR>
</SPAN></FONT></FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
&nbsp;
</SPAN></FONT>
<P ALIGN=CENTER>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><HR ALIGN=CENTER SIZE="3" WIDTH="95%"></SPAN></FONT>
<P>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
</SPAN></FONT><FONT SIZE="2"><FONT FACE="Consolas, Courier New, Courier"><SPAN STYLE='font-size:10pt'>_______________________________________________<BR>
earlywarning mailing list<BR>
<a href="[email-masked]">[email-masked]</a><BR>
<a href="https://www.ietf.org/mailman/listinfo/earlywarning">https://www.ietf.org/mailman/listinfo/earlywarning</a><BR>
</SPAN></FONT></FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>

--B_3352391989_9890027--

Content-class: urn:content-classes:message
Date: Thu, 25 Mar 2010 16:51:25 -0700
From: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
To: "Brian Rosen" <[email-masked]>, <[email-masked]>
Subject: Re: [earlywarning] (no subject)

This is a multi-part message in MIME format.

------_=_NextPart_001_01CACC76.15150B42
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

That will not apply to devices connected to wireless cellular networks.

From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, March 25, 2010 4:50 PM
To: DALY, BRIAN K (ATTCINW); [email-masked]
Subject: Re: [earlywarning] (no subject)

Once again, this is NOT about a solution limited to wireless cellular
networks.  It is about a solution for internet connected endpoints of
all kinds.  

Brian

On 3/25/10 7:46 PM, "DALY, BRIAN K (ATTCINW)" <[email-masked]> wrote:

Keith - We agree with you, and to further the point, in wireless
cellular IP networks a point to point solution would be problematic.
Cell Broadcast is used for CMAS because SMS cannot be used for any real
time alerting - it was not designed for that application and has serious
limitations, as the FCC CMSAAC studied.
 
When it comes to the evolved packet core and IMS, again a point to point
solution  will cause significant congestion on the network and a
broadcast/multicast solution must be used to effectively deliver alert
messages. Thus things like location and "priority" are already handled
in the delivery network.
 
ATIS and 3GPP will be studying how to support multimedia alerts in the
future, as recommended by the FCC CMSAAC. This is all beyond the scope
of this work effort.
 
Regards,
Brian
 
Date: Thu, 25 Mar 2010 03:13:24 +0100
From: "DRAGE, Keith (Keith)" <[email-masked]>
Subject: Re: [earlywarning] Updated Charter Text for ATOCA
To: Hannes Tschofenig <[email-masked]>,
      "[email-masked]" <[email-masked]>
Message-ID:
 
<[email-masked]
cent.com>
      
Content-Type: text/plain; charset="us-ascii"
 
What I am not seeing here is any separation of the problem from the one
that cell broadcast attempts to solve. Fundamentally, cell broadcast, as
exists on all GSM, UTRAN and E-UTRAN based cell phones and is being used
for Tsunami warning and Public Warning, exists and is not going to
substantially change. The major limitation here is is length of message,
and what does get transmitted will be very much dependent on that
restriction.
 
Moreover I have heard from a number of governmental bodies that they are
happy with that situation and are not envisaging further standardisation
in that area outside of 3GPP.
 
So my view at the moment is that there is no point in IETF trying to
address the scope of what is already specified in cell broadcast (from
base station to end mobile).
 
regards
 
Keith

________________________________

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

------_=_NextPart_001_01CACC76.15150B42
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>Re: [earlywarning] (no subject)</title>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>That will not apply to devices connected to wireless cellular
networks.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>

<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Brian Rosen
[mailto:[email-masked]] <br>
<b>Sent:</b> Thursday, March 25, 2010 4:50 PM<br>
<b>To:</b> DALY, BRIAN K (ATTCINW); [email-masked]<br>
<b>Subject:</b> Re: [earlywarning] (no subject)<o:p></o:p></span></p>

</div>

</div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif"'>Once again, this is NOT about a solution
limited to wireless cellular networks. &nbsp;It is about a solution for
internet connected endpoints of all kinds. &nbsp;<br>
<br>
Brian<br>
<br>
<br>
On 3/25/10 7:46 PM, &quot;DALY, BRIAN K (ATTCINW)&quot; &lt;<a
href="[email-masked]">[email-masked]</a>&gt; wrote:</span><o:p></o:p></p>

<p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif"'>Keith &#8211; We agree with you, and to
further the point, in wireless cellular IP networks a point to point solution
would be problematic. Cell Broadcast is used for CMAS because SMS cannot be
used for any real time alerting &#8211; it was not designed for that application
and has serious limitations, as the FCC CMSAAC studied.<br>
&nbsp;<br>
When it comes to the evolved packet core and IMS, again a point to point
solution &nbsp;will cause significant congestion on the network and a
broadcast/multicast solution must be used to effectively deliver alert
messages. Thus things like location and &#8220;priority&#8221; are already
handled in the delivery network.<br>
&nbsp;<br>
ATIS and 3GPP will be studying how to support multimedia alerts in the future,
as recommended by the FCC CMSAAC. This is all beyond the scope of this work
effort.<br>
&nbsp;<br>
Regards,<br>
Brian<br>
&nbsp;<br>
</span><span style='font-size:10.0pt;font-family:Consolas'>Date: Thu, 25 Mar
2010 03:13:24 +0100<br>
From: &quot;DRAGE, Keith (Keith)&quot; &lt;<a
href="[email-masked]">[email-masked]</a>&gt;<br>
Subject: Re: [earlywarning] Updated Charter Text for ATOCA<br>
To: Hannes Tschofenig &lt;<a href="[email-masked]">[email-masked]</a>&gt;,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&quot;<a href="[email-masked]">[email-masked]</a>&quot;
&lt;<a href="[email-masked]">[email-masked]</a>&gt;<br>
Message-ID:<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;<a
href="[email-masked]">[email-masked]</a>&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
Content-Type: text/plain; charset=&quot;us-ascii&quot;<br>
&nbsp;<br>
What I am not seeing here is any separation of the problem from the one that
cell broadcast attempts to solve. Fundamentally, cell broadcast, as exists on
all GSM, UTRAN and E-UTRAN based cell phones and is being used for Tsunami
warning and Public Warning, exists and is not going to substantially change.
The major limitation here is is length of message, and what does get
transmitted will be very much dependent on that restriction.<br>
&nbsp;<br>
Moreover I have heard from a number of governmental bodies that they are happy
with that situation and are not envisaging further standardisation in that area
outside of 3GPP.<br>
&nbsp;<br>
So my view at the moment is that there is no point in IETF trying to address
the scope of what is already specified in cell broadcast (from base station to
end mobile).<br>
&nbsp;<br>
regards<br>
&nbsp;<br>
Keith<br>
</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><br>
&nbsp;<o:p></o:p></span></p>

<div class=MsoNormal align=center style='text-align:center'><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>

<hr size=3 width="95%" align=center>

</span></div>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:Consolas'>_______________________________________________<br>
earlywarning mailing list<br>
<a href="[email-masked]">[email-masked]</a><br>
<a href="https://www.ietf.org/mailman/listinfo/earlywarning">https://www.ietf.org/mailman/listinfo/earlywarning</a></span><o:p></o:p></p>

</div>

</body>

</html>

------_=_NextPart_001_01CACC76.15150B42--

Date: Thu, 25 Mar 2010 19:50:17 -0400
From: Brian Rosen <[email-masked]>
To: "DALY, BRIAN K (ATTCINW)" <[email-masked]>, <[email-masked]>
Subject: Re: [earlywarning] (no subject)

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3352391429_9885686
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Once again, this is NOT about a solution limited to wireless cellular
networks.  It is about a solution for internet connected endpoints of all
kinds.  

Brian

On 3/25/10 7:46 PM, "DALY, BRIAN K (ATTCINW)" <[email-masked]> wrote:

> Keith � We agree with you, and to further the point, in wireless cellular IP
> networks a point to point solution would be problematic. Cell Broadcast is
> used for CMAS because SMS cannot be used for any real time alerting � it was
> not designed for that application and has serious limitations, as the FCC
> CMSAAC studied.
>  
> When it comes to the evolved packet core and IMS, again a point to point
> solution  will cause significant congestion on the network and a
> broadcast/multicast solution must be used to effectively deliver alert
> messages. Thus things like location and �priority� are already handled in the
> delivery network.
>  
> ATIS and 3GPP will be studying how to support multimedia alerts in the future,
> as recommended by the FCC CMSAAC. This is all beyond the scope of this work
> effort.
>  
> Regards,
> Brian
>  
> Date: Thu, 25 Mar 2010 03:13:24 +0100
> From: "DRAGE, Keith (Keith)" <[email-masked]>
> Subject: Re: [earlywarning] Updated Charter Text for ATOCA
> To: Hannes Tschofenig <[email-masked]>,
>       "[email-masked]" <[email-masked]>
> Message-ID:
>       
> <[email-masked]
> om>
>       
> Content-Type: text/plain; charset="us-ascii"
>  
> What I am not seeing here is any separation of the problem from the one that
> cell broadcast attempts to solve. Fundamentally, cell broadcast, as exists on
> all GSM, UTRAN and E-UTRAN based cell phones and is being used for Tsunami
> warning and Public Warning, exists and is not going to substantially change.
> The major limitation here is is length of message, and what does get
> transmitted will be very much dependent on that restriction.
>  
> Moreover I have heard from a number of governmental bodies that they are happy
> with that situation and are not envisaging further standardisation in that
> area outside of 3GPP.
>  
> So my view at the moment is that there is no point in IETF trying to address
> the scope of what is already specified in cell broadcast (from base station to
> end mobile).
>  
> regards
>  
> Keith
>  
>  
> 
> 
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

--B_3352391429_9885686
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [earlywarning] (no subject)</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Once again, this is NOT about a solution limited to wireless cellular networks. &nbsp;It is about a solution for internet connected endpoints of all kinds. &nbsp;<BR>
<BR>
Brian<BR>
<BR>
<BR>
On 3/25/10 7:46 PM, &quot;DALY, BRIAN K (ATTCINW)&quot; &lt;<a href="[email-masked]">[email-masked]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Keith &#8211; We agree with you, and to further the point, in wireless cellular IP networks a point to point solution would be problematic. Cell Broadcast is used for CMAS because SMS cannot be used for any real time alerting &#8211; it was not designed for that application and has serious limitations, as the FCC CMSAAC studied.<BR>
&nbsp;<BR>
When it comes to the evolved packet core and IMS, again a point to point solution &nbsp;will cause significant congestion on the network and a broadcast/multicast solution must be used to effectively deliver alert messages. Thus things like location and &#8220;priority&#8221; are already handled in the delivery network.<BR>
&nbsp;<BR>
ATIS and 3GPP will be studying how to support multimedia alerts in the future, as recommended by the FCC CMSAAC. This is all beyond the scope of this work effort.<BR>
&nbsp;<BR>
Regards,<BR>
Brian<BR>
&nbsp;<BR>
</SPAN></FONT><FONT SIZE="2"><FONT FACE="Consolas, Courier New, Courier"><SPAN STYLE='font-size:10pt'>Date: Thu, 25 Mar 2010 03:13:24 +0100<BR>
From: &quot;DRAGE, Keith (Keith)&quot; &lt;<a href="[email-masked]">[email-masked]</a>&gt;<BR>
Subject: Re: [earlywarning] Updated Charter Text for ATOCA<BR>
To: Hannes Tschofenig &lt;<a href="[email-masked]">[email-masked]</a>&gt;,<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&quot;<a href="[email-masked]">[email-masked]</a>&quot; &lt;<a href="[email-masked]">[email-masked]</a>&gt;<BR>
Message-ID:<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;<a href="[email-masked]">[email-masked]</a>&gt;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
Content-Type: text/plain; charset=&quot;us-ascii&quot;<BR>
&nbsp;<BR>
What I am not seeing here is any separation of the problem from the one that cell broadcast attempts to solve. Fundamentally, cell broadcast, as exists on all GSM, UTRAN and E-UTRAN based cell phones and is being used for Tsunami warning and Public Warning, exists and is not going to substantially change. The major limitation here is is length of message, and what does get transmitted will be very much dependent on that restriction.<BR>
&nbsp;<BR>
Moreover I have heard from a number of governmental bodies that they are happy with that situation and are not envisaging further standardisation in that area outside of 3GPP.<BR>
&nbsp;<BR>
So my view at the moment is that there is no point in IETF trying to address the scope of what is already specified in cell broadcast (from base station to end mobile).<BR>
&nbsp;<BR>
regards<BR>
&nbsp;<BR>
Keith<BR>
</SPAN></FONT></FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'> <BR>
&nbsp;<BR>
<BR>
<HR ALIGN=CENTER SIZE="3" WIDTH="95%"></SPAN></FONT><FONT SIZE="2"><FONT FACE="Consolas, Courier New, Courier"><SPAN STYLE='font-size:10pt'>_______________________________________________<BR>
earlywarning mailing list<BR>
<a href="[email-masked]">[email-masked]</a><BR>
<a href="https://www.ietf.org/mailman/listinfo/earlywarning">https://www.ietf.org/mailman/listinfo/earlywarning</a><BR>
</SPAN></FONT></FONT></BLOCKQUOTE>
</BODY>
</HTML>

--B_3352391429_9885686--

Content-class: urn:content-classes:message
Date: Thu, 25 Mar 2010 16:46:58 -0700
From: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
To: <[email-masked]>
Subject: [earlywarning] (no subject)

This is a multi-part message in MIME format.

------_=_NextPart_001_01CACC75.77260576
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Keith - We agree with you, and to further the point, in wireless
cellular IP networks a point to point solution would be problematic.
Cell Broadcast is used for CMAS because SMS cannot be used for any real
time alerting - it was not designed for that application and has serious
limitations, as the FCC CMSAAC studied.

When it comes to the evolved packet core and IMS, again a point to point
solution  will cause significant congestion on the network and a
broadcast/multicast solution must be used to effectively deliver alert
messages. Thus things like location and "priority" are already handled
in the delivery network.

ATIS and 3GPP will be studying how to support multimedia alerts in the
future, as recommended by the FCC CMSAAC. This is all beyond the scope
of this work effort.

Regards,

Brian

Date: Thu, 25 Mar 2010 03:13:24 +0100

From: "DRAGE, Keith (Keith)" <[email-masked]>

Subject: Re: [earlywarning] Updated Charter Text for ATOCA

To: Hannes Tschofenig <[email-masked]>,

      "[email-masked]" <[email-masked]>

Message-ID:

<[email-masked]
cent.com>

Content-Type: text/plain; charset="us-ascii"

What I am not seeing here is any separation of the problem from the one
that cell broadcast attempts to solve. Fundamentally, cell broadcast, as
exists on all GSM, UTRAN and E-UTRAN based cell phones and is being used
for Tsunami warning and Public Warning, exists and is not going to
substantially change. The major limitation here is is length of message,
and what does get transmitted will be very much dependent on that
restriction.

Moreover I have heard from a number of governmental bodies that they are
happy with that situation and are not envisaging further standardisation
in that area outside of 3GPP.

So my view at the moment is that there is no point in IETF trying to
address the scope of what is already specified in cell broadcast (from
base station to end mobile).

regards

Keith

 

------_=_NextPart_001_01CACC75.77260576
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.5pt;
	font-family:Consolas;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:Consolas;}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal>Keith &#8211; We agree with you, and to further the point,
in wireless cellular IP networks a point to point solution would be problematic.
Cell Broadcast is used for CMAS because SMS cannot be used for any real time
alerting &#8211; it was not designed for that application and has serious
limitations, as the FCC CMSAAC studied.<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>When it comes to the evolved packet core and IMS, again a
point to point solution &nbsp;will cause significant congestion on the network
and a broadcast/multicast solution must be used to effectively deliver alert
messages. Thus things like location and &#8220;priority&#8221; are already
handled in the delivery network.<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>ATIS and 3GPP will be studying how to support multimedia
alerts in the future, as recommended by the FCC CMSAAC. This is all beyond the
scope of this work effort.<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>Regards,<o:p></o:p></p>

<p class=MsoNormal>Brian<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoPlainText>Date: Thu, 25 Mar 2010 03:13:24 +0100<o:p></o:p></p>

<p class=MsoPlainText>From: &quot;DRAGE, Keith (Keith)&quot;
&lt;[email-masked]&gt;<o:p></o:p></p>

<p class=MsoPlainText>Subject: Re: [earlywarning] Updated Charter Text for ATOCA<o:p></o:p></p>

<p class=MsoPlainText>To: Hannes Tschofenig &lt;[email-masked]&gt;,<o:p></o:p></p>

<p class=MsoPlainText>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;[email-masked]&quot; &lt;[email-masked]&gt;<o:p></o:p></p>

<p class=MsoPlainText>Message-ID:<o:p></o:p></p>

<p class=MsoPlainText>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;[email-masked]&gt;<o:p></o:p></p>

<p class=MsoPlainText>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <o:p></o:p></p>

<p class=MsoPlainText>Content-Type: text/plain; charset=&quot;us-ascii&quot;<o:p></o:p></p>

<p class=MsoPlainText><o:p>&nbsp;</o:p></p>

<p class=MsoPlainText>What I am not seeing here is any separation of the
problem from the one that cell broadcast attempts to solve. Fundamentally, cell
broadcast, as exists on all GSM, UTRAN and E-UTRAN based cell phones and is
being used for Tsunami warning and Public Warning, exists and is not going to
substantially change. The major limitation here is is length of message, and
what does get transmitted will be very much dependent on that restriction.<o:p></o:p></p>

<p class=MsoPlainText><o:p>&nbsp;</o:p></p>

<p class=MsoPlainText>Moreover I have heard from a number of governmental
bodies that they are happy with that situation and are not envisaging further
standardisation in that area outside of 3GPP.<o:p></o:p></p>

<p class=MsoPlainText><o:p>&nbsp;</o:p></p>

<p class=MsoPlainText>So my view at the moment is that there is no point in
IETF trying to address the scope of what is already specified in cell broadcast
(from base station to end mobile).<o:p></o:p></p>

<p class=MsoPlainText><o:p>&nbsp;</o:p></p>

<p class=MsoPlainText>regards<o:p></o:p></p>

<p class=MsoPlainText><o:p>&nbsp;</o:p></p>

<p class=MsoPlainText>Keith<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

</div>

</body>

</html>

------_=_NextPart_001_01CACC75.77260576--

Date: Thu, 25 Mar 2010 18:27:31 -0500
To: Richard Barnes <[email-masked]>, Henning Schulzrinne <[email-masked]>
From: "James M. Polk" <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] New Charter Text for ATOCA

At 05:56 PM 3/25/2010, Richard Barnes wrote:
>I like option (1), although I would contribute to Military Bossing
>Around Protocol (MBAP) if someone wants to write it.

hehe

the text below is acceptable with the following nit fix suggestions

>Proposed text:
>"
>In situations of a major emergency

"," (comma)

>there could

s/could/can

>be scenarios where
>there are multiple alerts generated that may require a priority
>mechanism.  Since solutions developed by this working group will re- used

s/re- used/re-used

>  existing IETF messaging standards, the priority mechanisms for
>those protocols can be applied (e.g., the SIP resource priority header
>in RFC 4412).  If the initial work of this group encounters priority
>requirements specific to emergency alerting, then they may be
>addressed in a revision to this charter.
>"

James

>On Mar 25, 2010, at 3:47 PM, Henning Schulzrinne wrote:
>
>>There are three possibilities:
>>
>>- We anticipate that existing priority mechanisms are trivially
>>applicable and that the details of which one to use is likely to
>>depend on the local jurisdiction or lower-layer technology. I have
>>no objection to mentioning that, minus the "trivial" part.
>>
>>- We need to write a draft describing this. This seems unnecessary;
>>we don't write drafts for every single application. ("Here is the
>>draft how generals use RPH to boss around their sergeants.") If it
>>were, we'd need a milestone.
>>
>>- We need one or more new mechanisms that are specific to the
>>alerting application. This also doesn't seem to be the case.
>>
>>Henning
>>
>>On Mar 25, 2010, at 6:40 PM, James M. Polk wrote:
>>
>>>I'm not pushing the acceleration of this definition - merely
>>>pointing out the probability that many will observe this work, and
>>>this charter, and see at least one hole that wasn't mentioned that
>>>probably (in their minds) should have been. Some might conclude
>>>that deeming "priority as out of scope" to be shortsighted.
>>>Mentioning 4412 will let charter readers know this group believes
>>>it knows how to define priority, and has a specific solution in
>>>mind (at least for SIP) - yet knows that other work has to precede
>>>this definition. Comments may come in saying its delay should be
>>>shortened or lengthened. For example, Chile's government is
>>>changing their laws within 3 weeks to deal with exactly what this
>>>group is about - based on the events of their earthquake; as I've
>>>been personally contacted on 2 fronts to help them. Anyone want to
>>>predict that priority won't come up in those discussions?
>>>
>>>James
>>>
>>>At 03:40 PM 3/25/2010, Henning Schulzrinne wrote:
>>>>Also, this seems rather orthogonal. Nothing prevents use of any
>>>>resource priority mechanism or namespace with alerts. It would
>>>>only matter if we need to define fundamentally new RPH mechanisms.
>>>>We don't need to specify which routing protocol, SIP extensions or
>>>>IP options we are using, either.
>>>>
>>>>Henning
>>>>
>>>>On Mar 25, 2010, at 4:31 PM, Hannes Tschofenig wrote:
>>>>
>>>>>Hi James,
>>>>>
>>>>>I thought about including wording regarding the resource priority
>>>>>header defined for SIP in the charter text but then was wondering
>>>>>whether I am going a bit too far given that I say it is out-of- 
>>>>>scope at the moment.
>>>>>
>>>>>So, do you push strongly for putting RPH into the charter?
>>>>>
>>>>>Ciao
>>>>>Hannes
>>>>>
>>>>>James M. Polk wrote:
>>>>>>At 12:22 PM 3/25/2010, Hannes Tschofenig wrote:
>>>>>>
>>>>>>>>In
>>>>>>>>situations of a major emergency there could be scenarios where
>>>>>>>>there are
>>>>>>>>multiple alerts generated that may require that a priority
>>>>>>>>mechanism has
>>>>>>>>to be implemented, and this mechanism is out of scope at his
>>>>>>>>time.
>>>>>>>
>>>>>>>I got feedback that this is a bit strong.
>>>>>>>
>>>>>>> From the discussions in the room I understood that this was a
>>>>>>>pure scoping question. The initial scope is to work out the
>>>>>>>basic mechanisms. Later, priority handling would be
>>>>>>>investigated (but requires a WG rechartering).
>>>>>>>
>>>>>>>To those attending the meeting: Is this a fair summary of the
>>>>>>>discussion we had?
>>>>>>>
>>>>>>>My suggestion is to re-word the statement a bit:
>>>>>>>
>>>>>>>"In situations of a major emergency there could be scenarios
>>>>>>>where there are
>>>>>>>multiple alerts generated that may require that a priority
>>>>>>>mechanism has
>>>>>>>to be used. The work on a resource priority mechanism is out of
>>>>>>>scope of the initial charter."
>>>>>>
>>>>>>I don't like this. This wording is better than what was
>>>>>>previously there, but doesn't make it clear enough what will be
>>>>>>done when it needs to be done. It should state explicitly that
>>>>>>an RFC 4412 Resource-Priority namespace is how "priority" will
>>>>>>be addressed by this WG, but that will be defined in a
>>>>>>subsequent recharter in the future.
>>>>>>
>>>>>>I agree an RP namespace shouldn't be defined quickly, but I'm
>>>>>>also aware of how long ECRIT has had a doc defining it's RP
>>>>>>namespace and still doens't have a milestone to get a WGLC on
>>>>>>the done doc.
>>>>>>
>>>>>>This topic is something that will be looked at by many
>>>>>>organizations, SDOs and governments. The idea that we don't have
>>>>>>a priority mechanism in mind is something those other
>>>>>>organizations will quickly question. Stating in the charter that
>>>>>>we know about the topic, and actually know how to address the
>>>>>>topic (with the reference), but are acknowledging that this
>>>>>>isn't an initial priority of the WG should be fine.
>>>>>>
>>>>>>At the end of the day, we all know that defining an RP namespace
>>>>>>will be a 5-8 page ID that should take less than 2 days to
>>>>>>write, so it's not like this WG (once it becomes a WG) will have
>>>>>>massive choices of alternatives to analyze, thus necessitating
>>>>>>long WG deliberations and implementation experience in testbed
>>>>>>trials.
>>>>>>
>>>>>>If CAP is to be carried in SIP, then the one existing SIP
>>>>>>resource priority mechanism will be used - unless it is proven
>>>>>>not to work (then a lot of other WGs will have to more work on
>>>>>>their hands too).
>>>>>>
>>>>>>James
>>>>>>
>>>>>>
>>>>>>>Is this better?
>>>>>>>
>>>>>>>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
>>>
>>
>>_______________________________________________
>>earlywarning mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/earlywarning

From: Richard Barnes <[email-masked]>
To: Henning Schulzrinne <[email-masked]>
Date: Thu, 25 Mar 2010 15:56:04 -0700
Cc: [email-masked]
Subject: Re: [earlywarning] New Charter Text for ATOCA

I like option (1), although I would contribute to Military Bossing  
Around Protocol (MBAP) if someone wants to write it.  Proposed text:
"
In situations of a major emergency there could be scenarios where  
there are multiple alerts generated that may require a priority  
mechanism.  Since solutions developed by this working group will re- 
used existing IETF messaging standards, the priority mechanisms for  
those protocols can be applied (e.g., the SIP resource priority header  
in RFC 4412).  If the initial work of this group encounters priority  
requirements specific to emergency alerting, then they may be  
addressed in a revision to this charter.
"

On Mar 25, 2010, at 3:47 PM, Henning Schulzrinne wrote:

> There are three possibilities:
>
> - We anticipate that existing priority mechanisms are trivially  
> applicable and that the details of which one to use is likely to  
> depend on the local jurisdiction or lower-layer technology. I have  
> no objection to mentioning that, minus the "trivial" part.
>
> - We need to write a draft describing this. This seems unnecessary;  
> we don't write drafts for every single application. ("Here is the  
> draft how generals use RPH to boss around their sergeants.") If it  
> were, we'd need a milestone.
>
> - We need one or more new mechanisms that are specific to the  
> alerting application. This also doesn't seem to be the case.
>
> Henning
>
> On Mar 25, 2010, at 6:40 PM, James M. Polk wrote:
>
>> I'm not pushing the acceleration of this definition - merely  
>> pointing out the probability that many will observe this work, and  
>> this charter, and see at least one hole that wasn't mentioned that  
>> probably (in their minds) should have been. Some might conclude  
>> that deeming "priority as out of scope" to be shortsighted.   
>> Mentioning 4412 will let charter readers know this group believes  
>> it knows how to define priority, and has a specific solution in  
>> mind (at least for SIP) - yet knows that other work has to precede  
>> this definition. Comments may come in saying its delay should be  
>> shortened or lengthened. For example, Chile's government is  
>> changing their laws within 3 weeks to deal with exactly what this  
>> group is about - based on the events of their earthquake; as I've  
>> been personally contacted on 2 fronts to help them. Anyone want to  
>> predict that priority won't come up in those discussions?
>>
>> James
>>
>> At 03:40 PM 3/25/2010, Henning Schulzrinne wrote:
>>> Also, this seems rather orthogonal. Nothing prevents use of any  
>>> resource priority mechanism or namespace with alerts. It would  
>>> only matter if we need to define fundamentally new RPH mechanisms.  
>>> We don't need to specify which routing protocol, SIP extensions or  
>>> IP options we are using, either.
>>>
>>> Henning
>>>
>>> On Mar 25, 2010, at 4:31 PM, Hannes Tschofenig wrote:
>>>
>>>> Hi James,
>>>>
>>>> I thought about including wording regarding the resource priority  
>>>> header defined for SIP in the charter text but then was wondering  
>>>> whether I am going a bit too far given that I say it is out-of- 
>>>> scope at the moment.
>>>>
>>>> So, do you push strongly for putting RPH into the charter?
>>>>
>>>> Ciao
>>>> Hannes
>>>>
>>>> James M. Polk wrote:
>>>>> At 12:22 PM 3/25/2010, Hannes Tschofenig wrote:
>>>>>
>>>>>>> In
>>>>>>> situations of a major emergency there could be scenarios where  
>>>>>>> there are
>>>>>>> multiple alerts generated that may require that a priority  
>>>>>>> mechanism has
>>>>>>> to be implemented, and this mechanism is out of scope at his  
>>>>>>> time.
>>>>>>>
>>>>>>
>>>>>> I got feedback that this is a bit strong.
>>>>>>
>>>>>> From the discussions in the room I understood that this was a  
>>>>>> pure scoping question. The initial scope is to work out the  
>>>>>> basic mechanisms. Later, priority handling would be  
>>>>>> investigated (but requires a WG rechartering).
>>>>>>
>>>>>> To those attending the meeting: Is this a fair summary of the  
>>>>>> discussion we had?
>>>>>>
>>>>>> My suggestion is to re-word the statement a bit:
>>>>>>
>>>>>> "In situations of a major emergency there could be scenarios  
>>>>>> where there are
>>>>>> multiple alerts generated that may require that a priority  
>>>>>> mechanism has
>>>>>> to be used. The work on a resource priority mechanism is out of  
>>>>>> scope of the initial charter."
>>>>>
>>>>> I don't like this. This wording is better than what was  
>>>>> previously there, but doesn't make it clear enough what will be  
>>>>> done when it needs to be done. It should state explicitly that  
>>>>> an RFC 4412 Resource-Priority namespace is how "priority" will  
>>>>> be addressed by this WG, but that will be defined in a  
>>>>> subsequent recharter in the future.
>>>>>
>>>>> I agree an RP namespace shouldn't be defined quickly, but I'm  
>>>>> also aware of how long ECRIT has had a doc defining it's RP  
>>>>> namespace and still doens't have a milestone to get a WGLC on  
>>>>> the done doc.
>>>>>
>>>>> This topic is something that will be looked at by many  
>>>>> organizations, SDOs and governments. The idea that we don't have  
>>>>> a priority mechanism in mind is something those other  
>>>>> organizations will quickly question. Stating in the charter that  
>>>>> we know about the topic, and actually know how to address the  
>>>>> topic (with the reference), but are acknowledging that this  
>>>>> isn't an initial priority of the WG should be fine.
>>>>>
>>>>> At the end of the day, we all know that defining an RP namespace  
>>>>> will be a 5-8 page ID that should take less than 2 days to  
>>>>> write, so it's not like this WG (once it becomes a WG) will have  
>>>>> massive choices of alternatives to analyze, thus necessitating  
>>>>> long WG deliberations and implementation experience in testbed  
>>>>> trials.
>>>>>
>>>>> If CAP is to be carried in SIP, then the one existing SIP  
>>>>> resource priority mechanism will be used - unless it is proven  
>>>>> not to work (then a lot of other WGs will have to more work on  
>>>>> their hands too).
>>>>>
>>>>> James
>>>>>
>>>>>
>>>>>> Is this better?
>>>>>>
>>>>>> 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
>>>>
>>
>>
>
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 25 Mar 2010 18:47:20 -0400
To: "James M. Polk" <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] New Charter Text for ATOCA

There are three possibilities:

- We anticipate that existing priority mechanisms are trivially applicable and that the details of which one to use is likely to depend on the local jurisdiction or lower-layer technology. I have no objection to mentioning that, minus the "trivial" part.

- We need to write a draft describing this. This seems unnecessary; we don't write drafts for every single application. ("Here is the draft how generals use RPH to boss around their sergeants.") If it were, we'd need a milestone.

- We need one or more new mechanisms that are specific to the alerting application. This also doesn't seem to be the case.

Henning

On Mar 25, 2010, at 6:40 PM, James M. Polk wrote:

> I'm not pushing the acceleration of this definition - merely pointing out the probability that many will observe this work, and this charter, and see at least one hole that wasn't mentioned that probably (in their minds) should have been. Some might conclude that deeming "priority as out of scope" to be shortsighted.  Mentioning 4412 will let charter readers know this group believes it knows how to define priority, and has a specific solution in mind (at least for SIP) - yet knows that other work has to precede this definition. Comments may come in saying its delay should be shortened or lengthened. For example, Chile's government is changing their laws within 3 weeks to deal with exactly what this group is about - based on the events of their earthquake; as I've been personally contacted on 2 fronts to help them. Anyone want to predict that priority won't come up in those discussions?
> 
> James
> 
> At 03:40 PM 3/25/2010, Henning Schulzrinne wrote:
>> Also, this seems rather orthogonal. Nothing prevents use of any resource priority mechanism or namespace with alerts. It would only matter if we need to define fundamentally new RPH mechanisms. We don't need to specify which routing protocol, SIP extensions or IP options we are using, either.
>> 
>> Henning
>> 
>> On Mar 25, 2010, at 4:31 PM, Hannes Tschofenig wrote:
>> 
>> > Hi James,
>> >
>> > I thought about including wording regarding the resource priority header defined for SIP in the charter text but then was wondering whether I am going a bit too far given that I say it is out-of-scope at the moment.
>> >
>> > So, do you push strongly for putting RPH into the charter?
>> >
>> > Ciao
>> > Hannes
>> >
>> > James M. Polk wrote:
>> >> At 12:22 PM 3/25/2010, Hannes Tschofenig wrote:
>> >>
>> >>>> In
>> >>>> situations of a major emergency there could be scenarios where there are
>> >>>> multiple alerts generated that may require that a priority mechanism has
>> >>>> to be implemented, and this mechanism is out of scope at his time.
>> >>>>
>> >>>
>> >>> I got feedback that this is a bit strong.
>> >>>
>> >>> From the discussions in the room I understood that this was a pure scoping question. The initial scope is to work out the basic mechanisms. Later, priority handling would be investigated (but requires a WG rechartering).
>> >>>
>> >>> To those attending the meeting: Is this a fair summary of the discussion we had?
>> >>>
>> >>> My suggestion is to re-word the statement a bit:
>> >>>
>> >>> "In situations of a major emergency there could be scenarios where there are
>> >>> multiple alerts generated that may require that a priority mechanism has
>> >>> to be used. The work on a resource priority mechanism is out of scope of the initial charter."
>> >>
>> >> I don't like this. This wording is better than what was previously there, but doesn't make it clear enough what will be done when it needs to be done. It should state explicitly that an RFC 4412 Resource-Priority namespace is how "priority" will be addressed by this WG, but that will be defined in a subsequent recharter in the future.
>> >>
>> >> I agree an RP namespace shouldn't be defined quickly, but I'm also aware of how long ECRIT has had a doc defining it's RP namespace and still doens't have a milestone to get a WGLC on the done doc.
>> >>
>> >> This topic is something that will be looked at by many organizations, SDOs and governments. The idea that we don't have a priority mechanism in mind is something those other organizations will quickly question. Stating in the charter that we know about the topic, and actually know how to address the topic (with the reference), but are acknowledging that this isn't an initial priority of the WG should be fine.
>> >>
>> >> At the end of the day, we all know that defining an RP namespace will be a 5-8 page ID that should take less than 2 days to write, so it's not like this WG (once it becomes a WG) will have massive choices of alternatives to analyze, thus necessitating long WG deliberations and implementation experience in testbed trials.
>> >>
>> >> If CAP is to be carried in SIP, then the one existing SIP resource priority mechanism will be used - unless it is proven not to work (then a lot of other WGs will have to more work on their hands too).
>> >>
>> >> James
>> >>
>> >>
>> >>> Is this better?
>> >>>
>> >>> 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: Thu, 25 Mar 2010 17:40:48 -0500
To: Henning Schulzrinne <[email-masked]>, Hannes Tschofenig <[email-masked]>
From: "James M. Polk" <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] New Charter Text for ATOCA

I'm not pushing the acceleration of this definition - merely pointing 
out the probability that many will observe this work, and this 
charter, and see at least one hole that wasn't mentioned that 
probably (in their minds) should have been. Some might conclude that 
deeming "priority as out of scope" to be shortsighted.  Mentioning 
4412 will let charter readers know this group believes it knows how 
to define priority, and has a specific solution in mind (at least for 
SIP) - yet knows that other work has to precede this definition. 
Comments may come in saying its delay should be shortened or 
lengthened. For example, Chile's government is changing their laws 
within 3 weeks to deal with exactly what this group is about - based 
on the events of their earthquake; as I've been personally contacted 
on 2 fronts to help them. Anyone want to predict that priority won't 
come up in those discussions?

James

At 03:40 PM 3/25/2010, Henning Schulzrinne wrote:
>Also, this seems rather orthogonal. Nothing prevents use of any 
>resource priority mechanism or namespace with alerts. It would only 
>matter if we need to define fundamentally new RPH mechanisms. We 
>don't need to specify which routing protocol, SIP extensions or IP 
>options we are using, either.
>
>Henning
>
>On Mar 25, 2010, at 4:31 PM, Hannes Tschofenig wrote:
>
> > Hi James,
> >
> > I thought about including wording regarding the resource priority 
> header defined for SIP in the charter text but then was wondering 
> whether I am going a bit too far given that I say it is 
> out-of-scope at the moment.
> >
> > So, do you push strongly for putting RPH into the charter?
> >
> > Ciao
> > Hannes
> >
> > James M. Polk wrote:
> >> At 12:22 PM 3/25/2010, Hannes Tschofenig wrote:
> >>
> >>>> In
> >>>> situations of a major emergency there could be scenarios where there are
> >>>> multiple alerts generated that may require that a priority mechanism has
> >>>> to be implemented, and this mechanism is out of scope at his time.
> >>>>
> >>>
> >>> I got feedback that this is a bit strong.
> >>>
> >>> From the discussions in the room I understood that this was a 
> pure scoping question. The initial scope is to work out the basic 
> mechanisms. Later, priority handling would be investigated (but 
> requires a WG rechartering).
> >>>
> >>> To those attending the meeting: Is this a fair summary of the 
> discussion we had?
> >>>
> >>> My suggestion is to re-word the statement a bit:
> >>>
> >>> "In situations of a major emergency there could be scenarios 
> where there are
> >>> multiple alerts generated that may require that a priority mechanism has
> >>> to be used. The work on a resource priority mechanism is out of 
> scope of the initial charter."
> >>
> >> I don't like this. This wording is better than what was 
> previously there, but doesn't make it clear enough what will be 
> done when it needs to be done. It should state explicitly that an 
> RFC 4412 Resource-Priority namespace is how "priority" will be 
> addressed by this WG, but that will be defined in a subsequent 
> recharter in the future.
> >>
> >> I agree an RP namespace shouldn't be defined quickly, but I'm 
> also aware of how long ECRIT has had a doc defining it's RP 
> namespace and still doens't have a milestone to get a WGLC on the done doc.
> >>
> >> This topic is something that will be looked at by many 
> organizations, SDOs and governments. The idea that we don't have a 
> priority mechanism in mind is something those other organizations 
> will quickly question. Stating in the charter that we know about 
> the topic, and actually know how to address the topic (with the 
> reference), but are acknowledging that this isn't an initial 
> priority of the WG should be fine.
> >>
> >> At the end of the day, we all know that defining an RP namespace 
> will be a 5-8 page ID that should take less than 2 days to write, 
> so it's not like this WG (once it becomes a WG) will have massive 
> choices of alternatives to analyze, thus necessitating long WG 
> deliberations and implementation experience in testbed trials.
> >>
> >> If CAP is to be carried in SIP, then the one existing SIP 
> resource priority mechanism will be used - unless it is proven not 
> to work (then a lot of other WGs will have to more work on their hands too).
> >>
> >> James
> >>
> >>
> >>> Is this better?
> >>>
> >>> 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
> >

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 25 Mar 2010 16:40:51 -0400
To: Hannes Tschofenig <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] New Charter Text for ATOCA

Also, this seems rather orthogonal. Nothing prevents use of any resource priority mechanism or namespace with alerts. It would only matter if we need to define fundamentally new RPH mechanisms. We don't need to specify which routing protocol, SIP extensions or IP options we are using, either.

Henning

On Mar 25, 2010, at 4:31 PM, Hannes Tschofenig wrote:

> Hi James,
> 
> I thought about including wording regarding the resource priority header defined for SIP in the charter text but then was wondering whether I am going a bit too far given that I say it is out-of-scope at the moment.
> 
> So, do you push strongly for putting RPH into the charter?
> 
> Ciao
> Hannes
> 
> James M. Polk wrote:
>> At 12:22 PM 3/25/2010, Hannes Tschofenig wrote:
>> 
>>>> In
>>>> situations of a major emergency there could be scenarios where there are
>>>> multiple alerts generated that may require that a priority mechanism has
>>>> to be implemented, and this mechanism is out of scope at his time.
>>>> 
>>> 
>>> I got feedback that this is a bit strong.
>>> 
>>> From the discussions in the room I understood that this was a pure scoping question. The initial scope is to work out the basic mechanisms. Later, priority handling would be investigated (but requires a WG rechartering).
>>> 
>>> To those attending the meeting: Is this a fair summary of the discussion we had?
>>> 
>>> My suggestion is to re-word the statement a bit:
>>> 
>>> "In situations of a major emergency there could be scenarios where there are
>>> multiple alerts generated that may require that a priority mechanism has
>>> to be used. The work on a resource priority mechanism is out of scope of the initial charter."
>> 
>> I don't like this. This wording is better than what was previously there, but doesn't make it clear enough what will be done when it needs to be done. It should state explicitly that an RFC 4412 Resource-Priority namespace is how "priority" will be addressed by this WG, but that will be defined in a subsequent recharter in the future.
>> 
>> I agree an RP namespace shouldn't be defined quickly, but I'm also aware of how long ECRIT has had a doc defining it's RP namespace and still doens't have a milestone to get a WGLC on the done doc.
>> 
>> This topic is something that will be looked at by many organizations, SDOs and governments. The idea that we don't have a priority mechanism in mind is something those other organizations will quickly question. Stating in the charter that we know about the topic, and actually know how to address the topic (with the reference), but are acknowledging that this isn't an initial priority of the WG should be fine.
>> 
>> At the end of the day, we all know that defining an RP namespace will be a 5-8 page ID that should take less than 2 days to write, so it's not like this WG (once it becomes a WG) will have massive choices of alternatives to analyze, thus necessitating long WG deliberations and implementation experience in testbed trials.
>> 
>> If CAP is to be carried in SIP, then the one existing SIP resource priority mechanism will be used - unless it is proven not to work (then a lot of other WGs will have to more work on their hands too).
>> 
>> James
>> 
>> 
>>> Is this better?
>>> 
>>> 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: Thu, 25 Mar 2010 16:31:15 -0400
From: Hannes Tschofenig <[email-masked]>
To: "James M. Polk" <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] New Charter Text for ATOCA

Hi James,

I thought about including wording regarding the resource priority header 
defined for SIP in the charter text but then was wondering whether I am 
going a bit too far given that I say it is out-of-scope at the moment.

So, do you push strongly for putting RPH into the charter?

Ciao
Hannes

James M. Polk wrote:
> At 12:22 PM 3/25/2010, Hannes Tschofenig wrote:
>
>>> In
>>> situations of a major emergency there could be scenarios where there 
>>> are
>>> multiple alerts generated that may require that a priority mechanism 
>>> has
>>> to be implemented, and this mechanism is out of scope at his time.
>>>
>>
>> I got feedback that this is a bit strong.
>>
>> From the discussions in the room I understood that this was a pure 
>> scoping question. The initial scope is to work out the basic 
>> mechanisms. Later, priority handling would be investigated (but 
>> requires a WG rechartering).
>>
>> To those attending the meeting: Is this a fair summary of the 
>> discussion we had?
>>
>> My suggestion is to re-word the statement a bit:
>>
>> "In situations of a major emergency there could be scenarios where 
>> there are
>> multiple alerts generated that may require that a priority mechanism has
>> to be used. The work on a resource priority mechanism is out of scope 
>> of the initial charter."
>
> I don't like this. This wording is better than what was previously 
> there, but doesn't make it clear enough what will be done when it 
> needs to be done. It should state explicitly that an RFC 4412 
> Resource-Priority namespace is how "priority" will be addressed by 
> this WG, but that will be defined in a subsequent recharter in the 
> future.
>
> I agree an RP namespace shouldn't be defined quickly, but I'm also 
> aware of how long ECRIT has had a doc defining it's RP namespace and 
> still doens't have a milestone to get a WGLC on the done doc.
>
> This topic is something that will be looked at by many organizations, 
> SDOs and governments. The idea that we don't have a priority mechanism 
> in mind is something those other organizations will quickly question. 
> Stating in the charter that we know about the topic, and actually know 
> how to address the topic (with the reference), but are acknowledging 
> that this isn't an initial priority of the WG should be fine.
>
> At the end of the day, we all know that defining an RP namespace will 
> be a 5-8 page ID that should take less than 2 days to write, so it's 
> not like this WG (once it becomes a WG) will have massive choices of 
> alternatives to analyze, thus necessitating long WG deliberations and 
> implementation experience in testbed trials.
>
> If CAP is to be carried in SIP, then the one existing SIP resource 
> priority mechanism will be used - unless it is proven not to work 
> (then a lot of other WGs will have to more work on their hands too).
>
> James
>
>
>> Is this better?
>>
>> Ciao
>> Hannes
>> _______________________________________________
>> earlywarning mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/earlywarning

Date: Thu, 25 Mar 2010 15:27:26 -0500
To: Hannes Tschofenig <[email-masked]>, [email-masked]
From: "James M. Polk" <[email-masked]>
Subject: Re: [earlywarning] New Charter Text for ATOCA

At 12:22 PM 3/25/2010, Hannes Tschofenig wrote:

>>In
>>situations of a major emergency there could be scenarios where there are
>>multiple alerts generated that may require that a priority mechanism has
>>to be implemented, and this mechanism is out of scope at his time.
>>
>
>I got feedback that this is a bit strong.
>
> From the discussions in the room I understood that this was a pure 
> scoping question. The initial scope is to work out the basic 
> mechanisms. Later, priority handling would be investigated (but 
> requires a WG rechartering).
>
>To those attending the meeting: Is this a fair summary of the 
>discussion we had?
>
>My suggestion is to re-word the statement a bit:
>
>"In situations of a major emergency there could be scenarios where there are
>multiple alerts generated that may require that a priority mechanism has
>to be used. The work on a resource priority mechanism is out of 
>scope of the initial charter."

I don't like this. This wording is better than what was previously 
there, but doesn't make it clear enough what will be done when it 
needs to be done. It should state explicitly that an RFC 4412 
Resource-Priority namespace is how "priority" will be addressed by 
this WG, but that will be defined in a subsequent recharter in the future.

I agree an RP namespace shouldn't be defined quickly, but I'm also 
aware of how long ECRIT has had a doc defining it's RP namespace and 
still doens't have a milestone to get a WGLC on the done doc.

This topic is something that will be looked at by many organizations, 
SDOs and governments. The idea that we don't have a priority 
mechanism in mind is something those other organizations will quickly 
question. Stating in the charter that we know about the topic, and 
actually know how to address the topic (with the reference), but are 
acknowledging that this isn't an initial priority of the WG should be fine.

At the end of the day, we all know that defining an RP namespace will 
be a 5-8 page ID that should take less than 2 days to write, so it's 
not like this WG (once it becomes a WG) will have massive choices of 
alternatives to analyze, thus necessitating long WG deliberations and 
implementation experience in testbed trials.

If CAP is to be carried in SIP, then the one existing SIP resource 
priority mechanism will be used - unless it is proven not to work 
(then a lot of other WGs will have to more work on their hands too).

James

>Is this better?
>
>Ciao
>Hannes
>_______________________________________________
>earlywarning mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/earlywarning

To: ken carlberg <[email-masked]>
From: Janet P Gunn <[email-masked]>
Date: Thu, 25 Mar 2010 14:28:45 -0400
Cc: [email-masked], Hannes Tschofenig <[email-masked]>, [email-masked]
Subject: Re: [earlywarning] New Charter Text for ATOCA

This is a multipart message in MIME format.
--=_alternative 006580A8852576F1_Content-Type: text/plain; charset="US-ASCII"

I support Ken's proposal.

Janet

[email-masked] wrote on 03/25/2010 01:49:43 PM:

> [image removed] 
> 
> Re: [earlywarning] New Charter Text for ATOCA
> 
> ken carlberg 
> 
> to:
> 
> Hannes Tschofenig
> 
> 03/25/2010 01:51 PM
> 
> Sent by:
> 
> [email-masked]
> 
> Cc:
> 
> earlywarning
> 
> 
> On Mar 25, 2010, at 1:22 PM, Hannes Tschofenig wrote:
> 
> > "In situations of a major emergency there could be scenarios 
wherethere are
> > multiple alerts generated that may require that a priority mechanism 
has
> > to be used. The work on a resource priority mechanism is out of 
> scope of the initial charter."
> 
> personally, I would recommend 
> s/of the initial charter/of the initial charter, but may be 
> revisited at a later date"
> 
> overall, I feel comfortable with the above and pushing aside the 
> subject of prioritization in this first go around -- if for nothing 
> else, to keep the proposed effort as simple and focused as possible.
> But I'd like to convey that we'd keep this topic open for future 
> discussion if the need arises.  reason being that some countries 
> (ie, authorities) outside of the US do support/prefer to prioritize 
> communications when a contention exists.
> 
> cheers,
> 
> -ken
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

--=_alternative 006580A8852576F1_Content-Type: text/html; charset="US-ASCII"

<br><font size=2 face="sans-serif"><br>
I support Ken's proposal.</font>
<br>
<br><font size=2 face="sans-serif">Janet</font>
<br>
<br><tt><font size=2>[email-masked] wrote on 03/25/2010
01:49:43 PM:<br>
<br>
&gt; [image removed] </font></tt>
<br><tt><font size=2>&gt; <br>
&gt; Re: [earlywarning] New Charter Text for ATOCA</font></tt>
<br><tt><font size=2>&gt; <br>
&gt; ken carlberg </font></tt>
<br><tt><font size=2>&gt; <br>
&gt; to:</font></tt>
<br><tt><font size=2>&gt; <br>
&gt; Hannes Tschofenig</font></tt>
<br><tt><font size=2>&gt; <br>
&gt; 03/25/2010 01:51 PM</font></tt>
<br><tt><font size=2>&gt; <br>
&gt; Sent by:</font></tt>
<br><tt><font size=2>&gt; <br>
&gt; [email-masked]</font></tt>
<br><tt><font size=2>&gt; <br>
&gt; Cc:</font></tt>
<br><tt><font size=2>&gt; <br>
&gt; earlywarning</font></tt>
<br><tt><font size=2>&gt; <br>
&gt; <br>
&gt; On Mar 25, 2010, at 1:22 PM, Hannes Tschofenig wrote:<br>
&gt; <br>
&gt; &gt; &quot;In situations of a major emergency there could be scenarios
wherethere are<br>
&gt; &gt; multiple alerts generated that may require that a priority mechanism
has<br>
&gt; &gt; to be used. The work on a resource priority mechanism is out
of <br>
&gt; scope of the initial charter.&quot;<br>
&gt; <br>
&gt; personally, I would recommend <br>
&gt; s/of the initial charter/of the initial charter, but may be <br>
&gt; revisited at a later date&quot;<br>
&gt; <br>
&gt; overall, I feel comfortable with the above and pushing aside the <br>
&gt; subject of prioritization in this first go around -- if for nothing
<br>
&gt; else, to keep the proposed effort as simple and focused as possible.<br>
&gt; But I'd like to convey that we'd keep this topic open for future <br>
&gt; discussion if the need arises. &nbsp;reason being that some countries
<br>
&gt; (ie, authorities) outside of the US do support/prefer to prioritize
<br>
&gt; communications when a contention exists.<br>
&gt; <br>
&gt; cheers,<br>
&gt; <br>
&gt; -ken<br>
&gt; _______________________________________________<br>
&gt; earlywarning mailing list<br>
&gt; [email-masked]<br>
&gt; </font></tt><a href=https://www.ietf.org/mailman/listinfo/earlywarning><tt><font size=2>https://www.ietf.org/mailman/listinfo/earlywarning</font></tt></a><tt><font size=2><br>
</font></tt>
--=_alternative 006580A8852576F1_=--

From: ken carlberg <[email-masked]>
Date: Thu, 25 Mar 2010 13:49:43 -0400
To: Hannes Tschofenig <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] New Charter Text for ATOCA

On Mar 25, 2010, at 1:22 PM, Hannes Tschofenig wrote:

> "In situations of a major emergency there could be scenarios where there are
> multiple alerts generated that may require that a priority mechanism has
> to be used. The work on a resource priority mechanism is out of scope of the initial charter."

personally, I would recommend 
s/of the initial charter/of the initial charter, but may be revisited at a later date"

overall, I feel comfortable with the above and pushing aside the subject of prioritization in this first go around -- if for nothing else, to keep the proposed effort as simple and focused as possible.  But I'd like to convey that we'd keep this topic open for future discussion if the need arises.  reason being that some countries (ie, authorities) outside of the US do support/prefer to prioritize communications when a contention exists.

cheers,

-ken

Date: Thu, 25 Mar 2010 13:22:01 -0400
From: Hannes Tschofenig <[email-masked]>
To: [email-masked]
Subject: Re: [earlywarning] New Charter Text for ATOCA

>
> In
> situations of a major emergency there could be scenarios where there are
> multiple alerts generated that may require that a priority mechanism has
> to be implemented, and this mechanism is out of scope at his time.
>   

I got feedback that this is a bit strong.

 From the discussions in the room I understood that this was a pure 
scoping question. The initial scope is to work out the basic mechanisms. 
Later, priority handling would be investigated (but requires a WG 
rechartering).

To those attending the meeting: Is this a fair summary of the discussion 
we had?

My suggestion is to re-word the statement a bit:

"In situations of a major emergency there could be scenarios where there are
multiple alerts generated that may require that a priority mechanism has
to be used. The work on a resource priority mechanism is out of scope of the initial charter."

Is this better? 

Ciao
Hannes

Date: Thu, 25 Mar 2010 11:28:41 -0400 (EDT)
From: [email-masked]
To: "DRAGE, Keith (Keith)" <[email-masked]>
Importance: Normal
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [earlywarning] Updated Charter Text for ATOCA

Is this global best practice??

Carl

> What I am not seeing here is any separation of the problem from the one
> that cell broadcast attempts to solve. Fundamentally, cell broadcast, as
> exists on all GSM, UTRAN and E-UTRAN based cell phones and is being used
> for Tsunami warning and Public Warning, exists and is not going to
> substantially change. The major limitation here is is length of message,
> and what does get transmitted will be very much dependent on that
> restriction.
>
> Moreover I have heard from a number of governmental bodies that they are
> happy with that situation and are not envisaging further standardisation
> in that area outside of 3GPP.
>
> So my view at the moment is that there is no point in IETF trying to
> address the scope of what is already specified in cell broadcast (from
> base station to end mobile).
>
> regards
>
> Keith
>
>
>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
>> Sent: Wednesday, March 24, 2010 9:37 PM
>> To: [email-masked]
>> Subject: [earlywarning] Updated Charter Text for ATOCA
>>
>> .... a minor update
>>
>> Authority to Citizen Alert (ATOCA)
>> =================
>>
>> Authorities need mechanisms to notify citizens and visitors
>> of emergency
>> events.   Traditionally, they have done so with broadcast
>> networks (radio
>> and television).  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. The goal of this group is
>> not to specify how originators of alerts obtain
>> authorization, but rather how a messaging system can verify
>> authorization and deliver message to the intended recipients.
>> A critical element of the work arethe mechanisms that assure
>> that only authorized agents can send alerts.
>>
>> The recipients of these alerts are the wide range of devices
>> connected to the Internet and 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), but the initial
>> work in the group is focused on small messages, which may be
>> mechanically rendered by thedevice in other forms (text to
>> speech for example).  In situations of a major emergency
>> there could be scenarios where there are multiple alerts
>> generated that may require that a priority mechanism has to
>> be implemented, and this mechanism is out of scope at his time.
>>
>> 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 affected by the alert.  In many
>> jurisdictions, there are regulations that define whether
>> recipients within the affected area have opt-in or opt-out
>> capability, but the protocols we 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.
>>
>> Another class of recipients that are in scope of the work are
>> explicit opt-in subscriptions which ask for alerts for a
>> specified location.
>> An example of such a subscription would be 'send me alerts
>> for location x' (previously determined as the location of interest).
>> This work builds on existing IETF geopriv location work.
>>
>> There are other efforts in other fora on alerts, 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.  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.
>> Of course, existing protocols for delivering messages (e.g.,
>> SIP) will be the basis for the message delivery system of
>> this working group.
>>
>> 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.
>>
>> Milestones
>>
>> TBD      Initial document for "Terminology and Framework" document.
>>          A starting point for this work is
>>          draft-norreys-ecrit-authority2individuals-requirements.
>> TBD      Initial document for conveying alerts in SIP
>> TBD      Initial document for subscribing to alerts using SIP
>>          A starting point for this work is draft-rosen-sipping-cap
>> TBD      Initial document for locating the alerting server
>> for a geographic
>>          region. A starting point for this work is
>>          draft-rosen-ecrit-lost-early-warning.
>>
>> _______________________________________________
>> 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: "Spencer Dawkins" <[email-masked]>
To: "Hannes Tschofenig" <[email-masked]>, <[email-masked]>
Date: Thu, 25 Mar 2010 09:52:37 -0500
Subject: Re: [earlywarning] Updated Charter Text for ATOCA

>> Also if interactivity is required or offered as an extra service, RTT can 
>> be useful.
>>
> I have so far never heard that interactivity would be desired.

FWIW, my understanding is that this is not even possible (you just told the 
entire city of Yokohama that a tsunami is two hours out - who's supposed to 
handle the questions from the entire city of Yokohama?)

Spencer 

Date: Thu, 25 Mar 2010 10:38:35 -0400
From: Hannes Tschofenig <[email-masked]>
To: Richard Barnes <[email-masked]>
Cc: "DRAGE, Keith \(Keith\)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [earlywarning] Updated Charter Text for ATOCA

Another thing to add is that the properties of the envisioned mechanism 
are different. Example: I want to receive warnings of a indicated location.

Furthermore, we also said that the link layer aspects are outside the 
scope and will not be considered. We focused on communication with 
IP-based endpoints and there is no talk about cell broadcast, etc.

Ciao
Hannes

Richard Barnes wrote:
> So Keith, do you think that emergency notifications should not be 
> available on any other network?
>
> Even if you use cell broadcast, there's a need for a distribution 
> architecture, as the US CMAS demonstrates.
>
> --Richard
>
>
>
> On Mar 24, 2010, at 7:13 PM, DRAGE, Keith (Keith) wrote:
>
>> What I am not seeing here is any separation of the problem from the 
>> one that cell broadcast attempts to solve. Fundamentally, cell 
>> broadcast, as exists on all GSM, UTRAN and E-UTRAN based cell phones 
>> and is being used for Tsunami warning and Public Warning, exists and 
>> is not going to substantially change. The major limitation here is is 
>> length of message, and what does get transmitted will be very much 
>> dependent on that restriction.
>>
>> Moreover I have heard from a number of governmental bodies that they 
>> are happy with that situation and are not envisaging further 
>> standardisation in that area outside of 3GPP.
>>
>> So my view at the moment is that there is no point in IETF trying to 
>> address the scope of what is already specified in cell broadcast 
>> (from base station to end mobile).
>>
>> regards
>>
>> Keith
>>
>>
>>
>>> -----Original Message-----
>>> From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
>>> Sent: Wednesday, March 24, 2010 9:37 PM
>>> To: [email-masked]
>>> Subject: [earlywarning] Updated Charter Text for ATOCA
>>>
>>> .... a minor update
>>>
>>> Authority to Citizen Alert (ATOCA)
>>> =================
>>>
>>> Authorities need mechanisms to notify citizens and visitors
>>> of emergency
>>> events.   Traditionally, they have done so with broadcast
>>> networks (radio
>>> and television).  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. The goal of this group is
>>> not to specify how originators of alerts obtain
>>> authorization, but rather how a messaging system can verify
>>> authorization and deliver message to the intended recipients.
>>> A critical element of the work arethe mechanisms that assure
>>> that only authorized agents can send alerts.
>>>
>>> The recipients of these alerts are the wide range of devices
>>> connected to the Internet and 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), but the initial
>>> work in the group is focused on small messages, which may be
>>> mechanically rendered by thedevice in other forms (text to
>>> speech for example).  In situations of a major emergency
>>> there could be scenarios where there are multiple alerts
>>> generated that may require that a priority mechanism has to
>>> be implemented, and this mechanism is out of scope at his time.
>>>
>>> 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 affected by the alert.  In many
>>> jurisdictions, there are regulations that define whether
>>> recipients within the affected area have opt-in or opt-out
>>> capability, but the protocols we 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.
>>>
>>> Another class of recipients that are in scope of the work are
>>> explicit opt-in subscriptions which ask for alerts for a
>>> specified location.
>>> An example of such a subscription would be 'send me alerts
>>> for location x' (previously determined as the location of interest).
>>> This work builds on existing IETF geopriv location work.
>>>
>>> There are other efforts in other fora on alerts, 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.  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.
>>> Of course, existing protocols for delivering messages (e.g.,
>>> SIP) will be the basis for the message delivery system of
>>> this working group.
>>>
>>> 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.
>>>
>>> Milestones
>>>
>>> TBD      Initial document for "Terminology and Framework" document.
>>>         A starting point for this work is
>>>         draft-norreys-ecrit-authority2individuals-requirements.
>>> TBD      Initial document for conveying alerts in SIP
>>> TBD      Initial document for subscribing to alerts using SIP
>>>         A starting point for this work is draft-rosen-sipping-cap
>>> TBD      Initial document for locating the alerting server
>>> for a geographic
>>>         region. A starting point for this work is
>>>         draft-rosen-ecrit-lost-early-warning.
>>>
>>> _______________________________________________
>>> earlywarning mailing list
>>> [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, 25 Mar 2010 10:36:10 -0400
From: Hannes Tschofenig <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [earlywarning] Updated Charter Text for ATOCA

Hi Arnoud,

Arnoud van Wijk wrote:
> Hi Hannes,
> Well, RTT can be sent 30 characters per second. So it could be sent as 
> a burst instantaneously.
> But while I can understand if you have a cell broadcast method of 
> sending a message : Sulphuric acid leak at ACME Sulphur, please stay 
> inside and close doors.
> It does not need to be RTT.
Right. That's my thinking.

>
> Though if you want to respond to the message, then RTT comes into play.
There is no response envisioned.

>
> I think it depends on the current and future scope. If you plan to add 
> audio and video, then RTT comes in play as well.
That's the part that does not make sense to me.

> Also if interactivity is required or offered as an extra service, RTT 
> can be useful.
>
I have so far never heard that interactivity would be desired.

Ciao
Hannes

> Just my 2 cents.
>
> /Arnoud
>
> On 24-3-2010 19:10, Hannes Tschofenig wrote:
>> Arnoud,
>>
>> do you think real-time text makes sense here given that there is no 
>> interaction taking place here? This is a one-shot thing with the 
>> message being prepared beforehand.
>> You wouldn't see the person typing the early warning message.
>>
>> Ciao
>> Hannes
>>
>> Arnoud van Wijk wrote:
>>> Hi Hannes,
>>> I want to make the difference between Real-Time Text and message 
>>> based text clearer and suggest a minor edit here.
>>>
>>>> consumed by automatons.  Ideally, the alerts would contain, or 
>>>> refer to
>>>> media other than text messages (e.g., audio and/or video or 
>>>> Real-Time Text), but the initial
>>>                            
>>> ^^^^^^^^^^^^^^                                                                     
>>> ^^^^^^^^^^^^^^^^
>>>> work in the group is focused on small messages, which may be 
>>>> mechanically
>>>> rendered by thedevice in other forms (text to speech for example).  In
>>>> situations of a major emergency there could be scenarios where 
>>>> there are
>>>> multiple alerts generated that may require that a priority 
>>>> mechanism has
>>>> to be implemented, and this mechanism is out of scope at his time.
>>>
>>> Real-Time Text is a real-time media just like video and audio. It 
>>> will use the same RTP and SIP signalling and should not impact the 
>>> network at all.
>>> (see RFC41030).
>>> I think it is a good practice to include Real-Time Text in all the 
>>> work and documents.
>>>
>>> For the rest, the charter looks good.
>>>
>>> cheers
>>>
>>> Arnoud
>>>
>>> _______________________________________________
>>> earlywarning mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/earlywarning
>>
>>

Date: Wed, 24 Mar 2010 23:01:51 -0700
From: Arnoud van Wijk <[email-masked]>
Organization: R3TF
To: Hannes Tschofenig <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] Updated Charter Text for ATOCA
Reply-To: [email-masked]

Hi Hannes,
Well, RTT can be sent 30 characters per second. So it could be sent as a 
burst instantaneously.
But while I can understand if you have a cell broadcast method of 
sending a message : Sulphuric acid leak at ACME Sulphur, please stay 
inside and close doors.
It does not need to be RTT.

Though if you want to respond to the message, then RTT comes into play.

I think it depends on the current and future scope. If you plan to add 
audio and video, then RTT comes in play as well. Also if interactivity 
is required or offered as an extra service, RTT can be useful.

Just my 2 cents.

/Arnoud

On 24-3-2010 19:10, Hannes Tschofenig wrote:
> Arnoud,
>
> do you think real-time text makes sense here given that there is no 
> interaction taking place here? This is a one-shot thing with the 
> message being prepared beforehand.
> You wouldn't see the person typing the early warning message.
>
> Ciao
> Hannes
>
> Arnoud van Wijk wrote:
>> Hi Hannes,
>> I want to make the difference between Real-Time Text and message 
>> based text clearer and suggest a minor edit here.
>>
>>> consumed by automatons.  Ideally, the alerts would contain, or refer to
>>> media other than text messages (e.g., audio and/or video or 
>>> Real-Time Text), but the initial
>>                            
>> ^^^^^^^^^^^^^^                                                                     
>> ^^^^^^^^^^^^^^^^
>>> work in the group is focused on small messages, which may be 
>>> mechanically
>>> rendered by thedevice in other forms (text to speech for example).  In
>>> situations of a major emergency there could be scenarios where there 
>>> are
>>> multiple alerts generated that may require that a priority mechanism 
>>> has
>>> to be implemented, and this mechanism is out of scope at his time.
>>
>> Real-Time Text is a real-time media just like video and audio. It 
>> will use the same RTP and SIP signalling and should not impact the 
>> network at all.
>> (see RFC41030).
>> I think it is a good practice to include Real-Time Text in all the 
>> work and documents.
>>
>> For the rest, the charter looks good.
>>
>> cheers
>>
>> Arnoud
>>
>> _______________________________________________
>> earlywarning mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/earlywarning
>
>

Date: Wed, 24 Mar 2010 23:29:20 -0700
From: Marc Linsner <[email-masked]>
To: "DRAGE, Keith (Keith)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [earlywarning] Updated Charter Text for ATOCA

Keith,

In-line....

On 3/24/10 7:13 PM, "DRAGE, Keith (Keith)" <[email-masked]>
wrote:

> What I am not seeing here is any separation of the problem from the one that
> cell broadcast attempts to solve. Fundamentally, cell broadcast, as exists on
> all GSM, UTRAN and E-UTRAN based cell phones and is being used for Tsunami
> warning and Public Warning, exists and is not going to substantially change.
> The major limitation here is is length of message, and what does get
> transmitted will be very much dependent on that restriction.

I thought the US CMAS required new handsets? (cell broadcast is not enabled
in the handset)

> 
> Moreover I have heard from a number of governmental bodies that they are happy
> with that situation and are not envisaging further standardisation in that
> area outside of 3GPP.
> 
> So my view at the moment is that there is no point in IETF trying to address
> the scope of what is already specified in cell broadcast (from base station to
> end mobile).

That's one way to get rid of WiMAX.  Don't warn WiMAX users when the next
Tsunami is coming.   :^)

-Marc-

> 
> regards
> 
> Keith
> 
> 
> 
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
>> Sent: Wednesday, March 24, 2010 9:37 PM
>> To: [email-masked]
>> Subject: [earlywarning] Updated Charter Text for ATOCA
>> 
>> .... a minor update
>> 
>> Authority to Citizen Alert (ATOCA)
>> =================
>> 
>> Authorities need mechanisms to notify citizens and visitors
>> of emergency
>> events.   Traditionally, they have done so with broadcast
>> networks (radio
>> and television).  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. The goal of this group is
>> not to specify how originators of alerts obtain
>> authorization, but rather how a messaging system can verify
>> authorization and deliver message to the intended recipients.
>> A critical element of the work arethe mechanisms that assure
>> that only authorized agents can send alerts.
>> 
>> The recipients of these alerts are the wide range of devices
>> connected to the Internet and 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), but the initial
>> work in the group is focused on small messages, which may be
>> mechanically rendered by thedevice in other forms (text to
>> speech for example).  In situations of a major emergency
>> there could be scenarios where there are multiple alerts
>> generated that may require that a priority mechanism has to
>> be implemented, and this mechanism is out of scope at his time.
>> 
>> 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 affected by the alert.  In many
>> jurisdictions, there are regulations that define whether
>> recipients within the affected area have opt-in or opt-out
>> capability, but the protocols we 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.
>> 
>> Another class of recipients that are in scope of the work are
>> explicit opt-in subscriptions which ask for alerts for a
>> specified location.
>> An example of such a subscription would be 'send me alerts
>> for location x' (previously determined as the location of interest).
>> This work builds on existing IETF geopriv location work.
>> 
>> There are other efforts in other fora on alerts, 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.  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.
>> Of course, existing protocols for delivering messages (e.g.,
>> SIP) will be the basis for the message delivery system of
>> this working group.
>> 
>> 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.
>> 
>> Milestones
>>  
>> TBD      Initial document for "Terminology and Framework" document.
>>          A starting point for this work is
>>          draft-norreys-ecrit-authority2individuals-requirements.
>> TBD      Initial document for conveying alerts in SIP
>> TBD      Initial document for subscribing to alerts using SIP
>>          A starting point for this work is draft-rosen-sipping-cap
>> TBD      Initial document for locating the alerting server
>> for a geographic
>>          region. A starting point for this work is
>>          draft-rosen-ecrit-lost-early-warning.
>> 
>> _______________________________________________
>> 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: Wed, 24 Mar 2010 22:23:01 -0400
From: Hannes Tschofenig <[email-masked]>
To: "DRAGE, Keith (Keith)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [earlywarning] Updated Charter Text for ATOCA

Hey Keith,

from the discussions in the past I understood that this is the SIP / 
XMPP delivery mechanism similar to the HTTP mechanism being in use today.
Example: http://www.weather.gov/alerts/

I hope that makes sense.

Ciao
Hannes

DRAGE, Keith (Keith) wrote:
> What I am not seeing here is any separation of the problem from the one that cell broadcast attempts to solve. Fundamentally, cell broadcast, as exists on all GSM, UTRAN and E-UTRAN based cell phones and is being used for Tsunami warning and Public Warning, exists and is not going to substantially change. The major limitation here is is length of message, and what does get transmitted will be very much dependent on that restriction.
>
> Moreover I have heard from a number of governmental bodies that they are happy with that situation and are not envisaging further standardisation in that area outside of 3GPP.
>
> So my view at the moment is that there is no point in IETF trying to address the scope of what is already specified in cell broadcast (from base station to end mobile).
>
> regards
>
> Keith
>
>
>
>   
>> -----Original Message-----
>> From: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
>> Sent: Wednesday, March 24, 2010 9:37 PM
>> To: [email-masked]
>> Subject: [earlywarning] Updated Charter Text for ATOCA
>>
>> .... a minor update
>>
>> Authority to Citizen Alert (ATOCA)
>> =================
>>
>> Authorities need mechanisms to notify citizens and visitors 
>> of emergency
>> events.   Traditionally, they have done so with broadcast 
>> networks (radio
>> and television).  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. The goal of this group is 
>> not to specify how originators of alerts obtain 
>> authorization, but rather how a messaging system can verify 
>> authorization and deliver message to the intended recipients.
>> A critical element of the work arethe mechanisms that assure 
>> that only authorized agents can send alerts.
>>
>> The recipients of these alerts are the wide range of devices 
>> connected to the Internet and 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), but the initial 
>> work in the group is focused on small messages, which may be 
>> mechanically rendered by thedevice in other forms (text to 
>> speech for example).  In situations of a major emergency 
>> there could be scenarios where there are multiple alerts 
>> generated that may require that a priority mechanism has to 
>> be implemented, and this mechanism is out of scope at his time.
>>
>> 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 affected by the alert.  In many 
>> jurisdictions, there are regulations that define whether 
>> recipients within the affected area have opt-in or opt-out 
>> capability, but the protocols we 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.
>>
>> Another class of recipients that are in scope of the work are 
>> explicit opt-in subscriptions which ask for alerts for a 
>> specified location.
>> An example of such a subscription would be 'send me alerts 
>> for location x' (previously determined as the location of interest).
>> This work builds on existing IETF geopriv location work.
>>
>> There are other efforts in other fora on alerts, 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.  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.
>> Of course, existing protocols for delivering messages (e.g., 
>> SIP) will be the basis for the message delivery system of 
>> this working group.
>>
>> 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.
>>
>> Milestones
>>  
>> TBD      Initial document for "Terminology and Framework" document.
>>          A starting point for this work is
>>          draft-norreys-ecrit-authority2individuals-requirements.
>> TBD      Initial document for conveying alerts in SIP
>> TBD      Initial document for subscribing to alerts using SIP
>>          A starting point for this work is draft-rosen-sipping-cap
>> TBD      Initial document for locating the alerting server 
>> for a geographic
>>          region. A starting point for this work is
>>          draft-rosen-ecrit-lost-early-warning.
>>
>> _______________________________________________
>> earlywarning mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/earlywarning
>>     

From: Richard Barnes <[email-masked]>
To: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 24 Mar 2010 19:15:55 -0700
Cc: Hannes Tschofenig <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [earlywarning] Updated Charter Text for ATOCA

So Keith, do you think that emergency notifications should not be  
available on any other network?

Even if you use cell broadcast, there's a need for a distribution  
architecture, as the US CMAS demonstrates.

--Richard

On Mar 24, 2010, at 7:13 PM, DRAGE, Keith (Keith) wrote:

> What I am not seeing here is any separation of the problem from the  
> one that cell broadcast attempts to solve. Fundamentally, cell  
> broadcast, as exists on all GSM, UTRAN and E-UTRAN based cell phones  
> and is being used for Tsunami warning and Public Warning, exists and  
> is not going to substantially change. The major limitation here is  
> is length of message, and what does get transmitted will be very  
> much dependent on that restriction.
>
> Moreover I have heard from a number of governmental bodies that they  
> are happy with that situation and are not envisaging further  
> standardisation in that area outside of 3GPP.
>
> So my view at the moment is that there is no point in IETF trying to  
> address the scope of what is already specified in cell broadcast  
> (from base station to end mobile).
>
> regards
>
> Keith
>
>
>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
>> Sent: Wednesday, March 24, 2010 9:37 PM
>> To: [email-masked]
>> Subject: [earlywarning] Updated Charter Text for ATOCA
>>
>> .... a minor update
>>
>> Authority to Citizen Alert (ATOCA)
>> =================
>>
>> Authorities need mechanisms to notify citizens and visitors
>> of emergency
>> events.   Traditionally, they have done so with broadcast
>> networks (radio
>> and television).  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. The goal of this group is
>> not to specify how originators of alerts obtain
>> authorization, but rather how a messaging system can verify
>> authorization and deliver message to the intended recipients.
>> A critical element of the work arethe mechanisms that assure
>> that only authorized agents can send alerts.
>>
>> The recipients of these alerts are the wide range of devices
>> connected to the Internet and 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), but the initial
>> work in the group is focused on small messages, which may be
>> mechanically rendered by thedevice in other forms (text to
>> speech for example).  In situations of a major emergency
>> there could be scenarios where there are multiple alerts
>> generated that may require that a priority mechanism has to
>> be implemented, and this mechanism is out of scope at his time.
>>
>> 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 affected by the alert.  In many
>> jurisdictions, there are regulations that define whether
>> recipients within the affected area have opt-in or opt-out
>> capability, but the protocols we 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.
>>
>> Another class of recipients that are in scope of the work are
>> explicit opt-in subscriptions which ask for alerts for a
>> specified location.
>> An example of such a subscription would be 'send me alerts
>> for location x' (previously determined as the location of interest).
>> This work builds on existing IETF geopriv location work.
>>
>> There are other efforts in other fora on alerts, 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.  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.
>> Of course, existing protocols for delivering messages (e.g.,
>> SIP) will be the basis for the message delivery system of
>> this working group.
>>
>> 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.
>>
>> Milestones
>>
>> TBD      Initial document for "Terminology and Framework" document.
>>         A starting point for this work is
>>         draft-norreys-ecrit-authority2individuals-requirements.
>> TBD      Initial document for conveying alerts in SIP
>> TBD      Initial document for subscribing to alerts using SIP
>>         A starting point for this work is draft-rosen-sipping-cap
>> TBD      Initial document for locating the alerting server
>> for a geographic
>>         region. A starting point for this work is
>>         draft-rosen-ecrit-lost-early-warning.
>>
>> _______________________________________________
>> 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: "DRAGE, Keith (Keith)" <[email-masked]>
To: Hannes Tschofenig <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 25 Mar 2010 03:13:24 +0100
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [earlywarning] Updated Charter Text for ATOCA

What I am not seeing here is any separation of the problem from the one that cell broadcast attempts to solve. Fundamentally, cell broadcast, as exists on all GSM, UTRAN and E-UTRAN based cell phones and is being used for Tsunami warning and Public Warning, exists and is not going to substantially change. The major limitation here is is length of message, and what does get transmitted will be very much dependent on that restriction.

Moreover I have heard from a number of governmental bodies that they are happy with that situation and are not envisaging further standardisation in that area outside of 3GPP.

So my view at the moment is that there is no point in IETF trying to address the scope of what is already specified in cell broadcast (from base station to end mobile).

regards

Keith

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
> Sent: Wednesday, March 24, 2010 9:37 PM
> To: [email-masked]
> Subject: [earlywarning] Updated Charter Text for ATOCA
> 
> .... a minor update
> 
> Authority to Citizen Alert (ATOCA)
> ==================================
> 
> Authorities need mechanisms to notify citizens and visitors 
> of emergency
> events.   Traditionally, they have done so with broadcast 
> networks (radio
> and television).  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. The goal of this group is 
> not to specify how originators of alerts obtain 
> authorization, but rather how a messaging system can verify 
> authorization and deliver message to the intended recipients.
> A critical element of the work arethe mechanisms that assure 
> that only authorized agents can send alerts.
> 
> The recipients of these alerts are the wide range of devices 
> connected to the Internet and 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), but the initial 
> work in the group is focused on small messages, which may be 
> mechanically rendered by thedevice in other forms (text to 
> speech for example).  In situations of a major emergency 
> there could be scenarios where there are multiple alerts 
> generated that may require that a priority mechanism has to 
> be implemented, and this mechanism is out of scope at his time.
> 
> 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 affected by the alert.  In many 
> jurisdictions, there are regulations that define whether 
> recipients within the affected area have opt-in or opt-out 
> capability, but the protocols we 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.
> 
> Another class of recipients that are in scope of the work are 
> explicit opt-in subscriptions which ask for alerts for a 
> specified location.
> An example of such a subscription would be 'send me alerts 
> for location x' (previously determined as the location of interest).
> This work builds on existing IETF geopriv location work.
> 
> There are other efforts in other fora on alerts, 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.  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.
> Of course, existing protocols for delivering messages (e.g., 
> SIP) will be the basis for the message delivery system of 
> this working group.
> 
> 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.
> 
> Milestones
>  
> TBD      Initial document for "Terminology and Framework" document.
>          A starting point for this work is
>          draft-norreys-ecrit-authority2individuals-requirements.
> TBD      Initial document for conveying alerts in SIP
> TBD      Initial document for subscribing to alerts using SIP
>          A starting point for this work is draft-rosen-sipping-cap
> TBD      Initial document for locating the alerting server 
> for a geographic
>          region. A starting point for this work is
>          draft-rosen-ecrit-lost-early-warning.
> 
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning
> 

Date: Wed, 24 Mar 2010 22:10:09 -0400
From: Hannes Tschofenig <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [earlywarning] Updated Charter Text for ATOCA

Arnoud,

do you think real-time text makes sense here given that there is no 
interaction taking place here? This is a one-shot thing with the message 
being prepared beforehand.
You wouldn't see the person typing the early warning message.
 
Ciao
Hannes

Arnoud van Wijk wrote:
> Hi Hannes,
> I want to make the difference between Real-Time Text and message based 
> text clearer and suggest a minor edit here.
>
>> consumed by automatons.  Ideally, the alerts would contain, or refer to
>> media other than text messages (e.g., audio and/or video or Real-Time 
>> Text), but the initial
>>    
>                            
> ^^^^^^^^^^^^^^                                                                     
> ^^^^^^^^^^^^^^^^
>> work in the group is focused on small messages, which may be 
>> mechanically
>> rendered by thedevice in other forms (text to speech for example).  In
>> situations of a major emergency there could be scenarios where there are
>> multiple alerts generated that may require that a priority mechanism has
>> to be implemented, and this mechanism is out of scope at his time.
>>    
>
> Real-Time Text is a real-time media just like video and audio. It will 
> use the same RTP and SIP signalling and should not impact the network 
> at all.
> (see RFC41030).
> I think it is a good practice to include Real-Time Text in all the 
> work and documents.
>
> For the rest, the charter looks good.
>
> cheers
>
> Arnoud
>
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

Date: Wed, 24 Mar 2010 17:56:49 -0700
From: Arnoud van Wijk <[email-masked]>
Organization: R3TF
To: [email-masked]
Subject: Re: [earlywarning] Updated Charter Text for ATOCA
Reply-To: [email-masked]

Hi Hannes,
I want to make the difference between Real-Time Text and message based 
text clearer and suggest a minor edit here.

> consumed by automatons.  Ideally, the alerts would contain, or refer to
> media other than text messages (e.g., audio and/or video or Real-Time Text), but the initial
>    
                            
^^^^^^^^^^^^^^                                                                     
^^^^^^^^^^^^^^^^
> work in the group is focused on small messages, which may be mechanically
> rendered by thedevice in other forms (text to speech for example).  In
> situations of a major emergency there could be scenarios where there are
> multiple alerts generated that may require that a priority mechanism has
> to be implemented, and this mechanism is out of scope at his time.
>    

Real-Time Text is a real-time media just like video and audio. It will 
use the same RTP and SIP signalling and should not impact the network at 
all.
(see RFC41030).
I think it is a good practice to include Real-Time Text in all the work 
and documents.

For the rest, the charter looks good.

cheers

Arnoud

Date: Wed, 24 Mar 2010 18:22:29 -0400
From: Hannes Tschofenig <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [earlywarning] New Charter Text for ATOCA

Hi Carl,

thanks for the input.

How would your feedback be reflected in the charter text?

Ciao
Hannes

[email-masked] wrote:
> Hannes -
>
> Some additional information. In Canada, they use a Canadian Profile of CAP
> for authority to authority and then transform the CAP message to GeoRSS
> GML, SMS, or KML for authority to citizen. In Taiwan, there has been some
> work also in the alerting world using a new draft spec called GeoSMS. In
> Taiwan, they are also using a draft OGC standards called Sensor Alert
> Service (SAS), but this will change based on the work described below.
>
> That said, the OGC community is forging ahead looking at frameworks and
> architectures for alerting. In the OGC Web Services 7.0 testbed:
>
> OWS-7 is doing a lot of testing related to alert notification
> capabilities.  They are currently looking at a new service tentatively
> titled SES (Sensor Event Service)
> http://portal.opengeospatial.org/files/?artifact_id)576 (earlier
> discussion paper) which is being enhanced to output the alert in several
> different formats - CAP, ATOM, and I believe GeoRSS.  I believe the Sensor
> part of the Event Service is a misnomer as this service will not be tied
> to only sensors so I think the name will change eventually.  It is the
> consensus of the OWS-7 group that the draft OGC Sensor Alert Service will
> no longer be required.  As I understand it, the OGC Web Notification
> Service is a method of delivery of the message (email, Short Message
> Service (SMS), Instant Messaging (IM), automated phone calls or faxes) as
> such is more of a message transport service. SAS and WNS are beng
> integrated into the SES specification.
>
> Who is supporting this work within the OGC community? OWS-7 is described
> here: http://www.opengeospatial.org/standards/requests/60. There are
> numerous additional OGC Member organizations working this application
> area. The OWS-7 work is aligned with the GMES, ORCHESTRA, and GEOSS
> requirements for alerting.
>
> The OGC work is being done perhaps at a higher level in the applications
> stack than the IETF work being envisioned.
>
> Cheers
>
> Carl
>
>
>
>   
>> Based on the discussions during the breakout session we came up with the
>> following text proposal.
>> Please let us know whether you are OK with the wording.
>>
>>
>> Authority to Citizen Alert (ATOCA)
>> =================
>>
>> Authorities need mechanisms to notify citizens and visitors of emergency
>> events.   Traditionally, they have done so with broadcast networks (radio
>> and television).  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. The goal of this group is not to specify
>> how originators of alerts obtain authorization, but rather how a messaging
>> system can verify authorization and deliver message to the intended
>> recipients.
>> A critical element of the work arethe mechanisms that assure that only
>> authorized agents can send alerts.
>>
>> The recipients of these alerts are the wide range of devices connected to
>> the Internet and 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), but the initial
>> work in the group is focused on small messages, which may be mechanically
>> rendered by thedevice in other forms (text to speech for example).  In
>> situations of a major emergency there could be scenarios where there are
>> multiple alerts generated that may require that a priority mechanism has
>> to be implemented, and this mechanism is out of scope at his time.
>>
>> 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
>> affected by the alert.  In many jurisdictions, there are regulations that
>> define whether recipients within the affected area have opt-in or opt-out
>> capability, but the protocols we 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.
>>
>> Another class of recipients that are in scope of the work are explicit
>> opt-in subscriptions which ask for alerts that are sent to an associated
>> party.  An example of such a subscription would be 'send me alerts which
>> are
>> sent too my daughter based on her location'. This work builds on existing
>> IETF geopriv location work.
>>
>> There are other efforts in other fora on alerts, 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.  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.
>> Of course, existing protocols for delivering messages (e.g., SIP)
>> will be the basis for the message delivery system of this working group.
>>
>> 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.
>>
>> Milestones
>>
>> TBD      Initial document for "Terminology and Framework" document.
>>          A starting point for this work is
>>          draft-norreys-ecrit-authority2individuals-requirements.
>> TBD      Initial document for conveying alerts in SIP
>> TBD      Initial document for subscribing to alerts using SIP
>>          A starting point for this work is draft-rosen-sipping-cap
>> TBD      Initial document for locating the alerting server for a
>> geographic
>>          region. A starting point for this work is
>>          draft-rosen-ecrit-lost-early-warning.
>>
>> _______________________________________________
>> earlywarning mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/earlywarning
>>
>>     
>
>   

Date: Wed, 24 Mar 2010 17:40:49 -0400 (EDT)
From: [email-masked]
To: "Hannes Tschofenig" <[email-masked]>
Importance: Normal
Cc: [email-masked]
Subject: Re: [earlywarning] New Charter Text for ATOCA

Hannes -

Some additional information. In Canada, they use a Canadian Profile of CAP
for authority to authority and then transform the CAP message to GeoRSS
GML, SMS, or KML for authority to citizen. In Taiwan, there has been some
work also in the alerting world using a new draft spec called GeoSMS. In
Taiwan, they are also using a draft OGC standards called Sensor Alert
Service (SAS), but this will change based on the work described below.

That said, the OGC community is forging ahead looking at frameworks and
architectures for alerting. In the OGC Web Services 7.0 testbed:

OWS-7 is doing a lot of testing related to alert notification
capabilities.  They are currently looking at a new service tentatively
titled SES (Sensor Event Service)
http://portal.opengeospatial.org/files/?artifact_id)576 (earlier
discussion paper) which is being enhanced to output the alert in several
different formats - CAP, ATOM, and I believe GeoRSS.  I believe the Sensor
part of the Event Service is a misnomer as this service will not be tied
to only sensors so I think the name will change eventually.  It is the
consensus of the OWS-7 group that the draft OGC Sensor Alert Service will
no longer be required.  As I understand it, the OGC Web Notification
Service is a method of delivery of the message (email, Short Message
Service (SMS), Instant Messaging (IM), automated phone calls or faxes) as
such is more of a message transport service. SAS and WNS are beng
integrated into the SES specification.

Who is supporting this work within the OGC community? OWS-7 is described
here: http://www.opengeospatial.org/standards/requests/60. There are
numerous additional OGC Member organizations working this application
area. The OWS-7 work is aligned with the GMES, ORCHESTRA, and GEOSS
requirements for alerting.

The OGC work is being done perhaps at a higher level in the applications
stack than the IETF work being envisioned.

Cheers

Carl

> Based on the discussions during the breakout session we came up with the
> following text proposal.
> Please let us know whether you are OK with the wording.
>
>
> Authority to Citizen Alert (ATOCA)
> =================
>
> Authorities need mechanisms to notify citizens and visitors of emergency
> events.   Traditionally, they have done so with broadcast networks (radio
> and television).  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. The goal of this group is not to specify
> how originators of alerts obtain authorization, but rather how a messaging
> system can verify authorization and deliver message to the intended
> recipients.
> A critical element of the work arethe mechanisms that assure that only
> authorized agents can send alerts.
>
> The recipients of these alerts are the wide range of devices connected to
> the Internet and 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), but the initial
> work in the group is focused on small messages, which may be mechanically
> rendered by thedevice in other forms (text to speech for example).  In
> situations of a major emergency there could be scenarios where there are
> multiple alerts generated that may require that a priority mechanism has
> to be implemented, and this mechanism is out of scope at his time.
>
> 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
> affected by the alert.  In many jurisdictions, there are regulations that
> define whether recipients within the affected area have opt-in or opt-out
> capability, but the protocols we 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.
>
> Another class of recipients that are in scope of the work are explicit
> opt-in subscriptions which ask for alerts that are sent to an associated
> party.  An example of such a subscription would be 'send me alerts which
> are
> sent too my daughter based on her location'. This work builds on existing
> IETF geopriv location work.
>
> There are other efforts in other fora on alerts, 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.  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.
> Of course, existing protocols for delivering messages (e.g., SIP)
> will be the basis for the message delivery system of this working group.
>
> 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.
>
> Milestones
>
> TBD      Initial document for "Terminology and Framework" document.
>          A starting point for this work is
>          draft-norreys-ecrit-authority2individuals-requirements.
> TBD      Initial document for conveying alerts in SIP
> TBD      Initial document for subscribing to alerts using SIP
>          A starting point for this work is draft-rosen-sipping-cap
> TBD      Initial document for locating the alerting server for a
> geographic
>          region. A starting point for this work is
>          draft-rosen-ecrit-lost-early-warning.
>
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning
>

Date: Wed, 24 Mar 2010 17:36:49 -0400
From: Hannes Tschofenig <[email-masked]>
To: [email-masked]
Subject: [earlywarning] Updated Charter Text for ATOCA

.... a minor update

Authority to Citizen Alert (ATOCA)
=================

Authorities need mechanisms to notify citizens and visitors of emergency
events.   Traditionally, they have done so with broadcast networks (radio
and television).  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. The goal of this group is not to specify
how originators of alerts obtain authorization, but rather how a messaging
system can verify authorization and deliver message to the intended 
recipients.
A critical element of the work arethe mechanisms that assure that only
authorized agents can send alerts.

The recipients of these alerts are the wide range of devices connected to
the Internet and 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), but the initial
work in the group is focused on small messages, which may be mechanically
rendered by thedevice in other forms (text to speech for example).  In
situations of a major emergency there could be scenarios where there are
multiple alerts generated that may require that a priority mechanism has
to be implemented, and this mechanism is out of scope at his time.

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
affected by the alert.  In many jurisdictions, there are regulations that
define whether recipients within the affected area have opt-in or opt-out
capability, but the protocols we 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.

Another class of recipients that are in scope of the work are explicit
opt-in subscriptions which ask for alerts for a specified location.
An example of such a subscription would be 'send me alerts for
location x' (previously determined as the location of interest).
This work builds on existing IETF geopriv location work.

There are other efforts in other fora on alerts, 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.  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.
Of course, existing protocols for delivering messages (e.g., SIP)
will be the basis for the message delivery system of this working group.

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.

Milestones
 
TBD      Initial document for "Terminology and Framework" document.
         A starting point for this work is
         draft-norreys-ecrit-authority2individuals-requirements.
TBD      Initial document for conveying alerts in SIP
TBD      Initial document for subscribing to alerts using SIP
         A starting point for this work is draft-rosen-sipping-cap
TBD      Initial document for locating the alerting server for a geographic
         region. A starting point for this work is
         draft-rosen-ecrit-lost-early-warning.

Date: Wed, 24 Mar 2010 17:26:28 -0400
From: Hannes Tschofenig <[email-masked]>
To: [email-masked]
Subject: [earlywarning] New Charter Text for ATOCA

Based on the discussions during the breakout session we came up with the 
following text proposal.
Please let us know whether you are OK with the wording.

Authority to Citizen Alert (ATOCA)
=================

Authorities need mechanisms to notify citizens and visitors of emergency
events.   Traditionally, they have done so with broadcast networks (radio
and television).  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. The goal of this group is not to specify
how originators of alerts obtain authorization, but rather how a messaging
system can verify authorization and deliver message to the intended 
recipients.
A critical element of the work arethe mechanisms that assure that only
authorized agents can send alerts.

The recipients of these alerts are the wide range of devices connected to
the Internet and 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), but the initial
work in the group is focused on small messages, which may be mechanically
rendered by thedevice in other forms (text to speech for example).  In
situations of a major emergency there could be scenarios where there are
multiple alerts generated that may require that a priority mechanism has
to be implemented, and this mechanism is out of scope at his time.

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
affected by the alert.  In many jurisdictions, there are regulations that
define whether recipients within the affected area have opt-in or opt-out
capability, but the protocols we 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.

Another class of recipients that are in scope of the work are explicit
opt-in subscriptions which ask for alerts that are sent to an associated
party.  An example of such a subscription would be 'send me alerts which are
sent too my daughter based on her location'. This work builds on existing
IETF geopriv location work.

There are other efforts in other fora on alerts, 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.  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.
Of course, existing protocols for delivering messages (e.g., SIP)
will be the basis for the message delivery system of this working group.

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.

Milestones
 
TBD      Initial document for "Terminology and Framework" document.
         A starting point for this work is
         draft-norreys-ecrit-authority2individuals-requirements.
TBD      Initial document for conveying alerts in SIP
TBD      Initial document for subscribing to alerts using SIP
         A starting point for this work is draft-rosen-sipping-cap
TBD      Initial document for locating the alerting server for a geographic
         region. A starting point for this work is
         draft-rosen-ecrit-lost-early-warning.

From: "DRAGE, Keith (Keith)" <[email-masked]>
To: Hannes Tschofenig <[email-masked]>
Date: Wed, 24 Mar 2010 02:54:48 +0100
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [earlywarning] [Ecrit] ATOCA Informal Gathering at IETF#77

As you insist on calling this during main meeting time in conflict with sessions people have to chair, please circulate all material beforehand.

Keith 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Hannes Tschofenig
> Sent: Wednesday, March 24, 2010 1:39 AM
> To: 'ECRIT'; GEOPRIV; [email-masked]
> Subject: [Ecrit] ATOCA Informal Gathering at IETF#77
> 
> Reminder for the chat about the ATOCA charter text discussion 
> as mentioned in my previous mail.
> 
> DATE: Wednesday, 24th March
> TIME: 13:00 to 15:00
> ROOM: Carmel (4th floor)
> 
> Looking forward to see you there.
> 
> Ciao
> Hannes
> 
>  
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit
> 

Date: Tue, 23 Mar 2010 21:38:31 -0400
From: Hannes Tschofenig <[email-masked]>
To: 'ECRIT' <[email-masked]>, GEOPRIV <[email-masked]>,  [email-masked]
Subject: [earlywarning] ATOCA Informal Gathering at IETF#77

Reminder for the chat about the ATOCA charter text discussion as 
mentioned in my previous mail.

DATE: Wednesday, 24th March
TIME: 13:00 to 15:00
ROOM: Carmel (4th floor)

Looking forward to see you there.

Ciao
Hannes

From: "DRAGE, Keith (Keith)" <[email-masked]>
To: Hannes Tschofenig <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 22 Mar 2010 15:38:37 +0100
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [earlywarning] Informal Gathering at IETF#77

You are taking people away from the AVT session I am chairing.

Keith 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
> Sent: Monday, March 22, 2010 2:29 PM
> To: [email-masked]
> Subject: Re: [earlywarning] Informal Gathering at IETF#77
> 
> Hi all,
> 
> I got a few responses to my mail and hence I would propose to 
> meet on Wednesday from 13:00 to 15:00. 
> I will try to find a room.
> 
> We would be working on the charter text.
> 
> Ciao
> Hannes
> 
> Hannes Tschofenig wrote:
> > Hi all,
> >
> > the IETF#77 meeting is getting closer and I was wondering 
> whether some 
> > of you would like to get together to chat about the charter 
> text. We, 
> > for some reason, got a bit struck with the wording of the charter.
> >
> > Drop me a mail if you are interested to chat about this topic!
> >
> > 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: Mon, 22 Mar 2010 10:28:53 -0400
From: Hannes Tschofenig <[email-masked]>
To: [email-masked]
Subject: Re: [earlywarning] Informal Gathering at IETF#77

Hi all,

I got a few responses to my mail and hence I would propose to meet on 
Wednesday from 13:00 to 15:00. 
I will try to find a room.

We would be working on the charter text.

Ciao
Hannes

Hannes Tschofenig wrote:
> Hi all,
>
> the IETF#77 meeting is getting closer and I was wondering whether some 
> of you would like to get together to chat about the charter text. We, 
> for some reason, got a bit struck with the wording of the charter.
>
> Drop me a mail if you are interested to chat about this topic!
>
> Ciao
> Hannes
>
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

Date: Sat, 06 Mar 2010 10:51:35 +0200
From: Hannes Tschofenig <[email-masked]>
To: [email-masked]
Subject: [earlywarning] Informal Gathering at IETF#77

Hi all,

the IETF#77 meeting is getting closer and I was wondering whether some 
of you would like to get together to chat about the charter text. We, 
for some reason, got a bit struck with the wording of the charter.

Drop me a mail if you are interested to chat about this topic!

Ciao
Hannes