[121433] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: New netblock Geolocate wrong (Google)

daemon@ATHENA.MIT.EDU (Richard Barnes)
Tue Jan 19 07:29:54 2010

In-Reply-To: <m2vdeymgfm.wl%randy@psg.com>
Date: Tue, 19 Jan 2010 07:29:04 -0500
From: Richard Barnes <richard.barnes@gmail.com>
To: Randy Bush <randy@psg.com>
Cc: North American Network Operators Group <nanog@merit.edu>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org

Just to be fair here, I appreciate that there's some additional
complexity here (not much -- I implemented a client for this yesterday
in ~80 lines of Javascript), but LOC records don't cover everything.
They're fine for stationary stuff, but not so great for anything that
moves with any frequency (unless you're willing to make the DNS really
dynamic).
--Richard



On Tue, Jan 19, 2010 at 7:23 AM, Randy Bush <randy@psg.com> wrote:
>>>> Something that I have often wondered is how folks would feel about
>>>> publishing some sort of geo information in reverse DNS (something like
>>>> LOC records, with whatever precision you like) -- this would allow the
>>>> folks that geo stuff to automagically provide the best answer, and
>>>> because you control the record, you can specify whatever resolution /
>>>> precision you like.
>>>
>>> yes!
>>
>> FWIW, there has been some work in the IETF on creating protocols to
>> allow pretty rich location information to be published in reverse DNS.
>> =A0Basically, you publish a NAPTR pointer to a location server [1] where
>> an interested client can ask for the location of a specific IP address
>> [2][3]. =A0(Publishing location in this way is a requirement in several
>> systems for VoIP 9-1-1 around the world to allow first responders to
>> ask networks for location. =A0See for example the NENA i3 architecture
>> in the US and a similar "Canadian i2" for Canada.)
>>
>> The location representation these protocols use is a profile of the
>> Geospatial Markup Language, so you can represent anything from a
>> simple point to full GIS-like layers; you can also represent civic
>> addresses (i.e., postal addresses) directly.
>
> surely, with its vast talents, the ietf can make this more complex.
>
> after all, look at the inflate-and-embellish stupidity that made the
> simple idea of bgp communities for data collecion, completely ueless,
> draft-meyer-collection-communities-00.txt
>
> </sarcasm>
>
> i just wanna deal with a cidr block for stupid simple thing, not boil
> the ocean. =A0and we have LOC RRs. =A0no brilliance or inventiveness need=
ed.
>
> randy
>


home help back first fref pref prev next nref lref last post