Randy:

>> 
>> 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 was not suggesting a new placement, just the edit to the last line.

>> 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

I propose adding that to the bottom of the paragraph that starts:

   If and only if the geofeed file is not signed per Section 5, ...

By doing that, it does not conflict with the requirement in Section 5 that the 
address range of the signing certificate cover all prefixes in the signed 
geofeed file.

Russ
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Reply via email to