>> 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. > 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. > 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. > 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. randy _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
