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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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
