Subject: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Which devices and services should support emergency calls

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 14 Oct 2008 14:49:17 +0300

ED-1 A device or application SHOULD support emergency calling if a
   user could reasonably expect to be able to place a call for help with
   the device.

   SP-1 If a device or application expects to be able to place a call
   for help, the service provider that supports it MUST facilitate
   emergency calling.

   ED-2 Devices that create media sessions and exchange audio, video
   and/or text, and have the capability to establish sessions to a wide
   variety of addresses, and communicate over private IP networks or the
   Internet, SHOULD support emergency calls.

This is nice text and nice requirements. 
Still, I believe it would improve the credibility of the document if 
we acknowledge the fact that we aren't regulating the deployment. 

Maybe we can soften these requirements a bit and write something like. 

"
As end users are typically not aware of the details of the technology
they are using we below list the following high-level goals for the
implementation and deployment of emergency services functionality:

   ED-1 / SP-1 It is RECOMMENDED that a device or application supports
emergency calling if a
   user could reasonably expect to be able to place a call for help with
the device. 
   It is therefore RECOMMENDED that devices that create media sessions
and exchange 
   audio, video and/or text, and have the capability to establish
sessions to a wide
   variety of communication end points, and deliver data over private IP
networks or the
   Internet ,to support emergency calls.
"

The same is true for requirements listed below. In the past I suggested
to soften them a bit and to add references about current regulation. 
One, however, has to acknowledge that these numbers are not applicable
to all juristictions. 

6.2.2.  Access network "wire database" location information

 It is RECOMMENDED
   that interior location be provided when spaces exceed approximately
   650 square meters.

6.2.3.  End-system measured location information

   ED-16/INT-7 Devices MAY support end-system measured location.
   Uncertainty of less than 100 m with 95% confidence SHOULD be
   available for dispatch.

   ED-17/INT-8/AN-8 Devices that support endpoint measuring of location
   MUST have at least a coarse location capability (typically <1km
   accuracy when not location hiding) for routing of calls.  The
   location mechanism MAY be a service provided by the access network.

6.2.4.  Network-measured location information

   AN-9 Access networks MAY provide network-measured location
   determination.  Wireless access network which do not support network
   measured location MUST require that all devices connected to the
   network have end-system measured location.  Uncertainty of less than
   100 m with 95% confidence SHOULD be available for dispatch.

   AN-10 Access networks that provide network measured location MUST
   have at least a coarse location (typically <1km when not location
   hiding) capability at all times for routing of calls.

   AN-11 Access networks with range of <10 meters (e.g. personnal area
   networks such as Bluetooth MUST provide a location to mobile devices
   connected to them.  The location provided SHOULD be that of the
   access point location unless a more accurate mechanism is provided.

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

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 14 Oct 2008 09:00:42 -0400

I think your reasoning is faulty.  I think it IS important to describe when
-phonebcp is applicable.  We do that in many circumstances in the IETF. This
not a deployment requirement, it's an implementation requirement.  There are
no BCP police of course.

I also think it is essential to provide guidance (in a BCP, it's not a
protocol specification) on location uncertainty.  I can add words about
local regulation (perhaps, "some jurisdictions have regulations governing
this") if you wish.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Tuesday, October 14, 2008 7:49 AM
To: ECRIT
Subject: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Which devices and
services should support emergency calls

"

 It is RECOMMENDED

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 14 Oct 2008 16:12:28 +0300

This does not sound like text that hints to when Phone BCP is
applicable. 
Additionally, this "applicability" might change when regulators change
their mind 
There are many different policies in different countries. 

The good thing: Most of these location determination requirements is
outside the scope of our work anyway

>From: ext Brian Rosen [mailto:[email-masked]] 
>Sent: 14 October, 2008 16:01
>To: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'
>Subject: RE: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Which 
>devices and services should support emergency calls
>
>I think your reasoning is faulty.  I think it IS important to 
>describe when -phonebcp is applicable.  We do that in many 
>circumstances in the IETF. This not a deployment requirement, 
>it's an implementation requirement.  There are no BCP police of course.
>
>I also think it is essential to provide guidance (in a BCP, 
>it's not a protocol specification) on location uncertainty.  I 
>can add words about local regulation (perhaps, "some 
>jurisdictions have regulations governing
>this") if you wish.
>
>Brian
>
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo)
>Subject: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Which 
>devices and services should support emergency calls
>
>
>Still, I believe it would improve the credibility of the 
>document if we acknowledge the fact that we aren't regulating 
>the deployment. 
>
>As end users are typically not aware of the details of the 
>technology they are using we below list the following 
>high-level goals for the implementation and deployment of 
>emergency services functionality:
>
>   ED-1 / SP-1 It is RECOMMENDED that a device or application 
>supports emergency calling if a
>   user could reasonably expect to be able to place a call for 
>help with the device. 
>   It is therefore RECOMMENDED that devices that create media 
>sessions and exchange 
>   audio, video and/or text, and have the capability to 
>establish sessions to a wide
>   variety of communication end points, and deliver data over 
>private IP networks or the
>The same is true for requirements listed below. In the past I 
>suggested to soften them a bit and to add references about 
>current regulation. 
>One, however, has to acknowledge that these numbers are not 
>applicable to all juristictions. 
>
>