RE: [Geopriv] ResponseTime

From: Roger Marshall ^lt;RMarshall@telecomsys.com>
Date: Mon Aug 27 2007 - 17:25:47 EDT

Ugh, the example should have been '30 seconds' rather than '60 seconds',
i.e.,
 
30 : 50 (means provide a location inside a radius of 50m within 30
seconds)
 
-roger.

________________________________

        From: Roger Marshall [mailto:RMarshall@telecomsys.com]
        Sent: Monday, August 27, 2007 2:21 PM
        To: Stuard, Doug; Dawson, Martin; Stark, Barbara;
peter_blatherwick@mitel.com; Robert Sparks
        Cc: GEOPRIV
        Subject: RE: [Geopriv] ResponseTime
        
        
        What about using two independents, or even three variables?
         
        Timing and Uncertainty are two variables that could, (if
implemented rightly among the elements which determine location),
provide additional control, as well as allow the server to choose among
different back-end determination technologies, as Robert mentioned in
this thread.
         
        Examples of:
        0 : 0 (means give me whatever location you have asap)
        0 : 50 (means provide location which is reported as being within
a radius of 50m asap)
        30 : 50 (means provide a location inside a radius of 50m within
60 seconds)
         
        Coupling what is also done (by some vendors) within Wireless/CS
domains today, you could add a third variable, though a 'confidence'
parameter is still somewhat misunderstood (and certainly mis-applied),
so most might want to set this third value to a constant for now:
         
        30 : 50 : 95 (give me the location with a 50m or less tolerance,
determined within 30 seconds with a confidence of at least 95%)
         
        -roger marshall.

________________________________

                From: Stuard, Doug [mailto:Doug.Stuard@andrew.com]
                Sent: Monday, August 27, 2007 2:13 PM
                To: Dawson, Martin; Stark, Barbara;
peter_blatherwick@mitel.com; Robert Sparks
                Cc: GEOPRIV
                Subject: RE: [Geopriv] ResponseTime
                
                

                Given the practical limits stated, option i) is good

                Option ii) as stated seems too open ended. If restated
to "as accurate as you can get it within the stated time limit", I think
virtually all realistic use cases are covered.

                 

                In practice, a number of techniques converge within 20
seconds or so, so you could either wait until the stated time limit, or
until (reasonable) convergence is achieved.

                 

                Doug

                 

                 

                From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]
                Sent: Monday, August 27, 2007 4:46 PM
                To: Stark, Barbara; peter_blatherwick@mitel.com; Robert
Sparks
                Cc: GEOPRIV
                Subject: RE: [Geopriv] ResponseTime

                 

                The semantics of response time are "most accurate you
can get within this time".

                 

                I think I've seen both defaults proposed. That is, the
absence of the response time parameter can be:

                 

                i) As fast as possible at whatever accuracy
that results in.

                ii) Take as long as you like until you think
it's as accurate as you can get it.

                 

                Given there are technologies that could see incremental
(and diminishingly small) improvements in accuracy for every
iteration/measurement - even if it went on all day - the LIS would have
to apply its own interpretation of "accurate as you can get it" but
that's an invisible judgement as far as the client is concerned.

                 

                Obviously both defaults can't apply. To me, logically, a
response time of zero would mean as fast as possible (since zero can
only have theoretical significance so it might as well have a special
interpretation). That would leave option ii) as the default semantic.

                 

                Cheers,

                Martin

                 

________________________________

                From: Stark, Barbara [mailto:bs7652@att.com]
                Sent: Tuesday, 28 August 2007 6:30 AM
                To: peter_blatherwick@mitel.com; Robert Sparks
                Cc: GEOPRIV
                Subject: RE: [Geopriv] ResponseTime

                 

                I think there is a need for a device to be able to ask
for a "ASAP" vs. "accurate" response for location to be used when
requesting emergency services. If it were totally optional, and not
using it means "ASAP", then how does a device request "accurate"? I was
suggesting using a default value, like 60 seconds (but hopefully
recommended by phonebcp) to mean "accurate".

                Barbara

                 

________________________________

                From: peter_blatherwick@mitel.com
[mailto:peter_blatherwick@mitel.com]
                Sent: Monday, August 27, 2007 2:39 PM
                To: Robert Sparks
                Cc: GEOPRIV
                Subject: Re: [Geopriv] ResponseTime

                
                Hi,
                
> ... need to hear from more of the group than
> just the folks that were active in the discussion
earlier in the month
                
                I have stayed mostly out of the debate thus far, so here
goes.
                
                I would support response time parameter ONLY as an
optional extension. This for the following reasons:
                
                o I do not see value in it for the most part; I expect
most applications (including ECS) simply don't need it or it would bring
fairly minimal value added. (I can certainly see some special cases /
applications where it might be helpful, hence do see value as optional
extension for those.)
                
                o It seems very difficult to make such a parameter
specific enough to get the proposed value out of it in any consistent
way,
                
                o MOST IMPORTANT I desperately want endpoints needing to
support HELD for ECS purposes to have an absolutely ruthlessly simple
subset of the functionality that they must implement. The subset must
be both small (footprint) and very easy to implement correctly.
Endpoints that want to do more than ECS can add to the simple subset by
using extended options, but those that do only the ECS part need to be
very constrained. The value added bar needs to be set very high for the
core subset. The value of response time parameter in ECS does not make
that grade for me.
                
                Just to be clear on that last point, I'm not all that
concerned about the protocol itself (pretty easy) but more so about the
implications to the rest of the implementation: What to do if response
does not come back in requested time ... what to do if not at requested
accuracy .. what if .. what if .... And also I have the general concern
of "feature creep", of which this is one potential example.
                
                -- Peter
                .
                
                
                

 

Robert Sparks <rjsparks@nostrum.com>

27.08.07 12:05

        
        To: GEOPRIV <geopriv@ietf.org>
        cc:
        Subject: [Geopriv] ResponseTime

                
                
                
                All -
                
                Lets push to close on the responseTime question.
                
                To do this, I'm going to need to hear from more of the
group than
                just the folks that were active in the discussion
earlier in the month.
                
                So far, I've seen a good argument that a server can have
different
                technologies available for determining location and
would benefit
                from knowing something about how long a client is
willing to wait in
                order to choose which one to focus on. There has been a
question
                about an implicit time/accuracy tradeoff here and a
suggestion that
                we should explore a more explicit separation of
indicating those things.
                
                I've also seen a good argument that it is unclear how a
client
                implementation is going to provide values that would be
useful to the
                server. Without more clarity around this point, I see
discomfort from
                several people that the proposed mechanism is an
opportunity for
                "Unintended Consequences" to rear its head.
                
                On rereading the threads, I strongly suspect that there
are a set of
                assumptions going into arguing for this parameter that
haven't been
                made explicit yet, and I'd like to try a round of
teasing those out
                to see if it closes the gap in the discussion.
                
                Lets start with these two statements (which I _think_
the folks
                pushing for the parameter are assuming are true -
correct what I have
                wrong please):
                
                1) The clients will provide a useful indication of
responseTime from
                the server's point of view.
                2) Different clients (or different applications at the
same client)
                will provide different enough values to make the same
server choose
                different location technologies in servicing the query.
                
                I can see the parameter helping a system work as long as
the service
                has some way to tell the client what to ask for (and I
recognize that
                means the client has to know what service it's
invoking).
                
                James (or anyone else who has deployed or is developing
a deployment
                of something like this) - do you expect to have some
influence in a
                deployment over what the clients include in this
parameter? Are you
                expecting to have a relationship with the vendors
providing clients
                that lets you hand them values to hardcode,
                or give you a configuration interface you can use as a
service
                provider? Or are you expecting that to be entirely
outside your control?
                
                RjS
                
                
                
                
                _______________________________________________
                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]

                *****

                The information transmitted is intended only for the
person or entity to which it is addressed and may contain confidential,
proprietary, and/or privileged material. Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon
this information by persons or entities other than the intended
recipient is prohibited. If you received this in error, please contact
the sender and delete the material from all computers. GA622

------------------------------------------------------------------------
------------------------
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]

         

        The information contained in this message may be privileged
and/or confidential. If you are not the intended recipient, or
responsible for delivering this message to the intended recipient, any
review, forwarding, dissemination, distribution or copying of this
communication or any attachment(s) is strictly prohibited. If you have
received this message in error, please so notify the sender immediately,
and delete it and all attachments from your computer and network.

         

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Mon, 27 Aug 2007 14:25:47 -0700

This archive was generated by hypermail 2.1.8 : Mon Aug 27 2007 - 17:28:11 EDT