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

["Brian Rosen" <br at brianrosen.net>]

I'm trying to solve a problem where the user is doing the wrong thing.  By
definition, his opinion is that he should terminate the call.  "Negotiating"
with the user is not possible.  We can do something and provide an override,
but it doesn't work to negotiate with the user.

I do understand the "intruder" problem.  I'd like to be able to solve that
in the best possible way.  If the user really knew what was happening, they
would pull the battery out of the device, because any phone can be called
any time.  That's not a reasonable response, and I understand that.  We have
a balance to strike.  Of course the override could and probably should be
proactive (that is, if you should be able to invoke the override before you
terminate).  That is also not a complete answer.  It seems to me that the
incidence of bad judgment causing serious problems is so much more common
than the intruder's shouldn't hear alerting that we ought to compromise in a
way that facilitates the former rather than the latter.  Although I'm not
entirely comfortable taking that position, I'm a heck of a lot more
comfortable with that then any other proposed solution.

I'm not at all worried about the "least surprise" issue with people coming
in from other jurisdictions.  Surprise is the most common reaction to people
in the jurisdictions it's been implemented in, mostly because you don't make
emergency calls very often.  Most Canadians don't know that the PSAP can
control termination on wireline calls.

The current proposed mechanism is that you negotiate the feature with a full
3 way handshake.  Then, normally, instead of termination, you signal
hookstate.  If you get stuck (the signaling of hookstate doesn't complete,
or the override is triggered), you terminate.  The PSAP has a way to alert.
All that is required to make this work in complex networks is that the
negotiation mechanism and the hookstate signaling mechanism is transparent
to networks and devices other than the UAS and the UAC.  If either end
really does send BYE, the call terminates.  

Brian

> -----Original Message-----
> From: Ted Hardie [mailto:hardie at qualcomm.com]
> Sent: Friday, January 09, 2009 5:45 PM
> To: Brian Rosen; 'ECRIT'
> Subject: Re: [Ecrit] FW: FW: I-D Action:draft-rosen-ecrit-premature-
> disconnect-rqmts-02.txt
> 
> > > 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