From Daniel.Karrenberg at ripe.net Mon May 1 15:54:53 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 01 May 1995 15:54:53 +0200 Subject: Towards a Disjoint IRR In-Reply-To: Your message of Fri, 28 Apr 1995 22:00:55 EDT. <199504290200.WAA09937@curtis.ansremote.com> Message-ID: <9505011354.AA29144@ncc.ripe.net> > Curtis Villamizar writes: > > 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. Well does it? Not in my view of the world. + There are multiple Routing Registries (RR) which combined form the Internet Routing Registry (IRR). + Each RR has a unique value of the source attribute. (The current implementation of the IRR is to copy all known RRs. A slight improvement allowing dynamic updates to these copies is currently being implemented. There had been a proposal for a RR object to describe each RR and an IRR object to list the currently known RRs. This never came to pass, or didi it?) + Ideally each object is registered only in one RR. This it appears only once in the IRR + Each object can be registered in multiple RRs. This means it appears multiple times in the IRR. + If an object appears multiple times in the IRR, it is a local matter which ones take precedence. A convention is to order the responses of a whois server and give earlier answers for the same object priority. The current RIPE DB software has two config file options for this: -------- # default databases to do lookups in DEFLOOK RIPE # if all databases are selected (-a switch) ALLLOOK RIPE INTERNIC MERIT ALTERNET NCC-AS-LIST -------- The latter probably needs cleaning up ;-) > This is a problem, but why is this a registery problem? Am I missing > something? The questions now are: Q1) Should users be allowed to register objects in multiple RRs? The answer is YES because: - some RRs may require local registration for getting service - some RRs may abuse a single registry requirement Q2) Should users be encouraged to register objects in multiple RRs. The answer is NO because - it creates inconsistency problems Q3) Should RR operators register objects in their RR on behalf of users without the user's knowledge? It does not matter whether this is by copying from another RR or by other means. The answer is NO because - it creates inconsistency problems - it confuses the users Daniel -------- Logged at Mon May 1 16:26:30 MET DST 1995 --------- From Daniel.Karrenberg at ripe.net Mon May 1 16:26:27 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 01 May 1995 16:26:27 +0200 Subject: Towards a Disjoint IRR In-Reply-To: Your message of Thu, 27 Apr 1995 15:33:02 EDT. <199504271933.PAA05472@home.merit.edu> Message-ID: <9505011426.AA29351@ncc.ripe.net> > "Dale S. Johnson" writes: > > 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 I am in favour as far as the RIPE RR is concerned. A few observations: + Changed dates can generally be trusted. + We have no (or only very few) north american data. We will purge it after coordination with the user if we come across it. + If you suspect you have newer data, please tell the user asking where he wants to be registered. If the user is European suggest registering in the RIPE RR. > AND WHICH HAS ADVISORY AS690 LINES, remove that net from the RADB? Usually we are not happy about modifying user data. After requests from our users and some evaluation we are prepared to make an exception for the 'advisory: AS690' attributes, provided we can receive a complete list of them from you at the flag day. We will then add those to the RIPE RR and tell the users. > 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]. That is why I like it. > The disadvantages of pruning the RADB include: > > This is modification of user data on a massive scale. This is only a problem if the data was really added by the users and not derived from something else. > Some users (e.g. multi-homed users) may need to be registered in more > than one registry. So what? > 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?) That is a possibility. I would like to see the others flagged as well though. > 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. That's what we will probably do w.r.t. the advisory: AS690 thing. > 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). Yes. Daniel -------- Logged at Mon May 1 18:15:35 MET DST 1995 --------- From curtis at ans.net Mon May 1 18:10:08 1995 From: curtis at ans.net (Curtis Villamizar) Date: Mon, 01 May 1995 12:10:08 -0400 Subject: copyright boilerplate in conf file Message-ID: <199505011611.MAA00842@curtis.ansremote.com> Just checking. We are supposed to modify the copyright below rather than leave yours since the intent is to protect the data registered in the IRR from being used for advertisement or marketing or something like that. Right? Or do we leave Daniel's copyright, or does anyone care as long as we leave the intent intact? Curtis RIGHTS Copyright (c)1992/1993/1994 by Daniel Karrenberg and the RARE Association RIGHTS RIGHTS Restricted rights. RIGHTS RIGHTS Except for agreed Internet operational purposes, no part of this RIGHTS publication may be reproduced, stored in a retrieval system, or RIGHTS transmitted, in any form or by any means, electronic, mechanical, RIGHTS recording, or otherwise, without prior permission of the RIPE NCC RIGHTS on behalf of the copyright holders. Any use of this material to RIGHTS target advertising or similar activities are explicitly forbidden RIGHTS and will be prosecuted. The RIPE NCC requests to be notified of RIGHTS any such activities or suspicions thereof. -------- Logged at Mon May 1 19:00:15 MET DST 1995 --------- From dsj at merit.edu Mon May 1 19:00:08 1995 From: dsj at merit.edu (Dale S. Johnson) Date: Mon, 1 May 1995 13:00:08 -0400 Subject: Towards a Disjoint IRR Message-ID: <199505011700.NAA18668@home.merit.edu> All, The Advisory AS690 lines were initially intended as a transition step to last from December through March 1995. Needless to say, we fell way behind this schedule. Curtis has a plan coded and in testing which will make Advisory lines totally--well: advisory. Under his plan, all policy expressions in the AS690 aut-num object will be AS-based, but advisory attributes can be used to give end-AS suggestions to AS690 about how they would like their routing handled. It may well be the the RIPE database can totally ignore the advisory concept, and that Curtis' scheme will handle RIPE-based registrations well anyway. (MCI can continue its current use of Advisories as they like). I hope this is true; it would be wonderful. But ANS will have to speak for these details; they are in control of that situation now. --Dale > + If you suspect you have newer data, please tell the user asking where he > wants to be registered. If the user is European suggest registering in > the RIPE RR. > > > AND WHICH HAS ADVISORY AS690 LINES, remove that net from the RADB? > > Usually we are not happy about modifying user data. After requests from > our users and some evaluation we are prepared to make an exception for > the 'advisory: AS690' attributes, provided we can receive a complete list > of them from you at the flag day. We will then add those to the RIPE RR > and tell the users. Flag day is scheduled for next Monday, May 8. (Hopefully). -------- Logged at Mon May 1 19:01:22 MET DST 1995 --------- From Daniel.Karrenberg at ripe.net Mon May 1 19:01:20 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 01 May 1995 19:01:20 +0200 Subject: copyright boilerplate in conf file In-Reply-To: Your message of Mon, 01 May 1995 12:10:08 EDT. <199505011611.MAA00842@curtis.ansremote.com> Message-ID: <9505011701.AA02089@ncc.ripe.net> > Curtis Villamizar writes: > > Just checking. > > We are supposed to modify the copyright below rather than leave yours > since the intent is to protect the data registered in the IRR from > being used for advertisement or marketing or something like that. > Right? Or do we leave Daniel's copyright, or does anyone care as long > as we leave the intent intact? > RIGHTS Copyright (c)1992/1993/1994 by Daniel Karrenberg and the RARE Associ > ation > RIGHTS > RIGHTS Restricted rights. > RIGHTS This concerns the data in the registry. You are free to change it at will. I suggest that you put in similar language for all it is worth. Copyrighting a complilation is tricky anyways..... Check with your legal consel ;-). The software itself has RARE/TERENA copyright which lets you do what you want with it and only asks for proper credit. Daniel -------- Logged at Mon May 1 19:12:57 MET DST 1995 --------- From cengiz at ISI.EDU Mon May 1 19:12:53 1995 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Mon, 1 May 1995 10:12:53 -0700 Subject: Towards a Disjoint IRR In-Reply-To: <9505011354.AA29144@ncc.ripe.net> References: <199504290200.WAA09937@curtis.ansremote.com> <9505011354.AA29144@ncc.ripe.net> Message-ID: <199505011712.AA18161@cat.isi.edu> Daniel Karrenberg (Daniel.Karrenberg at ripe.net) on May 1: > Q2) Should users be encouraged to register objects in multiple RRs. > > The answer is NO because > > - it creates inconsistency problems Daniel, I think Curtis's point was that the inconsistency is not actually a problem because everyone will going to thrust its own data first. Curtis please correct me if I am wrong. I think inconsistency is a problem, especially if the conflict is happening in two sources which are not in my control (say I am the RA and the conflict is between MCI.db and CANet.db, who should I trust). Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California http://www.isi.edu/div7/people/cengiz.home -------- Logged at Mon May 1 19:46:25 MET DST 1995 --------- From curtis at ans.net Mon May 1 19:35:50 1995 From: curtis at ans.net (Curtis Villamizar) Date: Mon, 01 May 1995 13:35:50 -0400 Subject: Towards a Disjoint IRR In-Reply-To: Your message of "Mon, 01 May 1995 15:54:53 +0200." <9505011354.AA29144@ncc.ripe.net> Message-ID: <199505011736.NAA01498@curtis.ansremote.com> In message <9505011354.AA29144 at ncc.ripe.net>, Daniel Karrenberg writes: > > > Curtis Villamizar writes: > > > > 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. > > Well does it? > Not in my view of the world. [ ... tutorial deleted ... ] I agree with your Q1 and Q2. > Q3) Should RR operators register objects in their RR on behalf of users > without the user's knowledge? It does not matter whether this is by > copying from another RR or by other means. > > The answer is NO because > > - it creates inconsistency problems > - it confuses the users There is support for secondaries, though I have't tried it, it looks simple enough. I agree that the US RADB should not claim to be authoritative over RIPE for European networks, but I see no reason why they (or ANS, or MCI) can't mirror RIPE information in a separate database that is periodically fetched in its entirety from RIPE. I thought I clearly mentioned a distribution of primary authority with RADB mirroring some registries and serving as primary for providers who don't run their own registry, or prefer to mirror the RADB (and leave them with the registration headaches). There is already duplication, and the IRR registries are just going to have to resolve this over time. Once AS690 advisories are gone (hopefully soon), I see no reason not to drop PRDB machine generated route object registrations in favor of a registration entered by the end user. We will have to provide advance notification, particularly if a change in the recorded origin will change routing. Long term, I see ANS as being the primary repository for ANS inet-rtr objects, ANS aut-num, and route objects for ANS direct attached customers. I see the RADB as primary for customers of Sprint, PSI, CIX, etc or any other US provider that does not run a registry. Does this fit nicely into your view of the world? > Daniel Curtis -------- Logged at Mon May 1 20:23:14 MET DST 1995 --------- From curtis at ans.net Mon May 1 20:20:58 1995 From: curtis at ans.net (Curtis Villamizar) Date: Mon, 01 May 1995 14:20:58 -0400 Subject: Towards a Disjoint IRR In-Reply-To: Your message of "Mon, 01 May 1995 16:26:27 +0200." <9505011426.AA29351@ncc.ripe.net> Message-ID: <199505011820.OAA01707@curtis.ansremote.com> In message <9505011426.AA29351 at ncc.ripe.net>, Daniel Karrenberg writes: > > > Some users (e.g. multi-homed users) may need to be registered in more > > than one registry. > > So what? Why is this so. If they register in one place and there are other places with secondary information, there registration should reach everywhere. For example if they register with MCI, RADB should provide secondary and ANS should be secondary too, perhaps even getting inforation from the RADB. AS long as the AS690 aut-num has policy for their home AS (origin), they should get routed correctly. > > 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. > > That's what we will probably do w.r.t. the advisory: AS690 thing. I don't expect AS690 advisories to have a long life. We are able to generate configs without them using mostly AS based policy with exceptions listed on a per network basis that are identical to those with the AS advisories, it just takes to long right now to be practical. I'm working on integrating this with peval and Dale's work to get rid of the advisories, quickly if possible. Curtis -------- Logged at Mon May 1 21:00:47 MET DST 1995 --------- From dsj at merit.edu Mon May 1 21:00:38 1995 From: dsj at merit.edu (Dale S. Johnson) Date: Mon, 1 May 1995 15:00:38 -0400 Subject: copyright boilerplate in conf file Message-ID: <199505011900.PAA23076@home.merit.edu> Curtis, Here are some other current .db file headers: RADB: # # 950501 06:37:02 # # Copyright (c)1992/1993/1994/1995 by Merit, Inc. and the # Regents of the University of Michigan. # # Restricted rights. # # Except for agreed Internet operational purposes, no part of this # publication may be reproduced, stored in a retrieval system, or # transmitted, in any form or by any means, electronic, mechanical, # recording, or otherwise, without prior permission of Merit, Inc. # on behalf of the copyright holders. Any use of this material to # target advertising or similar activities are explicitly forbidden # and will be prosecuted. Merit, Inc. requests to be notified of # any such activities or suspicions thereof. MCI: # # 950501 01:09:59 # CANET: # # 950421 15:14:35 # # Copyright (c)1994 by CA*Net Networking Inc, # and the University of Toronto. # # Restricted rights. # # Except for agreed Internet operational purposes, no part of this # publication may be reproduced, stored in a retrieval system, or # transmitted, in any form or by any means, electronic, mechanical, # recording, or otherwise, without prior permission of CA*net Networking # Inc. on behalf of the copyright holders. Any use of this material to # target advertising or similar activities are explicitly forbidden # and will be prosecuted. The CA*net NOC requests to be notified of # any such activities or suspicions thereof. --Dale ============ From: Curtis Villamizar > From curtis at curtis.ansremote.com Mon May 1 12:16:44 1995 > To: rr-impl at ripe.net > Cc: curtis at ans.net > Reply-To: curtis at ans.net > Subject: copyright boilerplate in conf file > Date: Mon, 01 May 1995 12:10:08 -0400 > > > Just checking. > > We are supposed to modify the copyright below rather than leave yours > since the intent is to protect the data registered in the IRR from > being used for advertisement or marketing or something like that. > Right? Or do we leave Daniel's copyright, or does anyone care as long > as we leave the intent intact? > > Curtis > > > RIGHTS Copyright (c)1992/1993/1994 by Daniel Karrenberg and the RARE Association > RIGHTS > RIGHTS Restricted rights. > RIGHTS > RIGHTS Except for agreed Internet operational purposes, no part of this > RIGHTS publication may be reproduced, stored in a retrieval system, or > RIGHTS transmitted, in any form or by any means, electronic, mechanical, > RIGHTS recording, or otherwise, without prior permission of the RIPE NCC > RIGHTS on behalf of the copyright holders. Any use of this material to > RIGHTS target advertising or similar activities are explicitly forbidden > RIGHTS and will be prosecuted. The RIPE NCC requests to be notified of > RIGHTS any such activities or suspicions thereof. -------- Logged at Mon May 1 21:12:09 MET DST 1995 --------- From dsj at merit.edu Mon May 1 21:12:05 1995 From: dsj at merit.edu (Dale S. Johnson) Date: Mon, 1 May 1995 15:12:05 -0400 Subject: Towards a Disjoint IRR Message-ID: <199505011912.PAA23588@home.merit.edu> Curtis, > There is already duplication, and the IRR registries are just going to > have to resolve this over time. Once AS690 advisories are gone > (hopefully soon), I see no reason not to drop PRDB machine generated > route object registrations in favor of a registration entered by the > end user. We will have to provide advance notification, particularly > if a change in the recorded origin will change routing. PRDB machine-generated route object registrations will stop at the end of the day next Monday, May 8 (target). From that point on there *is* no PRDB: users attempting to send net NACRs to the prdb will get a reply message saying "Here is a translation of your NACR into a route object: please mail this to auto-dbm at ra.net". I don't think this has anything to do with timetables about advisories. > Long term, I see ANS as being the primary repository for ANS inet-rtr > objects, ANS aut-num, and route objects for ANS direct attached > customers. I see the RADB as primary for customers of Sprint, PSI, > CIX, etc or any other US provider that does not run a registry. Does > this fit nicely into your view of the world? Very nicely, indeed. --Dale -------- Logged at Mon May 1 21:17:27 MET DST 1995 --------- From curtis at ans.net Mon May 1 20:52:22 1995 From: curtis at ans.net (Curtis Villamizar) Date: Mon, 01 May 1995 14:52:22 -0400 Subject: Towards a Disjoint IRR In-Reply-To: Your message of "Mon, 01 May 1995 10:12:53 PDT." <199505011712.AA18161@cat.isi.edu> Message-ID: <199505011854.OAA01902@curtis.ansremote.com> In message <199505011712.AA18161 at cat.isi.edu>, Cengiz Alaettinoglu writes: > > Daniel Karrenberg (Daniel.Karrenberg at ripe.net) on May 1: > > Q2) Should users be encouraged to register objects in multiple RRs. > > > > The answer is NO because > > > > - it creates inconsistency problems > > Daniel, > > I think Curtis's point was that the inconsistency is not actually a > problem because everyone will going to thrust its own data first. Curtis > please correct me if I am wrong. See my last two messages. We with "thrust" our own aut-num, inet-rtr, direct attached customers, and do secondary for other registries that are authoritative for other parts of the topology so our config process is not affected by occasional failure to reach another part of the Internet. > I think inconsistency is a problem, especially if the conflict is > happening in two sources which are not in my control (say I am the RA > and the conflict is between MCI.db and CANet.db, who should I trust). If everyone is keeping all the data and considering their own copy authoritative, I agree that there would be a big consistency problem. Sorry if I was unclear. > Cengiz > > -- > Cengiz Alaettinoglu Information Sciences Institute > (310) 822-1511 University of Southern California > http://www.isi.edu/div7/people/cengiz.home Curtis -------- Logged at Mon May 1 22:59:21 MET DST 1995 --------- From dsj at merit.edu Mon May 1 22:59:16 1995 From: dsj at merit.edu (Dale S. Johnson) Date: Mon, 1 May 1995 16:59:16 -0400 Subject: Towards a Disjoint IRR Message-ID: <199505012059.QAA28074@home.merit.edu> > > + If you suspect you have newer data, please tell the user asking where he > > wants to be registered. If the user is European suggest registering in > > the RIPE RR. > > > > > AND WHICH HAS ADVISORY AS690 LINES, remove that net from the RADB? > > > > Usually we are not happy about modifying user data. After requests from > > our users and some evaluation we are prepared to make an exception for > > the 'advisory: AS690' attributes, provided we can receive a complete list > > of them from you at the flag day. We will then add those to the RIPE RR > > and tell the users. > > Flag day is scheduled for next Monday, May 8. (Hopefully). Actually, next Monday, May 8 is when we hope to turn the PRDB off, move all its route objects into the RADB, and retire the PRDB. This date does not have to have anything to do with other flag days, such as when ANS accepts the MCI.db or CANET.db into its config generation, or when it accepts the RIPE.db, or when it switches to Curtis' AS690 object that makes AS690 advisories unnecessary. Daniel, I think between Curtis and me we've all ready said that your copying the AS690 advisories into the RIPE db is probably no longer a timely idea. Even if that turns out not to be the case, I don't think it needs to be correlated with the May 8 "Death of the PRDB" flag day. --Dale -------- Logged at Tue May 2 22:02:45 MET DST 1995 --------- From bmanning at ISI.EDU Tue May 2 15:57:22 1995 From: bmanning at ISI.EDU (bmanning at ISI.EDU) Date: Tue, 2 May 1995 06:57:22 -0700 (PDT) Subject: Towards a Disjoint IRR In-Reply-To: <199505011736.NAA01498@curtis.ansremote.com> from "Curtis Villamizar" at May 1, 95 01:35:50 pm Message-ID: <199505021357.AA24797@zed.isi.edu> > There is support for secondaries, though I have't tried it, it looks > simple enough. I agree that the US RADB should not claim to be > authoritative over RIPE for European networks, but I see no reason why > they (or ANS, or MCI) can't mirror RIPE information in a separate > database that is periodically fetched in its entirety from RIPE. > > I thought I clearly mentioned a distribution of primary authority with > RADB mirroring some registries and serving as primary for providers > who don't run their own registry, or prefer to mirror the RADB (and > leave them with the registration headaches). > Why does this sound like something that I have seen before? Can you say DNS? Sure you can! -- --bill -------- Logged at Wed May 3 16:01:48 MET DST 1995 --------- From dsj at merit.edu Wed May 3 16:00:15 1995 From: dsj at merit.edu (Dale S. Johnson) Date: Wed, 3 May 1995 10:00:15 -0400 Subject: Andrew: BGP->Route object translator Message-ID: <199505031400.KAA20758@home.merit.edu> All FYI: Andrew has come up with a clever way around the IRR intent: simply machine-generate his route objects from the live BGP tables and submit them daily. Advantages: everything is registered, just like we want it. Disadvantages: even things we'd have hoped a human would filter out (net 10) get registered. (Also, a certain amount of thrash in the DB). Comments? --Dale ============ From: Andrew Partan > From asp at uunet.uu.net Tue May 2 15:16:11 1995 > Subject: Re: Something to make you vomit... > To: smd at sprint.net > Date: Tue, 2 May 1995 14:46:30 -0400 (EDT) > Cc: heimlich at ans.net, dsj at merit.edu > > Here is something that I hacked together. Generates route objects from > "show ip bgp" output. [I'm not quite sure that I have everything that I > want in the route object yet.] > > I'm thinking of running it once/day out of cron and sending the output > to the RADB. > --asp > > #!/bin/sh > # > # Generate RADB route objects from a "show ip bgp reg ^$" dump. > # The dump is in $1 > > # Who is running this. > who=`whoami` > > # Current date, YYMMDD > yymmdd=`date +%y%m%d` > > # The route object > cat << EOF > /tmp/ro.$$ > { > print "route:", \$1 > print "descr: AlterNet route - AS 701" > print "origin: AS701" > print "advisory: AS690 1:701" > print "mnt-by: MAINT-AS701" > print "changed: $who at uunet.uu.net $yymmdd" > print "source: RADB" > print "" > } > EOF > > # Get the routes (if there is one). > gawk 'substr($0,4,2) ~ /[0-9][0-9.]/ {print substr($0,4,17)}' $1 \ > | gawk -f /tmp/ro.$$ > > # Clean up > rm -f /tmp/ro.$$ -------- Logged at Wed May 3 16:10:56 MET DST 1995 --------- From selina at ans.net Wed May 3 16:10:46 1995 From: selina at ans.net (Selina Priestley) Date: Wed, 03 May 1995 10:10:46 -0400 Subject: Andrew: BGP->Route object translator In-Reply-To: Message from of Wed May 3,1995 10:0 EDT <199505031400.KAA20758@home.merit.edu> Message-ID: <199505031410.AA71725@interlock.ans.net> Curtis pointed out that they'd want to do some checking so that only routes with aspaths they should register for were registered and that diffing daily pulls would be fairly simple and save you folks a lot of work. Route 10 could get registered? What do we have now that checks registrations? Could it be altered to also look for Martians? Selina > All FYI: > > Andrew has come up with a clever way around the IRR intent: simply > machine-generate his route objects from the live BGP tables and submit > them daily. > > Advantages: everything is registered, just like we want it. > > Disadvantages: even things we'd have hoped a human would filter out > (net 10) get registered. (Also, a certain amount of thrash in the DB). > > Comments? > > --Dale > > > ============ From: Andrew Partan > > > From asp at uunet.uu.net Tue May 2 15:16:11 1995 > > Subject: Re: Something to make you vomit... > > To: smd at sprint.net > > Date: Tue, 2 May 1995 14:46:30 -0400 (EDT) > > Cc: heimlich at ans.net, dsj at merit.edu > > > > Here is something that I hacked together. Generates route objects from > > "show ip bgp" output. [I'm not quite sure that I have everything that I > > want in the route object yet.] > > > > I'm thinking of running it once/day out of cron and sending the output > > to the RADB. > > --asp > > > > #!/bin/sh > > # > > # Generate RADB route objects from a "show ip bgp reg ^$" dump. > > # The dump is in $1 > > > > # Who is running this. > > who=`whoami` > > > > # Current date, YYMMDD > > yymmdd=`date +%y%m%d` > > > > # The route object > > cat << EOF > /tmp/ro.$$ > > { > > print "route:", \$1 > > print "descr: AlterNet route - AS 701" > > print "origin: AS701" > > print "advisory: AS690 1:701" > > print "mnt-by: MAINT-AS701" > > print "changed: $who at uunet.uu.net $yymmdd" > > print "source: RADB" > > print "" > > } > > EOF > > > > # Get the routes (if there is one). > > gawk 'substr($0,4,2) ~ /[0-9][0-9.]/ {print substr($0,4,17)}' $1 \ > > | gawk -f /tmp/ro.$$ > > > > # Clean up > > rm -f /tmp/ro.$$ -------- Logged at Wed May 3 16:23:27 MET DST 1995 --------- From bmanning at ISI.EDU Wed May 3 16:20:33 1995 From: bmanning at ISI.EDU (bmanning at ISI.EDU) Date: Wed, 3 May 1995 07:20:33 -0700 (PDT) Subject: Andrew: BGP->Route object translator In-Reply-To: <199505031400.KAA20758@home.merit.edu> from "Dale S. Johnson" at May 3, 95 10:00:15 am Message-ID: <199505031420.AA26280@zed.isi.edu> > > All FYI: > > Andrew has come up with a clever way around the IRR intent: simply > machine-generate his route objects from the live BGP tables and submit > them daily. > > Advantages: everything is registered, just like we want it. > > Disadvantages: even things we'd have hoped a human would filter out > (net 10) get registered. (Also, a certain amount of thrash in the DB). > > Comments? > Well, net10 can and should be registered, just as you state in the advantages column. I dislike the thrash, but I expect it is inevitable. (What happens when we go to 15min RS updates?) Otherwise, I expect that this is only half of what he should be placing in the IRR. Simple dumping of BGP tables does not get you the policy expressions that most people are using to generate filters. Is Andrew going to accept any/every thing in the IRR? --bill -------- Logged at Wed May 3 20:39:57 MET DST 1995 --------- From Tony.Bates at mci.net Wed May 3 20:39:52 1995 From: Tony.Bates at mci.net (Tony Bates) Date: Wed, 03 May 1995 14:39:52 -0400 Subject: Small fix to whoisd.pl Message-ID: <199505031839.OAA00366@lovefm.reston.mci.net> Hi, I am in the process of porting the RR stuff to run on Slowaris (SunOS 5.4 to be exact ) and came across this amazing horrible nit which we should reflect back in the src. In the whoisd code we do a setsockopt so we can reuse the address like so: setsockopt(S, $SOL_SOCKET, $SO_REUSEADDR, 1) || die "setsockopt: $!"; Unfortunately, the value of OPTVAL (1) in the c source of perl is not tranlated properly into a pointer to an integer as it needs to be for the system call to work properly. The odd thing is on SunOS4.1.3 the setsockopt routine doesn't actually care if it is wrong. After hacking the perl code and lots of debugging to gdb we (thanks Dennis for considerable gdb help) found the SunOS5.4 networking code does and returns invalid argument. The awful fix is to do the following. Change the lines to: $on = "\0\0\001"; setsockopt(S, $SOL_SOCKET, $SO_REUSEADDR, $on) || die "setsockopt: $!"; Or some such. This actually fakes the c code to do the right thing and actually make the you get a point to int with a non-zero value. This is a terrible and also annoying as in perl5 all this code is re-written as it is done properly. Anyway, you may want to test and reflect this change back in the source. Cheers, --Tony. -------- Logged at Wed May 3 20:48:01 MET DST 1995 --------- From Tony.Bates at mci.net Wed May 3 20:47:57 1995 From: Tony.Bates at mci.net (Tony Bates) Date: Wed, 03 May 1995 14:47:57 -0400 Subject: Scratch my last mail Message-ID: <199505031847.OAA00406@lovefm.reston.mci.net> Still doesn't work right....need to hack the perl-4.036 code...sigh.. --Tony -------- Logged at Wed May 3 20:56:57 MET DST 1995 --------- From lpj at merit.edu Wed May 3 20:56:52 1995 From: lpj at merit.edu (Laurent Joncheray) Date: Wed, 3 May 1995 14:56:52 -0400 (EDT) Subject: Small fix to whoisd.pl In-Reply-To: <199505031839.OAA00366@lovefm.reston.mci.net> from "Tony Bates" at May 3, 95 02:39:52 pm Message-ID: <199505031856.OAA03302@home.merit.edu> It is an old issue but... why don't you port whoisd to be called from [x]inetd. So you won't need any networking hack. It has been like that on radb.ra.net, and it seems to be fine. Laurent PS: lot of advantages: do not need to run as root, IP filtering, logging, In our previous episode, Tony Bates said: > > Hi, > I am in the process of porting the RR stuff to run on Slowaris > (SunOS 5.4 to be exact ) and came across this amazing horrible nit > which we should reflect back in the src. In the whoisd code we do a > setsockopt so we can reuse the address like so: > > setsockopt(S, $SOL_SOCKET, $SO_REUSEADDR, 1) || die "setsockopt: $!"; > > Unfortunately, the value of OPTVAL (1) in the c source of perl is not > tranlated properly into a pointer to an integer as it needs to be for > the system call to work properly. The odd thing is on SunOS4.1.3 the > setsockopt routine doesn't actually care if it is wrong. After hacking > the perl code and lots of debugging to gdb we (thanks Dennis for > considerable gdb help) found the SunOS5.4 networking code does and returns > invalid argument. > > The awful fix is to do the following. Change the lines to: > > $on = "\0\0\001"; > setsockopt(S, $SOL_SOCKET, $SO_REUSEADDR, $on) || die "setsockopt: $!"; > > Or some such. > > This actually fakes the c code to do the right thing and actually make > the you get a point to int with a non-zero value. This is a terrible > and also annoying as in perl5 all this code is re-written as it is > done properly. Anyway, you may want to test and reflect this change > back in the source. > > Cheers, > --Tony. > -- Laurent Joncheray, E-Mail: lpj at merit.edu Merit Network Inc, 4251 Plymouth Rd, Suite C, Phone: +1 (313) 936 2065 Ann Arbor, MI 48105, USA Fax: +1 (313) 747 3185 "This is the end, Beautiful friend. This is the end, My only friend, the end" JM -------- Logged at Wed May 3 21:41:05 MET DST 1995 --------- From Tony.Bates at mci.net Wed May 3 21:40:23 1995 From: Tony.Bates at mci.net (Tony Bates) Date: Wed, 03 May 1995 15:40:23 -0400 Subject: Small fix to whoisd.pl In-Reply-To: Your message of Wed, 03 May 1995 14:56:52 EDT. <199505031856.OAA03302@home.merit.edu> Message-ID: <199505031940.PAA00484@lovefm.reston.mci.net> I always though it was going too slow to read the conf file each time. Does this turn out not to be the case ? --Tony. Laurent Joncheray writes: * It is an old issue but... * why don't you port whoisd to be called from [x]inetd. So you * won't need any networking hack. It has been like that on radb.ra.net, * and it seems to be fine. * Laurent * PS: lot of advantages: do not need to run as root, IP filtering, logging, * * In our previous episode, Tony Bates said: * > * > Hi, * > I am in the process of porting the RR stuff to run on Slowaris * > (SunOS 5.4 to be exact ) and came across this amazing horrible nit * > which we should reflect back in the src. In the whoisd code we do a * > setsockopt so we can reuse the address like so: * > * > setsockopt(S, $SOL_SOCKET, $SO_REUSEADDR, 1) || die "setsockopt: $!"; * > * > Unfortunately, the value of OPTVAL (1) in the c source of perl is not * > tranlated properly into a pointer to an integer as it needs to be for * > the system call to work properly. The odd thing is on SunOS4.1.3 the * > setsockopt routine doesn't actually care if it is wrong. After hacking * > the perl code and lots of debugging to gdb we (thanks Dennis for * > considerable gdb help) found the SunOS5.4 networking code does and return * s * > invalid argument. * > * > The awful fix is to do the following. Change the lines to: * > * > $on = "\0\0\001"; * > setsockopt(S, $SOL_SOCKET, $SO_REUSEADDR, $on) || die "setsockopt: $!"; * > * > Or some such. * > * > This actually fakes the c code to do the right thing and actually make * > the you get a point to int with a non-zero value. This is a terrible * > and also annoying as in perl5 all this code is re-written as it is * > done properly. Anyway, you may want to test and reflect this change * > back in the source. * > * > Cheers, * > --Tony. * > * * * -- * Laurent Joncheray, E-Mail: lpj at merit.edu * Merit Network Inc, 4251 Plymouth Rd, Suite C, Phone: +1 (313) 936 20 * 65 * Ann Arbor, MI 48105, USA Fax: +1 (313) 747 31 * 85 * "This is the end, Beautiful friend. This is the end, My only friend, the en * d" JM -------- Logged at Wed May 3 22:05:10 MET DST 1995 --------- From lpj at merit.edu Wed May 3 22:05:02 1995 From: lpj at merit.edu (Laurent Joncheray) Date: Wed, 3 May 1995 16:05:02 -0400 (EDT) Subject: Small fix to whoisd.pl In-Reply-To: <199505031940.PAA00484@lovefm.reston.mci.net> from "Tony Bates" at May 3, 95 03:40:23 pm Message-ID: <199505032005.QAA05492@home.merit.edu> Well, you are welcome to try our server. whois -h whois.ra.net . and compare the response time with the one at RIPE. The most dificult is to take into account the type of machine and the network delay/bandwith. But i am sure you'll figure out. Laurent In our previous episode, Tony Bates said: > > I always though it was going too slow to read the conf file each > time. Does this turn out not to be the case ? > > --Tony. > > Laurent Joncheray writes: > * It is an old issue but... > * why don't you port whoisd to be called from [x]inetd. So you > * won't need any networking hack. It has been like that on radb.ra.net, > * and it seems to be fine. > * Laurent > * PS: lot of advantages: do not need to run as root, IP filtering, logging, > * > * In our previous episode, Tony Bates said: > * > > * > Hi, > * > I am in the process of porting the RR stuff to run on Slowaris > * > (SunOS 5.4 to be exact ) and came across this amazing horrible nit > * > which we should reflect back in the src. In the whoisd code we do a > * > setsockopt so we can reuse the address like so: > * > > * > setsockopt(S, $SOL_SOCKET, $SO_REUSEADDR, 1) || die "setsockopt: $!"; > * > > * > Unfortunately, the value of OPTVAL (1) in the c source of perl is not > * > tranlated properly into a pointer to an integer as it needs to be for > * > the system call to work properly. The odd thing is on SunOS4.1.3 the > * > setsockopt routine doesn't actually care if it is wrong. After hacking > * > the perl code and lots of debugging to gdb we (thanks Dennis for > * > considerable gdb help) found the SunOS5.4 networking code does and return > * s > * > invalid argument. > * > > * > The awful fix is to do the following. Change the lines to: > * > > * > $on = "\0\0\001"; > * > setsockopt(S, $SOL_SOCKET, $SO_REUSEADDR, $on) || die "setsockopt: $!"; > * > > * > Or some such. > * > > * > This actually fakes the c code to do the right thing and actually make > * > the you get a point to int with a non-zero value. This is a terrible > * > and also annoying as in perl5 all this code is re-written as it is > * > done properly. Anyway, you may want to test and reflect this change > * > back in the source. > * > > * > Cheers, > * > --Tony. > * > > * > * > * -- > * Laurent Joncheray, E-Mail: lpj at merit.edu > * Merit Network Inc, 4251 Plymouth Rd, Suite C, Phone: +1 (313) 936 20 > * 65 > * Ann Arbor, MI 48105, USA Fax: +1 (313) 747 31 > * 85 > * "This is the end, Beautiful friend. This is the end, My only friend, the en > * d" JM > -- Laurent Joncheray, E-Mail: lpj at merit.edu Merit Network Inc, 4251 Plymouth Rd, Suite C, Phone: +1 (313) 936 2065 Ann Arbor, MI 48105, USA Fax: +1 (313) 747 3185 "This is the end, Beautiful friend. This is the end, My only friend, the end" JM -------- Logged at Wed May 3 22:39:20 MET DST 1995 --------- From curtis at ans.net Wed May 3 22:32:55 1995 From: curtis at ans.net (Curtis Villamizar) Date: Wed, 03 May 1995 16:32:55 -0400 Subject: Andrew: BGP->Route object translator In-Reply-To: Your message of "Wed, 03 May 1995 10:00:15 EDT." <199505031400.KAA20758@home.merit.edu> Message-ID: <199505032032.QAA03474@curtis.ansremote.com> In message <199505031400.KAA20758 at home.merit.edu>, "Dale S. Johnson" writes: > All FYI: > > Andrew has come up with a clever way around the IRR intent: simply > machine-generate his route objects from the live BGP tables and submit > them daily. > > Advantages: everything is registered, just like we want it. > > Disadvantages: even things we'd have hoped a human would filter out > (net 10) get registered. (Also, a certain amount of thrash in the DB). > > Comments? > > --Dale > > > ============ From: Andrew Partan > > > From asp at uunet.uu.net Tue May 2 15:16:11 1995 > > Subject: Re: Something to make you vomit... > > To: smd at sprint.net > > Date: Tue, 2 May 1995 14:46:30 -0400 (EDT) > > Cc: heimlich at ans.net, dsj at merit.edu > > > > Here is something that I hacked together. Generates route objects from > > "show ip bgp" output. [I'm not quite sure that I have everything that I > > want in the route object yet.] > > > > I'm thinking of running it once/day out of cron and sending the output > > to the RADB. > > --asp > > > > #!/bin/sh > > # > > # Generate RADB route objects from a "show ip bgp reg ^$" dump. > > # The dump is in $1 > > > > # Who is running this. > > who=`whoami` > > > > # Current date, YYMMDD > > yymmdd=`date +%y%m%d` > > > > # The route object > > cat << EOF > /tmp/ro.$$ > > { > > print "route:", \$1 > > print "descr: AlterNet route - AS 701" > > print "origin: AS701" > > print "advisory: AS690 1:701" > > print "mnt-by: MAINT-AS701" > > print "changed: $who at uunet.uu.net $yymmdd" > > print "source: RADB" > > print "" > > } > > EOF > > > > # Get the routes (if there is one). > > gawk 'substr($0,4,2) ~ /[0-9][0-9.]/ {print substr($0,4,17)}' $1 \ > > | gawk -f /tmp/ro.$$ > > > > # Clean up > > rm -f /tmp/ro.$$ Dale, We've dicussed this internally. > Once we get rid of advisories, Sprint and Alternet just need to do > "show ip bgp" and pull off all of the prefixes and lengths and the > home AS from the AS path. Then for each one, they can compare with > the most recent list they sent. This can be done trivially by sorting > both lists, diffing, and grepping the "^>" lines from the diff. Then > they take that list, pack it in boilerplate and submit it. If the > legitimate owner submitted it or it is an AS that we know about and > Andrew isn't allow to modify, then Andrew gets a reject message. No > big deal if he gets a reject, since he will only send once. > > If you want I'll describe how you can do deletions of routes that > haven't been heard from in N days (weeks, months, whatever). It is > quite easy. Also Andrew and Sean could actually keep track of the AS > that they do (or don't) want to submit for and save a few reject > messages. Maybe after the 8th, we can write some code for him and > send it off. Comments on Andrew's idea: > This needs to be refined slightly. The "show ip bgp" output contains > an AS path. The last entry in the AS path will be the home AS. > Andrew is putting in AS701 for every route he knows which would be > incorrect for most routes. It would also be nice if he'd keep track > of routes he has sent and not resend them every day, saving Dale from > installing the special Alternet mail filter to handle this. > > Since most of the routes will be registered by someone else, Andrew > will get a huge rejection message every day if he does this. Curtis -------- Logged at Wed May 3 23:18:49 MET DST 1995 --------- From cengiz at ISI.EDU Wed May 3 23:18:49 1995 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Wed, 3 May 1995 14:18:49 -0700 Subject: Andrew: BGP->Route object translator In-Reply-To: <199505032032.QAA03474@curtis.ansremote.com> References: <199505031400.KAA20758@home.merit.edu> <199505032032.QAA03474@curtis.ansremote.com> Message-ID: <199505032118.AA26055@cat.isi.edu> Curtis Villamizar (curtis at ans.net) on May 3: > > This needs to be refined slightly. The "show ip bgp" output contains > > an AS path. The last entry in the AS path will be the home AS. > > Andrew is putting in AS701 for every route he knows which would be ************************ > > incorrect for most routes. I know nothing about cisco's show ip bgp, but I assume in show ip bgp reg ^$ reg ^$ matches the as path, i.e. empty as paths, i.e. the routes that he learned from IGP. Is this right? In which case, he is the true home as for those routes. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California http://www.isi.edu/div7/people/cengiz.home -------- Logged at Thu May 4 07:10:44 MET DST 1995 --------- From curtis at ans.net Thu May 4 06:46:02 1995 From: curtis at ans.net (Curtis Villamizar) Date: Thu, 04 May 1995 00:46:02 -0400 Subject: Andrew: BGP->Route object translator In-Reply-To: Your message of "Wed, 03 May 1995 14:18:49 PDT." <199505032118.AA26055@cat.isi.edu> Message-ID: <199505040446.AAA04024@curtis.ansremote.com> In message <199505032118.AA26055 at cat.isi.edu>, Cengiz Alaettinoglu writes: > > Curtis Villamizar (curtis at ans.net) on May 3: > > > This needs to be refined slightly. The "show ip bgp" output contains > > > an AS path. The last entry in the AS path will be the home AS. > > > Andrew is putting in AS701 for every route he knows which would be > ************************ > > > incorrect for most routes. > > I know nothing about cisco's show ip bgp, but I assume in > show ip bgp reg ^$ > reg ^$ matches the as path, i.e. empty as paths, i.e. the routes that > he learned from IGP. > > Is this right? In which case, he is the true home as for those routes. > > Cengiz I missed that. I guess Andrew had taken the AS into account. This doesn't help his attached customers with their own AS. Now all we need is the machinery in the shell program to avoid resubmitting the same thing every day and to withdraw the route (resubmit the route object as withdrawn) when components haven't been seen in a very long time (for some value of very long). I think Steve agreed to let me write this and make it available since it shouldn't take long at all. I'll probably get to it before May 8. Curtis -------- Logged at Thu May 4 10:02:22 MET DST 1995 --------- From Daniel.Karrenberg at ripe.net Thu May 4 10:02:20 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 04 May 1995 10:02:20 +0200 Subject: Small fix to whoisd.pl In-Reply-To: Your message of Wed, 03 May 1995 14:56:52 EDT. <199505031856.OAA03302@home.merit.edu> Message-ID: <9505040802.AA28095@ncc.ripe.net> > Laurent Joncheray writes: > It is an old issue but... > why don't you port whoisd to be called from [x]inetd. So you > won't need any networking hack. It has been like that on radb.ra.net, > and it seems to be fine. > Laurent > PS: lot of advantages: do not need to run as root, IP filtering, logging, The main issue here is performance. It is fork() against fork() exec() initialise() For something that potentially gets hit several times a second it makes a difference. Note that our server gets hit more often than yours because we also are the registration database for Europe. NB: If I remember correctly the code has an option to be run from inetd(8). So you can do it if you like. Daniel -------- Logged at Thu May 4 14:29:05 MET DST 1995 --------- From lpj at merit.edu Thu May 4 14:27:22 1995 From: lpj at merit.edu (Laurent Joncheray) Date: Thu, 4 May 1995 08:27:22 -0400 (EDT) Subject: xinetd timings? In-Reply-To: <199505041110.HAA06119@toad.merit.edu> from "Rick Riolo" at May 4, 95 07:10:48 am Message-ID: <199505041227.IAA22434@home.merit.edu> Well, since we are running the dbserver on port 5042 (no xinetd) and port 5044 (xinetd) you can do a loop like: call dbserver on port 5042 -> log the time call dbserver on port 5044 -> log the time Let say you run that for 1 hour during the night, and you look at the log file. Your point is right, initialise() in called for any request when running on xinetd, but who cares if it counts for 1% of the total time. Laurent In our previous episode, Rick Riolo said: > > maybe we should do a little timing test? > > my guess is yes, the setup time will take 3 (or N) times as > long with xinetd vs without, but it will be 2 or 3 (or some small N) > times 20ms or some little number, so it won't really matter, > even if hit 10 times a second. > > any other guesses? > > laurent: is the below noted difference right? > (I have no idea what xinetd does...sounds right though). > if so, we could easily set up a test with just those parts > (ie strip the initialise() from in.whoisd) and run a loop > and time the too approaches (divorced from the noise > of actually doing the lookups and across-network exchanges). > > or we could do a whole bunch of real queries at different > times to get some nice average that should wash out > network-induced noise in the timings. > > - r > > -------- > > > From: Daniel Karrenberg > > To: Laurent Joncheray > > CC: rr-impl at ripe.net > > > > > > Laurent Joncheray writes: > > > It is an old issue but... > > > why don't you port whoisd to be called from [x]inetd. So you > > > won't need any networking hack. It has been like that on radb.ra.net, > > > and it seems to be fine. > > > Laurent > > > PS: lot of advantages: do not need to run as root, IP filtering, logging, > > > > The main issue here is performance. It is > > > > fork() > > > > against > > > > fork() > > exec() > > initialise() > > > > For something that potentially gets hit several times a second it makes a > > difference. Note that our server gets hit more often than yours because > > we also are the registration database for Europe. > > > > NB: If I remember correctly the code has an option to be run from > > inetd(8). So you can do it if you like. > > > > Daniel > -- Laurent Joncheray, E-Mail: lpj at merit.edu Merit Network Inc, 4251 Plymouth Rd, Suite C, Phone: +1 (313) 936 2065 Ann Arbor, MI 48105, USA Fax: +1 (313) 747 3185 "This is the end, Beautiful friend. This is the end, My only friend, the end" JM -------- Logged at Thu May 4 15:58:43 MET DST 1995 --------- From Tony.Bates at mci.net Thu May 4 15:57:21 1995 From: Tony.Bates at mci.net (Tony Bates) Date: Thu, 04 May 1995 09:57:21 -0400 Subject: Andrew: BGP->Route object translator In-Reply-To: Your message of Thu, 04 May 1995 00:46:02 EDT. <199505040446.AAA04024@curtis.ansremote.com> Message-ID: <199505041357.JAA01675@lovefm.reston.mci.net> I really think this is the wrong approach of generating your route entries from your routing tables. Any connection which is down will not be in the bgp routing tables. If Andrew or others really dont have a database of their routes. Then they can grab all the cisco configs and depending on whether they redist static or not grep all the network lines or ip route lines. Grabbing a snap-shot of a BGP RiB is bound to miss things. --Tony. Curtis Villamizar writes: * * In message <199505032118.AA26055 at cat.isi.edu>, Cengiz Alaettinoglu writes: * > * > Curtis Villamizar (curtis at ans.net) on May 3: * > > > This needs to be refined slightly. The "show ip bgp" output contains * > > > an AS path. The last entry in the AS path will be the home AS. * > > > Andrew is putting in AS701 for every route he knows which would be * > ************************ * > > > incorrect for most routes. * > * > I know nothing about cisco's show ip bgp, but I assume in * > show ip bgp reg ^$ * > reg ^$ matches the as path, i.e. empty as paths, i.e. the routes that * > he learned from IGP. * > * > Is this right? In which case, he is the true home as for those routes. * > * > Cengiz * * * I missed that. I guess Andrew had taken the AS into account. This * doesn't help his attached customers with their own AS. Now all we * need is the machinery in the shell program to avoid resubmitting the * same thing every day and to withdraw the route (resubmit the route * object as withdrawn) when components haven't been seen in a very long * time (for some value of very long). I think Steve agreed to let me * write this and make it available since it shouldn't take long at all. * I'll probably get to it before May 8. * * Curtis -------- Logged at Thu May 4 16:57:42 MET DST 1995 --------- From dsj at merit.edu Thu May 4 16:56:11 1995 From: dsj at merit.edu (Dale S. Johnson) Date: Thu, 4 May 1995 10:56:11 -0400 Subject: Andrew: BGP->Route object translator Message-ID: <199505041456.KAA28830@home.merit.edu> All, > > Curtis Villamizar (curtis at ans.net) on May 3: > > > > This needs to be refined slightly. The "show ip bgp" output contains > > > > an AS path. The last entry in the AS path will be the home AS. > > > > Andrew is putting in AS701 for every route he knows which would be > > ************************ > > > > incorrect for most routes. > > > > I know nothing about cisco's show ip bgp, but I assume in > > show ip bgp reg ^$ > > reg ^$ matches the as path, i.e. empty as paths, i.e. the routes that > > he learned from IGP. > > > > Is this right? In which case, he is the true home as for those routes. > > > > Cengiz > > > I missed that. I guess Andrew had taken the AS into account. This > doesn't help his attached customers with their own AS. Now all we > need is the machinery in the shell program to avoid resubmitting the > same thing every day and to withdraw the route (resubmit the route > object as withdrawn) when components haven't been seen in a very long > time (for some value of very long). I think Steve agreed to let me > write this and make it available since it shouldn't take long at all. > I'll probably get to it before May 8. Or: should andrew have his own "source: ALTERNET". He doesn't have to run 181 at all; all he would have to do is run that script into a file once per day or more, and put the file up for FTP. The rest of the IRR would then pick that file up and post it through their whois servers. Sprint would quickly follow suit, I think. The RADB may have little to do but to be a collator and publisher of ISP's .db files, but that is sort of the direction we have all proposed. --Dale -------- Logged at Thu May 4 17:08:09 MET DST 1995 --------- From selina at ans.net Thu May 4 16:14:03 1995 From: selina at ans.net (Selina Priestley) Date: Thu, 04 May 1995 10:14:03 -0400 Subject: Andrew: BGP->Route object translator In-Reply-To: Message from of Thu May 4,1995 9:57 EDT <199505041357.JAA01675@lovefm.reston.mci.net> Message-ID: <199505041414.AA03770@interlock.ans.net> Yes, I'd much prefer to have connectivity arranged for my customers *before* we brought them up, but just to play Devil's Advocate, if providers do this every other day and diff the new data against the last data, the new routes will eventually get there, and a lot of unrouted gunk won't (maybe we won't have half the routes in the dbase unrouted anymore). If they wind up sending everything every day, we might be able to use this data to delete routes in the dbase that haven't been found in a long while too (a big window obviously - months). It seems to me that once you've got a route in your table that isn't heard elsewhere, you've got a problem. But if you're telling your customers that they'll have connectivity to everywhere x days after they're all set up, and the level of expectation changes, it might just become a feature. Selina > I really think this is the wrong approach of generating your route > entries from your routing tables. Any connection which is down will > not be in the bgp routing tables. If Andrew or others really dont have > a database of their routes. Then they can grab all the cisco configs and > depending on whether they redist static or not grep all the network > lines or ip route lines. Grabbing a snap-shot of a BGP RiB is bound to > miss things. > > --Tony. > > Curtis Villamizar writes: > * > * In message <199505032118.AA26055 at cat.isi.edu>, Cengiz Alaettinoglu writes: > * > > * > Curtis Villamizar (curtis at ans.net) on May 3: > * > > > This needs to be refined slightly. The "show ip bgp" output contains > * > > > an AS path. The last entry in the AS path will be the home AS. > * > > > Andrew is putting in AS701 for every route he knows which would be > * > ************************ > * > > > incorrect for most routes. > * > > * > I know nothing about cisco's show ip bgp, but I assume in > * > show ip bgp reg ^$ > * > reg ^$ matches the as path, i.e. empty as paths, i.e. the routes that > * > he learned from IGP. > * > > * > Is this right? In which case, he is the true home as for those routes. > * > > * > Cengiz > * > * > * I missed that. I guess Andrew had taken the AS into account. This > * doesn't help his attached customers with their own AS. Now all we > * need is the machinery in the shell program to avoid resubmitting the > * same thing every day and to withdraw the route (resubmit the route > * object as withdrawn) when components haven't been seen in a very long > * time (for some value of very long). I think Steve agreed to let me > * write this and make it available since it shouldn't take long at all. > * I'll probably get to it before May 8. > * > * Curtis -------- Logged at Thu May 4 18:45:00 MET DST 1995 --------- From cengiz at ISI.EDU Thu May 4 18:44:57 1995 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Thu, 4 May 1995 09:44:57 -0700 Subject: Andrew: BGP->Route object translator In-Reply-To: <199505041456.KAA28830@home.merit.edu> References: <199505041456.KAA28830@home.merit.edu> Message-ID: <199505041644.AA29605@cat.isi.edu> Dale S. Johnson (dsj at merit.edu) on May 4: > Or: should andrew have his own "source: ALTERNET". He doesn't have > to run 181 at all; all he would have to do is run that script into > a file once per day or more, and put the file up for FTP. The rest > of the IRR would then pick that file up and post it through their > whois servers. > > Sprint would quickly follow suit, I think. > > The RADB may have little to do but to be a collator and publisher of ISP's > .db files, but that is sort of the direction we have all proposed. > > --Dale Interesting idea. I was thinking along the same lines. Dividing IRR into public and private registries. Private registries run their own systems but may not provide public access to this data such as whois, and not necessarily have copies of other databases. They may not be running Ripe-181 systems, but are able to convert to it from their internal format (like Andrew). Public sites would be responsible for a set of private registries and collect their data and the data from the other public registries. Public sites would also provide services on this data, such as whois, making it available for ftp. This is probably a good idea if the number of registries increases beyond a point and is a first step to an hierarchical registry organization. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California http://www.isi.edu/div7/people/cengiz.home -------- Logged at Thu May 4 19:11:43 MET DST 1995 --------- From curtis at ans.net Thu May 4 18:35:21 1995 From: curtis at ans.net (Curtis Villamizar) Date: Thu, 04 May 1995 12:35:21 -0400 Subject: Andrew: BGP->Route object translator In-Reply-To: Your message of "Thu, 04 May 1995 09:57:21 EDT." <199505041357.JAA01675@lovefm.reston.mci.net> Message-ID: <199505041636.MAA11317@curtis.ansremote.com> In message <199505041357.JAA01675 at lovefm.reston.mci.net>, Tony Bates writes: > I really think this is the wrong approach of generating your route > entries from your routing tables. Any connection which is down will > not be in the bgp routing tables. If Andrew or others really dont have > a database of their routes. Then they can grab all the cisco configs and > depending on whether they redist static or not grep all the network > lines or ip route lines. Grabbing a snap-shot of a BGP RiB is bound to > miss things. > > --Tony. Tony, There is no intention to remove anything if the connection is down for a short period of time. If a route is not seen (the connection is down?) for 3 month continuously, then I think marking it as withdrawn is a safe move. If wee miss a route the first day their service is turned up, because they were down, we'll get them the next day. I don't see why this would be a problem. Curtis -------- Logged at Thu May 4 19:54:58 MET DST 1995 --------- From curtis at ans.net Thu May 4 19:51:24 1995 From: curtis at ans.net (Curtis Villamizar) Date: Thu, 04 May 1995 13:51:24 -0400 Subject: a few patches to dbase Message-ID: <199505041752.NAA11434@curtis.ansremote.com> Dear Keepers of the Source, As you may have heard, we have a large and ugly machine generated aut-num object which allows us to transition from AS690 advisories without changing the way routing works for any network. While we are not particularly fond of this 15,000 line RIPE object, it does make a gradual transition possible. We hope to work with providers to reduce the policy descriptions to something manageable. This aut-num created a big performance problem for most of the RIPE tools. On a 486/33 (my home machine) dbupdate could not load this object in 12 hours. With just 2 fixes, it is down to under 8 minutes. I think these patches are worth putting in the base distribution. I have some small patches to the following files. Also, I modified the Makefile and created a config.generic file and have the Makefile doing substitutions to elinate a lot of editing. cleandb.pl.patch.950504 enparse.pl.patch.950504 dbopen.pl.patch.950504 misc.pl.patch.950504 dbupdate.pl.patch.950504 syntax.pl.patch.950504 The patches are below. I'll send the files Makefile, Makefile.generic and config.generic in a separate message in case anyone wants them. Curtis -------------------------------- Notes on the patches: cleandb.pl - Doesn't fail if thmp directory already exists. If it does fail it tells you the name of the directory it couldn't create. dbopen.pl - Some more debuging info if opt_V is set. dbupdate.pl - added "-m mail-address" option. Fixed Getopts line. - minor debugging additions if opt_V is set enparse.pl - small change, major performance improvement, read the comment - minor debugging additions if opt_V is set misc.pl - speedup to isnetlist, not sure if it helps much - added update_the_time function for some performance debugging syntax.pl - debugging added if opt_V set to track progress and performance - moved "$object{$itmp} =~ " lines out of ineer loops, for an aut-num with 10,000+ [inter]as-{in,out} lines, this avoids evaluating this costly statement 10,000+ times. Goes faster. Feel free to toss the debugging stuff if you feel it is ugly or excessive. It has no effect if you don't put -V on the command line. -------------------------------- *** cleandb.pl.orig Thu May 4 03:51:45 1995 --- cleandb.pl Thu May 4 03:57:21 1995 *************** *** 418,426 **** $NEWDIR = "$ARGV[0].new"; $NEWDB = "$NEWDIR/$fileext"; ! if (!mkdir($NEWDIR, 0750)) { &dbclose(*i); ! die "Failed to create temporary directory: $!"; } if ($opt_v) { --- 418,426 ---- $NEWDIR = "$ARGV[0].new"; $NEWDB = "$NEWDIR/$fileext"; ! if ((! -d $NEWDIR) && !mkdir($NEWDIR, 0750)) { &dbclose(*i); ! die "Failed to create temporary directory \"$NEWDIR\": $!"; } if ($opt_v) { *** dbopen.pl.orig Mon Apr 24 10:51:19 1995 --- dbopen.pl Wed May 3 12:52:10 1995 *************** *** 24,30 **** --- 24,32 ---- if ($TYPE{$source} eq "SPLIT") { $name .= ".".$type; } + print STDERR " $source -> $DBFILE{$source} + $type ->\n\t" if $opt_V; } + print STDERR "dbopen: $name\n" if $opt_V; if ($write) { *** dbupdate.pl.orig Mon Apr 24 10:51:19 1995 --- dbupdate.pl Thu May 4 12:09:54 1995 *************** *** 35,40 **** --- 35,42 ---- # -l logfile - log output to file in stead of STDOUT # -n logtext - Network update - use logtext in acklog file # -v - verbose output (LONGACK) + # -m mail-address - treat as mail from mail-address for the purpose + # of MAIL-FROM style authorization # -M - treat input file (or STDIN) as mail and compose # and send ack mail back # -A - assume "assign" mode, only add will be allowed *************** *** 46,52 **** # -F - Do fast update without mail and other stuff # -S - Do only syntax check - Not implemented ! &Getopts('ln:vMAHVFS'); # Need this below for running perl in tainted mode. --- 48,59 ---- # -F - Do fast update without mail and other stuff # -S - Do only syntax check - Not implemented ! &Getopts("l:m:n:vMAHVFS"); ! ! if ($opt_m) { ! $FROM = "$opt_m"; ! print STDERR "Treating as mail from $FROM\n" if ($opt_V) ! } # Need this below for running perl in tainted mode. *************** *** 323,328 **** --- 330,336 ---- # Not too good, probably permission problem # if this is given as output ... + print STDERR "dbupdate - open database failed\n" if $opt_V; &adderror(*entry, "Failed to open DB file: $!"); &adderror(*entry, "Please check the \"source:\" value"); &adderror(*entry, "Contact <$HUMAILBOX> if source seems ok"); *** enparse.pl.orig Mon Apr 24 10:51:19 1995 --- enparse.pl Thu May 4 02:05:00 1995 *************** *** 32,46 **** --- 32,80 ---- require "defines.pl"; require "adderror.pl"; + # + # readsomething_xfer is just here to assist readsomething. + # An eval is used to load indexed arrays while readsomething + # runs. When it is done, a join is done loading the multiple + # lines into the entry associative array. readsomething_xfer + # does this join and gets rid of the indexed arrays. This is + # _much_ faster for long objects like the AS690 aut-num, reducing + # an operation that took over an hour down to about 2 minutes. + # + + sub readsomething_xfer { + if ($opt_V) { + &update_the_time(); + print STDERR sprintf("readsomething completed %5d lines at %s\n", + $readsomething_counter, $the_time); + } + foreach $tag ( keys %tags ) { + eval "\$entry{\"$tag\"} = join(\'\n\', \@readsomething_$tag);" + . "undef \@readsomething_$tag;"; + } + if ($opt_V) { + &update_the_time(); + print STDERR "readsomething completed xfer at $the_time\n"; + } + } + sub readsomething { local($file) = @_; local($inentry) = $NOK; local($tag) = ""; local(%entry) = (); + local($readsomething_counter) = 0; + local(%tags) = (); while (<$file>) { + if ($opt_V && (((++$readsomething_counter) % 1000) == 0)) { + &update_the_time(); + print STDERR sprintf("readsomething completed %5d lines at %s\n", + $readsomething_counter, $the_time); + } + s/^\s*//; s/\s*$//; s/\n*$//; *************** *** 55,64 **** 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*(.*)/) { --- 89,96 ---- if (/^\*..:\s*(.*)/) { $inentry = $OK; $tag = substr($_, 1, 2); ! ++$tags{$tag}; ! eval "\$readsomething_$tag\[\$\#readsomething_$tag+1\] = \"$1\";"; next; } if (/^([a-z\-A-Z_]+)\s*:\s*(.*)/) { *************** *** 66,85 **** $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; --- 98,117 ---- $tag = $1; $tag =~ tr/A-Z/a-z/; $tag = $ATTR{$tag} if $ATTR{$tag}; ! ++$tags{$tag}; ! eval "\$readsomething_$tag\[\$\#readsomething_$tag+1\] = \"$2\";"; next; } if (/^.*$/) { next if $inentry == $NOK; + &readsomething_xfer(); $CUROBJTYPE = &entype(*entry); return ($inentry,%entry); } } + &readsomething_xfer(); $CUROBJTYPE = &entype(*entry); return ($inentry, %entry) if ($inentry); return $EOF; *************** *** 214,220 **** local($stat); local($hasdelete); ! print STDERR "enparse - reading something\n" if $opt_V; ($stat, %entry) = &readsomething($file); --- 246,255 ---- local($stat); local($hasdelete); ! if ($opt_V) { ! &update_the_time(); ! print STDERR "enparse - reading something at $the_time\n"; ! } ($stat, %entry) = &readsomething($file); *** misc.pl.orig Mon Apr 24 10:51:20 1995 --- misc.pl Wed May 3 15:40:08 1995 *************** *** 187,197 **** return 1; } # sub isnetlist { ! local($str) = @_; ! local($NET) = "\\d+\\.\\d+\\.\\d+\\.\\d+\\/\\d+"; ! return 0 if $str !~ /^\s*{\s*$NET\s*(\s*,\s*$NET\s*)*}\s*$/; return 1; } # --- 187,197 ---- return 1; } + # local($str) and local($NET) slows things down a lot + $__isnetlist__NET = "\\d+\\.\\d+\\.\\d+\\.\\d+\\/\\d+"; # sub isnetlist { ! return 0 if $_[0] !~ /^\s*{\s*$__isnetlist__NET\s*(\s*,\s*$__isnetlist__NET\s*)*}\s*$/; return 1; } # *************** *** 420,425 **** --- 420,435 ---- return 0 if $str =~ /[{}]/; return 1; } + + # + # getting a time stamp for performance logging + # + + sub update_the_time { + $the_time = `/bin/date +%H:%M:%S`; + $the_time =~ s/\n//; + } + # # exclusive locking # *** syntax.pl.orig Mon Apr 24 10:51:21 1995 --- syntax.pl Thu May 4 03:54:20 1995 *************** *** 77,86 **** local(*object) = @_; local($rtcode) =$O_OK; local($itmp, $val, $msg); ! print STDERR "checksyntax - called\n" if $opt_V; foreach $itmp (keys %object) { if ($object{$itmp} eq "") { ($val, $msg) = &dosyntax($itmp, "", *object); if ($val == $O_WARNING) { --- 77,96 ---- local(*object) = @_; local($rtcode) =$O_OK; local($itmp, $val, $msg); + local($checksyntax_counter) = 0; ! if ($opt_V) { ! &update_the_time(); ! print STDERR "checksyntax - called at $the_time\n"; ! } foreach $itmp (keys %object) { + if ($opt_V) { + &update_the_time(); + ++$checksyntax_counter; + print STDERR sprintf("checksyntax: item #%d \"%s\" at %s\n", + $checksyntax_counter, $itmp, $the_time); + } if ($object{$itmp} eq "") { ($val, $msg) = &dosyntax($itmp, "", *object); if ($val == $O_WARNING) { *************** *** 107,112 **** --- 117,124 ---- local($j,$k) = 0; local(%linewrap) = (); local(%newval) = (); + print STDERR "Checking syntax in \"$itmp\" " + . ($#array + 1) . " lines\n" if $opt_V; foreach $j (0..$#array) { # # as-in lines *************** *** 123,129 **** } else { ($peer, $wt, $pol) = split(/\s+/, $array[$j], 3); } - $object{$itmp} =~ s/from\s+|accept\s+//g; # # as-out lines # --- 135,140 ---- *************** *** 141,147 **** ($peer, $pol) = split(/\s+/, $array[$j], 2); $wt = 1; } - $object{$itmp} =~ s/to\s+|announce\s+//g; # # interas-in lines # --- 152,157 ---- *************** *** 165,171 **** split(/\s+/, $array[$j], 5); $wt = "$lid-$rid-$cost"; } - $object{$itmp} =~ s/from\s+|accept\s+//g; # # interas-out lines # --- 175,180 ---- *************** *** 206,212 **** $wt = "$lid-$rid"; } } - $object{$itmp} =~ s/to\s+|announce\s+//g; } # # Now finally check if the lines are the same. --- 215,220 ---- *************** *** 222,227 **** --- 230,248 ---- } $linewrap{"$peer:$wt"} = 1; } + print STDERR "Rebuilding \"$itmp\"\n" if $opt_V; + if($FLAG eq "ai") { + $object{$itmp} =~ s/from\s+|accept\s+//g; + } + if ($FLAG eq "ao") { + $object{$itmp} =~ s/to\s+|announce\s+//g; + } + if ($FLAG eq "it") { + $object{$itmp} =~ s/from\s+|accept\s+//g; + } + if ($FLAG eq "io") { + $object{$itmp} =~ s/to\s+|announce\s+//g; + } # # Now loop through the value and syntax check the re-built line # *************** *** 238,247 **** --- 259,270 ---- } } } + print STDERR "Finished Preprocessing \"$itmp\"\n" if $opt_V; # # Otherwise just split on newlines and pass line by line to syntax checker # } else { + print STDERR "Spliting \"$itmp\"\n" if $opt_V; foreach $j (split(/\n/, $object{$itmp})) { local($val, $msg) = &dosyntax($itmp, $j, *object); if ($val == $O_WARNING) { *************** *** 253,258 **** --- 276,282 ---- $rtcode = $O_ERROR; } } + print STDERR "Finished Preprocessing \"$itmp\"\n" if $opt_V; } } } *************** *** 264,269 **** --- 288,295 ---- local($key, $value, *object) = @_; + print STDERR "dosyntax: \"$key\"\n" if $opt_V; + # # THE FIRST SET OF ATTRIBUTES MAY NOT HAVE AN EMPTY VALUE IF THEY EXIST # *************** *** 432,437 **** --- 458,464 ---- "is not a routing policy KEYWORD"; } } + print STDERR "dosyntax: done \"$key\"\n" if $opt_V; return; } # *************** *** 1729,1733 **** --- 1756,1762 ---- if ($key eq "uw") { return; } + + print STDERR "dosyntax: DONE with \"$key\"\n" if $opt_V; } 1; -------- Logged at Thu May 4 20:10:45 MET DST 1995 --------- From GeertJan.deGroot at ripe.net Thu May 4 20:10:42 1995 From: GeertJan.deGroot at ripe.net (Geert Jan de Groot) Date: Thu, 04 May 1995 20:10:42 +0200 Subject: Small fix to whoisd.pl In-Reply-To: Your message of "Wed, 03 May 1995 14:56:52 EDT." <199505031856.OAA03302@home.merit.edu> Message-ID: <9505041810.AA04984@ncc.ripe.net> On Wed, 3 May 1995 14:56:52 -0400 (EDT) Laurent Joncheray wrote: > It is an old issue but... > why don't you port whoisd to be called from [x]inetd. So you > won't need any networking hack. It has been like that on radb.ra.net, > and it seems to be fine. > Laurent > PS: lot of advantages: do not need to run as root, IP filtering, logging, I just did some measurements; I did a 10 queries to the standard whois service, and one running via inetd, and found: direct: 25.25s inetd: 5.00s direct whois is 5 times faster. This is averaged over a number of measurements on the same machine, and local (2 hops ether) network. This is probably why httpd servers want to run standalone, instead of via inetd. Note that I needed to hack whoisd to make it work under inetd (David whispered something about a fix being available from Merit, but I didn't have it so I butchered the code to do this; I'm not a perl programmer) The big difference is probably caused by perl initializing, as it 'compiles' the perl script every time it starts; some debug-prints made that quite clear. It seems that we can have either a safe whois, or a fast whois; I can think of a port relay program (yech), or a kernel hack to unprivilege port 43 (that's what I would do). Geert Jan -------- Logged at Thu May 4 23:37:40 MET DST 1995 --------- From dsj at merit.edu Thu May 4 23:37:36 1995 From: dsj at merit.edu (Dale S. Johnson) Date: Thu, 4 May 1995 17:37:36 -0400 Subject: Small fix to whoisd.pl Message-ID: <199505042137.RAA15977@home.merit.edu> Geert Jan, > On Wed, 3 May 1995 14:56:52 -0400 (EDT) Laurent Joncheray wrote: > > It is an old issue but... > > why don't you port whoisd to be called from [x]inetd. So you > > won't need any networking hack. It has been like that on radb.ra.net, > > and it seems to be fine. > > Laurent > > PS: lot of advantages: do not need to run as root, IP filtering, logging, > > I just did some measurements; I did a 10 queries to the standard whois > service, and one running via inetd, and found: > direct: 25.25s > inetd: 5.00s > direct whois is 5 times faster. > > This is averaged over a number of measurements on the same machine, > and local (2 hops ether) network. > > This is probably why httpd servers want to run standalone, instead of > via inetd. Note that I needed to hack whoisd to make it work under > inetd (David whispered something about a fix being available from > Merit, but I didn't have it so I butchered the code to do this; > I'm not a perl programmer) > > The big difference is probably caused by perl initializing, as it > 'compiles' the perl script every time it starts; some debug-prints > made that quite clear. Depending on what the nature of this initialization is, there may be a chance here to use the world's most bizarre sanctioned hack. If the initialization is reading info from files that changes occasionally, then only the current solutions will work. If it is just doing internal table building or such, consider my all-time favorite bizarre command: DUMP (p 139, Programming Perl) This function causes an immediate core dump. Primarily this is so that you can use the undump program to turn your core dump into an executable binary after having initialized all your variables at the beginning of the program. ...Think of it as a goto with an intervening core dumpand reincaration. --Anonymous -------- Logged at Thu May 4 23:53:07 MET DST 1995 --------- From curtis at ans.net Thu May 4 23:49:02 1995 From: curtis at ans.net (Curtis Villamizar) Date: Thu, 04 May 1995 17:49:02 -0400 Subject: usefull little program Message-ID: <199505042149.RAA18256@curtis.ansremote.com> BTW- The following is useful for figuring out what getopts is doing with your argument string. For example: perl check-getopts.perl "ln:vMAHVFS" -l filename String = "ln:vMAHVFS" OPT l = "1" Shows why dbupdate -l would create a logfile named "1" and get upset about the filename argument. Curtis #!/usr/local/bin/perl require "getopts.pl"; $str = $ARGV[0]; shift; &Getopts("$str"); print "String = \"$str\"\n"; foreach $opt ('a'..'z','A'..'Z') { eval "if (defined(\$opt_$opt))" . " { print \"OPT \$opt = \\\"\$opt_$opt\\\"\n\" }"; } -------- Logged at Thu May 4 23:53:42 MET DST 1995 --------- From curtis at ans.net Thu May 4 23:36:27 1995 From: curtis at ans.net (Curtis Villamizar) Date: Thu, 04 May 1995 17:36:27 -0400 Subject: better Makefile (LONG) Message-ID: <199505042137.RAA12133@curtis.ansremote.com> Hi, It seems that a fair amount of editing of the conf file is needed and most of it is fairly mechanical. I just put together a Makefile, Makefile.generic, and Makefile.config. You are supposed to be able to just edit the first four non-comment lines in the Makefile and go. A config.`hostname` file is generated which you can then edit further if you need to. There is also a topdir.`hostname` file that can be used to put stuff somewhere other than the current directory, though that too could have been a variable in the Makefile (the directory layout on my home machine that I often test on is different from the AIX target that ANS will be using. Thats why the file.). Just put the target directory name on one line in the topdir.`hostname` file. Our AIX system needed a minor change in src/Makefile. Below is: src/Makefile.patch.950504 Makefile Makefile.generic config.generic Please dispose of unused bits in a proper recepticle. :-) Curtis BTW- there is still a bug in cleandb on BSDI that I have worked around for the moment but I will send a patch later. The same problem may also impact netdbm. #!/bin/sh # This is a shell archive (produced by GNU sharutils 4.1). # To extract the files from this archive, save it to some FILE, remove # everything before the `!/bin/sh' line above, then type `sh FILE'. # # Made on 1995-05-04 17:34 EDT by . # Source directory was `/home/riverford/curtis/ans/radb/dbase/dbase.dist'. # # Existing files will *not* be overwritten unless `-c' is specified. # # This shar contains: # length mode name # ------ ---------- ------------------------------------------ # 462 -r--r----- src/Makefile.patch.950504 # 2199 -rw-r----- Makefile # 1539 -rw-r----- Makefile.generic # 21067 -rw-r----- config.generic # touch -am 1231235999 $$.touch >/dev/null 2>&1 if test ! -f 1231235999 && test -f $$.touch; then shar_touch=touch else shar_touch=: echo echo 'WARNING: not restoring timestamps. Consider getting and' echo "installing GNU \`touch', distributed in GNU File Utilities..." echo fi rm -f 1231235999 $$.touch # # ============= src/Makefile.patch.950504 ============== if test ! -d 'src'; then echo 'x - creating directory src' mkdir 'src' fi if test -f 'src/Makefile.patch.950504' && test X"$1" != X"-c"; then echo 'x - skipping src/Makefile.patch.950504 (file already exists)' else shar: Saving src/Makefile.patch.950504 (text) echo 'x - extracting src/Makefile.patch.950504 (text)' sed 's/^X//' << 'SHAR_EOF' > 'src/Makefile.patch.950504' && *** Makefile.orig Mon Apr 24 10:51:22 1995 --- Makefile Thu May 4 14:26:54 1995 *************** *** 95,102 **** X chmod $(BINMODE) $@ X X X install: $(PROGS) $(LIBS) ! install -m $(BINMODE) $(PROGS) $(BINDIR) X X X clean: --- 95,105 ---- X chmod $(BINMODE) $@ X X + # some install programs are challenged (AIX) X install: $(PROGS) $(LIBS) ! for prog in $(PROGS) ; do \ ! install -c -m $(BINMODE) $$prog $(BINDIR)/$$prog ; \ ! done X X X clean: SHAR_EOF $shar_touch -am 0504165395 'src/Makefile.patch.950504' && chmod 0440 'src/Makefile.patch.950504' || echo 'restore of src/Makefile.patch.950504 failed' shar_count="`wc -c < 'src/Makefile.patch.950504'`" test 462 -eq "$shar_count" || echo "src/Makefile.patch.950504: original size 462, current size $shar_count" fi # ============= Makefile ============== if test -f 'Makefile' && test X"$1" != X"-c"; then echo 'x - skipping Makefile (file already exists)' else shar: Saving Makefile (text) echo 'x - extracting Makefile (text)' sed 's/^X//' << 'SHAR_EOF' > 'Makefile' && # # $Id$ # X # Where is your perl executable ? X PERL= /usr/local/bin/perl X MAILDOM= ans.net ORGTAG= ans ORGFULLNAME= ANS Routing Registry X # You shouldn't have to modify anything below. Modify # topdir.${HOSTNAME} if your target isn't the current directory X SHELL= /bin/sh X SRCDIR= src MFILE= Makefile MGENERIC= Makefile.generic X MAKE= make -f ${MGENERIC} PERL=${PERL} \ X MAILDOM=${MAILDOM} ORGTAG=${ORGTAG} \ X ORGFULLNAME="${ORGFULLNAME}" X all: X @if [ "x." = "x.${HOSTNAME}" ] ; then \ X echo make HOSTNAME=`hostname` $@ ; \ X make HOSTNAME=`hostname` $@ ; \ X elif [ -f topdir.${HOSTNAME} ] ; then \ X echo ${MAKE} TOPDIR=`cat topdir.${HOSTNAME}` $@ ; \ X ${MAKE} TOPDIR=`cat topdir.${HOSTNAME}` $@ ; \ X else \ X echo ${MAKE} TOPDIR=`pwd` $@ ; \ X ${MAKE} TOPDIR=`pwd` $@ ; \ X fi X install: X @if [ "x." = "x.${HOSTNAME}" ] ; then \ X echo make HOSTNAME=`hostname` $@ ; \ X make HOSTNAME=`hostname` $@ ; \ X elif [ -f topdir.${HOSTNAME} ] ; then \ X echo ${MAKE} TOPDIR=`cat topdir.${HOSTNAME}` $@ ; \ X ${MAKE} TOPDIR=`cat topdir.${HOSTNAME}` $@ ; \ X else \ X echo ${MAKE} TOPDIR=`pwd` $@ ; \ X ${MAKE} TOPDIR=`pwd` $@ ; \ X fi X config: X @if [ "x." = "x.${HOSTNAME}" ] ; then \ X echo make HOSTNAME=`hostname` $@ ; \ X make HOSTNAME=`hostname` $@ ; \ X elif [ -f topdir.${HOSTNAME} ] ; then \ X echo ${MAKE} TOPDIR=`cat topdir.${HOSTNAME}` $@ ; \ X ${MAKE} TOPDIR=`cat topdir.${HOSTNAME}` $@ ; \ X else \ X echo ${MAKE} TOPDIR=`pwd` $@ ; \ X ${MAKE} TOPDIR=`pwd` $@ ; \ X fi X clean: X @if [ "x." = "x.${HOSTNAME}" ] ; then \ X echo make HOSTNAME=`hostname` $@ ; \ X make HOSTNAME=`hostname` $@ ; \ X elif [ -f topdir.${HOSTNAME} ] ; then \ X echo ${MAKE} TOPDIR=`cat topdir.${HOSTNAME}` $@ ; \ X ${MAKE} TOPDIR=`cat topdir.${HOSTNAME}` $@ ; \ X else \ X echo ${MAKE} TOPDIR=`pwd` $@ ; \ X ${MAKE} TOPDIR=`pwd` $@ ; \ X fi X uninstall: X @if [ "x." = "x.${HOSTNAME}" ] ; then \ X echo make HOSTNAME=`hostname` $@ ; \ X make HOSTNAME=`hostname` $@ ; \ X elif [ -f topdir.${HOSTNAME} ] ; then \ X echo ${MAKE} TOPDIR=`cat topdir.${HOSTNAME}` $@ ; \ X ${MAKE} TOPDIR=`cat topdir.${HOSTNAME}` $@ ; \ X else \ X echo ${MAKE} TOPDIR=`pwd` $@ ; \ X ${MAKE} TOPDIR=`pwd` $@ ; \ X fi SHAR_EOF $shar_touch -am 0504140495 'Makefile' && chmod 0640 'Makefile' || echo 'restore of Makefile failed' shar_count="`wc -c < 'Makefile'`" test 2199 -eq "$shar_count" || echo "Makefile: original size 2199, current size $shar_count" fi # ============= Makefile.generic ============== if test -f 'Makefile.generic' && test X"$1" != X"-c"; then echo 'x - skipping Makefile.generic (file already exists)' else shar: Saving Makefile.generic (text) echo 'x - extracting Makefile.generic (text)' sed 's/^X//' << 'SHAR_EOF' > 'Makefile.generic' && # # $Id$ # # based on: # RCSfile: Makefile.dist1,v # Revision: 0.11 # Author: marten # Date: 1993/08/02 12:59:46 # X default: X @echo "Don't use Makefile.generic, use the regular Makefile" X # # inherit TOPDIR and PERL from the previous Makefile # # TOPDIR= /home/riverford/curtis/ans/radb/dbase # PERL= /usr/local/bin/perl # X LIBDIR= $(TOPDIR)/lib BINDIR= $(TOPDIR)/bin X # This is the configuration file that will be opened when the environment # variable $RIPEDBCNF is not set X DEFCONFIG= $(TOPDIR)/config.${HOSTNAME} X config.${HOSTNAME}: config.generic X sed < config.generic > config.${HOSTNAME} \ X -e 's,$${TOPDIR},${TOPDIR},g' \ X -e 's,$${MAILDOM},${MAILDOM},g' \ X -e 's,$${ORGTAG},${ORGTAG},g' \ X -e 's,$${ORGFULLNAME},${ORGFULLNAME},g' X $(DEFCONFIG): config.${HOSTNAME} X cp config.${HOSTNAME} $(DEFCONFIG) X config: config.${HOSTNAME} X # # YOU ARE NOT SUPPOSED TO MAKE CHANGES TO ANYTHING BELOW # X SRCDIR= src MFILE= Makefile X MAKE= make LIBDIR=$(LIBDIR) BINDIR=$(BINDIR) \ X DEFCONFIG=$(DEFCONFIG) PERL=$(PERL) X X all: $(SRCDIR)/$(MFILE) $(MFILE) config.${HOSTNAME} X -mkdir $(LIBDIR) X (cd $(SRCDIR); $(MAKE) all) X X install: $(SRCDIR)/$(MFILE) $(MFILE) $(DEFCONFIG) X -mkdir $(BINDIR) X -mkdir $(LIBDIR) X -mkdir $(TOPDIR)/tmp X -mkdir $(TOPDIR)/etc X -mkdir $(TOPDIR)/data X (cd $(SRCDIR); $(MAKE) install) X sed -e 's:PERL:$(PERL):' < whois.pl > $(BINDIR)/whois X chmod 755 $(BINDIR)/whois X X clean: $(SRCDIR)/$(MFILE) $(MFILE) X (cd $(SRCDIR); $(MAKE) clean) X X uninstall: $(SRCDIR)/$(MFILE) $(MFILE) X (cd $(SRCDIR); $(MAKE) uninstall) SHAR_EOF $shar_touch -am 0504141595 'Makefile.generic' && chmod 0640 'Makefile.generic' || echo 'restore of Makefile.generic failed' shar_count="`wc -c < 'Makefile.generic'`" test 1539 -eq "$shar_count" || echo "Makefile.generic: original size 1539, current size $shar_count" fi # ============= config.generic ============== if test -f 'config.generic' && test X"$1" != X"-c"; then echo 'x - skipping config.generic (file already exists)' else shar: Saving config.generic (text) echo 'x - extracting config.generic (text)' sed 's/^X//' << 'SHAR_EOF' > 'config.generic' && ############################################################################# # # %I% %D% # # This is the RIPE database software main configuration file. # Almost all tools that manage the databases use some parts of this # config file, most of them do not use everything. # ############################################################################# # # Alter the database names below for your local environment # ############################################################################# X # default database to do lookups in X DEFLOOK ${ORGTAG_UC} X # if all databases are selected X ALLLOOK ${ORGTAG_UC} X # RIPE uses- #ALLLOOK RIPE INTERNIC ALTERNET NCC-AS-LIST X # Filenames associated with sources, more than one source can point to a file # Make sure that all the databases you define below are available ... # The optional 3rd argument SPLIT says that all object types live in seperate # files, and the file name mentioned here is a basename for all these # seperate files. The real files will have the two letter for the object # they contain attached to them. A mix and match of SPLIT and non # split databases works fine. X DBFILE ${ORGTAG_UC} ${TOPDIR}/data/${ORGTAG}.db SPLIT DBFILE RADB ${TOPDIR}/data/radb.db X # RIPE uses- #DBFILE ${ORGTAG_UC} ${TOPDIR}/data/${ORGTAG}/${ORGTAG}.db SPLIT #DBFILE MERIT ${TOPDIR}/data/nsf/nsf.db #DBFILE NIC ${TOPDIR}/data/nsf/nic.db #DBFILE INTERNIC ${TOPDIR}/data/internic/internic.db #DBFILE NCC-AS-LIST ${TOPDIR}/data/asn/asn.db #DBFILE ALTERNET ${TOPDIR}/data/alter/alter.db X ############################################################################# # # Some systems have a different path for sendmail. # Also note the sendmail.cf trusted user warning below. # ############################################################################# X # MAILCMD is the command into which a composed e-mail is given as standard # input, to be send as mail. The message piped into this command has ALL # the necessary mail header to process the mail: # From: # To: # Subject: # The mail command should take the recipients from the actual message. # Using sendmail it will be executed as: /usr/lib/sendmail -t < "messagefile" # (default: /usr/lib/sendmail -t) # # NOTE: # -f${ORGTAG}-dbm makes ${ORGTAG}-dbm the trusted user that will appear # on the envelope. Bounces will go to this address. If you do not specify # this, sendmail will send bounces straight back to the automatic # mailbox, where it will bounce again, and again, .... # User has to be a trusted user, T in sendmail.cf. X MAILCMD /usr/lib/sendmail -f${ORGTAG}-dbm -t X ############################################################################# # # This section is the mail reply boilerplate. It should not need changes. # ############################################################################# X # DEFMAIL is the mailbox used when no mail notifications or acknowledgements # both as to and from address in various places. # IT MUST NOT BE THE AUTOMATIC MAILBOX!!!! X DEFMAIL ${ORGTAG}-dbm@${MAILDOM} X # HUMAILBOX is a human looked at mailbox, used for forwarding # special objects. IT MUST NOT BE THE AUTOMATIC MAILBOX!!!! # It can be used in mail messges as explained in MAILTXT below. X HUMAILBOX ${ORGTAG}-dbm@${MAILDOM} X # What to display if no match was found X NOMATCH No entries found for the selected source(s). NOMATCH NOMATCH If you would like to search on arbitrary strings, NOMATCH please use the WAIS server on wais.${MAILDOM} or NOMATCH telnet to info.${MAILDOM} for a WAIS client interface. NOMATCH The WAIS database name is ${ORGTAG}-database. NOMATCH This will only work for ${ORGTAG_UC} data. X # What to display if we got TOOMANY hits back X TOOMANY The index search returned too many hits. TOOMANY Please refine your search key. X # The MAILTXT is the text that comes right after the headers in an email ack # send by "dbupdate" when processing an email update (-M flag). # In this text you can use 4 variables that will be expanded to the real # values in the ack: # # $FROM = "Reply-To:" or "From:" address in mail being processed # $SUBJECT = "Subject:" field ,, ,, # $MDATE = "Date:" field ,, ,, # $MSGID = "Msg-Id:" field ,, ,, X MAILTXT MAILTXT Your e-mail: MAILTXT MAILTXT > From: $FROM MAILTXT > Subject: $SUBJECT MAILTXT > Date: $MDATE MAILTXT > Msg-Id: $MSGID MAILTXT MAILTXT has been processed by the automatic update procedure MAILTXT at the ${ORGFULLNAME}. MAILTXT Diagnostic output follows: MAILTXT MAILTXT ------------------------------------------------------------------------ X # MHEADER The complete mailheader for the ack mail, you can include any # mail header field, EXCEPT for the "To:" field which is added inside the # ack sending program. Again you can use the 4 variables as specified in # MAILTXT X MHEADER From: ${ORGTAG_UC} Database Management <${ORGTAG}-dbm@${MAILDOM}> MHEADER Subject: Re: $SUBJECT MHEADER Reply-To: ${ORGTAG}-dbm@${MAILDOM} MHEADER Precedence: bulk X # ACKERR is the message that will be displayed when errors or warnings were # found in an update. X ACKERR ACKERR Objects that just generated a WARNING have been updated as shown. ACKERR ACKERR Objects that generated an *ERROR* have NOT been updated as requested. ACKERR Please re-submit corrected objects. X # ACKOK is message displayed when no error/warnings were found in an update X ACKOK ACKOK No error/warnings were found in your database update. Congratulations. X # Signature on the acknowledgement X ACKSIG ------------------------------------------------------------------------ ACKSIG ACKSIG Please use ACKSIG ACKSIG instead of <${ORGTAG}-dbm@${MAILDOM}> and ACKSIG instead of ACKSIG ACKSIG for fast turnaround times on all but guarded objects. ACKSIG ACKSIG If you have any question about an error or warning message, please ACKSIG contact <${ORGTAG}-dbm@${MAILDOM}>. ACKSIG ACKSIG Sincerely Yours, ACKSIG ACKSIG ${ORGTAG_UC} Database Maintenance Department (Automatic Section) X # NOTITXT Notification text used in notification messages. # Same variables as in MAILTXT can be used here. X NOTITXT Dear Colleague, NOTITXT NOTITXT This is to notify you that some objects in which you are mentioned as NOTITXT a notifier, guardian or maintainer of one of the guarded attributes NOTITXT in this object have been modified in the NEW ${ORGTAG_UC} database. NOTITXT The objects below are the NEW entries for these NOTITXT objects in the database. In case of DELETIONS, the deleted object is NOTITXT displayed. NOOPs will not be reported. NOTITXT NOTITXT The update causing these changes had the following mail headers: NOTITXT NOTITXT - From: $FROM NOTITXT - Subject: $SUBJECT NOTITXT - Date: $MDATE NOTITXT - Msg-Id: $MSGID NOTITXT NOTITXT ${ORGTAG_UC} Database Notification Department X # NHEADER The Header used for notification messages X NHEADER From: ${ORGTAG_UC} Database Notifications <${ORGTAG}-dbm@${MAILDOM}> NHEADER Subject: Notification of ${ORGTAG_UC} Database changes NHEADER Reply-To: ${ORGTAG}-dbm@${MAILDOM} X # FWHEADER The header for forwarding updates that failed because of # maintainer autorisation failures. X FWHEADER From: ${ORGTAG_UC} Database Maintainer Forwarding <${ORGTAG}-dbm@${MAILDOM}> FWHEADER Subject: Requested ${ORGTAG_UC} database object changes FWHEADER Reply-To: ${ORGTAG}-dbm@${MAILDOM} X # FWTEXT The text send out to maintainers to inform them that someone # tried to change objects for which they are maintainers, but failed # the authorisation X FWTEXT FWTEXT Dear Maintainer, FWTEXT FWTEXT This is to notify you that some objects in which you are mentioned as FWTEXT a maintainer were requested to be changed, but *failed* the proper FWTEXT authorisation for any of the mentioned maintainers. FWTEXT Please contact the sender of these changes about changes that need FWTEXT need to be made to the following objects. FWTEXT FWTEXT The mail message causing these failures had the following mail headers: FWTEXT FWTEXT - From: $FROM FWTEXT - Subject: $SUBJECT FWTEXT - Date: $MDATE FWTEXT - Msg-Id: $MSGID FWTEXT FWTEXT ${ORGTAG_UC} Database Maintainer Forwarding Department X # Maintainer objects are handles special and cannot be created auto # automatically. They are forwarded to $HUMAILBOX or whatever you # want to specify. The ERROR sent back to the sender, will contain # $HUMAILBOX as the mailbox it was sent to. This one can take variable # substitution like MAILTXT. X MTFWHEADER To: $HUMAILBOX MTFWHEADER From: ${ORGTAG_UC} Database Maintainer Creation <$HUMAILBOX> MTFWHEADER Subject: Maintainer Creation request MTFWHEADER Reply-To: $HUMAILBOX X # And this is the text of the message that will be sent in the above case. X MTFWTEXT A maintainer object is requested by: MTFWTEXT MTFWTEXT - From: $FROM MTFWTEXT - Subject: $SUBJECT MTFWTEXT - Date: $MDATE MTFWTEXT - Msg-Id: $MSGID MTFWTEXT MTFWTEXT Please process the object below. MTFWTEXT X # COPYRIGHT message that goes on top of every newly generated, or cleaned # database, will be output with "#" before each line. X RIGHTS Copyright (c)1992/1993/1994 by Daniel Karrenberg and the RARE Association RIGHTS RIGHTS Restricted rights. RIGHTS RIGHTS Except for agreed Internet operational purposes, no part of this RIGHTS publication may be reproduced, stored in a retrieval system, or RIGHTS transmitted, in any form or by any means, electronic, mechanical, RIGHTS recording, or otherwise, without prior permission of RIGHTS ${ORGFULLNAME} on behalf of the copyright holders. RIGHTS RIGHTS Any use of this material to target advertising or similar RIGHTS activities are explicitly forbidden and will be prosecuted. RIGHTS ${ORGFULLNAME} requests to be notified RIGHTS of any such activities or suspicions thereof. RIGHTS RIGHTS ${ORGFULLNAME} would like to acknowledge and RIGHTS thank RIPE and RARE Association, and in particular Daniel RIGHTS Karrenberg and Tony Bates, for their pioneering work making the RIGHTS International Routing Registry possible, and for providing much RIGHTS of the software that drives this registry. X ############################################################################# # # In theory, you shouldn't have to edit anything below this line # ############################################################################# X # What sources can be updated ? Others will generate an error. # Remove this if you run a secondary copy only X CANUPD ${ORGTAG_UC} X # Run database sw in test mode? Testmode will cause ALL mail acks and other # mail messages to be send to DEFMAIL defined further below. X TESTMODE 0 X # file to keep people that can make entries using the update daemon # not in distribution yet. In fact, it has not even been written ;-) # It is a good idea though. X # AUTHFILE ${TOPDIR}/conf.auth X # help file for "whois help" X HELP ${TOPDIR}/etc/db-help X # whoisd query log file X QRYLOG ${TOPDIR}/etc/qrylog X # Error log file (if something really goes wrong ...) X ERRLOG ${TOPDIR}/etc/errlog X # this is where an audit trail for deletes and other important # database actions goes. Only one liners are syslogged. Maintainer # should take care of rotating logs and the like. X AUDITLOG ${TOPDIR}/etc/auditlog X # authorization log (not yet used) AUTHLOG ${TOPDIR}/etc/authlog X # this is where all update requests will be logged, this SHOULD be a # directory, logged will be in file YYMMDD with EOF markers between # messages X UPDLOG ${TOPDIR}/etc/updlog X # this is where all acknowledgements will be logged, this SHOULD be a # directory, logged will be in file YYMMDD with EOF markers between # messages X ACKLOG ${TOPDIR}/etc/acklog X # This is where the whoisd pid goes once started # (default: /tmp/whoisd.pid) X PIDFILE ${TOPDIR}/etc/whoisd.pid X # This is the lock file basename for cleandb, to avoid rename/open race # condition. The database name is appended to this basename, to create # sperate lock files for all databases. # (default: /tmp/CLEANDB.LOCK) X CLEANLOCK ${TOPDIR}/CLEANDB.LOCK X # TMPDIR is the tmp directory where various tools keep tmp files. # Make sure you have enough disk space, the tools do not understand # "disk full" messages and will do unexpected things. # (default: /tmp) X TMPDIR ${TOPDIR}/tmp X # The list of valid attribute names themselves in short and long version # ATTR ac admin-c ATTR aa as-name ATTR ad address ATTR ae as-exclude ATTR ai as-in ATTR al as-list ATTR an aut-num ATTR am as-macro ATTR ao as-out ATTR as aut-sys ATTR at auth ATTR au authority ATTR bg bdry-gw ATTR bi bis ATTR bl bdrygw-l ATTR ch changed ATTR cl comm-list ATTR cm community ATTR co connect ATTR cy country ATTR da dom-name ATTR de descr ATTR df default ATTR di dom-net ATTR dm dom-in ATTR dn domain ATTR do dom-out ATTR dp dom-prefix ATTR dt upd-to ATTR em e-mail ATTR fx fax-no ATTR gd guardian ATTR gw gateway ATTR ho hole ATTR if ifaddr ATTR ii ias-int ATTR in inetnum ATTR ir inet-rtr ATTR it interas-in ATTR io interas-out ATTR la localas ATTR lo location ATTR ma maintainer ATTR mb mnt-by ATTR mt mntner ATTR mn mnt-nfy ATTR na netname ATTR nh nic-hdl ATTR ni nsf-in ATTR no nsf-out ATTR ns nserver ATTR ny notify ATTR op op-phone ATTR of op-fax ATTR om op-mail ATTR or origin ATTR pe peer ATTR ph phone ATTR pn person ATTR rl routpr-l ATTR rm remarks ATTR rp rout-pr ATTR rt route ATTR rz rev-srv ATTR sd sub-dom ATTR so source ATTR tc tech-c ATTR wd withdrawn ATTR zc zone-c X # TEMPORARY FOR MERIT, WILL DISSAPEAR IN APRIL 1995 ATTR lr local-route X # Attributes with u* short names are special! # They all have hardcoded side effects, so do NOT change them # unless you know what you are doing X ATTR ua authorise # very special ATTR ud delete # delete operation ATTR ue *ERROR* # error attribute ATTR uo override # very special as well ATTR uw WARNING # warning attribute # X # attribute aliases (because they appear so often!) # ATTA ch change ATTA fx fax ATTA rm remark ATTA ua authorised ATTA ud deleted ATTA aa asname X # object alias for template mode # ALIAS in network ALIAS in netnum X # The database objects in terms of their attributes # # ATSQ - all defined attributes in this object, also defines print order # MAND - these attributes are mandatory # OPT - these attributes are optional # MULT - these attributes can appear more than once per object # SORT - sort order, single digit, lowest sorted first # UNIQ - these attributes define the unique key # KEYS - these attributes define all possible keys # REC - these attributes must be looked up if referenced # OBS - these attributes are obsoleted. When send in an update # dbupdate will remove them and generate a warning. # specially done for transitioning # X # First, let's determine what objects are guarded, these can not be # updated automatically, and will generate an error message. They # need special magic to be included. And no, I'm not gonna tell what # the magic is. X GRDOBJ am an cm rt # GRDOBJ am an cm rt mt X # autonomous systems # OBJ an ATSQ an aa de ai ao it io ae df gd ac tc OBJ an ATSQ rm ny mb ch so OBJ an MAND an de ac tc ch so OBJ an OPT aa ai ao it io ae df gd rm ny ma mb OBJ an MULT de ai ao it io ae df ac tc rm ch ny mb OBJ an SORT 0 OBJ an UNIQ an OBJ an KEYS an OBJ an REC ac tc X X # as macros # OBJ am ATSQ am de al gd tc ac rm ny mb ch so OBJ am MAND am de al gd tc ac mb ch so OBJ am OPT rm ny OBJ am MULT de al tc ac rm ch ny mb OBJ am SORT 8 OBJ am UNIQ am OBJ am KEYS am OBJ am REC tc ac X # boundary gateways - obsoleted 940906 # # OBJ bg ATSQ bg de lo au gd ac tc rm ny ma ch so # OBJ bg MAND ac au bg ch de gd lo so tc # OBJ bg OPT ny ma rm # OBJ bg MULT ac de lo tc ch ny # OBJ bg SORT 1 # OBJ bg UNIQ bg # OBJ bg KEYS bg # OBJ bg REC ac tc X # community # OBJ cm ATSQ cm de au gd tc ac rm ny ma mb ch so OBJ cm MAND cm de au gd tc ac mb ch so OBJ cm OPT ny ma rm OBJ cm MULT de tc ac rm ch ny mb OBJ cm SORT 6 OBJ cm UNIQ cm OBJ cm KEYS cm OBJ cm REC ac tc OBJ cm OBS ma X # domains # OBJ dn ATSQ dn de ac tc zc ns sd di rm ny ma mb ch so OBJ dn MAND ac ch de dn so tc zc OBJ dn OPT di ns rm sd ny ma mb OBJ dn MULT ac ch de di ns rm sd tc zc ny mb OBJ dn SORT 4 OBJ dn UNIQ dn OBJ dn KEYS dn OBJ dn REC ac tc zc OBJ dn OBS ma X # networks # OBJ in ATSQ in na de cy ac tc co as cl ii ni no gw rz OBJ in ATSQ rm ny ma mb ch so OBJ in MAND ac ch cy de in na so tc OBJ in OPT as bl cl co ch gw ii ni no rl rm rz ny ma mb OBJ in MULT ac ch de ii rm rz tc ny mb OBJ in SORT 5 OBJ in UNIQ in OBJ in KEYS in na OBJ in REC ac tc # OBJ in GRD as cl OBJ in OBS bl rl ma X # Do not use the guarded stuff any more. It works like the previous versions # but will be obsoleted shortly. X # GUARD cl ${TOPDIR}/guarded/community MULTIPLE # GUARD as ${TOPDIR}/guarded/as SINGLE X # routing privilege /boundary gateway obsoleted 940906 mt # Left in here to make sure they are all gone. Point to empty directory. X # GUARD rl ${TOPDIR}/guarded/removed MULTIPLE # GUARD bl ${TOPDIR}/guarded/removed MULTIPLE X # persons # OBJ pn ATSQ pn ad ph fx em nh rm ny ma mb ch so OBJ pn MAND ad ch ph pn so OBJ pn OPT em fx nh rm ny ma mb OBJ pn MULT ad ch em fx ph rm ny mb OBJ pn SORT 3 OBJ pn UNIQ pn nh OBJ pn KEYS pn nh OBJ in OBS ma X # routing privileges - obsoleted 940906 mt # # OBJ rp ATSQ rp de au gd ac tc rm ny ma ch so # OBJ rp MAND ac au ch de gd rp so # OBJ rp OPT tc ny ma # OBJ rp MULT ac de tc ch ny # OBJ rp SORT 2 # OBJ rp UNIQ rp # OBJ rp KEYS rp # OBJ rp REC ac tc X # clns object # OBJ dp ATSQ dp da de bi dm do df ac tc gd rm ny ma mb ch so OBJ dp MAND dp da ac tc ch so OBJ dp OPT bi de dm do df gd ny ma rm mb OBJ dp MULT de bi dm do df ac tc ch ny rm mb OBJ dp SORT 7 OBJ dp UNIQ dp OBJ dp KEYS dp da OBJ dp REC ac tc OBJ dp OBS ma X # inet-rtr # OBJ ir ATSQ ir la if pe ac tc rm ny mb ch so OBJ ir MAND ir la if tc ac ch so OBJ ir OPT pe ny mb rm OBJ ir MULT if pe tc ac rm ny ch mb OBJ ir SORT 9 OBJ ir UNIQ ir OBJ ir KEYS ir if OBJ ir REC tc ac X # maintainer # OBJ mt ATSQ mt de ac tc dt mn at rm ny mb ch so OBJ mt MAND mt de ac dt at ch so OBJ mt OPT tc mn rm ny mb OBJ mt MULT de ac tc dt mn at rm ny mb ch OBJ mt SORT 10 OBJ mt UNIQ mt OBJ mt KEYS mt OBJ mt REC ac tc X # route - ONLY PRDB SUPPORTS THESE CURRENTLY # OBJ rt ATSQ rt de or ho wd cl lr rm ny mb ch so OBJ rt MAND rt de or ch so OBJ rt OPT ho wd cl rm ny mb la OBJ rt MULT de ho cl rm ny ch mb OBJ rt SORT 11 OBJ rt UNIQ rt or OBJ rt KEYS rt X # the list of valid country names RIPE database specific, used # for syntax checking. May move into different config at later stage. X COUNTRY AE ae COUNTRY AL al COUNTRY AM am COUNTRY AT at COUNTRY AZ az COUNTRY BE be COUNTRY BF bf COUNTRY BG bg COUNTRY BH bh COUNTRY BY by COUNTRY CH ch COUNTRY CM cm COUNTRY CS cs COUNTRY CZ cz COUNTRY CY cy COUNTRY DE de COUNTRY DK dk COUNTRY DZ dz COUNTRY EE ee COUNTRY EG eg COUNTRY ES es COUNTRY FI fi COUNTRY FR fr COUNTRY GB gb COUNTRY GR gr COUNTRY HR hr COUNTRY HU hu COUNTRY IE ie COUNTRY IL il COUNTRY IN in COUNTRY IR ir COUNTRY IS is COUNTRY IT it COUNTRY KE ke COUNTRY KG kg COUNTRY KW kw COUNTRY KZ kz COUNTRY LA la COUNTRY LB lb COUNTRY LI li COUNTRY LU lu COUNTRY LV lv COUNTRY LT lt COUNTRY MA ma COUNTRY MC mc COUNTRY MK mk COUNTRY MT mt COUNTRY NC nc COUNTRY NE ne COUNTRY NL nl COUNTRY NO no COUNTRY OM om COUNTRY PF pf COUNTRY PL pl COUNTRY PT pt COUNTRY RO ro COUNTRY RU ru COUNTRY SA sa COUNTRY SE se COUNTRY SG sg COUNTRY SI si COUNTRY SK sk COUNTRY SN sn COUNTRY SU su COUNTRY TN tn COUNTRY TR tr COUNTRY UA ua COUNTRY US us COUNTRY UZ uz COUNTRY YU yu COUNTRY ZA za X # And some funny translations for the yobbos X COUNTRY GB UK COUNTRY GB uk X # legal connect attribute values in alphabetic order # also RIPE database specific used for syntax checking, may move to # different config file later .... # # In fact they are obsoleted. # CONNECT ACONET CONNECT ALT CONNECT CIX CONNECT CNR CONNECT DATANET CONNECT EASI CONNECT EBONE CONNECT EMPB CONNECT EU CONNECT EU-FI CONNECT FICIX CONNECT FUNET CONNECT GARR CONNECT HEPNET CONNECT ICS CONNECT INFN CONNECT IRIS CONNECT IUNET CONNECT JANET CONNECT LANLINK CONNECT LOCAL CONNECT NETTUNO CONNECT NIKHEF CONNECT NLNET CONNECT NORDU CONNECT NSF CONNECT PIPEX CONNECT POWERWAN CONNECT RCCN CONNECT REDIRIS CONNECT RENATER CONNECT RIPE CONNECT SARA CONNECT SURF CONNECT SWIP CONNECT SWITCH CONNECT TIP CONNECT WCW CONNECT WIN CONNECT XLINK X ENDCONF # do not remove! SHAR_EOF $shar_touch -am 0504153895 'config.generic' && chmod 0640 'config.generic' || echo 'restore of config.generic failed' shar_count="`wc -c < 'config.generic'`" test 21067 -eq "$shar_count" || echo "config.generic: original size 21067, current size $shar_count" fi exit 0 -------- Logged at Fri May 5 16:05:24 MET DST 1995 --------- From dsj at merit.edu Fri May 5 16:05:19 1995 From: dsj at merit.edu (Dale S. Johnson) Date: Fri, 5 May 1995 10:05:19 -0400 Subject: question on requirement for mnt-by fields: Message-ID: <199505051405.KAA06273@home.merit.edu> Anyone? > From jhawk at mit.edu Thu May 4 16:29:13 1995 > Received: from radb.ra.net (radb.ra.net [198.108.0.8]) by home.merit.edu (8.6.12/merit-2.0) with ESMTP id QAA12239; Thu, 4 May 1995 16:29:12 -0400 > Received: from merit.edu (merit.edu [35.1.1.42]) by radb.ra.net (8.6.10/8.6.9) with ESMTP id QAA19970 for ; Thu, 4 May 1995 16:29:43 -0400 > Received: from limekiller.MIT.EDU (root at LIMEKILLER.MIT.EDU [18.70.0.36]) by merit.edu (8.6.10/merit-2.0) with ESMTP id QAA26168; Thu, 4 May 1995 16:29:10 -0400 > Received: (from jhawk at localhost) by limekiller.MIT.EDU (8.6.11/8.6.11) id QAA07592; Thu, 4 May 1995 16:29:11 -0400 > Date: Thu, 4 May 1995 16:29:11 -0400 > Message-Id: <199505042029.QAA07592 at limekiller.MIT.EDU> > To: khuon at merit.net > Cc: db-admin at merit.net > Subject: Re: Why did this auto-dbm fail? > From: John Hawkinson > Status: R > > > > JH> > Without the self referencing mnt-by field, the auto-dbm barfed on your > > JH> > submission. > > JH> Eh? Without?? > > > > > > By your own admission, originally, your mntner did NOT have a mnt-by field > > thus you weren't allowed to modify it. > > Why does the lack of a mnt-by field suggest that I would be unable to modify > the mntner object? I had been just recently modified it; it was only > attempting to add the self-referential mnt-by that fail authorization. > > RIPE-120 says: > > If there is no mnt-by attribute, the update always proceeds > causing any notifications specified in notify attributes of > the object. This ensures backward compatibility. It is > > Is the existance of an mnt-by a prerequisite for adding one? > > The next paragraph reads: > > If a new object with a mnt-by attribute is added to the > database or a mnt-by attribute is added to an object that > previously had no such attribute, the authorisation step is > performed on the maintainer to be added. > > I must admit, I'm perplexed -- what do they mean by the last > phrase ``the authorization step...''? Are they implying that such > an action will always fail? > > --jhawk > -------- Logged at Fri May 5 16:19:50 MET DST 1995 --------- From GeertJan.deGroot at ripe.net Fri May 5 16:19:48 1995 From: GeertJan.deGroot at ripe.net (Geert Jan de Groot) Date: Fri, 05 May 1995 16:19:48 +0200 Subject: question on requirement for mnt-by fields: In-Reply-To: Your message of "Fri, 05 May 1995 10:05:19 EDT." <199505051405.KAA06273@home.merit.edu> Message-ID: <9505051419.AA07156@ncc.ripe.net> Dale, You're touching history here - let me try to explain what happened: In the past, when the current authorisation mechanism wasn't in place yet, aut-num objects were always protected - you had to send them to another address, and they were authorized by hand (basically, we checked the sender and the headers and then did a privileged update). The reason for this was that people felt that it should not be possible to have the routing policy changed by anyone - this data should be protected. Later the authorisation mechanism was added, and it works as a logical or: - You pass one of the mnt-by authorisation mechanisms, OR - The update is done using the special privileged update mechanism. ... which means that if an object doesn't have a mnt-by, then it can only be updated by a privileged person. You can remove the authentication using a maintainer like this: aut-num: AS4711 mnt-by: AS4711-MNT mntner: AS4711-MNT auth: NONE Hope this helps, Geert Jan On Fri, 5 May 1995 10:05:19 -0400 "Dale S. Johnson" wrote: > > Anyone? > > > > JH> > Without the self referencing mnt-by field, the auto-dbm barfed on y our > > > JH> > submission. > > > JH> Eh? Without?? > > > > > > > > > By your own admission, originally, your mntner did NOT have a mnt-by fiel d > > > thus you weren't allowed to modify it. > > > > Why does the lack of a mnt-by field suggest that I would be unable to modif y > > the mntner object? I had been just recently modified it; it was only > > attempting to add the self-referential mnt-by that fail authorization. > > > > RIPE-120 says: > > > > If there is no mnt-by attribute, the update always proceeds > > causing any notifications specified in notify attributes of > > the object. This ensures backward compatibility. It is > > > > Is the existance of an mnt-by a prerequisite for adding one? > > > > The next paragraph reads: > > > > If a new object with a mnt-by attribute is added to the > > database or a mnt-by attribute is added to an object that > > previously had no such attribute, the authorisation step is > > performed on the maintainer to be added. > > > > I must admit, I'm perplexed -- what do they mean by the last > > phrase ``the authorization step...''? Are they implying that such > > an action will always fail? > > > > --jhawk > > -------- Logged at Fri May 5 16:56:29 MET DST 1995 --------- From David.Kessens at ripe.net Fri May 5 16:56:25 1995 From: David.Kessens at ripe.net (David.Kessens at ripe.net) Date: Fri, 5 May 1995 16:56:25 +0200 (MET DST) Subject: question on requirement for mnt-by fields In-Reply-To: <9505051419.AA07156@ncc.ripe.net> from "Geert Jan de Groot" at May 5, 95 04:19:48 pm Message-ID: <9505051456.AA06361@mature.ripe.net> A non-text attachment was scrubbed... Name: not available Type: text Size: 906 bytes Desc: not available Url : https://www.ripe.net/mailman/private/rr-impl/attachments/19950505/d670aa9a/attachment.pl From dsj at merit.edu Fri May 5 17:20:18 1995 From: dsj at merit.edu (Dale S. Johnson) Date: Fri, 5 May 1995 11:20:18 -0400 Subject: question on requirement for mnt-by fields: Message-ID: <199505051520.LAA09441@home.merit.edu> Geert Jan, > Hope this helps, It does. One related question: What are guardians for nowdays? 181 says they are still required. What do they do? --Dale ============ From: Geert Jan de Groot > From geertj at ripe.net Fri May 5 10:20:56 1995 > To: "Dale S. Johnson" > Cc: rr-impl at ripe.net > Subject: Re: question on requirement for mnt-by fields: > Date: Fri, 05 May 1995 16:19:48 +0200 > > > Dale, > > You're touching history here - let me try to explain what happened: > > In the past, when the current authorisation mechanism wasn't in place yet, > aut-num objects were always protected - you had to send them to another > address, and they were authorized by hand (basically, we checked the sender > and the headers and then did a privileged update). > The reason for this was that people felt that it should not be possible > to have the routing policy changed by anyone - this data should be > protected. > > Later the authorisation mechanism was added, and it works as a > logical or: > - You pass one of the mnt-by authorisation mechanisms, OR > - The update is done using the special privileged update mechanism. > > ... which means that if an object doesn't have a mnt-by, then > it can only be updated by a privileged person. > > You can remove the authentication using a maintainer like this: > aut-num: AS4711 > mnt-by: AS4711-MNT > > mntner: AS4711-MNT > auth: NONE > > Hope this helps, > > Geert Jan > > On Fri, 5 May 1995 10:05:19 -0400 "Dale S. Johnson" wrote: > > > > Anyone? > > > > > > JH> > Without the self referencing mnt-by field, the auto-dbm barfed on y > our > > > > JH> > submission. > > > > JH> Eh? Without?? > > > > > > > > > > > > By your own admission, originally, your mntner did NOT have a mnt-by fiel > d > > > > thus you weren't allowed to modify it. > > > > > > Why does the lack of a mnt-by field suggest that I would be unable to modif > y > > > the mntner object? I had been just recently modified it; it was only > > > attempting to add the self-referential mnt-by that fail authorization. > > > > > > RIPE-120 says: > > > > > > If there is no mnt-by attribute, the update always proceeds > > > causing any notifications specified in notify attributes of > > > the object. This ensures backward compatibility. It is > > > > > > Is the existance of an mnt-by a prerequisite for adding one? > > > > > > The next paragraph reads: > > > > > > If a new object with a mnt-by attribute is added to the > > > database or a mnt-by attribute is added to an object that > > > previously had no such attribute, the authorisation step is > > > performed on the maintainer to be added. > > > > > > I must admit, I'm perplexed -- what do they mean by the last > > > phrase ``the authorization step...''? Are they implying that such > > > an action will always fail? > > > > > > --jhawk > > > -------- Logged at Fri May 5 17:36:08 MET DST 1995 --------- From David.Kessens at ripe.net Fri May 5 17:36:05 1995 From: David.Kessens at ripe.net (David.Kessens at ripe.net) Date: Fri, 5 May 1995 17:36:05 +0200 (MET DST) Subject: question on requirement for mnt-by fields: In-Reply-To: <199505051520.LAA09441@home.merit.edu> from "Dale S. Johnson" at May 5, 95 11:20:18 am Message-ID: <9505051536.AA06467@mature.ripe.net> A non-text attachment was scrubbed... Name: not available Type: text Size: 589 bytes Desc: not available Url : https://www.ripe.net/mailman/private/rr-impl/attachments/19950505/bc85a69a/attachment.pl From David.Kessens at ripe.net Fri May 5 17:39:37 1995 From: David.Kessens at ripe.net (David.Kessens at ripe.net) Date: Fri, 5 May 1995 17:39:37 +0200 (MET DST) Subject: a few patches to dbase In-Reply-To: <199505041752.NAA11434@curtis.ansremote.com> from "Curtis Villamizar" at May 4, 95 01:51:24 pm Message-ID: <9505051539.AA06478@mature.ripe.net> A non-text attachment was scrubbed... Name: not available Type: text Size: 14948 bytes Desc: not available Url : https://www.ripe.net/mailman/private/rr-impl/attachments/19950505/aa89d706/attachment.pl From lpj at merit.edu Fri May 5 18:26:15 1995 From: lpj at merit.edu (Laurent Joncheray) Date: Fri, 5 May 1995 12:26:15 -0400 (EDT) Subject: Small fix to whoisd.pl In-Reply-To: <9505041810.AA04984@ncc.ripe.net> from "Geert Jan de Groot" at May 4, 95 08:10:42 pm Message-ID: <199505051626.MAA12001@home.merit.edu> My test results: both servers (whoids and in.whoisd) run on a Sparc 20, on the same Ethernet segment as the client. I did a loop(500) { whois -h radb 128.141 # whoisd whois -h radb -p 10043 128.141 # in.whoisd whois -h radb 35 # whoisd whois -h radb -p 10043 35 # in.whoisd } I got 1000 data points. The whoisd take about 0.8s for 1 query The in.whoisd takes about 1.4s for 1 query (70% slower). That's all folks. Laurent PS: data available on request :-) In our previous episode, Geert Jan de Groot said: > > On Wed, 3 May 1995 14:56:52 -0400 (EDT) Laurent Joncheray wrote: > > It is an old issue but... > > why don't you port whoisd to be called from [x]inetd. So you > > won't need any networking hack. It has been like that on radb.ra.net, > > and it seems to be fine. > > Laurent > > PS: lot of advantages: do not need to run as root, IP filtering, logging, > > I just did some measurements; I did a 10 queries to the standard whois > service, and one running via inetd, and found: > direct: 25.25s > inetd: 5.00s > direct whois is 5 times faster. > > This is averaged over a number of measurements on the same machine, > and local (2 hops ether) network. > > This is probably why httpd servers want to run standalone, instead of > via inetd. Note that I needed to hack whoisd to make it work under > inetd (David whispered something about a fix being available from > Merit, but I didn't have it so I butchered the code to do this; > I'm not a perl programmer) > > The big difference is probably caused by perl initializing, as it > 'compiles' the perl script every time it starts; some debug-prints > made that quite clear. > > It seems that we can have either a safe whois, or a fast whois; > I can think of a port relay program (yech), or a kernel hack > to unprivilege port 43 (that's what I would do). > > Geert Jan > > -- Laurent Joncheray, E-Mail: lpj at merit.edu Merit Network Inc, 4251 Plymouth Rd, Suite C, Phone: +1 (313) 936 2065 Ann Arbor, MI 48105, USA Fax: +1 (313) 747 3185 "This is the end, Beautiful friend. This is the end, My only friend, the end" JM -------- Logged at Fri May 5 19:49:16 MET DST 1995 --------- From curtis at ans.net Fri May 5 19:45:59 1995 From: curtis at ans.net (Curtis Villamizar) Date: Fri, 05 May 1995 13:45:59 -0400 Subject: question on requirement for mnt-by fields: In-Reply-To: Your message of "Fri, 05 May 1995 11:20:18 EDT." <199505051520.LAA09441@home.merit.edu> Message-ID: <199505051746.NAA03519@curtis.ansremote.com> In message <199505051520.LAA09441 at home.merit.edu>, "Dale S. Johnson" writes: > Geert Jan, > > > Hope this helps, > > It does. One related question: > > What are guardians for nowdays? 181 says they are still required. > What do they do? > > --Dale Use the source Luke. This stuff is all chacked in syntax.pl. Look at dosyntax under the short name for the field you are interested in. Its faster than asking. -- anonymous :-) PS- Since I was just into this stuff to find out what _really_ happens when I try to dbupdate stuff... Check your conf file to see which objects require guardian. In enparse.pl, you are forced to have an "ua" or "mb". If a guardian is seen in an object, it just has to be a valid RFC822 email address. Guardians are out though. Maintainers are in vogue. See the maintainer stuff "mb", and "mt" in syntax.pl. Also see maintainer.pl, the sub Maintainer for the authorization check that happens when a guarded object gets changed (too big to include). --> syntax.pl # # gd - guardian # if ($key eq "gd") { if (!(&isemail($value))) { return $O_ERROR, "syntax error in \"$ATTL{$key}\" - ". "guardian must be a mailbox entry"; } return; } --> misc.pl sub isemail { local($str) = @_; local($ok) = 1; local($localpart, $domainpart) = split(/\@/, $str, 2); $localpart =~ s/^\$//; if ($localpart =~ /^"[a-zA-Z0-9\-\.\_\/\=\ %]+"$/) {} elsif ($localpart =~ /^[a-zA-Z0-9\-\.\_\/\=%]+$/) {} else {return 0;} if ($domainpart =~ /^[a-zA-Z0-9\_\-]+(\.[a-zA-Z0-9\_\-]+)+$/) {} else {return 0;} return 1; } --> enparse.pl # 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; } } -------- Logged at Sat May 6 03:33:21 MET DST 1995 --------- From curtis at ans.net Sat May 6 03:21:38 1995 From: curtis at ans.net (Curtis Villamizar) Date: Fri, 05 May 1995 21:21:38 -0400 Subject: Oops - makefile omission Message-ID: <199505060121.VAA04540@curtis.ansremote.com> Never send changes to a mailing list right after editing "a little change". I forgot a little detail. These are patches to the Makefiles I just sent. Curtis *** Makefile.orig2 Fri May 5 08:49:11 1995 --- Makefile Fri May 5 09:09:01 1995 *************** *** 8,13 **** --- 8,14 ---- MAILDOM= ans.net ORGTAG= ans + ORGTAG_UC= ANS ORGFULLNAME= ANS Routing Registry # You shouldn't have to modify anything below. Modify *************** *** 21,27 **** MAKE= make -f ${MGENERIC} PERL=${PERL} \ MAILDOM=${MAILDOM} ORGTAG=${ORGTAG} \ ! ORGFULLNAME="${ORGFULLNAME}" all: @if [ "x." = "x.${HOSTNAME}" ] ; then \ --- 22,28 ---- MAKE= make -f ${MGENERIC} PERL=${PERL} \ MAILDOM=${MAILDOM} ORGTAG=${ORGTAG} \ ! ORGTAG_UC=${ORGTAG_UC} ORGFULLNAME="${ORGFULLNAME}" all: @if [ "x." = "x.${HOSTNAME}" ] ; then \ *** Makefile.generic.orig2 Thu May 4 14:15:54 1995 --- Makefile.generic Fri May 5 09:09:45 1995 *************** *** 30,35 **** --- 30,36 ---- sed < config.generic > config.${HOSTNAME} \ -e 's,$${TOPDIR},${TOPDIR},g' \ -e 's,$${MAILDOM},${MAILDOM},g' \ + -e 's,$${ORGTAG_UC},${ORGTAG_UC},g' \ -e 's,$${ORGTAG},${ORGTAG},g' \ -e 's,$${ORGFULLNAME},${ORGFULLNAME},g' -------- Logged at Mon May 8 18:46:11 MET DST 1995 --------- From Tony.Bates at mci.net Mon May 8 18:46:06 1995 From: Tony.Bates at mci.net (Tony Bates) Date: Mon, 08 May 1995 12:46:06 -0400 Subject: For thise that care... Message-ID: <199505081646.MAA05225@ns.mci.net> This is what was done to fix perl 4.036 such that setsockopt would work under solaris set of correctly. --Tony. *** doio.c.orig Wed May 3 10:29:05 1995 --- doio.c Wed May 3 15:13:34 1995 *************** *** 1604,1610 **** --- 1604,1616 ---- register STR **st = stack->ary_array; register int sp = arglast[1]; register STIO *stio; + /* + * FIX - for crappy OPTVAL value being passed wrong + */ + int on; + char *buf; int fd; + int len; unsigned int lvl; unsigned int optname; *************** *** 1629,1635 **** break; case O_SSOCKOPT: st[sp] = st[sp+3]; ! if (setsockopt(fd, lvl, optname, st[sp]->str_ptr, st[sp]->str_cur) < 0) goto nuts; st[sp] = &str_yes; break; --- 1635,1652 ---- break; case O_SSOCKOPT: st[sp] = st[sp+3]; ! if(st[sp]->str_pok) { ! buf = (char *)st[sp]->str_ptr; ! len = st[sp]->str_cur; ! } else if (st[sp]->str_nok) { ! on = (int) st[sp]->str_u.str_nval; ! buf = (char *)&on; ! len = sizeof(on); ! } else { ! buf = (char *)(0); ! len = 0; ! } ! if (setsockopt(fd, lvl, optname, buf, len) < 0) goto nuts; st[sp] = &str_yes; break; -------- Logged at Tue May 9 13:32:11 MET DST 1995 --------- From David.Kessens at ripe.net Tue May 9 13:32:08 1995 From: David.Kessens at ripe.net (RIPE NCC Staff) Date: Tue, 09 May 1995 13:32:08 +0200 Subject: For thise that care... In-Reply-To: Your message of Mon, 08 May 1995 12:46:06 EDT. <199505081646.MAA05225@ns.mci.net> Message-ID: <9505091132.AA21611@ncc.ripe.net> Hi Tony, Of course I care... I will put a note about this fix in the distribution when I am back from Rome! Kind regards, David Kessens RIPE NCC Database maintainer ------------------------- * Tony Bates writes: * This is what was done to fix perl 4.036 such that setsockopt would * work under solaris set of correctly. * * * --Tony. * * *** doio.c.orig Wed May 3 10:29:05 1995 * --- doio.c Wed May 3 15:13:34 1995 * *************** * *** 1604,1610 **** * --- 1604,1616 ---- * register STR **st = stack->ary_array; * register int sp = arglast[1]; * register STIO *stio; * + /* * + * FIX - for crappy OPTVAL value being passed wrong * + */ * + int on; * + char *buf; * int fd; * + int len; * unsigned int lvl; * unsigned int optname; * * *************** * *** 1629,1635 **** * break; * case O_SSOCKOPT: * st[sp] = st[sp+3]; * ! if (setsockopt(fd, lvl, optname, st[sp]->str_ptr, st[sp]->str_cur) < * 0) * goto nuts; * st[sp] = &str_yes; * break; * --- 1635,1652 ---- * break; * case O_SSOCKOPT: * st[sp] = st[sp+3]; * ! if(st[sp]->str_pok) { * ! buf = (char *)st[sp]->str_ptr; * ! len = st[sp]->str_cur; * ! } else if (st[sp]->str_nok) { * ! on = (int) st[sp]->str_u.str_nval; * ! buf = (char *)&on; * ! len = sizeof(on); * ! } else { * ! buf = (char *)(0); * ! len = 0; * ! } * ! if (setsockopt(fd, lvl, optname, buf, len) < 0) * goto nuts; * st[sp] = &str_yes; * break; -------- Logged at Tue May 9 23:59:53 MET DST 1995 --------- From dsj at merit.edu Tue May 9 23:59:38 1995 From: dsj at merit.edu (Dale S. Johnson) Date: Tue, 9 May 1995 17:59:38 -0400 Subject: PRDB just converted to RADB. Message-ID: <199505092159.RAA09114@home.merit.edu> Advance FYI: We have just completed retiring the PRDB.db by merging it with the RADB.db . No information should have been lost. Whois queries to whois -h whois.ra.net (or to whois -h prdb.merit.edu) will no longer return anything with "source: PRDB"; the information will be shown as "source: RADB" instead. (In cases where routes were registered in both the PRDB and RADB, the route with the latest changed date was chosen). We do not expect that this will cause any operational problems. Please let us know if you experience unexpected results. A more general notification of the change will go to NANOG tomorrow (after we have a few more hours experience with the results). --Dale Johnson Brian Renaud -------- Logged at Thu May 11 15:14:28 MET DST 1995 --------- From dsj at merit.edu Thu May 11 15:14:16 1995 From: dsj at merit.edu (Dale S. Johnson) Date: Thu, 11 May 1995 09:14:16 -0400 Subject: Cross-database AS-macro references Message-ID: <199505111314.JAA06570@home.merit.edu> Tony, Enke, If ANS registers a bunch of AS-macros defining their ASs in the RADB, can you (and your users) reference those from aut-num policy expressions within the MCI.db? Or are there other things that need to be done to make this work? --Dale -------- Logged at Thu May 11 15:26:12 MET DST 1995 --------- From dsj at merit.edu Thu May 11 15:26:05 1995 From: dsj at merit.edu (Dale S. Johnson) Date: Thu, 11 May 1995 09:26:05 -0400 Subject: MAIL-FROM case sensitive? Message-ID: <199505111326.JAA07222@home.merit.edu> Anyone, Is email address authentication using the MAIL-FROM lines really supposed to be case-sensitive? It seems to be so on our implementation (and is causing a *lot* of questions and bounces). If it is intended this way, is there some gotcha we're likely to discover if we make it case-insensitive? --Dale -------- Logged at Thu May 11 15:34:12 MET DST 1995 --------- From Tony.Bates at mci.net Thu May 11 15:33:31 1995 From: Tony.Bates at mci.net (Tony Bates) Date: Thu, 11 May 1995 09:33:31 -0400 Subject: MAIL-FROM case sensitive? In-Reply-To: Your message of Thu, 11 May 1995 09:26:05 EDT. <199505111326.JAA07222@home.merit.edu> Message-ID: <199505111333.JAA19310@lovefm.reston.mci.net> Its a regex match as it states..pure and simple...I sort of like it this way as people have to think a little about what they are matching but I guess nothing will break if you change the case as part of the checking. --Tony. "Dale S. Johnson" writes: * Anyone, * * Is email address authentication using the MAIL-FROM lines really supposed * to be case-sensitive? It seems to be so on our implementation (and is * causing a *lot* of questions and bounces). * * If it is intended this way, is there some gotcha we're likely to discover * if we make it case-insensitive? * * --Dale -------- Logged at Thu May 11 15:40:50 MET DST 1995 --------- From Tony.Bates at mci.net Thu May 11 15:40:15 1995 From: Tony.Bates at mci.net (Tony Bates) Date: Thu, 11 May 1995 09:40:15 -0400 Subject: Cross-database AS-macro references In-Reply-To: Your message of Thu, 11 May 1995 09:14:16 EDT. <199505111314.JAA06570@home.merit.edu> Message-ID: <199505111340.JAA19322@lovefm.reston.mci.net> In theory yes but it does raise the IRR thing again which I still dont see moving ahead to quickly but anyway I am not sure what this buys unless ANS can really suport configs based on AS based plocies (even if this means mapping down to route in the implementation). It is nice to have a bunch of ASes to reference ANS customers by but if by this it means ANS will start implementing what they talked about doing which is using ripe-181 policy for configuration they have to get MEDs working. I know this is perhaps the wrong place to be spouting this but I still have not seen a concrete date as to when you will take advisories directly from us or anyone else for that matter and I'd rather see this happen than spending time on setting up AS-MACROs for ANS. I'm probably mixing issues here but things seem more than a little unclear as to when support of other RR will be put in place. --Tony. "Dale S. Johnson" writes: * Tony, Enke, * * If ANS registers a bunch of AS-macros defining their ASs in the RADB, * can you (and your users) reference those from aut-num policy expressions * within the MCI.db? * * Or are there other things that need to be done to make this work? * * --Dale -------- Logged at Thu May 11 15:46:06 MET DST 1995 --------- From labovit at merit.edu Thu May 11 15:45:58 1995 From: labovit at merit.edu (Craig Labovitz) Date: Thu, 11 May 1995 09:45:58 -0400 (EDT) Subject: MAIL-FROM case sensitive? In-Reply-To: <199505111326.JAA07222@home.merit.edu> from "Dale S. Johnson" at May 11, 95 09:26:05 am Message-ID: <199505111345.JAA08056@home.merit.edu> Dale, In general, email is *not* case-sensitive. All of the major mail programs (sendmail, PP, etc) do not pay any attention to case. I would have to check, but I think this is also part of the rfc-822 spec. - C Dale S. Johnson writes: > Anyone, > > Is email address authentication using the MAIL-FROM lines really supposed > to be case-sensitive? It seems to be so on our implementation (and is > causing a *lot* of questions and bounces). > > If it is intended this way, is there some gotcha we're likely to discover > if we make it case-insensitive? > > --Dale > -- Craig Labovitz labovit at merit.edu Merit Network, Inc. (313) 764-0252 (office) 1071 Beal Ave, Ann Arbor, MI (313) 747-3745 (fax) -------- Logged at Thu May 11 16:30:24 MET DST 1995 --------- From khuon at merit.net Thu May 11 16:29:41 1995 From: khuon at merit.net (Jake Khuon) Date: Thu, 11 May 1995 10:29:41 -0400 Subject: MAIL-FROM case sensitive? In-Reply-To: Craig Labovitz's message of Thu, 11 May 1995 09:45:58 -0400. <199505111345.JAA08056@home.merit.edu> Message-ID: <199505111429.KAA14634@Espresso.Merit.Net> ### On Thu, 11 May 1995 09:45:58 -0400 (EDT), Craig Labovitz ### wrote to dsj at merit.edu (Dale S. Johnson) concerning ### "Re: MAIL-FROM case sensitive?": CL> Dale S. Johnson writes: CL> > Anyone, CL> > CL> > Is email address authentication using the MAIL-FROM lines really supposed CL> > to be case-sensitive? It seems to be so on our implementation (and is CL> > causing a *lot* of questions and bounces). CL> > CL> > If it is intended this way, is there some gotcha we're likely to discover CL> > if we make it case-insensitive? CL> CL> In general, email is *not* case-sensitive. All of the major mail CL> programs (sendmail, PP, etc) do not pay any attention to case. CL> I would have to check, but I think this is also part of the rfc-822 CL> spec. Could it be that email authentication is case-sensitive because the auth field can also be used for encrypted passwords? Is there a way to possibly turn off case-sensitivity for MAIL-FROM yet still retain it for encrypted password checking? -- /*===================[ Jake Khuon ]======================+ | Systems Research Programmer, IE Group /| /|[~|)|~|~ N E T W O R K | | Vox: (313) 763-4907 Fax: (313) 747-3185 / |/ |[_|\| | Incorporated | +======[ Suite C, Bldg. 1 4251 Plymouth Rd. Ann Arbor, MI 48105 ]======*/ -------- Logged at Thu May 11 20:45:03 MET DST 1995 --------- From curtis at ans.net Thu May 11 20:36:55 1995 From: curtis at ans.net (Curtis Villamizar) Date: Thu, 11 May 1995 14:36:55 -0400 Subject: Cross-database AS-macro references In-Reply-To: Your message of "Thu, 11 May 1995 09:40:15 EDT." <199505111340.JAA19322@lovefm.reston.mci.net> Message-ID: <199505111839.OAA12049@curtis.ansremote.com> Tony, I'm typing as fast as I can. In message <199505111340.JAA19322 at lovefm.reston.mci.net>, Tony Bates writes: > In theory yes but it does raise the IRR thing again which I still > dont see moving ahead to quickly > but anyway I am not sure what this buys unless ANS can really > suport configs based on AS based plocies (even if this means mapping > down to route in the implementation). As you have probably figured out from past mail on this list, the ANS aut-num presented some fairly severe performance problems for some of the tools. This took a little time to fix. There have been other problems getting some of Merit's tools ported to our AIX config generation box. There shouldn't be portability problems with perl, but some code has pathnames embedded and poor or no error message, requires perl5 with both gdbm and ndbm and this combination hasn't ported to AIX very smoothly. A second problem is that the aut-num has been generated directly from the PRDB. We've been told by CANET (emphatically), RIPE, and MCI, that the data in the PRDB is stale and that advisories should be taken from the RADB. This change in input source format hasn't been accommodated in the code. So much for the update. Target date remains ... how about two weeks? > It is nice to have a bunch of ASes to reference ANS > customers by but if by this it means ANS will start implementing what > they talked about doing which is using ripe-181 policy for > configuration they have to get MEDs working. I know this is perhaps > the wrong place to be spouting this but I still have not seen a > concrete date as to when you will take advisories directly from us or > anyone else for that matter and I'd rather see this happen than > spending time on setting up AS-MACROs for ANS. I'm probably mixing > issues here but things seem more than a little unclear as to when > support of other RR will be put in place. Sorry, we aren't ready to do MED yet. For the majority of destinations fixed interchange preferences per home AS works fine. It works for the major COREN regionals. It doesn't work for MCI and Sprint direct connect destinations as well without MED. We know this and we know we have to fix it. Sorry about the schedule slip. I happen to be working long days and weekends to try to get certain config tools transitioned from Merit which is a prerequisite for the AS based aut-num if you want any sort of testing before deployment. You're just going to have to be a patient a little longer. Regards, Curtis -------- Logged at Thu May 11 21:37:21 MET DST 1995 --------- From curtis at ans.net Thu May 11 21:14:31 1995 From: curtis at ans.net (Curtis Villamizar) Date: Thu, 11 May 1995 15:14:31 -0400 Subject: just an FYI - don't panic Message-ID: <199505111914.PAA12093@curtis.ansremote.com> All, This is just an FYI. I haven't been real enthusiastic about the idea of submiting these aut-num objects to the RADB. This was submitted to a test database at Merit. I will assert that this aut-num _cannot_ be submitted by e-mail due to a minor RIPE-181 design oversight. Lines of the following form cannot be broken up using the currently defined RIPE line continuation: as-in: from ASxxx 1 accept ASyyy AND NOT { ..very long list.. } To break up this line using the RIPE line continuation would change it's meaning. In some cases, ASyyy expands to a few thousand networks and the list of exceptions is tens of networks, though in a few cases the list of exceptions is over a hundred. Even if the list of exceptions is only a few tens of networks, the lines very quickly become too long for some mail processing software which can then mangle the lines in unpredictable ways. The solution to this general problem is for RIPE-181 (and related documents to support a general line continuation using the backslash character at the end of the line to indiacte that there is more on the next line. Curtis PS- The solution to this particular problem has been for ANS to load this in a local database (using dbupdate, so using full sytax checking) for testing rather than try to send it in the mail. PPS- Yes, I will be forwarding patches to fix this so things like this can be e-mailed in the future. Later. ------- Forwarded Message Received: from interlock.ans.net by wawa.ans.net with SMTP id AA07837 (5.65c/IDA-1.4.4 for ); Thu, 11 May 1995 14:21:31 GMT Received: by interlock.ans.net id AA48214 (InterLock SMTP Gateway 3.0 for curtis at ans.net); Thu, 11 May 1995 10:23:28 -0400 Message-Id: <199505111423.AA48214 at interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 11 May 1995 10:23:28 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 11 May 1995 10:23:28 -0400 To: curtis at ans.net Subject: it chucked Date: Thu, 11 May 1995 10:22:45 -0400 From: Selina Priestley - ------- Forwarded Message Date: Thu, 11 May 1995 09:51:20 -0400 From: NSF Routing Arbiter Database Management To: RADB object Submitter Subject: Re: 690 aut-num Your e-mail: > From: RADB object Submitter > Subject: 690 aut-num > Date: Thu, 11 May 1995 09:45:52 -0400 > Msg-Id: <199505111346.AA06021 at interlock.ans.net> has been processed by the automatic update procedure at the NSF Routing Arbiter. Diagnostic output follows: ------------------------------------------------------------------------ Update FAILED: [aut-num] AS690 aut-num: AS690 descr: ANSNET [ ... further profanity truncated to save sanity ... ] -------- Logged at Thu May 11 21:42:44 MET DST 1995 --------- From Tony.Bates at mci.net Thu May 11 21:42:38 1995 From: Tony.Bates at mci.net (Tony Bates) Date: Thu, 11 May 1995 15:42:38 -0400 Subject: just an FYI - don't panic In-Reply-To: Your message of Thu, 11 May 1995 15:14:31 EDT. <199505111914.PAA12093@curtis.ansremote.com> Message-ID: <199505111942.PAA25372@lovefm.reston.mci.net> Curtis, whay cant these lines be broken up with the current RIPE-181 line wrap rules ? --Tony. Curtis Villamizar writes: * * All, * * This is just an FYI. I haven't been real enthusiastic about the idea * of submiting these aut-num objects to the RADB. This was submitted to * a test database at Merit. I will assert that this aut-num _cannot_ be * submitted by e-mail due to a minor RIPE-181 design oversight. * * Lines of the following form cannot be broken up using the currently * defined RIPE line continuation: * * as-in: from ASxxx 1 accept ASyyy AND NOT { ..very long list.. } * * To break up this line using the RIPE line continuation would change * it's meaning. In some cases, ASyyy expands to a few thousand networks * and the list of exceptions is tens of networks, though in a few cases * the list of exceptions is over a hundred. * * Even if the list of exceptions is only a few tens of networks, the * lines very quickly become too long for some mail processing software * which can then mangle the lines in unpredictable ways. * * The solution to this general problem is for RIPE-181 (and related * documents to support a general line continuation using the backslash * character at the end of the line to indiacte that there is more on the * next line. * * Curtis * * PS- The solution to this particular problem has been for ANS to load * this in a local database (using dbupdate, so using full sytax * checking) for testing rather than try to send it in the mail. * * PPS- Yes, I will be forwarding patches to fix this so things like this * can be e-mailed in the future. Later. * * * ------- Forwarded Message * * Received: from interlock.ans.net by wawa.ans.net with SMTP id AA07837 * (5.65c/IDA-1.4.4 for ); Thu, 11 May 1995 14:21:31 GM * T * Received: by interlock.ans.net id AA48214 * (InterLock SMTP Gateway 3.0 for curtis at ans.net); * Thu, 11 May 1995 10:23:28 -0400 * Message-Id: <199505111423.AA48214 at interlock.ans.net> * Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); * Thu, 11 May 1995 10:23:28 -0400 * Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); * Thu, 11 May 1995 10:23:28 -0400 * To: curtis at ans.net * Subject: it chucked * Date: Thu, 11 May 1995 10:22:45 -0400 * From: Selina Priestley * * * - ------- Forwarded Message * * Date: Thu, 11 May 1995 09:51:20 -0400 * From: NSF Routing Arbiter Database Management * To: RADB object Submitter * Subject: Re: 690 aut-num * * Your e-mail: * * > From: RADB object Submitter * > Subject: 690 aut-num * > Date: Thu, 11 May 1995 09:45:52 -0400 * > Msg-Id: <199505111346.AA06021 at interlock.ans.net> * * has been processed by the automatic update procedure at the NSF Routing A * rbiter. * Diagnostic output follows: * * ------------------------------------------------------------------------ * Update FAILED: [aut-num] AS690 * * aut-num: AS690 * descr: ANSNET * * [ ... further profanity truncated to save sanity ... ] -------- Logged at Thu May 11 21:58:58 MET DST 1995 --------- From Tony.Bates at mci.net Thu May 11 21:57:57 1995 From: Tony.Bates at mci.net (Tony Bates) Date: Thu, 11 May 1995 15:57:57 -0400 Subject: Cross-database AS-macro references In-Reply-To: Your message of Thu, 11 May 1995 14:36:55 EDT. <199505111839.OAA12049@curtis.ansremote.com> Message-ID: <199505111957.PAA25452@lovefm.reston.mci.net> Curtis, thanks for the update. Two weeks sounds good to me. I realise the large task facing you. --Tony. Curtis Villamizar writes: * * Tony, * * I'm typing as fast as I can. * * In message <199505111340.JAA19322 at lovefm.reston.mci.net>, Tony Bates writes * : * > In theory yes but it does raise the IRR thing again which I still * > dont see moving ahead to quickly * > but anyway I am not sure what this buys unless ANS can really * > suport configs based on AS based plocies (even if this means mapping * > down to route in the implementation). * * As you have probably figured out from past mail on this list, the ANS * aut-num presented some fairly severe performance problems for some of * the tools. This took a little time to fix. There have been other * problems getting some of Merit's tools ported to our AIX config * generation box. There shouldn't be portability problems with perl, * but some code has pathnames embedded and poor or no error message, * requires perl5 with both gdbm and ndbm and this combination hasn't * ported to AIX very smoothly. * * A second problem is that the aut-num has been generated directly from * the PRDB. We've been told by CANET (emphatically), RIPE, and MCI, * that the data in the PRDB is stale and that advisories should be taken * from the RADB. This change in input source format hasn't been * accommodated in the code. * * So much for the update. Target date remains ... how about two weeks? * * > It is nice to have a bunch of ASes to reference ANS * > customers by but if by this it means ANS will start implementing what * > they talked about doing which is using ripe-181 policy for * > configuration they have to get MEDs working. I know this is perhaps * > the wrong place to be spouting this but I still have not seen a * > concrete date as to when you will take advisories directly from us or * > anyone else for that matter and I'd rather see this happen than * > spending time on setting up AS-MACROs for ANS. I'm probably mixing * > issues here but things seem more than a little unclear as to when * > support of other RR will be put in place. * * Sorry, we aren't ready to do MED yet. * * For the majority of destinations fixed interchange preferences per * home AS works fine. It works for the major COREN regionals. It * doesn't work for MCI and Sprint direct connect destinations as well * without MED. We know this and we know we have to fix it. * * Sorry about the schedule slip. I happen to be working long days and * weekends to try to get certain config tools transitioned from Merit * which is a prerequisite for the AS based aut-num if you want any sort * of testing before deployment. You're just going to have to be a * patient a little longer. * * Regards, * * Curtis -------- Logged at Thu May 11 23:13:32 MET DST 1995 --------- From dsj at merit.edu Thu May 11 23:13:28 1995 From: dsj at merit.edu (Dale S. Johnson) Date: Thu, 11 May 1995 17:13:28 -0400 Subject: Does this look familiar to anyone Message-ID: <199505112113.RAA29333@home.merit.edu> Anyone seen a bug like this before? Querying "194.128" (no /15" finds one net; with the /15 finds two): ('Haven't looked into any code about this yet...) --Dale ============ From: Selina Priestley > From selina at ans.net Thu May 11 14:56:56 1995 > To: rrgroup at merit.edu > Cc: heimlich at ans.net > Subject: whois tool irregularity > Reply-To: selina at ans.net > Date: Thu, 11 May 1995 14:56:12 -0400 > > Isn't this odd? > > bugsy-sfp:/u/sfp: whois -h whois.ra.net 194.128 > route: 194.128.0.0/15 > descr: PIPEX-BLOCK3 > origin: AS1849 > advisory: AS690 1:1849 2:701(147) 3:701(134) 4:1800 > remarks: Holes to come! > mnt-by: AS1849-MNT > changed: tim at pipex.net 950428 > source: RIPE > > bugsy-sfp:/u/sfp: whois -h whois.ra.net 194.128/15 > route: 194.128.0.0/15 > descr: PIPEX Ltd > descr: 216 Cambridge Science Park > descr: Milton Road > descr: Cambridge > descr: England > descr: CB4 4WA > descr: UNITED KINGDOM > origin: AS1849 > comm-list: COMM_NSFNET > advisory: AS690 1:1849 2:701(147) 4:1800 > mnt-by: MAINT-AS1849 > changed: support at pipex.net 950511 > source: RADB > > route: 194.128.0.0/15 > descr: PIPEX-BLOCK3 > origin: AS1849 > advisory: AS690 1:1849 2:701(147) 3:701(134) 4:1800 > remarks: Holes to come! > mnt-by: AS1849-MNT > changed: tim at pipex.net 950428 > source: RIPE > > Selina -------- Logged at Thu May 11 23:22:31 MET DST 1995 --------- From dsj at merit.edu Thu May 11 23:22:24 1995 From: dsj at merit.edu (Dale S. Johnson) Date: Thu, 11 May 1995 17:22:24 -0400 Subject: No subject Message-ID: <199505112122.RAA29617@home.merit.edu> From sfp at noc.ans.net Thu May 11 21:54:13 1995 From: sfp at noc.ans.net (Selina F. Priestley) Date: Thu, 11 May 1995 15:54:13 EDT Subject: WARNING: RA whois tool problems Message-ID: <199505111954.AA84321@bugsy.aa.ans.net> Until the RA can find and fix these problems, please try to use netmasks when specifying routes.. Unfortunately, aggchk is already out of date for some information, and can no longer be trusted as a definitive source. I believe other people have seen things even more strange that the examples I have included. If you know of any other symptoms of illness, please forward them along to me and rrgroup at merit.edu. Since I have heard nothing back from my earlier report to them, it seems safest to assume that the RA does not yet know what the problem is and could use as much data as possible to isolate it. Don't cc: the full distribution. We'll notify the full list as some sort of resolution is reached. RA folk, if there is another list which is more appropriate to send trouble reports to, let me know. Thanks, Selina In this example, the RADB object for 194.128/15 does not show unless the netmask is specified - only the RIPE object shows. ======================================================================== bugsy-sfp:/u/sfp: whois -h whois.ra.net 194.128 route: 194.128.0.0/15 descr: PIPEX-BLOCK3 origin: AS1849 advisory: AS690 1:1849 2:701(147) 3:701(134) 4:1800 remarks: Holes to come! mnt-by: AS1849-MNT changed: tim at pipex.net 950428 source: RIPE bugsy-sfp:/u/sfp: !!/15 whois -h whois.ra.net 194.128/15 route: 194.128.0.0/15 descr: PIPEX Ltd descr: 216 Cambridge Science Park descr: Milton Road descr: Cambridge descr: England descr: CB4 4WA descr: UNITED KINGDOM origin: AS1849 comm-list: COMM_NSFNET advisory: AS690 1:1849 2:701(147) 4:1800 mnt-by: MAINT-AS1849 changed: support at pipex.net 950511 source: RADB route: 194.128.0.0/15 descr: PIPEX-BLOCK3 origin: AS1849 advisory: AS690 1:1849 2:701(147) 3:701(134) 4:1800 remarks: Holes to come! mnt-by: AS1849-MNT changed: tim at pipex.net 950428 source: RIPE wawa-selina:/u/selina: whois -h whois.ra.net 194.128.1.1 route: 194.128.0.0/15 descr: PIPEX-BLOCK3 origin: AS1849 advisory: AS690 1:1849 2:701(147) 3:701(134) 4:1800 remarks: Holes to come! mnt-by: AS1849-MNT changed: tim at pipex.net 950428 source: RIPE ======================================================================== Here, there are two routes for 192.5.4/23 (both of which show with a queriy to 192.5.4), yet only the RADB object shows when 192.5.5 is queried. ======================================================================== bugsy-sfp:/u/sfp: shownet 192.5.4 route: 192.5.4.0/23 descr: Vixie Enterprises descr: 116 Stanley Street descr: Redwood City descr: CA 94062, USA origin: AS3557 comm-list: COMM_NSFNET advisory: AS690 1:3561(11) 2:3561(218) 4:200(144) 5:701(147) mnt-by: MAINT-AS3557 changed: nsfnet-admin at merit.edu 950118 source: RADB route: 192.5.4.0/23 descr: NET-VIX2 origin: AS3557 advisory: AS690 1:3561(11) 2:3561(218) 3:200(128) 4:200(144) 5:701(147) ) mnt-by: BARRNET changed: vaf at valinor.barrnet.net 950111 source: MCI bugsy-sfp:/u/sfp: shownet 192.5.5 route: 192.5.5.0/24 descr: Vixie Enterprises descr: 116 Stanley Street descr: Redwood City descr: CA 94062, USA origin: AS3557 comm-list: COMM_NSFNET advisory: AS690 2:200(144) 3:701(147) mnt-by: MAINT-AS3557 changed: nsfnet-admin at merit.edu 940729 source: RADB route: 192.5.4.0/23 descr: NET-VIX2 origin: AS3557 advisory: AS690 1:3561(11) 2:3561(218) 3:200(128) 4:200(144) 5:701(147) ) mnt-by: BARRNET changed: vaf at valinor.barrnet.net 950111 source: MCI -------- Logged at Thu May 11 23:38:53 MET DST 1995 --------- From marten at BayNetworks.com Thu May 11 23:37:01 1995 From: marten at BayNetworks.com (Marten Terpstra) Date: Thu, 11 May 1995 17:37:01 -0400 Subject: Does this look familiar to anyone In-Reply-To: Your message of Thu, 11 May 1995 17:13:28 EDT. <199505112113.RAA29333@home.merit.edu> Message-ID: <9505112137.AA06891@class.wellfleet> Is one of these database indexed with the -p option? If it is, then it is a known bug (to me at least ;-) I can explain if you really want to know ;-) -Marten "Dale S. Johnson" writes * Anyone seen a bug like this before? * * Querying "194.128" (no /15" finds one net; with the /15 finds two): * * ('Haven't looked into any code about this yet...) * * --Dale * * ============ From: Selina Priestley * * > From selina at ans.net Thu May 11 14:56:56 1995 * > To: rrgroup at merit.edu * > Cc: heimlich at ans.net * > Subject: whois tool irregularity * > Reply-To: selina at ans.net * > Date: Thu, 11 May 1995 14:56:12 -0400 * > * > Isn't this odd? * > * > bugsy-sfp:/u/sfp: whois -h whois.ra.net 194.128 * > route: 194.128.0.0/15 * > descr: PIPEX-BLOCK3 * > origin: AS1849 * > advisory: AS690 1:1849 2:701(147) 3:701(134) 4:1800 * > remarks: Holes to come! * > mnt-by: AS1849-MNT * > changed: tim at pipex.net 950428 * > source: RIPE * > * > bugsy-sfp:/u/sfp: whois -h whois.ra.net 194.128/15 * > route: 194.128.0.0/15 * > descr: PIPEX Ltd * > descr: 216 Cambridge Science Park * > descr: Milton Road * > descr: Cambridge * > descr: England * > descr: CB4 4WA * > descr: UNITED KINGDOM * > origin: AS1849 * > comm-list: COMM_NSFNET * > advisory: AS690 1:1849 2:701(147) 4:1800 * > mnt-by: MAINT-AS1849 * > changed: support at pipex.net 950511 * > source: RADB * > * > route: 194.128.0.0/15 * > descr: PIPEX-BLOCK3 * > origin: AS1849 * > advisory: AS690 1:1849 2:701(147) 3:701(134) 4:1800 * > remarks: Holes to come! * > mnt-by: AS1849-MNT * > changed: tim at pipex.net 950428 * > source: RIPE * > * > Selina -------- Logged at Fri May 12 00:45:20 MET DST 1995 --------- From curtis at ans.net Fri May 12 00:13:53 1995 From: curtis at ans.net (Curtis Villamizar) Date: Thu, 11 May 1995 18:13:53 -0400 Subject: just an FYI - don't panic In-Reply-To: Your message of "Thu, 11 May 1995 15:42:38 EDT." <199505111942.PAA25372@lovefm.reston.mci.net> Message-ID: <199505112214.SAA12521@curtis.ansremote.com> In message <199505111942.PAA25372 at lovefm.reston.mci.net>, Tony Bates writes: > Curtis, > whay cant these lines be broken up with the current RIPE-181 > line wrap rules ? > > --Tony. Because ASxxx AND NOT { 1 2 3 4 5 } does not equal ASxxx AND NOT { 1 2 3 } ASxxx AND NOT { 4 5 } In other words: A AND NOT ( B OR C ) != ( A AND NOT B ) OR ( A AND NOT C ) for example: A = 1 2 3 4 5 B = 1 2 C = 3 A AND NOT ( B OR C ) -> 4 5 ( A AND NOT B ) -> 3 4 5 ( A AND NOT C ) -> 1 2 4 5 ( A AND NOT B ) OR ( A AND NOT C ) -> 1 2 3 4 5 Is that clear? The problem is in lists where ASxxx expands to a few thousand networks and there are perhaps a dozen legitimate exceptions (like DMZs) that get slightly different treatment. Curtis -------- Logged at Fri May 12 00:57:30 MET DST 1995 --------- From cengiz at ISI.EDU Fri May 12 00:57:25 1995 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Thu, 11 May 1995 15:57:25 -0700 Subject: just an FYI - don't panic In-Reply-To: <199505112214.SAA12521@curtis.ansremote.com> References: <199505111942.PAA25372@lovefm.reston.mci.net> <199505112214.SAA12521@curtis.ansremote.com> Message-ID: <199505112257.AA26819@cat.isi.edu> There is a way to do this with ripe-181 line continuations (at least according to the documentation, the tools (i.e. dbupdate) may not implement this correctly): as-in: ... accept ASxxx AND NOT { 1, 2, 3 as-in: ... accept , 4, 5} Note that ... must be identical on both lines. urtis Villamizar (curtis at ans.net) on May 11: > > In message <199505111942.PAA25372 at lovefm.reston.mci.net>, Tony Bates writes: > > Curtis, > > whay cant these lines be broken up with the current RIPE-181 > > line wrap rules ? > > > > --Tony. > > Because > > ASxxx AND NOT { 1 2 3 4 5 } > > does not equal > > ASxxx AND NOT { 1 2 3 } > ASxxx AND NOT { 4 5 } > > In other words: > > A AND NOT ( B OR C ) > > != > > ( A AND NOT B ) OR ( A AND NOT C ) > > for example: A = 1 2 3 4 5 > B = 1 2 > C = 3 > > A AND NOT ( B OR C ) -> 4 5 > > ( A AND NOT B ) -> 3 4 5 > ( A AND NOT C ) -> 1 2 4 5 > ( A AND NOT B ) OR ( A AND NOT C ) -> 1 2 3 4 5 > > Is that clear? > > The problem is in lists where ASxxx expands to a few thousand networks > and there are perhaps a dozen legitimate exceptions (like DMZs) that > get slightly different treatment. > > Curtis Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California http://www.isi.edu/div7/people/cengiz.home -------- Logged at Fri May 12 01:08:49 MET DST 1995 --------- From marten at BayNetworks.com Fri May 12 01:06:58 1995 From: marten at BayNetworks.com (Marten Terpstra) Date: Thu, 11 May 1995 19:06:58 -0400 Subject: just an FYI - don't panic In-Reply-To: Your message of Thu, 11 May 1995 15:57:25 PDT. <199505112257.AA26819@cat.isi.edu> Message-ID: <9505112306.AA06936@class.wellfleet> cengiz at ISI.EDU (Cengiz Alaettinoglu) writes * * There is a way to do this with ripe-181 line continuations (at least * according to the documentation, the tools (i.e. dbupdate) may not * implement this correctly): The tools understand the documented continuation lines (at least the tools I have been involved with ;-) The idea is that you can break up the policy expression anywhere, just repeat the neighbors and weights and continue on the next line. * as-in: ... accept ASxxx AND NOT { 1, 2, 3 * as-in: ... accept , 4, 5} * * Note that ... must be identical on both lines. Indeed. -Marten * * urtis Villamizar (curtis at ans.net) on May 11: * > * > In message <199505111942.PAA25372 at lovefm.reston.mci.net>, Tony Bates write * s: * > > Curtis, * > > whay cant these lines be broken up with the current RIPE-181 * > > line wrap rules ? * > > * > > --Tony. * > * > Because * > * > ASxxx AND NOT { 1 2 3 4 5 } * > * > does not equal * > * > ASxxx AND NOT { 1 2 3 } * > ASxxx AND NOT { 4 5 } * > * > In other words: * > * > A AND NOT ( B OR C ) * > * > != * > * > ( A AND NOT B ) OR ( A AND NOT C ) * > * > for example: A = 1 2 3 4 5 * > B = 1 2 * > C = 3 * > * > A AND NOT ( B OR C ) -> 4 5 * > * > ( A AND NOT B ) -> 3 4 5 * > ( A AND NOT C ) -> 1 2 4 5 * > ( A AND NOT B ) OR ( A AND NOT C ) -> 1 2 3 4 5 * > * > Is that clear? * > * > The problem is in lists where ASxxx expands to a few thousand networks * > and there are perhaps a dozen legitimate exceptions (like DMZs) that * > get slightly different treatment. * > * > Curtis * * * Cengiz * * -- * Cengiz Alaettinoglu Information Sciences Institute * (310) 822-1511 University of Southern California * http://www.isi.edu/div7/people/cengiz.home -------- Logged at Sat May 13 02:37:03 MET DST 1995 --------- From curtis at ans.net Sat May 13 02:29:13 1995 From: curtis at ans.net (Curtis Villamizar) Date: Fri, 12 May 1995 20:29:13 -0400 Subject: just an FYI - don't panic In-Reply-To: Your message of "Thu, 11 May 1995 15:57:25 PDT." <199505112257.AA26819@cat.isi.edu> Message-ID: <199505130030.UAA25472@curtis.ansremote.com> In message <199505112257.AA26819 at cat.isi.edu>, Cengiz Alaettinoglu writes: > > There is a way to do this with ripe-181 line continuations (at least > according to the documentation, the tools (i.e. dbupdate) may not > implement this correctly): > > as-in: ... accept ASxxx AND NOT { 1, 2, 3 > as-in: ... accept , 4, 5} > > Note that ... must be identical on both lines. Hey that does seem to work. Oops. Sorry Tony. Is it OK if I added about 4 lines of code in enparse.pl to do Unix style backslash at the end of the line continuation? Curtis -------- Logged at Mon May 15 22:29:15 MET DST 1995 --------- From renaud at merit.edu Mon May 15 22:27:29 1995 From: renaud at merit.edu (Brian Renaud) Date: Mon, 15 May 1995 16:27:29 -0400 Subject: inet-rtr support Message-ID: <9505152027.AA01461@yurt.merit.edu> Our dbupdate doesn't seem to accept inet-rtr objects. We made a quick tour of the code and couldn't find any support for these. Are we just missing some important bit of magic? -Brian -------- Logged at Tue May 16 02:06:14 MET DST 1995 --------- From dsj at merit.edu Tue May 16 02:05:55 1995 From: dsj at merit.edu (Dale S. Johnson) Date: Mon, 15 May 1995 20:05:55 -0400 Subject: just an FYI - don't panic Message-ID: <199505160005.UAA16590@home.merit.edu> Curtis, > From curtis at curtis.ansremote.com Fri May 12 20:38:24 1995 > To: cengiz at isi.edu (Cengiz Alaettinoglu) > Cc: curtis at ans.net, Tony Bates , rr-impl at ripe.net, > heimlich at ans.net, selina at ans.net > Reply-To: curtis at ans.net > Subject: Re: just an FYI - don't panic > Date: Fri, 12 May 1995 20:29:13 -0400 > > > In message <199505112257.AA26819 at cat.isi.edu>, Cengiz Alaettinoglu writes: > > > > There is a way to do this with ripe-181 line continuations (at least > > according to the documentation, the tools (i.e. dbupdate) may not > > implement this correctly): > > > > as-in: ... accept ASxxx AND NOT { 1, 2, 3 > > as-in: ... accept , 4, 5} > > > > Note that ... must be identical on both lines. > > > Hey that does seem to work. Oops. Sorry Tony. > > Is it OK if I added about 4 lines of code in enparse.pl to do Unix > style backslash at the end of the line continuation? This is a great idea; I think it should be done. But... in order for this idea to be completely implemented, the change has to be installed in Amsterdam, Reston, and Toronto as well as Ann Arbor; and probably several places (ESNet, DSI, NASA, APNIC) that we aren't sure of yet. Also, is enparse.pl part of any of the tools? Then it needs to be changed in all the copies of those tools that anyone has FTP'd as well. -------- Logged at Tue May 16 03:09:32 MET DST 1995 --------- From cengiz at ISI.EDU Tue May 16 03:09:30 1995 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Mon, 15 May 1995 18:09:30 -0700 Subject: just an FYI - don't panic In-Reply-To: <199505160005.UAA16590@home.merit.edu> References: <199505160005.UAA16590@home.merit.edu> Message-ID: <199505160109.AA09707@cat.isi.edu> Dale S. Johnson (dsj at merit.edu) on May 15: > Curtis, > > > From curtis at curtis.ansremote.com Fri May 12 20:38:24 1995 > > To: cengiz at isi.edu (Cengiz Alaettinoglu) > > Cc: curtis at ans.net, Tony Bates , rr-impl at ripe.net, > > heimlich at ans.net, selina at ans.net > > Reply-To: curtis at ans.net > > Subject: Re: just an FYI - don't panic > > Date: Fri, 12 May 1995 20:29:13 -0400 > > > > > > In message <199505112257.AA26819 at cat.isi.edu>, Cengiz Alaettinoglu writes: > > > > > > There is a way to do this with ripe-181 line continuations (at least > > > according to the documentation, the tools (i.e. dbupdate) may not > > > implement this correctly): > > > > > > as-in: ... accept ASxxx AND NOT { 1, 2, 3 > > > as-in: ... accept , 4, 5} > > > > > > Note that ... must be identical on both lines. > > > > > > Hey that does seem to work. Oops. Sorry Tony. > > > > Is it OK if I added about 4 lines of code in enparse.pl to do Unix > > style backslash at the end of the line continuation? > > This is a great idea; I think it should be done. But... > > in order for this idea to be completely implemented, the change has to > be installed in Amsterdam, Reston, and Toronto as well as Ann Arbor; > and probably several places (ESNet, DSI, NASA, APNIC) that we aren't > sure of yet. > > Also, is enparse.pl part of any of the tools? Then it needs to be > changed in all the copies of those tools that anyone has FTP'd as > well. > In addition, if the whois/radbserver returns result with Unix style backslashes, all the tools (pr*, peval) need to recognise them as well. I am still for this change since we still have few tools. But perhaps we should add this when we add support for rpsl at which time we need to upgrade all tools anyway. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California http://www.isi.edu/div7/people/cengiz.home -------- Logged at Tue May 16 03:21:26 MET DST 1995 --------- From heimlich at ans.net Tue May 16 03:20:44 1995 From: heimlich at ans.net (Steve Heimlich) Date: Mon, 15 May 1995 21:20:44 -0400 Subject: just an FYI - don't panic In-Reply-To: Your message of Mon, 15 May 1995 20:05:55 EDT. <199505160005.UAA16590@home.merit.edu> Message-ID: <199505160120.AA54972@interlock.ans.net> Dale, Who will act as coordinator to get this stuff distributed? I assume that the RA in the U.S. can take the lead in this role if we were to provide source. Thanks, Steve > > Is it OK if I added about 4 lines of code in enparse.pl to do Unix > > style backslash at the end of the line continuation? > > This is a great idea; I think it should be done. But... > > in order for this idea to be completely implemented, the change has to > be installed in Amsterdam, Reston, and Toronto as well as Ann Arbor; > and probably several places (ESNet, DSI, NASA, APNIC) that we aren't > sure of yet. > > Also, is enparse.pl part of any of the tools? Then it needs to be > changed in all the copies of those tools that anyone has FTP'd as > well. -------- Logged at Tue May 16 03:34:15 MET DST 1995 --------- From curtis at ans.net Tue May 16 03:26:07 1995 From: curtis at ans.net (Curtis Villamizar) Date: Mon, 15 May 1995 21:26:07 -0400 Subject: inet-rtr support In-Reply-To: Your message of "Mon, 15 May 1995 16:27:29 EDT." <9505152027.AA01461@yurt.merit.edu> Message-ID: <199505160127.VAA03375@curtis.ansremote.com> In message <9505152027.AA01461 at yurt.merit.edu>, Brian Renaud writes: > > Our dbupdate doesn't seem to accept inet-rtr objects. We made a > quick tour of the code and couldn't find any support for these. > > Are we just missing some important bit of magic? > > -Brian Uncomment the inet-rtr objects from the config file. They are commented out. Mine looks like this: # inet-rtr # OBJ ir ATSQ ir la if pe ac tc rm ny mb ch so OBJ ir MAND ir la if tc ac ch so OBJ ir OPT pe ny mb rm OBJ ir MULT if pe tc ac rm ny ch mb OBJ ir SORT 9 OBJ ir UNIQ ir OBJ ir KEYS ir if OBJ ir REC tc ac Curtis -------- Logged at Tue May 16 03:38:37 MET DST 1995 --------- From dsj at merit.edu Tue May 16 03:38:14 1995 From: dsj at merit.edu (Dale S. Johnson) Date: Mon, 15 May 1995 21:38:14 -0400 Subject: just an FYI - don't panic Message-ID: <199505160138.VAA17855@home.merit.edu> Steve, > Who will act as coordinator to get this stuff distributed? I assume > that the RA in the U.S. can take the lead in this role if we were to > provide source. The only thing close to an official answer to this question at the moment is that RIPE is the home and custodian of the official distribution source. At the RA, we've been trying rather hard to minimize any modifications to RIPE code, if only to simplify importing further revisions of their code. (But not making modifications is getting harder, as we get user pressure to make email address parsing case-insensitive, add PGP, [add inet-rtr support, if we aren't just looking for it in the wrong places today], etc). The RA does post the radbserver (rpslserver) and RtConfig tookkit distributions, which are separable packages from the RIPE distribution. If we were to package and post our own "RIPE-181-modified by the RA" distribution today, there might be some considerable confusion. The RA is generally willing to install Curtis' changes in our implementation, though this needs discussion with the list since our accepting such non-181 syntax would probably break implementations and/or tools of other registries (such as RIPE itself) which import that data and make it available to their tools (like prtraceroute). Clearly this all needs sorting out. (Maybe starting in the halls at NANOG?) But for the moment, the answer is that RIPE is the custodian. --Dale ============ From: Steve Heimlich > From heimlich at ans.net Mon May 15 21:21:43 1995 > To: "Dale S. Johnson" > Cc: cengiz at isi.edu, curtis at ans.net, Tony.Bates at ns.mci.net, rr-impl at ripe.net, > selina at ans.net > Subject: Re: just an FYI - don't panic > Date: Mon, 15 May 1995 21:20:44 -0400 > > Dale, > > Who will act as coordinator to get this stuff distributed? I assume > that the RA in the U.S. can take the lead in this role if we were to > provide source. > > Thanks, > Steve > > > > Is it OK if I added about 4 lines of code in enparse.pl to do Unix > > > style backslash at the end of the line continuation? > > > > This is a great idea; I think it should be done. But... > > > > in order for this idea to be completely implemented, the change has to > > be installed in Amsterdam, Reston, and Toronto as well as Ann Arbor; > > and probably several places (ESNet, DSI, NASA, APNIC) that we aren't > > sure of yet. > > > > Also, is enparse.pl part of any of the tools? Then it needs to be > > changed in all the copies of those tools that anyone has FTP'd as > > well. -------- Logged at Tue May 16 03:42:05 MET DST 1995 --------- From dsj at merit.edu Tue May 16 03:41:45 1995 From: dsj at merit.edu (Dale S. Johnson) Date: Mon, 15 May 1995 21:41:45 -0400 Subject: inet-rtr support Message-ID: <199505160141.VAA17910@home.merit.edu> Curtis, As does ours: # inet-rtr # OBJ ir ATSQ ir la if pe ac tc rm ny mb ch so OBJ ir MAND ir la if tc ac ch so OBJ ir OPT pe ny mb rm OBJ ir MULT if pe tc ac rm ny ch mb OBJ ir SORT 9 OBJ ir UNIQ ir OBJ ir KEYS ir if OBJ ir REC tc ac You say your implementation does accept inet-rtr objects? Would you try this one: inet-rtr: nss11.ans.net localas: AS690 ifaddr: 140.222.11.1 255.255.255.0 ifaddr: 140.222.11.2 255.255.255.0 ifaddr: 140.222.11.3 255.255.255.0 ifaddr: 140.222.11.5 255.255.255.0 ifaddr: 140.222.11.62 255.255.255.0 ifaddr: 140.222.8.195 255.255.255.0 ifaddr: 192.103.60.5 255.255.255.0 ifaddr: 198.32.128.66 255.255.255.0 ifaddr: 199.221.47.5 255.255.255.0 peer: 140.222.8.196 AS1321 BGP passive peer: 198.32.128.226 AS1688 BGP passive peer: 198.32.128.65 AS1688 BGP passive peer: 199.221.47.7 AS1957 BGP passive peer: 198.32.128.20 AS2041 BGP passive peer: 198.32.128.130 AS2882 BGP passive peer: 198.32.128.67 AS3561 BGP passive peer: 198.32.128.97 AS3561 BGP passive peer: 198.32.128.16 AS3830 BGP passive admin-c Steve Heimlich tech-c: Selina Priestley mnt-by: ANS changed: nsfnet-admin at merit.edu 950227 source: RADB --Dale ============ From: Curtis Villamizar > From curtis at curtis.ansremote.com Mon May 15 21:35:24 1995 > To: Brian Renaud > Cc: rr-impl at ripe.net > Reply-To: curtis at ans.net > Subject: Re: inet-rtr support > Date: Mon, 15 May 1995 21:26:07 -0400 > > > In message <9505152027.AA01461 at yurt.merit.edu>, Brian Renaud writes: > > > > Our dbupdate doesn't seem to accept inet-rtr objects. We made a > > quick tour of the code and couldn't find any support for these. > > > > Are we just missing some important bit of magic? > > > > -Brian > > Uncomment the inet-rtr objects from the config file. They are > commented out. > > Mine looks like this: > > # inet-rtr > # > OBJ ir ATSQ ir la if pe ac tc rm ny mb ch so > OBJ ir MAND ir la if tc ac ch so > OBJ ir OPT pe ny mb rm > OBJ ir MULT if pe tc ac rm ny ch mb > OBJ ir SORT 9 > OBJ ir UNIQ ir > OBJ ir KEYS ir if > OBJ ir REC tc ac > > Curtis -------- Logged at Tue May 16 03:44:39 MET DST 1995 --------- From heimlich at ans.net Tue May 16 03:43:56 1995 From: heimlich at ans.net (Steve Heimlich) Date: Mon, 15 May 1995 21:43:56 -0400 Subject: just an FYI - don't panic In-Reply-To: Your message of Mon, 15 May 1995 21:38:14 EDT. <199505160138.VAA17855@home.merit.edu> Message-ID: <199505160143.AA20521@interlock.ans.net> Ok, reasonable answer. I think there's a large issue of operational coordination and support (at least from the U.S. RA) to which I alluded in some earlier email (not everyone included here). This is bound to come up at NANOG, which is a good thing. Steve > Steve, > > > Who will act as coordinator to get this stuff distributed? I assume > > that the RA in the U.S. can take the lead in this role if we were to > > provide source. > > The only thing close to an official answer to this question at the moment > is that RIPE is the home and custodian of the official distribution > source. > > At the RA, we've been trying rather hard to minimize any modifications to > RIPE code, if only to simplify importing further revisions of their code. > (But not making modifications is getting harder, as we get user pressure > to make email address parsing case-insensitive, add PGP, [add inet-rtr > support, if we aren't just looking for it in the wrong places today], > etc). > > The RA does post the radbserver (rpslserver) and RtConfig tookkit > distributions, which are separable packages from the RIPE distribution. > If we were to package and post our own "RIPE-181-modified by the RA" > distribution today, there might be some considerable confusion. > > The RA is generally willing to install Curtis' changes in our > implementation, though this needs discussion with the list since > our accepting such non-181 syntax would probably break implementations > and/or tools of other registries (such as RIPE itself) which import > that data and make it available to their tools (like prtraceroute). > > Clearly this all needs sorting out. (Maybe starting in the halls at > NANOG?) But for the moment, the answer is that RIPE is the custodian. > > --Dale > > > ============ From: Steve Heimlich > > > From heimlich at ans.net Mon May 15 21:21:43 1995 > > To: "Dale S. Johnson" > > Cc: cengiz at isi.edu, curtis at ans.net, Tony.Bates at ns.mci.net, rr-impl at ripe.net > , > > selina at ans.net > > Subject: Re: just an FYI - don't panic > > Date: Mon, 15 May 1995 21:20:44 -0400 > > > > Dale, > > > > Who will act as coordinator to get this stuff distributed? I assume > > that the RA in the U.S. can take the lead in this role if we were to > > provide source. > > > > Thanks, > > Steve > > > > > > Is it OK if I added about 4 lines of code in enparse.pl to do Unix > > > > style backslash at the end of the line continuation? > > > > > > This is a great idea; I think it should be done. But... > > > > > > in order for this idea to be completely implemented, the change has to > > > be installed in Amsterdam, Reston, and Toronto as well as Ann Arbor; > > > and probably several places (ESNet, DSI, NASA, APNIC) that we aren't > > > sure of yet. > > > > > > Also, is enparse.pl part of any of the tools? Then it needs to be > > > changed in all the copies of those tools that anyone has FTP'd as > > > well. -------- Logged at Tue May 16 04:09:14 MET DST 1995 --------- From curtis at ans.net Tue May 16 04:04:06 1995 From: curtis at ans.net (Curtis Villamizar) Date: Mon, 15 May 1995 22:04:06 -0400 Subject: just an FYI - don't panic In-Reply-To: Your message of "Mon, 15 May 1995 20:05:55 EDT." <199505160005.UAA16590@home.merit.edu> Message-ID: <199505160205.WAA03484@curtis.ansremote.com> In message <199505160005.UAA16590 at home.merit.edu>, "Dale S. Johnson" writes: > Curtis, > > > From curtis at curtis.ansremote.com Fri May 12 20:38:24 1995 > > To: cengiz at isi.edu (Cengiz Alaettinoglu) > > Cc: curtis at ans.net, Tony Bates , rr-impl at ripe.net, > > heimlich at ans.net, selina at ans.net > > Reply-To: curtis at ans.net > > Subject: Re: just an FYI - don't panic > > Date: Fri, 12 May 1995 20:29:13 -0400 > > > > > > In message <199505112257.AA26819 at cat.isi.edu>, Cengiz Alaettinoglu writes: > > > > > > There is a way to do this with ripe-181 line continuations (at least > > > according to the documentation, the tools (i.e. dbupdate) may not > > > implement this correctly): > > > > > > as-in: ... accept ASxxx AND NOT { 1, 2, 3 > > > as-in: ... accept , 4, 5} > > > > > > Note that ... must be identical on both lines. > > > > > > Hey that does seem to work. Oops. Sorry Tony. > > > > Is it OK if I added about 4 lines of code in enparse.pl to do Unix > > style backslash at the end of the line continuation? > > This is a great idea; I think it should be done. But... > > in order for this idea to be completely implemented, the change has to > be installed in Amsterdam, Reston, and Toronto as well as Ann Arbor; > and probably several places (ESNet, DSI, NASA, APNIC) that we aren't > sure of yet. > > Also, is enparse.pl part of any of the tools? Then it needs to be > changed in all the copies of those tools that anyone has FTP'd as > well. Dale, It's not really that bad. If enparse.pl is fixed on the machine to which the object is submitted, the adjacent lines go through the mail with no damage and then get put in the database as one big line. Since this is the last time mildly broken mail systems will get to corrupt this entry (hopefully whois can deal with long lines), no one will ever know how this long line got in there. Curtis ps- The change is the part below after the comment. Since there were other changes, the context diff probably wouldn't work, so just edit it in if you want this. (also "local($more);" doesn't hurt). sub readsomething { ... while (<$file>) { # normal Unix style line continuation while (s/\\\s*$//) { last if (!($more = <$file>)); $_ .= $more; } -------- Logged at Tue May 16 11:31:21 MET DST 1995 --------- From Daniel.Karrenberg at ripe.net Tue May 16 11:31:18 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 16 May 1995 11:31:18 +0200 Subject: just an FYI - don't panic In-Reply-To: Your message of Mon, 15 May 1995 21:38:14 EDT. <199505160138.VAA17855@home.merit.edu> Message-ID: <9505160931.AA11235@ncc.ripe.net> As far as the RIPE database software is concerned, the RIPE NCC has been "home of the source" and I propose to keep it so. While we are not as lavishly endowed with resources ;-) as the RA is, we do have enough to do this task. If anyone has bug fixes or improvements, please send them to or this list. Both people maintaining the software, David Kessens and myself, will be at NANOG. As to the \ continuations, we will include them in the current release. As to PGP, a major design issue needs to be solved first: Where to store the public keys. It seems that the RA team is prepared to maintain the keys manually and separately from the database proper. Given the immediate number of updates this may be feasible. In the long run it might be better to store the keys as part of the maintainer object itself. Daniel -------- Logged at Tue May 16 14:48:20 MET DST 1995 --------- From David.Kessens at ripe.net Tue May 16 14:48:13 1995 From: David.Kessens at ripe.net (RIPE NCC Staff) Date: Tue, 16 May 1995 14:48:13 +0200 Subject: just an FYI - don't panic In-Reply-To: Your message of Mon, 15 May 1995 21:38:14 EDT. <199505160138.VAA17855@home.merit.edu> Message-ID: <9505161248.AA13358@ncc.ripe.net> Dear Dale, * "Dale S. Johnson" writes: * Steve, * * > Who will act as coordinator to get this stuff distributed? I assume * > that the RA in the U.S. can take the lead in this role if we were to * > provide source. * * The only thing close to an official answer to this question at the moment * is that RIPE is the home and custodian of the official distribution * source. * * At the RA, we've been trying rather hard to minimize any modifications to * RIPE code, if only to simplify importing further revisions of their code. Thank you ! * (But not making modifications is getting harder, as we get user pressure * to make email address parsing case-insensitive, add PGP, [add inet-rtr * support, if we aren't just looking for it in the wrong places today], * etc). I think that most of things you mention here are exactly the same as the wishlist of the RIPE community so for that there is no need for a divergence ;-) The inet-rtr support is there, although it is not very visible since it uses only generic attributes as admin-c and others. Please note that you forgot a colon after the admin-c attribute in your previous mail. After adding that the inet-rtr object was properly updated : ------------------------------------------------------------------------ Update OK: [inet-rtr] nss11.ans.net Delete OK: [inet-rtr] nss11.ans.net ------------------------------------------------------------------------ * The RA does post the radbserver (rpslserver) and RtConfig tookkit * distributions, which are separable packages from the RIPE distribution. * If we were to package and post our own "RIPE-181-modified by the RA" * distribution today, there might be some considerable confusion. * * The RA is generally willing to install Curtis' changes in our * implementation, though this needs discussion with the list since * our accepting such non-181 syntax would probably break implementations * and/or tools of other registries (such as RIPE itself) which import * that data and make it available to their tools (like prtraceroute). (Syntax) changes (not the implementation details!) are normally discussed in the RIPE database working group. After we reach consensus the changes will be implemented. I would strongly ask you all to join the discussion on the as that is probably the most appropriate platform to discuss these issues. For example the case-sensitive E-mail parsing could be changed if our contributors and you all ask for it ! * Clearly this all needs sorting out. (Maybe starting in the halls at * NANOG?) But for the moment, the answer is that RIPE is the custodian. I hope to see you all in the halls ;-), Kind regards, David Kessens RIPE NCC Database maintainer ----------- * ============ From: Steve Heimlich * * > From heimlich at ans.net Mon May 15 21:21:43 1995 * > To: "Dale S. Johnson" * > Cc: cengiz at isi.edu, curtis at ans.net, Tony.Bates at ns.mci.net, rr-impl at ripe.ne * t, * > selina at ans.net * > Subject: Re: just an FYI - don't panic * > Date: Mon, 15 May 1995 21:20:44 -0400 * > * > Dale, * > * > Who will act as coordinator to get this stuff distributed? I assume * > that the RA in the U.S. can take the lead in this role if we were to * > provide source. * > * > Thanks, * > Steve * > * > > > Is it OK if I added about 4 lines of code in enparse.pl to do Unix * > > > style backslash at the end of the line continuation? * > > * > > This is a great idea; I think it should be done. But... * > > * > > in order for this idea to be completely implemented, the change has to * > > be installed in Amsterdam, Reston, and Toronto as well as Ann Arbor; * > > and probably several places (ESNet, DSI, NASA, APNIC) that we aren't * > > sure of yet. * > > * > > Also, is enparse.pl part of any of the tools? Then it needs to be * > > changed in all the copies of those tools that anyone has FTP'd as * > > well. -------- Logged at Tue May 16 14:48:55 MET DST 1995 --------- From renaud at merit.edu Tue May 16 14:48:51 1995 From: renaud at merit.edu (Brian D. Renaud) Date: Tue, 16 May 1995 08:48:51 -0400 Subject: just an FYI - don't panic Message-ID: <199505161248.IAA04817@home.merit.edu> I think we should try to get together at NANOG to decide what we're going to do to avoid source code divergence. Perhaps as a sidebar conversation at dinner... -Brian > From: Steve Heimlich > Subject: Re: just an FYI - don't panic > Date: Mon, 15 May 1995 21:20:44 -0400 > > Dale, > > Who will act as coordinator to get this stuff distributed? I assume > that the RA in the U.S. can take the lead in this role if we were to > provide source. > > Thanks, > Steve -------- Logged at Tue May 16 15:03:10 MET DST 1995 --------- From Tony.Bates at mci.net Tue May 16 15:02:13 1995 From: Tony.Bates at mci.net (Tony Bates) Date: Tue, 16 May 1995 09:02:13 -0400 Subject: just an FYI - don't panic In-Reply-To: Your message of Tue, 16 May 1995 08:48:51 EDT. <199505161248.IAA04817@home.merit.edu> Message-ID: <199505161302.JAA23732@lovefm.reston.mci.net> Just a small note on this. From my persective the RIPE folks should certainly be the keepers of the code. As shown, some of the requests are due to either not enough involvmenet in the RIPE-181 process (understandable but suggests more reading of that pesky paper ;-)) and also perhaps the fact that the documentation needs to be improved (inet-rtr router issue highlights this exaclty - this was coded in before we got agreement on the doc and then turned on the next day). As to the issue of divergence I do not think this is as difficult an issue as people are making it. I have a number of small things I've added (some of which I will be feeding back at some point) locally but by keeping a seperate copy of RIPE based specific module it is easy to patch things in. I do feel we may need to be a little more open to change but it is always a trade off of local over global need. If it is truly a global thing then it needs consensus amoung the community and this always takes time. As to a sidebar conversation I'll have to pass as I will not be at NANOG so I guess this is my input. --Tony. "Brian D. Renaud" writes: * * I think we should try to get together at NANOG to decide what we're * going to do to avoid source code divergence. Perhaps as a sidebar * conversation at dinner... * * -Brian * * > From: Steve Heimlich * > Subject: Re: just an FYI - don't panic * > Date: Mon, 15 May 1995 21:20:44 -0400 * > * > Dale, * > * > Who will act as coordinator to get this stuff distributed? I assume * > that the RA in the U.S. can take the lead in this role if we were to * > provide source. * > * > Thanks, * > Steve -------- Logged at Tue May 16 15:41:32 MET DST 1995 --------- From eric at enfm.utcc.utoronto.ca Tue May 16 15:40:45 1995 From: eric at enfm.utcc.utoronto.ca (Eric M. Carroll) Date: Tue, 16 May 1995 09:40:45 -0400 Subject: just an FYI - don't panic In-Reply-To: Daniel.Karrenberg's message of "Tue, 16 May 1995 05:31:18 -0400". <9505160931.AA11235@ncc.ripe.net> Message-ID: <95May16.094104edt.606849@enfm.utcc.utoronto.ca> > As to PGP, a major design issue needs to be solved first: Where to store > the public keys. It seems that the RA team is prepared to maintain the > keys manually and separately from the database proper. Given the immediate > number of updates this may be feasible. In the long run it might be better > to store the keys as part of the maintainer object itself. Daniel, For the moment, I think the need to have your code support PGP object authentication, leaving key management explicitly out of band, is large enough to warrent support. We certainly do not mind having key management as an out of band activity, at least initially. We do, however, want something stronger than the current system. I would like to be able to sign an entire database, as well. We currently maintain what is effectively a local and exported version of our database. The exported version may have aggregates surpressed, advisory tags added, etc for the happiness of the downstream ACL builder. Right now, this is somewhat easier than trying to get users to maintain community strings. The local db version has everything. Signing the published db would be a positive check on whether it is authentic or not. While I recognize it does not scale and that we need something else, I actually *like* the idea of OOB key management. The reason is that I view the database as an repository of the transactions of a trusted administrative relationship. OOB key management is just another opportunity to find out who it is I am actually about to trust. Maybe the RA could set up a PGP key server as a value added service for routing coordination? Eric Carroll University of Toronto Network & Operations Services External Networking Facilities Management -------- Logged at Tue May 16 16:20:41 MET DST 1995 --------- From curtis at ans.net Tue May 16 16:09:31 1995 From: curtis at ans.net (Curtis Villamizar) Date: Tue, 16 May 1995 10:09:31 -0400 Subject: DON'T PANIC!!! Message-ID: <199505161410.KAA00301@curtis.ansremote.com> Please read the subject and read the four line patch. No data that is incompatible with RIPE tools will be introduced to the database. The problem that is being avoided is submitting objects through certain mail systems that truncate or otherwise munge lines that are longer than expected. For some mail systems this is 256 characters for others it is 80 characters or less. This change allows a simple proprossing that allows arbitrarily long RIPE lines to go through the mail undamaged and then quickly get reassembled at the other end putting it back in the format of just plain long RIPE lines with no continuation. If your copy of perl can't handle long lines, you've got a serious problem since perl is supposed to handle arbitrarily long lines. There is no need for a worldwide redistribution of tools, so please *don't panic*. Curtis ------- Forwarded Message Received: from interlock.ans.net by wawa.ans.net with SMTP id AA08790 (5.65c/IDA-1.4.4 for ); Tue, 16 May 1995 01:35:50 GMT Received: from home.merit.edu by interlock.ans.net with SMTP id AA20487 (InterLock SMTP Gateway 3.0 for ); Mon, 15 May 1995 21:38:15 -0400 Received: (from dsj at localhost) by home.merit.edu (8.6.12/merit-2.0) id VAA17855; Mon, 15 May 1995 21:38:14 -0400 Date: Mon, 15 May 1995 21:38:14 -0400 From: "Dale S. Johnson" Message-Id: <199505160138.VAA17855 at home.merit.edu> To: dsj at merit.edu, heimlich at ans.net Subject: Re: just an FYI - don't panic Cc: Tony.Bates at ns.mci.net, cengiz at isi.edu, curtis at ans.net, rr-impl at ripe.net, selina at ans.net Steve, > Who will act as coordinator to get this stuff distributed? I assume > that the RA in the U.S. can take the lead in this role if we were to > provide source. The only thing close to an official answer to this question at the moment is that RIPE is the home and custodian of the official distribution source. At the RA, we've been trying rather hard to minimize any modifications to RIPE code, if only to simplify importing further revisions of their code. (But not making modifications is getting harder, as we get user pressure to make email address parsing case-insensitive, add PGP, [add inet-rtr support, if we aren't just looking for it in the wrong places today], etc). The RA does post the radbserver (rpslserver) and RtConfig tookkit distributions, which are separable packages from the RIPE distribution. If we were to package and post our own "RIPE-181-modified by the RA" distribution today, there might be some considerable confusion. The RA is generally willing to install Curtis' changes in our implementation, though this needs discussion with the list since our accepting such non-181 syntax would probably break implementations and/or tools of other registries (such as RIPE itself) which import that data and make it available to their tools (like prtraceroute). Clearly this all needs sorting out. (Maybe starting in the halls at NANOG?) But for the moment, the answer is that RIPE is the custodian. - --Dale ============ From: Steve Heimlich > From heimlich at ans.net Mon May 15 21:21:43 1995 > To: "Dale S. Johnson" > Cc: cengiz at isi.edu, curtis at ans.net, Tony.Bates at ns.mci.net, rr-impl at ripe.net, > selina at ans.net > Subject: Re: just an FYI - don't panic > Date: Mon, 15 May 1995 21:20:44 -0400 > > Dale, > > Who will act as coordinator to get this stuff distributed? I assume > that the RA in the U.S. can take the lead in this role if we were to > provide source. > > Thanks, > Steve > > > > Is it OK if I added about 4 lines of code in enparse.pl to do Unix > > > style backslash at the end of the line continuation? > > > > This is a great idea; I think it should be done. But... > > > > in order for this idea to be completely implemented, the change has to > > be installed in Amsterdam, Reston, and Toronto as well as Ann Arbor; > > and probably several places (ESNet, DSI, NASA, APNIC) that we aren't > > sure of yet. > > > > Also, is enparse.pl part of any of the tools? Then it needs to be > > changed in all the copies of those tools that anyone has FTP'd as > > well. ------- End of Forwarded Message -------- Logged at Tue May 16 16:35:21 MET DST 1995 --------- From David.Kessens at ripe.net Tue May 16 16:35:17 1995 From: David.Kessens at ripe.net (David.Kessens at ripe.net) Date: Tue, 16 May 1995 16:35:17 +0200 (MET DST) Subject: DON'T PANIC!!! In-Reply-To: <199505161410.KAA00301@curtis.ansremote.com> from "Curtis Villamizar" at May 16, 95 10:09:31 am Message-ID: <9505161435.AA01979@mature.ripe.net> A non-text attachment was scrubbed... Name: not available Type: text Size: 4658 bytes Desc: not available Url : https://www.ripe.net/mailman/private/rr-impl/attachments/19950516/ce2a3a4c/attachment.pl From dsj at merit.edu Tue May 16 16:57:29 1995 From: dsj at merit.edu (Dale S. Johnson) Date: Tue, 16 May 1995 10:57:29 -0400 Subject: just an FYI - don't panic Message-ID: <199505161457.KAA09155@home.merit.edu> David, AAAAAARRRRRRRRRRRRGGGGGGGGGGGHHHHHHHHHHH!!!! THAT SIMPLE!!! Thanks extremely for the extra set of eyes. (sigh). --Dale > The inet-rtr support is there, although it is not very visible since it > uses only generic attributes as admin-c and others. Please note that you > forgot a colon after the admin-c attribute in your previous mail. After > adding that the inet-rtr object was properly updated : > > ------------------------------------------------------------------------ > Update OK: [inet-rtr] nss11.ans.net > > Delete OK: [inet-rtr] nss11.ans.net > ------------------------------------------------------------------------ -------- Logged at Tue May 16 17:19:03 MET DST 1995 --------- From curtis at ans.net Tue May 16 16:30:04 1995 From: curtis at ans.net (Curtis Villamizar) Date: Tue, 16 May 1995 10:30:04 -0400 Subject: inet-rtr support In-Reply-To: Your message of "Mon, 15 May 1995 21:41:45 EDT." <199505160141.VAA17910@home.merit.edu> Message-ID: <199505161431.KAA00365@curtis.ansremote.com> In message <199505160141.VAA17910 at home.merit.edu>, "Dale S. Johnson" writes: > Curtis, > > As does ours: > > # inet-rtr > # > OBJ ir ATSQ ir la if pe ac tc rm ny mb ch so > OBJ ir MAND ir la if tc ac ch so > OBJ ir OPT pe ny mb rm > OBJ ir MULT if pe tc ac rm ny ch mb > OBJ ir SORT 9 > OBJ ir UNIQ ir > OBJ ir KEYS ir if > OBJ ir REC tc ac > > You say your implementation does accept inet-rtr objects? > > Would you try this one: > > inet-rtr: nss11.ans.net > localas: AS690 > ifaddr: 140.222.11.1 255.255.255.0 > ifaddr: 140.222.11.2 255.255.255.0 > ifaddr: 140.222.11.3 255.255.255.0 > ifaddr: 140.222.11.5 255.255.255.0 > ifaddr: 140.222.11.62 255.255.255.0 > ifaddr: 140.222.8.195 255.255.255.0 > ifaddr: 192.103.60.5 255.255.255.0 > ifaddr: 198.32.128.66 255.255.255.0 > ifaddr: 199.221.47.5 255.255.255.0 > peer: 140.222.8.196 AS1321 BGP passive > peer: 198.32.128.226 AS1688 BGP passive > peer: 198.32.128.65 AS1688 BGP passive > peer: 199.221.47.7 AS1957 BGP passive > peer: 198.32.128.20 AS2041 BGP passive > peer: 198.32.128.130 AS2882 BGP passive > peer: 198.32.128.67 AS3561 BGP passive > peer: 198.32.128.97 AS3561 BGP passive > peer: 198.32.128.16 AS3830 BGP passive > admin-c Steve Heimlich > tech-c: Selina Priestley > mnt-by: ANS > changed: nsfnet-admin at merit.edu 950227 > source: RADB > > --Dale Dale, I sent you a set of route objects. What happen to them? Please note the following: nslookup nss11.ans.net Server: localhost Address: 127.0.0.1 *** localhost can't find nss11.ans.net: Non-existent host/domain nslookup cnss11.t3.ans.net Server: localhost Address: 127.0.0.1 Name: cnss11.San-Francisco.t3.ans.net Address: 140.222.11.62 Aliases: cnss11.t3.ans.net hint: If (# < 128) { use cnss# } else { use enss# }. The Problem above is that the admin-c line does not have a ":" This worked for me but I changed the database name and maintainer name to make the authorization pass. Please use the real DNS names so if people ever try to verify the existance of the routers, it will be possible to do so. Curtis ps- since you are not using the inet-rtr object I sent you, the interfaces are likely to be wrong and information in the remarks that we will actually use to generate configs will be missing. This is OK as long as you make sure that the maintainer objects allow us to modify these as well as you. For the time being, I'll just put the local ANS database ahead of RADB in the path. bin/dbupdate -m curtis at ans.net -v /tmp/dsj.object Update OK: [inet-rtr] nss11.ans.net No error/warnings were found in your database update. Congratulations. ------------------------------------------------------------------------ Please use instead of and instead of for fast turnaround times on all but guarded objects. If you have any question about an error or warning message, please contact . Sincerely Yours, ANS Database Maintenance Department (Automatic Section) [curtis at curtis.ansremote.com 22] cat !$ cat /tmp/dsj.object inet-rtr: nss11.ans.net localas: AS690 ifaddr: 140.222.11.1 255.255.255.0 ifaddr: 140.222.11.2 255.255.255.0 ifaddr: 140.222.11.3 255.255.255.0 ifaddr: 140.222.11.5 255.255.255.0 ifaddr: 140.222.11.62 255.255.255.0 ifaddr: 140.222.8.195 255.255.255.0 ifaddr: 192.103.60.5 255.255.255.0 ifaddr: 198.32.128.66 255.255.255.0 ifaddr: 199.221.47.5 255.255.255.0 peer: 140.222.8.196 AS1321 BGP passive peer: 198.32.128.226 AS1688 BGP passive peer: 198.32.128.65 AS1688 BGP passive peer: 199.221.47.7 AS1957 BGP passive peer: 198.32.128.20 AS2041 BGP passive peer: 198.32.128.130 AS2882 BGP passive peer: 198.32.128.67 AS3561 BGP passive peer: 198.32.128.97 AS3561 BGP passive peer: 198.32.128.16 AS3830 BGP passive admin-c: Steve Heimlich tech-c: Selina Priestley mnt-by: MAINT-AS690 changed: nsfnet-admin at merit.edu 950227 source: ANS -------- Logged at Tue May 16 17:41:31 MET DST 1995 --------- From Daniel.Karrenberg at ripe.net Tue May 16 17:41:27 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 16 May 1995 17:41:27 +0200 Subject: MAIL-FROM case sensitive? In-Reply-To: Your message of Thu, 11 May 1995 09:26:05 EDT. <199505111326.JAA07222@home.merit.edu> References: <199505111326.JAA07222@home.merit.edu> Message-ID: <9505161541.AA01843@ncc.ripe.net> > "Dale S. Johnson" writes: > Anyone, > > Is email address authentication using the MAIL-FROM lines really supposed > to be case-sensitive? It seems to be so on our implementation (and is > causing a *lot* of questions and bounces). It is a regex and should not have any confusing side-effects. As per RFC822 the localpart is indeed case-sensitive. It is a local decision to ignore case on localparts. > If it is intended this way, is there some gotcha we're likely to discover > if we make it case-insensitive? I'll make a note for a warning in the documentation. It should remain as is. Daniel -------- Logged at Tue May 16 17:42:39 MET DST 1995 --------- From curtis at ans.net Tue May 16 17:33:49 1995 From: curtis at ans.net (Curtis Villamizar) Date: Tue, 16 May 1995 11:33:49 -0400 Subject: just an FYI - don't panic In-Reply-To: Your message of "Tue, 16 May 1995 11:31:18 +0200." <9505160931.AA11235@ncc.ripe.net> Message-ID: <199505161534.LAA03283@curtis.ansremote.com> In message <9505160931.AA11235 at ncc.ripe.net>, Daniel Karrenberg writes: > > > As far as the RIPE database software is concerned, the RIPE NCC has been > "home of the source" and I propose to keep it so. While we are not as > lavishly endowed with resources ;-) as the RA is, we do have enough > to do this task. If anyone has bug fixes or improvements, please send > them to or this list. I second this motion, along with the numerous people that have already done so. :-) > Both people maintaining the software, David Kessens and myself, will be > at NANOG. > > As to the \ continuations, we will include them in the current release. > > As to PGP, a major design issue needs to be solved first: Where to store > the public keys. It seems that the RA team is prepared to maintain the > keys manually and separately from the database proper. Given the immediate > number of updates this may be feasible. In the long run it might be better > to store the keys as part of the maintainer object itself. > > Daniel I'll be sending another round of minor patches shortly, mostly things that speed the perl code up a little. I'm testing some of the changes on AIX, since the 32MB on my BSDI box seems to be a problem for netdbm due to fragmentation of memory by perl. I'm also going to give it one more shot on BSDI, this time without the Stanford memory allocator compiled into perl... Curtis -------- Logged at Thu May 18 16:38:32 MET DST 1995 --------- From jyy at merit.edu Thu May 18 16:37:40 1995 From: jyy at merit.edu (Jessica Yu (Jie Yun)) Date: Thu, 18 May 1995 10:37:40 -0400 Subject: Syntax checking Message-ID: <199505181437.KAA23502@home.merit.edu> Hi, I saw an AS object with as-in ... accept ALL being registered in RADB. ALL (really should be ANY) is an illegal word. Does the code check on that? Thanks! --Jessica home.merit.edu:/u2/jyy/Mail/inbox> whois -h radb.ra.net AS4550 aut-num: AS4550 as-name: ASN-AN-CMSPP descr: Alpha.net Corporation (ASN-AN-CMSPP) descr: 324 E. Wisconsin Avenue descr: Milwaukee descr: WI 53202, USA as-in: from AS2883 3 accept ALL as-in: from AS3560 10 accept AS3560 as-out: to AS2883 announce AS4550 AS3560 admin-c: Joseph T. Klein tech-c: Joseph T. Klein mnt-by: MAINT-AS4550 changed: jtk at alpha.net 950426 source: RADB -------- Logged at Thu May 18 17:12:52 MET DST 1995 --------- From Daniel.Karrenberg at ripe.net Thu May 18 17:12:49 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 18 May 1995 17:12:49 +0200 Subject: just an FYI - don't panic In-Reply-To: Your message of Tue, 16 May 1995 09:40:45 EDT. <95May16.094104edt.606849@enfm.utcc.utoronto.ca> References: <95May16.094104edt.606849@enfm.utcc.utoronto.ca> Message-ID: <9505181512.AA14270@ncc.ripe.net> > "Eric M. Carroll" writes: > Daniel, > > For the moment, I think the need to have your code support PGP object > authentication, leaving key management explicitly out of band, is > large enough to warrent support. We certainly do not mind having key > management as an out of band activity, at least initially. We do, > however, want something stronger than the current system. > I would like to be able to sign an entire database, as well. > ... Good idea. > While I recognize it does not scale and that we need something else, I > actually *like* the idea of OOB key management. The reason is that I > view the database as an repository of the transactions of a trusted > administrative relationship. OOB key management is just another > opportunity to find out who it is I am actually about to trust. Maybe > the RA could set up a PGP key server as a value added service for > routing coordination? It is not the key server but maintaining its content that worries me. But you have come a long way to convince me. Let's talk some more at NANOG. Daniel -------- Logged at Thu May 18 17:36:51 MET DST 1995 --------- From Tony.Bates at mci.net Thu May 18 17:33:51 1995 From: Tony.Bates at mci.net (Tony Bates) Date: Thu, 18 May 1995 11:33:51 -0400 Subject: Syntax checking In-Reply-To: Your message of Thu, 18 May 1995 10:37:40 EDT. <199505181437.KAA23502@home.merit.edu> Message-ID: <199505181533.LAA19765@lovefm.reston.mci.net> Wow - this one had me digging through that crap code I wrote for all this syntax nonsense and I needed to look at the logic again as to why this is okay. ALL is valid syntax as is can infact we a community (ugly I know) but true in the definition. --Tony. Jessica (Jie Yun) Yu writes: * Hi, * * I saw an AS object with as-in ... accept ALL being registered in RADB. * ALL (really should be ANY) is an illegal word. Does the code check * on that? Thanks! * * --Jessica * * home.merit.edu:/u2/jyy/Mail/inbox> whois -h radb.ra.net AS4550 * aut-num: AS4550 * as-name: ASN-AN-CMSPP * descr: Alpha.net Corporation (ASN-AN-CMSPP) * descr: 324 E. Wisconsin Avenue * descr: Milwaukee * descr: WI 53202, USA * as-in: from AS2883 3 accept ALL * as-in: from AS3560 10 accept AS3560 * as-out: to AS2883 announce AS4550 AS3560 * admin-c: Joseph T. Klein * tech-c: Joseph T. Klein * mnt-by: MAINT-AS4550 * changed: jtk at alpha.net 950426 * source: RADB * -------- Logged at Thu May 18 18:18:09 MET DST 1995 --------- From dsj at merit.edu Thu May 18 18:18:02 1995 From: dsj at merit.edu (Dale S. Johnson) Date: Thu, 18 May 1995 12:18:02 -0400 Subject: Delete syntax (again) Message-ID: <199505181618.MAA28440@home.merit.edu> Sorry; I think I asked this once but lost the answer: Where in RIPE documentation does anything describe how to use the "delete:" attribute? (Both for us, so we know what it really wants, and even more for the users who keep asking us). --Dale -------- Logged at Thu May 18 18:50:25 MET DST 1995 --------- From enke at mci.net Thu May 18 18:25:45 1995 From: enke at mci.net (Enke Chen) Date: Thu, 18 May 1995 12:25:45 -0400 Subject: Delete syntax (again) In-Reply-To: Your message of "Thu, 18 May 1995 12:18:02 EDT." <199505181618.MAA28440@home.merit.edu> Message-ID: <199505181625.MAA02108@clone3.reston.mci.net> Dale: The syntax is "delete:" followed by an email address. For example, delete: enke at mci.net Note that the trick is that the route object has to be exactly the same as the way it was registered. The delete line shall be the last line of the object. -- Enke > Date: Thu, 18 May 1995 12:18:02 -0400 > From: "Dale S. Johnson" > To: rr-impl at ripe.net > Sorry; I think I asked this once but lost the answer: > > Where in RIPE documentation does anything describe how to use the "delete:" > attribute? (Both for us, so we know what it really wants, and even more > for the users who keep asking us). > > --Dale -------- Logged at Thu May 18 18:58:10 MET DST 1995 --------- From David.Kessens at ripe.net Thu May 18 18:58:03 1995 From: David.Kessens at ripe.net (David.Kessens at ripe.net) Date: Thu, 18 May 1995 18:58:03 +0200 (MET DST) Subject: Delete syntax (again) In-Reply-To: <199505181618.MAA28440@home.merit.edu> from "Dale S. Johnson" at May 18, 95 12:18:02 pm Message-ID: <9505181658.AA04235@mature.ripe.net> A non-text attachment was scrubbed... Name: not available Type: text Size: 1395 bytes Desc: not available Url : https://www.ripe.net/mailman/private/rr-impl/attachments/19950518/bc3735cb/attachment.pl From jyy at merit.edu Thu May 18 19:21:43 1995 From: jyy at merit.edu (Jessica Yu) Date: Thu, 18 May 1995 13:21:43 -0400 Subject: Syntax checking In-Reply-To: Your message of "Thu, 18 May 1995 11:33:51 EDT." <199505181533.LAA19765@lovefm.reston.mci.net> Message-ID: <199505181721.NAA02164@cannes.merit.edu> >Wow - this one had me digging through that crap code I wrote for all >this syntax nonsense and I needed to look at the logic again as to why >this is okay. Please check. The reason I concern about it is that I am not sure the tools e.g. peval,etc. would take it well. >ALL is valid syntax as is can infact we a community >(ugly I know) but true in the definition. I have some difficulties to parse this. Would you explain? --Jessica -------- Logged at Thu May 18 19:34:22 MET DST 1995 --------- From Tony.Bates at mci.net Thu May 18 19:32:44 1995 From: Tony.Bates at mci.net (Tony Bates) Date: Thu, 18 May 1995 13:32:44 -0400 Subject: Syntax checking In-Reply-To: Your message of Thu, 18 May 1995 13:21:43 EDT. <199505181721.NAA02164@cannes.merit.edu> Message-ID: <199505181732.NAA23429@lovefm.reston.mci.net> Jessica Yu writes: * >Wow - this one had me digging through that crap code I wrote for all * >this syntax nonsense and I needed to look at the logic again as to why * >this is okay. * * Please check. The reason I concern about it is that I am not sure the tool * s * e.g. peval,etc. would take it well. * They have to deal with it as a community. In this case it was not meant this way but there you go. * >ALL is valid syntax as is can infact we a community * >(ugly I know) but true in the definition. * * I have some difficulties to parse this. Would you explain? * OOPS - sorry - was typing too fast as usual. ALL is valid syntax as ALL can infact be a community according to the definition. * --Jessica * --Tony. -------- Logged at Thu May 18 20:05:20 MET DST 1995 --------- From cengiz at ISI.EDU Thu May 18 20:04:38 1995 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Thu, 18 May 1995 11:04:38 -0700 Subject: Syntax checking In-Reply-To: <199505181732.NAA23429@lovefm.reston.mci.net> References: <199505181721.NAA02164@cannes.merit.edu> <199505181732.NAA23429@lovefm.reston.mci.net> Message-ID: <199505181804.AA21409@cat.isi.edu> Tony Bates (Tony.Bates at mci.net) on May 18: > > Jessica Yu writes: > * >Wow - this one had me digging through that crap code I wrote for all > * >this syntax nonsense and I needed to look at the logic again as to why > * >this is okay. > * > * Please check. The reason I concern about it is that I am not sure the tool > * s > * e.g. peval,etc. would take it well. > * > They have to deal with it as a community. In this case it was not > meant this way but there you go. Yes, peval treats it as a community name. >6:/ra/production/RtConfig-P-2.5/peval : peval -e ALL ((ALL)) >7:/ra/production/RtConfig-P-2.5/peval : ./peval -expand_all -e ALL Warning: Unable to expand macro: ALL ({}) (macro above means as-macro or community). Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California http://www.isi.edu/div7/people/cengiz.home -------- Logged at Thu May 18 22:28:32 MET DST 1995 --------- From Tony.Bates at mci.net Thu May 18 22:28:26 1995 From: Tony.Bates at mci.net (Tony Bates) Date: Thu, 18 May 1995 16:28:26 -0400 Subject: Small patch to misc.pl Message-ID: <199505182028.QAA00614@lovefm.reston.mci.net> As part of the checking on Jessica's comment I came across a small bug where comnunities were not checked correctly. Please apply the following patch. *** misc.pl Mon May 8 12:10:49 1995 --- ../testsrc/src/misc.pl Thu May 18 16:21:38 1995 *************** *** 197,203 **** # sub iscommunity { local($str) = @_; ! return 0 if $str =~ /[a-z]/; foreach $_ ((keys %KEYWORD, "AS")) { if (($_ eq "(") || ($_ eq ")")) { $_ = "\\".$_; --- 197,203 ---- # sub iscommunity { local($str) = @_; ! return 0 if $str !~ /[A-Z]+/; foreach $_ ((keys %KEYWORD, "AS")) { if (($_ eq "(") || ($_ eq ")")) { $_ = "\\".$_; Tony -------- Logged at Thu May 18 23:25:36 MET DST 1995 --------- From jyy at merit.edu Thu May 18 23:25:25 1995 From: jyy at merit.edu (Jessica Yu) Date: Thu, 18 May 1995 17:25:25 -0400 Subject: Small patch to misc.pl In-Reply-To: Your message of "Thu, 18 May 1995 16:28:26 EDT." <199505182028.QAA00614@lovefm.reston.mci.net> Message-ID: <199505182125.RAA02241@cannes.merit.edu> Hey, Tony: Thanks for such a quick action. --Jessica Date: Thu, 18 May 1995 16:28:26 EDT To: rr-impl at ripe.net From: Tony Bates Subject: Small patch to misc.pl Return-Path: tony at mci.net X-Phone: +1 703 715 7521 Sender: tony at mci.net As part of the checking on Jessica's comment I came across a small bug where comnunities were not checked correctly. Please apply the following patch. *** misc.pl Mon May 8 12:10:49 1995 --- ../testsrc/src/misc.pl Thu May 18 16:21:38 1995 *************** *** 197,203 **** # sub iscommunity { local($str) = @_; ! return 0 if $str =~ /[a-z]/; foreach $_ ((keys %KEYWORD, "AS")) { if (($_ eq "(") || ($_ eq ")")) { $_ = "\\".$_; --- 197,203 ---- # sub iscommunity { local($str) = @_; ! return 0 if $str !~ /[A-Z]+/; foreach $_ ((keys %KEYWORD, "AS")) { if (($_ eq "(") || ($_ eq ")")) { $_ = "\\".$_; Tony -------- Logged at Fri May 19 18:41:23 MET DST 1995 --------- From Tony.Bates at mci.net Fri May 19 18:41:14 1995 From: Tony.Bates at mci.net (Tony Bates) Date: Fri, 19 May 1995 12:41:14 -0400 Subject: More patches - small patch to net2net.pl Message-ID: <199505191641.MAA08070@lovefm.reston.mci.net> This fixes a porblem where and entry like route: 128.86.24.0 was rewritten to route: 128.86.24.0/ This only occured on classless routes without prefixes. --Tony. *** net2net.pl Wed Nov 16 13:24:04 1994 --- ../testsrc/src/net2net.pl Fri May 19 11:33:32 1995 *************** *** 140,145 **** --- 140,149 ---- $len = 16; } elsif ($2 == 0 && $3 == 0 && $4 == 0) { $len = 8; + } else { + return $NOK, + "$net_rep is not a classful net representation I understand", + @return_rep; } @return_rep = (@return_rep, $net_rep."/".$len); return $OK, "", @return_rep; -------- Logged at Tue May 23 15:30:01 MET DST 1995 --------- From Tony.Bates at mci.net Tue May 23 15:29:13 1995 From: Tony.Bates at mci.net (Tony Bates) Date: Tue, 23 May 1995 09:29:13 -0400 Subject: cleaing DBs before putting them up for ftp Message-ID: <199505231329.JAA13298@lovefm.reston.mci.net> If possible can RR clean their databases before putting them up for ftp. If you dont want to clean everyday at least every three days especially if you do not run a split system. The radb currently has 1638 entries which dont need to be there. --Tony. -------- Logged at Tue May 23 18:22:56 MET DST 1995 --------- From renaud at merit.edu Tue May 23 18:22:46 1995 From: renaud at merit.edu (Brian Renaud) Date: Tue, 23 May 1995 12:22:46 -0400 Subject: cleaing DBs before putting them up for ftp In-Reply-To: Your message of Tue, 23 May 1995 09:29:13 -0400. <199505231329.JAA13298@lovefm.reston.mci.net> Message-ID: <9505231622.AA07030@yurt.merit.edu> > If possible can RR clean their databases before putting them up for > ftp. If you dont want to clean everyday at least every three days > especially if you do not run a split system. > The radb currently has 1638 entries which dont need to be there. > > --Tony. Sorry, some sort of script entropy, it seems. -Brian -------- Logged at Thu May 25 19:48:50 MET DST 1995 --------- From jyy at merit.edu Thu May 25 19:48:44 1995 From: jyy at merit.edu (Jessica Yu) Date: Thu, 25 May 1995 13:48:44 -0400 Subject: interesting Message-ID: <199505251748.NAA03094@cannes.merit.edu> Hi, These two are really same record,i.e. same IP address with the same ASorigin. They should not be co-exist in the same DB. I think the problem is that the software allows 198.022.064.0/24 and treats it as different IP address, 198.22.64.0/24 ~= 198.022.064.0/24. I think the software should either not allow such ip address (198.022.064.._) or convert it to 198.22.64/24. We can avoid the problem. By the way, there are at least 5 route object has this case. It make it difficult for us to generate RS configuration which is how I discover this. --jessica cannes.merit.edu(49): whois -h radb.ra.net 198.22.64.0 route: 198.22.64.0/24 descr: Lodden Technology, Ltd. descr: 5850 Dixie Hwy descr: Clarkston descr: MI 48346, USA origin: AS4200 comm-list: COMM_NSFNET advisory: AS690 mnt-by: MAINT-AS4200 changed: nsfnet-admin at merit.edu 950406 source: RADB route: 198.022.064.0/24 descr: NET-LODDEN-FV3 origin: AS4200 advisory: AS690 1:4200(147) 2:4200(218) 3:4200(187) 4:4200(11) 5:4200(173) mnt-by: MAINT-AS4200 changed: phil at agis.net 950403 source: RADB -------- Logged at Fri May 26 11:20:34 MET DST 1995 --------- From Daniel.Karrenberg at ripe.net Fri May 26 11:19:52 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 26 May 1995 11:19:52 +0200 Subject: interesting In-Reply-To: Your message of Thu, 25 May 1995 13:48:44 EDT. <199505251748.NAA03094@cannes.merit.edu> References: <199505251748.NAA03094@cannes.merit.edu> Message-ID: <9505260919.AA29314@ncc.ripe.net> > Jessica Yu writes: > I think the problem is that the software allows 198.022.064.0/24 > and treats it as different IP address, 198.22.64.0/24 ~= 198.022.064.0/24. > I think the software should either > not allow such ip address (198.022.064.._) or convert it to 198.22.64/24. I believe it should convert. I also believe it did at some point. We will look into this. Daniel -------- Logged at Fri May 26 14:31:51 MET DST 1995 --------- From Tony.Bates at mci.net Fri May 26 14:30:51 1995 From: Tony.Bates at mci.net (Tony Bates) Date: Fri, 26 May 1995 08:30:51 -0400 Subject: interesting In-Reply-To: Your message of Fri, 26 May 1995 11:19:52 +0200. <9505260919.AA29314@ncc.ripe.net> Message-ID: <199505261230.IAA06147@lovefm.reston.mci.net> Well - I re-wrote this part in net2net.pl and I can easily believe I screwed this. I'll take a look later today. --Tony. Daniel Karrenberg writes: * * > Jessica Yu writes: * > I think the problem is that the software allows 198.022.064.0/24 * > and treats it as different IP address, 198.22.64.0/24 ~= 198.022.064.0/ * 24. > I think the software should either * > not allow such ip address (198.022.064.._) or convert it to 198.22.64/2 * 4. * * I believe it should convert. I also believe it did at some point. * We will look into this. * * Daniel -------- Logged at Fri May 26 21:05:39 MET DST 1995 --------- From renaud at merit.edu Fri May 26 21:05:21 1995 From: renaud at merit.edu (Brian Renaud) Date: Fri, 26 May 1995 15:05:21 -0400 Subject: From: vs. Reply-To: for MAIL-FROM checks Message-ID: <9505261905.AA09787@yurt.merit.edu> I see the the rfc822.pl code doesn't set firstreplyto to zero if it sees a From: line. Thus, any subsequent Reply-To: lines override the entry in the From: line. Does this make sense for authentication? (I'm not sure that either choice here is really satisfactory.) -Brian ------- Forwarded Message [less relevant stuff pruned] Date: Fri, 26 May 1995 11:39:40 -0700 From: Vince Fuller Subject: Fwd: RADB additions failing Why is this request failing? Is your program getting confused by the "reply-to" field? This request should pass authorization. Please fix this. --Vince --------------- 1) 26-May Vince Fuller Additions to RADB - new CIDR blo (2614 chars) 2) 26-May NSF Routing Re: Additions to RADB - new CIDR (4406 chars) Message 1 -- ********************* From: Vince Fuller Reply-To: ops at BARRNET.NET ... [various route objects] Message 2 -- ********************* From: NSF Routing Arbiter Database Management Subject: Re: Additions to RADB - new CIDR blocks Your e-mail: > From: ops at barrnet.net > Subject: Additions to RADB - new CIDR blocks > Date: Fri, 26 May 95 11:38:20 PDT > Msg-Id: has been processed by the automatic update procedure at the NSF Routing Arbiter . Diagnostic output follows: ... [lots of authorization failures deleted] ------- End of Forwarded Message -------- Logged at Sat May 27 22:30:29 MET DST 1995 --------- From Tony.Bates at mci.net Sat May 27 22:29:42 1995 From: Tony.Bates at mci.net (Tony Bates) Date: Sat, 27 May 1995 16:29:42 -0400 Subject: interesting In-Reply-To: Your message of Fri, 26 May 1995 11:19:52 +0200. <9505260919.AA29314@ncc.ripe.net> Message-ID: <199505272029.QAA24036@ns.mci.net> Daniel Karrenberg writes: * * > Jessica Yu writes: * > I think the problem is that the software allows 198.022.064.0/24 * > and treats it as different IP address, 198.22.64.0/24 ~= 198.022.064.0/ * 24. > I think the software should either * > not allow such ip address (198.022.064.._) or convert it to 198.22.64/2 * 4. * * I believe it should convert. I also believe it did at some point. * We will look into this. * * Daniel Well it converts again now ;-). Here's the patch for this. It requires a patch to net2net.pl and syntax.pl --Tony. *** net2net.pl Sat May 27 16:22:06 1995 --- ../testsrc/src/net2net.pl Sat May 27 16:22:22 1995 *************** *** 145,151 **** "$net_rep is not a classful net representation I understand", @return_rep; } ! @return_rep = (@return_rep, $net_rep."/".$len); return $OK, "", @return_rep; } else { return $NOK, --- 145,152 ---- "$net_rep is not a classful net representation I understand", @return_rep; } ! local($val) = &trimnet($net_rep); ! @return_rep = (@return_rep, $val."/".$len); return $OK, "", @return_rep; } else { return $NOK, *************** *** 165,171 **** local($begin) = &quad2int($oldnet); local($end) = &quad2int($2); if($end < $begin) { ! return $NOK, "range is invalid", @returndtring; } if ($oldnet =~ /(\d+)\.\d+\.\d+\.\d+/) { --- 166,172 ---- local($begin) = &quad2int($oldnet); local($end) = &quad2int($2); if($end < $begin) { ! return $NOK, "range is invalid", @returnstring; } if ($oldnet =~ /(\d+)\.\d+\.\d+\.\d+/) { *************** *** 240,246 **** "based on prefix $usepre", @returnstring; } ! return $OK, "", $net_rep; } else { return $NOK, "$net_rep is not an representation I understand", --- 241,249 ---- "based on prefix $usepre", @returnstring; } ! local($val) = &trimnet($net); ! @returnstring = "$val"."/".$len; ! return $OK, "", @returnstring; } else { return $NOK, "$net_rep is not an representation I understand", *************** *** 373,377 **** --- 376,385 ---- $s=sprintf ("%d.0.0.0", $byte0 ); } return( $s ); + } + + sub trimnet { + local($quad) = @_; + return(&int2quad(&quad2int($quad))); } 1; *** syntax.pl Tue May 23 22:37:14 1995 --- ../testsrc/src/syntax.pl Sat May 27 16:17:19 1995 *************** *** 1533,1538 **** --- 1533,1539 ---- if($stat == $NOK) { return $O_ERROR, "$msg\n"; } + $object{$key} = $str[0]; } return; } -------- Logged at Tue May 30 15:44:31 MET DST 1995 --------- From jyy at merit.edu Tue May 30 15:44:05 1995 From: jyy at merit.edu (Jessica Yu) Date: Tue, 30 May 1995 09:44:05 -0400 Subject: interesting In-Reply-To: Your message of "Sat, 27 May 1995 16:29:42 EDT." <199505272029.QAA24036@ns.mci.net> Message-ID: <199505301344.JAA03568@cannes.merit.edu> * * > Jessica Yu writes: * > I think the problem is that the software allows 198.022.064.0/24 * > and treats it as different IP address, 198.22.64.0/24 ~= 198.022.064.0/ * 24. > I think the software should either * > not allow such ip address (198.022.064.._) or convert it to 198.22.64/2 * 4. * * I believe it should convert. I also believe it did at some point. * We will look into this. * * Daniel >Well it converts again now ;-). Here's the patch for this. It requires >a patch to net2net.pl and syntax.pl >--Tony. Tony, Thanks a lot ! --Jessica -------- Logged at Wed May 31 18:49:00 MET DST 1995 --------- From ripe-dbm at ripe.net Wed May 31 18:48:57 1995 From: ripe-dbm at ripe.net (RIPE Database software maintainer) Date: Wed, 31 May 1995 18:48:57 +0200 Subject: URGENT: Bug fixes in the RIPE database distribution Message-ID: <9505311648.AA09043@ncc.ripe.net> Dear all, Recently Tony Bates found an authorisation problem in 'updatecheck.pl'. Today my fix is ready. Please apply this fix to your software! Furthermore, I included the recent fixes made by Tony for : net2net.pl misc.pl in the distribution and a small one from Curtis Villamizar for : dbupdate.pl I plan to add also some other fixes from Curtis in the next release. Kind regards, David Kessens RIPE NCC Database software maintainer ====================================================================== How to apply the fix(es) : Fix src/filename.pl with 'patch' or just put in the corresponding file(s) of the new distribution (ftp:/ftp.ripe.net/ripe/dbase/software, file with latest version number). Always make a backup copy of the old file(s) to be able to restore the original software in case you might experience problems. After the fix(es) are applied, do a 'make install' from the database root directory to install the patched file(s). The following files have been changed from the previous release: updatecheck.pl dbupdate.pl net2net.pl misc.pl ====================================================================== *** /ncc/dbase/src/old/updatecheck.pl Tue Jan 17 17:37:36 1995 --- /ncc/dbase/src/updatecheck.pl Tue May 30 18:47:24 1995 *************** *** 1,7 **** # $RCSfile: updatecheck.pl,v $ ! # $Revision: 1.19 $ # $Author: ripe-dbm $ ! # $Date: 1995/01/17 16:37:36 $ require "defines.pl"; require "adderror.pl"; --- 1,7 ---- # $RCSfile: updatecheck.pl,v $ ! # $Revision: 1.20 $ # $Author: ripe-dbm $ ! # $Date: 1995/05/30 13:34:47 $ require "defines.pl"; require "adderror.pl"; *************** *** 70,79 **** } ! # Check authorisation by maintainer unless override is specified. if (!$new{"uo"} && !&Maintainer(*cur, *new)) { ! return $E_AUTHFAIL unless !&entype(*new); } # Catch if called from dbdel, then skip all checks, --- 70,80 ---- } ! # Check authorisation by maintainer unless override is specified ! # and handles special (dirty trick) delete case with $new in $cur if (!$new{"uo"} && !&Maintainer(*cur, *new)) { ! return $E_AUTHFAIL if !$cur{"uo"}; } # Catch if called from dbdel, then skip all checks, *** /ncc/dbase/src/old/dbupdate.pl Tue May 30 18:38:57 1995 --- /ncc/dbase/src/dbupdate.pl Tue May 30 18:48:17 1995 *************** *** 1,9 **** #!PERL # $RCSfile: dbupdate.pl,v $ ! # $Revision: 0.33 $ ! # $Author: david $ ! # $Date: 1995/02/24 11:13:22 $ # This is a client that will update objects read from a file directly # in the database, without interference of updated. --- 1,9 ---- #!PERL # $RCSfile: dbupdate.pl,v $ ! # $Revision: 0.34 $ ! # $Author: ripe-dbm $ ! # $Date: 1995/05/30 14:44:09 $ # This is a client that will update objects read from a file directly # in the database, without interference of updated. *************** *** 46,52 **** # -F - Do fast update without mail and other stuff # -S - Do only syntax check - Not implemented ! &Getopts('ln:vMAHVFS'); # Need this below for running perl in tainted mode. --- 46,52 ---- # -F - Do fast update without mail and other stuff # -S - Do only syntax check - Not implemented ! &Getopts('l:n:vMAHVFS'); # Need this below for running perl in tainted mode. *** /ncc/dbase/src/old/net2net.pl Tue May 30 18:43:22 1995 --- /ncc/dbase/src/net2net.pl Tue May 30 18:49:30 1995 *************** *** 1,8 **** # # $RCSfile: net2net.pl,v $ ! # $Revision: 0.13 $ ! # $Author: tony $ ! # $Date: 1994/09/20 12:27:36 $ # # net2net.pl # --- 1,8 ---- # # $RCSfile: net2net.pl,v $ ! # $Revision: 0.14 $ ! # $Author: ripe-dbm $ ! # $Date: 1995/05/30 16:45:19 $ # # net2net.pl # *************** *** 140,147 **** $len = 16; } elsif ($2 == 0 && $3 == 0 && $4 == 0) { $len = 8; } ! @return_rep = (@return_rep, $net_rep."/".$len); return $OK, "", @return_rep; } else { return $NOK, --- 140,152 ---- $len = 16; } elsif ($2 == 0 && $3 == 0 && $4 == 0) { $len = 8; + } else { + return $NOK, + "$net_rep is not a classful net representation I understand", + @return_rep; } ! local($val) = &trimnet($net_rep); ! @return_rep = (@return_rep, $val."/".$len); return $OK, "", @return_rep; } else { return $NOK, *************** *** 161,167 **** local($begin) = &quad2int($oldnet); local($end) = &quad2int($2); if($end < $begin) { ! return $NOK, "range is invalid", @returndtring; } if ($oldnet =~ /(\d+)\.\d+\.\d+\.\d+/) { --- 166,172 ---- local($begin) = &quad2int($oldnet); local($end) = &quad2int($2); if($end < $begin) { ! return $NOK, "range is invalid", @returnstring; } if ($oldnet =~ /(\d+)\.\d+\.\d+\.\d+/) { *************** *** 236,242 **** "based on prefix $usepre", @returnstring; } ! return $OK, "", $net_rep; } else { return $NOK, "$net_rep is not an representation I understand", --- 241,249 ---- "based on prefix $usepre", @returnstring; } ! local($val) = &trimnet($net); ! @returnstring = "$val"."/".$len; ! return $OK, "", @returnstring; } else { return $NOK, "$net_rep is not an representation I understand", *************** *** 370,373 **** --- 377,386 ---- } return( $s ); } + + sub trimnet { + local($quad) = @_; + return(&int2quad(&quad2int($quad))); + } 1; + *** /ncc/dbase/src/old/misc.pl Wed May 31 14:06:18 1995 --- /ncc/dbase/src/misc.pl Wed May 31 14:08:13 1995 *************** *** 1,9 **** # misc - miscellaneaous functions # # $RCSfile: misc.pl,v $ ! # $Revision: 0.44 $ ! # $Author: marten $ ! # $Date: 1994/12/16 11:06:55 $ # require "defines.pl"; --- 1,9 ---- # misc - miscellaneaous functions # # $RCSfile: misc.pl,v $ ! # $Revision: 0.45 $ ! # $Author: ripe-dbm $ ! # $Date: 1995/05/31 12:04:40 $ # require "defines.pl"; *************** *** 197,203 **** # sub iscommunity { local($str) = @_; ! return 0 if $str =~ /[a-z]/; foreach $_ ((keys %KEYWORD, "AS")) { if (($_ eq "(") || ($_ eq ")")) { $_ = "\\".$_; --- 197,203 ---- # sub iscommunity { local($str) = @_; ! return 0 if $str !~ /[A-Z]+/; foreach $_ ((keys %KEYWORD, "AS")) { if (($_ eq "(") || ($_ eq ")")) { $_ = "\\".$_; *** /ncc/dbase/src/old/updatecheck.pl Tue Jan 17 17:37:36 1995 --- /ncc/dbase/src/updatecheck.pl Tue May 30 18:47:24 1995 *************** *** 1,7 **** # $RCSfile: updatecheck.pl,v $ ! # $Revision: 1.19 $ # $Author: ripe-dbm $ ! # $Date: 1995/01/17 16:37:36 $ require "defines.pl"; require "adderror.pl"; --- 1,7 ---- # $RCSfile: updatecheck.pl,v $ ! # $Revision: 1.20 $ # $Author: ripe-dbm $ ! # $Date: 1995/05/30 13:34:47 $ require "defines.pl"; require "adderror.pl"; *************** *** 70,79 **** } ! # Check authorisation by maintainer unless override is specified. if (!$new{"uo"} && !&Maintainer(*cur, *new)) { ! return $E_AUTHFAIL unless !&entype(*new); } # Catch if called from dbdel, then skip all checks, --- 70,80 ---- } ! # Check authorisation by maintainer unless override is specified ! # and handles special (dirty trick) delete case with $new in $cur if (!$new{"uo"} && !&Maintainer(*cur, *new)) { ! return $E_AUTHFAIL if !$cur{"uo"}; } # Catch if called from dbdel, then skip all checks, *** /ncc/dbase/src/old/dbupdate.pl Tue May 30 18:38:57 1995 --- /ncc/dbase/src/dbupdate.pl Tue May 30 18:48:17 1995 *************** *** 1,9 **** #!PERL # $RCSfile: dbupdate.pl,v $ ! # $Revision: 0.33 $ ! # $Author: david $ ! # $Date: 1995/02/24 11:13:22 $ # This is a client that will update objects read from a file directly # in the database, without interference of updated. --- 1,9 ---- #!PERL # $RCSfile: dbupdate.pl,v $ ! # $Revision: 0.34 $ ! # $Author: ripe-dbm $ ! # $Date: 1995/05/30 14:44:09 $ # This is a client that will update objects read from a file directly # in the database, without interference of updated. *************** *** 46,52 **** # -F - Do fast update without mail and other stuff # -S - Do only syntax check - Not implemented ! &Getopts('ln:vMAHVFS'); # Need this below for running perl in tainted mode. --- 46,52 ---- # -F - Do fast update without mail and other stuff # -S - Do only syntax check - Not implemented ! &Getopts('l:n:vMAHVFS'); # Need this below for running perl in tainted mode. *** /ncc/dbase/src/old/net2net.pl Tue May 30 18:43:22 1995 --- /ncc/dbase/src/net2net.pl Tue May 30 18:49:30 1995 *************** *** 1,8 **** # # $RCSfile: net2net.pl,v $ ! # $Revision: 0.13 $ ! # $Author: tony $ ! # $Date: 1994/09/20 12:27:36 $ # # net2net.pl # --- 1,8 ---- # # $RCSfile: net2net.pl,v $ ! # $Revision: 0.14 $ ! # $Author: ripe-dbm $ ! # $Date: 1995/05/30 16:45:19 $ # # net2net.pl # *************** *** 140,147 **** $len = 16; } elsif ($2 == 0 && $3 == 0 && $4 == 0) { $len = 8; } ! @return_rep = (@return_rep, $net_rep."/".$len); return $OK, "", @return_rep; } else { return $NOK, --- 140,152 ---- $len = 16; } elsif ($2 == 0 && $3 == 0 && $4 == 0) { $len = 8; + } else { + return $NOK, + "$net_rep is not a classful net representation I understand", + @return_rep; } ! local($val) = &trimnet($net_rep); ! @return_rep = (@return_rep, $val."/".$len); return $OK, "", @return_rep; } else { return $NOK, *************** *** 161,167 **** local($begin) = &quad2int($oldnet); local($end) = &quad2int($2); if($end < $begin) { ! return $NOK, "range is invalid", @returndtring; } if ($oldnet =~ /(\d+)\.\d+\.\d+\.\d+/) { --- 166,172 ---- local($begin) = &quad2int($oldnet); local($end) = &quad2int($2); if($end < $begin) { ! return $NOK, "range is invalid", @returnstring; } if ($oldnet =~ /(\d+)\.\d+\.\d+\.\d+/) { *************** *** 236,242 **** "based on prefix $usepre", @returnstring; } ! return $OK, "", $net_rep; } else { return $NOK, "$net_rep is not an representation I understand", --- 241,249 ---- "based on prefix $usepre", @returnstring; } ! local($val) = &trimnet($net); ! @returnstring = "$val"."/".$len; ! return $OK, "", @returnstring; } else { return $NOK, "$net_rep is not an representation I understand", *************** *** 370,373 **** --- 377,386 ---- } return( $s ); } + + sub trimnet { + local($quad) = @_; + return(&int2quad(&quad2int($quad))); + } 1; + *** /ncc/dbase/src/old/misc.pl Wed May 31 14:06:18 1995 --- /ncc/dbase/src/misc.pl Wed May 31 14:08:13 1995 *************** *** 1,9 **** # misc - miscellaneaous functions # # $RCSfile: misc.pl,v $ ! # $Revision: 0.44 $ ! # $Author: marten $ ! # $Date: 1994/12/16 11:06:55 $ # require "defines.pl"; --- 1,9 ---- # misc - miscellaneaous functions # # $RCSfile: misc.pl,v $ ! # $Revision: 0.45 $ ! # $Author: ripe-dbm $ ! # $Date: 1995/05/31 12:04:40 $ # require "defines.pl"; *************** *** 197,203 **** # sub iscommunity { local($str) = @_; ! return 0 if $str =~ /[a-z]/; foreach $_ ((keys %KEYWORD, "AS")) { if (($_ eq "(") || ($_ eq ")")) { $_ = "\\".$_; --- 197,203 ---- # sub iscommunity { local($str) = @_; ! return 0 if $str !~ /[A-Z]+/; foreach $_ ((keys %KEYWORD, "AS")) { if (($_ eq "(") || ($_ eq ")")) { $_ = "\\".$_; --- End of fix(es) --- -------- Logged at Wed May 31 19:08:55 MET DST 1995 --------- From selina at ans.net Wed May 31 19:07:26 1995 From: selina at ans.net (Selina Priestley) Date: Wed, 31 May 1995 13:07:26 -0400 Subject: URGENT: Bug fixes in the RIPE database distribution In-Reply-To: Message from of Wed May 31,1995 18:48 +0200 <9505311648.AA09043@ncc.ripe.net> Message-ID: <199505311707.AA45599@interlock.ans.net> Has anyone been looking at the problems with the whois server? This has really been a problem for operations here, since a) the problems *appear* to be non-deterministic and b) sometimes the exact netmask for a route is not known. Here's an example of whois oddity. Why doesn't the RADB 192.5.4.0/23 show up in the second query? Thanks, Selina foo-selina:/u/selina: ra 192.5.4 route: 192.5.4.0/23 descr: Vixie Enterprises descr: 116 Stanley Street descr: Redwood City descr: CA 94062, USA origin: AS3557 comm-list: COMM_NSFNET advisory: AS690 1:3561(11) 2:3561(218) 4:200(144) 5:701(147) mnt-by: MAINT-AS3557 changed: nsfnet-admin at merit.edu 950118 source: RADB route: 192.5.4.0/23 descr: NET-VIX2 origin: AS3557 advisory: AS690 1:3561(11) 2:3561(144) 3:3561(27) 4:3561(147) 5:3561(218) 5:701(147) 6:7 01(134) mnt-by: BARRNET changed: vaf at valinor.barrnet.net 950111 source: MCI foo-selina:/u/selina: ra 192.5.5 route: 192.5.5.0/24 descr: Vixie Enterprises descr: 116 Stanley Street descr: Redwood City descr: CA 94062, USA origin: AS3557 comm-list: COMM_NSFNET advisory: AS690 2:200(144) 3:701(147) mnt-by: MAINT-AS3557 changed: nsfnet-admin at merit.edu 940729 source: RADB route: 192.5.4.0/23 descr: NET-VIX2 origin: AS3557 advisory: AS690 1:3561(11) 2:3561(144) 3:3561(27) 4:3561(147) 5:3561(218) 5:701(147) 6:7 01(134) mnt-by: BARRNET changed: vaf at valinor.barrnet.net 950111 source: MCI > bugsy-sfp:/u/sfp: whois -h whois.ra.net 194.128 > route: 194.128.0.0/15 > descr: PIPEX-BLOCK3 > origin: AS1849 > advisory: AS690 1:1849 2:701(147) 3:701(134) 4:1800 > remarks: Holes to come! > mnt-by: AS1849-MNT > changed: tim at pipex.net 950428 > source: RIPE > > bugsy-sfp:/u/sfp: whois -h whois.ra.net 194.128/15 > route: 194.128.0.0/15 > descr: PIPEX Ltd > descr: 216 Cambridge Science Park > descr: Milton Road > descr: Cambridge > descr: England > descr: CB4 4WA > descr: UNITED KINGDOM > origin: AS1849 > comm-list: COMM_NSFNET > advisory: AS690 1:1849 2:701(147) 4:1800 > mnt-by: MAINT-AS1849 > changed: support at pipex.net 950511 > source: RADB > > route: 194.128.0.0/15 > descr: PIPEX-BLOCK3 > origin: AS1849 > advisory: AS690 1:1849 2:701(147) 3:701(134) 4:1800 > remarks: Holes to come! > mnt-by: AS1849-MNT > changed: tim at pipex.net 950428 > source: RIPE > > Dear all, > > Recently Tony Bates found an authorisation problem in 'updatecheck.pl'. > Today my fix is ready. Please apply this fix to your software! > > Furthermore, I included the recent fixes made by Tony for : > > net2net.pl > misc.pl > > in the distribution and a small one from Curtis Villamizar for : > > dbupdate.pl > > I plan to add also some other fixes from Curtis in the next release. > > Kind regards, > > David Kessens > RIPE NCC Database software maintainer > > ====================================================================== > > How to apply the fix(es) : > > Fix src/filename.pl with 'patch' or just put in the corresponding > file(s) of the new distribution (ftp:/ftp.ripe.net/ripe/dbase/software, > file with latest version number). Always make a backup copy of the old > file(s) to be able to restore the original software in case you might > experience problems. After the fix(es) are applied, do a 'make install' > from the database root directory to install the patched file(s). > > The following files have been changed from the previous release: > > updatecheck.pl > dbupdate.pl > net2net.pl > misc.pl > > ====================================================================== > *** /ncc/dbase/src/old/updatecheck.pl Tue Jan 17 17:37:36 1995 > --- /ncc/dbase/src/updatecheck.pl Tue May 30 18:47:24 1995 > *************** > *** 1,7 **** > # $RCSfile: updatecheck.pl,v $ > ! # $Revision: 1.19 $ > # $Author: ripe-dbm $ > ! # $Date: 1995/01/17 16:37:36 $ > > require "defines.pl"; > require "adderror.pl"; > --- 1,7 ---- > # $RCSfile: updatecheck.pl,v $ > ! # $Revision: 1.20 $ > # $Author: ripe-dbm $ > ! # $Date: 1995/05/30 13:34:47 $ > > require "defines.pl"; > require "adderror.pl"; > *************** > *** 70,79 **** > } > > > ! # Check authorisation by maintainer unless override is specified. > > if (!$new{"uo"} && !&Maintainer(*cur, *new)) { > ! return $E_AUTHFAIL unless !&entype(*new); > } > > # Catch if called from dbdel, then skip all checks, > --- 70,80 ---- > } > > > ! # Check authorisation by maintainer unless override is specified > ! # and handles special (dirty trick) delete case with $new in $cur > > if (!$new{"uo"} && !&Maintainer(*cur, *new)) { > ! return $E_AUTHFAIL if !$cur{"uo"}; > } > > # Catch if called from dbdel, then skip all checks, > *** /ncc/dbase/src/old/dbupdate.pl Tue May 30 18:38:57 1995 > --- /ncc/dbase/src/dbupdate.pl Tue May 30 18:48:17 1995 > *************** > *** 1,9 **** > #!PERL > > # $RCSfile: dbupdate.pl,v $ > ! # $Revision: 0.33 $ > ! # $Author: david $ > ! # $Date: 1995/02/24 11:13:22 $ > > # This is a client that will update objects read from a file directly > # in the database, without interference of updated. > --- 1,9 ---- > #!PERL > > # $RCSfile: dbupdate.pl,v $ > ! # $Revision: 0.34 $ > ! # $Author: ripe-dbm $ > ! # $Date: 1995/05/30 14:44:09 $ > > # This is a client that will update objects read from a file directly > # in the database, without interference of updated. > *************** > *** 46,52 **** > # -F - Do fast update without mail and other stuff > # -S - Do only syntax check - Not implemented > > ! &Getopts('ln:vMAHVFS'); > > # Need this below for running perl in tainted mode. > > --- 46,52 ---- > # -F - Do fast update without mail and other stuff > # -S - Do only syntax check - Not implemented > > ! &Getopts('l:n:vMAHVFS'); > > # Need this below for running perl in tainted mode. > > *** /ncc/dbase/src/old/net2net.pl Tue May 30 18:43:22 1995 > --- /ncc/dbase/src/net2net.pl Tue May 30 18:49:30 1995 > *************** > *** 1,8 **** > # > # $RCSfile: net2net.pl,v $ > ! # $Revision: 0.13 $ > ! # $Author: tony $ > ! # $Date: 1994/09/20 12:27:36 $ > # > # net2net.pl > # > --- 1,8 ---- > # > # $RCSfile: net2net.pl,v $ > ! # $Revision: 0.14 $ > ! # $Author: ripe-dbm $ > ! # $Date: 1995/05/30 16:45:19 $ > # > # net2net.pl > # > *************** > *** 140,147 **** > $len = 16; > } elsif ($2 == 0 && $3 == 0 && $4 == 0) { > $len = 8; > } > ! @return_rep = (@return_rep, $net_rep."/".$len); > return $OK, "", @return_rep; > } else { > return $NOK, > --- 140,152 ---- > $len = 16; > } elsif ($2 == 0 && $3 == 0 && $4 == 0) { > $len = 8; > + } else { > + return $NOK, > + "$net_rep is not a classful net representation I understand", > + @return_rep; > } > ! local($val) = &trimnet($net_rep); > ! @return_rep = (@return_rep, $val."/".$len); > return $OK, "", @return_rep; > } else { > return $NOK, > *************** > *** 161,167 **** > local($begin) = &quad2int($oldnet); > local($end) = &quad2int($2); > if($end < $begin) { > ! return $NOK, "range is invalid", @returndtring; > } > > if ($oldnet =~ /(\d+)\.\d+\.\d+\.\d+/) { > --- 166,172 ---- > local($begin) = &quad2int($oldnet); > local($end) = &quad2int($2); > if($end < $begin) { > ! return $NOK, "range is invalid", @returnstring; > } > > if ($oldnet =~ /(\d+)\.\d+\.\d+\.\d+/) { > *************** > *** 236,242 **** > "based on prefix $usepre", > @returnstring; > } > ! return $OK, "", $net_rep; > } else { > return $NOK, > "$net_rep is not an representation I understand", > --- 241,249 ---- > "based on prefix $usepre", > @returnstring; > } > ! local($val) = &trimnet($net); > ! @returnstring = "$val"."/".$len; > ! return $OK, "", @returnstring; > } else { > return $NOK, > "$net_rep is not an representation I understand", > *************** > *** 370,373 **** > --- 377,386 ---- > } > return( $s ); > } > + > + sub trimnet { > + local($quad) = @_; > + return(&int2quad(&quad2int($quad))); > + } > 1; > + > *** /ncc/dbase/src/old/misc.pl Wed May 31 14:06:18 1995 > --- /ncc/dbase/src/misc.pl Wed May 31 14:08:13 1995 > *************** > *** 1,9 **** > # misc - miscellaneaous functions > # > # $RCSfile: misc.pl,v $ > ! # $Revision: 0.44 $ > ! # $Author: marten $ > ! # $Date: 1994/12/16 11:06:55 $ > # > > require "defines.pl"; > --- 1,9 ---- > # misc - miscellaneaous functions > # > # $RCSfile: misc.pl,v $ > ! # $Revision: 0.45 $ > ! # $Author: ripe-dbm $ > ! # $Date: 1995/05/31 12:04:40 $ > # > > require "defines.pl"; > *************** > *** 197,203 **** > # > sub iscommunity { > local($str) = @_; > ! return 0 if $str =~ /[a-z]/; > foreach $_ ((keys %KEYWORD, "AS")) { > if (($_ eq "(") || ($_ eq ")")) { > $_ = "\\".$_; > --- 197,203 ---- > # > sub iscommunity { > local($str) = @_; > ! return 0 if $str !~ /[A-Z]+/; > foreach $_ ((keys %KEYWORD, "AS")) { > if (($_ eq "(") || ($_ eq ")")) { > $_ = "\\".$_; > *** /ncc/dbase/src/old/updatecheck.pl Tue Jan 17 17:37:36 1995 > --- /ncc/dbase/src/updatecheck.pl Tue May 30 18:47:24 1995 > *************** > *** 1,7 **** > # $RCSfile: updatecheck.pl,v $ > ! # $Revision: 1.19 $ > # $Author: ripe-dbm $ > ! # $Date: 1995/01/17 16:37:36 $ > > require "defines.pl"; > require "adderror.pl"; > --- 1,7 ---- > # $RCSfile: updatecheck.pl,v $ > ! # $Revision: 1.20 $ > # $Author: ripe-dbm $ > ! # $Date: 1995/05/30 13:34:47 $ > > require "defines.pl"; > require "adderror.pl"; > *************** > *** 70,79 **** > } > > > ! # Check authorisation by maintainer unless override is specified. > > if (!$new{"uo"} && !&Maintainer(*cur, *new)) { > ! return $E_AUTHFAIL unless !&entype(*new); > } > > # Catch if called from dbdel, then skip all checks, > --- 70,80 ---- > } > > > ! # Check authorisation by maintainer unless override is specified > ! # and handles special (dirty trick) delete case with $new in $cur > > if (!$new{"uo"} && !&Maintainer(*cur, *new)) { > ! return $E_AUTHFAIL if !$cur{"uo"}; > } > > # Catch if called from dbdel, then skip all checks, > *** /ncc/dbase/src/old/dbupdate.pl Tue May 30 18:38:57 1995 > --- /ncc/dbase/src/dbupdate.pl Tue May 30 18:48:17 1995 > *************** > *** 1,9 **** > #!PERL > > # $RCSfile: dbupdate.pl,v $ > ! # $Revision: 0.33 $ > ! # $Author: david $ > ! # $Date: 1995/02/24 11:13:22 $ > > # This is a client that will update objects read from a file directly > # in the database, without interference of updated. > --- 1,9 ---- > #!PERL > > # $RCSfile: dbupdate.pl,v $ > ! # $Revision: 0.34 $ > ! # $Author: ripe-dbm $ > ! # $Date: 1995/05/30 14:44:09 $ > > # This is a client that will update objects read from a file directly > # in the database, without interference of updated. > *************** > *** 46,52 **** > # -F - Do fast update without mail and other stuff > # -S - Do only syntax check - Not implemented > > ! &Getopts('ln:vMAHVFS'); > > # Need this below for running perl in tainted mode. > > --- 46,52 ---- > # -F - Do fast update without mail and other stuff > # -S - Do only syntax check - Not implemented > > ! &Getopts('l:n:vMAHVFS'); > > # Need this below for running perl in tainted mode. > > *** /ncc/dbase/src/old/net2net.pl Tue May 30 18:43:22 1995 > --- /ncc/dbase/src/net2net.pl Tue May 30 18:49:30 1995 > *************** > *** 1,8 **** > # > # $RCSfile: net2net.pl,v $ > ! # $Revision: 0.13 $ > ! # $Author: tony $ > ! # $Date: 1994/09/20 12:27:36 $ > # > # net2net.pl > # > --- 1,8 ---- > # > # $RCSfile: net2net.pl,v $ > ! # $Revision: 0.14 $ > ! # $Author: ripe-dbm $ > ! # $Date: 1995/05/30 16:45:19 $ > # > # net2net.pl > # > *************** > *** 140,147 **** > $len = 16; > } elsif ($2 == 0 && $3 == 0 && $4 == 0) { > $len = 8; > } > ! @return_rep = (@return_rep, $net_rep."/".$len); > return $OK, "", @return_rep; > } else { > return $NOK, > --- 140,152 ---- > $len = 16; > } elsif ($2 == 0 && $3 == 0 && $4 == 0) { > $len = 8; > + } else { > + return $NOK, > + "$net_rep is not a classful net representation I understand", > + @return_rep; > } > ! local($val) = &trimnet($net_rep); > ! @return_rep = (@return_rep, $val."/".$len); > return $OK, "", @return_rep; > } else { > return $NOK, > *************** > *** 161,167 **** > local($begin) = &quad2int($oldnet); > local($end) = &quad2int($2); > if($end < $begin) { > ! return $NOK, "range is invalid", @returndtring; > } > > if ($oldnet =~ /(\d+)\.\d+\.\d+\.\d+/) { > --- 166,172 ---- > local($begin) = &quad2int($oldnet); > local($end) = &quad2int($2); > if($end < $begin) { > ! return $NOK, "range is invalid", @returnstring; > } > > if ($oldnet =~ /(\d+)\.\d+\.\d+\.\d+/) { > *************** > *** 236,242 **** > "based on prefix $usepre", > @returnstring; > } > ! return $OK, "", $net_rep; > } else { > return $NOK, > "$net_rep is not an representation I understand", > --- 241,249 ---- > "based on prefix $usepre", > @returnstring; > } > ! local($val) = &trimnet($net); > ! @returnstring = "$val"."/".$len; > ! return $OK, "", @returnstring; > } else { > return $NOK, > "$net_rep is not an representation I understand", > *************** > *** 370,373 **** > --- 377,386 ---- > } > return( $s ); > } > + > + sub trimnet { > + local($quad) = @_; > + return(&int2quad(&quad2int($quad))); > + } > 1; > + > *** /ncc/dbase/src/old/misc.pl Wed May 31 14:06:18 1995 > --- /ncc/dbase/src/misc.pl Wed May 31 14:08:13 1995 > *************** > *** 1,9 **** > # misc - miscellaneaous functions > # > # $RCSfile: misc.pl,v $ > ! # $Revision: 0.44 $ > ! # $Author: marten $ > ! # $Date: 1994/12/16 11:06:55 $ > # > > require "defines.pl"; > --- 1,9 ---- > # misc - miscellaneaous functions > # > # $RCSfile: misc.pl,v $ > ! # $Revision: 0.45 $ > ! # $Author: ripe-dbm $ > ! # $Date: 1995/05/31 12:04:40 $ > # > > require "defines.pl"; > *************** > *** 197,203 **** > # > sub iscommunity { > local($str) = @_; > ! return 0 if $str =~ /[a-z]/; > foreach $_ ((keys %KEYWORD, "AS")) { > if (($_ eq "(") || ($_ eq ")")) { > $_ = "\\".$_; > --- 197,203 ---- > # > sub iscommunity { > local($str) = @_; > ! return 0 if $str !~ /[A-Z]+/; > foreach $_ ((keys %KEYWORD, "AS")) { > if (($_ eq "(") || ($_ eq ")")) { > $_ = "\\".$_; > > > --- End of fix(es) --- -------- Logged at Wed May 31 19:17:20 MET DST 1995 --------- From David.Kessens at ripe.net Wed May 31 19:17:13 1995 From: David.Kessens at ripe.net (David.Kessens at ripe.net) Date: Wed, 31 May 1995 19:17:13 +0200 (MET DST) Subject: URGENT: Bug fixes in the RIPE database distribution In-Reply-To: <199505311707.AA45599@interlock.ans.net> from "Selina Priestley" at May 31, 95 01:07:26 pm Message-ID: <9505311717.AA02198@mature.ripe.net> A non-text attachment was scrubbed... Name: not available Type: text Size: 17092 bytes Desc: not available Url : https://www.ripe.net/mailman/private/rr-impl/attachments/19950531/01d0ff53/attachment.pl From GeertJan.deGroot at ripe.net Wed May 31 19:29:12 1995 From: GeertJan.deGroot at ripe.net (Geert Jan de Groot) Date: Wed, 31 May 1995 19:29:12 +0200 Subject: URGENT: Bug fixes in the RIPE database distribution In-Reply-To: Your message of "Wed, 31 May 1995 13:07:26 EDT." <199505311707.AA45599@interlock.ans.net> Message-ID: <9505311729.AA09380@ncc.ripe.net> On Wed, 31 May 1995 13:07:26 -0400 Selina Priestley wrote: > Has anyone been looking at the problems with the whois server? This > has really been a problem for operations here, since a) the problems > *appear* to be non-deterministic and b) sometimes the exact netmask > for a route is not known. > > Here's an example of whois oddity. Why doesn't the RADB 192.5.4.0/23 show > up in the second query? > > foo-selina:/u/selina: ra 192.5.4 > route: 192.5.4.0/23 > source: RADB > > route: 192.5.4.0/23 > source: MCI > > foo-selina:/u/selina: ra 192.5.5 > route: 192.5.5.0/24 > source: RADB > > route: 192.5.4.0/23 > source: MCI > The (RIPE-) whois server uses a classful default if no mask is given,, so these read ra 192.5.4.0/24 and 192.5.5.0/24, respectively. (backward compatibility). Second, it sends the first match it finds. To find all less specifics, use the -L flag: ra -L 192.5.5 and it will list 192.5.4.0/23 (radb), 192.5.5.0/24 (radb), and 192.5.4.0/23 (mci) There is also a -M flag for more specific cases. What happens in your second example is beyond me, but ra uses different software... Geert Jan -------- Logged at Wed May 31 19:34:42 MET DST 1995 --------- From renaud at merit.edu Wed May 31 19:34:32 1995 From: renaud at merit.edu (Brian Renaud) Date: Wed, 31 May 1995 13:34:32 -0400 Subject: URGENT: Bug fixes in the RIPE database distribution In-Reply-To: Your message of Wed, 31 May 1995 19:17:13 +0200. <9505311717.AA02198@mature.ripe.net> Message-ID: <9505311734.AA12228@yurt.merit.edu> We run a RIPE whois server on the standard whois port. The radbserver runs on a different port. I guess a lot depends on what Selina's "ra" is really doing. > Dear Selina, > > To avoid confusion: > > The radb server software is not part of the RIPE database distribution. > It is a special server made and maintained by the radb team. The RIPE > database software uses it's own server. > > David Kessens > RIPE NCC Database software maintainer > ----------- -------- Logged at Wed May 31 19:38:50 MET DST 1995 --------- From selina at ans.net Wed May 31 19:36:34 1995 From: selina at ans.net (Selina Priestley) Date: Wed, 31 May 1995 13:36:34 -0400 Subject: URGENT: Bug fixes in the RIPE database distribution In-Reply-To: Message from of Wed May 31,1995 13:34 EDT <9505311734.AA12228@yurt.merit.edu> Message-ID: <199505311736.AA35429@interlock.ans.net> ra = whois -h whois.ra.net \!* Thanks *very* much for the quick responses. Selina > > We run a RIPE whois server on the standard whois port. The radbserver > runs on a different port. I guess a lot depends on what Selina's > "ra" is really doing. > > > Dear Selina, > > > > To avoid confusion: > > > > The radb server software is not part of the RIPE database distribution. > > It is a special server made and maintained by the radb team. The RIPE > > database software uses it's own server. > > > > David Kessens > > RIPE NCC Database software maintainer > > ----------- -------- Logged at Wed May 31 20:19:37 MET DST 1995 --------- From renaud at merit.edu Wed May 31 20:19:31 1995 From: renaud at merit.edu (Brian Renaud) Date: Wed, 31 May 1995 14:19:31 -0400 Subject: URGENT: Bug fixes in the RIPE database distribution In-Reply-To: Your message of Wed, 31 May 1995 13:07:26 -0400. <199505311707.AA45599@interlock.ans.net> Message-ID: <9505311819.AA12314@yurt.merit.edu> Selina, my non-authoritative opinion is that this is due to 192.5.4.0/23 being the most specific classless default route in the MCI registry, whereas 192.5.5.0/24 is the most specific classless default route in the RADB. % fgrep 192.5.5.0 d-mci/mci.db d-radb/radb.db d-radb/radb.db:*rt: 192.5.5.0/24 % fgrep 192.5.4.0 d-mci/mci.db d-radb/radb.db d-mci/mci.db:*rt: 192.5.4.0/23 d-radb/radb.db:*rt: 192.5.4.0/23 Whether the software should do this is another question. I'm sure the rr-impl community will correct my ignorance. -Brian > Has anyone been looking at the problems with the whois server? This > has really been a problem for operations here, since a) the problems > *appear* to be non-deterministic and b) sometimes the exact netmask > for a route is not known. > > Here's an example of whois oddity. Why doesn't the RADB 192.5.4.0/23 show > up in the second query? > > Thanks, > > Selina > > foo-selina:/u/selina: ra 192.5.4 > route: 192.5.4.0/23 > descr: Vixie Enterprises > descr: 116 Stanley Street > descr: Redwood City > descr: CA 94062, USA > origin: AS3557 > comm-list: COMM_NSFNET > advisory: AS690 1:3561(11) 2:3561(218) 4:200(144) 5:701(147) > mnt-by: MAINT-AS3557 > changed: nsfnet-admin at merit.edu 950118 > source: RADB > > route: 192.5.4.0/23 > descr: NET-VIX2 > origin: AS3557 > advisory: AS690 1:3561(11) 2:3561(144) 3:3561(27) 4:3561(147) 5:3561(218 ) 5:701(147) 6:7 > 01(134) > mnt-by: BARRNET > changed: vaf at valinor.barrnet.net 950111 > source: MCI > > foo-selina:/u/selina: ra 192.5.5 > route: 192.5.5.0/24 > descr: Vixie Enterprises > descr: 116 Stanley Street > descr: Redwood City > descr: CA 94062, USA > origin: AS3557 > comm-list: COMM_NSFNET > advisory: AS690 2:200(144) 3:701(147) > mnt-by: MAINT-AS3557 > changed: nsfnet-admin at merit.edu 940729 > source: RADB > > route: 192.5.4.0/23 > descr: NET-VIX2 > origin: AS3557 > advisory: AS690 1:3561(11) 2:3561(144) 3:3561(27) 4:3561(147) 5:3561(218 ) 5:701(147) 6:7 > 01(134) > mnt-by: BARRNET > changed: vaf at valinor.barrnet.net 950111 > source: MCI > > > > bugsy-sfp:/u/sfp: whois -h whois.ra.net 194.128 > > route: 194.128.0.0/15 > > descr: PIPEX-BLOCK3 > > origin: AS1849 > > advisory: AS690 1:1849 2:701(147) 3:701(134) 4:1800 > > remarks: Holes to come! > > mnt-by: AS1849-MNT > > changed: tim at pipex.net 950428 > > source: RIPE > > > > bugsy-sfp:/u/sfp: whois -h whois.ra.net 194.128/15 > > route: 194.128.0.0/15 > > descr: PIPEX Ltd > > descr: 216 Cambridge Science Park > > descr: Milton Road > > descr: Cambridge > > descr: England > > descr: CB4 4WA > > descr: UNITED KINGDOM > > origin: AS1849 > > comm-list: COMM_NSFNET > > advisory: AS690 1:1849 2:701(147) 4:1800 > > mnt-by: MAINT-AS1849 > > changed: support at pipex.net 950511 > > source: RADB > > > > route: 194.128.0.0/15 > > descr: PIPEX-BLOCK3 > > origin: AS1849 > > advisory: AS690 1:1849 2:701(147) 3:701(134) 4:1800 > > remarks: Holes to come! > > mnt-by: AS1849-MNT > > changed: tim at pipex.net 950428 > > source: RIPE -------- Logged at Wed May 31 20:21:03 MET DST 1995 --------- From Tony.Bates at mci.net Wed May 31 20:19:58 1995 From: Tony.Bates at mci.net (Tony Bates) Date: Wed, 31 May 1995 14:19:58 -0400 Subject: URGENT: Bug fixes in the RIPE database distribution In-Reply-To: Your message of Wed, 31 May 1995 13:07:26 EDT. <199505311707.AA45599@interlock.ans.net> Message-ID: <199505311819.OAA20876@lovefm.reston.mci.net> This is correct behaviour. The reason it looks odd is becuase of the fact that the RADB has their whoisd conf set to look in multiple sources by default. It does this lookup on a per source basis. --Tony. Selina Priestley writes: * Has anyone been looking at the problems with the whois server? This * has really been a problem for operations here, since a) the problems * *appear* to be non-deterministic and b) sometimes the exact netmask * for a route is not known. * * Here's an example of whois oddity. Why doesn't the RADB 192.5.4.0/23 show * up in the second query? * * Thanks, * * Selina * * foo-selina:/u/selina: ra 192.5.4 * route: 192.5.4.0/23 * descr: Vixie Enterprises * descr: 116 Stanley Street * descr: Redwood City * descr: CA 94062, USA * origin: AS3557 * comm-list: COMM_NSFNET * advisory: AS690 1:3561(11) 2:3561(218) 4:200(144) 5:701(147) * mnt-by: MAINT-AS3557 * changed: nsfnet-admin at merit.edu 950118 * source: RADB * * route: 192.5.4.0/23 * descr: NET-VIX2 * origin: AS3557 * advisory: AS690 1:3561(11) 2:3561(144) 3:3561(27) 4:3561(147) 5:3561(2 * 18) 5:701(147) 6:7 * 01(134) * mnt-by: BARRNET * changed: vaf at valinor.barrnet.net 950111 * source: MCI * * foo-selina:/u/selina: ra 192.5.5 * route: 192.5.5.0/24 * descr: Vixie Enterprises * descr: 116 Stanley Street * descr: Redwood City * descr: CA 94062, USA * origin: AS3557 * comm-list: COMM_NSFNET * advisory: AS690 2:200(144) 3:701(147) * mnt-by: MAINT-AS3557 * changed: nsfnet-admin at merit.edu 940729 * source: RADB * * route: 192.5.4.0/23 * descr: NET-VIX2 * origin: AS3557 * advisory: AS690 1:3561(11) 2:3561(144) 3:3561(27) 4:3561(147) 5:3561(2 * 18) 5:701(147) 6:7 * 01(134) * mnt-by: BARRNET * changed: vaf at valinor.barrnet.net 950111 * source: MCI * * * > bugsy-sfp:/u/sfp: whois -h whois.ra.net 194.128 * > route: 194.128.0.0/15 * > descr: PIPEX-BLOCK3 * > origin: AS1849 * > advisory: AS690 1:1849 2:701(147) 3:701(134) 4:1800 * > remarks: Holes to come! * > mnt-by: AS1849-MNT * > changed: tim at pipex.net 950428 * > source: RIPE * > * > bugsy-sfp:/u/sfp: whois -h whois.ra.net 194.128/15 * > route: 194.128.0.0/15 * > descr: PIPEX Ltd * > descr: 216 Cambridge Science Park * > descr: Milton Road * > descr: Cambridge * > descr: England * > descr: CB4 4WA * > descr: UNITED KINGDOM * > origin: AS1849 * > comm-list: COMM_NSFNET * > advisory: AS690 1:1849 2:701(147) 4:1800 * > mnt-by: MAINT-AS1849 * > changed: support at pipex.net 950511 * > source: RADB * > * > route: 194.128.0.0/15 * > descr: PIPEX-BLOCK3 * > origin: AS1849 * > advisory: AS690 1:1849 2:701(147) 3:701(134) 4:1800 * > remarks: Holes to come! * > mnt-by: AS1849-MNT * > changed: tim at pipex.net 950428 * > source: RIPE * * > * > Dear all, * > * > Recently Tony Bates found an authorisation problem in 'updatecheck.pl'. * > Today my fix is ready. Please apply this fix to your software! * > * > Furthermore, I included the recent fixes made by Tony for : * > * > net2net.pl * > misc.pl * > * > in the distribution and a small one from Curtis Villamizar for : * > * > dbupdate.pl * > * > I plan to add also some other fixes from Curtis in the next release. * > * > Kind regards, * > * > David Kessens * > RIPE NCC Database software maintainer * > * > ====================================================================== * > * > How to apply the fix(es) : * > * > Fix src/filename.pl with 'patch' or just put in the corresponding * > file(s) of the new distribution (ftp:/ftp.ripe.net/ripe/dbase/software, * > file with latest version number). Always make a backup copy of the old * > file(s) to be able to restore the original software in case you might * > experience problems. After the fix(es) are applied, do a 'make install' * > from the database root directory to install the patched file(s). * > * > The following files have been changed from the previous release: * > * > updatecheck.pl * > dbupdate.pl * > net2net.pl * > misc.pl * > * > ====================================================================== * > *** /ncc/dbase/src/old/updatecheck.pl Tue Jan 17 17:37:36 1995 * > --- /ncc/dbase/src/updatecheck.pl Tue May 30 18:47:24 1995 * > *************** * > *** 1,7 **** * > # $RCSfile: updatecheck.pl,v $ * > ! # $Revision: 1.19 $ * > # $Author: ripe-dbm $ * > ! # $Date: 1995/01/17 16:37:36 $ * > * > require "defines.pl"; * > require "adderror.pl"; * > --- 1,7 ---- * > # $RCSfile: updatecheck.pl,v $ * > ! # $Revision: 1.20 $ * > # $Author: ripe-dbm $ * > ! # $Date: 1995/05/30 13:34:47 $ * > * > require "defines.pl"; * > require "adderror.pl"; * > *************** * > *** 70,79 **** * > } * > * > * > ! # Check authorisation by maintainer unless override is specified. * > * > if (!$new{"uo"} && !&Maintainer(*cur, *new)) { * > ! return $E_AUTHFAIL unless !&entype(*new); * > } * > * > # Catch if called from dbdel, then skip all checks, * > --- 70,80 ---- * > } * > * > * > ! # Check authorisation by maintainer unless override is specified * > ! # and handles special (dirty trick) delete case with $new in $cur * > * > if (!$new{"uo"} && !&Maintainer(*cur, *new)) { * > ! return $E_AUTHFAIL if !$cur{"uo"}; * > } * > * > # Catch if called from dbdel, then skip all checks, * > *** /ncc/dbase/src/old/dbupdate.pl Tue May 30 18:38:57 1995 * > --- /ncc/dbase/src/dbupdate.pl Tue May 30 18:48:17 1995 * > *************** * > *** 1,9 **** * > #!PERL * > * > # $RCSfile: dbupdate.pl,v $ * > ! # $Revision: 0.33 $ * > ! # $Author: david $ * > ! # $Date: 1995/02/24 11:13:22 $ * > * > # This is a client that will update objects read from a file directly * > # in the database, without interference of updated. * > --- 1,9 ---- * > #!PERL * > * > # $RCSfile: dbupdate.pl,v $ * > ! # $Revision: 0.34 $ * > ! # $Author: ripe-dbm $ * > ! # $Date: 1995/05/30 14:44:09 $ * > * > # This is a client that will update objects read from a file directly * > # in the database, without interference of updated. * > *************** * > *** 46,52 **** * > # -F - Do fast update without mail and other stuff * > # -S - Do only syntax check - Not implemented * > * > ! &Getopts('ln:vMAHVFS'); * > * > # Need this below for running perl in tainted mode. * > * > --- 46,52 ---- * > # -F - Do fast update without mail and other stuff * > # -S - Do only syntax check - Not implemented * > * > ! &Getopts('l:n:vMAHVFS'); * > * > # Need this below for running perl in tainted mode. * > * > *** /ncc/dbase/src/old/net2net.pl Tue May 30 18:43:22 1995 * > --- /ncc/dbase/src/net2net.pl Tue May 30 18:49:30 1995 * > *************** * > *** 1,8 **** * > # * > # $RCSfile: net2net.pl,v $ * > ! # $Revision: 0.13 $ * > ! # $Author: tony $ * > ! # $Date: 1994/09/20 12:27:36 $ * > # * > # net2net.pl * > # * > --- 1,8 ---- * > # * > # $RCSfile: net2net.pl,v $ * > ! # $Revision: 0.14 $ * > ! # $Author: ripe-dbm $ * > ! # $Date: 1995/05/30 16:45:19 $ * > # * > # net2net.pl * > # * > *************** * > *** 140,147 **** * > $len = 16; * > } elsif ($2 == 0 && $3 == 0 && $4 == 0) { * > $len = 8; * > } * > ! @return_rep = (@return_rep, $net_rep."/".$len); * > return $OK, "", @return_rep; * > } else { * > return $NOK, * > --- 140,152 ---- * > $len = 16; * > } elsif ($2 == 0 && $3 == 0 && $4 == 0) { * > $len = 8; * > + } else { * > + return $NOK, * > + "$net_rep is not a classful net representation I understand * ", * > + @return_rep; * > } * > ! local($val) = &trimnet($net_rep); * > ! @return_rep = (@return_rep, $val."/".$len); * > return $OK, "", @return_rep; * > } else { * > return $NOK, * > *************** * > *** 161,167 **** * > local($begin) = &quad2int($oldnet); * > local($end) = &quad2int($2); * > if($end < $begin) { * > ! return $NOK, "range is invalid", @returndtring; * > } * > * > if ($oldnet =~ /(\d+)\.\d+\.\d+\.\d+/) { * > --- 166,172 ---- * > local($begin) = &quad2int($oldnet); * > local($end) = &quad2int($2); * > if($end < $begin) { * > ! return $NOK, "range is invalid", @returnstring; * > } * > * > if ($oldnet =~ /(\d+)\.\d+\.\d+\.\d+/) { * > *************** * > *** 236,242 **** * > "based on prefix $usepre", * > @returnstring; * > } * > ! return $OK, "", $net_rep; * > } else { * > return $NOK, * > "$net_rep is not an representation I understand", * > --- 241,249 ---- * > "based on prefix $usepre", * > @returnstring; * > } * > ! local($val) = &trimnet($net); * > ! @returnstring = "$val"."/".$len; * > ! return $OK, "", @returnstring; * > } else { * > return $NOK, * > "$net_rep is not an representation I understand", * > *************** * > *** 370,373 **** * > --- 377,386 ---- * > } * > return( $s ); * > } * > + * > + sub trimnet { * > + local($quad) = @_; * > + return(&int2quad(&quad2int($quad))); * > + } * > 1; * > + * > *** /ncc/dbase/src/old/misc.pl Wed May 31 14:06:18 1995 * > --- /ncc/dbase/src/misc.pl Wed May 31 14:08:13 1995 * > *************** * > *** 1,9 **** * > # misc - miscellaneaous functions * > # * > # $RCSfile: misc.pl,v $ * > ! # $Revision: 0.44 $ * > ! # $Author: marten $ * > ! # $Date: 1994/12/16 11:06:55 $ * > # * > * > require "defines.pl"; * > --- 1,9 ---- * > # misc - miscellaneaous functions * > # * > # $RCSfile: misc.pl,v $ * > ! # $Revision: 0.45 $ * > ! # $Author: ripe-dbm $ * > ! # $Date: 1995/05/31 12:04:40 $ * > # * > * > require "defines.pl"; * > *************** * > *** 197,203 **** * > # * > sub iscommunity { * > local($str) = @_; * > ! return 0 if $str =~ /[a-z]/; * > foreach $_ ((keys %KEYWORD, "AS")) { * > if (($_ eq "(") || ($_ eq ")")) { * > $_ = "\\".$_; * > --- 197,203 ---- * > # * > sub iscommunity { * > local($str) = @_; * > ! return 0 if $str !~ /[A-Z]+/; * > foreach $_ ((keys %KEYWORD, "AS")) { * > if (($_ eq "(") || ($_ eq ")")) { * > $_ = "\\".$_; * > *** /ncc/dbase/src/old/updatecheck.pl Tue Jan 17 17:37:36 1995 * > --- /ncc/dbase/src/updatecheck.pl Tue May 30 18:47:24 1995 * > *************** * > *** 1,7 **** * > # $RCSfile: updatecheck.pl,v $ * > ! # $Revision: 1.19 $ * > # $Author: ripe-dbm $ * > ! # $Date: 1995/01/17 16:37:36 $ * > * > require "defines.pl"; * > require "adderror.pl"; * > --- 1,7 ---- * > # $RCSfile: updatecheck.pl,v $ * > ! # $Revision: 1.20 $ * > # $Author: ripe-dbm $ * > ! # $Date: 1995/05/30 13:34:47 $ * > * > require "defines.pl"; * > require "adderror.pl"; * > *************** * > *** 70,79 **** * > } * > * > * > ! # Check authorisation by maintainer unless override is specified. * > * > if (!$new{"uo"} && !&Maintainer(*cur, *new)) { * > ! return $E_AUTHFAIL unless !&entype(*new); * > } * > * > # Catch if called from dbdel, then skip all checks, * > --- 70,80 ---- * > } * > * > * > ! # Check authorisation by maintainer unless override is specified * > ! # and handles special (dirty trick) delete case with $new in $cur * > * > if (!$new{"uo"} && !&Maintainer(*cur, *new)) { * > ! return $E_AUTHFAIL if !$cur{"uo"}; * > } * > * > # Catch if called from dbdel, then skip all checks, * > *** /ncc/dbase/src/old/dbupdate.pl Tue May 30 18:38:57 1995 * > --- /ncc/dbase/src/dbupdate.pl Tue May 30 18:48:17 1995 * > *************** * > *** 1,9 **** * > #!PERL * > * > # $RCSfile: dbupdate.pl,v $ * > ! # $Revision: 0.33 $ * > ! # $Author: david $ * > ! # $Date: 1995/02/24 11:13:22 $ * > * > # This is a client that will update objects read from a file directly * > # in the database, without interference of updated. * > --- 1,9 ---- * > #!PERL * > * > # $RCSfile: dbupdate.pl,v $ * > ! # $Revision: 0.34 $ * > ! # $Author: ripe-dbm $ * > ! # $Date: 1995/05/30 14:44:09 $ * > * > # This is a client that will update objects read from a file directly * > # in the database, without interference of updated. * > *************** * > *** 46,52 **** * > # -F - Do fast update without mail and other stuff * > # -S - Do only syntax check - Not implemented * > * > ! &Getopts('ln:vMAHVFS'); * > * > # Need this below for running perl in tainted mode. * > * > --- 46,52 ---- * > # -F - Do fast update without mail and other stuff * > # -S - Do only syntax check - Not implemented * > * > ! &Getopts('l:n:vMAHVFS'); * > * > # Need this below for running perl in tainted mode. * > * > *** /ncc/dbase/src/old/net2net.pl Tue May 30 18:43:22 1995 * > --- /ncc/dbase/src/net2net.pl Tue May 30 18:49:30 1995 * > *************** * > *** 1,8 **** * > # * > # $RCSfile: net2net.pl,v $ * > ! # $Revision: 0.13 $ * > ! # $Author: tony $ * > ! # $Date: 1994/09/20 12:27:36 $ * > # * > # net2net.pl * > # * > --- 1,8 ---- * > # * > # $RCSfile: net2net.pl,v $ * > ! # $Revision: 0.14 $ * > ! # $Author: ripe-dbm $ * > ! # $Date: 1995/05/30 16:45:19 $ * > # * > # net2net.pl * > # * > *************** * > *** 140,147 **** * > $len = 16; * > } elsif ($2 == 0 && $3 == 0 && $4 == 0) { * > $len = 8; * > } * > ! @return_rep = (@return_rep, $net_rep."/".$len); * > return $OK, "", @return_rep; * > } else { * > return $NOK, * > --- 140,152 ---- * > $len = 16; * > } elsif ($2 == 0 && $3 == 0 && $4 == 0) { * > $len = 8; * > + } else { * > + return $NOK, * > + "$net_rep is not a classful net representation I understand * ", * > + @return_rep; * > } * > ! local($val) = &trimnet($net_rep); * > ! @return_rep = (@return_rep, $val."/".$len); * > return $OK, "", @return_rep; * > } else { * > return $NOK, * > *************** * > *** 161,167 **** * > local($begin) = &quad2int($oldnet); * > local($end) = &quad2int($2); * > if($end < $begin) { * > ! return $NOK, "range is invalid", @returndtring; * > } * > * > if ($oldnet =~ /(\d+)\.\d+\.\d+\.\d+/) { * > --- 166,172 ---- * > local($begin) = &quad2int($oldnet); * > local($end) = &quad2int($2); * > if($end < $begin) { * > ! return $NOK, "range is invalid", @returnstring; * > } * > * > if ($oldnet =~ /(\d+)\.\d+\.\d+\.\d+/) { * > *************** * > *** 236,242 **** * > "based on prefix $usepre", * > @returnstring; * > } * > ! return $OK, "", $net_rep; * > } else { * > return $NOK, * > "$net_rep is not an representation I understand", * > --- 241,249 ---- * > "based on prefix $usepre", * > @returnstring; * > } * > ! local($val) = &trimnet($net); * > ! @returnstring = "$val"."/".$len; * > ! return $OK, "", @returnstring; * > } else { * > return $NOK, * > "$net_rep is not an representation I understand", * > *************** * > *** 370,373 **** * > --- 377,386 ---- * > } * > return( $s ); * > } * > + * > + sub trimnet { * > + local($quad) = @_; * > + return(&int2quad(&quad2int($quad))); * > + } * > 1; * > + * > *** /ncc/dbase/src/old/misc.pl Wed May 31 14:06:18 1995 * > --- /ncc/dbase/src/misc.pl Wed May 31 14:08:13 1995 * > *************** * > *** 1,9 **** * > # misc - miscellaneaous functions * > # * > # $RCSfile: misc.pl,v $ * > ! # $Revision: 0.44 $ * > ! # $Author: marten $ * > ! # $Date: 1994/12/16 11:06:55 $ * > # * > * > require "defines.pl"; * > --- 1,9 ---- * > # misc - miscellaneaous functions * > # * > # $RCSfile: misc.pl,v $ * > ! # $Revision: 0.45 $ * > ! # $Author: ripe-dbm $ * > ! # $Date: 1995/05/31 12:04:40 $ * > # * > * > require "defines.pl"; * > *************** * > *** 197,203 **** * > # * > sub iscommunity { * > local($str) = @_; * > ! return 0 if $str =~ /[a-z]/; * > foreach $_ ((keys %KEYWORD, "AS")) { * > if (($_ eq "(") || ($_ eq ")")) { * > $_ = "\\".$_; * > --- 197,203 ---- * > # * > sub iscommunity { * > local($str) = @_; * > ! return 0 if $str !~ /[A-Z]+/; * > foreach $_ ((keys %KEYWORD, "AS")) { * > if (($_ eq "(") || ($_ eq ")")) { * > $_ = "\\".$_; * > * > * > --- End of fix(es) --- -------- Logged at Thu Jun 1 08:45:07 MET DST 1995 ---------