Re: [OPSAWG] Paul Wouters' Discuss on draft-ietf-opsawg-9092-update-10: (with DISCUSS and COMMENT)

[Randy Bush <[e-mail]>]

> 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