Re: [Ecrit] FW: FW: I-D Action:draft-rosen-ecrit-premature-disconnect-rqmts-02.txt

[Ted Hardie <hardie at qualcomm.com>]

> > But the system we've put together here allows for someone in Toronto
>> whose only working phone happens to tunnel back to Germany to determine
>> the correct PSAP for their location and make an emergency call.  How
>> does
>> that phone (or that network) treat the requirements for CPH?
>There is no fundamental change in the social context. 
>You still have
>stressed people making poor judgments on when to end a call, and a trained
>PSAP call taker better able to determine when to end the call.  The networks
>are, certainly, more complex.  The requirements, and the proposed mechanisms
>have always dealt with the circumstance you are describing adequately: the
>feature is enabled call by call at the PSAP and works across complex
>networks such as the ones you describe.

I believe that the mechanisms you've described so far would only work
across complex networks provided every network in the world was aware
of and obedient to this signalling.  The "don't tear down flows" requirement
is pretty much not how things work in many networks now, and this would
require all networks now to watch for signalling and keep state in a way
they do not.

Could we get there?  With enough will, certainly.  But "works across complex
networks" does not seem to describe the current state of play.  It is possible
that I am misunderstanding the mechanisms proposed.  That wouldn't
be unlikely and would probably be at least partly my fault, since I've been
among those asking for the requirements to be worked out prior to the
mechanisms being developed.  Sorry, if so.

> >
> >
> > Perhaps by making a requirement that there is a need for agreement
>> here between the human user and the PSAP on who should have this
>> control?  Since this isn't the same in all jurisdictions, you can have
>> a mismatch both ways.



>But there isn't a negotiation between the caller and the PSAP.  The
>requirement we have is that the PSAP asserts control, and the user can
>override.  That is described.  To implement that, I think signaling needs
>negotiation (both so the caller side knows what to do, and the PSAP knows
>whether it's going to be able to assert control).

And here is the crux of the matter.  The PSAPs want to assert control.
That will violate the principle of least surprise for at least some users
who come from different jurisdictions or whose phones using other
technologies do not behave this way, and it will not be desired by
others even if they aren't surprised by it
.
> >
>You are stuck on the possibility the user actually does know better than the
>PSAP what is happening.

I see a tension here you do not.  The user should always be in control
of the device, unless they surrender that control voluntarily.  The
extreme example of this is the one Marc mentioned:  no one else should
be able to brick your phone in an emergency.  The other examples given
have been knocked back as unlikely (the abuser/home intruder example,
where the hang up *must* happen,  the anonymous tip example, etc.).
Maybe those are unlikely in the world these PSAPs serve. But the possibility of
abuse here is also pretty scary, even if it abuse by authorities in jurisdictions
different from the current users of the related feature. 

We have to get this right if we do it, and that means we have to treat
the desires of both parties.  From my way of thinking that implies a
much more negotiated approach than the "PSAP desires control this"
tone of the proposals to date. Absent a willingness to do that, I will
move on to the position "this is a bad idea, let's not do it".
You may well get rough consensus over my objections, but I would
rather than you heard them and took them seriously.

If I have not said so lately, let me repeat:  thanks for your work on
this.  Please understand my comments are not meant to frustrate you
or the work; they are meant to help get it right.

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