Re: [OPSAWG] John Scudder's No Objection on draft-ietf-opsawg-finding-geofeeds-10: (with COMMENT)
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
Re: [OPSAWG] John Scudder's No Objection on draft-ietf-opsawg-finding-geofeeds-10: (with COMMENT)
>> 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 OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] John Scudder's No Objection on draft-ietf-opsawg-finding-geofeeds-10: (with COMMENT)
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 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
Re: [OPSAWG] John Scudder's No Objection on draft-ietf-opsawg-finding-geofeeds-10: (with COMMENT)
One quick reply, more pending — To be clear, that was me thanking George for a job well done. I didn’t intend to imply the authors hadn’t provided credit where due, I did see that you had, and thanks for that. —John > On May 19, 2021, at 11:01 PM, Randy Bush wrote: > >> 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. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] John Scudder's No Objection on draft-ietf-opsawg-finding-geofeeds-10: (with COMMENT)
my apologies. -11 had too many typos. immediately pushed -12 randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] John Scudder's No Objection on draft-ietf-opsawg-finding-geofeeds-10: (with COMMENT)
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
[OPSAWG] John Scudder's No Objection on draft-ietf-opsawg-finding-geofeeds-10: (with COMMENT)
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
