> I don't see that as a big problem. There aren't going to be thousands of
> such successful service providers. It usually quickly settles Darwinian
> style to one or two. When the PSAPs see a bunch of calls from some new
> source, they will call them up, and get them on the "we know you" list. No
> big deal.
>
> You are still speculating about something that hasn't happened, and you
> can't find a good predecessor. The latest "thing" is the social newtworks,
> there were maybe 50 of them, and now there are maybe 5 or 6 that matter.
Exactly my point. In the scenario you've painted, the PSAP is going to
evaluate the validity/urgency of the request for emergency assistance
differently for their customers (as in the PSAP's customer) that chose to
use social network 7-50 verses 1-6. Please explain how my emergency is
lesser of a priority because I buy services from social network provider
#29. This is not the right tool for the PSAP to use for this purpose.
Simply stating these are the only tools available is not good enough.
-Marc-
>
> Brian
>
>
> On 10/30/09 6:12 PM, "Marc Linsner" <mlinsner@cisco.com> wrote:
>
>> It's not that I necessarily believe there will be a lack of SPs. I believe
>> the mix of SPs and the products they offer will change dramatically at a
>> pace that PSAPs won't be able to keep up. This week Google, next week
>> Noggle, the next week Boogle, etc. If in fact the PSAP requires
>> relationships with every SP that may send an emergency call their way, it
>> will only stifle innovation.
>>
>> -Marc-
>>
>>
>> On 10/30/09 4:55 PM, "Brian Rosen" <br@brianrosen.net> wrote:
>>
>>> There is way too much speculation here.
>>>
>>> You are speculating that there will be interesting services without service
>>> providers that have two way interactive media, where the identity of the
>>> callers is a simple domain name, emergency calls from those devices is
>>> interesting, they can't provide a suitable callback without a registration
>>> from the ESRP, and such calls wont be the preferred abuse call source.
>>>
>>> When we have that problem, if we ever have that problem, we'll solve it.
>>>
>>> Right now, the simpler case of a direct call from an unknown source because
>>> you have a proxy server in your boat will get through just fine nearly all
>>> the time. When it doesn't, it will be because that path is being used by
>>> someone attacking, and the lack of a service provider will probably be to
>>> the disadvantage of the direct caller. I'm not going to lose sleep over
>>> that problem. I'd rather beef up the system so we don't have to drop calls
>>> when we're attacked. OTOH, I don't want to promote the proxy server in the
>>> boat idea. If it happens occasionally, we'll cope.
>>>
>>> Brian
>>>
>>>
>>> On 10/30/09 4:14 PM, "Marc Linsner" <mlinsner@cisco.com> wrote:
>>>
>>>>
>>>>
>>>> On 10/30/09 2:29 PM, "Brian Rosen" <br@brianrosen.net> wrote:
>>>>
>>>>> I'm the messenger here. PSAPs prefer service providers to be on the path
>>>>> of
>>>>> a call, and they have bad experiences when they aren't.
>>>>>
>>>>> Given their experiences, I can't fault them.
>>>>>
>>>>> The reason the text is in phonebcp is as you said it is: because "normal"
>>>>> is
>>>>> likely to work. The fact that "normal" means SP path in 99.999% of cases
>>>>> gets the PSAPs what they want. They don't care about why we did it, they
>>>>> care they get the right result.
>>>>
>>>> I, like others, believe the role/definition of the 'SP', as currently
>>>> defined by the PSAPs, will change significantly going forward.
>>>>
>>>>>
>>>>> I don't believe we are going to see vanity domains used on calls, and even
>>>>> if they were in "From", they won't be the domain in P-Asserted-Identity,
>>>>> or
>>>>> the SubjectAltName of the Identity signature. If some service that used
>>>>> email addresses as identities sent us calls, the email address (with its
>>>>> domain) is the "userpart" of the identity, not the whole thing. There are
>>>>> some interesting problems when you have URI to something like the MS IM
>>>>> systems. The first "@' (br@brianrosen.net@msn.com) gets escaped. We've
>>>>> built systems that handle that.
>>>>
>>>> I think this is a little short-sighted. Certificates for vanity domains
>>>> are
>>>> certainly doable. Besides P-Asserted-Identity is not a MUST in phonebcp.
>>>> :^)
>>>>
>>>>>
>>>>> The Firewall/Session Border controls will have several criteria when PSAPs
>>>>> are overloaded, but AFAIK, no existing firewalls or SBCs do what you
>>>>> suggest
>>>>> other than the repeat offender rule, which is the first line of defense.
>>>>> They do filter based on criteria that equate to IP Address or Domain of
>>>>> the
>>>>> SP, which we can deal with. We'll use what works for the other users of
>>>>> these systems, we're unlikely to be able to have emergency services
>>>>> special
>>>>> firewalls or SBCs.
>>>>
>>>> We're not talking about existing firewalls and SBCs. We're talking about
>>>> ESInet Border Control Function. If you don't define what you want there,
>>>> you'll live with what you get. My suggestions are not beyond what's
>>>> possible, it's all software.
>>>>
>>>> -Marc-
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
