From dsj at merit.edu Mon Dec 5 20:27:55 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Mon, 5 Dec 1994 14:27:55 -0500 Subject: Meeting Tonight Message-ID: <199412051927.OAA15309@merit.edu> For the GRR meeting at IETF TONIGHT, after the rwhois bof: Here are some potential things to discuss: A) Handling multiple databases. What about "communities", maintainers that span multiple DBs? "Recursive" whois (& other queries)? What DBs should a query return? (hopefull all GRR DBs; I understand whoisd doesn't do this currently). B) Exchange formats: FTP (redoing indexing after each FTP: 8 hrs per day?) FTP (copying existing indexing over?) Realtime global updates? ("Meta-BGP") Synchronizaiton; resynch operations C) Common names for use at all GRRs. (probably not "ripe-dbm") GRR publicity; global RR mailbox? D) Config file generators and other potentially common tools & servers. E) Specific handling of MCI & CANET F) Status of "advisory" attribute. other topics? --Dale -------- Logged at Tue Dec 6 00:27:43 MET 1994 --------- From dsj at merit.edu Tue Dec 6 00:27:34 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Mon, 5 Dec 1994 18:27:34 -0500 Subject: Real Policy at MAE East Message-ID: <199412052327.SAA02857@merit.edu> FYI (probably ANS Confidential): Selina has been working out how to implement ANS MAE-East policy in RIPE-181. Here is what she's come up with: > From sfp at ans.net Mon Dec 5 16:31:07 1994 > To: dsj at merit.edu > Subject: mae east policy > Date: Mon, 05 Dec 1994 16:31:02 -0500 > From: Selina Priestley > > > Hi Dale, > > Here's what we will work with initially to get an idea for how > a cisco might work at MaeEast. Below are the *tentative* homeAS > policy lines that I based the Mae-East policy on.. (these are the > homeASs affected one way or another by mae. ) > > Selina > > > MAE-EAST: > as-in: from as 86 at E136 pref 101 548 1236 > as-in: from as 86 at E136 pref 102 1312 2548 > as-in: from as 86 at E136 pref 103 86 225 1842 2532 2714 3113 3133 3135 > as-in: from as 86 at E136 pref 104 279 2048 2637 3450 3512 3561 3749 > as-in: from as 701 at E136 pref 101 35 286 545 558 701 719 790 813 1234 1267 1270 1290 1705 1729 1732 1752 1759 1836 1888 1890 1891 1897 1899 1901 1963 2004 2028 2049 2056 2109 2110 2112 2116 2118 2125 2134 2135 2136 2148 2497 2578 2609 2610 2766 2819 2820 2822 2855 2865 2875 2876 2927 3836 3844 3855 3976 > as-in: from as 701 at E136 pref 102 560 696 1294 1741 1822 2871 2873 2917 3225 3244 > as-in: from as 701 at E136 pref 103 3 33 1273 2493 2643 2861 3557 > as-in: from as 701 at E136 pref 104 288 1903 2276 2383 3333 > as-in: from as 1674 at E136 pref 102 513 559 789 1133 1776 1853 1903 1902 2060 2494 2607 > as-in: from as 1674 at E136 pref 103 766 1125 1128 1134 1274 1955 2043 2546 2598 2602 2611 2614 3058 3208 3219 > as-in: from as 1674 at E136 pref 104 137 1103 1104 1717 1754 2038 2561 2601 2879 3215 3259 > as-in: from as 1849 at E136 pref 101 2871 2873 2917 3244 > as-in: from as 1879 at E136 pref 101 2600 > as-in: from as 1879 at E136 pref 102 224 244 565 1248 1257 1654 1739 1741 1835 1850 1880 1882 1883 2119 2120 2380 2588 2603 2831 2832 2834 2836 2840 2841 2843 2845 2846 2847 3221 3333 > as-in: from as 2149 at E136 pref 101 174 378 1204 1794 2149 2554 2706 2915 3250 > as-in: from as 2149 at E136 pref 102 2649 > as-in: from as 2149 at E136 pref 201 2538 > as-in: from as 2551 at E136 pref 101 2551 > as-in: from as 3830 at E136 pref 101 3830 3720 3915 > > some homeASs > 3 1:3 2:560 3:701(136) 4:701(134) > 19 1:19 2:568 > 33 1:200(128) 2:200(144) 3:701(136) 4:701(134) > 35 1:701(136) 2:701(134) > 43 1:293(145) 2:293(144) 3:174 > 45 1:293(144) 2:293(145) 3:200(128) 4:200(144) > 60 1:2699(145) 2:2699(144) > 71 1:200(128) 2:200(144) 3:2149 4:174 5:560 > 86 1:3561(218) 2:3561(11) 3:86 4:279 > 97 1:97 > 137 1:293(144) 2:293(145) 3:1133 4:1674 5:1800 > 174 1:2149 2:174 > 195 1:195 2:1740(218) 3:1740(135) > 200 1:200(128) 2:200(144) 3:1740 > 209 1:209 2:210 > 224 1:1800 2:1879 3:1133 4:1240 > 225 1:3561(218) 2:3561(11) 3:86 4:279 > 244 1:1800 2:1879 3:1133 4:1240 > 270 1:297(145) 2:297(144) 3:372 > 274 1:3561(218) 2:3561(11) 3:279 4:86 > 279 1:3561(218) 2:3561(11) 3:279 4:86 > 286 1:701(136) 2:701(134) 3:1800 > 288 1:297(145) 2:297(144) 3:372 4:701(136) 5:701(134) 6:1800 > 293 1:293(145) 2:293(144) > 297 1:297(145) 2:297(144) 3:372 > 378 1:2149 2:174 3:1800 4:1240 5:1133 > 513 1:1133 2:1674 3:1800 4:1240 > 517 1:1800 ...? working... > 544 1:1800 2:1879 3:1133 4:1240 > 545 1:701(136) 2:701(134) 3:545 4:237 5:233 > 548 1:86 2:279 3:568 4:19 > 558 1:701(136) 2:701(134) > 559 1:1133 2:1674 3:1800 > 560 1:560 2:701(136) 3:701(134) > 565 1:1800 2:1879 3:1133 4:1240 > 600 1:1800 2:1240 3:1239 > 668 1:668 2:22 3:175 4:19 5:568 > 679 1:1800 2:1133 3:1240 > 685 1:685 2:73 3:101 > 696 1:560 2:701(136) 3:701(134) > 701 1:701(136) 2:701(134) > 719 1:701(136) 2:701(134) 3:1800 > 760 1:1800 2:1133 3:1240 > 766 1:1800 2:1133 3:1674 4:1240 > 786 1:1800 2:1133 3:1240 > 789 1:1133 2:1674 3:1800 4:1240 > 790 1:701(136) 2:701(134) 3:1800 > 813 1:701(136) 2:701(134) > 1103 1:1128 2:1800 3:1133 4:1674 5:1240 > 1104 1:1128 2:1800 3:1133 4:1674 5:1240 > 1115 1:1800 2:1133 3:1240 > 1117 1:1800 2:1133 3:1240 > 1125 1:1800 2:1133 3:1674 4:1240 > 1128 1:1800 2:1133 3:1674 4:1240 > 1133 1:1133 2:1674 3:1800 > 1134 1:1800 2:1133 3:1674 4:1240 > 1204 1:2149 2:174 > 1205 1:1133 2:1674 3:1800 > 1206 1:1206 2:204 > 1213 1:1800 2:1133 3:1240 > 1234 1:701(136) 2:701(134) 3:1800 > 1236 1:86 2:279 3:1740(135) > 1239 1:1800 2:1240 3:1239 > 1241 1:1800 2:1133 3:1240 > 1248 1:1800 2:1879 3:1133 4:1240 > 1257 1:1800 2:1879 3:1133 4:1240 > 1262 1:297(141) 2:297(144) 3:372 4:297(145) > 1267 1:701(136) 2:701(134) 3:1800 > 1270 1:701(136) 2:701(134) 3:1800 > 1273 1:1800 2:1240 3:701(136) 4:701(134) > 1274 1:1800 2:1133 3:1674 4:1240 > 1275 1:293(145) 2:293(144) > 1290 1:701(136) 2:701(134) 3:1800 > 1294 1:1328 2:701(136) 3:701(134) > 1312 1:1312 > 1347 1:1225(130) 2:1225(129) 3:1225(131) 4:555 > 1653 1:1800 2:1879 3:1133 4:1240 > 1654 1:1800 2:1879 3:1133 4:1240 > 1662 1:1662 > 1705 1:701(136) 2:701(134) > 1717 1:1800 2:1240 3:1133 4:1674 > 1729 1:701(136) 2:701(134) 3:1800 > 1732 1:701(136) 2:701(134) > 1739 1:1800 2:1879 3:1133 4:1240 > 1740 1:1740(218) 2:1740(135) > 1741 1:1800 2:1879 3:1133 4:1240 > 1752 1:3561(218) 2:3561(11) 3:701(136) 4:1849 5:701(134) 6:1800 > 1754 1:293(145) 2:293(144) 3:1133 4:1674 5:1800 > 1755 1:1133 2:1674 3:1800 4:1240 5:701(136) 6:701(134) > 1759 1:701(136) 2:701(134) > 1776 1:1133 2:1674 3:1800 > 1784 1:1800 2:1240 3:1239 > 1790 1:1800 2:1240 3:1239 > 1794 1:2149 2:174 3:1239 4:1800 5:1240 > 1798 1:1240 2:1800 > 1800 1:1800 2:1240 > 1822 1:560 2:701(136) 3:701(134) > 1835 1:1800 2:1879 3:1133 4:1240 > 1836 1:701(136) 2:701(134) 3:1800 > 1842 1:200(128) 2:200(144) 3:86 4:279 > 1849 1:1849 2:701(136) 3:701(134) 4:1800 > 1850 1:1800 2:1879 3:1133 4:1240 > 1853 1:1133 2:1674 3:1800 > 1880 1:1800 2:1879 3:1133 4:1240 > 1882 1:1800 2:1879 3:1133 4:1240 > 1883 1:1800 2:1879 3:1133 4:1240 > 1887 1:1800 2:1879 3:1133 4:1240 > 1888 1:701(136) 2:701(134) 3:1800 > 1890 1:701(136) 2:701(134) 3:1800 > 1891 1:701(136) 2:701(134) 3:1800 > 1897 1:701(136) 2:701(134) 3:1240 4:1800 > 1899 1:701(136) 2:701(134) 3:1800 > 1901 1:701(136) 2:701(134) 3:1800 > 1902 1:1133 2:1674 3:1800 > 1903 1:1133 2:1674 3:1800 4:701(136) 5:701(134) > 1922 1:1800 2:1133 3:1240 > 1930 1:1800 2:1133 3:1240 > 1955 1:1800 2:1133 3:1674 4:1240 > 1963 1:701(136) 2:701(134) 3:2149 4:174 > 2004 1:701(136) 2:701(134) 3:1800 > 2012 1:1133 2:1674 3:1800 > 2018 1:1800 2:1240 3:1239 > 2028 1:701(136) 2:701(134) 3:1800 > 2033 1:1800 2:1240 > 2038 1:293(144) 2:293(145) 3:1133 4:1674 5:1800 > 2043 1:1800 2:1133 3:1674 4:1240 > 2048 1:3561(218) 2:3561(11) 3:279 4:86 > 2049 1:701(136) 2:701(134) 3:1800 > 2056 1:1327 2:701(136) 3:701(134) 4:1329 > 2060 1:1133 2:1674 3:1800 4:1240 > 2107 1:1800 2:1133 3:1674 4:1240 > 2108 1:1800 2:1133 3:1240 > 2109 1:701(136) 2:701(134) 3:1800 > 2110 1:701(136) 2:701(134) 3:1800 > 2111 1:1800 2:1240 3:1133 > 2112 1:701(136) 2:701(134) > 2116 1:701(136) 2:701(134) 3:1800 > 2118 1:701(136) 2:701(134) 3:1800 > 2119 1:1800 2:1879 3:1133 4:1240 > 2120 1:1800 2:1879 3:1133 4:1240 > 2125 1:701(136) 2:701(134) 3:1800 > 2131 1:1800 2:1133 3:1240 > 2134 1:701(136) 2:701(134) 3:1800 > 2135 1:701(136) 2:701(134) 3:1800 > 2136 1:701(136) 2:701(134) 3:1800 > 2148 1:701(136) 2:701(134) 3:1800 > 2149 1:2149 2:174 > 2276 1:1800 2:1240 3:3354 4:701(136) 5:701(134) > 2380 1:1800 2:1879 3:1133 4:1240 > 2383 1:1800 2:1240 3:1239 4:701(136) 5:701(134) > 2386 1:2386 2:1321 > 2493 1:2493(35) 2:2493(91) > 2494 1:1133 2:1674 3:1800 > 2497 1:701(136) 2:701(134) > 2532 1:3561(218) 2:3561(11) 3:86 4:279 > 2538 s:2538 128:2149 129:174 > 2546 1:1800 2:1133 3:1674 > 2548 1:2548 ?? working... > 2551 1:2551 2:1321 > 2554 1:2149 2:174 > 2561 1:1800 2:1240 3:1133 4:1674 > 2578 1:701(136) 2:701(134) 5:1800 > 2588 1:1800 2:1879 3:1133 4:1240 > 2598 1:1800 2:1133 3:1674 4:1240 > 2600 1:1879 2:1133 3:1674 4:1800 > 2601 1:1800 2:1240 3:1133 4:1674 > 2602 1:1800 2:1133 3:1674 4:1240 > 2603 1:1800 2:1879 3:1133 4:1240 > 2604 1:1133 2:1800 3:1240 > 2605 1:1800 2:1133 3:1240 > 2607 1:1133 2:1674 3:1800 > 2609 1:701(136) 2:701(134) 3:1800 > 2610 1:701(136) 2:701(134) 3:1800 > 2611 1:1800 2:1133 3:1674 4:1240 > 2614 1:1800 2:1133 3:1674 4:1240 > 2637 1:3561(218) 2:3561(11) 3:279 4:86 > 2643 1:1800 2:1240 3:701(136) > 2649 1:2649 2:2149 3:174 > 2683 1:1800 2:1240 > 2685 1:2685 2:701(136) 3:701(134) 4:279 5:86 > 2706 1:2149 2:174 3:297(144) 4:372 5:297(145) > 2711 1:1329 > 2714 1:3561(218) 2:3561(11) 3:86 4:279 > 2766 1:701(136) 2:701(134) > 2819 1:701(136) 2:701(134) 3:1800 > 2820 1:701(136) 2:701(134) 3:1800 > 2822 1:701(136) 2:701(134) 3:1800 > 2831 1:1800 2:1879 3:1133 4:1240 > 2832 1:1800 2:1879 3:1133 4:1240 > 2834 1:1800 2:1879 3:1133 4:1240 > 2836 1:1800 2:1879 3:1133 4:1240 > 2840 1:1800 2:1879 3:1133 4:1240 > 2841 1:1800 2:1879 3:1133 4:1240 > 2843 1:1800 2:1879 3:1133 4:1240 > 2845 1:1800 2:1879 3:1133 4:1240 > 2846 1:1800 2:1879 3:1133 4:1240 > 2847 1:1800 2:1879 3:1133 4:1240 > 2852 1:1800 2:1133 3:1240 > 2855 1:701(136) 2:701(134) 3:1800 > 2857 1:1324(32) 2:1324(35) 3:1800 4:1240 5:1133 > 2861 1:1800 2:1240 3:701(136) 4:701(134) > 2865 1:701(136) 2:701(134) 3:1800 > 2871 1:1849 2:701(136) 3:701(134) 4:1800 > 2873 1:1849 2:701(136) 3:701(134) 4:1800 > 2874 1:1800 2:1133 3:1240 > 2875 1:701(136) 2:701(134) 3:1800 > 2876 1:701(136) 2:701(134) 3:1800 > 2879 1:293(145) 2:293(144) 3:1133 4:1674 5:1800 > 2905 1:701(136) 2:701(134) > 2914 1:1240 2:1800 3:1239 > 2915 1:2149 2:174 > 2917 1:1849 2:701(136) 3:701(134) 4:1800 > 2927 1:701(136) 2:701(134) > 3058 1:1800 2:1133 3:1674 4:1240 > 3113 1:3561(218) 2:3561(11) 3:86 4:279 > 3133 1:3561(218) 2:3561(11) 3:86 4:279 > 3135 1:3561(218) 2:3561(11) 3:86 4:279 > 3150 1:1800 2:1240 3:1239 > 3208 1:1800 2:1133 3:1674 4:1240 > 3215 1:1800 2:1240 3:1133 4:1674 > 3219 1:1800 2:1133 3:1674 4:1240 > 3221 1:1800 2:1879 3:1133 4:1240 > 3225 1:701(136) 2:701(134) > 3228 1:1800 2:1133 3:1240 > 3244 1:1849 2:701(136) 3:701(134) 4:1800 > 3248 1:1800 2:1133 3:1240 > 3250 1:2149 2:174 3:1800 4:1240 5:1133 > 3252 1:1800 2:1133 3:1240 > 3259 1:1800 2:1240 3:1133 4:1674 > 3333 1:1128 2:1800 3:1879 4:701(136) 5:701(134) 6:1133 > 3354 1:1800 2:1240 3:1239 4:3354 > 3365 1:1800 2:1240 > 3378 1:3561(11) 2:3561(218) 3:1332 4:209 5:210 > 3404 1:1800 2:1240 3:1239 > 3450 1:3561(218) 2:3561(11) 3:279 4:86 > 3512 1:3561(218) 2:3561(11) 3:279 4:86 > 3557 1:200(128) 2:200(144) 3:701(136) 4:701(134) > 3561 1:3561(218) 2:3561(11) 3:279 4:86 > 3563 1:1240 2:1800 > 3578 1:1800 2:1240 3:1239 > 3579 1:1239 2:1800 3:1240 > 3720 1:3830 > 3749 1:3561(218) 2:3561(11) 3:279 4:86 > 3799 1:1239 2:1800 3:1240 > 3830 1:3830 > 3836 1:701(136) 2:701(134) > 3844 1:701(136) 2:701(134) > 3855 1:701(136) 2:701(134) > 3915 1:3830 > 3976 1:701(136) 2:701(134) > > ------- End of Forwarded Message > > -------- Logged at Tue Dec 6 02:32:49 MET 1994 --------- From Marten.Terpstra at ripe.net Tue Dec 6 02:32:47 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Tue, 06 Dec 1994 02:32:47 +0100 Subject: RIPE RR SW fix: cldb.pl Message-ID: <9412060132.AA08979@ncc.ripe.net> Oops sorry folks, forgot you all ;-( [ Put this module in place of /src/cldb.pl, go up to and run a "make". "make install" is not needed - MT ] # $RCSfile: cldb.pl,v $ # $Revision: 1.9 $ # $Author: marten $ # $Date: 1994/12/06 01:09:52 $ # This module contains all routines for classless indexing and lookups # and some routines to do conversions here and there require "misc.pl"; require "defines.pl"; require "time.pl"; # This is triple booo!!!! Change this !!!! # $OVERFLOWDIR = "/ncc/nccfs3/cldb/data"; # # convertonormal($cla) # # converts a integer prefix/length internal structure to a readable # quad prefix/len string sub converttonormal { local($cla) = @_; local($int, $len) = split(/\//, $cla); return &int2quad($int)."/$len"; } # # cla2unikey($cla) # # gives back an array of unique keys into the database that match this # cla. Basically it will extract all the "O" values for $mspnxl{$cla} and # put them into an array. sub cla2unikey { local($cla) = @_; local(@result) = (); local($cla2tmp); &getmspnxl($cla, *cla2tmp); while ($cla2tmp =~ s/^O([^,]+)[,]*//) { next if $1 =~ /DUMMY/; @result = (@result, $1); } return @result; } # # getmspnxl($index) # # gets the value (a string) for a certain index in the assoc array %mspnxl # because of the overflow mechanism, this could be retrieved from a file # or straight from the DBM file sub getmspnxl { local($index, *value) = @_; if ($previous eq $index) { } else { $previous = $index; } &timer("getmspnxl", 1); $value = $mspnxl{$index}; if ($value eq "ETOOBIG") { $value = ""; local($filename) = &converttonormal($index); $filename =~ s/\//\./g; local($counter) = 0; while (!open(FILE, "$OVERFLOWPREFIX.$filename")) { select(undef, undef, undef, 0.05); $counter++; if ($counter > 10) { die "major failure! cannot open $OVERFLOWPREFIX.$filename: $!"; } } sysread(FILE, $value, 1000000, 0); close(FILE); } &timer("getmspnxl", 0); return *value; } # # setmspnxl($index, $value) # # sets the value for a certain index in assoc array %mspnxl. Because of # the 1K max in DBM, the overflow mechanism must be used for large values # In the overflow mechanism, whenever a file needs to be updated, a new # file will be created, and renamed after. This is make the time the file # is not available (for servers) as short as possible. sub setmspnxl { local($index, *value, *addvalue) = @_; &timer("setmspnxl", 1); if (length($value) + length($addvalue) > 950) { if ($addvalue) { $value .= ",$addvalue"; } local($filename) = &converttonormal($index); $filename =~ s/\//\./g; # unlink("$OVERFLOWDIR/$filename.$CUROBJTYPE"); # Create a new file with new values open(FILE, "+>$OVERFLOWPREFIX.$filename,") || die "cannot open $filename: $!"; syswrite(FILE, $value, length($value), 0); close(FILE); # Move the new file to the original. rename("$OVERFLOWPREFIX.$filename,", "$OVERFLOWPREFIX.$filename"); $mspnxl{$index} = "ETOOBIG"; } else { if ($mspnxl{$index} eq "ETOOBIG") { local($filename) = &converttonormal($index); $filename =~ s/\//\./g; unlink("$OVERFLOWPREFIX.$filename"); } if ($addvalue || $value) { if ($addvalue) { $mspnxl{$index} .= ",$addvalue"; } else { $mspnxl{$index} = $value; } } else { delete $mspnxl{$index}; } } &timer("setmspnxl"); } # # old_to_new($oldnet) # # converts old style RIPE database network numbers (single classful net # and classful ranges) to prefix/length format. Prefix/length is the # internal representation used. Routine to convert a range into # prefix/length is happily stolen from "aggis" by Dale Johnson, MERIT # Thanks Dale ;-) sub old_to_new { local($oldnet) = @_; local($len); local(@returnstring) = (); local($one_net); &timer("old_to_new", 1); # Conventional classful nets if ($oldnet =~ /(\d+)\.(\d+)\.(\d+)\.(\d+)/) { if ($1 >= 192) { $len = 24; $len = 32 if $4; $one_net = 0x00000100; } elsif ($1 >= 128) { $len = 16; $len = 32 if $4; $one_net = 0x00010000; } else { $len = 8; $len = 32 if $4; $one_net = 0x01000000; } } # Special case, it can happen that we got a hostaddress and mask # let's make sure we remove the mask when we return this. # this is for ifaddr in inet-rtr if ($oldnet =~ /(\d+\.\d+\.\d+\.\d+)\s+\d+\.\d+\.\d+\.\d+/) { return "$1/$len"; } if ($oldnet !~ /\-/) { &timer("old_to_new"); return "$oldnet/$len"; } # Now, we have a classful range, let's convert this into pref/len if ($oldnet =~ /^(\d+\.\d+\.\d+\.\d+)\s+\-\s+(\d+\.\d+\.\d+\.\d+)/) { local($begin) = &quad2int($1); local($end) = &quad2int($2); local($newbegin) = $begin; while ($newbegin <= $end) { for ($pwr=1; $pwr<24; $pwr++) { $pwr2 = 2 ** $pwr; $thisend = $newbegin + ($pwr2-1)*$one_net; return @returnstring if !$newbegin; if (($thisend > $end) || $newbegin != ($newbegin & $masks[$len-$pwr])) { $pwr--; $giveback = sprintf("%s/%d", &int2quad($newbegin), $len-$pwr); @returnstring = (@returnstring, $giveback); $newbegin = $newbegin + $one_net * 2**$pwr; last; } } } } &timer("old_to_new"); return @returnstring; } # # findlsps($cla, $recursive) # # Find the list of less specifics for prefix $cla. If the recursion # flag is set, all less specifics (lsps) are returned, otherwise only # the first less specific. It is not a recursive routine, but oh well. sub findlsps { local($cla, $recurse) = @_; local($prefix, $len) = split(/\//, $cla); local($returnlist) = ""; local($ii); for ($ii=$len;$ii>=0;$ii--) { local($newcla) = ($prefix & $masks[$ii]); local($tmp); &getmspnxl("$newcla/$ii", *tmp); if ($tmp) { if ($recurse) { if ($returnlist) { $returnlist .= ",$newcla/$ii"; } else { $returnlist = "$newcla/$ii"; } } else { return "$newcla/$ii"; } } } return $returnlist; } # # findmsps($cla, $orig, $first, $nonrecurse) # # routine to find all more specifics of a certain classless address cla. # Because of recursion, it needs to remember the very first $cla it # is called with, which stays in $orig. This is needed to check whether # all found more specifics really are more specific. By default recursion # is on, it will try and find all more specifics. sub findmsps { local($cla, $orig, $first, $nonrecurse) = @_; local($j); local($msps) = ""; # Look up first less specific when the requested $cla does not # exist itself, and use that to find all more specifics. local($tmp); &getmspnxl($orig, *tmp); # Now, if this $cla does not exist itself, we can do two things, # - we can step one level back, and check all them (painful if # you have to step back to 0/0) # - allow only more specifics of prefixes that are actually # in the database, return nothing if the prefix in the DB # does not exist. # If you have indexed with priming on, the first is no problem. # If you have indexed with priming off, the first may take CPU.... # This implements the first solution if (!$tmp && $first) { $cla = (split(/\,/, &findlsps($orig)))[0]; } # And this the second solution # if (!$tmp && $first) { # return $msps; # } $tmp=""; &getmspnxl($cla, *tmp); foreach (split(/,/, $tmp)) { local($tmp); &getmspnxl($_, *tmp); if ($tmp) { local($p1, $l1) = split(/\//, $_); local($p2, $l2) = split(/\//, $orig); if (($p1 & $masks[$l2]) == ($p2 & $masks[$l2])) { if ($nonrecurse) { $msps .= "$_,"; } else { $msps .= $_ . "," . &findmsps($_, $orig,0,0); } } } } $msps; } # # givemsps($string, $cla) # # Give all more specifics of $cla that can be found in $string. I think this # can also be done by findmsps, but I'll keep it in here for now. Only # needed for insertations right now. Returns a sub-string will all more # specifics of $cla. This is a costly operations, and should only be done # for one-off insertations (like normal updates). Indexing a whole (locked) # file should not use this, the "to be inserted" cla's should be presorted. sub givemsps { local(*string, $cla) = @_; local($returnstring) = ""; # return $returnstring; &timer("givemsps", 1); local($pref, $len) = split(/\//, $cla); foreach (split(/,/, $string)) { next if $_ =~ /^O|^start$/; local($tmppref, $tmplen) = split(/\//, $_); next if $tmplen <= $len; if (($tmppref & $masks[$len]) == $pref) { if ($returnstring) { $returnstring .= ",".$_; } else { $returnstring = $_; } } } &timer("givemsps"); return $returnstring; } # # addtomspnxl($index, $value) # # Adds $value to the current value of $mspnxl{$index}. It is a wrapper # for setmspnxl sub addtomspnxl { local($index, *value) = @_; &timer("addtomspnxl", 1); local($addtotmp); &getmspnxl($index, *addtotmp); if ($addtotmp) { &setmspnxl($index, *addtotmp, *value); } else { &setmspnxl($index, *value); } &timer("addtomspnxl"); } # # deletefrommspnxl($index,$value) # # Deletes $value from the current value of $mspnxl{$index}. Basically # another wrapper for setmspnxl sub deletefrommspnxl { local($index, *value) = @_; local($j); local($deletetmp); &getmspnxl($index, *deletetmp); foreach $j (split(/,/, $value)) { if ($deletetmp =~ s/^$j$//g) {} elsif ($deletetmp =~ s/^$j,//g) {} elsif ($deletetmp =~ s/,$j,/,/g) {} elsif ($deletetmp =~ s/,$j$//g) {} } &setmspnxl($index, *deletetmp); } # # inscla($cla, $offset) # # Insert classless address $cla, which has an offset in the database # of $offset, into the tree structure # ! New version that does not store offsets but references to unique # ! keys, which makes the lookup indirect, but makes the classless # ! index independent of the offsets and thus the clean # # Extra flag mspscheck says whether or not a check should be made # for existing more specifics. When using netdbm, they are presorted # and do not have to be msp-checked. For normal insertions, they # should be checked. The reason this is optional is because givemsps # can be quite costly in time.... sub inscla { # local($cla, $offset, $mspscheck) = @_; local($cla, $uniquekey, $mspscheck) = @_; local($j); local($p); if (!$mspnxl{"0/0"}) { $mspnxl{"0/0"} = "start"; } print STDERR "inscla($cla) called\n" if $debug; local($prefix, $len) = split(/\//, $cla); for ($p=$len;$p>=0;$p--) { local($newcla) = ($prefix & $masks[$p]); local($tmp2); &getmspnxl("$newcla/$p", *tmp2); if ($tmp2) { local($tmp); &getmspnxl($cla, *tmp); if (!$tmp) { local($tmp4) = "O$uniquekey"; &setmspnxl($cla, *tmp4); &addtomspnxl("$newcla/$p", *cla); } else { local($tmp) = "O$uniquekey,$tmp"; &setmspnxl($cla, *tmp); } if ($mspscheck) { local($msps) = &givemsps(*tmp2, $cla); &addtomspnxl($cla, *msps); &deletefrommspnxl("$newcla/$p", *msps); } $p=0; } } } # # delfromcla($cla, $value) # delete a specific string from a $cla value. Delete the complete $cla # if the result is an empty reference. sub delfromcla { local($cla, $value) = @_; local($tmp); &getmspnxl($cla, *tmp); if ($tmp){ if ($tmp =~ s/^O$value$//) { &delcla($cla); return; } elsif ($tmp =~ s/^O$value,//) {} elsif ($tmp =~ s/,O$value,/,/) {} elsif ($tmp =~ s/,O$value$//) {} } &setmspnxl($cla, *tmp); } # # delcla($cla) # # Delete a classless address from the internal tree structure sub delcla { local($cla) = @_; &timer("delcla",1); local($q); local($prefix, $len) = split(/\//, $cla); for ($q=$len-1;$q>=0;$q--) { local($newcla) = ($prefix & $masks[$q]); local($tmp2); &getmspnxl("$newcla/$q", *tmp2); if ($tmp2) { &deletefrommspnxl("$newcla/$q", *cla); local($tmp); &getmspnxl($cla, *tmp); if ($tmp) { local($nothing); $tmp =~ s/^[^,]+[,]*//; &addtomspnxl("$newcla/$q", *tmp) if ($tmp ne ""); &setmspnxl($cla, *nothing, *nothing); } $q = 0; } } &timer("delcla"); } -------- Logged at Wed Dec 21 20:11:42 MET 1994 --------- From cengiz at ISI.EDU Wed Dec 21 20:11:12 1994 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Wed, 21 Dec 1994 11:11:12 -0800 Subject: RtConfig beta release available Message-ID: <199412211911.AA20237@cat.isi.edu> We are happy to announce that RtConfig is available in ftp.ra.net:pub/tools/RAToolSet/RtConfig-R0.1.tar.gz for beta use. g++ is needed to install RtConfig. If you do not have g++, we provide statically linked sparc executables in the same directory. This distribution includes our policy evaluator as a subcomponent. We appreciate any feedback, bug reports/fixes, suggestions and improvements. Andy & Cengiz -- Cengiz Alaettinoglu Information Sciences Institute Voice: (310) 822-1511 University of Southern California -------- Logged at Thu Dec 22 15:06:14 MET 1994 --------- From M.H.Behringer at dante.org.uk Thu Dec 22 15:01:37 1994 From: M.H.Behringer at dante.org.uk (Michael H. Behringer) Date: Thu, 22 Dec 1994 14:01:37 +0000 Subject: Migration to RIPE 181 Message-ID: Dale, Thanks for your reply. I take all your points, but I'm still not sure what Europeans then have to do, once the PRDB is retired, and the RIPE DB is not ready yet to support the advisory attribute for all European nets. Because then you cannot reasonably use the RIPE-DB, as the info there is not complete, but the Europeans can't send in NACRs either, because the PRDB doesn't exist any longer. My view is that the RIPE-DB *has* to be ready by the time the PRDB retires to not mess things up for Europe. I do not see how we (in Europe) can reasonably work with a unfinished RIPE-DB and no PRDB any more. Do you? Michael At 5:46 pm 21/12/94, Dale S. Johnson wrote: >Michael, > > I had been thinking that this transition to using native RIPE data >(with advisory attributes embedded) would be a second phase of AS690 >configurations--probably near the end of February. It would be good >to get an advance start on it, however. This change will actually be >very little coding work for us (just take data from an additional >source). It will have considerably more effect on RIPE and end-users. >RIPE will need to support the advisory attribute, probably go through >an initial mass-loading of it (coordinated with the users), and presumably >deal with questions about it for the next six or so months. (Merit >will of course also be offering support). Since this change will both >be visible to users, and will require changes in their behavior (e.g. >maintaining the advisory attribute in their route objects), it would >be good to get started on this quite soon. > > If the advisory attribute was in the software and initial values >were in place for all routes, and if we decided that users had had >enough advanced notice and training, then we could probably make the >step of converting to this data very quickly after the PRDB is retired >in January. > >--Dale > > >> From M.H.Behringer at dante.org.uk Wed Dec 21 07:57:32 1994 >> Date: Wed, 21 Dec 1994 12:58:01 +0000 >> To: epg at merit.edu >> From: M.H.Behringer at dante.org.uk (Michael H. Behringer) >> Subject: Re: Migration to RIPE 181 >> Cc: dsj at merit.edu >> >> Hi Elise, >> >> Thanks for your response. I just want to quickly verify something. >> >> At 1:53 pm 20/12/94, epg at merit.edu wrote: >> [...] >> >Yes, we have an agreement with the RIPE NCC that they will support the >> >advisory attribute. I believe that when the RIPE NCC implemented >> >181, this was forseen. I have copied Dale Johnson who has been >> >coordinating with Marten on this so he can correct me if I have >> >gotten it wrong. >> >> I know this is foreseen in the RIPE DB, and I know this has to be done >> (thats why I'm asking). Does this mean that by the 15th January the >> advisory attribute has to be in all RIPE DB route entries, and all networks >> that do not have this attribute by then will not be routed through NSFnet? >> >> Or will you still keep the current config for a while, to make sure none of >> the nets looses US connectivity. If so, when is the deadline for dropping >> this? >> >> >The goal is that no one will have to register twice. We propose to >> >derive the AS690 configs from the RADB and the RIPE Routing Registry. >> >> Good. >> >> Thanks for your help, Elise, >> >> Michael >> >> >> -------- Logged at Thu Dec 22 15:16:49 MET 1994 --------- From Marten.Terpstra at ripe.net Thu Dec 22 15:16:47 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Thu, 22 Dec 1994 15:16:47 +0100 Subject: Migration to RIPE 181 In-Reply-To: Your message of Thu, 22 Dec 1994 14:01:37 GMT. Message-ID: <9412221416.AA06645@ncc.ripe.net> M.H.Behringer at dante.org.uk (Michael H. Behringer) writes * Dale, * * Thanks for your reply. I take all your points, but I'm still not sure what * Europeans then have to do, once the PRDB is retired, and the RIPE DB is not * ready yet to support the advisory attribute for all European nets. Because * then you cannot reasonably use the RIPE-DB, as the info there is not * complete, but the Europeans can't send in NACRs either, because the PRDB * doesn't exist any longer. * * My view is that the RIPE-DB *has* to be ready by the time the PRDB retires * to not mess things up for Europe. I do not see how we (in Europe) can * reasonably work with a unfinished RIPE-DB and no PRDB any more. Do you? Just to make sure that the RIPE DB as such supports the advisory attribute, however there are no routes currently that contain this attribute. Perhaps MERIT should inform a wider audience about what is expected from them when the NACRs are retired .... -Marten -------- Logged at Thu Dec 22 15:46:04 MET 1994 --------- From epg at merit.edu Thu Dec 22 15:45:42 1994 From: epg at merit.edu (Elise Gerich) Date: Thu, 22 Dec 1994 09:45:42 -0500 Subject: RtConfig beta release available Message-ID: <199412221445.JAA04780@home.merit.edu> Way to go, Rick, Andy and Cengiz! Congrats! --Elise ----------forwarded message From cengiz at ISI.EDU Wed Dec 21 20:11:12 1994 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Wed, 21 Dec 1994 11:11:12 -0800 Subject: RtConfig beta release available Message-ID: <199412211911.AA20237@cat.isi.edu> We are happy to announce that RtConfig is available in ftp.ra.net:pub/tools/RAToolSet/RtConfig-R0.1.tar.gz for beta use. g++ is needed to install RtConfig. If you do not have g++, we provide statically linked sparc executables in the same directory. This distribution includes our policy evaluator as a subcomponent. We appreciate any feedback, bug reports/fixes, suggestions and improvements. Andy & Cengiz -- Cengiz Alaettinoglu Information Sciences Institute Voice: (310) 822-1511 University of Southern California -------- Logged at Thu Dec 22 17:59:14 MET 1994 --------- From Tony.Bates at mci.net Thu Dec 22 17:59:05 1994 From: Tony.Bates at mci.net (Tony Bates) Date: Thu, 22 Dec 1994 11:59:05 -0500 Subject: MCI RR data available daily from ftp.mci.net Message-ID: <199412221659.LAA03209@lovefm.reston.mci.net> Please note: the mci RR is now available rom ftp.mci.net as follows ftp://ftp.mci.net/pub/rr/mci.db.gz This job runs as part of the clean process. It should be available after 4am EST each day. It is also available in slpit forms as well. The uncompressed version is currently about 1.3 Meg. Dale, I'll talk to you off-line about started the NACR going away process. --Tony. -------- Logged at Thu Dec 22 18:28:40 MET 1994 --------- From dsj at merit.edu Thu Dec 22 18:28:24 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Thu, 22 Dec 1994 12:28:24 -0500 Subject: Migration to RIPE 181 Message-ID: <199412221728.MAA11022@home.merit.edu> Michael, You're right; there's a question here that I haven't answered. But the answer should be reassuring: AS690 will continue accepting NACRs and/or Route Objects as long as necessary. We will create yet another RIPE-181 database called "NSF-TRANS" which take the function of the PRDB as long as necessary. This means that Merit will support the following RIPE-181 databases: RADB - "Routing Arbiter Database": Our public portion of the IRR NSF-TRANS - What the PRDB is today, including route objects from the whole world. It will be preloaded from the current contents of the Informix PRDB. We also will continue to support PRDB.db - The "dump" of everything AS690 knows about in 181 format until the IRR is stable and complete enough that PRDB.db is redundant with the rest of the information. (PRDB.db is currently the only source of non-European data that is available to prtraceroute and similar tools). Initially, we will just continue accepting net NACRs at nsfnet-admin@ merit.edu like we have always done. We will mechanically translate these to RIPE-181 route objects, specifying "source: NSF-TRANS". For a testing period, we will update both the Informix PRDB and NSF-TRANS using the same input, and we will compare their output to make sure that the two systems are doing the same thing. When we are comfortable that this new system is working, we will turn off the PRDB and make NSF-TRANS be the operational system generating AS690 configs. Users will not have to be aware of any of this; they continue to submit net NACRs just like they always have done, and AS690 configs continue to be generated from these. They will begin to notice some small changes--reports are retired, rejection messages come from RIPE-181 software rather than from a human--but the basic system remains intact. This is why we have not worried about being aggressive about announcing the details of the changes. (Not to mention we're still working on them...) Within this basic transition strategy, a couple of other things can be happening on relatively independent timeframes. We have talked to all the large NSPs who are running RIPE-181 (i.e. MCI) about submitting MCI.db instead of NACRs for their NSFNET clients' updates. Merit then has the choice of either including MCI.db directly in the config generation process, or of writing a trivial script to generate NACRs from MCI.db . (We would be willing to do this kind of exchange with other DBs who support the advisory attribute, too). Also, at any time in this process, we can start accepting RIPE-181 route objects instead of NACRs. While the Informix PRDB is still running, we would just grab a copy of each of those and generate a net NACR from that information. This process could start any time (even today) except for one issue: we would need to require that each such route object be prepended with the NSFNET AUP text and certification. We have a petition in to the U.S. Inspector General to allow us to skip the AUP stuff, but it is very likely that we will not get that permission. We're not pushing the "send in a route template" approach until this gets cleared up, although it would be good for us to get a beta site or two to work with on trying this. So... the basic answer to your question is we will continue supporting the PRDB functions with a RIPE-181 database called "NSF-TRANS" until the other supporting systems are ready to replace this. Europeans will continue having their providers submit net NACRs to nsfnet-admin@ merit.edu like they have been since 1988 until RIPE feels comfortable that the advisory attribute is fully ready and populated in the RIPE.db. I think that is what you were asking? --Dale PS: Thanks for making me write this down. :-) (And my apologies to RIPE for not writing this discussion down for them first, but we have done most of this verbally and they are cc'd on the first messages about it...) Comments and reality checks from all parties more than welcome... --Dale > Dale, > > Thanks for your reply. I take all your points, but I'm still not sure what > Europeans then have to do, once the PRDB is retired, and the RIPE DB is not > ready yet to support the advisory attribute for all European nets. Because > then you cannot reasonably use the RIPE-DB, as the info there is not > complete, but the Europeans can't send in NACRs either, because the PRDB > doesn't exist any longer. > > My view is that the RIPE-DB *has* to be ready by the time the PRDB retires > to not mess things up for Europe. I do not see how we (in Europe) can > reasonably work with a unfinished RIPE-DB and no PRDB any more. Do you? > > Michael > > > > At 5:46 pm 21/12/94, Dale S. Johnson wrote: > >Michael, > > > > I had been thinking that this transition to using native RIPE data > >(with advisory attributes embedded) would be a second phase of AS690 > >configurations--probably near the end of February. It would be good > >to get an advance start on it, however. This change will actually be > >very little coding work for us (just take data from an additional > >source). It will have considerably more effect on RIPE and end-users. > >RIPE will need to support the advisory attribute, probably go through > >an initial mass-loading of it (coordinated with the users), and presumably > >deal with questions about it for the next six or so months. (Merit > >will of course also be offering support). Since this change will both > >be visible to users, and will require changes in their behavior (e.g. > >maintaining the advisory attribute in their route objects), it would > >be good to get started on this quite soon. > > > > If the advisory attribute was in the software and initial values > >were in place for all routes, and if we decided that users had had > >enough advanced notice and training, then we could probably make the > >step of converting to this data very quickly after the PRDB is retired > >in January. > > > >--Dale > > > > > >> From M.H.Behringer at dante.org.uk Wed Dec 21 07:57:32 1994 > >> Date: Wed, 21 Dec 1994 12:58:01 +0000 > >> To: epg at merit.edu > >> From: M.H.Behringer at dante.org.uk (Michael H. Behringer) > >> Subject: Re: Migration to RIPE 181 > >> Cc: dsj at merit.edu > >> > >> Hi Elise, > >> > >> Thanks for your response. I just want to quickly verify something. > >> > >> At 1:53 pm 20/12/94, epg at merit.edu wrote: > >> [...] > >> >Yes, we have an agreement with the RIPE NCC that they will support the > >> >advisory attribute. I believe that when the RIPE NCC implemented > >> >181, this was forseen. I have copied Dale Johnson who has been > >> >coordinating with Marten on this so he can correct me if I have > >> >gotten it wrong. > >> > >> I know this is foreseen in the RIPE DB, and I know this has to be done > >> (thats why I'm asking). Does this mean that by the 15th January the > >> advisory attribute has to be in all RIPE DB route entries, and all networks > >> that do not have this attribute by then will not be routed through NSFnet? > >> > >> Or will you still keep the current config for a while, to make sure none of > >> the nets looses US connectivity. If so, when is the deadline for dropping > >> this? > >> > >> >The goal is that no one will have to register twice. We propose to > >> >derive the AS690 configs from the RADB and the RIPE Routing Registry. > >> > >> Good. > >> > >> Thanks for your help, Elise, > >> > >> Michael -------- Logged at Thu Dec 22 18:44:18 MET 1994 --------- From M.H.Behringer at dante.org.uk Thu Dec 22 18:43:26 1994 From: M.H.Behringer at dante.org.uk (Michael H. Behringer) Date: Thu, 22 Dec 1994 17:43:26 +0000 Subject: Migration to RIPE 181 Message-ID: At 5:28 pm 22/12/94, Dale S. Johnson wrote: [...] > I think that is what you were asking? > Yes, indeed :-) Thanks for this very detailed explanation. This is reassuring. I still think we here in Europe should really get this done asap, but it is nice to know that we won't be diconnected if we don't get there in time. ;-) Again, thanks for your help, Michael -------- Logged at Thu Dec 22 18:47:30 MET 1994 --------- From dsj at merit.edu Thu Dec 22 18:47:24 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Thu, 22 Dec 1994 12:47:24 -0500 Subject: Migration to RIPE 181 Message-ID: <199412221747.MAA11772@home.merit.edu> Marten, > Perhaps MERIT should inform a wider audience about what is > expected from them when the NACRs are retired .... ...and perhaps Dale should read all his mail before replying to one message. (sigh) Yes, Marten; thanks. You're right. Please see previous message. Busy month... --Dale > > M.H.Behringer at dante.org.uk (Michael H. Behringer) writes > * Dale, > * > * Thanks for your reply. I take all your points, but I'm still not sure what > * Europeans then have to do, once the PRDB is retired, and the RIPE DB is not > * ready yet to support the advisory attribute for all European nets. Because > * then you cannot reasonably use the RIPE-DB, as the info there is not > * complete, but the Europeans can't send in NACRs either, because the PRDB > * doesn't exist any longer. > * > * My view is that the RIPE-DB *has* to be ready by the time the PRDB retires > * to not mess things up for Europe. I do not see how we (in Europe) can > * reasonably work with a unfinished RIPE-DB and no PRDB any more. Do you? > > Just to make sure that the RIPE DB as such supports the advisory > attribute, however there are no routes currently that contain this > attribute. Perhaps MERIT should inform a wider audience about what is > expected from them when the NACRs are retired .... > > -Marten > -------- Logged at Thu Dec 22 21:54:51 MET 1994 --------- From dsj at merit.edu Thu Dec 22 21:54:47 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Thu, 22 Dec 1994 15:54:47 -0500 Subject: MCI RR data available daily from ftp.mci.net Message-ID: <199412222054.PAA18782@home.merit.edu> Ok; The Routing Arbiter's pre-production database server is now serving up the following databases: RADB (formerly "MERITRR") RIPE CANET MCI PRDB.db The whois server can be found on _radb.ra.net (note the underscore). Just after new year we will make this the official radb.ra.net . --Dale > From tony at mci.net Thu Dec 22 11:59:20 1994 > To: rr-impl at ripe.net > Subject: MCI RR data available daily from ftp.mci.net > Cc: enke at mci.net, jstewart at mci.net, roy at mci.net, waters at mci.net > From: Tony Bates > > > Please note: > > the mci RR is now available rom ftp.mci.net as follows > > ftp://ftp.mci.net/pub/rr/mci.db.gz > > This job runs as part of the clean process. It should be available > after 4am EST each day. > > It is also available in slpit forms as well. > > The uncompressed version is currently about 1.3 Meg. > > Dale, > I'll talk to you off-line about started the NACR going away > process. > > --Tony. > -------- Logged at Thu Dec 22 21:56:23 MET 1994 --------- From Tony.Bates at mci.net Thu Dec 22 21:55:42 1994 From: Tony.Bates at mci.net (Tony Bates) Date: Thu, 22 Dec 1994 15:55:42 -0500 Subject: MCI RR data available daily from ftp.mci.net In-Reply-To: Your message of Thu, 22 Dec 1994 15:54:47 EST. <199412222054.PAA18782@home.merit.edu> Message-ID: <199412222055.PAA03653@lovefm.reston.mci.net> Dale, how soon before we can drop nacrs ? ==Tony. "Dale S. Johnson" writes: * Ok; The Routing Arbiter's pre-production database server is now serving * up the following databases: * * RADB (formerly "MERITRR") * RIPE * CANET * MCI * PRDB.db * * The whois server can be found on _radb.ra.net (note the underscore). * Just after new year we will make this the official radb.ra.net . * * --Dale * * * > From tony at mci.net Thu Dec 22 11:59:20 1994 * > To: rr-impl at ripe.net * > Subject: MCI RR data available daily from ftp.mci.net * > Cc: enke at mci.net, jstewart at mci.net, roy at mci.net, waters at mci.net * > From: Tony Bates * > * > * > Please note: * > * > the mci RR is now available rom ftp.mci.net as follows * > * > ftp://ftp.mci.net/pub/rr/mci.db.gz * > * > This job runs as part of the clean process. It should be available * > after 4am EST each day. * > * > It is also available in slpit forms as well. * > * > The uncompressed version is currently about 1.3 Meg. * > * > Dale, * > I'll talk to you off-line about started the NACR going away * > process. * > * > --Tony. * > -------- Logged at Thu Dec 22 22:53:18 MET 1994 --------- From dsj at merit.edu Thu Dec 22 22:53:14 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Thu, 22 Dec 1994 16:53:14 -0500 Subject: MCI RR data available daily from ftp.mci.net Message-ID: <199412222153.QAA00944@home.merit.edu> Tony, Looks like our messages crossed in the mail. Here's for the CC'd folks: > Tony, > > Thanks for announcing the mci.db ! > > I'm officially on vacation tomorrow until Jan 3, though I'll be > checking in. > > > I'll talk to you off-line about started the NACR going away process. > > What we absolutely need, of course, is the advisory line with the > as:metric lists. (Until, I suppose, some future time when all of > MCI's customers policies can be represented to AS690 using strict > RIPE-181. But not this month, please). > > What would also help (or make possible) a sensible solution would be > for you to include some text at the top of mci.db (and the split > route file) giving the NSF AUP certification: "We hereby swear that > any route below that is marked with community COMM_NSFNET abides > by..." > > Beyond that, all of the variations I can think of take all the work > off you and put it on us. You allow us to pick up mci.db. Probably > you supply us with an algorithm based on the change date: e.g. > "please look at all the entries with changed dates since the last > config run, and replace your PRDB entries with the information shown > from that route object". The rest is our problem. We have all ready > taken steps so that you do not have to supply net country codes or > org addresses, which were real hang-ups before. > > Sound good? If you can get the above things done, we could try this out the first week of January. --Dale ========================================================================= > From tony at mci.net Thu Dec 22 15:56:28 1994 > id AA10720 (5.65a/NCC-2.16); Thu, 22 Dec 1994 21:56:22 +0100 > To: "Dale S. Johnson" > Cc: rr-impl at ripe.net, enke at mci.net, jstewart at mci.net, roy at mci.net, > waters at mci.net > Subject: Re: MCI RR data available daily from ftp.mci.net > In-Reply-To: Your message of Thu, 22 Dec 1994 15:54:47 EST. > <199412222054.PAA18782 at home.merit.edu> > From: Tony Bates > Date: Thu, 22 Dec 1994 15:55:42 -0500 > Sender: tony at mci.net > > Dale, > how soon before we can drop nacrs ? > > ==Tony. > > "Dale S. Johnson" writes: > * Ok; The Routing Arbiter's pre-production database server is now serving > * up the following databases: > * > * RADB (formerly "MERITRR") > * RIPE > * CANET > * MCI > * PRDB.db > * > * The whois server can be found on _radb.ra.net (note the underscore). > * Just after new year we will make this the official radb.ra.net . > * > * --Dale > * > * > * > From tony at mci.net Thu Dec 22 11:59:20 1994 > * > To: rr-impl at ripe.net > * > Subject: MCI RR data available daily from ftp.mci.net > * > Cc: enke at mci.net, jstewart at mci.net, roy at mci.net, waters at mci.net > * > From: Tony Bates > * > > * > > * > Please note: > * > > * > the mci RR is now available rom ftp.mci.net as follows > * > > * > ftp://ftp.mci.net/pub/rr/mci.db.gz > * > > * > This job runs as part of the clean process. It should be available > * > after 4am EST each day. > * > > * > It is also available in slpit forms as well. > * > > * > The uncompressed version is currently about 1.3 Meg. > * > > * > Dale, > * > I'll talk to you off-line about started the NACR going away > * > process. > * > > * > --Tony. > * > > -------- Logged at Fri Dec 23 17:40:40 MET 1994 --------- From ca at cs.UMD.EDU Fri Dec 23 17:40:14 1994 From: ca at cs.UMD.EDU (Cengiz Alaettinoglu) Date: Fri, 23 Dec 1994 11:40:14 -0500 Subject: Migration to RIPE 181 In-Reply-To: References: Message-ID: <199412231640.LAA06856@han.cs.UMD.EDU> In the IRR meeting, we have agreed that one object (route object in this case) can belong to multiple databases and the local database server decides on which copy to prefer. Hence, till ripe-db is ready, we can register European routes in RADB with the advisory attribute. The drawback of this approach is that after the ripe-db is ready there is some cleanup work to be done. Michael H. Behringer (M.H.Behringer at dante.org.uk) on December 22: > Dale, > > Thanks for your reply. I take all your points, but I'm still not sure what > Europeans then have to do, once the PRDB is retired, and the RIPE DB is not > ready yet to support the advisory attribute for all European nets. Because > then you cannot reasonably use the RIPE-DB, as the info there is not > complete, but the Europeans can't send in NACRs either, because the PRDB > doesn't exist any longer. > > My view is that the RIPE-DB *has* to be ready by the time the PRDB retires > to not mess things up for Europe. I do not see how we (in Europe) can > reasonably work with a unfinished RIPE-DB and no PRDB any more. Do you? > > Michael > > > > At 5:46 pm 21/12/94, Dale S. Johnson wrote: > >Michael, > > > > I had been thinking that this transition to using native RIPE data > >(with advisory attributes embedded) would be a second phase of AS690 > >configurations--probably near the end of February. It would be good > >to get an advance start on it, however. This change will actually be > >very little coding work for us (just take data from an additional > >source). It will have considerably more effect on RIPE and end-users. > >RIPE will need to support the advisory attribute, probably go through > >an initial mass-loading of it (coordinated with the users), and presumably > >deal with questions about it for the next six or so months. (Merit > >will of course also be offering support). Since this change will both > >be visible to users, and will require changes in their behavior (e.g. > >maintaining the advisory attribute in their route objects), it would > >be good to get started on this quite soon. > > > > If the advisory attribute was in the software and initial values > >were in place for all routes, and if we decided that users had had > >enough advanced notice and training, then we could probably make the > >step of converting to this data very quickly after the PRDB is retired > >in January. > > > >--Dale > > > > > >> From M.H.Behringer at dante.org.uk Wed Dec 21 07:57:32 1994 > >> Date: Wed, 21 Dec 1994 12:58:01 +0000 > >> To: epg at merit.edu > >> From: M.H.Behringer at dante.org.uk (Michael H. Behringer) > >> Subject: Re: Migration to RIPE 181 > >> Cc: dsj at merit.edu > >> > >> Hi Elise, > >> > >> Thanks for your response. I just want to quickly verify something. > >> > >> At 1:53 pm 20/12/94, epg at merit.edu wrote: > >> [...] > >> >Yes, we have an agreement with the RIPE NCC that they will support the > >> >advisory attribute. I believe that when the RIPE NCC implemented > >> >181, this was forseen. I have copied Dale Johnson who has been > >> >coordinating with Marten on this so he can correct me if I have > >> >gotten it wrong. > >> > >> I know this is foreseen in the RIPE DB, and I know this has to be done > >> (thats why I'm asking). Does this mean that by the 15th January the > >> advisory attribute has to be in all RIPE DB route entries, and all networks > >> that do not have this attribute by then will not be routed through NSFnet? > >> > >> Or will you still keep the current config for a while, to make sure none of > >> the nets looses US connectivity. If so, when is the deadline for dropping > >> this? > >> > >> >The goal is that no one will have to register twice. We propose to > >> >derive the AS690 configs from the RADB and the RIPE Routing Registry. > >> > >> Good. > >> > >> Thanks for your help, Elise, > >> > >> Michael > >> > >> > >> > Cengiz -------- Logged at Fri Dec 23 21:16:21 MET 1994 --------- From Marten.Terpstra at ripe.net Fri Dec 23 21:16:15 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Fri, 23 Dec 1994 21:16:15 +0100 Subject: Migration to RIPE 181 In-Reply-To: Your message of Fri, 23 Dec 1994 11:40:14 EST. <199412231640.LAA06856@han.cs.UMD.EDU> Message-ID: <9412232016.AA19588@ncc.ripe.net> ca at cs.UMD.EDU (Cengiz Alaettinoglu) writes * * In the IRR meeting, we have agreed that one object (route object in * this case) can belong to multiple databases and the local database * server decides on which copy to prefer. * * Hence, till ripe-db is ready, we can register European routes in RADB * with the advisory attribute. Sorry but the phrase "till ripe-db is ready" is *very* confusing. The RIPE database is ready. Anyone can register routes with an advisory attribute. It'd be simple to write a few line script that would take the paths from the mumblemumbleDB (sorry I get confused about RRDB, RADB, PRDB, MERITRR ...) and submit them to the RIPE database. * The drawback of this approach is that after the ripe-db is ready there * is some cleanup work to be done. So why not just register these routes with advisory in the RIPE DB? -Marten Ps Merry Xmas all! -------- Logged at Fri Dec 23 21:22:26 MET 1994 --------- From Tony.Bates at mci.net Fri Dec 23 21:22:07 1994 From: Tony.Bates at mci.net (Tony Bates) Date: Fri, 23 Dec 1994 15:22:07 -0500 Subject: Migration to RIPE 181 In-Reply-To: Your message of Fri, 23 Dec 1994 21:16:15 +0100. <9412232016.AA19588@ncc.ripe.net> Message-ID: <199412232022.PAA05075@lovefm.reston.mci.net> Actually, this is not quite right. It is the bootstrap issue. For it to be an immediate replacement the current entries need to get the advisory tag in them for exisiting routes. We are going to automatically add an advisory line to all routes here based on the PRDB to get it bootstrapped. Enke will be working on this at MCI. There is no reason why we cant give the script out. It is actually already there in the PRDB dump anyway. --Tony. Marten Terpstra writes: * * ca at cs.UMD.EDU (Cengiz Alaettinoglu) writes * * * * In the IRR meeting, we have agreed that one object (route object in * * this case) can belong to multiple databases and the local database * * server decides on which copy to prefer. * * * * Hence, till ripe-db is ready, we can register European routes in RADB * * with the advisory attribute. * * Sorry but the phrase "till ripe-db is ready" is *very* confusing. The * RIPE database is ready. Anyone can register routes with an advisory * attribute. It'd be simple to write a few line script that would take * the paths from the mumblemumbleDB (sorry I get confused about RRDB, * RADB, PRDB, MERITRR ...) and submit them to the RIPE database. * * * The drawback of this approach is that after the ripe-db is ready there * * is some cleanup work to be done. * * So why not just register these routes with advisory in the RIPE DB? * * -Marten * * Ps Merry Xmas all! -------- Logged at Fri Dec 23 21:27:00 MET 1994 --------- From Marten.Terpstra at ripe.net Fri Dec 23 21:26:55 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Fri, 23 Dec 1994 21:26:55 +0100 Subject: Migration to RIPE 181 In-Reply-To: Your message of Fri, 23 Dec 1994 15:22:07 EST. <199412232022.PAA05075@lovefm.reston.mci.net> Message-ID: <9412232026.AA19654@ncc.ripe.net> Actually, this is exactly what I meant. I just get sort of confused about "not ready". Also to be really honest I'd rather that European nets end up in the RIPE RR and kept up to date there. Otherwise someone is going to have a huge job when we will try and really distribute the databases .... I have this feeling it won't be me though ... -Marten Tony Bates writes * Actually, * this is not quite right. It is the bootstrap issue. For it to * be an immediate replacement the current entries need to get the advisory tag * in * them for exisiting routes. We are going to automatically add an advisory * line to all routes here based on the PRDB to get it bootstrapped. Enke * will be working on this at MCI. There is no reason why we cant give * the script out. It is actually already there in the PRDB dump anyway. * * --Tony. * * Marten Terpstra writes: * * * * ca at cs.UMD.EDU (Cengiz Alaettinoglu) writes * * * * * * In the IRR meeting, we have agreed that one object (route object in * * * this case) can belong to multiple databases and the local database * * * server decides on which copy to prefer. * * * * * * Hence, till ripe-db is ready, we can register European routes in RADB * * * with the advisory attribute. * * * * Sorry but the phrase "till ripe-db is ready" is *very* confusing. The * * RIPE database is ready. Anyone can register routes with an advisory * * attribute. It'd be simple to write a few line script that would take * * the paths from the mumblemumbleDB (sorry I get confused about RRDB, * * RADB, PRDB, MERITRR ...) and submit them to the RIPE database. * * * * * The drawback of this approach is that after the ripe-db is ready ther * e * * * is some cleanup work to be done. * * * * So why not just register these routes with advisory in the RIPE DB? * * * * -Marten * * * * Ps Merry Xmas all! -------- Logged at Fri Dec 23 21:43:13 MET 1994 --------- From cengiz at ISI.EDU Fri Dec 23 21:42:11 1994 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Fri, 23 Dec 1994 12:42:11 -0800 Subject: Migration to RIPE 181 In-Reply-To: <9412232016.AA19588@ncc.ripe.net> References: <199412231640.LAA06856@han.cs.UMD.EDU> <9412232016.AA19588@ncc.ripe.net> Message-ID: <199412232042.AA03168@cat.isi.edu> Marten Terpstra (Marten.Terpstra at ripe.net) on December 23: > (sorry I get confused about RRDB, RADB, PRDB, MERITRR ...) FYI: RADB is the right answer. Both RRDB and MERITRR no longer exist. PRDB still exists, but it is the NSFNet's database. I hope that this will clarify any confusion. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute Voice: (310) 822-1511 University of Southern California -------- Logged at Fri Dec 23 21:45:16 MET 1994 --------- From Marten.Terpstra at ripe.net Fri Dec 23 21:45:13 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Fri, 23 Dec 1994 21:45:13 +0100 Subject: Migration to RIPE 181 In-Reply-To: Your message of Fri, 23 Dec 1994 12:42:11 PST. <199412232042.AA03168@cat.isi.edu> Message-ID: <9412232045.AA19738@ncc.ripe.net> * FYI: RADB is the right answer. Both RRDB and MERITRR no longer * exist. PRDB still exists, but it is the NSFNet's database. * * I hope that this will clarify any confusion. I think I can remember that ;-) -MT -------- Logged at Fri Dec 23 22:37:37 MET 1994 --------- From epg at merit.edu Fri Dec 23 22:37:26 1994 From: epg at merit.edu (Elise Gerich) Date: Fri, 23 Dec 1994 16:37:26 -0500 (EST) Subject: Migration to RIPE 181 In-Reply-To: <199412221747.MAA11772@home.merit.edu> from "Dale S. Johnson" at Dec 22, 94 12:47:24 pm Message-ID: <199412232137.QAA10567@home.merit.edu> Marten, Just to understand what you are saying, is the RIPE NCC unaware of the plans or is the broader community that you hope we will inform? Thanks, --Elise >Dale S. Johnson writes: > > Marten, > > > Perhaps MERIT should inform a wider audience about what is > > expected from them when the NACRs are retired .... > > ...and perhaps Dale should read all his mail before replying to one > message. (sigh) Yes, Marten; thanks. You're right. Please see > previous message. Busy month... > > --Dale > > > > > > M.H.Behringer at dante.org.uk (Michael H. Behringer) writes > > * Dale, > > * > > * Thanks for your reply. I take all your points, but I'm still not sure what > > * Europeans then have to do, once the PRDB is retired, and the RIPE DB is not > > * ready yet to support the advisory attribute for all European nets. Because > > * then you cannot reasonably use the RIPE-DB, as the info there is not > > * complete, but the Europeans can't send in NACRs either, because the PRDB > > * doesn't exist any longer. > > * > > * My view is that the RIPE-DB *has* to be ready by the time the PRDB retires > > * to not mess things up for Europe. I do not see how we (in Europe) can > > * reasonably work with a unfinished RIPE-DB and no PRDB any more. Do you? > > > > Just to make sure that the RIPE DB as such supports the advisory > > attribute, however there are no routes currently that contain this > > attribute. Perhaps MERIT should inform a wider audience about what is > > expected from them when the NACRs are retired .... > > > > -Marten > > > -------- Logged at Fri Dec 23 22:44:11 MET 1994 --------- From Marten.Terpstra at ripe.net Fri Dec 23 22:44:09 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Fri, 23 Dec 1994 22:44:09 +0100 Subject: Migration to RIPE 181 In-Reply-To: Your message of Fri, 23 Dec 1994 16:37:26 EST. <199412232137.QAA10567@home.merit.edu> Message-ID: <9412232144.AA19992@ncc.ripe.net> Elise Gerich writes * Marten, * Just to understand what you are saying, is the RIPE NCC unaware of the * plans or is the broader community that you hope we will inform? * * Thanks, * --Elise Elise, I am now sort of sure what will happen in January, but I am sure there is loads of SPs that are unsure of what exactly they have to do when NACRs are (or can be) retired .... -Marten PS It all became clear to me only after Dale's long messages. * * >Dale S. Johnson writes: * > * > Marten, * > * > > Perhaps MERIT should inform a wider audience about what is * > > expected from them when the NACRs are retired .... * > * > ...and perhaps Dale should read all his mail before replying to one * > message. (sigh) Yes, Marten; thanks. You're right. Please see * > previous message. Busy month... * > * > --Dale * > * > * > > * > > M.H.Behringer at dante.org.uk (Michael H. Behringer) writes * > > * Dale, * > > * * > > * Thanks for your reply. I take all your points, but I'm still not sure * what * > > * Europeans then have to do, once the PRDB is retired, and the RIPE DB * is not * > > * ready yet to support the advisory attribute for all European nets. Be * cause * > > * then you cannot reasonably use the RIPE-DB, as the info there is not * > > * complete, but the Europeans can't send in NACRs either, because the P * RDB * > > * doesn't exist any longer. * > > * * > > * My view is that the RIPE-DB *has* to be ready by the time the PRDB re * tires * > > * to not mess things up for Europe. I do not see how we (in Europe) can * > > * reasonably work with a unfinished RIPE-DB and no PRDB any more. Do yo * u? * > > * > > Just to make sure that the RIPE DB as such supports the advisory * > > attribute, however there are no routes currently that contain this * > > attribute. Perhaps MERIT should inform a wider audience about what is * > > expected from them when the NACRs are retired .... * > > * > > -Marten * > > * > * -------- Logged at Wed Dec 28 15:00:31 MET 1994 --------- From Daniel.Karrenberg at ripe.net Wed Dec 28 15:00:27 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 28 Dec 1994 15:00:27 +0100 Subject: Migration to RIPE 181 In-Reply-To: Your message of Fri, 23 Dec 1994 15:22:07 EST. <199412232022.PAA05075@lovefm.reston.mci.net> Message-ID: <9412281400.AA14827@ncc.ripe.net> > Tony Bates writes: > We are going to automatically add an advisory > line to all routes here based on the PRDB to get it bootstrapped. This is right for you. I would be in favour of doing the same in the RIPE RR were it not that we would have to touch other people's data which we consider a big nono. There are two possibilities: - we do it anyway - we generate suggested data which the maintainers concerned can then send in or modify as required. Either should not be a big deal. Comments? Daniel -------- Logged at Wed Dec 28 15:03:42 MET 1994 --------- From Daniel.Karrenberg at ripe.net Wed Dec 28 15:03:29 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 28 Dec 1994 15:03:29 +0100 Subject: Migration to RIPE 181 In-Reply-To: Your message of Fri, 23 Dec 1994 11:40:14 EST. <199412231640.LAA06856@han.cs.UMD.EDU> Message-ID: <9412281403.AA14876@ncc.ripe.net> > ca at cs.UMD.EDU (Cengiz Alaettinoglu) writes: > > In the IRR meeting, we have agreed that one object (route object in > this case) can belong to multiple databases and the local database > server decides on which copy to prefer. > > Hence, till ripe-db is ready, we can register European routes in RADB > with the advisory attribute. Why would you want to do that? Advisory attributes can be registered in the RIPE DB now (actually since they were defined). Routes originated by European ASes should be registered in the RIPE RR. Daniel -------- Logged at Wed Dec 28 15:09:31 MET 1994 --------- From farrache at cc.in2p3.fr Wed Dec 28 15:09:20 1994 From: farrache at cc.in2p3.fr (Gilles Farrache) Date: Wed, 28 Dec 94 15:09:20 MET Subject: Migration to RIPE 181 Message-ID: <9412281409.AA00562@ccpnxt5.in2p3.fr.> Daniel >There are two possibilities: > > - we do it anyway > > - we generate suggested data which the maintainers concerned > can then send in or modify as required. > >Either should not be a big deal. > >Comments? I do prefer the first one.. Gilles -------- Logged at Wed Dec 28 15:21:15 MET 1994 --------- From Tony.Bates at mci.net Wed Dec 28 15:21:04 1994 From: Tony.Bates at mci.net (Tony Bates) Date: Wed, 28 Dec 1994 09:21:04 -0500 Subject: Migration to RIPE 181 In-Reply-To: Your message of Wed, 28 Dec 1994 15:00:27 +0100. <9412281400.AA14827@ncc.ripe.net> Message-ID: <199412281421.JAA00485@lovefm.reston.mci.net> I already have the same dilemma as we already have 6895 routes registered. Almost as many as you (8229). However, we have the advantage of a big stick (connectivity). I think the softly, softly approach wont work if you want Merit to use the RIPE DB for NACRs. --Tony. Daniel Karrenberg writes: * * > Tony Bates writes: * > We are going to automatically add an advisory * > line to all routes here based on the PRDB to get it bootstrapped. * * This is right for you. * I would be in favour of doing the same in the RIPE RR were it not * that we would have to touch other people's data which we consider * a big nono. * * There are two possibilities: * * - we do it anyway * * - we generate suggested data which the maintainers concerned * can then send in or modify as required. * * Either should not be a big deal. * * Comments? * * Daniel -------- Logged at Wed Dec 28 15:32:46 MET 1994 --------- From M.H.Behringer at dante.org.uk Wed Dec 28 15:33:56 1994 From: M.H.Behringer at dante.org.uk (Michael H. Behringer) Date: Wed, 28 Dec 1994 14:33:56 +0000 Subject: Migration to RIPE 181 Message-ID: Daniel, I suggest you put out a plan on the RIPE list (or RIPE-op?) for automatically switching the advisory attribute, and ask if somebody would object if you did the change automatically for the whole DB. Honestly, I cannot imagine someone objecting to that. You should set a deadline for objections, say the 13th January (Fri), and if there are no major concerns, it could be done fairly soon afterwards, say the 16th (monday). (dates are suggestions only) This way we could make sure that the RIPE DB contains all needed information when the PRDB is retired (note: I don't say the RIPE-DB is "ready" ;-) . I very strongly feel we should have the RIPE DB up-to-date when the PRDB is retired. And I don't think this should be a problem. Michael At 2:00 pm 28/12/94, Daniel Karrenberg wrote: > > Tony Bates writes: > > We are going to automatically add an advisory > > line to all routes here based on the PRDB to get it bootstrapped. > >This is right for you. >I would be in favour of doing the same in the RIPE RR were it not >that we would have to touch other people's data which we consider >a big nono. > >There are two possibilities: > > - we do it anyway > > - we generate suggested data which the maintainers concerned > can then send in or modify as required. > >Either should not be a big deal. > >Comments? > >Daniel -------- Logged at Wed Dec 28 18:26:54 MET 1994 --------- From cengiz at ISI.EDU Wed Dec 28 18:26:34 1994 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Wed, 28 Dec 1994 09:26:34 -0800 Subject: Migration to RIPE 181 In-Reply-To: <9412281403.AA14876@ncc.ripe.net> References: <199412231640.LAA06856@han.cs.UMD.EDU> <9412281403.AA14876@ncc.ripe.net> Message-ID: <199412281726.AA10024@cat.isi.edu> Daniel Karrenberg (Daniel.Karrenberg at ripe.net) on December 28: > > > ca at cs.UMD.EDU (Cengiz Alaettinoglu) writes: > > > > In the IRR meeting, we have agreed that one object (route object in > > this case) can belong to multiple databases and the local database > > server decides on which copy to prefer. > > > > Hence, till ripe-db is ready, we can register European routes in RADB > > with the advisory attribute. > > Why would you want to do that? I wrote this before I read Dale's and Marten's replies (about the discussion on NSF-TRANS and RIPE's readiness). Please ignore my above comment. > > Advisory attributes can be registered in the RIPE DB now (actually > since they were defined). > > Routes originated by European ASes should be registered in the RIPE RR. I completely agree with this. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute Voice: (310) 822-1511 University of Southern California -------- Logged at Thu Dec 29 16:07:23 MET 1994 --------- From Marten.Terpstra at ripe.net Thu Dec 29 16:07:20 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Thu, 29 Dec 1994 16:07:20 +0100 Subject: RIPE DB bug in notification [maintainer.pl] Message-ID: <9412291507.AA21738@ncc.ripe.net> Folks, we found a bug in the notification code which caused notification of maintainers to fail completely if the corresponding maintainer had multiple mnt-nfy lines. The version of maintainer.pl below fixes this problem. Please drop this in src/maintainer.pl go to the main db directory and run "make". "make install" is not needed. -Marten # $RCSfile: maintainer.pl,v $ # $Revision: 1.6 $ # $Author: marten $ # $Date: 1994/12/29 15:04:08 $ # maintainer.pl - implements all functions associated with the maintainer # attribute, as defined in ripe-?? # There is a few global variables it will use for authorisation: # # $FROM - contains From: field from mail header # $PASSWD - contains password found in message # Also, the last maintainer object is kept globally for simplicity. # Otherwise we keep looking the stupid thing up again and again and again..... # maintainer - this is the main routine. It will receive two objects, # the new and old object, and starts processing from there. # # Here's the scoop: # # OldObject is empty: addition # NewObject is empty: delete # None empty: normal update require "notify.pl"; require "entype.pl"; sub Maintainer { local(*OldObject, *NewObject, $delete) = @_; local($status) = 0; local($returnstatus) = 0; # No maintainers mentioned, just return OK. return 1 if !$NewObject{"mb"} && !$OldObject{"mb"}; # Case 1: OldObject is empty, ie this is a new object. # - just return if NewObject contains no maintainers # - use maintainers in NewObject to verify if it has maintainers if (!&entype(*OldObject) || !$OldObject{"mb"}) { return if !$NewObject{"mb"}; $MatchingMaintainer = ""; foreach (split(/\s+/, $NewObject{"mb"})) { $status = &VrfyMaint($_, *NewObject); $MatchingMaintainer = $_ if $status; last if $status; } if (!$status) { # All maintainers will receive a copy of the object with # a message (specified in config) that someone tried to # update one of their objects, but failed authorisation. &ForwardToMaint(*OldObject, *NewObject); return 0; } # Notification that an object has been added/changed/deleted. # For all maintainers, send them a notification if they have # a mnt-nfy attribute specified in their object. Otherwise # no notification is done to the maintainers. Routine itself # is clever enough to figure out is this is a delete/add/update. &NotifyMaintainers(*OldObject, *NewObject); return 1; } # Case 2: Normal case, NewObject replaces OldObject or is a delete if ($OldObject{"mb"}) { $MatchingMaintainer = ""; foreach (split(/\s+/, $OldObject{"mb"})) { $status = &VrfyMaint($_, *OldObject); $MatchingMaintainer = $_ if $status; last if $status; } if (!$status) { # Auth failed. Bounce to originator and forward to maintainer # Same as above. &ForwardToMaint(*OldObject, *NewObject); return 0; } # Notify maintainers if requested (as above) only if not uknown # maintainer is added. &NotifyMaintainers(*OldObject, *NewObject); return 1; } } sub GetMaintainer { local($maintainername, $source) = @_; local(*i) = 'curdb'; local(%nothing) = (); local($normalized) = $maintainername; local($dbfile); $normalized =~ tr/A-Z/a-z/; local(@keys) = ($normalized); return 1 if ($CurMaintainer{"mt"} eq $maintainername); if ($TYPE{$source} eq "SPLIT") { $dbfile = "$DBFILE{$source}.mt"; } else { $dbfile = $DBFILE{$source}; } if (&dbopen(i, *nothing, 0, $dbfile)) { local(@matches) = &dbmatch(*i, *keys, 1); if ($#matches > 0) { &syslog("ERRLOG","GetMaintainer - found more than one match for ". "maintainer: $maintainername\n"); # Set error, should not happen!!!!! &dbclose(*i); return 0; } if (!$matches[0]) { &syslog( "ERRLOG", "GetMaintainer() no match found for maintainer $maintainer" ); &dbclose(*i); return 0; } %CurMaintainer = &enread(i, $matches[0]); $ExistMaintainer{$CurMaintainer{"mt"}} = 1; &dbclose(*i); return 1; } else { &syslog("ERRLOG", "GetMaintainer - failed to open $DBFILE{$source}.mt\n" ); return 0; } } sub VrfyMaint { local($maintainer, *object) = @_; local($status); local($source) = $object{"so"}; if (&GetMaintainer($maintainer, $source)) { foreach (split(/\n/, $CurMaintainer{"at"})) { $status = 0; if ($_ eq "NONE") { return 1; } if ($_ =~ /^MAIL-FROM/) { $status = &CheckMailFrom($_); return 1 if $status; next; } if ($_ =~ /^CRYPT-PW/) { $status = &CheckPassword($_); return 1 if $status; next; } } return $status; } else { return 0; } } sub CheckMailFrom { local($line) = @_; $line =~ m/MAIL-FROM\s+(.*)/; local($regex) = $1; return 1 if $FROM =~ /$regex/; &syslog("AUDITLOG", "Auth email failure \"$FROM\" !~ \"$regex\""); return 0; } sub CheckPassword { local($line) = @_; $line = m/CRYPT-PW\s+(\S+)/; local($cpwd) = $1; return 1 if crypt($PASSWORD, $cpwd) eq $cpwd; &syslog("AUDITLOG", "Auth passwd failure \"$PASSWORD\" !~ \"$cpwd\""); return 0; } # This routine will handle the mnt-nfy function in the maintainer object # It will extract the email addresses from mnt-nfy attribute, and from # there on, treat them as normal notifiers. sub NotifyMaintainers { local(*Oldobject, *NewObject) = @_; local(@notif) = (); local($line); local($del) = 1 if !&entype(*NewObject); local($m) = 0; local($source); if ($OldObject{"mb"}) { foreach $line (split(/\n/, $OldObject{"mb"})) { @notif = (@notif, split(/\s+/, $line)); $source = $OldObject{"so"}; } } else { foreach $line (split(/\n/, $NewObject{"mb"})) { @notif = (@notif, split(/\s+/, $line)); $source = $NewObject{"so"}; } } foreach $m (0..$#notif) { &GetMaintainer($notif[$m], $source); if ($CurMaintainer{"mn"}) { local(@mns); foreach (split(/\n/, $CurMaintainer{"mn"})) { @mns = (@mns, $_); } splice(@notif, $m, 1, @mns); } else { splice(@notif, $m, 1); $m--; } } &DoAddNotify(*notif, *OldObject, *NewObject, $del); } # This routine will forward objects to a all maintainers if authorisation # failed. The message configured in config should make clear to the # maintainer that the update actually failed, and they should take action # as the proper maintainers. # Notification of succeeded updates for maintainers is done through # the normal notify mechanism only if maintainer object contains a # mnt-nfy attribute. sub ForwardToMaint { local(*OldObject, *NewObject) = @_; local($line); local(@maintainers) = (); local($oldtype) = &entype(*OldObject); local($newtype) = &entype(*NewObject); local($source); local($email); if ($OldObject{"mb"}) { foreach $line (split(/\n/, $OldObject{"mb"})) { @maintainers = (@maintainers, split(/\s+/, $line)); $source = $OldObject{"so"}; } } else { foreach $line (split(/\n/, $NewObject{"mb"})) { @maintainers = (@maintainers, split(/\s+/, $line)); $source = $NewObject{"so"}; } } foreach (@maintainers) { # The idea was to not send a notificatio to the matching # maintainer. Let's forget about that one for now. # next if $_ eq $MatchingMaintainer; if (!&GetMaintainer($_, $source)) { &syslog("ERRLOG", "Failed to get maintainer $_ in fwd msg generation"); return; } foreach $email (split(/\n/, $CurMaintainer{"dt"})) { if (!$forward{$email}) { $forward{$email} = &ForwardTmpFile($email); open(FORWARD, ">$forward{$email}") || &syslog("ERRLOG", "Cannot create maintainer fwd file $forward{$email}"); &WriteForwardHeader(FORWARD, $email); } else { open(FORWARD, ">>$forward{$email}") || &syslog("ERRLOG", "Cannot open maintainer fwd file $forward{$email}"); } select(FORWARD); if (!$newtype) { # Deletion print "---\n"; print "DELETION REQUESTED FOR:\n\n"; print "\n" if &enwrite(*OldObject,1,0,1); } elsif (!$oldtype) { # Addition print "---\n"; print "ADDITION REQUESTED FOR:\n\n"; print "\n" if &enwrite(*NewObject,1,0,1); } else { # Update print "---\n"; print "UPDATE REQUESTED FOR:\n\n"; print "\n" if &enwrite(*NewObject,1,0,1); } close(FORWARD); } } select(STDOUT); } sub ForwardTmpFile { local($email) = @_; return "$TMPDIR/$email.$$"; } sub WriteForwardHeader { local($filehandle, $email) = @_; select($filehandle); print $FWHEADER; $email = $DEFMAIL if $TESTMODE; print "To: $email\n"; print "\n"; eval "print \"$FWTEXT\n\";"; select(STDOUT); } sub SendForwardMails { local($a); foreach $a (keys %forward) { system("$MAILCMD < $forward{$a}"); unlink($forward{$a}); } } 1; -------- Logged at Thu Dec 29 22:37:50 MET 1994 --------- From dsj at merit.edu Thu Dec 29 22:37:54 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Thu, 29 Dec 1994 16:37:54 -0500 Subject: Migration to RIPE 181 Message-ID: <199412292137.QAA16067@home.merit.edu> All, I basically like Michael's plan. My own preferance would be to announce that the RIPE DB would be updated from the PRDB *twice*, though I realize that this might seem like gratuitous touching of the users' data. Here is the reasoning: For every user, there is some correct place to update their data at any point in time. At the moment, Europeans have two places they need to update route information: the RIPE.db and the PRDB. Theoretically, every time they change anything about the route, they need to update it both places if they have NSFNET connectivity. (This is has been the situation since the RIPE.db started operation). As of some flag day, these users must update their data in only one place: the RIPE.db. Flag days are terrible things operationally, it is much kinder to give some kind of transition time. What I would propose is that there be an initial day when the RIPE.db gets loaded with AS690 advisories, as Daniel suggests. This will be a user-visible change, but it will not affect anything operationally. All the old processes still need to be followed that result in NACRs being submitted to the PRDB, and the PRDB information will be what really ends up in the config files. This change will bring some user visibility to the upcoming real change, however. During this time, users would be encouraged to update the Metric:AS lists in both the RIPE.db and the PRDB at the same time, so that the two copies of the data remain in synch. In fact, changes won't be made much except for new nets: Metric:AS lists don't change much unless a net changes providers, and that isn't happening much in Europe at the moment (unlike the US where many networks are moving from ANS to others). This procedure would give an awareness of what is coming up, though; gets people used to having AS690 Metric:AS lists in their route objects; gets them to ask the necessary questions, etc. before the real change. At some flag day called "When AS690 begins using registrations directly from RIPE", we make one more copy of the Metric:AS lists form the PRDB to RIPE.db . This assures that the actual data that has been used to configure AS690 up to the last day continues to be the data that configures AS690 the day after the cutover. From this day on, any user attempting to make a modification to a European net via an update to the PRDB or RADB gets a note saying "Authority for your data has been moved to the RIPE.db; please make your update there." Alternatively, it would be possible to ignore the out-of-synch database problem, and allow some users who updated one database but not the other during the transition period to suddenly lose connectivity. I don't feel strongly about variations on this plan, but the "update twice" approach seems to me to give the users the longest time to get used to the new approach, and it minimizes disruption by minimizing the number of nets that will get dropped on the flag day by copying the operational data at the same time that the system begins to trust the new (RIPE.db) data source. Thoughts? --Dale ---------- Note: the situation is considerably simpler with MCI, since MCI is the entity that is responsible for those Metric:AS lists for their customers in the first place. Note2: we don't have a much more code to produce to be able to generate AS690 configs from the IRR, so the transition could be pretty soon. On the other hand, this is a really major philosophical transition, and we haven't gotten into the comparative testing yet (update both databses from the same NACR input stream to see what happens). The current NSFNET scheme has a *lot* of ack-checking, and some ISPs are indeed holding nets hostage when they try to move to other providers, etc. This will all change when folks make their own updates directly, and there is less to prevent security breaches such as a user stealing someone else's net. I can imagine this kind of issue getting messy just as we prepare to go into production; hence I'm not confident that the transition won't slip a bit more. > From M.H.Behringer at dante.org.uk Wed Dec 28 09:32:57 1994 > To: Daniel Karrenberg , > Tony Bates > From: M.H.Behringer at dante.org.uk (Michael H. Behringer) > Subject: Re: Migration to RIPE 181 > Cc: Marten Terpstra , > ca at cs.umd.edu (Cengiz Alaettinoglu), "Dale S. Johnson" , > epg at merit.edu, rr-impl at ripe.net > > Daniel, > > I suggest you put out a plan on the RIPE list (or RIPE-op?) for > automatically switching the advisory attribute, and ask if somebody would > object if you did the change automatically for the whole DB. Honestly, I > cannot imagine someone objecting to that. You should set a deadline for > objections, say the 13th January (Fri), and if there are no major concerns, > it could be done fairly soon afterwards, say the 16th (monday). (dates are > suggestions only) > > This way we could make sure that the RIPE DB contains all needed > information when the PRDB is retired (note: I don't say the RIPE-DB is > "ready" ;-) . I very strongly feel we should have the RIPE DB up-to-date > when the PRDB is retired. And I don't think this should be a problem. > > Michael > > > At 2:00 pm 28/12/94, Daniel Karrenberg wrote: > > > Tony Bates writes: > > > We are going to automatically add an advisory > > > line to all routes here based on the PRDB to get it bootstrapped. > > > >This is right for you. > >I would be in favour of doing the same in the RIPE RR were it not > >that we would have to touch other people's data which we consider > >a big nono. > > > >There are two possibilities: > > > > - we do it anyway > > > > - we generate suggested data which the maintainers concerned > > can then send in or modify as required. > > > >Either should not be a big deal. > > > >Comments? > > > >Daniel -------- Logged at Fri Dec 30 16:34:30 MET 1994 --------- From bmanning at ISI.EDU Fri Dec 30 16:33:49 1994 From: bmanning at ISI.EDU (bmanning at ISI.EDU) Date: Fri, 30 Dec 1994 07:33:49 -0800 (PST) Subject: Migration to RIPE 181 In-Reply-To: <9412281409.AA00562@ccpnxt5.in2p3.fr.> from "Gilles Farrache" at Dec 28, 94 03:09:20 pm Message-ID: <199412301533.AA06325@zed.isi.edu> > >There are two possibilities: > > > > - we do it anyway > > > > - we generate suggested data which the maintainers concerned > > can then send in or modify as required. > > This a general problem w/ databases. It has been my experience that it is generally wise to take the second course w/ a time limit after which the first course is taken. Then you are done and can go to tea. -- --bill -------- Logged at Tue Jan 3 16:18:07 MET 1995 --------- From Marten.Terpstra at ripe.net Tue Dec 6 02:30:12 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Tue, 06 Dec 1994 02:30:12 +0100 Subject: RIPE RR software fixes Message-ID: <9412060130.AA08942@ncc.ripe.net> Someone has found a bug where if multiple route objects for the same prefix exist (with different origins) and one of them is deleted, all references in the index to this specific prefix are deleted (so it appears all are deleted, but they are not, just missing from the index). The fix is in modules cldb.pl and dbadd.pl. I will post modules as a whole (rather than patches) just to make sure everyone has got the same versions of these two. They will be sent in seperate mails. -Marten -------- Logged at Tue Dec 6 02:39:07 MET 1994 --------- From Marten.Terpstra at ripe.net Tue Dec 6 02:34:21 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Tue, 06 Dec 1994 02:34:21 +0100 Subject: RIPE RR SW fix: dbadd.pl Message-ID: <9412060134.AA09000@ncc.ripe.net> [ Put this module in place of /src/dbadd.pl, go up to and run a "make". "make install" is not needed -- MT] # dbadd - add, delete objects # # $RCSfile: dbadd.pl,v $ # $Revision: 0.23 $ # $Author: marten $ # $Date: 1994/12/06 01:10:29 $ require "dblock.pl"; require "enukey.pl"; require "enkeys.pl"; require "enwrite.pl"; require "addkey.pl"; require "dbmatch.pl"; require "defines.pl"; require "enread.pl"; require "encmp.pl"; require "updatecheck.pl"; require "cldb.pl"; sub dbadd { local(*db, *en, $modify) = @_; print STDERR "dbadd - called\n" if $opt_V; &dblock(*db); print STDERR "dbadd - finding unique key\n" if $opt_V; local($unikey) = &enukey(*en); print STDERR "dbadd - back from enukey\n" if $opt_V; if (defined($db{$unikey})) { &dbunlock(*db); return $E_EXIST; } print STDERR "dbadd - seeking\n" if $opt_V; seek(db, 0, 2); select(db); print "\n"; local($offset) = tell(db); print STDERR "dbadd - writing object to db\n" if $opt_V; &enwrite(*en); select(STDOUT); print STDERR "dbadd - adding unikey\n" if $opt_V; &addkey(*db, $unikey, $offset); print STDERR "dbadd - done adding unique key\n" if $opt_V; # If $modify is set, this is not a new entry, but an update # to an existing entry. Then there is no need to update the # (expensive) classless index. foreach (&enkeys(*en)) { if (/^\d+\.\d+\.\d+\.\d+/ && !$modify) { print STDERR "dbadd - inserting classless stuff\n" if $opt_V; local($pref, $len) = split(/\//, $_); local($netint) = &quad2int($pref); &inscla("$netint/$len", $unikey, 1); } else { print STDERR "dbadd - adding normal keys\n" if $opt_V; &addkey(*db, $_, $offset) unless $_ eq $unikey; } } &dbunlock(*db); print STDERR "dbadd - returning\n" if $opt_V; return $OK; } # # I don't think I am actually using this anywhere, so it is commented out # # sub dbmodify { # local(*db, *en) = @_; # local($i); # # &dblock(*db); # # local($unikey[0]) = &enukey(*en); # # if (!defined($db{$unikey[0]})) { # &dbunlock(*db); # return $E_NOT_FOUND; # } # # local(@result) = &dbmatch(*db, *unikey); # local(%curobject) = &enread(db, $result[0]); # if (&encmp(*en, *curobject)) { # &dbunlock(*db); # return $E_NOOP; # } # # local($updatestat) = &updatecheck(*curobject, *en, *db); # if ($updatestat != $OK) { # &dbunlock(*db); # return $updatestat; # } # # local($delstat) = &dbdel(*db, *curobject); # if ($delstat != $OK) { # &dbunlock(*db); # return $delstat; # } # # seek(db, 0, 2); # select(db); # print "\n"; # local($offset) = tell(db); # &enwrite(*en); # select(STDOUT); # seek(db,0,0); # # &addkey(*db, $unikey[0], $offset); # # foreach $i (&enkeys(*en)) { # if ($i =~ /^\d+\.\d+\.\d+\.\d+/) { # local($pref, $len) = split(/\//, $i); # local($netint) = &quad2int($pref); #&inscla("$netint/$len", $unikey, 1); # } else { # &addkey(*db, $i, $offset) unless $i eq $unikey; # } # } # # &dbunlock(*db); # # return $OK; #} sub dbadd_or_modify { local(*db, *en) = @_; local($addstat); local($updatestat); local($modify) = 0; print STDERR "dbadd_or_modify - called\n" if $opt_V; &dblock(*db); print STDERR "dbadd_or_modify - finding objects\n" if $opt_V; local($unikey[0]) = &enukey(*en); local(@result) = &dbmatch(*db, *unikey); if (defined $result[0]) { if ($#result > 1) { &dbunlock(*db); return E_MULT_MATCH; } local(%curobject) = &enread(db, $result[0]); # We know now that we are performing a real update, not # just a new entry or a delete. This means we can # mark this and not perform a classless index on this # because that will not change anything. Because the # classless index is expensive, it is better to not perform # it if unnecessary. $modify = 1; $updatestat = &updatecheck(*curobject, *en, *db); if ($updatestat != $OK) { &dbunlock(*db); return $updatestat; } if (&encmp(*en, *curobject)) { &dbunlock(*db); return $E_NOOP; } local($delstat) = &dbdel(*db, *curobject, $modify); if ($delstat != $OK) { &dbunlock(*db); return $delstat; } $addstat = &dbadd(*db, *en, $modify); &dbunlock(*db); return $addstat; } print STDERR "dbadd_or_modify - found one object\n" if $opt_V; $updatestat = &updatecheck(*curobject, *en, *db); if ($updatestat != $OK) { &dbunlock(*db); return $updatestat; } print STDERR "dbadd_or_modify - done checking, calling dbadd\n" if $opt_V; $addstat = &dbadd(*db, *en, $modify); &dbunlock(*db); return $addstat; } sub dbdel { local(*db, *en, $modify) = @_; local(@unikey); local(%curobject); local($mult) = 0; local($status) = $NOK; local(%dummy) = (); local($b); local($j); print STDERR "dbdel - called\n" if $opt_V; &dblock(*db); $unikey[0] = &enukey(*en); local(@result) = &dbmatch(*db, *unikey); if ($#result > 0) { print STDERR "dbdel - multiple entries found\n" if $opt_V; $mult = 1; } if ($#result < 0) { &dbunlock(*db); print STDERR "dbdel - entry not found\n" if $opt_V; return $E_NOT_FOUND; } foreach $b (@result) { %curobject = &enread(db, $b); if (!&encmp(*en, *curobject)) { $status = $E_MISMATCH unless $status == $OK; next; } # Dummy updatecheck to get notification. # New object is null, updatecheck will recognize and # skip checks not done for deletes. Only do if it is # a true delete, and not a replace if (&hasdelete(*en)) { $status = &updatecheck(*en, *dummy, *db); if ($status == $E_AUTHFAIL) { &dbunlock(*db); return $E_AUTHFAIL; } } $status = $OK; seek(db, $b, 0); print db "*XX"; @keys = &enkeys(*en); # No need to modify the classless index if this is a # modification, rather than a real delete. if (!$modify) { foreach (@keys) { if (/^\d+\.\d+\.\d+\.\d+/) { local($pref, $len) = split(/\//, $_); local($netint) = &quad2int($pref); &delfromcla("$netint/$len", $unikey[0]); } } } @keys = ($unikey[0], @keys); foreach (@keys) { &delkey(*db, $_, $b); } } &dbunlock(*db); return $status; } 1; -------- Logged at Tue Dec 6 19:26:27 MET 1994 --------- From Marten.Terpstra at ripe.net Tue Dec 6 19:15:35 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Tue, 06 Dec 1994 19:15:35 +0100 Subject: more fixes Message-ID: <9412061815.AA15456@ncc.ripe.net> One more small fix, trying to delete a maintained object while not being properly authorised did not work. Of course there is magic one needs to do, but even then it did not work. It will after this fix below to updatecheck.pl. -Marten *** /ncc/Dbase/src/updatecheck.pl Thu Nov 24 22:14:54 1994 --- updatecheck.pl Tue Dec 6 19:09:42 1994 *************** *** 1,7 **** # $RCSfile: updatecheck.pl,v $ ! # $Revision: 1.15 $ # $Author: marten $ ! # $Date: 1994/10/05 12:39:29 $ require "defines.pl"; require "adderror.pl"; --- 1,7 ---- # $RCSfile: updatecheck.pl,v $ ! # $Revision: 1.16 $ # $Author: marten $ ! # $Date: 1994/12/06 18:09:42 $ require "defines.pl"; require "adderror.pl"; *************** *** 58,64 **** # Check authorisation by maintainer unless override is specified. if (!$new{"uo"} && !&Maintainer(*cur, *new)) { ! return $E_AUTHFAIL; } # Catch if called from dbdel, then skip all checks, --- 58,64 ---- # 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, -------- Logged at Tue Dec 6 20:01:46 MET 1994 --------- From dsj at merit.edu Tue Dec 6 20:01:42 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Tue, 6 Dec 1994 14:01:42 -0500 Subject: Death of the "Global Routing Registry" Message-ID: <199412061901.OAA24156@merit.edu> As the result of an intense dicussion last night including decision-support hardware, the term "Global Routing Registry" will be retired, to be replaced by "Internet Routing Registry". Litle pieces of this big thing (like RIPE.db, RA.db, MCI.db, etc) will be called "Local Routing Registries". --Dale -------- Logged at Tue Dec 6 21:06:31 MET 1994 --------- From bmanning at ISI.EDU Tue Dec 6 21:06:23 1994 From: bmanning at ISI.EDU (Bill Manning) Date: Tue, 6 Dec 1994 12:06:23 -0800 (PST) Subject: notes from last night Message-ID: <199412062006.AA07325@zephyr.isi.edu> John Stewart - MCI Tony Bates - MCI Cengiz Bill Dale Johnson - MERIT Marten T. Daniel K. - RIPE Mirjam Kuehne - RIPE Elise Gerich - Merit Jessica Yu - Merit - multidatabase issues distinct by source attribute - works on single source (current imp.) a series of db that appear consistant when queried - where # of db is 2-10 10-100 (where the query can be analysis tools) documentation tools - prtraceroute etc. what do we do: RIPE keeps RIPE data, & others (internic, prdb, alternet) Tools currently query all and have internal weighting for belief on answers. MCI shadows RIPE, internal MCI, PRDB, CAnet, Internic. same as RIPE sw. mirror tools different than RIPE, pull twice a day. Split mode vs Single - more flexable - work on raw data - more flexable indexes.. Internic is into rwhois once a week. (wish they were here) (its tagged- can we get it as a mirror?) Merit - PRDB (for 690 till apr95), 4-6 wks w/ split RRDB and PRDB co-incident. Use of advisory attribute is appreciated. Pulled 181 over monday. Will announce in a week or two. RS - multi-view - need docs (whole issue of change control of 181 attributes) (things that can't be done in 181 (alternet, ANS) What tools do we have and where do they get the data? Get the data via one server (cached data?) How to do consistancy checking) If we can define what we are athoritative for, then we can figure out models of trust. Do we just query for the things we need? Distributed updates is a good thing. A whole snapshot or a diff? Diffs may not be able to deal w/ deletes. Keep copies from each db. (for at least a year - with limited set?) Need distributed DB guru? yes/no? What level of syncronization do we need? Update per record does not seem tractable. Shapshoot may not be feasable but it is easier. 2hrs or twice a week - use the snapshots as often as they want. Timestamp and MD5 sign the updates. Belief is the order in which things are returned. Models of trust is based on non-authoritative archives of others data. No "source GRR" (may build a "fake" GRR appearance) Use IRR (Internet Routing Registry (Daniel K) add what sources you hold and the ordering to the software (add timestamp of the latest update) IRR object - describe the local registry (done by rocky&bullwinkle & Mr.Peabody) Daniel will keep a copy of the "master-list" IRR wins over GRR based on the coin toss. mir at ripe.net jstewart at mci.net --- Changes to 181 extentions? references/referal objects ? deal w/ community strings and replication of strings (fifo on string uniqness) A global unique structure or loose (duplicated) RRs? Need 281, 381, updated/upgraded. Need to complete the documentation/rfc and then next series of upgrades. Do we ask for a plenery at the next IETF after the fyiRFC. Yes. Preclude changes now? No. Turn 181 into an RFC now. Daniel will do the dirty work. send to rr-impl list. Config-file generators (prconfig?) all new tools added to the pride tool suite mirror the stuff. add the advisory attribute (check syntax) Tony and Dale will work the details. -- --bill -------- Logged at Tue Dec 6 23:25:05 MET 1994 --------- From Tony.Bates at ripe.net Tue Dec 6 23:24:54 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Tue, 06 Dec 1994 23:24:54 +0100 Subject: notes from last night In-Reply-To: Your message of Tue, 06 Dec 1994 12:06:23 PST. <199412062006.AA07325@zephyr.isi.edu> Message-ID: <9412062224.AA16746@ncc.ripe.net> Just a point of clarification. This will be an Informational RFC - NOT an FYI. * * Do we ask for a plenery at the next IETF after the fyiRFC. * Yes. Preclude changes now? No. --Tony. -------- Logged at Wed Dec 7 09:18:47 MET 1994 --------- From epg at merit.edu Wed Dec 7 09:18:43 1994 From: epg at merit.edu (Elise Gerich) Date: Wed, 7 Dec 1994 03:18:43 -0500 Subject: Death of the "Global Routing Registry" Message-ID: <199412070818.DAA12786@merit.edu> Dale, >As the result of an intense dicussion last night including decision-support >hardware, the term "Global Routing Registry" will be retired, to be replaced >by "Internet Routing Registry". Litle pieces of this big thing (like RIPE.db, >RA.db, MCI.db, etc) will be called "Local Routing Registries". > >--Dale Yep, IRR was selected on the flip of a coin, but my understanding of what the subcomponents are called was "routing registries." This was in part because of the confusion that might happen with purely local registries which will be maintained for local, internal configurations. The analogy was the "Internet is a network of networks" and the IRR is a routing registry of routing registries. --Elise -------- Logged at Wed Dec 7 22:35:38 MET 1994 --------- From dsj at merit.edu Wed Dec 7 22:35:30 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Wed, 7 Dec 1994 16:35:30 -0500 Subject: Default behavior of whois Message-ID: <199412072135.QAA04088@merit.edu> Monday we decided that the "normal" behavior of the IRR will be for any site to return data from multiple dbs (in some order of trust declared by the local site). Given that this is to be so, can we change the default behavior of whoisd to support this? Particularly, when called with a standard Unix whois client, can we have whois return all of the production (not test) database answers for that query? (Like "-a"). (This is particularly inportant for the startup of the RADB, since most of our initial data will be from non-primary databases RIPE.db, CANET.db, MCI.db, and PRDB.db rather than from our primary database RADB.db). If there aren't any violent objections to this, Merit can make this change in our own code, and have it follow in the official distribution. --Dale ---------- (PS: Other nice options to support: "Give me just one answer, the first one you encounter". And "Give me one answer, but compare the responses from all the databases you have. Where the fields are identical, just give them. Where they differ, mark the variances".) -------- Logged at Thu Dec 8 02:53:37 MET 1994 --------- From Marten.Terpstra at ripe.net Thu Dec 8 02:52:13 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Thu, 08 Dec 1994 02:52:13 +0100 Subject: YAF (Yet Another Fix) Message-ID: <9412080152.AA25440@ncc.ripe.net> Mntner passwords that contain spaces were not correctly handled. Please replace your version of enparse.pl with the one below. Please note that passwords with leading or trailing spaces can NOT be used (simply because of parsing limitations, one can never know where a password starts or ends ...). Spaces somewhere in the middle of passwords are fine with the below version of enparse.pl. -Marten # enparse - read RIPE database and check syntax errors # # $RCSfile: enparse.pl,v $ # $Revision: 1.6 $ # $Author: marten $ # $Date: 1994/12/08 01:47:21 $ # # ARGUMENTS: filehandle to read from # RETURNS: INTEGER object_status # ASSOC object # # Object status = $O_OK, $O_WARNING, $O_ERROR, $EOF, or $NOK # $O_OK = object read and no errors/warnings generated # $O_WARNING = object read, but generated warnings # $O_ERROR = object read, but generated errors # $EOF = EndOfFile reached # $NOK = no object found, just garbage # # Object has warnings and errors included. # # This routine is a modified version of enread. It will read any # garbage, until it finds something of the form: # "xxxxxxx: " (no fixed length, spaces MUST be there) # or # "*xx: " # and then continues to read until it finds a line that does not # match these patterns. It then assumes it read an object, and will # start doing syntax checks. require "entype.pl"; require "syntax.pl"; require "defines.pl"; require "adderror.pl"; sub readsomething { local($file) = @_; local($inentry) = $NOK; local($tag) = ""; local(%entry) = (); while (<$file>) { s/^\s*//; s/\s*$//; s/\n*$//; next if /^#/; if (/^password:\s*(\S.*\S)/) { $PASSWORD = $1; next; } if (/^\*..:\s*(.*)/) { $inentry = $OK; $tag = substr($_, 1, 2); if ($entry{$tag}) { $entry{$tag} .= "\n"; } $entry{$tag} = $entry{$tag} . $1; next; } if (/^([a-z\-A-Z_]+)\s*:\s*(.*)/) { $inentry = $OK; $tag = $1; $tag =~ tr/A-Z/a-z/; $tag = $ATTR{$tag} if $ATTR{$tag}; if ($entry{$tag}) { $entry{$tag} .= "\n"; } $entry{$tag} = $entry{$tag} . "$2"; next; } if (/^.*$/) { next if $inentry == $NOK; $CUROBJTYPE = &entype(*entry); return ($inentry,%entry); } } $CUROBJTYPE = &entype(*entry); return ($inentry, %entry) if ($inentry); return $EOF; } sub checkobject { local(*object) = @_; local($type); local($rtcode) = $O_OK; local(%knownfield) = (); local(%mandfield) = (); local(%multfield) = (); local(%knownfield) = (); local(%guard) = (); local(%usefield) = (); local($i); print STDERR "checkobject - called\n" if $opt_V; $type = &entype(*object); if (!$type) { &adderror(*object, "unknown object type"); return $O_ERROR; } # Check guarded objects, should be authorised or maintained # The message will request the object be maintained foreach (keys %GRDOBJ) { if ($object{$_}) { if (!$object{"ua"} && !$object{"mb"}) { &adderror(*object, "the \"$ATTL{$_}\" object cannot be updated ". "automatically without a \"mnt-by\" attribute"); # now if this object was supposed to be deleted, remove # the delete attribute, since deletes will remove # syntax errors later in the program and this is one # that may not be removed. There is also no point in # doing more checks if it was supposed to be deleted. if ($object{"ud"}) { undef $object{"ud"}; return $O_ERROR; } # otherwise, continue extra checks for clarity to user $rtcode = $O_ERROR; } last; } } foreach $i ((split(/\s+/, $OBJATSQ{$type}),"ud","ua","uo","uw","ue")) { $knownfield{"$i"} = 1; } foreach $i (split(/\s+/, $OBJMAND{$type})) { $mandfield{"$i"} = 1; } foreach $i (split(/\s+/, $OBJMULT{$type})) { $multfield{"$i"} = 1; } foreach $i (split(/\s+/, $GRD{$type})) { $guard{"$i"} = 1; } foreach $i (keys %object) { $usefield{"$i"} = 1; } foreach (split(/\s+/, $OBS{$type})) { if ($object{$_}) { &addwarning(*object, "attribute \"$ATTL{$_}\" has been obsoleted,". " value removed from object"); delete $object{$_}; delete $usefield{$_}; $rtcode = $O_WARNING; } } foreach $i (keys %usefield) { if (!$knownfield{"$i"}) { if ($ATTL{"$i"}) { &adderror(*object, "attribute \"$ATTL{$i}\" unknown ". "in $ATTL{$type} object"); } else { &adderror(*object, "attribute \"$i\" unknown in $ATTL{$type} object"); } $rtcode = $O_ERROR; } undef $mandfield{"$i"} unless $object{$i} eq ""; if ($object{$i} =~ /\n/) { if (!$multfield{"$i"}) { &adderror(*object, "multiple lines not allowed for: \"$ATTL{$i}\""); $rtcode = $O_ERROR;; } } } foreach $i (keys %mandfield) { if ($mandfield{$i}) { if (defined($object{$i}) && ($object{$i} =~ /^\n*$/)) { &adderror(*object, "mandatory field \"$ATTL{$i}\" must have a value"); } else { &adderror(*object, "mandatory field \"$ATTL{$i}\" missing"); } $rtcode = $O_ERROR; } } print STDERR "checkobject - returned\n" if $opt_V; return $rtcode; } sub enparse { local($file) = @_; local(%entry); local($rtcode) = $O_OK; local($stat); print STDERR "enparse - reading something\n" if $opt_V; ($stat, %entry) = &readsomething($file); return $EOF if $stat == $EOF; return $NOK if $stat == $NOK; print STDERR "enparse - checking object format\n" if $opt_V; $rtcode = &checkobject(*entry); if ($rtcode == $O_OK) { print STDERR "enparse - checking object syntax\n" if $opt_V; $rtcode = &checksyntax(*entry); } return $rtcode, %entry; } 1; -------- Logged at Fri Dec 9 21:11:44 MET 1994 --------- From dsj at merit.edu Fri Dec 9 21:11:37 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Fri, 9 Dec 1994 15:11:37 -0500 Subject: "Export dbm" program Message-ID: <199412092011.PAA03641@merit.edu> Has anyone looked at a program that would make an external representation of a dbm file, so that that file could be ftp'd, archived, etc. without passing on gigs of zeros? Obviously, I'm thinking about passing around our various .db files all ready indexed, (rather than spendign 3 hours of CPU time reindexing each one on our main production machine, our backup production machine, our test machine, MCI's machine, CANET's machine, ...) Also, has there been philosophical discussion about whether the ftp file is cut (e.g.) once per day, or whether it is linked to the active .db file? --Dale -------- Logged at Fri Dec 9 21:31:43 MET 1994 --------- From GeertJan.deGroot at ripe.net Fri Dec 9 21:31:37 1994 From: GeertJan.deGroot at ripe.net (Geert Jan de Groot) Date: Fri, 09 Dec 1994 21:31:37 +0100 Subject: "Export dbm" program In-Reply-To: Your message of "Fri, 09 Dec 1994 15:11:37 EST." <199412092011.PAA03641@merit.edu> Message-ID: <9412092031.AA10150@ncc.ripe.net> On Fri, 9 Dec 1994 15:11:37 -0500 "Dale S. Johnson" wrote: > Has anyone looked at a program that would make an external representation > of a dbm file, so that that file could be ftp'd, archived, etc. without > passing on gigs of zeros? For now, you might want to look into dump. Something like 'dump 0f - /whatever/special/directory | gzip > /dumpfile' will work. This is SUN-specific but it might be useful for now. Geert Jan -------- Logged at Fri Dec 9 21:44:24 MET 1994 --------- From dsj at merit.edu Fri Dec 9 21:44:20 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Fri, 9 Dec 1994 15:44:20 -0500 Subject: "Export dbm" program Message-ID: <199412092044.PAA05939@merit.edu> Geert Jan, > This is SUN-specific but it might be useful for now. SUN-specific is seeming more and more universal these days... Thanks. :-) --Dale =============== > On Fri, 9 Dec 1994 15:11:37 -0500 "Dale S. Johnson" wrote: > > Has anyone looked at a program that would make an external representation > > of a dbm file, so that that file could be ftp'd, archived, etc. without > > passing on gigs of zeros? > > For now, you might want to look into dump. Something like > 'dump 0f - /whatever/special/directory | gzip > /dumpfile' > will work. > > This is SUN-specific but it might be useful for now. > > Geert Jan > > -------- Logged at Tue Dec 13 09:49:23 MET 1994 --------- From Daniel.Karrenberg at ripe.net Tue Dec 13 09:49:21 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 13 Dec 1994 09:49:21 +0100 Subject: "Export dbm" program In-Reply-To: Your message of Fri, 09 Dec 1994 15:11:37 EST. <199412092011.PAA03641@merit.edu> Message-ID: <9412130849.AA28389@ncc.ripe.net> > "Dale S. Johnson" writes: > Has anyone looked at a program that would make an external representation > of a dbm file, so that that file could be ftp'd, archived, etc. without > passing on gigs of zeros? External representation is easy: Use your favourite compress program. When decompressing you need a little program that seeks over "blocks" of consecutive 0s unless you have a lot of disk space. Of course you will have to specify which DBM package was used generating the index files! > Also, has there been philosophical discussion about whether the ftp file > is cut (e.g.) once per day, or whether it is linked to the active .db > file? Yes, you were there! The conclusion I remember was: Cut it once a day and provide a trail of the deltas separately with monotonously increasing serial numbers. It was suggested that the serial numbers could encode time. Daniel -------- Logged at Tue Dec 13 19:56:09 MET 1994 --------- From dsj at merit.edu Tue Dec 13 19:56:05 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Tue, 13 Dec 1994 13:56:05 -0500 Subject: "Export dbm" program Message-ID: <199412131856.NAA14274@merit.edu> > > Also, has there been philosophical discussion about whether the ftp file > > is cut (e.g.) once per day, or whether it is linked to the active .db > > file? > > Yes, you were there! The conclusion I remember was: Cut it once a day > and provide a trail of the deltas separately with monotonously > increasing serial numbers. It was suggested that the serial numbers > could encode time. Interesting! You're right; this is the mechanism we spec'd for intra-IRR data exchange (after we get some cycles to improve on straight ftp). The biggest advantage of this "delta" method that I remember was that it conserves bandwidth ('don't have to ftp the whole file every day) and cpu cycles (only have to dbupdate the most recent changes: don't have to do the whole 3-hour reindex for every large DB every day). What I was thinking about was the public ftp repository: the place folks go to get data is they want to do some analysis (like the PRDB reports files). If this is only updated once per day, then you have an annoying average-of-twelve-hours-out-of-date problem. But suppose this file in the anonymous ftp directory was actually the file that the registry ran off: the one that dbupdate updated. Then whoever got ftp'd this file for making reports would have absolutely up-to-date information. (With the caveat that his info might be so up-to-date that there's a half-finished record written at the end of the file). --Dale -------- Logged at Tue Dec 13 20:06:13 MET 1994 --------- From dsj at merit.edu Tue Dec 13 20:06:08 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Tue, 13 Dec 1994 14:06:08 -0500 Subject: FTP db scripts Message-ID: <199412131906.OAA15179@merit.edu> FYI, Here are some scripts as we're using them to ftp db's and index them. The PRDB script is a bit more complicated, because PRDB can finish anytime between 3:am and noon EST. #!/usr/local/bin/perl # # import.canet - bring over CANET.db # # $Id: import.canet,v 1.1 1994/12/13 18:59:30 dsj Exp dsj $ # # require "/ra/lib/perl/aftp.pl" ; require "/ra/lib/perl/times.pl" ; umask 2 ; $start = $^T ; chdir "/ra/crons/incoming.canet"; printf STDERR "%s $0 getting the new canet.db...\n", &date_stamp; &aftp( "crcd.canet.ca:/canet/crcd/canet.db" ); &timeline( "ftp canet.ca" ); print `/ra/ripe181/bin/netdbm canet.db` ; &timeline( "netdbm canet.db" ); print `/ra/ripe181/bin/netdbm -c canet.db` ; &timeline( "netdbm -c canet.db" ); print `/bin/rm -f /ra/ripe181/data/d-canet/*` ; print `/bin/mv canet.db* /ra/ripe181/data/d-canet` ; &timeline( "mv canet.db* /ra/ripe181/data/d-canet" ); ------------------ #!/usr/local/bin/perl # # import.prdb - use ftp to check for a new prdb being available. # if there is a new one, then kick off an index, and mark # that this one is the one you've got. # # The prdb program that kicks this process off is ~prdb/bin/prdb_rrdb. # The particular statement that starts the magic is: # date +%y%m%d%H%M%S > /u/ftp/pub/PRDB_TIMESTAMP # # BUGS: This code does not cover the case that a second reindex is # kicked off before the first is finished. # # $Id: import.prdb,v 1.2 1994/12/13 19:05:07 dsj Exp dsj $ # # require "/ra/lib/perl/aftp.pl" ; require "/ra/lib/perl/times.pl" ; umask 2; chdir "/ra/crons/incoming.prdb"; &aftp( "twain.merit.edu:pub/PRDB_TIMESTAMP" ); $new_date = &get_datestamp( "PRDB_TIMESTAMP" ); $last_date = &get_datestamp( "LAST_PRDB_TIMESTAMP" ); if ( $new_date gt $last_date ) { printf "%s $0 getting the new prdb.db...\n", &date_stamp; print `cp PRDB_TIMESTAMP LAST_PRDB_TIMESTAMP`; &aftp( "twain.merit.edu:pub/prdb.db" ); &timeline( "ftp prdb.db" ); print `/ra/ripe181/bin/netdbm prdb.db` ; &timeline( "netdbm prdb.db" ); print `/ra/ripe181/bin/netdbm -c prdb.db` ; &timeline( "netdbm -c prdb.db" ); print `/bin/rm -f /ra/ripe181/data/d-prdb/*` ; print `/bin/mv prdb.db* /ra/ripe181/data/d-prdb` ; &timeline( "mv prdb.db* /ra/ripe181/data/d-prdb" ); } #------------------------------ subroutines ----------------------------- # # Open a file, and return the date stamp within it. # sub get_datestamp { local( $file ) = @_ ; $date = `cat $file`; # 941205140956 if ( $date lt "940102030405" ) { print "error: no date in $file\n"; print "-->$date<--\n"; $date = "0\n"; } chop($date) ; return ($date) ; } #!/usr/local/bin/perl # # Bring a file over via anonymous ftp. # # $Id: aftp.pl,v 1.1 1994/12/13 19:02:53 dsj Exp dsj $ # sub aftp { local ( $remote, $local_file ) = @_; ($host = $remote) =~ s/:.*$// ; ($path = $remote) =~ s/^.*:// ; if ( $path =~ m|/| ) { $path =~ m|^(.*)/([^/]*)$| ; $cd_path = $1 ; $file = $2 ; } else { $file = $path ; $cd_path = ""; } $user = getpwuid( $< ); chop( $this_machine = `hostname` ); $this_machine .= ".ra.net" ; $cmd = "user anonymous $user\@$this_machine\n" ; $cmd .= "cd $cd_path\n" if ($cd_path) ; $cmd .= "get $file $local_file\n" . "quit\n" ; print `echo '$cmd' | ftp -n $host `; # # Should figure some way of checking success here... # } 1; #!/usr/local/bin/perl # # times.pl - format log lines with date/time stamps # # &date_stamp returns "yy-mm-dd hh:mm" # &timeline( "message" ) prints "hh:ss hh:ss message" # # $Id: times.pl,v 1.1 1994/12/13 19:02:53 dsj Exp dsj $ # # sub date_stamp { ($sec, $min, $hour, $mday, $mon, $year) = localtime( $^T ); return( sprintf("%2.2d-%2.2d-%2.2d %2.2d:%2.2d", $year, $mon+1, $mday, $hour, $min )); } sub timeline { local( $msg ) = @_ ; local( $now ) = time ; $last_timeline_call = $^T unless ($last_timeline_call); $total_used = prt_time( $now - $^T ); $last_used = prt_time( $now - $last_timeline_call ); print "$total_used $last_used $msg\n"; $last_timeline_call = $now ; } sub prt_time { local( $secs ) = @_ ; local( $days, $hrs, $min, $rtn); $days = int( $secs / 86400) ; $secs -= $days * 86400 ; $hrs = int( $secs / 3600) ; $secs -= $hrs * 3600 ; $min = int( $secs / 60 ); $secs -= $min * 60 ; if ( $days>0 ) { $rtn = sprintf("%2.2d:%2.2d:%2.2d:%2.2d", $days, $hrs, $min, $secs) } elsif ( $hrs>0 ) { $rtn = sprintf("%2.2d:%2.2d:%2.2d", $hrs, $min, $secs) } else { $rtn = sprintf("%2.2d:%2.2d", $min, $secs) } return( $rtn ); } 1; -------- Logged at Tue Dec 13 22:28:18 MET 1994 --------- From cengiz at ISI.EDU Tue Dec 13 22:27:50 1994 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Tue, 13 Dec 1994 13:27:50 -0800 Subject: "Export dbm" program In-Reply-To: <199412131856.NAA14274@merit.edu> References: <199412131856.NAA14274@merit.edu> Message-ID: <199412132127.AA02847@cat.isi.edu> Dale S. Johnson (dsj at merit.edu) on December 13: > What I was thinking about was the public ftp repository: the place folks > go to get data is they want to do some analysis (like the PRDB reports > files). If this is only updated once per day, then you have an annoying > average-of-twelve-hours-out-of-date problem. But suppose this file in > the anonymous ftp directory was actually the file that the registry ran > off: the one that dbupdate updated. Then whoever got ftp'd this file > for making reports would have absolutely up-to-date information. (With > the caveat that his info might be so up-to-date that there's a half-finished > record written at the end of the file). Dale, I do not see the point in doing this. As we discussed, one can not achieve synchronisation by simply keeping the ftp copy more up-to-date. Also the format of the ftp'able database and one in production may differ (some parties may use informix for example). If you want more up-to-date copy of the database, just play the deltas to the copy of the database you have locally. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute cengiz at isi.edu University of Southern California -------- Logged at Tue Dec 13 23:03:35 MET 1994 --------- From dsj at merit.edu Tue Dec 13 23:03:32 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Tue, 13 Dec 1994 17:03:32 -0500 Subject: "Export dbm" program Message-ID: <199412132203.RAA13773@merit.edu> Cengiz, > Dale S. Johnson (dsj at merit.edu) on December 13: > > What I was thinking about was the public ftp repository: the place folks > > go to get data is they want to do some analysis (like the PRDB reports > > files). If this is only updated once per day, then you have an annoying > > average-of-twelve-hours-out-of-date problem. But suppose this file in > > the anonymous ftp directory was actually the file that the registry ran > > off: the one that dbupdate updated. Then whoever got ftp'd this file > > for making reports would have absolutely up-to-date information. (With > > the caveat that his info might be so up-to-date that there's a half-finished > > record written at the end of the file). > > Dale, > > I do not see the point in doing this. As we discussed, one can not > achieve synchronisation by simply keeping the ftp copy more > up-to-date. Yes, I exactly agree with you (and Daniel) about synchronizing the databases within the IRR. My issue is about something else. It is useful to make bulk data available to general users on the Internet. Engineers use this for sanity checks against their own config files, for ad-hoc analysis (e.g. "How many aggregates are there?"), etc. The PRDB supports this through a variety of reports, including "net-comp.now" (the most popular) and "nets.unl.now" (a dump of all fields relating to networks in a machine-parsable format). The RIPE system supports this same function by making the *.db files available for anonymous ftp. If you want to (for instance) count the number of A's B's and C's in the world, you ftp their database and run you script on your machine. There is a sentence somewhere in the RIPE documents that says they don't do other reports because reports are so easy to generate off their .db dump. This dump of data is a basic end-user deliverable of the system, quite independent of anything that the members of the IRR need to have in place to achieve their own synchronization. It is this function that I am suggesting we make trivially up-to-date where possible by putting the actual db file up for distribution (rather than a strobed copy of it). [Actually, the RA has a technical difficulty with this: for security reasons, we do not want to run anonymous ftp or NFS mounts on the production machine, so the actual production .db file is not on-line to the ftp machine. But maybe we can work something else out; perhaps kerberos NFS]. > Also the format of the ftp'able database and one in production may > differ (some parties may use informix for example). Yes, you're right that the internal format does not have to be the same as the external ftp'able exchange format. However, it means that if you *are* running the RIPE software and you do use a symlink to make the ftp'able copy be the real internal copy, then you can build a more responsive system than if you use another approach. [This is another reason I'm not attracted to using an RDBMS to rebuild RIPE. The PRDB program that dumps just the nets now runs for a full hour, and thats only for 43,000 nets.]. > If you want more up-to-date copy of the database, just play the deltas > to the copy of the database you have locally. Yes, this is the best approach for members of the IRR. But if you are just Joe User and want to do some data analysis, though, it would be much nicer to just ftp the thing and get the up-to-date copy, rather than be required to install the portion of the 181 database engine that knows how to apply the deltas, and to go through that whole initial-plus- deltas procedure. > Cengiz > > -- > Cengiz Alaettinoglu Information Sciences Institute > cengiz at isi.edu University of Southern California --Dale -------- Logged at Tue Dec 13 23:15:34 MET 1994 --------- From cengiz at ISI.EDU Tue Dec 13 23:15:15 1994 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Tue, 13 Dec 1994 14:15:15 -0800 Subject: "Export dbm" program In-Reply-To: <199412132203.RAA13773@merit.edu> References: <199412132203.RAA13773@merit.edu> Message-ID: <199412132215.AA02888@cat.isi.edu> Dale S. Johnson (dsj at merit.edu) on December 13: > Yes, this is the best approach for members of the IRR. But if you are > just Joe User and want to do some data analysis, though, it would be > much nicer to just ftp the thing and get the up-to-date copy, rather > than be required to install the portion of the 181 database engine that > knows how to apply the deltas, and to go through that whole initial-plus- > deltas procedure. Joe User does not need up-to-date data as by the time he publishes his results that data is already out-of-date:-) I am not against what you suggested. I just do not see much use for it. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute cengiz at isi.edu University of Southern California -------- Logged at Wed Dec 14 11:50:23 MET 1994 --------- From Marten.Terpstra at ripe.net Wed Dec 14 11:50:17 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Wed, 14 Dec 1994 11:50:17 +0100 Subject: dbupdate.pl fix Message-ID: <9412141050.AA07070@ncc.ripe.net> Folks, dbupdate has a small bug where it can fail to do the proper indexing when handling multiple indexes (ie a mix or routes, inetnums and inet-rtrs). It can fail to use the correct index when one of the objects generates warnings and/or errors. Please replace src/dbupdate.pl with the one below and run a "make install" in the top level database directory. -Marten PS For all who are running "older" versions of the DB or have not kept up with all patches I have been sending out, the version on ftp://ncc.ripe.net/dbase-beta/dbase-beta.tar.gz is kept up-to-date. #!PERL # $RCSfile: dbupdate.pl,v $ # $Revision: 0.31 $ # $Author: marten $ # $Date: 1994/12/14 10:40:55 $ # This is a client that will update objects read from a file directly # in the database, without interference of updated. # It will update the object in the database that is linked to the # source field of the object, so better make sure you have a source field # and that it has a database associated to it ... @INC = ("LIBDIR", @INC); require "adderror.pl"; require "cldb.pl"; require "dbadd.pl"; require "dbclose.pl"; require "dbopen.pl"; require "defines.pl"; require "enparse.pl"; require "entype.pl"; require "enwrite.pl"; require "getopts.pl"; require "handle.pl"; require "misc.pl"; require "rconf.pl"; require "rfc822.pl"; require "syslog.pl"; # Parse options: # # -l logfile - log output to file in stead of STDOUT # -v - verbose output (LONGACK) # -M - treat input file (or STDIN) as mail and compose # and send ack mail back # -A - assume "assign" mode, only add will be allowed # usually set by parsing mail headers # -H - handle assignment mode. Will only accept persons # with nic-handle "assign" and return person entry # with the handle assigned and filled in. # (very RIPE database dependent) &Getopts('l:vMAHV'); # Need this below for running perl in tainted mode. $ENV{"PATH"} = ""; $ENV{"SHELL"} = "/bin/sh"; $ENV{"IFS"} = ""; # Read config file from RIPEDBCNF, or set to default. $conffile=$ENV{"RIPEDBCNF"}; $conffile= "DEFCONFIG" unless $conffile; print STDERR "dbupdate - reading config\n" if $opt_V; &rconf($conffile); # Save STDOUT open(SAVEOUT, ">&STDOUT"); # Open one ack file. Proper handling (stdout, logfile or mail) is handled # all the way at the end .... But, we open the logfile if needed already # because we need to exit if we cannot even create that file ... # If -M option is specified, -l is overruled. if ($opt_l) { open(LOGFILE, ">$opt_l") || die "Cannot create $opt_l: $!"; } open(STDOUT, ">$TMPDIR/dbupdack.$$") || &syslog("ERRLOG", "cannot create tmp ack file: $!"); # Make STDOUT unbuffered select(STDOUT); $| = 1; # # printstat ( arg ) # # int arg /* 0=failed, 1=ok, 2=noop */ # # prints verbose version of the update result. # sub printstat { local($stat) = @_; local($type) = &entype(*entry); print STDERR "dbupdate - printstat($stat) called\n" if $opt_V; print STDERR "dbupdate - printstat 1\n" if $opt_V; if ($hasdelete) { print "Delete "; } else { print "Update "; } print STDERR "dbupdate - printstat 2\n" if $opt_V; if ($stat == 1) { print "OK: ";} elsif ($stat == 2) { print "NOOP: ";} else { print "FAILED: "; } print STDERR "dbupdate - printstat 3\n" if $opt_V; print "[$ATTL{$type}] $entry{$type}\n\n"; print STDERR "dbupdate - printstat 4\n" if $opt_V; } # # doaction ( ) # # does all the work. # sub doaction { local($file) = @_; local($donestat) = 0; print STDERR "dbupdate - doaction($file) called\n" if $opt_V; while(1) { $donestat = 0; print STDERR "dbupdate - calling enparse\n" if $opt_V; ($parsestat, %entry) = &enparse($file); # next if nothing was read next if $parsestat == $NOK; # return if only thing read was EOF return if $parsestat == $EOF; $somethingfound = 1; print STDERR "dbupdate - read an object\n" if $opt_V; # Now, let's check whether this is a delete request or not # If it is, we have to skip all syntax checks ... # A wrongly defined delete attribute will return a 0, # and add a error message. $hasdelete = &hasdelete(*entry); # object parsing generated an error, output object with # errors and return. If we are deleting an object, then # forget about it, we do not want to return with syntax # errors local($type) = &entype(*entry); # now if we are running in -H mode, just next when we have # not found a person. if ($opt_H) { if ($type ne "pn") { print "No person object found\n"; next; } else { if ($entry{"nh"} !~ /^[aA][sS][sS][iI][gG][nN]$/) { &adderror(*entry, "nichandle \"assign\" expected"); print "\n" if &enwrite(*entry,1,1); next; } } } if (($parsestat == $O_ERROR) && (!$hasdelete)) { print STDERR "dbupdate - object has error and no delete\n" if $opt_V; if ($opt_v) { &printstat(0); } $haserror = 1; print "\n" if &enwrite(*entry,1,1,1); next; } # If we have to delete, remove all parse errors and warnings # and set status to OK: we do not want deletes to be checked if ($hasdelete) { &rmwarnings(*entry); &rmerrors(*entry); $parsestat= $O_OK; } # object parsed OK or has only warnings if ($parsestat == $O_OK || $parsestat == $O_WARNING) { # open database file associated with "so" for writing local(*db) = 'currentdb'; print STDERR "dbupdate - opening database\n" if $opt_V; if (&dbopen(db, *entry, 1)) { # Open classless database print STDERR "dbupdate - opening classless db\n" if $opt_V; &dbclopen(*entry,1); # Looks like we have some locking problem, so let's # lock the thing before we do anything else ... print STDERR "dbupdate - locking databases\n" if $opt_V; &dblock(*db); # do we delete or not ? if ($hasdelete) { print STDERR "dbupdate - deleting entry\n" if $opt_V; $dbstat = &dbdel(*db, *entry); # We do handle generation, so after a delete, we # have to delete the handle from that database # as well. if ($DOHANDLE && $HANDLEATTR{$type}) { if ($dbstat == $OK) { &DeleteHandle(*entry); } } } else { # We do handle generation, check whether we have # to assign a nic handle (if nh value is "assign") # Can be a request handle of form: assign handle # Line has already been syntax checked, so no worries # there. Errors are added by AssignHandle, so all we # need is an extra check. if ($DOHANDLE && $HANDLEATTR{$type}) { if ($entry{$HANDLEATTR{$type}} =~ /^[Aa][Ss][Ss][Ii][Gg][Nn]\s*(.*)$/) { local($handle) = &AssignHandle(*entry, $1); } else { # new object, we may have to put the handle # in the database. AddHandle will return if # if the handle is already in handle database &AddHandle(*entry); } } if (!&haserror(*entry)) { # NEW assignments && !person if ($opt_A && ($type ne "pn")) { print STDERR "dbupdate - calling dbadd\n" if $opt_V; $dbstat = &dbadd(*db, *entry); } else { print STDERR "dbupdate - calling add_or_mod\n" if $opt_V; $dbstat = &dbadd_or_modify(*db, *entry); } } else { # Fake dbstat, has error due to handle # generation ... $dbstat = $OK; } } # Totally yucky, but I do not know how to # do this better right now. The thing is that # every exit code but E_NOOP and OK are # errors, so catch NOOP first, and print # verbose warning if needed, then OK, and # then handle all the others as errors. # noop, just print stat if verbose print STDERR "dbupdate - doing acks\n" if $opt_V; if ($dbstat == $E_NOOP && $opt_v) { &printstat(2); $donestat = 1; } elsif (($dbstat != $OK) && ($dbstat != $E_NOOP)){ &adderror(*entry, "$MESSAGE[$dbstat]"); } # Object has errors, so print, and next if (&haserror(*entry)) { print STDERR "dbupdate - object has errors\n" if $opt_V; $haserror = 1; if ($opt_v) { &printstat(0); } print "\n" if &enwrite(*entry,1,1); &dbunlock(*db); &dbclose(*db); &dbclclose(); next; } # object has only warnings, so it must have # been processed. print and next. elsif (&haswarning(*entry)) { print STDERR "dbupdate - object has warnings\n" if $opt_V; $haserror = 1; if (!$donestat && $opt_v) { &printstat(1); } print "\n" if &enwrite(*entry,1,1); &dbunlock(*db); &dbclose(*db); &dbclclose(); next; } # all was OK, so only print stat if verbose if ($opt_v && !$donestat) { &printstat(1); } # all was OK, print object if nichandle assign mode if ($opt_H) { &enwrite(*entry,1,1); } &dbunlock(*db); &dbclose(*db); &dbclclose(); } else { # Not too good, probably permission problem # if this is given as output ... &adderror(*entry, "Failed to open DB file: $!"); &adderror(*entry, "Please check the \"source:\" value"); &adderror(*entry, "Contact <$HUMAILBOX> if source seems ok"); &printstat(0); &enwrite(*entry,1,1); } } } close(TMP); } # # Main program # # We want to make a local copy of the input, because we need to do mutliple # things with it ... open(COPY, ">$TMPDIR/dbupdcopy.$$") || die "Cannot open copy file: $!"; select(COPY); $| = 1; select(STDOUT); while (<>) { print COPY; } close(COPY); # Now we open the copy to actually process open(COPY, "$TMPDIR/dbupdcopy.$$") || die "Cannot open copy: $!"; # We have a mail, so let's first parse the headers ... if ($opt_M) { local($stat) = &parserfc822(COPY); # If we have at least a return address, compose the header of # the ack mail if ($stat) { if ($TESTMODE) { print "To: $DEFMAIL\n"; } else { print "To: $FROM\n"; } eval "print \"$MHEADER\";"; eval "print \"$MAILTXT\";"; # If not we are in trouble once more ... } else { print "Header could not be parsed ...\n"; } } # Take all the stuff from file COPY in doaction. It will process the # whole stuff. &doaction(COPY); if (!$somethingfound) { print "** No objects were found in your message **\n"; } elsif ($haserror) { print "$ACKERR" unless $opt_H; } else { print "$ACKOK" unless $opt_H; } print $ACKSIG unless $opt_H; close(COPY); close(STDOUT); open(STDOUT, ">&SAVEOUT"); # Output the ack, if -M specified then no logfile or stdout will be given. if ($opt_M) { system("$MAILCMD < $TMPDIR/dbupdack.$$"); } else { open(TMP, "$TMPDIR/dbupdack.$$"); while () { if ($opt_l) { print LOGFILE; } else { print; } } close(TMP); } # We sent out the ack, now send out the notifications if needed if (%notify) { &SendNotifications(); } if (%forward) { &SendForwardMails(); } # log all stuff to the right places # todays YYMMDD local($s,$m,$h,$md,$mo,$y,$wd,$yd,$is) = localtime(time); $mo+=1; $mo = "0".$mo unless $mo > 9; $md = "0".$md unless $md > 9; $y = "0".$y unless $y > 9; $YYMMDD = "$y$mo$md"; # This may seem yucky, but is needed to untaint the filename ... $filename = $LOGFILE{"UPDLOG"}."/".$YYMMDD; $filename =~ /(.*)/; $realfile = $1; # first let's log the updates send in or via stdin if (open(LOG, ">>$realfile")) { &lock(LOG); if ($opt_M) { print LOG "\n>>> MAIL UPDATE <<<\n\n"; } else { print LOG "\n>>> STDIN UPDATE <<<\n\n"; } open(TMP, "$TMPDIR/dbupdcopy.$$"); while () { print LOG; } close(TMP); close(LOG); &unlock(LOG); } else { &syslog("ERRLOG", "dbupdate cannot open $LOGFILE{\"UPDLOG\"}/$YYMMDD"); } # then we log the acknowledgement $filename = $LOGFILE{"ACKLOG"}."/".$YYMMDD; $filename =~ /(.*)/; $realfile = $1; if (open(LOG, ">>$realfile")) { &lock(LOG); if ($opt_M) { print LOG "\n>>> MAIL ACK <<<\n\n"; } else { print LOG "\n>>> STDIN ACK <<<\n\n"; } open(TMP, "$TMPDIR/dbupdack.$$"); while () { print LOG; } close(TMP); close(LOG); &unlock(LOG); } else { &syslog("ERRLOG", "dbupdate cannot open $LOGFILE{\"ACKLOG\"}/$YYMMDD"); } # remove the temp stuff we made unlink("$TMPDIR/dbtmp.$$"); unlink("$TMPDIR/dbupdcopy.$$"); unlink("$TMPDIR/dbupdack.$$"); -------- Logged at Wed Dec 14 12:21:49 MET 1994 --------- From GeertJan.deGroot at ripe.net Wed Dec 14 12:21:45 1994 From: GeertJan.deGroot at ripe.net (Geert Jan de Groot) Date: Wed, 14 Dec 1994 12:21:45 +0100 Subject: "Export dbm" program In-Reply-To: Your message of "Tue, 13 Dec 1994 17:03:32 EST." <199412132203.RAA13773@merit.edu> Message-ID: <9412141121.AA07216@ncc.ripe.net> On Tue, 13 Dec 1994 17:03:32 -0500 "Dale S. Johnson" wrote: > It is useful to make bulk data available to general users on the > Internet. Engineers use this for sanity checks against their own > config files, for ad-hoc analysis (e.g. "How many aggregates are > there?"), etc. The PRDB supports this through a variety of reports, > including "net-comp.now" (the most popular) and "nets.unl.now" (a dump > of all fields relating to networks in a machine-parsable format). The > RIPE system supports this same function by making the *.db files > available for anonymous ftp. If you want to (for instance) count the > number of A's B's and C's in the world, you ftp their database and run > you script on your machine. There is a sentence somewhere in the RIPE > documents that says they don't do other reports because reports are so > easy to generate off their .db dump. This dump of data is a basic > end-user deliverable of the system, quite independent of anything that > the members of the IRR need to have in place to achieve their own > synchronization. It is this function that I am suggesting we make > trivially up-to-date where possible by putting the actual db file up > for distribution (rather than a strobed copy of it). [Actually, the RA > has a technical difficulty with this: for security reasons, we do not > want to run anonymous ftp or NFS mounts on the production machine, so > the actual production .db file is not on-line to the ftp machine. But > maybe we can work something else out; perhaps kerberos NFS]. Dale, I don't see the point of this. People either: - want the bulk data for statistical data (count A's, B's, C's) In this case a 24-hour stale file should not be a problem - want authoritive data for object xyz to use for configuration & sanity checking. In this case the whois interface is a much better choice as it provides instant authoritive answers (a copy obtained by FTP would be stale the moment the FTP finishes; whether it's 5 minutes stale or 24 hours stale doesn't matter) We provide a copy of our database every night after cleanup, which is sufficient for the first category. As far as I know, we never received a request for the data as you suggest. Have you? Cheers, Geert Jan -------- Logged at Wed Dec 14 12:39:41 MET 1994 --------- From Marten.Terpstra at ripe.net Wed Dec 14 12:39:38 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Wed, 14 Dec 1994 12:39:38 +0100 Subject: "Export dbm" program In-Reply-To: Your message of Tue, 13 Dec 1994 13:27:50 PST. <199412132127.AA02847@cat.isi.edu> Message-ID: <9412141139.AA07331@ncc.ripe.net> cengiz at ISI.EDU (Cengiz Alaettinoglu) writes * > for making reports would have absolutely up-to-date information. (With * > the caveat that his info might be so up-to-date that there's a half-finish * ed * > record written at the end of the file). * * Dale, * * I do not see the point in doing this. As we discussed, one can not * achieve synchronisation by simply keeping the ftp copy more * up-to-date. * * Also the format of the ftp'able database and one in production may * differ (some parties may use informix for example). Cengiz is right, this would only work if you are using the RIPE software. And then even, the public ftp file and the real database file may be on different machines (which will be the case at the NCC when we switch to our new database server)..... You may suggest to open anon ftp on this database machine just for this reason, but there may be security/access implications. -Marten -------- Logged at Wed Dec 14 12:42:42 MET 1994 --------- From Marten.Terpstra at ripe.net Wed Dec 14 12:42:38 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Wed, 14 Dec 1994 12:42:38 +0100 Subject: "Export dbm" program In-Reply-To: Your message of Tue, 13 Dec 1994 17:03:32 EST. <199412132203.RAA13773@merit.edu> Message-ID: <9412141142.AA07347@ncc.ripe.net> * * Yes, you're right that the internal format does not have to be the same * as the external ftp'able exchange format. However, it means that if * you *are* running the RIPE software and you do use a symlink to make * the ftp'able copy be the real internal copy, then you can build a more * responsive system than if you use another approach. [This is another hmm, symlinks do not work in anon ftp (not when the real file is outside the anon ftp chrooted filesystem) and pose more security issues. * > If you want more up-to-date copy of the database, just play the deltas * > to the copy of the database you have locally. * * Yes, this is the best approach for members of the IRR. But if you are * just Joe User and want to do some data analysis, though, it would be * much nicer to just ftp the thing and get the up-to-date copy, rather * than be required to install the portion of the 181 database engine that * knows how to apply the deltas, and to go through that whole initial-plus- * deltas procedure. I agree with Geert Jan here that Joe User would be happy to have average 12 hour old data .... -Marten -------- Logged at Wed Dec 14 17:09:10 MET 1994 --------- From dsj at merit.edu Wed Dec 14 17:09:07 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Wed, 14 Dec 1994 11:09:07 -0500 Subject: "Export dbm" program Message-ID: <199412141609.LAA03143@merit.edu> Geert Jan, Cengiz, Martin, Well, we seem to have massive concensus that folks aren't much worried about 24-hour stale data for analysis. Geert Jan's comment that he didn't think Ripe had ever received a commplaint or request about the data was the kind of feedback I had been looking for. > As far as I know, we never received a request for the data as you suggest. > Have you? We know that NASA, ESNet, and PREPNet (at least) parsed PRDB reports as part of their own config file generating process. When we turned off some of the more obscure reports in Summer '93, we got various complaints from across the world. In each case we were able to give the folks new ways to get the data. The original Spires PRDB dates back to 1988 (and we took great pains to make Informix support everything that the Spires system did), so some of the "older" folks on the net probably got used to ftp'ing and grepping files before the whois service existed, and they still haven't retrained their fingers. As for the folks who use registries for config-file generators, they may still have need for queries like "I want to interpret the policy word `ANY' as a list of all net numbers registered in the IRR. Please return all those nets". Fortunately, Rick's radbserver allows this request-- I don't know how you'd achieve that with just whoisd. Since we, too, have the ftp respository on a different machine than the database itself (making the change less than totally trivial), I guess we won't pursue this either. --Dale -------- Logged at Wed Dec 14 17:59:50 MET 1994 --------- From dsj at merit.edu Wed Dec 14 17:59:46 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Wed, 14 Dec 1994 11:59:46 -0500 Subject: Integrating Support for PGP into RIPE distribution Message-ID: <199412141659.LAA07747@merit.edu> Hi, Laurent has PGP working with the RIPE-120 Maintainer object. This seems like a generally useful feature. Could we get you folks to integrate the mods to support this into the RIPE code distribution? Laurent will send more details. --Dale -------- Logged at Thu Dec 15 01:45:15 MET 1994 --------- From eric at enfm.utcc.utoronto.ca Thu Dec 15 01:44:46 1994 From: eric at enfm.utcc.utoronto.ca (Eric M. Carroll) Date: Wed, 14 Dec 1994 19:44:46 -0500 Subject: notes from last night In-Reply-To: Your message of "Tue, 06 Dec 1994 15:06:23 -0500". <199412062006.AA07325@zephyr.isi.edu> Message-ID: <94Dec14.194502est.606540@enfm.utcc.utoronto.ca> >RIPE keeps RIPE data, & others (internic, prdb, alternet) > > MCI shadows RIPE, internal MCI, PRDB, CAnet, Internic. Can someone tell me who and where the Internic db is generated and kept? I have a need for it for another project. Eric Carroll University of Toronto Network & Operations Services External Networking Facilities Management -------- Logged at Thu Dec 15 10:09:30 MET 1994 --------- From Tony.Bates at ripe.net Thu Dec 15 10:09:23 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Thu, 15 Dec 1994 10:09:23 +0100 Subject: notes from last night In-Reply-To: Your message of Wed, 14 Dec 1994 19:44:46 EST. <94Dec14.194502est.606540@enfm.utcc.utoronto.ca> Message-ID: <9412150909.AA14462@ncc.ripe.net> Eric, okay...here's the scoop on this. The way this is done is we take the internic reports, networks.txt and network-contacts.txt and then *try* to build ripe objects out of it. The script was originally done by someone in Germany and I just kludged (as is my general style) it to work. I say try as it doesn't deal with ranges, it does some checks as well. I already spoke to you about when I was in US (currently back in A'dam finishing off things) and I will send the script to rr-impl as soon as I can get into MCI to get it (cant at the moment). The alternative is just one copy is made as this is kind of slow and disted around. We probably should just ask the Internic to do this. Unfortunately, they weren't at the GRR bof. I've cc'd Mark to see if this is possible. --Tony. P.S. The indexing of this takes a mighty long time as well. "Eric M. Carroll" writes: * * >RIPE keeps RIPE data, & others (internic, prdb, alternet) * > * > MCI shadows RIPE, internal MCI, PRDB, CAnet, Internic. * * Can someone tell me who and where the Internic db is generated and * kept? I have a need for it for another project. * * Eric Carroll University of Toronto Network & Operations Services * External Networking Facilities Management -------- Logged at Thu Dec 15 13:54:39 MET 1994 --------- From Marten.Terpstra at ripe.net Thu Dec 15 13:54:37 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Thu, 15 Dec 1994 13:54:37 +0100 Subject: Integrating Support for PGP into RIPE distribution In-Reply-To: Your message of Wed, 14 Dec 1994 11:59:46 EST. <199412141659.LAA07747@merit.edu> Message-ID: <9412151254.AA16549@ncc.ripe.net> "Dale S. Johnson" writes * Hi, * * Laurent has PGP working with the RIPE-120 Maintainer object. This seems * like a generally useful feature. Could we get you folks to integrate * the mods to support this into the RIPE code distribution? Sure if it integrates easily. However, from what I saw from the first version, he put another wrapper around every update, which is something I do not like. This should be done inside dbupdate. If Laurent sends me the stuff, I'll try and work it in in a nice way. -Marten -------- Logged at Thu Dec 15 13:59:43 MET 1994 --------- From Tony.Bates at ripe.net Thu Dec 15 13:59:36 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Thu, 15 Dec 1994 13:59:36 +0100 Subject: Integrating Support for PGP into RIPE distribution In-Reply-To: Your message of Thu, 15 Dec 1994 13:54:37 MET. <9412151254.AA16549@ncc.ripe.net> Message-ID: <9412151259.AA16626@ncc.ripe.net> Yep - Marten is correct and I already mentioned this. MCI will be also be doing a PGP/other auth mechanism and the plan is to integrate it directly into dbupdate at some point. --Tony. Marten Terpstra writes: * * "Dale S. Johnson" writes * * Hi, * * * * Laurent has PGP working with the RIPE-120 Maintainer object. This see * ms * * like a generally useful feature. Could we get you folks to integrate * * the mods to support this into the RIPE code distribution? * * Sure if it integrates easily. However, from what I saw from the first * version, he put another wrapper around every update, which is * something I do not like. This should be done inside dbupdate. If * Laurent sends me the stuff, I'll try and work it in in a nice way. * * -Marten -------- Logged at Fri Dec 16 23:19:25 MET 1994 --------- From cengiz at ISI.EDU Fri Dec 16 23:18:57 1994 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Fri, 16 Dec 1994 14:18:57 -0800 Subject: ANY Message-ID: <199412162218.AA14797@cat.isi.edu> Dale S. Johnson (dsj at merit.edu) on December 14: > As for the folks who use registries for config-file generators, they > may still have need for queries like "I want to interpret the policy word > `ANY' as a list of all net numbers registered in the IRR. Please return > all those nets". I think assigning another meaning to ANY is a mistake (two different semantics for one syntactic term). Especially when there are already defined alternatives. We have an implicitly defined community "RIPE" which is the set of routes with "source: RIPE" attribute. I think we should extend this to all databases, i.e. RADB, CANET, MCI, ... communities to mean the set of routes with "source: RADB", CANET, MCI, etc. We can even define an IRR community to mean the set of routes that are registered in a recognized database (note that each database will contain a "registries" object with the names of the recognised databases as discussed in the IRR meeting.) We can also have implicit as macros, AS-RIPE, AS-RADB, AS-MCI to mean all the AS's with "source: RIPE", RADB, MCI etc. If someone wants the above unusual meaning of ANY, he would just type IRR. What do you guys think? Cengiz -- Cengiz Alaettinoglu Information Sciences Institute cengiz at isi.edu University of Southern California -------- Logged at Mon Dec 19 18:05:42 MET 1994 --------- From GeertJan.deGroot at ripe.net Mon Dec 19 18:05:40 1994 From: GeertJan.deGroot at ripe.net (Geert Jan de Groot) Date: Mon, 19 Dec 1994 18:05:40 +0100 Subject: Some more on PGP and such Message-ID: <9412191705.AA13794@ncc.ripe.net> While I'm not trying to start a PGP-discussion here I thought that some background info might be useful. Seems that the possibility to use this varies strongly per country.. Geert Jan ------- Forwarded Message Date: Sat, 17 Dec 1994 11:23:21 +0100 From: Yves Devillers To: Geert Jan de Groot Subject: Re: France & PGP In message <9412170039.AA28528 at ncc.ripe.net> geertjan.degroot at ripe.net wrote: Yves, Out of curiosity, is PGP a legal piece of software to use in France? ==>This is precisely a nightmare to security people in France. The rule is that any encryption (== two way) must be first approved by SCSSI (a body, immediatly under the authority of prime-minister, in charge of acting wrt computer and infomration system security). If it's one way only (eg: Unix pwcrypt) it only need to be "declared" (announced). I had quite some dfiscussion with police people in charge of those problem. They understand our need for privacy and trustness but they object that the first ones to use PGP will be major drug dealers, and other mafia. They disagree with us using PGP (which any way is a violation of french laws since it is not approved/authorised by SCSSI, who can't break it) If not, what are the rules? Is PGP-encrypted traffic allowed via the Paris POP of Ebone? ==>I don't think there are explicit restriction on the type that traffic that can flow through Ebone based on grounds like "unlawfull usage of encryption". The only restriction that may exist are to prevent computer attacks to propagate : RENATER (and EUnet) have the facility to disconnect a line - under emergency, and under control - in case of computer attack. We're discussing adding PGP support in the authorisation mechanism of the database. I'm a bit pessimistic on the legal aspects of this, and would like to find out if it is a problem to you. ==>I am not a bit pessimistic, I simply see no hope here. No organisedd body (identifiable and able to the target of prosecution) can recommend using PGP. With lot of hypocrisy I can only admit that only individuals can indulge into those offenses. I fear that if RIPE-NCC were to recommend that usage your team may experience problems next time they cross the french border (and any way with Europol being deployed you'll experience prosecution without the need for travel). I am convinced neither EUnet not RENATER will be able to accept to use such a recommendation. As I mentionned above, security people are really touchy (err, nervous) on PGP. Yves ---------------------------------------------------------------- Yves Devillers e-mail: Yves.Devillers at inria.fr Institut National de Recherche en Informatique et Automatique Phone: +33 1 39 63 55 96 INRIA, Centre de Rocquencourt Fax: +33 1 39 63 53 30 BP 105, 78153 Le Chesnay CEDEX Twx: 633 097 F France. ------- End of Forwarded Message -------- Logged at Mon Dec 19 19:30:49 MET 1994 --------- From lpj at home.merit.edu Mon Dec 19 19:30:43 1994 From: lpj at home.merit.edu (Laurent Joncheray) Date: Mon, 19 Dec 1994 13:30:43 -0500 (EST) Subject: Some more on PGP and such In-Reply-To: <9412191705.AA13794@ncc.ripe.net> from "Geert Jan de Groot" at Dec 19, 94 06:05:40 pm Message-ID: <199412191830.NAA26655@home.merit.edu> We are using PGP to *sign* the mails. Signature is not encryption. -- Laurent In our previous episode, Geert Jan de Groot said: > > > While I'm not trying to start a PGP-discussion here I thought that > some background info might be useful. Seems that the possibility > to use this varies strongly per country.. > > Geert Jan > > ------- Forwarded Message > > Date: Sat, 17 Dec 1994 11:23:21 +0100 > From: Yves Devillers > To: Geert Jan de Groot > Subject: Re: France & PGP > > > In message <9412170039.AA28528 at ncc.ripe.net> geertjan.degroot at ripe.net wrote: > > > Yves, > > Out of curiosity, is PGP a legal piece of software to use in France? > > ==>This is precisely a nightmare to security people in France. > The rule is that any encryption (== two way) must be first approved > by SCSSI (a body, immediatly under the authority of prime-minister, in > charge of acting wrt computer and infomration system security). > If it's one way only (eg: Unix pwcrypt) it only need to be > "declared" (announced). > > I had quite some dfiscussion with police people in charge of those problem. > They understand our need for privacy and trustness but they object that the > first ones to use PGP will be major drug dealers, and other mafia. > They disagree with us using PGP (which any way is a violation of french > laws since it is not approved/authorised by SCSSI, who can't break it) > > If not, what are the rules? Is PGP-encrypted traffic allowed via the > Paris POP of Ebone? > > ==>I don't think there are explicit restriction on the type that traffic > that can flow through Ebone based on grounds like "unlawfull usage of > encryption". The only restriction that may exist are to prevent computer > attacks to propagate : RENATER (and EUnet) have the facility to disconnect > a line - under emergency, and under control - in case of computer attack. > > > We're discussing adding PGP support in the authorisation mechanism > of the database. I'm a bit pessimistic on the legal aspects of this, > and would like to find out if it is a problem to you. > > ==>I am not a bit pessimistic, I simply see no hope here. No organisedd body > (identifiable and able to the target of prosecution) can recommend using > PGP. With lot of hypocrisy I can only admit that only individuals can indulge > into those offenses. > > I fear that if RIPE-NCC were to recommend that usage your team may experience > problems next time they cross the french border (and any way with Europol > being deployed you'll experience prosecution without the need for travel). > I am convinced neither EUnet not RENATER will be able to accept to use such > a recommendation. > > As I mentionned above, security people are really touchy (err, nervous) > on PGP. > > Yves > > ---------------------------------------------------------------- > Yves Devillers > e-mail: Yves.Devillers at inria.fr Institut National de Recherche > en Informatique et Automatique > Phone: +33 1 39 63 55 96 INRIA, Centre de Rocquencourt > Fax: +33 1 39 63 53 30 BP 105, 78153 Le Chesnay CEDEX > Twx: 633 097 F France. > > > ------- End of Forwarded Message > > -- Laurent Joncheray, E-Mail: lpj at merit.edu Merit Network Inc, 1071 Beal Avenue, Phone: +1 (313) 936 2065 Ann Arbor, MI 48109, USA Fax: +1 (313) 747 3745 "This is the end, Beautiful friend. This is the end, My only friend, the end" JM -------- Logged at Wed Dec 21 18:48:18 MET 1994 --------- From dsj at merit.edu Wed Dec 21 18:46:55 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Wed, 21 Dec 1994 12:46:55 -0500 Subject: Migration to RIPE 181 Message-ID: <199412211746.MAA03912@home.merit.edu> Michael, I had been thinking that this transition to using native RIPE data (with advisory attributes embedded) would be a second phase of AS690 configurations--probably near the end of February. It would be good to get an advance start on it, however. This change will actually be very little coding work for us (just take data from an additional source). It will have considerably more effect on RIPE and end-users. RIPE will need to support the advisory attribute, probably go through an initial mass-loading of it (coordinated with the users), and presumably deal with questions about it for the next six or so months. (Merit will of course also be offering support). Since this change will both be visible to users, and will require changes in their behavior (e.g. maintaining the advisory attribute in their route objects), it would be good to get started on this quite soon. If the advisory attribute was in the software and initial values were in place for all routes, and if we decided that users had had enough advanced notice and training, then we could probably make the step of converting to this data very quickly after the PRDB is retired in January. --Dale > From M.H.Behringer at dante.org.uk Wed Dec 21 07:57:32 1994 > Date: Wed, 21 Dec 1994 12:58:01 +0000 > To: epg at merit.edu > From: M.H.Behringer at dante.org.uk (Michael H. Behringer) > Subject: Re: Migration to RIPE 181 > Cc: dsj at merit.edu > > Hi Elise, > > Thanks for your response. I just want to quickly verify something. > > At 1:53 pm 20/12/94, epg at merit.edu wrote: > [...] > >Yes, we have an agreement with the RIPE NCC that they will support the > >advisory attribute. I believe that when the RIPE NCC implemented > >181, this was forseen. I have copied Dale Johnson who has been > >coordinating with Marten on this so he can correct me if I have > >gotten it wrong. > > I know this is foreseen in the RIPE DB, and I know this has to be done > (thats why I'm asking). Does this mean that by the 15th January the > advisory attribute has to be in all RIPE DB route entries, and all networks > that do not have this attribute by then will not be routed through NSFnet? > > Or will you still keep the current config for a while, to make sure none of > the nets looses US connectivity. If so, when is the deadline for dropping > this? > > >The goal is that no one will have to register twice. We propose to > >derive the AS690 configs from the RADB and the RIPE Routing Registry. > > Good. > > Thanks for your help, Elise, > > Michael > > > -------- Logged at Fri Jan 6 17:02:20 MET 1995 ---------