[OPSAWG] AD review of draft-ietf-opsawg-finding-geofeeds-04

["Rob Wilton (rwilton)" <[e-mail]>]

Hi,

Sorry for the delayed AD review.

Whilst I regard this document is useful, and a good thing (tm), I have a couple of concerns about the exact relationship between this document (std's track) and to RFC 8805, that is informational.


Main comments:

1. Specifically, I think that it would be useful for this document to offer more clarity as to whether the "remarks: Geofeed" tag specifically ties the content of the URL to a document in RFC 8805 format, or whether other formats may be found at that URL in future, noting that RFC 8805 section 7 suggests that a future format may be defined, and end of section 4 of this document also suggests that RFC 8805 may be updated.  If multiple formats, how does the client tell the difference.

2. I wasn't quite sure whether the mechanism for authenticating geofeed data really belonged in this document (e.g., because it applies to all possible forms of geofeed data), or whether it would it is specific to the CSV format described in RFC 8805, and that an update to that document would contain the canonical reference.

3. The definition of canonicalization refers to section 2.2 of RFC 5485 (which talks about ASCII) vs RFC8805 which talks about UTF-8.  Is this disparity an issue?

4. I think that INETNUM should be a normative reference, but I also question whether it is going to be a sufficiently stable reference?  Hence, I was wondering whether it wouldn't be helpful to describe the essence of the INETNUM hierarchy here to avoid a need for a normative reference.


Minor comments:

1. Introduction

   An optional, but utterly awesome, means for authenticating geofeed
   data is also defined.

I'm guessing that this might be Warren's prose, but it perhaps might be worth refining 'utterly awesome' to 'practical'?
   

2.  Geofeed Files

   The size of a file can be
   even larger if an unsigned geofeed file combines data for many
   prefixes, as may be likely if the location data are maintained by a
   different department than address management, dual IPv4/IPv6 spaces
   are represented, etc.
   
I'm not disputing this, but I wasn't sure why having different departments would increase the side of data.


   This document also suggests optional data for geofeed files to
   provide stronger authenticity to the data.

Would "optional signature data" be clearer than just "optional data"?


3.  inetnum: Class

   Until all producers of inetnum:s, i.e. the RIRs, state that they have
   migrated to supporting a geofeed: attribute, consumers looking at
   inetnum:s to find geofeed URLs MUST be able to consume both the
   remarks: and geofeed: forms.

Is there any possibility that the proper geofeed attribute won't be standardized as "geofeed:"?  I.e., this document refers to this attribute as "geofeed:", but the way that it is written it would end up being very
confusing if the "proper geofeed: attribute" was standardized as "geo-feed:" by referred to as "geofeed:" by this document.

I think that it would aid clarity, at a minimum, if it always at least referred to as the "proper geofeed: attribute", but it may better to just refer to it as the "proper geofeed attribute", i.e., to avoid binding the name used in this document to the proposed long term name?


   Any particular inetnum: object MAY have, at most, one geofeed
   reference, whether a remarks: or a proper geofeed: attribute when one
   is defined.

I think that this MAY should be a MUST, probably with the commas removed.  Otherwise, the constraint can be ignored.  E.g. NEW: 

   Any particular inetnum: object MUST have at most one geofeed
   reference, whether a remarks: or a proper geofeed: attribute when one
   is defined.


Although the draft does not allow a record to contain it, is it worth specifying what a client should do if it receives a record with both "remark: Geofeed" and the proper geofeed attribute?  E.g., should a client choose to use one in preference to the other?


   Currently, the registry data published by ARIN is not the same RPSL
   as the other registries; therefore, when fetching from ARIN via FTP
   [RFC0959], whois [RFC3912], RDAP [RFC7482], or whatever, the
   "NetRange" attribute/key must be treated as "inetnum" and the
   "Comment" attribute must be treated as "remarks".

Is there a reason why these are musts are not MUSTs?  Otherwise, could change from "must be treated" to "is treated" to avoid potential ambiguity.



   inetnum: objects form a hierarchy, see [INETNUM] Section 4.2.4.1,
   Hierarchy of INETNUM Objects.  Geofeed references SHOULD be at the
   lowest applicable inetnum: object.  When fetching, the most specific
   inetnum: object with a geofeed reference MUST be used.
   
As menionted earlier, is "Section 4.2.4.1" going to be a sufficiently stable reference?


   It is significant that geofeed data may have finer granularity than
   the inetnum: which refers to them.
   
This paragraph felt incomplete to me, i.e., I wasn't quite sure what it is trying to convey.


4.  Authenticating Geofeed Data

The text in this section feels a little bit colloquial to me.  As per above, is the intention that this defines the definitive signature encoding that would apply to all Geofeed files (if there is more than one format)?  Or would that we defined in an RFC8805 bis document?

E.g., perhaps change "it would be essentially" to "it is",
      And probably change "would be" to "is" in a few places.


   Both the address ranges of the signing certificate and of the
   inetnum: MUST cover all prefixes in the geofeed file; and the address
   range of the signing certificate must cover that of the inetnum:.

This could perhaps be more simply stated as, NEW:

   The address range of the signing certificate MUST cover that of the
   inetnum: and the address ranges of the inetnum: MUST cover all
   prefixes in the geofeed file.


   An address range A 'covers' address range B if the range of B is
   identical to or a subset of A.  'Address range' is used here because
   inetnum: objects and RPKI certificates need not align on CIDR prefix
   boundaries, while those of geofeed lines must.
   
Unclear what is meant by geofeed lines.  Does this mean entries in the geofeed csv?  Perhaps clarify.  Note, Geofeed lines is used in a couple of places in the document.


   Identifying the private key associated with the certificate, and
   getting the department with the HSM to sign the CMS blob is left as
   an exercise for the implementor.  On the other hand, verifying the
   signature requires no complexity; the certificate, which can be
   validated in the public RPKI, has the needed public key.
   
HSM - Hardware Security Module?  If so, please expand on first use.
  

   Until [RFC8805] is updated to formally define such an appendix, it
   MUST be 'hidden' as a series of "#" comments at the end of the
   geofeed file.  This is a cryptographically incorrect, albeit simple
   example.  A correct and full example is in Appendix A.
   
Presumably the # prefixes of the line MUST be stripped before processing?  Does that need to be stated here?


Nits:

 "Iff the geofeed file" => If, and only if, the geofeed file"?
 "fetching with a tweezers." => "fetching with tweezers" or "fetching with a pair a tweezers".
   
RPKI - Please expand on first use.

Regards,
Rob