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. On Fri, May 14, 2021 at 3:48 PM Randy Bush <[email protected]> wrote: > > "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. > > 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 > >
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
