diff --git a/draft-ietf-sidrops-6486bis.xml b/draft-ietf-sidrops-6486bis.xml
index 32fa2ed..91d38ea 100644
--- a/draft-ietf-sidrops-6486bis.xml
+++ b/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,
-	each object containing an EE certificate issued by the CA, and
-	any subordinate CA and EE certificates.  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 <xref target="RFC6488"/>, the fetch has failed and the RP
-	MUST proceed to <xref target="sect-6.7"/>; otherwise, proceed to
+	(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 <xref target="RFC6488"/>,
+	the fetch has failed and the RP MUST proceed to Section 6.7; otherwise,
+	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
-	acquire current valid instances of all of the objects enumerated
-	in a current valid manifest as a result of a fetch, then
-	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
+	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.
       </t>
 
       <t>
-	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.
+	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.
       </t>
     </section>