Update section 6.4

Text from Stephen Kent, input from Tim Bruijnzeels

	Date: Thu, 29 Oct 2020 15:37:30 +0000
	From: Stephen Kent <stkent=40verizon.net@dmarc.ietf.org>
	To: Tim Bruijnzeels <tim@nlnetlabs.nl>
	Cc: sidrops@ietf.org
	Subject: Re: [Sidrops] Interim Meeting Follow-up Mail

draft-ietf-sidrops-6486bis.xml

@@ -706,15 +706,27 @@
 
       <t>
 	The RP MUST acquire all of the files enumerated in the manifest
-	(fileList) from the publication point. This includes the CRL,
+	(fileList) from the publication point. If there are files listed
-	each object containing an EE certificate issued by the CA, and
+	in the manifest that cannot be retrieved from the publication point,
-	any subordinate CA and EE certificates.  If there are files
+	or if they fail the validity tests specified in <xref target="RFC6488"/>,
-	listed in the manifest that cannot be retrieved from the
+	the fetch has failed and the RP MUST proceed to Section 6.7; otherwise,
-	publication point, or if they fail the validity tests specified
+	proceed to <xref target="sect-6.7"/>; otherwise, proceed to
-	in <xref target="RFC6488"/>, the fetch has failed and the RP
-	MUST proceed to <xref target="sect-6.7"/>; otherwise, proceed to
 	<xref target="sect-6.5"/>.
       </t>
+
+      <t>
+	Note that all RPs MUST be able to process Manifests, Note that
+	all RPs MUST be able to process Manifests, CRLs and Resource
+	Certificates <xref target="RFC6487"/>, BGPsec Router Certificates
+	<xref target="RFC8209"/>, Ghostbuster Records <xref target="RFC6493"/>,
+	and ROAs <xref target="RFC6482"/>. The set of retrieved objects may
+	include other RPKI object types that the RP is not prepared to process.
+	When such objects are encountered by an RP, the RP MUST NOT attempt to
+	validate the eContent (as described in
+	<xref target="sect-2.1">Section 2.1.3.2</xref> above) of such objects;
+	encountering such objects does not, per se, result in a failed fetch.
+      </t>
+
     </section>
 
     <section title="Matching File Names and Hashes" anchor="sect-6.5">
@@ -744,25 +756,20 @@
     <section title="Failed Fetches" anchor="sect-6.7">
 
       <t>
-	If an RP does not acquire a current valid manifest, or does not
+	If a fetch fails for any of the reasons cited in 6.2-6.6, the RP MUST
-	acquire current valid instances of all of the objects enumerated
+	issue a warning indicating the reason(s) for termination of processing
-	in a current valid manifest as a result of a fetch, then
+	with regard to this CA instance. It is RECOMMENDED that a human
-	processing of the signed objects associated with the CA instance
-	has failed for this fetch cycle. 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.
       </t>
 
       <t>
-	Termination of processing means that the RP SHOULD continue to
+	Termination of processing means that the RP SHOULD continue to use
-	use cached versions of the objects associated with this CA
+	cached versions of the objects associated with this CA instance,
-	instance, until such time as they become stale or they can be
+	until such time as they become stale or they can be replaced by
-	replaced by objects from a successful fetch. This implies that
+	objects from a successful fetch.This implies that the RP MUST not
-	the RP MUST not try to acquire and validate subordinate signed
+	try to acquire and validate subordinate signed objects, e.g.,
-	objects, e.g., subordinate CA certificates, until the next
+	subordinate CA certificates, until the next interval when the RP is
-	interval when the RP is scheduled to fetch and process data for
+	scheduled to fetch and process data for this CA instance.
-	this CA instance.
       </t>
     </section>