Dear all, Speaking as RIPE Routing Working Group Co-Chair (*without having consulted with the other co-chairs*)
I think the routing working group in RIPE is a good platform to explore the topic at hand. I believe both Denis and Nick to be valuable contributors in the process ahead of us. I care a lot about getting the right people in the 'room', and ensuring all people involved have comitted time to work on the issue. I recognize that platforms also exist to discuss RPSL/IRR related issues (such as [email protected], the irrd project at http://irrd.net/, *NOG lists, or [email protected]) At whatever "RIPE 80" was, in the Routing Working Group session , Nick Hilliard asked for feedback from this WG. As a result, we as Routing WG we should follow-up, and I am willing to put in time. As I am one of your co-chairs, please email this list (or mail the chairs directly) if you have plans you want to share. *speaking as participant of the global Internet routing system*: I don't mind whereever we do this, but I would like all of it to be: A) publicly archived B) follow some process that all involved ahead of time understand C) COUNT ME IN Kind regards, Job On Thu, May 14, 2020 at 02:29:50PM +0000, ripedenis--- via routing-wg wrote: > This is exactly the point I am making George. I am not saying the > RIPE Database is special. Exactly the opposite. So if there is a > problem with using RPSL in the RIPE Database I assume it is likely > all IRRs have the same problem. So should the IETF look at this issue > or is it reasonable to change the way routing data is processed or > handled only in the RIPE IRR? cheersdenis > co-chair DB-WG > On Thursday, 14 May 2020, 16:16:13 CEST, George Michaelson > <[email protected]> wrote: > > The RIPE DB's RPSL is not special in any regard Denis. Its one BGP > configuration space after all. > > If the observations about the RIPE IRR are true, then is it not > equally likely they hold at other IRR too? > > So I think a reasonable approach here might be to take observations > about object types, complexity, usage, and ask other IRR if they also > see these behaviours? > > -George > > > On Fri, May 15, 2020 at 12:00 AM ripedenis--- via routing-wg > <[email protected]> wrote: > > > > Hi Gert > > > > You are right, this has been an issue for many years. It is not only the > > problem of parsing RPSL but also an issue with people understanding it as a > > language and applying it correctly. But should this be an issue taken up by > > the IETF? Or do you think the RIPE Database could/should do something > > different to all other IRRs? > > > > cheers > > denis > > > > co-chair DB-WG > > > > > > On Thursday, 14 May 2020, 14:45:11 CEST, Gert Doering <[email protected]> > > wrote: > > > > > > Hi, > > > > On Thu, May 14, 2020 at 09:52:06AM +0000, ripedenis--- via routing-wg wrote: > > > Just a comment on the RPSL issue from the RIPE 80 session today. RPSL has > > > little to do with the accuracy of data in the RIPE IRR. RPSL is just a > > > language. Assuming you understand the language, it is your choice whether > > > or not you maintain your data and keep it accurate and up to date. > > > > > > Right. > > > > That said, the data quality regarding import: and output: lines in the > > RIPE DB is so poor that "bad and useless" is not halfway sufficient > > to describe its badness. > > > > I think import/export is beyond repair - it is too complex to correctly > > parse, and at the same time not expressive enough to describe policy > > precisely enough ("export to AS X as peer, no further upstreaming permitted" > > vs. "export to AS Y as upstream, further distribution expected"). > > > > Gert Doering > > -- NetMaster > > -- > > have you enabled IPv6 on something today...? > > > > SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael > > Emmer > > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > > D-80807 Muenchen HRB: 136055 (AG Muenchen) > > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
