Subject: [Geopriv] New HELD error code: notLocatable

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 1 Jul 2008 20:01:47 -0500

I'd like to propose that HELD include a new error code be added.  This error code would be used to indicate to a Device that it has asked for location information from the wrong LIS.  Adding this to HELD will make discovery more robust.

This was first discussed here: <http://www.ietf.org/mail-archive/web/geopriv/current/msg05854.html> (see item 1).  Excerpt from this discussion:

> The error codes
> currently available indicate situations that could be temporary.  The
> situation highlighted in Section 4.3.2 is one that is permanent.
> Indicating to the host that this is a permanent situation lets the
> device continue searching for a valid LIS, rather than leaving it in
> the ambiguous state where the LIS *might* be the right one.  To address
> this, we need a new error code for this situation.  

I'd like to make the following changes:

 1. In Section 4.3.2, use clearer and more positive wording.  Change from:

   If the LIS cannot determine an accurate LI, it should not provide location information to the requesting device.

  ...to:

   If the LIS cannot determine LI for the Device, it should provide an error response to the requesting device.

 2. In Section 6.3, add a new code:

   notLocatable: This code indicates that the LIS is unable to locate the Device, and that the Device must not make further attempts to retrieve LI from this LIS.  This error code is used to indicate that the Device is outside the access network served by the LIS; for instance, the VPN and NAT scenarios discussed in Section 4.3.2.

This code will mean that a LIS that a device will be able to disregard a LIS that is unable to locate it, and potentially go on to discover a more appropriate LIS using other means.

Regards,
Martin

------------------------------------------------------------------------------------------------
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
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 1 Jul 2008 20:14:20 -0500

So this allows the client to discriminate between the situation where
the LIS can't provide a location "at the moment" - i.e. some transient
issue - from the situation where the LIS can never provide a location
for that device because it is simply the wrong LIS to be talking to?

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Thomson, Martin
Sent: Wednesday, 2 July 2008 11:02 AM
To: GEOPRIV; Mary Barnes
Subject: [Geopriv] New HELD error code: notLocatable

I'd like to propose that HELD include a new error code be added.  This
error code would be used to indicate to a Device that it has asked for
location information from the wrong LIS.  Adding this to HELD will make
discovery more robust.

This was first discussed here:
<http://www.ietf.org/mail-archive/web/geopriv/current/msg05854.html>

 1. In Section 4.3.2, use clearer and more positive wording.  Change
from:

   If the LIS cannot determine an accurate LI, it should not provide
location information to the requesting device.

  ...to:

   If the LIS cannot determine LI for the Device, it should provide an
error response to the requesting device.

   notLocatable: This code indicates that the LIS is unable to locate
the Device, and that the Device must not make further attempts to
retrieve LI from this LIS.  This error code is used to indicate that the
Device is outside the access network served by the LIS; for instance,
the VPN and NAT scenarios discussed in Section 4.3.2.

This code will mean that a LIS that a device will be able to disregard a
LIS that is unable to locate it, and potentially go on to discover a
more appropriate LIS using other means.

Regards,
Martin

------------------------------------------------------------------------
------------------------
------------------------------------------------------------------------
------------------------

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 1 Jul 2008 20:19:14 -0500

That's it.  You can think of this as the 'wrongLIS' code if you like.  It might be the right LIS later, but for now, it cannot find you, so there is no point asking again.

> From: Dawson, Martin
> Sent: Wednesday, 2 July 2008 11:14 AM
> To: Thomson, Martin; GEOPRIV; Mary Barnes
> Subject: RE: [Geopriv] New HELD error code: notLocatable
> 
> This was first discussed here: <http://www.ietf.org/mail-
> archive/web/geopriv/current/msg05854.html> (see item 1).  Excerpt from
> this discussion:
> 
> > The error codes
> retrieve LI from this LIS.  This error code is used to indicate that
> the Device is outside the access network served by the LIS; for
> instance, the VPN and NAT scenarios discussed in Section 4.3.2.
> 
> This code will mean that a LIS that a device will be able to disregard
> a LIS that is unable to locate it, and potentially go on to discover a

---

From: "Mary Barnes" <[email-masked]>
Date: Tue, 8 Jul 2008 15:29:43 -0500

Okay, I'll add this to the -08 version I'm working on right now. 

Thanks,
Mary.

-----Original Message-----
From: Thomson, Martin [mailto:[email-masked]] 
Sent: Tuesday, July 01, 2008 8:02 PM
To: GEOPRIV; Barnes, Mary (RICH2:AR00)
Subject: New HELD error code: notLocatable

This was first discussed here:
<http://www.ietf.org/mail-archive/web/geopriv/current/msg05854.html>
(see item 1).  Excerpt from this discussion:

> the ambiguous state where the LIS *might* be the right one.  To 
> address this, we need a new error code for this situation.

  ...to:

Regards,
Martin

------------------------------------------------------------------------
------------------------
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
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv