Paul, thank you for your review and thank you all for the following discussion. I have entered a No Objection ballot for this document.
Lars > On 2021-4-29, at 19:57, Paul Kyzivat <pkyzi...@alum.mit.edu> wrote: > > 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
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
