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

From: "Tschofenig, Hannes" <[email-masked]>
Date: Sun, 22 Jan 2006 18:46:55 +0100

hi raymond, 

thanks for reading our documents. 
please find some feedback inline:

________________________________

	Von: [email-masked] [mailto:[email-masked]] Im
Auftrag von Raymond Forbes
	Gesendet: Freitag, 20. Januar 2006 14:17
	An: [email-masked]
	Betreff: [Ecrit] Fw: [EMTEL] I-D
ACTION:draft-ietf-ecrit-requirements-02.txt

	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. 

[hannes] brian responded to you already about this aspect. we should
certainly make sure that the document is well-balanced in the
description of the architectural differences.
	
	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. 

[hannes] we had a long discussion about the term location validation and
i think that we use the terms differently. 
do you have a pointer to your definition? 

	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

[hannes] i have to read into the details of ETSI TS 102 164 but the
described scenario seems to be supported by the requirements draft. the
ability for an outbound proxy to perform location-based  routing is
clearly in scope of our work. the ability of using the sip identity work
is also allowed  and might be quite useful. 

	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. 

[hannes] here is the paragraph you are referring to: 
(
http://www.ietf.org/internet-drafts/draft-taylor-ecrit-security-threats-
01.txt) 

"
   3.  The timeliness, integrity and privacy of call signalling must be
       ensured as it passes between the emergency caller's device and
       the PSAP.

          NOTE - a confidentiality requirement applies to the
          association of a location with an emergency (e.g., within call
          signalling) or with an individual.  The location data per se
          is not confidential.
"

i would like to hear your opinion about the following security aspect.
we have two places where confidentiality protection 
is applicable: 

a) between the access network and the end host when location information
is provided by the access network to the end host (e.g., using dhcp as
described in http://www.ietf.org/rfc/rfc3825.txt and in
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-civil-08.txt
) 

b) as part of the emergency call itself. 

what problems do you see if confidentiality protection is not applied at
(a) and/or at (b) (with regard to the above-mentioned law)?

	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, ..." 

[hannes] maybe the term 'limited' should be read as 'specific'. the size
of the region, however, does not matter for the purpose of
location-based routing or for the mapping protocol. as such, it does not
matter.

      I could give a long discourse on these issues. 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. 

ciao
hannes

	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: "Raymond Forbes" <[email-masked]>
Date: Mon, 23 Jan 2006 15:28:05 +0000

Hannes,

See [RCF]: Below

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]>
22/01/2006 17:46
 
        To:     "Raymond Forbes" <[email-masked]>, 
<[email-masked]>
        cc: 
        Subject:        AW: [Ecrit] Fw: [EMTEL] I-D 
ACTION:draft-ietf-ecrit-requirements-02.txt

[RCF]: Read EU Commission Recommendation C(2003) 2657

                 ETSI TS 102 164 Assumes that he Routing toward the PSAP 
is

                 Real Geographic mapping in the TS 102 164 is calculated 
within

                 Firstly, Security Threats and Requirements for Emergency 
Calling

"

[RCF]: I can agree Option a) above, Option B is also true but is a human 
risk that people who know call content, including Location data may misuse 
their knowledge. I am not suggesting that there is a requirement to 
encrypt Emergency sessions, Or at least not from this EU data protection 
requirement.

[RCF]: there may be a general concern that communication across the public 
Internet is more easily eavesdropped (casually intercepted by unauthorised 
individuals) than communication across a private network (IP based or 
Circuit switched)

[RCF]: I think there is room for agreement the around the text; I think 
that I agree with Brian on this that the Region is Limited to be within a 
Specific Nation it may be a more locally or specifically defined region 
with a nation. It may be the Entire National Area (in the case of 
Luxembourg for example). 

Ciao
hannes

                 Regards,
 
                 Ray Forbes.
 
                 +44 24 7656 3106 phone
                 +44 24 7656 3816 fax.
                 This e-mail and any attachments are confidential.  If you 
are

 
                                 "Tschofenig, Hannes" 
<[email-masked]> 
                 Sent by: "emtel : Emtel" <[email-masked]> 

                 09/01/2006 22:47 

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

                 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).

 
                 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.

                 ciao
                 hannes

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

---

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

Hannes,

See [RCF]: Below

[RCF]: According to the EU Data protection and Privacy Directive EU 
Citizens have a right to not have their location traced, unless they chose 
to reveal their location to the respondent; with three Legal exceptions. 
An example of illicit tracking may be that robbers will know when to break 
into your house if they know that you are in another country. Another 
example is that local SPAM may be directed to your terminal as a 
nescience. 

Regards,

Ray Forbes.

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

"

[RCF]: According to the EU Data protection  and Privacy Directive EU 
Citizens have a right to not have their location traced, unless they chose 
to reveal their location to the respondent; with three Legal exceptions. 
An example of illicit tracking may be that robbers will know when to break 
into your house if they know that you are in another country. Another 
example is that local SPAM may be directed to your terminal as a 
nescience. 

[RCF]: There may be a general concern that communication across the public 
Internet is more easily eavesdropped (casually intercepted by unauthorised 
individuals) than communication across a private network (IP based or 
Circuit switched)

Ciao
hannes

                 Regards,
 
                 Ray Forbes.
 
                 +44 24 7656 3106 phone
                 +44 24 7656 3816 fax.

 
                                 "Tschofenig, Hannes" 

                 09/01/2006 22:47 

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

                 hi all,

 

 

                 ciao
                 hannes

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 26 Jan 2006 11:17:43 -0500

The note is certainly expendable, but I think the point is valid. Surely 
  the information: "Ottawa, Ontario" has no privacy implications, but 
the information: "Tom Taylor, Ottawa, Ontario" does. This is the 
distinction I was trying to make in the note.

> please find some feedback inline:
...>
>           signalling) or with an individual.  The location data per se
...