[db-wg] New NWI for geofeed?

On 05/05/2021 21:11, Cynthia Revström via db-wg wrote:

I'd like to ask for a clarification to section 4 specifically:

    Both the address ranges of the signing certificate and of the
    inetnum: MUST cover all prefixes in the geofeed file; and the address
    range of the signing certificate must cover that of the inetnum:.

    An address range A 'covers' address range B if the range of B is
    identical to or a subset of A.  'Address range' is used here because
    inetnum: objects and RPKI certificates need not align on CIDR prefix
    boundaries, while those of geofeed lines must.

What if you have a /16 as recorded by inetnum: as well as an RPKI 
certificate for that /16 but within the /16 there is a /24 that has been 
assigned to some other ASN?  Can you publish a geofeed file for the /16?

What if there is no inetnum: listed for that /24 yet in the global BGP 
tables there is an announcement of that /24 from a different ASN - would 
you still accept the geofeed announcement for the /16 based on inetnum: 
and RPKI cert?

Regards,
Hank



> Hi Ed,
> 
> This looks good to me :)
> 
> -Cynthia
> 
> On Tue, May 4, 2021 at 10:36 PM Edward Shryane via db-wg <db-wg at ripe.net> 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
>>>
>>
>>
>