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

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

I am sorry to be dense, but I can't seem to connect the dots here.

Compatibility with what?

I have agreed to work requirements first, mechanisms later, but we all have
difficulty keeping such priorities. Most of us are engineers at heart and if
we don't see at least one solution, we're likely not going to be able to
continue to work on the problem.  That doesn't mean that better solutions
won't occur to us or others.

In this case, I am definitely not wedded to a particular solution, I do
think the requirements are getting very fuzzy (because of the limitation to
discuss it in human terms only), but I'm soldiering on.  The requirement
that you selectively negotiate call-by-call, that the PSAP understands the
state of the device, and can control termination following negotiation, and
yet fail safe, leads to the proposed solution.  If you have a better idea,
great.

Brian

> -----Original Message-----
> From: DRAGE, Keith (Keith) [mailto:drage at alcatel-lucent.com]
> Sent: Wednesday, January 14, 2009 12:19 PM
> To: Brian Rosen; 'Ted Hardie'; 'ECRIT'
> Subject: RE: [Ecrit] FW: FW: I-D Action:draft-rosen-ecrit-premature-
> disconnect-rqmts-02.txt
> 
> At the risk of backward engineering, I don't find a requirement at the
> moment that would lead to this being adopted as a solution.
> 
> I believe I made comments to the effect that we need to deal with
> compatibility in my review.
> 
> Keith
> 
> > 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.
> 
> > -----Original Message-----
> > From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org]
> > On Behalf Of Brian Rosen
> > Sent: Tuesday, January 13, 2009 6:30 PM
> > To: 'Ted Hardie'; 'ECRIT'
> > Subject: Re: [Ecrit] FW: FW: I-D
> > Action:draft-rosen-ecrit-premature-disconnect-rqmts-02.txt
> >
> > 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
> > =

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