Hi all, > Coming out of 117, there was an action to put the 9092bis document up > for WG adoption. The authors have all responded that there is no > known IPR pertaining to this document. This document is an update to > the guidelines for finding and using geofeed data. > > Therefore, we would like to start a two week CfA for > https://datatracker.ietf.org/doc/draft-ymbk-opsawg-9092-update/. > Please reply on-list with your comments and whether or not you support > working on this document. The CfA will run until EOD on August 21, > 2023.
TL;DR - I support adoption of this document. A few suggestions for improvement of the document: 1/ In section 8 'Implementation Status', a reference could be added to https://www.rpki-client.org/. I extended this RPKI validator implementation to have the ability to cryptographically verify a given RPKI-signed Geofeed authenticator. Yay, running code! 2/ In section 5 it is unclear why RPKI-RTA and RFC 9323 are compared to each other in a subjective manner about perceived complexity. If anything, RFC9323 probably is simpler to implement (compared to RPKI-RTA), because of RFC9323's similarity to other pre-existing RPKI profiles. Both specifications facilitate RPKI signatures over a bare SHA256 digest, but RFC9323 also allows the signer to optionally include a filename (which could be a reference to the Geofeed file at hand). Multiple implementations exist. RPKI-RTA however appears to be an abandonded project, probably because the RTA proposal deviated significantly from RFC 6488, this deviation increases the burden on implementers because less previous implementation work can be leveraged. Suggestion: remove the RPKI-RTA reference, or perhaps just remove both RFC9323 and RPKI-RTA references, as the Geofeed specification itself already outlines a workable RPKI-based authenticator. 3/ It would be helpful if the specification provides clarity to implementers by mandating that the Autonomous System Identifier Delegation certificate extension MUST be absent. ASNs are not used in Geofeed data, and thus such an extension would serve no purpose on the Geofeed EE certificate. Other RPKI profile specifications nowadays are very specific about which of the RFC 3779 extensions are expected to be present or absent. 4/ The example EE certificate in Appendix A erroneously contains a superfluous Subject Information Access AccessDescription pointing towards a RRDP server. RRDP SIA ADs are only expected to appear on CA certificates, not on EE certs. See https://www.rfc-editor.org/errata/eid7239 for more information. I've prepared newly generated certificates which the authors could consider using: https://git.rg.net/randy/draft-9092update/pulls/1/files I also took the liberty to include a missing CRL, and update the example from IPv4 to IPv6 :-) In Closing/ Thanks for taking the time and effort to cross some t's and dot some i's on the Geofeed specification! Kind regards, Job _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
