Re: [Sidrops] Interim Meeting Follow-up Mail

[Stephen Kent <[e-mail]>]

Tim,

I revised the text of 6.4 and 6.7 to address the issues you cited. See 
below:

6.4.Acquiring Files Referenced by a Manifest

The RP MUST acquire all of the files enumerated in the manifest

(fileList) from the publication point. If there are files listed in

the manifest that cannot be retrieved from the publication point, or

if they fail the validity tests specified in [RFC6488], the fetch has

failed and the RP MUST proceed to Section 6.7; otherwise, proceed to

Section 6.5. Note that all RPs MUST be able to process Manifests,

CRLs and Resource Certificates [RFC6487], BGPsec Router Certificates

{RFC8209], Ghostbuster Records [RFC6493], and ROAs [RFC6482]. The

set of retrieved objects may include other RPKI object types that the

    RPis not prepared to process. When such objects are encountered by an

RP, the RP MUST NOT attempt to validate the eContent (as described in

Section 2.1.3.2 above) of such objects; encountering such objects does

not, per se, result in a failed fetch.



6.7.Failed Fetches

If a fetch fails for any of the reasons cited in 6.2-6.6, the RP MUST

issue a warning indicating the reason(s)for termination of processing

with regard to this CA instance.It is RECOMMENDED that a human

operator be notified of this warning.

Termination of processing means that the RP SHOULD continue to use

cached versions of the objects associated with this CA instance,

until such time as they become stale or they can be replaced by

objects from a successful fetch.This implies that the RP MUST not

try to acquire and validate subordinate signed objects, e.g.,

subordinate CA certificates, until the next interval when the RP is

scheduled to fetch and process data for this CA instance.