Subject: [Ecrit] [Fwd: Authority-to-Citizen Communication Draft Review]

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 05 Jul 2007 22:53:52 +0200

FYI, a quite detailed review by Leopold Murhammer (active ETSI EMTEL 
participant) of

http://www.ietf.org/internet-drafts/draft-norreys-ecrit-authority2individuals-requirements-00.txt

-------- Original Message --------
Subject:     Authority-to-Citizen Communication Draft Review
Date:     Wed, 4 Jul 2007 21:45:12 +0200
From:     Murhammer, Leopold <[email-masked]>
To:     Hannes Tschofenig <[email-masked]>

Hello Hannes,

I read the draft and I have a couple of comments:

1) The requirements here are not requirements of public authorities.

2) In the introduction SMS is mentioned. ETSI TR 102 444 makes clear 
that SMS is not a technology which shall used for warning the public.

3) In the introduction and later on in the text there is the option, 
that specific individuals or groups of individuals shall receive the 
message. The "legal" requirements up to now only have a geographic area 
where all people shall receive the message (not specific persons 
independent of their location). Where does this requirement come from?

4) The introduction also describes that gatewaying the message to 
traditional systems (e.g. PSTN) is needed. Where does such a requirement 
come from? I'm not aware of any such request by EU or other country.

5) The introduction also says that the user subscribes to such a 
service. In the ETSI requirement document this is not an option. In the 
US the default is that the user gets the message. He can opt out but not 
for presidential alerts. When there is a need for subscription for this 
service than other warning services in parallel need to be provided 
whithout subscription to fullfil the legal requirements.

6) The use case in the introduction where parents receive warnings of 
schools or adults receive warning regarding affected elderly people is 
not related to the emergency area and possibly not related to messages 
from authorities. The feature is fine, but it is not "authority to 
individuals" communication as it is defined by ETSI and used also in 
ohter bodies. This can be any form of a "general notification service".

7) In chapter 2. 'Terminology' the "Warning Notification Provider" 
includes also public transportation agencies and private institutions. 
Until now this was restricted to (government) authorities. It should not 
be allowed that a "public warning system" is used by e.g. enterprises, 
hospitals or universities.

8) Req-5: Only specific geographic regions shall be used as target, not 
specific individuals or groups.

9) Req-8: A confirmation of a warning message does not make sense. 
Ususally the public warning system does not know who is in a given area. 
For a private notification service this might be useful.

10) Req-10: I prefer a re-wording. The protocol shall allow to send a 
message which might contain the text in different languages. The 
requirement shall not give the impression that the transport network 
will do any modification of the text provided by the message provider.

11) Req-12: The user will receive what the network will deliver! It is 
up to the message provider and the equipment of the user to convert the 
message content. For a PUBLIC WARNING SYSTEM the user shall not be able 
to select in which form he will get the warning message. This is not 
required - not from EU, not from ETSI, not from FCC or any other body in US.
For a private/commercial notification service where the user subscribes 
and have to pay this might be an option, but not for a service provided 
by the government.

12) Req-15: It is not a requirement on the network which details must be 
provided in the message. This requirement shall be deleted here.

13) Req-18: I prefer a re-wording. The warning message might contain a 
recommendation on the reaction of the device and the requirement can be 
that such a 'recommended behavior' must be transported in the message. 
It is up to national regulation if such a "override" of configurations 
is allowed or not.

14) Chapter 6: It is OK to mention the 2 documents. The - possible - 
misuse of them to start a private notification service shall be avoided.

15) The reference on 3GPP TR 22 968 might be a problem. This is a 
working document of 3GPP.

Summary:
It shall be clarified if this is for government use - public warning 
system by authorities
or if this is a general commercial notification service (which might 
also be used by authorities on request).

Best regards,
Leo

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 5 Jul 2007 18:07:50 -0400

Some comments inline.

On Jul 5, 2007, at 4:53 PM, Hannes Tschofenig wrote:

>
> FYI, a quite detailed review by Leopold Murhammer (active ETSI  
> EMTEL participant) of
>
> http://www.ietf.org/internet-drafts/draft-norreys-ecrit- 
> authority2individuals-requirements-00.txt
>
>

Right - they are protocol requirements and this should probably be  
amplified. Obviously, the IETF can't obligate public authorities to  
do anything.

> 2) In the introduction SMS is mentioned. ETSI TR 102 444 makes  
> clear that SMS is not a technology which shall used for warning the  
> public.
>

Should be cited. I have seen studies that propose the use of SMS as a  
delivery vehicle, so it would probably be a good idea to get more  
background on this, although this is somewhat tangential to the main  
thrust of the discussion, namely IP-based systems.

> 3) In the introduction and later on in the text there is the  
> option, that specific individuals or groups of individuals shall  
> receive the message. The "legal" requirements up to now only have a  
> geographic area where all people shall receive the message (not  
> specific persons independent of their location). Where does this  
> requirement come from?

We want to do things that go beyond the legal requirements in a  
particular jurisdiction. At least in the US, there are lots of  
systems for alerting public safety officials, for example, and it  
would be nice to be able to have technically similar solutions, even  
if they are operated as separate systems.

> traditional systems (e.g. PSTN) is needed. Where does such a  
> requirement come from? I'm not aware of any such request by EU or  
> other country.

This will have to happen; lots of voice-based alerting systems are  
hybrid PSTN-VoIP. These "reverse 911" systems have become very  
popular in the US, with multiple jurisdictions using them.

> service. In the ETSI requirement document this is not an option. In  
> the US the default is that the user gets the message. He can opt  
> out but not for presidential alerts. When there is a need for  
> subscription for this service than other warning services in  
> parallel need to be provided whithout subscription to fullfil the  
> legal requirements.

Again, this is a technical document, not a legal document. I don't  
know of any technical means to force a user in an IP network to  
receive a message they don't want to receive, i.e., didn't subscribe  
to. We mention multicast, that that also has an implicit subscription  
mechanism.

>
> 6) The use case in the introduction where parents receive warnings  
> of schools or adults receive warning regarding affected elderly  
> people is not related to the emergency area and possibly not  
> related to messages from authorities. The feature is fine, but it  
> is not "authority to individuals" communication as it is defined by  
> ETSI and used also in ohter bodies. This can be any form of a  
> "general notification service".

At least in the US, these are generally considered closely related.  
 From what I know, many "reverse 911" systems are used for both, as  
there's no way that a smaller community can afford two systems that  
essentially do the same thing. Maybe the ETSI definitions needs to be  
broadened to reflect systems that are already successfully deployed?

> includes also public transportation agencies and private  
> institutions. Until now this was restricted to (government)  
> authorities. It should not be allowed that a "public warning  
> system" is used by e.g. enterprises, hospitals or universities.

Again, we're talking about a technology. We should probably amplify  
this distinction between multiple services and possibly a single  
underlying technology. As you may or may not know, the public-private  
distinction in the US is less clear, as all larger universities,  
public or private, have their own police forces, with full police  
powers, not just rent-a-cops. Amtrak and the postal service has its  
own police force and they have many of the same powers as a local  
police department.

>
> 8) Req-5: Only specific geographic regions shall be used as target,  
> not specific individuals or groups.

Again, we're not trying to just echo ETSI requirements. The IETF is  
not a branch of the European Union or ETSI.

> Ususally the public warning system does not know who is in a given  
> area. For a private notification service this might be useful.

At best, this could be a confirmation of receipt. Many 'reverse 911'  
systems offer such a feature and call back until receipt has been  
confirmed.

>
> 10) Req-10: I prefer a re-wording. The protocol shall allow to send  
> a message which might contain the text in different languages. The  
> requirement shall not give the impression that the transport  
> network will do any modification of the text provided by the  
> message provider.

Good point.

>
> 11) Req-12: The user will receive what the network will deliver! It  
> is up to the message provider and the equipment of the user to  
> convert the message content. For a PUBLIC WARNING SYSTEM the user  
> shall not be able to select in which form he will get the warning  
> message. This is not required - not from EU, not from ETSI, not  
> from FCC or any other body in US.
> For a private/commercial notification service where the user  
> subscribes and have to pay this might be an option, but not for a  
> service provided by the government.
>
> 12) Req-15: It is not a requirement on the network which details  
> must be provided in the message. This requirement shall be deleted  
> here.

Again, this is a technology issue. I suspect that we should separate  
out transport and content (e.g., CAP), to avoid this discussion.  
Somebody needs to specify a uniform structured document format.

>
> 13) Req-18: I prefer a re-wording. The warning message might  
> contain a recommendation on the reaction of the device and the  
> requirement can be that such a 'recommended behavior' must be  
> transported in the message. It is up to national regulation if such  
> a "override" of configurations is allowed or not.
>
> 14) Chapter 6: It is OK to mention the 2 documents. The - possible  
> - misuse of them to start a private notification service shall be  
> avoided.
>
> It shall be clarified if this is for government use - public  
> warning system by authorities
> or if this is a general commercial notification service (which  
> might also be used by authorities on request).

Maybe this is an implicit understanding that should be called out; as  
a protocol standardization body, the protocol components would  
clearly be available to any entity that would find them useful.

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 05 Jul 2007 17:51:05 -0500

>thrust of the discussion, namely IP-based systems.

fair qualifier, but I don't think ETSI's spec is universal, so SMS 
can be mentioned as one possibility at least

>if they are operated as separate systems.

I agree that groups sharing a role or trait have the ability to 
receive messages that the general public may not.

>popular in the US, with multiple jurisdictions using them.

I think this is starting to point to the difference between "where 
did the written requirement from?" and "lets look at a given 
requirement, then let's look at how similar implementations are used"

>to.

This will be the case when broadcast TV delivered to the masses has 
IP as an optional transport.  The EAS, at least within the US, will 
have little humor in hearing that oh, the TV didn't subscribe to that 
alerting service so they didn't know about the tornado 
approaching.  Some mediums will have a mandatory delivery, but maybe 
not what we usually think of as a mobile IP device like a PDA or 
laptop or 3G-IP phone.

>We mention multicast, that that also has an implicit subscription
>mechanism.
>
>
>>

this application shouldn't be assumed, as the service 
Leopold  describes above is an entirely paid-for service anywhere 
near this metro area (Dallas/Fort Worth), and therefore likely not an 
A-to-C service.

>systems offer such a feature and call back until receipt has been

this won't scale when you get into city wide or region wide events

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 5 Jul 2007 20:00:51 -0400

> have little humor in hearing that oh, the TV didn't subscribe to  
> that alerting service so they didn't know about the tornado  
> approaching.  Some mediums will have a mandatory delivery, but  
> maybe not what we usually think of as a mobile IP device like a PDA  
> or laptop or 3G-IP phone.
>

I think we should distinguish between several facets of receiving data:

(1) network layer delivery to anybody within a certain access network  
(GSM notifications, IP-TV, L2/L3 multicast, etc.); here, where is no  
explicit subscription, but somebody has to keep track of where  
devices are or devices have to tell some entity where they are. This  
is a form of subscription, even it's if done once after the router is  
plugged in.

(2) explicit protocol mechanisms where an end device tells a server  
that they are in a specific geographic region

> this won't scale when you get into city wide or region wide events

Anything scales with enough (peer-to-peer...) servers :-)

Henning

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 05 Jul 2007 19:15:57 -0500

>that they are in a specific geographic region

I agree with both of the above

>Anything scales with enough (peer-to-peer...) servers :-)

yeah... until the eastern seaboard of the US gets a hurricane 
warning, and 100 million devices are supposed to reply within a 
timely fashion  ;-)

I think just getting all the enabled devices within a city the size 
of Houston or Miami to reply will overwhelm most systems within a 
country's jurisdiction.

I'm merely suggesting this not be a wish list item, and some 
feasibility analysis be done before the piece moves forward

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 5 Jul 2007 19:37:58 -0500

When I was talking to Marc Linsner in Prague, the topic of being able to
register for these kinds of warnings when you are not in the area was
also brought up.

For example if I am at the IETF meeting in Chicago, and there is a storm
at my home in Wollongong, then I might like to be able to find out.

I would like this kind of service considered also as it is not quite the
same as case 2 below.

Cheers
James

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Friday, 6 July 2007 10:01 AM
> To: James M. Polk
> Cc: ECRIT
> Subject: Re: [Ecrit] Re: [Fwd: Authority-to-Citizen Communication
Draft
> Review]

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 05 Jul 2007 20:23:12 -0500

I agree with James W.

(wondering how long he's staring at his screen in disbelief ;-)

This is a very useful function.

Likewise, for the ability to keep track of someone/where (remotely) 
that I (for example) have an interest in (perhaps where my daughter 
is vacationing - type of thing)

James