Subject: [OPSAWG] Martin Duke's No Objection on draft-ietf-opsawg-finding-geofeeds-08: (with COMMENT)

From: Martin Duke via Datatracker <[email-masked]>
Date: Fri, 14 May 2021 09:21:24 -0700

Martin Duke has entered the following ballot position for
draft-ietf-opsawg-finding-geofeeds-08: 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:
----------------------------------------------------------------------

"Ideally, RPSL would be augmented to define a new RPSL geofeed:
   attribute in the inetnum: class.  Until such time, this document
   defines the syntax of a Geofeed remarks: attribute which contains an
   HTTPS URL of a geofeed file."

If the ideal solution is to produce a standards track document that creates a
new RPSL attribute, I don't understand why the Working Group didn't simply do
that, instead of messing with the remarks and then coming up with a transition
plan for moving from this design to the future one.

---

From: Randy Bush <[email-masked]>
Date: Fri, 14 May 2021 15:47:58 -0700

> If the ideal solution is to produce a standards track document that
> creates a new RPSL attribute, I don't understand why the Working Group
> didn't simply do that, instead of messing with the remarks and then
> coming up with a transition plan for moving from this design to the
> future one.

the word "ideally" was meant to signal "not gonna happen."

RPSL as in use today varies radically from the RPS as documented by the
ietf, and varies between RIRs and between software sets.  the last ietf
attempt to codify RPSLng was a disaster; when i first became an AD i was
told to shut the wg down asap and did so.

today, the main thread of RPSL definition is in the RIPE community and
the RIPE/NCC implementation.  this is in the process of adopting the
geofeed: attribute in the INETNUM class.  i believe the irrd open source
implementation is also following.  that's as good as it is likely to
get.  sorry.

randy

---

From: Martin Duke <[email-masked]>
Date: Mon, 17 May 2021 07:43:15 -0700

That seems like a reasonable decision.

Rather than be oblique about it, could we just say part of this in the
draft, to the effect of

"While the IETF published one of the specifying documents for RPS
[RFCXXXX], effective change control for RPSL today lies with the RIPE
community [ref]. However, it is in scope to use the Remarks: field..."

That's not perfect wording, but would be more informative to the reader.

---

From: Randy Bush <[email-masked]>
Date: Mon, 17 May 2021 12:48:18 -0700

< rant >

> community [ref]. However, it is in scope to use the Remarks: field..."

i wish.  ripe has the energy and the momentum.  ripe does a lot of the
docs.  ripe has running code.  and ripe is where this is moving forward
in the sense of documentation and open code.  otoh, most rirs are moving
on hacking geofeed: attributes.  massimo tracks far better than i.

but the rirs are immature siblings who pretend to get along when
grownups are watching, but fight dirty in the back seat of the car.  do
not judge their words; but their actions.  arin does not even have a
remarks: attribute, as you can see in the draft.

and if you wonder if this is a disservice to the members, note that arin
membership, last time i asked, represents less than 20% of the address
holders in their region.

so, ripe is indeed where it is happening.  but saying that ripe has
change control of the rpsl specification in the ietf sense is a dream.

how about

   The original RPSL specifications starting with [RIPE81], [RIPE181],
   and a trail of subsequent documents were done by the RIPE community.
   The IETF standardardized RPSL in [RFC2622] and [RFC4012].  Since
   then, it has been modified and extensively enhanced in the RIR
   community, mostly by RIPE, [RIPE-DB].  Currently, change contol
   effectively lies in the operator community.

randy

---

From: George Michaelson <[email-masked]>
Date: Tue, 18 May 2021 10:43:09 +1000

I also think Randy's version is better because of two things:

1) it aligns with reality: fields are added to RPSL as a response of
operator driven demand.

2) it aligns with the least cost path out: the likelihood of a reprise
or -bis of RPSL completing in the short or medium term in either IETF
or RIPE is low, because it is subject to a huge debate about the
applicability of modern routing praxis like RPKI, and disagreements
inside the operations community.

I checked with an IRR code developer, and adding fields "does no harm"
because they are used to recognizing an instance of an uknown
type:value form, and dealing with them (ignore)

-G

---

From: Martin Duke <[email-masked]>
Date: Tue, 18 May 2021 10:50:21 -0700

Yes, Randy clearly understands this best, and I believe his proposal
explains it well.

---

From: Randy Bush <[email-masked]>
Date: Tue, 18 May 2021 10:54:40 -0700

i did push -10 with that addition per discussion.  it gets pretty gritty
when the political and operational uglies raise their heads.  sorry.
and thanks.

randy