[db-wg] New NWI for geofeed?

Hi Denis,

I've added NWI-13 to the Numbered Work Items page, with a link to the Problem statement below:
https://www.ripe.net/manage-ips-and-asns/db/numbered-work-items

I'll get to work on an impact analysis.

Regards
Ed Shryane
RIPE NCC


> On 12 Apr 2021, at 17:59, denis walker via db-wg <db-wg at ripe.net> wrote:
> 
> Colleagues
> 
> ** corrected version getting the attribute names right **
> 
> The chairs agree that there is a consensus to set up an NWI to create
> the "geofeed:" attribute in the RIPE Database. We therefore ask the
> RIPE NCC to set up "NWI-13 Create a "geofeed:" attribute in the RIPE
> Database" Using the 'Problem statement' below. After the RIPE NCC
> completes it's impact analysis we can finalise the 'Solution
> definition'. The RIPE NCC can address any of the questions raised in
> this discussion that they feel are relevant to the basic creation of
> this attribute.
> 
> cheers
> denis
> co-chair DB-WG
> 
> 
> Problem statement
> 
> Associating an approximate physical location with an IP address has
> proven to be a challenge to solve within the current constraints of
> the RIPE Database. Over the years the community has chosen to consider
> addresses in the RIPE Database to relate to entities in the assignment
> process itself, not the subsequent actual use of IP addresses after
> assignment.
> 
> The working group is asked to consider whether the RIPE Database can
> be used as a springboard for parties wishing to correlate geographical
> information with IP addresses by allowing structured references in the
> RIPE Database towards information outside the RIPE Database which
> potentially helps answer Geo IP Location queries
> 
> The IETF is currently discussing an update to RPSL to add a new
> attribute "geofeed: url". The url will reference a csv file containing
> location data. Some users have already started to make use of this
> feature via the "remarks: geofeed: url". It is never a good idea to
> try to overload structured data into the free format "remarks:"
> attribute. This has been done in the past, for example with abuse
> contact details before we introduced the "abuse-c:" attribute. There
> is no way to regulate what database users put into "remarks:"
> attributes. So even if the new "geofeed:" attribute is not agreed, the
> url data will still be included in the RIPE Database.
> 
> Currently there are 24,408 INETNUM and 516,354 INET6NUM objects
> containing a "geoloc" attribute in the database. These have 7,731
> distinct values in the INETNUMs and 1,045 distinct values in the
> INET6NUMs. There are about 150 objects in the RIPE Database with a
> "remarks: geoloc url" attribute.
> 
> On Mon, 12 Apr 2021 at 17:56, denis walker <ripedenis at gmail.com> wrote:
>> 
>> Colleagues
>> 
>> The chairs agree that there is a consensus to set up an NWI to create
>> the "geoloc:" attribute in the RIPE Database. We therefore ask the
>> RIPE NCC to set up "NWI-13 Create a "geoloc:" attribute in the RIPE
>> Database" Using the 'Problem statement' below. After the RIPE NCC
>> completes it's impact analysis we can finalise the 'Solution
>> definition'. The RIPE NCC can address any of the questions raised in
>> this discussion that they feel are relevant to the basic creation of
>> this attribute.
>> 
>> cheers
>> denis
>> co-chair DB-WG
>> 
>> 
>> Problem statement
>> 
>> Associating an approximate physical location with an IP address has
>> proven to be a challenge to solve within the current constraints of
>> the RIPE Database. Over the years the community has chosen to consider
>> addresses in the RIPE Database to relate to entities in the assignment
>> process itself, not the subsequent actual use of IP addresses after
>> assignment.
>> 
>> The working group is asked to consider whether the RIPE Database can
>> be used as a springboard for parties wishing to correlate geographical
>> information with IP addresses by allowing structured references in the
>> RIPE Database towards information outside the RIPE Database which
>> potentially helps answer Geo IP Location queries
>> 
>> The IETF is currently discussing an update to RPSL to add a new
>> attribute "geofeed: url". The url will reference a csv file containing
>> location data. Some users have already started to make use of this
>> feature via the "remarks: geofeed: url". It is never a good idea to
>> try to overload structured data into the free format "remarks:"
>> attribute. This has been done in the past, for example with abuse
>> contact details before we introduced the "abuse-c:" attribute. There
>> is no way to regulate what database users put into "remarks:"
>> attributes. So even if the new "geofeed:" attribute is not agreed, the
>> url data will still be included in the RIPE Database.
>> 
>> Currently there are 24,408 INETNUM and 516,354 INET6NUM objects
>> containing a "geoloc:" attribute in the database. These have 7,731
>> distinct values in the INETNUMs and 1,045 distinct values in the
>> INET6NUMs. There are about 150 objects in the RIPE Database with a
>> "remarks: geoloc url" attribute.
>> 
>> On Wed, 7 Apr 2021 at 04:29, denis walker <ripedenis at gmail.com> wrote:
>>> 
>>> HI Massimo
>>> 
>>> I just checked the numbers Ed gave me and I misread the message. These
>>> are the numbers of objects with a "geoloc:" attribute not geofeed :(
>>> 
>>> cheers
>>> denis
>>> co-chair DB-WG
>>> 
>>> On Wed, 7 Apr 2021 at 02:56, Massimo Candela <massimo at us.ntt.net> wrote:
>>>> 
>>>> Hi Denis,
>>>> 
>>>> 
>>>> On 07/04/2021 02:02, denis walker wrote:
>>>>> Your data does not match the data I got from the RIPE NCC...
>>>>> 
>>>>> From the RIPE NCC:
>>>>> 
>>>>> Currently there are 24,408 INETNUM and 516,354 INET6NUM objects
>>>>> containing a "remarks: geofeed: url" attribute in the database. These
>>>>> have 7,731 distinct values in the INETNUMs and 1,045 distinct values
>>>>> in the INET6NUMs.
>>>> 
>>>> 
>>>> I cannot reproduce what you did.
>>>> Even if I just "grep -i geofeed" in ripe.db.inetnum.gz from the ripe ncc
>>>> ftp [1], I obtain only 132 items. And 39 in ripe.db.inet6num.gz. The
>>>> same if I use the complete dump [2].
>>>> 
>>>> Is the data in the FTP wrong? Am I doing something wrong?
>>>> 
>>>> Ciao,
>>>> Massimo
>>>> 
>>>> [1] https://ftp.ripe.net/ripe/dbase/split/
>>>> [2] https://ftp.ripe.net/ripe/dbase/ripe.db.gz
>