<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <br>
    <div class="moz-cite-prefix">On 12-Apr-22 14:15, Philip Prindeville
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:B683DB90-99C3-4DB5-95C6-6FF50A133F14@redfish-solutions.com">
      <pre class="moz-quote-pre" wrap="">In my case, I do split-horizon for my domain in-house and use RFC-1918 addresses, so leaking them with the internet would be pointless anyway.</pre>
    </blockquote>
    <p>I have separate LOC records for in-house and external views.  The
      in-house version is high precision.  The external version is
      fuzzed.</p>
    <p>I use LOC records on domains; the comparison with IP geolocation
      is because the usual alternative to LOC is to translate the domain
      name to an IP address; then geolocate that using one of the
      commercial databases.  <br>
    </p>
    <p>Of course, that gets tricky when a hostname has multiple IP
      addresses or is served by anycast (such as a CDN).  In that case,
      the semantics aren't obvious - should the location be that of the
      CDN server (and which one)? The origin server?  And with 1918/NAT,
      the origin server may be in different locations depending on the
      protocol used.  (E.g. one public IP address, with an SMTP server
      in one building and a WWW server in another)</p>
    <p>With WPs, you're not trying to locate a host at all; you're
      trying to infer (or calculate) the mobile device client's
      location.  Or assist the mobile device to calculate its location.<br>
    </p>
    <p>It's not clear to me that it's less work to prepopulate LOC
      records than to put a cellphone on top of the WAP before turning
      it on, getting the GPS coordinates (e.g. see the 'gpstest' app),
      and pasting them into the WAP's configuration.  <br>
    </p>
    <p>If you really want cm scale accuracy, you need some kind of
      surveying instrument - whose data has to go someplace - be it LOC
      or the WAP configuration.  Or the new AP figures out its location
      based on triangulating from existing APs that somehow are deemed
      trustworthy.  THEY might have LOC records to help, but that's not
      pre-provisioning.  Maybe the new AP could then publish a LOC
      record with its location to help clients.  But I don't see how
      pre-provisioning helps setting up a new AP in this case; you might
      do the survey before the WAP arrives, but once the survey
      instrument reports a position, you either have prepared a
      configuration file for it (usual case), or you have to find it
      & configure it at that point.  Either way, setting the
      location is the smallest part of setting up a configuration -
      VLANs, SSIDs, access control/portals take much more work.  <br>
    </p>
    <p>Anyhow, it's not clear exactly what problem you're asking LOC (or
      anything) to solve.</p>
    <p>BTW, RFC1876 is worth reading for the suggested search
      algorithms.  I don't think it ever moved from "experimental",
      which may be part of why uptake hasn't been great.<br>
    </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>