revisiting rpsl-related set of rcf documents?
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? Thanks, Wilfried
Wilfried, At 2015-11-19 14:40:53 +0200 Wilfried Woeber <woeber@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. ;) It would be effort to produce a modern set of RPSL RFC's. It could be done without a *huge* effort if it is possible to replace a standards-track RFC without setting up an IETF working group. If booting a working group is required then I would recommend not to do it (people who understand IETF process better than me may have other takes on this). :) Alternately RIPE could produce a set of RIPE documents with "modern" RPSL described. (RIPE-681? :P) I guess your real question is "is it worth the effort?". It doesn't seem like RPSL will disappear any time soon, so in principle it seems like updating the documentation is worth it. If this is true, I guess the question is coming up with the time/money for someone to do this. (I'm happy to act as a reviewer, but can't author anything like this.) Cheers, -- Shane
HI all On 19/11/2015 14:20, Shane Kerr wrote:
Wilfried,
At 2015-11-19 14:40:53 +0200 Wilfried Woeber <woeber@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. ;)
It would be effort to produce a modern set of RPSL RFC's. It could be done without a *huge* effort if it is possible to replace a standards-track RFC without setting up an IETF working group. If booting a working group is required then I would recommend not to do it (people who understand IETF process better than me may have other takes on this). :)
Alternately RIPE could produce a set of RIPE documents with "modern" RPSL described. (RIPE-681? :P)
The RIPE Database was built on a RIPE interpretation of RPSL 14+ years ago. Since then many further changes and additions have been made. So I like Shane's suggestion to basically take the original RFCs and just update them to reflect reality and publish them as RIPE docs. So no one is asking the IETF to formally produce a new set of documents for RPSL, we simply document the version of RPSL used by the RIPE/APNIC/AFRINIC Databases. As there are only slight differences between the versions of RPSL used by these 3 DBs it may be wise to document that as well. cheeers denis
I guess your real question is "is it worth the effort?". It doesn't seem like RPSL will disappear any time soon, so in principle it seems like updating the documentation is worth it. If this is true, I guess the question is coming up with the time/money for someone to do this. (I'm happy to act as a reviewer, but can't author anything like this.)
Cheers,
-- Shane
On 2015-11-19 15:20, Shane Kerr wrote:
Wilfried,
At 2015-11-19 14:40:53 +0200 Wilfried Woeber <woeber@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. ;)
It would be effort to produce a modern set of RPSL RFC's.
Certainly.
It could be done without a *huge* effort if it is possible to replace a standards-track RFC without setting up an IETF working group. If booting a working group is required then I would recommend not to do it (people who understand IETF process better than me may have other takes on this). :)
Alternately RIPE could produce a set of RIPE documents with "modern" RPSL described. (RIPE-681? :P)
I guess your real question is "is it worth the effort?".
Yes, more or less. But to be more specific, just submit a query for "rpsl" and have fun. The first one that come up for me is: https://en.wikipedia.org/wiki/Routing_Policy_Specification_Language The next ones are: http://www.irr.net/docs/rpsl.html (Copyright © 2011) https://tools.ietf.org/html/rfc2622 (June 1999) https://www.ripe.net/manage-ips-and-asns/db/rpsl (....see RFC 2622) The migration from the old RIPE Database (RIPE-181) to the RPSL version of the RIPE Database has been completed in 2001. That's the thing that worries me, this disconnect between current reality and prominent, but *terribly* outdated, documentation.
It doesn't seem like RPSL will disappear any time soon, so in principle it seems like updating the documentation is worth it. If this is true, I guess the question is coming up with the time/money for someone to do this.
Just wondering, whether this could be a topic for an intern or a project?
(I'm happy to act as a reviewer, but can't author anything like this.)
Cheers,
-- Shane
Thanks for the immediate reply, Wilfried
Hi! On 11/19/2015 02:20 PM, Shane Kerr wrote:
Wilfried,
At 2015-11-19 14:40:53 +0200 Wilfried Woeber <woeber@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. ;)
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
Is it only a matter of bad RFCs? 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
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@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@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
On 2015-11-19 16:38, Tomas Hlavacek wrote:
Hi!
On 11/19/2015 02:20 PM, Shane Kerr wrote:
Wilfried,
At 2015-11-19 14:40:53 +0200 Wilfried Woeber <woeber@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?
Probably not exclusively, but imho this is a major aspect.
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.
Interesting idea!
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?
I don't have a strong opinion on this one. That’s the reason why I'd like to see contributions to this discussion from the wider community.
Or would it be better to wait for revisions of the formal documents or even for RDL to be finalized?
I wasn't aware of that, thanks for the pointer! Alas, when I had a look, the IETF page came back with: "IESG state Expired" and "This Internet-Draft is no longer active. [...]". Is there any follow-up activity in the IETF?
Tomas
Wilfried
there was a good reason the first task i was given as an incoming ops ad was to close down the rps wg cf. if folk really want to put the work in to produce a draft that represents a useful reality, i am willing to help and/or help push. but truth is that rpsl is neither simple, elegant, or even pretty. otoh, it does need documenting. randy
participants (6)
-
denis -
Randy Bush -
Shane Kerr -
Stavros Konstantaras -
Tomas Hlavacek -
Wilfried Woeber