Hi Authors, OPSAWG,
Please see my AD review comments for draft-ietf-opsawg-9092-update-08. My focus was on the diff between the latest draft and RFC 9092. I only have some relatively minor comments. Minor level comments: (1) p 4, sec 3. inetnum: Class Any particular inetnum: object SHOULD have, at most, one geofeed reference, whether a remarks: or a proper geofeed: attribute when it is implemented. If there is more than one, the geofeed: attribute SHOULD be used. I don't find this text as clear as it could be. Given the recommendation is to have a single geofeed reference, then I think that it would be helpful to provide guidance as to what format that geofeed reference should take. I.e., I presume that the geofeed reference SHOULD also use the geofeed: attribute format if the RIR supports it or the remarks attribute otherwise? (2) p 9, sec 6. Operational Considerations The geofeed files MUST be published via and fetched using HTTPS [RFC9110]. Also note you have a similiar RFC 2119 statement in section 4, and I wonder whether it would be clearer to only have the formal requirement listed in one place and referenced from the other place? (3) p 9, sec 6. Operational Considerations The geofeed files MUST be published via and fetched using HTTPS [RFC9110]. It is interesting that the geofeed files MUST be fetched using HTTPS, but earlier the RIR's FTP SHOULD be used to gather the geofeed references. Presumably if the RIR data was available via HTTPS that could also be used? (4) p 11, sec 9. Security Considerations The consumer of geofeed data SHOULD fetch and process the data themselves. Importing datasets produced and/or processed by a third- party places ill-advised trust in the third-party. This feels like quite a strong statement to make, and I wonder whether it won't be better to just point out the risks of using a third-party and then allow the reader to decide whether to accept that risk? Nit level comments: (5) p 7, sec 5. Authenticating Geofeed Data (Optional) Identifying the private key associated with the certificate and getting the department that controls the private key (which might be stored in a Hardware Security Module (HSM)) to generate the CMS signature is left as an exercise for the implementor. On the other hand, verifying the signature has no similar complexity; the certificate, which is validated in the public RPKI, contains the needed public key. The RPKI trust anchors for the RIRs are expected to already be available to the party performing signature validation. Validation of the CMS signature over the geofeed file involves: involves: => "involves the following steps:", or you need to change back Obtain ... => Obtaining ..., etc. Regards, Rob
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
