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