Re: [db-wg] RPSL parser nits

[Horváth Ágoston János via db-wg]

Correct! I just drawing attention that while implementing the whois server,
we've also checked some rpsl parsers, and most of them failed the sanity
checks, even for parsing.

As for interpreting the mp-export/import lines, those have a grammar that
is also included in the rpsl parser in whois server, although only used for
evaluating syntactic correctness. I think they also could form the basis of
a more complex software.

By the way, at this point a generic solution becomes impossible as everyone
wants to use the resulting expression tree differently, so it's always a
custom work from the grammar upwards.

Cheers,
Agoston

On Mon, Aug 17, 2020 at 12:58 AM Nick Hilliard  wrote:

> Horváth Ágoston János wrote on 16/08/2020 19:57:> The ripe whois
> database (https://github.com/RIPE-NCC/whois) has an
> > excellent (=clean, performant and heavily tested) RPSL parser in it for
> > java. It's minimal work to copy the package, or, since this is BSD
> > licence, you could release a copy of it for others to use too.
>
> yip but do I understand it correctly that this is a syntactic parser
> only?  I.e. there is no semantic expression evaluator.  If this is the
> case, you'd need a lot of glue to be able to convert rpsl expressions
> into structures suitable for injection into templating engines.  This is
> the hard bit in irrtoolset that wrecked everyones' heads.
>
> Nick
>

Re: [db-wg] RPSL parser nits

[Nick Hilliard via db-wg]

Horváth Ágoston János wrote on 16/08/2020 19:57:> The ripe whois 
database (https://github.com/RIPE-NCC/whois) has an
excellent (=clean, performant and heavily tested) RPSL parser in it for 
java. It's minimal work to copy the package, or, since this is BSD 
licence, you could release a copy of it for others to use too.


yip but do I understand it correctly that this is a syntactic parser 
only?  I.e. there is no semantic expression evaluator.  If this is the 
case, you'd need a lot of glue to be able to convert rpsl expressions 
into structures suitable for injection into templating engines.  This is 
the hard bit in irrtoolset that wrecked everyones' heads.


Nick

Re: [db-wg] RPSL parser nits

[Horváth Ágoston János via db-wg]

Hi Nick et al,

The ripe whois database (https://github.com/RIPE-NCC/whois) has an
excellent (=clean, performant and heavily tested) RPSL parser in it for
java. It's minimal work to copy the package, or, since this is BSD licence,
you could release a copy of it for others to use too.

Cheers,
Agoston

On Thu, Jul 2, 2020 at 5:12 PM Nick Hilliard via db-wg 
wrote:

> Lutz Donnerhacke via db-wg wrote on 02/07/2020 15:47:
> > I try to be a bit more expressive in the aut-num of ASN199284, but
> > fail to get accepted at least the valid parts by the RPSL parser.
> rpsl(ng) hasn't seen any significant development work since the 1990s,
> and the only real update since then was to support ipv6 (rfc4012 in
> 2005).  The only functional parser out there, irrtoolset, is crippled
> with functional shortcomings and is basically abandonware.
>
> You may want to think twice about whether it's worth investing time and
> effort in rpsl in 2020.
>
> Nick
>
>

Re: [db-wg] RPSL parser nits

[Stavros Konstantaras via db-wg]

Hi Lutz (and sorry for the late reply),

Maybe you can have a look on “PolicyParser” located here:
https://github.com/stkonst/PolicyParser 


It hasn’t received any commit the last 4 year, however It was working well 
until the moment I left the NLnet Labs.
And is python based, so it will be easy for reading and patching/expanding. 


Hope the above helps. 


Best regards,

Stavros Konstantaras | Sr. Network Engineer | AMS-IX 
M +31 (0) 620 89 51 04 | T +31 20 305 8999
ams-ix.net

> On 2 Jul 2020, at 17:21, Lutz Donnerhacke via db-wg  wrote:
> 
>> You may want to think twice about whether it's worth investing time and
>> effort in rpsl in 2020.
> 
> That's true, but I do need some style of machine readable documentation 
> internally as well as an slightly competent looking aut-num object for 
> peering purposes.
> 
> So the only choices are:
> a) invent something new for internal usage and update the RADB in addition.
> b) use the existing ideas and tools.
> 
> I do not have any problem in patching or rewriting software, if necessary.
> For solution a) I have to do everything by myself anyway, so where is the 
> difference to b), even if I'm the only user?
> 
> If the projects are abandoned, who is to contact to shift the responsibility?
> 

Re: [db-wg] RPSL parser nits

[ripedenis--- via db-wg]

 Hi Lutz
Is your problem with the RPSL syntax in an AUT-NUM you try to create in the 
RIPE Database, or with some RPSL parser you are using on data you have 
extracted from the RIPE Database?
Nick, "You may want to think twice about whether it's worth investing time and 
effort in rpsl in 2020". Given that the discussion you tried to get going 
recently on the future of RPSL hardly got off the ground, then unless someone 
already has advanced plans on a replacement for RPSL I don't see it going away 
anytime soon.
cheersdenis
co-chair DB-WG
On Thursday, 2 July 2020, 17:12:29 CEST, Nick Hilliard via db-wg 
 wrote:  
 
 Lutz Donnerhacke via db-wg wrote on 02/07/2020 15:47:
> I try to be a bit more expressive in the aut-num of ASN199284, but 
> fail to get accepted at least the valid parts by the RPSL parser.
rpsl(ng) hasn't seen any significant development work since the 1990s, 
and the only real update since then was to support ipv6 (rfc4012 in 
2005).  The only functional parser out there, irrtoolset, is crippled 
with functional shortcomings and is basically abandonware.

You may want to think twice about whether it's worth investing time and 
effort in rpsl in 2020.

Nick

  

Re: [db-wg] RPSL parser nits

[Lutz Donnerhacke via db-wg]

> You may want to think twice about whether it's worth investing time and
> effort in rpsl in 2020.

That's true, but I do need some style of machine readable documentation 
internally as well as an slightly competent looking aut-num object for peering 
purposes.

So the only choices are:
 a) invent something new for internal usage and update the RADB in addition.
 b) use the existing ideas and tools.

I do not have any problem in patching or rewriting software, if necessary.
For solution a) I have to do everything by myself anyway, so where is the 
difference to b), even if I'm the only user?

If the projects are abandoned, who is to contact to shift the responsibility?

Re: [db-wg] RPSL parser nits

[Nick Hilliard via db-wg]

Lutz Donnerhacke via db-wg wrote on 02/07/2020 15:47:
I try to be a bit more expressive in the aut-num of ASN199284, but 
fail to get accepted at least the valid parts by the RPSL parser.
rpsl(ng) hasn't seen any significant development work since the 1990s, 
and the only real update since then was to support ipv6 (rfc4012 in 
2005).  The only functional parser out there, irrtoolset, is crippled 
with functional shortcomings and is basically abandonware.


You may want to think twice about whether it's worth investing time and 
effort in rpsl in 2020.


Nick

[db-wg] RPSL parser nits

[Lutz Donnerhacke via db-wg]

Hello,

I try to be a bit more expressive in the aut-num of ASN199284, but fail to get 
accepted at least the valid parts by the RPSL parser.

Of course, there are invalid expressions in my terms for the sake of 
expressiveness, i.e.
 - next-hop is only valid for static routes
 - communities must not contain the PeerAS pattern

But the other parts should be accepted, i.e.
 - protocol OSPF
 - rtr-sets in router expression part


It would be a cool idea to keep the formatting, or better have smart pretty 
printing of the RSPLng structures. Currently only the "syncupdate" Interface is 
able to keep the line warps, which is pretty annoying.

Where can I found the currently running code and do you accept patches in this 
regard?

Many thanks in advance
Lutz Donnerhacke