Subject: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09

From: John Lange <[email-masked]>
Date: Mon, 01 Jun 2009 14:25:11 -0500

On April 15 2009, the Canadian Radio and Telecommunications Commission
(CRTC), which is the Canadian equivalent of the FCC, issued "Telecom
Notice of Consultation CRTC 2009-194".

http://www.crtc.gc.ca/eng/archive/2009/2009-194.htm

Paragraph 17 asks; "Are there alternative solutions that would improve
on the current nomadic VoIP 9-1-1 service."

The proposed architecture was developed by Bell Canada based very
loosely on NENAi2 with extensive modifications. As it was developed by
the ILECs in 2006/2007, it does not employ the IETF standards.

I am working on a submission to this proceeding which advocates the
implementation of the standards developed by the IETF's ECRIT working
group and it's members. (As a side note, if there are any participants
on this list which are interested in helping with this effort, please do
contact me.)

After examining draft-ietf-ecrit-framework-09 and it's related RFCs and
RFC-drafts, I have some specific questions/concerns which I hope this
list can answer.

The Emergency Call Framework (ECF) as proposed :

- Location is cached at end-point during boot/location discovery but
there does not appear to be any mechanism whereby the end-point
announces the success of this process to the SIP Registrar.

If the device is able to determine it's location it should relay the
location information to the SIP registration server and the SIP
registrar should cache this information.

This allows the SIP Registrar and SIP proxy the ability to act
"on-behalf-of" end points that are not able to determine their location
either because they are not location capable, or because they are not
able to determine location from their access provider.

Furthermore, it removes the burden of "real-time" "on-behalf-of"
functionality from the rest of the network.

The ability of the registrar to query and cache location data for
endpoints as opposed to the requirement to perform location
determination in real-time, has a dramatic impact on the technical
requirements of the overall solution.

If location data must be queried in real-time during an actual emergency
event, the network components must be engineered to a much higher
standard. In some jurisdictions the mandated hardware and network
requirements will be impacted significantly. No less than redundant
five-nine hardware running on dedicated private networks will be
required resulting in higher costs.

I submit that a query-and-cache methodology is more in line with the
spirit of other IETF protocols, the DNS system being a prime example.

- Concerns with draft-ietf-geopriv-lis-discovery:

The focus of LIS discovery seems to be on local access network methods
such as DHCP and LLDP.

DHCP & LLDP are not good choices for LIS discovery because they are not
supported in the residential market. Residential firewall devices are
not likely to have DHCP/LLDP functionality and the likelihood that these
devices will be replaced or upgraded is small.

It would therefore seem that the emphasis should be on a LIS discovery
mechanism that does not rely on the local network such as STUN + DNS.

1) Device determines its IP address by querying the STUN server.
2) Device determines its domain name using reverse DNS.
3) Device does LIS discovery via DNS (SRV/NAPTR).

- draft-ietf-ecrit-phonebcp 6.3: "Proxies MAY provide location on behalf
of devices if: The proxy has a relationship with all access networks the
device could connect to".

This wording seems overly restrictive; in effect "all access networks
the device could connect to" amounts to every network on earth which
seems like an unreasonably high standard.

How about:

"Proxies MAY provide location on behalf of devices if: the device does
not provide it's own location and the proxy is able to determine
location on-behalf-of the device.

Any comments and/or questions would be welcome.

Regards,
-- 
John Lange
http://www.johnlange.ca

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 1 Jun 2009 17:09:10 -0400

At the time of the call, the device either does have its location, or it
doesn't.

If it does, then the SIP proxy can use it, if it needs to, because it's on
the signaling.
There isn't any point in caching it at the proxy, and it's a privacy issue
if it does.

The reason you want to get fresh location is that it's pretty darn hard to
know if a device is mobile and thus location at boot time is not necessarily
correct at run time.  If the device is fixed location, and the location at
boot is the same as location at call time, then if the location
infrastructure fails, the cached location is all you have, but it's correct.
That implies that the infrastructure doesn't absolutely need to be 5 nines.

"On behalf of" is needed when the device DOESN'T get it's location from its
access network.  I think you have a point on the language of the on behalf
of language in -phonebcp, but your suggestion is not good enough.  The
problem to be solved is one way or another we have to get location.  The
current wording is aimed at proxies who think they ought to do it always,
and the language says, fine, as long as you CAN do it always.  

Your language says "do it if you can" but that let's the proxy off the hook;
it has to work always.

I suppose we could craft something that is more like, if the proxy knows
that the device will be used on some networks that supply location to the
device, and in every other network it can supply location OBO, then it's
okay.

Brian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of John Lange
> Sent: Monday, June 01, 2009 3:25 PM
> To: ecrit
> Subject: [Ecrit] Emergency Call Framework for Canada; Questions on
> draft-ietf-ecrit-framework-09
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 01 Jun 2009 17:01:54 -0500

John

some comments in-line below

>announces the success of this process to the SIP Registrar.

This can be done with this specification:
http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-13.txt

>registrar should cache this information.

The registrar caching geolocation is not a protocol issue, it's a 
configuration issue (once it receives the location from the 
endpoint). Notice this does not have to be with the first REGISTER 
request (meaning with a subsequent one), and/or it could be with each 
REGISTER request.

>able to determine location from their access provider.

I'm missing what you mean by the starting "this" in the paragraph above?

If the UA has its location, nothing needs to act "on-behalf-of" (OBO) 
it when sending location in any SIP request.

>functionality from the rest of the network.

If endpoints have their location (your original premise), OBO is 
unnecessary -- which further reduces network complexity, no?

>requirements of the overall solution.

How is this better or easier or an optimization from the endpoint 
including its location in the SIP request in the first place?

>required resulting in higher costs.

again, all this goes away if the endpoint has its location prior to 
placing the emergency call, then including this location information 
if more current location information cannot be discovered easily. 
Remember, unless you believe that everything needs to be built for 
mobile endpoints (i.e., those that actually move from room to room 
and from city to city with many times within the same day), being IP 
based doesn't mean endpoints move much.  Further, given the fact that 
there are lower layer solutions already in place (802.11k and y and 
3GPP) -- the IETF doesn't need to solve everything moving as if it 
was never where it is before.  For example, my IP phones at home 
haven't moved all day (or all week, or all year, etc) -- therefore 
the location value they understand 1 minute ago, as well as a day 
ago, and a month ago haven't changed. This makes these locations 
valid for call routing and dispatch.

Mobile nodes that are 3GPP based have their own way of tracking 
location changes.

Mobile nodes that are 802.11 based will likely have a valid location 
for call routing at any time during the day, but dispatch could take 
a bit longer to determine. The good thing here is that most systems 
can determine location within 15 seconds for dispatch -- and I'd like 
to meet the dispatchers that can make it to their destination in time 
for that to be an issue  ;-)

>devices will be replaced or upgraded is small.

For LLDP, I fully agree with what you have above. I've had 4 ISPs 
over the last 10 years, and EACH of them have used DHCP, so I'm not 
sure where you get your data wrt DHCP not being supported in the 
residential market.

>mechanism that does not rely on the local network such as STUN + DNS.

How many vendors in the residential market do you know of that implement STUN?

It appears you keep getting back to a solution that requires an 
upgrade in the access networks or endpoints.

>location on-behalf-of the device.

How does anyone know if this location OBO by the proxy is good enough 
for dispatch?

I think (and this is just my opinion) that proxies in this situation 
will be just guessing where the endpoints are...

---

From: John Lange <[email-masked]>
Date: Tue, 02 Jun 2009 13:13:06 -0500

I covered a lot of ground in my last post and I can tell from the
responses that some of the points weren't clear.

I apologize so please let me clarify;

- I'm not disputing that having the endpoint do network discovery of
location is the best first choice.

What I'm saying is;

1) Endpoint location discovery via DHCP is not going to work for
residential so some other mechanism will need to be employed (and I
think it should be STUN + DNS).

2) The SIP Registrar needs to know if the end point has it's location so
that the SIP Registrar can do OBO and discover the Emergency Services
Routing Proxy (ESRP) URI _before_ an emergency call is placed.

3) allowing the OBO to happen before the call will dramatically reduce
the network infrastructure requirements and therefore the cost of
implementing the solution because real-time IP location determination
done to a standard good enough for emergency call routing (less than 3
seconds) requires a significantly more robust solution than a
query-cache methodology.

---

The bottom line here is that if the device doesn't know it's location
and the SIP registrar isn't aware that it needs to do OBO, then in all
likelihood the device can not place an emergency call to the correct
ESRP since querying location on-the-fly will be too slow to route the
call correctly.

That's it in a nutshell but I'm going to pull all the threads together
and reply with some more detail to some specific questions inline below:

> sure where you get your data wrt DHCP not being supported in the 

I'm talking about residential firewall/routers. Someone else on this
list pointed me to this:

"Location Information Server (LIS) Discovery From Behind Residential
Gateways"

http://tools.ietf.org/html/draft-thomson-geopriv-res-gw-lis-discovery-00

> How many vendors in the residential market do you know of that implement STUN?

STUN would be implemented by the VOIP provider and their devices would
be provisioned to query their own STUN servers. Many VOIP providers are
using STUN today and every recent VOIP device I've looked at recently
has an implementation of STUN so I submit that it is widely supported.

> upgrade in the access networks

Not at all. That is precisely what I'm trying to avoid.

> or endpoints.

An upgrade to endpoints so they can do location is inevitable but the
OBO functionality is there to cover-off those devices which can not be
upgraded.

On Mon, 2009-06-01 at 17:09 -0400, Brian Rosen wrote:
> There isn't any point in caching it at the proxy, and it's a privacy
> issue if it does.

You are correct that caching isn't required if the device knows it's
location _provided that_ the proxy is aware that the device already has
it's location.

However, as I stated above, if the devices doesn't know it's location
the registrar needs to know about it so it can do OBO. And if the
registrar is doing OBO then it needs to cache the result.

So my point would be, if you are going to allow the registrar to do OBO
and cache results then it might as well cache location for the other
devices as well so it can use that information as a backup just in case
the device looses its location or becomes unreachable for some reason
(for example, lets say the internet to the endpoint drops during a 911
call. If the proxy has the info cached it could answer OBO the device).

Furthermore, (*** this is a critical point ***) if the device does not
provide location and the OBO server is not able to determine location,
this could trigger some other action. This allows VOIP providers to
easily identify "dead spots" in the LIS/LOST (such as non-compliant
ISPs) and take corrective action (notify the regulator).

On the topic of privacy; real-time IP location determination is a
_MASSIVE_ privacy issue that will need to be addressed with public
policy, not an RFC.

Keep in mind that the VOIP provider already has sensitive personal
information for the user so suffice to say that as long as the
information is only accessible to authorized people, then exactly who
those authorized people are is something for the politicians to decide.

> and the language says, fine, as long as you CAN do it always.  

Actually, I think BCP would be: "Proxies MUST provide location on behalf
of devices ONLY if the device does not provide it's own location."

"If the device does not provide location and the proxy can't find
location OBO the device, then the call MUST be routed to a 3rd party
call centre for verbal location and routing."

Regards,
-- 
John Lange
http://www.johnlange.ca

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 2 Jun 2009 14:35:02 -0400

Why would the proxy really care to know if the device can get its own
location?  I would assume it would OBO as much as it could.  In general, OBO
isn't reliable unless there is a regulatory requirement to make
relationships between providers exist in every case.  You can't have
environments where it doesn't always work (unless you know for sure that the
access network provides location).

You're focused on fixed devices, which is okay, but what you are describing
won't (necessarily) work for mobile or nomadic devices.

We're also familiar with the no DHCP in DSL environments.  Although we
recognize that this is the case today, we understand that is not the case
tomorrow, and this whole document is aimed at new devices.   If the access
network is upgraded to handle location, it's likely to offer DHCP (and, BTW,
it doesn't have to use DHCP to give out IP addresses).

Brian

> Sent: Tuesday, June 02, 2009 2:13 PM
> To: ecrit
> Subject: Re: [Ecrit] Emergency Call Framework for Canada; Questions on

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 02 Jun 2009 13:42:19 -0500

>location is the best first choice.

this was not clear in your original post.

>Routing Proxy (ESRP) URI _before_ an emergency call is placed.

clearly a SIP server that doesn't receive location in a 911 call 
knows to include Ua location if it knows it. The issue is recognizing 
the call is 911 from the URI to know location needs to be looked for 
before transmitting the INVITE on.  The trick is recognizing the URI 
as that of a PSAP (without the sos urn, that is).

>seconds) requires a significantly more robust solution than a

OBO before the fact means the location information could be 
stale/old/wrong... this was the argument for using a URI instead of 
actual location. It seems we can't get away from this little detail.

---

From: "François D. Ménard" <[email-masked]>
Date: Tue, 2 Jun 2009 10:36:01 -0400

See www.brisenet.net for my proposed architecture.

We're currently costing the modification of ISC DHCPD to support  
Option 99 pass-through of PIDF-LO's  and my ATA vendor is costing the  
inclusion of DHCP Option 99 & SIP LOCATION CONVEYANCE in their end- 
points, for submission to the CRTC in August.

f.

On 1-Jun-09, at 6:01 PM, James M. Polk wrote:

> request (meaning with a subsequent one), and/or it could be with  
> each REGISTER request.
>
>
> If the UA has its location, nothing needs to act "on-behalf- 
> of" (OBO) it when sending location in any SIP request.
>
>
> based doesn't mean endpoints move much.  Further, given the fact  
> that there are lower layer solutions already in place (802.11k and y  
> and 3GPP) -- the IETF doesn't need to solve everything moving as if  
> it was never where it is before.  For example, my IP phones at home  
> can determine location within 15 seconds for dispatch -- and I'd  
> like to meet the dispatchers that can make it to their destination  
> in time for that to be an issue  ;-)
>
>
> How does anyone know if this location OBO by the proxy is good  
> enough for dispatch?
>

---

From: John Lange <[email-masked]>
Date: Tue, 02 Jun 2009 16:19:54 -0500

On Tue, 2009-06-02 at 14:35 -0400, Brian Rosen wrote:
> relationships between providers exist in every case.

Yes, the IP location determination infrastructure requires a
relationship between the VOIP Provider, the ESRP (PSAP), and the
ASP/ISP. I took this as being understood because it's mentioned in the
paragraph 2 of draft-ietf-ecrit-framework: "Supporting emergency calling
requires cooperation by a number of elements, their vendors and service
providers."

The requirement to have a relationship between the providers isn't a
significant obstacle. The regulator will say "you MUST implement this"
and it will happen. The goal is to have a standard that can be followed
so that when the mandate is imposed, the solution is known and hopefully
there are already vendors who support it.

>   You can't have environments where it doesn't always work

You can't? Well that makes some sense in the context of
draft-ietf-ecrit-framework. Since the Internet is an environment that
"doesn't always work", perhaps draft-ietf-ecrit-framework was not
intended for use there? It makes no specific mention of this but by
design it could only be deployed where the endpoint has a direct
relationship with a local network that knows about location. That pretty
much eliminates all residential and small/medium business.

> won't (necessarily) work for mobile or nomadic devices.

What I envision will work for fixed and nomadic devices that access the
internet through fixed access points that cover relatively small
geographical areas. In other words, residential and small/medium
businesses.

Large enterprises would implement their own solutions and that is where
the DHCP style solution described in the ecrit-framework makes the most
sense.

Mobile devices would also work depending on how they are accessing the
internet but I don't want to side-track on the discussion of cell phones
vs. mobile VOIP phones etc.

> tomorrow, and this whole document is aimed at new devices.

As I said, maybe I've misunderstood the purpose of this group. If
draft-ietf-ecrit-framework is just intended as "blue-sky" or use in the
enterprise then I apologize for hijacking this list with my concerns
over real-world implementation.

>  If the access network is upgraded to handle location, it's likely to
> offer DHCP

... and a DHCP solution won't work behind residential firewalls and
won't allow OBO functionality so it can't be implemented for the number
one place where governments are likely to mandate a solution;
nomadic/residential VOIP.

IMHO, if you don't have a solution for residential then it's all just
theory.

That is why I'm advocating a closer look at something like STUN + DNS
for LIS discovery. It will work, allows OBO and requires no new
hardware.

If the IETF publishes a standard then each jurisdiction can decide to
implement it or not.

Chances are good they will implement it because the advantage of
implementing an IETF standard over some other "home-brew" solution is
that your citizens can roam to other jurisdictions and vice-versa. Plus
the likelihood of endpoints supporting the IETF standard at a reasonable
cost is much higher than if vendors have to implement a unique solution
for every jurisdiction.

That is what standards are all about after all...

On the other hand, I doubt any solution will ever be universally
implemented but that's fine. As a VOIP provider I only have to meet the
regulatory requirements in my jurisdiction, not every place on earth.

Regards,
-- 
John Lange
http://www.johnlange.ca

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 2 Jun 2009 16:27:00 -0500

How will address the millions of already deployed terminals and routers?

-----Original Message-----
From: [email-masked] on behalf of "François D. Ménard"
Sent: Tue 6/2/2009 9:36 AM
To: James M. Polk
Cc: ecrit
Subject: Re: [Ecrit] Emergency Call Framework for Canada;Questions on  draft-ietf-ecrit-framework-09

f.

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: John Lange <[email-masked]>
Date: Tue, 02 Jun 2009 16:39:39 -0500

On Tue, 2009-06-02 at 13:42 -0500, James M. Polk wrote:

> knows to include Ua location if it knows it.

Under the proposed draft-ietf-ecrit-framework, the sip registrar will
never know the location of the end-point and certainly not in time to
route the call to the correct PSAP.

> actual location. It seems we can't get away from this little detail.

Yes, it "could be" but that is very unlikely. How often will a device
roam so far from the location it was at when it registered with the VOIP
provider that the cached location can't be used for routing to the
correct ESRP/PSAP? And don't forget that an updated location can still
be queried during the call to erase any doubt.

There will always be examples of where it won't work, wifi on trains and
plains is a good example so they'll have to implement their own location
or we'll have to live with it.

If we wait for a solution that solves every possible scenario then we'll
just have to invent new scenarios ;)

-- 
John Lange
http://www.johnlange.ca

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 2 Jun 2009 17:44:12 -0400

We're trying to define real world solutions.  We may fail, but we're trying.

OBO doesn't always work, because by the time a call gets to a VoIP provider,
it's IP address can be obscured by VPNs.  It doesn't work because the
regulator can't force connections between a service provider it doesn't have
jurisdiction over to an access network (which it probably always has
jurisdiction over, because it's always local).  The easy example is my
famous "Sierra Leone VoIP Services Pty" provider serving a customer at a
Starbucks in, say, Calgary.  You can scream all you want, but CRTC can't
tell SLVS to connect to Rogers Cable.

On the other hand, the device can get location from the hotspot in
Starbucks, who can pass it through SLVS on it's way to the Calgary PSAP.

OBO is usually aimed at transition: before we get the devices all upgraded,
what do we do.  In that environment, we may not be able to get location
every time, although I think the VPN problem is so prevalent that it's going
to fail too often.  I'm still in favor of trying to get OBO to work, for
transition only, and with the caveat that it may not always work.

DHCP works very well in residential VoIP.  The phone may have a NATed
address, but as long as the home router passes the location option, the
query to the provider will have the right thing to get the DHCP system to
return the location of the residence.  If you don't like DHCP, use HELD, but
you still have some remnants of the VPN problem.  Don't confuse DHCP for LIS
discovery with DHCP for location configuration.  Both work, but DHCP
discovery of a HELD server works.

I've stayed out of most of the LIS discovery discussions because I don't
seem to have much to offer.  I'll let others reply to STUN + Reverse lookup
+ SRV. It's been discussed many times.

Brian

> From: John Lange [mailto:[email-masked]]
> Sent: Tuesday, June 02, 2009 5:20 PM
> To: Brian Rosen
> Cc: 'ecrit'
> Subject: RE: [Ecrit] Emergency Call Framework for Canada; Questions on

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 2 Jun 2009 16:41:56 -0500

That is not entirely true.
It works for any device that is behind a residential gateway.
So, unless I am mistaken, your proposal will also require every single residential gateway to be updated AND, for all DSL that uses PPP as opposed to DHCP to be upgraded either to use DHCP or to support modifications so that a new options is available over PPP, and supported by the RG.

I think that this number is substantially more than the 400,000 devices you are talking about and a massive massive cost in infrastructure upgrade, substantially more that the $500m you are talking about.

Cheers
James

-----Original Message-----
From: "François D. Ménard" [mailto:[email-masked]]
Sent: Tue 6/2/2009 4:38 PM
To: Winterbottom, James
Cc: James M. Polk; ecrit
Subject: Re: [Ecrit] Emergency Call Framework for Canada;Questions on  draft-ietf-ecrit-framework-09
 
James,

The architecture that ILECs are proposing in Canada does not work for  
devices which are not on the public Internet.

It'll be cheaper to upgrade 400,000 ATAs in Canada than to spend 500M$  
on implementation of a non-ECRIT solution.

F.

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 02 Jun 2009 16:49:24 -0500

>for LIS discovery. It will work, allows OBO and requires no new

James -- upgrading residential gateways to support (DHCP) Option 99 
or 123 requires no new hardware either.... (last I checked)

James

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 02 Jun 2009 16:50:51 -0500

James W - I apologize (!!), this is a response to John, not your post 
(which is the next message)

---

From: "François D. Ménard" <[email-masked]>
Date: Tue, 2 Jun 2009 18:01:21 -0400

> discovery of a HELD server works.

I concur.

If you have a router which does not pass on DHCP Option 99, you can  
always initiate a PPPoE tunnel from your ATA and do a DHCP Option 99  
fetching through it.

There is nothing wrong with having multiple PPPoE sessions from your  
home to your ISP, and one dedicated to VoIP.

Furthermore, this will be an excellent mean to use PPPoE to prioritize  
the username/password for a VoIP PPPoE session over the username/ 
password for Internet access, for two sessions coming from the same  
home.

The ATAs we use here can be patched to support DHCP Option 99 fetching  
through a PPPoE session. All you need is to put a little Ethernet  
switch between your DSL modem / Cable Modem and your ATA and to allow  
for the possibility that both your ATA as well as your Router will  
launch a PPPoE tunnel to your ISP.

I'll send you a sticker you can can put on your router here... plug  
here and die - this box does not pass on location.

This architecture has the added bonus of accelerating the transition  
to IPv6.

For those concerned with that, our wholesale cable modem incumbent  
cable operator, permits up to 3 public IPs behind a single cable  
modem, and I use a switch behind my CM to assign a separate public IP  
for my VoIP PBX SIPtrunk client, from the public IP address of my  
router, which currently is too dumb to relay DHCP Option 99.

So all I need is to have the DHCP server programmed to send a PIDF-LO.

And for my SIP client to support SIP LOCATION CONVEYANCE.

And for it not to never send a BYE if I dial 9-1-1, even if I hang-up.

F.

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 2 Jun 2009 17:17:44 -0500

There was one very strong point made in i2 all along, and that is NO UPGRADES to residential equipment is required in order for it work. It may work better if upgrades are made, but they MUST NOT be required.

So, if I can use a device inside my home network and it can go out through my RG to the Internet and VSP to make an emergency call it has to work out of the box, as is, no matter when I bought it. I know some people don't like these requirements, but they are still requirements.

I will also point out that these are the requirements that are addressed in the LIS discovery through an RG draft that Martin T is authoring.

Cheers
James

-----Original Message-----
From: [email-masked] on behalf of James M. Polk
Sent: Tue 6/2/2009 4:49 PM
To: John Lange; Brian Rosen
Cc: 'ecrit'
Subject: Re: [Ecrit] Emergency Call Framework for Canada; Questions on  draft-ietf-ecrit-framework-09

James

---

From: "François D. Ménard" <[email-masked]>
Date: Tue, 2 Jun 2009 17:38:10 -0400

James,

F.

---

From: "François D. Ménard" <[email-masked]>
Date: Tue, 2 Jun 2009 17:50:37 -0400

> It works for any device that is behind a residential gateway.

Not if the key for emergency dispatch is only a public IP, which is  
what the ILECs are proposing.

Private IP = you use the legacy system and order T1s to all 9-1-1  
tandems.

> So, unless I am mistaken, your proposal will also require every  
> single residential gateway to be updated AND, for all DSL that uses  
> PPP as opposed to DHCP to be upgraded either to use DHCP or to  
> support modifications so that a new options is available over PPP,  
> and supported by the RG.

You can do a DHCP query across a PPPoE session to get an option 99  
PIDF-LO, atop an IP address that was already assigned via IPCP.

>
>
> I think that this number is substantially more than the 400,000  
> devices you are talking about

Nope. Canada = 400,000 nomadic VoIP subs.

> and a massive massive cost in infrastructure upgrade, substantially  
> more that the $500m you are talking about.
>

Infrastructure upgrades worth $500M are behind the ILEC proposals in  
Canada, and that will be a patch that will not even support location  
aware devices from the get go.

f.

---

From: "François D. Ménard" <[email-masked]>
Date: Tue, 2 Jun 2009 18:36:48 -0400

> _MASSIVE_ privacy issue that will need to be addressed with public

That's a good reason to keep the location in the end-point, where the  
end-point would only reveal it upon requesting S.O.S.

I find that OBO is a _MASSIVE_ violation of privacy.

> those authorized people are is something for the politicians to  

However, the VOIP provider if access independant (i.e. Vonage atop an  
ISP), has no idea of the location associated with the underlying  
circuit.

The question here is if VONAGE is to steer the call to the right PSAP,  
based upon which information will it be able do that ?

> of devices ONLY if the device does not provide it's own location."

That's a good statement, but it is not sufficiently precise.

The question is 'how can proxies (which are by definition stateless),  
inspect an S.O.S. call and try to look for the presence of a PIDF-LO  
by way of SIP LOCATION CONVEYANCE', and upon that not being there,  
decide to inject it.

This seems like a violation of the mother-rule-of-SIP, which is that  
proxies do not modify SIP message contents, which is where Lby? lies.

Some people are claiming that adding Location-by-reference does not  
violate the rule, however location-by-value would violate the rule.

What's the latest take on that?

> call centre for verbal location and routing."

What mechanism will a PROXY use to make this determination?

f.

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 02 Jun 2009 22:07:30 -0500

At 05:36 PM 6/2/2009, "François D. Ménard" wrote:

>>Actually, I think BCP would be: "Proxies MUST provide location on
>>behalf of devices ONLY if the device does not provide it's own location."
>

has anyone ever heard of a default route?

the call only has to be to _A_ PSAP -- 
preferrably in the same country (or 
state/province or county or city)... The call can 
be transferred from that PSAP to the appropriate 
one once the location of the caller is determined 
(when they tell the dispatcher). This transfer 
ought be nearly on speed-dial, considering how few PSAPs there are.

>The question is 'how can proxies (which are by definition stateless),

well, this statement is false. Proxies can merely 
choose to become transaction stateful (because 
the request and response go through the same 
proxies), and can inject a Record-Route into a 
SIP request to becomes dialog stateful. This 
means all subsequent requests go through this 
proxy also (all BYEs, REFERs, INFOs...)

>by way of SIP LOCATION CONVEYANCE',

well, perhaps all you need to look for is the 
presence of the Geolocation header, because that 
has to be present in order for there to be a 
Location URI or a PIDF-LO message body (i.e., 
this header's presence in the SIP request is a 
dead giveaway that location is not 
there).  Something can be done upon realizing that header is not present.

>and upon that not being there,
>decide to inject it.
>

possible correction -- proxies aren't to modify 
or delete message bodies, but they can certainly 
add or change the contents of any SIP header, 
though some aren't recommended to be changed 
(like Via, From or To, for example).

>violate the rule, however location-by-value would violate the rule.

so long as the SIP server is operating strictly 
as proxy, but many SIP servers don't limit 
themselves to only operating as a proxy -- many 
are B2BUAs and SBCs -- which by definition, *can* modify SIP message bodies.

>What's the latest take on that?

see above

>>call centre for verbal location and routing."

personally, I think OBO shouldn't be done, given 
how often I believe this will be incorrect 
location information, but I've been out-argued on 
this point. That said, routing to the 3rd party 
call center (as written above) would be my recommended 2nd step.

>What mechanism will a PROXY use to make this determination?

local configuration, clearly...

even though that won't taste too good to some. 
it's the way SIP generally operates.

---

From: John Lange <[email-masked]>
Date: Tue, 02 Jun 2009 22:22:01 -0500

> or 123 requires no new hardware either.... (last I checked)

James, you should check again. You need not look any further than your
own company. Ask around and see if Cisco will be providing new firmware
for _all_ of the devices it has ever made including devices from
companies it has purchased such as Linksys and Sipura.

Even if they did, what percentage of users would actually apply the
updates?

Any solution that requires the upgrading of residential gateways is not
feasible.

-- 
John Lange
http://www.johnlange.ca

---

From: John Lange <[email-masked]>
Date: Tue, 02 Jun 2009 22:30:10 -0500

On Tue, 2009-06-02 at 17:17 -0500, Winterbottom, James wrote:
> There was one very strong point made in i2 all along, and that is NO
> UPGRADES to residential equipment is required in order for it work. It
> may work better if upgrades are made, but they MUST NOT be required.

I agree completely (even though i2 is not my favourite document). 

Upgrades to RGs MUST NOT be required.

Upgrades to VOIP endpoints is much more feasible since most VOIP
endpoints are already provisioned remotely and receive periodic updates
from their VOIP providers but this MUST NOT be a requirement.

And that is why OBO MUST be a requirement.

> I will also point out that these are the requirements that are
> addressed in the LIS discovery through an RG draft that Martin T is
> authoring.

An excellent document that still needs some work and should... ahem, I
mean MUST ;) be referenced the ecrit-framework and BCP.

-- 
John Lange
http://www.johnlange.ca

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 02 Jun 2009 22:31:30 -0500

>Any solution that requires the upgrading of residential gateways is not

I'm not questioning the idea of the upgrade (in fact, I'm convinced 
it will be required in most instances), just that HW would be 
required. That's all this comment was about...

The question about the likelihood of the upgrade is a very different 
question, which is in and of itself an *interesting* question.

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 3 Jun 2009 07:09:33 +0200

> think it should be STUN + DNS).

I think people should be careful with statements of the form "will not  
work for X". Much better to say "will not work in all situations" or  
"will not work if Y". Even "will not work for MANY deployments" is  
dangerous as I claim noone actually know what "many" implies in  
statements like that.

I know network deployments where location by DHCP will work extremely  
well.

I know location by DHCP will not work in some cases, and work in some.

    Patrik

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 3 Jun 2009 02:26:26 -0700

John Lange said:

"1) Device determines its IP address by querying the STUN server 
2) Device determines its domain name using reverse DNS.
3) Device does LIS discovery via DNS (SRV/NAPTR)."

There are some situations in which steps 1 and 2 will not work reliably. 

With IPv4 exhaustion looming, it is likely that service providers will implement some form of IPv4 address sharing.  

In an access network that has deployed a Carrier Grade NAT (CGN), step 1 will produce an IP address on the CGN,
not the outer address of the residential CPE.  This could then result in discovery of a LIS on the wrong side
of the CGN, which would find itself unable to provide location since the source IP address will have been shared 
by too many users. 

An alternative approach to obtaining a suitable domain for step 3 would be to use the Domain Name Option (RFC 2132) 
which is commonly supported today.  The Searchlist Option (RFC 3397) is another possibility but it is not as 
widely supported.  This could produce a suitable domain without requiring the implementation of STUN or population
of PTR RRs. 

 EMAILING FOR THE LESSER EVIL
Join me

---

From: [email-masked]
Date: Wed, 3 Jun 2009 10:58:54 +0100

> 
> With IPv4 exhaustion looming, it is likely that service providers 
> will implement some form of IPv4 address sharing. 
> 
> In an access network that has deployed a Carrier Grade NAT (CGN), 
> step 1 will produce an IP address on the CGN, not the outer address
> of the residential CPE.  This could then result in discovery of a LIS
> on the wrong side of the CGN, which would find itself unable to provide
> location since the source IP address will have been shared by too many
> users. 

This shouldn't be a problem.

If the ISP is running a CGN such that the end user cannot find a 
non-RFC1918 public IP address, then all the ISP has to do (per 
draft-thomson-geopriv-res-gw-lis-discovery-01) is provision the 
appropriate NAPTR records in "in-addr.arpa" for whatever private IP space 
they are using. 

Also, draft-winterbottom-geopriv-held-identity-extensions has recently 
been updated to allow queries to be based on the particular IP port 
currently in use.

In other words, if the end user's STUN query returns the CGN's IP address, 
then the LIS that knows about that CGN IP address should be able to 
interrogate the NAT mappings and determine which customer's location is 
being requested.

> An alternative approach to obtaining a suitable domain for step 3 
> would be to use the Domain Name Option (RFC 2132) which is commonly
> supported today.  The Searchlist Option (RFC 3397) is another
> possibility but it is not as widely supported.  This could produce
> a suitable domain without requiring the implementation of STUN or 
population
> of PTR RRs. 

I've argued very strongly on the GeoPriv list against either of those 
options being used.

Using either implies a linkage between the access network and domain names 
which is simply not guaranteed to exist.  IME, neither are well supported 
by residential CPE anyway.

Ray

-- 
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 3 Jun 2009 03:25:13 -0700

> appropriate NAPTR records in "in-addr.arpa" for whatever private IP space 

Not sure why NATPR RRs would be put in in-addr.arpa.  If the ISP is
populating RRs in "in-addr.arpa",  couldn't they populate PTR RRs
pointing to a domain within which the SRV/NATPR RRs could be found? 

> been updated to allow queries to be based on the particular IP port 

Good idea. 

> interrogate the NAT mappings and determine which customer's location is 

Is it really a good idea for a LIS to query NAT mappings from a CGN??
I recall a router implementation where there was a facility for 
retrieving portions of the forwarding table on a backbone router. 
This didn't work well since the queries chewed up cycles that were needed for
processing of control plane traffic.

---

From: Marc Linsner <[email-masked]>
Date: Wed, 03 Jun 2009 08:58:10 -0400

Ray,

> appropriate NAPTR records in "in-addr.arpa" for whatever private IP space

Isn't this making assumptions about which DNS resolver the end host is
using?  I don't believe we can assume the end host is using the Access
Provider's resolver.  A common occurrence of bringing up a VPN split-tunnel
can change the resolver a host utilizes, or for some, static resolver
assignments are made.

What am I missing?

-Marc-

---

From: "Stark, Barbara" <[email-masked]>
Date: Wed, 3 Jun 2009 09:28:13 -0400

Many retail home routers have been end-of-lifed by their manufacturers.
It is highly unrealistic to expect upgrades to be made available for
these. It is, likewise, unrealistic to expect the average consumer to
know that an upgrade exists (when it does exist) or to know to apply
such an upgrade.

Discovery of the WAN IP address through a mechanism such as STUN, and
then doing a reverse DNS look-up for a LIS server does indeed remain the
best option during the many-year-long transition time frame, for the
case where an end device isn't able to get location info or LIS info via
DHCP.

But I'm fine for the IETF not to document or provide a BCP for that. I
can go elsewhere for refining best practices. Which is why I don't
really care to argue this question anymore. I mainly need the IETF to
provide the basic standards, and the basic framework. Which I think
they're doing a good job at getting around to. If those documents could
just make that final leap to RFC status ...
Barbara

> Of James M. Polk
> Sent: Tuesday, June 02, 2009 5:49 PM

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622

---

From: [email-masked]
Date: Wed, 3 Jun 2009 14:43:17 +0100

> pointing to a domain within which the SRV/NATPR RRs could be found? 

They could, but in many cases the choice of the PTR RRs is made by the 
customer.

Using a NAPTR RR allows for separation of the domain name (as used by the 
customer) from the infrastructure (as provided by the ISP).

> > been updated to allow queries to be based on the particular IP port 

Thanks :)
 
> processing of control plane traffic. 

It's probably no worse an idea than CGN itself ;-)

kind regards,

Ray

---

From: "Stark, Barbara" <[email-masked]>
Date: Wed, 3 Jun 2009 09:43:18 -0400

Most service providers do offer plans with multiple addresses, but the vast majority of people do not subscribe to these plans. Your service provider sounds unique in the world of service providers, to give away 3 addresses to all subscribers. Most service providers who utilize PPPoE limit (through RADIUS) the number of concurrent PPPoE sessions that are allowed to 1. The termination points for PPPoE sessions in the network tend to be capacity limited by number of concurrent sessions, so it would be a major cost to increase the number of supported PPPoE sessions per customer, in a world where those customers were actually expected to use those multiple sessions. Also, each PPPoE session requires an IP address. Today that's IPv4. As we all know, we're rapidly running out of those addresses, and doubling the number of IPv4 addresses used by all customer would be a Very Bad Thing. 

Oh, and help desk costs of helping people to enter PPPoE login password in an additional device are significant. Forgotten login/password info have historically been one of the largest help desk costs that service providers experience. Again, your proposal is a costly proposal.

People who can do the things that you have done in your home network are few and far between. You are not average. We must have solutions that work for the average person, and not just the special elite people who actually understand this stuff.
Barbara

> Of "François D. Ménard"
> Sent: Tuesday, June 02, 2009 6:01 PM
> To: Brian Rosen
> Cc: ecrit

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625

---

From: [email-masked]
Date: Wed, 3 Jun 2009 14:46:22 +0100

> Provider's resolver. 

Good point, that may need some more thought.

In the generic case it's fine, because a public IP would be mapped in the 
public in-addr.arpa zone.

> A common occurrence of bringing up a VPN split-tunnel

As with other LIS discovery processes, this needs doing before any VPNs 
are established.

Ray

---

From: "Stark, Barbara" <[email-masked]>
Date: Wed, 3 Jun 2009 14:05:44 -0400

Going back to respond to John's original email...

John,
2. I agree with your LIS discovery issues regarding legacy home routers
with NAT. However, solving this does not require new protocols;
therefore, I've decided to not object to the current lis-discovery
document proceeding as it is. The DHCP options for LIS discovery are
needed for the long-term. Getting end VoIP devices to use STUN and do
reverse DNS can be handled separately, either with the IETF (e.g.,
Martin's res-gw-lis-discovery document) or external to the IETF.

3. As for recommended proxy on-behalf-of behavior, the current wording
doesn't bother me, although your alternate wording is also fine. It
doesn't bother me, because it doesn't change the requirements on the end
devices, access nodes, or access networks. Those are the things that
have to be very predictable in their behavior, if this architecture is
to ultimately succeed. If I were to feel that a proxy under my control
should try to get locations, and if such behavior were consistent with
the regulatory environment my proxy operated in, then I would have it do
just that, no matter how phonebcp is worded.

1. Your suggestion that the device tell its location to its SIP
registrar causes me some difficulty. In this case, the device already
has its location, so it should also have its PSAP route info. If the
device has location and emergency routing info, then the SIP registrar
and VSP should just be able to dumbly route. Even if they don't
recognize it as an emergency call, they should still be able to route.
If the device can't update its location, it will use its locally cached
information -- so having the VSP cache this exact same location info
would be redundant. Having VSPs that operate inside a country do certain
things to ease the transition, like querying location on behalf of
location-less devices, is fine, if that's what's desired. Building
dependencies on VSP behavior is bad. You don't know where in the world
the VSP will be. You don't even know if the "VSP" is nothing more than
an Asterix PBX in someone's basement. And there's no need for the
emergency call to fail, just because the VSP is foreign. That's part of
the beauty of the current architecture -- it's independent of VSP
nationality. The device, the access network, and the desired PSAP are
usually (not always, in border scenarios) inside the same country. The
VSP (registrar) is anywhere.
Barbara

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623

---

From: John Lange <[email-masked]>
Date: Wed, 03 Jun 2009 13:52:40 -0500

> We're trying to define real world solutions.  We may fail, but we're trying.

The work ecrit has done on this issue is exemplary. Much better than
previous attempts (i2).

However, as James Winterbottom pointed out, "There was one very strong
point made in i2 all along, and that is NO UPGRADES to residential
equipment is required in order for it work."

So i2 might be dead, but the various groups that represent PSAPs in the
US and Canada have made this a clear requirement. So, even if you
completely disagree with the need for equipment replacement, the
parameters have already been set.

> jurisdiction over, because it's always local).

>   The easy example is my

Your example clearly identifies the divide between a
technical+regulatory solution and a strictly technical one.

In the above example, technically it may not work but from a regulatory
perspective it does work. It works because the CRTC doesn't care if the
SLVS user can reach 911 from his laptop in a Calgary Starbucks. SLVS is
not regulated by the CRTC and therefore users of SLVS are not required
to have access to 911.

To be clear, the CRTC only requires that customers of Canadian VOIP
providers have access to 911 while in Canada.

Conversely, Canadians using their devices while outside of Canada _MUST
NOT_ have access to a Canadian PSAP (i.e. create nuisance calls). It's
the opposite of what some might think.

If the SLVS regulator wants to dictate that SLVS customers have access
to 911 (or whatever) everyplace on earth, then I say good luck with
that.

> Starbucks, who can pass it through SLVS on it's way to the Calgary PSAP.

On the one hand you've argued that anything based on a public IP won't
work because the CRTC doesn't have jurisdiction over SLVS, but on the
other hand you've ignored that very same regulatory restriction by
assuming that SLVS will have a relationship with a Calgary PSAP.

This is not the case. I can positively assure you that the Calgary PSAP
will not accept calls from any VOIP provider that it does not have a
prior relationship with and for the foreseeable future that means VOIP
providers inside Canada.

PSAPs are _very_ sensitive to nuisance calls so the concept that the
PSAP/ESRP will be open to any IP address in the entire world... no.

And as you already pointed out, there can't be a regulatory requirement
for this because the CRTC has no jurisdiction to require a relationship
with SLVS. (as a side note; the CRTC actually has no jurisdiction over
PSAPs what-so-ever but PSAPs will likely go along with the CRTC
decision).

So, if I understand the position of this group, solutions that require
relationships between VOIP providers, ISPs, and PSAPs are not considered
viable because they require regulatory authority over all three parties
everyplace on earth which is impossible.

But the reality is, regulators only care about their own jurisdictions
and they DO have authority to order relationships between all three
parties.

>From the standpoint of the VOIP provider, the PSAP, the ISP and the
regulator, the fact that a given solution might not work if one of the
three parties is outside the jurisdiction of the regulator is
irrelevant.

> transition only, and with the caveat that it may not always work.

That is a very reasonable position and one I fully support. OBO must be
implemented even though it won't work 100% of the time.

> address, but as long as the home router passes the location option,

Ok, full stop here... A couple of messages on this list have made this
point without providing any technical explanation.

What I don't understand is how this will be done without upgrading or
replacing residential firewalls?

It's like saying "it's easy to get to the moon provided we shut off the
earth's gravity."

> If you don't like DHCP, use HELD,

I'm advocating using HELD, but first you have to discover the LIS so you
can do the HELD query. That's why we need STUN + DNS for LIS discovery
on endpoints and DNS LIS discovery for OBO.

>  but you still have some remnants of the VPN problem.

Again, there is a split here between the regulatory and technical. The
vast majority of users doing VOIP over VPN are "dialing-in" to corporate
VOIP servers. There is no regulatory requirement to provide location for
corporate users. It may well become a regulatory requirement in the
future but nobody has even raised it yet. Given that we're still
struggling with residential, it's safe to say that any such requirement
is several years off so holding up everything on that requirement isn't
necessary.

That being said, the technical solution is for the provider (in this
case the corporation) to provide the LIS and by forming a relationship
between the VPN tunnel and the enterprise LIS so that the LIS knows to
query an external LIS for location based on the public IP, not the
WAN/VPN IP.

>   Don't confuse DHCP for LIS

Again, I fundamentally disagree with this statement because it leaves
out the phrase "provided we upgrade and/or replace most every
residential firewall device currently in service."

> + SRV. It's been discussed many times.

On this list? I went through a fair portion of the list archives and
can't find anything. And "google: ecrit stun" turns up nothing from this
group.

---

The comment by Barbra Stark is quite telling; "But I'm fine for the IETF
not to document or provide a BCP for that. I can go elsewhere for
refining best practices. Which is why I don't really care to argue this
question anymore."

With apologies to Barbra for putting words in her mouth; "The BCP
developed by this group ignores reality. I'll go elsewhere for for BCP".

I get the impression that this has been argued many times in the past so
I guess it's just my turn to stir up the pot ;)

The framework document I'm developing for submission to my regulator
will not follow ecrit-framework or ecript-phonebcp (though it will be
based on it) for all of the reasons that I've made apparent on this
list.

However, the framework would be stronger if it did follow ecrit and
likewise, ecrit-framework and ecrit-phonebcp would be stronger if they
could demonstrate success in the marketplace.

-- 
John Lange
http://www.johnlange.ca

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 03 Jun 2009 14:29:58 -0500

>parameters have already been set.

one the one hand you say "i2 might be dead", and on the other hand 
you mean "we need to remain constrained by the i2 limitations".

this is interesting considering i2 didn't change anything in the 
PSAP, so why are PSAPs involved in making this requirement when they 
get to "stay in the past" with anything the IETF moves forward with?

I'm confused.

Further, in the same meeting (in 2003 in Atlanta, that I was in 
attendance of) - both the i2 and i3 WGs were formed within 
NENA.  Nothing was in stone yet wrt the architecture of either, other 
than i3 was IP e2e, including into the PSAP (i.e., to the call-taker's phone).

Thus, PSAPs have been aware of i2 for as long as they have been aware 
of i3.  Why are they able to dictate i2 rules upon the i3 solution?

i3, from the beginning, was to be built on the idea that location 
would be sent from the calling phone. This means "the residential 
phone and its network" must be changed to support IP, and all that IP 
brings to the table.

Now you are saying the RG cannot be changed for i3?

BTW - I was co-chair of i3 with Brian for the first year...

---

From: Marc Linsner <[email-masked]>
Date: Wed, 03 Jun 2009 17:00:17 -0400

John,

I would guess by your comments that you missed some early threads in both
ECRIT and GEOPRIV.

more in-line....

> equipment is required in order for it work."

Requirements are wonderful, they guide the solutions.  Not every requirement
has a technically feasible solution.  We can certainly debate how one gains
new functionality without upgrades, but that will probably lead us to a very
big rat hole, one the IETF has been in many times before.

> parameters have already been set.

i2 is not an IETF developed solution.

> providers have access to 911 while in Canada.

The CRTC can and will do whatever they want, based on the input from whoever
provides them input.  If Canada decides to not offer emergency assistance to
visitors to Canada, so be it.  I would hope the CRTC would consider the
consequences of their policies governing the Internet usage.

> to 911 (or whatever) everyplace on earth, then I say good luck with
The two points you make are exactly why regulators should proceed with
caution when making policy for the Internet.

> prior relationship with and for the foreseeable future that means VOIP

The Calgary PSAP can certainly dictate who can and who can't call them.
They can require that all citizens of Calgary MUST do business with approved
providers in order to enjoy the luxury of emergency assistance from
governmental agencies.  Although, IMO, this is somewhat contrary to the
globalization the Internet allows.

> PSAP/ESRP will be open to any IP address in the entire world... no.

This is not the consensus when I talk to PSAPs.  They would rather deal with
all the bad stuff instead of missing a real call for help.

> everyplace on earth which is impossible.

IMO, a more correct characterization is: The IETF is all about making the
end-user experience better and the Internet work better.  The success of the
Internet can be directly related to the distillation of access, network, and
applications.  Hence neither GeoPriv nor ECRIT will propose a solution that
requires relationships between various providers at different layers as that
would be contrary to the foundation of the Internet.

> and they DO have authority to order relationships between all three

As long as they realize they are restricting their constituent's choice to
providers within purview of their jurisdiction.
> replacing residential firewalls?

It won't happen without upgrades.

> on endpoints and DNS LIS discovery for OBO.

The solutions around this have been proposed multiple times without
significant progress.  Hopefully the technical aspects of this solution will
be resolved soon.

> is several years off so holding up everything on that requirement isn't

The IETF is proposing solutions that fit the Internet model which includes
VPNs.  The IETF doesn't sequence it's work based on regulation.

> query an external LIS for location based on the public IP, not the

Again, an IETF solution will not force relationships.

> can't find anything. And "google: ecrit stun" turns up nothing from this

Since most of this discussion is a GeoPriv issue, you would probably have
better luck searching there.  GeoPriv is defining how a device discovers
it's location.

-Marc-

---

From: John Lange <[email-masked]>
Date: Wed, 03 Jun 2009 16:07:01 -0500

> you mean "we need to remain constrained by the i2 limitations".

I think it's pretty clear that the PSAPs have the same requirements
today that they always did. And with respect to the issue of replacement
or upgrading end-user equipment, I agree with them.

> get to "stay in the past" with anything the IETF moves forward with?

I've asked the same question many many times. The answer is; because the
PSAP + the ILECs are by far the most powerful influence on the
regulators.

Of course that is not binding on the IETF but there requirements are
never the less something worth keeping in mind.

> I'm confused.

Ah yes. It's a messed up world we live in. The PSAP argument basically
amounts to; "the world is changing but we don't like change so please
make your square peg fit in this round hole. Oh, and the cost to us must
be zero."

Please don't get me started on a PSAP rant. They are dinosaurs all...
But they've been trained well by the ILECs and that's the world we live
in... ( I should clarify that i mean Canadian PSAPs).

> phone and its network" must be changed to support IP, and all that IP 

But that is technically not a true statement. Yes the phone will have to
be changed to support location, and yes, the best way to get accurate
location is from the local network. But no, the local network does not
have to be changed in order for the phone to get location.

Other devices can act OBO the local network and will do just as good a
job frequently enough to satisfy regulatory requirements until the day
that every RG has been replaced and every DHCP server does option 99 (or
whatever the solution turns out to be).

> Now you are saying the RG cannot be changed for i3?

I'm not saying that at all. What I am saying is, this won't work for
residential today and therefore it won't be acceptable to the regulators
(today).

I understand I could be the one in the wrong here because I don't
clearly understand the goals of this group.

If ecrit is saying "yes we know ecrit-framework and phonebcp can't be
implemented today. We are developing a standard for the future. After we
are done we'll do some interim standards to bridge between today and the
ecrit-framework of the future", then I think that's a reasonable
approach but that is not the impression I've had up until now.

My only concern would be that the progress is too slow. We need the
interim solutions before future solutions. Without them, the
aforementioned PSAPs and ILECs will impose their own "home-brew"
solutions with the associated predictable costs.

BTW, I listened in on the last 45 minutes of the call today (I screwed
up the timezone conversion or I would have been there sooner). Very
informative. For one thing, I had no idea that Best Current Practise is
not intended to mean what it says. It's not intended to be the best nor
is it current so that alleviates some confusion.

And the debate about the cell phone group (3GP?) expecting the proxy to
do location, not the handset sounded a lot like OBO-redux to me.

> BTW - I was co-chair of i3 with Brian for the first year...

What is the status of NENA with respect to i3? Is work still going on?
Has ecrit replaced it or exactly what is the relationship between the
two groups?

-- 
John Lange
http://www.johnlange.ca

---

From: John Lange <[email-masked]>
Date: Wed, 03 Jun 2009 16:44:21 -0500

Marc, no need for me to quote your entire reply. I just want to say that
your response was very informative and shed a lot of light onto how the
IETF sees regulatory requirements and it's goals as far as developing
standards.

I just might be able to stop tormenting this list now.... ;)

-- 
John Lange
http://www.johnlange.ca