Supporting LOC RR's

[Timothe Litt]

On 01-May-22 05:03, Bob Harold wrote:
>
> On Wed, Apr 13, 2022 at 9:39 AM Bjørn Mork <bjorn at mork.no> wrote:
>
>     Timothe Litt <litt at acm.org> writes:
>
>     > Anyhow, it's not clear exactly what problem you're asking LOC (or
>     > anything) to solve.
>
>     Which problems do LOC solve?
>
>     I remember adding LOC records for fun?() in the previous
>     millennium when
>     RFC 1876 was fresh out of the press.  But even back then paranoia
>     finally took over, and I deleted all of them.
>
>     Don't think I ever found anything to actually use them for.
>
>
>     Bjørn
>     -- 
>
>
> WIth regard to locating access points:
> Self-locating wifi APs
> https://www.youtube.com/watch?v=kVdFNR0R3EE
>
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.


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20220502/eda87007/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20220502/eda87007/attachment.sig>