Hi Randy, Further replies below. I’ve snipped where I had nothing further to say; please consider me to have chuckled at your bons mots, thanked you for updates, etc.
> On May 19, 2021, at 11:00 PM, Randy Bush <[email protected]> wrote: […] >> 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://urldefense.com/v3/__https://archive.psg.com/cat-herders.mov__;!!NEt6yMaO-gk!UwP65THoPAKtaE74N5YFw9MSNO17zkgu96E4xctycM7-Iu1KDATEZf22uke20g$ Does not render. Oh well, I’ve seen cat videos before, I’ll use my imagination. If your point is “the process is convoluted, so the description of it is too” then… ok. I won’t further belabor the point. […] >> 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. I know what an inetnum: is (although it’s a fair point that maybe not everybody does). In thinking about it a little more, yes “flag day” was too strong, however I think there’s still potentially a problem, depending on what entity has the issues. If it’s only the RIR (“server”) side that lags, then presumably clients will be built to consume both geofeed: and inetnum: from day one. In that case cutover is easy: once the RIR implements geofeed:, you cut over to it in all the inetnum:s that RIR serves, done. On the other hand, if there are clients (now, or ever) that implement only inetnum:, then I do think we’re in for an eternity of supporting both. […] >> 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. As long as my supposition above is the expected case, I agree that keeping it simple is fine. If it’s not the expected case, then three paragraphs seems a small price to pay. >> 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. OK. My fear was that there might already be substantial investment in geofeed:s that cover multiple objects, and resistance to shredding them down to individual object-level feeds. But maybe there isn’t and won’t be. > i figure that, if signing actually is used, and folk whine, we can beg > russ to do a bis. One counterargument to my scenario above, is that tooling up to sign the geofeed:s is probably a bigger effort than subdividing them in order to permit the signatures. […] >> 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. Thanks. > 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. I took a look and it looks good. I have one new nit, in §4, because of course I do: The bracketing "# RPKI Signature:" and "# End Signature:" MUST be present exactly as shown. A pedant might say “exactly as shown” means verbatim "# End Signature: 192.0.2.0/24” including that particular prefix value no matter what the associated object is. While your intent is obvious-ish, it may be worth being even clearer. It would be possible to write it out in excruciating detail of course, but possibly replacing “exactly as shown” with something like “following the model shown” might be enough. (I say “ish” because I wonder if “192.0.2/24”, the way right-thinking people write prefixes, would also be OK, or if it’s not “exactly as shown” enough.) I was sad to see the tweezers left on the cutting room floor but I understand why. —John _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
