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

From: [email-masked]
Date: Tue, 03 Jan 2006 15:50:01 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF.

	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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ecrit-requirements-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ecrit-requirements-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Tue, 24 Jan 2006 13:14:49 +0100

hi raymond, 
 
thanks for the pointer to 'EU Commission Recommendation C(2003) 2657'.
 
with regard to the security threats: i think we commented the protential
risk regarding the call content. 
to address this threat encryption might be a reasonable approach but
certainly not for free (with regard to the key management). it is
interesting to know that there is no requirement from the EU data
protection regulartion. 
 
with the next draft update we will try to clarify the text about psap
serving a limited area. 
 
ciao
hannes

________________________________

	Von: Raymond Forbes [mailto:[email-masked]] 
	Gesendet: Montag, 23. Januar 2006 16:28
	An: Tschofenig, Hannes
	Cc: [email-masked]
	Betreff: Re: AW: [Ecrit] Fw: [EMTEL] I-D
ACTION:draft-ietf-ecrit-requirements-02.txt

	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

	[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? 
	
	[RCF]: Read EU Commission Recommendation C(2003) 2657
	
	                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)?
	
	[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) 
	
	                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. 
	
	[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.
	                +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.

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

	                ciao
	                hannes

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

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