[routing-wg] RPSL

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 nanog at nanog.org, the irrd project at http://irrd.net/, *NOG lists,
or grow at ietf.org) 

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 <ggm at algebras.org> 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
> <routing-wg at ripe.net> 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 <gert at space.net> 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