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

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

Hi Randy,

Thanks.  Please see inline ...

> -----Original Message-----
> From: Randy Bush <[e-mail]>
> Sent: 12 April 2021 22:37
> To: Rob Wilton (rwilton) <[e-mail]>
> Cc: Ops Area WG <[e-mail]>; draft-ietf-opsawg-finding-
> [e-mail]
> Subject: Re: AD review of draft-ietf-opsawg-finding-geofeeds-04
> 
> hi rob et alia,
> 
> first, thanks a milion for a real review.  really appreciated.
[RW] 

No problem.  Sorry, it was delayed.


> 
> > 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'
[RW] 

So, solely for my understanding, if 8805 was updated in an incompatible way (e.g., a different format), then a separate "geofeed" attribute  would be used, e.g., "geofeed2:", or the like?

This makes me question whether this comment in section 4 is valid/correct: "Until [RFC8805] is updated to formally define such an appendix".  My understanding is that this couldn't be done without either breaking clients, or requiring new attribute names?



> 
> > 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.
[RW] 

RFC 2275 doesn't explain the hierarchy of INETNUM entries, and the one reference that does explain it is not a normative reference.  I.e., I think that you need to add a couple of sentences to explain the hierarchy so that you don't need the normative references to RIPE.




> 
> >    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.
[RW] 

Yes, lack of humour make me sad.

I'm happy for you to try and get "utterly awesome (i.e., practical but slightly complex)" through instead, but if you get push back then you're on your own ;-)



> 
> > 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.
[RW] 

Okay.


> 
> > 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.
[RW] 

Are they getting creative along other dimensions?  Who controls this definition,
and are they okay with the IETF constraining the definition this way?  I.e.,
is it possible to get the "irr folk" to agree that they are happy with what
is being proposed here?


> 
> >    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
[RW] 
Okay.

> 
> >    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.
[RW] 

I'll pass on the 2119 language debate rathole.


> 
> >    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.
[RW] 

As above, I think that this document needs to be say more about the hierarchy
of inetnums: so that it can avoid needing a normative reference, which seems
wise to avoid.



> 
> >    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.
> 
[RW] 

Thanks.


> > 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.
[RW] 

Ack.


> 
> >    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:.
[RW] 

This looks plausible to me, but don't have the expertise to know.  I assume
that one of the authors will speak up if this is not right.


> 
> >    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.
[RW] 
Okay.

> 
> > 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?
[RW] 

No need.  I don't think that iff is well known enough, so better to be explicit.

Thanks,
Rob


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