[db-wg] New NWI for geofeed?

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