thanks john. appreciated. > 0. I’d like to thank George Michaelson for a thorough and helpful, not > to say exemplary, shepherd’s report.
it's odd. the acks have thanked ggm twice, once for shepherding, and folk seem to miss it. > 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? really, if the ripe community adopts it. and progress is good there. ever see the cat herding video? https://archive.psg.com/cat-herders.mov > By the way, I bet you should expand “RIR“ on first use. ack. but aren't the darned RIRs expansive enough? :) > 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. sure > 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. no. this is per inetnum: object, not per registry. see beginning of para. perhaps i should add an example of an inetnum: object. inetnum: 147.28.0.0 - 147.28.15.255 netname: RGNET-RSCH-147-0 country: EE org: ORG-RO47-RIPE admin-c: RB45695-RIPE tech-c: RB45695-RIPE abuse-c: AR52766-RIPE status: LEGACY notify: r...@rg.net mnt-by: MAINT-RGNET mnt-by: RIPE-NCC-LEGACY-MNT remarks: Geofeed https://rg.net/geofeed created: 2020-10-20T23:45:00Z last-modified: 2020-11-12T13:16:12Z source: RIPE except i bet it would take hours to use proper example formalities for everything. > Why not permit both the remarks: and geofeed: versions to enable > transition? because then, as you point out, it is three paragraphs if they disagree. > 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. the grofeed lines would then need to be sorted, clumped, ... seems a bit complex for not much win. due to the administrative structure and process, inetnum: objects tend to the same granularity as RPKI objects. so having the geofeed files follow seems natural. i figure that, if signing actually is used, and folk whine, we can beg russ to do a bis. > 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? sure. > 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.) thanks for text > > 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. i figured if i gave on the tweezers, which was probably a bit too colloquial, maybe others would give on the utterly awesome. maybe we need a 2119 for anti self-impressed stuffiness? i am about to push -11. check diff if you have the time. right now i am panicked that i can not find that i sent the reply to roman i had composed about his comments other than authentication. but i think i did incorporate them, and even put him in the ack list. randy _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
