Last Call Review of draft-ietf-opsawg-finding-geofeeds-06
review-ietf-opsawg-finding-geofeeds-06-genart-lc-kyzivat-2021-04-29-00

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-opsawg-finding-geofeeds-06
Reviewer: Paul Kyzivat
Review Date: 2021-04-29
IETF LC End Date: 2021-05-04
IESG Telechat date: ?

Summary:

This draft is on the right track but has open issues, described in the 
review.

General:

I'm not competent to review the crypto and security aspects of this 
document. Hopefully there will also be a security review to cover those.

Issues:

Major: 0
Minor: 3
Nits:  2

1) Minor: Definition of "remarks: Geofeed"

Section 3 says:

    ... The format of the inetnum: geofeed
    attribute MUST be as in this example, "remarks: Geofeed" followed by
    a URL ...

 From the examples and common sense there should be a space preceding 
the URL. But the text doesn't mention this. I suggest changing to:

    ... The format of the inetnum: geofeed
    attribute MUST be as in this example, "remarks: Geofeed " followed by
    a URL ...

Also, is the word "Geofeed" case sensitive?

2) Minor: Modification of RPSL

Section 3 says:

    While we leave global agreement of RPSL modification to the relevant
    parties, we specify that a proper geofeed: attribute in the inetnum:
    class be simply "geofeed: " followed by a URL which will vary, but
    MUST refer only to a [RFC8805] geofeed file.
    ...
    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.

This is a bit presumptive. You say you are leaving the RPSL modification 
to others, yet you are herein standardizing the exact form that 
modification must take. What if the relevant parties want to choose a 
different form?

ISTM that this document should only mandate support for the Remarks form 
and leave support of the modified RPSL form to later, after RPSL has 
been updated.

3) Minor/Nit: IANA Considerations

I don't understand why this section is present. I don't find any 
reference of it within the document.

4) NIT: Use of "awesome"

I'm not sure how to feel about using *awesome* in the Introduction. It 
seems unusually informal for a standards document. But in a way I also 
find it refreshing.

I just suggest you rethink about whether you want that. I'm good either way.

5) Nit: IdNits

IdNits reports a number of things worth looking into. Notably the 
downrefs and the lack of an IPv6 example.