From dkalo at noc.ntua.gr Mon May 3 18:52:13 2004 From: dkalo at noc.ntua.gr (Dimitrios Kalogeras) Date: Mon, 03 May 2004 19:52:13 +0300 Subject: rpslcheck utility vs rpslng-auto@ripe.net Message-ID: <409678BD.80006@noc.ntua.gr> Hi to all of you, I am using the rpslcheck utility from the IRRToolSet 4.8.1 distribution before submiting them to the rpslng-auto at ripe.net. Although the rpslcheck tool provides error free result, the backend system from ripe responses with error ? Do you know if there is any differences between them ? Thanks, Dimitrios .PS I suppose there is an error in the page http://www.ripe.net/db/rpslng/ . The reason is that although it is stated that there is an RPSLng prototype Whois server on host rpslng.ripe.net, port 53001 the response from this server leads me to apnic. is this correct ? ajax# whois -h rpslng.ripe.net -p 53001 as5408 % [whois.apnic.net node-1] % Whois data copyright terms http://www.apnic.net/db/dbcopyright.html %ERROR:101: no entries found % % No entries found in the selected source(s). % [whois.apnic.net node-2] % Whois data copyright terms http://www.apnic.net/db/dbcopyright.html %ERROR:101: no entries found % % No entries found in the selected source(s). -- -- Dimitrios K. Kalogeras Electrical Engineer Ph.D. Network Manager NTUA/GR-Net Network Management Center _____________________________________ icq: 11887484 voice: +30-210-772 1863 fax: +30-210-772 1866 e-mail: D.Kalogeras at noc.ntua.gr pub 1024D/F2A69A72 2002-12-13 Dimitrios Kalogeras Key fingerprint = 64C5 646D 8D33 A3FF 14D1 66C6 5127 54CC F2A6 9A72 From engin at ripe.net Tue May 4 11:52:28 2004 From: engin at ripe.net (Engin Gunduz) Date: Tue, 4 May 2004 11:52:28 +0200 Subject: rpslcheck utility vs rpslng-auto@ripe.net In-Reply-To: <409678BD.80006@noc.ntua.gr> References: <409678BD.80006@noc.ntua.gr> Message-ID: <20040504095227.GA20445@cow.ripe.net> Hi Dimitrios, On 2004-05-03 19:52:13 +0300, Dimitrios Kalogeras wrote: > Hi to all of you, > I am using the rpslcheck utility from the IRRToolSet 4.8.1 distribution > before submiting them to the rpslng-auto at ripe.net. > Although the rpslcheck tool provides error free result, the backend > system from ripe responses with error ? IRRToolSet and our whois software use different syntax checkers. Although we tried to make them totally compatible, there may be differences. Could you please send the object to me? > Do you know if there is any differences between them ? > > Thanks, > Dimitrios > > > .PS > > I suppose there is an error in the page http://www.ripe.net/db/rpslng/ . > The reason is that although it is stated that there is an RPSLng > prototype Whois server on host rpslng.ripe.net, port 53001 the response > from this server leads me to apnic. is this correct ? This is strange. The rpslng prototype server runs exactly where you mentioned. I can query it. Perhaps your whois client does some trick? Could you please try to telnet to rpslng.ripe.net port 53001 and see what happens? Thanks, -engin > ajax# whois -h rpslng.ripe.net -p 53001 as5408 > % [whois.apnic.net node-1] > % Whois data copyright terms http://www.apnic.net/db/dbcopyright.html > > %ERROR:101: no entries found > % > % No entries found in the selected source(s). > > > % [whois.apnic.net node-2] > % Whois data copyright terms http://www.apnic.net/db/dbcopyright.html > > %ERROR:101: no entries found > % > % No entries found in the selected source(s). > > > > -- > -- > > Dimitrios K. Kalogeras > > Electrical Engineer Ph.D. > Network Manager > NTUA/GR-Net Network Management Center > _____________________________________ > icq: 11887484 > voice: +30-210-772 1863 > fax: +30-210-772 1866 > e-mail: D.Kalogeras at noc.ntua.gr > pub 1024D/F2A69A72 2002-12-13 Dimitrios Kalogeras > Key fingerprint = 64C5 646D 8D33 A3FF 14D1 66C6 5127 54CC F2A6 9A72 > -- Engin Gunduz RIPE NCC Software Engineering Department From ljb at merit.edu Fri May 7 23:17:37 2004 From: ljb at merit.edu (Larry J. Blunk) Date: Fri, 7 May 2004 17:17:37 -0400 Subject: RPSLng and nested refine/except expressions Message-ID: <200405071717.37661.ljb@merit.edu> In the -04 version of the RPSLng draft, the structured policy syntax was updated to allow nested refines and excepts in policy expressions. I.e. refine { refine { } } Examples of such expressions are given both RFC2622 and the RPSLng draft. However, the original RFC2622 syntax did not actually allow such expressions. However, in the process of implementing and running the syntax check on existing objects, I have found examples of the following: refine { } refine { } See, for example, AS7574 in the RADB. Unfortunately, such expressions are invalid in the lastest RPSLng draft. Are such expressions semantically identical to nested refines/excepts? Should both this form and the nested form be allowed. I have come up with a minor modification to the -04 syntax that would allow both, but I'm not sure if it is a good idea or not. -Larry From mrp at mrp.net Sat May 8 11:52:24 2004 From: mrp at mrp.net (Mark Prior) Date: Sat, 08 May 2004 19:22:24 +0930 Subject: RPSLng and nested refine/except expressions In-Reply-To: <200405071717.37661.ljb@merit.edu> References: <200405071717.37661.ljb@merit.edu> Message-ID: <409CADD8.1080904@mrp.net> Larry J. Blunk wrote: > However, in the process of implementing and running the syntax check > on existing objects, I have found examples of the following: > > refine { > > } refine { > > } > > See, for example, AS7574 in the RADB. Unfortunately, such expressions > are invalid in the lastest RPSLng draft. Are such expressions semantically > identical to nested refines/excepts? Should both this form and the nested > form be allowed. I have come up with a minor modification to the -04 > syntax that would allow both, but I'm not sure if it is a good idea or not. I use that sort of construct all the time so it better continue to exist! See AS2764 (where I used to work) and AS7575 (my latest effort). RADB's reformatting makes it less obvious but it is a cascading refine. Mark. From Cengiz_Alaettinoglu at yahoo.com Tue May 11 20:53:52 2004 From: Cengiz_Alaettinoglu at yahoo.com (Cengiz Alaettinoglu) Date: Tue, 11 May 2004 11:53:52 -0700 Subject: RPSLng and nested refine/except expressions In-Reply-To: <200405071717.37661.ljb@merit.edu> References: <200405071717.37661.ljb@merit.edu> Message-ID: <1084297751.3047.10.camel@elf> Historical perspective: - first there was the nested syntax - then it got replaced by the cascading syntax since the sematics were simpler - one example using the nested syntax unfortunately stayed in the document. Note that RPSL only defines semantics for the cascading form. On Fri, 2004-05-07 at 14:17, Larry J. Blunk wrote: > In the -04 version of the RPSLng draft, the structured policy syntax was > updated to allow nested refines and excepts in policy expressions. I.e. > > refine { > > refine { > > } > } > > Examples of such expressions are given both RFC2622 and the RPSLng > draft. However, the original RFC2622 syntax did not actually allow such > expressions. > > However, in the process of implementing and running the syntax check > on existing objects, I have found examples of the following: > > refine { > > } refine { > > } > > See, for example, AS7574 in the RADB. Unfortunately, such expressions > are invalid in the lastest RPSLng draft. Are such expressions semantically > identical to nested refines/excepts? Should both this form and the nested > form be allowed. I have come up with a minor modification to the -04 > syntax that would allow both, but I'm not sure if it is a good idea or not. > > -Larry > > > > -- Cengiz Alaettinoglu From ljb at merit.edu Wed May 12 19:42:04 2004 From: ljb at merit.edu (Larry J. Blunk) Date: Wed, 12 May 2004 13:42:04 -0400 Subject: RPSLng and nested refine/except expressions In-Reply-To: <1084297751.3047.10.camel@elf> References: <200405071717.37661.ljb@merit.edu> <1084297751.3047.10.camel@elf> Message-ID: <200405121342.04282.ljb@merit.edu> Thanks, Cengiz. This greatly simplifies things. I'll update the draft to use the cascading style and note the issue with the example in 2622. -Larry On Tuesday 11 May 2004 14:53, Cengiz Alaettinoglu wrote: > Historical perspective: > - first there was the nested syntax > - then it got replaced by the cascading syntax since the sematics were > simpler > - one example using the nested syntax unfortunately stayed in the > document. > > Note that RPSL only defines semantics for the cascading form. > > On Fri, 2004-05-07 at 14:17, Larry J. Blunk wrote: > > In the -04 version of the RPSLng draft, the structured policy syntax > > was updated to allow nested refines and excepts in policy expressions. > > I.e. > > > > refine { > > > > refine { > > > > } > > } > > > > Examples of such expressions are given both RFC2622 and the RPSLng > > draft. However, the original RFC2622 syntax did not actually allow such > > expressions. > > > > However, in the process of implementing and running the syntax check > > on existing objects, I have found examples of the following: > > > > refine { > > > > } refine { > > > > } > > > > See, for example, AS7574 in the RADB. Unfortunately, such > > expressions are invalid in the lastest RPSLng draft. Are such > > expressions semantically identical to nested refines/excepts? Should > > both this form and the nested form be allowed. I have come up with a > > minor modification to the -04 syntax that would allow both, but I'm not > > sure if it is a good idea or not. > > > > -Larry From ljb at merit.edu Thu May 13 18:06:04 2004 From: ljb at merit.edu (Larry J. Blunk) Date: Thu, 13 May 2004 12:06:04 -0400 Subject: draft-blunk-rpslng-05.txt has been submitted Message-ID: <200405131206.04919.ljb@merit.edu> The draft is available at www.radb.net/rpslng-05.html. The structured syntax has been updated to reflect comments by Cengiz and Mark. Note that the optional afi field is now outside the brackets in refine and except expressions. I believe this is simpler and more intuitive. We may wish to simplify further and only allow an initial afi specification on policy expressions (similar to the optional protocol fields). However, I don't have a strong opinion on this. -Larry From mrp at mrp.net Fri May 14 02:46:28 2004 From: mrp at mrp.net (Mark Prior) Date: Fri, 14 May 2004 10:16:28 +0930 Subject: draft-blunk-rpslng-05.txt has been submitted In-Reply-To: <200405131206.04919.ljb@merit.edu> References: <200405131206.04919.ljb@merit.edu> Message-ID: <40A416E4.9090907@mrp.net> Larry J. Blunk wrote: > The draft is available at www.radb.net/rpslng-05.html. The structured > syntax has been updated to reflect comments by Cengiz and Mark. Note > that the optional afi field is now outside the brackets in refine and except > expressions. I believe this is simpler and more intuitive. We may wish > to simplify further and only allow an initial afi specification on policy > expressions (similar to the optional protocol fields). However, I don't have > a strong opinion on this. Can we also "fix" community_elm so that you can use wildcards, or preferably regular expressions, on each side of the ":". For example, it would be useful to be able to delete(7575:*) rather than have to list them, although delete(7575:[1-9][0-9]{3}) would be better. Mark. From ljb at merit.edu Fri May 14 20:17:40 2004 From: ljb at merit.edu (Larry J. Blunk) Date: Fri, 14 May 2004 14:17:40 -0400 Subject: draft-blunk-rpslng-05.txt has been submitted In-Reply-To: <40A416E4.9090907@mrp.net> References: <200405131206.04919.ljb@merit.edu> <40A416E4.9090907@mrp.net> Message-ID: <200405141417.40262.ljb@merit.edu> On Thursday 13 May 2004 20:46, Mark Prior wrote: > Larry J. Blunk wrote: > > The draft is available at www.radb.net/rpslng-05.html. The > > structured syntax has been updated to reflect comments by Cengiz and > > Mark. Note that the optional afi field is now outside the brackets in > > refine and except expressions. I believe this is simpler and more > > intuitive. We may wish to simplify further and only allow an initial afi > > specification on policy expressions (similar to the optional protocol > > fields). However, I don't have a strong opinion on this. > > Can we also "fix" community_elm so that you can use wildcards, or > preferably regular expressions, on each side of the ":". For example, it > would be useful to be able to delete(7575:*) rather than have to list > them, although delete(7575:[1-9][0-9]{3}) would be better. > > Mark. Unfortunately, the dictionary "typedef" support seems a bit too limited to extend community_elm like this. Do you have any proposed text for the draft? It seems like a new "community_exp" pre-defined type would need to be added to the dictionary. The support for ":" syntax to express "integers" is already a bit of a hack added for communities. Speaking of communities, should the RFC3765 "NOPEER" community be added to the well-known community enum list? -Larry From ljb at merit.edu Mon May 24 20:35:40 2004 From: ljb at merit.edu (Larry Blunk) Date: Mon, 24 May 2004 14:35:40 -0400 Subject: LAST CALL -- draft-blunk-rpslng-05.txt has been submitted In-Reply-To: <200405141417.40262.ljb@merit.edu> References: <200405131206.04919.ljb@merit.edu> <40A416E4.9090907@mrp.net> <200405141417.40262.ljb@merit.edu> Message-ID: <40B2407C.3000001@merit.edu> I'd like to issue a last call to the list for draft-blunk-rpslng-05.txt prior to going to the IESG. Mark, it seems the extensions to community_elm are sufficiently complex and outside the scope of this draft that they should not be included. However, I'd appreciate hearing feedback from others (some text would be nice as well) about whether or not they think this is important enough to hold up the draft for inclusion. -Larry Larry J. Blunk wrote: > On Thursday 13 May 2004 20:46, Mark Prior wrote: > >>Larry J. Blunk wrote: >> >>> The draft is available at www.radb.net/rpslng-05.html. The >>>structured syntax has been updated to reflect comments by Cengiz and >>>Mark. Note that the optional afi field is now outside the brackets in >>>refine and except expressions. I believe this is simpler and more >>>intuitive. We may wish to simplify further and only allow an initial afi >>>specification on policy expressions (similar to the optional protocol >>>fields). However, I don't have a strong opinion on this. >> >>Can we also "fix" community_elm so that you can use wildcards, or >>preferably regular expressions, on each side of the ":". For example, it >>would be useful to be able to delete(7575:*) rather than have to list >>them, although delete(7575:[1-9][0-9]{3}) would be better. >> >>Mark. > > > Unfortunately, the dictionary "typedef" support seems a bit too limited > to extend community_elm like this. Do you have any proposed text for > the draft? It seems like a new "community_exp" pre-defined type would need > to be added to the dictionary. The support for ":" syntax to > express "integers" is already a bit of a hack added for communities. > > Speaking of communities, should the RFC3765 "NOPEER" community be > added to the well-known community enum list? > > -Larry > > From engin at ripe.net Thu May 27 14:08:25 2004 From: engin at ripe.net (Engin Gunduz) Date: Thu, 27 May 2004 14:08:25 +0200 Subject: LAST CALL -- draft-blunk-rpslng-05.txt has been submitted In-Reply-To: <40B2407C.3000001@merit.edu> References: <200405131206.04919.ljb@merit.edu> <40A416E4.9090907@mrp.net> <200405141417.40262.ljb@merit.edu> <40B2407C.3000001@merit.edu> Message-ID: <20040527120824.GB27594@x47.ripe.net> Hi all, On 2004-05-24 14:35:40 -0400, Larry Blunk wrote: > I'd like to issue a last call to the list for > draft-blunk-rpslng-05.txt prior to going to the IESG. I'd say let's go ahead. > Mark, it seems the extensions to community_elm are > sufficiently complex and outside the scope of this draft > that they should not be included. I agree that this is outside the scope of this effort. Even if there are many other things that can be fixed or improved in RPSL RFC, they will take considerable time. Regards, -engin > However, I'd appreciate > hearing feedback from others (some text would be nice as > well) about whether or not they think this is important > enough to hold up the draft for inclusion. > > -Larry > > > > Larry J. Blunk wrote: > >On Thursday 13 May 2004 20:46, Mark Prior wrote: > > > >>Larry J. Blunk wrote: > >> > >>> The draft is available at www.radb.net/rpslng-05.html. The > >>>structured syntax has been updated to reflect comments by Cengiz and > >>>Mark. Note that the optional afi field is now outside the brackets in > >>>refine and except expressions. I believe this is simpler and more > >>>intuitive. We may wish to simplify further and only allow an initial afi > >>>specification on policy expressions (similar to the optional protocol > >>>fields). However, I don't have a strong opinion on this. > >> > >>Can we also "fix" community_elm so that you can use wildcards, or > >>preferably regular expressions, on each side of the ":". For example, it > >>would be useful to be able to delete(7575:*) rather than have to list > >>them, although delete(7575:[1-9][0-9]{3}) would be better. > >> > >>Mark. > > > > > > Unfortunately, the dictionary "typedef" support seems a bit too > > limited > >to extend community_elm like this. Do you have any proposed text for > >the draft? It seems like a new "community_exp" pre-defined type would > >need > >to be added to the dictionary. The support for ":" syntax to > >express "integers" is already a bit of a hack added for communities. > > > > Speaking of communities, should the RFC3765 "NOPEER" community be > >added to the well-known community enum list? > > > > -Larry > > > > -- Engin Gunduz RIPE NCC Software Engineering Department From simon at limmat.switch.ch Sat May 29 12:29:54 2004 From: simon at limmat.switch.ch (Simon Leinen) Date: Sat, 29 May 2004 12:29:54 +0200 Subject: LAST CALL -- draft-blunk-rpslng-05.txt has been submitted In-Reply-To: <40B2407C.3000001@merit.edu> (Larry Blunk's message of "Mon, 24 May 2004 14:35:40 -0400") References: <200405131206.04919.ljb@merit.edu> <40A416E4.9090907@mrp.net> <200405141417.40262.ljb@merit.edu> <40B2407C.3000001@merit.edu> Message-ID: Short version: Let's ship it! Long version: I think the current version is Good Enough, and it's high time we get this out as an RFC, so that the routing registries implement it and we (ISPs that have peerings other than IPv4 unicast) can use it. Personally I'm not convinced that the current defaulting semantics in the "mp-..." attributes are optimal, but they seem to be close to the best compromise that we can achieve. My reservation is that we default mp-... without "afi" qualifier to default to exactly the four AFI/SAFIs of ipv4.unicast, ipv4.multicast, ipv6.unicast, ipv6.multicast, and this set of four AFI/SAFIs doesn't seem to be guaranteed future-proof. But I don't care, I don't think I'll be using the defaults anyway (look at AS559 in the RIPE test whois registry at rpslng.ripe.net, port 53001, for how I intend to use RPSLng). By the time people will want different defaults - either because IPv4 or IPv6 or multicast (re-)become exotic, or something else becomes widespread - we simply won't be able to seamlessly change those defaults. But probably by that time it will be a good idea to base the routing registry on something completely different anyway. A unified grammar (maybe even in RFC2234-compatible ABNF!) would be great, but let's leave this for a future RFC that replaces both RFC 2622 and the RPSLng RFC. Regards, -- Simon. From asjl at lpnz.org Sun May 30 03:14:09 2004 From: asjl at lpnz.org (Andy Linton) Date: Sun, 30 May 2004 13:14:09 +1200 Subject: LAST CALL -- draft-blunk-rpslng-05.txt has been submitted In-Reply-To: References: <200405131206.04919.ljb@merit.edu> <40A416E4.9090907@mrp.net> <200405141417.40262.ljb@merit.edu> <40B2407C.3000001@merit.edu> Message-ID: <40B93561.7090306@lpnz.org> Simon Leinen wrote: > Short version: Let's ship it! > I'd like this out as well - I want to get on with getting the New Zealand IXes using RPSL based configuration for the IPv6 route servers and I want to be able to point to a standard so I can start persuading the particpants to do the right thing with IPv6 from day one. I may then even persuade them of the value for IPv4. From cfriacas at fccn.pt Mon May 31 13:30:34 2004 From: cfriacas at fccn.pt (Carlos Friacas) Date: Mon, 31 May 2004 12:30:34 +0100 (WEST) Subject: LAST CALL -- draft-blunk-rpslng-05.txt has been submitted In-Reply-To: References: <200405131206.04919.ljb@merit.edu> <40A416E4.9090907@mrp.net> <200405141417.40262.ljb@merit.edu> <40B2407C.3000001@merit.edu> Message-ID: On Sat, 29 May 2004, Simon Leinen wrote: > Short version: Let's ship it! > > Long version: > > I think the current version is Good Enough, and it's high time we get > this out as an RFC, so that the routing registries implement it and we > (ISPs that have peerings other than IPv4 unicast) can use it. > > Personally I'm not convinced that the current defaulting semantics in > the "mp-..." attributes are optimal, but they seem to be close to the > best compromise that we can achieve. My reservation is that we > default mp-... without "afi" qualifier to default to exactly the four > AFI/SAFIs of ipv4.unicast, ipv4.multicast, ipv6.unicast, > ipv6.multicast, and this set of four AFI/SAFIs doesn't seem to be > guaranteed future-proof. But I don't care, I don't think I'll be > using the defaults anyway (look at AS559 in the RIPE test whois > registry at rpslng.ripe.net, port 53001, for how I intend to use > RPSLng). By the time people will want different defaults - either > because IPv4 or IPv6 or multicast (re-)become exotic, or something > else becomes widespread - we simply won't be able to seamlessly change > those defaults. But probably by that time it will be a good idea to > base the routing registry on something completely different anyway. > > A unified grammar (maybe even in RFC2234-compatible ABNF!) would be > great, but let's leave this for a future RFC that replaces both RFC > 2622 and the RPSLng RFC. > > Regards, > -- > Simon. Hello, I strongly agree with Simon. This is already suitable enough to be taken to the next step (the deployment that will enable non-v4-unicast-only ISPs to express their own routing policies). Regards, ./Carlos -------------- IPv6 -> http://www.ip6.fccn.pt Wide Area Network Workgroup, CMF8-RIPE, CF596-ARIN FCCN - Fundacao para a Computacao Cientifica Nacional http://www.fccn.pt "Internet is just routes (135072/470), naming (millions) and... people!"