hi rob,
thanks for review. appreciated.
> (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?
Any particular inetnum: object SHOULD have, at most, one geofeed
reference, whether a remarks: or a proper geofeed: attribute
when it is implemented. A geofeed: attribute is preferred, of
course, if the RIR supports it. If there is more than one type
of attribute in the intetnum: object, the geofeed: attribute
SHOULD be used.
> (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?
sure. removed the one in ยง4
> (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?
this refers to RIRs providing *bulk* ftp, i.e. get the whole shebang in
one slurp. can not do that for the geofeed files that are referenced.
xref GEOFEED-FINDER does provide bulk retrieval of the geofeed files.
> (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?
that is why it is SHOULD not MUST, tempting though a MUST may be. there
is a general problem of lack of understanding of trust boundaries in a
lot of these ops data. if you do not mind, i think we would leave it
in.
> (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.
sharp eye there. i went with obtaining; gerundification :)
want me to push this as a -09, or let it mellow?
again, thanks.
randy
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
