-11 pushed with massimo suggestion dealing with iesg reviews

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-10"
+<rfc category="std" docName="draft-ietf-opsawg-9092-update-11"
      submissionType="IETF" consensus="true" ipr="trust200902"
      obsoletes="9092" version="2" >
 
@@ -17,7 +17,7 @@
     <title abbrev="Finding and Using Geofeed Data">Finding and Using Geofeed Data</title>
     
     <author fullname="Randy Bush" initials="R." surname="Bush">
-      <organization>IIJ &amp; Arrcus</organization>
+      <organization>IIJ Research &amp; Arrcus</organization>
       <address>
         <postal>
           <street>5147 Crystal Springs</street>
@@ -224,7 +224,8 @@
         modified and extensively enhanced in the Regional Internet
         Registry (RIR) community, mostly by RIPE <xref target="RIPE-DB"
         format="default"/>.  At the time of publishing this document,
-        change control effectively lies in the operator community.
+        change control of RPSL effectively lies in the operator
+        community.
       </t>
 
       <t>
@@ -278,9 +279,8 @@
       <t>
         Until all producers of inetnum: objects, i.e., the RIRs, state
         that they have migrated to supporting a geofeed: attribute,
-        consumers looking at inetnum: objects to find geofeed URLs
+        consumers looking at inetnum: objects to find geofeed URLs MUST
-        MUST be able to consume both the remarks: and
+        be able to consume both the remarks: and geofeed: forms.
-        geofeed: forms.
       </t>
 
       <t>
@@ -292,15 +292,17 @@
       <t>
         Any particular inetnum: object SHOULD have, at most, one geofeed
         reference, whether a remarks: or a proper geofeed: attribute
-        when it is implemented.  A geofeed: attribute is preferred, of
+        when it is implemented.  As the remarks: form can not be
-        course, if the RIR supports it.  If there is more than one type
+        formally checked by the RIR, this can not be formally enforced.
-        of attribute in the intetnum: object, the geofeed: attribute
+        A geofeed: attribute is preferred, of course, if the RIR
-        SHOULD be used.
+        supports it.  If there is more than one type of attribute in the
+        intetnum: object, the geofeed: attribute MUST be used.
       </t>
       <t>
-        For inetnum:s covering the same address range, or an inetnum:
+	For inetnum:s covering the same address range, a signed geofeed
-        with both remarks: and geofeed: attributes, a signed geofeed
+	file MUST be preferred over an unsigned file.  If none are
-        file SHOULD be preferred over an unsigned file.
+	signed, or more than one is signed, the (signed) inetnum: with
+	the most recent last-modified: attribute MUST be preferred.
       </t>
       <t>
         If a geofeed file describes multiple disjoint ranges of IP
@@ -315,17 +317,8 @@
         more than one registry.
       </t>
       <t>
-        When geofeed references are provided by multiple inetnum:
+        When fetching, the most specific inetnum: object with a geofeed
-        objects that have identical address ranges, then the geofeed
+        reference MUST be used.
-        reference on the inetnum: with the most recent last-modified:
-        attribute SHOULD be preferred.
-      </t>
-      <t>
-        As inetnum: objects form a hierarchy, geofeed references
-        SHOULD be at the lowest applicable inetnum:
-        object covering the relevant address ranges in the referenced
-        geofeed file.  When fetching, the most specific inetnum: object
-        with a geofeed reference MUST be used.
       </t>
       <t>
         It is significant that geofeed data may have finer granularity
@@ -360,11 +353,17 @@
       </t>
 
       <t>
-        When reading data from the geofeed file, one MUST ignore data
+        When reading data from an unsigned geofeed file, one MUST ignore
-        outside the referring inetnum: object's address range.  This is
+        data outside the referring inetnum: object's address range.
-        to avoid importing data about ranges not under the control of
+        This is to avoid importing data about ranges not under the
-        the operator.  If geofeed files are fetched, other location
+        control of the operator.  Note that signed files MUST only
-        information from the inetnum: MUST be ignored.
+	contain prefixes within the referring inetnum:'s range as
+	mandated in <xref target="auth"/>.
+      </t>
+      
+      <t>
+	If geofeed files are fetched, other location information from
+	the inetnum: MUST be ignored.
       </t>
 
       <t>
@@ -379,10 +378,10 @@
     inetnum: 192.0.2.0/24 # example
     remarks: Geofeed https://example.com/geofeed_2
     ]]></sourcecode>
-         Since geofeed_1 contains geolocation data about 192.0.2.0/29,
+         An application looking for geofeed data for 192.0.2.0/29, MUST
-         it is discarded because 192.0.2.0/24 is within the more
+         ignore data in geofeed_1 because 192.0.2.0/29 is within the
-         specific inetnum: covering the address range and that inetnum:
+         more specific 192.0.2.0/24 inetnum: covering that address range
-         has a geofeed reference.
+         and that inetnum: does have a geofeed reference.
       </t>
 
       <t>
@@ -484,25 +483,34 @@
 
       <t>
 	The address range of the signing certificate MUST cover all
-	prefixes in the signed geofeed file.  The signing certificate
+	prefixes in the signed geofeed file.  If not, the authenticator
-	MUST NOT include the Autonomous System Identifier Delegation
+	is invalid.
-	certificate extension <xref target="RFC3779"/>.
+      </t>
+      <t>
+	The signing certificate MUST NOT include the Autonomous System
+	Identifier Delegation certificate extension <xref
+	target="RFC3779"/>.  If it is present, the authenticator is
+	invalid.
       </t>
 
       <t>
         As with many other RPKI signed objects, the IP Address
         Delegation certificate extension MUST NOT use the "inherit"
         capability defined in Section 2.2.3.5 of <xref
-        target="RFC3779"/>.  An IP Address Delegation extension using
+        target="RFC3779"/>.  If "inherit" is used, the authenticator is
-        "inherit" would complicate processing.  The implementation would
+        invalid.
-        have to build the certification path from the end-entity to the
+	</t>
-        trust anchor, then validate the path from the trust anchor to
+      <t>
-        the end-entity, and then the parameter would have to be
+	An IP Address Delegation extension using "inherit" would
-        remembered when the validated public key was used to validate a
+	complicate processing.  The implementation would have to build
-        signature on a CMS object.  Having to remember things from
+	the certification path from the end-entity to the trust anchor,
-        certification path validation for use with CMS object processing
+	then validate the path from the trust anchor to the end-entity,
-        would be quite complex and error prone.  And, the certificates
+	and then the parameter would have to be remembered when the
-        do not get that much bigger by repeating the information.
+	validated public key was used to validate a signature on a CMS
+	object.  Having to remember things from certification path
+	validation for use with CMS object processing would be quite
+	complex and error prone.  And, the certificates do not get that
+	much bigger by repeating the information.
       </t>
 
       <t>
@@ -773,7 +781,7 @@
       <t>
         The consumer of geofeed data SHOULD fetch and process the data
         themselves.  Importing datasets produced and/or processed by a
-        third-party places ill-advised trust in the third-party.
+        third-party places significant trust in the third-party.
       </t>
       <t>
         As mentioned in <xref target="auth" format="default"/>, some