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.
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
