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

[John Lange <john at johnlange.ca>]

On Tue, 2009-06-02 at 14:35 -0400, Brian Rosen wrote:
> 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.

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.

> You're focused on fixed devices, which is okay, but what you are describing
> 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.

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

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