> Suggested edits: > > The address range of the signing certificate MUST cover all prefixes > in the signed geofeed file. If not, the authenticator is invalid. > > The signing certificate MUST NOT include the Autonomous System > Identifier Delegation certificate extension [RFC3779]. If it is > present, the authenticator is invalid. > > As with many other RPKI signed objects, the IP Address Delegation > certificate extension MUST NOT use the "inherit" capability defined > in Section 2.2.3.5 of [RFC3779]. If "inherit" is used, the > authenticator is invalid.
sure > The consumer of geofeed data SHOULD fetch and process the data > themselves. Importing datasets produced and/or processed by a third- > party places significant trust in the third-party. this is in sec cons already. you want it moved up or duplicated? i kinda like it where it is, but am flexible. > I think is is probably better to drop the following from Section 6: > > When using data from a geofeed file, one MUST ignore data outside the > referring inetnum: object's inetnum: attribute address range. this is meant for an unsigned file. e.g. multiple diverse inetnum:s refer to the single geofeed file https://rg.net/geofeed. it allows an operator not signing to maintain one file. all geofeeds are not signed for a number of reasons o rpki data may not exist for some, cf. decades of difficulty getting rpki allowed by all RIRs. plus, you do not really want to tie the two operational processes together. o geofeed data are not critical. they just hints to geoloc obsessed content providers randy _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
