-07 published

draft-ietf-opsawg-9092-update.xml

@@ -8,7 +8,7 @@
 <?rfc compact="yes"?>
 <?rfc subcompact="no"?>
 
-<rfc category="std" docName="draft-ietf-opsawg-9092-update-06"
+<rfc category="std" docName="draft-ietf-opsawg-9092-update-07"
      submissionType="IETF" consensus="true" ipr="trust200902"
      obsoletes="9092" version="2" >
 
@@ -82,9 +82,10 @@
       <t>
         This document specifies how to augment the Routing Policy
         Specification Language inetnum: class to refer specifically to
-        geofeed data files and describes an optional scheme that uses
+        geofeed comma-separated values (CSV) data files and describes an
-        the Resource Public Key Infrastructure to authenticate the
+        optional scheme that uses the Resource Public Key Infrastructure
-        geofeed datafiles.
+        to authenticate the geofeed data files.  This document obsoletes
+        RFC 9092.
       </t>
 </abstract>
 
@@ -381,16 +382,10 @@
     inetnum: 192.0.2.0/24 # example
     remarks: Geofeed https://example.com/geofeed_2
     ]]></sourcecode>
-        and the file geofeed_1 contains geolocation data about
+         Since geofeed_1 contains geolocation data about 192.0.2.0/29,
-        192.0.2.0/29, this MUST be discarded because 192.0.2.0/24 is
+         it is discarded because 192.0.2.0/24 is within the more
-        within the more specific inetnum: covering the address range and
+         specific inetnum: covering the address range and that inetnum:
-        that inetnum: has a geofeed reference.
+         has a geofeed reference.
-      </t>
-
-      <t>
-        If an inetnum: object has both remarks: with geofeed data and
-        also has a geofeed: attribute, the geofeed: attribute SHOULD be
-        used and the remarks: ignored.
       </t>
 
       <t>
@@ -518,13 +513,13 @@
       </t>
 
       <t>
-	The CA SHOULD sign only one geofeed file with each generated
+	The Certificate Authority (CA) SHOULD sign only one geofeed file
-	private key and SHOULD generate a new key pair for each new
+	with each generated private key and SHOULD generate a new key
-	version of a perticular geofeed file.  The CA MUST generate a
+	pair for each new version of a perticular geofeed file.  The CA
-	new EE certificate for each signing of a particular geofeed
+	MUST generate a new End Entity (EE) certificate for each signing
-	file.  An associated EE certificate used in this fashion is
+	of a particular geofeed file.  An associated EE certificate used
-	termed a "one-time-use" EE certificate (see Section 3 of <xref
+	in this fashion is termed a "one-time-use" EE certificate (see
-	target="RFC6487"/>).
+	Section 3 of <xref target="RFC6487"/>).
       </t>
 
       <t>
@@ -551,7 +546,7 @@
 
 	<li>
 	  Validation of the signer's certificate MUST ensure that it is
-	  part of the current <xref target="RFC6486"/> manifest and that
+	  part of the current <xref target="RFC9286"/> manifest and that
 	  all resources are covered by the RPKI certificate.
 	</li>
 
@@ -652,7 +647,7 @@
       </t>
       <t>
         The geofeed files MUST be published via and fetched using
-        HTTPS <xref target="RFC2818" format="default"/>.
+        HTTPS <xref target="RFC9110" format="default"/>.
       </t>
       <t>
         When using data from a geofeed file, one MUST ignore data
@@ -824,15 +819,15 @@
       and Erik Kline who was too shy to agree to coauthorship.
       Additionally, we express our gratitude to early implementors,
       including Menno Schepers; Flavio Luciani; Eric Dugas; and Kevin
-      Pack.  Also, thanks to the following geolocation providers who
+      Pack.  Also, thanks to the following geolocation providers who are
-      are consuming geofeeds with this described solution: Jonathan
+      consuming geofeeds with this described solution: Jonathan Kosgei
-      Kosgei (ipdata.co), Ben Dowling (ipinfo.io), and Pol Nisenblat
+      (ipdata.co), Ben Dowling (ipinfo.io), and Pol Nisenblat
-      (bigdatacloud.com).  For an amazing number of helpful reviews,
+      (bigdatacloud.com).  For an amazing number of helpful reviews, we
-      we thank Job Snijders, who also found an ASN.1 'inherit' issue;
+      thank Job Snijders, who also found an ASN.1 'inherit' issue;
       Adrian Farrel; Antonio Prado; Francesca Palombini; Jean-Michel
       Combes (INTDIR); John Scudder; Kyle Rose (SECDIR); Martin Duke;
-      Murray Kucherawy; Paul Kyzivat (GENART); Rob Wilton; Roman
+      Mohamed Boucadair; Murray Kucherawy; Paul Kyzivat (GENART); Rob
-      Danyliw; and Ties de Kock.</t>
+      Wilton; Roman Danyliw; and Ties de Kock.</t>
     </section>
   </middle>
   <back>
@@ -841,7 +836,6 @@
       <?rfc include="reference.RFC.2119.xml"?>
       <?rfc include="reference.RFC.2622.xml"?>
       <?rfc include="reference.RFC.2725.xml"?>
-      <?rfc include="reference.RFC.2818.xml"?>
       <?rfc include="reference.RFC.3629.xml"?>
       <?rfc include="reference.RFC.3779.xml"?>
       <?rfc include="reference.RFC.4012.xml"?>
@@ -850,11 +844,12 @@
       <?rfc include="reference.RFC.5652.xml"?>
       <?rfc include="reference.RFC.8174.xml"?>
       <?rfc include="reference.RFC.6481.xml"?>
-      <?rfc include="reference.RFC.6486.xml"?>
       <?rfc include="reference.RFC.6487.xml"?>
       <?rfc include="reference.RFC.6488.xml"?>
       <?rfc include="reference.RFC.8805.xml"?>
       <?rfc include="reference.RFC.8933.xml"?>
+      <?rfc include="reference.RFC.9110.xml"?>
+      <?rfc include="reference.RFC.9286.xml"?>
     </references>
     
     <references title="Informative References">
@@ -888,7 +883,6 @@
           </front>
         </reference>
 
-
         <reference anchor="RIPE-DB" target="https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation">
           <front>
             <title>RIPE Database Documentation</title>
@@ -943,15 +937,17 @@
 
     <section title="Example" anchor="example">
       <t>
-   This appendix provides an example, including a trust anchor, 
+   This appendix provides an example, including a trust anchor, a
-   a CRL signed by the trust anchor, a CA certificate subordinate to
+   Certificate Revocation List (CRL) signed by the trust anchor, a CA
-   the trust anchor, a CRL signed by the CA, an end-entity certificate
+   certificate subordinate to the trust anchor, a CRL signed by the CA,
-   subordinate to the CA for signing the geofeed, and a detached signature.</t>
+   an end-entity certificate subordinate to the CA for signing the
+   geofeed, and a detached signature.</t>
 
    <t>
-   The trust anchor is represented by a self-signed certificate.  As usual in
+   The trust anchor is represented by a self-signed certificate.  As
-   the RPKI, the trust anchor has authority over all IPv4 address blocks,
+   usual in the RPKI, the trust anchor has authority over all IPv4
-   all IPv6 address blocks, and all AS numbers.</t>
+   address blocks, all IPv6 address blocks, and all Autonomous Systam
+   (AS) numbers.</t>
 
    <figure><artwork><![CDATA[
    -----BEGIN CERTIFICATE-----