Subject: [Ecrit] Difference between ECRIT-Direct and Unauthenticated Draft

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 11 Nov 2009 16:03:09 +0900

ECRIT-Direct (see
http://tools.ietf.org/id/draft-winterbottom-ecrit-direct-01.txt) uses the
following procedure: 

* End host obtains location 
* Uses location with LoST to obtain a ESRP URI
* Registers with the ESRP for callback
* Let the ESRP verify location and let it do the routing decision

The unauthenticated draft (see
http://tools.ietf.org/id/draft-schulzrinne-ecrit-unauthenticated-access-06.t
xt) uses the following procedure: 

* End host MAY obtain location and MAY use LoST
* If it does not use LoST then it needs to obtain the ESRP URI using DHCP
* Let the ESRP obtain location (if not done already by the end host) and let
it do the routing decision
* No SIP registration procedure described. 

Which parts do people like / dislike? 

Ciao
Hannes

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 11 Nov 2009 00:57:58 -0800

I dislike the assumption that providers of unauthenticated access will do
anything to enable emergency calling.   We're talking about cafes and hotels
here, deploying equipment that displays many of the same issues that have
been found in home gateways (e.g. DNS proxies as documented in RFC 5625).
If they do try to "help" with emergency services, they probably will botch
it so badly that we'd wish they didn't try at all. 

Much of the equipment in question consists of vintage 2001 access points
(IEEE 802.11b, no a, b, g or n).  It could be a decade before the L2
emergency functionality discussed in today's meeting makes it into broad
use, if it ever does. 

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hannes Tschofenig
Sent: Tuesday, November 10, 2009 11:03 PM
To: [email-masked]
Subject: [Ecrit] Difference between ECRIT-Direct and Unauthenticated Draft

ECRIT-Direct (see
<http://tools.ietf.org/id/draft-winterbottom-ecrit-direct-01.txt>
http://tools.ietf.org/id/draft-winterbottom-ecrit-direct-01.txt) uses the
following procedure: 

The unauthenticated draft (see
<http://tools.ietf.org/id/draft-schulzrinne-ecrit-unauthenticated-access-06.
txt>
http://tools.ietf.org/id/draft-schulzrinne-ecrit-unauthenticated-access-06.t
xt) uses the following procedure: 

Ciao 
Hannes

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 11 Nov 2009 05:25:39 -0500

The "decade" part doesn't worry me - having specs allows planning for  
future networks (and writing the RFCs into RFPs), particularly in semi- 
public places, such as airports and downtown WiFi networks. In any  
event, it will likely be a decade before we convert PSTN PSAPs into IP  
PSAPs.

Henning

On Nov 11, 2009, at 3:57 AM, Bernard Aboba wrote:

> I dislike the assumption that providers of unauthenticated access  
> will do anything to enable emergency calling.   We’re talking about  
> cafes and hotels here, deploying equipment that displays many of the  
> same issues that have been found in home gateways (e.g. DNS proxies  
> as documented in RFC 5625).  If they do try to “help” with emergency  
> services, they probably will botch it so badly that we’d wish they  
> didn’t try at all.
>
> Much of the equipment in question consists of vintage 2001 access  
> points (IEEE 802.11b, no a, b, g or n).  It could be a decade before  
> the L2 emergency functionality discussed in today’s meeting makes it  
> into broad use, if it ever does.
>
> From: [email-masked] [mailto:[email-masked]] On  
> Behalf Of Hannes Tschofenig
> ECRIT-Direct (see http://tools.ietf.org/id/draft-winterbottom-ecrit-direct-01.txt 
> ) uses the following procedure:
>
> The unauthenticated draft (see http://tools.ietf.org/id/draft-schulzrinne-ecrit-unauthenticated-access-06.txt 
> ) uses the following procedure:
>
> * Let the ESRP obtain location (if not done already by the end host)  
> and let it do the routing decision
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

---

From: Brian Rosen <[email-masked]>
Date: Wed, 11 Nov 2009 10:47:40 -0500

Small note on this.  You say:

If it does not use LoST then it needs to obtain the ESRP URI using DHCP

I may have missed something, but I think the only circumstance you can get
an ESRP URI from DHCP is if you were unable to get to a LoST server.

It should not be the case that a device prefers the DHCP server¹s ESRP URI
to attempting to get to a LoST server.  It has to be a backup, and should
roughly never happen.

In the NENA work, we have an unwavering rule: ALL CALLS, without exception,
are routed by LoST.
I guess I¹ll qualify ³without exception² to say agree that if you tried to
get to a LoST server and failed, that falling back to DHCP for the ESRP URI
is okay.

We want LoST to be used because our experience is that although we have lots
of backups and mechanisms to control routing, that in disasters, often
things happen you did not anticipate, and you need to change the basic
routing information.  There are caches, and there could be reachability
issues (although we will try mightily to make sure that if there is a path
to the ESRP, there is a path to a LoST server), so I am comfortable with the
notion that if you can¹t get to a LoST server, use DHCP.

However, it should roughly never happen that you can¹t get to a LoST server.

Brian

On 11/11/09 2:03 AM, "Hannes Tschofenig" <[email-masked]> wrote:

> 
> 
> ECRIT-Direct (see
> http://tools.ietf.org/id/draft-winterbottom-ecrit-direct-01.txt
> <http://tools.ietf.org/id/draft-winterbottom-ecrit-direct-01.txt> ) uses the
> following procedure:
> 
> http://tools.ietf.org/id/draft-schulzrinne-ecrit-unauthenticated-access-06.txt
> <http://tools.ietf.org/id/draft-schulzrinne-ecrit-unauthenticated-access-06.tx
> t> ) uses the following procedure:
>