thanks for review, paul
> #1 document track
>
> The document is Standards Track, and so are the docs is
> Obsoletes/Updates ([RFC2725] and [RFC4012]), but the document also
> claims "change control effectively lies in the operator community".
> Normally, that would mean the IETF publishes this as Informational.
> But of course that would raise the issue that an Informational would
> Obsolete a Standards Track document. Some discussion on this would be
> good.
please differentiate between change control of the document, and of
RPSL. the ietf abandoned RPSL decades ago.
> #2 Transport Security
>
> There are quite a few sentences scattered through the document about
> transport security that are not aligned, see:
>
> The URL uses HTTPS, so the WebPKI provides authentication
>
> So is HTTPS mandatory? I guess not since (see below) FTP is allowed as
> URL too.
please differentiate between
- fetching a geofeed file pointed to by an inetnum: https url, and
- fetching the rirs's published archive of all inetnums: and other
rpsl objects
> the RIR's FTP [RFC0959] services SHOULD be used
that is bulk fetching the rpsl, not the geofeed
> More seriously, can we avoid SHOULDing the FTP protocol?
> Are these resources not made available over HTTP?
one at a time with tweezers. don't do that.
> Note the paragraph above it says: "Historically, [...] often without
> consistent authentication". I wouldn't call that "Historically" if you
> are are promoting FTP and allow "unsigned" files.
again, please differentiate between the bulk fetch of the rpsl via ftp
and the fetch of individual geofeed files via https.
> The geofeed files MUST be published via and fetched using HTTPS
> [RFC9110].
>
> Uhm. So what about FTP now?
again, please differentiate between the bulk fetch of the rpsl via ftp
and the fetch of individual geofeed files via https.
> The Security Considerations could bundle all the talk about HTTPS and
> FTP and put in one clear clause here, mentioning that due to lack of
> universal signing, it is sadly super important to have transport
> security protection (eg HTTPS, not FTP)
again, the differentiateion between the rpsl data and the geofeed files
is critical.
> #3 Signature and white space requirements are a bit troubling
> #4 Misc. Security comments
more on these later, when russ has had a chance to comment
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Since geofeed_1 contains geolocation data about 192.0.2.0/29,
> it is discarded because 192.0.2.0/24 is within the more specific
> inetnum: covering the address range and that inetnum: has a
> geofeed reference.
>
> This reads a bit odd, a 192.0.2.0/29 comes out of nowhere. I guess you
> meant to say "a client looking for geofeed data for 192.0.2.0/29" ?
how about
An application looking for geofeed data for 192.0.2.0/29, MUST
ignore data in geofeed_1 because 192.0.2.0/29 is within the
more specific 192.0.2.0/24 inetnum: covering that address range
and that inetnum: does have a geofeed reference.
randy
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
