[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ecrit] FW: FW: I-D Action:draft-rosen-ecrit-premature-disconnect-rqmts-02.txt
My fault. Common fallacy of using the word in connection with only one side.
What I was trying to say is that we need requirements to deal with operation with entities that want to provide the capability, and those that do not.
But the key point I was making is that you are now mentioning a negotiation mechanism for which there is no underlying requirement.
I would like you to express the requirement in the draft that the solution is meant to meet.
regards
Keith
> -----Original Message-----
> From: Brian Rosen [mailto:br at brianrosen.net]
> Sent: Wednesday, January 14, 2009 7:54 PM
> To: DRAGE, Keith (Keith); 'Ted Hardie'; 'ECRIT'
> Subject: RE: [Ecrit] FW: FW: I-D
> Action:draft-rosen-ecrit-premature-disconnect-rqmts-02.txt
>
> 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