[db-wg] revisiting rpsl-related set of rcf documents?

I agree with Tomas in many points. RFCs are bad, assisting documentation hardly exists, software tools are obsolete and they survive by life injections of volunteers. So people tend to create their own (incomplete but rather more familiar) tools to do their job/project and hack around RPSL problems when assisting documentation simple does not exist. As I dive into the code of different tools to get ideas, I see people parsing RPSL with their own methodology! 

While I am spending more and more time at my current project at NLnet Labs I do face the same dilemma: Something new and shinny for RPSL or something quick and dirty to do the job and then move towards to something different??? 

The first option will definitely help small/medium operators to automate tasks (as they probably have limited resources to build their own fancy tools) and being 100% compatible with every policy. However, from previous e-mail discussion on the same topic I concluded that there is a HUGE need from the community to put RPSL in the book of history and replace it with a modern approach.

It is still unclear for me the direction that the WG is willing to take but I would like to assist in the corresponding activities. Personally speaking, I am closing to the second option of the dilemma and I get the same motivation from other members as well. 

Best Regards
Stavros

----
Stavros Konstantaras
Internet Research Engineer, NLnet Labs 
Science Park 400, 1098 XH, Amsterdam

Fingerprint: 4502 7D16 2DF8 ADB0 4AA6  21A9 BF9E EFFF 2744 FE5D

> On 19 Nov 2015, at 17:38, Tomas Hlavacek <tomas.hlavacek at nic.cz> wrote:
> 
> Hi!
> 
> On 11/19/2015 02:20 PM, Shane Kerr wrote:
>> Wilfried,
>> 
>> At 2015-11-19 14:40:53 +0200
>> Wilfried Woeber <woeber at cc.univie.ac.at> wrote:
>> 
>>> Following up on the discussion here, during the DB-WG session in Bucharest,
>>> where changes to different aspects of using the RIPE registry database
>>> 
>>> - including a reference to discussions relating to cross-RIR authorisation -
>>> 
>>> I'd like to ask the following question to the community:
>>> 
>>> Is it about time to revisit the set of RFCs and either get them updated to
>>> properly reflect the (more) current reality,
>>> 
>>> or
>>> 
>>> consciously have them declared historic and overtaken by events?
>>> 
>>> What's your point of view?
>> 
>> hm... hard to say. Certainly RFC 2622 is a stunningly bad RFC, and RFC
>> 2725 is better but hardly great (I had questions while implementing
>> RFC 2622 in the past and was told "look at the RtConfig code to see
>> how it works" when I found inconsistencies). RFC 2769 is an interesting
>> read, if you like science fiction. ;)
> 
> Is it only a matter of bad RFCs?
> 
>> From my point of view it might help to have also software that would
> help with producing RPSL. I can imagine a lot of stuff ranging from a
> simple HTML form that would guide people through selection of their
> peers and setting basic filters, to things like reversing RtConfig and
> pre-create RPSL from Cisco/Juniper/... configs.
> 
> As the matter of fact I thought about creating some helper software, but
> out of desperation induced by reading RFC 2622 I rather created a
> (incomplete) RPSL parser in Python and ran the measurements I presented
> on today's WG.
> 
> Which leads me to the question: Do you think that it make sense to put
> an effort into creating a software for current RPSL? Or would it be
> better to wait for revisions of the formal documents or even for RDL to
> be finalized?
> 
> Tomas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/db-wg/attachments/20151119/eb57bda1/attachment.html>