[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bind-users
Subject:    Re: Supporting LOC RR's
From:       Timothe Litt <litt () acm ! org>
Date:       2022-05-13 19:38:37
Message-ID: 7ba5e880-9558-502f-f835-6c37d05b0bca () acm ! org
[Download RAW message or body]

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
[Attachment #2 (multipart/mixed)]

[Attachment #4 (multipart/alternative)]

[Attachment #6 (text/plain)]


On 13-May-22 12:21, Philip Prindeville wrote:
> > That's interesting, and clever work to solve the problem of making APs into \
> > reliable location references. 
> > They are doing a more involved/automated version of what I suggested - using GPS \
> > (in their case built-in GPS, plus AP-AP communication) for APs to locate \
> > themselves.  Once the AP knows where it is, the clients can find out where they \
> > are in physical (WGS84 coordinate) space using the APs as references.  Note that \
> > it's an enterprise solution - definitely not for most homes - since it requires \
> > at least 4, and probably many more suitable APs. 
> > But LOC records don't have any role in what's described.  They *could* be an \
> > output (e.g. an AP could use DNS UPDATE to install LOC records).  But there's \
> > still no obviously useful consumer for the LOCs...so why bother? 
> > If you're in WiFi range of the AP, a client is better off getting precise \
> > information from its broadcast.  If not, it's useless.  And as previously noted, \
> > LOC for servers suffers from AnyCast, cache, and CDN uncertainty. 
> > LOC was proposed in simpler times.
> 
> Actually, if the AP doesn't have GPS but does offer WiFi Certified Location \
> Service, then it could use its own LOC record to provision itself... 
> -Philip
> 
WiFi Certified Location service computes the *relative* location of 2 
WiFi devices. https://www.wi-fi.org/discover-wi-fi/wi-fi-location To 
offer an absolute location (what LOC provides), at least one AP has to 
know where it is (and broadcast it).  Then additional APs can compute 
their positions relative to it, and compute their absolute location(s).  
Either your AP knows where it is, or it finds out via WCL (or some other 
means: e.g. GPS or configuration).

If you want an AP to find out where it is via LOC, someone has to 
generate the LOC record.  And the AP needs to be able to find it - 
meaning it has been configured with an IP address and/or name.  If you 
want to participate in WCL, you want the LOC to have a precise (and 
accurate) position.  OTOH, if an AP is participating in WCL and doesn't 
know its absolute location, it can compute it using WCL if some other AP 
knows and broadcasts its own absolute location.

This conversation has come full circle.  Where does the LOC record's 
position data come from, and who (or what) provisions it?  And (assuming 
the AP doesn't have GPS or another reference, such as installed WCL APs) 
why is that easier/better than putting the data in the AP's config?

As I noted, *after* an AP knows where it is, it *could* generate a LOC 
record, and even install it. But that makes it an *output* of 
provisioning, not an input.  And there's still no obvious customer.  
Yes, some other AP could then use the first AP's LOC with WCL to 
determine its absolute location.  (Well, you probably need three APs to 
triangulate...)  But it's less work all around to get it from the first 
AP's broadcast.  And you still have the bootstrapping problem.  WCL 
clients have no use for LOC.  If you want to map your APs, you can ask 
them for their locations directly.

Much as some would like it to be, involving DNS isn't the answer to 
everything.

If you still want to convince yourself that LOC is useful: starting with 
an empty building, some unprovisioned APs, and no LOC records, provide 
an algorithm that provisions your AP(s). Specify all inputs and where 
they come from.  Contrast it with the HP video and/or manual 
configuration.  Show what steps your algorithm eliminates and/or 
facilitates, and at what cost.  I don't expect a positive outcome, but 
if I'm wrong, by all means post the details.

Since this has indeed come full circle, I'm done.

Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.


[Attachment #7 (text/html)]

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <br>
    <div class="moz-cite-prefix">On 13-May-22 12:21, Philip Prindeville
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:50F68FAB-4197-4D0E-8838-2815FB37938B@redfish-solutions.com">
      <pre class="moz-quote-pre" wrap="">
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">That's interesting, and clever work to \
solve the problem of making APs into reliable location references.  

They are doing a more involved/automated version of what I suggested - using GPS (in \
their case built-in GPS, plus AP-AP communication) for APs to locate themselves.  \
Once the AP knows where it is, the clients can find out where they are in physical \
(WGS84 coordinate) space using the APs as references.  Note that it's an enterprise \
solution - definitely not for most homes - since it requires at least 4, and probably \
many more suitable APs.

But LOC records don't have any role in what's described.  They *could* be an output \
(e.g. an AP could use DNS UPDATE to install LOC records).  But there's still no \
obviously useful consumer for the LOCs...so why bother?

If you're in WiFi range of the AP, a client is better off getting precise information \
from its broadcast.  If not, it's useless.  And as previously noted, LOC for servers \
suffers from AnyCast, cache, and CDN uncertainty.

LOC was proposed in simpler times.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">

Actually, if the AP doesn't have GPS but does offer WiFi Certified Location Service, \
then it could use its own LOC record to provision itself...

-Philip

</pre>
    </blockquote>
    <p>WiFi Certified Location service computes the *relative* location
      of 2 WiFi devices.   <a moz-do-not-send="true"
        href="https://www.wi-fi.org/discover-wi-fi/wi-fi-location"
        class="moz-txt-link-freetext">https://www.wi-fi.org/discover-wi-fi/wi-fi-location</a>
  To offer an absolute location (what LOC provides), at least one AP
      has to know where it is (and broadcast it).   Then additional APs
      can compute their positions relative to it, and compute their
      absolute location(s).   Either your AP knows where it is, or it
      finds out via WCL (or some other means: e.g. GPS or
      configuration).</p>
    <p>If you want an AP to find out where it is via LOC, someone has to
      generate the LOC record.   And the AP needs to be able to find it -
      meaning it has been configured with an IP address and/or name.   If
      you want to participate in WCL, you want the LOC to have a precise
      (and accurate) position.   OTOH, if an AP is participating in WCL
      and doesn't know its absolute location, it can compute it using
      WCL if some other AP knows and broadcasts its own absolute
      location.<br>
    </p>
    <p>This conversation has come full circle.   Where does the LOC
      record's position data come from, and who (or what) provisions
      it?   And (assuming the AP doesn't have GPS or another reference,
      such as installed WCL APs) why is that easier/better than putting
      the data in the AP's config?</p>
    <p>As I noted, *after* an AP knows where it is, it *could* generate
      a LOC record, and even install it. But that makes it an *output*
      of provisioning, not an input.   And there's still no obvious
      customer.   Yes, some other AP could then use the first AP's LOC
      with WCL to determine its absolute location.   (Well, you probably
      need three APs to triangulate...)   But it's less work all around
      to get it from the first AP's broadcast.   And you still have the
      bootstrapping problem.   WCL clients have no use for LOC.   If you
      want to map your APs, you can ask them for their locations
      directly.<br>
    </p>
    <p>Much as some would like it to be, involving DNS isn't the answer
      to everything.</p>
    <p>If you still want to convince yourself that LOC is useful:
      starting with an empty building, some unprovisioned APs, and no
      LOC records, provide an algorithm that provisions your AP(s).  
      Specify all inputs and where they come from.   Contrast it with the
      HP video and/or manual configuration.   Show what steps your
      algorithm eliminates and/or facilitates, and at what cost.   I
      don't expect a positive outcome, but if I'm wrong, by all means
      post the details.</p>
    <p>Since this has indeed come full circle, I'm done.</p>
    <pre class="moz-signature" cols="72">Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed. 
</pre>
    <br>
    <pre class="moz-quote-pre" wrap="">
</pre>
  </body>
</html>


["OpenPGP_signature.asc" (application/pgp-signature)]

-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

ISC funds the development of this software with paid support subscriptions. Contact \
us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

--===============5320156806655847376==--



[prev in list] [next in list] [prev in thread] [next in thread]