Subject: [Ecrit] Fw: [EMTEL] I-D ACTION:draft-ietf-ecrit-requirements-02.txt

From: "Raymond Forbes" <[email-masked]>
Date: Fri, 20 Jan 2006 13:17:19 +0000

Ecrit delegates,

I read your I-Ds with interest. Thank you.

I was slightly concerned that they seam to be very terminal centric in 
terms of Location provision.

The Discussions in ETSI and the ECC have focused on Validated Location, 
Validated by the network or Provided within the network by a secure 
database. What the Validation means to the EU is that the Location on 
authenticated before it reaches the Emergency Services usually by the CSP 
(communication Service Provider). Not that it is a valid address or 
location which is the ecrit definition of validation; both concepts have 
validity.

ETSI TS 102 164 Assumes that he Routing toward the PSAP is generated by 
the CLI; and in ETSI TISPAN NGN that the SIP routing toward the PSAP will 
be from Asserted Identity Information added of validated by the ESRP; This 
is an option allowed in Title: Requirements for Emergency Context 
Resolution with Internet Technologies Author(s): H. Schulzrinne, R. 
Marshall 
Filename: draft-ietf-ecrit-requirements-02.txt

Real Geographic mapping in the TS 102 164 is calculated within the PSAP by 
secure look up into the operators "directory" databases (by a Private 
service IP link). The EU has special provision to allow and require this 
with the EU data protection Directive. This is not mentioned, but does not 
need to be mentioned. It is almost the same as the case (8), acquisition 
of Location Information by a Call Routing Entity in Title: Security 
Threats and Requirements for Emergency Calling Author(s): H. Schulzrinne, 
et al. Filename: draft-taylor-ecrit-security-threats-01.txt where in 
chapter 6.8 Requirements for Interface . 

Firstly, Security Threats and Requirements for Emergency Calling 
draft-taylor-ecrit-security-threats-01.txt on Page 6 point 3. The Note is 
not be true according to European Directive and Europe-wide laws. The EU 
data protection directive states that Location is Private data to the user 
that must be secured under the user's right to reveal, withstanding the 
three very clear legal exceptions: which are 1. National Security; 2. 
Criminal Activity and 3. making an Emergency call or Request to the 
Emergency services. These Authority must legally respect the rights of the 
User not to reveal the location to third parties and commercial 
organisations. I suggest that you delete the note. EU Directives and 
European-wide law covers at least 30 countries. Under EU Directives the 
User's Location is Private data that cannot be revealed except on the 
commercial request of the User for a Location based service or under one 
of the three provisions. The user's location falling inadvertently into 
the wrong hands is a security threat that you do not mention. This means 
that User's location cannot be held on a Publically accessible directory 
database.

Secondly, I have one question about the Requirements for Emergency Context 
Resolution with Internet Technologies Author(s): H. Schulzrinne, R. 
Marshall Filename: draft-ietf-ecrit-requirements-02.txt on Page 16 Chapter 
7 Mapping Protocol 1st Paragraph. The sentence states that the "PSAPS only 
serve a limited geographic region, ..." This in not True. It may be true 
in the US and Germany, but in many countries the PSAPs may server a wide 
area. The problem will be solved if the Words are changed to "PSAPS may 
only serve a limited geographic region, ..."

In Summary

"PSAP (Public Safety Answering Point): Physical location where emergency 
calls are received under the responsibility of a public authority.  (This 
terminology is used by both ETSI, in ETSI SR 002 180, and NENA.)" This 
definition from Title: Requirements for Emergency Context Resolution with 
Internet Technologies Author(s): H. Schulzrinne, R. Marshall Filename: 
draft-ietf-ecrit-requirements-02.txt is not correct the US people read 
ETSI documents though US Glasses. The PSAP in ETSI SR 002 180 is not the 
same as the PSAP in NENA, the ECC in SR 002 180 is the PSAP in NENA, as 
Marc Lisner and NENA are very aware. I'm not sure that this definition 
error affects the Internet draft very much. All I think these Internet 
drafts need to concern is the routing to a PASP function Outside the 
Telephone or IP network.

In ETSI the definition of PSAPs is split in into two functions, to cover 
different national situations, PSAP1 (or the PSAP) which is the first 
stage access point to the Emergency services This is not mentioned in the 
I-D. Secondly the PSAP2 (or ECC Emergency Control Centre) these are 
geographically located. This is the US PSAP and the PSAP mentioned in your 
document. In the UK this is EOAC, in New Zealand ECC. In Germany these 
Functions are physically collocated. 

In Sweden and the UK there are a small number of PSAP1 or (PSAP 
functions). For Example C&W and T-Mobil route all UK Emergency calls to 
One PSAP. The Other UK Operators Route all UK Emergency calls to a small 
number of PSAPs (managed by BT). These may be geographically distributed 
in times of normal operation, however they may be load distributed in 
times of severe load or PSAP failure. All Emergency Calls in Sweden are 
routed to a Small number of PSAPS run by a National Authorised Company 
called "SOS-Alarm" These are not PSAPs in your document if I read your 
documents correctly. These PSAPs route the Emergency onto the most 
appropriate Control or Assistance Centre, Fire, Police, Ambulance, 
Coastguard, Cave/Mountain/Forest rescue, etc... One Control or assistance 
Centre may dispatch several Emergency responders to an incident.

I think the one word addition of "may" will address this sufficiently.

I have discussed this last point with Hannes see below:

[hannes] if we can deal with this issue by changing the sentence from

"PSAP (Public Safety Answering Point): Physical location where emergency
calls are received under the responsibility of a public authority."

to

""PSAP (Public Safety Answering Point): Physical location where
emergency calls may be received under the responsibility of a public
authority."

[rcf] agreed.

Regards,

Ray Forbes.

+44 24 7656 3106 phone
+44 24 7656 3816 fax.
+44 771 851 1361 Mobile/text
------------
This e-mail and any attachments are confidential.  If you are not the 
intended recipient, please notify us immediately by reply e-mail and then 
delete this message from your system. Do not copy this e-mail or any 
attachments, use the contents for any purpose, or disclose the contents to 
any other person: to do so could be a breach of confidence.

"Tschofenig, Hannes" <[email-masked]>
Sent by: "emtel : Emtel" <[email-masked]>
09/01/2006 22:47
Please respond to "Tschofenig, Hannes"
 
        To:     [email-masked]
        cc: 
        Subject:        [EMTEL] I-D 
ACTION:draft-ietf-ecrit-requirements-02.txt

hi all,

a new version of our requirements document is available. please send
review comments to the mailing list (see
http://www.ietf.org/html.charters/ecrit-charter.html).

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

Title           : Requirements for Emergency Context Resolution
with Internet Technologies
Author(s)       : H. Schulzrinne, R. Marshall
Filename        : draft-ietf-ecrit-requirements-02.txt
Pages           : 27
Date            : 2006-1-3

This document enumerates requirements for emergency calls placed by
the public using voice-over-IP (VoIP) and general Internet multimedia
systems, where Internet protocols are used end-to-end.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-02.txt

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

ciao
hannes

-------------------------------------------------------------------
Mail archive for EMTEL can be browsed at the following url:
http://list.etsi.org/EMTEL.html
-------------------------------------------------------------------

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

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 20 Jan 2006 11:36:28 -0500

Ray

We focus on being terminal centric because in many cases the access network
provider, which is the only carrier that knows where the terminal is, is not
the CSP.  The CSP may be in a different country and not subject to laws
where the terminal is, even though it is providing telephony services to it.
The legal status is not the important part; it is the fact that the CSP
doesn’t know where the terminal is.  The terminal however, is being provided
packet service by the access network, and is the point where the subscriber
to the access network meets the subscriber to the CSP.  That is why we focus
on the terminal – because the access network can supply location to the
terminal, and the terminal can supply location to the CSP.  Attempting to
pass information between the access network and the CSP is fraught with
difficulty, the most severe of which is identifiers = how the access network
could identify the CSP subscriber.

We have some terminology issues, because we are using the term “Valid” to
mean that the location is one recognized by the public safety agencies as a
location they know how to send responders.  Validated thus means we have
taken steps to assure that the location is a valid one.  Protecting the
information from forgery or modification is a different issue which is also
important to us.

I have no problem removing the Note in the security threats document.

However, I do have a problem with removing the word “limited” in the
geographic coverage of a PSAP.  Even if one PSAP serves the entire country,
its service boundary is limited to that country.  So I think the requirement
is properly stated.  I would not oppose adding some clarification (“although
that region may be as large as an entire country”), but I don’t really think
it is needed.

Although I don’t have a big problem with the change to the PSAP definition,
I do wonder if we would be better off changing the definition to say that
the PSAP is where the call is first answered.

Brian

________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Raymond Forbes
Sent: Friday, January 20, 2006 8:17 AM
To: [email-masked]
Subject: [Ecrit] Fw: [EMTEL] I-D ACTION:draft-ietf-ecrit-requirements-02.txt

Ecrit delegates, 

I was slightly concerned that they seam to be very terminal centric in terms
of Location provision. 

The Discussions in ETSI and the ECC have focused on Validated Location,
Validated by the network or Provided within the network by a secure
database. What the Validation means to the EU is that the Location on
authenticated before it reaches the Emergency Services usually by the CSP
(communication Service Provider). Not that it is a valid address or location
which is the ecrit definition of validation; both concepts have validity. 

ETSI TS 102 164 Assumes that he Routing toward the PSAP is generated by the
CLI; and in ETSI TISPAN NGN that the SIP routing toward the PSAP will be
from Asserted Identity Information added of validated by the ESRP; This is
an option allowed in Title: Requirements for Emergency Context Resolution
with Internet Technologies Author(s): H. Schulzrinne, R. Marshall 
Filename: draft-ietf-ecrit-requirements-02.txt

Real Geographic mapping in the TS 102 164 is calculated within the PSAP by
secure look up into the operators "directory" databases (by a Private
service IP link). The EU has special provision to allow and require this
with the EU data protection Directive. This is not mentioned, but does not
need to be mentioned. It is almost the same as the case (8), acquisition of
Location Information by a Call Routing Entity in Title: Security Threats and
Requirements for Emergency Calling Author(s): H. Schulzrinne, et al.
Filename: draft-taylor-ecrit-security-threats-01.txt where in chapter 6.8
Requirements for Interface . 

Firstly, Security Threats and Requirements for Emergency Calling
draft-taylor-ecrit-security-threats-01.txt on Page 6 point 3. The Note is
not be true according to European Directive and Europe-wide laws. The EU
data protection directive states that Location is Private data to the user
that must be secured under the user's right to reveal, withstanding the
three very clear legal exceptions: which are 1. National Security; 2.
Criminal Activity and 3. making an Emergency call or Request to the
Emergency services. These Authority must legally respect the rights of the
User not to reveal the location to third parties and commercial
organisations. I suggest that you delete the note. EU Directives and
European-wide law covers at least 30 countries. Under EU Directives the
User's Location is Private data that cannot be revealed except on the
commercial request of the User for a Location based service or under one of
the three provisions. The user's location falling inadvertently into the
wrong hands is a security threat that you do not mention. This means that
User's location cannot be held on a Publically accessible directory
database. 

Secondly, I have one question about the Requirements for Emergency Context
Resolution with Internet Technologies Author(s): H. Schulzrinne, R. Marshall
Filename: draft-ietf-ecrit-requirements-02.txt on Page 16 Chapter 7 Mapping
Protocol 1st Paragraph. The sentence states that the "PSAPS only serve a
limited geographic region, ..." This in not True. It may be true in the US
and Germany, but in many countries the PSAPs may server a wide area. The
problem will be solved if the Words are changed to "PSAPS may only serve a
limited geographic region, ..." 

In Summary 

"PSAP (Public Safety Answering Point): Physical location where emergency
calls are received under the responsibility of a public authority.  (This
terminology is used by both ETSI, in ETSI SR 002 180, and NENA.)" This
definition from Title: Requirements for Emergency Context Resolution with
Internet Technologies Author(s): H. Schulzrinne, R. Marshall Filename:
draft-ietf-ecrit-requirements-02.txt is not correct the US people read ETSI
documents though US Glasses. The PSAP in ETSI SR 002 180 is not the same as
the PSAP in NENA, the ECC in SR 002 180 is the PSAP in NENA, as Marc Lisner
and NENA are very aware. I'm not sure that this definition error affects the
Internet draft very much. All I think these Internet drafts need to concern
is the routing to a PASP function Outside the Telephone or IP network. 

In ETSI the definition of PSAPs is split in into two functions, to cover
different national situations, PSAP1 (or the PSAP) which is the first stage
access point to the Emergency services This is not mentioned in the I-D.
Secondly the PSAP2 (or ECC Emergency Control Centre) these are
geographically located. This is the US PSAP and the PSAP mentioned in your
document. In the UK this is EOAC, in New Zealand ECC. In Germany these
Functions are physically collocated. 

In Sweden and the UK there are a small number of PSAP1 or (PSAP functions).
For Example C&W and T-Mobil route all UK Emergency calls to One PSAP. The
Other UK Operators Route all UK Emergency calls to a small number of PSAPs
(managed by BT). These may be geographically distributed in times of normal
operation, however they may be load distributed in times of severe load or
PSAP failure. All Emergency Calls in Sweden are routed to a Small number of
PSAPS run by a National Authorised Company called "SOS-Alarm" These are not
PSAPs in your document if I read your documents correctly. These PSAPs route
the Emergency onto the most appropriate Control or Assistance Centre, Fire,
Police, Ambulance, Coastguard, Cave/Mountain/Forest rescue, etc... One
Control or assistance Centre may dispatch several Emergency responders to an
incident. 

to

[rcf] agreed. 

Regards,

Ray Forbes.

+44 24 7656 3106 phone
+44 24 7656 3816 fax.

        To:        [email-masked] 
        cc:         
        Subject:        [EMTEL] I-D

hi all,

ciao
hannes

---

From: "Raymond Forbes" <[email-masked]>
Date: Mon, 23 Jan 2006 09:18:10 +0000

Brian,

I never proposed to remove the word "limited", clearly a PSAP (whatever 
definition we use) is national, I only proposed to add the word "may" as a 
PSAP may be national, not limited to a geographic region within a country.

I never proposed to change the definition of PSAP, just to understand that 
we read the words differently.

I do propose to delete the note, as you agree.

I am sure that we can find room for common agreement. On the two points 
that I propose

Regards,

Ray Forbes.

+44 24 7656 3106 phone
+44 24 7656 3816 fax.

"Brian Rosen" <[email-masked]>
20/01/2006 16:36
Please respond to br
 
        To:     "'Raymond Forbes'" <[email-masked]>, 
<[email-masked]>
        cc: 
        Subject:        RE: [Ecrit] Fw: [EMTEL] I-D 
ACTION:draft-ietf-ecrit-requirements-02.txt

Ray

We focus on being terminal centric because in many cases the access 
network
provider, which is the only carrier that knows where the terminal is, is 
not
the CSP.  The CSP may be in a different country and not subject to laws
where the terminal is, even though it is providing telephony services to 
it.
The legal status is not the important part; it is the fact that the CSP
doesn’t know where the terminal is.  The terminal however, is being 
provided
packet service by the access network, and is the point where the 
subscriber
to the access network meets the subscriber to the CSP.  That is why we 
focus
on the terminal – because the access network can supply location to the
terminal, and the terminal can supply location to the CSP.  Attempting to
pass information between the access network and the CSP is fraught with
difficulty, the most severe of which is identifiers = how the access 
network
could identify the CSP subscriber.

We have some terminology issues, because we are using the term “Valid” to
mean that the location is one recognized by the public safety agencies as 
a
location they know how to send responders.  Validated thus means we have
taken steps to assure that the location is a valid one.  Protecting the
information from forgery or modification is a different issue which is 
also
important to us.

However, I do have a problem with removing the word “limited” in the
geographic coverage of a PSAP.  Even if one PSAP serves the entire 
country,
its service boundary is limited to that country.  So I think the 
requirement
is properly stated.  I would not oppose adding some clarification 
(“although
that region may be as large as an entire country”), but I don’t really 
think
it is needed.

Although I don’t have a big problem with the change to the PSAP 
definition,
I do wonder if we would be better off changing the definition to say that
the PSAP is where the call is first answered.

Brian

Subject: [Ecrit] Fw: [EMTEL] I-D 

Ecrit delegates, 

terms
of Location provision. 

location

the

of
Location Information by a Call Routing Entity in Title: Security Threats 
and

of

Filename: draft-ietf-ecrit-requirements-02.txt on Page 16 Chapter 7 
Mapping

In Summary 

"PSAP (Public Safety Answering Point): Physical location where emergency
calls are received under the responsibility of a public authority.  (This
terminology is used by both ETSI, in ETSI SR 002 180, and NENA.)" This
definition from Title: Requirements for Emergency Context Resolution with
Internet Technologies Author(s): H. Schulzrinne, R. Marshall Filename:
draft-ietf-ecrit-requirements-02.txt is not correct the US people read 
ETSI
documents though US Glasses. The PSAP in ETSI SR 002 180 is not the same 
as
the PSAP in NENA, the ECC in SR 002 180 is the PSAP in NENA, as Marc 
Lisner
and NENA are very aware. I'm not sure that this definition error affects 
the
Internet draft very much. All I think these Internet drafts need to 
concern
is the routing to a PASP function Outside the Telephone or IP network. 

stage

In Sweden and the UK there are a small number of PSAP1 or (PSAP 
functions).
For Example C&W and T-Mobil route all UK Emergency calls to One PSAP. The
Other UK Operators Route all UK Emergency calls to a small number of PSAPs
(managed by BT). These may be geographically distributed in times of 
normal
operation, however they may be load distributed in times of severe load or
PSAP failure. All Emergency Calls in Sweden are routed to a Small number 
of
PSAPS run by a National Authorised Company called "SOS-Alarm" These are 
not
PSAPs in your document if I read your documents correctly. These PSAPs 
route
the Emergency onto the most appropriate Control or Assistance Centre, 
Fire,
Police, Ambulance, Coastguard, Cave/Mountain/Forest rescue, etc... One
Control or assistance Centre may dispatch several Emergency responders to 
an
incident. 

to

[rcf] agreed. 

Regards,

Ray Forbes.

+44 24 7656 3106 phone
+44 24 7656 3816 fax.

        To:        [email-masked] 
        cc:         
        Subject:        [EMTEL] I-D

hi all,

ciao
hannes