The domain is not totally private blah blah blah. It is an access network, ISP if you will, that will direct the flow to the ESRP. The ISP has foot print in the PSAP jurisdiction, it can be followed up with and forced to comply with things in exactly the same way that LEC can today. This is the same model as happened to today, the local access provider directs the calls to the PSAP.
Why do we need a long distance provider involved or even more alarmingly, as Brian suggests, a chain of long distance providers? When things fail or run amok in this scenario, who is responsible and how on Earth, or in heaven for that matter, do you unravel the mess? You will need an international court to decide the real cause.
The emergency providers are terrified, Brian, because real alternatives are not being put on the table. The emergency providers I talk to are just as terrified of end-points providing location and them having to just believe what it says, with no form of validation being available. The proposal on the table here provides mechanisms for these checks to take place, as well as keeping the traffic local rather than trunking it out of the local jurisdiction.
I will stress again that this solution is being totally misrepresented as if you are comparing it SIMless because it is not, the device must have a legitimate connection to the Internet.
Cheers
James
> -----Original Message-----
> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of
> Brian Rosen
> Sent: Wednesday, 28 October 2009 1:32 AM
> To: Marc Linsner; ecrit@ietf.org
> Subject: Re: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered
>
> Of course not all VSPs will have trust relationships with all PSAPs. One
> can hope that long term, we can evolve to transitive trust relationships
> that work pretty well cross border.
>
> The emergency guys are actually terrified of private/individual domains
> sending them calls, and we're telling them we expect that to be possible,
> but rare, and we're giving them mechanisms that will effectively allow
> them
> to turn off calls selectively, based on factors including what domain the
> call comes from. They expect that such calls will be one of the loopholes
> where they get equivalents to sim-less calls, which drive them nuts. They
> don't want ANY calls that don't come from service providers, although they
> seem to be okay with the notion that the SP may not have great identity
> (AOL
> being a poster child). So, while indeed they understand, and have
> concerns
> about having to take calls from Sierra Leone VoIP services Pty, they would
> much rather have a call that went through them then a call that went
> through
> no service provider at all.
>
> I'm not trying to make calls direct from devices or private domains
> impossible, but I think the notion that we're promoting them is a very bad
> idea until we have effective mechanisms to prevent abuse.
>
> Brian
>
>
>
>
> On 10/27/09 9:02 AM, "Marc Linsner" <mlinsner@cisco.com> wrote:
>
> > Brian,
> >
> > I'm a little confused. I don't remember you objecting to requirement
> RE1
> > from RFC5012 and I remember your use case about a Sierra Leone VSP.
> >
> > Are you implying that *all* VSPs will have a trust relationships with
> *all*
> > PSAPs?
> >
> > What is the difference between a call coming from a private/individual
> > domain (as in not a commercial VSP) and a VSP on the other side of the
> world
> > (outside the jurisdiction)?
> >
> > I'm trying to figure out whether you're objecting to anonymous calls to
> the
> > PSAP or the mechanisms proposed in this draft?
> >
> > [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@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@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@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf
> Of
> >>> Hannes Tschofenig
> >>> Sent: Tuesday, 27 October 2009 8:23 AM
> >>> To: ecrit@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@ietf.org
> >>>> [mailto:geopriv-bounces@ietf.org] On Behalf Of Rosen, Brian
> >>>> Sent: 26 October, 2009 23:10
> >>>> To: geopriv@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@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/geopriv
> >>>>
> >>>
> >>> _______________________________________________
> >>> Ecrit mailing list
> >>> Ecrit@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/ecrit
> >>>
> >>> _______________________________________________
> >>> Ecrit mailing list
> >>> Ecrit@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/ecrit
> >>
> >>
> >> _______________________________________________
> >> Ecrit mailing list
> >> Ecrit@ietf.org
> >> https://www.ietf.org/mailman/listinfo/ecrit
> >
> >
>
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
