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.
- Rewrite Authentication section to be more formal.
+ Rewrite Authentication to be more
+ formal.
Geofeed file only UTF-8 CSV.
@@ -341,8 +342,8 @@
- Historically, before geofeed files, this was done in varied
- ways, at the discretion of the implementer, often without
+ Historically, before , 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.
@@ -350,9 +351,9 @@
To minimize the load on RIRs' WHOIS
services, the RIR's FTP 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.
@@ -678,12 +679,13 @@
- 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 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 and .
Currently, geolocation providers have bulk WHOIS data access at