[db-wg] New NWI for geofeed?

Hi Edward,

Perfect!

Thanks

On 04/05/2021 22:35, Edward Shryane via db-wg wrote:
> Hello Denis, Colleagues,
> 
> Following is the impact analysis for the implementation of the "geofeed:" attribute in the RIPE database, based on the problem statement below and the draft RFC:
> https://tools.ietf.org/html/draft-ymbk-opsawg-finding-geofeeds
> 
> I will ask our Legal team to conduct a full impact analysis of the implementation plan.
> 
> Please reply with corrections or suggestions.
> 
> Regards
> Ed Shryane
> RIPE NCC
> 
> 
> 
> Impact Analysis for Implementing the "geofeed:" Attribute
> ============================================================
> 
> 
> "geoloc:" Attribute
> ----------------------
> Implementing the "geofeed:" attribute does not affect the "geoloc:" attribute. No decision has been taken on the future of the "geoloc:" attribute, a review can be done at a later date.
> 
> "remarks:" Attribute
> -----------------------
> Existing "remarks:" attributes in INETNUM or INET6NUM object types containing a "geofeed: url" value will not be automatically converted to a "geofeed:" attribute.
> 
> The implementation will validate that an INETNUM or INET6NUM object may contain at most a single geofeed reference, either a "remarks:" attribute *or* a "geofeed:" attribute. More than one will result in an error on update.
> 
> Any "remarks:" attributes in other object types will not be validated for geofeed references.
> 
> "geofeed:" Attribute
> -----------------------
> The "geofeed:" attribute will be added to the INETNUM and INET6NUM object types. It will be an optional, singly occurring attribute.
> 
> The attribute value must consist only of a well-formed URL. Any other content in the attribute value will result in a syntax error.
> 
> "geofeed:" URL
> -----------------
> The URL in the "geofeed:" attribute will be validated that it is well-formed (i.e. syntactically correct).
> 
> The URL must use the ASCII character set only (in the RIPE database, non-Latin-1 characters will be substituted with a '?' character).
> 
> Non-ASCII characters in the URL host name must be converted to ASCII using Punycode in advance (before updating the RIPE database).
> 
> Non-ASCII characters in the URL path must be converted using Percent-encoding in advance.
> 
> Only the HTTPS protocol is supported in the URL, otherwise an error is returned.
> 
> The reachability of the URL will not be checked. The content of the URL will not be validated.
> 
> Database dump and Split files
> ----------------------------------
> The "geofeed:" attribute will be included in the nightly database dump and split files.
> 
> NRTM
> --------
> The "geofeed:" attribute will be included in INETNUM and INET6NUM objects in the NRTM stream.
> 
> Whois Queries
> -----------------
> The "geofeed:" attribute will appear by default in (filtered) INETNUM and INET6NUM objects in Whois query responses, no additional query flag will be needed.
> 
> RDAP
> -------------
> The "geofeed:" attribute will not appear in RDAP responses. A separate RDAP profile will be needed to extend the response format to include geofeed. This can be implemented at a later date.
> 
> Documentation
> ---------------
> The RIPE database documentation will be updated, including the inet(6)num object templates and attribute description (with a reference to the IETF draft document).
> 
> Other RIRs
> -------------
> There is currently no coordinated plan to implement "geofeed:" across regions. Other RIRs may implement "geofeed:" at a later date.
> 
> Legal Review
> ---------------
> An initial review by the RIPE NCC Legal team found that geofeed data may qualify as personal data, and before introducing the "geofeed:" attribute a full impact analysis of its implementation would have to be conducted by the 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
>>
> 
>