From ala at merit.edu Tue Apr 4 21:34:54 1995 From: ala at merit.edu (Andrew Adams) Date: Tue, 4 Apr 1995 15:34:54 -0400 Subject: bug report Message-ID: <199504041934.PAA27180@home.merit.edu> Ok, here's a fun bug for you all. 1) Create a new database (mine was called PALA) and run netdbm on it. 2) Add a single maintainer object. (Below is the one I added). mntner: MAINT-AS568 descr: People authorized to make changes for AS568 admin-c: Not Available from PRDB upd-to: ala at merit.edu auth: MAIL-FROM ala at merit.edu auth: MAIL-FROM ala at home.merit.edu auth: MAIL-FROM ala at shockwave.merit.edu auth: MAIL-FROM ala at twain.merit.edu auth: MAIL-FROM ala at toad.merit.edu remarks: DDN NIC Staff remarks: PRE-APPROVAL: AS 568 pre-approves any requests involving their AS. changed: DB-admin at ra.net 950404 source: PALA 3) Add a single route object which ref's the maintainer you just added. (Below is the one I added). route: 137.8.0.0/14 descr: DISA, DSAC descr: P. O. Box 1605 descr: Columbus descr: OH 43216-5002, USA origin: AS568 withdrawn: 950404 advisory: AS690 1:568(144) 2:568(145) mnt-by: MAINT-AS568 changed: ala at merit.edu 950404 source: PALA 4) Now read the object back via whois. shockwave.merit.edu: whois -h radb2.ra.net '-s PALA 137.8.0.0/14' route: 137.8.0.0/14 descr: DISA, DSAC descr: P. O. Box 1605 descr: Columbus descr: OH 43216-5002, USA origin: AS568 withdrawn: 950404 withdrawn: 950404 advisory: AS690 1:568(144) 2:568(145) mnt-by: MAINT-AS568 changed: ala at merit.edu 950404 withdrawn: 950404 withdrawn: 950404 source: PALA Notice that the single, original withdrawn attribute has turned into four withdrawn attributes. 5) Now run cleandb on the database. (cleandb -c pala.db) 6) Now read the object back via whois. shockwave.merit.edu: !wh whois -h radb2.ra.net '-s PALA 137.8.0.0/14' route: 137.8.0.0/14 descr: DISA, DSAC descr: P. O. Box 1605 descr: Columbus descr: OH 43216-5002, USA origin: AS568 withdrawn: 950404 withdrawn: 950404 withdrawn: 950404 withdrawn: 950404 advisory: AS690 1:568(144) 2:568(145) mnt-by: MAINT-AS568 changed: ala at merit.edu 950404 withdrawn: 950404 withdrawn: 950404 withdrawn: 950404 withdrawn: 950404 source: PALA Notice that the four withdrawn attributes has turned into 8! 7) And every time clean db runs, the number of withdrawn attributes doubles! 8) Another data point - if the original route object contains an error, say the mask doesn't match the prefix, the error message that is returned contains the original object with two withdrawn attributes, instead of the original, single one. We have a route object in the radb number of withdrawn attributes is starting to get really long! (cleandb runs every nite). :-) -Andy -------- Logged at Tue Apr 4 23:26:36 MET DST 1995 --------- From marten at BayNetworks.com Tue Apr 4 23:24:56 1995 From: marten at BayNetworks.com (Marten Terpstra) Date: Tue, 04 Apr 1995 17:24:56 -0400 Subject: bug report In-Reply-To: Your message of Tue, 04 Apr 1995 15:34:54 EDT. <199504041934.PAA27180@home.merit.edu> Message-ID: <9504042124.AA00412@class.wellfleet> Andy, first and very quick guess. This problem does not seem to appear in the version running at the NCC. There are some routes in there with the withdrawn attribute that have been cleaned many many times. So here's my guess. Check the definition you have for the route objects in your config, specifically the ATSQ line. From what I see below, you have the wd attribute in there twice, once after the advisory attribute and once after the change attribute.... -Marten Andrew Adams writes * * Ok, here's a fun bug for you all. * * 1) Create a new database (mine was called PALA) and run netdbm on it. * * 2) Add a single maintainer object. (Below is the one I added). * * mntner: MAINT-AS568 * descr: People authorized to make changes for AS568 * admin-c: Not Available from PRDB * upd-to: ala at merit.edu * auth: MAIL-FROM ala at merit.edu * auth: MAIL-FROM ala at home.merit.edu * auth: MAIL-FROM ala at shockwave.merit.edu * auth: MAIL-FROM ala at twain.merit.edu * auth: MAIL-FROM ala at toad.merit.edu * remarks: DDN NIC Staff * remarks: PRE-APPROVAL: AS 568 pre-approves any requests involving the * ir AS. * changed: DB-admin at ra.net 950404 * source: PALA * * * 3) Add a single route object which ref's the maintainer you just added. * (Below is the one I added). * * route: 137.8.0.0/14 * descr: DISA, DSAC * descr: P. O. Box 1605 * descr: Columbus * descr: OH 43216-5002, USA * origin: AS568 * withdrawn: 950404 * advisory: AS690 1:568(144) 2:568(145) * mnt-by: MAINT-AS568 * changed: ala at merit.edu 950404 * source: PALA * * 4) Now read the object back via whois. * * shockwave.merit.edu: whois -h radb2.ra.net '-s PALA 137.8.0.0/14' * route: 137.8.0.0/14 * descr: DISA, DSAC * descr: P. O. Box 1605 * descr: Columbus * descr: OH 43216-5002, USA * origin: AS568 * withdrawn: 950404 * withdrawn: 950404 * advisory: AS690 1:568(144) 2:568(145) * mnt-by: MAINT-AS568 * changed: ala at merit.edu 950404 * withdrawn: 950404 * withdrawn: 950404 * source: PALA * * Notice that the single, original withdrawn attribute has turned into * four withdrawn attributes. * * 5) Now run cleandb on the database. (cleandb -c pala.db) * * 6) Now read the object back via whois. * * shockwave.merit.edu: !wh * whois -h radb2.ra.net '-s PALA 137.8.0.0/14' * route: 137.8.0.0/14 * descr: DISA, DSAC * descr: P. O. Box 1605 * descr: Columbus * descr: OH 43216-5002, USA * origin: AS568 * withdrawn: 950404 * withdrawn: 950404 * withdrawn: 950404 * withdrawn: 950404 * advisory: AS690 1:568(144) 2:568(145) * mnt-by: MAINT-AS568 * changed: ala at merit.edu 950404 * withdrawn: 950404 * withdrawn: 950404 * withdrawn: 950404 * withdrawn: 950404 * source: PALA * * Notice that the four withdrawn attributes has turned into 8! * * 7) And every time clean db runs, the number of withdrawn attributes * doubles! * * 8) Another data point - if the original route object contains an error, say * the mask doesn't match the prefix, the error message that is returned * contains the original object with two withdrawn attributes, instead of th * e * original, single one. * * We have a route object in the radb number of withdrawn attributes is * starting to get really long! (cleandb runs every nite). :-) * * -Andy -------- Logged at Wed Apr 5 14:21:14 MET DST 1995 --------- From rlr at merit.edu Wed Apr 5 14:21:04 1995 From: rlr at merit.edu (Rick Riolo) Date: Wed, 05 Apr 1995 08:21:04 -0400 Subject: bug report In-Reply-To: Your message of "Tue, 04 Apr 1995 17:24:56 EDT." <9504042124.AA00412@class.wellfleet> Message-ID: <199504051221.IAA04417@toad.merit.edu> Marten, thanks, that was it. andy etal, I fixed it in our conf files on radb and radb2. - r -------- > From: Marten Terpstra > To: Andrew Adams > CC: rr-impl at merit.edu > > Andy, > > first and very quick guess. This problem does not seem to appear in > the version running at the NCC. There are some routes in there with > the withdrawn attribute that have been cleaned many many times. So > here's my guess. Check the definition you have for the route objects > in your config, specifically the ATSQ line. From what I see below, you > have the wd attribute in there twice, once after the advisory > attribute and once after the change attribute.... > > -Marten > > > Andrew Adams writes > * > * Ok, here's a fun bug for you all. > * > * 1) Create a new database (mine was called PALA) and run netdbm on it. > * > * 2) Add a single maintainer object. (Below is the one I added). > * > * mntner: MAINT-AS568 > * descr: People authorized to make changes for AS568 > * admin-c: Not Available from PRDB > * upd-to: ala at merit.edu > * auth: MAIL-FROM ala at merit.edu > * auth: MAIL-FROM ala at home.merit.edu > * auth: MAIL-FROM ala at shockwave.merit.edu > * auth: MAIL-FROM ala at twain.merit.edu > * auth: MAIL-FROM ala at toad.merit.edu > * remarks: DDN NIC Staff > * remarks: PRE-APPROVAL: AS 568 pre-approves any requests involving the > * ir AS. > * changed: DB-admin at ra.net 950404 > * source: PALA > * > * > * 3) Add a single route object which ref's the maintainer you just added. > * (Below is the one I added). > * > * route: 137.8.0.0/14 > * descr: DISA, DSAC > * descr: P. O. Box 1605 > * descr: Columbus > * descr: OH 43216-5002, USA > * origin: AS568 > * withdrawn: 950404 > * advisory: AS690 1:568(144) 2:568(145) > * mnt-by: MAINT-AS568 > * changed: ala at merit.edu 950404 > * source: PALA > * > * 4) Now read the object back via whois. > * > * shockwave.merit.edu: whois -h radb2.ra.net '-s PALA 137.8.0.0/14' > * route: 137.8.0.0/14 > * descr: DISA, DSAC > > * descr: P. O. Box 1605 > * descr: Columbus > * descr: OH 43216-5002, USA > * origin: AS568 > * withdrawn: 950404 > * withdrawn: 950404 > * advisory: AS690 1:568(144) 2:568(145) > * mnt-by: MAINT-AS568 > * changed: ala at merit.edu 950404 > * withdrawn: 950404 > * withdrawn: 950404 > * source: PALA > * > * Notice that the single, original withdrawn attribute has turned into > * four withdrawn attributes. > * > * 5) Now run cleandb on the database. (cleandb -c pala.db) > * > * 6) Now read the object back via whois. > * > * shockwave.merit.edu: !wh > * whois -h radb2.ra.net '-s PALA 137.8.0.0/14' > * route: 137.8.0.0/14 > * descr: DISA, DSAC > * descr: P. O. Box 1605 > * descr: Columbus > * descr: OH 43216-5002, USA > * origin: AS568 > * withdrawn: 950404 > * withdrawn: 950404 > * withdrawn: 950404 > * withdrawn: 950404 > * advisory: AS690 1:568(144) 2:568(145) > * mnt-by: MAINT-AS568 > * changed: ala at merit.edu 950404 > * withdrawn: 950404 > * withdrawn: 950404 > * withdrawn: 950404 > * withdrawn: 950404 > * source: PALA > * > * Notice that the four withdrawn attributes has turned into 8! > * > * 7) And every time clean db runs, the number of withdrawn attributes > * doubles! > * > * 8) Another data point - if the original route object contains an error, say > * the mask doesn't match the prefix, the error message that is returned > * contains the original object with two withdrawn attributes, instead of th > * e > * original, single one. > * > * We have a route object in the radb number of withdrawn attributes is > * starting to get really long! (cleandb runs every nite). :-) > * > * -Andy -------- Logged at Wed Apr 5 20:49:54 MET DST 1995 --------- From ala at merit.edu Wed Apr 5 20:49:48 1995 From: ala at merit.edu (Andrew Adams) Date: Wed, 05 Apr 1995 14:49:48 -0400 Subject: bug report In-Reply-To: Your message of "Tue, 04 Apr 1995 17:24:56 EDT." <9504042124.AA00412@class.wellfleet> Message-ID: <199504051849.OAA29220@home.merit.edu> Thanks for the quick reply, Marten. Everything seems to work fine now. :-) -Andy > >Andy, > >first and very quick guess. This problem does not seem to appear in >the version running at the NCC. There are some routes in there with >the withdrawn attribute that have been cleaned many many times. So >here's my guess. Check the definition you have for the route objects >in your config, specifically the ATSQ line. From what I see below, you >have the wd attribute in there twice, once after the advisory >attribute and once after the change attribute.... > >-Marten > > >Andrew Adams writes > * > * Ok, here's a fun bug for you all. > * > * 1) Create a new database (mine was called PALA) and run netdbm on it. > * > * 2) Add a single maintainer object. (Below is the one I added). > * > * mntner: MAINT-AS568 > * descr: People authorized to make changes for AS568 > * admin-c: Not Available from PRDB > * upd-to: ala at merit.edu > * auth: MAIL-FROM ala at merit.edu > * auth: MAIL-FROM ala at home.merit.edu > * auth: MAIL-FROM ala at shockwave.merit.edu > * auth: MAIL-FROM ala at twain.merit.edu > * auth: MAIL-FROM ala at toad.merit.edu > * remarks: DDN NIC Staff > * remarks: PRE-APPROVAL: AS 568 pre-approves any requests involving th e > * ir AS. > * changed: DB-admin at ra.net 950404 > * source: PALA > * > * > * 3) Add a single route object which ref's the maintainer you just added. > * (Below is the one I added). > * > * route: 137.8.0.0/14 > * descr: DISA, DSAC > * descr: P. O. Box 1605 > * descr: Columbus > * descr: OH 43216-5002, USA > * origin: AS568 > * withdrawn: 950404 > * advisory: AS690 1:568(144) 2:568(145) > * mnt-by: MAINT-AS568 > * changed: ala at merit.edu 950404 > * source: PALA > * > * 4) Now read the object back via whois. > * > * shockwave.merit.edu: whois -h radb2.ra.net '-s PALA 137.8.0.0/14' > * route: 137.8.0.0/14 > * descr: DISA, DSAC > > * descr: P. O. Box 1605 > * descr: Columbus > * descr: OH 43216-5002, USA > * origin: AS568 > * withdrawn: 950404 > * withdrawn: 950404 > * advisory: AS690 1:568(144) 2:568(145) > * mnt-by: MAINT-AS568 > * changed: ala at merit.edu 950404 > * withdrawn: 950404 > * withdrawn: 950404 > * source: PALA > * > * Notice that the single, original withdrawn attribute has turned into > * four withdrawn attributes. > * > * 5) Now run cleandb on the database. (cleandb -c pala.db) > * > * 6) Now read the object back via whois. > * > * shockwave.merit.edu: !wh > * whois -h radb2.ra.net '-s PALA 137.8.0.0/14' > * route: 137.8.0.0/14 > * descr: DISA, DSAC > * descr: P. O. Box 1605 > * descr: Columbus > * descr: OH 43216-5002, USA > * origin: AS568 > * withdrawn: 950404 > * withdrawn: 950404 > * withdrawn: 950404 > * withdrawn: 950404 > * advisory: AS690 1:568(144) 2:568(145) > * mnt-by: MAINT-AS568 > * changed: ala at merit.edu 950404 > * withdrawn: 950404 > * withdrawn: 950404 > * withdrawn: 950404 > * withdrawn: 950404 > * source: PALA > * > * Notice that the four withdrawn attributes has turned into 8! > * > * 7) And every time clean db runs, the number of withdrawn attributes > * doubles! > * > * 8) Another data point - if the original route object contains an error, say > * the mask doesn't match the prefix, the error message that is returned > * contains the original object with two withdrawn attributes, instead of t h > * e > * original, single one. > * > * We have a route object in the radb number of withdrawn attributes is > * starting to get really long! (cleandb runs every nite). :-) > * > * -Andy -------- Logged at Wed Apr 5 21:20:01 MET DST 1995 --------- From khuon at merit.net Wed Apr 5 21:19:50 1995 From: khuon at merit.net (Jake Khuon) Date: Wed, 05 Apr 1995 15:19:50 -0400 Subject: Unexpected whois replies Message-ID: <199504051919.PAA12872@Espresso.Merit.Net> While evaluating the whois client and server, I came across something unexpected. Neither the -m or -M flags produced a route object. Rather, a router object was reported along with person objects. Was this intended or is this a bug? Or am I misunderstanding the reasoning behind these results? #365:(ttyp1)[~/Projects/whois]% whois -h whois.ripe.net -m 193.0.0.0/24 % This may take some time, server running at low priority inet-rtr: hef-router.nikhef.nl localas: AS1104 ifaddr: 193.0.0.157 255.255.255.224 ifaddr: 192.16.192.176 255.255.255.0 ifaddr: 193.0.0.221 255.255.255.224 ifaddr: 192.16.199.80 255.255.255.0 ifaddr: 192.16.183.80 255.255.255.0 ifaddr: 192.87.4.21 255.255.255.0 ifaddr: 192.87.45.80 255.255.255.0 peer: 193.0.0.134 AS3333 BGP peer: 193.0.0.222 AS3333 BGP peer: 192.16.183.32 AS1888 BGP peer: 192.16.183.96 AS1890 BGP peer: 192.16.183.112 AS1103 BGP peer: 192.87.4.19 AS2121 BGP peer: 192.87.4.24 AS1103 BGP admin-c: Rob Blokzijl tech-c: Marten Terpstra mnt-by: RIPE-NCC-MNT changed: marten at ripe.net 941121 changed: GeertJan.deGroot at ripe.net 941125 source: RIPE inet-rtr: Amsterdam.ripe.net localas: AS3333 ifaddr: 192.87.4.28 255.255.255.0 ifaddr: 193.0.0.222 255.255.255.224 ifaddr: 192.16.183.128 255.255.255.0 peer: 192.87.4.20 AS286 BGP4 peer: 192.87.4.18 AS1103 BGP4 peer: 192.87.4.24 AS1103 BGP4 peer: 193.0.0.221 AS1104 BGP peer: 192.87.4.35 AS1128 BGP4 peer: 192.16.183.32 AS1888 BGP peer: 192.87.4.27 AS1890 BGP peer: 192.87.4.19 AS2121 BGP4 peer: 193.0.0.219 AS2122 BGP4 peer: 192.16.183.64 AS3317 BGP admin-c: DK58 tech-c: GJD8 notify: ops at ripe.net mnt-by: RIPE-NCC-MNT changed: dfk at ripe.net 950308 source: RIPE person: Marten Terpstra address: Bay Networks, Inc. address: 2 Federal Street address: Billerica, MA 01821 address: USA phone: +1 508 436 8036 fax-no: +1 508 670 8760 e-mail: marten at BayNetworks.com nic-hdl: MT2 notify: marten at BayNetworks.com changed: marten at BayNetworks.com 950223 source: RIPE person: Rob Blokzijl address: NIKHEF section H address: Science Park Watergraafsmeer (WCW) address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: The Netherlands phone: +31 20 592 5102 fax-no: +31 20 592 5155 e-mail: k13 at nikhef.nl nic-hdl: RB13 changed: dfk at cwi.nl 900802 changed: ripe-dbm at ripe.net 920622 changed: GeertJan.deGroot at ripe.net 940215 source: RIPE person: Geert Jan de Groot address: RIPE Network Coordination Centre (NCC) address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: Netherlands phone: +31 20 592 5065 fax-no: +31 20 592 5090 e-mail: GeertJan.deGroot at ripe.net nic-hdl: GJD8 changed: ripe-dbm at ripe.net 920720 changed: GeertJan.deGroot at ripe.net 940103 source: RIPE person: Daniel Karrenberg address: RIPE Network Coordination Centre (NCC) address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: Netherlands phone: +31 20 592 5065 fax-no: +31 20 592 5090 e-mail: dfk at ripe.net nic-hdl: DK58 changed: ripe-dbm at ripe.net 920826 source: RIPE #366:(ttyp1)[~/Projects/whois]% whois -h whois.ripe.net -m 193.0.0.0/24 -M .0.0/24 % This may take some time, server running at low priority inet-rtr: hef-router.nikhef.nl localas: AS1104 ifaddr: 193.0.0.157 255.255.255.224 ifaddr: 192.16.192.176 255.255.255.0 ifaddr: 193.0.0.221 255.255.255.224 ifaddr: 192.16.199.80 255.255.255.0 ifaddr: 192.16.183.80 255.255.255.0 ifaddr: 192.87.4.21 255.255.255.0 ifaddr: 192.87.45.80 255.255.255.0 peer: 193.0.0.134 AS3333 BGP peer: 193.0.0.222 AS3333 BGP peer: 192.16.183.32 AS1888 BGP peer: 192.16.183.96 AS1890 BGP peer: 192.16.183.112 AS1103 BGP peer: 192.87.4.19 AS2121 BGP peer: 192.87.4.24 AS1103 BGP admin-c: Rob Blokzijl tech-c: Marten Terpstra mnt-by: RIPE-NCC-MNT changed: marten at ripe.net 941121 changed: GeertJan.deGroot at ripe.net 941125 source: RIPE inet-rtr: Amsterdam.ripe.net localas: AS3333 ifaddr: 192.87.4.28 255.255.255.0 ifaddr: 193.0.0.222 255.255.255.224 ifaddr: 192.16.183.128 255.255.255.0 peer: 192.87.4.20 AS286 BGP4 peer: 192.87.4.18 AS1103 BGP4 peer: 192.87.4.24 AS1103 BGP4 peer: 193.0.0.221 AS1104 BGP peer: 192.87.4.35 AS1128 BGP4 peer: 192.16.183.32 AS1888 BGP peer: 192.87.4.27 AS1890 BGP peer: 192.87.4.19 AS2121 BGP4 peer: 193.0.0.219 AS2122 BGP4 peer: 192.16.183.64 AS3317 BGP admin-c: DK58 tech-c: GJD8 notify: ops at ripe.net mnt-by: RIPE-NCC-MNT changed: dfk at ripe.net 950308 source: RIPE person: Marten Terpstra address: Bay Networks, Inc. address: 2 Federal Street address: Billerica, MA 01821 address: USA phone: +1 508 436 8036 fax-no: +1 508 670 8760 e-mail: marten at BayNetworks.com nic-hdl: MT2 notify: marten at BayNetworks.com changed: marten at BayNetworks.com 950223 source: RIPE person: Rob Blokzijl address: NIKHEF section H address: Science Park Watergraafsmeer (WCW) address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: The Netherlands phone: +31 20 592 5102 fax-no: +31 20 592 5155 e-mail: k13 at nikhef.nl nic-hdl: RB13 changed: dfk at cwi.nl 900802 changed: ripe-dbm at ripe.net 920622 changed: GeertJan.deGroot at ripe.net 940215 source: RIPE person: Geert Jan de Groot address: RIPE Network Coordination Centre (NCC) address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: Netherlands phone: +31 20 592 5065 fax-no: +31 20 592 5090 e-mail: GeertJan.deGroot at ripe.net nic-hdl: GJD8 changed: ripe-dbm at ripe.net 920720 changed: GeertJan.deGroot at ripe.net 940103 source: RIPE person: Daniel Karrenberg address: RIPE Network Coordination Centre (NCC) address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: Netherlands phone: +31 20 592 5065 fax-no: +31 20 592 5090 e-mail: dfk at ripe.net nic-hdl: DK58 changed: ripe-dbm at ripe.net 920826 source: RIPE #367:(ttyp1)[~/Projects/whois]% -- /*==============[ Jake [WinterHawk] Khuon ]==============+ | Systems Research Programmer, IE Group /| /|[~|)|~|~ N E T W O R K | | Vox: (313) 764-5271 Fax: (313) 747-3185 / |/ |[_|\| | Incorporated | +====[ Suite C2030, Bldg. 1 4251 Plymouth Rd. Ann Arbor, MI 48105 ]====*/ -------- Logged at Thu Apr 6 05:20:59 MET DST 1995 --------- From marten at BayNetworks.com Thu Apr 6 05:19:15 1995 From: marten at BayNetworks.com (Marten Terpstra) Date: Wed, 05 Apr 1995 23:19:15 -0400 Subject: Unexpected whois replies In-Reply-To: Your message of Wed, 05 Apr 1995 15:19:50 EDT. <199504051919.PAA12872@Espresso.Merit.Net> Message-ID: <9504060319.AA01020@class.wellfleet> "Jake Khuon" writes * While evaluating the whois client and server, I came across something * unexpected. Neither the -m or -M flags produced a route object. Rather, a * router object was reported along with person objects. Was this intended or * is this a bug? Or am I misunderstanding the reasoning behind these results? The answer is probably that there simply is nothing more specific than 193.0.0.0/24 in the database.... Perhaps you meant to do 193.0.0.0/16 or even 193.0.0.0/8 ? -Marten PS with the example below, you are asking for something more specific than the class C network 193.0.0.x and I am very sure that there is nothing in the RIPE database, other than the inet-rtr objects it returned to you.... * #365:(ttyp1)[~/Projects/whois]% whois -h whois.ripe.net -m 1 * 93.0.0.0/24 * % This may take some time, server running at low priority * * inet-rtr: hef-router.nikhef.nl * localas: AS1104 * ifaddr: 193.0.0.157 255.255.255.224 * ifaddr: 192.16.192.176 255.255.255.0 * ifaddr: 193.0.0.221 255.255.255.224 * ifaddr: 192.16.199.80 255.255.255.0 * ifaddr: 192.16.183.80 255.255.255.0 * ifaddr: 192.87.4.21 255.255.255.0 * ifaddr: 192.87.45.80 255.255.255.0 * peer: 193.0.0.134 AS3333 BGP * peer: 193.0.0.222 AS3333 BGP * peer: 192.16.183.32 AS1888 BGP * peer: 192.16.183.96 AS1890 BGP * peer: 192.16.183.112 AS1103 BGP * peer: 192.87.4.19 AS2121 BGP * peer: 192.87.4.24 AS1103 BGP * admin-c: Rob Blokzijl * tech-c: Marten Terpstra * mnt-by: RIPE-NCC-MNT * changed: marten at ripe.net 941121 * changed: GeertJan.deGroot at ripe.net 941125 * source: RIPE * * inet-rtr: Amsterdam.ripe.net * localas: AS3333 * ifaddr: 192.87.4.28 255.255.255.0 * ifaddr: 193.0.0.222 255.255.255.224 * ifaddr: 192.16.183.128 255.255.255.0 * peer: 192.87.4.20 AS286 BGP4 * peer: 192.87.4.18 AS1103 BGP4 * peer: 192.87.4.24 AS1103 BGP4 * peer: 193.0.0.221 AS1104 BGP * peer: 192.87.4.35 AS1128 BGP4 * peer: 192.16.183.32 AS1888 BGP * peer: 192.87.4.27 AS1890 BGP * peer: 192.87.4.19 AS2121 BGP4 * peer: 193.0.0.219 AS2122 BGP4 * peer: 192.16.183.64 AS3317 BGP * admin-c: DK58 * tech-c: GJD8 * notify: ops at ripe.net * mnt-by: RIPE-NCC-MNT * changed: dfk at ripe.net 950308 * source: RIPE * * person: Marten Terpstra * address: Bay Networks, Inc. * address: 2 Federal Street * address: Billerica, MA 01821 * address: USA * phone: +1 508 436 8036 * fax-no: +1 508 670 8760 * e-mail: marten at BayNetworks.com * nic-hdl: MT2 * notify: marten at BayNetworks.com * changed: marten at BayNetworks.com 950223 * source: RIPE * * person: Rob Blokzijl * address: NIKHEF section H * address: Science Park Watergraafsmeer (WCW) * address: Kruislaan 409 * address: NL-1098 SJ Amsterdam * address: The Netherlands * phone: +31 20 592 5102 * fax-no: +31 20 592 5155 * e-mail: k13 at nikhef.nl * nic-hdl: RB13 * changed: dfk at cwi.nl 900802 * changed: ripe-dbm at ripe.net 920622 * changed: GeertJan.deGroot at ripe.net 940215 * source: RIPE * * person: Geert Jan de Groot * address: RIPE Network Coordination Centre (NCC) * address: Kruislaan 409 * address: NL-1098 SJ Amsterdam * address: Netherlands * phone: +31 20 592 5065 * fax-no: +31 20 592 5090 * e-mail: GeertJan.deGroot at ripe.net * nic-hdl: GJD8 * changed: ripe-dbm at ripe.net 920720 * changed: GeertJan.deGroot at ripe.net 940103 * source: RIPE * * person: Daniel Karrenberg * address: RIPE Network Coordination Centre (NCC) * address: Kruislaan 409 * address: NL-1098 SJ Amsterdam * address: Netherlands * phone: +31 20 592 5065 * fax-no: +31 20 592 5090 * e-mail: dfk at ripe.net * nic-hdl: DK58 * changed: ripe-dbm at ripe.net 920826 * source: RIPE * * #366:(ttyp1)[~/Projects/whois]% whois -h whois.ripe.net * -m 193.0.0.0/24 * -M .0.0/24 * % This may take some time, server running at low priority * * inet-rtr: hef-router.nikhef.nl * localas: AS1104 * ifaddr: 193.0.0.157 255.255.255.224 * ifaddr: 192.16.192.176 255.255.255.0 * ifaddr: 193.0.0.221 255.255.255.224 * ifaddr: 192.16.199.80 255.255.255.0 * ifaddr: 192.16.183.80 255.255.255.0 * ifaddr: 192.87.4.21 255.255.255.0 * ifaddr: 192.87.45.80 255.255.255.0 * peer: 193.0.0.134 AS3333 BGP * peer: 193.0.0.222 AS3333 BGP * peer: 192.16.183.32 AS1888 BGP * peer: 192.16.183.96 AS1890 BGP * peer: 192.16.183.112 AS1103 BGP * peer: 192.87.4.19 AS2121 BGP * peer: 192.87.4.24 AS1103 BGP * admin-c: Rob Blokzijl * tech-c: Marten Terpstra * mnt-by: RIPE-NCC-MNT * changed: marten at ripe.net 941121 * changed: GeertJan.deGroot at ripe.net 941125 * source: RIPE * * inet-rtr: Amsterdam.ripe.net * localas: AS3333 * ifaddr: 192.87.4.28 255.255.255.0 * ifaddr: 193.0.0.222 255.255.255.224 * ifaddr: 192.16.183.128 255.255.255.0 * peer: 192.87.4.20 AS286 BGP4 * peer: 192.87.4.18 AS1103 BGP4 * peer: 192.87.4.24 AS1103 BGP4 * peer: 193.0.0.221 AS1104 BGP * peer: 192.87.4.35 AS1128 BGP4 * peer: 192.16.183.32 AS1888 BGP * peer: 192.87.4.27 AS1890 BGP * peer: 192.87.4.19 AS2121 BGP4 * peer: 193.0.0.219 AS2122 BGP4 * peer: 192.16.183.64 AS3317 BGP * admin-c: DK58 * tech-c: GJD8 * notify: ops at ripe.net * mnt-by: RIPE-NCC-MNT * changed: dfk at ripe.net 950308 * source: RIPE * * person: Marten Terpstra * address: Bay Networks, Inc. * address: 2 Federal Street * address: Billerica, MA 01821 * address: USA * phone: +1 508 436 8036 * fax-no: +1 508 670 8760 * e-mail: marten at BayNetworks.com * nic-hdl: MT2 * notify: marten at BayNetworks.com * changed: marten at BayNetworks.com 950223 * source: RIPE * * person: Rob Blokzijl * address: NIKHEF section H * address: Science Park Watergraafsmeer (WCW) * address: Kruislaan 409 * address: NL-1098 SJ Amsterdam * address: The Netherlands * phone: +31 20 592 5102 * fax-no: +31 20 592 5155 * e-mail: k13 at nikhef.nl * nic-hdl: RB13 * changed: dfk at cwi.nl 900802 * changed: ripe-dbm at ripe.net 920622 * changed: GeertJan.deGroot at ripe.net 940215 * source: RIPE * * person: Geert Jan de Groot * address: RIPE Network Coordination Centre (NCC) * address: Kruislaan 409 * address: NL-1098 SJ Amsterdam * address: Netherlands * phone: +31 20 592 5065 * fax-no: +31 20 592 5090 * e-mail: GeertJan.deGroot at ripe.net * nic-hdl: GJD8 * changed: ripe-dbm at ripe.net 920720 * changed: GeertJan.deGroot at ripe.net 940103 * source: RIPE * * person: Daniel Karrenberg * address: RIPE Network Coordination Centre (NCC) * address: Kruislaan 409 * address: NL-1098 SJ Amsterdam * address: Netherlands * phone: +31 20 592 5065 * fax-no: +31 20 592 5090 * e-mail: dfk at ripe.net * nic-hdl: DK58 * changed: ripe-dbm at ripe.net 920826 * source: RIPE * * #367:(ttyp1)[~/Projects/whois]% * * * -- * /*==============[ Jake [WinterHawk] Khuon ]==============+ * | Systems Research Programmer, IE Group /| /|[~|)|~|~ N E T W O R K | * | Vox: (313) 764-5271 Fax: (313) 747-3185 / |/ |[_|\| | Incorporated | * +====[ Suite C2030, Bldg. 1 4251 Plymouth Rd. Ann Arbor, MI 48105 ]====* * / * -------- Logged at Wed Apr 12 06:51:24 MET DST 1995 --------- From marten at BayNetworks.com Wed Apr 12 06:58:49 1995 From: marten at BayNetworks.com (Marten Terpstra) Date: Wed, 12 Apr 1995 00:58:49 -0400 Subject: BBN and RR Message-ID: <9504120458.AA05878@bali_hai.wellfleet> Could someone take this one over, I won;t have time to give him an elaborate response ..... -Marten ------- Forwarded Message Date: Mon, 10 Apr 95 15:24:01 EDT From: Steven Winnett To: marten at wellfleet.com cc: swinnett at BBN.COM Subject: RRDB Setup for Client: Need Info Marten, First of all, I want to congratulate you and your team for a stimulating and informative presentation last week at IETF. I would very much appreciate it if you would give me the email address of the person who gave the presentation on RPSL; I didn't quite catch his name or email id and I would like to get in touch with him about RPSL. Thank you. I am engaged in helping our client (a major department of the US Government) set up its own RRDB. We want this RRDB to be an exact mirror - in terms of controlling software - to the RRDB's currently set up for RIPE and MERIT, with of course small exceptions for local usage. So far I have been able to locate and rebuild the set of tools which are available from RIPE. What I would now like pointers to would be the following: 1. The special whois server software which fields inquiries. 2. The software which fields mailed in email updates to the database and automatically updates the database. 3. Any report generating software. I am assuming hewre, of course, that this software, like the tools, is essentially public domain. I would also like to know if there is a mailing list or some other sort of revisiion control system in place for all of this software, and if so could I please be added to this list. Finally, I would like to know if there exists a document which gives advice on whattt is required to set up your own RRDB, and then put in links to other RRDB's. I would also appreciate any pointers to software and/or documents discussing the issue of synchronicity which you raised towards the end of your presentation. Thank you. Steve Winnett Bolt, Beranek & Newman Cambridge, MA ------- End of Forwarded Message -------- Logged at Wed Apr 12 16:40:40 MET DST 1995 --------- From dsj at merit.edu Wed Apr 12 16:40:24 1995 From: dsj at merit.edu (Dale S. Johnson) Date: Wed, 12 Apr 1995 10:40:24 -0400 Subject: BBN and RR Message-ID: <199504121440.KAA23698@home.merit.edu> Steve, Marten forwarded this for response. > Date: Mon, 10 Apr 95 15:24:01 EDT > From: Steven Winnett > To: marten at wellfleet.com > cc: swinnett at BBN.COM > Subject: RRDB Setup for Client: Need Info > > Marten, > > First of all, I want to congratulate you and your team for a > stimulating and informative presentation last week at IETF. > I would very much appreciate it if you would give me the email > address of the person who gave the presentation on RPSL; I didn't > quite catch his name or email id and I would like to get in touch > with him about RPSL. Thank you. Cengiz Alaettinoglu (cengiz at isi.edu). > I am engaged in helping our client (a major department of the US > Government) set up its own RRDB. We want this RRDB to be an exact > mirror - in terms of controlling software - to the RRDB's currently > set up for RIPE and MERIT, with of course small exceptions for > local usage. So far I have been able to locate and rebuild the set > of tools which are available from RIPE. What I would now like pointers > to would be the following: > > 1. The special whois server software which fields inquiries. There is a whois server (designed to run on port 42) as part of the RIPE distribution. (whoisd). The RA project has built an extended whois-like server which runs on port 5042 as well. This server provides more functionality, in a format designed to be used by client programs rather than by humans directly. It is used by the RtConfig tool kit, which is used to generate GateD and Cisco router configurations for the Route Servers, for CANet, and soon for AS690. The extended whois server is available as: ftp://ftp.ra.net/pub/radb/tools/radbserver-181.tar.Z RtConfig is available as: ftp://ftp.ra.net/pub/tools/RAToolSet/RtConfig-R-1.0.tar.gz It would be good to send a note to rrgroup at merit.edu to us know what tools you are working with, so we can keep you in mind in terms of updates, etc. > 2. The software which fields mailed in email updates to the > database and automatically updates the database. This is a program called "dbupdate", which is part of the RIPE release. > 3. Any report generating software. Rather than issue published reports, the IRR (Internet Routing Registry: RIPE + RA + MCI + CANET + you + ... ) makes their database files available, and makes information available via servers and client programs. Special purpose reports are easy to build from any of these sources. > I am assuming hewre, of course, that this software, like the tools, > is essentially public domain. I would also like to know if there > is a mailing list or some other sort of revisiion control system in > place for all of this software, and if so could I please be added > to this list. rr-impl at ripe.net. RIPE, can you add Steve? > Finally, I would like to know if there exists a document which > gives advice on whattt is required to set up your own RRDB, and then > put in links to other RRDB's. I would also appreciate any pointers to > software and/or documents discussing the issue of synchronicity which > you raised towards the end of your presentation. There is no document. This kind of issue is coordinated on rr-impl . --Dale Johnson Merit/RA -------- Logged at Wed Apr 12 17:06:51 MET DST 1995 --------- From David.Kessens at ripe.net Wed Apr 12 17:06:48 1995 From: David.Kessens at ripe.net (David.Kessens at ripe.net) Date: Wed, 12 Apr 1995 17:06:48 +0200 (MET DST) Subject: BBN and RR In-Reply-To: <9504120458.AA05878@bali_hai.wellfleet> from "Marten Terpstra" at Apr 12, 95 00:58:49 am Message-ID: <9504121506.AA13549@mature.ripe.net> A non-text attachment was scrubbed... Name: not available Type: text Size: 435 bytes Desc: not available Url : https://www.ripe.net/mailman/private/rr-impl/attachments/19950412/10266ee0/attachment.pl From dsj at merit.edu Thu Apr 13 23:35:24 1995 From: dsj at merit.edu (Dale S. Johnson) Date: Thu, 13 Apr 1995 17:35:24 -0400 Subject: Sprint on rr-impl? Message-ID: <199504132135.RAA26230@home.merit.edu> Ripe guys: Here is a person from Sprint who would like to be on rr-impl. If this is an open list, can you put him on there and reply to him? Sprint agreeing to register their policies as part of an IRR would be a wonderful thing. (Even if they currently don't know an IRR/RADB from a RIPE PRDB). --Dale ============ From: Ismat Pasha > From ipasha at sprint.net Thu Apr 13 13:39:14 1995 > Date: Thu, 13 Apr 1995 13:41:20 -0400 > To: dsj at merit.edu > Subject: PRDB question > > > Hi, > Please pardon me if you are not the right > person to contact to subscribe to rr-impl at home.merit.edu. > In particular I am interested in learning about > Ripe PRDB, its deployment for the purpose > of generating IP network based filter lists. > I would greatly appreciate a pointer in the > right direction (If you know). > > --Thank You. > > --Ismat Pasha -------- Logged at Tue Apr 18 11:36:48 MET DST 1995 --------- From David.Kessens at ripe.net Tue Apr 18 11:36:44 1995 From: David.Kessens at ripe.net (David.Kessens at ripe.net) Date: Tue, 18 Apr 1995 11:36:44 +0200 (MET DST) Subject: Sprint on rr-impl? In-Reply-To: <199504132135.RAA26230@home.merit.edu> from "Dale S. Johnson" at Apr 13, 95 05:35:24 pm Message-ID: <9504180936.AA25608@mature.ripe.net> A non-text attachment was scrubbed... Name: not available Type: text Size: 1141 bytes Desc: not available Url : https://www.ripe.net/mailman/private/rr-impl/attachments/19950418/d4d0082d/attachment.pl From ripe-dbm at ripe.net Tue Apr 18 16:45:23 1995 From: ripe-dbm at ripe.net (RIPE Database Manager) Date: Tue, 18 Apr 1995 16:45:23 +0200 Subject: BUG fix ! Message-ID: <9504181445.AA03576@ncc.ripe.net> Dear all, Thanks to the GARR-NIS people a small bug with serious implications was found. After a general check of the read-in object the syntax check was only done when an OK was returned. So if there were warnings found the object was not syntax checked. However the object was still accepted as an OK object since no errors were found. This made it possible to send in objects with completely wrong syntax as long as an warning was generated during the general object check. Kind regards, David Kessens RIPE NCC database maintainer Fix with patch or just put in the attached file : ======================================================= *** /ncc/dbase/src/old/enparse.pl Tue Apr 18 15:43:52 1995 --- /ncc/dbase/src/enparse.pl Tue Apr 18 16:21:30 1995 *************** *** 1,9 **** # enparse - read RIPE database and check syntax errors # # $RCSfile: enparse.pl,v $ ! # $Revision: 1.7 $ ! # $Author: david $ ! # $Date: 1995/02/10 11:39:22 $ # # ARGUMENTS: filehandle to read from # RETURNS: INTEGER object_status --- 1,9 ---- # enparse - read RIPE database and check syntax errors # # $RCSfile: enparse.pl,v $ ! # $Revision: 1.8 $ ! # $Author: ripe-dbm $ ! # $Date: 1995/04/18 13:58:03 $ # # ARGUMENTS: filehandle to read from # RETURNS: INTEGER object_status *************** *** 231,237 **** if (!($hasdelete = &hasdelete(*entry))) { print STDERR "enparse - checking object format\n" if $opt_V; $rtcode = &checkobject(*entry); ! if ($rtcode == $O_OK) { print STDERR "enparse - checking object syntax\n" if $opt_V; $rtcode = &checksyntax(*entry); } --- 231,237 ---- if (!($hasdelete = &hasdelete(*entry))) { print STDERR "enparse - checking object format\n" if $opt_V; $rtcode = &checkobject(*entry); ! if ($rtcode != $O_ERROR) { print STDERR "enparse - checking object syntax\n" if $opt_V; $rtcode = &checksyntax(*entry); } ========================== OR ========================= # enparse - read RIPE database and check syntax errors # # $RCSfile: enparse.pl,v $ # $Revision: 1.8 $ # $Author: ripe-dbm $ # $Date: 1995/04/18 13:58:03 $ # # ARGUMENTS: filehandle to read from # RETURNS: INTEGER object_status # ASSOC object # # Object status = $O_OK, $O_WARNING, $O_ERROR, $EOF, or $NOK # $O_OK = object read and no errors/warnings generated # $O_WARNING = object read, but generated warnings # $O_ERROR = object read, but generated errors # $EOF = EndOfFile reached # $NOK = no object found, just garbage # # Object has warnings and errors included. # # This routine is a modified version of enread. It will read any # garbage, until it finds something of the form: # "xxxxxxx: " (no fixed length, spaces MUST be there) # or # "*xx: " # and then continues to read until it finds a line that does not # match these patterns. It then assumes it read an object, and will # start doing syntax checks. require "entype.pl"; require "syntax.pl"; require "defines.pl"; require "adderror.pl"; sub readsomething { local($file) = @_; local($inentry) = $NOK; local($tag) = ""; local(%entry) = (); while (<$file>) { s/^\s*//; s/\s*$//; s/\n*$//; next if /^#/; if (/^password:\s*(\S.*\S)/) { $PASSWORD = $1; next; } if (/^\*..:\s*(.*)/) { $inentry = $OK; $tag = substr($_, 1, 2); if ($entry{$tag}) { $entry{$tag} .= "\n"; } $entry{$tag} = $entry{$tag} . $1; next; } if (/^([a-z\-A-Z_]+)\s*:\s*(.*)/) { $inentry = $OK; $tag = $1; $tag =~ tr/A-Z/a-z/; $tag = $ATTR{$tag} if $ATTR{$tag}; if ($entry{$tag}) { $entry{$tag} .= "\n"; } $entry{$tag} = $entry{$tag} . "$2"; next; } if (/^.*$/) { next if $inentry == $NOK; $CUROBJTYPE = &entype(*entry); return ($inentry,%entry); } } $CUROBJTYPE = &entype(*entry); return ($inentry, %entry) if ($inentry); return $EOF; } sub checkobject { local(*object) = @_; local($type); local($rtcode) = $O_OK; local(%knownfield) = (); local(%mandfield) = (); local(%multfield) = (); local(%knownfield) = (); local(%guard) = (); local(%usefield) = (); local($i); print STDERR "checkobject - called\n" if $opt_V; $type = &entype(*object); if (!$type) { &adderror(*object, "unknown object type"); return $O_ERROR; } # Check guarded objects, should be authorised or maintained # The message will request the object be maintained foreach (keys %GRDOBJ) { if ($object{$_}) { if (!$object{"ua"} && !$object{"mb"}) { &adderror(*object, "the \"$ATTL{$_}\" object cannot be updated ". "automatically without a \"mnt-by\" attribute"); # now if this object was supposed to be deleted, remove # the delete attribute, since deletes will remove # syntax errors later in the program and this is one # that may not be removed. There is also no point in # doing more checks if it was supposed to be deleted. if ($object{"ud"}) { undef $object{"ud"}; return $O_ERROR; } # otherwise, continue extra checks for clarity to user $rtcode = $O_ERROR; } last; } } foreach $i ((split(/\s+/, $OBJATSQ{$type}),"ud","ua","uo","uw","ue")) { $knownfield{"$i"} = 1; } foreach $i (split(/\s+/, $OBJMAND{$type})) { $mandfield{"$i"} = 1; } foreach $i (split(/\s+/, $OBJMULT{$type})) { $multfield{"$i"} = 1; } foreach $i (split(/\s+/, $GRD{$type})) { $guard{"$i"} = 1; } foreach $i (keys %object) { $usefield{"$i"} = 1; } foreach (split(/\s+/, $OBS{$type})) { if ($object{$_}) { &addwarning(*object, "attribute \"$ATTL{$_}\" has been obsoleted,". " value removed from object"); delete $object{$_}; delete $usefield{$_}; $rtcode = $O_WARNING; } } foreach $i (keys %usefield) { if (!$knownfield{"$i"}) { if ($ATTL{"$i"}) { &adderror(*object, "attribute \"$ATTL{$i}\" unknown ". "in $ATTL{$type} object"); } else { &adderror(*object, "attribute \"$i\" unknown in $ATTL{$type} object"); } $rtcode = $O_ERROR; } undef $mandfield{"$i"} unless $object{$i} eq ""; if ($object{$i} =~ /\n/) { if (!$multfield{"$i"}) { &adderror(*object, "multiple lines not allowed for: \"$ATTL{$i}\""); $rtcode = $O_ERROR;; } } } foreach $i (keys %mandfield) { if ($mandfield{$i}) { if (defined($object{$i}) && ($object{$i} =~ /^\n*$/)) { &adderror(*object, "mandatory field \"$ATTL{$i}\" must have a value"); } else { &adderror(*object, "mandatory field \"$ATTL{$i}\" missing"); } $rtcode = $O_ERROR; } } print STDERR "checkobject - returned\n" if $opt_V; return $rtcode; } sub enparse { local($file) = @_; local(%entry); local($rtcode) = $O_OK; local($stat); local($hasdelete); print STDERR "enparse - reading something\n" if $opt_V; ($stat, %entry) = &readsomething($file); return $EOF if $stat == $EOF; return $NOK if $stat == $NOK; # Now, let's check whether this is a delete request or not # If it is, we have to skip all syntax checks ... # since syntax checks may change the object AND # one wants to be able to delete objects with wrong syntax # A wrongly defined delete attribute will return a 0, # and add a error message. if (!($hasdelete = &hasdelete(*entry))) { print STDERR "enparse - checking object format\n" if $opt_V; $rtcode = &checkobject(*entry); if ($rtcode != $O_ERROR) { print STDERR "enparse - checking object syntax\n" if $opt_V; $rtcode = &checksyntax(*entry); } } return $rtcode, $hasdelete, %entry; } 1; ======================================= -------- Logged at Wed Apr 19 22:59:39 MET DST 1995 --------- From dsj at merit.edu Wed Apr 19 22:59:34 1995 From: dsj at merit.edu (Dale S. Johnson) Date: Wed, 19 Apr 1995 16:59:34 -0400 Subject: telnet interface Message-ID: <199504192059.QAA07690@home.merit.edu> All, Today's discussion of the IRR on nanog has had a couple of references to a telnet interface to the RIPE database. Is there code for this in the distribution? Any hints on how you set it up? (Is it in docs anywhere?) --Dale -------- Logged at Thu Apr 20 01:00:18 MET DST 1995 --------- From GeertJan.deGroot at ripe.net Thu Apr 20 01:00:16 1995 From: GeertJan.deGroot at ripe.net (Geert Jan de Groot) Date: Thu, 20 Apr 1995 01:00:16 +0200 Subject: telnet interface In-Reply-To: Your message of "Wed, 19 Apr 1995 16:59:34 EDT." <199504192059.QAA07690@home.merit.edu> Message-ID: <9504192300.AA18013@ncc.ripe.net> On Wed, 19 Apr 1995 16:59:34 -0400 "Dale S. Johnson" wrote: > Today's discussion of the IRR on nanog has had a couple of references to > a telnet interface to the RIPE database. > > Is there code for this in the distribution? Any hints on how you set > it up? (Is it in docs anywhere?) There is a telnet interface for database lookups (telnet to info.ripe.net); you probably don't want the code (info.ripe.net is planned to be rebuilt for more than a year now, but time is lacking). There is no telnet interface for updates. There are a couple of reasons I can think of why a telnet interface is not a good idea: 1. The email interface is generally found sufficient, because a response (positive or negative) is received within minutes (max), essentially limited by the speed two email messages are sent/received (people that have connectivity bad enough for mail to take more than a minute probably do not want interactive telnet...) 2. Telnet has no authentication mechanism. Somehow I feel that some kind of 'login' authentication isn't a good idea. 3. Email has an easy way to log transactions. logging telnet is much more difficult... 4. I can't think of an easy way to authenticate new objects. cut/paste of PGP signatures looks painful to me. Email headers are useless; people apperently aren't too fond of password authentication. Am I missing something? Geert Jan -------- Logged at Thu Apr 20 03:17:09 MET DST 1995 --------- From dsj at merit.edu Thu Apr 20 03:17:05 1995 From: dsj at merit.edu (Dale S. Johnson) Date: Wed, 19 Apr 1995 21:17:05 -0400 Subject: telnet interface Message-ID: <199504200117.VAA15055@home.merit.edu> Geert Jan, Aah, I'd thought from the mail thread that people were saying there was a telnet update interface. Thanks for the info that this isn't true. (Though I think much of NANOG has been led to think it is true now). > Am I missing something? Well, as a developer I *never* use email--running dbupdate is so much more direct (even when the size of my mailbox is under a thousand). I haven't thought the details through, but a user dbupdate client that he could use the same way I do: #!/bin/dwim whois XXX > tmp vi tmp dbupdate tmp would seem to be pretty easy to build, including the PGP stuff. --Dale ============ From: Geert Jan de Groot > From geertj at ripe.net Wed Apr 19 19:01:28 1995 > To: "Dale S. Johnson" > Cc: rr-impl at ripe.net > Subject: Re: telnet interface > Date: Thu, 20 Apr 1995 01:00:16 +0200 > > On Wed, 19 Apr 1995 16:59:34 -0400 "Dale S. Johnson" wrote: > > Today's discussion of the IRR on nanog has had a couple of references to > > a telnet interface to the RIPE database. > > > > Is there code for this in the distribution? Any hints on how you set > > it up? (Is it in docs anywhere?) > > There is a telnet interface for database lookups (telnet to info.ripe.net); > you probably don't want the code (info.ripe.net is planned to be rebuilt > for more than a year now, but time is lacking). > > There is no telnet interface for updates. There are a couple of reasons > I can think of why a telnet interface is not a good idea: > 1. The email interface is generally found sufficient, because a response > (positive or negative) is received within minutes (max), essentially > limited by the speed two email messages are sent/received > (people that have connectivity bad enough for mail to take more than > a minute probably do not want interactive telnet...) > 2. Telnet has no authentication mechanism. Somehow I feel that some kind > of 'login' authentication isn't a good idea. > 3. Email has an easy way to log transactions. logging telnet is much > more difficult... > 4. I can't think of an easy way to authenticate new objects. cut/paste > of PGP signatures looks painful to me. Email headers are useless; > people apperently aren't too fond of password authentication. > > Am I missing something? > > Geert Jan -------- Logged at Thu Apr 20 10:47:36 MET DST 1995 --------- From David.Kessens at ripe.net Thu Apr 20 10:47:31 1995 From: David.Kessens at ripe.net (David.Kessens at ripe.net) Date: Thu, 20 Apr 1995 10:47:31 +0200 (MET DST) Subject: telnet interface In-Reply-To: <199504192059.QAA07690@home.merit.edu> from "Dale S. Johnson" at Apr 19, 95 04:59:34 pm Message-ID: <9504200847.AA04215@mature.ripe.net> A non-text attachment was scrubbed... Name: not available Type: text Size: 721 bytes Desc: not available Url : https://www.ripe.net/mailman/private/rr-impl/attachments/19950420/2195e141/attachment.pl From Daniel.Karrenberg at ripe.net Thu Apr 20 14:52:29 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 20 Apr 1995 14:52:29 +0200 Subject: telnet interface In-Reply-To: Your message of Thu, 20 Apr 1995 01:00:16 MDT. <9504192300.AA18013@ncc.ripe.net> Message-ID: <9504201252.AA23642@ncc.ripe.net> > Geert Jan de Groot writes: > > There is no telnet interface for updates. We have one coded and it works. It is not in the distribution. It is deployed only inside the NCC for testing. It works. See the response from David Kessens who implemented it. The main problem is authentication. > There are a couple of reasons > I can think of why a telnet interface is not a good idea: > 1. The email interface is generally found sufficient, because a response > (positive or negative) is received within minutes (max), essentially > limited by the speed two email messages are sent/received > (people that have connectivity bad enough for mail to take more than > a minute probably do not want interactive telnet...) That is perfectly right. It is why deployment is not a terribly high priority hereabouts. > 2. Telnet has no authentication mechanism. Somehow I feel that some kind > of 'login' authentication isn't a good idea. Yep. > 3. Email has an easy way to log transactions. logging telnet is much > more difficult... Nope. The DB software logging mechanism is independent of the transport mechanism. Telnet transactions are logged perfectly well at this point. > 4. I can't think of an easy way to authenticate new objects. cut/paste > of PGP signatures looks painful to me. Email headers are useless; > people apperently aren't too fond of password authentication. Again, see above. Kerberos black telnet sessions are a possibility. A weaker one is IP peer based authentication. We use that at the moment. > Am I missing something? Yes, that it was implemented partly on your request because the e-mail responses in the mailbox made the multi-hostmaster synchronisation more difficult. ;-) Daniel -------- Logged at Thu Apr 20 14:55:14 MET DST 1995 --------- From Daniel.Karrenberg at ripe.net Thu Apr 20 14:55:12 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 20 Apr 1995 14:55:12 +0200 Subject: telnet interface In-Reply-To: Your message of Wed, 19 Apr 1995 21:17:05 EDT. <199504200117.VAA15055@home.merit.edu> Message-ID: <9504201255.AA23673@ncc.ripe.net> > "Dale S. Johnson" writes: > > Well, as a developer I *never* use email--running dbupdate is so much > more direct (even when the size of my mailbox is under a thousand). > I haven't thought the details through, but a user dbupdate client > that he could use the same way I do: > > #!/bin/dwim > whois XXX > tmp > vi tmp > dbupdate tmp > > would seem to be pretty easy to build, including the PGP stuff. We have implemented it as a function in whoisd since that has all the necessary stuff already. Now you can accuse me of creeping featurism. ;-) Daniel -------- Logged at Tue Apr 25 00:18:36 MET DST 1995 --------- From cengiz at ISI.EDU Tue Apr 25 00:17:20 1995 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Mon, 24 Apr 1995 15:17:20 -0700 Subject: RtConfig-R-2.0 is released Message-ID: <199504242217.AA18875@cat.isi.edu> Hi, A new version of RtConfig is available as ftp://ftp.ra.net/routing.arbiter/tools/RAToolSet/RtConfig-R-2.0.tar.gz. It requires g++ 2.6.3 to compile. A Sun Sparc executable is also provided in the same directory. RtConfig is a tool which creates gated configurations from Ripe-181. This version support limited AS path expressions of the form which are often used when exporting routes. The next version will have full AS-path support. I am also hoping to include cisco support in the next release. Bug reports/fixes and suggestions are welcome as usual. Thanks for all those who provided feedback. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California http://www.isi.edu/div7/people/cengiz.home -------- Logged at Thu Apr 27 21:33:07 MET DST 1995 --------- From dsj at merit.edu Thu Apr 27 21:33:02 1995 From: dsj at merit.edu (Dale S. Johnson) Date: Thu, 27 Apr 1995 15:33:02 -0400 Subject: Towards a Disjoint IRR Message-ID: <199504271933.PAA05472@home.merit.edu> All, 1) The PRDB is about to be retired. (Oh? You say you've heard that one before? ;-| Quite possibly on Monday, May 8. (Annoucements will be made to rr-impl, as well as to nanog)). So: If you are currently picking up prdb.db, please make sure you are also picking up the radb.db and including it in ALLSEARCH so that traceroutes (etc.) via your server will continue to work. 2) We've talked about this informally before, but I'd like a group discussion before we call it final: Once the PRDB route objects are copied/merged into the RADB, should we purge all the RADB route objects that are duplicated in other IRR databases? Specifically, should we go through the lists of routes registered in MCI.db, CA*Net.db, and RIPE.db, and for each net registered in any of those dbs AND WHICH HAS ADVISORY AS690 LINES, remove that net from the RADB? The advantage of pruning the RADB in this way is that the IRR becomes more disjoint: generally, a route will be registered only in one registry in the IRR. Users will not have two (or more) updates to make for each route; the possibility of conflicting information is greatly reduced. [Enke and Craig are working on resolving *lots* of conflicts between the prdb.db and the mci.db as we speak]. The disadvantages of pruning the RADB include: This is modification of user data on a massive scale. Some users (e.g. multi-homed users) may need to be registered in more than one registry. There is a possibility that the PRDB data is more up-to-date than the data in the other registries. (The "changed date" is reliable in the prdb.db. How safe is it to trust the RIPE changed dates, and to only delete PRDB-transferred nets that have older changed dates than what is in the other registries?) We can mitigate the Changing Users Data problem by sending out an announcement of this plan, and then asking for anyone who does *not* want their duplicated nets pruned from the RADB to send us a list of either the Origin ASs or the Route IPs that they want us to leave alone. My own feeling is that a disjoint IRR is the correct vision, and that this kind of pruning once, as a transition step from the PRDB, is an appropriate step. (Especially with the announcement and exception list described above). Is there any disagreement with this? --Dale ============ From: Enke Chen > From enke at mci.net Wed Apr 26 17:11:58 1995 > To: dsj at merit.edu > cc: merit-ie at merit.edu, rr-types at mci.net > Subject: Purge data from the RADB > Date: Wed, 26 Apr 1995 17:11:22 -0400 > > Dale, > I know that people are working very hard on having the > discrepancies between the MCI RR and the PRDB (thus RADB) > resolved. That is a good thing. But for near-to-longer term, > the concern we have here is how the data in the RADB would > be handled and how discrepancies would be resolved. For > example, MICHnet now registers their route objects in the > MCI RR, and MICHnet only has connection to MCI. Will the > data in the RADB related to the MICHnet be purged to avoid > discrepancies in the future? > > It seems reasonable for the IRR to be distributed, and consist > of (almost) disjoint information from the MCI RR, CAnet RR, > RADB (supports ANS config and others). However, it is not > clear if the issue of multiple registrations can be avoided. > I remember that there was discussion about maintaining a list > of RR preference (or order of authorities) for each AS. Is this > something in the plan? > > This issues seem to be mainly releted to the RA. But feel > free to forward to the rr-impl list if necessary. > > -- Enke -------- Logged at Fri Apr 28 21:49:48 MET DST 1995 --------- From eric at enfm.utcc.utoronto.ca Fri Apr 28 21:49:09 1995 From: eric at enfm.utcc.utoronto.ca (Eric M. Carroll) Date: Fri, 28 Apr 1995 15:49:09 -0400 Subject: Towards a Disjoint IRR In-Reply-To: Your message of "Thu, 27 Apr 1995 15:33:02 -0400". <199504271933.PAA05472@home.merit.edu> Message-ID: <95Apr28.154930edt.606843@enfm.utcc.utoronto.ca> Dale, I support your view that a disjoint IRR is the correct vision, since it places the administrative burden closer to those who maintain the routers, and thus are the consumers of their own data. For example, CA*net has alot invested in keeping its own data accurate, since any errors will be expressed directly into our routers. Also, I believe the central "one registry to rule them all" model will not scale. As to the data cleanliness issue for conversion, canet.db has been carefully sanitized. PRDB CA*net data has not been (and will not be) carefully checked. I state authoritatively that canet.db is more accurate than PRDB. I encourage you to purge all CA*net data from the PRDB and use our database file instead. Please note that CA*net has taken the time to construct AS690 advisory lines for your routing enjoyment... Eric Carroll University of Toronto Network & Operations Services External Networking Facilities Management CA*net Network Engineering -------- Logged at Fri Apr 28 23:06:13 MET DST 1995 --------- From bmanning at ISI.EDU Fri Apr 28 23:04:36 1995 From: bmanning at ISI.EDU (bmanning at ISI.EDU) Date: Fri, 28 Apr 1995 14:04:36 -0700 (PDT) Subject: Towards a Disjoint IRR In-Reply-To: <95Apr28.154930edt.606843@enfm.utcc.utoronto.ca> from "Eric M. Carroll" at Apr 28, 95 03:49:09 pm Message-ID: <199504282104.AA19969@zed.isi.edu> > > Dale, > > I support your view that a disjoint IRR is the correct vision, since > While I tend to agree with Eric, I can see this model as being potentially hostile to people who are either having specific difficulties with a specific registration authority who may use this tacit agreement to "lock" registrations. As I pointed out elsewhere, while the registry may belong to the registration authority (nee ISP) the data in it belongs to the end user. We should ensure that there are tools to address/deal with duplications and making accurate determinations on which entries to beleive. --bill -------- Logged at Fri Apr 28 23:12:29 MET DST 1995 --------- From cengiz at ISI.EDU Fri Apr 28 23:12:31 1995 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Fri, 28 Apr 1995 14:12:31 -0700 Subject: Towards a Disjoint IRR In-Reply-To: <199504271933.PAA05472@home.merit.edu> References: <199504271933.PAA05472@home.merit.edu> Message-ID: <199504282112.AA09443@cat.isi.edu> Dale, Comments below. Dale S. Johnson (dsj at merit.edu) on April 27: > All, > > 1) The PRDB is about to be retired. (Oh? You say you've heard that > one before? ;-| Quite possibly on Monday, May 8. (Annoucements > will be made to rr-impl, as well as to nanog)). > > So: If you are currently picking up prdb.db, please make sure you > are also picking up the radb.db and including it in ALLSEARCH so > that traceroutes (etc.) via your server will continue to work. > > 2) We've talked about this informally before, but I'd like a group > discussion before we call it final: > > Once the PRDB route objects are copied/merged into the RADB, > should we purge all the RADB route objects that are duplicated > in other IRR databases? Specifically, should we go through the > lists of routes registered in MCI.db, CA*Net.db, and RIPE.db, > and for each net registered in any of those dbs AND WHICH HAS > ADVISORY AS690 LINES, remove that net from the RADB? I think this may be OK if the object in radb.db was created from prdb. However, if it was created explicitly by someone in that domain, we should not delete it. (To be more explicit, Ripe is the European registry, but if a domain in Europe also wants to register with RA, we should not say no, vice versa.) > > The advantage of pruning the RADB in this way is that the IRR becomes > more disjoint: generally, a route will be registered only in one > registry in the IRR. Users will not have two (or more) updates to > make for each route; the possibility of conflicting information > is greatly reduced. [Enke and Craig are working on resolving *lots* > of conflicts between the prdb.db and the mci.db as we speak]. > > The disadvantages of pruning the RADB include: > > This is modification of user data on a massive scale. > > Some users (e.g. multi-homed users) may need to be registered in more > than one registry. > > There is a possibility that the PRDB data is more up-to-date than the > data in the other registries. (The "changed date" is reliable in > the prdb.db. How safe is it to trust the RIPE changed dates, and > to only delete PRDB-transferred nets that have older changed dates > than what is in the other registries?) > > > We can mitigate the Changing Users Data problem by sending out an > announcement of this plan, and then asking for anyone who does *not* > want their duplicated nets pruned from the RADB to send us a list of > either the Origin ASs or the Route IPs that they want us to leave > alone. > > > My own feeling is that a disjoint IRR is the correct vision, and that > this kind of pruning once, as a transition step from the PRDB, is > an appropriate step. (Especially with the announcement and exception > list described above). It is a bad thing to have the same data registered in multiple places with conflicts, because one does not know which data to trust. However, we should leave it to the users to decide which places to register. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California http://www.isi.edu/div7/people/cengiz.home -------- Logged at Fri Apr 28 23:24:21 MET DST 1995 --------- From dsj at merit.edu Fri Apr 28 23:24:15 1995 From: dsj at merit.edu (Dale S. Johnson) Date: Fri, 28 Apr 1995 17:24:15 -0400 Subject: Towards a Disjoint IRR Message-ID: <199504282124.RAA14696@home.merit.edu> Cengiz, > > 2) We've talked about this informally before, but I'd like a group > > discussion before we call it final: > > > > Once the PRDB route objects are copied/merged into the RADB, > > should we purge all the RADB route objects that are duplicated > > in other IRR databases? Specifically, should we go through the > > lists of routes registered in MCI.db, CA*Net.db, and RIPE.db, > > and for each net registered in any of those dbs AND WHICH HAS > > ADVISORY AS690 LINES, remove that net from the RADB? > > I think this may be OK if the object in radb.db was created from > prdb. However, if it was created explicitly by someone in that domain, > we should not delete it. > > (To be more explicit, Ripe is the European registry, but if a domain > in Europe also wants to register with RA, we should not say no, vice > versa.) This is a good refinement. Sprint has recently registered a zillion nets in the RADB. They must want it that way. (Hopefully, the changed dates are consistent with this). Midnet also explicitly registered in the RADB, even though they are also in RIPE. Those should stay. Nets copied from the PRDB can be identified by the line: changed: nsfnet-admin at merit.edu 95xxxx --Dale -------- Logged at Fri Apr 28 23:30:50 MET DST 1995 --------- From dsj at merit.edu Fri Apr 28 23:30:45 1995 From: dsj at merit.edu (Dale S. Johnson) Date: Fri, 28 Apr 1995 17:30:45 -0400 Subject: Towards a Disjoint IRR Message-ID: <199504282130.RAA14837@home.merit.edu> > This is a good refinement. Sprint has recently registered a zillion > nets in the RADB. Make that 494. (Close enough for 5:30 Friday afternoon. Much less than the 6,000 they turned NACRs in for yesterday.) --Dale -------- Logged at Sat Apr 29 02:16:55 MET DST 1995 --------- From bmanning at ISI.EDU Sat Apr 29 02:15:16 1995 From: bmanning at ISI.EDU (bmanning at ISI.EDU) Date: Fri, 28 Apr 1995 17:15:16 -0700 (PDT) Subject: Towards a Disjoint IRR In-Reply-To: <199504282124.RAA14696@home.merit.edu> from "Dale S. Johnson" at Apr 28, 95 05:24:15 pm Message-ID: <199504290015.AA20380@zed.isi.edu> > This is a good refinement. Sprint has recently registered a zillion > nets in the RADB. They must want it that way. (Hopefully, the changed > dates are consistent with this). > > Midnet also explicitly registered in the RADB, even though they are > also in RIPE. Those should stay. > > Nets copied from the PRDB can be identified by the line: > > changed: nsfnet-admin at merit.edu 95xxxx > > --Dale Hum, taking MIDnet as an example... Sprint registered the nets in the RADB The same nets were migrated into the RADB from the PRDB MIDnet also registered the nets in the RADB MIDnet was forced to register in the MCIdb and, before the RADB was available, they registered nets in the RIPEdb. Which ones (if any) get pruned? Which ones get beleived? Who owns the data in a registry entry? -- --bill -------- Logged at Sat Apr 29 03:23:34 MET DST 1995 --------- From eric at enfm.utcc.utoronto.ca Sat Apr 29 03:23:22 1995 From: eric at enfm.utcc.utoronto.ca (Eric M. Carroll) Date: Fri, 28 Apr 1995 21:23:22 -0400 Subject: Towards a Disjoint IRR In-Reply-To: bmanning's message of "Fri, 28 Apr 1995 17:04:36 -0400". <199504282104.AA19969@zed.isi.edu> Message-ID: <95Apr28.212325edt.606492@enfm.utcc.utoronto.ca> Bill, I agree that there are locking, authentication and audit trail (or credibility) issues with a distributed registry. I think that this administrative & process infrastructure is a very important issue to face. The problem is the same in the phone network; they call it slamming, we call it "route poaching" leading to "CIDR MADness"[1]. Sean's "no mask longer than x" policy is an interesting strategy for national network defence. ;-) However, the bottom line is that there is no central registry in the Internet today from a practical perspective, and I think multiple registration models the problem better than central registry. It should be noted that in many cases, there is *no registry* mediating between some providers. For example, if there are multiple ISPs annoucing a route, I believe it is better to know that fact than have them do it silently. This permits static analysis of conflicts and reporting. This multiple conflicting registration *already* happens with the PRDB, assuming the current RA-less NAPs or MAE-E. Say, for example, I have X, service provider Z has X too, and announces it. Today, I prefer X locally, Z prefers X locally, AS690 and those behind it prefer what's in the PRDB, and everyone else, all bets are off. At least, if someone runs static analysis, I know that someone grabbed "my" route. I can then alert to the customer, and find out what should be happening. This is in fact what just happened recently. What I think shows promise is the digital signature strategy in the delegation & registration. This permits a customer to say for sure that they want to be in vendor Zs registry. The audit trail is preserved, and the credibility of the delegation & registration is established. The hard part for the customer is *revoking* that routing registration. This problem comes in two parts: routing registry registration and actual implemented routes interior to the old vendor. This is especially difficult in the face of heavy use of static routes. I cannot count the times a customer has transitioned, and the static simply remains on the old vendor's network, black-holing some large part of the customer's reachability. Eric Carroll University of Toronto Network & Operations Services External Networking Facilities Management CA*net Network Engineering [1] CIDR MADness - CIDR Mutual Assured Destruction - two-vendor iterated escalation the length of the mask for a given customer route in order to recover primary control of a route intiated when one vendor registers a longer-mask subaggregate of an overall agregate registered by a second vendor. I have been meaning to actually write that down since we talked in Colorado. :-) -------- Logged at Sat Apr 29 04:11:15 MET DST 1995 --------- From curtis at ans.net Sat Apr 29 04:00:55 1995 From: curtis at ans.net (Curtis Villamizar) Date: Fri, 28 Apr 1995 22:00:55 -0400 Subject: Towards a Disjoint IRR In-Reply-To: Your message of "Fri, 28 Apr 1995 14:04:36 PDT." <199504282104.AA19969@zed.isi.edu> Message-ID: <199504290200.WAA09937@curtis.ansremote.com> In message <199504282104.AA19969 at zed.isi.edu>, bmanning at ISI.EDU writes: > > > > Dale, > > > > I support your view that a disjoint IRR is the correct vision, since > > > > While I tend to agree with Eric, I can see this model as being potentially > hostile to people who are either having specific difficulties with a specific > registration authority who may use this tacit agreement to "lock" registratio > ns. > > As I pointed out elsewhere, while the registry may belong to the registration > authority (nee ISP) the data in it belongs to the end user. > > We should ensure that there are tools to address/deal with duplications and > making accurate determinations on which entries to beleive. > > > --bill Why doesn't this seem like a problem to me? The RADB concentrates data from CANET, MCI, ANS, anyone else with a registry in North America and also bring in data from the other continents. CANET would consider their own information authorative for CANET and their secondary mirror of RADB (if they run a secondary to keep things local) as authorative for everything not covered locally. Same with MCI, ANS, anyone else, consulting their own data first. The RADB would run secondary for CANET, MCI, ANS, etc, and primary for registeries that didn't fall into any of the above. If someone moves between providers, their old ISP could potentially 1) fail to remove the peering from inet-rtr (so what), 2) fail to put a "hole" in their route object, 3) fail to remove the AS from an AS macro, 4) fail to adjust their policy to accept the announcement of the hole in their aggregation. I don't think 2) is an issue. If explicit policy for an AS overrides an AS macro, then 3) is not an issue. The only issue is 4) because the the customer couldn't route traffic through their old provider if their old provider generated their configs reflecting their registry. It wouldn't affect policy outside that AS though, nor would it affect policies of other AS as long as the route object could get into some registry (their new provider or primary at the RADB). This simply goes back to the question of how big a prefix must be to justify moving out of a CIDR block without renumbering. Yes, this is a problem. The registry would reflect the situation if some providers routed the small more specific block and other didn't. If numerous providers chose not to route prefixes below a certain size, then it would give the customer a means of assessing whether to renumber. (Based on empeircal evidence it might boost the volume of their complaints on the mailing lists first). This is a problem, but why is this a registery problem? Am I missing something? Curtis -------- Logged at Mon May 1 15:54:56 MET DST 1995 ---------