Subject: Re: [Gen-art] Gen-ART Last Call review of draft-ietf-opsawg-finding-geofeeds-06

From: Randy Bush <[email-masked]>
Date: Tue, 04 May 2021 14:37:42 -0700

paul,

i believe it was you who was wondering about the ops community process
and progress getting this draft implemented.  as part of the RIPE
process, the RIPE/NCC, who has to actually implement this stuff, issues
an impact report.  i thought it might be informative.

randy

From: Edward Shryane via db-wg <[email-masked]>
Subject: Re: [db-wg] New NWI for geofeed?
To: denis walker <[email-masked]>
Cc: Database WG <[email-masked]>
Date: Tue, 4 May 2021 22:35:56 +0200

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-masked]> 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.
>

---

From: Lars Eggert <[email-masked]>
Date: Wed, 12 May 2021 11:32:51 +0300

Paul, thank you for your review and thank you all for the following discussion. I have entered a No Objection ballot for this document.

Lars

> On 2021-4-29, at 19:57, Paul Kyzivat <[email-masked]> wrote:
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> Document: draft-ietf-opsawg-finding-geofeeds-06
> Reviewer: Paul Kyzivat
> Review Date: 2021-04-29
> IETF LC End Date: 2021-05-04
> IESG Telechat date: ?
> 
> Summary:
> 
> This draft is on the right track but has open issues, described in the review.
> 
> General:
> 
> I'm not competent to review the crypto and security aspects of this document. Hopefully there will also be a security review to cover those.
> 
> Issues:
> 
> Major: 0
> Minor: 3
> Nits:  2
> 
> 1) Minor: Definition of "remarks: Geofeed"
> 
> Section 3 says:
> 
>   ... The format of the inetnum: geofeed
>   attribute MUST be as in this example, "remarks: Geofeed" followed by
>   a URL ...
> 
> From the examples and common sense there should be a space preceding the URL. But the text doesn't mention this. I suggest changing to:
> 
>   ... The format of the inetnum: geofeed
>   attribute MUST be as in this example, "remarks: Geofeed " followed by
>   a URL ...
> 
> Also, is the word "Geofeed" case sensitive?
> 
> 2) Minor: Modification of RPSL
> 
> Section 3 says:
> 
>   While we leave global agreement of RPSL modification to the relevant
>   parties, we specify that a proper geofeed: attribute in the inetnum:
>   class be simply "geofeed: " followed by a URL which will vary, but
>   MUST refer only to a [RFC8805] geofeed file.
>   ...
>   Until all producers of inetnum:s, i.e. the RIRs, state that they have
>   migrated to supporting a geofeed: attribute, consumers looking at
>   inetnum:s to find geofeed URLs MUST be able to consume both the
>   remarks: and geofeed: forms.
> 
> This is a bit presumptive. You say you are leaving the RPSL modification to others, yet you are herein standardizing the exact form that modification must take. What if the relevant parties want to choose a different form?
> 
> ISTM that this document should only mandate support for the Remarks form and leave support of the modified RPSL form to later, after RPSL has been updated.
> 
> 3) Minor/Nit: IANA Considerations
> 
> I don't understand why this section is present. I don't find any reference of it within the document.
> 
> 4) NIT: Use of "awesome"
> 
> I'm not sure how to feel about using *awesome* in the Introduction. It seems unusually informal for a standards document. But in a way I also find it refreshing.
> 
> I just suggest you rethink about whether you want that. I'm good either way.
> 
> 5) Nit: IdNits
> 
> IdNits reports a number of things worth looking into. Notably the downrefs and the lack of an IPv6 example.
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art