Subject: [earlywarning] Finishing the Charter Text Discussions

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 06 Apr 2010 13:18:18 +0200

Hi all, 

we had some discussions in response to the charter text I distributed. I made some minor changes based on the received comments but most of the discussions seemed (at least to me) not related to the charter text itself. 

Is the charter text OK for everyone? 

Ciao
Hannes

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

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 are the 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 the device 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 used. The work on a resource priority mechanism is out of scope of the 
initial charter, but may be revisited at a later date.

Which devices should get alerts is primarily driven by location.  The first
set of recipients that must be catered for are those within the area
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 efforts in other fora on early warning, which will be considered
in this effort.  For example, we expect to make use of the OASIS Common
Alerting Protocol (CAP) for the encoding of alerts.  OGC, ATIS, TIA, ITU-T, 
ETSI and 3GPP also have alert efforts underway, and consultation with these 
efforts will be undertaken to avoid unnecessary duplication of effort. 
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: "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]>
Date: Wed, 7 Apr 2010 08:30:39 -0700

Hi Hannes,

Based upon the previous email decisions, changes to the charter text are
still needed.  

The second paragraph of the charter provides a high level purpose and
scope for the ATOCA work.  The following should be added to the end of
the second paragraph to provide further clarification on the purpose and
scope of the ATOCA work:

"The ATOCA solutions will not adversely affect the ability of any access
technology to provide emergency services to the citizens (e.g. 9-1-1
calls) or to provide communication services to first responders or other
authorized emergency services personnel.  Additionally, ATOCA is not
replacement solution for any authority to citizen alerting supported by
any access technology."

Regards,

DeWayne A. Sennett

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Tuesday, April 06, 2010 4:18 AM
To: [email-masked]
Subject: [earlywarning] Finishing the Charter Text Discussions

Hi all, 

we had some discussions in response to the charter text I distributed. I
made some minor changes based on the received comments but most of the
discussions seemed (at least to me) not related to the charter text
itself. 

Ciao
Hannes

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

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 are the 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 the device 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 used. The work on a resource priority mechanism is out of scope of
the 
initial charter, but may be revisited at a later date.

Which devices should get alerts is primarily driven by location.  The
first
set of recipients that must be catered for are those within the area
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. 

There are efforts in other fora on early warning, which will be
considered
in this effort.  For example, we expect to make use of the OASIS Common
Alerting Protocol (CAP) for the encoding of alerts.  OGC, ATIS, TIA,
ITU-T, 
ETSI and 3GPP also have alert efforts underway, and consultation with
these 
efforts will be undertaken to avoid unnecessary duplication of effort. 
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

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

---

From: ken carlberg <[email-masked]>
Date: Wed, 7 Apr 2010 15:48:11 -0400

> replacement solution for any authority to citizen alerting supported by

given the previous thread on this list, I'm a bit leery of that first sentence.  But, if it were agreed to add it in, then I would expect the individuals who make a claim that an ATOCA solution adversely affects 9-1-1 type calls will be required to prove it instead of simply stating a position.

as for the second sentence, that is out of scope of the IETF.  any deployment of what is considered an ATOCA solution is a market decision.

-ken

---

From: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
Date: Wed, 7 Apr 2010 12:56:52 -0700

The second is more than a market decision - it is an interaction with a
regulatory requirement.

Perhaps a better way to phrase is as follows:

"Additionally, ATOCA will not interfere with nor replace solutions
designed to meet regulatory requirements for any authority to citizen
alerting of any access technology."

Brian Daly
AT&T

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of ken carlberg
Sent: Wednesday, April 07, 2010 12:48 PM
To: SENNETT, DEWAYNE A (ATTCINW)
Cc: Hannes Tschofenig; [email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

> replacement solution for any authority to citizen alerting supported
by

given the previous thread on this list, I'm a bit leery of that first
sentence.  But, if it were agreed to add it in, then I would expect the
individuals who make a claim that an ATOCA solution adversely affects
9-1-1 type calls will be required to prove it instead of simply stating
a position.

as for the second sentence, that is out of scope of the IETF.  any
deployment of what is considered an ATOCA solution is a market decision.

-ken

---

From: Brian Rosen <[email-masked]>
Date: Wed, 07 Apr 2010 16:00:04 -0400

Generally, it's not a good idea for any service to impede any other service,
but we don't have to say that all the time.  Here, I think we don't have to
discuss how authority to citizen should be prioritized over citizen to
authority.  I rather suspect that an outgoing warning of an impending
typhoon is more important that an incoming kitty-in-the-tree call, but maybe
that's just me.

ATOCA may or may not be a replacement for something that exists.  Agree with
Ken, the market (and in this case, likely governments) will decide.

So I would not want to see this text in the charter.

Brian

On 4/7/10 3:48 PM, "ken carlberg" <[email-masked]> wrote:

> individuals who make a claim that an ATOCA solution adversely affects 9-1-1
> type calls will be required to prove it instead of simply stating a position.
> 
> as for the second sentence, that is out of scope of the IETF.  any deployment
> of what is considered an ATOCA solution is a market decision.
> 
> -ken
>

---

From: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
Date: Wed, 7 Apr 2010 13:06:39 -0700

Absolutely false!!

You have no clue what the incoming emergency call is about - it could be
a kitty in the tree call, as you put it, or it could be "I just had a
heart attack and need help immediately".

An authority to citizen "call" should never take priority over a citizen
to authority, and this is regulated ni the FCC rules for CMAS.

And your typhoon analogy proves the point - a typhoon is known several
days in advance, while you have minutes to take action on a heart
attack.

Brian Daly

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Wednesday, April 07, 2010 1:00 PM
To: ken carlberg; SENNETT, DEWAYNE A (ATTCINW)
Cc: Hannes Tschofenig; [email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

Generally, it's not a good idea for any service to impede any other
service,
but we don't have to say that all the time.  Here, I think we don't have
to
discuss how authority to citizen should be prioritized over citizen to
authority.  I rather suspect that an outgoing warning of an impending
typhoon is more important that an incoming kitty-in-the-tree call, but
maybe
that's just me.

ATOCA may or may not be a replacement for something that exists.  Agree
with
Ken, the market (and in this case, likely governments) will decide.

Brian

> individuals who make a claim that an ATOCA solution adversely affects
9-1-1
> as for the second sentence, that is out of scope of the IETF.  any
deployment

---

From: Marc Linsner <[email-masked]>
Date: Wed, 07 Apr 2010 16:07:35 -0400

CMAS was opt-in by the carriers, not a requirement....??

-Marc-

---

From: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
Date: Wed, 7 Apr 2010 13:09:06 -0700

But those operators that opt-in must follow the FCC Part 10 rules for
CMAS. So I do nto understand your comment.

Brian

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Wednesday, April 07, 2010 1:08 PM
To: DALY, BRIAN K (ATTCINW)
Cc: [email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

-Marc-

---

From: Marc Linsner <[email-masked]>
Date: Wed, 07 Apr 2010 16:12:20 -0400

I agree with Ken, strike the last sentence.

-Marc-

---

From: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
Date: Wed, 7 Apr 2010 13:13:52 -0700

For the record, AT&T is in opposition to removing the last sentence.

Brian Daly
AT&T

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Marc Linsner
Sent: Wednesday, April 07, 2010 1:12 PM
To: [email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

-Marc-

9-1-1
deployment

---

From: Marc Linsner <[email-masked]>
Date: Wed, 07 Apr 2010 16:14:35 -0400

The opt-in was a market decision, not a requirement.

If ATOCA builds a different solution, it too will be a market decision to
offer or not.

-Marc-

---

From: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
Date: Wed, 7 Apr 2010 13:17:02 -0700

The opt-in was not a market decision - I disagree. It was a
congressional and FCC mandate stemmed from the WARN Act resulting in the
FCC Part 10 rules.

ATOCA does not fall under that.

Brian

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Wednesday, April 07, 2010 1:15 PM
To: DALY, BRIAN K (ATTCINW)
Cc: [email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

If ATOCA builds a different solution, it too will be a market decision
to
offer or not.

-Marc-

---

From: Brian Rosen <[email-masked]>
Date: Wed, 07 Apr 2010 16:17:44 -0400

In what way would any RFC not have to meet that requirement?

I understand that you are concerned that this work overlaps layer 2 specific
solutions.  However, there is no need to explicitly put this work in second
class.  It's not going to affect any words in a protocol specification.  If
there is a regulatory requirement that makes ATOCA compliant
implementations, like any other service, subservient in some way to some
other service, so be it.  The charter, and the spec, don't need to say that;
it's always true.

Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 7 Apr 2010 16:19:55 -0400

+1

The notion that ATOCA, or any IETF WG, can somehow accommodate "regulation" is a bit peculiar. Which regulation? Of which country or countries? Does it mean that if a country rules out use of VoIP, as some do, that we can't standardize protocols for that? Would the charter of the RAI WGs have to note that use of this technology is illegal in Egypt?

Clearly, any product or service using IETF protocols is subject to regulation in the country or other jurisdiction it is being deployed in. The FCC (assuming an appellate court lets them...) can prohibit the use of ATOCA mechanisms, but that's not our problem, except in the sense that the technology may not be deployed at all or only in limited environments. However, if we went by the deployment regulations in force at the time of standardization, we'd still be working on ISDN at this point. It's pretty clear that mobile technology is in transition; mechanisms that made perfect sense with 2G technologies may not be nearly as useful in 4G networks.

Henning

---

From: "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]>
Date: Wed, 7 Apr 2010 13:20:38 -0700

In regards to the comment on the first sentence, all services have to be
evaluated for impact before they are implemented in any live
environment.  However, a service that is designed from the beginning
with no consideration of the impacts to the access technologies is a
very badly designed service.  ATOCA will have an adverse effect to at
least some of the access technologies and if ATOCA is designed without
any considerations of the capabilities and limitations of the access
technologies, it will fail and it will cause adverse effects to the
access technologies.

The proof of network congestion already exists.  This is demonstrated
repeatedly as "all circuits busy" error responses, dropped calls,
fast-busy tones, delayed delivery of SMS messages, etc. 

Since ATOCA is the new communications entity beginning proposed, the
burden of proof is on ATOCA to prove that it will not adversely impact
any of the associated access technologies.

DeWayne 

-----Original Message-----

-ken

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 7 Apr 2010 16:21:20 -0400

I didn't know that the IETF had corporate opinions. But maybe the IETF rules have changed recently?

Henning

---

From: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
Date: Wed, 7 Apr 2010 13:21:56 -0700

We are just stating that ATOCA contradicts the CMAS (& EAS) rules, as
well as iPAWS and DMOpen architectures, and thus is in a different
class. Thus we believe we do need to be up front in the charter and nto
to confuse the industry.

Brian

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, April 07, 2010 1:18 PM
To: DALY, BRIAN K (ATTCINW); ken carlberg; SENNETT, DEWAYNE A (ATTCINW)
Cc: Hannes Tschofenig; [email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

I understand that you are concerned that this work overlaps layer 2
specific
solutions.  However, there is no need to explicitly put this work in
second
class.  It's not going to affect any words in a protocol specification.
If
there is a regulatory requirement that makes ATOCA compliant
implementations, like any other service, subservient in some way to some
other service, so be it.  The charter, and the spec, don't need to say
that;
it's always true.

Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 7 Apr 2010 16:24:52 -0400

I gather you'd also require each new web site to get permission from AT&T, given that it can have an adverse effect? I didn't know the appellate decision on network neutrality would have an effect quite as quickly :-)

Henning

---

From: Marc Linsner <[email-masked]>
Date: Wed, 07 Apr 2010 16:30:26 -0400

Brian,

>From 
http://hraunfoss.fcc.gov/edocs_public/attachmatch/DOC-281433A1.pdf

"Wireless carriers that choose to participate"

Or
http://www.fcc.gov/cgb/consumerfacts/cmas.html

"wireless service providers that voluntarily choose to participate in CMAS"

I take that to mean wireless carriers could chose not to participate, hence
the decision to participate is driven by something other than regulatory
requirement.

It's good that ATOCA doesn't fall under the FCC rules.  The hope is that a
ATOCA solution would be far more functional than any regulatory requirement.

-Marc-

---

From: Richard Barnes <[email-masked]>
Date: Wed, 7 Apr 2010 16:35:36 -0400

Could you clarify how ATOCA "contradicts" these rules?

Isn't that kind of like saying that SIP contradicts XMPP?  The idea of  
ATOCA is to build a system with some different features than CMAS,  
that is still generally interoperable with it.  SIP has much better  
support for lots of PSTN-replacement stuff than XMPP, and conversely  
XMPP can be a lot simpler to use inter-domain, but you can still pass  
IMs and dialogues from one to another.  Likewise, we expect the ATOCA  
system to meet a different set of trade-offs than CMAS, but still  
allow alerts to move back and forth.

--Richard

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 07 Apr 2010 16:22:27 -0500

At 10:30 AM 4/7/2010, SENNETT, DEWAYNE A (ATTCINW) wrote:
>authorized emergency services personnel.

The above sentence is troubling to me too.  Take the old adage "one 
man's victory is another man's defeat". In that - I mean -- who's to 
say that an ATOCA (layer 3-7) solution adversely affects a layer 2 
solution (existing or planned)?  This is nearly always in the eyes of 
the beholder.  The IETF, for the most part, deals only with layers 
3-7, and leaves lower layer solutions to other SDOs. The classic 
example is wrt IEEE.

Put another way - if you are a proponent of the WARN act, you like 
the 140 character limitation for any message.  Most of us in the IETF 
feel that's too limiting, and believe we can create something that is 
much more useful.  Now, anyone that MUST be in compliance with the 
WARN act needs to support at least the 140 character limitation. Does 
that mean there can be no other communication with a richer set of information?

Some might say that idea alone "adversely affect an access 
technology" because who implements both are taking on increased complexity.

Is that a reason to stop progress?

In the 50s the railroad industry tried to prevent the airline 
industry from becoming certified, at least in the US.  The rail 
industry say the airline industry as a threat.  Now, was that effort 
good for anyone?

If someone doesn't implement what the IETF specifies in ATOCA, then 
they don't implement it. We let the market decide -- of course where 
jurisdictions allow.

I am opposed to the suggested change to the charter.

James

>Additionally, ATOCA is not

---

From: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
Date: Wed, 7 Apr 2010 14:29:10 -0700

In response to " If someone doesn't implement what the IETF specifies in
ATOCA, then they don't implement it. We let the market decide -- of
course where jurisdictions allow'

Why not develop a charter and ultimately a protocol that makes sense and
everyone can live with, which will increase the likelihood of it being
used, rather than developing a service with blinders on thus making it
more likely it will not be adopted?

Brian

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of James M. Polk
Sent: Wednesday, April 07, 2010 2:22 PM
To: SENNETT, DEWAYNE A (ATTCINW); Hannes Tschofenig;
[email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

that mean there can be no other communication with a richer set of
information?

Some might say that idea alone "adversely affect an access 
technology" because who implements both are taking on increased
complexity.

James

---

From: Janet P Gunn <[email-masked]>
Date: Wed, 7 Apr 2010 17:46:05 -0400

I think that the relative priority of "citizen to authority", "authority 
to citizen", "authority to authority",  and even "citizen to citizen" 
needs to be a matter of "local policy", and independent of any IETF 
defined mechanism.

Janet

This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. 
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to 
any order or other contract unless pursuant to explicit written agreement 
or government initiative expressly permitting the use of e-mail for such 
purpose.

From:
"DALY, BRIAN K (ATTCINW)" <[email-masked]>
To:
"Brian Rosen" <[email-masked]>, "ken carlberg" <[email-masked]>, 
"SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]>
Cc:
Hannes Tschofenig <[email-masked]>, [email-masked]
Date:
04/07/2010 04:06 PM
Subject:
Re: [earlywarning] Finishing the Charter Text Discussions

Absolutely false!!

Brian Daly

-----Original Message-----

Brian

9-1-1
deployment

---

From: Janet P Gunn <[email-masked]>
Date: Wed, 7 Apr 2010 18:03:17 -0400

I don't have a dog in this fight (and I am not even "working") this week- 
but I can't resist putting in my 2 cents.

1) Typically, the greatest congestion occurs close to the "edges", whether 
you call it "the access network" or "the last mile".
 
2) There is often (but by no means always) a positive correlation between 
events that trigger both "citizen to authority" and "authority to citizen" 
messages,  and localized network congestion.

3) Any mechanism to support either "citizen to authority" or "authority to 
citizen" , or "authority to authority", "special" treatment should do so 
in a manner that does not exacerbate the localized congestion.

Janet

[email-masked] wrote on 04/07/2010 04:20:38 PM:

> [image removed] 
> SENNETT, DEWAYNE A (ATTCINW) 
> 
> to:
> 
> ken carlberg
> 
> 04/07/2010 04:21 PM
> 
> Sent by:
> 
> [email-masked]
> 
> Cc:
> 
> Hannes Tschofenig, earlywarning
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 8 Apr 2010 11:59:10 +0200

A couple of minor comments in this message:

> for location x' (previously determined as the location of interest). 

This sentence left me wondering, as the key aspect of the GEOPRIV work, rather than location, was privacy. There is therefore no point in my view in mentioning geopriv unless there is some explained privacy aspect. At the moment I do not see that explained.	
 
> encoding of alerts.  OGC, ATIS, TIA, ITU-T, ETSI and 3GPP 
> also have alert efforts underway, and consultation with these 

There have been two agreed sets of 3GPP work, both of which ARE COMPLETE. These are ETWS which completed with the freeze of release 8 and PWS which completed with the freeze of release 9. When Europe makes a final decision as to what they require from 3GPP networks, then there may well be some more work initiated, but there is no active work at the moment that can be contributed to. So it is incorrect to say "... 3GPP also have alert efforts underway...". I suspect the same applies to ATIS and TIA, at least where that work corresponds to the cell broadcast mechanisms. This of course does not preclude liaison, but do not assume that 3GPP can change a frozen specification because of that liaison.

regards

Keith

> Sent: Tuesday, April 06, 2010 12:18 PM
> we had some discussions in response to the charter text I 
> distributed. I made some minor changes based on the received 
> comments but most of the discussions seemed (at least to me) 
> not related to the charter text itself. 
> 
> 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 
> 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 are the 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 
> mechanically rendered by the device 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 used. 
> The work on a resource priority mechanism is out of scope of 
> the initial charter, but may be revisited at a later date.
> 
> Which devices should get alerts is primarily driven by 
> location.  The first set of recipients that must be catered 
> for are those within the area 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). 
> There are efforts in other fora on early warning, which will 
> be considered in this effort.  For example, we expect to make 
> use of the OASIS Common Alerting Protocol (CAP) for the 
> encoding of alerts.  OGC, ATIS, TIA, ITU-T, ETSI and 3GPP 
> also have alert efforts underway, and consultation with these 
> 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
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 8 Apr 2010 11:56:32 +0200

What I am not seeing from this extended discussion is anything that will assist in permitted deployment of this in 3GPP networks (and probably 3GPP2 networks).

The existing 3GPP cell broadcast mechanism uses spare capacity that is not used for any other purpose than cell broadcast. It is not used for point-to-point traffic. Therefore at time of government alert that capacity automatically gets used for goverment alerts at the expense of any other cell broadcast traffic, but not at the expense of other point-to-point data and voice. However this usage is only good for broadcasting to all users within the cell that have turned on that type of alert (with varying degrees of optionality - the US government may not allow you to opt out of a presidential alert except by turning your phone off). Note that cell broadcast is not the same as IP multicast - it happens at the levels below IP. IP multicast in cellphone networks will normally result in multiple point-to-point communications. Potentially MBMS could be used if deployed to support IP multicast, but that still uses the same traffic channels as other voice users.

Therefore within 3GPP networks there is still a use for directed communication whereby the cellphone is treated as an internet endpoint. This would be for the type of alerts, for example, that schools send to its pupils only indicating that their own school is closed. The rest of the population does not want these events, nor do pupils of other schools who may be in the same cell coverage area. Message identifiers are not a means of excluding this communication. Now under many usages of terminology, those situations do not comprise "emergency events" using the terms in this charter. My assumption is that such events will be defined by this charter, but that is not clear at the moment. 

Now lets consider what happens under aspects of 3GPP network stress. I believe Henning has said in the past that on 9-11, the only thing that kept working was the internet. It was not possible to make cellphone calls. A similar think happened in London on the underground bombings. Except where cellsite infrastructure itself was destroyed, what will have happened here is that the cell broadcast channel was indeed still working, but the network was so overloaded with signalling attempts that it was shedding traffic. Indeed 3GPP operators have algorithms for what traffic is shed under such circumstances. IP data, CS voice data and Voice over IP all use the same radio channels. Any of them occur at the expense of the other (although the split between CS voice usage and IP (and voice over IP) is configured.

I believe Janet is correct that emergency alerts happen at times of network stress. Even if the incident to which they relate is not generating traffic in its own right, I suspect the first response to receiving a flood alert is to pick the phone up and call the remainder of your family to check what precautions they are taking, thus resulting in additional network traffic.

Therefore it is likely that 3GPP network operators have to shed traffic when major alerts are being given. Certain traffic is tagged as having special handling on the wireless part (emergency calls and authority to citizen / authority). There are two aspects to this:

-	Can they identify non-essential traffic and discard a larger proportion of this as opposed to essential traffic.

-	Can they ensure that traffic is not duplicated in the first place.

In regard to the ATOCA proposal given above, neither of these are dealt with in the charter.

In the absence of any mechanisms to identify specific traffic as essential, or to identify such traffic at all, the net result will be that all such traffic will be deemed non-essential and will not be given authority to authority priority. Conceivably, that means that there will be no alerts at time of crisis using ATOCA mechanisms because all IP communication except voice over IP, and authority to authority data has been killed. Rather than give their users a false sense of security that they will receive ATOCA alerts under times of network stress, this may well mean that 3GPP operators actively discourage ATOCA subscriptions in the first place.

If the alerts that duplicate those made using the cell broadcast service are not made in the first place, and cellphone users are restricted to targetted alerts rather than those for the whole public, then it is possible that 3GPP operators will be be able to treat ATOCO alerts differently, rather than killing everything. I don't know how we handle that in RFCs, but that should form part of the study of providing this mechanism.

Saying "let the market decide" at this point of charter discussion will therefore not result in the scenario where coexistence can occur under emergency overload. The charter needs to investigate means of enhancing coexistence with other delivery mechanisms, rather than just acknowledging that they exist.

regards

Keith

________________________________

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Janet P Gunn
	Sent: Wednesday, April 07, 2010 11:03 PM
	To: SENNETT, DEWAYNE A (ATTCINW)
	Cc: [email-masked]; Hannes Tschofenig; [email-masked]
	Subject: Re: [earlywarning] Finishing the Charter Text Discussions

	I don't have a dog in this fight (and I am not even "working") this week- but I can't resist putting in my 2 cents. 
	
	1) Typically, the greatest congestion occurs close to the "edges", whether you call it "the access network" or "the last mile". 
	  
	2) There is often (but by no means always) a positive correlation between events that trigger both "citizen to authority" and "authority to citizen" messages,  and localized network congestion. 
	
	3) Any mechanism to support either "citizen to authority" or "authority to citizen" , or "authority to authority", "special" treatment should do so in a manner that does not exacerbate the localized congestion.
	
	Janet 
	
	This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. 
	NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. 
	
	[email-masked] wrote on 04/07/2010 04:20:38 PM:
	
	> [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of ken carlberg
	> https://www.ietf.org/mailman/listinfo/earlywarning <https://www.ietf.org/mailman/listinfo/earlywarning> 
	> https://www.ietf.org/mailman/listinfo/earlywarning <https://www.ietf.org/mailman/listinfo/earlywarning>

---

From: ken carlberg <[email-masked]>
Date: Thu, 8 Apr 2010 08:18:05 -0400

Keith,

first, thanks for the well thought out comments.  I agree with a number of specific points you made (which are snipped out), but other things I find some disagreement with...

> However this usage is only good for broadcasting to all users within the cell that have turned on that type of alert (with varying degrees of optionality - the US government may not allow you to opt out of a presidential alert except by turning your phone off).

ouch, the part in parenthesis is quite speculative, at best.

> Note that cell broadcast is not the same as IP multicast - it happens at the levels below IP. IP multicast in cellphone networks will normally result in multiple point-to-point communications. Potentially MBMS could be used if deployed to support IP multicast, but that still uses the same traffic channels as other voice users.

agreed, but lets not constrain our view to just the UE->tower.  Parts of the backhaul can be prone to congestion as well, and in a direction of LTE, more components will be IP based and thus taking advantage of a layer-3 tree distribution structure.

> I believe Janet is correct that emergency alerts happen at times of network stress. Even if the incident to which they relate is not generating traffic in its own right, I suspect the first respons…

I would disagree with the above assertion.  From what I've gathered, its only a small subset of alerts that happen at times of network stress.  Clearly the 9/11 attack and the London bombings are the most acute instances of an event that grabs a lot of attention and subsequent load on networks.  However, existing systems send alerts quite often that are localized and do not automatically correlate to network stress.  

A few years ago, I spoke with several local county emergency management directors along the I-95 corridor in the North East U.S., and their day-to-day concern isn't focused on terrorism or natural disasters, but rather on hazardous materials on the highways.  Their interest is in using mechanisms like inverse-911 and localizing the alerts.

As a different example, a friend of mine in DC received an alert on his cell phone yesterday of brush fire warnings -- not that a brush fire existed, but that the conditions were favorable for one to occur.  And there certainly wasn't any corresponding stress on the cell network. 

> In regard to the ATOCA proposal given above, neither of these are dealt with in the charter.

My concern about the above position is that it places a requirement on ATOCA to assume that something in layer 2, or some walled garden, exists and is *deployed*.  I think all of us are in agreement with the point that Dave Oran made a while back that its ideal to take advantage of mechanisms that can optimize ATOCA solutions.  But we need to be careful in assuming that the specification of other mechanisms does not guarantee their deployment.

-ken

---

From: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
Date: Thu, 8 Apr 2010 07:53:37 -0700

Actually the part in parenthesis is not speculative but law - it is part
of the WARN Act passed by Congress, and included in Part 10 of the FCC
rules.

Regarding the discussion on network stress, it is relatively easy to
stress the network in times of disaster. While the 9/11 and London
bombings may be an extreme, the more subtle cases are the Minneapolis
bridge disaster, the threat of a tsunami due to the earthquake in Chili
(which stressed the systems in SoCal when they tried to issue a tsunami
advisory). Even "benign" large scale messages such as to a college
campus can result in network stress. We have extensively studied and
modeled network behavior due to emergency situations, and the results of
these studies went into the 10 month long process developing and
optimized solution for commercial mobile networks.

The other factor is how time critical is the message - a brush fire
threat advisory is not that critical, so if it is delayed by a half
hour, hour, or several hours, no big deal. However, a tornado warning
may have only minutes of reaction time and if the message is delayed
tens of minutes to hours, then it becomes not only a useless message,
but also jeopardizes the integrity of the entire alerting system.

Actually localized alerts are as problematic - if not more than - alerts
covering a large geographic area. Wireless network are not engineered to
allow everyone to be able to access resources simultaneously - it is
based on statistical traffic modeling and historical data- the so-called
"busy hour". And the technology has limitations - for example, you can
only send 2 SMSs/second/sector as a rule of thumb. Likewise, there are a
limited number of Radio Access Bearers (RABs) available per sector, and
a limit on the number of PDP contexts that can be established at the
SGSN. So if ATOCA required users to have a PDP context established and a
push service to send the data to the device, if there are a large number
of devices per sector then you can see the congestion problem. This is
why any point to point mechanism - be it SMS, IP "push" or whatever,
will fail in alerting scenarios and why broadcast mechanisms are
required.

CMAS solves the localization of alerts that you mention as GSM has the
capability to target down to the cell site (it is an operator choice on
how fine a geographic area to deliver the alerts).

CMAS solves all the problems and use cases you mention using a mechanism
designed to take advantage of the efficiency of the "layer 2" networks.
I saw discussion that it is character limited - 90 is the real number,
not 140 as a previous post suggested. However this is only for the
initial deployment, and in the future multimedia capabilities will be
added (see the CMSAAC report).

Brian Daly

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of ken carlberg
Sent: Thursday, April 08, 2010 5:18 AM
To: DRAGE, Keith (Keith)
Cc: [email-masked]; SENNETT, DEWAYNE A (ATTCINW);
[email-masked]; Tschofenig; [email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

Keith,

first, thanks for the well thought out comments.  I agree with a number
of specific points you made (which are snipped out), but other things I
find some disagreement with...

> However this usage is only good for broadcasting to all users within
the cell that have turned on that type of alert (with varying degrees of
optionality - the US government may not allow you to opt out of a
presidential alert except by turning your phone off).

> Note that cell broadcast is not the same as IP multicast - it happens
at the levels below IP. IP multicast in cellphone networks will normally
result in multiple point-to-point communications. Potentially MBMS could
be used if deployed to support IP multicast, but that still uses the
same traffic channels as other voice users.

agreed, but lets not constrain our view to just the UE->tower.  Parts of
the backhaul can be prone to congestion as well, and in a direction of
LTE, more components will be IP based and thus taking advantage of a
layer-3 tree distribution structure.

> I believe Janet is correct that emergency alerts happen at times of
network stress. Even if the incident to which they relate is not
generating traffic in its own right, I suspect the first response to
receiving a flood alert is to pick the phone up and call the remainder
of your family to check what precautions they are taking, thus resulting
in additional network traffic.

I would disagree with the above assertion.  From what I've gathered, its
only a small subset of alerts that happen at times of network stress.
Clearly the 9/11 attack and the London bombings are the most acute
instances of an event that grabs a lot of attention and subsequent load
on networks.  However, existing systems send alerts quite often that are
localized and do not automatically correlate to network stress.  

A few years ago, I spoke with several local county emergency management
directors along the I-95 corridor in the North East U.S., and their
day-to-day concern isn't focused on terrorism or natural disasters, but
rather on hazardous materials on the highways.  Their interest is in
using mechanisms like inverse-911 and localizing the alerts.

As a different example, a friend of mine in DC received an alert on his
cell phone yesterday of brush fire warnings -- not that a brush fire
existed, but that the conditions were favorable for one to occur.  And
there certainly wasn't any corresponding stress on the cell network. 

> Therefore it is likely that 3GPP network operators have to shed
traffic when major alerts are being given. Certain traffic is tagged as
having special handling on the wireless part (emergency calls and
authority to citizen / authority). There are two aspects to this:
> 
> -	Can they identify non-essential traffic and discard a larger
proportion of this as opposed to essential traffic.
> In regard to the ATOCA proposal given above, neither of these are
dealt with in the charter.

My concern about the above position is that it places a requirement on
ATOCA to assume that something in layer 2, or some walled garden, exists
and is *deployed*.  I think all of us are in agreement with the point
that Dave Oran made a while back that its ideal to take advantage of
mechanisms that can optimize ATOCA solutions.  But we need to be careful
in assuming that the specification of other mechanisms does not
guarantee their deployment.

-ken