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 > > > >
