- db-wg - mailman.ripe.net

Removal of selected sets of contact information from the RIPE Database
by Joao Luis Silva Damas 23 Aug '01

23 Aug '01

Dear all, (apologies for duplicates) As you know, the subject of storage of person and role objects in the RIPE Database has been the focus of attention for some time, particularly information being stored in the Database that is not directly related to RIPE NCC activities and/or some of the people whose information is stored in the RIPE Database are not aware of the fact. During the RIPE 39 meeting in Bologna, I reported on increasing concerns about data privacy issues and potential legal implications the RIPE NCC could be involved in due to some of this data. Call it a coincidence,but we have been approached by the Dutch Data Protection Agency a few weeks ago to discuss this matter. The agency's action is taken on behalf of other similar global agencies who have requested their Dutch counterparts to act as the RIPE NCC is based in the Netherlands. As a result of the discussions, the authorities have requested the RIPE NCC to remove all unreferenced data currently stored in the Database. This affects mainly person objects related to domain name registration information stored in the RIPE Database. In order to minimise annoyances to users and the membership we would like to proceed with the process in a timely manner. In order to prevent undue deletions we propose the following process: 1. The following unreferenced person objects will be deleted: - objects referenced only from *.de domains, according to the list provided by DENIC (or list of mntners that define that set); - objects that are un-maintained. 2. Those who want to protect their objects in the database should tag them with a special mntner (RIPE-NCC-PN-NONE-MNT). This procedure is solely meant for personal use by individuals interested in keeping their personal data in the RIPE Database. However, this is subject to change in the future. 3. All of the object deletions will be performed in one step. There will be an outage in updates for ~1 day. We plan to start the process Friday, 21 September 2001 in the evening and finish by the end of Saturday. More concrete details will be provided in the coming weeks. Best regards, Joao Damas RIPE NCC

2 1

New RIPE-147 needed!
by Berislav Todorovic 23 Aug '01

23 Aug '01

Maybe this will sound like a hassle, but ... ... Everytime I receive a ripe-147 form from teh customer I have to "patch" it myself, to make it compliant with the new RPSL syntax. Any chance to get the new, RPSL-capable form in place (but as a NEW RIPE document, please!)? Here's what should be changed: * Add "as-name:" attribute. * Replace "as-in:" with "import:" and "as-out:" with "export:". * Check to see if RPSL syntax is honored. * Check the examples and make them compliant with RPSL syntax. Regards, Beri --------- Berislav Todorovic, Network Engineer --------- ------- KPNQwest N.V. - IP NOC (formerly EUnet NOC) ------- ---- Wilhelmina van Pruisenweg 78, 2595 AN Den Haag, NL ---- --- Phone: +31-70-379-3990; Mobile: +31-651-333-641 --- -- Email: beri(a)kpnqwest.net <=> beri(a)EU.net -- --- _ _ ____ _ .--. ____ ____ __/_ --- ----- /__/ /___/ /\ / / / | / /___/ /___ / ------ ------ _/ \_ / _/ \/ (__.\ |/\/ /___ ____/ (__. -----

1 0

Limitation in the RPSL DB
by Stephen Burley 08 Aug '01

08 Aug '01

Hi We have hit a small problem with the RPSL DB structure. As the RPSL DB is supposed to reflect the real routing world we need some functionality adding to the DB. It is possable for PA that is part of a multihomed customer to have a differant origin to that of the main block of ip space. Can we get this refelected the in RPSL DB structure? Would you like me to explain further? Regards Stephen Burley UUNET EMEA Hostmaster

4 3

sub-allocations or something similar
by Dmitry Morozovsky 08 Aug '01

08 Aug '01

Hello there colleagues, for some last years I'm working with RIPE DB I think it would be useful to have some kind of "sub-allocation" inetnum objects. Brief example in our current situation: there is downstream provider behind us, currently without its own address block, so I've assigned /21 for them. All that space was of course well-documented, with ripe-141's covering all the nets, and appropriate inetnum objects have been created. But, for aggregating purposes, I suppose aggregating inetnum for the whole /21 would be useful and self-documenting. I can create such object, but such object is considered as overlapped. I think about explicit route-object also, but size behind current minimum allocation size (/19 for 195/8 or /20 for newer) somewhat stops me :) Your (both community and especially RIPE NCC people) suggestions are strongly expected ;-) Thank you. Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck(a)rinet.ru *** ------------------------------------------------------------------------

4 4

Problems with Albanian Domains
by Elvis.Samson＠ernst-young.de 26 Jul '01

26 Jul '01

Hi, why is the albanian domain inima.al accessible through internet, but not listed in the ripe database? there are some european TLDs, where I couldn't find accessible websites in the ripe database. is there a reason for this or an error? regards and thanks for your help, elvis samson

2 1

RE: Problems with Albanian Domains
by Wilfried Woeber, UniVie/ACOnet 26 Jul '01

26 Jul '01

>why is the albanian domain inima.al accessible through internet, but not >listed in the ripe database? That is most probably due to the fact the RIPE DB is *not* an authoritative registry for (forward) domain names. While some TLD administrations indeed did use the RIPE-DB for some years to maintain a list of allocated/delegated domains, there was a major push during 2000 to remove (close to) all forward domain entries from the RIPE-DB. The RIEP-DB is still authortitative for the reverse Domains for address space that was distributed by way of the RIPE NCC. >there are some european TLDs, where I couldn't >find accessible websites in the ripe database. is there a reason for this >or an error? All TLD Administartors are welcome to register an object for the TLD itself - including a pointer to the whois server that in turn can answer queries. This mechanism is called "referral" and it works for some, but not for all, european TLDs. For an example how this looks like in reality, do a whois-query for e.g. $ whois -h whois.ripe.net -T domain unige.ch While this mechanism is available as an offer, neither the RIPE NCC nor the DB-WG have a mandate to urge TLD administrators to use that faciliy. >regards and thanks for your help, >elvis samson Just in case you want to follow up on Albanian domains, I'd suggest you get in touch with <Francesco.Gennai(a)iat.cnr.it> . This gentleman is listed as a contact in the SOA record for the TLD "AL". ______________________________________________________________________ bash$ nslookup Default Server: wsww.xx.xxxxxx.xx.at Address: 131.130.x.xxx > set q=soa > al. Server: wsww.xx.xxxxxx.xx.at Address: 131.130.x.xxx al origin = itgbox.iat.cnr.it mail addr = Francesco\.Gennai.iat.cnr.it [ ... ] ______________________________________________________________________ Best regards, -WW _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

Re: BOUNCE db-wg@ripe.net: Non-member submission from ["Zvezdelin Vladov" <zvezdi@langame.net>]
by RIPE NCC Staff 17 Jul '01

17 Jul '01

Dear Zvezdelin Vladov, This is indeed strange. Since both objects were created in the version 2 of the database, it is likely that there was a bug at some point that allowed the creation of duplicate nic-hdl in the database. As far as I know, this has not happened since version 3 went on-line 2001-04-23. Thanks for finding this - I'll contact the two people with the same nic-hdl and do what I can to help them straighten out the resulting mess (there are 456 objects that reference this nic-hdl!). If you have any more questions, please don't hesitate to contact <ripe-dbm(a)ripe.net>. Regards, Shane Kerr ____________________________ RIPE Database Administration. Original message: ---------------- From: "Zvezdelin Vladov" <zvezdi(a)langame.net> To: <db-help(a)ripe.net> Cc: <db-wg(a)ripe.net> Subject: strange person object???referenced, but does not exist? Date: Mon, 16 Jul 2001 16:25:21 +0200 Please, do the following query: whoisRIP -i tech-c KP389-RIPE This is person object of Kostantin Paeev, but at the end of the listing, you'll THE SAME NIC HDL NUMBER but for person: Katharina Potthoff When you look for this person Katharina, it does not exist in normal query. It this normal? for me this looks strange. Zvezdelin Vladov System&Network Manager AngelSoft Bulgaria Ph:+359 32 271209 Fax: +359 32 270934

2 1

bug in dictionary definition?
by unicorn＠Toledo.Kao.sm.net.ua 10 Jul '01

10 Jul '01

On Mon, 9 Jul 2001, RIPE Database Management wrote: > domain: Test-Forest.Od.UA > ... > nserver: 195.138.70.161 > ***Error: argument to nserver should be list [1:65535] of union DNS_name, rpsl_word. Does this complies `whois -v domain' information? It sais: > ... > nserver > > List of nameservers for a domain object; a minimum > of two is mandatory . > > <Fully qualified domain name(s) without trailing "."> > OR <IP Address(es) of the nameserver(s)> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > ... Whad do I have to place in `nserver field', in case I have no domain name at all? Is that `rpsl_word' should represent the reference to some another object describing my nameserver address? -- Sit Benedictum. Dragomiretsky Victor, Odessa Dept, KAM.

2 1

RE: Problems with WWW Whois ..
by RIPE NCC WebMaster 09 Jul '01

09 Jul '01

Hi Adam, >There seems to be another small bug in the WWW whois passer, >if you try to query for objects containing ':' (AS13646:RS-BOGONS-IN) >then you get the following output: The Whois arguments are invalid >( AS13646%3ARS-BOGONS-IN ). Please correct Cheers, > >Adam Thanks for the notification. We've mod_perl'ed the script to make it more efficient (you should see a great speed improvement in general) but one or two bugs have slipped though testing. We'll weed them out ASAP. On the near horizon is a completely new script with a somewhat more friendly interface. Regards, Lee Wilmot RIPE NCC p.s. could you please report problems to <webmaster(a)ripe.net> rather than to the working group, although I understand you were only replying to the original mail. Thanks :-)

1 0

RE: Problems with WWW Whois ...
by Low, Adam 06 Jul '01

06 Jul '01

Shane, There seems to be another small bug in the WWW whois passer, if you try to query for objects containing ':' (AS13646:RS-BOGONS-IN) then you get the following output: The Whois arguments are invalid ( AS13646%3ARS-BOGONS-IN ). Please correct Cheers, Adam

1 0

RIPE DB crash
by Magnus Karlsson 06 Jul '01

06 Jul '01

Yesterday there was a power outage at the NIKHEF. Following this outage the RIPE Database crashed. No objects or updates are lost! There is no need to resend your updates! The database will be fully restored during the day. All updates are queued and will be processed as soon as the database is fully restored. Thank you for your patience. -- Magnus Karlsson, RIPE NCC Database Group

2 1

Problems with WWW Whois ...
by Low, Adam 05 Jul '01

05 Jul '01

Hi, Is anybody working on the WWW whois on www.ripe.net ? I'm having inconsistent problems with numerous browsers, sometimes the query is successful but just as often I get an error message complaining about the URL and specifically the arguments passed to the script. It looks to me that someone's changed the code behind the submit button to add some trailing junk (submit=Submit) that the script cant pass. The Whois arguments are invalid ( AS13646&.submit=Submit+Query ). Please correct The Whois arguments are invalid ( AS13646&.submit= ). Please correct Anyone having problems with or have info ? Thanks, Adam

2 1

Publication of New RIPE Database Doc.
by Paul Rendek 03 Jul '01

03 Jul '01

Dear Colleagues, The RIPE NCC is pleased to announce that this week it will publish the "RIPE Database Reference Manual" on the RIPE NCC website. The new RIPE document is expected to answer many questions of Local Internet Registries and other users regarding the migration to version 3.0 of the RIPE Database software implemented on 23 April 2001. The new RIPE document obsoletes two previous documents: "RIPE Database Documentation Update" (ripe-189) and "RIPE Database Documentation" (ripe-157). The RIPE Database Reference Manual describes the functionality of the new version of the RIPE Database software that now uses the Routing Policy Specification Language (RPSL) to represent all database objects. RPSL defines an extended syntax for all database objects, mainly for the routing registry objects. Many new features have been implemented in this new version, such as Routing Policy System Security (RPSS) support specified in RFC 2725, fast IP lookups and automatic access control. RPSS provides authorisation mechanisms that enable a higher level of security for the Internet Routing Registries. Although the document is self-contained, it does not have examples of usage and illustrations of principles and concepts related to the RIPE Database functionality and implementation. This need will be filled by the "RIPE Database User's Manual" and the "RIPE Database Operations Manual" that are scheduled to be written. For more information and better understanding of the new document, the RIPE NCC encourages readers to brush up on RPSL (explained in RFC 2622), RPSS (explained in RFC 2725) and "Using RPSL in Practice" (the title of RFC 2650). Joao Luis Silva Damas, Chief Technical Officer of the RIPE NCC, wishes to acknowledge the contributions of past and present colleagues in the development of version 3.0 of the RIPE Database software: Andrei Robachevsky, Daniele Arena, Marek Bukowy, Engin Gunduz, Roman Karpiuk, Shane Kerr, A.M.R. Magee, Chris Ottrey and Filippo Portera. Paul Rendek RIPE NCC # # #

2 1

Unprocessed update mails to RIPE Whois Database
by RIPE Database Administration 25 Jun '01

25 Jun '01

Dear Colleagues, [apologies for duplicate messages] Between Thu Jun 14 16:19:15 2001 CEST and Fri Jun 15 10:34:29 2001 CEST, due to a failure in our systems which processes updates to RIPE Whois Database, the update message have not been processed, instead they were only stored. Most of the users who sent those messages noticed that they didn't get any acknowledgement from our system, and re-sent their updates. Realizing the failure on Friday Jun 22, we tried to find out those messages which were _not_ re-sent by the user, and we processed them. Thus, please don't be confused if you've got a late acknowledgement message. If you have any questions about the incident, please contact <ripe-dbm(a)ripe.net>. We are sorry about the inconvenience this caused. Best Regards, Engin Gunduz RIPE NCC Database Group

1 0

AW: AW: DB V3 feature request
by Andres Petralli 21 Jun '01

21 Jun '01

> > The real problem is the internal structs we use in the > software: they don't allow the programmer to change the object's text > representation easily. That's why it requires a biggish effort > to implement this. > If this is so, then we will run into many problems in future. I don't think ip-ranges will be the only things that will need to be stored in the db. Just think of routes, ases, whatever! This behaviour should be possibly avoided. Don't you think it would be wise to solve the problem now? Greets, Andres

1 0

AW: DB V3 feature request
by Andres Petralli 21 Jun '01

21 Jun '01

> a.b.c.d/xx > a.b.c.d 255.255.255.X > a.b.c.d - w.x.y.z > > I do not care if the object created always contains: > > a.b.c.d - w.x.y.z > Absolutely! It makes no sense that ripe changed to this dashed-only notation. I would also very much appreciate if at least the slashed notation would be re-introduced. This kind of notation is much more common than the other one! Greets Andres

3 2

RIPE-181 to RPSL Migration; Phase 2.
by db-news＠ripe.net 20 Jun '01

20 Jun '01

Dear Colleagues, (Apologies for multiple messages). On and from Monday, 14th May, 2001, <auto-dbm(a)ripe.net> shall only accept updates in RPSL format; updates in RIPE-181 format will no longer be accepted. Updates in RIPE-181 format can be sent to <auto-181(a)ripe.net>, where they will be automatically converted to RPSL format. <auto-rpsl(a)ripe.net> will continue to accept updates in RPSL format. The update path for the TEST database will also be changed. In summary, from 14th May, 2001: =============================== RIPE Database: ------------- <auto-dbm(a)ripe.net> - updates in RPSL format only <auto-rpsl(a)ripe.net> - updates in RPSL format only <auto-181(a)ripe.net> - updates in RIPE-181 format, automatically converted to RPS L format TEST Database: ------------- <test-dbm(a)ripe.net> - updates in RPSL format only <test-rpsl(a)ripe.net> - updates in RPSL format only <test-181(a)ripe.net> - updates in RIPE-181 format, automatically converted to RPS L format On Monday, 14th May, 2001, we cannot guarantee that an update message sent to <auto-dbm(a)ripe.net> will use a specific update path (RPSL or RIPE-181). Thus, we advise that updates in RIPE-181 format should be sent to <auto-181(a)ripe.net> and that updates in RPSL format should be sent to <auto-rpsl(a)ripe.net>. Please note that from Monday, 15th October, 2001, updates in RIPE-181 format will no longer be accepted by the RIPE Database. Further information is available from http://www.ripe.net/rpsl/. If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, A. M. R. Magee -------------- Database Group RIPE NCC

7 8

cgi-bin/whois?query broken
by Heiko Blume 19 Jun '01

19 Jun '01

hello when inserting objects with <angle brackets> like this: import: from AS1273 action pref=100; accept <AS-ECRC> AND NOT {0.0.0.0/0} the query http://www.ripe.net/cgi-bin/whois?query=AS5427 will not display the data correctly: import: from AS1270 action pref=100; accept AND NOT {0.0.0.0/0} also, AFAIR previously the http output made the 'ASxxx' strings as links to the objects which was very convenient. will we see that again? regards, heiko -- Heiko Blume (HB21) mailto:heiko.blume@iprimus.de iPrimus Telecommunications GmbH http://www.iprimus.de Marienburger Str. 1, D-10405 Berlin Phone: +49.30/443366-0 Fax: -15 Core-l -- If you don't know then you don't need to know

2 1

Another one feature request
by Dmitry Morozovsky 19 Jun '01

19 Jun '01

Hello there colleagues, what about loosing requirements a little for inetnum ranges format? Specifically, do not require spaces around dash in the middle of two IPv4? I.e., 195.91.168.0-195.91.169.255 I suppose could be considered as valid range as 195.91.168.0 - 195.91.169.255 Thank you in advance :) Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck(a)rinet.ru *** ------------------------------------------------------------------------

3 3

Help upderstanding error while updating ripe mntner object ...
by Thomas C. Knoeller 19 Jun '01

19 Jun '01

Howdy, Sorry to waste bandwidth, but I was wondering if someone could explain to me this error I am getting while trying to update an object in the ripe database. I am updating a maintainer object, and it seems to get past the authentication state (pgp auth), and the parsing state, but gives me the error: ==== BEGIN PGP SIGNED PART (keyID(s): C9DD67B0) ==== Update FAILED: [mntner] GBLX-RIPE-MNT ***Error: Object is referenced from other objects ==== END PGP SIGNED PART ==== Since this is the maintainer object for the rest of my objects in the database, I would think having it references from other objects would be a good thing. Can you help me understand what I am missing here? Thanks, -Tom

2 1

Another one feature request (or bug report?) Re: (fwd)
by Dmitry Morozovsky 18 Jun '01

18 Jun '01

Hello there colleagues, I suppose it is not so hard to implement ignoring of leading whitespaces in update messages. Just because automatic RIPE-141 checker produce indented objects... Thank you as always for you cooperation. Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck(a)rinet.ru *** ------------------------------------------------------------------------ ---------- Forwarded message ---------- Date: Fri, 15 Jun 2001 15:50:14 +0200 (MEST) From: RIPE Database Management <ripe-dbm(a)ripe.net> To: marck(a)rinet.ru Subject: Re: Acknowledgement message from database software Your e-mail: > From: Dmitry Morozovsky <marck(a)rinet.ru> > Cc: > Subject: > Date: Fri, 15 Jun 2001 17:50:00 +0400 (MSD) > Msg-Id: <Pine.BSF.4.21.0106151749460.9594-100000(a)woozle.rinet.ru> has been processed by the automatic update procedure at the RIPE NCC. Diagnostic output follows: ------------------------------------------------------------------------ ==== BEGIN PGP SIGNED PART (keyID(s): 55C20C73) ==== Update FAILED: Syntax error in object inetnum: 195.91.162.208 - 195.91.162.223 netname: RINET-HANNA-NET descr: Development jail block country: RU admin-c: AUTO-1 tech-c: RHM-RIPE status: ASSIGNED PA mnt-by: RINET changed: marck(a)rinet.ru 20010615 source: RIPE ***Error: syntax error ***Error: Unknown class encountered. Update FAILED: Syntax error in object person: Anna E. Losovskaya address: Off. 111, Bld. 11a, 1st Khvostov Lane address: Moscow 109180 RU phone: +7 (095) 916-7009 fax-no: +7 (095) 916-7008 e-mail: hanna(a)rinet.ru nic-hdl: AUTO-1 mnt-by: RINET changed: marck(a)rinet.ru 20010615 source: RIPE ***Error: syntax error ***Error: Unknown class encountered. ==== END PGP SIGNED PART ==== Objects in RIPE-181 format must be sent to <auto-181(a)ripe.net>, which are converted into RPSL format before processing. This will be possible only until October 15, 2001. Please see http://www.ripe.net/rpsl for more information. RIPE Database Maintenance Department

4 3

New mailing list: db-help
by Andrei Robachevsky 15 Jun '01

15 Jun '01

Dear Colleagues, Following the request from the community the RIPE NCC created a new mailing list: db-help(a)ripe.net. The charter of the list is as follows: "The db-help mailing list is provided to facilitate exchange knowledge and expertise about the RIPE Database between more experienced users of the database and less experienced ones. The RIPE NCC provides their input on a best effort basis. In case one expects an answer from the RIPE NCC, the request should be directed to the RIPE Database Administration at ripe-dbm(a)ripe.net." The RIPE NCC will regularly publish the contents of the Database FAQ and other useful information. Put the line "subscribe db-help" in the body of the message to majordomo(a)ripe.net to add your address to the list. Alternatively, you can send the line "help" in the body to get a list of commands accepted by the majordomo mail server. Regards, Andrei Robachevsky DB Group Manager RIPE NCC

1 0

Announcement: RIPE Database software version 3.0.1
by RIPE Database Administration 14 Jun '01

14 Jun '01

Dear Colleagues, [Apologies for multiple messages]. The RIPE NCC is pleased to announce the release of Version 3.0.1 of the RIPE Database software. This software is compliant with both RPSL (RFC-2622) and RPS-Security (RFC-2725). This release is primarily a bug fix release. No new features were added to the server. You can download this release by anonymous FTP from the following URL: ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-3.0.1.tar.gz If you do not intend to use the cross-reference files or prefer to build them yourself via "make docs", you can download the source without these files by anonymous FTP from the following URL: ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-3.0.1-nocxref.tar.gz A new version of the Whois client is also included with this release, in the utils/whois3 directory. You can also download this client separately by anonymous FTP from the following URL: ftp://ftp.ripe.net/tools/ripe-whois-3.0.tar.gz If you have any more questions, please don't hesitate to contact <ripe-dbm(a)ripe.net>. Regards, --- Shane Kerr Database Software Engineer RIPE NCC

1 0

RE: RPSL route-set/as-set query.
by Low, Adam 11 Jun '01

11 Jun '01

Thanks for that insight, I guess we are going to have to replace our old as-macro/set with a route-set instead then, I wonder if it would be easier to change the RPSL specification than request all our peers to change there policy configurations! (c: Thanks, Adam > -----Original Message----- > From: Andrei Robachevsky [mailto:andrei@ripe.net] > Sent: 11 June 2001 11:49 > To: Low, Adam > Cc: db-wg(a)ripe.net; ripe-dbm(a)ripe.net > Subject: Re: RPSL route-set/as-set query. > > > Dear Adam, > > "Low, Adam" wrote: > > > > Hi Colleagues, > > > > I had a question that I am unable to find an answer for > within the RPSL RFC's, it seems that it is not possible to > nest route-set objects within as-set objects, would this be a > limitation of the RIPE DBM, RPSL or syntax ?! > > > > This is a limitation of RPSL. Members of an as-set are aut-nums and > as-sets. > > However, a route-set members could be prefixes, other > route-sets as well > as aut-nums and as-sets. In such cases an aut-num defines the set of > routes that are originated by that AS and an as-set defines the set of > routes that are originated by the ASes in that as-set. > > > The reason I ask is that we are migrating a customer onto > our network and whilst renumbering we will be advertising > there assigned blocks from another provider. We currently use > as-set's to depict our announcements to peers/providers so > would like to add these to our as-set using a route-set > object without having to replace our as-set object with a > route-set object for our peer/provider announcements. > > > > Thanks, > > Adam > > Regards, > > > Andrei Robachevsky > DB Group Manager > RIPE NCC >

1 0

RPSL route-set/as-set query.
by Low, Adam 11 Jun '01

11 Jun '01

Hi Colleagues, I had a question that I am unable to find an answer for within the RPSL RFC's, it seems that it is not possible to nest route-set objects within as-set objects, would this be a limitation of the RIPE DBM, RPSL or syntax ?! The reason I ask is that we are migrating a customer onto our network and whilst renumbering we will be advertising there assigned blocks from another provider. We currently use as-set's to depict our announcements to peers/providers so would like to add these to our as-set using a route-set object without having to replace our as-set object with a route-set object for our peer/provider announcements. Thanks, Adam

2 1