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.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
