Subject: [OPSAWG] John Scudder's No Objection on draft-ietf-opsawg-finding-geofeeds-10: (with COMMENT)

From: John Scudder via Datatracker <[email-masked]>
Date: Wed, 19 May 2021 18:43:03 -0700

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 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.

---

From: Randy Bush <[email-masked]>
Date: Wed, 19 May 2021 20:00:29 -0700

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.

> 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?  :)

> “migrated”? Rewriting as ‘“Migrated” not only implies…’ would clarify,

sure

> 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:         [email-masked]
    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.

> 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.

> present in a geofeed file, can you say that explicitly in §4?

sure.

> “undue” because of course every transaction induces SOME load.)

thanks for text

> 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

---

From: Randy Bush <[email-masked]>
Date: Wed, 19 May 2021 20:17:14 -0700

my apologies.  -11 had too many typos.  immediately pushed -12

randy

---

From: John Scudder <[email-masked]>
Date: Thu, 20 May 2021 13:01:45 +0000

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 <[email-masked]> wrote:
>

---

From: John Scudder <[email-masked]>
Date: Thu, 20 May 2021 19:35:24 +0000

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-masked]> 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.

If your point is “the process is convoluted, so the description of it is too” then… ok. I won’t further belabor the point.

[…]

> 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.

[…]

> 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.

> 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

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.

[…]

>> present in a geofeed file, can you say that explicitly in §4?

Thanks.

> 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

---

From: Randy Bush <[email-masked]>
Date: Thu, 20 May 2021 13:36:52 -0700

>> ever see the cat herding video?
> https://urldefense.com/v3/__https://archive.psg.com/cat-herders.mov__;!!NEt6yMaO-gk!UwP65THoPAKtaE74N5YFw9MSNO17zkgu96E4xctycM7-Iu1KDATEZf22uke20g$
> 

i suspect your corporate nannyware put some strange rubbish after the
".mov"

but you can also try https://archive.psg.com/catherding.mpg

> 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.

>> the geofeed lines would then need to be sorted, clumped, ...  seems a
> 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.

> 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

for you, i would throw them back.  but the strength of the current
"brute force" phrasing appeals.

randy

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 20 May 2021 14:09:37 -0700

> with 42 inetnum: objects could cut them over one at a time on wednesday

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".

> my head hurts.  i want to keep thinking about this space.

Makes sense (on both counts, unfortunately).

> 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.

> "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