> 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. 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 This document specifies how to augment the Routing Policy Specification Language (RPSL) [RFC4012] inetnum: class to refer specifically to geofeed data CSV files, and how to prudently use 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. > BTW, have you an IETF reference regarding the inetnum: class? > 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. > 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> 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. > 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. 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. > 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> 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 > [RFC8446]. > > <JMC> > s/[RFC8446]/[RFC2818] > </JMC> yup randy -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
