John Scudder has entered the following ballot position for draft-ietf-opsawg-finding-geofeeds-10: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-finding-geofeeds/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this document, it looks useful. I have some comments and questions below. 0. I’d like to thank George Michaelson for a thorough and helpful, not to say exemplary, shepherd’s report. 1. Section 3: Ideally, RPSL would be augmented to define a new RPSL geofeed: attribute in the inetnum: class. Until such time, this document I, too, am curious as to why this ideal solution isn’t considered achievable. I’m also a little confused by the way you seem to be arguing with yourself in this section. First you tell me that change control for RPSL is vested in the operator community (by implication, not the IETF). A few paragraphs later you say: While we leave global agreement of RPSL modification to the relevant parties, we specify that a proper geofeed: attribute in the inetnum: class MUST be "geofeed: ", and MUST be followed by a single URL which Is it up to them? Or is it up to you? I don’t get it. I mean, I’m fine with what you’ve specced, but when you fence it off with disclaimers that say RPSL modification isn’t up to you, it leaves me confused. Perhaps your point is that the IETF gets to specify the geofeed: attribute, but only the RIRs get to decide when they will start using it? This is generally true of everything the IETF does, of course, but OK. But if that’s what you mean, it really wasn’t clear to me from reading the text. By the way, I bet you should expand “RIR“ on first use. 2. Section 3: 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 not only implies that the RIRs support the geofeed: attribute, but that all registrants have migrated any inetnum:s from remarks: use to geofeed:s. The referent of “this” in the last sentence isn’t clear. Maybe you mean “migrated”? Rewriting as ‘“Migrated” not only implies…’ would clarify, if so. 3. Section 3: Any particular inetnum: object MUST have at most, one geofeed reference, whether a remarks: or a proper geofeed: attribute when it is implemented. If there is more than one, all are ignored. This makes me think the geofeed: attribute will never, ever be adopted, because you’ve just created a flag day requirement. Why not permit both the remarks: and geofeed: versions to enable transition? Presumably you'd need some tie-break rule in case they're pointing different places, but that doesn't seem like a deal-breaker. 4. Section 5: If and only if the geofeed file is not signed per Section 4, then multiple inetnum: objects MAY refer to the same geofeed file, and the consumer MUST use only geofeed lines where the prefix is covered by the address range of the inetnum: object they have followed. Presumably this only works with unsigned geofeeds because you’re implicitly requiring that the geofeed file be signed only once. Is there any particular driver for this sign-only-once requirement? On a cursory review of §4, I don’t see anything that would make multiple signatures impracticable. I note that §3 says If a geofeed CSV file describes multiple disjoint ranges of IP address space, there are likely to be geofeed references from multiple inetnum: objects. While the text in §5 doesn’t actually give the lie to this quote (since I can read it as “if an unsigned geofeed CSV file…”) it does seem like the document is pulling in two different directions. At the very least, if there is a requirement that only a single signature be present in a geofeed file, can you say that explicitly in §4? 5. Section 5: An entity fetching geofeed data using these mechanisms MUST NOT do frequent real-time look-ups to prevent load on RPSL and geofeed servers. [RFC8805] Section 3.4 suggests use of the [RFC7234] HTTP Nit: I think you need a comma between “look-ups” and “to”. Or re-word as “To prevent undue load on RPSL and geofeed servers, an entity fetching geofeed data using these mechanisms MUST NOT do frequent real-time look-ups.” (I also added “undue” because of course every transaction induces SOME load.) 6. General Comment: While I notice some reviewers have expressed discomfort with the occasional lighthearted use of language (“fetching with tweezers”, etc), I found that it made the document more fun to read without hindering clarity in the slightest. In short, it made it a better spec. Thank you. _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
