On Thu, May 20, 2021 at 01:36:52PM -0700, Randy Bush wrote: > >> 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. > > i suspect your corporate nannyware put some strange rubbish after the > ".mov" > > but you can also try https://archive.psg.com/catherding.mpg > > >>> 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. > > it's even simpler. the whois server would support both flavors of > attribute in an inetnum:, remarks: and geofeed:. (note that it MUST > support the remark: form.) it is the individual inetnum: objects > registered by ISPs that cut over one by one at their leisure. an isp > with 42 inetnum: objects could cut them over one at a time on wednesday > afternoons.
I was going to comment something similar to John until I noticed this snippet: 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. [...] So, AFAICT, we already do require that all clients will be able to consume both forms, and the complications that John is worried about "just go away". > > 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. > > i think you mean if there are clients that do not support the geofeed: > attribute form in inetnum:s. yup, then they are not going to get the > urls from inetnum:s which have moved to the new form. such is forward > migration. > > >>> 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 geofeed 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. > > in parallel, i am thinking of the implications of a question in this > space from ben. i think the comparitive granularity of inetnum:s and > the corresponding rpki data is important but unknown. > > my head hurts. i want to keep thinking about this space. Makes sense (on both counts, unfortunately). > > 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” > > the quote marks were insufficiently explicit? > > > 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'll try it. but the previous complaint there was that the text was > insufficiently prescriptive. (FWIW, this is basically the space in which my second discuss point falls. If there's any semantic value to the stuff after "RPKI Signature"/"End Signature", we should say what it is, even if it's just matching the start/end lines. If there's no semantics at all, that's probably fine too. > > I was sad to see the tweezers left on the cutting room floor but I > > understand why. > > for you, i would throw them back. but the strength of the current > "brute force" phrasing appeals. I guess I have to go back to an older version and see what I missed by only reading the -12, then! -Ben _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
