From 0c948f190deb6da5a2d3773980074245a98fa3a6 Mon Sep 17 00:00:00 2001
From: Randy Bush <randy@psg.com>
Date: Mon, 16 Oct 2023 11:05:01 -0700
Subject: [PATCH] -05 published with massimo's hacks

---
 draft-ietf-opsawg-9092-update.xml | 26 ++++++++++++++------------
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/draft-ietf-opsawg-9092-update.xml b/draft-ietf-opsawg-9092-update.xml
index 06cc833..67d0708 100644
--- a/draft-ietf-opsawg-9092-update.xml
+++ b/draft-ietf-opsawg-9092-update.xml
@@ -136,7 +136,8 @@
             remarks: attribute and a geofeed: attribute.
           </li>
 	  <li>
-	    Rewrite Authentication section to be more formal.
+	    Rewrite Authentication <xref target="auth"/> to be more
+	    formal.
 	  </li>
           <li>
             Geofeed file only UTF-8 CSV.
@@ -341,8 +342,8 @@
       </t>
 
       <t>
-        Historically, before geofeed files, this was done in varied
-        ways, at the discretion of the implementer, often without
+        Historically, before <xref target="RFC9092"/>, this was done in
+        varied ways, at the discretion of the implementer, often without
         consistent authentication, where data were mostly imported from
         email without formal authorisation or validation.
       </t>
@@ -350,9 +351,9 @@
       <t>
         To minimize the load on RIRs' WHOIS <xref target="RFC3912"/>
         services, the RIR's FTP <xref target="RFC0959"/> services SHOULD
-        be used for large-scale access to gather geofeed URLs.  This
-        uses efficient bulk access instead of fetching via brute-force
-        search through the IP space.
+        be used for large-scale access to gather inetnum:s with geofeed
+        references.  This uses efficient bulk access instead of fetching
+        via brute-force search through the IP space.
       </t>
 
       <t>
@@ -678,12 +679,13 @@
       </t>
 
       <t>
-        Harvesting and publishing aggregated geofeed data outside of
-        the RPSL model should be avoided as it can have the effect
-        that more specifics from one aggregatee could undesirably
-        affect the less specifics of a different aggregatee.  The
-        validation model in Section <xref target="auth"/> handles this
-        issue within the RPSL model.
+        Harvesting and publishing aggregated geofeed data outside of the
+        RPSL model should be avoided as it can have the effect that more
+        specifics from one aggregatee could undesirably affect the less
+        specifics of a different aggregatee.  Moreover, publishing
+        aggregated geofeed data prevents the reader of the data to
+        perform the checks described in <xref target="fetch"/> and <xref
+        target="auth"/>.
       </t>
       <t>
         Currently, geolocation providers have bulk WHOIS data access at