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

[Randy Bush <[e-mail]>]

hi rob et alia,

first, thanks a milion for a real review.  really appreciated.

> 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.

see diff.  a lot of 8805 refs sprinkled in before the word 'geofeed
file'

> 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.

ibid

> 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?

russ, how do you want to handle?

> 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.

this is why 2275 and 4012 are normative and the refs to ripe docs are
informative.

>    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'?

my memory could be off, but i think it was i mocking warren.  i can make
the change.  sense of humor declines in the ietf.

> 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.

yucchy.  removed.

>    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"?

ok.  russ?  maybe 'authenticating'?

> 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 do not think this problem to be likely.  they seem not to be wiggling;
and we are codifying the attribute name in 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?

let's see how this goes.  the irr folk working on this do not seem to be
getting creative, at least along this dimension.

>    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?

hacked to say then ignore all

>    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?

because it is arin.  unpredictable.  but i'll upcase.

> Otherwise, could change from "must be treated" to "is treated" to
> avoid potential ambiguity.

imiho, 2119 adds syntax and accompanying semantics; and should not be
taken to invalidate the american language.

>    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?

unfortunately, RFC2725 is not as thorough on this point as the ripe
document.  i have hacked to ref both.

>    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.

    I.e. an INETNUM object for a prefix P could refer to a geofeed file
    in which P has been sub-divided into one or more longer prefixes.

> 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.

sure

i don't think we want to open the 8805 can right now.  the googlers are
having a hard enough time actually using it in operation; see nanog.  so
i doubt they want to spend time on a bis.

>    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.

nope.  on second thought, the inetnum: might cover more or less than the
rpki cert, just so long as the cert covers the data in the file it is
signing.  i think this catches it

        The address range of the signing certificate MUST cover all
        prefixes in the geofeed file it signs; and therefore must be
	covered by the range of the inetnum:.

>    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.

	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 the CSV lines in the
	geofeed file do.

> HSM - Hardware Security Module?  If so, please expand on first use.

ack

>    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?

	The signature does not cover the signature lines.

>  "Iff the geofeed file" => If, and only if, the geofeed file"?

shall i also s/i.e./id est/ etc?

>  "fetching with a tweezers." => "fetching with tweezers" or "fetching
>  with a pair a tweezers".

ok

> RPKI - Please expand on first use.

ok

try this

randy