RE: [Geopriv] HELD comment on responseTime parameter

From: Dawson, Martin ^lt;Martin.Dawson@andrew.com>
Date: Tue Aug 14 2007 - 09:40:48 EDT

Maybe there is a troll in our midst after all... -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, 14 August 2007 11:31 PM To: Dawson, Martin; 'Cullen Jennings' Cc: geopriv@ietf.org; 'Mary Barnes' Subject: RE: [Geopriv] HELD comment on responseTime parameter The answer to your question is that if a quick fix is available (1-2 sec) you use that to respond to ASAP, you use the most accurate response for the rest. [[MCD]] Which would completely fail to satisfy the routing requirement for E911 in wireless access - because ASAP is not accurate enough and most accurate is too slow. Which has been stated a lot of times now. Do you think this is an acceptable limitation? Because the cellular E911 industry, including emergency services, didn't think so. I have a counterproposal: [[MCD]] I'm going to assume for the moment that this ghastly contrivance is just proposed in jest. It will achieve nothing of value over just letting the server know what the client response time expectation is. And it displays more idealistic ignorance of the indeterminate nature of actual wireless location technologies. The protocol gets an optional mechanism where the server can return an enumerated list of determination mechanisms with the accuracy and response time of each. The query has an optional parameter that selects one. This parameter has two predefined values for "ASAP" and "accurate" which are mapped into the server's choice of the most appropriate mechanisms it has. If determination mechanism has a time/accuracy tradeoff, the enumerated list includes a a slope and intercept of a straight line approximation of the tradeoff. The query has an optional parameter for the point on the curve it wants. The design of the mechanism must be such that the client can completely ignore all of it everything except the "ASAP" and "accurate" values. The server can also not implement the enumerated list, but must implement ASAP/Accurate if it has the capability to provide different mechanisms. Brian > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Tuesday, August 14, 2007 12:34 AM > To: Cullen Jennings > Cc: geopriv@ietf.org; Mary Barnes > Subject: RE: [Geopriv] HELD comment on responseTime parameter > > Hi Cullen, > > There are certainly some people who haven't changed their stated > opinion. As ever, despite the consensus theory, any given thread in > Geopriv seems to have 90% of the emails generated by 3 or 4 people, the > rest by one or two others. Who knows what the majority view is? It's > easy to suspect that most subscribers don't actually read the thread, > let alone have an opinion. > > So, procedural conundrums aside - and given you've stuck your head over > the trench :) - What do you think? > > In particular, how do you recommend the following be addressed? > > "A LIS has three or more methods of location determination, or a single > method of location determination, where accuracy improves the longer the > response time that is incurred. How does a LIS know which method to use, > or how long to spend on a given method?" > > Henning's response is that this is not a real issue even though it is > demonstrably the case in wireless deployments today*. Actually, I > wouldn't care about this topic except that I do know it's a real issue. > Brian has avoided answering the question I believe. > > I suggest the following definition for an optional parameter. Let's call > it "within". > > "This parameter provides a quantified value for the time in which the > client would like to get a location result. The LIS may use this value > to determine the method of location determination and to provide the > optimum accuracy given this guidance. The LIS may take longer than the > indicated time to provide a response but cannot assume that the client > will be able to make use of the result. If the parameter is not > provided, then the LIS should assume that a response is required > immediately and the fastest available method of location determination > should be invoked." > > I'm agnostic about the last sentence - in particular whether the default > actually means ASAP or MostAccurate. I don't think the detractors of > this parameter are particularly consistent on this point either. I'd > actually suggest that explicit semantics should be defined for both ASAP > and MostAccurate to eliminate the guesswork. I think only one of them > can be the default... > > Cheers, > Martin > > * Ever the useful resort of the dogmatist, this could be termed the "I > reject your reality and substitute my own." ruse. (with apologies to > Adam Savage) :) > > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Tuesday, 14 August 2007 12:33 PM > To: Dawson, Martin > Cc: Rohan Mahy; geopriv@ietf.org; Mary Barnes > Subject: Re: [Geopriv] HELD comment on responseTime parameter > > > On Aug 7, 2007, at 1:37 AM, Dawson, Martin wrote: > > > Am I overly optimistic? > > Yes - I don't think I saw anyone change their opinion on this thread. > > > ------------------------------------------------------------------------ -- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------ -- > ---------------------- > [mf2] > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2]

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Tue, 14 Aug 2007 08:40:48 -0500

This archive was generated by hypermail 2.1.8 : Tue Aug 14 2007 - 09:42:40 EDT