kent hacking along

draft-ietf-sidrops-6486bis.xml

@@ -10,7 +10,7 @@
 <?rfc compact="yes"?>
 <?rfc subcompact="no"?>
 
-<rfc category="std" docName="draft-ietf-sidrops-6486bis-00" updates="6486" ipr="trust200902">
+<rfc category="std" docName="draft-ietf-sidrops-6486bis-01" updates="6486" ipr="trust200902">
   
 <front>
     
@@ -706,14 +706,22 @@
 
       <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
-	any subordinate CA and EE certificates.  If there are files
+	point, or if they fail the validity tests specified in
-	listed in the manifest that cannot be retrieved from the
+	[RFC6488], the fetch has failed and the RP MUST proceed to <xref
-	publication point, or if they fail the validity tests specified
+	target="sect-6.7"/>; otherwise, proceed to <xref
-	in <xref target="RFC6488"/>, the fetch has failed and the RP
+	target="sect-6.5"/>. Note that all RPs MUST be able to process
-	MUST proceed to <xref target="sect-6.7"/>; otherwise, proceed to
+	Manifests, CRLs and Resource Certificates <xref
-	<xref target="sect-6.5"/>.
+	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 Section 2.1.3.2 above) of such
+	objects; encountering such objects does not, per se, result in a
+	failed fetch.
       </t>
     </section>
 
@@ -744,26 +752,24 @@
     <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 <xref
-	acquire current valid instances of all of the objects enumerated
+      target="sect-6.2"/>-<xref target="sect-6.6"/>, the RP MUST issue a
-	in a current valid manifest as a result of a fetch, then
+      warning indicating the reason(s) for termination of processing
-	processing of the signed objects associated with the CA instance
+      with regard to this CA instance.  It is RECOMMENDED that a human
-	has failed for this fetch cycle. The RP MUST issue a warning
+      operator be notified of this 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
+	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>
 
   </section>
@@ -891,10 +897,13 @@
     <?rfc include="reference.RFC.2119"?>
     <?rfc include="reference.RFC.5280"?>
     <?rfc include="reference.RFC.6481"?>
+    <?rfc include="reference.RFC.6482"?>
     <?rfc include="reference.RFC.6485"?>
     <?rfc include="reference.RFC.6487"?>
     <?rfc include="reference.RFC.6488"?>
+    <?rfc include="reference.RFC.6493"?>
     <?rfc include="reference.RFC.8174"?>
+    <?rfc include="reference.RFC.8209"?>
     <reference anchor="X.690">
     <front>
     <title>ASN.1 encoding rules: Specification of basic encoding Rules (BER), Canonical encoding rules (CER) and Distinguished encoding rules (DER)</title>