[OPSAWG] AD review of draft-ietf-opsawg-9092-update-08

["Rob Wilton (rwilton)" <[e-mail]>]

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