Subject: [Last-Call] Intdir last call review of draft-ietf-opsawg-finding-geofeeds-08

From: Jean-Michel Combes via Datatracker <[email-masked]>
Date: Fri, 14 May 2021 14:15:34 -0700

Reviewer: Jean-Michel Combes
Review result: Ready with Issues

Hi,

Please find my review, as member of the INT Area Directorate, of the following
document:

*** GENERAL COMMENT(S)/QUESTION(S) ***
o RPSL
Warning: I am not a RPSL expert

*** DEEP REVIEW ***
Network Working Group                                            R. Bush
Internet-Draft                                              IIJ & Arrcus
Intended status: Standards Track                              M. Candela

<JMC>
IMHO, the Intended status of this document should not be “Standard Track” but
“Experimental”. Indeed: (1) RFC8805 status is Informational (2) Many solutions
are proposed for a single problem (i.e., remarks: attribute v.s. geofeed:
attribute) (2) Authors of this document “leave global agreement of RPSL
modification to the relevant parties” (sic) (3) This document doesn’t update
officially RFC2622/RFC4012 (4) There is at least an experimentation (i.e.,
geofeed-finder) </JMC>

                     Finding and Using Geofeed Data
                 draft-ietf-opsawg-finding-geofeeds-08

Abstract

   This document describes how to find and authenticate geofeed data.

<JMC>
This abstract is too short for me ...
Potential new text (don’t hesitate to modify it):
A network operator can publish a mapping of IP address prefixes to simplified
geolocation information, colloquially termed a "geolocation feed" or “geofeed”.
This document describes solutions to add geofeed data inside RPSL based
database. This document also describes a solution, based on RPKI, to
authenticate geofeed data. </JMC>

<snip>

1.  Introduction

<snip>

   This document specifies how to augment the Routing Policy
   Specification Language (RPSL) [RFC4012] inetnum: class to refer

<JMC>
s/[RFC4012]/[RFC2622]
BTW, have you an IETF reference regarding the inetnum: class?
Because, the term “inetnum” is neither inside RFC2622 nor RFC4012.
</JMC>

   specifically to geofeed data CSV files, and how to prudently use
   them.  In all places inetnum: is used, inet6num: should also be
   assumed [RFC4012].

<snip>

3.  inetnum: Class

<snip>

   Ideally, RPSL would be augmented to define a new RPSL geofeed:
   attribute in the inetnum: class.  Until such time, this document
   defines the syntax of a Geofeed remarks: attribute which contains an
   HTTPS URL of a geofeed file.  The format of the inetnum: geofeed
   attribute MUST be as in this example, "remarks: Geofeed ", where the
   token "Geofeed" is case sensitive, followed by a URL which will vary,

<JMC>
s/the token "Geofeed" is case sensitive/ the token "Geofeed" MUST be case
sensitive s/followed by a URL/and MUST be followed by a URL </JMC>

   but MUST refer only to a single [RFC8805] geofeed file.

       inetnum: 192.0.2.0/24 # example
       remarks: Geofeed https://example.com/geofeed.csv

   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

<JMC>
s/be simply "geofeed: "/MUST be simply "geofeed: "
s/followed by a URL/and MUST be followed by a URL
</JMC>
   MUST refer only to a [RFC8805] geofeed file.

       inetnum: 192.0.2.0/24 # example
       geofeed: https://example.com/geofeed.csv

<snip>

   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 not only implies that the RIRs
   support the geofeed: attribute, but that all registrants have
   migrated any inetnum:s from remarks: use to geofeed:s.

<JMC>
IMHO, the MUST should not be associated to service users but to the RIRs.
Potential new text (don’t hesitate to modify it):
Until all registrants, for a specific RIR, have migrated any inetnum: from
remarks: use to geofeed: use, this RIR MUST support both the remarks: and
geofeed: forms. Moving this paragraph inside Operationnal Considerations
section? </JMC>

   Currently, the registry data published by ARIN is not the same RPSL
   as the other registries; therefore, when fetching from ARIN via FTP

<JMC>
Maybe add RFC7485 as reference?
</JMC>

   "NetRange" attribute/key MUST be treated as "inetnum" and the
   "Comment" attribute MUST be treated as "remarks".

<snip>

5.  Operational Considerations

<snip>

   The geofeed files SHOULD be published over and fetched using https
   [RFC8446].

<JMC>
s/[RFC8446]/[RFC2818]
</JMC>

Thanks in advance for your replies.

Best regards,

JMC.

---

From: Randy Bush <[email-masked]>
Date: Fri, 14 May 2021 19:36:49 -0700

> A network operator can publish a mapping of IP address prefixes to
> simplified geolocation information, colloquially termed a "geolocation
> feed" or “geofeed”.  This document describes solutions to add geofeed
> data inside RPSL based database.

except it doesn't.  all it does is add a pointer from two classes of
rpsl objects to actual geofeed data.

but, yes, the abstract might have more text.  e.g. the paragraph from
the intro

   them.

i generally do not like abstract == intro, but will hack it.

   This document specifies how to augment the Routing Policy
   Specification Language inetnum: class to refer specifically to
   geofeed data CSV files, and describes an optional scheme to use the
   Routing Public Key Intrastructure to authenticate the geofeed data
   CSV files.

> Because, the term “inetnum” is neither inside RFC2622 nor RFC4012.

for me, C-s finds inetnum in 2622 and inet6num in 4012

but i'll take this as a request to put the 2622 cite back.  thanks.

   Ideally, RPSL would be augmented to define a new RPSL geofeed:
   attribute in the inetnum: class.  Until such time, this document
   defines the syntax of a Geofeed remarks: attribute which contains an
   HTTPS URL of a geofeed file.  The format of the inetnum: geofeed
   remarks: attribute MUST be as in this example, "remarks: Geofeed ",
   where the token "Geofeed" MUST be case-sensitive, followed by a URL
   which will vary, but MUST refer only to a single [RFC8805] geofeed
   file.

> IMHO, the MUST should not be associated to service users but to the

it is the consumer who must deal with variance between RIRs, and even
between objects in an RIR.

i do not think you want to get into the space of telling RIRs what they
MUST do.  they make the ICANN look friendly.

> Until all registrants, for a specific RIR, have migrated any inetnum:
> from remarks: use to geofeed: use, this RIR MUST support both the
> remarks: and geofeed: forms.

support in what way?

i suspect what you may intend is that an RIR may publish a mix of the
remarks: form and the geofeed: form.  i am certainly not going to say
that they MUST.

but i tossed this in

   Registries MAY, for the interim, provide a mix of the remarks:
   attribute form and the geofeed: attribute form.

> Maybe add RFC7485 as reference?

do i have to do it without snark? :)

   Currently, the registry data published by ARIN is not the same RPSL
   as that of the other registries (see [RFC7485] for a survery of the
   whois Tower of Babel); therefore, when fetching from ARIN via FTP

>    The geofeed files SHOULD be published over and fetched using https

yup

randy