Re: [Ecrit] New work in ECRIT

"Dawson, Martin" <Martin.Dawson@andrew.com> Thu, 05 August 2010 08:50 UTC

Return-Path: <Martin.Dawson@andrew.com>
X-Original-To: ecrit@core3.amsl.com
Delivered-To: ecrit@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80CEA3A684C for <ecrit@core3.amsl.com>; Thu, 5 Aug 2010 01:50:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDoSns5JXG2M for <ecrit@core3.amsl.com>; Thu, 5 Aug 2010 01:49:50 -0700 (PDT)
Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 4F0293A6829 for <ecrit@ietf.org>; Thu, 5 Aug 2010 01:49:50 -0700 (PDT)
Received: from [10.86.20.102] ([10.86.20.102]:5349 "EHLO ACDCE7HC1.commscope.com") by csmailgw2.commscope.com with ESMTP id S353461Ab0HEIuU (ORCPT <rfc822; ecrit@ietf.org>); Thu, 5 Aug 2010 03:50:20 -0500
Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.436.0; Thu, 5 Aug 2010 03:50:19 -0500
Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Thu, 5 Aug 2010 16:50:16 +0800
From: "Dawson, Martin" <Martin.Dawson@andrew.com>
To: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>, ext Bernard Aboba <bernard_aboba@hotmail.com>, "mlinsner@cisco.com" <mlinsner@cisco.com>, "ecrit@ietf.org" <ecrit@ietf.org>
Date: Thu, 05 Aug 2010 16:50:14 +0800
Thread-Topic: [Ecrit] New work in ECRIT
Thread-Index: AcszMOsY6YiCVp4xSpWhPKEJInzzPQBMxpTQAAUQo2A=
Message-ID: <8B0A9FCBB9832F43971E38010638454F03EB8B0389@SISPE7MB1.commscope.com>
References: <C87D8FB6.2760A%mlinsner@cisco.com> <BLU137-W933692C5ED6EC042DF1F893AE0@phx.gbl> <3D3C75174CB95F42AD6BCC56E5555B4502DE8DA2@FIESEXC015.nsn-intra.net>
In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4502DE8DA2@FIESEXC015.nsn-intra.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_8B0A9FCBB9832F43971E38010638454F03EB8B0389SISPE7MB1comm_"
MIME-Version: 1.0
X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com
X-BCN-Sender: Martin.Dawson@andrew.com
Subject: Re: [Ecrit] New work in ECRIT
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ecrit>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Aug 2010 08:50:04 -0000

Some thoughts for people to "kick around".

What's the equivalent of these scenarios in the PSTN world? Some examples:


 1.  A SIMless mobile phone is still able to initiate a circuit service session with the emergency call centre applicable to the location its calling from
 2.  A registered mobile phone with a zero pre-paid balance is still able to initiate a circuit service session with the applicable emergency call centre
 3.  A pay-phone can be used to initiate a circuit service session with the applicable emergency call centre without inserting any money
 4.  A residential POTS connection can still be used to initiate a circuit service session to the applicable emergency call centre even though there is no active line rental subscription

These are all real examples applicable in one or more combinations in one or more parts of the world.

With respect to broadband Internet connectivity, it is only necessary to substitute "circuit service session" with "IP packet session" and to consider the equivalent connectivity situations:


 1.  A SIMless device (wanting to be) connected to an LTE or WiMAX access (there is no circuit service available on these RANs)
 2.  An LTE or WIMAX device with a zero prepaid balance
 3.  A WiFi device connected to a "non-free" public hotspot
 4.  A residential DSL connection (connected to the DSLAM) that does not have an active subscription

The concepts are similar but the technical challenges associated with actually permitting the desired IP packet session to be established with the appropriate emergency call centre are profound and vary considerably with each technology. Some technical complication arises because layer 3 service has to be established before the ECRIT procedures even become applicable - so there's a catch-22.

Considerable amounts of detail with respect to how such "unauthenticated access" might be achieved are network technology specific and outside the scope of the IETF.

One consideration with respect to whether it's even worth the investment of human capital in "solving" this "problem" is that we live in a different world than the one that defined mid-twentieth century telephony (well - many of us do). We live in a world where access to the Internet is being tabled as a fundamental human right. Certainly it's the case that it's much easier to assume that people have connectivity than it ever used to be. Some jurisdictions have recently decided to disable SIMless calling to emergency services because its nuisance contribution far outweighed its value. Approximately zero emergency calls from SIMless devices were genuine; it's not the kind of world where people carry around an unregistered device just in case they need to make an emergency call.

So - we could put a lot of energy into trying to define the parameters of a concept that will never have a material regulatory basis.

Cheers,
Martin

________________________________
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Thursday, 5 August 2010 4:22 PM
To: ext Bernard Aboba; mlinsner@cisco.com; ecrit@ietf.org
Subject: Re: [Ecrit] New work in ECRIT

Hi Bernard,

a few comments to your statements below:

________________________________
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of ext Bernard Aboba
Sent: Tuesday, August 03, 2010 8:26 PM
To: mlinsner@cisco.com; ecrit@ietf.org
Subject: Re: [Ecrit] New work in ECRIT
My humble suggestion is that draft-rosen-ecrit-additional-data is both straightforward and highly beneficial.  While IETF tradition would suggest that items with such a high benefit/cost ratio should be delayed indefinitely or abandoned in favor of items that are more intractable,  I'd suggest a concession to common sense in this isolated instance.

Of course, in order to ensure that the WG does not debase itself in an orgy of productivity, tradition requires that the WG take on a number of work items which are "hard" only because the wrong questions are being asked.   I'd assert that both Unauthenticated Access and PSAP callback  fall in this category.

Unauthenticated Access is "hard" because it represents a solution without a real problem.  There is no regulatory requirement for this today, nor is there likely to be one in the near future because the "solution" would itself be a problem and because technology such as femtocells will make the "problem" disappear in due course.

I have to disagree with you and here are my arguments.  The document covers a number of scenarios, even though we always just short-cut the description and talk about "unauthenticated access":
 a) No access authorization
 b) No ASP
 c) Zero-balance ASP

There are differences between the legacy telephony system and VoIP. No doubt. We do, however, see people moving towards IP-based networks and now the question is how the existing regulatory requirements will apply to an IP-based environment. With all the years we have had a hard time to figure out how this is going to work out particularly since there is no flag day. Regulators, as you know, try to claim that they are technology neutral and therefore they are likely going to stick with their requirements and assume that technical people will get the rest to work. Many people had looked at the requlatory space and have not come up with a consistent answer of what all the regulatory requirements for VoIP systems are (given that regulators are often not too explicit). Maybe we should interact with NENA and EENA to hear their view on the regulatory situation.

Let me talk about the above three items in context of the legacy infrastructure:
For (a) and (c) there are regulatory requirements. (b) is a case that cannot happen in the legacy technology but is quite likely in the VoIP case (see the more verbose description at http://tools.ietf.org/html/draft-winterbottom-ecrit-direct-02).

>From a VoIP point of view I would be really surprised if (c) is not useful in a VoIP context as well. As mentioned in the previous paragraph, (b) might actually be desirable from a communication point of view and I hear the argument about the applicable jurisdiction all the time. (a) is clearly tough and maybe the only thing we can do in this document is to point out some of the challenges and discourage it. With the ESWs we have lots of presenters talking about this topic and we tried to convince people that (a) is not a good approach but nevertheless the feedback we got is that people from the regulatory side still see some value in it.  I fear that just because we do not like it does not make it go away. For the same reason the 3GPP has worked on solutions for IMS in this space.

 In a nutshell, I believe that this document is very useful already if it only provides a way to describe the differences between the legacy technology and why certain concepts cannot be mapped 1-to-1. Talking about the architectural challenges and what aspects need to be considered will be useful for readers as well. There are simpler cases that can be tackled, such as (b) and (c), with a somewhat detailed description.

PSAP Callback is "hard" largely because of the disconnect between the PSTN way of thinking and the reality of VOIP, which will result in extended (and largely fruitless) "discussions", until the passage of the leaves the obvious solution in plain view, like a whale washed up on the beach.  Serializing other work items until this "hard" problem is "solved" will essentially cause them to wait in the queue until our teeth are but a memory.

As we discussed during the IETF week I will interview some more emergency services people about the user interface experience to gather some more data about this aspect.

Ciao
Hannes



> Date: Tue, 3 Aug 2010 09:19:50 -0400
> From: mlinsner@cisco.com
> To: ecrit@ietf.org
> Subject: [Ecrit] New work in ECRIT
>
> During the meeting last week the following drafts were discussed in the
> context of accepting them as WG items.
>
> draft-rosen-ecrit-additional-data
> draft-schulzrinne-ecrit-psap-callback
> draft-schulzrinne-ecrit-unauthenticated-access
> draft-tschofenig-ecrit-trustworthy-location
> draft-rosen-ecrit-data-only-ea
>
> The chairs and ADs have reviewed the level of interest in these, compared
> the work to the current charter and believe these fit within the scope of
> ECRIT.
>
> We asked during the meeting if anyone objects to accepting any or all of
> these drafts as WG items. So, now, we're asking on the list.
>
> If you object to any of these drafts becoming WG items, please explain if
> you think the work is something ECRIT should not do, or if you simply have
> problems with current version of the particular draft. No response is a
> show of support for all of this work.
>
> Once the above question is answered, the chairs will devise a work plan to
> finish the accepted work.
>
> Also discussed in the meeting was the priority order of getting these drafts
> completed, and it was the general feeling that psap-callback,
> unauthenticated-access, and trustworthy-location were the most difficult and
> would take more time. Of those three the general feeling was the
> psap-callback was the highest priority. If you have an opinion on which
> draft should completed first, please send it to the list.
>
> Please respond by COB on Wednesday, 8/11/2010 if you have objections to any
> of this work, or you have strong feelings on the priority of the work.
>
> Thanks,
>
> -Marc, Richard, Roger-
>
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit