[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered



James

I'd like to focus on this point below.

At what point did an ESRP become a SIP registrar (for unauthenticated UAs to register to when they don't register to any other registrar in any domain in the <what>... universe)?

James

At 08:02 AM 10/27/2009, Marc Linsner wrote:
<snip>

[Don't take this as my endorsement of the draft, as I'm not sure I agree
with UAs registering with the ESRP.]

-Marc-


On 10/26/09 8:59 PM, "Brian Rosen" <br at brianrosen.net> wrote:

> First of all, I put it on the wrong email list, sorry about that.
>
> Then, we have carefully arranged it so that there is no identity coming from
> the access network provider, and because the location is coming from that
> provider, we really don't want to.  But even if we did, we would need a
> really good identifier, and there isn't one.
>
> The problem we have with -direct is anonymous callers, and if they have any
> option, they would also be location-less.  Until and unless we get rid of
> anonymity, we can't encourage service provider-less calls.  The draft does
> not make any provision to provide any kind of identity.  Many networks
> (think free wifi for example) would make providing good identity difficult.
>
> The fact is that there is a SERVICE provider in nearly all of the
> communications systems.   The SERVICE provider is in a position to assist
> the emergency calling system when it needs more information.  That's what a
> good SERVICE provider does.  Cutting them out is not a great idea.  Most of
> the attempts to provide real time communications between people have evolved
> to using service providers, even when there were alternatives.  File
> transfer via something like Torrent is a counterexample (which isn't real
> time), but even there, you end up with service providers like The Pirate Bay
> (R.I.P) to provide introduction services.  I don't think we're going to see
> changes that eliminate service providers, and in this case, they provide
> value to the emergency calling systems.  All of the emergency professionals
> I know have issues with service providers, but they would react with horror
> if you suggested cutting them out.  Ask them, please.
>
> So, I claim you have a solution in search of a problem.  We have solved the
> "calling network isn't the access network" problem already.  Service
> providers ARE in the path now, in nearly every case (in fact a counter
> example escapes me, although there probably are some). There is no movement
> I can detect which would change that any time soon; quite the opposite.  We
> have a known killer problem without some kind of subscription to a service
> that provides a good identity, for which you provide no answers.  We have
> experience with the killer problem: sim-less calling was supposed to provide
> a way to make an emergency call in exactly the kinds of circumstances you
> are describing. Our real world experience is that you create a huge problem
> that diverts resources from helping people to chasing scammers and
> flea-market sellers.
>
> Nothing is perfect: you can get a AIM screen name without a very good
> identity for example.  However, the notion that we're going to provide
> direct access without a service provider deliberately, especially without
> really good identity from the access network is, in my opinion not only a
> no, it's a heck no. I'll line up as many emergency service professionals as
> you would like to tell you this is a harmful idea.
>
>
>
>
>
>
> On 10/26/09 7:56 PM, "Dawson, Martin" <Martin.Dawson at andrew.com> wrote:
>
>> I am glad this has come up. It's a debate that has to happen if we are to
>> move
>> beyond a long standing legacy misconception.
>>
>> In the circuit service world - whether it was POTS or mobile, the access
>> network had full responsibility for delivering the emergency call. In that
>> world, routing an emergency call meant getting a circuit established to the
>> correct call center. In most parts of the world, this was done using the
>> regional part of the PSTN to switch the circuit to a call center on the PSTN.
>> In some jurisdictions, such as the US, it was done directly from the local
>> exchange carrier to the call center. Either way, there was no third party
>> involved.
>>
>> Now we have the Internet. We still have public access network providers. They
>> switch packets onto the Internet for their subscribers. They can similarly
>> ensure that packets reach the local emergency call centers.
>>
>> The fact is that there was no equivalent of a VSP in the traditional
>> environment. VoIP is a presence service, and it had no common equivalent in >> the PSTN world. It could have, but the narrowband state of technology and the
>> common market use cases didn't support its development. By the time ISDN
>> arrived, the PSTN had already slipped into its palliative stage without
>> realizing it.
>>
>> It's an entrenched misconception that because the circuit service provided by
>> exchange carriers was most commonly used for "voice" (but, it should be
>> noted,
>> also for fax, telex, tty, security system monitoring and, even, IP data) that
>> VSPs are somehow equivalent to exchange carriers. They are not.
>>
>> Indeed, involving VSPs in emergency calls is the Internet equivalent of
>> involving long distance providers in POTS emergency calls. They are neither >> necessary nor particularly helpful; they can't be guaranteed to be within the >> emergency jurisdiction; depending on them actually diminishes the efficacy of >> emergency service access. It does not help the caller, the emergency service,
>> nor the third party to insist on the third party's involvement.
>>
>> It can't be helped if you have over sold the benefits of VSP involvement to
>> yourself and others Brian. It is time to have a reasoned debate. From my
>> perspective, the argument that there is no "subscription" involved is
>> patently
>> false. There has to be a subscription of some description in order to get to
>> the Internet. Yes, there is free public Internet access (just as there are
>> free courtesy phones on the PSTN and free access to emergency services from
>> pay phones. All these services are still connected to the public Internet
>> infrastructure and they all represent an "operator" with some level of
>> information about the caller.
>>
>> With the over-emphasis on VSPs, what is missing from the ECRIT and i3 models >> is the direct interface for querying the access network for subscriber data >> (should it prove necessary). These models need to take the long view of how >> emergency calling is done in the Internet age; they should not be protracting
>> an unnecessary reliance on VSPs.
>>
>> I have deleted the premature and prejudicial text from the subject heading.
>> And I'll leave this on ECRIT as the most appropriate WG.
>>
>> Cheers,
>> Martin
>>
>> -----Original Message-----
>> From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org] On Behalf Of
>> Hannes Tschofenig
>> Sent: Tuesday, 27 October 2009 8:23 AM
>> To: ecrit at ietf.org
>> Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered harmful,
>> at least given our current experiences
>>
>> FYI: feedback from Brian regarding a recent ECRIT contribution.
>>
>>> -----Original Message-----
>>> From: geopriv-bounces at ietf.org
>>> [mailto:geopriv-bounces at ietf.org] On Behalf Of Rosen, Brian
>>> Sent: 26 October, 2009 23:10
>>> To: geopriv at ietf.org
>>> Subject: [Geopriv] Winterbottom-ecrit-direct considered
>>> harmful, at least given our current experiences
>>>
>>> The notion behind -direct is to not use a service provider to
>>> place an emergency call.  Instead, the device registers with
>>> an Emergency Services Routing Proxy immediately before the
>>> call and the call is routed directly from the device to the ESRP.
>>>
>>> At least at the moment, this is an exceedingly bad idea.
>>>
>>> Emergency calling authorities like service providers, a lot.
>>> They like them because they can hold them accountable, and the
>>> service providers don't like theft of service, which is
>>> something the emergency call guys have an analog to.
>>>
>>> The facts are that where unaccountable access to emergency
>>> calling is allowed, huge numbers of false calls occur, with no
>>> way to stop them, and no way to tell the good ones from the
>>> bad ones.  This has been seen multiple times where so called
>>> "simless" or "unauthenticated" calls are allowed.
>>>
>>> -direct precisely duplicates simless calling.  The only
>>> "registration" is an emergency registration, only emergency
>>> calls are allowed, any device can make an emergency call if
>>> all it has is a (radio) connection to any network.
>>> We can predict, with a very high degree of certainty, that the
>>> feature will be horribly abused: for example to test that a
>>> phone without a service plan works.
>>>
>>> There have been studies which show tens of thousands of bad
>>> calls with zero good ones.  Nearly every authority I know
>>> where the regulator has insisted on simless calling wants it
>>> repealed.  There is one counter example I know where the fact
>>> that they got a couple, literally, of good calls among the
>>> tens of thousands of bad calls was considered enough reason to
>>> put up with the problem.
>>>
>>> Service providers give us information that may be useful: a
>>> subscriber name and address for example, which is not
>>> spoofable by the caller.  They have ways to trace callers,
>>> especially bad callers.  They don't want their systems abused
>>> any more than the emergency calling authorities do.
>>>
>>> This is a bad idea.  A very bad idea.  Please stop it.
>>>
>>> Someday, we may have better ways to prevent abuse. Until we
>>> do, service providers are a good thing on an emergency call.
>>> We don't want them cut out.
>>>
>>> Brian
>>>
>>> _______________________________________________
>>> Geopriv mailing list
>>> Geopriv at ietf.org
>>> https://www.ietf.org/mailman/listinfo/geopriv
>>>
>>
>> _______________________________________________
>> Ecrit mailing list
>> Ecrit at ietf.org
>> https://www.ietf.org/mailman/listinfo/ecrit
>>
>> _______________________________________________
>> Ecrit mailing list
>> Ecrit at ietf.org
>> https://www.ietf.org/mailman/listinfo/ecrit
>
>
> _______________________________________________
> Ecrit mailing list
> Ecrit at ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit


_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www.ietf.org/mailman/listinfo/ecrit